Introduction:

Smart contracts are a fundamental part of blockchain technology, and they have enabled a wide range of innovative applications, from decentralized finance to supply chain management. However, like any software, smart contracts can have security vulnerabilities that can be exploited by attackers. In this article, we’ll introduce the Smart Contract Weakness Classification and Test Cases (SWC) registry, a tool that can help developers identify and mitigate these vulnerabilities.

What is the SWC Registry?

The SWC Registry, also known as the Smart Contract Weakness Classification Registry, is a project that aims to maintain a comprehensive list of known security vulnerabilities and weaknesses in smart contracts on various blockchain platforms, including Ethereum, Binance Smart Chain, and others. The project was initiated by a group of security researchers and experts who recognized the importance of identifying and mitigating security risks in smart contracts.

The SWC Registry provides a standardized classification system for identifying and describing different types of smart contract vulnerabilities and weaknesses. It currently includes over 200 entries that cover a wide range of security issues, such as integer overflow and underflow, reentrancy attacks, and permission issues.

Each entry in the SWC Registry includes a unique identifier, a title, a description of the vulnerability or weakness, and information about its potential impact and severity. The entries are categorized based on their level of severity, with categories ranging from “low” to “critical.”

Developers and auditors can use the SWC Registry as a reference when conducting security audits or when developing smart contracts. By consulting the registry, developers can ensure that their smart contracts do not contain any known vulnerabilities or weaknesses and can take the necessary steps to mitigate any identified risks.

In addition to providing a comprehensive list of smart contract vulnerabilities, the SWC Registry also serves as a platform for discussing and addressing new security issues as they arise. The project is open-source, and anyone can contribute by submitting new vulnerabilities or weaknesses, suggesting changes to existing entries, or participating in discussions about emerging security threats.

Who Created the SWC Registry?

The team behind MythX was indeed involved in the creation of the SWC Registry. They are among the experts from the blockchain community who contributed to the SWC working group, which proposed the idea and implemented the registry. The MythX team, which includes security experts like Bernhard Mueller and Joran Honig, is known for developing tools and services that help developers identify and fix security vulnerabilities in smart contracts, and their contributions to the SWC registry are part of that broader effort.

SWC Registry Repo:
https://github.com/SmartContractSecurity/SWC-registry/

Example of Weakness Classes in the SWC:

Reentrancy Vulnerability (SWC-107):

Calling external contracts poses a significant risk as it can result in loss of control flow. An instance of such risk is the reentrancy attack, also known as the recursive call attack. In this attack, a malicious contract calls back into the calling contract before the initial invocation of the function is complete, causing multiple function invocations to interact in undesirable ways.

DAO ATTACK:

A DAO (Decentralized Autonomous Organization) attack in smart contracts refers to an exploit in the code of a decentralized autonomous organization that allows an attacker to steal or manipulate the organization’s assets.

DAOs are essentially self-executing smart contracts that exist on a blockchain and operate autonomously without the need for intermediaries. They are designed to manage funds and make decisions through a voting system controlled by the members of the organization.

In a DAO attack, a hacker finds a vulnerability in the smart contract code and exploits it to gain control over the organization’s funds or manipulate its decision-making process. This can be done through a variety of means, such as creating a malicious proposal that is approved by the voting system, exploiting a flaw in the code to drain the organization’s funds, or launching a denial-of-service attack to prevent members from voting.

One infamous example of a DAO attack occurred in 2016 when an attacker exploited a vulnerability in the code of a DAO called “The DAO” and stole approximately one-third of the organization’s funds, worth around $50 million at the time. This incident highlighted the need for better security measures in smart contracts and the importance of conducting rigorous code audits before launching any DAO or other smart contract-based system.
Let’s take this smart contract to understand:

simple_dao.sol:


SimpleDA.sol explication:
This smart contract is a basic implementation of a decentralized autonomous organization. The contract has three functions: donate, withdraw, and queryCredit.

The donate function is a payable function that can be called by anyone and takes an address parameter called “to”. This function allows the caller to send ether to the contract and adds the sent amount to the credit balance of the specified address (“to”) in the credit mapping.

The withdraw function takes an amount parameter and allows the caller to withdraw a specified amount of ether from their credit balance if they have sufficient credit. The function first checks if the credit balance of the caller (msg.sender) is greater than or equal to the specified amount. If the balance is sufficient, the function uses the require statement to ensure that the caller is able to receive the ether by using the call function with the specified amount as an argument. If the call is successful, the function subtracts the specified amount from the credit balance of the caller.

The queryCredit function takes an address parameter and returns the credit balance of the specified address from the credit mapping.

The contract has a mapping called credit that maps addresses to uint values representing the credit balance of each address. The contract also uses the msg.value variable to obtain the amount of ether sent to the contract by the caller.
Is this smart contract vulnerable to Reentrancy Vulenrability??
The answer is yes ;

The SimpleDAO contract is vulnerable to the reentrancy attack because it uses a “pull” approach to transfer ether to the caller’s account in the withdraw function. Specifically, the function uses the call function to transfer ether to the caller, but it does not update the caller’s credit balance until after the call function returns. This creates a vulnerability where a malicious contract or attacker can call the withdraw function repeatedly before the first invocation of the function is finished, effectively draining the contract of ether.

Here’s how a reentrancy attack can be carried out on the SimpleDAO contract:

  1. The attacker deploys a malicious contract that has a fallback function that calls the withdraw function of the SimpleDAO contract.

  2. The attacker calls the donate function of the SimpleDAO contract and sends a large amount of ether to the malicious contract

  3. the fallback function of the malicious contract called automatically after receiving ether , which calls the withdraw function of the SimpleDAO contract.

  4. The withdraw function transfers ether to the attacker’s contract using the call function without updating the credit balance of the attacker’s address in the credit mapping.

  5. The fallback function of the malicious contract is executed again, and the withdraw function of the SimpleDAO contract is called again.

  6. The withdraw function transfers ether to the attacker’s contract again, but this time it uses the credit balance from the previous invocation of the function, effectively allowing the attacker to drain the contract of all its ether.

Here is an example of the attacker smart contract MaliciousContract.sol:


This contract is designed to be the attacker contract in a reentrancy attack on the SimpleDAO contract. The contract takes the address of the SimpleDAO contract as a constructor argument and stores it in the dao state variable.

The fallback function of the contract is external and payable, which means it can receive ether and be called from other contracts. In this case, the fallback function simply calls the withdraw function of the SimpleDAO contract with a withdrawal amount of 1 ether.

When the SimpleDAO contract calls back into the malicious contract during the execution of the withdraw function, the fallback function of the malicious contract is executed again, allowing the attacker to repeatedly call the withdraw function and drain the contract of ether.

Remediation:

The best practices to avoid Reentrancy weaknesses are:

  • Make sure all internal state changes are performed before the call is executed. This is known as the Checks-Effects-Interactions pattern

  • Use a reentrancy lock (ie. OpenZeppelin’s ReentrancyGuard.

Here is the same sample dao contract with modification to remdiate against reetrency attack :


Conclusion…

In conclusion, the SWC Registry is an essential resource for developers to identify and mitigate security risks in their smart contract code. By staying informed of the latest vulnerabilities and implementing best practices, developers can ensure the security and integrity of their code. However, as vulnerabilities can be complex and difficult to identify, it is often best to seek out professional security auditing services. Our company, SCT ITALIA, offers audit security services to help ensure that your token contract is secure and free from vulnerabilities that can be exploited by attackers. By taking proactive measures to secure your token, you can reduce the risk of financial losses and protect the investments of your users.