On 22 Feb, a vulnerability was reported to be found in CryptoNinja World, a dApp deployed on Ethereum.
Its “burn(uint256 tokenId) external virtual” function defined in the contract deployed at 0xd93704f2a0eA3Db109dE194D4a51ff3e5e77CEfd did not validate whether the owner of “tokenId” was the msg.sender. This resulted in a vulnerability where any address could burn the NFTs held by any address.
Hacker Exploits Level DaosaurNFT’s Discord Server
On 22 Feb, DaosaurNFT’s discord server had been exploited. DaosaurNFT(@DaosaurNFT) is an NFT project deployed on Ethereum.
BAYCs and CLONE X Are Stolen
On 23 Feb, popular NFTs including BAYC 6396, 4587 and CLONE X 3354 were stolen. CLONE X 3354 was sold for 5 ETHs, and BAYC 6396 was sold for 67.990 ETHs on Blur.
Hacker Exploits Level Finance’s Discord Server
On 23 Feb, Level Finance’s discord server had been exploited. Level Finance (@Level_Finance) is a DeFi application deployed on the BNB chain.
Hacker Exploits Rubic’s Discord Server
On 24 Feb, Rubic’s discord server had been exploited. Rubic (@CryptoRubic) is a cross-chain aggregator.
Hacker Exploits MurAll’s Discord Server
On 25 Feb, MurAll’s discord server had been exploited. MurAll (@MurAll_art) is a protocol for user created art on Ethereum. In response, MurAll urged users not to click any links from the MurAll Discord server.
A later update by MurAll stated that despite regaining control of the Discord server, scammers have hijacked the MurAll Discord invite. The invite takes users to a phishing verification bot. As of the time of writing, MurAll will be updated the website.
Otherdeed 96085 Is Stolen and Resold on Opensea
On 26 Feb, one famous NFT Otherdeed 96085 was stolen and resold on Opensea for 2.2 ETHs in less than 6 minutes.
RUG-PULLS:
Hope Finance Rug-pulls
On 21 Feb, Hope Finance, an application deployed on both Ethereum and Celer had been confirmed to be a rug-pull.
The team behind the project leveraged Celer and Uniswap to move all the held ETHs to Ethereum and sent 1095 ETHs from three addresses to Tornado Cash to cash out.
1095 ETHs worth around US $2 million were exploited in this incident.
Additional Details:
– Attacker’s Addresses
0x957D354d853a1FF03dDa608F3577d24eA18fCecE
0xB83dD80d040C0AB2cd9495E748915275713120a5
0x43B89dE77189b53f93BfF1c6DF8d3d6Fb97BA688
CONCLUSION-
9 notable security incidents have occurred in the past week. 1 was a rug-pull, 8 were attacks. 2 of 8 attacks were attacks against smart contracts and the rest were on social media or phishing attacks.
A Reminder for Project Teams: Always test thoroughly. Do smart contract audits before deploying smart contracts on-chain. Be alert to any anomalies happening in the various social media accounts you manage.
A Reminder for Crypto Users: Be cautious about suspicious links, emails, websites, and projects launched by teams without established reputations.
It is important for everyone in the crypto community to gain understanding and practice sufficient levels of cybersecurity.
To stay updated on notable security incidents in the world of Web3.0, subscribe to our newsletter: https://fairyproof.substack.com/
Recently, a number of users in the blockchain ecosystem have discovered that their Telegram accounts have been stolen. In some of these incidents, the victims were informed by their contacts, while others were discovered by the victims themselves.
The modus operandi in all these cases was to hack into individual accounts by stealing information from Telegram accounts and then send false messages to the victims by impersonating their contacts or attacking their contacts with the victim’s account.
Using social media platforms or applications to launch attacks are reported from time to time. However, in the past, hackers often used Twitter or Discord rather than Telegram.
This shows that the trend of using social accounts to carry out attacks is growing rapidly and the scope of the attacks is expanding rapidly.
The Fairyproof research team believes that this trend and problem deserves the attention and vigilance of the entire ecosystem. In view of this, the Fairyproof research team has summarized and analyzed these attacks based on the various characteristics of hackers using social accounts, and would like to share our findings with our peers and users in the ecosystem.
Full Article
When it comes to security incidents in the blockchain ecosystem, many users usually think that most of hackers’ attacks are on smart contracts, especially on DeFi-type contracts. Because these projects often have a large amount of crypto assets locked up in their smart contracts, by attacking these smart contracts, hackers can directly prey on the crypto assets within them.
However, this approach requires a high level of skill and a significant technical threshold, as the hacker needs to be proficient in smart contracts and find vulnerabilities in them in order to find the point of attack and launch the attack. It is therefore only suitable for a small group of hackers known as “scientists”.
However, hackers will not easily “give up” in the face of the huge market value of crypto assets and the lucrative benefits of illegal operations. As a result, in addition to this high threshold attack, an increasing number of unskilled criminals are seeking to use social networking software commonly used by the crypto community to steal account information for fraudulent purposes and to steal the assets of crypto asset holders.
We refer to this type of attack as a broad social account attack (or “phishing attack”, “social engineering attack”, etc.) [1].
I. What is a social account attack
A social account attack is when a hacker
– Using social networking software (e.g. email, instant messenger, social media platforms, etc.) to commit fraud against a target user by inducing the target user to disclose their sensitive information in order to steal their assets or by tricking the target user into actively transferring the assets they hold.
– Or by implanting a Trojan horse into the target user’s device, hacking into his or her social accounts, stealing his or her social information and using the account to defraud the target user’s associated social contacts to obtain his or her assets.
According to Fairyproof 2022 Blockchain Ecosecurity Annual Report, which counted 378 typical security incidents, there were 123 cases of attacks using social media, accounting for 32.54% of the total, which is comparable to the number of hacker attacks on smart contracts (143 cases)[2].
This shows that the use of social platforms/tools to carry out attacks has become an issue that every user in the blockchain ecosystem security must pay high attention to.
This paper attempts to explore and summarize the common methods of attack on social media and defensive measures used by hackers in the blockchain ecosystem, exploring five dimensions: common social platforms/tools, users using social platforms/tools, key points where social platforms/tools are used for attacks, dangerous operations that lead to the loss of assets by users, and preventive measures against attacks.
II. Social platforms/tools commonly used in the blockchain ecosystem
In the blockchain ecosystem, people usually choose different social platforms/tools with different characteristics depending on their needs.
A common social platform used for extensive business outreach and first-hand information is Twitter [3].
Discord[4] is a popular social networking tool used to bring communities together, motivate community members and facilitate interaction between project owners and the community.
To protect privacy and facilitate communication and negotiation, Telegram [5] is the main instant messaging software used.
The above three are the most commonly used social platforms/tools in the blockchain ecosystem. Apart from these, other social tools such as WeChat [6], WhatsApp [7], Facebook [8] and Instagram [9] are also used by some projects, but not nearly as frequently as the above three tools. Therefore, the exploration in this paper mainly focuses on the above three social platforms/tools.
III. Users who use social platforms/tools
In the blockchain ecosystem, we have broadly divided users of social platforms/tools into three categories according to the purpose of their use of social platforms/tools.
– Project side: These are users who are project operators or crypto asset issuers in the ecosystem. They usually issue various types of tokens themselves or have them locked in the project contracts they operate. These are usually ERC-20 tokens[10], ERC-721 tokens[11] or ERC-1155 tokens[12], etc.
These users use social platforms/tools mainly for the purpose of posting updates on their operational projects or updates on their issued tokens.
– Crypto asset investors or project users: These are users who may conduct on-chain transactions or interact with (the project’s) smart contracts. They usually buy various types of tokens issued by the project, trade tokens or interact with the contracts of the project run by the project.
These users use social platforms/tools mainly to get the latest news on the issuance of various types of tokens, the latest news on contract deployment interactions, the latest news on token trading and to share information about themselves.
– Blockchain Industry Practitioners: This category of users are those who work in the blockchain industry and are involved in the day-to-day aspects of the business such as operations and maintenance, commerce and development.
This category covers a wide range of users who do not necessarily invest in or hold crypto assets, but whose work is directly related to the operation of crypto assets or blockchain projects and have extensive connections with their peers.
These users use social platforms/tools mainly for the purpose of accessing various types of information to facilitate their internal and external communication, work, etc. They have a wide range of contacts in the ecosystem, and they spread and exchange information.
IV. Key points of social platforms/tools being used for attacks
In the blockchain ecosystem, various categories of users use social platforms/tools for different purposes and characteristics, which gives hackers the opportunity to make full use of these characteristics to target their targets and carry out attacks. The followings are the main scenarios.
– Exploiting the trust of crypto asset investors or project users in the project owner, the social platforms/tools used by the project owner are hijacked to launch attacks and place false messages to crypto asset investors or project users.
In this scenario, the main purpose of the social platform/tool used by the project owner is to distribute information, while the investor or project user is the direct consumer of such information. Under this interaction model, investors or project users generally have a psychological default belief that the information posted by the project owner in the social platform/tool is authentic and authoritative, and will follow the addresses, links, etc. given by the information species directly.
This default trust in the authenticity and authority of the information gives hackers an opportunity to take advantage of it. If a hacker steals the project owner’s social accounts and posts links to malware, fake transfer addresses or fake token issuance links, investors or project users are likely to click on the links, transfer assets or buy fake tokens without thinking, based on this trust.
Cases of hackers using Twitter and Discord to launch attacks are particularly common in this type of attack, as these two platforms/tools are mostly used by project owners to post information.
Where it is the project owner’s social accounts that are exploited, it is the crypto asset investor or project user who may lose crypto assets.
– Exploiting the strong desire of investors or project users to invest in or interact with a project and sending false project information directly to the target user
This type of attack occurs particularly often on the Twitter platform. This is because many opinion leaders or investment gurus in the blockchain ecosystem particularly like to visibly show their desire and quest for new projects and targets in their Twitter feeds.
Hackers take advantage of this desire to tweet publicly or privately about so-called “new projects” and leave links to these projects. These links can be links to malware, fake transfer addresses or fraudulent token-along offers.
If Twitter users see these messages and links and click on them without thinking or following the instructions, they are likely to fall prey to the hackers and lose their assets.
The hackers are using Twitter as a tool and the investors or project users are the ones who may lose their crypto assets.
These two types of attacks are the most common “phishing attacks” that we encounter in the blockchain ecosystem.
– Using the blockchain practitioner’s extensive network of contacts to hijack their social platforms/tools and use them to send false information to the practitioner’s contacts
The main use of social networking platforms/tools by blockchain practitioners is to interact and exchange information internally and externally. The most common tool used for this purpose is Telegram, which is therefore also used by hackers to attack such users.
In this type of attack, the hacker first steals the account of the targeted user by setting up a trick (e.g. by obtaining a login verification code, stealing a login key, etc.), then logs into the account and copies the correspondence of the social network he or she is messaging with, and then sends a fraudulent message to the targeted user posing as the social network (e.g. asking the targeted user to send encrypted assets to an address provided by the hacker, authorizing the hacker to steal the transactions of the encrypted assets, or to send a message to the target. clicking on a link to malware sent by the hacker, etc.)
Using this method, the hacker can impersonate all of the social connections on a Telegram user’s contact list and attack the target user or even all of them.
This type of attack is much more lethal and stealthy, and less likely to be detected, as these connections have already established a stronger trust relationship with the Telegram user.
These types of attacks began to appear frequently in late January this year. It is worthwhile for all Telegram users to be on high alert.
V. Dangerous actions that lead to loss of assets for the user
In any of the typical attacks listed above, the ultimate goal of the hacker is to exploit the user’s trust and trick the user into following the links or instructions he is given, regardless of the method used to launch the attack. These actions will eventually lead to the loss of the user’s encrypted assets.
The danger is therefore quite high. These dangerous actions usually include the following.
– The targeted user clicks on a link or scans a QR code from an unknown source, etc. This could lead to the user installing a Trojan horse in the environment of their crypto wallet, which could lead to the theft of their wallet key, or to the user being tricked into following up on an impostor project website (e.g. buying an impostor token), which could lead to the loss of crypto assets.
– The targeted user enters their wallet key or key in a dialog box or interface of unknown origin. This leads directly to the hacker taking control of the user’s crypto wallet and thus transferring all crypto assets from the wallet.
– The target user clicks to authorize a transaction from an unknown source. This would give the hacker the right to transfer the crypto assets from the user’s wallet at will.
VI. Preventive measures against the attack
In view of the characteristics of the typical attacks listed above and the dangerous actions that lead to the loss of crypto assets, Fairyproof recommends the following precautions for all three types of users to avoid having their social accounts exploited by hackers on the one hand and losing their crypto assets on the other.
– Security recommendations for day-to-day operations
For project information, take multiple verifications (i.e. through multiple channels and platforms) to verify its authenticity.
Pay more attention to security information in the ecology and familiarize yourself with the features and precautions of new attacks and cases.
Be cautious of websites with odd URLs and stay highly alert to unfamiliar links and click on them with caution.
– Security advice for Twitter use
Keep your account information secure and do not share it publicly; set up multiple verification processes and verification information for your account; set up privacy and security options; handle private information with care; do not click on any suspicious links on Twitter and do not scan any suspicious QR codes.
– Security advice for using Discord
Same security tips as for Twitter; also set up permissions for message senders, block suspicious users, activate 2-Factor authentication, etc.
– Security advice for using Telegram
As social networking on Telegram is more private and relies more on trust, users should be careful not to share authentication codes and, in particular, to set up their own private information (e.g. don’t disclose phone numbers, don’t make private information visible, etc.) when using Telegram, in addition to the recommendations of Twitter and Discord. Also be vigilant about the behavior of your social contacts and use voice or other non-text communication to confirm any odd behavior immediately.
– Security advice for using crypto wallets
When we open a crypto wallet, do not under any circumstances enter your password or mnemonic on a suspicious screen.
For each transaction, read the signature message carefully before signing, check the authenticity of the website and other information in the signature message and compare it to the website you intended to access.
Refuse to sign transactions with ambiguous or oddly sourced addresses.
The advice on the secure use of wallets is not the focus of this article and is provided here only as a side note to the advice on the secure use of social platforms/tools and will not be elaborated upon.
The role of social platforms/tools in the blockchain ecosystem is to build trust between people, but the underlying technology and operational processes on which such trust relationships are based are open to various vulnerabilities and exploitation. Therefore, once people have built up trust based on these social platforms/tools, hackers can use them to commit fraud and attack with impunity once they have “stolen” this trust relationship by exploiting the loopholes in technology or operation.
All precautions against these frauds and attacks can be summarized in the following guidelines.
– Reduce psychological dependence on this relationship of trust.
– Use multiple technical means and more rigorous operational processes to challenge this trust relationship, thereby increasing the cost and raising the threshold for hacking, and ultimately protecting the project and protecting the asset.
References:
[1] Salahdine F, Kaabouch N. Social engineering attacks: A survey[J]. Future Internet, 2019, 11(4): 89.
[2] Fairyproof’s Review Of 2022 Blockchain Security,
From 13 February 2023 to 19 February 2023, all security incidents that have occurred were Security Hacks.
SECURITY HACKS:
Hacker Leverages MEV Contract Front-Run in Attack Against Anyswap
On 15 Feb, a hacker attacked Anyswap, an application deployed on Ethereum.
The hacker leveraged an MEV contract to front-run a regular WETH transfer transaction by calling AnyswapV4Router’s anySwapOutUnderlyingWithPermit function to approve token spending. Although the function validated the permit signature, the transaction that exploited WETHs in this incident did not get validated. Therefore, in the subsequent function calls, the hacker could call the safeTransferFrom function to allow the _underlying address to approve spending of its WETHs by the hacker without validating signatures.
87 ETHs worth around US $130,000 were exploited in this incident.
On 16 Feb, a hacker attacked Platypus, an application deployed on the Snow blockchain, by leveraging on a flash-loan.
The root cause of this incident was that the emergencyWithdraw function defined in the MasterPlatypusV4 contract did not validate whether a borrower had paid back the debt.
The attacker flash-loaned 44 million USDCs, called the Platypus Finance contract’s deposit function to mint LP-USDCs. The attacker then staked the LP-USDCs to MasterPlatypusV4’s fourth vault, called the positionView function and minted a large amount of USPs. According to normal logic the hacker should own a huge debt by staking USPs and, therefore, should not be able to withdraw his/her staked assets. However, the vulnerability in the emergencyWithdraw function allowed the hacker to withdraw his/her staked assets.
After paying back the flash-loan, the hacker acquired a profit of 41,794,533 USPs and exchanged them to stable coins worth around US $8,522,926.
On 17 Feb, a hacker attacked Dexible, an application deployed on Ethereum.
The root cause of this incident was that the one of its contracts had a vulnerability in its access control.
The hacker defined a “transferfrom” function and passed this function together with a user’s address (0x58f5f0684c381fcfc203d77b2bba468ebb29b098) and the hacker’s address (0x684083f312ac50f538cc4b634d85a2feafaab77a) to a “fill” function. This results in the user’s address to approve the hacker to spend the token. All the exploited assets were transferred to Tornado Cash.
Crypto assets worth around US $1.54 million were exploited in this incident.
On 18 Feb, NFT project deployed on Polygon OkCat (@OkCat_NFT) announced on Twitter that their Twitter had been hijacked.
In their most recent update, the NFT project also warned users that the current Discord server is all a scam and urged users to unsubscribe and spread the word.
Revert Finance Team Claims v3utils Contract Attacked
On 18 Feb, the team behind Revert Finance, an application deployed on Ethereum, claimed on Twitter that its v3utils contract had been attacked by a hacker.
90% of the exploited assets were stolen from single accounts and the exploited assets included 22983.235188 USDCs, 4106.316699 USDTs, 485.5786287699002 OPs, 0.18217977664322793 WETHs, 36.59093198260223 DAIs, 211.21463945524238 WMATICs and 22 Premias.
Most of the addresses that had approved this contract to spend their tokens had revoked their approvals. The team reminded those that had not revoked their approvals to revoke their approvals. The team planned to release a full report about this incident and compensate the victims.
6 notable security incidents have occurred in the past week. 5 of 6 security incidents were attacks against smart contracts and one was on social media.
A Reminder for Project Teams: Always test thoroughly. Do smart contract audits before deploying smart contracts on-chain. Be alert to any anomalies happening in the various social media accounts you manage.
A Reminder for Crypto Users: Be cautious about suspicious links, emails, websites, and projects launched by teams without established reputations.
It is important for everyone in the crypto community to gain understanding and practice sufficient levels of cybersecurity.
To stay updated on notable security incidents in the world of Web3.0, subscribe to our newsletter: https://fairyproof.substack.com/
Fairyproof conducts a study of EIP-4337 and present findings with security checkpoints.
EIP-4337 [1] is a proposal for implementing account abstraction which allows users to use smart contract wallets instead of an Externally Owned Account (EOA) as their primary account.
The biggest motivation to create this EIP is to avoid changes in Ethereum’s consensus layer and implement account abstraction mainly in smart contracts.
A significant feature that an account abstraction solution should have is to simulate transactions that users initiate with EOAs. The biggest difference between a transaction initiated by an EOA and one initiated by a contract account is that an EOA requires a signature signed by the EOA’s private key.
To implement such a solution, five concepts are introduced in this proposal: “UserOperation”, “Bundler”, “EntryPoint”, “Paymaster” and “Aggregator”.
A “UserOperation” is a data structure that defines a transaction initiated from an EOA. In this EIP it should be implemented and sent to a separate mempool.
A “Bundler” is a block builder that collects UserOperations from the mempool, or a user that can send transactions to a block builder. After a Bundler collects UserOperations, it will send them to a special contract defined as an “EntryPoint”.
An “EntryPoint” is a smart contract that validates and execute UserOperations sent by Bundlers.
A “Paymaster” is a smart contract that can help pay transaction fees on a users’ behalf. This feature is optional and can be used to allow users to pay fees with EIP-20 tokens.
An “Aggregator” is a helper contract. This feature is also optional and is used to validate aggregated signatures.
In essence, the logic proposed in this EIP are as follows:
As a blockchain security company, Fairyproof has studied this EIP and hoped to find all the security checkpoints that should be kept in mind when auditing a solution implemented based on this EIP.
We have studied these five concepts and their proposed implementation details. Here are our findings with security checkpoints:
1. Security Checkpoints for UserOperation’s Implementation
A significant security issue in the EIP’s proposed logic is that malicious actors could launch DOS attacks by sending invalid UserOperations to trick the EntryPoint into execute these operations without paying any fees.
Therefore, validating UserOperations in all the interfaces cannot be ignored.
The following sanity checks should be done for UserOperation:
– Either the sender is an existing contract, or the initCode is not empty (but not both)
– If initCode is not empty, parse its first 20 bytes as a factory address and check if the factory is staked. If the factory accesses global state, it must be staked.
– The verificationGasLimit should be sufficiently low (<= MAX_VERIFICATION_GAS) and the preVerificationGas should be sufficiently high (enough to pay for the calldata gas cost of serializing the UserOperation plus PRE_VERIFICATION_OVERHEAD_GAS)
– The paymasterAndData is either empty, or start with the paymaster address which is a contract that (i) currently has nonempty code on chain, (ii) has a sufficient deposit to pay for the UserOperation, and (iii) is not currently banned.
– The callgas is at least the cost of a CALL with non-zero value.
– The maxFeePerGas and maxPriorityFeePerGas should be above a configurable minimum value that the client is willing to accept. At the minimum, they are sufficiently high to be included with the current block.basefee.
– Only one UserOperation per sender may be included in a single batch. A sender is exempt from this rule and may have multiple UserOperations in the pool and in a batch if it is staked.
2. Security Checkpoints for EntryPoint’s Implementation
The “UserOperation” parameter in the handlOps and simulateValidation interfaces should be checked.
Particularly in the UserOperation data structure: the “sender” field should be a smart contract address rather than an EOA address, the “nonce” value should be unique to prevent replay attacks, the “initCode” should not be null if the account is not on-chain and needs to be created, the “signature” should be dependent on the chainid and the EntryPoint address to prevent replay attacks.
The “beneficiary” parameter in the handleOps and handleAggregatedOps should be a valid beneficiary address.
The EIP suggests the EntryPoint contract to be upgradable. The address that has access control to upgrade the contract should be managed with care and caution. In case it is compromised, the EntryPoint will be exposed to huge risks.
3. Security Checkpoints for IAggregatedAccount’s Implementation
The “userOp” parameter in the validateUserOp interface should be checked. The aforementioned points for “UserOperation” apply to this as well.
The “aggregator” parameter should be a valid address if an aggregator is used or can be ignored if no aggregators are used. And it should be the same as the return value of the “getAggregator” interface.
The “userOpHash” parameter should be a non-null value and be a hash over the userOp (except signature), EntryPoint and chainId.
Regarding the implementation of the validateUserOp interface, the following things should be checked:
– if its caller is a trusted EntryPoint and a smart contract address.
– If the account does not support signature aggregation, it must check if the signature is a valid hash of the userOpHash, and should return SIG_VALIDATION_FAILED (and not revert) if the signature doesn’t match. If any other error occurs, the transaction should be reverted.
– it must pay its caller (EntryPoint) at least the “missingAccountFunds” and may need to pay more to cover future transactions
The validateUserOp interface’s return value should be checked and corresponding operations should be performed according to the return value.
4. Security Checkpoints for IAggregator’s Implementation
The “userOp” parameter in the validateUserOpSignature, aggregateSignatures and validateSignatures interfaces should be checked. The aforementioned points for “UserOperation” apply to this as well.
The “signature” parameter in the validateSignatures should be a non-null value.
With regards to the Aggregator’s implementation, the following things should be specifically checked:
– validateSignatures() must validate the aggregated signature matches for all UserOperations in the array, and revert otherwise.
– An aggregator should stake to be trusted unless otherwise being exempt.
5. Security Checkpoints for Paymaster’s Implementation
The “userOp” parameter in the validatePaymasterUserOp interface should be checked. The aforementioned points for “UserOperation” apply to this as well.
The “userOpHash” parameter should be a non-null value and be a hash over the userOp (except signature), EntryPoint and chainId.
The “withdrawAddress” parameter in the withdrawStake and withdrawTo interfaces should be a valid address.
The “account” in the balanceOf and depositTo interfaces should be a non-zero valid address.
The “withdrawAmount” in the withdrawTo interface shouldn’t be greater than the return value of the balanceOf interface.
A Paymaster should be a valid smart contract address if it is introduced.
A Paymaster should have enough crypto assets to pay relevant operations if it is introduced.
A Paymaster should stake to be trusted.
Conclusion
These security checkpoints do not cover all the potential security issues that this EIP may introduce when implementing a solution. They are only what Fairyproof is specifically aware of when auditing such a solution.
Apart from these checkpoints, there are other important issues that have been extensively talked about in this EIP. These issues are mostly related to logical issues and should be seriously taken into consideration as well when auditing.
From 6 February 2023 to 12 February 2023, all security incidents that have occurred were all Security Hacks.
SECURITY HACKS:
Hacker Attacks Exoniks’ Discord Server
On 7 Feb, a hacker attacked Exoniks’ discord server. Exoniks is an NFT project.
Hacker Attacks CowSwap by Exploiting Inappropriate Approval of Funds Transfer
On 7 Feb, a hacker attacked CowSwap , a DeFi application deployed on Ethereum.
A contract was inappropriately approved to spend a maximum value of DAIs. The hacker had exploited this vulnerability to transfer funds to the hacker’s address.
Here is how the incident happened:
On January 27th 2023 a new solver “Barter” was allowed and moved to production. Shortly after, the Barter solver set an approval to a contract “SwapGuard”.
The SwapGuard contract was used to limit the amount of tokens that could be lost in a single transaction due to slippage.
Because of the vulnerability, the attacker leveraged the approval to transfer funds from the settlement contract to the hacker’s addresses, thus draining the contract.
Crypto assets worth around US $180,000 were exploited in this incident.
At the time of writing, all approvals for the ‘bad contract’ had been revoked, and the Barter Solver has upgraded to a new contract which has no arbitrary execution code functionality built in.
On 7 Feb, a hacker attacked Toxics’ discord server. Toxics is an NFT project deployed on Ethereum.
Wanderverse Announces on Twitter Discord Server Compromise
On 8 Feb, NFT project deployed on Ethereum Wanderverse (@TheWanderverse_) announced on Twitter that their Discord server had been compromised.
On a later update, it was revealed that several community members had “lost assets after going to a scam site and signing an illegitimate tx.”. As a response, the community managed to save about “36 Wanderers and spent ~1.5ETH”. The ETH will be doubled and donated on retrieving the stolen Wanderers to the community treasury which will be operated by an elected group of members that will create proposals to protect community members in the future.
Drunken Ape Announces Discord Server Hacked
On 8 Feb, NFT project deployed on Solana Drunken Ape (@DrunkenApeSC) announced on Twitter that their Discord server had been hacked. As a response, the account hosted an AMA to address questions from the community. Later, the account announced that a new Discord server had been established.
Owner of LGTPoo Exploits LianGoPay Through Deployment of Fake LP Pool
On 9 Feb, LianGoPay, a DeFi application deployed on the BNB chain was exploited.
The root cause of this exploit was that the owner (0xb5950375D392728076449271b305639EFD2FC558) of LGTPool had deployed a fake LP pool and deposited a huge quantity of LP tokens into it and acquired 6.14 million LGT tokens.
Crypto assets worth around US $1.6 million were exploited in this incident.
For more details, please refer to:
🧵0️⃣
🚨On 7 Feb, the team behind @LianGoProtocol announced on its Twitter account that its BNB Chain deployed LGTPool vault had been exploited. 6, 148, 859 LGTs worth around US$1.6 million were exploited in this incident.
On 10 Feb, NFT project deployed on Ethereum WeAbove (@weaboveofficial) announced on Twitter that their Discord server had been hacked. In a later update, the project announced that their team is working to refund drained money, and retrieve and purchase the WeAbove NFTs to return them to their rightful owners.
Hacker Attacks dForcenet in Oracle Manipulation
On 10 Feb, a hacker attacked dForcenet, a DeFi application deployed on both Optimism and Arbitrum.
The root cause of this incident was that the implementation did not have measures to prevent re-entrancy attacks, thus its Oracle was manipulated.
The hacker had managed to exploit 719,437 dForce USDs (USXs) and 1236 ETHs on Arbitrum and transferred the USXs to Optimism. Additionally, the hacker also exploited 1,037,000 USXs on Optimism. All USXs were exchanged to 1110 ETHs worth around US$ 1.75 million and all the ETHs remained in its address on Optimism.
In total, crypto assets worth around US $ 3.7 million were exploited in this incident.
0x6c19762186c9f32c81eb2a79420fc7ad4485aa916cab37ec278b216757bfba0d on Optimism
0x5db5c2400ab56db697b3cc9aa02a05deab658e1438ce2f8692ca009cc45171dd on Arbitrum
Hacker Attacks Sushiswap in Price Difference Leverage
On 10 Feb, a hacker attacked Sushiswap , a DeFi application on Ethereum.
The root cause of this incident was that the price fed by Chainlink did not match the latest market price in its BentoBoxv1 contract.
The hacker flashloaned 574,275 +785,560 xSUSHIs and staked them in Sushi. Later, the price for kmxSUSHI/USDT fed by Chainlink decreased by 16.9%. The hacker leveraged this price difference and called the liquidate() function to acquire 15,429 + 11,333 USDTs.
Crypto assets worth around US $ 26, 000 were exploited in this incident.
CONCLUSION-
9 notable security incidents have occurred in the past week. 5 of 9 security incidents involve social media accounts and 4 were attacks against smart contracts.
A Reminder for Project Teams: Always test thoroughly. Do smart contract audits before deploying smart contracts on-chain. Be alert to any anomalies happening in the various social media accounts you manage.
A Reminder for Crypto Users: Be cautious about suspicious links, emails, websites, and projects launched by teams without established reputations.
It is important for everyone in the crypto community to gain understanding and practice sufficient levels of cybersecurity.
To stay updated on notable security incidents in the world of Web3.0, subscribe to our newsletter: https://fairyproof.substack.com/
On 1 Feb, SoDeadNFT (@SoDeadNFT) announced on Twitter that their discord had encountered a hack. The account later made an announcement that their Discord server and funds were both safe and that the team has handled the situation effectively.
Hacker Attacks Realm Hunter’s Discord Server
On 1 Feb, a hacker attacked Realm Hunter’s discord server. Realm Hunter is a game project.
On 1 Feb, Ethereum-based NFT project Squishiverse’s founder mooney.eth (@mooneynft) announced on Twitter that their Discord had been compromised. The user apologized and expressed their hope that no one had clicked the link posted by the hacker.
The user also indicated their suspicion that tit was “a Twitter account with a Gold Badge wanting to interview” them to be the culprit.
Later, mooney.eth had reported that no one was affected by the hack and urged users to be wary of scammers.
Hacker Exploits TellorFlex Oracle Issue to Attack BonqDAO
On 2 Feb, a hacker attacked BonqDAO, a DeFi application deployed on Polygon.
The root cause was that its oracle TellorFlex had an issue in its price feeder(staker)’s registration.
Hacker Attacks Orion Protocol Through Re-Entrancy Vulnerability
On 3 Feb, a hacker attacked Orion Protocol, a DeFi application deployed on both Ethereum and the BNB chain.
The root cause of this issue was that the implementation had a re-entrancy vulnerability.
In its implementation, the ExchangeWithAtomic contract acted as a marketplace where users could deposit or exchange assets. However, the contract’s exchange function did not have protection to prevent re-entrancy attacks.
Crypto assets worth around US $ 3 million were exploited in this incident.
0x5061F7e6dfc1a867D945d0ec39Ea2A33f772380A (on Ethereum)
0x84452042cb7be650be4eb641025ac3c8a0079b67 (on BNB Chain)
– Attacked Contracts:
0xb5599f568D3f3e6113B286d010d2BCa40A7745AA (on Ethereum)
0xe9d1d2a27458378dd6c6f0b2c390807aed2217ca (on BNB Chain)
– Hash Values of Attacking Transactions:
0xa6f63fcb6bec8818864d96a5b1bb19e8bd85ee37b2cc916412e720988440b2aa (on Ethereum)
0xfb153c572e304093023b4f9694ef39135b6ed5b2515453173e81ec02df2e2104 (on BNB Chain)
Hacker Attacks Superordinary Friends’ Discord Server
On 3 Feb, a hacker attacked Superordinary Friends’ discord server. Superordinary Friends is an NFT project deployed on Ethereum.
OogaVerse Announces Discord Server Attacked
On 3 Feb, Ethereum-based NFT project OogaVerse (@OogaVerse) announced on Twitter that their Discord server had been hacked. The account later made an announcement that their Discord server had been “thoroughly cleaned and is now working as usual”. The project also offered users who had “missing Oogas” to approach support in their Discord server.
Attacker Exploits SperaxUSD Through Token Balance Manipulation
On 4 Feb, a hacker attacked SperaxUSD, a DeFi application deployed on Arbitrum.
An exploiter had increased the token balance for their address to 9.7 billion tokens without providing required collateral and liquidated them before the operation was stopped by joint actions of the Sperax team and Arbitrum ecosystem partners.
All $USDs transactions and the smart contract were blocked on Feb 4, 03:11 AM UTC. The liquidated amount will be recapitalized by the Sperax team before relaunching the protocol.
Crypto assets worth around US $300,000 were exploited in this incident.
9 notable security incidents have occurred in the past week. 5 of 9 security incidents involve social media accounts and 4 were attacks against smart contracts.
A Reminder for Project Teams: Always test thoroughly. Do smart contract audits before deploying smart contracts on-chain. Be alert to any anomalies happening in the various social media accounts you manage.
A Reminder for Crypto Users: Be cautious about suspicious links, emails, websites, and projects launched by teams without established reputations.
It is important for everyone in the crypto community to gain understanding and practice sufficient levels of cybersecurity.
To stay updated on notable security incidents in the world of Web3.0, subscribe to our newsletter: https://fairyproof.substack.com/
