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!

Axelar is a cross-chain bridging protocol. To come to an agreement on whether a cross-chain vote has happened or not, 60% of the stake on Axelar has to approve it. The voting is performed on the Axelar blockchain, which is a Cosmos SDK chain. To off-chain listener is called vald.

There are uptime requirements for all of the voters, called chain maintainers, of a particular chain. Validators who miss votes will be deregistered and lose rewards.

Once the ContractCall on an Axelar gateway contract is made, the vald program will see this and vote on the Cosmos Axelar chain. To do this, they call ConfirmGatewayTxs.

While reviewing the configuration settings of the Axelar chain validators, they noticed the max_body_bytes setting. This is the maximum amount of bytes that can be in a request - 1MB. If this limit is exceeded, then the Axelar node will drop the request. These settings are seldomly changed and is the default value in the official setup instructions. By forcing the ConfirmGatewayTxs to be larger than 1MB, with excessive amounts of logs, the voting transactions from vald would be rejected!

By itself, this isn't a huge deal. However, considering the voting penalties is where this becomes interesting. Remember, if a certain amount of votes are missed, then the chain maintainers are deregistered. The voting has no minimum quorum check. If there's a poll to vote on, even if nobody can vote or does vote, the chain maintainers will get slashed for this.

The author of the cost does some cost analysis. To take down all major chains, it would cost 5K. In the future, it would cost another $11 per chain to do this again. Here's the flow of the attack:

1. Create 2 malicious transactions that make 2000 ContractCall logs on the Axelar Gateway.
2. Call ConfirmGatewayTxs on Axelar with the txids from the events listed. At this point, vald detects the polls and tries to vote but fails because of the size of the HTTP request.
3. Do step 2 over and over again until the chain maintainers are deregistered.

The impact of this is pretty severe - it stops Axelar in its tracks on all chains. Initially, Axelar rated this as medium and asked to pay 5K with this being considered a "liveness vs. security" issue, increasing this to 20K but this was still rejected. After multiple follow ups from Immunefi, this was upgraded to a critical at 50K. You gotta love Immunefi and their help towards hackers!

This vulnerability is a great win for public disclosure. The bug had not been fixed when this was published. However, within a few days of publishing the post, the issue was fixed by disabling auto-deregistration altogether. Without the public disclosure, this vulnerability may not have been fixed.

To me, the real vulnerability was the missing minimum vote check before slashing. It's weird that Axelar fixed this by removing the deregistration. I personally love this post of taking a "small thing" to abuse a fundamental design issue.

Arbitrum and Optimism are Optimistic Rollups. This means that they are an L2 blockchain that inherits the security of the L1 by posting all of the L2 data to the L1. There are several rolls with these blockchains:

• Sequencer: Creates the blocks from the submitted transactions to its private mempool.
• Batcher: Posts the transaction information to the Ethereum L1. This allows to deriving of the state of the L2 from only Ethereum, making it a rollup instead of a sidechain.
• Publisher: Posts the L2 consensus state to Ethereum. There is also a Challenger that can submit fraud proofs is something is done wrong by the Publisher.

The transaction lifecycle of an L2 is as follows:

1. User submits transaction to RPC on L2 or to specific contract on L1.
2. Sequencer creates a block and broadcasts it to the L2. The block is soft finalized.
3. The block information is posted to Ethereum via the Batcher role for the Data Availability part of a rollup.
4. The posted batch is seen by the L2 nodes. This makes the block hard-finalized.
5. If the batch is different than the current state of the L2 then a rollback is done on the soft-finalized transactions.

There are three scenarios where rollbacks can occur that are relevant:

• If the block time gap is too different on the L1 compared to the L2, then the block will be rolled back. This is a security mechanism to prevent too much manipulation of the block.timestamp in Solidity.
• In case of the Sequencer going down, transactions can be forced through the L1, after a 24 hour delay. If the transaction was never included in the L1 but was in an L2 block then this forced inclusion will trigger a rollback.
• Invalid posted batch information to the L2 not being processed on the L1. This leads to a rollback on the L2.

The goal of this paper is to force trigger rollbacks to have a double spend via deposits/withdrawls or after a large amount of blocks have passed to break bridges. Using the rollback mechanisms above, this is what they do. Of course, this requires some Tomfoolery to get transactions delayed properly.

In the Overtime attack, the goal is to change the time on a deposit that has already been used. It works as follows:

1. Cause a major delay in the batch processing. This is no "one" way to do this.
2. Submit deposit to the L2.
3. L2 accepts the deposit.
4. Batcher is unable to submit the the deposit to the L1 because of batching delays done in step 1.
5. Attacker initiates and gets a withdrawal accepted for their recent deposit.
6. Time-bound mechanism springs into action! The L2 block has its block rolled back.
7. L1 deposit is processed in the new L2 block. Now, we have two sets of funds from the same deposit. Personally, I'm confused on how the withdrawal gets processed before the redoing of the finalization on the L1.

In the QueueCut Attack, the liveness preservation is abused.

1. Introduce a delay in the L2 to L1 comms by adding a bunch of transactions with incompressable data.
2. Trigger deposit from the L1. This will soft finalization immediately.
3. Trigger a withdrawal on the L2 with that deposit. This will be processed quickly.
4. Because of the delay and queue, the force inclusion feature can now be used. Use this to trigger a deposit.
5. Force inclusion negates the L2 block that had the original deposit. Hence, we have a double spend.

The ZipBomb attack is making data uncompressable from the perspective of the Sequencer. This leads to the L1 refuses to process the L2 block, leading to a rollback. To me, the asynchronous processing is weird. I thought that the blocks would build on each other and require a perfect order. In reality, this isn't the case, which allows for the weird ordering of things. I imagine that many of these ideas came from noticing a bad state machine vs. the rollback mechanics being able to be DoSed.

The fixes to these bugs are not just a couple lines of code - they are design-level fixes because of the asynchronous processing. Both Optimism and Arbitrum having a streaming mechanism to ensure that blocks can always be handled. To mitigate the Zip Bomb attack, Arbitrum now only cares about the plaintext size on submission and not the compressed size.

On Optimism, they added a fee prioritization structure instead of a first-come-first-server queue. Additionally, instead of the more complicated one-block-per-transaction strategy, they now use a 2-second fixed interval. As far as cross-chain bridges go, there are still some concerns. They urged products to wait until L1 inclusion instead of L2 block confirmations.

1Inch is a limit order swap DeFi platform. 1Inch Fusion is a gasless swap protocol built on top of the core Limit Order Protocol. This version was deprecated in 2023 but was kept alive for backwards compatibility reasons. The original implementation had over 9 audits.

Recently, the V1 protocol was hacked. Looking at the exploit transactions, it starts off looking very normal. Then, came a red flag: both the taker and the maker on the swap were the same. Additionally, the attacker had made over 1M USDC on the trade.

Upon trying to make the Settlement of the limit order, a call to resolveOrders is made to a contract. This code appeared to be very similar to the example integration and looked pretty safe. Upon closer inspection, the victim contract had not updated the protocol even when the interfaces had changed.

The vulnerability appears to be around lack of validation on resolver. This is a NOT intended to be a controlled element of settleOrder. In fact, it's passed in with new bytes(0) since only the contract itself should be able to set it. How was this controlled? What gives? The woes of multiple versions!

Much of this code is written in Yul, the Assembly of Solidity. In the Yul, there is a ptr. When writing a value called the suffix, it's written at an offset depending on the passed in interactionLength. interactionLength is a full 32 byte word, which can overflow when doing ptr + interactionOffset + interactionLength. Because of this overflow, the pointer can be decreased to write the user controlled suffix to any location! Sounds like memory corruption!

Here's the full flow of the attack:

1. Create a swap order that swaps a few wei for millions. Normally, this would obviously be rejected.
2. Specify an invalid interactionLength value to overflow to point to the resolver address.
3. Add a fake suffix structure to overwrite the resolver address.

The authors of this post did the internal investigation but also did several of the audits on the protocol. So, what happened? Initially, the resolver contract code wasn't in scope for audits, so it was ignored. In March of 2023, these auditors actually found the integer overflow while assessing the scope. However, shortly after, the code was completely rewritten so they didn't feel it was necessary to callout.

Here's the interesting twist: this previous version of the contract had already been deployed and the auditors didn't know it. Additionally, they were unsure about the impact of the vulnerability, so they moved on from it.

How can we prevent this type of thing from happening in the future?

1. Clearly defined what code is being used. It's acceptable to have multiple versions but both need to be audited.
2. Informational findings are helpful. There may be more impact of something than an auditor initially realizes.

Overall, a super cool postmortem on the exploitation of this vulnerability. The vulnerability is unique and I love the analysis on how this slipped through the cracks.

This is just a bunch of slides but a ton can still be learned from it. The target is an In-Vehicle Entertainment system that has things like Amazon Alexa and things built into it. The first part of the process was getting the code off of it to reverse engineer and getting a debuggable environment.

The flash chip was a BGA eMMC chip. So, they used a hot air reworking station to remove the chip, popped it into an adapter and got the firmware off of it. To get a debuggable environment, they reverse engineered a bunch of settings for a secret debug menu and added a missing 0-ohm resistor but were shut out by a good password they couldn't crack.

Eventually, they just live patched the running memory of the chip to change /etc/shadow to get a shell. They also tried reprogramming the chip but bricked one of their devices trying to do this.

The device had an insecure HTTPs certificate handling on a request to api.sports.gracenote.com. By hosting a malicious DHCP server with attacker controlled DNS, they could interact with this service. On this server, there was a directory traversal arbitrary write vulnerability that allowed for writing arbitrary files.

Most of the system contained a read-only filesystem. Many of the mounts were even noexec. They found that the file pkcs11.txt allowed for the configuration of shared objects with a file path. Additionally, there was a mounted USB that was missing the noexec flag.

Using this configuration file, it was possible to load arbitrary .so/code> libraries. Of course, they could write this library to the USB. The only problem was that this wasn't changed right away; it was set at boot time of the device. Eventually, they found that by writing to /usr/local/bin/Media in a particular way the device would reboot. To go to root, they used an n-day kernel exploit.