Full Report
In the world of cryptocurrency, there are many bots who are attempting to make money on the eco-system. If a bot sees an arbitrage opportunity or a sandwich, it will see it and try to make money from it. However, as the space got more and more crowded, problems arose. In particular, to front-run you either collude with a miner or pay a higher gas fee. Since many bots exist and keep doing this, the price kept going up and up. This behavior is bad because it was clogging up the network with a bunch of bad and failing transactions. Additionally, the gas price was skyrocketing because of the frontrunning attacks. A solution to this? Flashbots! This is a market place that connects block makers, bot operators (aka block builders) and others to only have a handful of these opportunities pop up. This makes less congestion on chain happen. The service uses a first price sealed-bid auction in order to make sure only valid transactions are added (no more frontrunning the frontrunner). Each block builder will propose a price they are willing to pay; the highest bidder wins. On top of this, there is the new proposer user. This player can give the builders the proposed blocks for a price. With Flashbots, this is called MEV-Boost. On April 3rd 2023, an issue with part of the MEV-Boost stack was found. MEV-Boost works through a commit and reveal scheme. This is so that builders cannot see the contents of the proposed block but can see how much value it would bring; if they could see the block, they would be able to use the knowledge immediately. This is done via a relayer. This whole system relies on the relayer securely handling the proposed block. In particular, the builder will sign block headers. However, the relayer did NOT validate the block header for accuracy. If the block header was invalid, it would attempt to publish the block to the chain and get rejected. Regardless, the relayer would reveal the body to the proposer. Since the proposer had the block body, they could use the knowledge of the block ordering themselves to make a profit with sandwiches and arbitrage opportunities. An additional issue was found after evaluating the security of this system. A malicious proposer with two slots in a row could ask a relay for a block too late in the slot. If this is done, the proposer would miss their slot but the block body would be sent over. With this knowledge, they are able to build the block with optimal settings with the second slot. The attack steps are super interesting: The attacker sends multiple transactions to the public mempool with large swaps and infinite slippage. This was a bait to the sandwich bots. The bots pick up the mempool transactions with a profitable sandwich. The block is sent to a relayer. The attacker requests a block header then gives a poorly signed block header for the previously constructed block. The ultrasound relay attempts to publish this but has a bad block header. Prior to sending this, the full block is sent to the attacker. The attacker constructs a block that drains the sandwich bots! This isn't elaborated on very much but it's assumed that they added in transactions around the sandwich bot to make their transactions lose money instead of gain money. To fix this vulnerability, MEV-Boost relays no longer return the block body if the publishing fails. To fix the second problem (race condition), there is a cut off point of 3 seconds. Overall, an awesome and crazy view into the world of bots in cryptocurrency.
Analysis Summary
# Incident Report: MEV-Boost Relay Exploitation and Block Body Reveal
## Executive Summary
On April 3rd, 2023, a malicious proposer exploited a vulnerability in the MEV-Boost relay stack to drain funds from sandwich bots. By submitting invalidly signed block headers, the attacker forced the relay to reveal block contents while the block was rejected by the network, allowing the attacker to front-run the bots. The incident resulted in the draining of multiple MEV bots and led to immediate software patches to the relay infrastructure.
## Incident Details
- **Discovery Date:** April 3rd, 2023
- **Incident Date:** April 3rd, 2023
- **Affected Organization:** Flashbots / MEV-Boost Ecosystem (Ultrasound Relay specifically mentioned)
- **Sector:** Cryptocurrency / Decentralized Finance (DeFi)
- **Geography:** Global / Blockchain
## Timeline of Events
### Initial Access
- **Date/Time:** April 3rd, 2023
- **Vector:** Baiting and Protocol Vulnerability Exploitation
- **Details:** The attacker broadcasted transactions to the public mempool involving large swaps with infinite slippage. This was designed as "bait" to attract automated sandwich bots.
### Lateral Movement
- **N/A:** As this was a blockchain protocol attack, lateral movement within a traditional network did not occur; instead, the attacker moved between the roles of Proposer and Block Builder to exploit the Relay.
### Data Exfiltration/Impact
- **Details:** Once the bots committed their sandwich transactions to a block, the attacker submitted a malformed (poorly signed) block header to the relay. Due to a lack of validation, the relay revealed the full block body to the attacker before the block was successfully published to the chain.
### Detection & Response
- **Detection:** Real-time monitoring of blockchain transactions and relay failures on April 3rd.
- **Response actions taken:** Flashbots and relay operators identified the signature validation flaw and the timing race condition. Patches were deployed to relays to ensure block bodies are no longer returned if publishing fails.
## Attack Methodology
- **Initial Access:** Social engineering of bots via "bait" transactions in the public mempool.
- **Persistence:** Not applicable; transaction-based exploit.
- **Privilege Escalation:** Exploiting the "Proposer" role to gain unauthorized access to "Builder" block content.
- **Defense Evasion:** Using malformed signatures to trigger a specific error state in the relay.
- **Credential Access:** N/A.
- **Discovery:** Identifying that the relay (specifically Ultrasound Relay) did not validate headers before revealing the block body.
- **Lateral Movement:** Exploiting the "commit and reveal" scheme of the MEV-Boost stack.
- **Collection:** Gathering the internal transaction data of the sandwich bots.
- **Exfiltration:** Extracting the block body from the relay.
- **Impact:** Draining the liquidity/funds from the sandwich bots by re-ordering transactions in a new block.
## Impact Assessment
- **Financial:** Significant (Multiple sandwich bots were drained; specific dollar amounts often reach millions in such MEV exploits).
- **Data Breach:** Exposure of "sealed" block contents (transaction privacy breach).
- **Operational:** High network congestion and temporary loss of trust in specific MEV relays.
- **Reputational:** High; highlighted risks in the MEV-Boost architecture.
## Indicators of Compromise
- **Behavioral indicators:** Proposers submitting invalidly signed headers; suspicious transaction patterns involving infinite slippage bait; proposers requesting block headers at the very end of a slot (timing attack).
## Response Actions
- **Containment measures:** Relays updated to implement a 3-second cutoff for block requests to prevent timing attacks.
- **Eradication steps:** Software update to the MEV-Boost relay stack to ensure block headers are validated for accuracy *prior* to revealing the block body.
- **Recovery actions:** Deployment of "v2" relay logic to ensure that if a block fails to publish, the body remains hidden.
## Lessons Learned
- **Key takeaways:** Trustless systems must validate all signatures before revealing sensitive data; "Commit and Reveal" schemes are only as secure as their validation step.
- **What could have been done better:** Earlier stress-testing of relay behavior when presented with invalidly signed headers and "late-slot" requests.
## Recommendations
- **Prevention measures:**
1. Infrastructure providers should implement strict validation on all signed headers before processing.
2. Implement hard time-bounds (cut-offs) for interactions between proposers and relays to mitigate race conditions.
3. Bot operators should implement safeguards against "bait" transactions with unrealistic slippage parameters.