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!

The TRACE method is used for debugging applications. When a request is made with this method, it will send the full request with the specified verb and reflect this in the response.

The HTTPOnly cookie flag makes the cookie inaccessible from JavaScript. This is to prevent XSS from causing even worse damage, such as getting auth cookies.

What happens when we put these together? If a request was made with TRACE, then the cookie with the HTTPOnly flag would be sent back in the response, bypassing the protection. As a result, TRACE and TRACK were banned from browser requests. But, this was years ago.

This vulnerability is a variation of the HTTPOnly bypass. Instead of simply making a request via TRACE and TRACK, we can force the verb to change on the server-level. There is a non-standard but common header called X-HTTP-Method-Override.

Using the header will bypass the original security protection and send back the HTTPOnly cookie in the response. Pretty good blast from the past on this one!

Cache poisoning vulnerabilities are typically complicated and hard to come by. This author found a load of them and put them together in a single post.

The first issue is a problem with a load balancer. While checking for gathered emails, the author noticed a JavaScript file that contained an email that was not theirs - but had no idea why. After some testing, they noticed this only happened when a particular cookie was removed. It's like the load balancer was caching the file per user but sent back the most recent one if the request didn't have the cookie. This issue was used to salvage a large list of emails from the site.

Another load balancer issue was the result of a shallow copy vs. a deep copy. It turned out that once per hour that a caching bug occurred that led to an email leakage. Weird!

The final bug started off as hunting for XSSI issues. One of the JavaScript files was constantly changing information in it. This file contained authorization information for each user. What could go wrong with this?

The author deleted all of their cookies of the request still went through! But how? The URL had several other parameters, such as the location and other things, but they weren't random. It turned out that the CDN was caching these JS files! By brute forcing the loc parameter, it became possible for an attacker to steal auth information. Pretty neat!

A few things to look out from this:

• Are emails or IDs what you expect them to be?
• Test out how the caching is being done. Remove parameters, cookies and other things.
• Is the JavaScript dynamic? Seems to cause lots of problems if it is.

Mastodon is an open source alternative to Twitter. With Elon Musk taking over Twitter, many people have flocked to this instead. Gareth decided to take a look at the security of the platform.

The social network allows you to enable HTML! Sounds like XSS by default - but the Markdown/HTML allowed was pretty limited. Bold tags and others were allowed but not much else. The author found the source code for parsing the HTML elements and started to look for bugs.

The application allowed for the title attribute to be put into a tag. While playing around with double quotes, single quotes and quote-less attributes, they were unable to escape. Now, when combining find and replace with HTML parsing, is where things go bad. Gareth learned that the text :verified: would be replaced by the verified icon (blue checkmark). What happens if we put this into the middle of the title attribute?

The code below would magically get transformed an break out of the HTML when replaced! Below:

<abbr title="<a href='https://blah'>:verified:</a> 
   <iframe src=//garethheyes.co.uk/>"
> 

After:

<abbr title="<a href='https://blah</a>'><img draggable=" false" ... ><
iframe src=//garethheyes.co.uk/>

If you look closely, the double quote from the swapped in text will finish our HTML! Now, our iFrame will get rendered. What can we do with an HTML injection bug and a strict CSP?

The final step of the attack was creating a legitimate looking login page via injecting an iFrame. What's interesting is that the form would autofil in Chrome! Additionally, we can make the input invisible and give them a button to click which would send form with the credentials. Pretty neat phishing attack!

DFX Finance is a decentralized exchange for stablecoins. The exchange had flash loan functionality as well. A flash loan is where a large amount of money can be borrowed by a user, as long as the funds can be sent back with a fee.

The flash loan functionality completely lacked reentrancy protection. A nice visual from Peckshield shows a call to the flash() function then the deposit() function without escaping it.

To prevent the stealing of funds on the flash loan, the balance after the flash loan MUST be equal or exceed the original balance. Here's where the vulnerability lies: this checks the overall balance!

An attacker can take out a flash loan then deposit the funds into their account! By doing this, the balance is the same and the attacker has tricked the contract into thinking they have a very large sum of money.

A few interesting takeaways. First, reentrancy protection should be added everywhere, even when it seems unnecessary. In this case, the flash loan didn't have the reentrancy protection but the deposit did. However, the deed was done!

Second, this was audited by Trail of Bits in V1 and the functionality for the flash loan was audited by PickAx for V1. But, the reentrancy bug was not caught in the V2 audit. Overall, interesting bug from different function calls to the contract. Another discussion can be found at Twitter and Halborn.

Apache Batik is a library used for parsing Scalable Vector Graphics (SVG) and transforming them into other formats. Even crazier, the documentation mentioned executing JavaScript, loading and executing Java classes and many other things. This felt like a SSRF goldmine to the attacker, with several previous vulnerabilities indicating this.

A common use case is taking in an image or URL to an image to transform it using Apache Batik. The tool has many built in protections in place for scripting and other things. For ScriptSecurity, there are several different settings from no scripts to allowing scripts from loading remotely.

In the security controls, there is the concept of origin within a URI. In particular, local SVG files can load scripts but not remote scripts. If we can bypass this control, we can do some horrible things!

The parsing to ensure this works properly had a bug in it though. First, the script URL and the document URL get the host removed from it. Next, there is a check to see if the two hosts are the same. The getHost uses the standard Java function, which is known to behave strangely with non-HTTP protocols.

The host for a local file (file:///some_file.txt) will always return NULL. Things like an external file and HTTP will properly return the host, making the check succeed. However, jar or Java Archives will also return NULL! Since the domains are now the same, the security protections no longer work as intended.

The obvious attack vector is SSRF, but we can do more. Apache Batik supports remote class loading for with Java bindings. By including a remote class in our SVG to execute a JAR file, we can execute some Java code. Using this, it is pretty trivial to execute arbitrary code on the system.

An additional way, if remote JAR loading is not allowed but scripts are, is abusing the ECMAScript engine. In particular, accessing the Java runtime from ECMAScript gets trivial code execution, by design. The official security guide for the ECMAScript standard is securing the application with a Java Security manager which is probably never used.

Overall, parsing differentials are absolutely fascinating! It's super interesting seeing how this default and unexpected mechanism in Java caused such a big problem. However, the capabilities of these Apache products are just too powerful.

In April of 2022, Meta announced a Contract Point Deanonimization. These guidelines are bugs that enable matching of Uniquely Identifiable Information (UII) to User IDs. This goes from finding email addresses and linking that to a profile to many other things.

Naturally, emails and other things are important for the login/signup process. So, with this new program, the author decided to take a look here.

When passing an email to the password reset functionality, there is a masked email address. While playing around with the older domain of the Enterprise version of facebook (workplace), the author noticed some slightly different functionality on it. In particular, ONLY the email address and username were supported (not the phone number).

On the old workplace domain, they tried passing valid Meta accounts but nothing worked. But, it was still using some of Facebook's account cookies, indicating that the two domains were somewhat linked. They started the flow on Facebook then used the cookies on the workplace domain.

When they visited the page for entering the OTP the email was shown in an unmasked state. This is a perfect example of an information disclosure bug that this new program is trying to fix! The actual fix was to mask the email address on the reset page and only allow OTP validation to happen on the respected domain.

Overall, it's a pretty neat bug! With these extremely large systems, the intermingling of services can cause problems. This is where the recon is incredibly important.

Recently, the author of this post had found an issue with the account recovery flow. While trying to send multiple OTP codes, they hit an SMS captcha flow. Most people would stop here, but the author decided to check out the format of the captcha.

The captcha URL had a parameter called next. This parameter could be pointed to sensitive GraphQL operations, such as posting to the timeline or changing email privacy settings.

What this turns into is a CSRF attack, since the POST request will send the CSRF token (since it's a request being made from the page). The CSRF is triggered if a user clicks the continue button from the captcha with the malicious URL.

I'd personally never seen a bug like this! Seeing a URL control all of the content of a request is pretty interesting. The fix for this was adding a message authentication code (MAC) to ensure the URL couldn't be tampered with. Additionally, only a proper OTP code can trigger the action URL now.

Extensions within the Chrome browser are immensely important for building out the correct functionality. However, these extensions have incredible capabilities compared to the standard web page. These APIs for the extensions must be secure to ensure that no privilege escalation can occur.

The extension debugger API allows for debugging an extension during the development phase. When a tab is connected to this, it starts by navigating to a URL to see if the debugger is allowed to attach to the new URL. Of course, this needs to have the proper permissions to do so.

If you try to attach to webui, then the debugging session should be terminated. Once this happens, the onDetach event triggers. I assume that webui is a general term for web pages, with some of the pages within Chrome being more privileged than others.

The bug is that during the onDetach event being triggered on the termination of the API, the re-attach can occur on the tab. The author believes this happens because the URL has change on the tab has not been committed yet, which results in the permission check failing. Instead of looking at the webui URL on the tab, it looks at the original one, which has different permissions.

Why is this bad? If you can hit the debugger API, then you can add code into the page. By doing this on a privileged page, a serious privilege escalation could occur. This could even be used to execute commands on the device.

Overall, this is an interesting bug that comes down to a subtle logic issue. Sometimes, dynamic testing and trying out random things is the only way to find issues.

Team Finance, a crypto token launchpad, was hacked. They were attempting to migrate from the Uniswap v2 to v3. This whole project was a safe keeping for funds will some sort of migration was happening.

The migrate function for the smart contract had a faulty locking mechanism. The validation checked to see if the address belonged to a ERC20 token. Since this can be controlled by an attacker, they were able to lock their own ERC20 token in it and make the call themselves.

Once the bypass on the call was found, they could perform a liquidity transfer to a new attacker controlled Uniswap v3 pair. Then, the leftover liquidity that wasn't transferred was considered the profit of the swap. Alongside the bypass of the caller verification, an attacker could set the initial price of the token in the pool.

Now, the transfer was performed with a skewed price, giving the attacker a massive refund as profit. This finding was missed by Zokyo security. A good reference of this issue was on Rekt.news as well.

Defense in depth of not letting any token be used in the contract would have solved this problem. The security of the migration function relied upon this. Further analysis was done by Slowmist.

Overall, good audits don't solve everything (unfortunately) and migration code should be considered for the security of an eco-system. An interesting bug that allowed the hacker to get a major payout from specifying a bad initial price.

Kerberos is an old authentication protocol that is still used all over the place. The core security concept is using encryption to prove knowledge of user credentials. In the handshake process for this, the user can specify what encryption protocols they support. This is a blessing to make it usable everywhere but a curse because of security.

Modern Windows versions disable DES and prefer AES. However, lurking below the surface is another symmetric algorithm - RC4. The stream cipher is known to have many security issues, such as known plaintext attacks. In the RFC for Kerberos in 2006, a modification of RC4 is used in order to work around the known weaknesses of the algorithm. What are the changes?

• The encrypted data is protected by a keyed MD5 hash, which is used to prevent tampering. The key (confounder) is a 8 byte value.
• The key is derived from the hash and its base key used in the hash. The previous key and the confounder make sure that the same key is never reused for encryption.
• The base key is NOT the user key but is derived from a MD5 HAMC keyed with the user's key.

The generation of the user key for RC4 Kerberos has historic principles that make it the worst part of the algorithm. When trying to migrate from NTLM authentication (which transfers MD4 hashed passwords), they decided the best course of action was simply using this hash as the RC4-HMAC Kerberos key. They creates a few problems:

• If an attacker has access to the ciphertext of the RC4-HMAC key, they can attempt to brute force the password. The key isn't random - it's the output of MD4.
• Kerberoasting can be used here as well. This is the process of requesting a ticket from the Ticket Granting Service (TGT), which is encrypted with this key. Using a known plaintext attack, we can attempt to brute force the key as well. There is a variant of this called AS-REP Roasting
as well.

Everything prior to this was background. The author was simply trying to understand on the Windows Defender Credential Guard (CG) implements the various Kerberos encryption schemes. They started reverse engineering the DLL CRYPTDLL.DLL. Although this interface is undocumented, the DLL had to export functions and they were easy to work with. While doing this, they noticed there were several private types for encryption they wanted to dive into.

One of these algorithms was RSADSI RC4-MD4. This stood out to them for a few reason:

• The key is 16 bytes but only the first 8 are used.
• The derived session key is only 5 bytes of randomness. The rest of it is 0xAB repeated.
• There's no key blinding. Practically, this means that ciphertext can be duplicated between two messages.
• No cryptographic hash to protect tampering with the ciphertext. With RC4 being a stream cipher, this is particularly bad.

The first thought on exploitation was brute forcing the 40 bit key - but we can do better.

A message to the Key Distribution Center (KDC) can be forced to return an error message with an encrypted timestamp. Since the timestamp is known, a plaintext attack can be used to recover the key! In particular, plaintext byte XOR timestamp byte = key byte. Additionally, the AS-REP is encrypted with the same session key. Since we know the bytes for the keystream of RC4 from the timestamp, this can be used on the AS-REP message as well.

Unfortunately, the overlap of the timestamp and other known values is only 4 bytes of the 5 byte key in the AS-REP structure. Of course, we can brute force the final byte by requested encrypted data and attempting to decrypt it. This attack does require a proxy in order to MitM the request being made to the KDC. Can we do this without a privileged network position?

If pre-authentication is disabled, then anybody can make a request to get the TGT for a user and specify the RC4-MD4 encryption algorithm. With this, KDC sends back the encrypted AS-REP structure. The very beginning of this structure is DER encoded data, which should be consistent. So, we can use a plaintext attack once again to derive the streamkey for RC4. At this point, we still don't know the 40 bit key that we're trying to obtain or the streamkey for those bytes.

With this much information, we are able to successfully encrypt a timestamp to send back to the KDC though. Now, it's time for the magic and hacker mindset... the timestamp is an ASCII string that is null terminated. If the string is NOT null terminated, then an error message is sent back. If it is, then a success message is sent back. Using this information, we can determine when the plaintext is null. Since we have the encrypted byte we created and know this is a nullbyte, we can recover the keystream for this.

The trick above can be used for each byte in the timestamp in order to recover each keystream byte to decrypt the AS-REP structure! There's a second trick that must be used in order to keep writing nullbytes though... A quirk of the DER formats long form can be used to continue reading bytes past the point of the actual timestamp. Since we have 2⁸ possibilities for each byte and 5 bytes to get, a total of 1280 requests are required. Not bad compared to the 2⁴⁰ from before.

Overall, an absolutely amazing post for Project Zero. A few lessons learned from this:

• RC4 is bad and stream ciphers are hard to use properly.
• Don't compromise when writing a protocol for cryptography. Everything should be designed with as much consideration as possible; from strong algorithms to large keys.
• Tricks may require the addition of another trick! This is seen with the nullbyte padding attack requiring the DER format attack. I commonly think of a trick and if the trick doesn't work, I move on; I should consider this attack in future work.