CAIN and ABEL Tutorial 2

ARP Poison Routing
APR-HTTPS
APR
APR (ARP Poison Routing) is a main feature of the program. It enables sniffing on switched networks and the hijacking of IP traffic between hosts. The name “ARP Poison Routing” derives from the two steps needed to perform such unusual network sniffing: an ARP Poison Attack and routing packets to the correct destination.
ARP Poison Attack
This kind of attack is based on the manipulation of host’s ARP caches. On an Ethernet/IP network when two hosts want to communicate to each other they must know each others MAC addresses. The source host looks at its ARP table to see if there is a MAC address corresponding to the destination host IP address. If not, it broadcasts an ARP Request to the entire network asking the MAC of the destination host. Because this packet is sent in broadcast it will reach every host in a subnet however only the host with the IP address specified in the request will reply its MAC to the source host. On the contrary if the ARP-IP entry for the destination host is already present in the ARP cache of the source host, that entry will be used without generating ARP traffic.
Manipulating ARP caches of two hosts, it is possible to change the normal direction of traffic between them. This kind of traffic hijacking is the result of an ARP Poison attack and also a prerequisite to achieve a “Man-in-the-Middle” condition between victim hosts. The term Main-in-the-Middle refers to the fact that the traffic between hosts follows an obligated path through something before reaching the desired destination.
Re-Routing Packets
Now suppose that you successfully setup an ARP Poison attack between two hosts to intercept their network traffic. To do so you had specified the sniffer MAC address in ARP Poison packets and now you are forcing the two hosts to communicate through your computer.

In this situation the sniffer receives packets that are directed to its MAC address but not to its IP address so the protocol stack discards these packets causing a Denial of Service between the hosts. To avoid such problems the sniffer must be able to re-route poisoned packets to the correct destination. (You can’t capture any password if hosts cannot communicate)
Prerequisites
In order to re-route poisoned packets to the correct destination, the program must know each IP-MAC association of victim hosts. This is why the user is asked to scan for MAC addresses first.
Configuration
This feature needs the configuration of some parameters that can be set from the configuration dialog. It is possible to specify a spoofed MAC and IP addresses to be used in ARP Poison packets; this makes it very difficult to trace back to the origin of the attack because attacker’s real addresses are never sent across the network. On switched networks, the attack is also a stealth one from a central point of view because Cain’s APR uses Unicast Ethernet destination addresses in ARP Poison packets; these packets will be routed by switches accordingly to their CAM tables and never sent in broadcast.

Victim hosts can be selected from the APR Tab using the + button in the toolbar:
The meaning of this selection is: “I want to hijack all IP traffic that flows from host 192.168.0.1 and host 192.168.0.10 in each direction so that my workstation will be in a Man-in-the-Middle condition between them”. In this way the program is configured to perform an ARP Poison attack directed to the selected hosts and at the same time the association needed to re-route poisoned packets is created. Cain’s APR has been developed to handle attacks on multiple hosts at the same time so you can choose in the right list a pool of addresses.
The attack can now be enabled/disabled using the relative toolbar button;
APR Views
You can monitor the traffic activity from the two views under the APR sub TAB. The upper view (LAN View) shows the number of re-routed packets between poisoned hosts and also the routing direction of the packets. It can happen that for some reason (static ARP entries for example) the attack is successful for one host only; in this case you will see the number of re-routed packets rising for one direction only meaning that the sniffer is processing half of the traffic expected.
The lower view (WAN View) shows the number of re-routed packets directed to or coming from an IP address which is external to the current subnet. If one of the two hosts is a router it is possible that Cain’s APR will process WAN traffic too; in this case the lower list will be automatically populated with associations for WAN traffic.
When poisoning a router the following considerations arise:
- If you setup APR to hijack IP traffic between an internal host and its default gateway you will automatically intercept traffic from that host and all other hosts present in external networks connected by that gateway.
- When APR receives a packet originated from an internal host and directed to an IP address which is external to the current subnet it must re-route that packet to the correct gateway which is unknown.
The destination IP address present in the packet is the one of an external host and the destination Ethernet address is our sniffer MAC address….. the question arises as to where to re-route this packet if there are multiple exit point (gateways) in our LAN ? The packet could be sent in broadcast but this works only with routers, I checked that Checkpoint Firewalls for example discards packets directed to Unicast IP addresses encapsulated in frames with broadcast MAC addresses. when APR does not know where to re-route packets it will use the best route found in the local operating system’s route table.
If your LAN uses asymmetric routing you can modify the local route table using the Route Table Manager to avoid the above problem.
- Poisoning the subnet’s default gateway with all other hosts in the LAN can cause traffic bottlenecks because APR does not have the same performance of an high speed router.
- Default gateways addresses are usually virtual addresses generated by HSRP or VRRP routing protocols. Consider if you are poisoning a normal host and the default gateway virtual address…
In this case a packet originated outside the local network and directed to an internal host will reach the sniffer but this packet could contain the real MAC address of the active HSRP / VRRP host as Ethernet source address. Because this source MAC address is not the one you setup in the APR list, the packet will not be re-routed by APR causing DoS. When you want to poison HSRP / VRRP virtual addresses you have to poison also real addresses of HSRP/ VRRP members.
APR WAN Status

Each entry present in the WAN list can reach the following status:
- Broadcasting: This state means that APR received a packet from a host that resides on a different network and directed to an IP address of your broadcast domain. That packet must be routed by APR but the correct destination MAC address is not present in the host list. In this situation APR will broadcast that packet to all hosts in your LAN.
- Half-Routing: This state means that APR is routing the traffic correctly but only in one direction (ex: Client->Server or Server->Client). This can happen if one of the two hosts cannot be poisoned or if asymmetric routing is used on the LAN. In this state the sniffer looses all packets in an entire direction so it cannot grab authentications that use a challenge-response mechanism.
- Full-Routing: This state means that the IP traffic between two hosts has been completely hijacked and APR is working in FULL-DUPLEX. (e.g.: ServerClient). The sniffer will grab authentication information accordingly to the filters set.
APR-HTTPS enables the capture and the decryption of HTTPS traffic between hosts. It works in conjunction with Cain’s Certificate Collector to inject fake certificates into SSL sessions, previously hijacked by mean of APR. Using this trick it is possible to decrypt encrypted data before it arrives to the real destination performing a what so called Man-in-the-Middle attack.
Be warned that clients will notice this kind of attack because the server’s certificate file injected into the SSL session is a fake one and although it is very similar to the real one it is not signed by a trusted certification authority. When the victim client starts a new HTTPS session, his browser shows a pop-up dialog warning about the problem

APR-HTTPS uses the certificate files manipulated by the Certificate Collector. They contains the same parameters of the real ones except for asymmetric encryption keys; this deceives a lot of users to accept the server certificate and continue with the session.

The lower list in the APR-HTTPS tab contains all the session files that have been captured during the Man-in-the-Middle attack; decrypted data is saved in these text files located under the “HTTPS” subdirectory of the main installation folder

How it works
Cain’s HTTPS sniffer works in FULL-DUPLEX CLIENT-SIDE STEALTH mode; both server and client traffic is decrypted and if spoofing is enabled the attacker’s IP and MAC addresses are never exposed to the victim client. Connections are accepted by a local “acceptor” socket listening on HTTPS port defined in the configuration dialog; this socket handle hijacked client connections but only when APR is enabled. OpenSSL libraries are used to manage SSL communications over two more sockets, one used for the traffic between the client Cain and the other used for the traffic between Cain server.
This is how all works step by step:
1) The HTTPS filter is enabled by the user in the configuration dialog
2) APR is enabled by the user using the button on the toolbar -> the Man-in-the-Middle attack is ready
3) The victim client starts a new session to an HTTPS enabled server (e.g. https://xyz.com)
4) Packets from the client are hijacked by APR and captured by Cain’s sniffer by mean of Winpcap driver
5) APR-HTTPS search for a fake certificate associated to the requested server in the Certificate Collector; if present the certificate will be used if not it will be automatically downloaded, properly modified and stored locally for future usage .
6) Packets from the victim are modified so that they are re-directed to the local acceptor socket; modifications are made on MAC addresses, IP addresses and TCP source ports (Port Address Translation “PAT” is used to handle multiple connections). The data captured is then sent again into the network using Winpcap but it is this time addressed to the local socket that will accept the Client-side connection.
7) The Server-side socket is created and connected to the real server requested by the victim.
OpenSSL libraries are used to manage encryption on both sockets using the fake certificate victim-side and the real certificate sever-side.
9) Packets sent by the Client-side socket are modified again to reach the victim’s host.
10) Data coming from the server is decrypted, saved to session files, re-encrypted and sent to the victim host by mean of the Client-side socket.
11) Data coming from the client is decrypted, saved to session files, re-encrypted and sent to the server by mean of the Server-side socket.
Although it can be noticed from the fake certificate file used, this kind of attack is STEALTH from a client point of view because the victim thinks to be connected to the real server; try a “netstat -an” on the client to check yourself.
Once decrypted, traffic from the client is also sent to the HTTP sniffer filter for a further analysis on credentials. You can take a look at the data saved in session files by APR-HTTPS here.
Prerequisites
This feature needs APR to be enabled and a Man-in-the-Middle condition between the HTTPS server and the victim host.
Limitations
This feature does not work like a PROXY server; because of the usage of the Winpcap driver it cannot decrypt HTTPS sessions initiated from the local host.
Usage
After you successfully set up APR and enabled the HTTPS sniffer filter, sessions are automatically saved in the HTTPS subdirectory and can be viewed using the relative function within the list pop up menu.