DNS Hijack – Simplifying the misroute

DNS Hijacks are rapidly getting common and threat to e-commerce, corporates and end users. What exactly is a DNS hijack and how does that work and most importantly, how should we safeguard against this rapidly increasing threat.

By: Archie Jackson (AVP Technology/Information Security – Genpact)
“DNSpionage.”

The hackers behind DNSpionage succeeded in compromising key components of DNS infrastructure for more than 50 Middle Eastern companies and government agencies, including targets in Albania, Cyprus, Egypt, Iraq, Jordan, Kuwait, Lebanon, Libya, Saudi Arabia and the United Arab Emirates.

For example, the passive DNS data shows the attackers were able to hijack the DNS records for mail.gov.ae, which handles email for government offices of the United Arab Emirates. Here are just a few other interesting assets successfully compromised in this cyber espionage campaign:

-nsa.gov.iq: the National Security Advisory of Iraq
-webmail.mofa.gov.ae: email for the United Arab Emirates’ Ministry of Foreign Affairs
-shish.gov.al: the State Intelligence Service of Albania
-mail.mfa.gov.eg: mail server for Egypt’s Ministry of Foreign Affairs
-mod.gov.eg: Egyptian Ministry of Defense
-embassy.ly: Embassy of Libya
-owa.e-albania.al: the Outlook Web Access portal for the e-government portal of

Albania

-mail.dgca.gov.kw: email server for Kuwait’s Civil Aviation Bureau
-gid.gov.jo: Jordan’s General Intelligence Directorate
-adpvpn.adpolice.gov.ae: VPN service for the Abu Dhabi Police
-mail.asp.gov.al: email for Albanian State Police
-owa.gov.cy: Microsoft Outlook Web Access for Government of Cyprus
-webmail.finance.gov.lb: email for Lebanon Ministry of Finance
-mail.petroleum.gov.eg: Egyptian Ministry of Petroleum
-mail.cyta.com.cy:Cyta telecommunications and Internet provider, Cyprus
-mail.mea.com.lb: email access for Middle East Airlines

What exactly is a DNS?

The domain name system (DNS) functions as an interpreter between humans, who talk words, and computers, who talk numbers.

DNS is the keeper of all domain names that are registered on the internet. Its job is to translate those names into IP addresses and hence show the relevant website to the user. Whenever we want to visit a website, it simply matches the name with the IP address and shows the result. This process may take place through a local cache or through a zone file that is present on the server. A zone file is a file on the server that contains entries for different Resource Records (RR). These records can provide us a bunch of information about the domain. Let’s say the user opens up the browser and types in citibank.com. It is now the responsibility of the DNS resolver in the user’s operating system to fetch the IP Address. It first checks it’s local cache to see if it can find a record for the queried domain name. A local cache usually contains a mapping of IP-addresses to hostnames which are saved during recent lookups so that the DNS resolver does not have to fetch the IP address again and again. If it can’t find the IP address in it’s cache it queries the DNS server to see if it has a record for it. A DNS server is usually given to the end user by the ISP (Internet Service Provider) or you can manually set up a DNS server for yourself. If it still can’t find the IP Address then it goes through a process or recursive DNS query in which it queries different nameservers to get the IP-address of the domain. As soon as it finds the IP-address it returns the IP-address back to the user and also caches it for it’s future use.

Example, using nslookup

In the second line we have set the type = a. This will query the A records and return us an IP-address for the domain we query. When we type in google.com we get an output showing the server and an IP-address#port. This server is the current DNS server that is serving our request. DNS uses UDP port 53 to serve its requests. The third line in the output shows “Non-authoritative answer”. We can see all the IP-addresses associated with google.com. This is usually the case with large organizations where they use multiple servers to manage scalability of request traffic.

A Zone file is basically a text file present on the server hosting the domain that contains entries for different resource records.

Different types of Resource Records exist within a Zone file.

• A Records- Maps an IP Address to a hostname. For e.g. 74.125.236.80 for google.com.
• NS Records-Delegates a given zone to use the given authoritative nameserver. For e.g. ns1.google.com is an authoritative nameserver for google.com
• MX Records-This tells us which server is responsible for receiving mails sent to that domain name.
• TXT Records-This consists of arbitrarily human readable text in a record.
• CNAME Records- Gives an alias of one name to another.

How does a DNS Hijack work?

DNS Hijacking, is when bad actors redirect or “hijack” DNS addresses and reroute traffic to bogus DNS servers. Once a DNS address is successfully hijacked to a bogus DNS server, it translates the legitimate IP address or DNS name into the IP addresses of the hacker’s malicious website of choice.

DNS spoofing and DNS poisoning (or DNS cache poisoning) are the same thing, but slightly different than DNS hijacking. In the latter, the hacker would either plant a malware or hack the router DNS settings. However, in DNS poisoning or spoofing, the hackers compromise (poison) the cache of a DNS server.

DNS redirect, on the other hand, is an unethical way of redirecting users to unintended pages such as advertisements pages, etc. ISPs are the ones that usually practice DNS redirect to drive users, say from a 404 page to their desired pages which are usually ad pages. It wouldn’t be unfair to name it ISP DNS hijacking.

If your computer has been infected by a malware that managed to change your PCs DNS settings, it will no longer have the ability to correctly make the connection between a user friendly domain name and its original IP address. This means that you will be directed to fake versions of certain websites you are trying to visit.Your computer’s DNS settings are usually assigned by your ISP (Internet Service Provider). When you try to access a website, your computer refers your request to those settings which redirects it to a DNS server. The server matches the name with the IP address and then sends you to the desired website.If your computer settings are compromised, your request will be redirected to a rogue DNS server. Consequently, the rogue server will translate your request into a fake IP address that leads to a fake or malicious website.

DNS is highly decentralized. No single DNS server holds all the IP addresses and their corresponding domains. Your query will travel along a chain of DNS servers before you get your result. Therefore, DNS hijacking is the practice of redirecting DNS queries. You send out a query, but a third party steers the query the wrong way. As a result, you get a false IP address, and the wrong page loads on your screen.

Example, if you’re trying to access your online bank. Your DNS is hijacked and a different website is loaded that looks exactly like your bank’s homepage and you enter your login details. This is a known phishing scam when hackers create fake copies of a website to extract their victims’ usernames and passwords. The next thing you know, your bank account has been compromised.

A DNS hack could happen at any link in the chain of DNS queries. Here’s how:

• Malware: Your computer or router can be infected with malware that rewrites the configuration of DNS settings. As a result, your device queries a conned DNS server that serves you fake IP addresses. A malicious malware could redirect you through hacker-controlled open web proxies and get access to all your traffic and could also be directed to a dummy website that extracts your passwords and usernames through fake login procedures.
• Compromised DNS server: In this, your query is redirected in the wrong destination by a DNS server under a hacker’s control. This attack is even more clever because once the query leaves your device, you have no control whatsoever over the direction your traffic takes.
• Internet service provider interference:Some internet service providers use DNS hijacking on their own users to display ads or collect statistics. They do this by hijacking the NXDOMAIN response.NXDOMAIN is the response you get if you type in a domain that does not exist (meaning it doesn’t have a corresponding IP address). For example, if you entered “ssdsrfadsfdgfaaf.com” into your browser, you would get the NXDOMAIN response: “The website cannot be found” or a similar error message. When an internet service provider hijacks the NXDOMAIN response, they replace the error message with a fake website set up by the internet service provider to show you ads or collect your data.

Techniques:

The following examples use victim[.]com to stand in for the victim domain, and private IP addresses to stand in for the actor controlled IP addresses.

• Technique 1 – DNS A Records

The first method exploited by the attacker is altering DNS A Records, as seen in Figure 1.

• The attacker logs into PXY1, a Proxy box used to conduct non-attributed browsing and as a jumpbox to other infrastructure.
• The attacker logs into the DNS provider’s administration panel, utilising previously compromised credentials.
• The A record (e.g. mail[.]victim[.]com) is currently pointing to 192.168.100.100.
• The attacker changes the A record and points it to 10.20.30.40 (OP1).
• The attacker logs in from PXY1 to OP1.
  • A proxy is implemented to listen on all open ports, mirroring mail[.]victim[.]com.
  • A load balancer points to 192.168.100.100 [mail[.]victim[.]com] to pass through user traffic.
• certbot is used to create a Let’s Encrypt certificate for mail[.]victim[.]com
  • We have observed multiple Domain Control Validation providers being utilised as part of this campaign.
• A user now visits mail[.]victim[.]com and is directed to OP1. The Let’s Encrypt certificate allows the browsers to establish a connection without any certificate errors as Let’s Encrypt Authority X3 is trusted. The connection is forwarded to the load balancer which establishes the connection with the real mail[.]victim[.]com. The user is not aware of any changes and may only notice a slight delay.
• The username, password and domain credentials are harvested and stored.
  • Technique 2 – DNS NS Records

 

The second method exploited by the attacker involved altering DNS NS Records

• The attacker again logs into PXY1.
• This time, however, the attacker exploits a previously compromised registrar or ccTLD.
• The nameserver record ns1[.]victim[.]com is currently set to 192.168.100.200. The attacker changes the NS record and points it to ns1[.]baddomain[.]com [10.1.2.3]. That nameserver will respond with the IP 10.20.30.40 (OP1) when mail[.]victim[.]com is requested, but with the original IP 192.168.100.100 if it is www[.]victim[.]com.
• The attacker logs in from PXY1 to OP1.
  • A proxy is implemented to listen on all open ports, mirroring mail[.]victim[.]com.
  • A load balancer points to 192.168.100.100 [mail[.]victim[.]com] to pass through user traffic.
• certbot is used to create a Let’s Encrypt certificate for mail[.]victim[.]com.
  • We have observed multiple Domain Control Validation providers being utilised during this campaign.
• A user visits mail[.]victim[.]com and is directed to OP1. The Let’s Encrypt certificate allows browsers to establish a connection without any certificate errors as Let’s Encrypt Authority X3 is trusted. The connection is forwarded to the load balancer which establishes the connection with the real mail[.]victim[.]com. The user is not aware of any changes and may only notice a slight delay.
• The username, password and domain credentials are harvested and stored.
  • Technique 3 – DNS Redirector

 

 

The attacker has also been observed using a third technique This involves a DNS Redirector.

The DNS Redirector is an attacker operations box which responds to DNS requests.

1. A DNS request for mail[.]victim[.]com is sent to OP2 (based on previously altered A Record or NS Record).
2. If the domain is part of victim[.]com zone, OP2 responds with an attacker-controlled IP address, and the user is re-directed to the attacker-controlled infrastructure.
3. If the domain is not part of the victim.com zone (e.g. google[.]com), OP2 makes a DNS request to a legitimate DNS to get the IP address and the legitimate IP address is returned to the user.

Targets

A large number of organizations have been affected by this pattern of DNS record manipulation and fraudulent SSL certificates. They include telecoms and ISP providers, internet infrastructure providers, government and sensitive commercial entities.

Defending Against DNS Hijacking

How to detect

The fastest way to detect DNS hijacking is by using the ping utility. If you ping a non-existent domain and it resolves, that is probably a very strong indicator that your ISP is hijacking your DNS traffic. The idea here is to ping the hostname, this should fail if it does actually return an IP address you are the victim of DNS hijacking.

Another way which gives you a 100% confirmation if your DNS is being hijacked, is to change your DNS address on a device you use to 0.0.0.0 and 0.0.0.1 . If after that your Internet still works and you can open up web pages normally your DNS traffic hijacked.

How to Protect

• Be aware of the issue:Like with most things, the first step would be to become aware of the issue and to try and find out if you’ve already been affected by a DNS changer. The easiest way to detect a DNS hijack is to use the ping utility. Try pinging a domain you know for sure doesn’t exist and if it resolves, there is a very high chance that you are a victim of DNS hijacking.
• Stay away from shady websites:Considering that in many cases, the attacks are carried out through trojan horse or similar malware programs, it is highly recommended to stay away from shady websites in the first place. The viruses are usually served through video or audio codecs, through Youtube downloaders or other similar free online utilities. A great example is the DNS Changer Trojan which was used to hijack over 4 million computers.
• Change your router password:Changing your router password constantly also decreases your chances of being hijacked. If a hacker targeted your router and is trying to access it to change the settings, it would be best not to find that it is only protected by the default factory password.
• Use a VPN service:Using a VPN service is also one of the most common and effective ways of protecting yourself against DNS hijacking. A VPN would encrypt all your internet traffic and send it through a virtual tunnel. Since this includes all your DNS/Web traffic, your hijacker will be unable to decipher your traffic, which in the end means that you will not have to deal with any annoying or dangerous redirects. On top of this, you can use a VPN regardless of your location, which means that you can stay protected while you travel or while using less secured Wi-Fi networks.

Some of those best practices for organizations:

• -Use DNSSEC (both signing zones and validating responses). DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn’t match the domain requested, the name server blocks the user from reaching the fraudulent address. While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by APNIC, the regional Internet address registry for the Asia-Pacific region.
• -Use registration features like Registry Lock that can help protect domain names records from being changed
• -Use access control lists for applications, Internet traffic and monitoring
• -Use 2-factor authentication, and require it to be used by all relevant users and subcontractors
• -In cases where passwords are used, pick unique passwords and consider password managers
• -Review accounts with registrars and other providers
• -Monitor certificates by monitoring