The objective of this blog post is to provide a comprehensive understanding of the block timestamp, and how they can be used to perform an attack on a DeFi project. We will define the term and elaborate on its workings, examining its potential consequences for the blockchain ecosystem. This is an addition to the series from our earlier blog, where we shared the details of Solidity Integer Overflow and Underflow, and Front Running Attack.
Introduction#
At times, smart contract developers tend to use time-specific actions to execute some logic in the contract. As a result, they rely on the timestamp generated by the node running the smart contract. These specific actions can also be the execution of critical smart contract logic, such as a source of entropy to generate a random number that serves an actionable execution.
Vulnerability#
The timestamp dependence vulnerability occurs when the smart contract does an operation based on the value of the block timestamp. The timestamp value is generated by the node executing the smart contract, making it easily manipulated and vulnerable to attacks. One of the most challenging issues with blockchain technology is synchronizing the precise time between nodes due to the distributed nature of the network. However, comprehending the present time is probably inevitable during the development of smart contracts, especially as most smart contract development languages are Turing complete.
A smart contract can be exploited if it compares the node's timestamp value to a time value that will occur in less than 900 seconds. The timestamp value is referenced by the nodes that run the smart contract, which means that it can also be manipulated to be equal to a certain value.
A miner has the opportunity to set the timestamp as a value that would increase their chances of profiting from a logic, such as the function of the contract in which the timestamp is used as a source to generate randomness. This can be done within 15 seconds of block validation.
For instance, a lottery application might select a random bidder from a group of bidders using the block timestamp. A miner may enter the lottery and then modify the timestamp value to increase their chances of winning.
Attack Explained#
Consider the below smart contract TimeStamp.sol,
A user can win all of the Ether in the contract if they submit a transaction at a specific timing.
Line 2:
In line 2 of the contract, we have declared an integer variable prevBlockTime, which is used to keep track of the block timestamp required in the contract.
Line 4:
In line 4 of the contract, we have declared a payable constructor.
A constructor is a function that is used to initialize objects. This function is immediately called when a contract is created, or called when an object of the contract’s class is created.
Functions or addresses declared as payable can receive ether in the contract. Thus, this contract is able to receive ether when it is deployed.
Line 6 - 14:
In line 6 of the contract, we have declared an external payable function named guess.
Inside this function on line 7, we have a require statement that states that the caller of the contract needs to send 2 Ether. The following require statement on line 8 states that there can't be more than 1 transaction originating from this contract at a given time.
On line 10 of this contract, the block timestamp is set to prevBlockTime, whenever a user executes the contract.
On line 12, the if statement is executed only when the value of the block timestamp is exactly divisible by 7. When that happens, the balance of the contract is sent to the address that executes this contract.
Attack Scenario:
This contract is deployed with a certain ether balance. A malicious actor Eve, operates a very powerful miner which can alter the block timestamp value.
Eve locates the hash of the desired block, by setting the block.timestamp value to a number in the future, which is exactly divisible by 7, and finds that target block hash.
This means that Eve's block is successfully added into the chain, and they take away the balance set in the contract.
Incident Impact#
- Time Warp attack on Feathercoin
Feathercoin was a target of a time warp attack in 2013. In this incident, a group of miners took advantage of a vulnerability in Feathercoin's mining algorithm that allowed them to manipulate the timestamp of blocks and generate new blocks at a much faster rate.
There are varying estimates of the losses due to this attack. The attackers were able to create and mine approximately 18.6 million Feathercoins in a short period of time. At the time of the attack, Feathercoin's market capitalization was around $10 million, and its value had dropped by approximately 20% after the attack was discovered. However, it's unclear how many of these newly created coins were actually sold by the attackers and how much of an impact they had on the market, but it's clear that the attack had a significant impact on Feathercoin's value and reputation.
In response to the attack, the Feathercoin developers were quick to respond to this incident. They released a new version of the Feathercoin software that fixed the vulnerability in the mining algorithm and implemented a new difficulty adjustment algorithm to prevent future attacks.
- GovernMental Ponzi Scheme
The GovernMental Ponzi scheme amassed nearly 1100 ETH through its jackpot payouts. The contract awarded the payout to the last player to enter the round and remain for at least one minute. Thus, a miner who also happened to be a player was able to manipulate the timestamp in such a way that he or she would appear to be the very last person to join the game by a margin of over a minute. An adjustment was made to a time in the future so that it would appear as though one minute had passed, even though this was not the case.
Prevention#
The simplest way to prevent this vulnerability is to avoid using the block.timestamp value on the contract altogether. The block.timestamp value is mostly used as a source of entropy, such as in the generation of a random number, which can also be achieved using other alternative approaches.
It is simple to mitigate the timestamp dependence vulnerability by adhering to the 15 second rule. According to the Ethereum Yellow paper, there is no limit to how far the blocks are in time, but each timestamp should be greater than the timestamp of its parent. Consequently, it explains that if the state of the time-dependent event can vary by 15 seconds and maintain integrity, it is safe to use the block.timestamp parameter in the contract.
For example, consider a staking contract, where a user stakes his share of digital assets for a period of six months. In this situation, using the block.timestamp value to measure the timed action is not an instance of a vulnerability.
Another approach is to use a reliable oracle such as the data providers like ChainLink for the purpose of random number generation. ChainLink Oracle provides the Verifiable Random Function that enables a contract to generate a number without causing a security threat.
Conclusion#
Contracts frequently require access to time values in order to perform certain types of functions. Values such as block.timestamp and block.number can provide an indication of the current time or a time delta, but they are not suitable for most purposes.
Reference Sources Geeks for Geeks, Immune Bytes
