New DNS Hijacking Attacks

DNS hijacking isn’t new, but this seems to be an attack of unprecedented scale:

Researchers at Cisco’s Talos security division on Wednesday revealed that a hacker group it’s calling Sea Turtle carried out a broad campaign of espionage via DNS hijacking, hitting 40 different organizations. In the process, they went so far as to compromise multiple country-code top-level domains—the suffixes like .co.uk or .ru that end a foreign web address—putting all the traffic of every domain in multiple countries at risk.

The hackers’ victims include telecoms, internet service providers, and domain registrars responsible for implementing the domain name system. But the majority of the victims and the ultimate targets, Cisco believes, were a collection of mostly governmental organizations, including ministries of foreign affairs, intelligence agencies, military targets, and energy-related groups, all based in the Middle East and North Africa. By corrupting the internet’s directory system, hackers were able to silently use “man in the middle” attacks to intercept all internet data from email to web traffic sent to those victim organizations.

[…]

Cisco Talos said it couldn’t determine the nationality of the Sea Turtle hackers, and declined to name the specific targets of their spying operations. But it did provide a list of the countries where victims were located: Albania, Armenia, Cyprus, Egypt, Iraq, Jordan, Lebanon, Libya, Syria, Turkey, and the United Arab Emirates. Cisco’s Craig Williams confirmed that Armenia’s .am top-level domain was one of the “handful” that were compromised, but wouldn’t say which of the other countries’ top-level domains were similarly hijacked.

Another news article.

Tags: , , ,

Posted on April 18, 2019 at 5:13 AM • 19 Comments

Comments

Hydroplane • April 18, 2019 7:04 AM

I wonder what the impact of TLS wound have on this ‘operation.’ If clients (browsers) expect a site to use HTTPS, then just because the name resolves to a particular IP address, doesn’t mean it trusts the site. Sadly, there are a few holes in this idea. Many CAs that do domain-based validation could be fooled too. Some other CAs could ‘cooperate’ with ‘authorities’ (willingly or not-so-willingly). Projects like the SSL Observatory would (hopefully) help detect such collusion. Everything in this smells like a nation-state actor is behind this operation. Spies are going to spy, and they probably don’t care too much about the collateral damage.

Cormacolinde • April 18, 2019 8:02 AM

I’ve been thinking about how to block these attacks for a while now and at least you need to do the following to detect and limit your exposure:
– Monitor your DNS! Make sure you monitor your NS glue records and other critical records.
– Create a CAA record to prevent someone using a different CA to get certificates.
– Use DNSSEC to sign your DNS zone.

But in order to protect yourself from this kind of attack completely, you might be better using an internal CA for all internal systems, and use certificate pinning.

And obviously some sort of tunneled DNS client would help. I know the Cisco Umbrella client does this, but there’s probably others.

Sok Puppette • April 18, 2019 9:21 AM

Many CAs that do domain-based validation could be fooled too.

Basically any commercial CA would be fooled by a sustained successful attack. Certs aren’t worth the paper they’re not printed on.

The right answer here is DNSSEC, but inertia and FUD have kept it from being deployed. At the moment it doesn’t even help to sign your zone, because almost nothing checks it. The main value from signing is to counter whining idiots who won’t write code to check signatures because “nothing is signed anyway”.

The most important pressure point here is the browser providers, which have been dragging their feet and/or just outright refusing to do anything for ages.

And DANE/TLSA needs to be in the mix, too; much of the potential value of DNSSEC is lost without it.

Mike D. • April 18, 2019 11:53 AM

@Cormacolinde: CAA records, unfortunately, depend on all CAs actually honoring them. They don’t save you from a CA’s intermediate certificate getting compromised: IIRC TLS doesn’t check for CAA records itself, just that the certificate traces back to a trusted root.

@Sok: And nothing is signed because nobody checks the signatures.

Mike D. • April 18, 2019 11:56 AM

Also half-baked stuff like this doesn’t help:

Route 53 supports DNSSEC for domain registration but does not support DNSSEC for DNS service. If you want to configure DNSSEC for a domain that is registered with Route 53, you must use another DNS service provider.

Pickle Rick • April 18, 2019 12:01 PM

Neither CAA nor DNSSEC are the “right answer”. They help, sure, although they are more server-side settings. This is really more a client-side attack.

Use of HTSTS perhaps in combo with DNSSEC is closer to the “right answer”, but is still far from ideal, and doesn’t address a number of issues that are basically related to the problem of trusted key distribution and zero-knowledge trust.

The “Right answer” is unfortunately to redesign DNS, name resolution (and other related traffic routing, eg BGP) services with built-in security included. We built this internet thing back in the 70s/80s, and kept bolting additional features onto the same foundation ever since. We need to redesign that foundation.

albert • April 18, 2019 2:50 PM

“…Albania, Armenia, Cyprus, Egypt, Iraq, Jordan, Lebanon, Libya, Syria, Turkey, and the United Arab Emirates….”

This is indeed an interesting choice of countries….

. .. . .. — ….

Anon E. Moose • April 18, 2019 4:03 PM

Is nothing sacrosanct these days? sheesh. Do I need to cache the DNS servers to protect my people from nation-state attacks? And monitor then changes?

Also, are these guys from Hawaii with the SeaTurtle moniker?

Sancho_P • April 18, 2019 5:03 PM

What I do not understand here:

”In most cases, the attackers appear to have changed the DNS records for these domains (we’ll get to the “how” in a moment) so that the domains pointed to servers in Europe that they controlled.” (https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/)

So they changed e.g. the Lebanon based IP 194.126.10.18 to 139.59.134.216 which is based in Germany?
One of my servers is also based in Germany and shares the IP with 3 other businesses, but I guess my service provider knows exactly who is who and has backups of the machine (= knows what we are doing), including logs of remote access to the particular services.

Could someone please explain how a service provider (here DigitalOcean?) in Europe would not know who owned (paid) and had control at the time in question? Running a DNS in particular?

EvilKiru • April 19, 2019 4:38 PM

@Sancho_P: Your ISP probably doesn’t care if you run your own DNS server and is even less likely to care who uses it, unless your DNS traffic exceeds your bandwidth allowance.

Sancho_P • April 19, 2019 6:04 PM

@EvilKiru

Right, bad enough, but it seems LE don’t bother to investigate even after the fact?
Offer copyright protected files, CP or hate speech and they are there!

Clive Robinson • April 19, 2019 6:48 PM

@ EvilKiru, Sancho_P,

Your ISP probably doesn’t care if you run your own DNS server and is even less likely to care who uses it,

Whilst that may once have been true, some ISP’s see there is money to be made from knowing what your DNS searches are.

It’s kind of getting to the point where any information nomatter how limited, or how daft it appears to be to collect it, somebody somewhere will and try to moniterise it…

Dennis • April 20, 2019 8:07 AM

Telcos are also in a better position to push for merged application stacks. Some services are better served closer to the end user and closer they will get. This way the advertisers are assured to have your MACs and know exactly what/where your needs are.

SpaceLifeForm • April 20, 2019 1:40 PM

@Pickle Rick

The “Right Answer” is to eliminate DNS.

Yep, not trivial.

But, it used to be that way.

Bang!Path!Routing

VinnyG • April 22, 2019 7:23 AM

@albert re: target list – I also find the named targets list interesting, and a bit puzzling. If this was an NSA (or Israeli) op, one would definitely expect Iran to be among the targets. Likewise there is an apparently poor fit between that list and the “priority enemies list” of several other states who are major high-tech spying players. Two possibilities occur to me: the list is not complete because Cisco acceded to pressure to omit certain targets from their report; this was a preliminary methods test conducted against targets with limited capabilities to retaliate…

Clive Robinson • April 22, 2019 10:26 AM

@ VinnyG, Albert,

Likewise there is an apparently poor fit between that list and the “priority enemies list” of several other states who are major high-tech spying players.

Ommiting key targets, would not change the “importance” waitings to the nations.

If you take each item on the list and asign it values for each suspect country you can order them and look for correlations. Kind of like “curve fitting” by RMS etc.

Thus you could have a weak estimator as to the organisation that came up with the list, and more importantly a likely list of other peiority entries ommited from the list…

As I’ve indicated it is weak but it gives an indicator that can then be tested against other asspects.

Then unfortunatly you need to go looking for “confirmation tests” which are legaly probably beyond what you are alowed to do.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.