The bug which lost more than $600M in various cryptocurrencies a few hours ago
twitter.com
twitter.com
Someone starts a blockchain company and hires a bunch of devs who make, idk, $40 to $100 per hour to build the thing. Maybe more, it doesn't really matter. Even just one dev or a few devs can make all the contracts needed for this.
One day that dev notices a vulnerability in the smart contract he's writing! He has two choices: (a) patch the vulnerability, which will get him a pat on the back, or (b) convince himself he didn't notice anything, quit his job, wait a month, go to a coffee shop with a hoodie on, boot into whonix, connect to the internet with a 4g dongle, run a few lines of code, and get $600 million dollars.
Most people would choose (a)! And law enforcement is a thing! But a lot of people will choose (b), and if they do a merely decent job they will get away with it, and 600 million dollars is stolen®.
Actually, it's worse than that, because unlike normal banks, the code used by these digital banks is open source, and anyone in the world can go bug hunting.
And the bug wasn't really obvious, although the lack of input sanitation is something an auditor (given enough time) would probably point out.
Regardless, this quote from your link stands out: “it should never be expected that 100% of the deployed code has been formally audited.”
The audits of this protocol is also continuous.
Also, they specifically state that not everything is audited? Nowhere do they mention continuous audits.
Uniswap: https://uniswap.org/audit.html
Sushi Swap: https://github.com/peckshield/publications/blob/master/audit...
Alpaca Finance (high complexity in my opinion): https://docs.alpacafinance.org/transparency
A lot of projects provide their source and you can verify that what you're interacting with matches the source.
The hilarious thing is nearly all of these high profile hacks happen even after being audited.
There was one company I remember being called out as a suspect, but I can't find the name.
Also given (a) anonymity (b) ability to take cover amid so many other hacks, you could do this for a few years, slow down, and remain a top tier firm claiming the lowest hack rate.
I think proper DeFi company should have their own system on deploying contracts. Further, they should have their own security team that audit everything.
An argument that open source is less secure, and on Hacker News! Now I've seen it all.
Military cryptographic systems, IBM mainframes, and many other products use this approach as a layer in their security framework and it is actually pretty successful.
If I asked you to break into the a PFSense box you could just Google "PFSense version X.X.X CVEs" and you would probably get a way in if the box was enough out of date, but if you tried to find the same thing for something like the General Dynamics TACLANE you would have a hard time even finding where to start.
Humans might be motivated to sit on a bug until they can reach the cybercafe. Bots, not so much.
More than that, there's a minority perspective in DeFi that the code is the law. If the code allows it (e.g., withdrawals under an unintended circumstance), it's therefore legal. If it were illegal, the code wouldn't allow it.
With crypto all it takes is one piece of malicious software, or to fall for a single phishing email, and you've lost everything.
[0] https://www.zdnet.com/article/bitcoin-wallet-trick-has-nette...
Think again. In the wild wild west that is cryptocurrency the first thing people assume is an inside job.
People with a lot of money and a cut-throat ethic will send death threats to your front door merely for small bugs you accidentally commited to github or for a governance dispute on a forum where you posted pseudonymously.
If you dare steal money as an insider you had better make sure you know how to use it to quickly get high-end personal security for you, your family, and friends. This of course simultaneously outs you as guilty.
Any hack occurs and you are immediately woken up in the middle of the night to be interrogated by people you've never seen before let alone heard of, stomping through your apartment. Your life becomes a movie.
Angry vicious actors with few scruples and long memories will loudly and expensively hunt for you for the rest of your life so you can make them whole. LEOs aren't even your biggest concern at that point.
Being an insider or former insider after a large hack sucks whether or not you're guilty.
https://twitter.com/kelvinfichter/status/1425217046636371969
I don't get the appeal for irreversibility. A legitimate trade always occurs between willing partners, why would you be so afraid that the transaction would be cancelled?
The only legitimate use that comes to my mind are complex financial instruments where things mostly happens with an assumption that the underlaying assets are very well defined, so you want assets be stable.
Is there a company or cryptocurrencies focusing on solving the human part in the transactions? Huge part of the value with working in traditional systems is their resiliency against human errors. Sometimes mistakes happen(a faulty system, a design bug or straight out human error and people who are trying to take advantage of those), most of the time these are correctable.
The transaction will likely be for goods, services and/or money. If one or more parties don't provide said goods, services or money then the other parties may well want the transaction cancelled. That's different from them all being willing to transact in the first place.
That's not a justification for irreveribility. The opposite in fact. But if you were planning on screwing your customer, say, the irreversibility is a bonus.
Charge back fraud (also called friendly fraud) is a big problem in commerce, where the buyer will buy something, receive it and then cancel the payment. The merchant will often have to swallow the cost.
That's actually why credit cards come with protection against fraudulent merchants and you need a good enough credit score to actually get a credit card. On top of that, payment processors run fraud detection systems that block suspicious actions.
Irreversibility turns the trade into a competition over who is the better fraud. The only thing that the crypto guarantees is that the winner keeps the prize.
I think it's more complicated than that. It moves the fraud risk to one specific spot (the consumer) which VASTLY simplifies the checkout process + the costs associated with online purchasing. Right now online payments are a giant mess - every single merchant has to implement anti-"fraud" tools to try and ascertain the identity of the consumer and determine if it matches the owner of the card.
As a consumer, I would happily take this trade for lower prices.
Payment processing just isn't the same thing as a currency. It's like expecting the dollar bill to do payment processing. Is lightning network supposed to be that fancy decentralized payment processing platform that is going to kill credit cards or will people stick with visa and mastercard?
It makes sense if you have a small group of trusted entities that want to have a ledger between themselves (like inter-bank ledgers for various purposes) but if you have somebody in the middle handling disputes... don't you just have paypal? Then cryptocurrency is just an extra complicated step that doesn't really matter.
A strong example of where the irreversibility of crypto is very useful is in the online sale of expensive electronic goods. Especially for things like speakers, TVs, and projectors, fraud rates are extremely high and boutique shops struggle to effectively support online customers, because such a large percentage of their sales get chargebacks after they've shipped the goods.
If you accept crypto, you have a 100% guarantee that when the money has hit your wallet, the money is good and will stay in your wallet. You don't need to deal with an anti-fraud firm, you don't need to check whether this person is trying to have the goods shipped to a sketchy country, and you don't need to fear that your $6,000 item is going to sail away from you without payment.
Yes, this means that the consumer has to fully trust the merchant, but in the case of online sales, the merchant is the known quantity with a reputation. Every consumer is a random, unknown person to the merchant and so it's much harder (and therefore more expensive) for the merchant to establish trustworthyness.
This is absolutely not true. There’s plenty of risk buying expensive goods online, lots of problematic merchants. I don’t understand why merchants are inherently more trustworthy than customers?
The merchant has much less to go on. There aren't review websites detailing the reputation and history of every random buyer that enters a credit card onto your website.
What does that mean?
The phrase "high resale value merchandise" sounds like it refers to the stuff that, in physical stores, is kept in a locked case so you have to ask someone to open it.
But that stuff is readily available online, isn't it?
I assume that most chargebacks happen for purchases made with stolen credit cards. So the chargeback just returns the money to the rightful owner.
If the consumer used bitcoin, and someone stole their credentials to buy something, then they would have no way to get their money back.
Yes, they become possible at the cost of putting the counterparty risk onto the consumer, but that's better than the sale being entirely non-viable.
Especially when the risk of customers committing fraud is incredibly low. Why would you start with an assumption that this is something so rampant it needs to be solved in a way that harms literally all honest customers?
If you think fraud rates are extremely low, you've never tried to sell $2,000 electronics online as a boutique electronics store.
Bitcoin was the only option.
Regardless, how does Bitcoin solve this? There’s a lot of illegitimate users of crypto, how are you solving fraud with irreversible transactions?
It's difficult to find sources, but generally speaking you are going to go 'on warning' at around 1.5% and if you go too much over 2% chargeback rate you just get dropped by the credit card company as a customer. Credit card companies don't like dealing with high fraud customers and won't support you.
https://chargeback.com/average-chargeback-rates-how-does-you... https://chargebacks911.com/chargeback-rate/
Bitcoin helps in two ways. The first is that it gives you a way to accept money at all. As stated above, if your chargeback rate is above 2% for any extended period of time, all of your payment processors - including your banks - are going to drop you as a customer. You may be willing to pay 5% overheads for a higher chargeback rate, but your credit card company doesn't want that as a statistic and they just won't support you.
The other way Bitcoin helps is that once your wallet (use BTCPay) says "2 confirmations" you've got a 99.97% guarantee that the money is yours and won't be reverted. And that's true whether you are receiving $2,000 or $2,000,000. Regardless of whether that money came from "an illegitimate user", you as the merchant can be confident shipping hardware out because you know that the payment is not going to be clawed back.
Merchants are in a much better position to price this in than consumers. Merchants structurally execute a lot more transactions within a market vertical than consumers ever do.
If the merchant can't do that, because deals are simply too high value or aren't frequent enough, then insurance companies or intermediaries (e.g. payment processors) can pool risk across merchants, using actuarial techniques to assign a price to the insurance. For example, professional indemnity insurance for property transactions.
To counteract this negative feedback loop, assuming the increased prices don't drive away all of your real customers, you can spend the increase on transaction analysis, and turn away customers based on their likelihood of fraud, so you've added inefficiency into the system to help deal with a criminal element, and also likely turned away real sales due to false positives in your analysis.
It's no surprise that these types of merchants are looking for a disruptive technology to remove this inefficiency. Doing so would allow them to charge less and outcompete as well as capture the entire market of people marked as false positives by other merchants.
Completely true. Irreversibility and lack of consumer protections might just about fly for small transactions with pocket change which people on both sides of the transaction don't mind losing, but isn't going to be acceptable to most people for larger transactions. If I'm buying a house, for example, I don't want the risk of it being stolen because of an unfixable bug in a smart contract, or sold to the wrong person by an irreversible mistake entering the address. Scaling up further, if you look at the back office for any investment bank, a big chunk of people power is spend on trade reconciliation and essentially fixing human errors - this is a good thing for both parties making such transactions.
On the other hand, stocks are more susceptible to demographic collapse; for example, if a lot of shareholders die and all their relatives inherit their stocks, you can expect a selloff to occur which could crash the stock price. With stocks, shares are never lost forever; they just get passed down to an increasing number of increasingly lazy and incompetent heirs. That's not to say that cryptocurrencies cannot be passed down (they can) but the fact that they are tied to a secret passphrase (instead of the legal system) makes it more likely that they can get lost. The negative economic effects of wealth inheritance are not as strong in crypto space.
The idea that negligent people may lose their tokens is highly meritocratic as it transfers wealth from negligent people to careful people.
These errors are correctable if the counter-parties trust each other, or at least have a relationship that they don't want to undermine by being petty.
Immutable blockchain systems are valuable in part because they allow entities to transact with each other even if they don't trust each other at all, don't know each other at all, or are even antagonistic with each other. Yes, if something goes wrong, a transaction won't be reversed, but without the blockchain these potentially antagonistic entities wouldn't have the capacity to do business with each other in the first place.
Blockchains allow these entities capture the value of transacting with each other—value that wouldn't otherwise be realized—at the expense of irreversibility.
You can potentially imagine that if antagonistic entities tried to do business in a more malleable environment, a request to reverse an error by one entity might not be honored by the other entity, or one entity might maliciously attempt to reverse a transaction that was not performed in error, but was simply disadvantageous in hindsight.
The possibility that a transaction may need to be reversed—or that a reversal request may need to be litigated—increases transaction costs, especially when counter parties are antagonistic. The certainty of irreversibility creates a context by which certain entities are willing to do business with each other, when they might not otherwise do business at all.
Yes - so far, it worked well for extortion with ransomware but is that something that we want to have? Can you think of a legit business case where the merchant providing the promised service is guaranteed and all you need is a method to receive the payment? All that when the merchant and the buyer don't trust each other at all and on't have a conflict resolution mechanism. What do they trade exactly?
If you start with irreversible payments and you need payments to be reversible with some kind of review/appeal process you can add reversibility through escrow. The classic arrangement is a 2-of-3 multi-key system where the payment is made to an escrow address where it can be either finalized or refunded only when at least two key holders concur; the third key, held by a neutral third party, is used to settle disputes when the payer and payee cannot come to an agreement on their own.
There are, however, situation were reversible payments are a liability, and there is no way to build an irreversible payment system on top of a reversible one. For example, you can't build a reliable escrow system on top of reversible payments since the payer can trivially circumvent the escrow by unilaterally revoking their payment to the escrow account.
At will and ex-post broadcasting "oops, we had a bug - please roll back or block the bad actors" doesn't strike me as a solid solution, nor a fair & automated one. I was under the impression this hyped up space learned from the DAO fiasco but i might be wrong.
There will always be a need for this eventual "please roll back or block the bad actors". And more money you put into the game more it will be demanded when someone gets hurt.
I don't like crypto but this way of fixing things is pretty normal and standard in software and orher industries also. You simply can run into situations which weren't planned. So i don't think there is a problem with these fixes
It's normal in most industries, but it also defeats the main selling point of crypto - "code is law" doesn't actually work, you always end up in a world of humans and politics.
What's to stop these actions being taken for reasons other than theft?
And relying on external authorities is a good thing actually. Because it's way way more effective than software solutions. Now of course the external authority can compromise sometimes but for this we also already have solutions for like thousands of years - diversification. If people just would learn not to put all their eggs into pne basket and expect eventual compromise that wouldn't be a problem. I think some 101 finances and practical real world problem solutions classes or something like this would get us way further than decentralisig everything with software
If you think it through you simply can not rely 100% on anything humans build. But still societies as a whole thrive and human progress is real.
DeFi is no exception. It’s designed to make banking cheaper. But it’s new technology and will take some time to mature.
Personally, I believe banks won’t exist in the traditional sense anymore 20 years in the future if you like it or don’t. I mean, I love steam locomotives but I don’t expect them to be a common means of transportation ever again. ;-)
A bug in a DeFi contract? Sorry nothing we can do! Bug in Wells Fargo account settlement code? Ah we’re sorry, let’s roll that back for ya!
You can also use variables to store addresses to other contracts and call external methods indirectly using these pointer like structures. If I understood the bug correctly, the hacker was able to modify such a pointer and redirect all transactions to a wallet contract she controlled.
So this is how you can upgrade contracts: There is the „implementation contract“ pattern. Basically, you define a user-facing proxy contract defining the interface but all it does is delegate user calls to the actual implementation contract by maintaining a variable pointing to it. Using a privileged call you can update that address even after deploying the proxy.
Formal verification
Once all this is done, the transaction fees will be equal or higher than traditional banking systems :-p
As the growth slows down there will be an increased focus on best practices for smart contracts, on auditing, and on formal verification. There are also a lot of startups that are looking into insurance for smart contracts and crypto balances in general.
In general, the best experts in the space could probably write smart contracts with >100x fewer bugs than your typical smart contract. Especially with something as complex as the EVM it's difficult to assert that any piece of software is truly bug-free, but there are a lot of steps that can be taken to make them significantly more rare. It's just that these mitigating steps are more expensive than the growth at this time.
The second one is that the more money, the more incentives to hack. And given that transactions are irreversible, you only need each bug once, you don't care that it's fixed later. So if a bug can report a hacker millions of dollars, there's going to be quite a lot of hackers researching, probably with more effort there than the effort put in best practices, audit and formal verification.
The problem of buggy software will continue to exist for new smart contracts that are introduced and manage to capture value quickly, but as the ecosystem matures and more niches are filled, new code will be less likely to attract large numbers of users, so the scope and impact of any bugs in that code will be much less.
Eventually an equilibrium will be reached whereby survival of the fittest ensures that the smart contracts most people rely upon can be trusted. Effectively, some smart contracts will build brand value, and people will be able to rely on the reputations of these smart contracts. Some people may take a risk on a new smart contract and loose (or win), but most people who follow the heard will not have a problem.
It is also important that scrutiny be applied to these protocols, and I imagine that at some point DeFi protocols may be be subject to regulator audit and approval before they are opened up and made available for use by retail customers. If the right people pay enough attention to the implementation of these protocols, then it should be possible to trust them. Also, if you yourself are risking significant funds, it wouldn't be a bad idea to personally review and understand the smart contract code.
That being said, over extended periods of time (decades), long-lived smart contracts will tend to be safer, and insecure smart contracts will tend to be identified as such. If enough value is at risk, and if enough time has passed, then it is extremely unlikely that an exploitable bug will exist that has not already been exploited.
Keep in mind that as a general rule smart contract implementations are immutable, so any bug that exists within a protocol is typically a bug introduced to the protocol when it is first deployed. There are never any "new" bugs that are introduced to an existing smart contract; if a bug emerges after a long period of time has passed, it is a bug that existed at the beginning but had not been previously identified.
At a certain point the passage of time will have reduced this risk below a tolerable threshold that is more than outweighed by the value that people get from using the software. So in practical terms, in the aggregate, such long-lived systems could reasonably be treated as secure.
Either I want something to match, in which case check it all, or I don't care if it matches, in which case don't check at all.
Why would you ever check 4 bytes?
To me it smells like a way to prevent fuzzers stumbling on a deliberate loophole.
Who thought an amazing new P2P invention would improve the image of normal money and traditional banks?
Shady stuff that happens in the banking system usually happens behind the closed doors and we don't hear about it for years, if ever. Crypto/DeFi is new and exciting - it gets a lot of attention from press. It is still way easier for me to trust code than to trust people. Call it a character trait / flaw if you want.
"Exciting" or not.
I always feel like we're making mistakes that tangential areas of software engineering must have already solved. I guess devs tend to also not like math or writing proofs either, which is ironic given this is "crypto" lol.
I don’t like loss or theft ,obviously, but I have to think if regular IT/apps/software/networks etc.. had this big of a material threat, we would see far more secure systems and organizations.
So it would reason that as block chains and crypto eat the world they will raise the bar.
Am I thinking about this right?
A few years back I wrote https://medium.com/coinmonks/lashing-out-at-a-spank-channel-... about a similar hack where a contract "trusted" a given (user input) contract based on nothing other than verifying a function signature. This latest hack was smarter but ultimately it still exploited a 4 bytes hash "security" feature...
Full stop; I’m stuck here. Why does it need to do this?
> By sending this cross-chain message, the user could trick the EthCrossChainManager into calling the EthCrossChainData contract, passing the onlyOwner check. Now the user just had to craft the right data to be able to trigger the function that changes the public keys.
Could this bug have been avoided by extra safety features in the language used to write the contracts like a better type system? Or the code wasn't using all the language features it could? I found the cause of the bug hard to understand to be honest.
Never trust user input.
[EDIT] Okay not 5... maybe like 25 but not in crypto tech.
The technical details are fascinating and super complex. And IME comically badly documented.
The gatekeeper function was "protected" by hash of its name and parameter types and this is the $600M quote:
"You don't need to find a full hash collision, you're only checking the first four bytes. "
And it is all in the environment where mountains of hardware with highly optimized software are combined in huge networks with the only purpose of calculating few basic types of hashes :)
As another comment mentioned, this is a classic "confused deputy" vulnerability.
This is distinct from other languages where methods and functions are addressed unambiguously by the full signature as a string (like in Python), or by a specific memory address (like in C).
In most situations this addressing scheme works very well, because in practical terms there will never be a hash collision inside of a smart contract, and if there were such a collision, the compiler would catch it and fail to compile, and the EVM would reject any bytecode containing such a conflict. Regardless, this is not a problem within Ethereum.
The thing is, Poly Network is a separate thing from Ethereum, and although it does integrate with Ethereum, it does so with its own separate software. The way it interfaces with Ethereum is via several Ethereum smart contracts, including one (smart contract #1) that holds the tokens that it manages on the Ethereum blockchain (valued in the hundreds of millions of dollars), and another (smart contract #2) that permits users of the Poly Network software to invoke arbitrary functions on arbitrary smart contracts already deployed on Ethereum. The Poly Network software talks directly to these smart contracts.
Poly controls these smart contract with a permissions system implemented inside the smart contracts themselves, whereby the invocation of any function of the smart contracts is verified against a list of public keys (i.e. account addresses) that are authorized to make any such invocation. Only users that hold the private keys that correspond to these authorized public keys may invoke the smart contracts' functions; in practice, these keys are controlled by the Poly Network software. Each smart contract stores this list within its own data (analogous to private instance data inside a Java object).
The problem is that the Poly Network proprietary software uses the same authorized key pairs to move funds in and out of smart contract #1 and also to invoke smart contract #2. This means that a user of the Poly Network software can use smart contract #2 to invoke smart contract #1, which is very bad.
What happened is that the hacker figured this out, and used smart contract #2 to update the authorized public key list inside contract #1, which was allowed to happen because he routed the message through the Poly Network software, which dutifully signed the message with its own secure private keys. In other words, the Poly network signed a message from the hacker authorizing the Poly smart contracts to replace the authorized public key list with the hacker's public key, giving the hacker control over contract #1.
It wasn't as simple as this, though. Apparently, although the Poly Network allows any function name to be invoked by the end user, that function is required to be invoked with a signature that includes a particular set of arguments, specifically "(bytes,bytes,uint64)". The hacker wouldn't be able to call "putCurEpochConPubKeyBytes" directly from the Poly Network software, because "putCurEpochConPubKeyBytes" accepts only one argument, not the three arguments that the Poly Network software uses to construct the signature for function invocations sent from contract #2.
So, the hacker had to discover another function name that when combined with the three arguments would result in a four-byte hash that corresponded to the four-byte hash of the function he wanted to invoke. By brute force the hacker discovered that "f1121318093(bytes,bytes,uint64)" has the same four-byte hash as "putCurEpochConPubKeyBytes(bytes)". So the hacker used an invocation to "f1121318093(bytes,bytes,uint64)" to invoke "putCurEpochConPubKeyBytes(bytes)" on contract #1, and thereby replace the authorized public keys for that contract with his own. Having obtained control over contract #1, he was able to transfer out all of the tokens it controlled, to the tune of hundreds of millions of dollars.
There are any number of ways that Poly Network could have prevented this from occurring, most obviously by not allowing contract #2 to invoke contract #1. They also could have done a better job of filtering what kinds of messages users can send from the Poly Network software.