DNS hijacking

DNS hijacking

This message was prepared by Waves Team member Inal Cardanov and published on the official forum. We duplicate the original English version, as well as a free translation into Russian for the Russian-speaking part of the community.

What happened?

Summary

Domain name wavesplatform.com (without subdomains) within ~4 hours was resolving to the wrong server.

Root Causes

The attacker sent fake documents to the support of the domain registrar. The registrar without full verification of the documents allowed to reset the password and change an email. Documents were absolutely irrelevant, but registrar didn’t care about it.

Note

The blockchain itself and matcher was working properly. APIs were available by public alternative domains matcher.wavesnodes.com and nodes.wavesnodes.com.

Why did it happen?

There were no technical problems. Social engineering methods were used.

Our client has come out of beta on the same day and changed the domain from beta.wavesplatform.com to client.wavesplatform.com, but it had nothing to do with the described incident. It was an accidental coincidence. Important note about migration: users account data automatically moved to the new domain, there was no need to re-enter the seed phrase on the new domain.

Our actions

Detection

Our site reliability engineer (SRE) got an alert from monitoring system about the outage at 5:50 pm (UTC). At that time he got only DNS error if tried to open wavesplatform.com. He checked Cloudflare and found, that DNS records were changed. At 6:20 pm he was still getting an error when trying to open a website or https://client.wavesplatform.com. Mobile and desktop applications didn’t work too.

Resolution

We tried to contact the domain registrar. While we were trying to do that, we realized that http://wavesplatform.com opens client (mobile and desktop apps still did not work). httpS://wavesplatform.com was showing an error message because SSL certificate was for another domain. We had enabled HSTS (with 30 days max-age), but new users could open the site using HTTP.

Note: Waves client is available on https://client.wavesplatform.com and users know about that. https://wavesplatform.com is an official website. The attacker didn’t use the correct domain for the client. All subdomains were unavailable.

Right after that, we started to warn our users in twitter, telegram, discord and all other channels not to enter seed phrase on our website.

After not too long proceedings with the registrar, we decided to make a redirect from wavesplatform.com to the lite client (it has different domain waveswallet.io on the different registrar, with separate source codes). It took some time to double check our main client source codes.

After we were convinced that there are no threats for users, we rolled back all changes in DNS records. At 9:50 pm Google DNS (8.8.8.8) started to resolve domains to the right servers.

At 10:29 pm Alexander Ivanov announced, that everything is back online.

Lessons Learned

The blockchain itself and matcher was working properly. APIs were available by the alternative public domains: matcher.wavesnodes.com and nodes.wavesnodes.com.

We also reviewed the source codes of the malicious client.

What went well

  • We detected site outage after 10 minutes. Monitoring system and Cloudflare works well and helped to act fast and reduce potential impact.
  • Alternative domains for public blockchain nodes and matcher helped to reduce impact for applications and bots.

What went wrong

  • Because of capabilities of DNS we couldn’t update records as fast as it was needed.
  • People are the most vulnerable part of technologies. It is hard to prevent their misconduct.

Where we got lucky

  • Attacker didn’t use a correct subdomain the client and didn’t get SSL certificate for the domain.

How to prevent same problem in the future

  1. Domain registrar investigates the incident, but as soon as it would be possible, we will improve the protection against this type of attack.
  2. We work hard on integration with hardware wallet Ledger and we will force it as it’s possible.
  3. We also will work on 2FA (multisig accounts) for our clients. Multisig will become possible after smart accounts release and activation on MAINNET.
  4. Our Lite Client http://waveswallet.io by default will work only with blockchain nodes and matcher on alternative domain .wavesnodes.com. It will not require data services.
  5. We will create a lightweight desktop version of the client, where you will be able to set node and matcher URI in settings before it starts. In current Desktop Client you can change URI of node and matcher, but only after login.
  6. We will develop browser extension like metamask for authorization and signing transactions. It eliminates the need to enter seed on any website.
  7. We develop a decentralized platform, but still have centralized points of failure. We permanently think about improving the decentralization and invite our community to work together on more decentralization. If you have ideas or suggestions, please welcome in comments.

Questions from the community

Why did you delete your warning message from twitter?

We removed the message on Twitter to avoid panic, as we quickly returned the accesses and realized that the user data could not be compromised due to described above problems with SSL and irrelevant domain name.

Why metamask users was seeing the phishing alert on wavesplatfrom.com?

Metamask plugin has github repository with the list of phishing sites. When the user opens any page, the plugin tries to find the domain in blacklist, and redirects user to page https://metamask.io/phishing.html if necessary. They added wavesplatform to the blacklist at 8:28 pm. At 10:22 pm they accepted our pull request to delete our domain from the blacklist. Thanks to the metamask team for their quick response.

Why do you require to enter seed phrase on your website?

We do not require to enter your seed on a website, it is required for client (wallet) only. If you do not want to use web version, there are desktop and mobile applications.

What was happening with your twitter?

Some users found in our twitter strange replies with just user mentions. Twitter account was not compromised. There was a bug in the customer support application (omnideskRU) with access to our twitter account. It was an accidental coincidence.

Conclusion

Unfortunately, it is really hard to fully protect from DNS hijacking. This incident allowed us to think about the necessity of decentralized, fast and secure DNS.

We thank everyone for your support through this incident, though short it was.

Next PostPrevious Post