D-Squared@discord: Hey folks - Here’s another video on this ZK learning journey. This time around we’re focusing on common ZK vulnerabilities found within Circom and similar ZK domain specific languages.

Here’s the video walkthrough - https://youtu.be/1RQSwj8h8rM

Additionally, I send out a weekly email newsletter relating to crypto security if you’re interested, subscribe here - http://eepurl.com/gLhH9r

P.S. Also, if there are other communities you think would be interested in explainer series like this, feel free to share.

The Interest Protocol token sale contract has a bug that allows admins to take all IPT tokens before purchasers can claim them.

The admin withdraw() method does not check if it has already been called - withdraw() can be called repeatedly to drain the entire contract of IPT.

Some Users were attacked recently, scammers used a tiny camera, mended in a sunglasses (they were able to see the seed phrase over the shoulder).

recover Platypus stolen funds.

Date: 17/02/23
Blockchain: ETH

Problem: Exploiter contract is missing withdraw function, access control.

The Platypus hack is a very interesting event in the DeFi history, first of all that is because the hacker was found after some on-chain investigation because of using ENS. The second reason is because a part of funds were frozen on the attacker contract because of the mistake during the exploit.

The Platypus:
1) Updated contracts.
2) Called flash loan callback function on attacker contract, which approves hacker funds on the contract to the Platypus.
3) Transfer funds from the hacker.

Discoverer: BlockSec.
Recovered: 2.4 M $
link

Guys do you want to be more engage with smart contract security in private group? If yes leave a comment

🧐 Multisig exploiter is laundering fund through eXch.

eXch is a non-KYC exchange

Using chatGPT to understand smartcontract in breif:
https://chrome.google.com/webstore/detail/blockfence/cpgbcelefhmacblaocimfilfnchkghba

Bridge risk framework


🔴Bridge types:

📍Native bridges:
user move asset from base chain to other chain

📍General bridges: liquidity providers

🔴Bridge participants:

📍Bridge users
📍Passive liquidity provider
📍Message Relayer

🔴Attack surface Area
📍smart contract vulnerabilities
📍Compromised signer keys
📍Reorgs
📍Malicious RPCs or node vulnerabilities
📍Challenge windows/censorship attacks

Formal verification for fun and profit
https://youtube.com/playlist?list=PLKtu7wuOMP9XHbjAevkw2nL29YMubqEFj

Formal verification of WETH
https://www.zellic.io/blog/formal-verification-weth

Verify emails with the same trust assumption as the email domain i.e. without trusting our server (because it doesnt exist)
dev.zkemail.xyz

Learn to be not idiot:) http://blockworksresearch.com/research/we-do-a-little-counter-exploit

🔴High severity
“The use of setYieldSource leaves the contract in a temporary inconsistent state because it changes the underlying yield source, but doesn’t (yet) transfer the underlying balances, while the shares stay the same.

The function balanceOfToken will show the wrong results, because it is based on _sharesToToken, which uses yieldSource.balanceOfToken(address(this)), that isn’t updated yet.

More importantly supplyTokenTo will give the wrong amount of shares back: First it supplies tokens to the yieldsource. Then is calls _mintShares, which calls _tokenToShares, which calculates the shares, using yieldSource.balanceOfToken(address(this)) This yieldSource.balanceOfToken(address(this)) only contains the just supplied tokens, but doesn’t include the tokens from the previous YieldSource. So the wrong amount of shares is given back to the user; they will be given more shares than appropriate which means”

“they can drain funds later on (once transferFunds has been done).

@securlydevv