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!

Transient storage is a new type of EVM memory that stores data only for the length of the transaction. It is cheaper than storage but deletes itself at the end of the transaction. These are callable via TSTORE and TLOAD opcodes. A great use case for this is reentrancy flags. With new functionality comes new bugs!

The vulnerable contract was a Vault contract that interacted with UniswapV3 via callbacks. The smart contract is making a call to a UniSwapV3 pool. When the tokens are transferred back to the Vault, it must know who the intended caller is. This is done by specifying the UniswapPool address into storage slot 1.

On the swap callback function from UniswapV3, there is verification being done that it's indeed the proper pool. This is done from reading slot 1 of the transient storage. Later on, the amount that was minted is stored into this slot. The problem is that the amount is never cleaned up!

Both the amount and UniswapPool use slot 1 of transient storage. Since the amount being minted is a user controlled number, the attacker used this property to write an address they controlled with the amount value. Now that this was set, they were able to bypass the UniswapPool verification check to call the contract to steal all of the funds in the callback.

Don't reuse storage slots... this isn't 1980's video games. Good writeup!

At a live hacking event, the author of this post Roni decided to look at a new release of Gemini. In this update, the interface had Run in Sandbox as an option for Python execution. This was a sandbox used for executing Python in the context of Gemini.

The sandbox is powered by Google's GVisor, which is a user-space kernel. It does some magic with intercepting system calls and does a great job at restrictions access. It has a 100K bug bounty so this was likely impossible to escape. So, what's in the sandbox itself? Remember, this is a custom Python binary that is being ran.

They rewrote Front End to run their own Python code in the sandbox, to give them more flexibility. To see what they could do, they downloaded the Python interpreter itself. The custom Python binary had the os package in it, making it easy to see the file system. They were unable to pop a shell so this was the best they could do.

Exploring the file system led to some interesting files. In particular, the /usr/bin/entry/entry_point file. It was 579Mb in size though. Trying to base64 print it over the network just led to a network hang. Eventually, they read parts of the file in 10Mb chunks to get the whole file out.

Using binwalk, even though it's just a binary file, lead to some files being revealed. Upon reviewing these files, it appeared that some source code had been leaked. This code was not meant to be public, as pointed out by some comments in the interpreter program itself.

The sandbox had access to some Google specific network services but failed on other outbound connections. From reviewing some papers and reading internal source code, they realized that the process for opening up network information was done via Gemini itself. Gemini self-prompts to unlock necessary access. For instance, writing a prompt to access the Google Flights API will spawn a sandbox with the proper privileges - this wasn't noticed earlier because of how the sandbox was being started in their session.

By using a secondary prompt injection, access to a more privileged sandbox was given that did have this type of access. The hope was that they could get access to two extra file descriptors that they were not always given there. They were hopeful this would lead to a P0 type of issue to do things on Google infrastructure. The Google team did some assessments and believed that nothing extra on the box could be accessed even with a secondary prompt injection.

Within the sandbox, they found several protobuf files that were meant to be "internal-only" that exposed some sensitive information. Although I can't see the data they saw, I felt like the leakage of data was over-hyped. Maybe I'm missing something here though.

Overall, the post was okay. The sandbox escape discussion was fun! However, instead of memes and commands that they can't show the result of for "legal reasons", diagrams of the flow would have been appreciated. I also like posts that are more into the weeds with less story telling but that's a style choice I suppose.

Ethereum is migrating to the newest fork Pectra. In order to make sure it's secure, the Ethereum foundation is hosting an attackathon on all Pectra-specific changes on Cantina with most Ethereum clients in scope, including the Ethereum Consensus client Lighthouse. The vulnerability would lead to a split of Lighthouse nodes from Ethereum, breaking consensus.

Lighthouse had paralleled validator updates because changes made to one validator did not affect the other. In the Electra upgrade, consolidations were introduced that allow for exits straight to another validator. Naturally, these two things collide and it was noticed by the development team.

To make this work with the parallelization strategy called single-pass epoch processing, the function process_effective_balance_updates was rerun on each validator index. Unfortunately, there are other functions with side effects run between these runs. This leads to different results when ran multiple times! Word of the day: hysteresis - a property lagging behind the changes in the effect causing it.

There is a very detailed situation that is described that makes Lighthouse differ from the specification. By using the multiple updates, a node would have a different effective balance than they should. If Lighthouse was the only software used, this wouldn't be a huge deal. However, since it has to be perfectly aligned with the other clients, this is a problem.

To fix the vulnerability, single-pass epoch processing only happens on validators unaffected by the consolidations. All nodes affected by consolidations are processed before updating their effective balances. They also mention the adding of specification and fault injection tests around this to try to find other variants of it. Overall a great find and an amazing write up about it.

NextJS is a super popular React framework with a ton of extra functionality. In fact, this website is built on top of it. The author of this post was reviewing NextJS and found a way to circumvent the middleware, which is commonly used for authentication.

Within the framework, there is a check for recursive requests. For instance, if the middleware itself is making a request to the server. This is done by setting the x-middleware-request header with the path of the middleware being executed. For every piece of middleware it sees, a colon-delimited path is added. If the middleware has already been seen, then the code simply skips the middleware.

As it turns out, it's possible to specify this header yourself! So, if you know the path of the middleware you want to skip then adding x-middleware-subrequest: my_path skips the check. If this is used for authentication/authorization, then it's a horrible vulnerability. The path is somewhat guessable and the header can be used as a polyglot as well.

Initially, they found this in an old version of the package. Since that code had been removed, they assumed only older versions were affected. In reality, the code had been moved somewhere else. It's best to report vulnerabilities, even if they only affect older versions. You never know what you're missing about impact as a bug hunter.

Instead of needing to specify the path, it's super simple: middleware or src/middleware. With the changing of the path, it actually makes it easier. Additionally, there is a now a recursive check with a maximum of 5. So, middleware: just needs to be repeated 5 times now.

They used this exploit on a few bug bounty programs. One program was using the middleware as a rewrite rule. They knew this because of a header in the response. By using this vulnerability, they were able to visit the admin page. On another program, they used this as a cache poisoning DoS via forcing a 404 response by skipping the rewrite rules.

Overall, an excellent write up on the discovery and exploitation of a NextJS vulnerability. I learned a ton about the framework, exploitation, and proper disclosure from this. Great work!

Bybit had a 1.4 billion theft of crypto assets - 401K ETH - drained from a cold wallet. They use Safe{Wallet} with a 3 out X MultiSig. If all of these people reviewed what they were signing, then what happened?

Attackers compromised the Safe{Wallet} UI. So when the Bybit folks were signing off on the transaction and reviewing the details, they were signing off on the wrong thing! The attack was specifically targeting Bybit, looking at the JavaScript.

Instead of doing a transfer of any funds, delegateCall was made to a contract controlled by the attacker. At this point, they were able to modify the Safe contract storage to change the proxy slot. By doing this, future calls the attacker made to the contract would go through their proxy to execute a delegateCall, allowing for complete ownership of the assets at the address. Stealing funds is trivial at this point.

What would have the executors seen? On the web page, they saw the original transaction. What about the wallet? They would have seen raw bytes with no real meaning in them. Brutal... Overall, a good look into the exploit.

NEAR is a blockchain with a unique runtime and architecture from EVM chains. The network is broken into shards of validators to support lots of transactions on the network. This uniqueness is what drew the authors to this program.

Upon initial analysis of the codebase, the receipt processing looked sketchy. The error handling appeared extremely complex yet solid at first glance. Eventually, they noticed a new change: max_receipt_size. To me, this is interesting - small changes can create subtle new invariants that were not there before.

The validation of the receipt size was done in multiple locations. Notably, this only happened on the in take. In some scenarios, the receipt size could be increased during execution. In particular, if a receipt points to another receipt and the data from this other receipt is added to the original receipt, the actual size increases without validation. Having a receipt barely below the size limit and having it expanded causes some havoc.

When being processed again as an incoming_receipt by other nodes, the exceeded size limit leads to a panic being hit. From their report, they were hunting for possible panics in the codebase and how to hit them. Aka, sink-to-source bug hunting.

The impact is that all nodes receiving the receipt immediately crash. Some nodes would likely bounce back via watchdog programs but would then crash again. Once this receipt is dropped, the contract could be called again to trigger this crash over and over again though.

The solution is somewhat interesting: the function validate_receipt actually removes the validation of the receipt size. In particular, they ONLY want to check for size constraints during creation and not expansion. I would have expected a check to be added on the expansion code to not exceed the limit, so this patch surprised me.

The auditors were not thrilled with their payout. It was rated as a high severity issue, which has a range of 20K-200K. A similar vulnerability was paid out 150K. They were paid out less than half, so likely something between 80K-100K for the vulnerability, which is still great money. The authors claimed that they never talked directly with NEAR themselves - they only talked with HackenProof who talked to NEAR for them.

From my perspective, programs are going to pay out what they want to pay out. When the previous vulnerability was reported, maybe NEAR was doing better financially; there's more to deciding a payout than just the impact of the vulnerability, especially when funds are not directly at risk. Immunefi does have a different business model that does seem to push for higher payouts though. I appreciate the insight into the HackenProof experience though.

Overall, a fun bug! Sink to source bug hunting works well and the addition of the max size of the receipt introduced a funny invariant. Searching for No's and ways to trigger them is a great way to find DoS bugs.

While at a gym, the author noticed a WiFi symbol on a scale. Upon doing further research, they realized that all of the products on Amazon were made by the same OEM with marginally different codebases. The mobile apps were even the same. So, the author decided to try to remotely hack these devices.

Before even buying a device, they reverse engineered the mobile app to find APIs. To their horror, the firmware update APIs suffered from simple SQL injections. This let them enumerate devices and their authentication secrets, without having the physical box for it. They required some fun SQLi WAF bypasses to make this work.

From there, they decided to get a shell on the device for further testing. This was done via connecting via UART on one of the scales. This was useful for debugging the linking flow of the scale. In particular, they wanted to know how the API servers communicated with the scale itself and through the phone app of the user.

The scale would receive credentials for the WiFi via Bluetooth. The device uses mTLS to get a session token for authentication. The user-device association could be done in two ways: one initiated by the user and another by the scale. All of these properly checks the deviceid against the session token and other fields, making this pretty solid.

While messing around with the parameters, they were intrigued by the multiple ways to do auth. Eventually, they tried mixing-and-matching the two flows for tying the user and device together. By providing a user session token but using a deviceid in the headers that we don't own, the request authenticates us but believes it's a device initiated request because of the header. So, it assumes that the device is valid but it's really not. The explanation and the code snippet they provide helps a lot with this.

Several good bugs! From a blackbox perspective, multiple authentication schemes coming together is tricky to get right. The SQL injection bug was trivial but they had to put other work in order to find these APIs. You always need to put in the work but it's just in different areas sometimes, such as reverse engineering.

The team behind the Henlo Kart product was working on publishing two public packages to NPM. They were worried about sensitive files, such as .env, containing deployment credentials, being leaked. This was done via the .gitignore file. For the initial deployment of two packages, this worked well.

Later, an update to one of the packages was made - they wanted to exclude additional files from NPM. So, they created an .npmignore file to do this. Surprisingly, the presence of this file invalidated the .gitignore! This meant that the sensitive .env file was leaked. This contained a private key for the deployer account.

After a few hours, they noticed the error. They attempted to revoke the package version, but this was not allowed because other packages they created depended on it. By the time they contacted NPM to remove the package, the damage was done - the key had been exposed. An attacker found it.

The attacker took about 60ETH that was sitting in AAave. Additionally, they took control of the core Henlo contract, giving them the ability to mint new tokens. The team was able to recover some of the funds but the damage had been done. So, they rebranded the product and launched a new token from the previous snapshots.

The attackers are real! This is a sad reminder of that. Good explanation of the attack and the failures though.

Appsmith is an open-source developer tool designed to help organizations build internal applications, such as dashboards, admin panels, and customer support tools. It has three roles - admin, developer and app viewer.

Appsmith has datasources that allows applications to use information from various databases and other endpoints - many of these run locally. One of these, configured by default, is a PostgreSQL database. The configuration of this server allows for the logging into the database as any user without providing a password. This is done via a server-side connection.

The interaction with PostgreSQL requires a valid account. Although the app requires an invitation for current workspaces, its default configuration allows for user signup! A user can then configure their own workspaces and application to expose the vulnerable functionality.

The application, that the user is able to create, allows for login as the superuser of Postgres via the web console. Using this, it's possible to call cat /etc/passwd on a SQL query. Since this is the super user, it's effectively game over.

There are two other bugs but this one was by far the most interesting. Good find!

The Ingress NGINX Controller on Kubernetes is a popular ingress controller for managing incoming network traffic and routing it to the proper Pod. This is built on top of the popular NGINX reverse proxy software. The author claims that 41% of internet facing clusters use this software. Since it's internet facing, an authentication bypass or an RCE bug would be catastrophic for these services.

The service attempts to translate Kubernetes Ingress objects into NGINX configurations. The Admission Controller is a Kubernetes API server for reviewing, modifying and blocking requests. These controllers don't require authentication.

In the Admission Controller code, the AdmissionReview request generates a temporary NGINX configuration file using a template. Then, to test for validity, it runs nginx -t. Since the configuration file has user controlled inputs, the path is unauthenticated and the config is executed, this makes it a great attack surface.

The authreq parameter is used for authentication-related annotations. However, this field has zero input sanitization. Hence, it's possible to add arbitrary directives to the NGINX configuration file. There are several other variants of this on the authtls and mirror parameters. So, why is this injection a big deal?

The NGINX configuration format has a lot of directives, many of which are undocumented. the ssl_engine directive is able to load shared modules, without top-of-file restrictions like load_module. Doing this would allow for the execution of arbitrary code but requires a file to be on the system.

The pod runs an NGINX instance itself. When processing NGINX, the request body is saved to a temporary file if its large enough. Although NGINX removes the file immediately, there is an open file descriptor in the /proc file system. Using this, it's possible to access the contents of the file from the NGINX configuration. To make this race condition easier, making the Content-Length larger than the body will keep NGINX waiting. Sadly, this requires brute forcing PIDs and file descriptors, but that's worth the problem.

Here's the full path to RCE:

1. Upload the .so payload by abusing the file buffer feature.
2. Send an AdmissionReview request to the controller with directive injections. In particular, inject the ssl_engine to load the shared library from step 1.
3. Try different PID paths over and over again. Eventually, it will execute and you'll get RCE.

Overall, a great write up or a relatively unknown attack surface. This covers the fact that running nginx -t can lead to code execution, making configuration injection a very serious vulnerability.