Saturday, 6 August 2011

DNSWall, Rebinding and client attacks (Part 2).

Continuing from last nights post on DNS Rebinding, I will detail this attack more and then start to show a few defences.

The attacker will start by either creating their own website or attacking and subverting another. The latter is more effective with many large and high profile sites having been compromised in the last 12 months and used for these types of attacks. Further, these sites are more trusted (ones such as News Ltd’s) being read by many existing subscribers and commonly whitelisted in companies.

In the incidence, the DNS server will be under the control of the attacker as well. This can be through attacking the organisations DNS, the end user’s DNS (and home routers can be very susceptible to this) or by injecting packets. The attacker who sets up their own site for this attack has an easier time as they will generally be in charge of their own DNS already. Hence, they can easily set the responses that the DNS resolves queries to for a site.

In stage 1, the victim goes to the attacker’s site. The DNS will initially return the correct IP Address for the webserver that the attacker has control of on the internet.

The TTL is set (this is the time to live) for the query at a value that suits the attacker’s purpose. Following the initial call to the website, the next response will be an IP address that the attacker wants to extend their access to. That is, they rebind the hostname of the webserver to another address.

For instance, if you have a system on IP address 10.1.1.2 and the attacker wants to gain access and information from an internal intranet system that is authenticated though IP address authentication (or using CSRF – more on this later) internet to your network and firewall on IP 10.1.1.100, the attacker will rebind their hostname that the DNS returns to 10.1.1.100.

Next time the victim’s browser makes a call to the hostname, it will be pointed not to the attacker’s website, but to the victim’s internal server at 10.1.1.100 bypassing the firewall and other controls.
You may ask how does this help the attacker?

This is one of many types of rebinding attack and is known as a “Firewall Circumvention” rebind attack.
The attacker would have already loaded script into their initial webpage. This can be JavaScript, Flash or a combination of both (and even other types of active code). The hostname call from JavaScript or Flash will be delayed so that a different name is obtained from the DNS server than the browser itself obtained. Using JavaScript and Flash together, an attacker can pull information from an internal site and feed it back to the attacker over standard HTTP queries bypassing the firerwall.

One of the biggest issues here is that Java, JavaScript, Flash and the browser itself all “pin” DNS queries differently and for different amounts of time. So the browser will remember an IP address (pin it) for a different amount of time than that of the script.

Java has a control that was designed to stop (or at least make this more difficult) here in the documentation they state “The positive caching is there to guard against DNS spoofing attacks

networkaddress.cache.ttl (default: -1)
 
The value of -1 designates "cache forever" where Java will remember the IP address it was first given for the life of the session (this is right to a reboot sometimes).

FLASH has the Socket class in the newer versions of FLASH Player (Version 9.0 and greater, ActionScript 3.0). That also make this attack more dangerous as the sockets that flash can bind can be anything within the organisation. That is, any port and any protocol, not just web.

The call to Java in the applet and that in Flash can be subverted by delaying the response from the DNS server that these applets make to after the initial page has loaded.

This way, the attacker can go from a webpage with an IP on the external Internet, a delay and then a response to the script on an internal RFC 1918 address (in our example 10.1.1.100) that will be cached forever. Once the script is cached, the attacker can return the IP address to the external IP of the Internet again to ensure that page reloads are maintained as well.

The script (such as the Java applet) will point at the internal Server (10.1.1.100) but the user and browser will again see the attacker as an external IP address and the attacker can use this to send information to or from the system they wish to attack that lies behind the firewall.

Craig Heffner used such a scenario in his BlackHat presentation “How to Hack Millions of Routers”.
This attack can be easily deployed to attack routers, printers, switches, internal servers and more. With flash sockets, this can be used to scan internal ports on protocols other than HTTP/HTTPS. One common technique is for SSH username and password guessing behind a firewall.

So, are you looking at the authentication logs for internal systems as well? 

In the third and final part of this post, I will cover one solution, DNS Wall. There are other solutions ranging from not running script (though in the Web 2.0 world this is no longer much of an option), to using NoScript (as long as you support and use Firefox as your browser) to other DNS options and even creating tailored IPS block lists and filters.

NoScript is a definite option where you can use it. Even with ALL SCRIPTS ALLOWED, NoScript provides protection against many rebinding attacks. But the issue is when there are many users and in organisations where a standardised browser deployment does not include Firefox, this is not an option.
So, next, a solution to the problem I have just raised…

No comments: