Logo
blank Skip to main content

How EOS Casinos Lost $562,000 to Smart Contract Vulnerabilities

When we hear about blockchain technology, we instantly think of the financial industry. But nowadays, it’s used in data sharing, copyright and royalty protection, the real estate market, and even in winemaking. The capabilities of the EOS network have turned out to be useful for gambling.

At the end of 2018, we witnessed the hacking of EOS casinos – EOSBet and DEOS Games. They lost $538,000 and $24,000, respectively. This was possible because hackers exploited vulnerabilities in EOS smart contracts.

Our development team has vast experience in cybersecurity and deep knowledge of blockchain vulnerabilities. We had already analyzed pros and cons of cybersecurity for blockchain technology. In this article, we analyze the causes of these recent EOS casino hacks and see if they could have been avoided.

EOS was launched on June 9, 2018, by the company Block.one. It’s a relatively new network with great support for smart contracts. The most prominent features of EOS are:

  • High transaction throughput in the range of tens of thousands of transactions per second.
  • No transaction fees.
  • Ability to redeploy and modify smart contracts.

These features make the EOS platform appealing for creating DApps.

The EOS development team is constantly working on improving the network. But unfortunately, the network is still a work in progress and has a few bugs and kinks. We’ve already covered a few of them in our previous articles.

Read also:
EOS RAM Exploit: Explanation of the Vulnerability and Recovery Tips

How does an EOS casino work?

Gambling is somewhat popular on blockchain networks. Here are several reasons why EOS is a good choice for a crypto casino DApp:

  • Transactions are free and anonymous.
  • Tokens are transferred within 10 minutes.
  • It’s easy to develop EOS smart contracts.
  • Casinos can offer no commission and set a minimum bet.

The two largest EOS casinos – EOSBet and DEOS games – work similarly: they’re games of chance, similar to dice. They allow players to bet some tokens, guessing the value of a randomly generated number. If a player guesses correctly, they receive a prize. The prize amount is proportional to the probability of guessing correctly. The wider the range of possible values, the larger the prize.

Selecting a wider possible range gives players a chance to win the jackpot. Obviously, this is extremely unlikely. The probability of winning the jackpot is less than 1% the chance of a normal win. An average player would waste a lot of tokens before winning the jackpot, resulting in a net loss. However, in both recent DApp smart contract hacks, hackers managed to manipulate and exploit vulnerabilities of the smart contracts in order to guarantee a jackpot.

Read also:
Application Licensing with Blockchain: EOS Network

The EOSBet hack

In autumn 2018, gambling DApp EOSBet suffered from two smart contract vulnerabilities. The first time the EOSBet casino gaming platform was hacked on September 14. The casino lost 40,000 EOS, or $200,000, from its wallet. The second hack happened on October 15. That hack cost 65,000 EOS, or $338,000. These attacks are similar, as both are connected with an EOS DApp smart contract exploit. Let’s analyze the second, which was the larger.

To carry out this second attack, hackers designed a vulnerable contract that was capable of responding to token transfers. They placed bets using this contract. Processing notifications from other contracts is a legitimate mechanic of EOS smart contracts. But in this scenario, a notification was handled improperly. In order to select a way to handle an invocation (or a notification), EOS smart contracts use a single function. This function contains a big switch that selects an appropriate action for the given parameters. Usually, for simple smart contracts, this function can be generated automatically. However, you need to design a custom handler for processing specific notifications.

The eosio.token smart contract has to be added as a source of notifications in order to detect and handle token transfers. A function with an appropriate signature also has to be added.

The function from the vulnerable contract was implemented in this way:

C
// extend from EOSIO_ABI, because we need to listen to incoming eosio.token transfers
#define EOSIO_ABI_EX( TYPE, MEMBERS ) \
extern "C" { \
    void apply( uint64_t receiver, uint64_t code, uint64_t action ) { \
        auto self = receiver; \
        if( action == N(onerror)) { \
            /* onerror is only valid if it is for the "eosio" code account and authorized by "eosio"'s "active permission */ \
            eosio_assert(code == N(eosio), "onerror actions are only valid from the \"eosio\" system account"); \
        } \
        if( code == self || code == N(eosio.token) || action == N(onerror) ) { \
            TYPE thiscontract( self ); \
            switch( action ) { \
                EOSIO_API( TYPE, MEMBERS ) \
            } \
            /* does not allow destructor of thiscontract to run: eosio_exit(0); */ \
        } \
    } \
}

In other words, the applied function allows the contract to receive notifications from the eosio.tokens smart contract. The transfer function handles any incoming tokens.

However, the transfer function actually has no way of verifying if a notification came from the eosio.token smart contract. This means that the hacker could call the transfer function without actually transferring any tokens.

Since no actual tokens were transferred, the attacker was able to keep calling this function as many times as they wanted. But the contract believed that it was receiving real bets and unknowingly gave out prizes in real tokens.

The DEOS Games hack

The attack on DEOS Games is more interesting. This casino was hacked on September 9, 2018. In this case, the vulnerability of the casino smart contract was in the way the protocol generated random numbers. A EOS blockchain is implemented in a deterministic environment in order to make different nodes be able to verify transactions and agree on a common state. If random numbers that are generated on the blockchain are indeed random, they would be different for each node and consensus would be impossible.

So in order to predict the outcome of a roll, the attacker wrote a smart contract that would execute the same code with the same parameters as an authentic contract. This way, they would know for sure if they would win and wouldn’t have to waste tokens while trying for a jackpot.

Read also:
5 Security Tips for Writing Smart Contracts

Fixing vulnerabilities in smart contracts

Both issues that made the attacks possible are well-known vulnerabilities in smart contracts.

The first issue is an example of an unprotected function. While the specific mechanics are unique to EOS, the general idea is universal. A function that was supposed to be internal to the contract (called only during a notification) was accessible to anyone. Essentially, this is the same issue that brought down Parity.

The issue wasn’t difficult to fix. The DEOS development team only had to verify if the tokens came from the correct smart contract during transfer:

C
if( action == N(transfer)){ \
eosio_assert( code == N(eosio.token), "Must transfer EOS”); \
} \

The casino’s team quickly patched this vulnerability, and the DApp was back up and running in no time.

The second issue is a more classic example of using predictable values to generate random numbers. There’s no way to generate non-deterministic random values in a deterministic network. Any contract that generates a random value can be hacked if called from another smart contract. We’ve seen a similar issue in FoMo3D, and it can be found in most other gambling smart contracts.

Fortunately, the payout from these attacks wasn’t particularly large, especially compared to other blockchain hacks.

The EOS tools and practices aren’t mature enough to completely guarantee EOS smart contract security. But since these issues were known in other networks, the developers should have predicted that they would exist in EOS.

But there would have been another way to discourage hackers from attacking. The developers could have organized a bug bounty. In this case, the hackers could have simply disclosed the discovered vulnerabilities instead of exploiting them. The two vulnerabilities described here require a lot of effort to execute, and the results weren’t really massive as far as blockchain heists go.

Case Study:
Smart Contract Security Audit: Penetration Testing and Static Analysis

Conclusion

EOS is a relatively new technology with a few vulnerabilities that allow hackers to exploit EOS smart contracts. Like any new technology, EOS requires particular attention to cybersecurity. Luckily, both EOSBet and DEOS Games did no harm to users. But the DApp owners were unable to regain the stolen money.

At Apriorit, we’ve spent a lot of time studying the development of the blockchain solutions. If you want to know more about our expertise on the subject, check out the Apriorit blockchain blog. Our development team can help you apply blockchain technology to your project and ensure its security.

Related services

Blockchain Development

Tell us about your project

Send us a request for proposal! We’ll get back to you with details and estimations.

By clicking Send you give consent to processing your data

Book an Exploratory Call

Do not have any specific task for us in mind but our skills seem interesting?

Get a quick Apriorit intro to better understand our team capabilities.

Book time slot

Contact us