Securebits Blog

DNSWall is a proof-of-concept (PoC) tool developed by some security researchers from Stanford University as a protection mechanism against DNS rebinding attacks. In their research paper “Protecting Browsers from DNS Rebinding Attacks”, Collin Jackson et al. discuss the DNS Rebinding vulnerabilities, attacks, and defenses.

DNS rebinding attack exploits the web browser same-origin policy. The same-origin policy states that a web browser can run scripts (e.g. Javascript, Flash, etc) that communicate with ‘another’ web site as long as the original website and the second one share the same origin. The same-origin policy defines three conditions: (a) same protocol, (b) same port, and (c) same hostname. For example, the address "http://www.securebits.org" and the address "https://www.securebits.org" do not share the same origin, and thus, cannot script against each other. The web browser does not allow scripts from "http://www.securebits.org" to communicate freely with "https://www.securebits.org". On the other hand, the address "http://www.securebits.org:8080" and the address "http://www.securebits.org:8080/somefolder/" are said to have the same origin because they share the same protocol (http), the same port (8080) and the same hostname (www.securebits.org).

An attacker can exploit this policy by rebinding the hostname of a particular website to an IP address that is different than the original one. Usually, the attacker would build a website that is under his/her control. He/she also controls the DNS server that resolves the DNS queries related to that website. When the victim accesses the website for the first time, the DNS server gives out the correct IP address. However, later on, the attacker rebinds the hostname of the website with a false IP address - usually an IP address that the attacker does not have access to – so that any subsequent link to the website will be directed to that IP address. By doing this, the attacker can script against the IP address – he/she can port scan, bypass firewall, access systems, etc.

To illustrate this with an example, let’s say that the victim’s machine is behind a firewall and has the IP 10.10.10.5. In the same network, there is a printer with the IP 10.10.10.8. The printer can be accessed through a web interface and normally does not prompt for username/password since it is in a private network and is only accessible by trusted systems within the network. The attacker, who is outside in the Internet, would build a website "www.example.com", and also control a DNS server that resolves the hostname "www.example.com" to the IP 65.54.43.32. Through social engineering tricks, the attacker would trick the victim to visit the website "www.example.com". Initially, the browser will send a DNS query to resolve that name and eventually will get the IP 65.54.43.32. When the client visits the website, the contents of the website are downloaded. The attacker sets a script (Javascript or Flash) that initiates a connection to the “hostname” (www.example.com). By the time this script is executed by the browser, the browser needs to query the DNS again to resolve the hostname "www.example.com". At this time, the attacker’s DNS server will reply with the IP address 10.10.10.8, basically rebinding the hostname to a different IP. Now, the script will actually initiate the connection with the local printer and can re-configure it.

This type of DNS rebinding attack is called “Firewall Circumvention” and it is one of the typical attacks using DNS rebinding technique. The example above mentioned “a printer” as an example; however, any internal device, such as a DSL router, switch, server, etc, can be a target of DNS rebinding attack.

Dnswall is a program that runs on the corporate network DNS server. Its sole purpose is to prevent the resolving of public names to internal IP addresses. According to the authors:

“By blocking outbound traffic on port 53, a firewall administrator for an organization can force all internal machines, including HTTP proxies and VPN clients, to use a DNS server that is configured not to resolve external names to internal IP addresses. To implement this approach, we developed a 300 line C program, dnswall, that runs alongside BIND and enforces this policy.

[…] Many consumer firewalls, such as those produced by Linksys, already expose a caching DNS resolver and can be augmented with dnswall to block DNS responses that contain private IP addresses. The vendors of these devices have an incentive to patch their firewalls because these rebinding attacks can be used to reconfigure these routers to mount further attacks on their owners”

The Dnswall program runs as an intermediary proxy DNS server between the client and the real forwarder server. It intercepts the DNS queries sent by clients, forwards the query with little modification, receives and forwards the reply to the client only when the IP address in the answer payload is public. If the answer IP address is private/multicast, the Dnswall sends NXDOMAIN reply. Particularly, the program checks for IP addresses in the following ranges:

- Invalid IP address: an IP address that starts with 0; i.e. 0.x.x.x
- Node-Local IP address: 127.x.x.x
- Link-Local IP address: 169.254.x.x
- Site-Local IP address: 10.x.x.x, 172.x.x.x, 192.168.x.x
- Multicast IP address: 224.x.x.x

The program can run with the following arguments:

     ./dnswall -b (bind ip) -B (bind port) 
       -f (forwarder ip) -F (forwarder port)

Where ‘bind ip’ is the listening IP address, ‘bind port’ is the listening port number, ‘forwarder ip’ is the IP of the real DNS server, and ‘forwarder port’ is the port on which the forwarder is listening.

Finally, an important point to mention is that the Dnswall program forwards DNS queries after modifying the TXID of the original query. This is done to map the replies with their original queries. However, the new TXID used is sequentially incremented, starting from 0 to 65536. This opens the door to the opportunity of DNS cache poisoning. An attacker would predict the TXID and inject a false response to poison the DNS cache of the client machine. The code snippet that handles this is:

  // Replace the id with our own query identifier
  *((short *)&msg[0]) = htons(current_query);
  current_query++;
  if (current_query >= 65536)
   current_query = 0;

Administrators who seriously want to deploy Dnswall needs to do a little modification to this code to prevent the poisoning attacks. Mainly, a randomization algorithm should be used to select new TXID, or at least preserve the same original TXID.

IP spoofing is one of the techniques used by attackers to perform different attacks. It could be used while flooding a network, SYN-attacking a server, generating IDS false positives, etc. The rule when spoofing the source IP address is that replies do not matter to the attacker since replies will be sent to the spoofed IP and will not reach the attacker. Implementing an attack that requires an interactive communication between the attacker’s machine and the victim cannot take place with a spoofed IP address.

Port scanning is the technique to discover open ports on a remote system. To discover an open TCP port, the attacker needs to send a TCP SYN packet to a specific port and receive one packet back. If the received packet is a SYN_ACK packet, the port is open. If the received packet is a RST packet, the port is closed. If no reply is received, the port is filtered by a firewall or any other filtering engine. The reply packet, whether it is a SYN_ACK or RST, must reach the attacker’s machine so that it will be examined. This requires that the received packet is destined to the IP address of the attacker’s machine (or at least an IP address that is under control of the attacker) which in turn requires that the scanning packet sent by the attacker contains the actual source IP address of the attacker. So, the basic operation of port scanning cannot be done with a spoofed IP address.

Nmap, the infamous port scanner, can send spoofed scan packets. However, it is not meant as a reliable scan. Meaning, the attacker will not get reliable results of his/her scan. Such spoofed scan can be used to elude the IDS/IPS and generate huge amount of signatures. Also, it could be used as a way to divert the attention of the target corporate organization to another competitor organization; the spoofed scan will appear as if it is coming from the competitor organization.

However, the question is: can we have spoofed port scanning that is reliable? The answer is ‘Yes’ but with the following two constraints:
[1] The port scan should be conducted internally within a LAN; for example, the port scan can be part of an internal security audit or penetration test. The technique used to achieve this reliable spoofed port scan cannot be implemented over a WAN.
[2] The spoofed IP addresses used during the port scan should fall within the range of the local subnet. For example, if the attacker’s machine is in class C (255.255.255.0), he/she can use any of the 253 valid IP addresses within the subnet range; if subnet is a class B (255.255.0.0), the pool of valid spoofed IP addresses is 65533.

The technique to achieve this reliable spoofed port scan is based on integrating ARP poisoning with port scanning. ARP poisoning refers to the ability of the attacker to insert a fake entry in the ARP cache of the victim machine. This fake entry links an IP address, which is within the same subnet range of the victim’s machine, with a false MAC address. The entry will cause any traffic destined to that particular IP address to be destined, at layer 2, to the machine with the MAC address associated with the IP address. An attacker will typically insert fake entries that link different IP addresses to the MAC address of his/her machine; thus, all local traffic will be delivered to his/her machine. A typical use of ARP poisoning is to achieve layer 2 traffic interception between two machines (either of them could be even a router or gateway.)

The process of doing a reliable spoofed port scanning works by poisoning the ARP cache of the remote machine with a false entry that links the spoofed source IP address used in the scanning with the MAC address of the attacker’s machine. For every spoofed source IP used, the attacker needs to inject a fake ARP entry for it. It is also important to note that there is a difference between scanning a system that is located within the local subnet and a system that is in a different subnet. When scanning a system located locally, the ARP cache of this machine needs to be poisoned; however, when scanning a system located outside the local subnet, the ARP cache of the router/gateway is what needs to be poisoned. This is because the ARP protocol functions at layer 2 which cannot be routed externally to other networks.

To effectively poison an ARP cache of a remote machine, two ARP packets at maximum are needed or one ICMP packet and one ARP packet. In the case of two ARP packets, the first one is an ARP request while the second is an ARP reply. Both packets contain the following arguments: the destination MAC address is the victim MAC address, the source MAC address is the attacker’s MAC address, the destination IP address is the victim’s IP address, and the source IP address is the spoofed IP address which the attacker wants to inject. For example, let’s assume the following scenario:
a. The victim’s IP address is 10.10.10.10
b. The victim’s MAC address is aa:aa:aa:bb:bb:bb
c. The attacker’s IP address is 10.10.10.3
d. The attacker’s MAC address is bb:bb:bb:cc:cc:cc
e. The attacker wants to intercept traffic going from the victim to 10.10.10.50

The attacker, then, sends two ARP packets (the first is ‘Query’ and the second is ‘Reply’) to the victim with the following arguments:
a. Source IP is 10.10.10.50
b. Destination IP is 10.10.10.10
c. Source MAC is bb:bb:bb:cc:cc:cc
d. Destination MAC is aa:aa:aa:bb:bb:bb

These two packets will inject the following spoofed entry in the ARP cache of the remote machine:
10.10.10.50 is at bb:bb:bb:cc:cc:cc

This will cause any packet sent by the victim machine (10.10.10.10) to 10.10.10.50 to be switched at layer 2 to the attacker’s machine.

By integrating the technique of “ARP Poisoning” into “Port Scanning”, we can have a reliable spoofed source IP port scanning. What is needed is to poison the remote machine (or the gateway) with a fake entry that links every used spoofed source IP with the attacker’s MAC address. Such will cause any scan reply to be delivered to the scanning machine. The algorithm for the whole process of spoofed scanning would be as follows:
1. Check whether the scan target is within the local subnet or outside.
2. If it is within the local subnet, the “poisoning target” is the same as the “scan target”. If the “scan target” is outside the local subnet, then the “poisoning target” is the “gateway”
3. Generate a random spoofed source IP that falls within the local subnet.
4. ARP-poison the “poisoning target” with a fake entry that directs all traffic destined to the spoofed IP to the attacker’s machine.
5. Send the scan packet to the “scan target”
6. Wait for a reply with the same MAC address as the attacker’s MAC address.

Generating different spoofed IP with every scanning packet (one packet for one port) would make the scan appear as if it is distributed between multiple (fake) systems. H.K. has generated a live image with Etherapp tool representing the distribution of the spoofed port scanning: