How the Syrian Electronic Army hacked The New York Times and Twitter

How the Syrian Electronic Army hacked The New York Times and Twitter

Yesterday, a hacker group — most likely the Syrian Electronic Army (SEA) — managed to redirect The New York Times, Twitter, and Huffington Post websites to alternate, defaced websites. These websites were down for hours, and in some cases are still down more than 24 hours later. How did a single hacker group manage to hoodwink dozens of network admins and security specialists, and run rings around three of the largest web properties? The simple answer is that securing websites is extremely hard, and almost no amount of preparation can protect a website from a well-organized attack. Let’s dive into the specifics of the attack — and discuss how the NYT, Twitter, and HuffPo could’ve better protected themselves.

A bit of history

As you probably know, and without getting into unnecessary complexities of NAT and virtual hosts, every device connected to the internet has an IP address. Back when the ARPAnet was first created, every service was accessed directly via an IP address. Unmemorable numeric addresses obviously aren’t ideal, though, and so the folks at the Stanford Research Institute — one of the first and most important entities on the early ARPAnet — created a Hosts.txt file that mapped memorable names to numeric addresses. With the Hosts file in place, you could connect to services by name rather than number — but, in the background, that name was simply being looked up in the Hosts file and translated into the required IP address.

The Hosts file lives on to this day — here’s what it looks like in Windows 8

As the ARPAnet grew, it became difficult to update and distribute the Hosts file between each of the ARPAnet links — and thus the Domain Name System (DNS) was born. DNS is essentially a (somewhat) secure and decentralized way of distributing those Hosts files to DNS servers around the world. Today, when you type a website address into your browser, your browser quickly and quietly requests the IP address from a nearby DNS server.

The web’s intrinsic weakness

The DNS has one key feature that allowed the SEA to take over the three domains, and will allow this same kind of attack to be carried out in the future: Delegation of trust. Basically, today’s DNS is a hierarchy of root name servers, authoritative name servers, and recursive DNS servers. The root servers are mostly operated by internet veterans, such as Verisign, RIPE, and ICANN, and are mostly tasked with storing a list of authoritative name servers. Authoritative name servers are databases that a domain (say, extremetech.com) has nominated as the trusted source of the name-to-IP-address translation. Whatever IP address is stored by the authoritative name server, that’s the IP address that your browser ultimately receives. Recursive DNS servers, which are generally operated by ISPs and companies like OpenDNS and Google, perform the task of going to the root server to ask for an authoritative name server, and then going to the authoritative name server to ask for the IP address.

Generally, as a web surfer, your interaction with the DNS will consist of hitting the recursive DNS servers hundreds of times per day. If you are a domain owner, when you update your domain’s IP address or other DNS records, you are playing with the authoritative name server. You will never really interact directly with the root servers.

Now, the problem is, root servers and recursive DNS servers completely trust an authoritative name server (thus their name). If someone alters an authoritative name server record, it is automatically propagated to every internet user, usually within a few minutes or hours (as dictated by the domain’s TTL). If you can access the authoritative name server, you can redirect a domain name to another IP address — and that’s exactly what happened to the New York Times, Twitter, and Huffington Post.

Surprisingly simple

The three domain names for the three websites in question are managed by Melbourne IT, a domain registrar. If the NYT ever wants to change the IP address of its website, it logs into its Melbourne IT control panel and duly pushes some new records to the authoritative name server. Unfortunately, if you have the right name and password, anyone can log into that control panel and change those DNS records — and that’s exactly what happened.

Melbourne IT sent an email to all of its customers, alerting them that a reseller account had been compromised. It did not identify which reseller, but it seems that Twitter, NYT, and HuffPo all bought their domains through the same reseller. We don’t know how the SEA obtained the reseller’s details, but spear phishing (phishing targeted directly at the reseller) is the most likely method. With the account details in hand, the SEA simply logged into Melbourne IT and updated the DNS records to point to its own server — voilà, three defaced websites.

Fixing the problem is equally as simple — just update the authoritative name server records again — but due to caching, some recursive DNS servers might take 24-48 hours to restore the correct records. If you’re still having issues accessing the NYT website, it’s because your recursive DNS server (usually provided by your ISP) hasn’t updated its cache yet.

One easy fix

As you can imagine, this is a fairly well known flaw of DNS — which is why the system allows for registry locking. If the registrar so wishes, it can lock the domain, so that no one — including the owner or a hacker — can modify, move, or delete DNS records. As it turns out, twitter.com was locked, which is why the SEA couldn’t deface Twitter’s main page — nytimes.com, on the other hand, wasn’t locked. Whether the NYT’s technical team kept the domain unlocked for a specific reason (maybe they were updating some records), or whether it was just a screw-up, we don’t know. There are reasons for not locking a domain, but in the case of high-profile domains those reasons are fairly scarce.

The final irony with domain locking, of course, is that most registrars allow you to unlock your domain through an online control panel — so if a hacker gets your name and password, locking will only cause a minor delay. Ideally, high-profile websites should be managed by registrars that require, real-world hoops to jump through to unlock a domain — but even then, social engineering could still be used to get the domain unlocked.