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!

DNS rebinding is a fairly well-known attack used in various situations. The idea is to trick the browser on the origin of the website by changing IP address between DNS requests. For instance, if it's 1.2.3.4 initially but an internal IP afterwards, like 127.0.0.1, then we can make requests to localhost and bypass the same origin policy.

Historically, these were used for accessing internal networks of users within the browser. With the invention of headless browsers, this has became a good attack method on it as well. In a previous post by the authors, they used this to get access to EC2 metadata credentials on their product. They could run this as long as they wanted, with no time constraints. However, what if we don't have unlimited time?

The main constraint of DNS rebinding is the time between DNS lookups. Since browsers cache DNS, we need a way to force a new lookup. A popular way to force a new lookup is by flushing the cache by overloading it with so many entries, which takes about 10 seconds. However, other things like Ubuntu will take 5 minutes or VPNs take 30.

In previous research, Craig Heffner performed DNS rebinding by relying with multiple A records for the same domain in the same response. The 2 records were a public IP and a private IP. To make this exploitable, the browser must use the public IP first then the private one later. To force the usage of the second (private) entry a TCP RST was sent to the browser on the original IP address would fallback to the second one, which was a private IP.

With this in mind, they decided to look various browsers to see if new techniques could be discovered. On Safari, the private record is prioritized. Additionally, the requests for the A record and AAAA records were done in parallel. Once the first DNS response is received, regardless of the ipv4 or ipv6 status, this will be used for the DNS request.

Putting this information together, a slight delay on the private IP will lead to a quick DNS rebind. First, return the public IP for the website in one of the responses, but faster than the other. Once the private IP is returned, the browser will use this one instead. Now, we have a super faster DNS rebinding attack on Safari.

On Chrome, it has a priority list: local IPv6, public IPv6, local IPv4 and public IPv4. When Chrome knows about multiple IP addresses, it will try a different IP address as soon as one of the servers resets the connection. So, putting this all together, we can attack the browser as follows:

1. Load the website.
2. Have an A record pointing to the local network and an AAAA (IPv6) pointing to a public website that you control.
3. Chrome will use the IPv6 for the initial request.
4. Shutdown the public server. This will send a reset.
5. The loaded page will now use the private IPv4 address instead of the IPv6, allowing for a SOP bypass.

Private Network Access (PNA) is a specification for blocking pages loaded over HTTP to make request to private networks. This prevents the exploitability of DNS rebinding because we can no longer access private IPs. However, in Chrome where this is implemented, this is NOT done on iFrames yet.

The attack is exactly the same as the previous Chrome issue except with a twist of using an iFrame in the middle of it. From the previous step 5, instead of making the request to localhost directly, we do this inside of an iFrame. Load the private URL in an iFrame. After this has been done, inject a script into the loaded iFrame. Now, you can make requests successfully with the DNS rebinding.

Overall, an amazing list of techniques to make DNS rebinding more exploitable. This is one of the best articles I've read in a long time and is just amazing research. Thank you Daniel!

The SSH ProxyCommand is used for proxying SSH connections. In particular, custom commands can be used to connect to the server. Within these commands are variables, such as %h for the hostname or %p for the port.

These parameters are not being sanitized when used within the SSH command scripts. So, a malicious host, port or many others could be used to get command injection in the SSH proxying setup.

At first, I didn't understand where this came from. They provided a command from Github for a PoC. In this example, the submodule files contain ssh://`open -aCalculator`foo.example.com/bar, which creates a command injection on the proxy setup.

Be careful what you download! This could have been exploited to torch people using git in many different ways. Awesome, yet simple bug in an everyday system.

In the Wildcat protocol, the WildcatMarketControllerFactory is used for deploying a contracts. The function determines if the contract has been deployed to by checking if the codehash is bytes32(0). At first glance, this seems reasonable but has a weird flaw.

Addresses only return 0x0 as the codehash if they are empty. What does empty mean here? The 0x0 is only returned when is it COMPLETELY empty. If it is an account without account (aka funds exist there), then the empty hash is returned.

If anyone transfers 1 wei to that address, then the protocol is harmed. The deployments of many things will simply NOT work. MiloTruck seemed very proud of this finding, and I agree, it's pretty sick! I didn't know the difference between an empty account and a non-existent account for a codehash.

When a user is creating a loan, they provide the signature of the opposite party. If the sender of the call is a borrower, then the lender would need to be the other signature. All of these signatures are validated within the protocol.

The side of the signature is not validated though. As a result, an attacker can force a signature to be used for the wrong purpose. In particular, a signature for a borrow can be used to force a user to become a lender.

Cryptography is great! However, the use case is just as important as the math.

In 2023, MiloTruck made the most money on Immunefi at 172K. In this post, he goes through the year and what they learned. I'll be going through some of their takeaways, as these provide the most value.

The first takeaway was that math is complicated. By getting the only medium finding via an unsafe cast, they learned this. If it's complicated to you, it's likely complicated to the developer. If it's complicated to the developer, there is likely to bugs.

Later down the road, they did 5 audits in one month. In this, they only spent a small amount of time in each. This was a mistake since many bugs come from a deep, deep understanding the vulnerability. During this month, they learned that contests should be chosen according to your skill level. Additionally, simple and small contests should be avoided, as there aren't many bugs and if there are bugs, they'll be dupped to hell.

The next big audit was Chainlinik CCIP. This had a payout of $185K for the H/M pot. For this, they went all in. They read through documentation, similar protocol audits and talks before the contest. By doing this, they understood the bugs to look for and had a deep understanding of the protocol quite quickly. This led to 3/3 highs with an 8th place finish.

During an audit where they found 8/8 mediums, they only reported 6. They didn't report 2 of them because they considered the issues acceptable risks. They learned to always ask the protocol team whether the behavior you described is intended. Worse case scenario, you report it as well.

In an audit of the Wildcat protocol, they learned to always read the documentation and whitepaper of the protocol. This allows you to understand the expected use cases of a protocol, which may not always be obvious.

At the end, they mention why they were able to achieve this: super competitive and a high standard. By reviewing previous misses they were able to adapt their auditing methodology to not miss bugs in the future. Second, they wrote up PoCs on every bug that was possible and wrote very, very good reports, which gave them nice bonuses. Additionally, really, really understanding the protocols and in-depth with hard edge cases is what they seem to be good at.

The final section might be the most interesting: Are Contests Worth It? You can't earn millions from C4 with how much competition there is. So, the top talent is moving away to other locations. Sherlock tried fixing this with a Lead Senior Watson, which takes a fixed amount of the pool. Private audits, Immunefi, auditing firms and Spearbit are much more lucrative.

So, should you do contests? It's a great place to learn and get opportunities. From this, they got offered from Trust Security and Spearbit. Overall, awesome post on their learnings and perspective from the year of auditing.

Beanstalk is a stablecoin protocol. In order to peg the price of BEAN, the function convertFacet() is used. When passing in token addresses for the stablecoin pool, there was no validation that the well address is valid.

The function convert() takes in three parameters: convertData structure, an array of ints called stems and an array of int called amounts. When providing a list of stems and amounts, there is no validation that these are NOT zero length. I imagine that a loop contained some validations but didn't consider this case.

If the convertData has a type of WELL_LP_TO_BEANS, it contains a well address. When using this, the well address not was verified to be an allowlisted value. This allows for an expected and trusted contract to be spoofed with arbitrary values.

Later on, a call to _wellRemoveLiquidityTowardsPeg is made. This has a call to removeLiquidityOneToken on the well, which can return extremely small values. So, the convert function is made with a BEAN deposit without withdrawing any real tokens. Eventually, these can be claimed by an attacker through a different function call.

There are two issues within the code. The first one is a lack of validation of the zero length arrays leads to several values being zero during the conversion. The second issue is with the missing validation on the trusted address for the well. These together lead to a horrible issue where 22M could have been stolen.

Overall, a fairly simple attack. The zero length array trick was fascinating to me on this though. This bypassed some math been done and sanity checks, which was super cool to see.

When writing code that needs to be high performance with multithreading, data may need to be read or written across various threads. If you do not do this securely, then you end up with race conditions, putting the system into weird states. So, these are strategies on how to do it securely.

There are three main types of data: stack, global/static and heap. Stacks are per thread and then global/static & heap data is per process. So, locking needs to performed on global/static information.

The first method is the most simple: mutual exclusive locks. With this method, there is a variable that is associated with the rest of the data that determines if the information can be accessed. If the data is 0, you can access it but you must acquire the mutex by setting it to 1. Once you're done, release it by setting it to 0. If you come across the lock at 1, then a thread sleeps until it's 0 again.

The second pattern is readers/writers locks. This is used in cases where the thread needs multiple readers at the same time with only infrequent writes. To obtain an initial lock, call the function rw_enter. Many users can use this for a read at once.

If a thread needs to write, the mutex can be upgraded with a call to rw_tryupgrade. Once done with the write, a call to rw_downgrade can be made to move this to a reader lock. Finally, a call to rw_exit can be used to drop the lock entirely. Although this isn't explicitly stated, I'm guessing that the writers lock waits for all reads to finish and prevents any other future reads from occurring.

Semaphores are the final method. Mutex is a binary semaphore. So, semaphores contain an integer with the maximum amount of items that can be shared. These contain two operations: wait and signal.

Some datatypes are atomic - meaning that they are updated within a single instruction or operation. This is useful with small datatypes, like integers, across threads.

When using locks, there are several things that can go wrong that lead to panics that are not intuitive. First, reentering a mutex from the same thread will pause a kernel panic. Second, releasing a mutex that the thread doesn't hold will also cause a panic. Of course, a common one is forgetting to release the mutex will lead to locks as well.

From a security perspective, the mutex or operation needs to be used naturally. If the programmer forgets to use the locking mechanism and accesses the data anything, then threads can still interfere with each other. Denial of services can occur when bad code is written as well, like multi-enters and so forth.

Recently, some researchers found a vulnerability within Atlassian Companion App. The issue was that the program has a blocklist of file types of about 350. The author of the original post found that .class files were not in the blocklist, giving them RCE.

Why the blocklist? Atlassian does not add the quarantine attribute to files downloaded because it would make the user experience worse. However, a blocklist is commonly a bad idea, as an attacker just needs to find one file type that works.

The file type .fileloc is similar to a symbolic link but acts as a shortcut on macOS but it accepts a full path to another file on the system. Since this was not a blocked file type, this was a good candidate for exploitation. While reverse engineering the application, they noticed that files in the blocklist were still downloaded but inaccessible. Weird!

The name of this directory was random and they needed the macOS username as well. So, they found a websocket API that would return the folder UUID and another to retain the username in an error message. With all of this, we have a full chain.

Sometimes, security bugs do not come from an individual issue but the combining of technologies together without considering the implications. There are two separate contracts in this story: Multicall and ERC2771.

Multicall is a method of calling multiple functions within a contract at a given time. This is useful because it saves on gas when performing multiple calls at once.

ERC-2771 is a standard for meta-transactions. This standardizes how the caller address should be resolved for calls that are made by a trusted relayer, when the user cannot sign the contract. In the ERC2771Context implementation, this is done by overriding the msgSender() and msgData() functions.

So, what's the issue? When these two contracts are combined, the address is spoofable. By going through the trusted forwarder with a multicall(), we can make the addresses be spoofed to the victim.

By making the address one of the victim, we can act on behalf of them. I love bugs that are not a vulnerability in a single thing but from a result of joining things together.

Recently, somebody posted about an XSS on the analytics.twitter.com domain. At first glance, this looks to be nothing more than an alert popper since the cookies are HTTPOnly, there are CSRF tokens on Twitter and the SameSite cookie flag is set to strict.

Some APIs on api.twitter.com will accept cookies. So, this solves problem 1. Reading the JavaScript notes that the CSRF token is just a hash of the cookie csrf_id, which is NOT HTTPOnly. So, we can read the cookie as well.

SameSite doesn't kill everything! Think about the settings of cookies and protections in place, as doing security cross a large list of sub-domains is difficult. It must be well-thought-out to ensure that compromise on one subdomain doesn't affect the rest of the website.