Cryptocurrency loan platform implodes in $130M hack
vice.com
vice.com
From the article:
C.R.E.A.M. was targeted by what is known as a flash loan attack. Flash loans are uncollateralized cryptocurrency loans structured so that they must be paid back instantly using smart contracts, making them attractive for things like arbitrage across exchanges. If the loan isn’t paid back, then it never happens, because both occur in the same transaction.
Analysts on social media who pored over the details of the attack suggested that the hacker exploited C.R.E.A.M. in an incredibly complex transaction for a flash loan that ultimately allowed the hacker to drain C.R.E.A.M.’s Ethereum-based lending pools, leading to a gain of around $130 million in different tokens. The attack cost the hacker roughly 9 ETH in network fees, or around $36,000.
[edit] tl;dr: it's the reason there's now an Ethereum Classic, and we learned that Code is Law and trustlessness only applies to grandma's savings, not Vitaliks.
[1] https://www.coindesk.com/learn/2016/06/25/understanding-the-...
Yep. Legal jargon IRL is about as close as you get IRL to "code", with roughly 1,000 years of legal development underlying common law and modern legal systems to inform a style of language that is practically its own dialect.
Quite a bit of it has developed over the centuries in an effort to eliminate potential ambiguities in things like contracts so there would be no question about how the legal instrument should be executed.
This is why, to the butt of many jokes & frustrations, legalese is so extremely verbose & dense. Eliminating ambiguities or unintentional side effects or loopholes is extremely difficult.
Code appears to be little different in this respect: Implementing code that effectively says "don't manipulate the market in a way that makes us lose $millions" is not a straightforward task.
This is the lesson a lot of people fail to learn from watching. They seem to have to experience it.
Let to an ETH hard fork into -> (ETH Classic - still traded, and ETH)
Could you not use the same exact description of anyone exploiting bugs in software to gain access to a system?
I believe there is actually a case making its way through the courts as we speak where someone is making the case that "code is law" is binding and should be able to keep the proceeds of his "loophole exploitation." Personally I'm with him haha. Sow -> Reap. [1]
[1] https://www.coindesk.com/tech/2021/10/22/after-stealing-16m-...
Those are bypassing security restrictions. Whereas each step in this process was a legitimate & allowable crypto transaction.
Both are exploits. But they are not the same type of exploit.
In this case, the trade didn’t even violate the intended behavior of systems involved. It’s not like a bug which results in a system operating differently than intended. The system operated exactly as intended, but their intended system design was obviously flawed.
An analogy to traditional finance might be something like a short squeeze, where a sufficiently capitalized counterparty can blow up the trade and extract money from someone else if (and only if) they can pump enough capital into the system.
The difference with smart contracts is that an attacker doesn’t need to have the capital to execute the trade. They can secure a “flash loan” that is conditional on the trade working out, otherwise the loan never happens. That’s why the attacker was able to pump $500 million into the play without ever taking ownership of the $500 million or even putting it at risk. The flash loan only occurred in the context of the trade, but it was open and closed as part of the complex contract. The attacker only had to pay transaction fees to push the contract through.
They clearly did NOT intended to give the coins away. Or if you argue they do any OS had any remote code execution attack also intended.
They designed a cryptocurrency with a floating value that went up or down according to certain rules. Someone read these rules carefully and then borrowed billions of dollars of capital to play the game, according to the rules, in a way that moved the value in their favor.
This isn't like a remote code execution attack because OS designers aren't planning features that allow unauthorized remote code execution.
This is more like an options trade that didn't work out because someone with more money used their capital to blow up the trade. You can't make a bad trade in the stock market and then argue that your loss was a "bug" because you intended to make money, not lose money.
Code is law will only lead to SkyNet.
This is more like setting your screensaver or debugger to cmd.exe on windows NT and waiting for an admin process to crash or the screensaver to start. (I forget exactly how it worked)
If someone chose to play such a game intending to win and with appropriate planning to ensure wins through optimal play, I wouldn’t call that an exploit at all. It’s beating the game, and the owner may ban you from playing it, but no laws were broken by you playing it in such a manner with larger than average capital. But your winnings are yours, fair and square.
If it was, people will argue malicious compliance like you are, but intent has to be considered, both the intent of the developer and the intent of the exploiter (or loaner, is maybe a less loaded term for them)
“Someone read the rules carefully, then borrowed capital to move the rules in their favor”, you could say the same thing about an integer overflow, both are attacks of excess, with intent for massive personal gain, outside the intended use case of the system
100% Agree you can also look up trading patterns on option expiration Fridays to see people making sure that their trades 'work out'
I frequently make decisions that don’t turn out as I intended. You need a distinction between whether the outcome is what you intended and whether the process is what you intended. It isn’t a clear line.
No, the design was so complex that its flaws were well hidden, and therefore not intended.
Quoting C. A. R. Hoare:
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
That’s no less true for a Chrome sandbox escape.
In fact, this Ethereum loan platform’s behavior is encoded in program source codes, just like Chrome. One expects that some exploitable issues in the Chromium code arise not from syntactical but conceptual errors. The code could match a mistaken programmer intent, and this often happens.
Excellent question, one that crypto dudes could ask themselves a little more often.
You are probably reading this comment and thinking "yeah, hah, naive fools". About as naive as the fools, that believe in a 100 line program, that gives you a puzzle that nothing will realistically ever be able to solve, yet the program could tell immediately if the solution is wrong or right.
This is clearly a false statement. The people who set up the system did NOT intend to allow others to take $130 million for nothing.
The point was that their code did not express their intentions 100% correctly, and that's because that is quite hard to do.
And that’s basically what happened here: Someone read the fine print of the trading platform and realized they could use a flash loan to push the system into a space where the trade would default and the attacker would profit. So they pressed the button and the system worked as designed.
If you want your gains/losses to be reasonably bound, you have to limit yourself to buying and selling stocks directly. Unfortunately, there's not enough money in that to make a living day-trading.
It is like when Kim Kardashian gets paid 50M for a 30 second add on Instagram. I may think that is unreasonable, but I don't have any contract with anyone implying that she be paid a standard actor's wage.
Intent is certainly a big part of law.
When examining classic contracts, a judge will try to also deem intent.
Contracts have been thrown out, interpreted by intent of parties.
An example, are the comments in the source code for this smart contract? Did everyone have opportunity to see them?
It could affect a court battle...
If your plan is to rely on the court system, then just rely on the court system. You can write your contract on paper; smart contracts serve no purpose whatsoever then.
But just as in real life, an executor can make mistakes.
Traditionally, a judge may return or redistribute assets in such a case. Or claim the will was not interpreted correctly. In such cases, determining the intent of the contract is the goal of the court.
Like it or not, smart contracts are not immune to contract law, civil law, courts.
The first court cases, which will undoubtedly happen, will be very interesting.
And moreso, different legal jurisdictions will interpret things differently. If I was writing smart contracts, I'd want some sort of boilerplate, insisting upon legal jurisdiction, maybe like an open source license, but for smart contracts.
After all, once your identity is known, normal courts can compel you to do things...
The intent (in legal sense) was to make a specific stock trade, not to make money.
If the execution price was obviously incorrect, the trade will be voided for example.
Intent is literally the heart of criminal law. You have to have intended a crime for it to be a criminal act. In this context, this means that you had to intend to do things that would legally constitute a crime, even if you did not know that the actions/result would be a crime. For some crimes, specific intent is not required for all of the factors (for example, for statutory rape, you do not need to have intended or even known that the other person was underage; for many manslaughter charges you do not have to have intended to kill someone so long as you intended to do things that could reasonably have been expected to cause someone's death).
Intent is also a fundamental factor in tort law, where intentional acts can literally quadruple the amount of damages the plaintiff may receive.
And in contract law, intent is a basic foundational element of a contract. And indeed, a number of contractual disputes arise over one party intending to make money, not actually making money, and suing their counter-party as a result. And many times, the plaintiff wins...
This situation is probably governed by contract law. Since those disputes turn entirely on the specific facts proving or disproving mutual intent, it's hard to say who would win in this dispute since only a small subset of the relevant facts are publicly known.
it is literally not. Though it is a requirement of some crimes.
> You have to have intended a crime for it to be a criminal act.
No, you don't, in general. You have to have intended a particular outcome if the particular crime requires that, but plenty of crimes do not have such requirements (or specifically do not apply if intent is present). E.g., “depraved heart” murder, involuntary manslaughter, and any strict liability crime or crime of negligence or recklessness.
Even if intent isn’t written into a specific law, the whole system is built to specifically allow intent to be considered in so many stages. Sometimes they don’t even decide to prosecute.
Laws exists specifically to create a functioning society. Laws do not exist for the sake of having laws. Any sane person enforcing any kind of rule understands this.
This take is like programmers getting angry when businesses don’t care about the quality the the code or something, forgetting that the whole reason people hire programmers is to solve business problems, not to write text on a computer. Total miss of the point of the exercise.
Mental state (which is much broader than intent, though intent is an aspect of it) is an important consideration for criminal law and most offenses have a required mental state (strict liability offenses are a small minority). And mental state is, yes, considered broadly beyond the formal requirements, too.
But to say that “intent is literally the heart of criminal law” is both literally false and substantively misleading.
Maybe, but the crime wouldn't be first degree murder.
Try googling "mens rea"; e.g.:
"A mens rea refers to the state of mind statutorily required in order to convict a particular defendant of a particular crime. See, e.g. Staples v. United States, 511 US 600 (1994). Establishing the mens rea of an offender is usually necessary to prove guilt in a criminal trial. The prosecution typically must prove beyond reasonable doubt that the defendant committed the offense with a culpable state of mind." [0]
> Maybe, but the crime wouldn't be first degree murder.
The felony murder rule disagrees.
https://www.justia.com/criminal/offenses/homicide/felony-mur...
Whether or not one accepts that use of “normal”, it remains a rule and the claim that murder without specific intent is categorically not first degree, even in broad general terms is false (even before looking into all the variations in specific statutory schemes in the US, which really frustrate this kind of generalization, which takes common law rules and overgeneralizes the way things that are not part of the common law are mapped on to it.)
That's too macro. Multiple steps.
The intent of a stock trade is to exchange currency for share(s). That intent was fulfilled.
Your _desire_ was to make money, but that's not an inherent function of the stock trade.
What is a 'smart contract' in that universe and how is it different than a 'contract'?
1. Someone locking themselves in a dark (usually smoky) room with someone in a button down shirt (with rolled up sleeves) standing over their shoulder.
2. Green text on a black background
3. The words "I'm in" yelled at some point.
Doesn't sound like any of that happened here.
How do you appeal to the courts after doing business under an explicit shared understanding that the courts are unnecessary and irrelevant? It will be difficult to prove that you had any expectation of the other party obeying any norms other than doing everything within its technical power to benefit from the transactions.
Why do you suppose this is the case? Surely that’s not in any way true.
You have to pick between outside and inside the law.
i feel that there is a case of false advertising somewhere here. The classic finance system doesn't advertise "code is law" as a feature, and thus easily claws back accidentally transferred into your account $1B. The Ethereum based crypto and the likes are heavily promoting the "code is law" feature, and thus their readiness and attempts to back off from it anytime the things not going their way suggests false advertising and intentional, at this point giving the history, misleading of the users/customers.
Wrt. the original post - it is pretty surreal, users just borrow and mint $500M-2B in a transaction. The crypto proponents tear at Fed for printing money. Yet even the Fed and WallStreet rarely do $2B flash transaction, and not on a whim by some passer-by Shmoe user. The crypto is really democratizing/distributing and multiplying the financial madness that previously was limited to the exclusive club of big money. I have hard time to see how that is any good, and the wolves of crypto look to me much worse than the wolves of the WallStreet.
I actually think Smart Contracts have loads of potential beyond all this "number go up" stuff
Here just a few : https://intercoin.org/applications
This word to describe software settling monetary transactions is actually a bad choice and oversells what Ethereum actually can provide. A better term would be a financial vending machine.
On chain EVM transactions are essentially just stupid scripts that act according to the same simple, deterministic roles every time you put money into it. The end result is always either you gaining or losing money (but return some other form of “value” like a chocolate bar from a vending machine) by means of a transaction between two people that do not need to know i.e. “trust” each other.
While it certainly does not redefine civil law, a vending machine — if well designed — can enforce compliance with the law without requiring a middle man like a bank or a lawyer.
As every programmer can testify, however, even simple programs can exhibit fairly complex behavior and that’s often impossible to fully predict by static analysis alone.
Still „virtual financial vending machines“ (it’s not as catchy as “smart contracts”) have a huge potential to disrupt the banking and financial services sector.
Good article that covers the topic: https://www.ft.com/content/4169ea4b-d6d7-4a2e-bc91-480550c2f...
Whether it qualifies underall all common senses of "hack" is debatable, but it at least qualifies under a common sense of the word.
"Ugly and imaginative solutions have something in common: they both break the rules. And there is a gradual continuum between rule breaking that's merely ugly (using duct tape to attach something to your bike) and rule breaking that is brilliantly imaginative (discarding Euclidean space)."
That's what a cyberattack hack is.
Well, while the attacker did not exploit a bug inside the lending protocol code per se that person surely relied on a design flaw. Basically, what successful flash loan attacks do is to manipulate the price of an asset inside a „liquidity pool“ of a single „distributed exchange“ (DEX) temporarily to a much lower value and then buy off this asset cheaply and sell it on another DEX for profit.
To protect itself from a flash loan attack, a DEX protocol should use an external „oracle“ to determine the price of an asset instead of relying on the „in-house price“ (in lieu of a better word). C.R.E.A.M. does not seem to do this. This is clearly a flaw in its pricing model.
1. Using account A, Flash Borrow 500m DAI
2. Deposit 500m dai into yDAI
3. Deposit ~500m yDAI into yUSD
4. Deposit ~500m yUSD into yUSDVault
5. Mint ~$500m crYUSD (it used yUSDVault as underlying)
6. Account A now has $500m crYUSD
7. Using account B, flash borrow $2b ETH
8. Mint cETHER
9. Borrow 500m yUSDVault
10. Mint $500m crYUSD
11. Transfer $500m crYUSD to account A
12. Borrow 500m yUSDVault
13. Mint $500m crYUSD
14. Transfer $500m crYUSD to account A
15. Borrow 500m yUSDVault
16. Transfer 500m yUSDVault to account A
17. Account A now has $1.5b crYUSD and $500m yUSDVault
18. Using account A, Redeem $500m yUSDVault
19. Transfer 8m yUSD to yUSDVault to ~double its’ share value
20. Since yUSDVault is now worth double, cream now thinks that the account A’s $1.5b crYUSD is worth $3b
21. Borrow $2b ETH
22. Account A now has $2 ETH, $500m yUSD, and $1b in Cream collateral.
23. The ETH and yUSD can be used to pay back the flash loans while the $1b collateral can be used to drain Cream.
I’m trying to think of the most complicated single transaction item I’ve ever seen booked. I wish I wasn’t so rusty because trying to figure out the journal entries for this would be a fun little nerd puzzle.
Edit: These sort of financial engineering, whether one believes it to be an inherent flaw or not, are the exact reason why banks and financial regulation were eventually adopted.
Crypto becomes the wild west, we have these "flaws / glitches / financial engineering" -> many people lose money -> regulation by lawmakers -> the circle repeats itself.
[0] https://etherscan.io/tx/0x0fe2542079644e107cbf13690eb9c2c659...
1. You take a stablecoin like DAI or USDC and deposit with Yearn, who in turn lend it out and earn interest. You receive yDAI or yUSDC tokens in return which can be redeemed for the original deposit plus accrued interest.
2. You take your yDAI and deposit that into a Curve pool which is a decentralized exchange specializing in stablecoins. There is a pool that allows swapping between yDAI and yUSDC (and two others). If you deposit in this pool, you get a generic yUSD token that represents your claim to the pool’s assets and fees.
3. You look at your yUSD not content with the financial alchemy you’ve performed so far and think “what can I do with this securitized certificate of deposit?” Fear not, Yearn has a “vault” (lending strategy) specifically for yUSD. You praise the degenerate ape overlords and deposit to earn even more interest on your boring dollars. In return you receive yUSDVault tokens.
4. Not content, you begin to wonder why stop with yUSDVault. Are there any other strangers you can lend your rehypothecated certificate of deposit to? Yes! Cream finance will happily issue you their version of yUSD called cryUSD against your yUSDVault collateral…party on Wayne!
5. Now, Cream aren’t your typical boring bank that incinerate their money on synthetic CDOs and the like. These cryUSD tokens that they issue, can also be used as collateral to borrow other things! Hooray! But in order to value cryUSD, Cream needs to figure out how much the underlying yUSDVault tokens are worth. To do this, they need to figure out how much yUSD each yUSDVault token has claim to, and then multiply by the yUSD price.
6. It just so turns out that if you borrow a bunch of yUSDVault in a flash loan, and then redeem it for yUSD, you can get the balance of the yUSDVault very low. Let’s say you did this and left the yUSDVault balance very low (say, $8m). This is not a problem in itself, as these tokens are designed to be redeemed.
7. Well, knowing what we know from step 5, a clever trader realizes that if they do all of the above, and then borrow some yUSD (say $8m) and just donate it to the yUSDVault, when Cream goes to calculate how much cryUSDVault is worth, it will have immediately doubled in value, because some generous donor has just doubled the balance of yUSD owned by yUSDVault (and doubling the borrowing power of cryUSDVault in the process). So if you had flash borrowed a bunch of cryUSDVault (say $1.5b) against flash borrowed collateral (say $2b of ETH), you just now managed to double the value of your loaned assets to $3b but you’ve only posted $2b of collateral.
8. Normally a borrower’s collateral would be liquidated well before being underwater, but in this case everything is happening atomically inside a single transaction.
9. So the smart trader takes her $3b of cryUSDVault, borrows a bunch of other stuff to repay the $2b flash loan, which leaves her with $1b of collateral to borrow a bunch of other stuff (and ultimately default on).
Thanks for the write up, but it seems rather daunting that someone should have to have so much knowledge about such systems.
From there you "just" need to figure out a way to stack a chain of asset transformations to bamboozle the flash loan process into giving you too much money. I say "just" because it's obviously not a simple process, and there's no guarantee that you'd ever find a flaw in the system where it makes some incorrect assumption of value, but this person did, and was able to exploit it to great success.
It's one thing for crypto to be a fun thing where people can day trade on made up numbers, arguably harming 'no one', but when major transactions get problematic, then it's a huge source of pain. Civil and legal lawsuits galore.
It demonstrates that net-net crypto is a value destroyer and is just a bad distraction.
The moment we try to regulate it (and we would have to do this if we wanted to normalized it and make it usable in the commons), then 'all the fun' would be drained out of the bubble as it boils down to just regular banking, more or less.
It's like an intellectual 'Chinese Finger Trap' for smart people with a bit of money to burn, that has negative externalizes.
If it's going to be 'money' then regulate it as money, and watch it the Tower collapse under the weight of it's own complexity.
I just don't see a space for everyone to be happy: if we want crypto to be currency 2.0, it needs to be as unfun as possible, and then you get back to regular banking. If we want crypto to be fun, then we're never going to escape this cycle of "hype and fomo sees people chasing the next coin" to "lots of money went poof" and "someone got rich by making someone else poor."
There might be a little bit of a happy place, above where the boring banks hold on to their systematic control of the system, but a little below where crypto is now with some regulation.
But I feel by the time crypto is useful, that will mostly have converged and 'regular fintech' will provide most of the opportunity.
It's wild that markets can be manipulated inside essentially an uncommitted transaction.
* Not my joke. It was a co-worker's.
Price of Bitcoin will continue to rise as each year people figure out that, if someone can hack wallets, they're not doing it widespread enough for it to be a concern to the average bear, pun intended.
That codebase has a name: it's called Bitcoin.
No discernable hackage seen in the wild for the better part of the last 7-ish years.
And the incentive to find one grows exponentially with time.
The actual flaw is in Cream's oracle design for certain exotic long-tail assets. Basically, smart contracts need to get the price of an asset, and Cream was using the most naive way of simply calling the equivalent of asset.getPrice().
The reason this approach is critically unsafe is highlighted by this incident. A flashloan can alter price, borrow assets based on the new price, then return the price to normal before the transaction is finished.
This is not merely a coding bug but a basic design flaw that should have been caught by anyone with even a basic understanding of oracle design. It really reflects poorly on the competence of the entire DeFi space, considering CREAM is a pretty major protocol.
I hope I'm not adding to the confusion because I am not an expert.
does the oracle in this specific case use external data? and combine that with internal / blockchain inputs? how does one sanitize all those inputs?
are oracles transactional, ie if you manage to alter the state of an oracle within a contract’s transaction, other transactions don’t get any “dirty reads” from the oracle, etc?
The obvious problem is that if that data is manipulated somehow, the smart contract can potentially execute with malicious information.
Chainlink uses a proof a stake (POS) concept where it calls out to a number of LINK nodes that have staked assets for liability in order to win rewards. With all of the Oracles data it goes through an algorithm, for simplicity, let's say the average of all the prices it received, gives the nodes a reputation score, on top of that it uses the reputation of the nodes to choose who ultimately fulfills the request, the number of tokens staked will also take into account. If reputation starts going negative, they could lose the tokens they have staked.
So in this case someone wrote a smart contract/stored procedure that:
- loan $a_lot_of_money from $defi_a
- do something with $a_lot_of_money to confuse an oracle (e.g. a price feed)
- exploit $defi_b who relies on above oracle data
- return $a_lot_of_money to $defi_a
This all happens in a single "db transaction" so as long as $defi_a receives its money back the tx is going to pass.
If $defi_b relies on an oracle that takes it's data from on-chain, and thus is manipulatable with $a_lot_of_money, it is suspectible to those attacks.
To counteract this, $defi_b could only rely on oracles that are secure against manipulation from $a_lot_of_money, but they don't always exist.
This mechanism can be used for good (riskless arbitrage across decentralized exchange) or for bad exploits.
The solution is better coding practices, and plenty of platforms have protections against this.
If flash loans didn't exist, then an entity with sufficient capital can still alter prices and exploit differentials in borrowing costs to profit. This is a common complaint about the mainstream financial system - examples include market corners, short squeezes, George Soros breaking the Bank of England, or the Fed artificially lowering borrowing costs for the U.S. Treasury. But they're limited to people who already have a billion dollars. Flash loans let everybody have a billion dollars, so that if there's an arbitrage opportunity you don't need capital to take advantage of it.
I can already hear my grandma say "I'm glad I lost all my savings, now the platform gets safer."
Apart from that, it's naive to think that this makes the ecosystem safer. We still have SQL injections and XSS in the wild even though everybody should know how to avoid them after literal decades of exploits.
When there's a crypto vulnerability, the contract usually gets drained. It goes bankrupt. There is no funds and no viable business there. Therefore, there's not just a significant incentive to guard against security holes, but there's also a selection mechanism.
People underestimate the power of bankruptcy, failure, death, revolution, nonexistence, and other selection mechanisms. Selection bias is the most powerful force in nature, because natural systems without a selection mechanism tend to get selected away. Arguably a lot of the problems with our current economy come about because we fail to let things fail.
How is CREAM a "pretty major protocol"? It was forked from Compound so no innovation on their own, and their token is not even in the top 100, and their platform is around #30 compared to others in DeFi. There is so much shit things in both DeFi and Cryptocurrency that it's unfair to judge other projects based on how bad they are.
It's like saying a well-written Rust project gets bad rep because some PHP developer once had a SQL injection, and somehow all programmers are the same...
yUSD's value did actually double during the attacker, because the attacker gave yUSD holders millions of dollars as part of the attack.
It's not "incredibly complex". Someone just laundered the magic beans through a series of intermediate cryptocurrencies until they got to one they could just conjure out of thin air. You know, like Tether.
Don't worry though, this is good for Bitcoin.
lol...have you ever given any thought whatsoever to performing a similar exploit? If you have, you wouldn't be brushing this off so nonchalantly
> This was one of the most sophisticated and cleanly executed DeFi attacks. The summary of the attack is that the attacker borrowed $1.5b of Yearn’s yUSD vault shares against $2b worth of collateral. They then doubled the value of the shares atomically by donating yUSD to the yearn vault. This meant that their debt on Cream became $3b against a $2b collateral. They can now default and take home a sweet $1b profit. Cream only had $130m assets available for lending, so the attacker was limited to $130m profits.
> 25. Since yUSDVault is now worth double, Cream now thinks that the account A cryUSD is now worth $3b instead of the original $1.5b. Technically, this is true. The vault of yUSDVault shares really did double. There’s no price or oracle manipulation here and don’t let chainlink god tell you otherwise :).
> 26. The problem is that account B’s debt suddenly increased to $3b against collateral of just $2b. Account B can now default on the loan and “pocket the $1b profit”. All is not good anymore. In normal circumstances where price of assets changes slowly, the system would’ve liquidated the account B before its debt became more than the collateral. Liquidation isn’t possible here because the price jump happened atomically. Using a TWAP or other time delayed oracle wouldn’t have helped either because you still wouldn’t have been able to liquidate the user. To liquidate a user, you need to buy out their debt position using their collateral. Nobody would have sold $3b worth of yUSDVault to Cream for $2b of ETH. Delaying your oracle input doesn’t mean someone will magically accept your trade at delayed prices.
Famously, a guy managed to build a whole legitimate company atop one of those schemes, which went fine until he missed a step and the whole system crashed.
https://krebsonsecurity.com/2019/09/mypayrollhr-ceo-arrested...
unaudited
unaudited
unaudited
unaudited
unaudited
well, well, well
If it isn't the consequences of my own actions.
Auditing really doesn't mean much. A lot of audited platforms get hacked. A lot of unaudited platforms get hacked. Nobody is ever accountable.
Do audited projects get hacked? Yes, absolutely. Is a clean audit report mean a project is bullet proof. Definitely not, especially if it's not from a top-tier firm. But an audit will definitely catch any of the common exploits that are easy to make, like this protocol doesn't check to make sure that the caller is not currently inside another transaction in the contract.
All in all, an unaudited protocol has at least an order of magnitude higher risk than one audited by a reputable firm. Ignoring audits altogether would be like refusing to lock your doors, because you heard about a house that still get robbed when the front door was locked.
I agree that unaudited is worse. But what are you actually paying for with these clowns?
External audits by good teams are a good layer, but neither they, nor any other individual layer is a silver bullet. Good audits do provide a lot of value.
This was not a standard attack though. It was a genuinely new attack vector that's not been seen before. Flash loan was just one hammer in the attacks toolbox.
Remember anything a flashloan can do, a whale can do too.
Auditing isn't perfect, but it is better than not doing it at all.
Its a greater issue in security where audits and testing can lead one into a false sense of security, 'because it is audited'. The original post was saying all the hacked contracts were 'unaudited'. While this is true, I am arguing that in nearly every case, the audit would just be a copy paste of the same data the solidity developer would see when they ran the open source tooling.
That's not been my experience with good audits. Automated tooling only gets you so far. We use open source automated security tooling, unit tests, and and some formal proving, and audits have found things these didn't.
Here's the audit that just finished:
https://github.com/OriginProtocol/security/blob/master/audit...
Their findings are very valuable, could potentially have saved million of user AUM/TVL. Sincerely, Best of luck with Origin!
He will release projects in prod, encourage people to throw money in, take the money and later claim he was just testing. It's bad behavior.
DeFi, in its users, self selects for a lot of...erm...unique personality traits.
Do they "truly" believe it themselves, or are they just rational actors well aware that they lose a lot of money if people stop listening to them? No way to know.
If I have a balance on a DeFi platform, it's vulnerable to attacks like the one in the original article. If I have a balance in a bank, this isn't the case. The risks aren't the same at all. Not the same type of risk, not the same magnitude of risk.
DeFi allows for a lot of unique and flexible things...and people are re-discovering that writing bullet proof code in such an environment is really really hard. i.e. No training wheels and lots of footguns available
>How can people still think that it's the future?
I'd view these events more as growing pains of a complex technology rather than an indication that it has no future.
People are learning though. See Cardano and their choice of Haskell and emphasis on formal verification.
If someone steals from my credit account, I Trust my financial institution to undo it.
Trustless systems are overrated when you have trustworthy institutions.
Quite. But what if you don't have access to trustworthy institutions? Or what if you need to coordinate between trustworthy institutions that either don't work together or don't share mutual trust? What if you distrust the very currency the institution does business with?
Your point is correct. If you trust the institutions all the way down, trustless is complicated and unnecessary. If you don't trust the institutions, what are your other options?
It sounds like people trusted CREAM with their money, and shouldn't have. Not as trustless as you might hope.
If the devs have written formal models for the system and verified that with a proof solver, you have a reasonable assurance the code matches the spec and that the spec is at least consistent with itself.
If the devs have Property Based Testing suites and fuzzing tools to automatically search for vulnerabilities in the code/spec or introduced via changes, you have reasonable assurances that the development process is thorough and likely won't haphazardly introduce a vulnerability in a change (and actively squash potential vulns that are discovered).
If open source security auditors (who's reputation is core to their business) regularly and publicly auditing the platform, you have reasonable assurances that on top of the code being reasonably secure, the spec itself doesn't have any glaring flaws in it.
If bug bounties have red teams regularly trying to discover exploits, you have additional assurance that if a bug exists, it'll likely be discovered, ethically reported, and resolved before being exploited.
Point being, zero trust isn't about not having trust, it's about not having blind trust. These should be the expectation for all high value software. We should be able to trust in the engineering of software systems like we trust in the engineering behind buildings and bridges.
---
Now with regard to this specific hack, CreamFi failed to do 2 out of the 4 of those things mentioned above and their security auditor only provided a very cursory/high level audit. Their report was not confidence inspiring and should have been a red flag to users to not use the service.
Now compare this with the org they forked their code off of. Compound Finance maintains a formal spec, uses formal methods, has a bug bounty, and receives regular, in depth security audits. CreamFi chose to make changes to a codebase after abandoning the security tooling (formal spec was no longer maintained) and protections that were in place with Compound Finance's code.
Any moderately competent technical user should have been able to tell that CreamFi was (like many other knock-off DeFi platforms) a ticking time bomb. We as a software engineering community however still have a long way to go in making these qualities/flags accessible to normal users.
I understand the practical argument (code is easier to audit and more reliable), I'm just not sure how the sum total of the ecosystem is better when, as a practical matter, crappy smart contracts keep losing depositors' money, and depositors keep trusting the wrong contracts.
For developed nations, we'll see Central Bank Digital Currencies slowly replace the existing financial network. You can still get your flexible monetary policy, regulatory compliance, and reversible transactions with a CBDC. The additional benefit is that now instead of having a bunch of centralised, discontiguous, and opaque services for transferring funds, now you have a decentralised, unified, and transparent network for doing this. Additionally, smart contract or smart validator functionality allows you to move some of the traditionally centralised financial logic up into this transparent & decentralised space while still maintaining all the legal protections you'd have otherwise.
Side note: I say decentralised here because ideally CBDCs will use some Proof of Authority system with the various states/provinces/counties/parishes/districts/etc each running validators. The idea here being that you still retain full control by the nation however it now becomes exceedingly difficult for any one person to manipulate the network without the consent/awareness of many other officials.
Now how about developing nations? Many of these nations lack a stable or trusted financial sector. Their people don't trust the officials, the offices, or the policies. These people are the main users of the truly decentralised networks. Of course the risk of crappy smart contracts losing your money is a risk (and assurance/accreditation programs are working to improve the visibility of well designed & operated contracts). The question however is whether that risk is greater or lesser than the risks or costs of using traditional financial institutions in these regions (if the people can even get access to them).
That said I just don't see a lot of the value in a lot of "DeFi" at the moment. A lot of it exists solely as vehicles to allow people to move more money around at a time so that they can take bigger leveraged risks on the market. Now there are useful applications in the space however many are still small and finding their footing.
The majority of supply chain/production traceability solutions and identity solutions in the space are really just two sides of the same coin and serve the purpose of providing a decentralised (or at minimum federated) source of reputation for people and businesses where the local government fails to. Identity solutions provide a means for people in these nations to "prove" their credentials/reputation to gain access to low-to-reasonable interest rate loans or prove their credentials to potential employers. Likewise they provide a means for businesses to provide a history for their products which helps them sell their products at closer to the international market rate (compared to being forced to sell to the big corporation in their region that turns around and resells to the rest of the world).
Lending and Micro-lending platforms provide a means for people in these regions to get access to loans (denominated in their local currency) at rates they would otherwise not be able to get access to. People or organisations in higher QoL/CoL nations/regions can provide liquidity to these services and users in these developing regions can slowly get access to larger & lower interest loans over time by building up their "credit history"/reputation tied to their identity. In developed nations we have systems for this already but many developing nations lack such a service that is accessible to many of their people (and that is trusted). These services still have a long way to go but as the previously mentioned digital identity solutions become more available, this space should start to see some significant improvements in usability & trust.
I'll stop at that because I've already gone way past what I intended to write up (I was also considering going into detail about decentralised good & services marketplaces) but my point being that while there's a lot of issues with smart contracts, the systems provide a means for institutions to rebuild trust by using systems that prevent or at least greatly reduce the potential for abuse or lying by those institutions (or other individuals).
TL;DR: In developed nations CBDCs unify the financial space without compromising on any features of the existing system and at the same time reduce the surface area for illicit activity or attacks on financial institutions. In developing nations however fully decentralised cryptocurrencies provide a fabric for existing institutions to rebuild the trust of their people and international trust therefore increasing their people's and businesses' access to economic opportunities both domestically and internationally.
* https://rekt.news/compound-rekt/
* HN discussion: https://news.ycombinator.com/item?id=28716979
The Compound Finance paper spec essentially just lists "this subsystem does these things" and then each function/operation is a list of preconditions, what actions are taken in what conditions, and the expected result. This isn't bad per se but it's not great either. Instead the paper spec really should be showing what transformation is being applied to the state, why we want that transformation applied, what properties must hold throughout the transformation, and then demonstrating that those properties hold.
Compare this (Compound):
https://github.com/compound-finance/compound-protocol/blob/m... https://github.com/compound-finance/compound-protocol/tree/m...
to this (Uniswap):
https://github.com/runtimeverification/verified-smart-contra... https://github.com/runtimeverification/verified-smart-contra...
or this (Djed):
https://eprint.iacr.org/2021/1069.pdf
The first just describes the system and then asserts preconditions hold which works well enough for verifying that the code matches the spec but the other actually verify that the spec is doing what the user & developer expect it to by formalising the system and analysing the properties of that system.
Compound's project wouldn't have been vulnerable to any of the attacks executed on CreamFi however they are vulnerable to the class of spec errors. Uniswap and Djed on the other hand would be protected from the majority of that class of issue that Compound experienced. This isn't to say that they are invulnerable but I'd be willing to say that they are approaching "cryptography-grade" security where you can trust these protocols just like you can trust AES, RSA, and ECC encryption & signing.
---
This of course isn't to say that what Compound does is bad but as that incident shows, there is still room for their improvement in the security space. Cryptocurrency and "Decentralised Finance" are finally starting to grow up into proper subsets of the cryptocurrency and game theory communities. Now this might be a bit of general commentary on the SW space but hopefully long term this trend causes some of this security minded design to bleed over into the greater software engineering community.
Formal verification absolutely would not have helped in this case.
1. A definition of the constraints of the system. These constraints are "outside" the system and if they are violated, the properties of the system will not hold. This part boils down to clear and dis-ambiguous documentation on the constraints of the system as well as some tooling to help verify the constraints are held (not always possible).
2. A definition of the system itself. This defines the rules and operations within the system as well as formal methods to prove the correctness of this system. Provided this definition is shown to be consistent, as long as the constraints (part 1) are held true, the system is secure.
3. The code itself. Projects have to choose between either writing the code and using formal methods to verify functional equivalence between the code and the system (faster but harder) or using a code generator to produce a runtime directly generated from the system definition.
---
The code (part 3) is only secure if there's a full one to one map between it and the system definition(part 2). The system definition (part 2) is only secure if all the constraints (part 1) are upheld. You can verify parts 2 and 3 automatically but in many cases you won't be able to verify all of part 1 automatically.
This attack relied on the fact that one of the tokens was atomically volatile (allowing the attacker to manipulate funds in a single atomic step increasing the price up to whatever price and risking nothing if they are unsuccessful). The previous exploit was due to the listing of another liquidity pool token that allowed reentrancy. This allowed the two pools to repeatedly interact with each other inside of each other's code bypassing various state checks.
CreamFi failed in two places. One the devs stopped maintaining the spec after forking the protocol off the original Compound Finance protocol so even if they had held the constraints, they had added features that haven't been considered with regard to the formal security of the system. Two (and more importantly) the listing committee (responsible for introducing new tokens) wasn't aware of the constraints of the system.
One could formally verify that if the account number is set in the wash account (plus like six other places) then the loan won’t be repaid due to programming errors. But formal verification doesn’t tell one that the UI is garbage and hard to know that the account number needs entered in six places to get the correct formally verified action to occur instead of the other formally verified action that repays the loan in full.
The risk of investing in stocks is always that the underlying companies could have their business ruined overnight for any reason. The risk of swaps is always that the counterparty could go bust and be unable to pay you even if your bet pays off (see Lehman Brothers). The risk of leveraged futures positions is you can get liquidated on fat finger trades or flash crashes. The risk of structured credit products like CLOs or mortgage backed securities is that the pool is fraudulent. The risk of many quant strategies is that the correlations go to one and your capital gets wiped out as your hedges fail to protect you.
Do any of these risks mean those asset classes are doomed? No, all of the above asset classes are bigger than ever. Markets can and do live with disastrous risk looming over their heads all the time. Unless your name is Nassim Taleb, the reality is that you mitigate the risks you can, model out the risks that you cannot, then price the asset accordingly. The foundation of modern finance is “we don’t have to live in mortal fear of risk if we’re smart about it”
If inherent risk was an insurmountable barrier to the existence of a financial product, then I guarantee you the financial system would just be the old-timely community bankers like in It’s a Wonderful Life.
All of these systems are complex black boxes, for which the full risk profile can never be fully known let alone eliminated. Yet all of these asset classes continue to reach record size. For the foreseeable future, risk is not a meaningful constraint on financial activity or the growth of any otherwise profitable sector.
Global capital is insanely hungry for yield. It’s willing to accept very large, outsized risks as long as returns are attractive. DeFi continues to grow because it offers significantly higher top-line returns than traditional products. As long as that continues to be true, investors will stomach, and in many cases outright ignore, the risks.
(It’s 2 AM in Tokyo and so I can’t elaborate for HNers who think that sentence is Greek. Short version: it’s going to be a very long day for some DeFi war rooms.)
In fact, this is a great illustration of why formal verification is not nearly sufficient to guarantee a properly functioning trading system.
I understand how the first can be arguable (or obvious, depending on what you mean), but are you really saying the second isn't true?
Had the team actually maintained the formal spec, they could have notified the listing committee (which every iteration of has had at least one team member on it). This was absolutely a human error however it likely would have been caught prior to entering production if the team had maintained the formal spec.
I do wonder how much support they're getting.
This is the equivocation that is at the heart of smart contracts.
The promise of smart contracts is that "the code is the law". There is no need for trust, courts, or intermediaries. Of course his only works if the contract correctly implements a perfectly defined spec and has no bugs.
If one claims "the code is the law" they cannot claim it is a "hack" or "theft" when their code executes as written rather than as they desire.
This "theft" is an example of things working exactly as designed, and this seems to be an unfixable flaw in the concept behind smart contracts.
This current attack sounds more like market manipulation, but all bundled up in a single transaction. I can't find the details, but in the real financial world, there's a reliance on multiple competing arbitrageurs who make it hard to move the market much in big securities. In an automated system, that can all happen instantly.
1. https://halborn.com/explained-the-cream-finance-hack-august-...
Also, that method man song is awesome, I can't believe I haven't heard of that until now. Crypto rules everything around me! Cream!
I'm not sure if that makes it better (no security was broken) or worse (these markets are highly susceptible to manipulation)
As exemplified by - historically - the infamous DAO, and since then a very long string of buggy smart contracts leading to large loss of monies (this one being the latest), smart contracts are really good at curing SWE hubris that they are actually capable of writing bug-free code without machine assistance.
For all the bad things people say about blockchains and related tech., I suspect they will bring about a new era in formal software verification methods.
Assuming I do want to understand the DeFi landscape (and willing to suspend my disbelief some amount to do so), where is a good place to begin?
There are thousands of people there more than happy to show you the ropes.
This forum is pretentious on its good days, and when it comes to crypto it is just willfully ignorant.
Even without much DeFi experience I can see some comments are simple dismissals without understanding the enormity of technical details, which is a fatal mistake in the field. Not many explanations of why those dismissals are wrong though.