Today I am going to show you how insecure our homes and certain enterprises LANs are. The basics of this issue is to perform a Man-In-The-Middle attack, just together with SSL sniffing, so we can just see every encrypted data packet between the origin and its destination. Please note that this is not any user manual for cracking purposes.
This is the scenario:
The left side of the network is my home LAN. As you can see my router/gateway (in this case a Comtrend HG-536+) connects my LAN with the Internet via my service provider (in this case Jazz Telecom).
I have two computers attached to the switch: the laptop is running BackTrack 5 R2 linux, while the PC is running Windows XP. The phone is an Android-based device, in this case a Samgung Galaxy S+ running Android 2.3 Gingerbread. Both Windows and Android are fully security-updated.
I have tested this method with both Windows and Android. I am using here Windows just to note that THIS IS NOT A WIRELESS WEAKNESS.
The user seated in front of the Windows PC is going to check his e-mail in GMail webpage. So the normal traffic flow is represented in this picture:
The communication starts with the usual three-way handshake of any TCP connection. First of all it takes place the SYN from PC to GMail, depicted in soft pink. Later, the SYN-ACK from Gmail to PC and at last the ACK from PC to Gmail. At this point, they both share the encrypted handshake and secure SSL communication starts. The strength of the algorithm lies in the basics of that only the PC and GMail are aware of their own SSL keys.
Here you can see the GMail login screen (in spanish) in Internet Explorer 8 fully up to date in normal use:
Since VeriSign is signing a valid certificate, Internet Explorer shows a padlock meaning that this is a trusted communication with GMail.
The same thing occurs with Firefox 10:
You can see that everything is working fine. Then we make a successful login without any trouble at all.
If the linux host cheats the PC and makes it think that it is actually the gateway, instead of the real router, then all the traffic flow changes from the above picture to this one:
The brown line represents the traffic flow from PC to laptop, and the green line represents the communication flow between the laptop and the mail server. As the attacker is just in the middle of the data communication, this kind of attack is called Man-In-The-Middle.
The laptop is not yet able to read any encrypted packet because it has not the keys yet. When the three-way-handshake ends and the SSL keys have been shared between PC and GMail, the attacker has both of them because it he has captured (or sniffed) all traffic.
At this point we can see every SSL encrypted data packet including, but not limited to, GMail username and password in plain text, received and sent e-mails, folders and many more. Imagine what happens if the PC user makes an online bank transfer or something similar.
“But what about SSL Certificates, Thawte, VerySign, etc.?”
This is a critical matter. The Man-In-The-Middle attacker is going to change the PC’s SSL key to its own SSL key. Therefore the encrypted communication takes place only between attacker and GMail and not between PC and laptop.
At this point we start our attack against the PC so we need to set up BackTrack to do it:
First we need to forward TCP traffic involving ports 80 and 443 from PC to Internet and vice-versa:
iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port <listenPort>iptables -t nat -A PREROUTING -p tcp –destination-port 443 -j REDIRECT –to-port<listenPort>echo 1 > /proc/sys/net/ipv4/ip_forward
In this case I am going to use the tcp port 9000 for both HTTP and HTTPS. Note that if we want to capture FTP, SMTP, POP3 or other services we need to add an iptables entry for each port.
Now we need to start sniffing ssl content at port tcp 9000 with a tool called sslstrip:
sslstrip -l 9000
Now we need to fake the MAC address table of both the PC and the router:
arpspoof -i eth0 -t 192.168.1.82 192.168.1.1arpspoof -i eth0 -t 192.168.1.1 192.168.1.82
where 192.168.1.82 is the PC IPv4 address and 192.168.1.1 is the real gateway router. Here you can see this part:
The PC user opens Firefox and types www.gmail.com:
Note that the address bar shows HTTP and not HTTPS (no padlock nor certificates).
The user now checks his e-mail normally and then he goes to see his Facebook account, this time using Internet Explorer (okay it’s not realistic to change the web browser for different surfing purposes but you know it’s for testing both browsers).
Note that when you click Entrar (Login in spanish) the address bar shows HTTP instead of HTTPS.
After his login in both sites, we check the sslstrip.log file:
I scroll the window bar through the right and I see both username and password in plain text.
Note that some ASCII characters (some symbols) are represented in hexadecimal.
We can also check the username and password in plain text captured during both login processes by Wireshark Network Protocol Analyzer
I saved the capture and opened it in other computer, so that’s why you can see that the Wireshark window buttons change their position (my laptop uses Debian Squeeze and not BackTrack).
So, without any doubt, privacy does not exist in the Internet but we can make some good practices:
Use a fast, secure and up to date web browser. Firefox it’s a good option to try because it has some add-ons that may enhance some security features.
Be aware of the address bar when you visit some websites like social, e-mail and banking and be sure that SSL is in use.
Secure your LAN. MAC-address-sticky command is a good way to start in Cisco switches but if you don’t have one of those (that’s my case), be sure that your wireless network is fully protected (Strong WPA2 keys, RADIUS if possible, no beacons, MAC filtering, etc.). The easiest way to access an incorrectly protected LAN is wirelessly, so pay attention to secure it properly.
Thanks for reading, see you next time.