Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Bitlocker is a Full Disk Encryption (FDE) solution offered by Microsoft for the Windows Operating system. There are many different configurations for how this is setup practically.

One of the setups is having a Volume Master Key (VMK) within the Trusted Platform module (TPM). When the decryption process needs to take place, the key is sent from the TPM to the computer. The problem with this is that if you can sniff the TPM to sniff the data, including the key, to eventually decrypt the entire drive.

The first part of the article is dedicated to finding the TPM (and the pins on it) on a Lenovo Thinkpad. After doing some digging, they figured out that this was using the LPC protocol in order to send data, which requires 6 pins.

Even though the pins could be directly connected to via direct soldering, they ended up finding a series of pads to connect to. From doing continuity tests, they figured out what each pad did, eventually getting a clean connection!

To originally observe the traffic, they used a MSO 19.2 logic analyzer. This worked for basic analysis, but the sample rate on the logic analyzer was not fast enough. So, they setup an FPGA to do the sniffing instead with the LPC Sniffer tool.

At this point, the bus could be sniffed to see all data coming and leaving the TPM. Using this, the VMK header can be identified, with the encryption key being viewable directly afterwards. At this point, it is real easy to view the key!

They had a consistency problem with output. As a result, they ran this test a few times and compared the output. As doing this, they were able to easily figure out the content. Damn, the key had been taken once it was sent out of the TPM.

After this, it was possible to decrypt the disk via the dislocker utility. This allows you to specify the VMK key, without rebuilding the FVEK (whatever this is). Now, Bitlocker was completely circumvented simply because data was being sent out of the TPM. The original article comes from Pulse Security.

Matt Blaze was given a grant at the University of Penn to look at the security of various wireless networking solutions. The goal was to improve the two-way public safety radio, known as APCO 25. This is the standard for digital radio used by the DoD, police stations and many other things. This has some encryption primitives but were not great at the time.

These radios are made by several vendors. At the time, Motorola was the only vendor that could load on encryption to be used though. These could be dropped in for standard radio or trunk radio. State and local tend to use trunk and the federal used more traditional systems.

The P25 Voice protocol looks as follows:

• 9600 bits per second with 2 symbols being sent at a time.
• 12.5KHz bandwidth, to co-exist with existing analog FM radio.
• IMBE vocoder. Does a good job at encoding voices for being digital! The packets hold 180ms of audio then add some metadata.
• All transmissions are a one-way model with no ACK or sessions. This makes security complicated because handshakes are not longer possible in this system.

Since this is a one-way protocol, the entire system only has symmetric encryption. It uses AES, DES and several proprietary variations of RC4. The keys, used for decryption, must be loaded on the radios in advanced. Additionally, there is an over the air rekeying (OTAR) in order to update the keys for the radio; these keys do expire.

The radios error on the side of demodulation. If the radio has encryption enabled but the sender is not encrypting the data, then the voice is demodulated anyway. There is a button to turn on and off secure mode, as well.

The first issue is that the voice traffic is NOT authenticated what-so-ever. This means that encrypted traffic can be replayed at will. Even though we do not know the exact content of the message, this could be used to spoof the user being used. If nonces (number used once), then this attack would not be possible.

The next attack allows for the discovery of all radios around. When using the radio, a Unit ID, TalkGroupID and NAC are sent with every transmission. The Unit ID is supposed to be encrypted but on the ping message, which can check the encryption ID, the Unit ID is sent back in the clear. This helps to discover all idle radios in the area by using the issue mentioned above. The author calls this the Maurauder's Map of police cars and things.

Another interesting attack was the encrypted DoS attack. By selectively jamming a specific part of the frame (64 bit NID), the entire rest of the attack would be thrown out. For 864 symbols of data, only 32 symbols needed to be jammed, which requires a substantially less amount of energy for a jamming attack than what should be required. Using this, if somebody was using the radios in encrypted mode, they would get frustrated and switch back to the unencrypted mode, allowing you to hear the text in the clear. Kevin Mitnick used to do this back in the day!

Even though the over the air rekeying is added, there is a major problem with it. When one radio attempts the rekeying, if one of them is NOT listening, then they do NOT get the key. While in the field, there is no way to rekey a radio, making it completely useful. Practically, this means that NOBODY will be using the encryption.

To make matters worse, the authors noticed that many of the stations using P25 sent data in the clear, with no encryption! "The first rule of cryptoanalysis: Look for plaintext". They setup a large amount of radios to sit on the federal P25 spectrum. By looking at the encrypted lines, they would find the bands sending sensitive information. It turned out that some of the radios did not have the encryption on, with tactical information being leaked, confidential informants and many more. The only agency that they never saw data from was the postal inspector (lolz).

The mitigation for P25 not super helpful. Instead of giving real findings, the author simply says that the protocol needs to be completely rewritten in order to be secure. Currently, the usability is poor, making it easy to accidentally send data in the clear.

Overall, the talk sheds light into issues with the P25 protocol used in lots of radios today. There is a false sense of security in the radios because of a fail open method and usability problems making it trivial to accidentally send data in the cleartext. The talk has many great stories of them interacting with law officials and many practical things that happened during the research.

Matt Blaze was given a grant at the University of Penn to look at the security of various wireless networking solutions. The goal was to improve the two-way public safety radio, known as APCO 25. This is the standard for digital radio used by the DoD, police stations and many other things. This has some encryption primitives but were not great at the time.

These radios are made by several vendors. At the time, Motorola was the only vendor that could load on encryption to be used though. These could be dropped in for standard radio or trunk radio. State and local tend to use trunk and the federal used more traditional systems.

The P25 Voice protocol looks as follows:

• 9600 bits per second with 2 symbols being sent at a time.
• 12.5KHz bandwidth, to co-exist with existing analog FM radio.
• IMBE vocoder. Does a good job at encoding voices for being digital! The packets hold 180ms of audio then add some metadata.
• All transmissions are a one-way model with no ACK or sessions. This makes security complicated because handshakes are not longer possible in this system.

Since this is a one-way protocol, the entire system only has symmetric encryption. It uses AES, DES and several proprietary variations of RC4. The keys, used for decryption, must be loaded on the radios in advanced. Additionally, there is an over the air rekeying (OTAR) in order to update the keys for the radio; these keys do expire.

The radios error on the side of demodulation. If the radio has encryption enabled but the sender is not encrypting the data, then the voice is demodulated anyway.

Matt Blaze was given a grant at the University of Penn to look at the security of various wireless networking solutions. The goal was to improve the two-way public safety radio, known as APCO 25. This is the standard for digital radio used by the DoD, police stations and many other things. This has some encryption primitives but were not great at the time.

These radios are made by several vendors. At the time, Motorola was the only vendor that could load on encryption to be used though. These could be dropped in for standard radio or trunk radio. State and local tend to use trunk and the federal used more traditional systems.

The P25 Voice protocol looks as follows:

• 9600 bits per second with 2 symbols being sent at a time.
• 12.5KHz bandwidth, to co-exist with existing analog FM radio.
• IMBE vocoder. Does a good job at encoding voices for being digital! The packets hold 180ms of audio then add some metadata.
• All transmissions are a one-way model with no ACK or sessions. This makes security complicated because handshakes are not longer possible in this system.

Since this is a one-way protocol, the entire system only has symmetric encryption. It uses AES, DES and several proprietary variations of RC4. The keys, used for decryption, must be loaded on the radios in advanced. Additionally, there is an over the air rekeying (OTAR) in order to update the keys for the radio; these keys do expire.

The radios error on the side of demodulation. If the radio has encryption enabled but the sender is not encrypting the data, then the voice is demodulated anyway.

Shopify is a complete commerce platform that lets you start, grow, and manage a business. It has a protected atom feed, which is similar to RSS. These can be protected by a password.

The atom feed was password protected. By finding the preview version of this, the title and some of the content would be seen. Viewing this resulted in a leak of private information.

Overall, this was a really simple bug; just a lack of auth on an endpoint. Sometimes, accessing data in unexpected ways has access control problems. This reminds me of a DropBox vulnerability from a 2020.

The blog is from a hacker who hit on Microsoft and Google for several years. This post is about Google, GSuite, a Microsoft 365 similar product.

In GSuite, there are Super Admins. These users can create groups, manage users, change passwords of users and manage everything else. The author thought "Could I add myself to a GSuite organization and make yourself a super admin?"

The author was looking on domains.google.com. This is a registrar hosted and run by Google. On the registrar, there is a feature that lets a user create a GSuite subscription and manage it from there.

A lot of vulnerabilities in large organizations come when mixing and matching services together. Why does Google Domains have the ability to manage a subscription and add users? I have no idea, but it is there!

If the functionality is existent in this area of the code, it needs to be just as secure as the main location. The author found a trivial IDOR vulnerability on the Google Domains functionality for adding super admins. By setting the ID and name to be another organization, you could create a Super Admin in the other users account.

The outcome of this was the ability to become a Super Admin in any GSuite organization. This is the prized jewel of Google hacking! Finding bugs in large organizations often comes from findings more lax places that implement the original functionality improper.

Stark Bank is a financial technology company that tries to simplify banking operations, such as transfers and payments. They maintain several cryptographic libraries for several different eco-system. One of these is a Elliptic Curve Digital Signature Algorithm (ECDSA) library.

Conceptually, I know it is based upon finding points on a curve. The simplified algorithm goes as follows:

1. Check that r and s are integers in the [1, n-1] range where n is the curve order and r,s are the points on the curve.
2. Compute u1 = zs^-1 % n and u2 = rs^-1 % n.
3. Compute the elliptic curve point (x, y) = u1 G + u2 Q where Q is the publc key.
4. If r congruent x % n. then the signature is valid.

The library was not validating that r and s were within the proper range. As a result, these could be specified as 0,0. In many languages, the multiplicative inverse returns zero if supplied with 0 (even though it is undefined). Why does this matter though?

All of the math operations above turn into 0. As a result, the signature algorithm can be passed by simply supplying a signature of 0s for r and s. Wow, that's insane and one hell of a find! This affects all of their libraries in Python, Java, DotNet, Elixir and Node.

Concrete CMS is designed for ease of use, for users with a minimum of technical skills. It enables users to edit site content directly from the page. It provides version management for every page,similar to wiki software, another type of web site development software.

As a limited privileged user, a URL can be entered. Then, the CMS will use CURL to download this locally. There is a validation done on the file type to ensure that PHP files and other malicious types cannot be added to the filesystem. However, the CMS downloads it locally with CURL prior to doing this validation. Can we access this?

The file is created in a temporary directory. By reversing how this code works, they found that the generation of the directory name was predictable. It came down to the usage of milliseconds to generate the ID. By syncing the time with the responses from the server, this can be done fairly trivially with the syncing and some brute forcing.

There is one thing that is confusing though: they claim that they extended the race window by adding a sleep command to the PHP file. If the PHP code is being executed (the sleep call), then why do you need to call it externally? This was really strange to me and I'm not sure why they did not pop a reverse shell from the initial execution of the payload. The only explanation would be to add a permanent backdoor.

The article alludes to the CURL command having an SSRF bug as well, but they decide to save this for another day. Overall, the race condition PHP execution is a good find! Don't let the error message fool you; trust but verify.

Content Security Policies (CSP) are rules to load resources in CSS, images and many other things. This can be defined in a response called the Content-Security-Policy or put into <meta> tags on the HTML. The CSP is implemented in most browsers but is quite complex to implement.

When a violation is made of the policy, this information can send the information. There are quite a few ways to send a report: the CSP report-uri in a CSP, a SecurityPolicyViolationEvent and two others.

There was one major issue with the original specification of the CSP though: the CSP recommended that the origin of the blocked URI was to be displayed. This is a problem because the blocked URL,from the redirect, could contain sensitive information cross origin.

Leaking the origin by using the blocked-uri has happened multiple times. In particular, Egor Homakov which uses a variation of this to fingerprint users across origins.

Safari does not adhere to the W3C specification. As a result, we can use the CSP to block a cross-origin redirection. When the CSP denies the request, the value being sent now may have a secret inside of it! Using the event handler, we have leaked a secret cross origin.

To exploit this with SSO, OAuth can be destroyed from this. When the website goes to the SSO location and gets redirected with a new OAuth code, we can leak the secret token from this! Damn, that's the worst cross-origin browser bug I have ever seen.

After reporting this to Safari in February of 2020, the response claimed that this was not a risk to WebKit users. It seems that the vulnerability was misunderstood by the WebKit team.

What are some fixes to this vulnerability on an OAuth implementation? Using SameSite cookies (I assume strict but they do not say), POST messages instead of GET, using postMessage and a few others. These are not true security fixes; but a workaround for a Safari bug that happens to not make implementations vulnerable.

To prevent this in the browser, include the original request in the error message and not he original target. They ended up finding a similar vulnerability in CORS as well!

We often take the security of browsers for granted and assume things work properly. What happens when the browser is bad? Companies have to include custom fixes and all hell breaks loose. From this, they got over 100K in bug bounties!

Trusted Execution Environment (TEE) is the secure part of TrustZones. This has has two worlds: secure and non-secure. The secure world performs sensitive tasks that are considered sensitive, such as encryption or DRM. Samsung TVs implement this technology for processing video files.

In TEE, the GlobalPlatform API is commonly used. When calling these APIs, the parameters are not properly validated for the address being written to. As a result, an address in the secure world can be specified!

By doing this, it is possible to write to an arbitrary address within the trusted application (TA). The fix for this (5 of them) was to validate the parameters being sent in.

Another vulnerability was a NULL dereference caused by not checking the return value in Malloc. Theoretically, the TA could be mapped to zero, potentially making this exploitable.