👮
Contract Cops
  • Mastering Ethereum Book
    • What is ethereum?
    • Tokens
    • Oracles
    • Decenralized Applications(DApps)
    • The Ethereum virtual machine
    • Ethereum basics
    • Ethereum clients
    • Cryptography
    • Wallets
    • Transactions
    • Chapter 7 - Smart Contracts & Solidity
    • Side Notes
      • Tokens
      • Smart Contracts and Solidity
  • Cryptography
    • Ethereum Cryptography - Cheatsheet
    • Assymetric vs symmetric cryptography
    • ECDSA vs RSA
    • Elliptic curves and ECDSA
    • Sha-256 Example
    • Sha-256
    • What are the different steps in SHA-256?
  • Ethereum Blocks
    • Block Headers
  • Learning Solidity
    • Storage vs memory
    • Upgradeable contracts
      • Proxy pattern in smart contracts
  • PoS
    • Proof of stake
  • PoW
    • PoW
  • Tokens
    • ERC-1155
    • ERC20
  • Cryptonomics
    • Automated market makers
    • Collateral Tokens
    • Collateralized Stablecoin
    • Fiat currency
    • Liquidity pool
    • Open Position: Meaning and Risk in Trading
    • Slippage
    • Spot price
  • Common Attack Vectors
    • Checking access control
    • Access control issues on critical functions
    • Account Existence Check for low level calls
    • Account Existence Check
    • Common attacks with contract/EOA addresses
    • Arithmetic under/overflow
    • Assert Attack
    • Assert require revert
    • Assert Violation
    • Bad Interface DOS
    • Bad pragma and compiler
    • Block Timestamp Manipulation
    • Bypassing contract check
    • Code With No Effects
    • Code size check vulnerability
    • Constructors with Care
    • Default Visibilities
    • Delegatecall
    • Delegatecall
    • Denial of Service (DoS)
    • DoS with block gas limit
    • Entropy Illusion
    • External contract referencing
    • Flash Loan Attack
    • Floating Point and Precision
    • Function selector abuse
    • Function selector abuse
    • Smart contract gas griefing
    • Hash collision parameters
    • Hash Collisions With Multiple Variable Length Arguments
    • Imprecise arithmetic
    • Improper Array Deletion
    • Incorrect array deletion
    • Incorrect interface
    • Insufficient Gas Griefing
    • Loop through long arrays
    • Message call with hardcoded gas amount
    • Not enough gas for ether transfer
    • Precision Loss in Calculations
    • Oracle Manipulation
    • Public Burn Function
    • Read-only reentrancy
    • Race Conditions/Front Running
    • Reentrancy Attacks
    • Reentrancy
    • Requirement Violation
    • Right-To-Left-Override control character (U+202E)
    • Shadowing State Variables
    • Short Address / Parameter attack
    • Signature Malleability
    • Signature Replay
    • Transaction Order Dependence
    • Tx.Origin Authentication
    • Unchecked CALL Return Values
    • Unexpected ether
    • Uninitialized Storage Pointers
    • Unsafe Ownership Transfer
  • EIP's
    • EIP155
    • EIP55
  • PoW
    • Ethash
    • Scrypt - RFC 7914
  • Questions for self evaluation
    • Questions 23/04/2023 (Nr: 84)
    • Usability guide for questions
  • Frequently asked questions
    • What is the difference between transaction and message?
    • What is the use of a interface or function without implementation?
  • UsefulResources
Powered by GitBook
On this page
  1. Common Attack Vectors

External contract referencing

PreviousEntropy IllusionNextFlash Loan Attack

Last updated 2 years ago

Ethereum is a global decentralized singleton computing machine. This means that on the network, there are millions of executable objects (smart contracts), many of which are well known and used by many other contracts. (take ERC20 implementations for example, SafeMath libraries, etc);

A lot of contracts reference and use other external contracts as a result. This can be problematic, as malicious code can be masked easily by attackers.

In Solidity, any address can be casted as a contract. This means that a user might look like he's referencing one contract, but under the hood masking malicious functionality.

The following example shows this clearly:

On a first glance, this looks like a normal contract that uses the EncodeHelper to return the abi encoded bytes32 of a string.

Taking a closer look at the constructor of the Encoding contract, however, we see that the contract can mask malicious code.

Because of how Solidity and the EVM work, any address is a valid address to a contract. This is not checked anywhere/stored on the blockchain.

This means that the EncodeHelper, referenced in the Encoding contract doesn't have to necessarily point to the above defined EncodeHelper contract. This is especially apparent when we look that the deployer of the Encoding contract can easily pass a different address to a contract that has the same function definitions as the above EncodeHelper.

To demonstrate this better, we can define the following exploit contract that the user can mask.

As we can see, the EncodeStr is practically the same definition here, but emits an event with the secret alongside with it.

Preventative measuresWhen referencing external contracts, you should try to use the "new" keyword whenever possible. This way, by deploying one contract, you ensure that the contract that is being deployed doesn't mask any hidden functionality.Another way is to make the address of the contract that's being referenced within a constant state variable and use that to create the reference to the external contract.

1680362687312
1680363266724