It’s not "hackers". It’s an inside job, and a rug pull.
cypherpunks01
Seems that an Elements rangeproof cache bug may've gotten exploited. Fix for suspicious issue was committed just last week and attackers could've monitored the public commits and exploited the bug before fix was ever pushed? Sort of self-fulfilling prophecy if true, that's a leading theory anyhow. fix: range proof cache bind to asset and scriptpubkey https://github.com/ElementsProject/elements/commit/c26d719c2...
galkk
Time for bitcoin classic++?
georgemcbay
$320m, not a bad haul. More than enough to buy yourself a pardon if you get caught.
etothepii
Is there any indications that this and the ColdCard heist could in fact be escaped distilled agents from the huggingface and similar attacks?
TZubiri
One disadvantage of decentralized money, criminals gain more power. Many such cases
atian
“Inside job.”
aizk
I wonder how they'd ever cash out.
nullc
I worked at blockstream back in 2017 and developed the original cryptographic range proofs which are the ancestors some of the involved code here. However, the vulnerabilities here and the whole liquid product as it exists today postdates my involvement in the company (while I was there it was under initial development but envisioned quite differently than what they eventually did), and I haven't followed any of it closely since. But I gave this issue a quick look based on the transactions and github history. Underlying issue was related to validation caching. Signatures and proofs are expensive to validate, to improve performance and prevent certain DOS attacks their validation is cached. It's important that the key used in the cache capture everything that goes into the validation decision (though to prevent some attacks its important not too much goes into the key, or an attacker can flood with valid proof attacked to insignificantly different transactions). It appears to me that there was a longstanding vulnerability-- stemming back to the introduction of multiple-asset-support-- which could cause a consensus split/ddos. But on a lazy review I can't come up with any way of translating it into theft. I see how someone could make an invalid transaction that would be falsely accepted by nodes that have cache state from a constructed prior transaction, but the ways I can come up with results in the invalid transaction just burning assets--- not directly very useful. [Big asterisks on the non obviously exploitable here, I've only thought about it for a minute or two and I really know fairly little about assets support in Liquid-- but exploiting it would require being able to create a fake 'shadow' asset with the a generator that is the negation of a real asset.] In any case: This was recently fixed, but the "fix" introduced a hash collision vulnerability: The new fields added to the hash were not delimited. Failing to include type information like lengths in hashes is a perennial problem in cryptographic protocols. Imagine you have a protocol where you sign a {comment, command} tuple, each a string. If the protocol computes the hash by just concating the command and comment and they're variable length fields, then you could get a signature of {"boring comment containing dangerous command", "boring command"} but then present it to someone as {"boring comment containing ","dangerous command boring command"} and have the signature pass. That sort of thing. This new vulnerability has a somewhat straight forward path to exploitation and prints funds out of thin air. Based on some of the public comments about nodes rejecting the attack transaction, I'm guessing they rolled out the "fix" to the federation in advance of publishing the changes because they seem to have accepted an attack that everyone else was still rejecting. Advanced private deployment of a 'fix' might have gave them the confidence to drop the fix on github with little fanfare as it was "already fixed", but doing so painted a target on the issue that remained. Interestingly, off the shelf open weight AI like Kimi K3 immediately identify the new vulnerability without any particularly artful prompting. Makes me wonder if "safe" AI played a role in the introduction of the new, more serious, vulnerability. Interestingly, it looks like the funds are being returned: https://mempool.space/tx/3a3eac4a26395b8c2563aaf1eb8b1b77798... I'm going to guess that anyone who actually knows more has their hands busy dealing with the return of the funds. I'm not sure if anyone has ever taken and then returned 1/3rd of a billion dollars worth of assets before.
rgbrgb
There’s kind of an interesting thread here about open source, which is usually thought of as more secure because of more eyes on the code, actually being less secure because an accidental merge can be exploited instantly with LLM’s monitoring. Is there a lot more security value in obscurity than before?
Related Discussions
Found 5 related stories in 54.8ms across 5,720 title embeddings via pgvector HNSW
Discussion Highlights (12 comments)
skinfaxi
Why do they say it's white hat hackers?
Daviey
https://xcancel.com/Liquid_BTC/status/2096696272447218108#m
xyst
It’s not "hackers". It’s an inside job, and a rug pull.
cypherpunks01
Seems that an Elements rangeproof cache bug may've gotten exploited. Fix for suspicious issue was committed just last week and attackers could've monitored the public commits and exploited the bug before fix was ever pushed? Sort of self-fulfilling prophecy if true, that's a leading theory anyhow. fix: range proof cache bind to asset and scriptpubkey https://github.com/ElementsProject/elements/commit/c26d719c2...
galkk
Time for bitcoin classic++?
georgemcbay
$320m, not a bad haul. More than enough to buy yourself a pardon if you get caught.
etothepii
Is there any indications that this and the ColdCard heist could in fact be escaped distilled agents from the huggingface and similar attacks?
TZubiri
One disadvantage of decentralized money, criminals gain more power. Many such cases
atian
“Inside job.”
aizk
I wonder how they'd ever cash out.
nullc
I worked at blockstream back in 2017 and developed the original cryptographic range proofs which are the ancestors some of the involved code here. However, the vulnerabilities here and the whole liquid product as it exists today postdates my involvement in the company (while I was there it was under initial development but envisioned quite differently than what they eventually did), and I haven't followed any of it closely since. But I gave this issue a quick look based on the transactions and github history. Underlying issue was related to validation caching. Signatures and proofs are expensive to validate, to improve performance and prevent certain DOS attacks their validation is cached. It's important that the key used in the cache capture everything that goes into the validation decision (though to prevent some attacks its important not too much goes into the key, or an attacker can flood with valid proof attacked to insignificantly different transactions). It appears to me that there was a longstanding vulnerability-- stemming back to the introduction of multiple-asset-support-- which could cause a consensus split/ddos. But on a lazy review I can't come up with any way of translating it into theft. I see how someone could make an invalid transaction that would be falsely accepted by nodes that have cache state from a constructed prior transaction, but the ways I can come up with results in the invalid transaction just burning assets--- not directly very useful. [Big asterisks on the non obviously exploitable here, I've only thought about it for a minute or two and I really know fairly little about assets support in Liquid-- but exploiting it would require being able to create a fake 'shadow' asset with the a generator that is the negation of a real asset.] In any case: This was recently fixed, but the "fix" introduced a hash collision vulnerability: The new fields added to the hash were not delimited. Failing to include type information like lengths in hashes is a perennial problem in cryptographic protocols. Imagine you have a protocol where you sign a {comment, command} tuple, each a string. If the protocol computes the hash by just concating the command and comment and they're variable length fields, then you could get a signature of {"boring comment containing dangerous command", "boring command"} but then present it to someone as {"boring comment containing ","dangerous command boring command"} and have the signature pass. That sort of thing. This new vulnerability has a somewhat straight forward path to exploitation and prints funds out of thin air. Based on some of the public comments about nodes rejecting the attack transaction, I'm guessing they rolled out the "fix" to the federation in advance of publishing the changes because they seem to have accepted an attack that everyone else was still rejecting. Advanced private deployment of a 'fix' might have gave them the confidence to drop the fix on github with little fanfare as it was "already fixed", but doing so painted a target on the issue that remained. Interestingly, off the shelf open weight AI like Kimi K3 immediately identify the new vulnerability without any particularly artful prompting. Makes me wonder if "safe" AI played a role in the introduction of the new, more serious, vulnerability. Interestingly, it looks like the funds are being returned: https://mempool.space/tx/3a3eac4a26395b8c2563aaf1eb8b1b77798... I'm going to guess that anyone who actually knows more has their hands busy dealing with the return of the funds. I'm not sure if anyone has ever taken and then returned 1/3rd of a billion dollars worth of assets before.
rgbrgb
There’s kind of an interesting thread here about open source, which is usually thought of as more secure because of more eyes on the code, actually being less secure because an accidental merge can be exploited instantly with LLM’s monitoring. Is there a lot more security value in obscurity than before?