CREAM Hack and follow up

Please tell me if I’m missing something, but as I understand it. CREAM was hacked due to a vulnerability in Yearn contract that gave the hacker boosted collateral. This resulted in $9 million donation to Yearn, which was given back to Cream, who then dumped ONLY CREAM tokens on those effected, making it a race to cash out based on plummeting CREAM token values. Doesn’t seem right, and Yearn shows no remorse or responsibility. You guys are supposed to be the best, and from what I understand your contract was the weak link, then you gave away my money.

The CREAM tokens gave me roughly 30% of my loss back. Of course I should have had Nexus Mutual, but I let it expire a couple months before, and was waiting for Gas prices to drop so I could pull the ycrvsteth, I’m not a crypto millionaire. Interest rates are incredibly low on yearn now and transactions are crazy expensive on the mainnet.

Your understanding is not correct, the hack is isolated to Cream and there was no Yearn vulnerability involved. You can read a writeup from Yearn’s side here.

3 Likes

I’ve read this, reads like this “The hackers exploited our pricepershare function to make the cream hack possible, but it’s not our fault”

“There was nothing wrong with our contracts, but we’re implementing a fix, on something that isn’t broken any way, just for fun”

2nd part of the issue still outstanding. You gave 1/13th of the hacked funds back to someone who decided to keep it.

As Banteg mentioned, your understanding is incorrect.

The exploit was isolated to Cream’s code, no funds where lost on yearn contracts, and the yearn vault worked as expected.

The problem here is on Cream’s code and similar to AAVE’s issue that was disclosed later, relying on yield tokens as price oracle was in hindsight an attack vector, compounded with other issues that i state below.

In the disclosure you can see the issue on Cream’s side apart from involving the price oracle dependency from yield tokens, also needed the yield tokens to be on a money market that you can lend and borrow them as well to pull off the exploit, again this is all on the Money Market protocol side, not yearn.

Stating that vault contracts had an issue in this attack, is like saying that Uniswap pools have an issue when you can manipulate them to affect a protocol that uses it’s spot price incorrectly.

Yearn making improvements on how our pricePerShare works is on the best interest of the protocol to allow for better and secure integrations.

If there’s something we can improve and learn from this issue even if our code wasn’t exploited, we will explore it, it’s part of our internal process, it doesnt mean anything passed that.

2 Likes

From the GitHub post mortem

“The [exploit transaction] had a side effect of increasing the yUSD vault pricePerShare twofold, from 1.000996 to 2.001993”

Had YOUR contract’s pricePerShare calculated correctly from a donation CREAM wouldn’t have had an issue. Right? It threw off accounting, and you had to pay back funds to 2 users who interacted with the vault during the hack. Given the relationship it’s hard to imagine Yearn developers didn’t know what variable was being used as the oracle by CREAM developers. So how can you say CREAM was using the spot price incorrectly? It was being calculated incorrectly by the Yearn contract…

There being other mechanics involved with a Money Market protocol feels moot to the pricePerShare issue.

ODDLY ENOUGH No one has commented on the $9 million of end users money that you gave to an insolvent org and trusted them to do the right thing with, then they didn’t. But they’re your partners in the Iron Bank, and I’m just the community member you’ve farmed a whole bunch eth interest off of for 9 months, then gave my money away.

1 Like

I suggest you just reread what storm said. This is a documented and discussed feature of yearn vaults and we use this to handle vault donations for yvBOOST, among other use cases.

Cream did not design their loan system in mind for handling v2 vaults correctly, with consideration to this behavior. There was no bug in the way Yearn calculated yUSD’s value. Cream was wrong with how they calculated collateral based on these prices. That being said, this means it will be quite hard to do these type of markets with vault tokens, which is why Yearn is designing a different way to do this. That way partners like Cream can more easily handle yVault token collateral.

No one is blaming Sushi for the fact that Aave was sitting on an 11 figure vulnerability due to the way xSushi pricing was handled in Aave. As the hacker said, “aave lucky, cream unlucky”. Notice how he never mentioned yearn’s luck, because he knew it was the lending protocol’s issue.

Coming at Yearn this way isn’t going to help. You need to put pressure on Cream if you want to get more restitution. Considering that the community owns a large part of the governance token, it seems like it could be an effective strategy to plan some DAO votes to establish the road ahead for paying off the hack.

2 Likes

I’m here to chat about the post mortem, and the case for plausible deniability vs admit partial responsibility on Yearn’s end. Also the $9 million impropriety on Yearn’s end.

I fully appreciate the dialog, but it still stands to reason that Yearn is thinking in Yearn’s best interest, and doing their best to avoid responsibility. Complete argument for your reading pleasure.

Issue 1
YEARN’s implausible deniability

Opening Statment: Yearn’s case for no responsibility for the CREAM hack is: “no one is blaming sushi, for Aave having the same vulnerability” and that no Yearn funds were lost and that the issue was on CREAM’s side, and their code acted “as it should”.

  1. Yearn bears responsibility because Yearn and CREAM are PARTNERS. Sushi and Aave are autonomous entities, there is no feasible universe where the pricePerShare function being used as an “Oracle” wasn’t at minimum known by Yearn devs, if not suggested. Oracles are a hot topic and known weakness to the whole defi community, before launching CREAM’s yVault token collateral composability, this must have been discussed/know by Yearn devs.

  2. Yearn devs claim the pricePerShare function “worked as expected”, and the ability for anyone to send funds as if the contract was a normal wallet was left open on purpose, and is a “documented feature”.

A lie by omission, while partially true, Yearn devs must have never fully considered/tested how the pricePerShare function would behave if the vault’s underlying token was sent to the vault in this manner. This makes sense at the vault’s inception because no one would airdrop the vaults underlying token to said vault, but the pricePerShare function should have been revisited when you knew it would become an Oracle. See Point A below for supporting evidence.

  1. Yearn devs claims no vault accounting was ever wrong and the CREAM team’s calculations were the only wrong ones.

Fallacy, by their own admission the pricePershare function was manipulated by the hacker to return a value of 2, when it should be 1. Two unrelated accounts interacted with the vault before it was fixed and those users had to be repaid for the miscalculation. ALSO, CREAM’s “oracle” is simply an interface that calls Yearn’s yVault contract’s external pricePerShare function directly. The pricePerShare function being manipulatable is the lynchpin of the entire hack. Allowing for inflated collateral values for the hacker and anyone holding the yVault token at that time. Also supported by Point A below.

A. Mudit Gupta hack analysis you provided in github at
Creamed Cream - Learn the Secret Recipe (Cream Hack Analysis) - Mudit Gupta's Blog
The magic happens here – Transfer 8m yUSD to yUSDVault. This basically donates $8m to the yUSDVault. The yUSD balance becomes $16m while total supply remains $8m. Therefore, the price of every yUSDVault share becomes $2 for real. All holders of yUSDVault just doubled their investments.

  1. Yearn tries using the hacker’s signed message as evidence of innocence: “As the hacker said, “aave lucky, cream unlucky”. Notice how he never mentioned yearn’s luck, because he knew it was the lending protocol’s issue.”

Another lie by omission and misdirection, if we’re going to use the hacker’s word against him or her, perhaps we should use this portion too? “ydev: incest bad, don’t do."

Clearly the hacker is scolding Yearn. We know they didn’t “get Yearn funds”, but that’s not the issue, the issue is responsibility of Yearn and CREAM codebase combined. Did you think I couldn’t read hexadecimal? Or use etherscan? Or google it? :wink:

Closing Argument:
I’m simply stating that Yearn devs should admit partial responsibility because they helped write the code with their partner. And their contract pricePerShare function being a manipulatable Oracle was integral to a very complex and unfortunately impressive hack.

Issue 2
Misappropriation of $9 million dollars in victim funds

Opening Statement: Yearn was sent approximately $9 million dollars in yvault tokens by the hacker so he or she could manipulate the pricePerShare function and therefore CREAM collateral “oracle”

  1. Yearn immediately sent this money to CREAM. Without verifying how it would be used. CREAM kept it and dumped their CREAM tokens on victim’s. Been like what 3 or 4 hacks this year for CREAM?

If Mochi or some other questionable protocol had been hacked instead of your partner CREAM would you have sent it back to Mochi without thinking?

Closing Argument:
If Yearn can’t convince CREAM to distribute the $9million, they should be held responsible for said funds.

  1. Yearn tries using the hacker’s signed message as evidence of innocence: “As the hacker said, “aave lucky, cream unlucky”. Notice how he never mentioned yearn’s luck, because he knew it was the lending protocol’s issue.”

Another lie by omission and misdirection, if we’re going to use the hacker’s word against him or her, perhaps we should use this portion too? “ydev: incest bad, don’t do."

Clearly the hacker is scolding Yearn. We know they didn’t “get Yearn funds”, but that’s not the issue, the issue is responsibility of Yearn and CREAM codebase combined. Did you think I couldn’t read hexadecimal? Or use etherscan? Or google it? :wink:

Like I said, he never mentioned Yearn’s luck, not sure how his portion at the end has anything to do with luck :man_shrugging:. Congrats on being able to use Etherscan, literally nobody was saying you couldn’t.

A lie by omission, while partially true, Yearn devs must have never fully considered/tested how the pricePerShare function would behave if the vault’s underlying token was sent to the vault in this manner. This makes sense at the vault’s inception because no one would airdrop the vaults underlying token to said vault, but the pricePerShare function should have been revisited when you knew it would become an Oracle. See Point A below for supporting evidence.

More evidence that you read nothing that I wrote. This feature has been used to airdrop to yvBOOST holders many, many, many times at this point. It is how Yearn profit shares our EPS airdrops and bribe revenue to those token holders, Yearn just donates to the vault.

Cream must have not taken this into account when listing vault tokens on their CreamV1 product. Notice how IronBank, the product Yearn did have a bit of a hand in, does not take vault tokens as collateral.

Issue 2
Misappropriation of $9 million dollars in victim funds

Opening Statement: Yearn was sent approximately $9 million dollars in yvault tokens by the hacker so he or she could manipulate the pricePerShare function and therefore CREAM collateral “oracle”

  1. Yearn immediately sent this money to CREAM. Without verifying how it would be used. CREAM kept it and dumped their CREAM tokens on victim’s. Been like what 3 or 4 hacks this year for CREAM?

Damned if you do, damned if you don’t. If Yearn kept the yUSD, then yUSD owners would have withdrawn for a sweet, sweet free 2x profit. If Yearn sent it to our treasury, Yearn would have set off the alarms and also given ownership to our multisig and governance who have no right to that money. Imagine the swarm of people coming in claiming that Yearn stole their money. This scenario doesn’t change no matter the situation. Damned if you do, damned if you don’t.

I think it is best that Cream has the yUSD. Since the victims own so much cream now, seems not too out of scope to have a DAO vote to see what to do with it. Has the Cream community had any of these discussions lately? It seems like most of the resources are going into screaming at Yearn when there is literally nothing Yearn can do right now.

Closing Argument:
I’m simply stating that Yearn devs should admit partial responsibility because they helped write the code with their partner. And their contract pricePerShare function being a manipulatable Oracle was integral to a very complex and unfortunately impressive hack.

I highly doubt anyone at Yearn wrote the v1 cream code.

2 Likes

I’m definitely not screaming. You go with Option C and set up a claim and distribute directly to the victims, instead of blindly trusting 1 of, if not the most hacked protocols ever to distribute.

And the victims didn’t keep the CREAM, you damn well know most dumped as soon as they claimed it.

Keep it civil, thanks

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.