Craigslist DNS Hijack: Charting the Effects

Posted by on December 2nd, 2014
March 18th, 2015

Craigslist reported a DNS outage on Sunday, November 23rd starting at 5pm PST when, according to the craigslist CEO, “DNS records maintained at one of our domain registrars were compromised, diverting users to various non-craigslist sites.” By 7:18am Monday morning, craigslist confirmed that the DNS records had been corrected by the registrar, Network Solutions. During the course of the hijacking, we found that upwards of 26% of DNS queries directed users to rogue name servers. These name servers then directed traffic to an infamous prank site, digitalgangster.com, causing a denial of service attack, as reported by Ars Technica. And even after Monday morning, hijack records remained in the caches of DNS resolvers around the globe.

So what is a DNS hijack? What were the effects? And how long did it take to resolve? We monitored the craigslist.org hijack; the data shows just how widespread and long-lived DNS hijacks can be.

What Is DNS Hijacking and Cache Poisoning

First, a little background on DNS vulnerabilities and attacks. DNS records, and web traffic destined for those domains, are typically compromised in one of two ways, hijacking or cache poisoning. In both cases, redirected web traffic can be used to execute denial of service attacks, install malware and phish for passwords.

Hijacking involves compromising the DNS server or registrar itself, typically through a phishing attack or a compromised password. The hijacker gains administrative access to the DNS account in order to changes the records directly. Typically a hijacker will change the name server (NS) record to point future DNS queries to a name server under their control. A hijacker may also directly change address (A or AAAA) records themselves. Examples of this type of attack are hijacks of some New York Times and Twitter domains in 2013.

Cache poisoning occurs on DNS resolvers distributed throughout networks that comprise the Internet. When end users make a DNS query, resolvers in the DNS hierarchy serve a response if they have a valid record in their cache; therefore, most queries only resolve to the authoritative DNS server at periodic intervals proportional to the time-to-live (TTL) of the record. In the case of cache poisoning, an attacker inserts a forged DNS record into a DNS resolver, using a variety of tactics that typically involve racing to provide a valid response or brute forcing less secure DNS configurations. The poisoned records, again typically NS records, direct future DNS queries to the attacker’s name server, which then serves up an authoritative record of the attacker’s choice.

Hijacking at craigslist

In the craigslist DNS interruption last Sunday, it was a hijacking that triggered the misdirected traffic. The hijacked NS records directed users to four of the attacker’s name servers hosted at Network Solutions’ WorldNic and Hostinger Group’s 000webhost:

  • ns75.worldnic.com
  • ns76.worldnic.com
  • ns01.000webhost.com
  • ns02.000webhost.com

Below you can see the proportion of DNS queries that resolved to different name servers across more than 1300 global DNS resolvers, the source used for all of the following data. As of Sunday at 9:20pm Pacific, 4 hours into the attack, 26% of DNS resolvers were directing queries to the rogue name servers (Figure 1).

Figure 1: Result of NS queries to craigslist.org by server on Sunday, November 23rd at 9:20pm Pacific.
Figure 1: Result of NS queries to craigslist.org by server on Sunday, November 23rd at 9:20pm Pacific.

From a country perspective, Asia was hardest hit with more than 30% of DNS resolvers serving hijacked records in Japan, South Korea, Australia and China (Figure 2).

Figure 2: Proportion of queries by country resolving to rogue name servers on Sunday, November 23rd at 9:20pm Pacific.
Figure 2: Proportion of queries by country resolving to rogue name servers on Sunday, November 23rd at 9:20pm Pacific.

Within and across countries there is a high degree of variance by network. Some major networks had over 50% of resolvers serving hijacked records, including China Unicom, Telstra of Australia and Qwest of the U.S (Figure 3).

Figure 3: Proportion of queries by network resolving to rogue name servers on Sunday, November 23rd at 9:20pm Pacific.
Figure 3: Proportion of queries by network resolving to rogue name servers on Sunday, November 23rd at 9:20pm Pacific.

Clearing the Cache

In a DNS hijacking, a critical part of response and recovery is that network operators flush their caches as soon as the proper NS records are restored. Over time the NS records in caches should expire, varying on the TTL of records in each resolver, but a manual flush expedites the process. Therefore, we’d hope to see that hijacked records would be flushed within the first day after the hijacking. By Monday at 9:20pm Pacific, 3.5% of resolvers were returning non-craigslist name servers, an 87% reduction over 24 hours. By Sunday November 30th, a week after the hijack, 0.3% of DNS resolvers still served hijacked records (Figure 4).

Name Servers Sun Mon Tue Wed Thu Fri Sat Sun
craigslist.org 73.5% 96.6% 98.2% 99.4% 99.6% 99.6% 99.7% 99.7%
worldnic.com 20.5% 0.2% 0.1% 0.1% 0.1% 0.1%
webhost.com 6.1% 3.3% 1.7% 0.6% 0.4% 0.4% 0.3% 0.3%
Figure 4: Query resolution for craigslist.org by name server at 9:20pm Pacific each day.

Across countries, we see that despite a high prevalence of hijacked records on resolvers in Japan and Australia, these caches were cleared within 48 hours. Other countries, including Germany and Norway still do not have all resolvers returning the correct NS records (Figure 5).

Country Sun Mon Tue Wed Thu Fri Sat Sun
Japan 58.1% 95.9% 100% 100% 100% 100% 100% 100%
Australia 65.3% 97.9% 100% 100% 100% 100% 100% 100%
China 67.1% 96.3% 96.4% 97.4% 98.7% 98.7% 100% 100%
United States 70.1% 95.5% 98.5% 99.5% 99.5% 99.5% 100% 100%
UK 71.6% 97.3% 98.6% 100% 100% 100% 100% 100%
Germany 75.3% 93.2% 95.9% 97.2% 98.6% 98.6% 98.6% 98.6%
Norway 75.3% 93.2% 95.9% 97.2% 98.6% 98.6% 98.6% 98.6%
Brazil 89.0% 98.6% 100% 100% 100% 100% 100% 100%
Figure 5: Proportion of queries resolving to craigslist.org across multiple networks in each country at 9:20pm Pacific each day.

And from a network view, most major networks had flushed their caches within 24 hours, though Qwest took nearly 5 days and TeliaSonera still has resolvers serving hijacked records after a week (Figure 6).

Network Sun Mon Tue Wed Thu Fri Sat Sun
Qwest 45.5% 96.8% 96.9% 96.9% 96.9% 96.7% 100% 100%
Softbank 53.3% 100% 100% 100% 100% 100% 100% 100%
NTT 57.3% 93.3% 100% 100% 100% 100% 100% 100%
China Telecom 60.0% 94.4% 94.7% 94.1% 100% 100% 100% 100%
TeliaSonera 62.5% 75.0% 75.0% 75.0% 75.0% 75.0% 87.5% 87.5%
AT&T 72.9% 100% 100% 100% 100% 100% 100% 100%
Deutsche Telekom 73.3% 100% 100% 100% 100% 100% 100% 100%
Embratel 78.6% 100% 100% 100% 100% 100% 100% 100%
Verizon Business 85.3% 85.3% 100% 100% 100% 100% 100% 100%
Internode 88.9% 100% 100% 100% 100% 100% 100% 100%
Telefonica 93.3% 100% 100% 100% 100% 100% 100% 100%
Level 3 93.7% 100% 100% 100% 100% 100% 100% 100%
Figure 6: Proportion of queries resolving to craigslist.org across multuple vantage points per network at 9:20pm Pacific each day.

We can look into a specific resolver on the TeliaSonera network and find that, indeed, the DNS trace resolves to a 000webhost name server rather than a craigslist name server (Figure 7).

Figure 7: DNS trace from a resolver on the TeliaSonera network to craigslist.org, with cached results for root servers, .org servers and craigslist.org on Monday, December 1st at 1:45pm Pacific.
Figure 7: DNS trace from a resolver on the TeliaSonera network to craigslist.org, with cached results for root servers, .org servers and craigslist.org on Monday, December 1st at 1:45pm Pacific.

Even a week after a highly publicized (in the network operator world) DNS hijack, some major networks still have not flushed their resolvers’ caches. This highlights the importance of being vigilant before, during and after a hijack.

Detecting and Resolving a DNS Hijack

You’ll want to be on the look out for a DNS hijack in two cases. First, in a hijack of your own name space, you’ll need to both restore the proper records and encourage network operators to flush their caches (just as craigslist.org did). Second, in the case of someone else’s name space being hijacked you’ll want to flush the relevant records (just as major ISPs did). For more examples of DDoS Attacks, BGP Hijacks and Cache Poisoning watch this webinar.

Processing...