DNS spoofing

#security #dns

To send a request to any service or device on the Internet you need to know its IP-address. IP-addresses are not human-friendly but thanks to DNS today we can use human-readable “addresses” like google.com – we call them domains. When you type “google.com” in a browser your OS sends a query to a DNS resolver to get IP-address for that domain underneath. And DNS resolver sends query to a Authoritative nameserver to get that information.

To speed up and optimize that process DNS resolvers usually cache responses from Authoritative nameservers (normally for a period specified by “TTL” in the DNS record). Next time someone queries “google.com” DNS resolver will take that data from cache unless cache is empty or expired.

Okay, everything looks good so far. All works, users are able to open google.com without any delays.

DNS Spoofing

With DNS spoofing (also known as DNS cache poisoning) it’s possible to “put” incorrect IP-address for some domain into DNS Resolver cache. And that DNS Resolver will respond to queries with incorrect IP-address for the domain until cache is expired. With that attacker may lead users to malicious website. And the website may try to steal data or money from unsuspecting users.

How does it work

DNS Resolvers and nameservers use UDP to send requests and responses. Unlike TCP, UDP doesn’t use “handshakes” to initiate connection, doesn’t check if recipient is ready to receive and doesn’t validate if response came from legitimate sender. That is, attacker can send message to a DNS Resolver pretending to be a legitimate server responding to a query:

Attacker queries “example.com” from DNS Resolver
And at the same time sends forged response to the DNS Resolver like “IP-address for example.com is 1.2.3.4” (where 1.2.3.4 is IP-address of malicious website)
If DNS Resolver receives attacker’s message first it will cache forged data – resolver can’t validate for sure if that message came from Authoritative nameserver
Next time someone queries “example.com” DNS Resolver will respond with forged data – “IP-address for example.com is 1.2.3.4”
And that someone may open malicious website in browser

DNS Spoofing difficulties

Despite this vulnerability of DNS caching process DNS spoofing attacks are not easy. The DNS Resolver does actually query the Authoritative nameserver, so attacker has only a few milliseconds to send the fake reply before the real reply arrives. Moreover attacker may need to know:

UDP port – many DNS Resolvers use random port for additional security
Request id
If DNS Resolver caches that specific query at all

On the other hand attacker may gain access to DNS Resolver itself (or owner of the resolver may be malicious actor himself). In that case cached data can be easily forged.

The risk of DNS cache poisoning is real.

SSL and HSTS

That attack is partially mitigated by SSL. Malicious actors can’t generate SSL-certificate without access to your domain. In case user tries to open example.com (and example.com IP-address was received from DNS Resolver with poisoned cache) then any modern browser will show an error and stop user from doing it. However there are cases when users will still open http version of a website:

Some of them will try to “fix” that error by changing “https” to “http”
Some of them may have http version in their bookmarks
Attacker may share http link e.g. by using fishing emails

HSTS header (short for HTTP Strict Transport Security) may improve it a bit. That header directs browser to open that website using https only. Meaning if user previously opened example.com browser won’t let him to use http version. But if user opens website for the first time – he will be able to use http version and malicious website will be opened.

DNSSEC

Domain Name System was created without taking much security into account. And that led to such vulnerabilities. DNSSEC (Domain Name System Security Extensions) was created to fill that gap. DNSSEC is a feature of the Domain Name System that authenticates responses to domain name lookups and guarantees data integrity. It does not provide privacy protection for these lookups, but prevents attackers from poisoning the responses to DNS requests.

All answers from DNSSEC protected zones are digitally signed using asymmetric key. Meaning it’s possible to check signature of DNS Resolver or Authoritative nameserver response to make sure it wasn’t forged. So in case of the attack described above:

Attacker queries “example.com” from DNS Resolver
And at the same time sends forged response to the DNS Resolver like “IP-address for example.com is 1.2.3.4” (where 1.2.3.4 is IP-address of malicious website)
If DNS Resolver receives attacker’s message first it will ignore that message because digital signature is not valid
DNS Resolver then receives response from Authoritative server and caches it
Attack was unsuccessful

To use DNSSEC it should be supported by both your TLD and your Domain registrar (or DNS operator that manages DNS records).

You can check list of TLDs which support DNSSEC here https://support.openprovider.eu/hc/en-us/articles/216648838-List-of-TLDs-that-support-DNSSEC. If your Domain registrar/DNS operator does not support DNSSEC (or does not support DNSSEC for your TLD) you can move to different registrar or operator.

DNS Registrar compromise

Attacker may somehow gain access to your DNS Registrar:

Your password may be compromised
Or DNS Registrar may have some security flaws on its side

In first case common security practices will help to prevent the attack:

Use strong password
Keep password in secure place, do not keep it as a plaintext, do not share password, etc
Use 2FA

In second case you can’t fully protect yourself but you can detect if somebody altered DNS records for your domain.

DNS monitoring

If malicious actor changed DNS records of your domain you better get notified about it as soon as possible. You can configure automatic monitoring to check DNS records of your domain:

Check if specific records have expected values. E.g. if you A record for your domain has expected IP-address
Check if records were changed.

There are services that allow you to set up DNS monitoring.

Conclusion

DNS security is not the first thing the comes to mind when you start thinking about app security. However threats are real and such attacks happen (and sometimes cost users a lot of money https://rekt.news/curve-finance-rekt/). So it’s better to be protected.