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.