Blog | HashDit

SCS@HashDit

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 Installation Link

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.

Risk Level	Risk Explanation
-1	Unknown Risk
0	No Risk
1	Low Risk
2	Medium Risk - Suspicious Website
3	Medium Risk - Dangerous Website
4	High Risk - Dangerous Website

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/

Monthly Incident Sharing - April 2024

May 14, 2024 · 7 min read

Bug introduced in Upgrade tx

SCS@HashDit

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:

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:

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:

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:

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:

Code snippet:

Key lessons for developers

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.
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.
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.
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!

Monthly Incident Sharing - March 2024

April 9, 2024 · 7 min read

SCS@HashDit

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:

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:

By directly calling the onFlashloan() function, the user could manipulate other trove managers positions.
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 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.

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

Onchain information:

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:

Code snippet: Unverified contract

Key lessons for developers

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.
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.
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.
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!

Meme Education Guide

April 4, 2024 · 7 min read

SCS@HashDit

Meme Education Guide

Introduction

Since its inception, meme tokens have earned themselves a polarizing reputation in the crypto space. From the fun frenzy around Doge coins, Cat coins, Pepe coins, to the latest hype surrounding Solana memes, they've become a phenomenon that’s difficult to ignore. Their promise of potentially delivering exponential returns attracts many users. But with great rewards come great risks.

In the decentralized web3 world, fraud such as honeypot scams and rugpull schemes are unfortunately common. These deceptive strategies often use innocuous meme tokens as bait, exploiting the pseudonymous nature of addresses to deceive unsuspecting investors.

At HashDit, we're committed to maximizing user security by providing countermeasures to these issues. Our aim is to enable more users to understand the potential risks associated with tokens they encounter, especially as trading becomes increasingly accessible with the surge of channels, with Telegram bots being one good example.

HashDit provides token scanning and threat intelligence services to platforms such as PancakeSwap and Trust Wallet, where users can make informed decisions after being notified of the risks. Platforms like DAppBay have also integrated our API, offering a scanner that users can employ to evaluate the risk associated with a token before investing in it.

However, while automation can help to identify most risks, it's not completely foolproof. Even the most sophisticated models can have false positives. So, how can you personally ensure a meme token's safety before investing? Here's a basic checklist:

As a meme user investor:

Research the Token: Start your exploration by looking into the meme token online. Rely on trustworthy sources such as the project's website, or reputable third-party sites like CoinMarketCap. This helps you glean a well-rounded view of the asset.
Verify the Contract Address: Token replication is a common forgery tactic. To avoid falling into honeypot traps or scams, ensure that you're investing in the legitimate token by verifying the contract address with authentic sources like the project’s website.
Investigate the Team and Developers: Confidence in a token is often synonymous with the team behind it. Check their track record and transparency levels. Always remember, a credible team builds a credible token.
Audit Reports: It is important to find out if professional security auditors have vetted the meme token’s code. Audit reports from reliable firms can significantly mitigate the risk of scams hidden in the code.
Social Media and Community Interactions: Stay engaged with the project’s online communities on platforms like Telegram, Twitter, Discord, and so forth. Active and responsive social media channels underscore the project's genuine nature.
Smart Contract Checks: Basic review of the smart contract code is strongly advised, BscScan is a good way to check this. Firstly, check if the contract code is verified or open-source. (Paste the address on BscScan. Click on Contract and then Code.)

If the contract code has been verified, there should be an accompanying green tick seen.

If the contract has not been verified, the code would not be seen and there would be no green tick.

If the code is verified, users should then proceed to look for any privileged functions that the team has access to, within the "Search Source Code" box.

The presence of these privileged functions might pose a potential security risk to investors, causing loss of funds.

Common privileged functions can include, but not limited to: mint(), pause(), blacklist(), whitelist(), setFee(), etc. An easy way to search through the code is to use keywords (ctrl-F) like “onlyOwner” and “authorized”.

However, it is possible that the privileged role has been renounced i.e the dead address. As such, it is critical to check if the privileged role is an Externally Owned Account (EOA). To verify the ownership, click on “Read Contract” and search for “owner”.

If the address is an EOA, you would see an “Address” label beside the actual address, as seen below.

However, do take note that the address could be a “Dead address”. A “Dead address” in crypto terms simply means that nobody has the keys to this account and hence the tokens there would be taken out of circulation. 2 common examples are 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000dead

In other circumstances, you could see another label called “Contract”. This simply means that another smart contract has privileges over this token.

If it was a Multi-Signature wallet, you would see a “Smart Account by Safe”. This is relatively more secure as multiple owners can verify transactions.

If this label is not there, it could be a Timelock related smart contract managed by the team. In this case, users should check with the team to get more clarity.

Automated Security Scanners: Other external tools such as GoPlus and Honeypot.is can be utilized to cross-check that the token is indeed secure. This increases confidence in the security assessing process.
Liquidity Locks: A locked liquidity usually denotes a safer investment. You can check this on the project's website, as well as verify through independent tools like BscScan. Detecting a lack of liquidity lock could save you from falling for a rug pull.

Most meme projects would inform their investors on their site that a certain percentage is burned or locked. However, to ensure that this information is accurate, you are encouraged to verify this with BscScan. You can follow the following steps:

After pasting the address, click on the token link under “More Info” -> “TOKEN TRACKER”.
Then, click “Holders” to check who are the top holders for the meme token.

Some of the positive signs to look out for amongst the top holders include the presence of Dead addresses, having its supply stored in Multi-Signature wallets or being listed on Centralized Exchanges (CEXs) like Binance. This means that some of the liquidity is locked temporarily with trustable entities or permanently with these addresses.

Another common strategy for meme tokens is to use a Liquidity Locker. There are 2 types here: either a 1) 3rd party Locking-as-a-Service platform or a 2) Personal locking contract deployed by the team.

Popular 3rd party platforms include PinkSale and Unicrypt locking services. As such, their respective labels will be visible in the Holders list as seen below.

A personal Locking contract by the team could be a smart contract with the name “Vesting / Locking wallet”, as seen in the image below.

Similarly, you can apply the same process to the liquidity token. Usually, this would be a PancakeSwap LP token. To get the liquidity token from the meme token, you can use another tool like dextools.io, paste the address to obtain the pair contract address.

As a meme project owner:

To launch and maintain a successful and trustworthy meme token, consider the following:

Transparency: Keep your team identities accessible, and refrain from restricting users' comments on community platforms like Twitter or Telegram. Posting regular updates about the project's progress are also key to building trust and transparency.
Credibility: Forge partnerships with reputable projects, and aim to list your token on recognized centralized or decentralized exchanges that have established themselves as being trustworthy. These actions can help to add credibility to the meme token.

Supply Locking: Locking your token's supply adds an extra layer of security and stability to your project. This includes not just the token’s supply, but also the liquidity on decentralized exchanges. As a guideline, the locking period should be at least 1 year. Numerous platforms offer Locking-as-a-Service, or you could opt to deploy your own locking or vesting contracts using libraries like OpenZeppelin.

Conclusion

In conclusion, exercising awareness and caution by both users and project owners are essential for fostering growth in the dynamic world of meme tokens. By following the safety guidelines here, users can avoid potential pitfalls, and projects can increase their chance of success.

It is important to take note that meme tokens generally contain high risks and can have significant price fluctuations so users should be wary in terms of their risk management.

Monthly Incident Sharing - February 2024

March 14, 2024 · 5 min read

StakingV4Proxy owner transfer tx

SCS@HashDit

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 Feb 2024 edition, the total losses mounted up to $132 million, showing a 141% increase compared to February 2023.

Of which, they are split across 3 sections: DApps ($65m), CEXs ($62m) and Phishing ($5m).

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

PlayDapp - $30m - Private Key Compromise

PlayDapp is a GameFi and Web3 Service protocol. In this attack, the hacker was able to compromise the original Minter account. As such, a malicious minter account was added and he minted 200m $PLA tokens, before dumping them on the open market.

Since then, the token transfer method has been paused and the token is planning to be migrated to a new address $PDA.

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:

Add Malicious Minter tx

Malicious Mint tx

Vulnerable code snippet:

Ronin Network’s Jihoz - $10m - Private Key Compromise

Ronin Network is a bridge protocol allowing cross chain of funds. In this attack, Ronin Network’s cofounder Jihoz had his wallet compromised. However, the attack is limited to only personal accounts, and does not affect operations of Sky Mavis and the Ronin chain.

Root cause: The hacker was able to compromise the private key of Jihoz’s wallet. As such, his assets were stolen from there.

Onchain information:

Vulnerable code snippet:

Shido - $3.3m - Private Key Compromise

Shido is a L1 blockchain protocol which combines the interoperability of Cosmos, and the development power of EVM and WASM. In this attack, the attacker was able to compromise the StakingV4Proxy owner's wallet on Ethereum, upgrading to a malicious logic, withdrawing $SHIDO tokens and dumping them on the open market.

Root cause: The hacker was able to compromise the private key of StakingV4Proxy’s owner wallet. It is unclear if it was an internal or external attack.

After transferring ownership to a malicious owner, he immediately upgrades the StakingV4Proxy contract with a malicious withdrawToken() function that withdraws all $SHIDO tokens from the contract.

Onchain information:

StakingV4Proxy upgrade tx

Withdraw all $SHIDO tokens tx

Vulnerable code snippet:

Seneca - $3.1m - Lack of Validation

Seneca Protocol is a DeFi lending platform and stablecoin issuer. In this attack, the attacker was able to compromise approximately 1,385 PT-Kelp rsETH from a Seneca collateral pool. He subsequently swapped these tokens for approximately $3 million worth of ETH.

Root cause: There is a lack of validation check for the user input data in the performOperations() function. This bug allows any account to call the function while specifying OPERATION_CALL as the action to be performed, allowing an exploiter to arbitrarily invoke external calls to steal funds from approving users.

Onchain information:

Hack tx on Ethereum

Hack tx on Arbitrum

Vulnerable code snippet:

BlueberryFDN - $1.6m - Oracle Misconfiguration

BlueberryFDN is a DeFi protocol which allows lending and borrowing of funds across chains. In this instance, the attack was front-runned by a whitehat, c0ffeebabe.eth. The vulnerability was due to the lending contract's incorrect handling of price decimals. As such, the attacker was able to borrow all the liquidity of three lending pools (OHM, USDC, WBTC) with extremely low collateral, since the assets borrowed are under-estimated, due to the non-normalized price.

Root cause: There was an incorrect usage of the oracle because the oracle always returns prices scaled to 18 decimals, thus causing assets that have less than 18 decimals to be undervalued significantly when being borrowed.

On Ethereum, WETH has a decimal of 18, OHM has a decimal of 9, USDC has a decimal of 6, and WBTC has a decimal of 8. Since BlueberryProtocol’s price oracle scales all token prices based on a decimal of 18, this caused the value of OHM to shrink by 1e9, USDC by 1e12, and WBTC by 1e10. As a result, the attacker managed to borrow assets worth 460 ETH by only collateralizing 1 ETH.

Onchain information:

Code snippet:

Key lessons for developers

Keys should be properly secured, rotated regularly and have some level of decentralization. Adopt a zero-trust model. Conduct proper background checks for new employees in view of insider compromises.

Validation is important - ensure all possible user inputs are checked for state changing methods. This is especially true for calldata parameters where attackers can craft any data and when the protocol contract handles users’ approvals.

Proper handling of decimals in different tokens used in the protocol is fundamental, particularly when calculating token price values. Furthermore, guaranteeing that the price oracles used in the protocol are normalized to the expected decimals is critical. Price oracles provide current and accurate token prices, thus any discrepancies might lead to significant errors in token pricing and overall system operations.

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

HashDit API Integration

March 12, 2024 · 3 min read

SCS@HashDit

HashDit API Integration

What Is HashDit?

HashDit is a Web3 Security Firm dedicated to providing completely free security solutions to both end users and protocol developers on the BNB Chain. Our central objective is to furnish crucial threat intelligence to empower day-to-day DeFi investors in making well-informed decisions. Navigating this DeFi intricate landscape poses challenges even for seasoned investors, let alone newcomers. HashDit aims to bridge this knowledge gap by offering timely and comprehensive threat intelligence on DeFi projects. HashDit's API integration extends its influence to numerous prominent applications, anchoring active measures to safeguard users from the clutches of fraudulent activities. Hashdit typical clients include but are not limited to the following protocols.

1.TrustWallet

HashDit's API takes center stage within TrustWallet, an industry vanguard Web3 Wallet. Serving as a protective layer within the user experience, HashDit's threat intelligence suite preempts elevated risks by promptly notifying users before they connect to the dApp or execute transactions. This proactive approach ensures users operate with heightened vigilance, fortifying their engagement within the dynamic DeFi landscape.

In 2023, HashDit API continually safeguarded assets on TrustWallet and prevented 584k of 630k risky BSC transactions, that's a 93% coverage, preventing users from transferring nearly $169m to scammers!

2.PancakeSwap

This leading DEX on the BNBChain, with a substantial $1.3 billion in TVL, seamlessly incorporates HashDit's solution. Automated scans of tokens within the PancakeSwap framework offer users discernible risk scores. This feature empowers users with real-time insights into potential transactional risks, bolstering informed decision-making amid their DeFi interactions.

3.BscScan

A prime example of HashDit's impact unfolds through its collaboration with blockchain explorers, most notably BscScan. Integrating risk alerts within the explorer's interface bolsters user prudence and caution. Users are empowered to tread warily when engaging with projects or addresses displaying suspicious or high-risk attributes. This measured approach fosters an environment of cautious exploration, preventing undue exposure to potential risks.

Integrate HashDit API With 3 Steps

Step1: Apply for access by sending a request with following information to support@hashdit.com.
- Project name
- Project description & main products
- Estimated chains
- Estimated QPS
  - Query Per Second, the HashDit Security API rate limit is 1200 calls/minute. If you require a higher limit than the available plans, please input correct QPS info.
- Scenario (see more details in “Security Scanner Scenario” below)
  - DeFi Wallet
    - Url Security Scanner
    - Address Security Scanner
  - Dex
    - Token Security Scanner
    - Others (input the description)
- Release date
Step2: HashDit team will review the request and provide the api token and test examples within 5 work days.
Step3: You can build up the Security Scanner within your project 🎉.

Security Scanner Scenario

1.Wallet

Typical Example:
https://trustwallet.com/blog/a-safer-web3-experience-with-trust-wallet-security-scanner
Url Security Scanner
- API: https://hashdit.github.io/hashdit/docs/hashdit-api/dapp-url-analysis
- User interaction and design references

Address Security Scanner
- API: https://hashdit.github.io/hashdit/docs/hashdit-api/address-analysis-api
- User interaction and design references

2.Dex Token Security Scanner

Typical Example:
https://pancakeswap.finance/swap?outputCurrency=0xDd25E1955FD9F7B3aBE83CC419070A7ace104DCE
API：https://hashdit.github.io/hashdit/docs/hashdit-api/address-analysis-api
User interaction and design references

Monthly Incident Sharing - January 2024

February 8, 2024 · 4 min read

SCS@HashDit

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 Jan 2024 edition, the total losses mounted up to $153 million, showing a staggering 453% increase compared to January 2023.

Top 5 DApps incidents

Orbit Chain - $81.5m

Orbit Chain is a Bridge protocol, which uses the model of locking collateral on the source chain to mint wrapped tokens on the destination chain. In this attack, the hacker was able to compromise 1 of the bridge’s vault and steal its funds. Hack tx

Root cause: Backend compromise. The hacker was able to produce 15 correct Signer keys (v, r, s values), although the threshold needed was just 7.

Vulnerable code snippet:

Magic Internet Money (MIM) - $6.5m

Magic Internet Money is a DeFi protocol which allows lending and borrowing of funds. In this attack, the attacker was able to compromise 1 of the protocol’s markets and steal funds. Hack tx

Root cause: The borrow function in CauldronV4 contracts was vulnerable to manipulation of the part parameter (the user’s share of total debt) via repeatedly borrowing and repaying an asset, taking advantage of the rounding error.

Vulnerable code snippet:

Gamma Strategies - $4.6m

Gamma Strategies is a DeFi protocol which allows active liquidity management and market making strategies. In this attack, the attacker was able to compromise 1 of the protocol’s vaults and steal funds. Hack tx

Root cause: The liquidity ratio checker function erroneously allowed for deposits in any ratio so long as the contents within the vault were single-sided. This allowed for a disproportionate amount of token 0 being deposited, gaining more shares than expected. A second issue was there was no check for the current tick to be within the base position’s lower and upper tick (only a check for the tick change)

Vulnerable code snippet:

Radiant - $4.4m

Radiant is a DeFi protocol which allows lending and borrowing of funds across chains. In this attack, the attacker was able to compromise 1 of the protocol’s markets and steal funds. Hack tx

Root cause: "New/empty market" exploit. It is a known vulnerability to the combination of a rounding error and a totalSupply value of 0. Bug introduced in recent upgrade.

Vulnerable code snippet:

Socket Dot Tech - $3.3m

Socket Dot Tech is an Interoperability protocol bringing seamless connectivity across blockchains. In this attack, the attacker was able to compromise 1 of the protocol’s vaults and steal funds. Hack Tx

Root cause: Unsafe call in the performAction() function. The attacker constructed calldata in the swapExtraData parameter to call transferFrom() of arbitrary tokens, transferring tokens approved to the contract by other users to the attacker's address. Bug was introduced in the recent proxy upgrade.

Code snippet:

Key lessons for developers

Keys should be properly secured, rotated regularly and have some level of decentralization. Adopt a zero-trust model. Conduct proper background checks for new employees in view of insider compromises.

Validation is important - ensure all possible user inputs are checked for state changing methods. This is especially true for calldata parameters where attackers can craft any data and when the protocol contract handles users’ approvals.

Rounding in Solidity always rounds down. As such, it is important to perform multiplication before division and to round down for the user during withdrawals, and round up during deposits. Consider increasing precision during calculations to avoid unexpected manipulation attacks.
However, in the latest donation attacks for lending protocols, we see that the usual rule to favor protocol for calculations is no longer sufficient. There must be better health checks for bad debt as well, at the end state of a transaction.

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.
Always engage a security auditor to review all code upgrades before they are deployed on chain. This prevents new bugs from being introduced.

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

Twitter Compromise Security Blog

January 27, 2024 · 8 min read

SCS@HashDit

Twitter Compromise Security Blog

Introduction

In the landscape of cryptocurrencies, Twitter plays a primary role as a conduit of essential news and real-time updates, weaving itself into the fabric of professional and personal crypto interactions. Yet the importance of this reach brings with it a need for unyielding security. Compromised Twitter accounts - particularly those focused on crypto - pose substantial threats; their impacts can resonate deeply not just within individual digital wallets, but across the entire crypto market.

In this blog post, we're going to explore both the personal and professional implications of these security breaches, paying special attention to their effects within the crypto community. As we journey through the world of crypto Twitter, grasping the potential threats is crucial to fortifying our digital fortress and nurturing a safe, reliable space for crypto discourse.

Part 1: Understanding Compromised Accounts

A compromised Twitter account means a legitimate, usually verified account, falls prey to a malicious entity. The attacker obtains control, gaining access to personal data and the power to impersonate the original account holder. In the crypto-Twitter world, this can lead to misinformation, financial manipulation or phishing attacks, posing substantial risks to the wider crypto community.

There are 3 main risks associated with Compromised Accounts

Potential distribution of harmful links or malware. This could occur if the malicious actor uses the hijacked account to send or post dangerous links which, when clicked, could infect a user's device with malware. This puts the user's personal and potentially sensitive data at risk, as malware can be used to steal information, spy on user activity, or even hijack further accounts.
Manipulate trusting followers into making detrimental financial decisions based on misleading guidance.
Security breaches reflect negatively on the organization behind the account, damaging their reputation and casting doubt about their competence in protecting user information and funds. Hence, Twitter account security is crucial to maintaining credibility and safeguarding followers' interests.

There have been several notable accounts (not only Crypto related) that have been compromised just in 2024 so far:

SEC Ref
Mandiant Ref
CoinGecko Ref
ReStake Finance Ref
Injective Ref
Arkham Intelligence’s CEO Ref

Part 2: Signs of a Compromised Twitter Account

Recognizing the signs of a compromised Twitter account is crucial to minimize potential damage.

Symptoms include but are not limited to:

User point of view
1. Compromised accounts start making an unexpected tweet from their usual timeline.
  For example,
  - Urgent call to action message
  - Twitter card spoofing is a technique used by the scammers to trick users into believing they are clicking on the official site.
  - Replies are usually turned off to prevent users from calling them out and warning others.
2. Making unsolicited DMs to everyday users. This will be to gain trust since it appears to be from a trusted source and can be seen from the DM recipient.
3. Blocking security related accounts that call them out. This is to prevent accounts with wider following from informing others.

Compromised account’s point of view
1. The project party might start noticing unexpected tweets, retweets, or likes appearing on your profile
2. Receiving direct messages you did not send
3. Noticing changes to your account settings such as email, password, or linked phone number that you didn't make
4. Alerts for login attempts or successful logins from unfamiliar locations, a sudden increase in the number of unknown followers, involuntarily following new accounts
5. Messages from your followers about suspicious activity or spam originating from your account.

Part 3: How Twitter Accounts Get Compromised

Understanding how hackers compromise Twitter accounts is key to enhancing your security position.

Phishing:
1 of the most common techniques used is through Social Engineering and Phishing. For example, if DMs are turned on and your social media presence is strong, they target you, gain your trust and subsequently ask you to click and authorize Twitter permissions through a 3rd party site. This 3rd party site will gain access to posting on your behalf, changing passwords and settings etc.
SIM Swap Attacks:
These represent a real threat to Twitter users who've linked their accounts with their mobile numbers, presenting a lucrative attack vector for bad actors. In essence, scammers manipulate this to their advantage to commandeer your account.
Password Vulnerability and Lack of 2FA:
A negligently secure mindset lays the foundation for such attacks. Usage of weak passwords that can fall prey to brute-force attacks and absence of Two-Factor Authentication (2FA) turns the account into low-hanging fruit for hackers.
Consequences of Data Breaches:
Accounts running on the same password across multiple platforms are in jeopardy. The compromise of one account may well trigger a domino effect, subjecting various other accounts to risk too.
The Risk of Malware:
If you're storing passwords unencrypted on your local desktop or making visits to dangerous websites to download potentially malicious applications, you're inadvertently setting the stage for hackers to access your passwords.

Part 4: How to Secure Your Twitter Account

Understanding the necessary steps to secure your Twitter account is essential to maintaining your privacy and safety online.

To ensure the robust security of your Twitter account, consider the following steps:

Creating a strong password is one of the first and most fundamental steps towards securing your online presence. Regularly updating your password can also bolster its resilience against unauthorized access.
It should be at least 12 characters long and composed of varied elements including a combination of uppercase letters, lowercase letters, numbers, and symbols. Avoid including easily guessable data such as your name, birthdates, or common words. If remembering a complex password seems challenging, consider using a reliable password manager or creating a passphrase, which is a sentence-like string of words that is easy to remember and hard for hackers to crack.
Switch to Non-SMS-Based 2FA: It would be best to activate a non-SMS-based two-factor authentication. Instead of SMS, consider using an authenticator app or, for maximum security, a Yubikey.
Regularly Audit Third-Party App Permissions: It's pivotal to periodically verify third-party application permissions linked to your account and screen for any unsanctioned approvals. These could potentially be monitoring your actions. Basic guide is as follows:
More -> Settings and Support -> Settings and Privacy -> Security and Account access -> Apps and sessions -> Connected apps -> Delete it!
Be Cautious of Suspicious Activity: Stay alert to any dubious emails, direct messages, or links from unfamiliar sources. In spite of possible impersonations, it's prudent not to interact with them.
Use Secure and Updated Devices: It's crucial to access your Twitter account through secure devices that are regularly updated to keep your account safe from newly discovered threats.
Continuously Review Account Access: Regular updating of who has permission to access the Twitter account can prevent unauthorized access.
Periodic Security Model Updates: Review your security model now and then, especially when there are changes in your organization like a team member leaving or a new member joining and needing access to the account.
Being familiar with prevalent hacking techniques and conducting regular security checks allow you to proactively defend your account. Understanding the way hackers operate and staying vigilant about your account's security offers an extra layer of protection.

Part 5: What to Do if Your Account Gets Compromised

If your account gets compromised, it is paramount that you react quickly to mitigate any negative consequences to the community.

Password Reset: Promptly update your password, making sure to include all associated emails.
Cease Third-Party Permissions: It's crucial to terminate all third-party permissions without delay to prevent further unauthorized access.
Inform the Community: Immediately alert your community about the compromised account using alternative communication channels such as a secondary Twitter account or other platforms like Discord or Telegram. This would warn them against trusting any new posts from the breached account.
Contact Twitter Support: If all these measures still yield no improvement, consider reaching out to Twitter's customer support, ideally from a different Twitter account. This might aid in further resolving the issue.

Conclusion

In conclusion, in an era of escalating cyber threats, safeguarding your digital presence is more critical than ever, particularly so for projects that reach a large audience or manage high Total Value Locked (TVL). The stakes for these projects are particularly high due to the significant influence and value they hold.

Understanding common signs of account compromise, being aware of prevalent hacking methods, creating robust passwords, and consistently refining security settings are not just best practices, they are necessities. Projects must take accountability for their impact and make Twitter account security a constant priority. Always remember, the strength of your online security is only as robust as its weakest link, thus maintaining a secure environment requires consistent vigilance, awareness, and behavior adjustments.

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

2023 Top 10 Security Incidents

December 31, 2023 · 5 min read