kadenzipfel/smart-contract-vulnerabilities

A collection of smart contract vulnerabilities along with prevention methods

Smart Contract Vulnerabilities

• Insufficient Gas Griefing
• Reentrancy
• Integer Overflow and Underflow
• Timestamp Dependence
• Authorization Through tx.origin
• Floating Pragma
• Outdated Compiler Version
• Unsafe Low-Level Call
• Uninitialized Storage Pointer
• Assert Violation
• Use of Deprecated Functions
• Delegatecall to Untrusted Callee
• Signature Malleability
• Incorrect Constructor Name
• Shadowing State Variables
• Weak Sources of Randomness from Chain Attributes
• Missing Protection against Signature Replay Attacks
• Requirement Validation
• Write to Arbitrary Storage Location
• Incorrect Inheritance Order
• Presence of Unused Variables
• Unencrypted Private Data On-Chain
• Inadherence to Standards
• Asserting Contract from Code Size
• Transaction-Ordering Dependence
• DoS with Block Gas Limit
• DoS with (Unexpected) revert
• Unexpected ecrecover null address
• Default Visibility
• Insufficient Access Control
• Off-By-One
• Lack of Precision

Contributions

Submit a PR!

smart-contract-vulnerabilities's Issues

Generalize repo to smart contract security

Instead of just having attack vectors, lets put those in a folder and include other folders for security considerations.

Folders can include:

• Known attacks
• Best practices
• Historical attacks

Update or remove 'further reading'

Most of the resources are either out of data or defunct

Broken link in unchecked-call-return-value.md

Broken link in unchecked-call-return-value.md

https://consensys.github.io/smart-contract-best-practices/recommendations/#handle-errors-in-external-calls

Faulty Contract Detection

Some contracts do not want other contracts to interact with them (very common in gambling contracts using sub-par RNG).

A common way to prevent this is to check whether the calling account has any code stored in it, however contract accounts initiating calls during their construction will not yet show that they store code.

An example of this is the FOMO3D bug.

Merge attacks and vulnerabilities together

There isn't a clear line between attacks and vulnerabilities, so we'll just place them all together in a folder titled attacks-and-vulnerabilities.

[Suggestion] Section for off-chain attacks

Some non-Solidity attacks such as honeypots, short address attack, mis-characterizing code using ascii tricks, making failed transactions appear successful on explorers, injections, unsafe/unreliable oracle sources, etc. may deserve their own section.

Oracle related vulns

• manipulation
• variation between oracle and true value
• down sequencer

Centralization risk

[Attack] Contract Replication?

Not sure what to call this but just the general idea of using a contract to take advantage of variables that will be known by the time the transaction hits the chain (e.g. taking advantage of on-chain randomization).

Pull over push payments

Let's include an explanation of this, and link to it whenever it is mentioned.

Setup CI to update doc book on pushes to main branch

[Further Reading]

https://solidity.readthedocs.io/en/v0.5.11/bugs.html

Fix sources so that they are listed

E.g.

• https://consensys.github.io/smart-contract-best-practices/recommendations/#multiple-inheritance-caution
• https://solidity.readthedocs.io/en/v0.4.25/contracts.html#multiple-inheritance-and-linearization
• https://pdaian.com/blog/solidity-anti-patterns-fun-with-inheritance-dag-abuse/

how to start

please create a blog how to start smart contract bug bounty.

Add examples for all attacks

A good chunk have examples already, but all of them should.

Unclogged Blockchain Reliance

Many contracts rely on calls happening within certain period of time, but Ethereum can be spammed with very high Gwei transactions for a decent amount of time relatively cheaply.

For example, FOMO3D (a countdown game where the last investor wins the jackpot, but each investment adds time to the countdown) was won by a user who completely clogged the blockchain for a small period of time, disallowing others from investing until the timer ran out and he won.

There are many "croupier" gambling contracts nowadays that rely on past blockhashes to provide RNG. This is not a terrible source of RNG for the most part, and they even account for the pruning of hashes that happens after 256 blocks, but at that point many of them simply null the bet. This would allow someone to make bets on many of these similarly-functioning contracts with a certain result as the winner for them all, check the croupier's submission while it's still pending, and, if it's unfavorable, simply clog the blockchain until pruning occurs and you can get your bets returned.

Vulnerabilities related to chain reorgs

e.g. https://solodit.xyz/issues/12279

Honeypot Attacks

A few listed in here:

https://medium.com/coinmonks/the-phenomena-of-smart-contract-honeypots-755c1f943f7b

Unencrypted Secrets

Ethereum smart contract code can always be read. Treat it as such. Even if your code is not verified on Etherscan, attackers can still decompile or even just check transactions to and from it to analyze it.

One example of a problem here would be having a "guessing game" where the user has to guess a stored private variable to win the Ether in the contract. This is, of course, extremely trivial to exploit (to the point that you shouldn't try it because it's almost certainly a honeypot contract that's much trickier).

Another common problem here is using unencrypted off-chain secrets, such as API keys, with Oracle calls. If your API key can be determined, malicious actors can either simply use it for themselves, or take advantage of other vectors such as exhausting your allowed API calls and forcing the Oracle to return an error page which may or may not lead to problems depending on the structure of the contract.

Inadherence to Standards

An example of this would be Binance's "ERC20"

Separate attacks and vectors

"Forcibly Sending Ether" and "Unexpected Ether Balance" are both in the same list but it's an example of a vulnerability and attack based on the same underlying functionality.

Note 0.8.0 built-in safemath

Include further reading list

Some great references here:
https://github.com/sigp/solidity-security-blog

[Attack/Vulnerability] Dependence on Gas Calculations

Not sure exactly what to call this but some contracts may have functionality such as rewarding the caller for the amount of gas they spend. This would typically take the form of recording gasleft() at the beginning of the function and gasleft() at the end of the function, although if there are calls in-between where the attacker could call their own contract, they have the ability to spend a lot of gas on a fodder contract by deleting, have the full amount spent on deletes rewarded to them, but only end up paying a partial amount of gas.

Note backrunning & sandwich attacks in transaction ordering dependence