WebKeyDao Hack Analysis

On March 14, 2025, the WebKey Dao project operating on the Binance Smart Chain (BSC) suffered an exploit, leading to a financial loss estimated at approximately $737,000 USD. This analysis delves into the mechanics of the attack, identifies the root cause, and outlines key security takeaways.

Incident Overview

Date: March 14, 2025

Platform: Binance Smart Chain (BSC)

Attacker Address: 0x3026c464d3bd6ef0ced0d49e80f171b58176ce32

Affected Contract (Proxy): 0xd511096a73292a7419a94354d4c1c73e8a3cd851

Implementation Contract (at time of attack): 0xc39c54868a4f842b02a99339f4a57a44efc310b8

Attack Transaction: 0xf13d281d4aa95f1aca457bd17f2531581b0ce918c90905d65934c9e67f6ae0ec

Exploit Mechanics

The attacker executed a profitable arbitrage strategy by exploiting the misconfigured parameters within the WebKey Dao contract. The core steps of this strategy, repeated within the attack transaction(s), were as follows:

1. Buy: Call the buy function, spending USDT to purchase wkeyDao tokens at the artificially low price set by the operator.

2. Receive: Instantly receive the purchased wkeyDao tokens due to the non-zero immediateReleaseTokens value.

3. Sell: Swap the received wkeyDao tokens on a Decentralized Exchange (like PancakeSwap) for USDT or other assets at the current, higher market price.

The attacker repeated this buy-receive-sell cycle. For instance, analysis of the main attack transaction (0xf13d...ae0ec) shows the attacker utilized approximately $1,200 USDT in parts of the exploit to acquire 230 wkeyDao tokens, which were subsequently sold for around $13,000 USDT. By repeating this arbitrage within the transaction, the attacker was able to drain significant value, contributing to the total estimated loss of ~$737k.

Technical Deep Dive: Tracing the Vulnerability

Our investigation focused on how the attacker acquired tokens at a significantly below-market rate.

1. Analysis of the buy function: The buy function facilitated token sales based on parameters defined in the currentSaleInfo storage variable. At the time of the attack, this included a fixed price ($1,200 USDT for the bundle purchased) and a value for immediateReleaseTokens. When immediateReleaseTokens was set to a non-zero value, the contract would immediately transfer that number of tokens to the buyer upon purchase. While this mechanism enabled the exploit, the function itself operated according to its logic based on the existing sale parameters. The root cause did not lie within the buy function's code logic itself.

2. Investigating currentSaleInfo: We traced how the currentSaleInfo variable, particularly the immediateReleaseTokens parameter, was set. The primary mechanism for modifying this data is the setSaleInfo function.

3. Analysis of the setSaleInfo function: The setSaleInfo function's logic is straightforward and includes an essential access control check: only the designated contract operator can call it to update sale parameters. This function, in isolation, does not present an inherent vulnerability.

4. Identifying the Precursor Transaction: A review of historical interactions with the contract revealed a critical transaction executed by the operator address approximately 120 days prior to the exploit:

   Operator Transaction: 0xda64c661c80739865c344d57415476c8a9cac4cee8ec51274dcb173939f976df This transaction invoked setSaleInfo and configured the currentSaleInfo with the exact parameters that the attacker later exploited. The decoded input data for this transaction (shown below) clearly indicates the values set for _price and _immediateReleaseTokens which created the vulnerability.

Root Cause Determination

The fundamental cause of this exploit was not a flaw in the smart contract's code logic but an operational issue. Incorrect sale parameters (specifically, a low price combined with immediate token release, as shown in the transaction data above) were set via the setSaleInfo function by the designated operator well in advance of the attack. This misconfiguration created a window of opportunity, allowing the attacker to purchase tokens far below their market value. The reason for this misconfiguration could range from human error during setup to a potential compromise of the operator's private key.

Lesson learned

This incident underscores the critical importance of operational security alongside code security:

1. Parameter Validation: Implement rigorous checks and multi-person verification processes when setting critical contract parameters like sale prices and token release schedules.

2. Secure Key Management: Employ robust key management solutions for privileged roles like contract operators. Consider using Multi-Party Computation (MPC) wallets or hardware wallets stored securely to prevent single points of failure and unauthorized access.

3. Regular Audits & Monitoring: While the code itself wasn't flawed, regular reviews of contract state and parameters, alongside monitoring for unusual operator actions, could potentially detect such misconfigurations earlier.

By focusing on secure operational procedures and safeguarding privileged accounts, DeFi projects can significantly reduce the risk of exploits stemming from misconfigurations.