After the release of the first issue of Celes Security Service, the readers also want to get more wonderful content. Director Zhang of Celes Security Service, as a professional engineer, was delighted to compile the 2nd issue of Director Zhang’s Discussion on Safety for everyone.

Everybody, please get ready. Here we go！

There is always an Apply function in EOS contracts, which is used to map Action requests to specific processing functions. In fact, this is a system-provided function. If the contract does not rewrite its own apply function, the system’s function will be used by default. If a contract needs to handle some of its own unique logic in apply, you need to rewrite the apply function, which mainly to filter some messages that whether are to be forwarded.

Fake Betting

This contract is intended to forward messages of own contract and eosio.token contract, in which the token bet is eos. At first glance, there’s no problem with the code, but there’s a big problem with this apply function. So what’s the problem?

Let’s analyze it:

When forwarding messages in this agreement, only the action of this agreement or eosio.token agreement is accepted, and eos token will be used. Eosio.token in this contract is mainly responsible for the function of betting, but the previous code only determines whose message is forwarded rather than whose transfer message is forwarded. In this way, hackers can call the transfer of this contract and participate in betting activities in the identity of this contract, but their eos will not decrease. If a hacker wins, he will get an eos reward, and if he loses, he will not lose anything.

Then we need to add restrictions. Only the transfer message from eosio.token is correct. This ensures that others cannot bypass eosio.token to call the transfer method.

Below is the modified code

False Account Transfer

Similar to this case, there is also a false transfer notice, which is actually relatively simple.

The principle is as follows:

In this attack, the hackers used account A to transfer money to his account B. The normal transfer is that after the system contract eosio.token receives the “transfer”, both account A and account B can receive the transfer notice. However, the hackers set the contract on account B at the beginning and added the transfer notice “ require_recipient(N(C))” to contract C, so that the contract C will also receive the transfer notice from A to B. However, the contract C did not check whether the transfer was sent for itself. Therefore, when the contract C received the transfer notice and foolishly thought that the token was sent for itself and added a record.

To put it more generally, it is like saying that Zhang San transferred money to Li Si and then told Wang Wu: “I transferred money to Li Si”. Wang Wu has the problem of selective deafness and only heard “transferred money” and then said, “OK, I’ll write down this account”.

In fact, when writing the contract’s Apply function, you should be particularly careful, fully understand the logic implemented in Apply, and design more test cases and cover all cases as much as possible.

Pair programming is a good way to write code and it is best for someone to review the written code, which can effectively improve the security of the code.

As programmers, we must remember to “sail carefully for ten thousand years”!