Smart contract backdoor unveiled: It's not just hackers who steal money, the "one-click coin" platform has hidden backdoors

I believe that my friends are no strangers to the concept of "additional issuance" in the token field. For example, TEDA has frequently issued ERC20 USDT on Ethereum recently. Since this is an act that increases the circulation of tokens, it has been full of controversy . Of course, under normal circumstances, the additional issue of tokens is public and well-documented, so we can also respond in time and even interfere with the relevant project parties, but if this "increase" is not recorded, even What did the project party not know? You might be surprised that there is such a strange thing? Yes, Beijing Lianan recently discovered the bad behavior of setting up a backdoor in the contract, secretly issuing additional tokens and stealing them.

Recently, Beijing Lianan received feedback from some project parties that after they issued ERC20 tokens, they did not further distribute them to other addresses, and found that some tokens of unknown origin were transferred on the chain, that is, the original source of these tokens was not their contract creation. Token assigned to the official address. At the same time, the project party also found that these Tokens are not the same-name coins or "counterfeit coins" generated by other contracts with the same name. They are more like an "additional issue" that was not initiated by them.

For example, a project is convenient to reflect. They observed that the token HJL transaction on the Ethereum chain was abnormally issued. Some tokens appeared to be generated out of thin air on the Ethereum network. No records were generated, saying that a good blockchain "cannot be tampered with. "Retroactive"?

The project address is as follows: https://cn.etherscan.com/token/0xf6CBA5729E9137149A278db075b53f429aa31C54

Is this caused by an additional issue? In the true sense of issuance, we believe that it should be the relevant project initiator or authorizer to actively initiate an act to increase the supply of Tokens. Under normal circumstances, the issuance of tokens has the following conditions:

  • Smart contracts support additional tokens.
  • The permission to issue additional tokens is usually held by the smart contract owner account.

In this case, we should see records of additional issues on the chain. For example, the additional issue of ERC20 USDT will have records similar to this:

However, according to the project party who reported the problem, they did not transfer money to 0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c, and this address seems to have a Token "falling from the sky."

It can be seen that in the above record, 43 million HJLs were generated after the contract was created, and transferred to the address beginning with 0xfee0c, then the address was transferred to the address beginning with 0x2ebecf, and then we saw the transfer with the address beginning with 0xfa6dd2, obviously this address has not been previously Get the official tokens created.

So, we further checked the contract of this token: https://cn.etherscan.com/address/0xf6CBA5729E9137149A278db075b53f429aa31C54#contracts

Finally, we found out where the mystery machine is. When the smart contract is deployed on the chain, it will normally issue a parameter _totalSupply to set the supply token, and also add 1% of the total supply to the account at address 0xfA6DD2B9976d67852Cc4b3180f1Ef8692c4aD87c This 1% of the tokens are not included in the total supply. As far as HJL is concerned, it is equivalent to the actual issue of 43000000 + 43000000 * 1% = 43000000 + 430000 = 43430000 HJL. The additional HJL seems to be given by this address. "Steal" away.

From the address 0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c regarding the transfer of HJL, it does give people a feeling of getting HJL out of thin air, and transferred out 330000HJL.

There are 100,000 HJLs left in the address, and the total of the transferred HJLs is 430,000 HJLs, which is in line with the operations in the contract.

We further looked at the transfer records of this address, and found that there were more than one such "Skyfall" tokens, all of which did not see transfers and contract calls, and the address directly transferred these tokens out

Are the contracts for these projects also experiencing similar problems? We checked the contract of Phantom Matter (PHTM2): https://cn.etherscan.com/address/0xbcc4bcc7577e4042d45ae189ba6c0b264d7bab34#code

Not surprisingly, we saw the same code, the same address, and the same one-hundred-percent "stealing" strategy, which shows that this is actually a backdoor for the relevant contract, but the project party said it was not aware of it. , Then how did they win?

The communication with the project party further learned that its coin-issuing contract was not developed by itself, but was completed on a coin-issuing platform called "Easy Token". The next question is in the process of using this platform:

  • Does the platform's template come with such code.
  • If such a code is included, is this part of its feature set or is it the established way for customers to pay.
  • If there are such functions and settings, is it explicitly stated to the customer.

Therefore, we conducted a test on the testnet. On the website, users first select the type of coin issuance.

Then enter information such as name, symbol, and supply.

The last is to pay the corresponding creation transaction fee, and then confirm it. There is no mention throughout the process that there will be an additional 1% of tokens generated in the final contract code and transferred to its designated address. Obviously, this is not an existing transaction. Some customer-facing features or settings.

Beijing Lian'an has used the token to generate websites and deploy contracts in the test network. From the perspective of the contract code, it has also seen the same behavior of multiple tokens and theft. The receiving address is also 0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c. It can be seen that the website is named after the token release platform. While providing token release services to customers, the website obtains tokens without the customer's knowledge. Once the relevant tokens can be traded, they will be able to sell them. Out of benefits.

As for the items associated with the 0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c address, there are mainly:

  • HJL (HJL)
  • Moneyhome (MH)
  • Phantom Matter (PHTM2)
  • CRS (CRS)
  • Libra Pi (LP)
  • SMART (SMART)
  • UCC (UC)

Some of these tokens have already been traded on the exchange. We have also seen the records of the addresses involved in the transfer to the relevant exchanges. It can be seen that the mode is to secretly issue an additional 1% of the token.

During the entire process, we found that the project party was in a very insecure "streaking" state. When using the so-called coin-issuing platform, the entire process was black-boxed to them. They only saw some setting options and did not know at all. Catty in the middle. At the same time, although the code will be open source after the code is deployed and verified, projects using such platforms usually have limited technical capabilities and will not check for defects. The party did the code audit request, which caused the backdoor that was so "flaunted" in this code to pass through the levels without being blocked in time.

Here, Beijing Lianan reminds all parties in the industry to follow the corresponding security principles for the development of smart contracts. If it involves outsourcing development, please pay attention to the assessment of moral hazard while evaluating its capabilities. Finally, the security audit of smart contracts is indispensable. Please contact a professional security agency in time for corresponding security testing.