In modern times, it is possible for an attacker to persistently and repeatedly hijack a victim's bank account at most major US banks through the victim visiting a web page. This is done without browser exploits or any visible warning. For a criminal, these attacks are cheap and highly successful. The attack that I am talking about is DNS hijacking. DNS hijacking is a type of attack wherein a victim's DNS queries are intercepted and (generally) false responses are given. What this allows an attacker to do is redirect a user to another web site while keeping the URL bar the same. For instance, if a victim went to wf.com (Wells Fargo), a DNS query could be sent to the attacker's DNS server that would reply with the attacker's web server where they could record any login data. Since 2010, there has been a rise in the number of MITM (Man-in-the-Middle) attacks through DNS hijacking. This changes the threat model of MITM attacks because, up until that point, large-scale MITM attacks had been largely unheard of. The reason for this is that, generally, when one wants to MITM someone's traffic, they need to handle all of their traffic, for instance, through a proxy. This requires significant bandwidth per victim, and it means an attacker would need to build significant infrastructure. This is something that would likely cost an attacker more than their profit. Fortunate for attackers, the server a client uses for DNS is nearly always something that can be changed without changing other network settings. Because of this, DNS in particular, lends itself to being small and easy to intercept. This enabled the rise of DNS hijacking malware. In 2010, we saw DNSCHANGER, a piece of malware that ran on a victim's machine and changed their DNS server via Windows API calls. In 2014, we saw an evolution of this principle in the form of SOHO, a piece of malware that spread itself via CSRF. Essentially, it sent many requests trying default passwords for many brands of routers on 192.168.0.0, 192.168.1.1, 10.0.0.1, etc in an attempt to find the victim's router and change its DNS server. This DNS server is then used by members of the network because the router sets most of its clients' DNS server via DHCP. (I'd say most clients receive their DNS server settings from their DHCP server, which is often their router.) After this, an attacker could intercept HTTP requests that include redirects or hyperlinks to TLS sites (https) and change them to normal HTTP. This is similar to how TLSSTRIP works. Part of my talk at BSidesSF will include releasing a tool that does this. It's called ‘DNTLSSTRIP.’ DNTLSSTRIP helps pentesters execute DNS hijacking and dynamically intercept and modify HTTP data. It’s modular, so your users can add a module for any protocol they want to dynamically intercept. The second part of my talk will be on how DNS hijacking attacks can be used inside corporate networks for pentesters, as well as how criminals might use them and how you can defend against them. This leads us to a thought experiment of sorts: owning a network using exclusively DNS once inside. I will be showing a demo of this at my talk. In a corporate environment, stakes are much higher, and as such, attackers are particularly motivated to penetrate a given network. (For this, we are assuming the attacker already has a trivial foothold in a network through common means like phishing or the like.) For this reason, the most likely way an attacker would get into such a network would be a targeted attack, most likely router exploits or default passwords. For that reason, it is best to think about such an attack from the perspective of an attacker getting RCE on, say, the router for a given network. From here, an attacker or pentester would want to spread in a network. Once again, this presents a great way to use DNS hijacking. Due to the vast number of services that update over unencrypted channels and do not check to see if the binaries they download are authentic, there are many ways an attacker can use MITM to pivot to having control of multiple boxes. In the case of my demonstration, I will use CVE-2016-1252, an APT signing bypass exploit. I would not be surprised if APT groups have access to a myriad of similar vulnerabilities and 0day exploits to match. An attacker would also not have to bypass TLS in this case because the majority of default APT sources for most distributions do not use TLS. From this point, an attacker need only push a fake critical update for a critical service or a service that automatically (think a crontab for apt-get upgrade) updates. It is not unreasonable to think that after a number of days of running such an attack, an attacker would have access to a number of machines on that network. Once again, using DNS, an attacker could create an obfuscated C&C channel using TXT records, similar to how DNSCAT works. Mitigations, another thought experiment: how does a defender stop these attacks. All of the above attack methods depend on making outbound DNS requests to arbitrary servers. This can be solved by blackholing DNS requests to unknown servers at the firewall level or End point / AV client for corporate resources that are "off-net." This wholly eliminates the primary attack vector we used in the above paragraph, and it allows us to block any requests to outside DNS servers. This also stops an attacker from using DNS as a C&C channel, though this still allows for attacks on automatically updating software. To solve this, it is important to try to use end-to-end encryption whenever possible. Lastly, as a practical matter, it makes the most sense to blackhole requests to unknown DNS servers at the IDS/IPS level with solutions like - say - Tripwire. I will be discussing these topics and more at BSidesSF 2017 in the talk: DNS attacks, past, present, and future. I hope to see you there!
About the Author: Nick McKenna is a student researcher who has had an interest in cyber security for the past five years. Nick likes seeing how things work and trying to break them. If you have any questions, you can contact Nick here. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
