2024 End of Year BSC Security Report

Table of contents​

• Overview
• Disclaimer
• Executive Summary
• Notable developments
  • Developments in the Wallet Drainer Scams
  • Continued rise of DPRK Scams
  • Continued rise of Spoofing Scams
• Year-over-Year (YoY)
  • General
  • Type of attack vectors
  • Type of projects
  • Chain comparison
• 2024 in focus
  • General
  • Wallet Drainer Analysis
  • Spoofing Analysis
  • Quarter-over-Quarter (QoQ)
  • Month-over-Month (MoM)
  • Type of attack vectors
  • Type of projects
• Conclusion
• Appendix
  • HashDit
  • Top 10 Incidents
  • 2024 highlights

Overview​

This report focuses on security events that happened on BSC in 2024, analyzing the type of projects targeted and sharing the common attack techniques used in 2024, with respect to the financial loss of the incidents.

Disclaimer​

The financial data provided here is accurate based on our own monitoring system and based on the $USD amount of the cryptocurrency involved at the time of the incident. Due to the fluctuating price nature of cryptocurrencies, the total amount loss might differ with the current token valuations.

Furthermore, the financial data might not fully reflect the true “exploited amount” of the incident. This is especially true for scams where the total scammed amount is usually mixed with an initial base amount injected by the scam project party.

Executive Summary​

1. A total of $62,895,059 was lost across 149 security incidents in 2024
2. This represents a decline of 61% from 2023 total of $162,214,631
3. May saw the most loss, with $20,624,200 across 9 incidents
4. Q4 was the most costly quarter, at $31,399,100 from 88 incidents
5. The most financially damaging attack vector belongs to Hot Wallet Compromise, with $27,040,000 in 6 incidents.
6. BSC ranks 6th in total losses across chains, representing 3% of total loss in Web3. This gave an average loss of $422,114 per incident. The 1st place went to Ethereum, representing 53% of total loss, with $1,075,000,000 in losses in 326 incidents. This resulted in an average loss of $3,297,546 per incident.

Notable developments​

Developments in the Wallet Drainer Scams​

Wallet Drainers are a sophisticated form of fraud that preys on users with low security awareness. These scams often operate under a "Scam-as-a-Service" model, allowing individuals to purchase malicious scripts to conduct their own scam campaigns. The primary method involves tricking users into visiting phishing websites and signing scam transactions with their crypto wallets, leading to the theft of their funds. This technique is not limited to a single blockchain but follows the flow of money across various chains. In 2024, Wallet Drainers continue to run wild, spreading havoc across ordinary users who are not careful in the space. Some of the notable instances include:

• Wallet Drainers have extended their reach beyond EVM chains to include networks like TON and Cardano.
• Scammers continue to focus on high-profile events, such as the Pudgy’s PENGU airdrop, to maximize their impact.
• Compromised data from breaches like MailerLite and LastPass have been used to spread phishing scams.
• Drainers have created fake channels and social media accounts on platforms like Telegram and Discord to mislead users.
• Scammers have developed fake meeting software and used social engineering to trick users into downloading malware.
• Targeting commonly used npm packages in crypto projects, such as Solana/Web3.js and LottieFiles, to compromise multiple projects' front ends.
• DNS hijacking incidents, including the major compromise of Squarespace, resulted in significant impacts on many hosted sites, such as Compound and Celer.

Continued rise of DPRK Scams​

DPRK-affiliated personnel continue to target trending protocols and high-net-worth individuals in the Web3 space. Their tactics include impersonating legitimate employees to compromise projects, exfiltrate sensitive data, and steal funds over time. Notable incidents include the compromises of DMM Bitcoin and WazirX exchanges. Additionally, they exploit non-technical vulnerabilities to compromise large Total Value Locked (TVL) Web3 methods.

Continued rise of Spoofing Scams​

Scammers have adopted a new tactic of sending small amounts of real money to unsuspecting victims. This involves creating addresses with similar endings to those that users normally interact with and sending a few pennies. They monitor the mempool and quickly generate these addresses to follow up on original transactions. This spoofing technique has been observed on multiple non-EVM chains, including Solana (with over $3 million in losses) and Tron. The largest recorded damage was $68 million on Ethereum in May.

Year-over-Year (YoY)​

General​

In 2024, HashDit monitored $62,895,059 funds loss on BSC. The amounts lost to exploits have continued to drop significantly since 2022, continuing the downward trend of 2023, with a YoY 61% decrease in damages, as seen from the figure below.

Figure 1: Total amount stolen funds (in dollars) on BSC over the last 5 years

In total, there were 149 security incidents on BSC, representing a 64% year-over-year decrease from 2023, dropping even lower than the 2022 incident count of 286. The average number of incidents per month decreased from 34 to 12. Figure 2 shows that the increasing trend of security incidents has finally been broken in 2024 on BSC, which could signify a positive sign and turnaround in the space.

Figure 2: Number of incidents on BSC over the last 5 years

Type of attack vectors​

Analyzing the attack vectors trends based on Financial losses, both Hacks and Scams have dropped significantly from 2023, with Hacks accounting for $50.6m (31% decrease) and Scams accounting for $12.1m (86% decrease) in 2024.

Figure 3: Financial losses per attack vector over the last 5 years

In terms of incident count, both Hacks and Scams have also shown a positive reversal trend from 2023, with 123 Hacks (41% decrease) and 25 Scams (87% decrease) in 2024.

Figure 4: Number of incidents per attack vector over the last 5 years

A comparative analysis of the decrease in percentages reveals a significant reduction in both hacks and scams. This positive trend can be attributed to several key factors. Enhanced security measures on the BSC have played a crucial role in mitigating these threats. The implementation of advanced security protocols and continuous monitoring has made it more difficult for malicious actors to exploit vulnerabilities.

Additionally, users are becoming more vigilant and knowledgeable about potential scams. There is a growing awareness among the community about the importance of conducting thorough due diligence (DD) before investing in new projects. This proactive approach by users, combined with the robust security efforts on BSC, has contributed to a safer and more secure environment in the crypto space.

Type of projects​

This chart represents the type of projects that were exploited since 2020.

Figure 5: Security Incidents per type of project over the last 5 years

It is clear that DeFi projects are still the main targets for crypto hackers, with 104 in 2024, still a noticeable drop from 70% decrease from 2023. Many of these projects are relatively obscure and are generally categorized under decentralized finance (DeFi). They typically involve staking or rewards mechanics, which attract users looking for high returns on their investments. Despite their potential for profitability, the lack of visibility and recognition makes these projects more susceptible to risks and scams. As a result, it is crucial for investors to exercise caution and conduct thorough research before engaging with such DeFi projects.

Chain comparison​

The figure below shows the comparison between the chains with the top funds losses to exploits over the last 4 years.

BSC (in green) has shown positive steps, figures dropping significantly since 2021.

On the other hand, Ethereum (in blue) has continued to be the largest hitting chain since 2021, maintaining its lead at the forefront. At the same time, other chains like BTC (in yellow), Blast (in dark blue) and XRP (in light purple) have shown large increases from 2023.

Figure 6: Biggest financial losses across chains over the last 5 years

2024 in focus​

General​

In total, roughly $62.8 million were lost to 149 security incidents on BSC.

Interestingly, when removing the top 3 largest incidents, the total financial loss drops down to just above $30m, a large 52% drop from the total amount loss of 2024. This signifies that most of the damage is still attributed to 1 or 2 large hitting cases.

Figure 7: Amount of stolen funds in dollars excluding the 3 largest incidents

By observing the quarterly and monthly trends below, there are some interesting observations to be made.

Wallet Drainer Analysis​

In 2024, we closely monitored Drainer operations, observing over 500,000 drainer transactions on BNB Chain, resulting in a total loss exceeding $20 million USD.

The most significant incident occurred on December 11, 2024, when a user lost $8.3 million worth of SolvBTC.BBN and SolvBTC tokens to an Angel Drainer address on BNB Chain. Other incidents did not surpass the $1 million mark, with the second-largest being an $833,000 loss in January and another $830,000 loss in July.

For comparison, on Ethereum, the total drainer amount is much more staggering, exceeding $500 million USD combined. The highest single incident involved $55 million worth of DAI tokens stolen in August 2024, with these funds still residing in the scammer's wallets to date.

This highlights the growing need to educate users on security awareness when signing transactions and to adopt more security tools to aid in understanding what they are signing.

Spoofing Analysis​

In 2024, spoofing and address poisoning scams continued to proliferate. We monitored over 30 groups conducting these scams on Ethereum and BNB Chain, resulting in more than $80 million in losses across all chains. Our analysis revealed that most of these groups have a lifespan of less than one month, with the largest groups (those with the most scam funds invested) operating for more than half a year.

These groups employed various tactics, including:

• Using fake tokens that mimic actual funds transferred.
• Sending 0 amounts of the actual funds transferred.
• Sending small amounts of the actual funds being transferred.

These measures were used to deceive victims and execute scams effectively.

Some of the scam profits were exited through non-KYC platforms like Exch and FixedFloat, or they were bridged to other less traceable chains such as Litecoin or Tron.

Quarter-over-Quarter (QoQ)​

1. On BNB Chain, Q4 sees significant increase in fiat losses compared to the rest of the quarters

Fiat losses surged by 121%, rising from $14.2 million in Q3 to $31.4 million in Q4. In fact, it represented nearly half of the total incident losses in 2024. This significant increase was primarily driven by two major incidents in Q4 2024. The first was the Radiant case, which resulted in losses amounting to $17.8 million. The second involved an individual who fell victim to a Drainer incident, suffering losses of $7.8 million. These two events were among the most damaging losses of the year, contributing substantially to the overall increase in fiat losses.

Figure 8: Financial losses across chains over the last 4 quarters in 2024

2. Across all chains in Web3, the overall losses dropped in Q4 as compared to other quarters. This is likely due to increased security education and awareness among users, even though threat actors continue to proliferate in the Web3 space. Enhanced knowledge and vigilance have empowered users to better protect their assets and avoid scams, contributing to the reduction in overall losses.

Figure 9: Chain comparison fund losses in Q4

Month-over-Month (MoM)​

The average monthly loss is calculated to be ~$5.2m, with 9 out of the 12 months being below this average reference line.

Figure 10: Amount of stolen funds in dollars per month in 2024

In those months above the reference line, the significant increase in fiat loss was due to one or two singular, abnormally large security events. For example, in September, there were two major incidents: the BingXOfficial hot wallet compromise for approximately $6.8 million and the CUT2024CUT price manipulation vulnerability for around $1.45 million. This indicates that, on average, losses per incident are relatively small.

Analyzing the trend in the number of security incidents, the chart shows that the number of cases largely peaked in April, September, and November, with the average being around 12 incidents per month.

Figure 11: Number of projects impacted by security exploits

Interestingly, even though April has the one of the highest number of security incidents at 17, the financial loss only stands at $2.7m which is more than half of September’s data. With a nearly similar count at 18, September’s financial loss is more than double, at $9.4m.

Type of attack vectors​

Out of the 149 security incidents, the majority were attributed to hacks, accounting for 82.55%. Scams made up 16.78%, and improper management (operational issues caused by the team's mismanagement) accounted for 0.67%.

Figure 12: Proportion of different type of exploits

This is synchronous with the financial loss of these security incidents. As shown in Figure 12, hacks resulted in a financial loss of $50.6 million, which is significantly more than the $12.1 million loss from scams.

Figure 13: Financial impact measured in dollars comparing different types of incidents

For further analysis of the specific attack vectors, this figure below displays this against the financial loss in 2024.

Figure 14: Proportion of the funds lost comparing the different type of vulnerabilities

A worrying 49.01% of incidents were attributed to Hot Wallet Compromise, where CEXs or protocols were careless with managing security around their privileged accounts or lacked security awareness. This led to threat actors breaching their infrastructure and obtaining keys to drain funds.

The second largest contributor was Phishing among regular users, who might store substantial amounts of funds in hot wallets without being aware of the threats. Clicking on fake sites can lead to fake signatures being generated, resulting in stolen funds.

The third largest contributor was Private Key Compromise within other entities, highlighting the importance of securing keys properly and following proper security guidelines in both Web2 and Web3 environments.

Type of projects​

When focusing on the project type versus financial loss, 48.64% of financial losses are attributed to DeFi projects. The trend of DeFi continues to lead across all major chains, including BSC. However, some developers might not be well-versed in security when writing their smart contracts, leading to investors bearing the brunt of the compromises.

The second most targeted type were individuals at 14.66%, followed by CEX platforms at 13.51%. Individuals continue to be a main target for scammers, especially with the rise in the crypto market bringing in a new wave of investors whose security awareness may not be strong. Wallets and security extensions play a vital role in protecting these users.

CEX platforms also continue to be targets since they hold large amounts of funds. If the keys are not managed and stored safely, they become easy targets for hackers.

Figure 15: Proportion of funds lost comparing the type of project

Conclusion​

In 2024, we observed a notable shift in the landscape of security incidents. While the number and amount of hacks have dropped, scams are on the rise, highlighting the need for users to be more security aware. Phishing remains a persistent threat, and it is crucial for users to stay vigilant against such tactics.

Our HashDit user products, such as the Chrome extension and Snaps, could have potentially prevented over $25 million in losses. We highly recommend these free products to enhance user security. Additionally, our B2B products, including monitoring, auditing, and prevention tools, will continue to serve the top protocols on BNB Chain, protecting them from threat actors.

Malicious actors will continue to lurk in the background, and we are committed to staying ahead of them for the sake of the Web3 community. BSC remains a strong competitor, outperforming Ethereum in terms of daily active users and transactions. Although 2023 showed better performance in terms of total funds lost to exploits, it is undeniable that scammers and hackers will continue to evolve their methods until stricter measures are in place to hold them accountable.

Within HashDit, we will keep improving by:

• Implementing a comprehensive set of stringent audit guidelines that all top TVL projects must meet before deploying significant features on-chain.
• Collaborating promptly with key stakeholders to conduct in-depth root cause analyses on all major incidents, ensuring similar issues are not present in the top TVL projects.
• Working closely and sharing intel within members to identify potentially fraudulent projects at an early stage, particularly those amassing substantial liquidity.
• Monitoring any malicious activities related to hacks and scams vigilantly and transmitting alerts via numerous channels such as Twitter and Telegram to rapidly inform the community.
• Continually extending HashDit’s influence to the community by regularly publishing articles and reports related to hack and scam techniques, strengthening users' knowledge regarding security awareness in the crypto space.

We remain dedicated to protecting the Web3 community and ensuring a safer environment for all users and protocols.

Appendix​

HashDit​

User-Facing Products​

1. HashDit Chrome Extension: The HashDit Chrome Extension provides an extra layer of protection when interacting with websites involving digital assets. It operates between websites and extension-based wallets like TrustWallet and MetaMask, analyzing transactions, identifying risk factors, and alerting users to potential threats.

2. HashDit MetaMask Snaps: The HashDit MetaMask Snaps offers similar protective features as the Chrome Extension, focusing on showing risks when users are on phishing sites or signing risky transactions. While it has fewer functions compared to the Chrome Extension, it still provides essential security alerts to help users avoid scams.

Business-Facing Products

1. Novel Prevention Product: Our novel prevention product can stop hacks in real-time once any previously set invariants are broken. This proactive approach ensures that any deviations from expected behavior are immediately addressed, preventing potential exploits and safeguarding assets.

2. Monitoring: Our monitoring service detects risky events both on-chain and off-chain. On-chain monitoring includes tracking sensitive events such as ownership changes or malicious upgrades, while off-chain monitoring covers social media compromises and DNS hijacks. This comprehensive monitoring allows for quick responses to minimize financial losses, with alerts shared via multiple channels like Twitter and Telegram.

3. Threat Intelligence Product API: The Threat Intelligence Product API provides a wholesale, all-in-one solution that flags risks associated with addresses or URLs in real-time. By gathering and detecting various types of information, this API offers accurate and timely detection of scam/exploit risks, helping businesses stay ahead of potential threats.

Commitment to Security​

HashDit remains dedicated to improving security for both users and businesses in the Web3 community. By implementing stringent audit guidelines, collaborating with key stakeholders, and sharing intelligence, we aim to create a safer environment for all. Our educational efforts continue to equip builders, investors, and users with the knowledge needed to adopt a security-first mindset, ensuring the Web3 ecosystem becomes a safer place for everyone.

Top 10 Incidents​

1. Radiant

   • Attack Vector: Hot Wallet Compromise
   • Damage: $17,800,000
   • Description: Hacker gained signatures of three owners of an 11-threshold multisig. The attacker deployed a malicious contract (0xf0fc) to drain Radiant's lending pool. Devices were compromised with malware, affecting at least three contributors. The malicious implementation continues to drain funds from users who have approved it.

2. User

   • Attack Vector: Phishing
   • Damage: $8,300,000
   • Description: A user (@0xYuanbo) lost ~$8.3m worth of SolvBTC.BBN & SolvBTC tokens to an Angel Drainer address on BSC due to two transfer transactions signed to scam Create2 addresses. Most funds sent to the Drainer Customer were burned by the Solv Protocol.

3. BingXOfficial

   • Attack Vector: Hot Wallet Compromise
   • Damage: $6,840,000
   • Description: On September 20, BingX's technical team detected abnormal network access, suspecting a hacker attack on their hot wallet. Emergency measures were taken, including asset transfer and withdrawal suspension.

4. ALEXLabBTC

   • Attack Vector: Private Key Compromise
   • Damage: $4,300,000
   • Description: Hacker compromised a key and made a malicious proxy upgrade. The Alex deployer account performed five identical upgrades to the “Bridge Endpoint” contract on BNB Smart Chain, resulting in the removal of approximately $4.3 million.

5. BullcoinBSC

   • Attack Vector: Hot Wallet Compromise
   • Damage: $2,400,000
   • Description: Multisig transferred ownership to a compromised address, which later upgraded the contract with a backdoor. At least three of the project's multisig signer addresses were compromised, likely due to centralization of the keys.

6. MEV bot

   • Attack Vector: Lack of Validation
   • Damage: $2,200,000
   • Description: Hacker invoked the fallback function logic with a specific function selector. Funds were bridged to ETH within nine hours of deployment. Executors included the hacker.

7. NFPrompt

   • Attack Vector: Private Key Compromise
   • Damage: $1,500,000
   • Description: Hackers compromised wallets, including those of NFP’s contract administrators, gaining control of victims' funds, including a portion of NFP treasury and ecosystem fund.

8. CUT2024CUT

   • Attack Vector: Price Manipulation
   • Damage: $1,450,000
   • Description: The $CUT token's price protection mechanism was vulnerable to price manipulation. The exploiter gained extra $CUT tokens and sold them, profiting ~$1.4m from the BUSD-CUT pancake pair.

9. Duelbits

   • Attack Vector: Hot Wallet Compromise
   • Damage: $1,100,000
   • Description: The Duelbits crypto casino and sports betting website was drained. The thief accessed a Duelbits wallet, likely through a private key compromise.

10. CoinsPaid

    • Attack Vector: Hot Wallet Compromise
    • Damage: $1,000,000
    • Description: On July 22, CoinsPaid experienced a hacker attack, likely by the Lazarus group from DPRK.

2024 highlights​

• Our Chrome Extension user base grew exponentially, reaching almost 1,000 users, which is a growth of more than 300% from the start of the year.

• We joined partnerships with critical infrastructure platforms in the space, such as 48Club and Token Pocket, to reduce scams and frauds on BNB Chain.

• Released countless tweets to raise user security awareness, covering topics such as spotting fake Pig Butchering sites, identifying phishing scams like Drainers and Spoofers, and numerous other scam warnings. These tweets amassed over 788,000 views and attracted more than 2,400 new followers to our HashDit X account.

Overview​

This report focuses on security events that occurred on BNB Smart Chain (BSC) in Q3 of 2024. It analyzes the types of projects targeted, the common attack techniques used and the financial losses that resulted from the incidents.

Disclaimer​

The financial data provided here is accurate based on our own monitoring system and based on the $USD amount of the cryptocurrency involved at the time of the incident. Due to the fluctuating price nature of cryptocurrencies, the total amount loss might differ with the current token valuations.

Furthermore, the financial data might not fully reflect the true “exploited amount” of the incident. This is especially true for scams where the total scammed amount is usually mixed with an initial base amount injected by the scam project party.

TL;DR​

1. Q3 sees increase in fiat losses compared to Q2

Fiat losses increased by approximately 50%, rising from $9.1 million in Q2 to $14.2 million in Q3. Interestingly, this increase in losses was observed despite a decrease in the number of hacks, with Q3 experiencing 34 hacks compared to 46 in Q2.

2. BSC ranks second in Q3 fiat losses when compared to other chains

In Q3, BSC (Binance Smart Chain) accounted for 2.8% of the total fiat losses across all chains, ranking second. Ethereum took first place, representing 88% of the total fiat losses. In terms of incident count, BSC also ranked second with 27%, trailing behind Ethereum.

3. Price Manipulation and Lack of Validation bugs were the two most substantial types of exploit, with DeFi type of projects being the most targeted

32% of total fund losses were due to price manipulation attacks, often caused by poorly designed smart contracts relying on liquidity pool prices. The second leading attack vector was lack of validation, accounting for 23.53%, due to developers not checking input validation in smart contracts, leading to compromised contracts. Other issues included reentrancy, spoofing, and rug pulls.

Q3 Comparisons​

BSC Comparisons​

YoY Comparison​

When we compare the data with Q3 of previous years, there is a decreasing trend. Q3 financial losses dropped by a large 68% between 2023 and 2024.

This suggests that the security of the BNB Chain has improved significantly over the years.

Figure 1: Q3 financial losses from 2021 - 2024

2024 Q3 vs 2024 other quarters​

Fiat Losses​

Figure 2: Financial losses across the first 3 quarters in 2024

• Q3 have the highest financial losses in a quarter in 2024

• ~50% increase in amount lost to exploits from Q2 to Q3

Number of Incidents​

Figure 3: Number of incidents across the 3 quarters in 2024

In terms of incident count, that number dropped by 26% from Q2 to Q3 to 34 incidents this quarter.

Notable Trends

Q3 accounted for 45.10% of amount losses in 2024 so far

Figure 4: Amount lost to exploits across the previous quarters in 2024

Chain Comparisons​

Q3 Comparison to Other Blockchains​

Figure 5: Proportion of funds loss across all chains in Q3

As seen in Figure 5, BSC accounts for 2.8% of total funds loss and 27% of total incident count. The top chain affected is Ethereum with 88% of the total losses in Q3 of 2024 and 55% of total incident count

QoQ Analysis​

Fiat Losses

Figure 6: Proportion of incidents across all chains from Q1-Q3 in 2024

Noticeably, Ethereum still had the highest number of financial losses in each quarter of 2024 thus far. Generally, Q2 has the lowest amount of losses in 2024 across all chains, although it had security incidents across all chains in that quarter.

Deep Dive on 2024 Q3 Incidents on BSC​

In total, roughly $14.2 million was lost as a result of security incidents on BSC in Q3. As demonstrated by Figure 7, the month with the greatest losses was October which stands at $9.4 million.

Figure 7: Amount of stolen funds in dollars per month in Q3 of 2024

Figure 8 shows the number of projects impacted by exploits in Q3 .

Figure 8: Number of project impacted by exploits

The highest number of security incidents took place in October. In total, there were 34 incidents on BSC in Q3 2024. Similarly in September, there was the highest number of security incidents at 18.

Attack vectors analysis​

Out of the total 34 security incidents, hacks made up 79.41%. The remaining percentage were a result of scams.

Figure 9: Proportion of types of exploits

Proportional to the attack vector count, the financial impact of hacks was greater as well. The total financial loss of hacks was $12.7m and the total financial loss from hacks was $1.4m, as shown in Figure 10.

Figure 10: Financial impact measured in dollars comparing different types of incidents

This might suggest that there is a good emphasis on scam security for general BSC users.

Specific attack vectors analysis​

Figure 11 shows the specific attack vectors and their corresponding financial losses in Q3 of 2024.

Figure 11: Proportion of funds lost across different types of exploits

In Q3, 32% of the total funds loss were attributed to Price Manipulation attacks. This could be due to poorly designed smart contracts relying on the instantaneous price of liquidity pools, making them easier to manipulate with a large swap trade or flash loans by hackers.

The second leading attack vector was Lack of Validation, which accounted for 23.53%. This is still a main cause of concern as we noticed developers not checking for input validation within poor designed smart contracts. This can result in untrusted calls that result in contracts being compromised.

Loss by Project Type​

When comparing the project type against financial loss, 61.76% of financial losses were attributed to DeFi projects.

The second most targeted type was Unknown contracts at 11.76% which are obscure and unknowing contracts, where their project name could not be identified. This is followed by Individuals at 11.76% which are likely a result of general users being scammed.

Figure 12: Proportion of funds lost against the type of project

The large proportion of fiat losses associated with DeFi projects suggests that DeFi remains the most common type of crypto project on BSC. It also shows how important it is for users to only invest in reputable and well audited projects, and for developers to take precautions for Price Manipulation and Lack of Validation issues.

At the same time, the constant trend of Individuals getting scammed should serve as a critical reminder for users to only sign transactions that they understand and use security plug-ins where suitable.

Top 10 Incidents in Q3 of 2024​

The following were the top 10 security incidents in terms of financial losses in Q3 of 2024.

Figure 13: Top exploits measured in dollars in 2024 Q3 on BNB Smart Chain

BingXOfficial - $6.8 Million Loss​

Attack type: Hot Wallet Compromise

On September 20, 2024, BingXOfficial, a centralized exchange (CEX), experienced a security breach in its hot wallet across multiple chains. On the Binance Smart Chain (BSC), the impact was approximately $6.8 million.

The root cause of the security breach at BingX was likely related to unauthorized access to the exchange's hot wallet. Since hot wallets are connected to the internet, they are inherently more vulnerable to cyberattacks.

MEV Bot - $2.2 Million Loss​

Attack type: Internal Breach

On August 22, 2024, an unknown MEV bot was compromised, resulting in a loss of approximately $2.2 million.

Typically, this MEV bot contract is designed to exploit price differences in liquidity pools. However, the vulnerability in this case was due to a lack of validation of the pool contract supplied within the victim contract. This allowed the attacker to use a fake pool contract to perform a "swap," tricking the contract into transferring funds to the attacker's contract.

Interestingly, only Executors can call the vulnerable function, and the hacker was one of the validated addresses added during the setup. This suggests that an internal breach could be a likely scenario in this case.

CUT2024CUT - $1.4 Million Loss​

Attack type: Price Manipulation

On September 10, 2024, CUT2024CUT, a token DeFi project, was exploited due to a price manipulation attack, resulting in losses exceeding $1.4 million USD on the Binance Smart Chain (BSC).

The CUT project had implemented a vulnerable reward calculation system that depended on the pool reserves. This vulnerability allowed attackers to deplete the liquidity pool (LP) reserves.

User - $1.07 Million Loss​

Attack type: Phishing

Throughout this quarter, we detected multiple instances of users falling victim to phishing attacks, resulting in total losses exceeding $1.07 million.

Two primary types of phishing transactions were observed:

1. Wallet Drainers: Scammers trick users into visiting phishing websites, where they are then deceived into signing transactions that transfer funds directly to the attackers.
2. Spoofing Cases: Users are deceived into transferring funds to a recipient that appears to be legitimate but is actually a copycat.

UPS - $0.52 Million Loss​

Attack type: Price Manipulation

On July 21, 2024, the UPS project was compromised, resulting in a loss of approximately $0.52 million worth of funds.

The root cause of the hack was a vulnerability in the UPS token's transfer mechanism. When transferring tokens to a PancakeSwap pair, the UPS token burns tokens at the pair and calls the "sync" function. The hacker exploited this mechanism to reduce the UPS reserves in the PancakeSwap pair, causing a reserves imbalance. As a result, the UPS reserve became very small, allowing the hacker to drain BUSD from the pair using only a few UPS tokens.

Unknown Token Stake - $0.35 Million Loss​

Attack type: Price Manipulation

On August 6, 2024, an unknown Token Stake contract was exploited due to a price manipulation attack, resulting in a loss of $0.35 million.

The root cause of the exploit was the Token Stake contract's reliance on an instantaneous price oracle. This made it susceptible to price oracle manipulation, allowing the attacker to profit from the Token Stake contract.

XMM - $0.29 Million Loss​

Attack type: Price Manipulation

On September 14, 2024, the XMM project was hacked, resulting in a loss of approximately $0.29 million.

The hacker exploited a flaw in the transfer function that allowed the recipient to mint tokens. This vulnerability enabled the hacker to mint a large amount of XMM tokens at the start of the attack, allowing them to profit by dumping the tokens into the liquidity pool.

Bankroll - $0.23 Million Loss​

Attack type: Business Logic Vulnerability

On September 23, 2024, the Bankroll DeFi project was attacked due to a business logic vulnerability, resulting in a loss of approximately $0.23 million.

The root cause of the attack was a flaw in the BuyFor function, which allowed the invoked contract to be used as the customerAddress. This vulnerability enabled the attacker to transfer WBNB back into the victim contract, inflating the profitPerShare_ value significantly in the distribute routine.

Truflation - $0.23 Million Loss​

Attack type: Malware Scam

On September 25, 2024, the Truflation project, a decentralized infrastructure project, was exploited for approximately $0.23 million due to a malware scam.

The project's multisig wallet had a 1 out of 1 threshold, making it highly vulnerable. The holder of the private key was easily compromised through malware as a result of social engineering. This allowed the malicious actor to scam the team into transferring funds to their account.

Unknown project - $0.2 Million Loss​

Attack type: Reentrancy

On September 25, 2024, an unknown project was exploited for approximately $0.2 million. The root cause was identified as a reentrancy vulnerability.

Interestingly, after the initial attack transaction, the deployer invoked the victim contract's emergencyWithdrawUSDT function multiple times, each for a small amount rather than withdrawing all the funds at once. This allowed the attacker to make small, repeated profits.

Conclusion​

Below we have some final tips for investors and developers:

For investors:​

1. Understand What You're Signing: Never blindly sign random signatures or transactions. Always ensure signatures are from official websites.
2. Verify Official Websites: Double-check that you are on the official website of the DApp.
3. Exercise Caution with New/Trending Projects: Be wary of projects that guarantee high APYs or use MEV bots. Always verify the project team’s authenticity.
4. Use Multiple Wallets: Utilize different wallets for various activities—hot wallets for frequent transactions and cold wallets for storing high-value funds.
5. Interact with Open-Source Contracts: Ensure you are interacting with open-source contracts and revoke approval once the interaction is complete.
6. Check Risk Warnings: Use tools like Metamask Snaps and HashDit Extension to check risk warnings of transactions.
7. Heed Warnings on Trust Wallet and PancakeSwap: Pay attention to warnings about phishing sites, malicious contracts, and dangerous tokens. If flagged as high risk, it is strongly advised to stay away.

For BNB Chain Developers:​

1. Verify & Open-Source Contracts: Ensure all relevant contracts are verified and open-sourced on-chain to maintain transparency and trust.
2. Conduct Audits: Have the project audited by at least two well-known security companies and address all identified issues, including newly added code.
3. Implement a Bug-Bounty Program: Encourage the community to help maintain the security of the code by offering rewards for identifying vulnerabilities.
4. Prioritize Security: Run sufficient testing, stress-testing, and simulations for scenarios such as adverse token price fluctuations and edge cases.
5. Prevent Centralization Risks: Use multi-signature wallets instead of a single EOA wallet for operations.
6. Minimize Contract Upgradeability: Limit contract upgradeability and apply changes only when necessary.
7. Secure Fund Storage: Ensure funds are stored securely through proper key management and fund distribution.
8. Implement Safeguards: Formulate an incident response plan and introduce time locks or pausing mechanisms within smart contracts to mitigate the impact of hacks.
9. Monitor System Parameters: Continuously monitor system parameters, such as the exchange rate of tokens.

About Hashdit​

HashDit’s core mission is to provide the essential threat intelligence for the everyday crypto investors to make informed decisions. Our methodology includes a variety of automated and manual techniques to evaluate a DApp project.

Hashdit Products:

• HashDit extension: A chrome web extension which utilizes the HashDit API to warn users for potential risky urls and risky addresses. HashDit’s pop-up warning window is displayed on the frontend to immediately alert users to take extra caution.
• Risk assessment: All-in-one collection of security rating framework, auto-scan tools, and corresponding APIs, which are able to deliver accurate detection for potential risks based on an address / dApp / transaction / signature. This is integrated with core platforms like Trust Wallet and PancakeSwap, to leverage their reach and protect more users.
• Audit service: Comprehensive code audits following extensive and detailed best practices for smart contracts and discovering code loopholes/security vulnerabilities before they are deployed on-chain, guaranteeing users’ safety on BSC.
• Monitoring: The combination of real-time on-chain monitoring, off-chain social media monitoring, and public alerts via Twitter makes this service a valuable tool for enhancing security and awareness in the blockchain space. By detecting sensitive events and compromised social media accounts early, we can quickly respond to minimize financial losses and provide immediate guidance for account recovery. This comprehensive approach ensures that both financial transactions and communication channels are protected, helping to build transparency and trust within the community.
• Prevention: Transaction Prevention Solution, a proactive defense strategy for threat detection and handling. This solution enables project teams to promptly address attacks, control fund disposal, secure user assets, and establish a robust multi-layer protection system. It currently includes four strategies that can be used in combination, aiming to provide a comprehensive risk recognition and risk disposal transaction prevention system
• Education: The goal is to share security knowledge for builders, investors and users in the Web3 community. With all the players in the industry equipped with the security knowledge needed and adopting a security-first mindset, only then will the Web3 ecosystem be a safer place for everyone.

If you have any doubts or concerns about a specific project, contract address, transaction, or risk score, please do not hesitate to reach out to our team for assistance.

Introduction​

In this monthly series, HashDit is sharing the monthly security incidents in the crypto space and what we can learn from them. For this July 2024 edition, the total losses amounted to $282.5 million, showing a 25% decrease compared to July 2023 ($377.2 million).

In this sharing, we focus on the DApps incidents. Below are the top 5 DApps incidents that DApp Developers should pay attention to.

Top 5 DApps incidents​

Li.Fi protocol - $10m - Lack of Validation​

Chain: Ethereum

Li.Fi protocol is a bridge aggregation protocol with DEX connectivity and cross-chain data messaging capabilities. On July 16 2024, in this incident, the GasZipFacet contract was upgraded, introducing a vulnerable code which resulted in a compromise of approximately $10 million.

Interestingly, a similar exploit 2 years ago, when Li.Fi was also compromised for the same vulnerability.

Root cause: The primary cause of the incident was no validation of swapCallData in the LibSwap.sol library. This calldata can be externally controlled in the outer function depositToGasZipERC20 method. This allows arbitrary calls whereby funds approved to this victim contract can be abused and stolen.

Onchain information:

Hack tx

Code snippet:

Rho Markets - $7.6m - Oracle Manipulation​

Chain: Scroll

Rho Markets is a liquidity platform built on Scroll, based on an overcollateralized lending model (which is a fork of Compound Finance). On July 19, 2024, in this incident, a misconfigured oracle provided the wrong price of $ETH for the rETH market ($BTC price was fed instead). Thankfully, an MEV bot front ran the original hacker and was able to safeguard the $7.6 million and return them back to the project party.

Root cause: On July 16, 2024, after updating the smart contract for a new market, Rho Markets found that ETH and BTC price oracles were giving contradictory feeds due to a deployment script misconfiguration. This reversed BTC and ETH prices, creating arbitrage opportunities for MEV bots. Incorrect oracle pricing led to assets(USDC, USDT, wstETH, STONE, and wrsETH) being borrowed up to their caps.

Onchain information:

Oracle misconfiguration tx

Hack tx

Transaction snippet:

DoughFina - $1.8m - Lack of Validation​

Chain: Ethereum

On July 12, 2024, DoughFina, a DeFi project, had its ConnectorDeleverageParaswap contract compromised, resulting in a loss of ~$1.8 million. In this attack, there was a lack of validation issue which allowed anyone to withdraw funds from the vulnerable contract.

Root cause: The primary cause of the incident was that there is lack of validation in the flash loan call back data which leads to a WETH transfer.

After invoking the flashloan method of the ConnectorDeleverageParaswap contract, the flash loan call data allowed multiple operations to be executed afterwards.

This allowed the hacker to burn AaveWETH from one of Dough’s pools. WETH is then approved to the Victim contract which can then be transferred from out to the hacker.

Onchain information:

Hack tx 1

Hack tx 2

Code snippet:

Minterest - $1.4m - Exchange rate manipulation​

Chain: Mantle

Minterest is a blockchain cross-chain DeFi lending protocol that redistributes 100% of the value captured back to users. On July 15, 2024, its MUSDYToken_Mantle contract was compromised, leading to an estimate loss of ~$1.4m on Mantle (ETH and Taiko not affected).

Root cause: The exchange rate of the Minterest is dependent on the token cash balance (updated immediately during token transfers, instead of at the end of the state).

Reentrancy vulnerability in which an attacker could loan out tokens that they had previously just borrowed from the protocol.

Onchain information:

Hack tx

Code snippet:

Monoswap - $1.3m - Social Engineering​

Chain: Blast

Monoswap is a community-driven and yield-focused v3 Decentralized Exchange built to facilitate the Blast ecosystem.. On the 24th of July, 2024, due to a social engineering exploit of one of its developers, the deployer wallet was compromised, resulting in financial losses approximating $1.3 million in ETH.

Root cause: One of Monoswap developers installed phishing software from https[:]//kakaocall[.]kr. The scammer pretended to be a VC institution to deceive the developer's trust and carried out phishing attacks.

Onchain information:

Hack tx 1

Hack tx 2

Hack tx 3

Transaction snippet:

Key lessons for developers​

1. Given the risk of social engineering attacks, it is essential for employees to install only trusted software and exercise heightened caution when working with third parties. Specifically, be vigilant for potential red flags, including:

   • Educate and Train Team Members:

     • Awareness Programs: Regularly conduct training sessions to educate team members about the various types of social engineering attacks, such as phishing, vishing (voice phishing), and smishing (SMS phishing).

     • Simulated Attacks: Perform simulated social engineering attacks to test and improve the team's response to real threats.

     • Trusted Software: Always verify the source before installing any software. Ensure that you download applications only from official websites or trusted platforms, and avoid using pirated or cracked versions. Additionally, check for reviews and ratings, and consult with your IT department if you are unsure about the legitimacy of the software.

   • Secure Communication Channels:

     • Encrypted Communication: Use encrypted communication channels for sensitive information and authentication processes.

     • Verification Protocols: Establish protocols for verifying the identity of individuals before sharing sensitive information or performing critical actions.

   • Limit Access and Permissions:

     • Role-Based Access Control (RBAC): Implement RBAC to ensure that team members only have access to the information and systems necessary for their role.

     • Regular Audits: Conduct regular audits of access permissions to ensure they are up-to-date and appropriate.

2. Input validation is a crucial process - it's essential to verify all potential user inputs, especially when these inputs affect changes to the state of the system. This holds particularly true in the below scenarios:

   • Calldata Parameters: Given that attackers have the ability to craft any data, extra validation steps must be in place for calldata parameters.

   • User Approvals: During the process where the protocol contract manages users' approvals, meticulous input checks are paramount to prevent potential malicious activities.

3. To guard against price manipulation, it's essential to ensure that updated prices cannot be influenced to reflect unexpected values. Oracles, both on-chain and off-chain types, can be employed by developers. Here's how:

   • Set Boundaries: Implementing limits can block prices from being abruptly manipulated to an impossible value, regardless of the oracle type in use.

   • Fallback Oracle: Integrate a secondary oracle as a fallback measure. This ensures that if the initial oracle fails, there is a backup in place to verify the consistency of prices. By doing so, it ensures continuous, reliable price feeds, and safeguards against single point of failure.

   • Test scripts: Test scripts can be designed to check the integrity of the data being fed into the Oracle system. By running these scripts, you can ensure that the data is accurate, complete, and consistent with the expected format and values. This helps in identifying and correcting any discrepancies early in the process.

4. Tips to Prevent Exchange Rate Manipulation:

   • Educate and Train Team Members: Use multiple, independent oracle sources to fetch exchange rates. Aggregating data from various sources can help ensure accuracy and reduce the risk of manipulation from a single compromised source.

   • Use Strong 2FA Mechanisms: Implement validation checks to ensure the consistency and accuracy of exchange rate data. Cross-verify rates with other reliable sources to detect anomalies.

   • Monitor and Respond to Suspicious Activity: Ensure that exchange rate data is transmitted securely using encryption protocols. This helps prevent interception and tampering of data during transmission.

   • Secure Communication Channels: In the context of exchange rate systems, a reentrancy attack could be particularly damaging. For example, if an exchange rate contract is vulnerable to reentrancy, an attacker could exploit this to manipulate the exchange rates.

     • Checks-Effects-Interactions Pattern: Ensure that state changes are made before any external calls. This reduces the risk of reentrancy attacks.

     • Reentrancy Guards: Implement reentrancy guards, such as mutexes, to prevent multiple calls to a function before the first call is resolved.

Feel free to contact us at support@hashdit.io for any support needed! Stay safe!

Hashdit 2024 BNB Smart Chain (BSC) H1 Security Report

Overview​

This report focuses on security events that happened on BSC in 2024 H1, analyzing the type of projects targeted and sharing the common attack techniques used in 2024 H1, with respect to the financial loss of the incidents.

Disclaimer​

The financial data provided here is accurate based on our own monitoring system and based on the $USD amount of the cryptocurrency involved at the time of the incident. Due to the fluctuating price nature of cryptocurrencies, the total amount loss might differ with the current token valuations.

Furthermore, the financial data might not fully reflect the true “exploited amount” of the incident. This is especially true for scams where the total scammed amount is usually mixed with an initial base amount injected by the scam project party.

2024 H1 in focus​

General​

In 2024 H1, approximately $17.29 million were lost to 73 security incidents on BSC. By observing the monthly chart below, the months with the top amount loss were May, March followed by January. The highest number of security incidents took place in April at 17.

Figure 1: Amount of stolen funds in dollars and number of incidents per month in 2024 H1

Against other chains​

Figure 2: Financial Loss and number of exploits across chains for 2024 H1 (Smaller chain incidents are grouped under “Others”)

In the first half of 2024, BSC recorded $17.29 million in losses across 73 incidents, accounting for 1.4% of the total losses. Among all blockchains, BSC ranked 8th in terms of financial losses and 2nd in the number of exploits.

In contrast, Ethereum experienced the highest losses and the greatest number of attacks. Continuing the trend from 2023, Ethereum remained the blockchain with the largest loss amount in the first half of 2024. There were 208 exploits on Ethereum, resulting in $535 million in losses, which represented 43% of the total losses.

With H1 previous years​

When we compare the data with H1 of previous years, there is a decreasing trend of financial losses (excluding 2020), which can signify that the security posture of BNB Chain has improved over the years.

Figure 3: Financial Loss across the previous H1 of 2020 - 2024

In 2021, the decentralized finance (DeFi) market experienced unprecedented growth, with numerous protocols launching without adequate security measures. This lack of security awareness allowed malicious actors to exploit vulnerabilities.

Since then, there has been a stronger emphasis on security for DeFi protocols, leading to a significant reduction in impactful exploits. As a result, financial losses in the first half of 2024 dropped by 83% compared to the same period in 2023 ($101 million), marking a substantial improvement. Attack vectors analysis

Out of the 73 security incidents, hacks take up 80.82%, while 19.18% are scams.

Figure 4: Proportion of different type of exploits

This correlates to the financial loss of hacks and scams in the first half of 2024. The total financial loss of hacks ($14.9m) is nearly 7x that of notable scams ($2.3m), as shown below in Figure 5 below.

Figure 5: Financial impact measured in dollars comparing different types of incidents

Specific attack vectors analysis​

Figure 6 displays the specific attack vectors against its number of exploits in 2024 H1.

Figure 6: Proportion of the funds lost comparing the different type of vulnerabilities

Looking at the breakdown of attack vectors, 35% of the attacks were attributed to price manipulation vulnerabilities. The second most common attack vector was due to a lack of validation, while the third most common attack vector was private key compromise, accounting for 8.15% of the attacks.

Loss by Project Type​

When focusing on the project type vs financial loss, 32.87% of financial loss are attributed to DeFi projects.

The 2nd most project type targeted was Bridge projects at 29.61%, followed by CEX or Centralized Exchanges at 9.57%.

Figure 7: Proportion of funds lost comparing the type of project

Top 10 incidents in 2024 H1​

The following were the top 10 security incidents in terms of financial loss in 2024 H1.

Figure 8: Top exploits measured in dollars in 2024 H1 on the BNB Smart Chain

The top 10 exploits resulted in a total loss of $12.98 million. Notably, 7 out of these 10 incidents were due to private key compromises, which collectively accounted for $9.91 million, representing a significant 76% of the total losses. This highlights a concerning trend in the nature of exploits, emphasizing the critical need for enhanced security measures to protect private keys.

AlexLabBTC - $4.3 Million Loss​

Attack type: Private key compromise

On May 15, the AlexLabBTC bridge on Binance Smart Chain (BSC) was compromised. The attacker gained control of the bridge upgrader role's key and executed a malicious proxy upgrade. This upgrade introduced a harmful withdrawal method, which allowed the hacker to drain the bridge's funds.

User - $1.54 Million Loss​

Attack type: Social Engineering and Phishing

In the first half of the year, users on Binance Smart Chain (BSC) have incurred losses amounting to at least $1.54 million in cryptocurrency. These losses are predominantly attributed to social engineering and phishing attacks, which have been disseminated through fake social media accounts, fraudulent websites, and phishing emails. A significant contributor to these attacks is Inferno Drainer, a malicious wallet drainer that specifically targets and steals funds from ordinary users.

NFPrompt - $1.5 Million Loss​

Attack type: Private key compromise

On March 14, NFPrompt, a DeFi protocol, experienced a security breach. The attack targeted one of its Swap contracts containing USDT and NFP. The hacker compromised the owner's private key, enabling them to invoke an owner-privileged withdrawal function. This allowed the attacker to retrieve all the funds held in the contract.

Duelbits - $1.1 Million Loss​

Attack type: Hot wallet compromise

On February 14, the gambling platform Duelbits was attacked, resulting in the theft of approximately $1.1 million worth of cryptocurrency. The stolen funds were subsequently bridged to Ethereum and deposited into Tornado Cash. The primary cause of the breach was the compromise of a Duelbits hot wallet.

CoinsPaid - $1.0 Million Loss​

Attack type: Hot wallet compromise

On January 6, the cryptocurrency exchange CoinsPaid was attacked, resulting in the theft of approximately $1 million worth of BNB funds.

XBridge - $0.82 Million Loss​

Attack type: Wrong Proxy Upgrade

On April 24, XBridge, a product of SaitaChainCoin, was attacked, resulting in a total loss of approximately $0.82 million. The breach occurred due to the project team introducing an incorrect mapping, which allowed anyone to assume a privileged role and withdraw tokens from the bridge contract.

PolyhedraZK - $0.76 Million Loss​

Attack type: Private key compromise

On March 13, PolyhedraZK, an infrastructure project, was compromised, resulting in a loss of approximately $0.76 million. The hacker gained control of the key for the bridge upgrader role and executed a malicious proxy upgrade. This upgrade introduced a malicious withdrawal method, allowing the attacker to drain the bridge funds.

FinanceChainge - $0.71 Million Loss​

Attack type: Lack of validation

On April 15, FinanceChainge was attacked, resulting in a loss of $0.71 million. The breach was primarily due to a validation bug in a contract, which allowed the hacker to steal approved funds.

BitForex - $0.66 Million Loss​

Attack type: Hot wallet compromise

On February 26, the cryptocurrency exchange BitForex was compromised, resulting in the theft of approximately $0.66 million worth of funds.

SerenityShield - $0.59 Million Loss​

Attack type: Private key compromise

On February 27, the infrastructure project SerenityShield had one of its hot wallets compromised, which resulted in approximately $0.59 million worth of funds stolen.

Conclusion​

In the first half of 2024, total losses caused by hacks, phishing scams, and rug pulls dropped to $17.2 million, compared to $101 million in the same period in 2023. This significant reduction indicates an overall improvement in the security situation on Binance Smart Chain (BSC).

In 2023, the most damaging attack vector was rug pulls. However, in 2024, the most damaging attacks have shifted to price manipulation. This change underscores the critical need for web3 projects to avoid reliance on the instantaneous price of liquidity pools and not depend solely on the balance of tokens in a contract. It is essential to consider the risks associated with flash loans and direct transfers that can impact token prices. To enhance security, projects should consider using entity oracles like Chainlink for a secure price feed.

Below we have some final tips for investors and developers:

For investors:

1. Understand What You're Signing: Never blindly sign random signatures or transactions. Always ensure signatures are from official websites.
2. Verify Official Websites: Double-check that you are on the official website of the DApp.
3. Exercise Caution with New/Trending Projects: Be wary of projects that guarantee high APYs or use MEV bots. Always verify the project team’s authenticity.
4. Use Multiple Wallets: Utilize different wallets for various activities—hot wallets for frequent transactions and cold wallets for storing high-value funds.
5. Interact with Open-Source Contracts: Ensure you are interacting with open-source contracts and revoke approval once the interaction is complete.
6. Check Risk Warnings: Use tools like Metamask Snaps and HashDit Extension to check risk warnings of transactions.
7. Heed Warnings on Trust Wallet and PancakeSwap: Pay attention to warnings about phishing sites, malicious contracts, and dangerous tokens. If flagged as high risk, it is strongly advised to stay away.

For developers:

1. Verify & Open-Source Contracts: Ensure all relevant contracts are verified and open-sourced on-chain to maintain transparency and trust.
2. Conduct Audits: Have the project audited by at least two well-known security companies and address all identified issues, including newly added code.
3. Implement a Bug-Bounty Program: Encourage the community to help maintain the security of the code by offering rewards for identifying vulnerabilities.
4. Prioritize Security: Run sufficient testing, stress-testing, and simulations for scenarios such as adverse token price fluctuations and edge cases.
5. Prevent Centralization Risks: Use multi-signature wallets instead of a single EOA wallet for operations.
6. Minimize Contract Upgradeability: Limit contract upgradeability and apply changes only when necessary.
7. Secure Fund Storage: Ensure funds are stored securely through proper key management and fund distribution.
8. Implement Safeguards: Formulate an incident response plan and introduce time locks or pausing mechanisms within smart contracts to mitigate the impact of hacks.
9. Monitor System Parameters: Continuously monitor system parameters, such as the exchange rate of tokens.

Hashdit is a leading Web3 security firm dedicated to monitoring and protecting against hacks and scams. Our mission is to deliver top-tier products that safeguard users and assist developers within the Web3 space.

If you have any doubts or concerns about a specific project, contract address, transaction, or risk score, please do not hesitate to reach out to our team for assistance.

Introduction​

In this monthly series, HashDit is sharing the monthly security incidents in the crypto space and what we can learn from them. For this June 2024 edition, the total losses amounted to $56.4 million, showing a 276% increase compared to June 2023 ($15 million).

In this sharing, we focus on the DApps incidents. Below are the top 5 DApps incidents that DApp Developers should pay attention to.

Top 5 DApps incidents​

Uwulend - $23.7m - Price Manipulation​

Chain: Ethereum

Uwulend is a DeFi protocol where users can participate as depositors, borrowers or LP stakers. Depositors provide liquidity to the market to earn a passive income, while borrowers are able to borrow in an overcollateralized (perpetually) fashion. On June 10 2024, in this incident, the Market contracts used an unreliable averaged-out oracle which resulted in an initial compromise of $20 million.

After the project paused and unpaused the protocol, they were once again exploited for another $3.7 million just 3 days later.

Root cause: The price oracle used took 11 different prices, and used the median price as the price oracle. However, 5 of these prices were spot prices and directly under the control of the attacker. This meant that only one EMA price needed to be manipulated.

The second issue is that the input prices are in USDE, but the oracle output is in sUSDE, which currently trades around 1.08. The oracle converts between them with an owner controlled conversion factor. This conversion was set to 1.03 three months ago, and has been steadily more wrong over time as the price of sUSDE goes up with yield.

Onchain information:

Hack tx

Code snippet:

Velocore - $6.8m - Lack of validation​

Chain: Linea & Zksync

On the 2nd of June, 2024, Velocore is a Layer-2 protocol that leverages ZK technology to enhance Ethereum scalability. Due to a Lack of validation vulnerability in the smart contract, Velocore experienced a security breach on June 2nd, 2024, resulting in financial losses approximating $6.8 million in ETH.

Root cause: The root cause of this compromise was due to vulnerabilities within the Balancer-style CPMM pool contract, specifically the ‘velocore__execute’ function. The vulnerability here is that effectiveFee1e9 was allowed to exceed 100% - that is 1e18 (take note of the ‘unchecked’ block). This resulted in an underflow, changing a withdrawal into a large deposit.

Onchain information:

Hack tx

Malicious upgrade tx

Code snippet:

Loopring - $5m - Social Engineering​

Chain: Ethereum

Loopring is a zkRollup Layer 2. It allows for high-throughput, low-cost trading and payment on Ethereum. On June 9, 2024, in this attack, some Loopring Smart Wallets were targeted in a security breach. Subsequently, the attacker transferred assets out of the affected wallets. This resulted in a loss of approximately $5 million across the wallets.

Root cause: The attack succeeded by compromising Loopring's 2FA service, allowing the hacker to impersonate the wallet owner (by obtaining the right signature) and gain approval for the Recovery from the Official Guardian.

Onchain information:

Hack tx

Code snippet:

Bazaar - $1.4m - Lack of Validation​

Chain: Blast

On June 10, 2024, Bazaar, a DeFi project, had its BazaarVaultBlast contract compromised, resulting in a loss of ~$1.4 million. In this attack, there was a lack of validation issue which allowed anyone to withdraw funds from the vulnerable contract.

Root cause: The vulnerable function exitPool() did not validate its caller, which means that a malicious actor could invoke this method and parse another user’s balance to withdraw their funds to himself.

Onchain information:

Hack tx

Code snippet:

Holograph - $1.3m - Insider Attack​

Chain: Ethereum

Holograph is an omnichain tokenization protocol, enabling asset issuers to mint natively composable omnichain tokens. On June 13, 2024, the incident involved a misused HLG created on Mantle that was activated through Layerzero bridge. There was a Falsified packet that was executed on Mantle which resulted in a large mint of 1 billion HLG tokens on Ethereum, valued around $1.3 million at the time.

Root cause: It was a private key compromise that was later on confirmed by Holograph, this was an insider attack. A former contractor exploited Holograph Protocol to mint additional HLG. The malicious actor deployed an unverified contract on Mantle, which was used to mint additional HLG.

Onchain information:

Large mint tx

Mantle packet tx

Transaction snippet:

Key lessons for developers​

1. In light of potential insider compromises, it's crucial to apply thorough background checks for new employees. Specifically, keep an eye out for potential red flags including:

   • Preference for certain platforms: Malicious developers seem to favor using Github, often impersonating user profiles such as SuperTalentedDev726 or CryptoKnight415.

   • Use of numbers: Both email addresses and Github usernames often contain numerical sequences. It's suspected they use this as a method for tracking the identities they impersonate.

   • Asian identities: There's a tendency toward choosing Japanese (and possibly Korean) identities, often claiming prior education in Japan.

   • Prominent educational background: The falsified credentials often include elite universities in Japan, Hong Kong, and Singapore. Such institutions may include Singapore State University, Nanyang Technological University, University of Hong Kong or Hong Kong University of Science and Technology.

   • Codebase theft: While not always the case, these imposters often steal existing projects from GitHub and recondition the commit messages to reflect their assumed usernames.

   • Multiple applications: They tend to apply repeatedly for the same job, resorting to multiple email addresses for their submissions.

   • Premature expertise: They often claim experience in Solidity/EVM too early (such as in 2015), which is an unlikely scenario giving the nascent state of blockchain technology at the time.

2. To guard against price manipulation, it's essential to ensure that updated prices cannot be influenced to reflect unexpected values. Oracles, both on-chain and off-chain types, can be employed by developers. Here's how:

   • Set Boundaries: Implementing limits can block prices from being abruptly manipulated to an impossible value, regardless of the oracle type in use.

   • Fallback Oracle: Integrate a secondary oracle as a fallback measure. This ensures that if the initial oracle fails, there is a backup in place to verify the consistency of prices. By doing so, it ensures continuous, reliable price feeds, and safeguards against single point of failure.

3. Input validation is a crucial process - it's essential to verify all potential user inputs, especially when these inputs affect changes to the state of the system. This holds particularly true in the below scenarios:

   • Calldata Parameters: Given that attackers have the ability to craft any data, extra validation steps must be in place for calldata parameters.

   • User Approvals: During the process where the protocol contract manages users' approvals, meticulous input checks are paramount to prevent potential malicious activities.

4. Here are five key tips to protect against social engineering attacks that compromise 2FA for Web3 protocol teams:

   • Educate and Train Team Members

     • Awareness Programs: Regularly conduct training sessions to educate team members about the various types of social engineering attacks, such as phishing, vishing (voice phishing), and smishing (SMS phishing).

     • Simulated Attacks: Perform simulated social engineering attacks to test and improve the team's response to real threats.

   • Use Strong 2FA Mechanisms

     • Hardware Tokens: Encourage the use of hardware-based 2FA tokens (e.g., YubiKey) instead of SMS-based 2FA, which is more susceptible to SIM swapping attacks.

     • App-Based 2FA: If hardware tokens are not feasible, use app-based 2FA solutions like Google Authenticator or Authy, which are more secure than SMS.

   • Monitor and Respond to Suspicious Activity

     • Anomaly Detection: Implement systems to detect and alert on unusual login attempts or behavior that could indicate a compromised account.

     • Immediate Response: Have a clear incident response plan in place to quickly address and mitigate any suspected social engineering attacks.

   • Secure Communication Channels

     • Encrypted Communication: Use encrypted communication channels for sensitive information and authentication processes.

     • Verification Protocols: Establish protocols for verifying the identity of individuals before sharing sensitive information or performing critical actions.

   • Limit Access and Permissions

     • Role-Based Access Control (RBAC): Implement RBAC to ensure that team members only have access to the information and systems necessary for their role.

     • Regular Audits: Conduct regular audits of access permissions to ensure they are up-to-date and appropriate.

Feel free to contact us at support@hashdit.io for any support needed! Stay safe!

Introduction​

In this monthly series, HashDit is sharing the monthly security incidents in the crypto space and what we can learn from them. For this May 2024 edition, the total losses mounted up to $92.3 million, showing a 16% increase compared to May 2023.

In this sharing, we focus on the DApps incidents. Below are the top 5 DApps incidents that DApp Developers should pay attention to.

Top 5 DApps incidents​

GoGalaGames - $21.7m - Private Key Compromise​

GoGalaGames is a GameFi protocol that allows players to earn cryptocurrencies and non-fungible tokens (NFTs) through gameplay. In this incident, its minting role’s private key was compromised, leading to a mint of 5,000,000,001 GALA tokens, an estimated loss of ~$222m on ETH. Interestingly, only a portion of GALA tokens were swapped for ETH, amounting to an estimate of 5913 ETH or $22m USD.

Thankfully, funds have since been returned and sent to an address termed as Gala Fund Recovery. Also, the excess GALA tokens have been burned.

Root cause: The hacker was able to compromise the private key of the original Minter account. It is unclear if it was an internal or external attack.

Onchain information:

Mint tx

Code snippet:

SonneFinance - $20m - Empty Market Attack​

Sonne Finance is a decentralized lending protocol for individuals, institutions and protocols to access financial services. It is a permissionless, open source and Optimistic protocol serving users on Optimism. Users can deposit their assets, use them as collateral and borrow against them. In this attack, the hacker made use of a mislapse in the protocol’s market configuration to execute an empty market attack.

Root cause: Sonne was aware of the empty market bug, and planned to:

• timelock add a market
• user add funds
• timelock open up the market for use.

It would work, as long as the order was followed. However, they scheduled the supportMarket operation independently, instead of using scheduleBatch. Additionally, they opened the EXECUTOR_ROLE to everyone. This essentially allowed anyone to execute the operations in any order.

The exploited solVELO market was deployed 4 days ago without any liquidity, and added to the Unitroller 2 days later after timelock. As such, this empty market was abused with direct donation to borrow funds from other markets with liquidity.

Onchain information:

Hack tx 1

Hack tx 2

Code snippet:

ALEXLabBTC - $4.3m - Private Key Compromise​

On May 15, 2024, ALEXLabBTC, a DeFi project, had an unverified contract compromised, after a malicious upgrade. The potential loss was ~$12m, however the attacker was thankfully inexperienced. The attacker was successfully able to transfer around 13.8 million STX (~$2 million) on the Stack BTC layer-2 chain.

However, on BSC where the potential damage was $4.3m, a white hat was able to secure funds, and eventually returned all 100% to the project team. On ETH, the exploiter tried to steal assets notionally worth around $5 million, but failed to do so. ALEX Lab later announced they were able to recover or secure around $4.5 million of those assets (through CEX).

Root cause: Using compromised private keys obtained via a phishing attack. The exploiter was able to upgrade the code to a malicious logic contract and drain some assets from the ALEX protocol.

Onchain information:

Hack tx

Malicious upgrade tx

Code snippet:

Pump.fun - $1.9m - Insider Attack​

Pump.fun is a Solana Based Memecoin Launchpad that allows users to deploy their own Solana tokens. The incident involved a former employee gaining pump.fun's admin privileges, resulting in the misappropriation of approximately 12,300 SOL, valued around $1.9 million at the time.

Root cause: A former employee, illegitimately taken access of the withdraw authority using their privileged position at the company, used flash loans on a Solana lending protocol.

The loans were used to borrow SOL to buy out as many memecoins until they hit 100% on their bonding curves, which allowed the exploiter to gain liquidity to repay the flash loans. This affected roughly $1.9 million out of a total of $45 million in liquidity within the bonding curve contracts during a specific timeframe.

Onchain information:

Hack tx

Code snippet:

NORMIE - $800k - Price Manipulation​

On the 26th of May, 2024, the Base network suffered a damaging exploit targeted at the memecoin, NORMIE. Due to a vulnerability in the smart contract, there was an unfortunate loss of approximately 224.98 ETH.

Root cause: The fundamental catalyst for the exploit was a flaw in the smart contract logic. This flaw granted the attacker the capability to trick the contract into acknowledging their address as a privileged one. This deceptive maneuver allowed them to mint tokens without authorization, circumventing crucial security measures, and consequently leading to a significant financial loss.

Onchain information:

Hack tx

Code snippet:

Key lessons for developers​

1. In light of potential insider compromises, it's crucial to apply thorough background checks for new employees. Specifically, keep an eye out for potential red flags including:

   • Preference for certain platforms: Malicious developers seem to favor using Github, often impersonating user profiles such as SuperTalentedDev726 or CryptoKnight415.

   • Use of numbers: Both email addresses and Github usernames often contain numerical sequences. It's suspected they use this as a method for tracking the identities they impersonate.

   • Asian identities: There's a tendency toward choosing Japanese (and possibly Korean) identities, often claiming prior education in Japan.

   • Prominent educational background: The falsified credentials often include elite universities in Japan, Hong Kong, and Singapore. Such institutions may include Singapore State University, Nanyang Technological University, University of Hong Kong or Hong Kong University of Science and Technology.

   • Codebase theft: While not always the case, these imposters often steal existing projects from GitHub and recondition the commit messages to reflect their assumed usernames.

   • Multiple applications: They tend to apply repeatedly for the same job, resorting to multiple email addresses for their submissions.

   • Premature expertise: They often claim experience in Solidity/EVM too early (such as in 2015), which is an unlikely scenario giving the nascent state of blockchain technology at the time.

2. To guard against price manipulation, it's essential to ensure that updated prices cannot be influenced to reflect unexpected values. Oracles, both on-chain and off-chain types, can be employed by developers. Here's how:

   • Set Boundaries: Implementing limits can block prices from being abruptly manipulated to an impossible value, regardless of the oracle type in use.

   • Fallback Oracle: Integrate a secondary oracle as a fallback measure. This ensures that if the initial oracle fails, there is a backup in place to verify the consistency of prices. By doing so, it ensures continuous, reliable price feeds, and safeguards against single point of failure.

3. Keys should be properly secured, are rotated regularly and have some level of decentralization. Adopt a zero-trust model.

4. For projects utilizing lending protocols:

   • When deploying a new market (especially for Compound / Aave v2 forks), ensure that it is first initialized with 0 Collateral Factor and deploy with small deposit to lock dead shares.
   • Disallow deposits when the pool price is out of the base range of liquidity.
   • Increase precision on price change thresholds and deposit ratios.
   • For those allowing single-sided pool deposits, add a conditional statement to prevent deposits of any ratio of assets so long as vault is single-sided.

Feel free to contact us at support@hashdit.io for any support needed! Stay safe!

Security Scan Summary Report for Cross-Chain Bridges on the BNB Chain​

Background​

A cross-chain bridge is a decentralized application that helps to transfer assets from one blockchain to another. The cross-chain bridge is a core component of Web3 infrastructure. For users, the cross-chain bridge can facilitate the seamless movement of tokens and messages between chains. Undeniably, while cross-chain bridges are vital for unleashing exponential innovation in Web3, they simultaneously open up potential avenues for exploitation by malicious entities. Bridges have become a new target for cryptocurrency crime. Vulnerabilities in these bridges are under attack, and hacking incidents are becoming increasingly notable.

To ensure the safety of users on the BNB chain, we have conducted security scans on 37 active bridge projects on the BNB chain. The scans mainly focus on two aspects:

1. The degree of centralization in the privileged roles of the project.
2. The open-source status of the project's smart contracts.

1.Degree of Centralization in the Project’s Privileged Roles​

The main focus here is on whether privileged role management follows good security practices. The examination includes whether a privileged role is an EOA (Externally Owned Account). When an EOA is used in a privileged role, it exposes an attack surface. If the corresponding private key is exposed, the attacker may gain control over the privileged functions, endangering the project's economic ecosystem and user funds. Therefore, it is generally considered a better practice with a higher degree of decentralization to use multi-signature wallets, MPC (multi-party computation), or time lock contracts as privileged addresses. Using an EOA as a privileged role in a smart contract signifies a higher degree of centralization in the project. The assessment also checks whether the threshold or other parameters for privileged roles that have already used multi-signature wallets are set reasonably. If the threshold is not set properly, the multi-signature wallet cannot reduce the degree of centralization and still carries a centralization risk.

In the real world, notable cross-chain bridge vulnerabilities due to poor security practices for privileged roles are common:

• Harmony Bridge (June 2022) - Two out of five private keys required to promote, approve, and execute transactions on the Harmony Bridge multi-signature were exposed. Here, the mult-sig wallet threshold is less than 51%, which is relatively low.
• Multichain Bridge Hack (July 2023) - The bridge's private key was exposed, leading to unauthorized withdrawals, all under the control of the Multichain CEO.
• QANplatform (October 2022) - The cross-chain bridge project was attacked, suspected to be due to a private key leak. It resulted in a loss of approximately $1.9 million, causing the price of the QANX token to plummet.

Centralized bridge projects are not only vulnerable to attacks but also enable centralized participants to unilaterally control all funds. Decentralized privileged roles help mitigate centralization risks by requiring any potential attacker (including the bridge operator) to compromise the private keys of multiple independent entities to carry out any malicious activity, thus serving as an effective form of security.

2. The Open-Source Status of the Project's Smart Contracts​

This scan primarily focuses on the open-source nature of a project's smart contracts.

Since the principal function of cross-chain bridges is the transfer of value from one blockchain to another, all cross-chain protocols necessarily involve smart contracts. In most cross-chain use case scenarios, smart contracts across multiple chains are employed to facilitate functions like token minting, burning, locking, or unlocking – all crucial to efficient cross-chain movement.

Smart contracts function as both a safeguard against vulnerabilities and a potential technical risk in the event of flawed implementation. Usually, smart contracts provide a valuable mechanism for cross-chain bridges to perform integral security checks, such as ensuring the amount a user withdraws doesn't exceed their deposits and enforcing rate limitations. On the other hand, poorly written, or unaudited smart contract code can have a substantially adverse effect: vulnerabilities within the smart contract code can be exploited by malicious hackers, who could potentially steal massive volumes of data from the cross-chain bridge.

If a cross-chain bridge smart contract on a blockchain explorer is closed source, users would not be able to understand the cross-chain logic by examining the smart contract. Similarly, it would be more difficult for users to judge the quality of the code or identify potential vulnerabilities within the smart contract. Even worse, nefarious project parties may potentially create backdoor functions within closed-source bridge smart contracts, which could lead to user funds becoming irretrievably locked. Using or approving unverified smart contracts inherently exposes users to significant financial risk.

Contrary to what some project teams may believe, failing to open-source project contracts does not necessarily prevent potential hacker attacks. In truth, experienced hackers can still make attempts on closed source project smart contracts, which impedes normal user interaction and breeds mistrust. Open-sourcing contract code not only promotes project transparency, but also helps prevent the inclusion of malicious code, ultimately fostering increased user trust. Hence, open-sourcing smart contracts is often considered to be best practice in the industry.

Security Check Results​

The scan results show:

• Out of 37 projects, 12 (32%) were found to have no apparent security risks in these two aspects;
• 15 (41%) out of 37 projects had issues of privileged roles centralization; 9 (24%) out of 37 projects had issues related to closed-source smart contracts.
• 5 (13%) projects had security issues in both aspects;
• The remaining 6 (16%) projects are not applicable to our scanning. 2 of the projects do not use smart contracts, instead they use Externally Owned Accounts (EOA) to transfer tokens on the chain combined with off-chain programs for cross-chain transfers. The other four projects did not develop their own cross-chain bridges, they simply provide routing selection for multiple cross-chain bridges, so our scanning doesn't hold much significance for these types of bridge aggregators.

We found a total of 239 issues with the centralization of privileged roles and 67 issues with closed-source smart contracts.

We have identified the below types of risks, which include:

1. In some bridge projects, closed-source smart contracts exist on BSCSCAN.
2. In some bridge projects, the smart contracts have applied the proxy pattern. While their proxy contracts are open-source, the corresponding logic contracts are closed-source.
3. In some bridge projects, closed-source smart contracts are used as privileged roles in certain smart contracts.
4. In some bridge projects, Externally Owned Accounts (EOAs) are used as key privileged roles in smart contracts, possessing various privileged functions.
5. In some bridge projects, although multi-signature wallets have been used as privileged roles in smart contracts, the multi-signature wallets have set unreasonable/low thresholds (<51%).
6. In some bridge projects, despite the use of multi-signature wallets as privileged roles in smart contracts, the number of owners set for the multi-signature wallet is unreasonable, such as only consisting of one owner. This essentially means that the degree of centralization is equivalent to that of an EOA.

Through our communication and initiatives, thus far, at least four project teams have completely or partially addressed the existing issues. Therefore, currently, there are 16 projects that have implemented good security practices in these two respects. We are still actively communicating with the remaining projects.

In general, nearly 50% of the cross-chain bridge projects on the BSC chain currently have a good degree of on-chain code openness and a high level of decentralization of privileged roles. In the remaining projects, most project teams have actively responded to our scanning results, showing a willingness to continuously optimize and improve in these two aspects, and are already taking steps to do so. Therefore, the security situation of bridge projects on the BSC chain is quite optimistic. Comparatively speaking, in many other blockchains, the BSC ecosystem has a relatively high overall security for its bridges.

Best Practice Recommendations​

Best Practices for Addressing Centralization in Privileged Roles​

Decentralization is critical for providing security against single points of failure. We recommend solutions such as multi-signature wallets, time-lock contracts, and MPC wallets for use as privileged roles in smart contracts to reduce the level of centralization.

• Multi-signature is abbreviated as multisig and requires multiple private key holders to sign a transaction, usually used to prevent one party from controlling the wallet.
• A time-lock can lock certain functions of a smart contract for a specified period. It can significantly improve the security of smart contracts. For example, consider a scenario where a hacker has compromised a bridge project's multi-signature wallet and is preparing to withdraw money from the vault, but the vault contract has a two-day lock period. Thus, from the initiation of the withdrawal transaction to the actual withdrawal of funds, the attacker will need to abide by this two-day lock period. During this period, the project team can find countermeasures, and investors can sell out their tokens preemptively to reduce losses.
• MPC wallets are a subset of crypto wallets created using multi-party computation methods. They allow multiple users to create a joint wallet to store digital assets without any single point of failure. In this way, MPC wallets can ensure safety and mitigate risks, because compromising the system requires substantial effort from multiple parties.

We suggest combining one or more of the above solutions as privileged roles. However, please note that whether it is a multisig wallet, a timelock contract, or an MPC wallet, reasonable parameter settings must be applied in order to truly play a role and reduce the level of centralization.

• The popular/industry standard interface currently employed for multi-signature wallets is GnosisSafe. When using a multi-signature wallet, it's important to ensure a reasonable threshold is applied. The appropriate threshold for a multi-sig wallet should depend on the number of share owners and their level of trust, and it can vary based on various practical situations. There's always a balance between absolute security and convenience. If you set an overly high signature requirement, wallet operation can become overly complex and cumbersome. On the other hand, setting too low of a signature requirement may invite risks of wallet misappropriation. Common settings include a 2-3-4 mode (a 3-person wallet requiring 2 signatures or a 4-person wallet requiring 3 signatures), which can ensure that, in the case of a participant's private key being stolen or the participant being inaccessible, others can continue to operate the wallet without reducing the wallet's financial security. Generally speaking, the threshold should not be lower than 51% of the total number of owners, but the total number of owners should not be less than 2.

• Determining a reasonable lock time for a time lock contract depends on several factors, such as the specific needs of the project, the level of risk tolerance, and functionality requirements. However, it's important to remember that the right lock time for a specific project may vary. For high-risk operations or projects in volatile markets, longer lock times may be necessary. Conversely, for lower-risk operations or stable markets, a shorter lock time might suffice. If the lock time is too short, say a few minutes, the project team may not have enough time to take any action, and then this locking procedure would be essentially in vain. Typically, the length of lock time chosen should provide sufficient time for the contract's stakeholders to react to changes in the contract. Popular choices are often between 24 to 72 hours for many DeFi projects, as this provides an acceptable trade-off between security and operational efficiency.

Best Practices for Smart Contract Codes​

When using cross-chain protocols, risks associated with smart contracts are practical. The safest cross-chain bridges continuously test their codebases through private and competitive audits, along with various internal security tests such as fuzzing, static analysis, formal verification, symbolic execution, etc.

Assessing the times of a codebase has been audited and by whom can serve as a reliable signal that the cross-chain bridge in use has protection against technical attacks. Additionally, layered security measures (like enabling emergency pauses and updates, and implementing rate limits) can mitigate the impact of any smart contract errors.

With all these measures in place, open-source code benefits the project by enhancing transparency and boosting user trust. Typically, closed-source project contracts imply potential risks or even hidden malicious code, backdoor functions, and a risk of rug pulling.

It's best to open source all contracts within the project ecosystem. This is to ensure transparency for users and to allow code auditors/white hats to verify the security of the code.

An often overlooked case of an unverified contract is when a smart contract uses a proxy pattern. A proxy contract is a contract which delegates calls to another contract. To interact with the actual(logic) contract users have to go through the proxy, and the proxy knows which contract to delegate the call to (the logic). A proxy pattern is often used when project parities want upgradability for their contracts. This way the proxy contract stays immutable, but they can deploy a new logic contract behind the proxy contract - simply change the logic address inside the proxy contract. So that the proxy contract indeed delegates its functionality to the logic contract. Therefore, it's dangerous when only the proxy contract is verified and the logic contract isn't as it can't be guaranteed that the logic contract isn't malicious. As a best security practice, it's better to open source not only the proxy contract but also the logic contract.

When the privileged roles of a smart contract are unverified contracts, the unverified contracts might hold some potential backdoors or malicious external interactions, it's best to open source that smart contract code of the privileged role.

How to open source contracts:

• On BNB chain: https://bscscan.com/verifyContract
• On opBNB chain: https://opbnbscan.com/verifyContract

Furthermore, always maintain transparency with your investors - for example, create Medium articles, informing users of the addresses or updates of key contracts, etc.

Recommendation for users​

Before using a cross-chain bridge, users also need to conduct due diligence to ensure that they choose a bridge with effective security measures. Here are some key points:

1. Security: Check whether the cross-chain bridge has passed multiple in-depth security audits, and whether the audit results didn't show any major issues. Also, consider how they have responded to and rectified any identified issues.
2. Transparency: It's important that the bridge protocol's source code is open source and easily accessible. This can help users understand how the protocol works and identify any potential issues.
3. Decentralization: If you have a certain understanding of smart contracts, you can check whether privileged roles in the smart contract use highly decentralized multi-signature wallets or time-lock contracts; and whether the threshold of the multi-signature wallet or the lock duration of the time-lock contract is rationally set.
4. Community support: An active and engaged community can help keep the bridge protocol updated, adaptable to market changes, and capable of solving any problems that may arise.
5. Performance: Observing the performance of the cross-chain bridge, including transaction speeds and costs, is also an important step. A bridge with strong performance and low cost ensures a better user experience.
6. User Experience: User experience is another significant factor, including the usability of the interface, whether there is a comprehensive user guide, and customer support availability.
7. Partnerships and ecosystem: It's beneficial for users to check whether the cross-chain bridge has many partners and supports many chains, to assess the extent and maturity of its ecosystem.

For cross-chain investments, due diligence is essential. You should look at official documents, white papers, security audit reports, consider community reviews, listen to expert opinions, and if possible, test their services. Find out more about it from forums, communities, or Q&A websites, and conduct a comprehensive evaluation from all aspects. Don't lightly believe in unverified information.

Glossary​

• EOA: Externally Owned Accounts are accounts that are controlled by a private key and have no coding associated with them. If you hold the private key associated with an EOA, you can send coins and messages from it. (E.g a Metamask account).

• Rugpull: A rugpull in the crypto industry is when a development team suddenly abandons a project and sells or removes all its liquidity. The name comes from the phrase to pull the rug out from under (someone), meaning to withdraw support unexpectedly.

• Privileged Role: In smart contracts, "privileged roles" often refer to certain roles or accounts within the contract that have special permissions. These accounts have the authority to perform actions that regular users cannot execute in the contract. For example, privileged roles might be able to change contract parameters, upgrade the contract, or pause the contract in emergency situations. When designing and deploying smart contracts, these privileged roles should be managed and controlled very carefully, as they have potential risks that may be misused or abused. For instance, if a bad actor gets control of a privileged role, they might have the ability to cause abnormal contract behavior or make destructive operations, such as stealing assets stored in the contract. Sometimes, privileged roles in a smart contract may be assigned to a multi-signature wallet, controlled collectively by multiple entities, increasing complexity and security.

• Multi-Sig Wallet: A multi-signature (multi-sig) wallet is a type of digital wallet that requires approval from multiple parties to authorize a cryptocurrency transaction. This type of wallet is designed to provide increased security, as it minimizes the risk of single-point failures or attacks. The 'multi-signature' aspect refers to the multiple cryptographic keys involved: each co-owner of the wallet has a unique key, and a preset number (the 'threshold') of these keys must be used in concert to authorize a transaction.

• MPC(Multi-Party Computation): A Multi-Party Computation (MPC) wallet utilizes multi-party computation technology, in which each party holds a piece of the private key, and computations are collaboratively concluded without revealing individual inputs. This introduces a new level of security as no single party has access to the entire private key, and transactions require authorization from multiple parties, making it extremely difficult for attackers. MPC is used in various applications such as privacy-preserving data analytics, secure voting, secret sharing, etc., including enhancing the security of crypto wallets and transactions. Compared to multi-signature wallets, the method provided by MPC for ensuring security is different; an MPC wallet offers security through private key sharing without needing to execute a multi-party transaction on the blockchain, while multi-signature wallets offer security by approving transactions with multiple keys executed on the blockchain (leading to typically higher gas fees).

Getting Started with HashDit Snaps: A Step-by-Step Guide​

Introduction​

Meet HashDit Snaps, a revolutionary MetaMask extension designed to dramatically boost your security when interacting with smart contracts. HashDit snap aims to protect users by screening transactions before they are executed through transaction insights. This include warnings against interactions with:

• Ponzi Schemes
• Risky Smart Contract Interactions
• Phishing Websites and Addresses
• Scam Websites and Addresses

HashDit snap also provides clear details about the function and arguments invoked during a smart contract interaction.

Installation​

Installing MetaMask

As a pre-requisite, MetaMask must be installed on your browser before installing HashDit Snaps.

MetaMask Snaps is currently only supported on the browser version, and not the mobile version.

Installing The Snap On the HashDit Snap website, start the installation process by clicking the Add to MetaMask button.

Installing The Snap

On the HashDit Snap website, start the installation process by clicking the Add to MetaMask button.

Permissions Continue through the install and accept the requested permissions. The requested permissions are required to allow HashDit Snap to work properly.

• Access the internet: Allow HashDit Snap to access the internet. This is used to both send and receive data with the HashDit API.
• Access the Ethereum provider: Allow HashDit Snap to communicate with MetaMask directly, in order for it to read data from the blockchain and suggest messages and transactions.
• Allow websites to communicate directly with HashDit Security: Allow websites to send messages to HashDit Security and receive a response from HashDit Security.
• Fetch and display transaction insights: Allow HashDit Snap to decode transactions and show insights within the MetaMask UI. This is used for all the security features.
• See the origins of websites that suggest transactions: Allow HashDit Security to see the origin (URL) of websites that suggest transactions. This is used by the URL screening feature.
• Store and manage its data on your device: Allow HashDit Security to store, update, and retrieve data securely with encryption. Other snaps cannot access this information. The only data stored is the signed hash of the security message (see below).

The HashDit snap does not have access to the user's private keys. Furthermore, the only transaction initiated by the Snap is a signature request dispatched during installation.

Signature Request

Upon completion of the installation process, the user will be prompted to sign a security message. Note that this is only used to authenticate the HashDit API. Rejecting the signature request will prevent HashDit's features from working.

If the signature request is rejected, it can be re-prompted by just reinstalling the snap.

If you attempt to use HashDit snap without signing the security message, an error screen will be displayed.

Reinstalling the snap will resolve this issue.

Reinstalling The Snap

To update the snap or re-sign the signature request, users simply need to click the 'Reconnect' button, which triggers a new installation prompt.

How To Use HashDit Snap​

Using HashDit Snap is simple! Once the HashDit Snap is installed, the security features are entirely automatic. The HashDit Snap will provide transaction insights before a transaction is executed by a user. In the transaction screen, a user can switch to the HashDit Security tab to view the risks involved with their transaction.

The features of HashDit Snap are currently supported on the Binance Smart Chain Mainnet and Ethereum Mainnet. Other networks will only support URL screening.

Features​

Transaction Screening and Destination Screening

Transaction Screening

The Transaction Screening insight offers a risk assessment before interacting with a smart contract. This assessment provides users with three values that shed light on potential risks associated with their transaction: Overall Risk - The overall risk level of the transaction, which can be one of three levels · Low Risk · Medium Risk · High Risk Risk Overview - The recommended action Risk Details - Details explaining the output of the overall risk

Destination Screening

The Destination Screening insight scans a transaction's destination address against HashDit's database of blacklisted and whitelisted addresses. This database encompasses known scamming, phishing, and trusted addresses. This assessment provides users with three values that shed light on potential risks of interaction:

Overall Risk - The overall risk level of the transaction can be one of three levels · Low Risk · Medium Risk · High Risk Risk Overview - The recommended action Risk Details - Details explaining the output of the overall risk

URL Screening

The URL Screening insight scans the website origin of the transaction and compares it against HashDit's database of whitelisted and blacklisted URLs. Our database includes sites flagged as scams, deemed high-risk, and whitelisted. The insight will provide users with a risk level, ranging from -1 to 4.

Function Call Information

The Function Call insight provides clear and explicit details about the function and arguments invoked during a smart contract interaction. The aim is to offer more readable parameters than Metamask's current 'Hex' tab. This is achieved by displaying each function argument, its type, and its corresponding value.

Links​

Official Website: https://www.hashdit.io/en/snap

Documentation and FAQ: https://hashdit.gitbook.io/hashdit-snap

GitHub Repo: https://github.com/hashdit/metamask-snap

MetaMask Snap Page: https://snaps.metamask.io/snap/npm/hashdit-snap-security/

Introduction​

In this monthly series, HashDit is sharing the monthly security incidents in the crypto space and what we can learn from them. For this Apr 2024 edition, the total losses mounted up to $2.7 million, showing a 54% decrease compared to April 2023.

In this sharing, we focus on the DApps incidents. Below are the top 5 DApps incidents that DApp Developers should pay attention to.

Top 5 DApps incidents​

XBridge - $1.03m - Wrong Proxy Upgrade​

XBridge is a Bridge / Cross-Chain protocol that allows users to bridge funds from one chain to another. In this attack, a vulnerable logic contract was introduced in a proxy contract upgrade, allowing the attacker to drain 466,490,205 STC tokens, 511,424,527 SRLTY tokens and 11,165,018 Mazi tokens, amounting to ~$1.03m. Interestingly, the attacker did not liquidate all tokens, and only swapped ~$192k to BNB and deposited it into Tornado Cash, leaving some tokens in his wallet.

Root cause: The listToken function in the target contract does not verify msg.sender and _tokenOwner. Essentially, as long as _baseToken==_correspondingToken, the attacker can set the key variable _tokenOwner to msg.sender which is himself, and subsequently call withdrawTokens to extract the baseToken funds directly.

The upgrade introduced a wrong mapping _tokenOwner instead of using TokenOwner (which was correctly set up in the old logic contract), anyone can thus assume _tokenOwner and withdraw tokens.

Onchain information:

Bug introduced in Upgrade tx

Hack tx

Code snippet:

FinanceChainge - $710k - Lack of Validation​

FinanceChainge is a DeFi protocol, which is known as a liquid cross-chain aggregator. In this attack, the hackers exploited the swap function with a malicious payload. The hack amount is ~ $710k. Interestingly, the sole victim is 0x8a4aa176007196d48d39c89402d3753c39ae64c1, which is linked to the project team and hence likely funds belonging to the project.

Root cause: The swap() function had a bug which allowed hackers to exploit users’ allowance given to this victim contract.

Onchain information:

Hack tx 1

Hack tx 2

Code snippet:

OpenLeverage - $226k - Internal accounting​

OpenLeverage is a DeFi protocol which operates as a DEX, allowing users to swap tokens. In this rather complicated attack, the attacker was able to compromise the OpenLev contract on BSC. The exploit consisted of a sequence of arbitrary external calls, taking advantage of inconsistency in the accounting for borrowers.

Root cause: The attack occurred due to a discrepancy in the accounting process, which comprised two separate transactions.

Firstly, the attacker set up a "margin position" in the OpenLevV1 contract using the marginTrade function. This function call permitted an additional position creation with minimal collateral through an untrusted external call to the OpBorrowing contract. This position was ultimately liquidated.

However, both OpenLevV1 and OpBorrowing contracts use the LToken contract for their transactions. Consequently, the debt of the margin position was unintentionally cleared in the liquidation process.

In the second transaction, the attacker exploited this situation. They used the payoffTrade function, bypassing the health check, and drained all the collateral from the margin positions.

Onchain information:

Hack tx 1

Hack tx 2

Code snippet:

NGFS - $190k - Lack of Validation​

NGFS is a DeFi token on BSC. In this attack, the attacker was able to manipulate his own token balance due to a lack of validation for a privileged function. As such, he could simply increase his balance and dump the tokens on the open market.

Root cause: The function delegateCallReserves() can be called only once, and is supposed to be set up during the initialization phase, however it was left untouched. As such, anyone could assume _uniswapV2Proxy position and then call the setProxySync() method to set an arbitrary _uniswapV2Library. Lastly, within the reserveMultiSync() function, the attacker could set a large balance for himself since he has _uniswapV2Library privilege.

Onchain information:

Hack tx

Code snippet:

ATM - $180k - Price Manipulation​

ATM is a DeFi token on BSC. In this attack, the attacker was able to make use of the funds in the ATM contract to add liquidity to the pool. At the same time, he could invoke the skim function to drain excess funds from the pair.

Root cause: The _transfer routine can be exploited by directly transferring funds to the pair contract. This triggers the distributeCurrency function, adding liquidity from the perspective of the ATM contract. The attacker could then profit by simply calling skim on the pair.

Onchain information:

Hack tx 1

Hack tx 2

Code snippet:

Key lessons for developers​

1. Input validation is a crucial process - it's essential to verify all potential user inputs, especially when these inputs affect changes to the state of the system. This holds particularly true in the below scenarios:

   • Calldata Parameters: Given that attackers have the ability to craft any data, extra validation steps must be in place for calldata parameters.

   • User Approvals: During the process where the protocol contract manages users' approvals, meticulous input checks are paramount to prevent potential malicious activities.

2. To guard against price manipulation, it's essential to ensure that updated prices cannot be influenced to reflect unexpected values. Oracles, both on-chain and off-chain types, can be employed by developers. Here's how:

   • Set Boundaries: Implementing limits can block prices from being abruptly manipulated to an impossible value, regardless of the oracle type in use.

   • Fallback Oracle: Integrate a secondary oracle as a fallback measure. This ensures that if the initial oracle fails, there is a backup in place to verify the consistency of prices. By doing so, it ensures continuous, reliable price feeds, and safeguards against single point of failure.

3. Upgrading proxy code should be taken very seriously and should require several checks such as:

   • Thorough Testing: Conduct rigorous testing before deploying any updates to ensure that the changes will not disrupt existing functionalities or introduce new vulnerabilities.

   • Code Audits: Always get your code audited by a third party. It's crucial to have another set of eyes inspect your code, as they may spot issues that you've overlooked.

   • Pause Functionality: Make sure that your contract has a 'pause' functionality. In case something goes wrong, this function allows halting the operations until the issue is fixed.

4. Addressing internal accounting errors and effectively handling external arbitrary calls are critical for crypto developers, especially for lending projects which involve complex financial transactions. Here are some recommendations:

   • Sequencing Transactions: Consider sequencing transactions appropriately. Generally, it's safer to make state changes before conducting external calls.

   • External Calls: Be extremely careful while interacting with third-party contracts. They should be treated as potentially malicious. Avoid state changes after making a call to an external contract.

   • Precise Accounting: Keep accurate and precise accounting to make sure all balances tally at the end of each operation. This is primarily to ensure that no tokens are lost or mistakenly created during transactions.

   • Debt and Collateral Management: Carefully track and manage computational handling of debt and collateral. Errors in management or calculation can lead to vulnerabilities such as unforeseen liquidations or insolvency.

   • Limit Permissions: Limit the permissions of the contract that makes external calls to only what's necessary to reduce your contract's attack surface.

Feel free to contact us at support@hashdit.io for any support needed! Stay safe!

Introduction​

In this monthly series, HashDit is sharing the monthly security incidents in the crypto space and what we can learn from them. For this Mar 2024 edition, the total losses mounted up to $146 million, showing a 50% decrease compared to March 2023.

Of which, they are split across 2 sections: DApps ($114m) and Phishing ($32m).

In this sharing, we focus on the DApps incidents. Below are the top 5 DApps incidents that DApp Developers should pay attention to.

Top 5 DApps incidents​

Munchables - $62.5m - Insider Attack​

Munchables is a GameFi and NFT protocol. In this attack, it was confirmed to be an Insider Attack where a rogue employee was malicious, gaining access to a privileged account. After malicious logic was introduced in a proxy contract upgrade, 62M funds were transferred out by the attacker. Thankfully, after some negotiation and investigation, the funds were eventually returned.

Root cause: Malicious developer was hired and suspected to be linked to DPRK, and had bad intentions right from the start. It was found that the malicious logic was already introduced during deployment and the bad actor used manual manipulation of the getLocked storage slot to assign himself an enormous Ether balance in the contract, so that his locked amount would bypass the withdrawal checks.

Onchain information:

Hack tx

Malicious contract upgrade

Code snippet:

Unverified contract

PrismaFi - $12m - Lack of Validation​

PrismaFi is a DeFi protocol, which is known as a non-custodial and decentralized Ethereum LST & LRT backed stablecoins. In this attack, the hackers bypassed the migrate function and called the flash loan directly with carefully crafted input data.

The flash loan's callback function, onFlashloan(), was called. The lack of proper checks allowed the hackers to close a trove owner's Trove and immediately reopen it within the same TroveManager. The transaction caused the owner's position to be closed and reopened, resulting in the trove owner having a new position with the same debt but less collateral and the difference in collateral sitting in the zap contract.

The hackers then opened a new Trove and used the MigrateTroveZap contract to migrate it, effectively using the remaining collateral for their own Trove. Finally, the hackers closed their Trove and took the profits.

Root cause: The root cause of the vulnerability was twofold:

1. By directly calling the onFlashloan() function, the user could manipulate other trove managers positions.
2. The contract allowed for a mismatch between the collateral in the initial position and the collateral in the new position, with the difference being susceptible to being taken.

Onchain information:

Hack tx 1

Hack tx 2

Hack tx 3

Code snippet:

WooFi - $8.7m - Price Manipulation​

WooFi is a DeFi protocol which operates as a DEX, allowing users to swap tokens. In this attack, the attacker was able to compromise the WooPPV2 contract on Arbitrum. The exploit consisted of a sequence of flash loans that took advantage of low liquidity to manipulate the price of WOO in order to repay the flash loans at a cheaper price.

Root cause: There were 2 configuration issues.

1. A previously unidentified error resulted in the price being adjusted far outside of the expected range ($0.00000009)
2. The fallback check, normally executed against Chain Link, didn’t cover the WOO token price.

Onchain information:

Hack tx 1

Hack tx 2

Code snippet:

SSS_HQ - $4.8m - Function wrongly implemented​

SSS_HQ or Super Sushi Samurai is a GameFi platform on Blast chain. In this attack, thankfully a White Hat was able to spot the bug before any malicious actor, where he increased his own balance by repeatedly transferring to himself. He subsequently swapped these tokens in the liquidity pool and protected the liquidity of ~$4.8m.

Root cause: The tax transfer logic is wrongly implemented in the _update method of the SSS.sol code. The _balances[to] value is incremented before the _balances[from] value is updated (done within the _postCheck method), seen in the first picture. As such, the balance of the to address uses the stale value i.e original balance, seen in the second picture. This is summed with the amount variable, stored in the toBalance variable and subsequently overwriting the _balances[from] in the last statement, almost doubling the sender’s balance.

Onchain information:

White-hat Hack tx

Code snippet:

Unizen - $2.1m - Lack of Validation​

Unizen is a DeFi protocol which operates as a DEX across multiple chains. In this instance, the attack happened on Ethereum, just 5 hours after the victim proxy was upgraded to a vulnerable logic contract. The vulnerable contract introduced a function 0x1ef29a02 which allowed arbitrary calldata to be sent.

Root cause: Lack of validation in a Swap related function (which allowed arbitrary transferFrom calls, specifying the From, To and Amount parameters). As such, victims that have approved their funds to this contract will be affected.

Onchain information:

Hack tx

Code snippet: Unverified contract

Key lessons for developers​

1. In light of potential insider compromises, it's crucial to apply thorough background checks for new employees. Specifically, keep an eye out for potential red flags including:

   • Preference for certain platforms: Malicious developers seem to favor using Github, often impersonating user profiles such as SuperTalentedDev726 or CryptoKnight415.

   • Use of numbers: Both email addresses and Github usernames often contain numerical sequences. It's suspected they use this as a method for tracking the identities they impersonate.

   • Asian identities: There's a tendency toward choosing Japanese (and possibly Korean) identities, often claiming prior education in Japan.

   • Prominent educational background: The falsified credentials often include elite universities in Japan, Hong Kong, and Singapore. Such institutions may include Singapore State University, Nanyang Technological University, University of Hong Kong or Hong Kong University of Science and Technology.

   • Codebase theft: While not always the case, these imposters often steal existing projects from GitHub and recondition the commit messages to reflect their assumed usernames.

   • Multiple applications: They tend to apply repeatedly for the same job, resorting to multiple email addresses for their submissions.

   • Premature expertise: They often claim experience in Solidity/EVM too early (such as in 2015), which is an unlikely scenario giving the nascent state of blockchain technology at the time.

2. Input validation is a crucial process - it's essential to verify all potential user inputs, especially when these inputs affect changes to the state of the system. This holds particularly true in the below scenarios:

   • Calldata Parameters: Given that attackers have the ability to craft any data, extra validation steps must be in place for calldata parameters.

   • User Approvals: During the process where the protocol contract manages users' approvals, meticulous input checks are paramount to prevent potential malicious activities.

3. To guard against price manipulation, it's essential to ensure that updated prices cannot be influenced to reflect unexpected values. Oracles, both on-chain and off-chain types, can be employed by developers. Here's how:

   • Set Boundaries: Implementing limits can block prices from being abruptly manipulated to an impossible value, regardless of the oracle type in use.

   • Fallback Oracle: Integrate a secondary oracle as a fallback measure. This ensures that if the initial oracle fails, there is a backup in place to verify the consistency of prices. By doing so, it ensures continuous, reliable price feeds, and safeguards against single point of failure.

4. Ensuring that the deployed function aligns with the intended objective is a critical requirement, especially for high-stakes operations such as accounting. This assurance can be achieved through:

   • Thorough Testing: Execute comprehensive fuzz testing and edge case analysis. This doesn't solely ensure correct function logic, it also helps to identify potential flaws and security vulnerabilities that might otherwise be overlooked.

   • Use Trusted Templates: Consider using trusted codebases, such as Openzeppelin, as a foundation for your code. These established libraries have been vetted extensively by the developer community, reducing the likelihood of introduction of unexpected bugs or issues.

Feel free to contact us at support@hashdit.io for any support needed! Stay safe!

*Unverified contracts screenshots courtesy of Dedaub’s decompiler!