From charlesreid1

Line 28: Line 28:
=Pauls Security Podcast Wiki Notes=
=Pauls Security Podcast Wiki Notes=


<pre>
The best ways to Arp cache poison?
Tech Segment: Arp Cache Poisoning Notes


So, for some future technical segments I am researching the best ways in which to Arp cache poison. Below are some interesting notes:
==send_arp==


There is a cool program called send_arp (http://insecure.org/sploits/arp.games.html) which does arp cache poisoning. Its pretty simple right, consider the following example:
Program called send_arp (http://insecure.org/sploits/arp.games.html), very simple example given below in which the ARP cache entry for the DNS server is poisoned.


<pre>
     DNS Server: 192.168.1.10
     DNS Server: 192.168.1.10
     Attacker: 192.168.1.67
     Attacker: 192.168.1.67
     Victim: 192.168.1.61
     Victim: 192.168.1.61


./send_arp 192.168.1.10 00:1f:c6:7b:4e:a2 192.168.1.61 00:0c:6e:20:6b:4e
./send_arp \
  192.168.1.10 00:1f:c6:7b:4e:a2 \
  192.168.1.61 00:0c:6e:20:6b:4e
</pre>
 
In this example, 192.168.1.10 is our DNS server, followed by its Mac address.
 
192.168.1.61 is our victim, followed by its MAC address.
 
The above command sends the arp entry for 192.168.1.10 to 192.168.1.61. In my example, I am tell the client "Hey, your DNS server's MAC address is really 00:1f:c6:7b:4e:a2". This now means that all of that traffic will be forwarded to that mac address.


In this example, 192.168.1.10 is our DNS server, followed by its Mac address. 192.168.1.61 is our victim, followed by its MAC address. The above command sends the arp entry for 192.168.1.10 to 192.168.1.61. In my example, I am tell the client "Hey, your DNS server's MAC address is really 00:1f:c6:7b:4e:a2". This now means that all of that traffic will be forwarded to that mac address. This works great, Windows is the target in my example, and its totally fooled. If I fire up tcpdump, I can see the requests:
The target should be totally fooled. Check by firing up tcpdump on the attacker machine:


<pre>
16:17:24.561166 IP 192.168.1.61.2073 > 192.168.1.10.53: 3+ A? amazon.com. (28)
16:17:24.561166 IP 192.168.1.61.2073 > 192.168.1.10.53: 3+ A? amazon.com. (28)
16:17:24.561179 IP 192.168.1.61.2073 > 192.168.1.10.53: 3+ A? amazon.com. (28)
16:17:24.561179 IP 192.168.1.61.2073 > 192.168.1.10.53: 3+ A? amazon.com. (28)
</pre>
But wait! There's more! The client is not happy, let's found out why!
==packet forwarding==
From the perspective of the attacker, things are not going to go down smoothly. In the tcpdump traffic shown above, you can see requests going to our computer (since we poisoned the ARP table entry, everything will go to our hardware). But the traffic, when it arrives, is addressed to 192.168.1.10, which is the IP address the DNS server is supposed to have. But the attacker machine has an IP address of 192.168.1.67. Layer 2 was set up properly, but Layer 3 wasn't.
DNS requests have been properly routed to our hardware on Level 2, but even if a DNS server were running, the traffic isn't addressed to us, so the network card will, by default, ignore the packets unless they're addressed to 192.168.1.67.


However, from the client's perspective, things are not-so-happy. Why? Because my attacking hosts IP addreess is not 192.168.1.10, so the IP stack has no idea what to do with the packets. Essentially, we've spoofed layer 2 and didn't tell layer 3. So, even if I am running a DNS server at this point, my machine will not respond. It will only respond to IP traffic sent to 192.168.1.67, its assigned IP address. So, what most of us attacker type people do is enable forwarding in the Linux kernel:
To fix this, enable packet forwarding in the Linux kernel:


<pre>
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_forward
</pre>
By enabling packet forwarding, the Linux kernel will forward, unmodified, any packets it receives for any non-192.168.1.67 addresses. This way, your computer will receive all network traffic, but will pass it along as though nothing happened. This makes passive attacks that intercept traffic and sniff packets possible.


So now the Linux kernel will forward the traffic to 192.168.1.10, and the client can then resolve names and the world is happy again. This works great for intercepting traffic and packet sniffing. However, what do you do if you want to manipulate DNS entries as they are going by? While further research is needed to find the best way to do this on Linux (I was hoping to receive feedback on this one :) Cain & Abel works great for this. They do APR (Arp Poison Routing) which takes care of this routing layer. This allows you to re-write the responses and change entries, screenshot below:
==Manipulating DNS==


If you want to modify the DNS traffic, there are multiple options (e.g.?)


So how is this different from the DNS bug that Dan found? Arp cannot cross layer 3 boundries, so you have to be on the same subnet as your victim. However, if you are able to compromise the internal network, you can launch this attack. There are several ways to mitigate, using tools such as arpwatch and even snort has ways to monitor the Arp table. However, I've found that most people do not configure these defenses. This can be a very subtle way to control hosts on the network, and next week we will explore some attacks that will build on this segment.
Windows folks can use the program Cain and Abel to modify DNS entries as they go by. Cain and Abel does ARP poisoning of the routing layer, allowing you to rewrite responses to DNS queries and change DNS entries.


Below are some tools that enable you to do this as well:
==Countermeasures==


    dsniff - The "arpspoof" command will let you do this.
You can detect and mitigate attacks with a program like [[Arpwatch]], or by using [[Snort]] to monitor the ARP table.
    Cain & Abel - A Windows-based tool that will let you do this as well.
</pre>


This can be a good way to control hosts on a network.


=Resources/Links=
=Resources/Links=

Revision as of 04:39, 21 August 2016

ARP = address resolution protocol = the protocol for mapping MAC addresses to IP addresses


Some Background

How ARP Works

This refers to some concepts about network communications protocols covered on the Packet Analysis page.

ARP is a way of using Layer 2 addressing, MAC addresses, with Layer 3 addressing, or IP addresses.

To communicate with other devices on a network, you use their IP addresses. But routers operate on Level 2, MAC addresses. That means that communicating with other devices on a network also requires knowing their MAC address. Getting a MAC address from an IP address is done through ARP.

When computer A is crafting a packet to computer B, it begins by seeing if computer B is in the ARP cache, meaning computer A would already have computer B's MAC address. If not found, computer sends a broadcast packet to FF:FF:FF:FF:FF:FF and asks for which computer at which IP address owns a particular MAC address.

Computers C, D, and E discard the packet. But the recipient, computer B, crafts a reply with its MAC address with an ARP reply. When computer A receives the reply, it stores that information in the computer's ARP cache.

How ARP Poisoning (Spoofing) Works

This is the process of fooling a switch or router into thinking your computer has a MAC address that it actually doesn't.

One way to use ARP poisoning is to tap the wire of a network, and intercept traffic from a router to a target computer. In this case, you're fooling the router into sending you the traffic instead, and you forward the traffic on to the target computer like nothing ever happened.

Another way to use ARP poisoning is to cause denial of service attacks. In this case, client requests are sent to a router, which then forwards traffic to a particular MAC address at a particular IP address. Except, the destination computer isn't who it's supposed to be, and so isn't ready for the traffic.

A note that when you start intercepting packets on the computer with the spoofed MAC address, you should be ready for whatever bandwidth those requests are coming in at - by inserting yourself between the router and the target, you become the bottleneck.

Pauls Security Podcast Wiki Notes

The best ways to Arp cache poison?

send_arp

Program called send_arp (http://insecure.org/sploits/arp.games.html), very simple example given below in which the ARP cache entry for the DNS server is poisoned.

    DNS Server: 192.168.1.10
    Attacker: 192.168.1.67
    Victim: 192.168.1.61

./send_arp \
  192.168.1.10 00:1f:c6:7b:4e:a2 \
  192.168.1.61 00:0c:6e:20:6b:4e

In this example, 192.168.1.10 is our DNS server, followed by its Mac address.

192.168.1.61 is our victim, followed by its MAC address.

The above command sends the arp entry for 192.168.1.10 to 192.168.1.61. In my example, I am tell the client "Hey, your DNS server's MAC address is really 00:1f:c6:7b:4e:a2". This now means that all of that traffic will be forwarded to that mac address.

The target should be totally fooled. Check by firing up tcpdump on the attacker machine:

16:17:24.561166 IP 192.168.1.61.2073 > 192.168.1.10.53: 3+ A? amazon.com. (28)
16:17:24.561179 IP 192.168.1.61.2073 > 192.168.1.10.53: 3+ A? amazon.com. (28)

But wait! There's more! The client is not happy, let's found out why!

packet forwarding

From the perspective of the attacker, things are not going to go down smoothly. In the tcpdump traffic shown above, you can see requests going to our computer (since we poisoned the ARP table entry, everything will go to our hardware). But the traffic, when it arrives, is addressed to 192.168.1.10, which is the IP address the DNS server is supposed to have. But the attacker machine has an IP address of 192.168.1.67. Layer 2 was set up properly, but Layer 3 wasn't.

DNS requests have been properly routed to our hardware on Level 2, but even if a DNS server were running, the traffic isn't addressed to us, so the network card will, by default, ignore the packets unless they're addressed to 192.168.1.67.

To fix this, enable packet forwarding in the Linux kernel:

echo "1" > /proc/sys/net/ipv4/ip_forward

By enabling packet forwarding, the Linux kernel will forward, unmodified, any packets it receives for any non-192.168.1.67 addresses. This way, your computer will receive all network traffic, but will pass it along as though nothing happened. This makes passive attacks that intercept traffic and sniff packets possible.

Manipulating DNS

If you want to modify the DNS traffic, there are multiple options (e.g.?)

Windows folks can use the program Cain and Abel to modify DNS entries as they go by. Cain and Abel does ARP poisoning of the routing layer, allowing you to rewrite responses to DNS queries and change DNS entries.

Countermeasures

You can detect and mitigate attacks with a program like Arpwatch, or by using Snort to monitor the ARP table.

This can be a good way to control hosts on a network.

Resources/Links

http://www.cs.sjsu.edu/faculty/stamp/students/Roney298report.pdf

Flags