• Bogged Finance Incident: Root Cause Analysis

    22 May 2021
  • Started at May-22-2021 02:47:06 PM +UTC, Bogged Finance was exploited to inflate the BOG balance, which is immediately sold to gain about $3.6M. The incident was due to a bug that allows the attacker to increase the balance via self-transfer. While it appears to be a flashloan attack, it is a flashswap-assisted one. In the following, we elaborate the technical details.




    Summary

    This incident was due to a bug in the BOG token contract that is designed to be deflationary by charging 5% of the transferred amount. Specifically, among the 5% charge, 1% is burned and 4% is taken as a fee for staking profit. However, the token contract implementation only charges 1% of the transferred amount but still inflates the 4% as the staking profit. As a result, the attacker can take advantage of flashloans to significantly increase the staking amount and repeatedly perform self-transfers to claim the inflated staking profit. After that, the attacker immediately sells the inflated BOG for about $3.6M WBNB.

    Read more
  • PancakeBunny Incident: Root Cause Analysis

    20 May 2021
  • Started at May-19-2021 10:34:28 PM +UTC, PancakeBunny was exploited to mint 6.97 million of BUNNY as reward from its vault (VaultFlipToFlip). The incident was due to a bug in the way of measuring asset price from an AMM-based oracle. It is worthwhile to mention that this attack involves 8 flashloans with more than $700M USD. In the following, we elaborate the technical details.




    Summary

    This incident was due to a bug in the protocol that uses the AMM-based oracle, i.e., PancakeSwap, to measure the price of specific PancakeSwap LPs (BNB-BUSDT/BNB-BUNNY). After a flashloan-based price manipulation on PancakeSwap, the exploitation leads to a skewed calculation of reward amount of BUNNY from the VaultFlipToFlip vault. The whole process leads to the unwarranted minting of 6.97 million of BUNNY. After that, the attacker immediately sells BUNNY for profit.

    Read more
  • Bearn.Fi Incident: Inconsistent Asset Denomination Between Vault & Strategy

    16 May 2021
  • Started at 10:36:20 AM +UTC, May 16, 2021, BearnFi’s BvaultsBank contract was exploited to drain about $11M funds from the pool. The incident was due to a bug in its internal withdraw logic in inconsistently reading different asset denomination for the same input amount between the BvaultsBank and the associated strategy BvaultsStrategy. In the following, we elaborate the technical details.




    Summary

    This incident was due to the mis-matched asset denomination implicitly assumed by BvaultsBank and its BvaultsStrategy strategy. Specifically, the BvaultsBank's withdraw logic assumes the withdrawn amount is denominated in BUSD while the BvaultsStrategy's withdraw logic assumes the withdrawn amount is denominated in ibBUSD. Note that ibBUSD is an interest-bearing token and is more expensive than BUSD. As a result, the withdraw request of 100 BUSD effectively leads to the withdraw of 100 ibBUSD. The exploitation of the issue leads to about $11M funds drained from the BvaultsBank contract.

    Read more
  • ValueDeFi Incident: Incorrect Weighted Constant Product Invariant Calculation

    08 May 2021
  • [Disclaimer] This analysis is based on the initial finding by @FrankResearcher!

    Started at 07:41:39 PM +UTC, May 7, 2021, ValueDeFi’s vSwap contract was exploited to drain a number of pools at the loss of about $11M. The incident was due to the improper use of a complex exponentiation power() function behind the calculation and enforcement of the weighted constant product invariant. It is worthwhile to mention that vSwap uses the weighted constant product invariant formula for non 50-50 ratio pools. In the following, we elaborate the technical details.




    Summary

    This incident was due to the mis-calculation by the protocol on the adopted weighted constant product invariant for non 50-50 ratio pools. There is no flashloan or price manipulation involved. The consequence of mis-calculated invariant allows for draining of affected pool funds. Currently, the bug has been exploited to attack 9 non 50-50 ratio pools with the estimated loss of $11M.

    Read more
  • The Spartan Incident: Root Cause Analysis

    02 May 2021
  • Started at 04:38:39 PM +UTC, May 1, 2021, the Spartan protocol contract was exploited to result in more than $30M loss. The incident was due to a flawed liquidity share calculation in the protocol, which is exploited to drain assets from the pool. In this blog post, we elaborate the technical details of the issue.




    Summary

    This incident was due to a flawed logic in calculating the liquidity share when the pool token is burned to withdraw the underlying assets. In particular, the specific hack inflates the asset balance of the pool before burning the same amount of pool tokens to claim an unnecessarily large amount of underlying assets. The consequence of this attack results in more than $30M loss from the affected pool.

    Read more
  • The Furucombo Incident Analysis: Cascading Trust

    27 Feb 2021
  • Started at 16:47:53PM UTC, Feb. 27, 2021, the Furucombo protocol contract was exploited to result in more than $14M loss. The incident was due to a flaw of inappropriate trust in the protocol, which is exploited to cascadingly misuse the allowed spending of this protocol on its users. In this blog post, we elaborate the technical details of the issue.




    Summary

    This incident was due to a flawed logic in trusting a remote entity that has been previously whitelisted. However, the remote entity supports a logic that makes use of the delegatecall feature to invoke user-provided (untrusted) code. As a result, this flawed logic is exploited to spend the approved allowance from the Furucombo protocol users. The consequence of this attack directly result in more than $14M loss from the affected users, including cream.

    Read more
  • The yDAI Incident Analysis: Forced Investment

    04 Feb 2021
  • Started at 21:49:07 PM +UTC, Feb. 4, 2021, the yDAI vault contract was exploited to result in about $11M loss. The incident was due to a flaw in allowing for a forced investment into a strategy, i.e., StrategyDAI3pool, which is manipulated to be not profitable at the investment moment. Here we elaborate the technical details of the issue in this blog post.




    Summary

    This incident was due to a flawed logic in allowing for forced investment of a non-profitable strategy. The flashloan has been utilized to influence the targeted strategy so that it becomes not profitable at the specific transaction of exploitation. This nature of the flaw is the same as an earlier issue related to the TUSD vault, though the slippage control is still in place and the attack is profitable because the withdraw fee has been turned off for vault migration. The consequence of this attack directly result in about $11M loss from the affected yDAI vault. Our initial analysis shows that the attacker grabs $2.8M, and the curve pool gets $3M.

    Read more
  • Cover Incident: The Unlimited Token-Minting Vulnerability

    28 Dec 2020
  • [Disclaimer] This analysis is based on the initial finding by @nomorebear!

    Started at 08:08:12 AM +UTC, Dec. 28, 2020, Cover’s Blacksmith contract was exploited to mess up the total amount of COVER tokens in circulation with currently 40+ quintillion COVERs (1 quintillion = 10^18). The incident was due to a business logic bug in the way of calculating the COVER rewards for staking users. It is worthwhile to mention that it seems a white-hat operation and the gains from the exploit are already returned back to the team. In the following, we elaborate the technical details.




    Summary

    This incident was due to a business bug in the protocol that mis-calculates the reward amount for staking users. There is no flashloan or price manipulation involved. The consequence of normal staking and unstaking operations will directly result in wrong amount of COVER tokens being minted. Currently, the bug has been exploited to issue more than 40+ quintillion COVERs (1 quintillion = 10^18). The minted tokens are sold off at various DEX platforms and the gains are returned back to the team.

    Read more
  • WarpFinance Incident: Root Cause Analysis

    18 Dec 2020
  • Started at 10:24:41 PM +UTC, Dec. 17, 2020, WarpFinance was exploited and drained $\~7.8 million of DAI from its vault (WarpVaultSC). The incident was due to a bug in the way of measuring asset price from an AMM-based oracle. It is worthwhile to mention that this attack does not result in immediate profit for the attacker. In the following, we elaborate the technical details.




    Summary

    This incident was due to a bug in the protocol that uses the AMM-based oracle, i.e., Uniswap, to measure the asset price. After a flashloan-based price manipulation on Uniswap, the exploitation leads to an un-proportional (borrowed) amount of DAI and USDC from the WarpFinance lending platform. The whole process leads to $\~7.8 million of DAI/USDC loss. However, the attacker does not get hold of this fund or is not at his disposal. Instead, the deposited LP tokens as collaterals from the attacker are locked in WarpFinance due to an under-water borrow position.

    Read more
  • Pickle Incident: Root Cause Analysis

    21 Nov 2020
  • Started at 18:37:24 PM +UTC, Nov-21-2020, Pickle Finance was attacked by exploiting two bugs in the ControllerV4 smart contract. The hack results in draining all invested 19.76M DAIs under the StrategyCmpdDaiV2 management. Here we elaborate the technical details of these two bugs in this blog post.




    Summary

    Pickle is a yield-generating YFI-related DeFi protocol on Ethereum that allows users to deposit assets and earn yields. However, it has two bugs in the controller logic: The first one is input validation bug that fails to validate whether a given jar is supported or not; and the second one is arbitrary code execution that allows for external (untrusted) code execution in the context of the controller. The exploitation leads to drain all invested 19.76M DAIs under the StrategyCmpdDaiV2 management.

    Read more
  • 88mph Incident: Root Cause Analysis

    19 Nov 2020
  • Started at 08:26:52 PM +UTC, Nov-17-2020, 88mph was attacked by exploiting a business logic error in the DInterest smart contract. The hack results in maliciously minting approximately $100K worth of MPH tokens. Later, the hacker transferred the funds to the MPH-ETH UniswapV2 pool. With the help of the legendary whitehat, samczsun, the dev team exploited another bug in the MPHMinter contract to drain the Uniswap pool for rescuring existing funds and getting the hacked funds back. Here we elaborate the technical details of these two bugs in this blog post.




    Summary

    88mph is a fixed-rate yield-generation protocol on Ethereum that allows users to deposit assets, earn fixed-rate interests, and farm for MPH tokens. However, it has a flaw in the deposit, funding, early withdrawal process which fails to burn the MPH tokens minted to the funder. By repeating this flow for many times, the hacker successfully minted $100K worth of MPH from nothing.

    Read more
  • Origin Dollar Incident: Root Cause Analysis

    17 Nov 2020
  • Started at 00:47:19 AM +UTC, Nov-17-2020, the Origin protocol was attacked by exploiting its flawed handling of the mint logic in its VaultCore smart contract. The hack results in a loss of approximately $7.7M (11,809 ETH and 2,249,821 DAI) from the affected vault. Here we elaborate the technical details in this blog post.




    Summary

    This incident was due to a bug in the protocol without (1) validating the transferred-in assets and (2) enforcing reentrancy protection on the mint logic. The exploitation leads to a greatly inflated totalSupply of the rebasing token, i.e., OUSD. The attacker then makes use of the inflation to redeem and drain about $7.7M of assets from the OUSD vault.

    Read more
  • Cheese Bank Incident: Root Cause Analysis

    16 Nov 2020
  • In this blog, we detail a Cheese Bank hack that occurred at 19:22:21 PM +UTC, Nov-6-2020. This hack was discovered while we review evil-will flashloans. This particular hack drains $3.3 million of USDC/USDT/DAI from Cheese Bank by exploiting a bug in its way to measure asset price from an AMM-based oracle. In the following, we elaborate the technical details.




    Summary

    Cheese Bank is a decentralized autonomous digital bank on Ethereum that allows investors to manage asset, including lending, fund management, insurance services etc. However, it has a flawed approach in the value measurement of collaterals based on the AMM-based oracle, i.e., Uniswap. As a result, with a flashloan-based manipulation of collateral price on Uniswap, the exploitation manages to make a series of malicious borrow operations, leading to $3.3 million of USDC/USDT/DAI loss (of Cheese Bank).

    Read more
  • Value DeFi Incident: Root Cause Analysis

    15 Nov 2020
  • Started at 15:36:30 PM +UTC, Nov-14-2020, Value DeFi was exploited to drain $7.4 million of DAI from its pooled MultiStablesVault. The incident was due to a bug in the way to measure asset price from an AMM-based oracle. The hacker further leaves a message ("do you really know flashloan?") to challenge the team. In the following, we elaborate the technical details.




    Summary

    This incident was due to a bug in the protocol that uses the AMM-based oracle, i.e., Curve, to measure the asset price. After a flashloan-based price manipulation on Curve, the exploitation leads to an unproportional 3crv tokens even from with the same amount of previously minted pooltokens. After the withdrawal, these 3crv tokens are then redeemed for DAI. The whole process leads to $7.4 million of DAI loss of Value DeFi (while $2 million of DAI is returned back to Value DeFi).

    Read more
  • Akropolis Incident: Root Cause Analysis

    13 Nov 2020
  • Started at 11:50:41 AM +UTC, Nov-12-2020, Akropolis was attacked by exploiting its flawed handling of the deposit logic in its SavingsModule smart contract. The hack results in a loss of 2,030,841.0177 DAI from the affected YCurve and sUSD pools in Akropolis. Here we elaborate the technical details in this blog post.




    Summary

    This incident was due to a bug in the protocol without (1) validating the supported tokens and (2) enforcing reentrancy protection on the deposit logic. The exploitation leads to a large number of pooltokens minted without being backed by valuable assets. The redemption of these minted pooltokens is then exercised to drain about 2.0mn DAI from the affected YCurve and sUSD pools.

    Read more
  • Analyzing the Voting Amplification Vulnerability in Sushi Governance Contract

    08 Sep 2020



  • On Sep. 7, 2020, Jong Seok Park posted in this medium post describing a delegation double spending bug in the governance subsystem of SushiSwap. Upon receiving the notice, PeckShield researchers immediately analyzed the vulnerability and came up with this blog to further elaborate the technical details.

    Read more
  • YAM Incident: Root Cause Analysis

    13 Aug 2020



  • At 08:01 AM UTC, Aug-13-2020, the creator of YAM, @brockjelmore, tweeted about the failure of rescuing the $750,000 yCRV tokens locked in the governance contract. Hours before that tweet, people in the Ethereum community advocated of voting to a bug-fix proposal which could have the chance to SAVE YAM!. Here we will elaborate the technical details in this blog post.



    Summary

    This incident was caused by the wrong calculation of totalSupply in the first rebase. The system was designed to execute bug-fix proposals to solve the problem. Unfortunately, the proposal having enough votes cannot be executed before the second rebase since the ETA of the proposal is set to a time after the second rebase automatically. When the bug-fix proposal is effective after the second rebase, the initSupply derived from the abnormal totalSupply makes the proposal a defeated proposal. That’s why nothing could save YAM except a hard-fork.

    Read more
  • Opyn Hacks: Root Cause Analysis

    05 Aug 2020
  • Started at 09:25:54 AM +UTC, Aug-4-2020, the decentralized insurance product, Opyn, was attacked by exploiting its flawed handling of ETH reception in its Opyn ETH Put smart contact. Opyn published a medium post about this incident. Here we will elaborate the technical details in this blog post.



    Summary

    This hack was done by calling exercise() with more than two vaults with ETH as the underlying assets. Since the implementation treats the same batch of ETH received as multiple batches of ETH receptions, the hacker re-uses that batch of ETH to retrieve the collateral USDC and make profits.

    Read more
  • Balancer Hacks: Root Cause and Loss Analysis

    28 Jun 2020
  • Started at 06:03:11 PM +UTC, Jun-28-2020, the DeFi platform, Balancer, was attacked by exploiting its flawed handling of ERC20 deflationary tokens. Technically, the main logic behind the incident is the incompatibility between Balancer and deflationary tokens, which is then misused by the attacker to create skewed STA/STONK pools states and make profits from that.

    This hack consists of four different steps:

    • Flashloan Borrow: The bad actor borrowed a flash loan (104,331 WETH) from dYdX.
    • STA Depletion: With the borrowed WETH, the bad actor performed a flurry of swaps to deplete almost all STA tokens owned by a Balancer pool. Note that STA is a deflationary token that will charge 1% on every token transfer. The result of STA depletion is that there is only 1e-18 STA left in the pool.
    • Exploitation for Profit The bad actor exploited the flawed handling of STA in Balancer and stoled the pool assets approximately valued $523,616.52.
    • Flashloan Repay Finally, the bad actor repaid the dYdX flash loan and walked away with the stolen assets.

    In the following, we analyze this particular hack as demonstrated in the transaction. http://oko.palkeo.com/0x013be97768b702fe8eccef1a40544d5ecb3c1961ad5f87fee4d16fdc08c78106/).


    Figure 1: Balancer Hack Breakdown

    Read more
  • Uniswap/Lendf.Me Hacks: Root Cause and Loss Analysis

    19 Apr 2020
  • Started at 12:58:19 AM +UTC, Apr-18-2020, the DeFi platform, Uniswap, was attacked by a hacker using a reentry vulnerability. Around 24 hours later, at Apr-19-2020 12:58:43 AM +UTC, a similar hack occurred on Lendf.Me. Technically, the main logic behind these two incidents is the incompatibility between ERC777 and those DeFi smart contracts, which might be misused by the attacker to utterly hijack a normal transaction and perform additional illicit operations.

    Specifically, in the Uniswap hack, the attacker exploits the vulnerability to drain the Uniswap liquidity pool of ETH-imBTC (with about 1,278 ETH)while in the Lendf.Me hack, the attacker makes use of it to (arbitrarily) increase the internal record of the attacker’s imBTC collateral amount so that she can borrow (and indeed borrow) a variety of 10+ assets from all available Lendf.Me liquidity pools (with total asset value of $25,236,849.44).

    Meanwhile, it is also important to notice that ERC777 itself is a community-established token standard with its advanced features for various scenarios. However, these advanced features might not be compatible with certain DeFi scenarios. Worse, such incompatibility might further lead to undesirable consequences (e.g., reentrancy). We also notice that other token standards (e.g., ERC1155) have been similarly designed to have a callback function. Having said that, our manual review of the imBTC ERC777 implementation indicates that it indeed follows the ERC777 standard.


    Figure 1: ERC777-Compatible transferFrom()

    Read more
  • bZx Hack II Full Disclosure (With Detailed Profit Analysis)

    18 Feb 2020
  • On 2/18, just a few hours after the official hack report was released, the bZx team pauses the protocol again in light of another hack.


    bZx Hack II: Five Exploitation Steps With Oracle Manipulation

    PeckShield researchers detected the abnormal transaction pattern with an in-house real-time anomaly detection engine and looked into it immediately. This second hack is different from the first one in that it is indeed an oracle attack. With oracle manipulation, it essentially takes a reverse way to allow for the leakage of supposedly-locked bZx funds directly to an attacker-controlled account, without the further need of absorbing the leaked funds into a Compound position. Specifically, the oracle manipulation substantially drives up the price of the affected token, i.e., sUSD, and makes it extremely valuable in the bZx lending system. The attacker can then simply deposit earlier-purchased or hoarded sUSD as collateral to borrow WETH for profit (instead of selling or dumping). In the above figure, we show the detailed five steps behind this hack: Flashloan Borrow, Hoard, Pump, Collateralized Borrow, Flashloan Repay. Notice the fourth step is Collateralized Borrow, instead of Dump. In the following, we examine each specific step.

    Read more
  • bZx Hack Full Disclosure (With Detailed Profit Analysis)

    17 Feb 2020
  • On 02/15, we have provided a transaction-level recap on the bZx hack that recently captures various headlines in DeFi-related tweets and media. There are quite a few misunderstandings circulating around about the nature of this particular hack. We emphasize that this is not an oracle attack. Instead, it is a clever arbitrage execution, which did exploit a bug in bZx smart contract implementation to allow for the leakage of supposedly-locked bZx funds to Uniswap and further absorb the leaked funds into a Compound position. In this blog, we’d like to provide a full disclosure of the hack with an in-depth profit analysis, just as promised in our previous blog.


    Figure: Five Arbitrage Steps in bZx Hack

    Read more
  • bZx Hack Analysis Exposes Challenging DeFi-Inherent Composable Liquidity Risks

    15 Feb 2020
  • On 02/15, bZx team announced on the bZx’s official Telegram channel, saying that there was an “exploit executed” against the bZx protocol and that the firm has paused that protocol, “except for lending and unlending.” The team has not released the official post-mortem analysis yet, and researchers at PeckShield take the initiative to delve into the details and realize that this particular issue is inherent in current DeFi projects that share so-called composable liquidity. In addition, this issue can be likely exploitable in a number of similar settings (particularly with margin trades or borrows).

    We have to admit that the exploit itself, technically, is quite original. And the goal of our analysis and this disclosure is to clarify unnecessary misunderstandings around the issue and hopefully can lead to more insightful discussions. These discussions will be beneficial for the DeFi community, especially in the development of next-generation, safer and more robust liquidity-sharing models.

    Read more
  • EIDOS Airdrop Stifles the Liveness of EOSIO Network

    08 Nov 2019
  • [Update: (2019-11-15) EOSIO namebid issue was fixed, but CPU resources are still tight. Some sellrex orders could not be completed, resulting in the inability to rent CPU.]

    On 11/1, enumivo team announced on their website that they’re airdropping free EIDOS tokens if you send any amount of EOS to the EOS address eidosonecoin. This resulted in a mining mania for EIDOS right after the announcement was released for one week so far. Also, the CPU resource of EOSIO network was forced into the saturated state, in which users need to stake enough EOS to utilize the portion of CPU time based on the staked amount. PeckShield researchers monitored and analyzed the transactions on EOSIO network as well as the CPU rental mechanism based on REX by the time the airdrop started. Here’re some interesting findings we’ve got.


    Figure 1: https://enumivo.org/get-free-eidos

    Read more
  • Critical ItchySwap Bug in AirSwap Smart Contracts

    27 Sep 2019
  • On 2019/09/13, the AirSwap team announced a critical vulnerability in a new AirSwap smart contract, which could allow attackers to perform a swap without requiring a signature from a counter-party. In other words, users, if affected, might get their assets lost and thus are strongly suggested to take the remedy procedure outlined in the medium announcement. As of today, the vulnerable smart contract is no longer used in AirSwap Instant and Trader products, but users might have interacted with the vulnerable smart contract earlier and some of them could still find themselves vulnerable (and their assets could be at risk).


    Figure 1: AirSwap Logo From Its Official Home-page

    The details of the related vulnerability have not been released yet. After reviewing the original AirSwap contract and related wrappers, researchers at PeckShield have independently identified the bug. As claimed in the above medium post, the vulnerability (we named it ItchySwap) is critical and could be used to steal all assets of affected users.

    Here we will disclose the details, and hope each affected user could take necessary remedy procedure ASAP.

    Read more
  • EOS New Congestion Attack Details Explained

    16 Sep 2019
  • On 09/14, EOSPlay announced in their telegram account that they had noticed suspicious betting behavior and spikes of CPU usage on the EOS mainnet. Then, someone on Twitter reported that EOSPlay was attacked. PeckShield researchers analyzed the attack and found that it was a new type of transaction congestion attacks. Unlike the previous transaction congestion attack (CVE-2019-6199), this attacker rented large amounts of CPU from REX. Then, she created thousands of transactions to increase the price of CPU. As a result, most transactions signed by others were blocked because of lacks of CPU resource. Because of that, the EOSPlay’s random number generator was hacked resulting of about 30,000 EOS financial loss.


    Figure 1: Announcement on EOSPlay Telegram

    Read more
  • 0x Exchange Contract Vulnerability Details Explained

    14 Jul 2019
  • On 07/12, 0x announced the existence of a critical vulnerability in the 0x v2.0 Exchange contract which would allow an attacker to fill certain orders with invalid signatures. In less than eight hours, the vulnerable contract was shutdown, patched, and re-deployed. As a result, DEXs and wallets which used 0x protocol also suspended their services, including Radar Relay, Tokenlon, Star Bit etc.

    Read more
  • Follow The Money - Tracking The Asset Movements Of Cryptopia Hack

    23 May 2019
  • In January 2019, New Zealand crypto exchange Cryptopia was hacked, and about $16M USD (price at that time) worth of ETHs and other tokens were moved out of Cryptopia wallets. After being quite for a few months, and as the crypto token price recovers, the hackers started to move the stolen assets again. According to data from PeckShield Digital Asset Tracking and Recovery (DATAR) system, in the recent a few days, 4,787 ETHs have been moved into Huobi exchange, and 26,003 ETHs are still waiting to be laundered.

    Read more
  • Critical ItchyDAO Bug in the Voting Contract of MakerDAO

    08 May 2019
  • Around 2019/05/07 00:30 a.m. (UTC+8), blockchain security company Zeppelin announced a security warning on the most famous DeFi project - MakerDAO, declared that there is a critical vulnerability in the voting contract which might affect users who have staked MKR, and advised them to move their MKR out of the old contract and back into personal wallet immediately.

    According to their medium post, the vulnerability has now been fixed.

    The new contract is not open-sourced yet, however, after PeckShield thoroughly reviewed the original voting contract, we believe we’ve identified the bug. And it’s confirmed by the Maker foundation after we discussed with their engineer. As claimed by Zeppelin, the vulnerability (we named it Itchy DAO) is critical and could be used to compromise the voting result, and more worse, could possibly cause some MKR tokens staked in the contract unable to retrieve back and stay locked forever.

    Here we will disclose the details, and hope every affected projects could fix it ASAP.

    Read more
  • BTTBank Fake BTT Attack Details Explained

    12 Apr 2019
  • On 2019/04/11, 00:17 a.m., our data showed that the hacker’s account starting with TCX1Cay… created a TRC10 token named BTTx with token ID 1002278. Between 00:25 a.m. and 01:00 a.m., 40,000,000 BTTx tokens were transferred into multiple addresses which launched “fake BTT” attacks on BTTBank’s account starting with TXHFhq….

    Read more
  • Fatal TransferMint Bug in Multiple TRC20 Smart Contracts

    09 Apr 2019
  • On 2019/04/08, PeckShield researchers identified a new type of vulnerability, TransferMint in multiple TRC20 smart contracts, which could be exploited by attackers to mint unlimited tokens. This bug is similar to the ones we identified on ERC20 smart contracts in 2018, such as batchOverflow, proxyOverflow, transferFlaw, and ownerAnyone. However, the TransferMint bug identified on TRC20 contracts is a little bit different from the previous ones.

    Read more
  • CoinBene Incident Investigation Report

    08 Apr 2019
  • Crypto exchange, CoinBene, was reported to be hacked, although the exchange denied it. Leveraging the home-grown digital asset tracking and recovery (DATAR) system, our research found several key patterns matching the ones in exchange hacking events, such as, particular event sequence, large number of asset types, and very high value tokens were moved from CoinBene to other competing exchanges in a short period of time.

    We can draw the conclusion that there are substantial evidences showing that CoinBene was indeed hacked, resulting in large transfers of various tokens out of CoinBene wallet starting from 03/25/2019 19:00 UTC.

    The full report is attached here.

    Read more
  • $6M Tokens Stolen From DragonEX - Retracing The Asset Movements

    27 Mar 2019
  • In the morning of 03/24 Beijing time, the DragonEX exchange announced that digital assets was stolen from their platform, and asked for help to track and intercept the hackers. In the report, DragonEX mentioned that more than 20 crypto currencies was stolen, including BTC, ETH, EOS, etc. The total value of the stolen tokens was not revealed, but after some initial analysis, we found that this incident ranked among the top blockchain hacking events in terms of total value and token types.

    Read more
  • PeckShield First Anniversary Celebration - Onward and Upward!

    23 Mar 2019
  • During the crypto bull market in 2017, people worked day and night, 24x7, but during the 2018 bear market, many left. On 03/23/2018, PeckShield Inc. was established. One year later, we are still here. In Blockchain We Trust.

    Read more
  • EOS "Transaction Congestion Attack": Attackers Could Paralyze EOS Network with Minimal Cost

    15 Jan 2019
  • On 01/10, blockchain security company PeckShield detected that EOS gambling game EOS.Win was targeted by a new type of transaction congestion attacks. Unlike past popular attacks exploiting contract layer issues such as random numbers or transaction rollback attacks, This type of attacks exploits lower level, blockchain layer vulnerabilities. Further analysis by PeckShield researchers found that, this is a blockchain layer denial-of-service loophole, and attackers could start large amount of deferred trash transactions to stop BP producing blocks with valid transactions, i.e., stop transactions from normal users going into blocks, and paralyze the EOS Mainnet.

    Read more
  • Fastwin Hack Explained: Block.one Releases Stealthy Patches Against Critical Flaws

    18 Dec 2018
  • On 12/05/2018, the newly released EOS gambling DApp, Fastwin, was attacked by hackers. Blockchain security firm PeckShield detected and reported this hack in real time. Based on the analyzed data, between 03:18 AM and 04:15 AM, the hacker account named ha4tsojigyge attacked the Fastwin contract fastwindice3 124 times and got 1,929.71 EOS back. From further analysis by PeckShield researchers, the newly identified inlineReflex attacks were launched by the hacker to exploit the buggy logic for checking the caller of the contract.

    Read more
  • Fee.org or Coinbase: Who Is the 850K BTC Whale?

    10 Dec 2018
  • In the last few days, there were 107 new accounts popped up in the Bitcoin rich list, each with a 8000 BTC balance, and altogether 850K BTC, worth about 2.9 Billion USD. Figure 1 shows some of the new BTC accounts. From the patterns of these accounts’ creation and transactions, it’s very likely they are controlled by the same identity. Who is the whale behind this huge amount of bitcoin?

    Read more
  • Defeating EOS Gambling Games: The Techniques Behind Random Number Loophole

    22 Nov 2018
  • In the past month, blockchain security company PeckShield has exposed hackers attacking eight EOS gambling games, including EOSBet, EOSCast, FFgame, EOSDice, EOSWin, MyEosVegas, LuckyGo, and EOSLelego. Besides hackers gaining 170,503.5 EOS tokens , these attacks are threatening the overall security of the EOS ecosystem.

    Read more
  • Protecting From Replay Attacks After Recent BCH Hard Fork

    19 Nov 2018
  • Since the BCH hard fork on 11/16 and splitting into BCH ABC and BCH SV chains, PeckShield has detected huge amount of (small value) transactions replayed on ABC and SV chains. On a single day of 11/18, there were huge 1,409,055 transactions replayed!

    Read more
  • "Fake EOS Attack" Upgraded, 60K EOS Tokens Lost by EOSCast

    02 Nov 2018
  • Early morning on 10/31, online media reported that gambling platform EOSCast was attacked by hackers and lost more than 70K EOS tokens. Blockchain security company PeckShield followed up, analyzed blockchain data, and found out that starting from 00:15, hacker “refundwallet” attempted to attack EOSCast contract “eoscastdmgb1”, first used “Fake EOS attack” 8 times but failed, then used a variant of Fake EOS transfer attack for 9 times and succeeded.

    Read more
  • "Fake Transfer Notice" Loophole Details Explained, 140K EOS Tokens Lost by EOSBet

    26 Oct 2018
  • At 10/15 noon time, as reported by IMEOS, well-known EOS blockchain gambling platform EOSBet was attacked, and large amount of EOS tokens was lost. Initial analysis showed that a hacker account named ilovedice123 attacked EOSBet’s contract, eosbetdice11.

    Blockchain security company PeckShield detected and monitored this attack in real time. Initially this attack was classified as overflow attack by some folks on the web, but from further analysis by Peckshield security professionals, the hacker actually exploited a loophole in EOSBet contract during money receiving verification – fake transfer notice.

    Read more
  • Multiple Replay Attacks on Smart Contracts Observed in the Wild

    18 Aug 2018
  • On Aug 11, Zhenxuan Bai et al. presented Replay Attacks on Ethereum Smart Contracts[1] at DEF CON26, which uses two proxyOverflow-affected smart contracts as an example[2]. Researchers at PeckShield did a follow-up research and found multiple replay attacks in the wild. Also, we identified more smart contracts prone to Replay Attack which are deployed on the Ethereum mainnet.

    We start from a recap of the effort of Zhenxuan Bai et al. The basic idea behind is monitoring a signed message sent to one contract and replaying that message on the victim contract. When both contracts have identical algorithm on validating the signed message, the attacker could impersonate someone else in the context of the victim contract.

    Read more
  • PeckShield Token Security Rating Comes Online, Various Security Issues Found

    17 Aug 2018
  • PeckShield security rating is a public service provided by the leading blockchain security company PeckShield.

    This security rating is jointly published by PeckShield and the pioneering blockchain media, Mars Finance International. Under the principles of “Professional, Objective, and Authoritative”, PeckShield security team, using the tokens’ total market cap as guidance, selected a list of 350 ERC20 tokens, which are traded on major exchanges. Following the PeckShield Security Rating Model (PSRM), we assigned nine security levels, A, A-, B, B-, C, C-, D, D-, and F. By referring to these security levels, exchanges and investors can determine tokens’ security status, avoid high risk tokens, and minimize possible security risks.

    Read more
  • Coinw Exchange Mobile Client Can Be Manipulated to Expose User’s Private Information

    15 Aug 2018
  • On 07/05/2018 5PM, blockchain security company PeckShield discovered that the mobile client app of the cryptocurrency exchange Coinw has a tradeRifle security loophole. Attackers can use the clear text in some Coinw’s functions to intercept users’ token, use the token to execute a replay attack, and create any transaction requests, which may result to users asset loss. We have reported this loophole to Coinw immediately after our attack tests. On 07/19, Coinw’s technical team informed us that they have completed the loophole repair and software upgrade. Coinw website didn’t announce this loophole, and for security purpose, we decided to disclose the details of it one month after its discovery.

    Read more
  • A Redundant SafeMath Implementation to Make Your Contract Unsafe!

    14 Aug 2018
  • Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow[1], proxyOverflow[2], transferFlaw[3], ownerAnyone[4], multiOverflow[5], burnOverflow[6], ceoAnyone[7], allowAnyone[8], allowFlaw[9]), tradeTrap[10], evilReflex[11]). Some of them could be used by attackers to generate tokens out of nowhere or steal tokens from legitimate owners, while others can be used to take over the ownership from legitimate contract owners (or administrators).

    In this blog, we disclose a new type of vulnerability named unSafeMath. With such an implementation, any protection provided by the original SafeMath library would be gone with the wind. Consequently, anyone can transfer an arbitrary amount of tokens to any address from the affected ERC20 contracts. As a matter of fact, we have observed attacks in the wild. In the following, we are going to go through the details of the vulnerability.

    Read more
  • BCSEC and PeckShield to Launch World’s First Anonymous Crowd Test Platform

    01 Aug 2018
  • Jul 24, 2018 - The world’s first anonymous crowd-testing platform, DVP (dvpnet.io) [1], is launched by BCSEC [2] and PeckShield jointly today, which opens a new era of improving blockchain security by crowd testing.

    The main idea behind DVP, Decentralized Vulnerability Platform, is to build an anonymous security crowd-testing community with the blockchain technology, which provides decentralization and the “vulnerability is mining” paradigm. DVP effectively connects the white hats, security firms, blockchain firms, and reduces the risk of accidental vulnerability disclosure and improves the security of the whole blockchain ecosystem.

    Read more
  • Pwning Fomo3D Revealed: Iterative, Pre-Calculated Contract Creation For Airdrop Prizes!

    24 Jul 2018
  • Fomo3D [1] is an extreme popular, phenomenal and ponzi-like crypto-game in recent days. Justo, the developer of the game, made an astonishing announcement on twitter: “I have discovered an exploit that would be considered the equivalent of a nuclear bomb on the EVM.”

    Read more
  • The tradeRifle Vulnerability Identified in LBank Mobile Service (CVE-2018-13363)

    12 Jul 2018
  • [Update: On 2018-07-10, the latest version of LBank mobile apps has accordingly fixed the reported issues! Thank LBank team for responsible and timely upgrade!]

    On 6/29/2018, 1:00:00 a.m. UTC+8, PeckShield researchers again identified the tradeRifle vulnerability in the mobile apps of LBank — one of the top 10 cryptocurrency exchanges. Specifically, an attacker could extract the token of an user’s current login session. This token could be used to issue arbitrary trades by replaying the create order packets. Even worse, while withdrawing digital assets, the LBank mobile apps, both Android and iOS versions, are prone to man-in-the-middle (MITM) attacks, which could lead to serious financial damages. We notified LBank immediately by the time this issue was confirmed and the proof-of-concept exploit was verified.

    On 7/10/2018, 11:32:00 p.m. UTC+8, LBank announced in its official website that their security response team had applied the patch against the tradeRifle bug report, which was received on 6/29/2018 [1]. LBank also claimed in the announcement that none of the crypto assets of their users are affected by this bug.

    Read more
  • Procedure of Reclaiming Your Lost EOS Balance

    11 Jul 2018
  • [Update: Please send the MD5 of your private key for us to verify!]

    1. Send your EOS account information to [email protected] including:

      • Account name, EOS balance (including CPU/RAM/NET balances), the pubic key and the MD5 of private key

      • Proof of transaction using this account (e.g., screenshot of wallet apps, logs) before 03:14:00 UTC, 2018/7/11

    2. PeckShield validates the information and responds back to you

    3. Update the public/private key pair associated with the account or provide a new account to receive the fund

    4. PeckShield returns the balance back to you after verifying that your account (or the newly provided account) is safe

    Read more
  • EOSRescuer: Rescuing High-Risk EOS Accounts

    10 Jul 2018
  • As the largest ICO in history, EOS is touted as the most competitive candidate of next-generation blockchain systems and has naturally attracted great attention world-wide. Among all the buzz about EOS, the security aspect of EOS is one of the most controversial topics.

    In this blog, PeckShield researchers take a close look at a key component of EOS, i.e., EOS accounts. Especially, we are interested in understanding the way how the EOS accounts are generated by existing tools [3]. We are surprised to find that certain EOS accounts are readily vulnerable to being compromised and the corresponding digital assets are seriously under the risk of being stolen. For simplicity, we call these affected accounts as high-risk EOS accounts. In order to mitigate the issue and protect high-risk EOS users, PeckShield is now launching a public service dubbed EOSRescuer [2].

    In the following, we would like to go through the details of this particular security issue, and make a disclosure of vulnerable accounts list covered by EOSRescuer.

    Read more
  • The tradeRifle Vulnerability Identified in Huobi OTC Service (CVE-2018-13149)

    08 Jul 2018
  • [Update: On 2018-07-05, the latest version of Huobi OTC service has accordingly fixed the reported issues! Thank Huobi team for responsible and timely upgrade!]

    Nowadays, cryptocurrency exchanges play an important role in the crypto ecosystem. Among all exchanges, those providing Over-The-Counter (OTC) trading service attract our interest due to the convenience for fiat-to/from-crypto currency trading. In the meantime, the offline fiat exchange also poses security threats, such as the chargeback fraud that the buyer chargebacks the payment from the seller after receiving the crypto assets. By analyzing most of the OTC services provided by top cryptocurrency exchanges, we find out that the OTC trading service of Huobi is vulnerable to replay attack and man-in-the-middle (MITM) attack, which could be exploited to cause serious financial loss. Specifically, an attacker can eavesdrop financially-sensitive information of the seller and replays an message to impersonate the seller for issuing a privilege operation, for example, releasing the fund without paying any fiat currency. As for MITM attack, an attacker can fabricate the bank account of a crypto assets seller for collecting the fiat currency paid by the victim buyer.

    In the following, we would like to go through the details of a vulnerable OTC service provided by Huobi. We want to highlight that upon our notification on July 4, Huobi has promptly responded by issuing a security fix, preventing any damage or financial loss from being caused to her customers [1].

    Read more
  • EPoD: Ethereum Packet of Death (CVE-2018-12018)

    27 Jun 2018
  • PeckShield has so far discovered quite a few critical smart contract vulnerabilities. Besides smart contracts, the Ethereum ecosystem also includes other various components that are equally exposed to possible exploitation. Obviously, one such component is the core of Ethereum, i.e., the underlying client software running on each Ethereum node. If she takes down an Ethereum client/node, an attacker could completely get rid of the computation power contributed by the client/node. And if many Ethereum clients/nodes are all of a sudden knocked offline, their corresponding computation power could be immediately lost, causing serious disruption to the entire Ethereum operations. In this writing, we are going to reveal a critical vulnerability identified in popular Ethereum clients, which could be exploited to cause serious impact on the whole Ethereum network.

    Read more
  • New evilReflex Bug Identified in Multiple ERC20 Smart Contracts (CVE-2018-12702, CVE-2018-12703)

    23 Jun 2018
  • [Update: (2018-06-24) With swift, coordinated response from Huobi.pro, we appreciate the announcement [11] on suspending the deposits and withdrawals of affected tokens!]

    Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow[1], proxyOverflow[2], transferFlaw[3], ownerAnyone[4], multiOverflow[5], burnOverflow[6], ceoAnyone[7], allowAnyone[8], allowFlaw[9]), tradeTrap[10]). Some of them could be used by attackers to generate tokens out of nowhere or steal tokens from legitimate holders, while others can be used to take over the ownership from legitimate contract owner (or administrator).

    In this blog, we disclose a new type of vulnerability named evilReflex. By exploiting this bug, the attacker can transfer an arbitrary amount of tokens owned by a vulnerable smart contract to any address. Specifically, whenever a smart contract has non-zero token balance, those tokens could be swept out by an attacker.

    Read more
  • EPoD: Ethereum Packet of Death (CVE-2018-12018)

    15 Jun 2018
  • On June 15th, Dr. Jiang, founder and CEO of PeckShield, announced that PeckShield had found a security breach that could lead to 60% of current Ethereum nodes to crash in seconds.

    Read more
  • Full Disclosure of Highly-Manipulatable, tradeTrap-Affected ERC20 Tokens in Multiple Top Exchanges

    11 Jun 2018
  • [Update: (2018-06-12) The BMB (BMB) contract (0x0e935e976a47342a4aee5e32ecf2e7b59195e82f) is NOT affected by tradeTrap. We sincerely apology for mistakenly listing it as a vulnerable ERC20 token.]

    Quoted from our last blog [1], “publicly tradable ERC-20 tokens have considerable high market value. Various exchanges, either centralized (e.g., Binance, Huobi.pro, and OKex) or decentralized (e.g., IDEX, EtherDelta, ForkDelta), provide the marketplace by listing them, especially with high-liquidity ones, for public trading. Evidently, the transparency and security of their corresponding smart contracts is paramount. In practice, there is a de-facto requirement for these contract to be publicly verifiable on etherscan.io. Moreover, reflecting the fundamental ‘code-is-law’ spirit and trust of blockchain technology, these contracts once deployed should not be further subject to centralized control or manipulation.”

    After publishing our blog [1], we have been contacted by a number of affected cryptocurrency exchanges. As we believe the corresponding mitigation mechanism is now in place, it is the time to disclose the details of tradeTrap. As emphasized in [1], once smart contracts of publicly tradable ERC-20 tokens are deployed, they should not be further subject to centralized control or manipulation. Unfortunately, tradeTrap plagues 700+ ERC20 tokens and we have so far confirmed at least dozens of them are publicly tradable on current exchanges, including BinanceHuobi.proOKexOKCoinKR, CoinEggKucoinAllcoin, HitBTCBitbnsZBOTCBTCCoinBeneCOSSEtherDeltaForkDeltaIDEXYEX, Tidex, Radar Relay, Yobit, WazirX, CoinExchange, CoinSpot, Bluetrade, CEX, and Livecoin. The full list of tradeTrap-affected ERC20 tokens is available here.

    While we intend to think these contracts are deployed with good will and without any hidden or unintentional purpose, the existence of highly manipulatable interfaces (or knobs), however, could be exploited to either make inappropriate arbitrage or even directly control buy / sell prices of affected tokens. All these will eventually result in financial loss for trading customers and essentially reflect lack of enough security of affected exchanges when listing these tokens for trading.

    In the following, we would like to disclose two types of manipulatable interfaces which could be exploited to achieve unfair arbitrage.

    Read more
  • Highly-Manipulatable ERC20 Tokens Identified in Multiple Top Exchanges (including Binance, Huobi, and OKex)

    08 Jun 2018
  • Publicly tradable ERC-20 tokens have considerable high market value. Various exchanges, either centralized (e.g., Binance, Huobi.pro, and OKex) or decentralized (e.g., IDEX, EtherDelta, ForkDelta), provide the marketplace by listing them, especially with high-liquidity ones, for public trading. Evidently, the transparency and security of their corresponding smart contracts is paramount. In practice, there is a de-facto requirement for these contract to be publicly verifiable on etherscan.io. Moreover, reflecting the fundamental “code-is-law” spirit and trust of blockchain technology, these contracts once deployed should not be further subject to centralized control or manipulation.

    In this blog, we would like to report a security issue called tradeTrap (mixed with vulnerable implementation) that utterly violates the above requirement. Unfortunately, tradeTrap plagues hundreds of ERC20 tokens and we have so far confirmed at least ten of them are publicly tradable on current exchanges. Those affected tokens could be of high-profit arbitrage opportunities to bad guys.

    Read more
  • Enter Final 23-Hours Grace Period For EOS Registration: 194 Million Dollars of EOS Tokens Are Not Registered Or Wrongly Registered

    02 Jun 2018
  • The largest ICO in history, i.e,. the ERC-20 EOS Token ICO, is now closed on June 1st at 22:59:59 UTC. In total, EOS has raised $4 billion with 331,433 shareholders. Among these token holders (excluding the reserved 0xb1 address), 149,533 of them had registered their EOS public keys and they will be officially included in the snapshot for EOS genesis generation. These registered 149,533 token holders share 88% of the total supplied EOS tokens. On the other hand, there are 181,900 token holders (1.41% share) who have not completed the registration yet. If they do not complete the registration in the 23-hours grace period, they may not literally own the tokens when the grace period is over. For the rest 10.59%, the 0xb1 address holds the reserved 10% share, and the final part 0.59% is kept in the EOS smart contract, representing those investors who already paid for the token sale, but have not claimed them yet.

    Read more
  • Watch Your EOS Registration: Wrong/Inappropriate Registration Might Cost 27 Million Dollars!

    31 May 2018
  • We have been updating EOS community about latest registration status and upcoming deadline for weeks, and made great efforts to urge the entire EOS community and related shareholders to take the necessary actions for smooth registration. As of today, we found that 29.98% EOS tokens are still NOT registered!

    Today, we found another worrisome issue that requires immediate attention from EOS community. Among all registered (70.02%) EOS tokens, 0.23% EOS tokens are not properly registered. Based on today’s EOS price (12.40 USD), these improperly registered tokens are equivalent to ~27 million dollars (USD) , which might be lost forever if not immediately re-registered before the EOS mainnet launch. With that, we strongly recommend token holders who had already finished the registration to re-examine the EOS keys carefully. Otherwise your registration might be invalidated!

    Specifically, our analysis shows that there are two different ways that lead to an invalid registration:

    1. Using a public, known key: EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV;
    2. Using a bad format key

    In first case, since the EOS key is publicly known, your registered tokens might be immediately stolen by others. This particular case was reported by EOSAuthority today [1]. However, our analysis show that the registration issue is much more severe than we thought because of the second case.

    Read more
  • Analyzing and Reproducing the EOS Out-of-Bound Write Vulnerability in nodeos

    29 May 2018
  • Today, Qihoo 360 posted in its blog about an out-of-bound access vulnerability in nodeos, a part of EOSIO software package. This vulnerability can be exploited to trigger an RCE (Remote-Code-Execution) attack [1]. Considering the severity of the vulnerability and the timing of upcoming EOS mainnet launch, researchers at PeckShield immediately looked into the nodeos codebase and successfully reproduced the bug by crafting a malicious smart contract to crash the vanilla EOS client as mentioned in the blog.

    Read more
  • BiYong, An IM-Integrated Digital Wallet App, Poses Serious Privacy and Personal Risks

    27 May 2018
  • [Update: (2018-06-05) The latest version of Biyong has accordingly fixed the reported issues! Thank Biyong team for responsible and timely upgrade!]

    Digital wallets provide an essential functionality in managing digital assets or tokens for users and are considered a key pillar in the broad blockchain ecosystem. In today’s mobile app markets, there are quite a few wallet-oriented mobile apps (e.g., Exodus and imToken) that provide great convenience and service for managing digital assets. However, different from other mobile apps, digital wallets may face stricter requirements and higher standards for better privacy and security, especially with the enforcement of EU General Data Protection Regulation (GDPR).

    Recently, researchers at PeckShield have examined a number of mobile app-based digital wallets and came across a well-known blockchain-oriented IM app, i.e., BiYong, with nearly 3 million monthly active mobile users. This particular app aims to become “WeChat” in the Blockchain world by building a social network that links Blockchain users, communities, media, assets, applications and etc. It not only offers features to seamlessly interact with Telegram, but also provides digital wallet functionality for asset transfer or payment. However, our analysis shows that BiYong fails to hold a high standard in managing and collecting users’ private information. Specifically, this app collects user ID in Telegram (i.e., Telegram ID and name), telephone number, and even payment passcode and uploads them to BiYong servers in plaintext! We consider it completely unacceptable as it violates user privacy and disobeys the fundamental spirit behind Blockchain for the maintenance of user privacy and pseudonymity.

    Read more
  • Final Week Countdown: Half of EOS Tokens Are Still NOT Registered!

    25 May 2018
  • One week before the expected freezing of ERC20-based EOS tokens, we found that 51.7% EOS tokens are still NOT registered. Compared with our last study on 05/01/2018, the EOS registration rate observes some improvement, but certainly not significant at all. Among the 48.3% registered tokens, 10% is already reserved for block.one at the very beginning, leaving externally-circulating tokens with 38.3% registered! This is a very BAD sign for the entire EOS community.

    Read more
  • New allowAnyone Bug Identified in Multiple ERC20 Smart Contracts (CVE-2018-11397, CVE-2018-11398)

    23 May 2018
  • Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow[1], proxyOverflow[2], transferFlaw[3], ownerAnyone[4], multiOverflow[5]), burnOverflow[6]), ceoAnyone[7]). Some of them could be used by attackers to generate tokens out of nowhere or steal tokens from legitimate holders, while others can be used to take over the ownership from legitimate contract owner (or administrator).

    Today, our system reports a new vulnerability called allowAnyone that affects a number of publicly tradable tokens (including EDU). Because of the vulnerability, attackers can steal valuable tokens (managed by affected, vulnerable smart contracts) from legitimate holders. More specifically, our investigation shows that in those vulnerable smart contracts, the ERC20 standard API, transferFrom(), has an issue when checking the allowed[ ][ ] storage, which typically represents the amount of tokens that _from allows msg.sender to use. As a result, anyone can transfer tokens on behalf of another one who has non-zero balance.

    Read more
  • New ceoAnyone Bug Identified in Multiple Crypto Game Smart Contracts (CVE-2018-11329)

    21 May 2018
  • Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow[1], proxyOverflow[2], transferFlaw[3], ownerAnyone[4], multiOverflow[5], burnOverflow[6]). These vulnerabilities typically affect various tokens that may be publicly traded in exchanges. Today, we would like to report a new vulnerability named ceoAnyone, which affects, instead of tradable tokens in exchanges, but Crypto-Games.

    Starting from the end of 2017, blockchain-based crypto-games have become popular especially with the initial success of CryptoKitties. Among crypto-games, cypto idle game is an interesting category that enables players to make money by idling for hours, then followed by a profit-making transaction (e.g., selling a Lab Rat on Ether Goo). Many of the cypto idle game owners make profit from the transaction fee. However, what if the owner address could be manipulated or completely hijacked by attackers?

    Read more
  • New burnOverflow Bug Identified in Multiple ERC20 Smart Contracts (CVE-2018-11239)

    18 May 2018
  • Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow[1], proxyOverflow[2], transferFlaw[3], ownerAnyone[4], multiOverflow[5]). Some of them could be used by attackers to generate tokens out of nowhere while others can be used to steal tokens from legitimate holders.

    Today, we would like to report another vulnerability called burnOverflow that affects a few ERC20-related tokens. In particular, one such token, i.e., Hexagon Token (HXG), has already been attacked in the wild. Specifically, on 5/18/2018, 12:55:06 p.m. UTC, PeckShield detected such attacking transaction (as shown in Figure 1) where someone calls transfer() with a huge amount of HXG token — 0xffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,fffe to another address without actually spending any HXG token.

    Read more
  • New multiOverflow Bug Identified in Multiple ERC20 Smart Contracts (CVE-2018-10706)

    10 May 2018
  • Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow, proxyOverflow, transferFlaw, ownerAnyone). Some of them could be used by attackers to generate tokens out of nowhere while others can be used to steal tokens from legitimate holders. Today, we would like to report another vulnerability named multiOverflow that afflicts dozens of ERC20-based smart contracts. Our investigation shows that multiOverflow is another integer overflow bug which is similar to batchOverflow but with its own characteristics.

    Read more
  • New ownerAnyone Bug Allows For Anyone to ''Own'' Certain ERC20-Based Smart Contracts (CVE-2018-10705)

    03 May 2018
  • This morning, our vulnerability-scanning system at PeckShield identified a new vulnerability named ownerAnyone in certain ERC20-based smart contracts such as AURA, which is deployed by a decentralized banking and finance platform – AURORA. This bug, if successfully exploited, might introduce the danger of serious financial accident. Fortunately, the attackers would not be financially benefited from exploiting the vulnerability. Instead, the ownerAnyone bug can be used to trigger Denial-of-Service (DoS) attack on the affected smart contracts.

    Read more
  • No improvement: EOS Token Registration Continues to be Low (ONLY 28.57% Tokens Registered)!

    02 May 2018
  • The ERC20-based EOS tokens are expected to become frozen on the Ethereum blockchain on June 2, 2018 22:59:59 UTC (shortly before the scheduled EOS mainnet launch). Evidently, holding a certain amount of EOS tokens at this stage is not equivalent yet to having the corresponding share of native EOS tokens. Instead, current holders of ERC20-based EOS tokens need to register their tokens through the EOSCrowdsale contract. Only after the registration, current token holders will be entitled later on the EOS mainnet with voting privilege for their favorite block producers or super-nodes, which currently undergo intensive competition and heated discussions.

    In our last month study [1], we found as of 04/01/2018, among all issued tokens, EOS token registration rate is as low as 23.55%. One month later, we revisited and found as of 05/01/2018, the EOS token registration rate remains as low as 28.57%, with no improvement at all. Among the 28.57% registration, 10% is already reserved for block.one at the very beginning, leaving externally-circulating tokens with 18.56% registered! This is worrisome specially compared to recently leaped EOS market cap.

    Read more
  • Your Tokens Are Mine: A Suspicious Scam Token in A Top Exchange

    28 Apr 2018
  • Our automated scanning system at PeckShield discovered a new vulnerability named transferFlaw (CVE-2018–10468). This particular vulnerability affects a publicly traded ERC20 token listed in a top exchange. Different from batchOverflow [1] and proxyOverflow [2] we identified before, this vulnerability does not lead to generating countless tokens. Instead, this one, when exploited, can be used by attackers to steal others’ tokens.

    Our in-depth code analysis further indicates that it is probably a scam token. We have promptly notified affected exchanges to delist the related token. Note that the token has been publicly tradable for about 10 months even though at a relatively low trade volume, we believe it poses a realistic threat to legitimate users and cryptocurrency market as a whole.

    Read more
  • MyEtherWallet Domain-Hijacking Financially Victimized 198 Users, Causing $320K Loss

    26 Apr 2018
  • On April 24th, MyEtherWallet (or MEW) users in certain areas suffered from domain hijacking and, when visiting official MyEtherWallet.com domain, may be redirected to phishing sites (physically located in Russia). As of this writing, there are 198 victims falling prey with $320K US dollars loss.

    Read more
  • New proxyOverflow Bug in Multiple ERC20 Smart Contracts (CVE-2018-10376)

    25 Apr 2018
  • On 4/24/2018, 01:17:50 p.m. UTC, PeckShield again detected an unusual MESH token transaction (shown in Figure 1). In this particular transaction, someone transferred a large amount of MESH token — 0x8fff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff (63 f’s) to herself along with a huge amount fee — 0x7000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0001 to the address issuing this transaction.

    Read more
  • ALERT: New batchOverflow Bug in Multiple ERC20 Smart Contracts (CVE-2018-10299)

    22 Apr 2018
  • Built on our earlier efforts in analyzing EOS tokens, we have developed an automated system to scan and analyze Ethereum-based (ERC-20) token transfers. Specifically, our system will automatically send out alerts if any suspicious transactions (e.g., involving unreasonably large tokens) occur.

    In particular, on 4/22/2018, 03:28:52 a.m. UTC, our system raised an alarm which is related to an unusual BEC token transaction (shown in Figure 1). In this particular transaction, someone transferred an extremely large amount of BEC token — 0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000 (63 0’s – In fact, there’re actually two such large token transfers, with each transfer involving the same amount of tokens from the same BeautyChain contract but to two different addresses).

    Read more
  • Low EOS Token Registration Deserves Community Attention (and Actions)!

    14 Apr 2018
  • Among existing digital cryptocurrency tokens, EOS gained prominence within the crypto community and has been touted as the next-generation flagship blockchain infrastructure. Its market capitalization has recently skyrocketed and makes it 5th place with more than $6B valuation [1]. Notice that holding a certain amount of EOS tokens at this stage is not equivalent yet to having the corresponding share of native EOS tokens. In particular, before the official EOS mainnet launch in June, 2018, token holders need to register their EOS tokens through the EOSCrowdsale contract. Only after the token registration, current token holders can ‘‘own’’ their token share on the EOS mainnet right after the June launch. The ownership will further entitle token holders to vote for their favorite block producers, which currently undergo intensive competition and heated discussions.

    In this blog, we take a close look at th EOS token registration progress. Our goal here is to find out how many token holders actually have completed the registration process. More specifically, considering the total supply of 1 billion EOS tokens, what is the percentage (or registration rate) that have actually completed the above registration?

    Read more