Monday, October 17, 2016

WI-FI PT / 4 - ATTACKS MAN-IN-THE-MIDDLE / 4.4 - Stealing username/passwords with SSL (Secure Socket Layer) MITM attack

4.4 - Stealing username / passwords with SSL MITM attack

- SSL MITM is one the most common exploitation attack. It requires that the attacker "kali""places himself in the middle of the communication between the victim "roch" and another destination host, for instance the legitimate AP. The prevalent technique used in this attack is the ARP cache poisoning traffic, or ARP spoofing, although other techniques like DNS spoofing can be also very effective. Using a Honeypot, once the victim is connected, the attacker has full control of the Internet traffic sent and received by the victim. Because this attack uses ARP spoofed techniques, it can be considered that happens at Layer 2. The attacker "kali" acts as a delegated proxy of the victim regarding the Internet, because it handles the ARP protocol, DNS request and responses, and data sent and received from outside the local network.

- For the purpose of demonstrating this and following practices, a test Outlook e-mail acount has been created, whose features are:

         e-mail account =
         password = passwordPFM

- Before starting the attack, let's check that a user connects from "roch" to Outlook with HTTPS (HTTP Secure working on top of the SSL/TLS protocol). The browser shows a padlock, writting the beginning of the URL in green, meaning that the visited website is the real one:

- Also, it can be checked that "roch" ( holds a correct ARP table, associating the default gateway AP's IP with its real MAC address 00:25:F2:9B:91:22

- Now, let's prepare the "kali" machine for the attack. First of all, "kali" needs to be able of routing packets that arrive to it. For that purpose, ip_forward must be set to 1:

- Also, the firewall iptables must ensure that packets arriving to port 80 are redirected to port 10000 (used by default by the tool sslstrip):

- The tool sslstrip acts as the proxy between "roch" and "kali", and it can be found at: Kali Linux -> Sniffing/Spoofing -> Network Spoofing:

- Then, sslstrip is launched:

- Next step will be to use arspoof. With ARP spoofing technique the attacker "kali" sends fake ARP messages, associating its MAC address with the IP address of the legitimate AP default gateway, redirecting any traffic meant for the legitimate AP to be sent to "kali" instead. In this way, "kali" can intercept, stop or even modify the traffic. In other words, the tool arpspoof convinces "roch" that "kali"s MAC address is the legitimate AP's MAC address. The kernel forwards everything except for traffic destined to port 80, which it is redirected to a listening port like 10000 (as allowed before with Iptables). Actually, this attack can be used as a starting point for other attacks, like DoS, session hijacking or MITM. arpspoof takes this options:

- i = interface used to send fake ARP messaages
- t = target or victim, in this case "roch" which IP is, and the legitimate AP

- From the debug messages created by arpspoof, it can be read that the AP gateway has got an IP address associated to MAC address 08:00:27:EA:E9:D0, what obvioulsy is not true:

- However it is not true, the victim "roch" believes the whole deception, adding to its ARP table the fake IP-MAC association:

- As a result of the spoofed ARP table, whenever "roch" wants to send a packet to the legitimate AP, it will be actually sent to "kali", whose MAC address is 08:00:27:EA:E9:D0.

- Now, when "roch" tries to connect with Outlook, there is no padlock, and the URL is neither HTTPS nor green anymore, because who is responding to the HTTP request is actually "kali", not using any certificate to prove that communication with the website is secured. An unaware users would not notice that detail:

- Let's focus on the detailed URL after the attack authentication is done:

- Comparing it with the previous one (before the attack was launched):

- Using the command tail to detect what's happening at the file sslstrip.log, it can be verified that the account name ( and the password (passwordPFM) have been successfully captured by sslstrip:

- Also, let's see what happen if the administrator of "roch" wants to access the legitimate AP's Graphical User Interface, writng at the browser:

- Again, username (admin) and password (Ab12345) are captured by sslstrip:

- Once the attack has been successfully performed, it is important for the attacker to cover tracks. For that reason, as soon as possible, once the desired info has been captured, arpspoof must be stopped in order to the fake ARP table could not be detected. It is funny that when arpspoof is stopped, there is a message telling that everything is being cleaned, and targets are recovering their correct ARP tables: "cleaning up and re-arping targets":