From Beginner to Pro: Secureum RACEs and the Journey to Ethereum Security Mastery

Published in

InfoSec Write-ups

5 min readMar 18, 2023

Hello hackers!!! Are you looking for a perfect place to learn web3 security? Do you know about Secureum? Secureum is a newsletter that focuses on security topics related to Ethereum, a decentralized blockchain platform. The name “Secureum” is derived from a combination of “security” and “Ethereum,” and is pronounced like the latter.

In this series of blogs, we will be solving Secureum RACEs.

What is Secureum RACE?

Secureum RACEs are smart contract security quizzes, where you have to understand the vulnerable contract and have to answer 8 questions within 16 minutes.

Seems like a tough job right!!! yes, it is.

But the rewards for success are significant: if you place in the top 32 on the leaderboard, you’ll have the opportunity to win workshops or real-world audits and more. Whether you’re an experienced Ethereum security professional or just starting to explore this exciting field, participating in Secureum RACEs can be a great way to test your skills, learn new insights, and earn valuable rewards.

Let’s get started, but before that

If you want to access the full code, you can find it on GitHub https://github.com/UVvirus/secureum_race/blob/main/RACE_5.sol

Usually, the Secureum format will be like this, There will be one vulnerable contract followed by 8 questions. Since the codebase is too long and it will be annoying for the users to read, I decided to add it to the GitHub repo. You can find the link above.

1. InSecureum balanceOf()

A) May be optimized by caching state variable in local variable

B) May be optimized by changing state mutability from view to pure

C) May be optimized by changing its visibility to external

D) None of the above

ANSWER: D

EXPLANATION: Caching is unnecessary because the _balances state variable is only used once and then returned right away.

As the function accesses a state variable, which requires at least view, state mutability cannot be adjusted to pure.

Because the balanceOfBatch() method now calls it internally, it cannot be changed from internal to external.

2. In InSecureum, array lengths mismatch check is missing in

A) balanceOfBatch()

B) _safeBatchTransferFrom()

C) _mintBatch()

D) _burnBatch()

ANSWER: All the above

3. The security concern(s) with InSecureum _safeTransferFrom() is/are

A) Incorrect visibility

B) Susceptible to an integer underflow

C) Missing zero-address validation

D) None of the above

ANSWER: A, B, C

EXPLANATION: The function is prefixed with an underscore, which indicates that it should be an internal function.

By default, the compiler will check for overflows in versions above 0.8. But it will ignore the unchecked block. Here fromBalance is in the unchecked block which is vulnerable to overflow vulnerability.

There is no validation for zero-address, which will eventually lead to burning the tokens. If the attacker-supplied zero address on the “to” address parameter. Since the function is Public this can happen.

4. The security concern(s) with InSecureum _safeBatchTransferFrom() is/are

A) Missing array lengths mismatch check

B) Susceptibility to an integer underflow

C) Incorrect balance update

D) None of the above

ANSWER: A, C

EXPLANATION: As we’ve already observed, there is an array length mismatch in the second question, which is missing a check.

Additionally, it appears that the value of fromBalance is calculated in the code, but it is not actually used anywhere within the function.

These are both potential issues that could lead to vulnerabilities in the contract

5. The security concern(s) with InSecureum _mintBatch() is/are

A) Missing array lengths mismatch check

B) Incorrect event emission

C) Allows burning of tokens

D) None of the above

ANSWER: A, B, C

EXPLANATION: From the 2nd question we know that option A is correct.

When comparing the TransferBatch event on the other functions such as _safeBatchTransferFrom(), _burnBatch(), It is emitted like operator, from, address(0) but here in this function(_mintBatch) the order changes.

The zero address check ensures that whether the sender is a non-zero address, but it didn't check whether the receiver is a zero address or not, it should check for the “to” address. Now, this leads to the burning of tokens.

6) The security concern(s) with InSecureum _burn() is/are

A) Missing zero-address validation

B) Susceptibility to an integer underflow

C) Incorrect balance update

D) None of the above

ANSWER: D

7) The security concern(s) with InSecureum _doSafeTransferAcceptanceCheck() is/are

A) isContract check on incorrect address

B) Incorrect check on return value

C) Call to incorrect isContract implementation

D) None of the above

ANSWER: C

EXPLANATION: The function isContract() in Ethereum should be modified to check whether the code length is greater than 0. This is because Ethereum not only has contract accounts but also has Externally Owned Accounts (EOAs) that do not contain any code. Since contracts deployed on the blockchain will always have code, checking for a length greater than 0 can be a reliable way to determine whether an account is a contract or an EOA. By updating the isContract()function in this way, we can ensure that the code operates correctly and can accurately distinguish between contract accounts and EOAs.