- 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.
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.
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
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.
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
The whole process leads to the unwarranted minting of 6.97 million of BUNNY. After that, the attacker
immediately sells BUNNY for profit.
Started at 10:36:20 AM +UTC, May 16, 2021,
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
BvaultsBank and the associated strategy
In the following, we elaborate the technical details.
This incident was due to the mis-matched asset denomination implicitly assumed by
BvaultsBank and its
BvaultsBank's withdraw logic assumes the withdrawn amount is denominated in
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
The exploitation of the issue leads to about $11M funds drained from the
[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.
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
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.
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
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.
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
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.
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.
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
[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.
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
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.
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
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.
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
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.
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.
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.
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
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.
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
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.
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
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.
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
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
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.
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.
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.
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.
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:
In the following, we analyze this particular hack as demonstrated in the transaction. http://oko.palkeo.com/0x013be97768b702fe8eccef1a40544d5ecb3c1961ad5f87fee4d16fdc08c78106/).
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.
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.
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
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.
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
[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.
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).
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Aug 11, Zhenxuan Bai et al. presented Replay Attacks on Ethereum Smart Contracts at DEF CON26, which uses two proxyOverflow-affected smart contracts as an example. 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 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
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
Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow, proxyOverflow, transferFlaw, ownerAnyone, multiOverflow, burnOverflow, ceoAnyone, allowAnyone, allowFlaw), tradeTrap, evilReflex). 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
Jul 24, 2018 - The world’s first anonymous crowd-testing platform, DVP (dvpnet.io) , is launched by BCSEC  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
Fomo3D  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
[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 . LBank also claimed in the announcement that none of the crypto assets of their users are affected by this bug.Read more
[Update: Please send the MD5 of your private key for us to verify!]
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
PeckShield validates the information and responds back to you
Update the public/private key pair associated with the account or provide a new account to receive the fund
PeckShield returns the balance back to you after verifying that your account (or the newly provided account) is safe
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 . 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 .
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
[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 .Read more
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
[Update: (2018-06-24) With swift, coordinated response from Huobi.pro, we appreciate the announcement  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, proxyOverflow, transferFlaw, ownerAnyone, multiOverflow, burnOverflow, ceoAnyone, allowAnyone, allowFlaw), tradeTrap). 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
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
[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 , “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 , 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 , 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 Binance, Huobi.pro, OKex, OKCoinKR, CoinEgg, Kucoin, Allcoin, HitBTC, Bitbns, ZB, OTCBTC, CoinBene, COSS, EtherDelta, ForkDelta, IDEX, YEX, 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
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
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
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:
- Using a public, known key: EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV;
- 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 . However, our analysis show that the registration issue is much more severe than we thought because of the second case.Read more
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 . 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
[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
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
Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow, proxyOverflow, transferFlaw, ownerAnyone, multiOverflow), burnOverflow), ceoAnyone). 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
Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow, proxyOverflow, transferFlaw, ownerAnyone, multiOverflow, burnOverflow). 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
Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow, proxyOverflow, transferFlaw, ownerAnyone, multiOverflow). 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
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
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
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 , 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
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  and proxyOverflow  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
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
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
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
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 . 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