ImmuneBytes
  • Home
  • SECURITY AUDIT
    • DApp Audit
    • DeFi Audit
    • Token Audit
    • Stablecoin Audit
    • NFT Audit
  • BLOCKCHAIN SECURITY
    • Celo Audit
    • Algorand Audit
    • Avalanche Audit
    • Ethereum Audit
    • Cardano Audit
    • Fantom Audit
    • Flow Audit
    • Polkadot Audit
    • Polygon Audit
    • Solana Audit
    • Aurora Audit
    • Tezos Audit
    • Near Audit
    • BSC Audit
  • Request Quote
  • Blog
  • Contact Us
Smart Contract Security

All you need to know about: External contract referencing

by ImmuneBytes January 21, 2021
January 21, 2021
External Contract referencing

Table of Contents

  • 1 What exactly is an External contract referencing?
  • 2 How to prevent External contract referencing?
  • 3 A real-world example: Re-entrancy Honey-pot

It’s Thursday! And that calls for a new part of All About Smart Contract Bugs & Security – A cakewalk series and that’s exactly what we are here for! External Contract Referencing is another weakness in a smart contract that is often overlooked by developers and can later become the reason for its downfall.

Do check out the other parts in the series wherein we discuss Tx.origin, Uninitialized Storage Parameters, Race conditions,, and many other bugs that have proven to weaken smart contracts.

What exactly is an External contract referencing?

The Ethereum “world computer” can reuse code and interact with contracts that are already deployed on the network. Resulting in a large number of contracts pointing to external contracts, usually via external message calls. These external message calls can mask malicious actors’ intentions in some plain ways which we will discuss in this blog.

The vulnerability explained

Let’s start by considering this piece of smart contract code which uses this code for encrypting another smart contract:

import “Rot13Encryption.sol”;

contract EncryptionContract {

    // library for encryption

    Rot13Encryption encryptionLibrary;

    // constructor – initialise the library

    constructor(Rot13Encryption _encryptionLibrary) {

        encryptionLibrary = _encryptionLibrary;

    }

    function encryptPrivateData(string privateInfo) {

        // potentially do some operations here

        encryptionLibrary.rot13Encrypt(privateInfo);

     }

 }

The problem with this contract is that the encryptionLibrary address is neither public nor constant. Thus the deployer of the contract can give an address in the constructor which points to this contract:

contract Print{

    event Print(string text);

    function rot13Encrypt(string text) public {

        emit Print(text);

    }

 }

Once the above code starts pointing to this, the encryptPrivateData() would simply produce an event which prints the unencrypted private data. If a linked contract doesn’t contain the function being called, the callback function will execute. 

For example, with line encryptionLibrary.rot13Encrypt(), if the contract specified by encryptionLibrary was:

contract Blank {

     event Print(string text);

     function () {

         emit Print(“Here”);

         //put malicious code here and it will run

     }

 }

Thus if users can alter contract libraries, they can in principle get users to unknowingly run arbitrary code.

Note: The Rot cypher is not a recommended encryption technique.

How to prevent External contract referencing?

There are several ways in which this vulnerability can be omitted.

One measure is to use the new keyword to create contracts. In the example above, the constructor could be written like:

constructor() {
encryptionLibrary = new Rot13Encryption();
}

Using this an instance of the referenced contract is created at the time of deployment and the deployer cannot replace the Rot13Encryption contract with anything else without modifying the smart contract.

Another solution can be to hard code any external contract addresses if they are known.

A real-world example: Re-entrancy Honey-pot

There have been many honey pots recently deployed on the mainnet. These contracts try to outsmart Ethereum attackers who try to exploit the contracts, but in turn, end up losing Ether to the contract they expect to exploit. 

One example employs the above attack by replacing an expected contract with a malicious one in the constructor. This Reddit post here by a user explains how they lost 1 Ether to this contract by trying to exploit the re-entrancy bug they expected to be present in the contract. 

This was a breakdown of External Contract Referencing and how it can be modified to someone’s malicious interests. We have given a complete analysis and preventive measures so you can avoid committing such a mistake. Although, getting a third-party audit is always a wise choice. Connect with our team to get your smart contract free of any such vulnerabilities and loopholes that can invite hackers to your doorstep.

Tune in next Thursday for Part-XIII of this series wherein we discuss High order byte clean storage.

Spread the love
external contract referencingsmart contract vulnerabilities
0 comment
0
FacebookTwitterPinterestEmail
previous post
next post

You may also like

Top 5 Security Tips to Consider While Writing...

December 12, 2022

How To Choose The Best Expert to Secure...

December 7, 2022

Top 10 Use Cases of Smart Contracts

December 2, 2022

Top 5 Programming Languages to Build Smart Contracts

November 29, 2022

Introduction to Supernova: An Explosive Vision of the...

November 3, 2021

What is a Bug Bounty and How is...

August 13, 2021

zkAudit: Celsius and Horizen’s Major Step Towards Preserving...

July 23, 2021

Got Your Smart Contract Audited? Here’s What To...

June 25, 2021

DDoS Attacks Explained: Why are cryptocurrencies being targeted?

February 18, 2021

High-order bytes in Solidity can clean up storage:...

January 28, 2021
  • BLOCKCHAIN SECURITY
    • Celo Audit
    • Algorand Audit
    • Avalanche Audit
    • Ethereum Audit
    • Cardano Audit
    • Fantom Audit
    • Flow Audit
    • Polkadot Audit
    • Polygon Audit
    • Solana Audit
    • Aurora Audit
    • Tezos Audit
    • Near Audit
    • BSC Audit
  • SECURITY AUDIT
    • DeFi Audit
    • DApp Audit
    • NFT Audit
    • Stablecoin Audit
    • Token Audit

Categories

  • Blockchain (65)
  • Crypto (32)
  • Cybersecurity (4)
  • DApp (2)
  • DeFi (11)
  • Metaverse (3)
  • NFT (2)
  • Penetration Testing (7)
  • Security Hacks (15)
  • Smart Contract Audit (22)
  • Smart Contract Audit Tools (4)
  • Smart Contract Security (23)
  • Smart Contract Vulnerabilities (5)
  • Uncategorized (12)
  • Wallet (4)

Join our community

  • TELEGRAM
  • TWIITER
  • DISCORD
  • GITHUB
  • INSTAGRAM
  • FACEBOOK
  • LINKEDIN
  • MEDIUM

Career

  • Join Us

Quick Links

  • About us
  • Blog

Discover

  • Portfolio
  • Reports
  • Pricing

Resources

  • Privacy Policy
  • Disclaimer
  • Help

© 2021 ImmuneBytes. All Rights Reserved.

ImmuneBytes
  • Home
  • SECURITY AUDIT
    • DApp Audit
    • DeFi Audit
    • Token Audit
    • Stablecoin Audit
    • NFT Audit
  • BLOCKCHAIN SECURITY
    • Celo Audit
    • Algorand Audit
    • Avalanche Audit
    • Ethereum Audit
    • Cardano Audit
    • Fantom Audit
    • Flow Audit
    • Polkadot Audit
    • Polygon Audit
    • Solana Audit
    • Aurora Audit
    • Tezos Audit
    • Near Audit
    • BSC Audit
  • Request Quote
  • Blog
  • Contact Us