GemPad’s December Crisis: Technical Breakdown of the $2.2M Smart Contract Breach

December 17, 2024, marked a dark day for GemPad users when an attacker drained $2.2 million through a sophisticated smart contract breach. The security incident exposed a critical vulnerability in GemPad’s LP Locker V2 contract, allowing the attacker to execute a reentrancy attack across Ethereum, BNB Chain, and Base networks.

Prominent projects like Munch Protocol, AnonFi, and BPay suffered significant losses because of this exploit. Most surprisingly, this vulnerability slipped through recent security audits by both Cyberscope and SolidProof. While the breach affected only twenty-seven of the 3000+ GemPad projects using locker services, it revealed concerns about the platform’s security infrastructure gaps.

This technical piece aims to peel back the layers of the exploit, examining how it unfolded, why established security audits failed to detect the vulnerability, and what crucial lessons emerge for the broader DeFi ecosystem.

Understanding GemPad’s Approach to Security

GemPad is a multichain decentralized launchpad and crowdfunding platform. Its standout feature is that users can launch their projects without needing smart contract coding expertise. Instead, project creators can generate different types of tokens through pre-audited templates. Like a master architect’s blueprint, GemPad’s design philosophy emphasizes the fusion of simplicity and security.

Overview of GemPad’s Infrastructure

Three mighty blockchain networks form the backbone of GemPad’s infrastructure:

Ethereum Network
BNB Chain
Base Network

Smart contract templates serve as the building blocks, carefully standardized across projects. These templates, bearing the stamp of pre-audits, promised a fortress of security for token deployments.

Participants Security Certification

Each project’s smart contract undergoes rigorous examination, theoretically building an impenetrable wall against vulnerabilities. Yet this laser focus on individual security blinded observers to cracks forming in GemPad’s foundation.

Anatomy of the December 2024 Exploit

Hidden beneath layers of security audits was the fatal flaw that shattered trust in the platform’s design.

Step-by-Step Attack Analysis

Shortly after the breach, Cyberscope published an incident report that provides exhaustive details of the exploit that targeted GemPad, shedding light on the attack’s sophistication and execution:

Malicious Token Creation: The attacker created a malicious token, referred to as “T,” which incorporated a custom transfer function explicitly designed to re-enter the Gempad Locker contract. This token was central to manipulating contract logic and bypassing standard security measures.
Flash Loan Acquisition: Securing a flash loan with the malicious token “T” as the beneficiary, the attacker gained immediate liquidity without collateral, enabling rapid execution of the planned exploit.
Liquidity Manipulation: With the acquired flash loan, the attacker purchased various tokens and created liquidity in their own Uniswap V2 pools. The resulting LP tokens were then transferred to the malicious token contract, consolidating resources for further manipulation.
Uniswap V3 Liquidity Position: Using both the malicious token and the Uniswap V2 LP tokens, the attacker established a liquidity position within Uniswap V3, setting the operational groundwork for their scheme.
Locking the V3 Position: The newly created Uniswap V3 liquidity position was locked into the Gempad Locker contract, subtly embedding the attack vector within legitimate operations.
Re-Entrancy Attack via Fee Collection: By invoking the collectFees function on the Gempad Locker contract, the attacker exploited the inherent reentrancy vulnerability. This function call chain led to the following:
- Initial balance checks by the contract.
- Invocation of the Uniswap V3 contract’s collectFees function, which was intercepted by the malicious token’s transfer function.
- Re-entry into the Gempad Locker contract, executing the multipleLock function.
- Creation and controlling of a new lock with phantom tokens, misleading the contract’s accounting.
Balance Discrepancy Exploitation: Upon completing the reentrant process and creating a new lock, the contract’s balance appeared artificially inflated. The contract calculated the apparent balance difference and sent the excess tokens to the malicious token contract. Although the flash loan was returned, the transaction recorded a free lock due to the exploit.
Funds Drainage: The attacker finalized the exploit by integrating with the Gempad Locker contract, meticulously withdrawing Uniswap V2 LP tokens and accessing locked funds, effectively draining resources under the guise of legitimate transactions.

Understanding the Vulnerability

Smart contract gospel preaches state updates before external calls. Nevertheless, GemPad’s contract broke this commandment, transferring execution while leaving its gates unlocked. Each time the contract reached outward, the attacker slipped back through the same door.

Here’s a rough sequence diagram illustrating the process:

In summary, the fundamental cause of the GemPad exploit was a reentrancy vulnerability within the LockV2 contract. This flaw enabled the attacker to manipulate the contract’s logic — a critical issue that should have been identified and addressed during the design and auditing stages of the contract.

Security Audit Failure Analysis

Behind GemPad’s gleaming security badges lurked shadows of oversight. Two respected audit firms, SolidProof and Cyberscope, blessed the protocol’s smart contracts yet missed the fatal flaw that cost millions.

Missed Vulnerability Indicators

Beneath pristine audit reports lay troubling gaps:

High security scores masked a deadly reentrancy vulnerability
Gempad Lock’s flawed gateway remained invisible
Battle-testing fell short of real-world chaos

Audit Process Shortcomings

Cracks in the audit fortress widened under scrutiny. Reentrancy – smart contract security’s oldest foe – slipped past watchful eyes.

Both audit firms faced harsh questions. Multiple reviews failed to spot what one attacker found. Security’s new commandments emerged:

Comprehensive infrastructure assessment beyond individual contracts
Regular security reviews of dependent systems
Implementation of real-world stress testing protocols

This failure cut deeper than simple oversight. Despite glowing assessments, the fundamental weakness in GemPad’s foundation endangered every project under its roof. Questions burned about the platform’s readiness to protect its users’ trust.

Recovery and Mitigation Strategy

In GemPad’s defense, the project swiftly acted after the incident.

Smart Contract Upgrades and Fixes

Fresh code flows through GemPad’s veins. Assure DeFi stands sentinel over new locker contracts, their deployment frozen until security’s blessing.

Three pillars support the rebuilt fortress:

Reentrancy guards stand watch at every gate
Cross-chain messages pass through stricter filters
Access controls tighten their grip

Conclusion

December 2024’s GemPad breach echoes through DeFi’s halls. Twenty-seven projects bled $2.2 million across blockchain networks, while smart contract vulnerabilities mocked security’s pride.

Audit firms, those supposed sentinels of code, missed the deadly reentrancy flaw lurking beneath. Their oversight cost projects dearly, shattering trust in time-honored security processes.

Yet from chaos springs order. GemPad’s swift response – emergency protocols snapping into place, smart contracts reborn stronger – speaks of DeFi’s resilience. Overall, this incident is a reminder that security goes beyond mere audit stamps, demanding constant vigilance.

Author: Damaso Sanoja