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 = pruebapfm@hotmail.com
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" (192.168.0.25) holds a
correct ARP table, associating the default gateway AP's IP
192.168.0.1 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
192.168.0.25, and the legitimate AP 192.168.0.1
- From
the debug messages created by arpspoof, it can be read that
the AP gateway has got an IP address 192.168.0.1 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 192.168.0.1, 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 (pruebapfm@hotmail.com) 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
192.168.0.1 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":
