Dria
Swan
NFTHardhat
21,000 USDC
View results
Previous Next
Submission Details
Severity: high
Invalid

Double Spending Vulnerability in DatasetAccessToken Contract :The burn function in the DatasetAccessToken contract does not have a mechanism to keep track of which tokens have been burned.

nitinaimshigh

Summary : The impact of not having a mechanism to keep track of burned tokens in the DatasetAccessToken contract can be significant, and it is essential to implement a solution to mitigate these risks.

Vulnerability Details : The DatasetAccessToken contract has a vulnerability that allows an attacker to burn the same token multiple times, resulting in unauthorized access to the dataset. This vulnerability is caused by the lack of a mechanism to keep track of burned tokens.

To exploit this vulnerability, an attacker can create a contract that burns the same token multiple times, using the burn function in the DatasetAccessToken contract. The attacker can then use the requestAccess function to gain unauthorized access to the dataset.

Impact : The impact of this vulnerability is high, as it allows an attacker to gain unauthorized access to the dataset by burning the same token multiple times. This can result in financial losses, data breaches, and reputational damage.

Proof of Concept Code : Here's a proof of concept code that demonstrates the impact of not having a mechanism to keep track of burned tokens in the DatasetAccessToken contract..

pragma solidity ^0.8.0;
​
import {ERC721} from "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import {ERC721Burnable} from "@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol";
​
contract DatasetAccessToken is ERC721, ERC721Burnable {
// ...
​
function burn(uint256 tokenId) public override {
// Burn the token without checking if it's already been burned
ERC721Burnable.burn(tokenId);
​
// Request access to the dataset
// This can be called multiple times with the same token ID
requestAccess(msg.sender);
}
​
function requestAccess(address user) internal {
// Grant access to the dataset
// This can be called multiple times with the same token ID
// ...
}
}
​
contract Attacker {
DatasetAccessToken public datasetAccessToken;
constructor(DatasetAccessToken _datasetAccessToken) public {
datasetAccessToken = _datasetAccessToken;
}
​
function attack(uint256 tokenId) public {
// Burn the token multiple times
for (uint256 i = 0; i < 10; i++) {
datasetAccessToken.burn(tokenId);
}
}
​
}

In this proof of concept code, we have two contracts: DatasetAccessToken and Attacker. The DatasetAccessToken contract has a burn function that burns a token without checking if it's already been burned. The Attacker contract has an attack function that burns the same token multiple times.

This proof of concept code demonstrates the impact of not having a mechanism to keep track of burned tokens in the DatasetAccessToken contract. By burning the same token multiple times, the attacker can gain unauthorized access to the dataset.

Tools Used : VS Code

Recommendations : To fix this vulnerability, we can add a mechanism to keep track of burned tokens, such as a mapping of burned tokens, as I mentioned earlier. Here's an updated version of the DatasetAccessToken contract that includes a mapping of burned tokens:

contract DatasetAccessToken is ERC721, ERC721Burnable {
// ...
​
mapping(uint256 => bool) public burnedTokens;
​
function burn(uint256 tokenId) public override {
// Check if the token has already been burned
require(!burnedTokens[tokenId], "Token has already been burned");
​
// Burn the token
ERC721Burnable.burn(tokenId);
​
// Mark the token as burned
burnedTokens[tokenId] = true;
​
// Request access to the dataset
requestAccess(msg.sender);
}
}
Updates

Lead Judging Commences

inallhonesty Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Out of scope

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.