error_outlineWEBSITE HACKED ? sos@getsecureworld.com

What is timestamp dependence vulnerability?

blog + secure coding + Smart contract + Solidity Z. Oualid today

Background
share close

During the development of a smart contract, programmers may need to know the exact time to be able to execute some actions. Therefore, smart contract developers use what we call a timestamp offered by the node executing the smart contract. However, this may cause create multiple vulnerabilities that can cause a huge financial loss. So what is timestamp dependence vulnerability?

The timestamp dependence vulnerability happens when the smart contract relies on the value of the block timestamp value to execute an operation. The value of the timestamp is generated by the node executing the smart contract which makes it manipulable and vulnerable to attacks.

In this blog post, we are going to explain what a timestamp dependence vulnerability means and when it occurs and why. We are going to give you a detailed technical explanation of this vulnerability supported by multiple examples to better understand. So if you are interested in knowing more about this subject, then please continue to read a leave a comment below.

What is timestamp dependence vulnerability?

Due to the distributed nature of the Blockchain network, setting the exact time between nodes and synchronizing it, is one of the most difficult problems that Blockchain technology suffers from. However, during the development of smart contracts, getting in the need of knowing the current time is inevitable, especially since most smart contract development languages are Turing complete.

To partially solve this issue, most Blockchain technologies that support the smart contract concept, offer the timestamp of the system to retrieve the actual time of the network. Usually, this value is the number of seconds since the UNIX epoch.

The timestamp dependence vulnerability happens when the smart contract uses the timestamp value generated by the node to compare it to a time value that will happen in less than 900 seconds.

The timestamp value is generated by the nodes that execute the smart contract, which means that they can be altered to be equal to a specific value.

To better understand the concept of this vulnerability, I invite you to take a look at the following section where I will give you technical examples of this vulnerability.

Technical examples of the timestamp dependence vulnerability

In this section, you are going to see some examples of real vulnerable smart contracts that suffer from this vulnerability.

Example 1:

Check the following smart contract source code https://etherscan.io/address/0xa11e4ed59dc94e69612f3111942626ed513cb172#code

This smart contract represents a sort of lottery game where the user should send an amount of money to the smart contract function play(). The amount of money should be equal to the TICKET_AMOUNT otherwise the transaction will fail.

Then the smart contract retrieves the actual time when the contract is executing, applies a formula to it, and stores the value in the random variable (line 14). After that, the smart contract checks if the value of the random variable is equal to zero or not. If it is the user who sent the transaction becomes the winner otherwise nothing happens.

To get the actual time, the smart contract uses the block.timestamp variable. The value of this variable is given by the node, therefore the node could easily manipulate that value by increasing it till it gets the result of line 14 as zero.

Example 2:

Here is another example of a vulnerable smart contract:

In this example, the smart contract Roulette gives the user the ability to get all the funds in the contract by simply sending 10 ethers to this contract at the right moment. The right moment simply means that the timestamp value retrieved from the “now” instruction when the transaction is sent should be dividable by 15.

Therefore, by incrementing a maximum of 15 times to the timestamp proposed by the node “which will keep it valid as the value is still less than 900” the node itself can exploit this vulnerability and take all the money in the contract.

In the following section, I will explain why this vulnerability exploitation is limited in time and cannot be always exploitable.

Does using the timestamp value always create a vulnerability?

To answer this question you should know how the node’s generated blocks are validated in the Blockchain. To validate and include a block in the Blockchain, validators should check the following criteria in the next block:

  1. Is there an object, which is a block, in the database with block.prevhash as its hash? Let parents be that block.
  2. Is the proof of work on the block valid?
  3. Is the proof of work on all uncle headers valid?
  4. Are all uncles unique and actually uncles (ie. children of the parent of the parent, but not the parent)?
  5. Is block.timestamp <= now + 900 and is block.timestamp >= parent.timestamp?
  6. Is block.number == parent.number + 1?
  7. Is block.difficulty == adjust_difficulty(parent.difficulty,timestamp,parent.timestamp)?
  8. Is block.transaction_hash = TRIEHASH(transaction_list)?
  9. Is block.stacktrace_hash = TRIEHASH(stacktrace)?
  10. Is block.uncle_hash = H(uncle_list)?

You can find this list here if you want more details about those checks.

Note:

The checks presented in this explanation are used in the Ethereum Blockchain. Other technologies may use other logic in the validation of their blocks.

If you take a look at the fifth line, you will notice that the block.timestamp value is also checked to validate the proposed block. In addition, this value should be less than or equal to the actual value plus 900 seconds. Moreover, the timestamp value should be higher or equal to the parent.timestamp value. Otherwise, the next block will be automatically rejected.

Therefore, the nodes could play with time in this interval, not less than parent.timestamp and not higher than the actual time plus 900. This simply means that if you are comparing larger time ranges that are longer than the actual time plus 900 seconds (days, months, years) then you should be okay. However, if your condition to execute an action depends on seconds, then you should think of another way to check this difference.

What is the impact of the timestamp dependence vulnerability?

The impact of this vulnerability depends on the reason behind using the timestamp value in the smart contract. For example, in the previously discussed smart contract, the impact is very important as it implies financial losses. Therefore, the more you really are on this value to make a sort of access control to execute a certain task in the contract, the more likely to make it vulnerable to attacks.

How to prevent the timestamp dependence vulnerability?

There are two ways to prevent the timestamp dependence vulnerability:

  1. By not using this value as an access control check
  2. By allowing a range of +900 seconds of error

Allowing a range of 900 seconds error means that if the timestamp value returned by the node is incremented by a value between 1 and 900 seconds, this will not have a big impact on your smart contract business logic. For example, if you only allow a user to withdraw his money from your contract after 5 years. Then, if he does that with 900 seconds before the actual time it would not have a big impact on your business.

Does the timestamp dependence vulnerability exist in other Blockchain?

To my best knowledge, this type of vulnerability may happen in any Blockchain that gives nodes the ability to propose a timestamp value for their next proposed blocks without checking them. The only way to block this vulnerability once and for all is to have a time synchronization between all the nodes in the network in a distributed architecture. However, this is a very difficult research problem that people try to solve.

In Solana Blockchain, this kind of attack is very difficult to happen, as the order of the blocks and the timestamp they get is related to a voting protocol to estimate it. This timestamp value is generated based on a proof of history protocol based on the cryptographic concepts that make it very difficult to be altered by the validator node that executes the smart contract.

Written by: Z. Oualid

Rate it

About the author
Avatar

Z. Oualid

I am a Cyber Security Expert, I have worked with many companies around the globe to secure their applications and their networks. I am certified OSCP and OSCE which are the most recognized and hard technical certifications in the industry of cybersecurity. I am also a Certifed Ethical hacker (CEH). I hope you enjoy my articles :).


Previous post

Post comments (0)

Leave a reply

Your email address will not be published. Required fields are marked *