Callisto Network
WebsiteSecurity DepartmentTwitter
  • Whitepaper
    • 🇮🇹Whitepaper (ITA)
    • 🇮🇳Whitepaper (TELUGU)
    • 🇮🇳Whitepaper (HINDI)
    • 🇨🇳Whitepaper (CN Traditional)
    • 🇭🇰Whitepaper (CN Simplified)
    • 🇫🇷Whitepaper (FR)
    • 🇵🇭Whitepaper (PH)
  • 📌Strategic Plan
  • Callisto Network Vision
  • 🚀Callisto Network Progress Tracker
  • 🗓️Ecosystem Reports
    • Callisto Monthly - February 2023
    • Callisto Monthly - January 2023
      • 🇮🇹Callisto Monthly - January 2023 (ITA)
      • 🇫🇷Callisto Monthly - January 2023 (FR)
      • 🇮🇳Callisto Monthly - January 2023 (TELUGU)
    • Callisto Monthly - December 2022
      • 🇮🇹Callisto Monthly - December 2022 (ITA)
      • 🇫🇷Callisto Monthly - December 2022 (FR)
      • 🇵🇭Callisto Monthly - December 2022 (PHI)
    • Callisto Monthly - November 2022
      • 🇫🇷Callisto Monthly - November 2022 (FR)
      • 🇮🇹Callisto Monthly - November 2022 (ITA)
      • 🇮🇳Callisto Monthly - November 2022 (TELEGU)
    • Callisto Monthly - October 2022
      • 🇮🇹Callisto Monthly - October 2022 (ITA)
      • 🇫🇷Callisto Monthly - October 2022 (FR)
      • 🇵🇭Callisto Monthly - October 2022 (PHI)
      • 🇨🇳Callisto Monthly - October 2022 (CN Simplified)
      • 🇭🇰Callisto Monthly - October 2022 (CN Traditional)
      • 🇷🇺Monthly - October 2022 (RU)
    • Callisto Monthly - September 2022
      • 🇮🇹Callisto Monthly - September 2022 (ITA)
      • 🇫🇷Callisto Monthly - September 2022 (FR)
      • 🇵🇭Callisto Monthly - September 2022 (PHI)
      • 🇨🇳Callisto Monthly - September 2022 (CN Simplified)
      • 🇭🇰Callisto Monthly - September 2022 (CN Traditional)
    • Callisto Monthly - August 2022
      • 🇮🇹Callisto Monthly - August 2022 (ITA)
      • 🇫🇷Callisto Monthly - August 2022 (FR)
      • 🇵🇭Callisto Monthly - August 2022 (PH)
    • Callisto Monthly - July 2022
      • 🇮🇹Callisto Monthly - July 2022 (ITA)
    • Callisto Monthly - June 2022
    • Callisto Monthly - May 2022
    • Callisto Monthly - April 2022
    • Callisto Monthly - March 2022
  • Technologies
    • 📈Callisto Dynamic Monetary Policy
      • Crypto-models To Overcome Inflation and Callisto Network's Approach
      • Skuld Hard Fork - Update On Progress
    • 🧊Cold Staking
      • Cold Staking And PoS Staking Comparison
    • 🪙Wrapped Callisto (ccCLO)
    • ®️DexNS 2021
    • ⛏️Proof of Work
      • ZPoW #1 - Exploiting The Block Time & Block Size
      • Callisto Network Introduces the Dynamic Gas Price
    • Ⓜ️Callisto Network Masternodes
    • 🎓Tutorials
      • Setting Up Metamask For Callisto Network
        • Update the RPC URL in MetaMask
      • How to buy Callisto with Your Credit Card
      • How to Run a Callisto Network Node?
      • Callisto Network Masternodes Set-up
    • 🌐Callisto Hub
    • 🧩Web 3.0 Infrastructure
    • 🔍Chain Inspector
  • We Fund You!
    • 💲We Fund You!
      • We Fund You Award - 1st Edition
  • Security Department
    • 🔍Auditing Department
      • Auditing Department Amendment v5
    • 📖Documentation
      • 🛡️Security Department Best Practices
      • 🪙ERC 223 Token Standard
        • ERC20 Standard Main Issue
      • 🖼️CallistoNFT Standard
        • Roadmap
      • ✖️Cross-Chain Bridges Security Model
    • Products & Services
      • 🔍Security Audits For Smart Contracts
        • Mission: Securing The Smart Contracts Ecosystem
        • Trust and Smart Contracts: Code is the Limit
    • 🤝Various Contributions
      • Ethereum Classic
        • ECIP-1092 51attack solution: PirlGuard & Callisto proposal
      • Ethereum
        • Statement regarding Geth v1.10.8 split
      • EOS
        • Page 1Chintai (EOS resource exchange) low severity issue.
        • EOS congestion 9/13/2019 and EOSPlay hack
      • Ultimate solution to 51% attacks: amend the Nakamoto consensus
  • Hack Investigation Dept.
    • Hack Investigation Department
    • Helio Exploit
    • Binance Bridge Hack
    • TempleDAO's STAX Contract Hack Investigation
    • NFT Theft Analysis
    • AUDIUS Governance System Exploit Overview
    • LUNA ‘Hardfork’ Review
  • One Earth, One Heart
    • 🌎One Earth, One Heart
    • 💚Callisto Charity Efforts
  • Community
    • 📥Callisto Network Improvement Proposals
    • 💬Callisto AMAs
      • Callisto Team's Ask Me Anything on 04/05/2023
      • Callisto Team's Ask Me Anything on 03/03/2023
      • Callisto Team's Welcome AMA on 10/11/2022
      • Callisto Team's Ask Me Anything on 10/10/2022
      • Callisto Security Team's Ask Me Anything on 02/09/2022
      • Callisto Team's Ask Me Anything on 28/07/2022
      • Dexaran's Ask Me Anything on 11/04/2022
    • 📌Get Started
  • Callisto Enterprise
    • 🪙Callisto Enterprise Token
      • Vision and Tokenomics
    • 👥Team
      • Callisto Team Motivation System
  • In The Press
    • 🟢Callisto Network
      • Ethereum, Ethereum Classic, Callisto Network, A Common History
      • Callisto Network: Three Years After Mainnet Launch
      • Czech Ethereum Killer
    • 🖼️NFTs
      • Artist Creates And Then Destroys Art To Launch CallistoNFT
      • Security Network Develops New NFT Standard To Address ERC-721 Flaws
  • Miscellaneous
    • 🧩Media Kit
Powered by GitBook
On this page
  • What happens?
  • How it happens?
  • What attacker did
  • Theoretical explanation
  • What do we know?
  • What lesson should we learn from this?
  • What we know about the attackers contract?
  1. Security Department
  2. Various Contributions
  3. EOS

EOS congestion 9/13/2019 and EOSPlay hack

PreviousPage 1Chintai (EOS resource exchange) low severity issue.NextUltimate solution to 51% attacks: amend the Nakamoto consensus

Last updated 2 years ago

Original article by Dexaran posted on on September 15, 2019.

What happens?

At 9/13/2019 the DApp was hacked. The hacker exploited a flaw of the implementation of the EOSplay Random Number Generator (RNG), which allows him to take away about 30,000 EOS from the EOSPlay smart contract.

NOTE 1: The attack is not related to the design of EOSIO but only to the design of this particular DApp.

NOTE 2: We do not have the source codes of the hacked contract. Everything described on this article is a set of assumptions made by smart-contract developers based on what we know about the smart-contracts and EOS. We can only observe the history of transactions at the time of the attack and, based on the results of these transactions, draw conclusions about the attack principle, design of the attacker’s contract and contract of attacked DApp.

If you found a mistake, something that I’m missing or any useful info that I should include into this article please contact me:

Here are the results of the contract decompilation:

https://hackmd.io/u6yWyfFrRDieRFnjgmn9pA

How it happens?

What attacker did

(Source: )

  1. Rented 1,2M of CPU and NET at EOSREX resource exchange. (This costs him ~300 EOS)

  2. Staked CPU&NET for , and . (I’m not sure but it seems that eosplayadmin belongs to the attacker while dswinnermach is listed as at the DappRadar)

  3. The attacker created a lot of to the attacked EOSPlay DApp and won a lot of EOS (about 30,000). Deferred transactions caused network congestion and prevented most users from sending transactions.

  4. Four hours later the attacker caused a new wave of network congestion. At that time he was sending transactions to dswinnermach. (For example )

  5. The attack resolves. Network congestion stopped. EOS drained by the attacker is currently located .

Theoretical explanation

Apparently EOSPlay’s RNG was built fully on-chain. The problem with the RNG is that it requires a source of entropy to generate a random number. There is no built-in source of entropy in EOS. EOSPlay developers decided to use future blocks as a source of entropy, because the user does not know what will happen in the future at the time of sending the transaction.

It turns out that the hacker could manipulate future transactions to send “losing” transactions into infinite loops, thus preventing them from being executed. ”Winning” transactions were left to be executed successfully.

These are hacker’s accounts:

Apparently the hacker was trying to attack this DAPPS:

What do we know?

Lesson learned here is don’t design contracts that depend upon extra bandwidth available during uncontested mode. The eosplay contract should have a low cpu action to pause execution available to contract maintainers.

Since the attacker caused the EOS network to become congested, the EOSPlay team was not able to block its smart contract operations. Therefore, the attacker managed to completely empty EOSPlay’s funds.

What lesson should we learn from this?

  1. Smart-contract security is important. The fact that you can stop/upgrade the contract does not mean that you are 100% secure. It’s smart-contract developers’ responsibility to conduct security audits, but bounties and all the security-related operations to make ensure smart-contracts security. It’s way better to spend $20K on a professional security audit rather than have an exploit which will allow hackers to steal $100K.

  2. Random Number Generators must not use on-chain sources of entropy to generate numbers. There is no viable source of entropy in EOS blockchain.

  3. It is necessary to have a spare account staked with CPU and a super-cheap `stopcontract()` function in your DApp contract. Even if your contract is stoppable/upgradeable it does not mean that you can stop or redeploy it if someone will initiate a harsh network congestion. Every attacker can rent a lot of CPU via REX and initiate a congestion before exploiting some bugs in a DApp. If DApp developers will not have an account that will have enough CPU staked to withstand a congestion and keep the ability to send transactions then DApp developers will not be able to access the contract during the attack.

  4. Automated anomalies detection is also worth considering. When designing your DApp it is better to think about possible attack scenarios and implement some checks in advance. For example if your gambling DApp is going to pay players 30 times in a row then it is a bad sign. The problem here is out lack of imagination and the inability to predict all possible scenarios. If a hacker is a bit more creative than a developer of a DApp then the attack may come from a direction we never expect.

  5. It is better to have source codes published to enable community review the code and highlight the vulnerabilities. In case of a real attack it will be easier to investigate and understand it. This will help to avoid such incidents in future.

What we know about the attackers contract?

It uses 530 kb RAM so it is a decent contract. Not 10 lines of code.

There are the following public actions at the contract:

  • hi(num)

  • send()

  • setamount(amount)

  • settime(time)

  • setflag(flag)

  • setnum(num)

  • setc(currentvc, usedc, taskc, currentb)

  • init()

  • setrunnum(num)

  • settarget(t1, t2)

  • run(num, id) — the main function of the contract that was used to send deferred transactions

  • dd(ok)

  • clean()

  • start(num, id)

There are three public tables at the contract:

  • kkks — preserves a single row: id = 0 and flag = 0

  • infos — preserves a single row: id=0, currentvc = 1, usedc = 10, taskc = 0, currentb = 0

  • configs — preserves a single row: id=0, amount=0, flag=0, betnum=0, targettime= 1568418945500, x1= 450000, x2= 400000

There is a (resource exchange) in EOS. REX enables users to buy CPU and NET bandwidth and use it to power transactions.

A hacker rented 1,2 million CPU from REX to create thouthands of to the EOSPlay smart-contract which caused the network congestion. (Source: )

The attacker fills the queue with deferred transactions and waited until they are in the block where the bet is executed. Then he sent “losing” transaction into infinite loops. (Source: )

( for example)

Here are Daniel Larimer’s comments regarding the attack ():

Owning and staking gives users a prorata share of available bandwidth. When people don’t use their share it is redirected to others on a prorata basis. During heavy use users no longer receive this free benefit.

There were some statements that the attacker made it impossible for EOSPlay developers to stop the contract and interrupt the attack. For example states the following:

This is not true from what I know. The developers stopped the contract. Here is the transaction:

The EOSPlay conract was not emptied. Currently there are 148833.86 EOS remaining at the account’s balance:

The contract is located here:

Here you can find the contracts’ ABI:

🤝
Medium
EOSPlay
https://t.me/Dexaran
Dexaran
himself
eosplayadmin
dswinnermach
Spinach DApp
deferred transactions
this one
here
REX
deferred transactions
Michael Fletcher
Michael Yeates
https://eosflare.io/account/mumachayinmm
https://eosflare.io/account/gotoworkhome
https://eosflare.io/account/mumachayinm1
https://eosflare.io/account/mumachayinm2
https://eosflare.io/account/mumachayinm3
https://eosflare.io/account/mumachayinm4
https://eosflare.io/account/mumachayinm5
https://eosflare.io/account/eosplaybrand
https://eosflare.io/account/dswinnermach
this tx
https://eosflare.io/account/dswinnerpool
source
#eos
this article (EOSGO)
https://eosflare.io/tx/2E32E80D77571D639535A830BA772A2D6F9FBAEB90A510CC5ACA6406A5EE1764
https://eosflare.io/account/eosplaybrand
https://eosauthority.com/account?account=mumachayinmm
https://gist.github.com/Dexaran/e7f98e19f31077b549024b464cf45258