Zipped contracts
Compressed contracts that automatically self-extract when called
https://github.com/merklejerk/zipped-contracts

GasBad is an open-source project that evaluates gas efficiency in Solidity libraries
https://github.com/ciwines/gas-bad
@EthSecurity1

https://medium.com/@spearbit/numerical-analysis-tips-and-tricks-for-defi-audits-9965db8ac5de

https://blog.decurity.io/typical-vulnerabilities-in-lending-and-cdp-protocols-e778e540e215
@EthSecurity1

We reached to 1000 members thank you all.
Special thanks to officercia.eth who support me at first.

Hey team, I am working on https://web3sec.news which is an open source initiative for web3 security. It tracks of all latest hacks, news, events, roadmaps, challenges, blogs etc for the community as an aggregator. It would be very helpful if you can help me getting the community feedbacks & spreading the cause together 💪🏻🔥

Ethereum investigation tools. #osint Google Dorks
Blacklists
Storage Platforms
Explorers
Scoring
https://github.com/moonIighted/OSINT-MindMaps/blob/main/Ethereum%20Investigation.png
Transaction monitoring @Ethsecurity1

Auditing resources part 3:
Immunify Forge POC
EVM Security ReposPractice Secureum Races
Web3 Security DAO
Tomo Labo Bugs - Medium | High
Auditor Roadmap by Razzor
All things Reentrancy
Checks while Hacks
rareskills common vulners
@EthSecurity1

Here are some key auditing tips and insights :
1. Understand the System: Before starting the audit, it's important to understand the
system you're auditing. This includes understanding the high-level overview of the system, how it works, and what makes it unique. In the case of Asteria, understanding the roles of different players in the system, how vaults exist, how loans are represented, and how liquidations work was crucial.
2. Identify Complexities: Identify the complexities in the system. For example Asteria, the
complexities included calls going back and forth between contracts, the system being almost entirely stateless, and the need for accurate total assets of the vault.
3. Look for Vulnerabilities: Look for vulnerabilities in the system. In the case of Asteria, vulnerabilities were found in the delegate role, the stateless system, the Seaport auctions, and the ERC4626 calculations.
4. Learn from Mistakes: Learn from the mistakes made in the system. For Asteria, mistakes were made in not using EC recover properly, having a lot of data inputted, having many different entry points using shared back-end logic, and not resetting variables when changing hands.
5. Implement Fixes: Implement fixes for the vulnerabilities found. For Asteria, fixes included adding checks, getting rid of certain functions, adding unchecked blocks, and changing the way the Seaport liquidations work.
6. Test Thoroughly: Ensure thorough testing is done to cover all edge cases. In the case of Asteria, while they had done the hard parts of testing, they could have done more thorough testing to ensure all edge cases were covered.
7. Rebuild if Necessary: If the product has evolved a lot and more features have been added, it might be beneficial to rebuild or rethink the system from first principles. This
can help ensure that all functionalities are encoded in shared logic and that all validations are rock solid.
8. Stay Updated: Stay updated with the latest vulnerabilities and fixes in the blockchain and smart contract space. This can help you identify potential vulnerabilities in the system you're auditing.
Remember, auditing is a complex process that requires a deep understanding of the system, a keen eye for detail, and a thorough approach to testing. @EthSecurity1

On May 28, @jimbosprotocol
fell victim to a significant flash loan attack, resulting in a staggering loss of $7.5M.

In this article we offer a concise analysis, unveiling key details and implications of this incident. https://medium.com/@auditone.io/the-7-5-million-flash-loan-unveiled-analyzing-jimbos-protocol-attack-25cf7fd55079 @EthSecurity1

The math behind Defi is not as hard as you think
https://cryptocutie.medium.com/the-math-behind-defi-is-not-as-hard-as-you-think-60e1ba39ee2a
Immunefi bug bounty writeups list
https://github.com/sayan011/Immunefi-bug-bounty-writeups-list
Huff vs Yul for EVM Smart Contracts
https://medium.com/@jtriley15/huff-vs-yul-for-evm-smart-contracts-620d1d618197
@EthSecurity1

Compound v2 visualisation

https://betterprogramming.pub/compound-v2-in-depth-6227c0528b5?gi=4e5180ce876b
@EthSecurity1

Signed signature always should have an expiration.

The expiration ensures that the signature becomes invalid once the specified time has passed. @EthSecurity1

GM!

Today, we will try to understand what a bug bounty is, why it’s important, and why it can complement auditing rather than replace it in order to increase security!

• officercia.medium.com/web3-security-distilled-9ff4b2f778c5

Please share 🫡️️️️️️

#security #bugbounty #web3

Cool idea 💡 Tornado v2 🧵
https://twitter.com/bi_gly/status/1667094239132655618?s=21
@EthSecurity1

If you watched patrick's hardhat edition course either foundry edition you will found only thing has diffred is👇

how good question

I recommend to everybody who intend to watch foundry edition

swallow this repo instead watch it:)) https://github.com/selfteaching/How-To-Ask-Questions-The-Smart-Way

@EthSecurity1

Fully repaying a loan will result in debt payment being lost.When a loan is fully repaid the loan storage is deleted. Since loan is a storage reference to the loan, loan.lender will return address(0) after the loan has been deleted. This will result in the debt being transferred to address(0) instead of the lender. Some ERC20 tokens will revert when being sent to address(0) but a large number will simply be sent there and lost forever.In Cooler#repay the loan storage associated with the loanID being repaid is deleted. loan is a storage reference so when loans[loanID] is deleted so is loan. The result is that loan.lender is now address(0) and the loan payment will be sent there instead.

Recommendation:
Send collateral/debt then delete:

- if (repaid == loan.amount) delete loans[loanID];
+ if (repaid == loan.amount) {
+ debt.transferFrom(msg.sender, loan.lender, loan.amount);
+ collateral.transfer(owner, loan.collateral);
+ delete loans[loanID];
+ return;
+ }
@EthSecurity1

Some pitfalls of handling signatures in smart contracts:

1. Using ecrecover and not checking if it returned address(0) (invalid signature)
2. Signature malleability
a) by using EIP2098 (compact signature)
b) by flipping s & v (documented in EIP2, but ecrecover won't revert) @EthSecurity1

1-Pick the right audit
2-Get a intuitive feel of protocol
3-Whiteboard key workflow
4-Identify focus areas
5-Line-by-Line code review
6-Review current test cases
7-Write POCs
8-Riview finding
@EthSecurity1

Gas Griefing Attack
Imagine you have a smart contract that uses the require statement to perform a call to another contract using the to.call function. You want to make sure that the callee contract receives a specific amount of gas that you specify.
However, there are two reasons why the require call alone cannot guarantee this:
-Gas required for the call itself: When you make the call, the gas required for the call's operations and memory usage will further reduce the available gas. This means that the actual gas available at the moment of the call will be lower than what you initially expected.
-The 63/64 rule: Even if the gas available at the point of the call seems sufficient, the Ethereum protocol applies the 63/64 rule. This rule reduces the available gas even more, potentially affecting the amount of gas the callee contract receives. The remaining gas (1/64 of the gas required) can still be enough for the rest of the transaction to succeed, allowing the call to continue. @EthSecurity1

Liquidations are enabled when repayments are disabled, causing borrowers to lose funds without a chance to repay

Summary:

Debt repaying can be temporary disabled by the admin of BlueBerryBank, however liquidations are not disabled during this period. As a result, users' positions can accumulate more borrow interest, go above the liquidation threshold, and be liquidated, while users aren't able to repay the debts.
Vulnerability Detail:

The owner of BlueBerryBank can disable different functions of the contract, including repayments. However, while repayments are disabled liquidations are still allowed. As a result, when repayments are disabled, liquidator can liquidate any position, and borrowers won't be able to protect against that by repaying their debts. Thus, borrowers will be forced to lose their collateral.

Impact:

Positions will be forced to liquidations while their owners won't be able to repay debts to avoid liquidations @EthSecurity1

I created web3 privacy channel
@web3privacy1