Technical Analysis of the Poly Network Hack(rekt.news)
rekt.news
Technical Analysis of the Poly Network Hack
https://rekt.news/polynetwork-rekt/
34 comments
Don't know about USDC, but USDT almost instantly locked the funds, making them unspendable.
Interesting. Do you know the mechanics of how funds get locked? Are they prevented from being transferred on-chain or only from being removed at the USD-USDT edges?
the smart contract has a blacklist flag that can be activated by the Tether, this prevents on-chain transfers.
https://etherscan.io/token/0xdac17f958d2ee523a2206206994597c...
The USDT will be burned and the USD released to the rightful owner after law/legal approval -- https://twitter.com/paoloardoino/status/1425188386034311168
The USDT will be burned and the USD released to the rightful owner after law/legal approval -- https://twitter.com/paoloardoino/status/1425188386034311168
Wait, so they have the ability to arbitrarily blacklist people from transferring tethers? At this point, is Tether anything other than a weird bank?
But see how nice having a blacklist is (which you seem to say is the core business of banks, when in fact it is to provide massive amount of capital as loans at a cost or create yield-producing aggregated products - which can work with any currency, crypto or not, and which Tether barely fits the definition of).
I d propose every chain to have a blacklist mechanism, temporary if you want, with a voting mechanism to remove innocents. You cant facebook your way ("we re just a platform") out of financial rules or you ll just end up rewarding thieves while benefitting innocents very little.
I d propose every chain to have a blacklist mechanism, temporary if you want, with a voting mechanism to remove innocents. You cant facebook your way ("we re just a platform") out of financial rules or you ll just end up rewarding thieves while benefitting innocents very little.
To be fair, they never claimed to be anything else, just a conduit to allow seamless transfers of usd value on the blockchain, while they hold the actual funds (applies to all non-algorithmic stables).
It is more like a regular bank than anything else. A bank that uses a different transport network.
That's why decentralized stable coins like DAI and others exist :)
That's why decentralized stable coins like DAI and others exist :)
Yes, Tether is nothing more than a weird bank. USDT is backed by real currency (or atleast Tether claims so). And is equivalent of the treasury giving you a bill and promising to pay you, just on a pollution causing blockchain
Does this mean they are lost forever? like burning real bills? Or is there a mechanism to repay the original owners?
Code is law, law was obeyed, the original owners dont matter anymore. Currency of the future.
No, the real bills that back the money should still be sitting in the bank (although some people would question this, given that we are talking about tether. Only the token representation has been frozen.
It will never cease to amaze me that someone with the technical chops to pull off an attack worth this much hasn't done the minimum pre-work necessary to get away with the cash or at least some non-trivial amount of it.
Money laundering, especially when hundreds of millions of dollars in value are on the line (meaning it's not your sleepy local police office dealing with it, but the best the federal government can offer), is hard in itself - and cashing out in actual physical dollars is even harder.
The potential for messing up on the way is simply enormous. Remember Silk Road? Guy got v& because of a stackoverflow post.
The potential for messing up on the way is simply enormous. Remember Silk Road? Guy got v& because of a stackoverflow post.
Not really. Ethereum has anonymous transfers through zkSnarks in the same spirit as other anon cryptos, except as a contract:
https://tornado.cash/
All the hacker would have had to do was do the hack from a secure connection (ie cantenna to free wifi + proxy chaining ..etc.)
https://tornado-cash.medium.com/how-to-stay-anonymous-with-t...
https://tornado.cash/
All the hacker would have had to do was do the hack from a secure connection (ie cantenna to free wifi + proxy chaining ..etc.)
https://tornado-cash.medium.com/how-to-stay-anonymous-with-t...
The problem with these is that similar to TOR, you need enough legitimate transactions to mask your traffic... because otherwise you can easily be spotted, which is why the TC website explicitly warns:
> After depositing, users should wait some amount of time before withdrawing to improve their privacy.
If you have 600 million dollars to launder, the probability of being caught is still massive. It simply is an enormous sum of money.
> After depositing, users should wait some amount of time before withdrawing to improve their privacy.
If you have 600 million dollars to launder, the probability of being caught is still massive. It simply is an enormous sum of money.
1. Tornado is self described as “experimental software.” I would not trust that protocol over a token designed around privacy like xmr. Especially with volume this large, timing attacks become a concern.
2. LE can still catch you on the way out. People are gonna start asking questions when you spend hundreds of millions in crypto.
2. LE can still catch you on the way out. People are gonna start asking questions when you spend hundreds of millions in crypto.
>The potential for messing up on the way is simply enormous. Remember Silk Road? Guy got v& because of a stackoverflow post.
Ulbricht messed up in a lot of different ways. That was just one of the many. It wasn't just one little slip-up; he had truly awful OPSEC. (And pretty poor technical skills in general, it seems, based on his SO question [1] and various other things.) Even if the SO question potentially may have been found through parallel construction (no way to ever know), there were so many different parallel paths investigators could've taken that his downfall was almost certainly inevitable.
But your overall point is definitely correct. The oft-quoted attacker's advantage in information (and other) security is that the defenders need to "win" every time and the attackers only need to "win" once. Try 100 different exploit attempts; if the defenders prevent 99 of them, they lose.
This gets flipped when it comes to OPSEC. The attacker needs to "win" every OPSEC battle and the investigators often only need to "win" once. If they find a single mistake, they may be able to tug on a thread that leads to the attacker's likely affiliation and identity. And the more sophisticated and complex the attack, the more surface area there is for mistakes, just like how more complex systems/organizations have larger surface areas for attackers to target.
[1] https://stackoverflow.com/questions/15445285/how-can-i-conne...
Ulbricht messed up in a lot of different ways. That was just one of the many. It wasn't just one little slip-up; he had truly awful OPSEC. (And pretty poor technical skills in general, it seems, based on his SO question [1] and various other things.) Even if the SO question potentially may have been found through parallel construction (no way to ever know), there were so many different parallel paths investigators could've taken that his downfall was almost certainly inevitable.
But your overall point is definitely correct. The oft-quoted attacker's advantage in information (and other) security is that the defenders need to "win" every time and the attackers only need to "win" once. Try 100 different exploit attempts; if the defenders prevent 99 of them, they lose.
This gets flipped when it comes to OPSEC. The attacker needs to "win" every OPSEC battle and the investigators often only need to "win" once. If they find a single mistake, they may be able to tug on a thread that leads to the attacker's likely affiliation and identity. And the more sophisticated and complex the attack, the more surface area there is for mistakes, just like how more complex systems/organizations have larger surface areas for attackers to target.
[1] https://stackoverflow.com/questions/15445285/how-can-i-conne...
They're claiming to be white hat and have given back 250m.
But 1) in the context of the article (which only knows about $4.7m being returned), this was only something they did after they failed to get away with the money; and 2) if you were a "white hat" you would give back all of the money, not 40% of it ;P.
They only started making that claim after foolishly transferring the coins to an address tied to a Binance account.
250 of 600? I question how white that hat is.
What was missing for me in the article is the fact that they don't call a function by name AND by validation of hash.
Instead, only by hash(<method name string> + "(bytes,bytes,uint64)").slice(0,10) which is brute-force-able.
Still, this sounds just like one of my worst nightmares. A code in production having bugs that will lose all my money to an untraceable environment (the tornado chain).
Instead, only by hash(<method name string> + "(bytes,bytes,uint64)").slice(0,10) which is brute-force-able.
Still, this sounds just like one of my worst nightmares. A code in production having bugs that will lose all my money to an untraceable environment (the tornado chain).
Funny tangent about the function hash... I can't tell you the number of man-hours I spent brute-forcing random function names to find the lowest value hash.
Quick background. Back in the pre Flashbot days, the competitive barrier to front running was winning priority gas auctions. Basically whoever was able to bid at the highest gas price would get their transaction mined with first, and would extract the MEV. (Kind of analogous to traditional HFTs fighting to shave off nanoseconds to win a latency-based priority race.)
So you had to make sure that your on-chain smart contract for the front-running bot is an insanely gas optimized as possible. You'd literally pay a thousand times per unit of gas as the average person. Every single byte matters. And one thing about the EVM is that zero bytes in the transaction data cost slightly less than non-zero bytes.
So anyway, in the hot-path of that front-running bot, you'd want to get as many zeros in the method hash as you could. So I'd literally run a GPU to brute force method names.
Quick background. Back in the pre Flashbot days, the competitive barrier to front running was winning priority gas auctions. Basically whoever was able to bid at the highest gas price would get their transaction mined with first, and would extract the MEV. (Kind of analogous to traditional HFTs fighting to shave off nanoseconds to win a latency-based priority race.)
So you had to make sure that your on-chain smart contract for the front-running bot is an insanely gas optimized as possible. You'd literally pay a thousand times per unit of gas as the average person. Every single byte matters. And one thing about the EVM is that zero bytes in the transaction data cost slightly less than non-zero bytes.
So anyway, in the hot-path of that front-running bot, you'd want to get as many zeros in the method hash as you could. So I'd literally run a GPU to brute force method names.
I am simultaneously stunned at the brilliance of the scheme and the monumental loss of human productivity.
Wouldn't it be cheaper to replace the method id with byte id? No need to follow solidity abi if nobody but you is going to call the contract.
For sure. The biggest challenge is once you leave Solidity entirely, it's hard to do anything but very simple operations. And actually, I did essentially do what you mentioning for our "gas refund" contracts. Basically another trick to cut gas spend is to use the refund the EVM gives for calling contract self-destruct.
You create a bunch of dummy contracts when gas is cheap. Then on your transaction where you're paying a 100x gas price to win the contract, you self-destruct as many contracts as you can to max the refund. However the self-destruct call itself costs gas, so you want to make the call as simple as possible. This is a pretty simple: 1) check caller address, invoke self-destruct. So you'd just write the entire contract directly in EVM byte code instead of using Solidity.
You create a bunch of dummy contracts when gas is cheap. Then on your transaction where you're paying a 100x gas price to win the contract, you self-destruct as many contracts as you can to max the refund. However the self-destruct call itself costs gas, so you want to make the call as simple as possible. This is a pretty simple: 1) check caller address, invoke self-destruct. So you'd just write the entire contract directly in EVM byte code instead of using Solidity.
>The biggest challenge is once you leave Solidity entirely, it's hard to do anything but very simple operations.
You don't have to leave solidity, it could all be done in the fallback/default function, no?
For the rest, you described gas tokens, but self destruct refunds were removed with London so they are all worthless now.
You don't have to leave solidity, it could all be done in the fallback/default function, no?
For the rest, you described gas tokens, but self destruct refunds were removed with London so they are all worthless now.
Good question. I'm 90% sure that fallback function is actually implemented in byte code by comparing the byte code against all the method signatures. Then if none match, the assembly jumps to the fallback. So, what you save in 0s in the input byte code, you pay more than that in the execution gas.
Yeah, for gas tokens you're right. This was all pre-Flashbots, so talking about February or March at the latest. Flashbots kind of wrecked the whole game. Now it's a whole lot simpler, just ship transactions to Flashbots and bid as close as possible to breakeven. Consequently 90%+ of the profits now go to the miners.
Yeah, for gas tokens you're right. This was all pre-Flashbots, so talking about February or March at the latest. Flashbots kind of wrecked the whole game. Now it's a whole lot simpler, just ship transactions to Flashbots and bid as close as possible to breakeven. Consequently 90%+ of the profits now go to the miners.
>So, what you save in 0s in the input byte code, you pay more than that in the execution gas.
In this case all methods should be internal, so the preamble would have no methods at all to look for.
In this case all methods should be internal, so the preamble would have no methods at all to look for.
This doesn't even sound like a hack. The beneficiaries executed the digital contract in way that was explicitly permissible by the contract. It was perhaps contrary to the original intent of the contracts creator but that intent needs to be irrelevant for digital contracts to serve any useful purpose more than just traditional non-digital contracts.
I agree, I'm not a lawyer but it's not clear to me what laws the hacker broke.
[deleted]
I wonder if Coinbase has flagged the USDC that was stolen. Are those currently less-fungible USDCs?