One of the core ideas behind Proposer-Builder Separation is that proposers cannot be allowed to see the contents of the block they're signing until they've signed the block. Proposers must trust mev-boost to return the most profitable header to them.
Theoretically, this makes it extremely hard for a malicious proposer to deconstruct bundles, as they would have to 1) double sign for a single slot, which is slashable 2) win the race against the relay to submit the block to the network, which is highly unlikely
However, a little under 12 hours ago, a malicious validator managed to win the race anyways. This is the block they used to do it. Notice anything strange?
The relay certainly didn't like it.
It turns out that mev-boost-relay will return all the transactions as long as the producer signed the block correctly. The assumption is that the signed block will then be broadcasted to the network, meaning the validator would have to race the relay in order to send a new block.
Unfortunately, if the signed block was invalid, then it would never be accepted by the network, so there would be no race at all. By setting both the parent root and the state root to zero, that's exactly what the malicious validator did.
Because the relay was never able to broadcast the block, it was a simple matter of taking the revealed transactions, deconstructing the bundles, and claiming the liquidity from the MEV bots unlucky enough to be included in the block.
The patch itself is as simple as the vulnerability is. Now, mev-boost-relay will refuse to return the transactions if the block was not successfully sent to the network. Then, just for good measure, it delays the response by a second too.
The community is working to fully roll out the patch to all relays, and will be publishing a complete postmortem shortly. I'll drop a link to it in this thread when it's out.
Five hours ago, an attacker stole 2 million BNB (~$566M USD) from the Binance Bridge. During that time, I've been working closely with multiple parties to triage and resolve this issue. Here's how it all went down.
It all started when @zachxbt sent me the attacker's address out of the blue. When I clicked into it, I saw an account worth hundreds of millions of dollars. Either someone had pulled off a huge rug, or there was a massive hack underway
@zachxbt At first, I thought that @VenusProtocol had been hacked yet again. However, it only took a couple seconds to determine that the attacker *really did* deposit over $200M USD into Venus
Instead, I needed to figure out where those funds came from
1/ Nomad just got drained for over $150M in one of the most chaotic hacks that Web3 has ever seen. How exactly did this happen, and what was the root cause? Allow me to take you behind the scenes 👇
2/ It all started when @officer_cia shared @spreekaway's tweet in the ETHSecurity Telegram channel. Although I had no idea what was going on at the time, just the sheer volume of assets leaving the bridge was clearly a bad sign
3/ My first thought was that there was some misconfiguration for the token's decimals. After all, it seemed as though the bridge was running a "send 0.01 WBTC, get 100 WBTC back" promotion
1/ Today, someone tried to hack me with a crypto stealer, so I guess I've finally made it
Fortunately, they weren't successful, but all it would've taken was three clicks. Read on to learn about how the attack works, how to protect yourself, and some basic malware analysis🕵️
2/ The first step is to create an urgent and compelling hook. When placed under pressure, even trained security professionals might act instinctively instead of rationally. This DM does both.
If you clicked the link, then you're only two clicks away from being pwned
3/ Clicking the link automatically downloads this file to your computer. Once again, this is compelling - who is cryptogeng.eth, and what exactly does the statement claim?
If you open the download, then you're one click away from being pwned
So as I mentioned earlier, the two token accounts must hold the same token. The attacker forged accounts to bypass the validation on common.crate_collateral_tokens, but what about depositor_source?
Another day, another Solana fake account exploit. This time, @CashioApp lost around $50M (based on a quick skim). How did this happen?
In order to mint new CASH, you need to deposit some collateral. This cross-program invocation (CPI) will transfer tokens from your account to the protocol's account, but only if the two accounts hold the same type of token. Otherwise, the token program will reject the transfer.
Here, the protocol validates that the crate_collateral_tokens account hold the right type of token by comparing it with the collateral account. It also verifies the collateral account shares the same token type as the saber_swap.arrow account.