Memeswap's Vault & DoS Issues Resolved: How QuillAudits Made It Happen

1. Information Gathering
   • Collected and reviewed all relevant documentation, including whitepaper, technical specifications, and design documents.
   • Obtained a clear understanding of the Memeswap platform's functionality and intended user interactions.
   • Discussed client concerns and specific areas of focus for the audit.
      
2. Manual Code Review:
   • Conducted a line-by-line review of the smart contract code, focusing on:
     • Vulnerability identification: Searching for known vulnerabilities like reentrancy, front-running, integer overflows, and access control issues, etc.
     • Logic flaws: Identifying inconsistencies or unintended behaviours in the code logic.
     • Solidity best practices: Compliance with secure coding standards and adherence to established guidelines.
        
3. Functional Testing:
   • Developed and executed a comprehensive set of test cases covering various user interactions and edge cases.
   • Leveraged tools like Hardhat and Ganache to deploy and test the smart contract locally.
      
4. Automated Testing:
   • Employed static analysis tools like QuillShield to identify vulnerabilities through automated code scanning.
   • Utilized symbolic execution tools like Mythril to explore various code execution paths and uncover potential attack vectors.
   • Integrated unit tests are written by the Memeswap team to verify specific contract functions and their behaviour.
      
5. Reporting & Remediation:
   • Prepared a detailed report outlining all identified vulnerabilities, categorized by severity and potential impact.
   • Provided clear recommendations for fixing each vulnerability, including code snippets and best practices.
   • Collaborated with the Memeswap Protocol team to prioritize and address the identified issues.
   • Conducted additional verification testing after vulnerability fixes were implemented.
      

Audit Discoveries

1. Malicious Contract Exploit Resulting in Protocol Shutdown

Discovery: A critical vulnerability was identified within the trigger modifier in MemeswapVault contract, a component designed to facilitate the dequeuing of items and the distribution of Ether to the next user in the queue. However, this mechanism proved susceptible to exploitation by malicious actors. Specifically, if the recipient of the Ether transfer is a contract designed to revert transactions via its receive or fallback function, the entire operation collapses. This scenario precipitates a Denial of Service (DoS) condition, effectively paralyzing the protocol and entrapping funds within the contract.

Detailed Breakdown of the Issue:

The exploit unfolds through the following sequence:

1. Legitimate User Stakes: A genuine participant stakes 1 Ether within the vault.
2. Attacker Stakes and Enqueues: Concurrently, an attacker stakes 1 Ether and promptly enqueues the same amount.
3. Dequeue Trigger Activated: Subsequent invocations of functions employing the trigger modifier attempt to dequeue the attacker's staked Ether. However, the attacker's contract is programmed to revert any incoming transactions, triggering a DoS condition.
4. Protocol Shutdown: The relentless reversion of transactions grinds all operations to a halt, inhibiting further engagement and ensnaring funds within the contract.

Consequences: The ramifications of this vulnerability were profound, culminating in a complete cessation of the protocol's activities. Functions reliant on the trigger modifier became inoperable due to the enforced transaction reversions, thereby obstructing users' abilities to stake, enqueue, rent, or claim rewards. This led to an absolute shutdown of the protocol, rendering it non-functional and resulting in funds being irretrievably locked within the contract.
 

2. Potential Denial of Service Vulnerability in MemeswapVault

Discovery: A critical Denial of Service (DoS) vulnerability has been identified within the MemeswapVault contract, specifically pertaining to the logic governing the enqueue and dequeue processes. This vulnerability could potentially render the contract inoperative due to arithmetic underflow or overflow conditions, stemming from the interaction between the dequeuePossible function and the enqueue mechanism.

Detailed Breakdown of the Issue:

1. Initial Setup:
   • A user stakes 1 ether in the vault, updating totalSupply to 1 ether and setting balances[msg.sender] to 1 ether.
   • A new token deployment rents 0.6 ether from the vault, adjusting rentedSupply to 0.6 ether.
2. Enqueue Without Dequeue:
   • The logic within dequeuePossible() can be manipulated to consistently return false. This manipulation ensures that totalSupply - rentedSupply remains less than any enqueued amount, thereby preventing successful invocation of the dequeue function within the trigger modifier.
3. Enqueue Manipulation:
   • An attacker exploits this vulnerability by enqueueing multiple amounts (e.g., 1 ether, 2 ether, 4 ether) without triggering a dequeue, leveraging the condition if (_amount > balances[msg.sender] + userTotalQueue[msg.sender]).
4. Triggering Dequeue:
   • Upon a legitimate user attempting to stake, the dequeuePossible() function erroneously returns true, initiating the dequeue process. While the first legitimate enqueue operation proceeds correctly, subsequent attempts lead to arithmetic underflow or overflow.
5. Underflow/Overflow Error:
   • The operation balances[user] -= amount within the dequeue function precipitates an underflow or overflow when attempting to dequeue amounts exceeding the user's balance. This scenario triggers contract reversion, halting operations indefinitely.

Consequences:

• The contract may become permanently locked, inhibiting any future enqueue or dequeue activities.
• Users' funds risk being trapped within the contract indefinitely, with no means of recovery.
• The integrity and reliability of the contract are compromised, leading to a loss of trust among participants and potential financial repercussions.
• The vulnerability can trigger an arithmetic underflow, causing the contract to revert transactions and cease functioning permanently.
   

3. Potential Slippage Risk Due to Zero Minimum Amounts in Liquidate Function

Discovery: A critical oversight has been identified within the liquidate function of the MemeswapCollector contract. Specifically, the parameters amountAMin and amountBMin, which are intended to safeguard against excessive slippage during liquidity removal, have been set to zero. This configuration effectively removes any protection against slippage, allowing for up to 100% slippage during the removal of liquidity.

Issue Encountered: A critical oversight has been identified within the liquidate function of the MemeswapCollector contract. Specifically, the parameters amountAMin and amountBMin, which are intended to safeguard against excessive slippage during liquidity removal, have been set to zero. This configuration effectively removes any protection against slippage, allowing for up to 100% slippage during the removal of liquidity.

Consequences: By setting amountAMin and amountBMin to zero, the contract fails to enforce minimum amounts for tokens received from liquidity removal. This lack of enforcement could lead to the removal of liquidity at highly unfavorable rates, potentially resulting in substantial financial losses for participants. Moreover, this vulnerability could be exploited maliciously, leading to unexpected behavior or exploitation of the contract's users.
 

4. Contract Initialization Vulnerability in MemeswapTokenFactory

Issue Encountered: In src/MemeswapTokenFactory.sol, an inherent flaw exists within the initialize() function of the MemeswapTokenFactory contract. This function, designed to initialize the contract, lacks a mechanism to prevent repeated initialization. Consequently, the owner of the contract possesses the capability to call initialize() multiple times, thereby altering critical parameters such as the assignment of the vault.

Impact: The absence of a condition within the initialize() function to verify whether the contract has already been initialized introduces a significant centralization risk. This vulnerability empowers the owner to reassign the vault after its initial assignment, potentially leading to abuse of power. Such centralized control contradicts the decentralized ethos of blockchain technology and poses a risk of manipulation or misuse by the contract owner.
 

Remediation Strategies

1. Malicious Contract Exploit Resulting in Protocol Shutdown

Action:

QuillAudits implemented a validation mechanism within the trigger modifier to ensure that only externally owned accounts (EOAs) or contracts with safe Ether handling methods could receive transfers.

Outcome:

The fix effectively mitigated the risk of a DoS attack, ensuring the stability and reliability of the dequeuing process. The protocol is now protected against malicious contracts that could previously trigger a shutdown.
 

2. Denial of Service Vulnerability in MemeswapVault: Enqueue and Dequeue Manipulation

Action:

QuillAudits addressed the enqueue and dequeue manipulation by refining the logic in the dequeuePossible function. They introduced strict checks and balances to prevent conditions that could lead to arithmetic underflow or overflow.

Outcome:

The enhancements prevented the contract from becoming locked and ensured that enqueue and dequeue operations could proceed safely. Users’ funds are now protected from being trapped within the contract, and the protocol's reliability has been restored.
 

3. Slippage Risk Due to Zero Minimum Amounts in Liquidate Function

Action:

QuillAudits corrected the zero-value parameters by setting appropriate minimum thresholds for amountAMin and amountBMin in the liquidate function.

Outcome:

The risk of excessive slippage during liquidity removal was eliminated, safeguarding users from financial losses. The contract now enforces minimum amounts for tokens received, ensuring fair and secure liquidity operations.
 

4. Contract Initialization Vulnerability in MemeswapTokenFactory

Action:

QuillAudits added a condition to the initialize() function that prevents repeated initialization. This safeguard ensures that the contract can only be initialized once, and the vault assignment remains immutable after the first initialization.

Outcome:

The centralization risk was significantly reduced, aligning the contract with decentralized principles. The contract owner can no longer manipulate critical parameters after the initial setup, preserving the integrity and trustworthiness of the protocol.

Impressed by our findings and recommendations, the MemeSwap developers promptly addressed all identified vulnerabilities. Through our collaborative efforts, the MemeSwap project is now significantly more secure, ensuring the protection of user funds.

The MemeSwap’s smart contracts security audit identified and addressed critical vulnerabilities, protecting user funds and ensuring platform stability. This case study demonstrates the importance of proactive security measures for blockchain-based projects, especially those dealing with financial assets. By conducting audits and addressing identified issues, the MemeSwap Team has taken a significant step towards securing its platform and safeguarding user trust.