EthSecurity
1)If you deploy an empty Solidity contract, what bytecode will be present on the blockchain, if any? If you deploy an empty Solidity contract with no functions or variables defined, the bytecode that will be deployed to the blockchain will be: 608060405β¦
when reviewed Balancer pools critical issues found out everything was free for traders. linear pools ratio was 1:1 + no fees ;( audit giants reviewed it before @EthSecurity1
π3
new patrick collins github course for first runners https://github.com/Cyfrin/security-and-auditing-full-course-s23 @EthSecurity1
GitHub
GitHub - Cyfrin/security-and-auditing-full-course-s23: The ultimate, most advanced, security, DeFi, assembly, web3 auditor courseβ¦
The ultimate, most advanced, security, DeFi, assembly, web3 auditor course ever created. - GitHub - Cyfrin/security-and-auditing-full-course-s23: The ultimate, most advanced, security, DeFi, assem...
π4β€2β‘1
β Error: uint160(uint160 a * uint56 b)
Intermediate result of a * b can overflow uint160
When performing arithmetic operations on uint data types in Solidity, the result takes on the smallest uint type that can hold the result without overflowing.
a is of type uint160
b is of type uint56
Multiplying two uint values performs unchecked arithmetic
So when we multiply a * b:
The result could potentially be up to 160 + 56 = 216 bits wide.
β Fix: uint160(uint256(uint160 a) * uint56 b)
Cast to uint256 first then multiply @EthSecurity1
Intermediate result of a * b can overflow uint160
When performing arithmetic operations on uint data types in Solidity, the result takes on the smallest uint type that can hold the result without overflowing.
a is of type uint160
b is of type uint56
Multiplying two uint values performs unchecked arithmetic
So when we multiply a * b:
The result could potentially be up to 160 + 56 = 216 bits wide.
β Fix: uint160(uint256(uint160 a) * uint56 b)
Cast to uint256 first then multiply @EthSecurity1
β€4
A Deep Dive into 1inch Fusion
x.com/officer_cia/status/1721201204573733305
Defi Dao gevernanc defi attacks
https://dacian.me/dao-governance-defi-attacks
layerzero vulnerability
https://medium.com/@Heuss/layerzeros-cross-chain-messaging-vulnerability-e5ef48c5ccec
Collected 26 unobvious tips for yβall fam. FYI
http://github.com/OffcierCia/tips-solidity-code-auditors
@Ethsecurity1
x.com/officer_cia/status/1721201204573733305
Defi Dao gevernanc defi attacks
https://dacian.me/dao-governance-defi-attacks
layerzero vulnerability
https://medium.com/@Heuss/layerzeros-cross-chain-messaging-vulnerability-e5ef48c5ccec
Collected 26 unobvious tips for yβall fam. FYI
http://github.com/OffcierCia/tips-solidity-code-auditors
@Ethsecurity1
in your storage
DAO Governance DeFi Attacks
On-chain DAO Governance protocols create a large attack surface for creative exploitation..
π4β€2π₯1
TLDR: Attacker can break neutrality guarantees of Chainlink's VRF (verifiable random function). Chainlink confirmed CRITICAL severity and paid us $300K for the finding!π
From the Chainlink blog: "malicious VRF subscription
Link to blog: https://blog.chain.link/smart-contract-research-case-study/
β¦
@EthSecurity1
From the Chainlink blog: "malicious VRF subscription
Link to blog: https://blog.chain.link/smart-contract-research-case-study/
β¦
@EthSecurity1
Chainlink Blog
Supporting the Smart Contract Vulnerability Research Community | Chainlink Blog
Understand the importance of smart contract vulnerability research for a secure and sustainable Web3 economy.
π₯11
In this clip, ArthurB
points out that Optimism has not implemented fraud proofs at all https://twitter.com/Justin_Bons/status/1726395238749450722 @EthSecurity1
points out that Optimism has not implemented fraud proofs at all https://twitter.com/Justin_Bons/status/1726395238749450722 @EthSecurity1
https://blog.openzeppelin.com/15-billion-rugpull-vulnerability-in-convex-finance-protocol-uncovered-and-resolved @EthSecurity1
Openzeppelin
$15Billion Rugpull Vuln. Uncovered and Resolved
Anonymous team at Convex Finance collaborates with OpenZeppelin to secure the DeFi protocol and community
π₯1π±1
Uniswap v4 Lethal Integration: Vulnerabilities in Hooks Due to Risky Interactions
https://phalcon.xyz/blog/lethal-integration-vulnerabilities-in-hooks-due-to-risky-interactions @EthSecurity1
https://phalcon.xyz/blog/lethal-integration-vulnerabilities-in-hooks-due-to-risky-interactions @EthSecurity1
BlockSec
A Platform to Monitor and Block Hacks - BlockSec Phalcon
Phalcon helps protocols, liquidity providers/traders, L1/L2 Chains, and exchanges detect attacks, get instant alerts, and take automatic actions.
Security Analysis of the Ethereum Fork Choice specification
https://youtu.be/AaoaokIwVWE
Security & Common Pitfalls Of Merkle Trees
https://youtu.be/OLdmqfsmOPY
Ethereum yellow paper
https://youtu.be/e84V1MxRlYs
@EthSecurity1
https://youtu.be/AaoaokIwVWE
Security & Common Pitfalls Of Merkle Trees
https://youtu.be/OLdmqfsmOPY
Ethereum yellow paper
https://youtu.be/e84V1MxRlYs
@EthSecurity1
YouTube
Security Analysis of the Ethereum Fork Choice specification
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
π₯2
π2
Forwarded from Kotya security (Vlad)
Hello everyone!
I have been actively working with @userw01 on the article lately. In the "Cracks in the Code: Understanding the Vulnerabilities of AMM Protocols" article, we dive deep into the key features of AMM protocols, explore the most popular protocol types, discuss common attack vectors with lots of examples, and provide tips for auditors.
Check out the article here: https://millietez.medium.com/cracks-in-the-code-understanding-the-vulnerabilities-of-amm-protocols-2f5b360e159e
https://mirror.xyz/millietez.eth/ixD3xe-Q7JQowYcIFmGKxkPae_C5tCN9kWn9jXUhnKk
Enjoy the read!
I have been actively working with @userw01 on the article lately. In the "Cracks in the Code: Understanding the Vulnerabilities of AMM Protocols" article, we dive deep into the key features of AMM protocols, explore the most popular protocol types, discuss common attack vectors with lots of examples, and provide tips for auditors.
Check out the article here: https://millietez.medium.com/cracks-in-the-code-understanding-the-vulnerabilities-of-amm-protocols-2f5b360e159e
https://mirror.xyz/millietez.eth/ixD3xe-Q7JQowYcIFmGKxkPae_C5tCN9kWn9jXUhnKk
Enjoy the read!
β€6π3
What is the use of the signextend opcode?SIGNEXTEND performs the necessary sign extension when working with two's complement encoded signed integers in EVM. This allows operations on the values to produce the expected results for both positive and negative numbers. when there are negative numbers in calldata it cost more gas because the minor encoding, checking, arithmetic and comparison differences for negative numbers are why they cost slightly more gas than equivalent positive values. The EVM optimizes for the common case of non-negatives. why an int256 variable that stores -1 look like in hex?-1 stored as an int256 in Ethereum would be represented by the full 256-bit hex value ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff.
In binary, -1 is 1111111111111111111111111111111111111111111111111111111111111111
Converting that binary value to hex, we get:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Why is it important to ECDSA sign a hash rather than an arbitrary bytes32? hashing first before signing provides critical security properties like preimage resistance, binding signatures to data, canonical encoding and data integrity that direct signing of arbitrary bytes lacks. It's an important step for ECDSA signatures to provide robust cryptographic protection.
@EthSecurity1
In binary, -1 is 1111111111111111111111111111111111111111111111111111111111111111
Converting that binary value to hex, we get:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Why is it important to ECDSA sign a hash rather than an arbitrary bytes32? hashing first before signing provides critical security properties like preimage resistance, binding signatures to data, canonical encoding and data integrity that direct signing of arbitrary bytes lacks. It's an important step for ECDSA signatures to provide robust cryptographic protection.
@EthSecurity1
β€3β‘1π1
Risks on CEXβs Confirmation Number on Arbitrum and Optimism https://medium.com/chainlight/patch-thursday-risks-on-cexs-confirmation-on-arbitrum-and-optimism-7ee25a1d58bf Post-Mortem Report: Sequencer Downtime and L1 Gas Pricing Issue
https://github.com/ArbitrumFoundation/docs/blob/50ee88b406e6e5f3866b32d147d05a6adb0ab50e/postmortems/15_Dec_2023.md MEV BOOK https://www.monoceros.com/insights/maximal-extractable-value-book
Mev & evolution of crypto exchange
https://archetype.mirror.xyz/DVJFtcEcdTqk4DxC3VX4McgyjfktXF05pCG1LFtB4-E @EthSecurity1
https://github.com/ArbitrumFoundation/docs/blob/50ee88b406e6e5f3866b32d147d05a6adb0ab50e/postmortems/15_Dec_2023.md MEV BOOK https://www.monoceros.com/insights/maximal-extractable-value-book
Mev & evolution of crypto exchange
https://archetype.mirror.xyz/DVJFtcEcdTqk4DxC3VX4McgyjfktXF05pCG1LFtB4-E @EthSecurity1
Medium
Exploring Finality Risks of Ethereum L2 From a CEX Perspective
In this article, we analyze how the transactions of Ethereum Layer 2 chains get finalized and observe the approaches of various CEXs.
β€4π1
Polynonce: A Tale of a Novel ECDSA Attack and Bitcoin Tears https://research.kudelskisecurity.com/2023/03/06/polynonce-a-tale-of-a-novel-ecdsa-attack-and-bitcoin-tears/ Encrypted mempools https://joncharbonneau.substack.com/p/encrypted-mempools @EthSecurity1
Kudelskisecurity
Polynonce: A Tale of a Novel ECDSA Attack and Bitcoin Tears - Kudelski Security Research Center
Mar 06, 2023 - Nils Amiet -
Halting the Solana Blockchain with Epsilon Stake https://tik-old.ee.ethz.ch/file/9d40dad802dd12d9ba1f1b7c1759920c/Solana___ICDCN_24.pdf
@EthSecurity1
@EthSecurity1
β‘1
what is domain separator?
The domain separator helps prevent signature reuse attacks in DeFi protocols by making signatures unique to a particular contract and message type. Here are some more details:
Without a domain separator, a signature could potentially be reused for different messages or contracts. This enables various attacks.
For example, a signature approving a small transfer amount could be reused to approve a large transfer on another contract.Or a signature meant for a benign callback could be reused to trigger funds transfers.
The domain separator binds a signature to a specific contract address and message type.
It is computed from the contract address, a salt value, and the message EIP-712 typehash.When generating a signature, the signer computes and includes the domain separator.When verifying a signature, the contract recomputes the expected domain separator.If the domain separators don't match, the signature is invalid for that context.
This prevents simply replaying a signature on another contract/message type.
Even a tiny change to the contract address, salt, or message typehash invalidates old signatures.
So attackers cannot trivially transfer or forge signatures between contexts.
some potential pitfalls:
Forgetting to specify the domain separator when verifying signatures. This would allow cross-contract/message replay attacks.
Using a constant/hardcoded domain separator value rather than computing it dynamically. This defeats the purpose of making it context-specific.
Not updating the salt value periodically. Over time, old signatures could potentially be replayed on contracts with the same address.
Computing the domain separator incorrectly, such as omitting important components like the contract address. This could again allow reuse across contexts.
Failing to sanitize or validate input values used in domain separator computation. These should not be attacker-controlled.
Setting domain separators on a per-function rather than per-contract basis. This doesn't fully isolate signatures to a single context.
Not accounting for potential metadata like chain/network ID in domain separators. Signatures may not be cross-chain compatible.
Not versioning the domain separator format or hashing algorithm over time. Old styles could be replayed.
Failing to specify expected calldata/function signature when relevant. Signatures for calls are less isolated.
Not regenerating domain separators when upgrading a contract implementation. Old contexts may be accessible.
β
Insufficient entropy or non-randomness in salt values, compromising uniqueness over time.@EthSecurity1
The domain separator helps prevent signature reuse attacks in DeFi protocols by making signatures unique to a particular contract and message type. Here are some more details:
Without a domain separator, a signature could potentially be reused for different messages or contracts. This enables various attacks.
For example, a signature approving a small transfer amount could be reused to approve a large transfer on another contract.Or a signature meant for a benign callback could be reused to trigger funds transfers.
The domain separator binds a signature to a specific contract address and message type.
It is computed from the contract address, a salt value, and the message EIP-712 typehash.When generating a signature, the signer computes and includes the domain separator.When verifying a signature, the contract recomputes the expected domain separator.If the domain separators don't match, the signature is invalid for that context.
This prevents simply replaying a signature on another contract/message type.
Even a tiny change to the contract address, salt, or message typehash invalidates old signatures.
So attackers cannot trivially transfer or forge signatures between contexts.
some potential pitfalls:
Forgetting to specify the domain separator when verifying signatures. This would allow cross-contract/message replay attacks.
Using a constant/hardcoded domain separator value rather than computing it dynamically. This defeats the purpose of making it context-specific.
Not updating the salt value periodically. Over time, old signatures could potentially be replayed on contracts with the same address.
Computing the domain separator incorrectly, such as omitting important components like the contract address. This could again allow reuse across contexts.
Failing to sanitize or validate input values used in domain separator computation. These should not be attacker-controlled.
Setting domain separators on a per-function rather than per-contract basis. This doesn't fully isolate signatures to a single context.
Not accounting for potential metadata like chain/network ID in domain separators. Signatures may not be cross-chain compatible.
Not versioning the domain separator format or hashing algorithm over time. Old styles could be replayed.
Failing to specify expected calldata/function signature when relevant. Signatures for calls are less isolated.
Not regenerating domain separators when upgrading a contract implementation. Old contexts may be accessible.
β
Insufficient entropy or non-randomness in salt values, compromising uniqueness over time.@EthSecurity1
π6β€3
New year start with new loss. Orbit Bridge ~81.5 m $
Happy new year
Happy new year
β‘8π₯5π’2π1
Twice hack 4.5 m$
https://www.theblock.co/post/270080/radiant-capital-reportedly-hacked-eth?utm_source=telegram1&utm_medium=social
@EthSrcurity1
https://www.theblock.co/post/270080/radiant-capital-reportedly-hacked-eth?utm_source=telegram1&utm_medium=social
@EthSrcurity1
The Block
Radiant Capital reportedly hacked for $4.5 million worth of ETH
Cross-chain lending protocol Radiant Capital was hacked for 1,900 ETH, blockchain security firm PeckShield reported on X today.
π₯2π1
EthSecurity
One common vulnerability with the ecrecover function in Solidity is malleability of signatures. ecrecover is used to recover the address that signed a message from an elliptic curve signature. However, signatures in crypto systems like Ethereum are malleable.β¦
ECRecover and Signature Verification in Ethereum https://coders-errand.com/ecrecover-signature-verification-ethereum/
This blog has great articles about cryptography and ZK
And sure watch this
Ethereum yellow paper
https://youtu.be/e84V1MxRlYs?si=ysB4c21fT9Ce024u
@EthSecurity1
This blog has great articles about cryptography and ZK
And sure watch this
Ethereum yellow paper
https://youtu.be/e84V1MxRlYs?si=ysB4c21fT9Ce024u
@EthSecurity1
Coder's Errand
ECRecover and Signature Verification in Ethereum β’ Coder's Errand
This post explains how Ethereum signatures differ from standard ECDSA signatures, and how to use ECRecover to verify them.
π₯2