Binance Had $6.3 Billion Stolen
You've heard about the Binance hack in the news, right? A massive hack hit the world's largest crypto exchange. This wasn't just someone stealing a vault key and taking the money. It was an attack that changed whom the vault would listen to from then on.
✦ Stolen Key vs. Changed Wallet Behavior
Why this attack was different
Put simply, on a normal day a customer walks into a bank, asks for a withdrawal, and a clerk checks the slip and hands over the cash.
This time, it went beyond forging a single withdrawal slip. Someone planted an automatic withdrawal device that could keep pulling money out of the vault. So it wasn't only the money sitting in Binance's vault at the start that got drained.
New money that came in while the device was running could keep leaking out too.
The weakness this attack exposed isn't just that exchanges hold piles of coins. Approval authority over a wallet can change how the wallet itself works, and while that authority stays in effect, the damage can keep growing.
Not One Withdrawal Slip, but an Approval That Changed How the Vault Works
✦ One-Off Approval vs. Delegation Approval
Each kind of approval reaches a different distance
Normally, when you send crypto, you approve a message that says 'send this much to this address.' It's like stamping a single withdrawal slip that says 'send $1,000 from my account to A.' While that slip is valid, one specified transfer gets processed.
But Ethereum has a feature that lets a wallet set another program to run with the wallet's own authority. It's called EIP-7702. It was originally meant to let people batch several payments or make wallets easier to use.
It's a bit like connecting a connector to an AI agent so it can use all sorts of functions.
Think of it as a bank vault. Approving a paper slip that says 'take out $1,000 this time' over and over is slow and tedious, so you hook a program up to the vault's automatic device instead.
That means it doesn't just send money once and finish, the way a slip does. Even afterward, the connected program can keep using the wallet's authority. If that program is legitimate, it's a handy feature.
If it's malicious, it can move the coins in the wallet somewhere else.
In this attack, the attacker did exactly that. They changed the settings of Binance 14, Binance's Ethereum withdrawal wallet, so it would run a malicious program the attacker had prepared.
Only 1 of 50 Worked. But It Was Calculation, Not Luck
This is where the idea of a 'transaction number' comes in. Every time an Ethereum wallet sends a transaction under its own name, it bumps a serial number up by one. It's like the ticket numbers at a bank counter going 101, 102, 103.
That number isn't a password.
It's public on the blockchain, and all it does is tell already-processed transactions apart so they can't be processed again.
The 'wallet setting change approval' the attacker used carried a serial number too. At a bank, it would be a document saying 'process this approval when the ticket number is 101.'
Under Ethereum's rules, that document is accepted only when the wallet's actual number is exactly 101. If the wallet has already moved on to 102, the 101 document is useless.
But Binance 14 is a busy wallet that keeps processing customer withdrawals nonstop. It's the world's largest crypto exchange, after all.
So even if the attacker checked the wallet's number and then made a move, the attempt could fail if another withdrawal got processed first.
So the attacker didn't prepare just one approval. They prepared 50 in advance, running from the number they'd checked through the numbers that followed. And those 50 weren't picked at random, like lottery numbers.
The ticket number could change at any moment, so they prepared documents numbered 101 through 150 in a row, setting things up so that one of them would go through.
✦ How the 50 Approvals Were Prepared
Consecutive numbers soaked up the shifting counter
According to on-chain analysis, Binance 14's number was 18,914,775 at 20:17:47 UTC on October 29. The attacker prepared signed approvals for 50 consecutive numbers, from 18,914,775 through 18,914,824.
At the wallet's transaction pace at the time, 50 numbers covered about 6 minutes 24 seconds.
The actual approval transaction was recorded on the blockchain at 20:20:59 UTC. Just before that, Binance 14 had finished transaction number 18,914,808, so the next number was 18,914,809.
The 35th approval of the 50 carried exactly that number, and the attacker's bet paid off.
One more important detail. All 50 of these approval signatures were produced with Binance 14's key. In bank terms, the attacker had prepared 50 approval slips stamped with the genuine seal of the account called 'Binance 14.'
One of them, number 18,914,809, matched the current number. But how the attacker got hold of that seal in the first place can't be confirmed from public blockchain records alone.
About 3 minutes 24 seconds after the approval was applied, the attacker's prepared program ran, and roughly $2.5 billion worth of coins left Binance 14. But the real problem didn't end with the first withdrawal.
✦ Damage That Grew While the Delegation Stayed On
The leaks kept going after the first outflow
The wallet setting the attacker changed stayed in place for about 3 hours 50 minutes, and during that time newly arriving assets leaked out several more times.
About $823 million worth of USDC also left Hot Wallet 34, a separate Binance smart wallet set up to trust Binance 14.
That's what makes this different from a plain wallet theft. The attacker didn't just grab the coins in the wallet once. They changed the rules the wallet runs by and kept draining it.
Why Exchange Hacks Keep Happening
✦ What Attackers Go After at an Exchange
From the key storage device to the approval program
Exchanges hold coins that customers have deposited, and the authority to process withdrawals is concentrated in the exchange's wallets and operating systems.
For an attacker, targeting the approval system that runs an exchange's vault can cause far bigger damage than targeting one customer's account.
Attackers don't have to steal the vault key itself, either. They can get the system to approve a fake withdrawal order, or push a bad command into the automatic withdrawal device. Then the money can come out without anyone stealing a key.
So at a crypto exchange, it isn't only the devices storing the keys. The staff accounts, servers and approval programs that ask those devices to sign can all become targets. If even one of them is breached, something like this can happen at any time.
In its early investigation, Binance mentioned the possibility that a staffer's (DevOps engineer's) laptop was hacked, and later said it had found signs of additional compromise. However, it said it had found no evidence that wallet private keys were leaked.
Blockchain records can show that a valid Binance 14 signature was used, but they can't reveal the internal path that produced that signature.
In last year's Bybit hack, too, the attacker stole developer credentials from Safe, a wallet management service provider, and manipulated what the transaction screen showed.
Bybit staff approved what looked like a normal internal transfer, but it was actually a transaction handing wallet control to the attacker.
The method differed a little from this case, but the common thread is that the attack went after the approval process that moves coins, not the coin wallet itself.
What Blockchain Protects, and What It Can't
✦ What Blockchain Protects and What It Doesn't
It protects records, but it can't pick out who signed
Blockchain is a technology that verifies transaction records and makes those records hard to alter.
But it doesn't judge whether the person who approved a transaction is a legitimate exchange staffer, or whether the one who requested the withdrawal was a real customer.
It can check whether the seal on the withdrawal slip is genuine. But it can't tell whether the person who stamped it is the rightful owner or a fraudster.
✦ Good to Know
What is a regular signed transaction?
Of course, the whole incident wasn't caused by EIP-7702. The total damage of roughly $6.3 billion includes wallets on other blockchains too. The EIP-7702 method was confirmed on one Ethereum wallet, Binance 14.
And even on Ethereum, the outflow from Binance 16 used regular signed transactions, and on other blockchains, too, assets left through regular signed transactions.
So the fatal weakness this incident exposed isn't the ledger itself. It's the approval authority that lets transactions be written into the ledger.
A blockchain executes a transaction with a valid signature, but it can't tell whether that signature came from a hacker's hands.
As long as exchanges pool customers' assets and process withdrawals on their behalf, attackers can go after the authority to move coins, and the systems that exercise it, again at any time.
This isn't investment advice. You know that, right? Let's each protect our own hard-earned money.
That's all for this post. See you next time.
Related posts
- Ledger Hack: 80 BTC Vanished From a Reseller-Bought Wallet
- Is the Fake SHIB Airdrop a Wallet Drainer? Crypto Alert
- Bitcoin Firm Strategy (MSTR) at Risk of MSCI Index Removal
🌐 Korean version: 바이낸스 63억 달러 해킹 사건이 드러낸 암호화폐의 치명적 약점 (최대한 쉽게 설명해볼게)
No comments:
No comments yet. Want to leave the first one?
Post a Comment