Domain name security, the example of cryptocurrencies

A study of three hijackings of domain names in the last six months, in the world of cryptocurrencies

Cryptocurrency is certainly a hot topic today, especially because of the spectacular rise of Bitcoin in December 2017. But not only honest people noticed the rise. Criminals also want to take advantage of it. The techniques they use to attack wallets and steal money vary but we shall focus here only on the hijacking of domain names.

It should be noted that one of the difficulties in cybersecurity is the absence of raw facts about the attacks, and the absence of independent analyzes. All we know about the attack is based only on vague summaries, themselves based on public data, which is not always enough. Cyber ​​security reports by this or that company are not better informed and may be influenced by the interests of the company, for example because it sells security products. Articles in the media should be taken with great care.

Here, in addition to the published articles, we shall rely mainly on DNSDB. DNSDB is a base of "passive DNS". This technique involves instrumenting a DNS resolver to transmit the DNS responses it has received. These responses are then stored in a database, which can be queried. This makes it possible to "go back in time" and see what the DNS responses were at a given time. For example, here, DNSDB displays the successive IP addresses of the machine that serves as a whois server for Afnic (all the times are in UTC):

;; first seen: 2014-03-10 17:25:41 -0000
;;  last seen: 2014-03-24 08:09:24 -0000
matrix.nic.fr. IN AAAA 2001:67c:2218:2::4:55

;; first seen: 2014-03-24 08:12:12 -0000
;;  last seen: 2017-11-14 10:57:47 -0000
matrix.nic.fr. IN AAAA 2001:67c:2218:30::15

;; first seen: 2017-11-14 09:58:45 -0000
;;  last seen: 2017-11-14 12:23:10 -0000
matrix.nic.fr. IN AAAA 2001:67c:2218:e::51:35

;; first seen: 2017-11-14 11:26:09 -0000
;;  last seen: 2018-01-26 09:16:11 -0000
matrix.nic.fr. IN AAAA 2001:67c:2218:1b::51:99

We can see four different IP addresses used over time. (DNSDB indicates for each the first and the last occurrences, the first and the last time the resolvers used by DNSDB saw this response.)

Let's look at the three cases of hijacking in the title, starting with the most recent one. (Note that there is no indication that the three attacks were made by the same group.) Blackwallet was (they seem to have closed, following the hijacking) a "wallet" service, ie hosting accounts in cryptocurrencies, in this case lumens, the currency of the Stellar network. Its domain name, blackwallet.co, was hijacked on January 13, 2018. (Cf. the article by Bleeping Computer and the article by Security Affairs, as well as the Reddit warning). Here are the name servers of the domain, before the hijacking:

;; first seen: 2017-07-04 23:10:47 -0000
;;  last seen: 2018-01-13 17:40:15 -0000
blackwallet.co. IN NS ns1087.ui-dns.de.
blackwallet.co. IN NS ns1039.ui-dns.biz.
blackwallet.co. IN NS ns1069.ui-dns.com.
blackwallet.co. IN NS ns1102.ui-dns.org.

And here, during the hijacking:

;; first seen: 2018-01-13 18:11:31 -0000
;;  last seen: 2018-01-14 01:04:35 -0000
blackwallet.co. IN NS adi.ns.cloudflare.com.
blackwallet.co. IN NS anirban.ns.cloudflare.com.

Note that it took several hours to correct the problem. After it was corrected, the right servers could be seen again:

;; first seen: 2018-01-14 01:44:31 -0000
;;  last seen: 2018-01-20 11:46:34 -0000
blackwallet.co. IN NS ns1100.ui-dns.de.
blackwallet.co. IN NS ns1046.ui-dns.org.
blackwallet.co. IN NS ns1096.ui-dns.biz.
blackwallet.co. IN NS ns1099.ui-dns.com.

Note that today Cloudflare's nameservers, used during the hijacking, still serve the wrong data, as seen here with the DNS debugging client dig:

% dig @adi.ns.cloudflare.com NS blackwallet.co.
; <<>> DiG 9.10.3-P4-Debian <<>> @adi.ns.cloudflare.com NS blackwallet.co.
...
;; ANSWER SECTION:
blackwallet.co.        86400 IN NS adi.ns.cloudflare.com.
blackwallet.co.        86400 IN NS anirban.ns.cloudflare.com.

;; Query time: 13 msec
;; SERVER: 2400:cb00:2049:1::adf5:3a38#53(2400:cb00:2049:1::adf5:3a38)
;; WHEN: Fri Jan 26 13:51:52 CET 2018
;; MSG SIZE  rcvd: 100

Once the name servers were changed, the criminals could at leisure redirect visitors to the destination of their choice. In this case, they were redirected to a website where a malicious Javascript code diverted the lumens (money).

The web server used by the criminals is still running, which makes it possible to check that  HTTPS did not protect. It had an "authentic" certificate, created by the Comodo Certification Authority (CA) for *.blackwallet.co. The real certificate was issued by another CA, Symantec, and only covers www.blackwallet.co. Once you control a domain, getting a certificate is easy, and that is why certificates do not protect much.

A little before Christmas, another hijacking hit EtherDelta, an ethers trading platform, the currency of the Ethereum blockchain (cf. the article by Bleeping Computer):

;; first seen in zone file: 2017-06-10 16:02:22 -0000
;;  last seen in zone file: 2017-12-20 17:02:21 -0000
etherdelta.com. IN NS tom.ns.cloudflare.com.
etherdelta.com. IN NS dorthy.ns.cloudflare.com.

;; first seen: 2017-12-20 18:28:33 -0000
;;  last seen: 2017-12-20 21:54:06 -0000
etherdelta.com. IN NS ns1.shockhosting.net.
etherdelta.com. IN NS ns2.shockhosting.net.

;; first seen: 2017-12-20 21:55:29 -0000
;;  last seen: 2017-12-21 02:11:42 -0000
etherdelta.com. IN NS ns1.byet.org.
etherdelta.com. IN NS ns2.byet.org.
etherdelta.com. IN NS ns3.byet.org.
etherdelta.com. IN NS ns4.byet.org.

;; first seen: 2017-12-21 22:18:22 -0000
;;  last seen: 2018-01-21 08:55:36 -0000
etherdelta.com. IN NS asa.ns.cloudflare.com.
etherdelta.com. IN NS owen.ns.cloudflare.com.

We can see that the legitimate servers were at Cloudflare, but were changed, first for those in shockhosting.net, then for those in byet.org, before being restored to their proper value.

The last case of hijacking was that of ClassicEtherWallet, a wallet for ethers, in June 2017. (See the warning posted on Reddit, and the article by Bleeping Computer): the name servers were changed from the legitimate ones, at 1&1, to Cloudflare, and then restored but at another hosting provider:

;; first seen in zone file: 2016-07-25 16:31:09 -0000
;;  last seen in zone file: 2017-06-29 16:02:31 -0000
classicetherwallet.com. IN NS ns-us.1and1-dns.de.
classicetherwallet.com. IN NS ns-us.1and1-dns.us.
classicetherwallet.com. IN NS ns-us.1and1-dns.com.
classicetherwallet.com. IN NS ns-us.1and1-dns.org.

;; first seen in zone file: 2017-06-30 16:02:31 -0000
;;  last seen in zone file: 2017-06-30 16:02:31 -0000
classicetherwallet.com. IN NS jeff.ns.cloudflare.com.
classicetherwallet.com. IN NS dolly.ns.cloudflare.com.

;; first seen: 2017-06-30 18:53:30 -0000
;;  last seen: 2018-01-21 09:24:32 -0000
classicetherwallet.com. IN NS ns1085.ui-dns.de.
classicetherwallet.com. IN NS ns1022.ui-dns.com.
classicetherwallet.com. IN NS ns1059.ui-dns.biz.
classicetherwallet.com. IN NS ns1087.ui-dns.org.

In these three cases, what happened behind what could be seen in the public DNS? How were these hijackings possible? Without any internal information, obviously we cannot say. The fact that other domains of the same registrar or registry were apparently not affected seems to indicate that the hijacking was specific to these three names. They are probably changes made via the registrar's control panel (and not the DNS hosting provider, since the name servers were changed). To do so, the criminals had a selection of commonplace techniques: client password too weak, password poorly kept (the famous post-it stuck under the desk), social engineering ("Hi, this is Natasha, I work for your Internet provider's support [...] It seems to me that there's a small problem [...] I'll log on, what's the password again?"). From the outside, we cannot say which loophole they used. ("Someone accessed my hosting provider account", said the Blackwallet manager, without providing any further details, confusing registrar and hosting provider at the same time).

But the problem is not specific to domain names. It is aggravated, however, by the fact that, all too often, different providers force customers to have shared accounts: a single account, and thus a single password to manage the customer's domains. These shared passwords are a real source of trouble: you have to pass them on to others (which weakens the perception of the importance of secrecy) and you have to think about changing them when someone leaves the organization (which is not always done).

What solutions can be used to mitigate the risk? There are several (security is never simple), discussed in the suggested readings at the end of this article. Let's say that, in the three cases examined here, it would have been useful to:

• have better account security (strong passwords, unshared, not stored except in a secure way in a password manager),

• monitor DNS zone content, to be alerted right away, instead of waiting until Reddit announces your misfortune worldwide,

• and above all activate ”registry lock” systems like the ".fr lock" cited below.

Of course, the problem is not limited to the rapidly changing, brittle world of cryptocurrencies. Such attacks are perfectly possible, and regularly carried out, against domain names of other categories. Recommended reading on this topic: the Afnic issue paper on "Securing the management of domain names",  another Afnic issue paper on the ".fr lock" solution, and ANSSI best practices on the management of domain names.