🚨 The 5th episode of Web3 Security Clan Podcast is live!
This episode dives into “How to Break Into ZK” with @marcobesier from @zksecurityXYZ Exploring the ZK landscape, opportunities, and how to get started.
Youtube: https://t.co/CG67B1CsQM
Spotify: https://t.co/csvApdPY8N
@luhelminger Systems can verify a succinct proof that all of the signatures were verified correctly.
Of this, I think most heavily used cryptographic protocols will eventually rely on ZK to efficiently deploy PQ cryptography at scale.
You can already see that in Google and Ethereum Roadmap
@luhelminger Many PQ alternatives, such as hash-based signatures, are much larger and lack algebraic structure, making efficient verification at scale significantly more challenging
This is where verifiable computation becomes important. Instead of verifying every large PQ signature directly
I remember when I was getting started in ZK, I was told that a lot of companies were looking for ZK engineers/researchers.
Where are those companies now ??
@luhelminger Based on my search, I wasn’t able to find many companies.
However, I’d really appreciate it if you could share any that are currently hiring, as I may have missed some.
On 11th of July Bonzo Lend (@bonzo_finance) got hacked for 9M
The attacker deposited 3$ of collateral and walked out with $9M, without forging a single signature.
Here is how 🧵
1⃣ Project summary
Bonzo Lend is Hedera's (@hedera) largest lender. It reads asset prices from Supra's oracle. Every price Supra writes on-chain is supposed to carry a valid BLS signature from its committee, and the feed contract verifies that signature before storing the price. That check is the only thing standing between "a price" and "the price".
2⃣ The bug
Wallet A submitted a price update where the BLS signature field was [0,0]. A zeroed signature. No real committee ever signs a zero.
To verify a BLS signature you run a pairing check, roughly `e(signature, G) == e(H(message), pubkey)`. Supra's verifier built that check and handed it to Hedera's alt_bn128 pairing precompile (system contract 0.0.8).
The problem: both the submitted signature AND the referenced committee public key were the point at infinity (zero). Pair anything with the identity and you get the identity back, so the equation held trivially and the precompile returned 1 (true).
Under EIP-197 that is the correct answer for that input. The precompile did its job. The verifier did not.
3⃣ The attack path
1. Deposit 250 SAUCE (worth ~$3) into Bonzo Lend as collateral.
2. Push a price update to Supra's pull oracle with a [0,0] signature. The raw price field was 1 followed by 30 zeros, roughly 12 orders of magnitude above SAUCE's real ~0.2 HBAR.
3. The verifier accepts the blank signature and the fake price is written on-chain.
4. 8 seconds later, borrow against the now absurdly valuable collateral:
- 6,634,528.20 USDC
- 34,518,389.36 WHBAR
~$9.05M total.
5. Swap the loot into WETH and WBTC and bridge ~$5.25M to Ethereum via LayerZero (per PeckShield: ~2.36K ETH and ~15.58 WBTC).
No flash loan. None needed. Write the price in one tx, borrow against it in the next.
I have dove into @CantonNetwork and Daml development and security in the past few months. I thought it was time to start getting more hands on. My first real project with Daml - Lendaml! A lending-borrowing protocol built entirely with the Canton tech stack.
This is different from other lending protocols with the fact that privacy is reserved at all times, there are operators that match lenders and borrowers (as observers - they never have custody of the funds).
If anyone is interested please take a look I would love feedback.
https://t.co/rqE50xFkW5
Restricting AI in cybersecurity is not just preventing models from finding vulnerabilities.
Malicious actors use AI to understand a codebase faster, map its attack surface, trace complex data flows, test hypotheses etc....
And you wouldn't even know that's a cybersecurity use.
Of all the cryptography and ZK resources I’ve gone through, @RareSkills_io and @danboneh stand out as the most organized and clearly explained.
By the end, you don’t just understand the details, you walk away with a clear mental model and a solid vision of the topic.
That's the hard part.
There's a reason why almost anyone can solve "find-the-bug" challenges, but very few people can find live vulnerabilities in the wild.
CTFs have bounded domains and usually one clear, proven solution. Live exploits, on the other hand, are unbounded -- we don’t know where they are, or even if they exist at all.
That said, there are hot zones in codebases -- areas where developers are more likely to make mistakes.
There are also danger zones -- places where even a small error would be fatal.
Once you’ve worked with many similar codebases, languages, patterns, and technologies, you start to see those hot spots instinctively.
Hunting is like reading a heatmap.