🔴Many security vulnerabilities come from faulty assumptions

Identifying the assumptions made by the devs and evaluating if they are correct can uncover big discrepancies between what the code does vs what it is intended to do

Here are examples of common faulty assumptions: 📔

1. Initialization functions will only be called ONCE and/or can be called only by the contract deployer

2. Only admins can call certain functions(access control issues)

3. Functions will always be called in a certain order as expected by the system

Ex. what if there's a function that closes a position but expects that you opened one in the 1st place?

A function that checks if your payment is on time but expects you got a loan before that?

4. Parameters can only have non-zero values or values within a certain threshold

addresses will never be zero-valued
sender will always be different from the receiver
an element of a struct array will always exist so the values won't be the default ones

5. Certain addresses or data values can never be attacker-controlled

6. Function calls will always be successful and so checking for return values is not required
These are just a few examples of common assumptions that don't always hold true
Always try to identify what assumptions are made when writing the code and compare that to how the system could actually behave
@EthSecurity1

nonReentrant modifiers might potentially cause a DoS attack.
https://medium.com/@bloqarl/uncovering-real-life-examples-of-denial-of-service-attacks-on-smart-contracts-8bc220c2cdd0
@EthSecurity1

This paper presents a dynamic, real-time approach to detecting anomalous blockchain transactions.

https://arxiv.org/abs/2304.12749
@EthSecurity1

A number of Comp forks have been hacked, chiefly Hundred Finance

compoundfinance
V2 forks, satisfying conditions, e.g., cToken.totalSupply == 0, can be drained @EthSecurity1

the person who stole 20m from sandwitch bots by unbundling sandwiches reported another bug that would allow the same attack again, in exchange of being called "low-carb-crusader" https://collective.flashbots.net/t/disclosure-mitigation-of-block-equivocation-strategy-with-early-getpayload-calls-for-proposers/1705 @EthSecurity1

Detect real-time threats on your blockchain stack is more important these days and i want to go deeper. Comment me all thing you know about topic https://github.com/base-org/pessimism
@EthSecurity1

A Practical, AI-Generated Phishing PoC with ChatGPT

https://curtbraz.medium.com/a-practical-ai-generated-phishing-poc-f81d3c3da76b
@EthSecurity1

Good web3sec checklist behind these
https://gist.github.com/CloudEllie/213965a3448230f5b615e7046f9dd26d

https://news.1rj.ru/str/EthSecurity1/403
https://news.1rj.ru/str/EthSecurity1/421
@EthSecurity1

Web3 Dev
1)How do you construct a lending protocol that supports arbitrary collateral, has no oracles, and has no expirations?

Read the whitepaper to find out:
paradigm.xyz/2023/05/blend

2) Web3education.dev brought by patrick collins

@EthSecurity1

web3 security tips: 1)Some of the high/medium submitted issues in the last Sherlock contest was:

1. Access control
2. Input validation
3. Fee-on-transfer
2)4 ways for receiving unexpected Ethers

1. via payable functions
2. selfdestruct()
3. coinbase transaction
4. pre-sent before creation

Contract logic should not depend on this.balance because can be manipulated @EthSecurity1

If you see a Solidity method that has an argument of type array, always check for 3 things:

1. What if the array length is 0?
2. What if there are duplicated elements in the array?
3. What if there are zero value elements in the array?
@EthSecurity1

Seeing a potential re-entrancy exploit with the SteadyStackNFT contract.

Looks like anyone on the goldlist can re-use their signatures to mint as many NFTs as they want.

There's no supply check on this function so someone could mint out the remaining supply (limited by gas).@EthSecurity1

Seems he https://twitter.com/jaredfromsubeth earned 1m in one month through mevbot:) @EthSecurity1

coinbase.transfer()
Flashbots allows you to pay validators for your transactions through a smart contract by using block.coinbase.transfer(AMOUNT_TO_TRANSFER). This smart contract function transfers Ethereum from the contract to the address of the validator who proposes a block. The Flashbots builder will treat fees through coinbase transfers in the same way they do normal transaction fees, which is to say that 1 wei of coinbase payments is equivalent to 1 wei paid through transaction fees. This provides significant benefits to Flashbots users:

You can condition payment to the validator on some criteria being met
Related, you can only pay for successful transactions, not failures
You can pay for a transaction from account X with ETH from account Y (see: searcher sponsored transaction repo here)
Here's an example from our open source simple arbitrage bot of how paying through coinbase transfers work:

function uniswapWeth(uint256 _wethAmountToFirstMarket, uint256 _ethAmountToCoinbase, address[] memory _targets, bytes[] memory _payloads) external onlyExecutor payable {
require (_targets.length == _payloads.length);
uint256 _wethBalanceBefore = WETH.balanceOf(address(this));
WETH.transfer(_targets[0], _wethAmountToFirstMarket);
for (uint256 i = 0; i < _targets.length; i++) {
(bool _success, bytes memory _response) = _targets[i].call(_payloads[i]);
require(_success); _response;
}

uint256 _wethBalanceAfter = WETH.balanceOf(address(this));
require(_wethBalanceAfter > _wethBalanceBefore + _ethAmountToCoinbase);
if (_ethAmountToCoinbase == 0) return;

uint256 _ethBalance = address(this).balance;
if (_ethBalance < _ethAmountToCoinbase) {
WETH.withdraw(_ethAmountToCoinbase - _ethBalance);
}
block.coinbase.transfer(_ethAmountToCoinbase);
}


The above smart contract code will attempt to capitalize on arbitrage opportunities. If it does not make money doing so then the transaction will fail.

For more information on how coinbase transfers are priced see the bundle pricing page.

Managing payments to coinbase.address when it is a contract
Validators will occasionally have a smart contract listed as their block.coinbase address. This changes the expected behavior of making payments to block.coinbase. Specifically it costs more gas to transfer ETH to block.coinbase if it is a contract than if it is an EOA, and as such many searchers will underestimate their gas consumption and their bundles will fail for validators who use contracts instead.

To handle this edge case searchers can up their gas limit to accomodate the additional payment to validators and call block.coinbase in the following way:

block.coinbase.call{value: _ethAmountToCoinbase}(new bytes(0));

However, searchers should be acutely aware of the risk of reentrancy attacks, as calling coinbase in this way temporarily gives execution to a third party, and typically payments to coinbase are made after checks for profit. Moreover, searchers should be aware that supporting payments to coinbase addresses that are contracts will cause their gas consumption to go up, and as a result their bundle gas price to go down. This is a tradeoff that should be considered.@EthSecurity1

Here’s another video on this ZK learning journey. This time around focusing on common ZK vulnerabilities found within Circom and similar ZK domain specific languages.

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

@EthSecurity1

Reentrancy

Smash topic and go further
Cia Officer wrote this article and put few link to go deepr:

-Single function reentrancy
-Cross-contract reentrancy
-Cross-chain reentrancy
-Cross-function reentrancy
-Readonly reentrancy
https://blog.pessimistic.io/reentrancy-attacks-on-smart-contracts-distilled-7fed3b04f4b6
@EthSecurity1

Great challenge https://cryptohack.org/courses/
@Ethsecurity1

High finding from recent BlueBerry Update 1 contest: swap with no slippage & no deadline. Exposes the user to potential total loss of funds.

Combination of "No Slippage Parameter" & "No Expiration Deadline" from my Slippage Deep Dive https://dacian.me/defi-slippage-attacks @EthSecurity1