Project: Harpie
Platform: Sherlock
Source, Code

Number: 35
Problem: Nonces not used in signed data
Severity: Medium

Vulnerability detail:
Nonces are not used in the signature checks. A nonce can prevent an old value from being used when a new value exists. Without one, two transactions submitted in one order, can appear in a block in a different order

Impact:
If a user is attacked, then tries to change the recipient address to a more secure address, initially chooses an insecure compromised one, but immediately notices the problem, then re-submits as a different, uncompromised address, a malicious miner can change the order of the transactions, so the insecure one is the one that ends up taking effect, letting the attacker transfer the funds

Recommendation:
Include a nonce in what is signed

Lead Senior Watson: Not an issue AFAIK, miners can't reorder txs unless they are signed with the same nonce. There would have to be some serious mis-use of this function by the recipient address, i.e. they would have to ask the server to sign for two different addresses and then broadcast the txs with the same nonce for this call. The proposed fix could probably be safely removed but doesn't hurt to keep it there.

Fix

#SHERLOCK #MEDIUM #REPORT #SIGNATURE #HARPIE

Project: Sentiment
Platform: Sherlock
Source, Code

Number: 36
Problem: A malicious early user/attacker can manipulate the LToken's pricePerShare to take an unfair share of future users' deposits
Severity: High

Vulnerability detail:
A well known attack vector for almost all shares based liquidity pool contracts, where an early user can manipulate the price per share and profit from late users' deposits because of the precision loss caused by the rather large value of price per share.

A malicious early user can deposit() with 1 wei of asset token as the first depositor of the LToken, and get 1 wei of shares. Then the attacker can send 10000e18 - 1 of asset tokens and inflate the price per share from 1.0000 to an extreme value of 1.0000e22 ( from (1 + 10000e18 - 1) / 1) .
As a result, the future user who deposits 19999e18 will only receive 1 wei (from 19999e18 * 1 / 10000e18) of shares token. They will immediately lose 9999e18 or half of their deposits if they redeem() right after the deposit().

Impact:
The attacker can profit from future users' deposits. While the late users will lose part of their funds to the attacker.

Recommendation:
Consider requiring a minimal amount of share tokens to be minted for the first minter, and send a port of the initial mints as a reserve to the DAO so that the pricePerShare can be more resistant to manipulation.

Fix

#SHERLOCK #HIGH #REPORT #SHARES #SENTIMENT

https://cointelegraph.com/news/how-to-avoid-front-runners-on-decentralized-crypto-exchanges

https://consensys.github.io/smart-contract-best-practices/attacks/frontrunning/


Optimal frontrunning attacks and how to stop them
https://youtu.be/BwkNQWM32y0

#EDUCATION

https://www.paradigm.xyz/2023/01/eth-rng

https://soliditydeveloper.com/prevrandao

@ethers_officer

🔴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

Are you familiar with the challenges borrowing and lending protocols face?
#web3sec #defi
Dive into:
- Illiquid liquidations
- Collateral Safeness
- The dangers of governance
- Oracle risk and cost of manipulation

https://tokeninsight.com/en/research/market-analysis/the-7-deadly-sins-of-lending-protocols
@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

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