Spying on Segmented Networks

Network segmentation using Switches seemed the perfect solution to avoid the dreaded sniffers. But all that glitters is not gold and it is possible to take advantage of an insecurity in the ARP protocol to spy on the network. In this article we are going to explain one of the techniques used to sniffing in a network segmented through Switches: ARP-SPOOFING.

Let's start by getting into the environment, clarifying ideas and defining terms. I do not want to start releasing acronyms and technical words and you all stay with your mouth open and looking for another article to read.

Ethernet networks

The ethernet was conceived around a main idea: all the machines of the same local network share the same medium (the cable). All machines are able to "see" all network traffic. Because of this, ethernet cards incorporate a filter that ignores all traffic that is not intended for it. This is achieved by ignoring those packets whose MAC address (Media Access Control) does not match your own. A sniffer removes this filter from the network card and places it in promiscuous mode. In this way the card is able to "see" all the traffic passing through the network. It is only a matter of placing the appropriate filters and start capturing the packages that interest us most (login / passwd of telnet connections, POP3, vnc, ...)

The use of switches solves this problem. Through the segmentation of the network the only traffic that we will be able to see will be ours, since the Switch is responsible for routing to our segment only those packages destined for our MAC address.

What is a MAC address?

all the computers of the same network share the same medium, so there must be a unique identifier for each computer, or better for each network card. This does not happen in a modem telephone connection, since it is assumed that any data sent is destined for the equipment on the other side of the line. But when sending data on a local network, you must clearly specify who you are targeting. This is achieved through the MAC address, a number composed of 12 hexadecimal digits that uniquely identifies each ethernet device. The MAC address consists of 48 bits. The first 24 bits identify the hardware manufacturer, and the remaining 24 bits correspond to the serial number assigned by the manufacturer, ensuring that two cards can not have the same MAC address.

Now that it is more or less clear that to communicate in an ethernet network with another team it is necessary to know its MAC address, which is unique, we will see how we can know the MAC addresses of the computers in our network. The configuration of the card of our team will be obtained with the ifconfig -a command. The output of this command will resemble the following:

eth0 Link encap: Ethernet HWaddr 00: C0: 4F: 68: BA: 50

inet addr: 192.168.0.1 Bcast: 192.168.0.255 Mask: 255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU: 1500 Metric: 1

RX packets: 31658 errors: 0 dropped: 0 overruns: 0 frame: 0

TX packets: 20940 errors: 0 dropped: 0 overruns: 0 carrier: 0

collisions: 0 txqueuelen: 100

Interrupt: 19 Base address: 0xdc00

where the MAC address is 00: C0: 4F: 68: BA: 50.

If we want to know the addresses of other computers in the network, we will use the arp cache of our computer, using the arp -a command. This command will show us the IP / MAC relation of the computers that the cache has stored at that moment. (If we want to obtain the ethernet address of a machine, we will first ping it. arp -a we can get your MAC address). Whenever we want to communicate with a computer in the network, we must know its MAC address. For this we will send an arp-request to the Broadcast address, requesting the MAC of the ip of the equipment with which we want to contact. This will respond with an arp-reply informing us of your MAC. This will be stored the cache arp, for some minutes, for future communications. This way we will not have to re-request the MAC address. This is where the problem begins

ARP Operation

The address resolution protocol ( ARP ) is responsible for "translating" the 32-bit IP addresses to the corresponding hardware addresses. In ethernet & token ring these addresses usually have 48 bits. Reverse translation is done by the RARP or Reverse ARP protocol.

When a computer needs to resolve an IP address to a MAC, it does an arp (Arp request) request to the broadcast of that network segment, FF: FF: FF: FF: FF, requesting that the equipment with this IP responds with its ethernet address (MAC).

Schematically the process is:

In order to reduce traffic on the network, every arp-reply that reaches the network card is stored in the cache, even if the request is not made by us. That is, all arp-reply that arrives at us is stored in the cache. This factor is the one we will use to perform arp-spoofing.

Arp-Spoofing

This method does not put the network interface into promiscuous mode. This is not necessary because the packets are for us and the switch will route the packets to us. Let's see how this is possible.

The method consists of "poisoning" the arp cache of the two machines we want to sniff. Once the caches are poisoned, the two hosts will begin communication, but the packets will be for us, sniffearemos and we will route them back to the appropriate host. This way the communication is transparent for the two hosts. The only way to find out that there is "a man in the middle" in our connection would be to see the arp cache of our machine and check if there are two machines with the same MAC address. The outline of the communication is simple:

From our machine we will send fake arp-reply type packets to the two hosts we want to sniff. In these reply's we must tell host 1 that the ethernet address of the second host is ours, this information being stored in its arp cache. This computer will now send the packets to host 2 but with our MAC address. The packages are already ours. The switch will take care of giving us the data. Let's imagine the following situation:

We send a constant stream of arp-reply (to prevent the arp cache of the machines from being refreshed with the true information) to host 1 and host 2 with the following data:

HOST 1: arp-reply informing that 192.168 .0.2 has MAC address 03: 03: 03: 03: 03

HOST 2: arp-reply reporting that 192.168.0.1 has MAC address 03: 03: 03: 03: 03: 03

This way we are "poisoning" arp caches. From now on the packages sent between us will reach us, but for both hosts not to notice anything strange, we must send the packages to their final destination. For this we must treat the packets we receive depending on the source host:

Packages from HOST 1 -----------------> forward to 02: 02: 02: 02: 02 : 02

Packages from HOST 2 -----------------> forward to 01: 01: 01: 01: 01: 01

In this way the communication between the two is not interrupted, and we can "see" all the traffic between them. We will only have to use a sniffer to be able to capture and filter the traffic between masters, be it telnet login, passwd, ftp, POP3, ..., or even the entire session. That already depends on the skill and interest of each.

As you can verify the process is not complicated, but what utilities we have available to be able to send the fake arp packages?

There are several programs to "play around" with arp-spoofing: Arptool, Arp-Fun, ettercap. This last one is very complete, since it allows several types of sniffeo: By IP, MAC and Arp-Spoofing. It can be executed well in command mode, or through a windows environment. In this environment we will be shown at the beginning a list of the hosts found in the LAN. To perform this search, the program sends an ARP-REQUEST of the IPs taking into account the IP of the host where it is running and the netmask. Obtaining ARP-REPLYs can then compose the list of hosts present in the network. Be very careful with the network mask that we use, because if it is class B (255.255.0.0) the program will perform 255 * 255 = 65025 ARP-REQUEST, which will take your time since the delay between each request is of 1 millisecond.

So far we have seen how ARP protocol vulnerabilities can be used to spy on our network. But the possibilities are multiple: DoS (Denial of Service) attacks, if we "poison" the arp cache of a machine by passing through the network gateway, all communication with the outside will pass through us. If we discard packets from this host and do not forward them to the gateway, the host will not be able to communicate with the outside. Some switches can be manipulated using ARP packets so that instead of acting in "bridging" mode they do so in "repeat" mode. That is to say, that instead of sending the packages by the appropriate "mouth or port" of the switch, will send them by all, to all the machines will arrive all the packages of the network. This is achieved by flooding the address table with lots of fake MAC addresses. The switch upon receiving a packet whose destination MAC address is not in its cache, will send it to all the computers, waiting for the response of the equipment to be able to store its MAC in the cache. But as we are "bombarded" with fake MAC addresses, this will not happen.

ARP-SPOOFING and redundant servers

ARP-SPOOFING not only serves as a tool for spying on a network or doing DoS attacks. It can also be used to create redundant servers, servers with fault tolerance. The idea is to create an auxiliary server that takes the identity of the server that has stopped working. For this we will use IP alias and ARP-SPOOFING. It is a quick and not very orthodox solution, but it can be useful if our budget is not very high.

In many cases it is vital redundancy in a certain service: HTTP, FTP, SMTP, POP .... Computers that allow redundancy in a service are usually quite expensive, so this method can solve the problem. The situation is the following:

We have a main server with two network interfaces (the second one will allow us to access the server when the backup is running) and a backup server also with two network cards (or you can use only one in the redundant and use IP Alias ??to have two IP addresses).

The backup server must be configured so that when it is activated (because the main one has suffered a problem and stops working) set up your network card with the IP of the main server to be replaced (either by configuring the single card with IP Alias or configuring a second card). The backup server will then use ARP SPOOFING to ensure that it receives all packets destined for the server it is replacing. The ARP packets to be sent will report that the MAC address corresponding to the IP of the primary server is now the MAC of the backup server. This shipment must occur continuously, while the main crash lasts, thus preventing arp caches from being refreshed with the real MAC address of the main server.

As we can see in the figure, if the backup server responds to the ARP REQUEST with its ARP REPLY before the main server, the ARP REPLY of the backup will be "crushed" with the main server. While on the contrary, it will be the ARP REPLY of the principal that will be replaced by that of the backup server. This should not happen, since otherwise the redundancy process would be useless.

Activation of the backup server should occur automatically, as these problems usually occur at dawn (not always clear) and it would be no use if we were the ones that had to manually activate it.

Using an NFS server for both computers would be the most convenient, since this way we can access the same content from both servers, an interesting solution for services such as HTTP, POP3, FTP ...

The main thing is already explained, now alone you have to make use of your imagination. In the bibliography you will find some articles on which I have based myself to write this article and that surely also can help you. Now you just have to read and practice. But remember one thing: "DO NOT BREAK ANYTHING".

greetings/

//mohamed

terminsilly vilar