VaultSX Hack: Lessons Learned and Other Thoughts

Article credited to Dexaran and provided by EOS GO

The main topics of the article are:

• a brief overview of what happened to VaultSX
• a process of negotiating with hackers
• a few tips for how to act if you are a hacker
• a number of concepts that could prevent such an accident in the future
• a couple of tips for users to consider

---

What happened?

The REAL thing that prevents hackers attack from being seized is the inability of network participants to build consensus around whether this should be done and how exactly this should be done.

VaultSX contract was hacked on 14 May 2021 at EOS mainnet. A hacker launched a sophisticated attack and drained 1,180,142 EOS (~$13M USD) and 461,796 USDT from the contract. Read the detailed description here (great thanks to CMichel for the excellent write up).

EosNation offered the attacker a bounty of $100,000 bounty offer transaction #1 and bounty offer transaction #2.

Offer by EosNation tx#1: EOS Nation is offering a 100,000 USDT bounty to the white hat hacker who identified the re-entry attack exploit on the flash.sx smart contract.

Offer by EosNation tx#2: The reward will be transferred to the account of your choice once the 1,180,142.5653 EOS and 461,796.8968 USDT are returned to the flash.sx account.

Then the attacker redistributed the funds across his accounts at 5,000 EOS to the account.

On May 15, 2021 06:11:10 AM block producers made a decision to overwrite the permissions of all the attackers accounts (watch the example of the Update Auth transaction). Therefore the consequences of the attack were neutralized and the funds are no longer in possession of the attacker.

Read the final statement on the attack made by EosNation here. At the moment, the funds are still at the accounts of the attacker, but the keys to these accounts are seemingly held by the block producers. Funds are awaiting return to users.

Negotiating with hackers.

Why didn't hackers accept EosNation's offer?

This is a good question, and to begin with, let's ask ourselves "Would I accept such an offer if I were a hacker?" For me the answer is "NO". I believe that the bounty offer was improper and it couldn't help negotiating with hackers in any sensible way.

There were two main mistakes in the offer: (1) the amount of bounty offered and (2) the procedure of bounty payment.

Bounty size

$100,000 looks like a decent amount but we need to keep in mind that hacking a smart-contract is not an easy task. That requires high expertise and it is very likely that it is performed by a security expert whose salary is ranging between $10,000 and $20,000 per month.

Now imagine that it was not just a single hacker but a group of 3 hackers. This brings us to ~$33,000 per person which could be less than 2 monthly salaries. In addition, offering $100,000 to a person who is holding $13,000,000 does not look like a reasonable deal.

If you want your rewards to be considered adequate, then you need to consider both impact and work done / time spent into account.

Personally, I think that the amount of bounty offered should not be less than 10% of the total amount of funds impacted.

Rewarding procedure

The offer of EosNation looks like "First you send us all the money, then we send you the reward... may be. There are no guarantees that we will not start asking to fulfill some extra conditions like deanonymizing yourself once you decide to return the funds." Obviously if I would be the hacker then I would not consider this offer.

The correct offer should look like this: "Please return 90% of the funds to the attacked account. In this case, we will consider you a white hat and will not persecute or interfere with you in the future. You can keep 10% of the funds as a reward."

My personal experience with EosNation

At the launch of EosNation reward proxy I found a bug in their proxy contract that would have allowed me to drain the contract. The amount of funds kept in the contract was roughly 1400 EOS.

I decided to report the bug to EosNation developers and told them that I'm willing to receive 100 EOS for the report. Once the bug was fixed the EosNation developers told me that this was a small bug and it is not worth 100 EOS and they will only send me 35. Small bug or not - when offering the bounty you must first consider what alternatives the hacker had at the moment when he made the decision to report the bug or steal all the money he could.

Do not be greedy! Offer poeple reasonable rewards if you want them to accept.

35 EOS bounty transaction can be found here.

Being a hacker

Imagine you've hacked something and grabbed a lot of funds. Now its time to get out with all the funds you have.

It is important to understand here that if you cross the line of adequacy due to greed and steal so much money that the ecosystem will suffer significant damage, then the influencers of the network will go to any measures of suppression.

Cryptocurrency networks are held by people and in the case when all people agree on some point - everything is possible. The consensus rules could be changed. The whole network can be re-launched from a snapshot "1 day before the attack". Its only a question of "how much" and whether people can agree on it.

Do not be greedy! The best thing you can do as a hacker is to keep everyone happy. Your goal as a hacker is to get away with the money, but not cause irreparable damage to the ecosystem and the community, keep that in mind.

Without a doubt, hackers are good for the ecosystem. They catch bugs and make developers think about security measures. This should be rewarded and valued highly. However, if a hacker becomes impudent and demands too much for their deeds, then there are chances that they will be left with nothing.

After the attack, the hacker is better off not stealing all the money, but returning most of it back. Suppose that after the attack, they announced that they have withdrawn funds and are ready to transfer them back once the bug is fixed. I would advocate returning 90% of funds back and keeping 10% as the reward.

From a users point of view

Imagine you are a user of a DAPP and you keep a decent part of your funds there. The DAPP gets hacked and you lose everything. The next day the hacker announces that 90% of the funds will be returned back. It's likely that the users will be happy and the 10% loss can be acceptable.

In our industry, a 10% loss can occur occasionally at any "unlucky dump day" or as a result of some influencers bad tweet. There is nothing special.

However, TheDAO hardfork was performed to retreive 30% of funds so getting away with funds is an art of not crossing the line.

Securing our smart-contracts

The VaultSX contract passed a security audit performed by SlowMist. You can find the audit report here.

However, this did not save the contract owners from a complex attack that the auditors could not predict. As a result, we must pay attention to the concept of layered security.

Automated Anomaly Detection Systems - not implemented

Security measures such as Automatic Anomaly Detection Systems were not implemented in the contract. Unfortunately, our smart contracts almost never implement Anomaly Detection systems at all.

It is likely that if more than 30% of the funds are withdrawn from the contract in a short period of time, then the chances are high that this is the result of a hacker attack.

Automatic anomaly detection systems cannot stop an attack, but they can mitigate damage. Such systems are an algorithm for detecting behavior that is not typical of a contract under normal circumstances. I highly recommend that developers of high-end contracts implement the simplest anomaly detection systems.

Smart-contract insurance - conception

It is not always possible to predict an attack. It is not always possible to minimize damage with software. However, our main goal is to protect users' funds.

I believe that specialized organizations that insure smart contracts can be created. In this case users can be notified in advance that in the event of a hack, their funds will be recovered (fully or partially depending on which type of insurance the developer chooses).

In this way, the developer can fully delegate the responsibility for ensuring the security of his users to the insurance company, which is interested in the contract not being hacked.

User education

Dear users, please note that smart contracts are in any case less secure than your own addresses. If you keep your funds in contract wallets, your security is nothing more than trust in the developer.

There are many scenarios that can happen with smart contracts, but cannot with your personal addresses:

• The developer can make a logical mistake in a smart-contract which can be exploited by hackers.

• The developer can improperly update the contract every time the contract is updated.

• A human factor is a thing - private keys can be stolen / smart-contract owners can be bribed.

Stay safe and keep your funds safe.

Suggested News