14 ms·

The bug which lost more than $600M in various cryptocurrencies a few hours ago

131 points by edward 5y ago

irjustin 5y ago
Can someone help ELI5 please? [EDIT] Okay not 5... maybe like 25 but not in crypto tech.
- saalweachter 5y ago
  Smart contracts are actually dumb contracts.
- lordnacho 5y ago
  My quick reading of it: there's this chain of chains that tries to make it possible to interoperate the various blockchains. The way they do it is they have a gatekeeper on each chain that locks up funds on one chain and releases them on another. Someone found a way to replace this gatekeeper with their own version, leading to havoc. The technical details are fascinating and super complex. And IME comically badly documented.
  - trhway 5y ago
    >Someone found a way to replace this gatekeeper with their own version 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 :)
- vincnetas 5y ago
  I would say it was confused deputy attack : https://en.wikipedia.org/wiki/Confused_deputy_problem https://en.wikipedia.org/wiki/Confused_deputy_problem
- cesarb 5y ago
  If I understood it correctly, there was one contract (EthCrossChainManager) which could call arbitrary methods on other contracts, the methods being identified by a 4-byte hash. There was another contract (EthCrossChainData) which had a method the attacker wanted to call, since it allowed to change relevant public keys, but which had a check on the identity of the caller. However, that check allowed the former contract to call the later. So the attacker only had to find a method name which led to the same 4-byte method identifier, and trick one contract into calling the other; the first one though it was calling an arbitrary function on an unrelated arbitrary contract, while the second one thought it was a legitimate internal call from the related first contract. As another comment mentioned, this is a classic "confused deputy" vulnerability.
- legutierr 5y ago
  Ethereum smart contract functions (i.e. methods) are addressed based on a four-byte hash of the signature, within the context of the smart contract itself (a smart contract is analogous to a Java or Python class instance, having state and logic). So, after compilation, a function will be addressed like <smart contract address>.<method hash>, if you can imagine. 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.
Clewza313 5y ago
Here's the original thread, as opposed to a random person quoting a random tweet halfway into it: https://twitter.com/kelvinfichter/status/1425217046636371969 https://twitter.com/kelvinfichter/status/1425217046636371969 https://threadreaderapp.com/thread/1425217046636371969.html https://threadreaderapp.com/thread/1425217046636371969.html
- rahimnathwani 5y ago
  Calling dang.
  - dredmorbius 5y ago
    Email the HN moderator team directly: hn@ycombinator.com
im3w1l 5y ago
So my understanding of contracts (and particularly cross chain ones) is low. But how likely is the compare-four-bytes-only to be a deliberate weakness? Is this an inside job?
- creshal 5y ago
  Cynic mode: Putting sighash in things you shouldn't is incredible common cargo culting in cryptobro areas, it's much more likely that the people involved didn't even understand its implications.
malthaus 5y ago
So as someone very critical of the whole DeFi / Smart Contracts philosophy (purely in terms of practicality, not the high-level concepts behind it) - please explain to me how the impacts of those bugs are going to be mitigated going forward. 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.
- zimbatm 5y ago
  I bet that we will see insurance companies emerge in the market. Contracts will send a portion of the transaction to an insurance company. The insurance company would mandate "layers" to validate the contract. Users can then claim damages if there was a bug in the contract. Once all this is done, the transaction fees will be equal or higher than traditional banking systems :-p
  - xur17 5y ago
    There are a number of "smart contract" insurance companies already, Nexus Mutual is one of the main ones, and the rate of return after paying for insurance on a number of platforms exceeds what normal banks would pay you.
- Taek 5y ago
  At least up to this point, the amount of growth in the industry from moving fast and having buggy software (as opposed to moving slow and having fully verified software) has more than made up for all the hacks. For every $600 million dollar hack, there's been $6 billion dollars in gains from growth in the industry. Moving slower means fewer hacks, but it also means lower growth, and the growth is the more important multiple right now. 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.
joelbluminator 5y ago
So I'm gonna stick with real currencies but thanks...looks good.
mrtksn 5y ago
Cryptocurrencies are fascinating but the irreversibility is not a feature but a bug. 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.
- lawn 5y ago
  > A legitimate trade always occurs between willing partners 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.
  - mrtksn 5y ago
    But that is an illegitimate trade and cuts BOTH WAYS. When the buyer is fraudulent the merchant swallows the cost AND when the merchant is fraudulent the buyer swallows 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.
    - xur17 5y ago
      > 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.
MauranKilom 5y ago
Very ironic (or topical?) for a crypto exploit to boil down to finding a hash collision.
- paulgb 5y ago
  “Find a hash matching these digits” is roughly Bitcoin’s proof of work system. Maybe another way of looking at this is that these weren’t hackers, they were just miners who found a more lucrative coin to mine.
  - t0mbstone 5y ago
    OMG that's brilliant
jokoon 5y ago
I'm having a great laugh every time I hear about crypto-stuff goofs. Who thought an amazing new P2P invention would improve the image of normal money and traditional banks?
- exo762 5y ago
  > 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.
  - NicoJuicy 5y ago
    Can't really hide lost funds worth 600 million $ because of a hack. "Exciting" or not.
- whitepaint 5y ago
  Rome was not built in a day. Examples of 2008, GME fiasco, and many other display a clear and obvious need for decentralized finance.
  - thehappypm 5y ago
    In my opinion, 2008, GME, and many other gaffes really show we need more regulation -- not less!
- dqpb 5y ago
  Mocking inventors for the challenges they cross along the way tends to not age well.
londons_explore 5y ago
"Check the first 4 bytes of" should be banned in crypto code. 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.
- et2o 5y ago
  This is perhaps the most confusing element of it all, to me. I can hardly imagine a legitimate reason to do this. Defeats entirely the purpose of a hash.
  - ed_elliott_asc 5y ago
    Checking whole hash was probably too slow, you can imagine they put in a check for first four bytes, if that matched then check the whole hash - probably merge conflict and lost the second bit - doesn’t seem too far fetched!
  - thrwawy4345784 5y ago
    Maybe somebody thought of short sha-1 id's of git: https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection With that only 4 chars is enough to identify a commit :-)
  - cesarb 5y ago
    If I understood it correctly, the purpose of this hash is just to shorten the method signature (name+types) to a 4 byte identifier. Unless a contract has thousands of methods, the chance of collision is very low (and the compiler could detect any collision, since it can see all methods). The "legitimate reason" for shortening the method signature is probably just to save space; bytes on distributed blockchain transactions are expensive.
- abstractbarista 5y ago
  This blew me away. That's 2^32. They took a cryptographic hash, with good preimage/second-preimage/collision resistance, and then discarded 7/8 of it before comparing to ensure some user-provided input is valid. What in the world?!
55555 5y ago
There's a serious fundamental problem with DeFi that can't be solved with blockchains. 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.
- fny 5y ago
  Now say you're a company hired to do an audit. Same incentives. 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.
  - davidlee1435 5y ago
    Are you thinking of solidity.finance? https://rekt.news/deathbed-confessions-c3pr/ https://rekt.news/deathbed-confessions-c3pr/
- crypt1d 5y ago
  A lot of these contracts, and especially those owned by first-tier cryptocurrency companies, are reviewed by 3rd party auditors. Of course that doesn't completely remove the risk, but certainly at least ensures that no obvious bugs are missed.
motoboi 5y ago
1990’s CGI. All over again. Never trust user input.
social_quotient 5y ago
Is the disincentive with lack of security going to be so strong with crypto projects that people finally take it serious enough to make it a first priority? 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?
- whitepaint 5y ago
  Haha, that is a really interesting point. It actually seems inevitable imo.
seanwilson 5y ago
> So someone realized that they could send an cross-chain message directly to the EthCrossChainData contract. > 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.
jaxrtech 5y ago
I currently work in the crypto space (views are my own). For the life of me, I cannot understand why we do not have a foundation built on something like TLA+ or the Z3 theorem prover instead of paying another human to try and poke your code for thousands of dollars. Maybe formal methods wouldn't be a silver bullet, but it seems a lot better and less error prone than manual review. Or maybe adopt existing knowledge from safety critical environments (e.g. programming brakes on a locomotive). 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.
decentralised 5y ago
The "bug" is that some developers think of matching function signatures as some form of authN / authZ. A few years back I wrote https://medium.com/coinmonks/lashing-out-at-a-spank-channel-2b42b23f0dc6 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...
jl2718 5y ago
“a privileged contract that has the right to trigger messages from another chain. It's a pretty standard thing for cross-chain projects.” Full stop; I’m stuck here. Why does it need to do this?

131 points by edward 5y ago

irjustin 5y ago

Can someone help ELI5 please? [EDIT] Okay not 5... maybe like 25 but not in crypto tech.

saalweachter 5y ago
Smart contracts are actually dumb contracts.
lordnacho 5y ago
My quick reading of it: there's this chain of chains that tries to make it possible to interoperate the various blockchains. The way they do it is they have a gatekeeper on each chain that locks up funds on one chain and releases them on another. Someone found a way to replace this gatekeeper with their own version, leading to havoc. The technical details are fascinating and super complex. And IME comically badly documented.
- trhway 5y ago
  >Someone found a way to replace this gatekeeper with their own version 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 :)
vincnetas 5y ago
I would say it was confused deputy attack : https://en.wikipedia.org/wiki/Confused_deputy_problem https://en.wikipedia.org/wiki/Confused_deputy_problem
cesarb 5y ago
If I understood it correctly, there was one contract (EthCrossChainManager) which could call arbitrary methods on other contracts, the methods being identified by a 4-byte hash. There was another contract (EthCrossChainData) which had a method the attacker wanted to call, since it allowed to change relevant public keys, but which had a check on the identity of the caller. However, that check allowed the former contract to call the later. So the attacker only had to find a method name which led to the same 4-byte method identifier, and trick one contract into calling the other; the first one though it was calling an arbitrary function on an unrelated arbitrary contract, while the second one thought it was a legitimate internal call from the related first contract. As another comment mentioned, this is a classic "confused deputy" vulnerability.
legutierr 5y ago
Ethereum smart contract functions (i.e. methods) are addressed based on a four-byte hash of the signature, within the context of the smart contract itself (a smart contract is analogous to a Java or Python class instance, having state and logic). So, after compilation, a function will be addressed like <smart contract address>.<method hash>, if you can imagine. 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.

Clewza313 5y ago

Here's the original thread, as opposed to a random person quoting a random tweet halfway into it: https://twitter.com/kelvinfichter/status/1425217046636371969 https://twitter.com/kelvinfichter/status/1425217046636371969 https://threadreaderapp.com/thread/1425217046636371969.html https://threadreaderapp.com/thread/1425217046636371969.html

rahimnathwani 5y ago
Calling dang.
- dredmorbius 5y ago
  Email the HN moderator team directly: hn@ycombinator.com

im3w1l 5y ago

So my understanding of contracts (and particularly cross chain ones) is low. But how likely is the compare-four-bytes-only to be a deliberate weakness? Is this an inside job?

creshal 5y ago
Cynic mode: Putting sighash in things you shouldn't is incredible common cargo culting in cryptobro areas, it's much more likely that the people involved didn't even understand its implications.

malthaus 5y ago

So as someone very critical of the whole DeFi / Smart Contracts philosophy (purely in terms of practicality, not the high-level concepts behind it) - please explain to me how the impacts of those bugs are going to be mitigated going forward. 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.

zimbatm 5y ago
I bet that we will see insurance companies emerge in the market. Contracts will send a portion of the transaction to an insurance company. The insurance company would mandate "layers" to validate the contract. Users can then claim damages if there was a bug in the contract. Once all this is done, the transaction fees will be equal or higher than traditional banking systems :-p
- xur17 5y ago
  There are a number of "smart contract" insurance companies already, Nexus Mutual is one of the main ones, and the rate of return after paying for insurance on a number of platforms exceeds what normal banks would pay you.
Taek 5y ago
At least up to this point, the amount of growth in the industry from moving fast and having buggy software (as opposed to moving slow and having fully verified software) has more than made up for all the hacks. For every $600 million dollar hack, there's been $6 billion dollars in gains from growth in the industry. Moving slower means fewer hacks, but it also means lower growth, and the growth is the more important multiple right now. 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.

joelbluminator 5y ago

So I'm gonna stick with real currencies but thanks...looks good.

mrtksn 5y ago

Cryptocurrencies are fascinating but the irreversibility is not a feature but a bug. 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.

lawn 5y ago
> A legitimate trade always occurs between willing partners 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.
- mrtksn 5y ago
  But that is an illegitimate trade and cuts BOTH WAYS. When the buyer is fraudulent the merchant swallows the cost AND when the merchant is fraudulent the buyer swallows 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.
  - xur17 5y ago
    > 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.

MauranKilom 5y ago

Very ironic (or topical?) for a crypto exploit to boil down to finding a hash collision.

paulgb 5y ago
“Find a hash matching these digits” is roughly Bitcoin’s proof of work system. Maybe another way of looking at this is that these weren’t hackers, they were just miners who found a more lucrative coin to mine.
- t0mbstone 5y ago
  OMG that's brilliant

jokoon 5y ago

I'm having a great laugh every time I hear about crypto-stuff goofs. Who thought an amazing new P2P invention would improve the image of normal money and traditional banks?

exo762 5y ago
> 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.
- NicoJuicy 5y ago
  Can't really hide lost funds worth 600 million $ because of a hack. "Exciting" or not.
whitepaint 5y ago
Rome was not built in a day. Examples of 2008, GME fiasco, and many other display a clear and obvious need for decentralized finance.
- thehappypm 5y ago
  In my opinion, 2008, GME, and many other gaffes really show we need more regulation -- not less!
dqpb 5y ago
Mocking inventors for the challenges they cross along the way tends to not age well.

londons_explore 5y ago

"Check the first 4 bytes of" should be banned in crypto code. 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.

et2o 5y ago
This is perhaps the most confusing element of it all, to me. I can hardly imagine a legitimate reason to do this. Defeats entirely the purpose of a hash.
- ed_elliott_asc 5y ago
  Checking whole hash was probably too slow, you can imagine they put in a check for first four bytes, if that matched then check the whole hash - probably merge conflict and lost the second bit - doesn’t seem too far fetched!
- thrwawy4345784 5y ago
  Maybe somebody thought of short sha-1 id's of git: https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection With that only 4 chars is enough to identify a commit :-)
- cesarb 5y ago
  If I understood it correctly, the purpose of this hash is just to shorten the method signature (name+types) to a 4 byte identifier. Unless a contract has thousands of methods, the chance of collision is very low (and the compiler could detect any collision, since it can see all methods). The "legitimate reason" for shortening the method signature is probably just to save space; bytes on distributed blockchain transactions are expensive.
abstractbarista 5y ago
This blew me away. That's 2^32. They took a cryptographic hash, with good preimage/second-preimage/collision resistance, and then discarded 7/8 of it before comparing to ensure some user-provided input is valid. What in the world?!

55555 5y ago

There's a serious fundamental problem with DeFi that can't be solved with blockchains. 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.

fny 5y ago
Now say you're a company hired to do an audit. Same incentives. 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.
- davidlee1435 5y ago
  Are you thinking of solidity.finance? https://rekt.news/deathbed-confessions-c3pr/ https://rekt.news/deathbed-confessions-c3pr/
crypt1d 5y ago
A lot of these contracts, and especially those owned by first-tier cryptocurrency companies, are reviewed by 3rd party auditors. Of course that doesn't completely remove the risk, but certainly at least ensures that no obvious bugs are missed.

motoboi 5y ago

1990’s CGI. All over again. Never trust user input.

social_quotient 5y ago

Is the disincentive with lack of security going to be so strong with crypto projects that people finally take it serious enough to make it a first priority? 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?

whitepaint 5y ago
Haha, that is a really interesting point. It actually seems inevitable imo.

seanwilson 5y ago

> So someone realized that they could send an cross-chain message directly to the EthCrossChainData contract. > 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.

jaxrtech 5y ago

I currently work in the crypto space (views are my own). For the life of me, I cannot understand why we do not have a foundation built on something like TLA+ or the Z3 theorem prover instead of paying another human to try and poke your code for thousands of dollars. Maybe formal methods wouldn't be a silver bullet, but it seems a lot better and less error prone than manual review. Or maybe adopt existing knowledge from safety critical environments (e.g. programming brakes on a locomotive). 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.

decentralised 5y ago

The "bug" is that some developers think of matching function signatures as some form of authN / authZ. A few years back I wrote https://medium.com/coinmonks/lashing-out-at-a-spank-channel-2b42b23f0dc6 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...

jl2718 5y ago

“a privileged contract that has the right to trigger messages from another chain. It's a pretty standard thing for cross-chain projects.” Full stop; I’m stuck here. Why does it need to do this?