In the previous guide on spying on captured packets, I showed you to eavesdrop on the photos and movies people are downloading on the network. In this guide we’re going to step it up a notch and only see the password a user entered but also decrypted an encrypted traffic stream.
Always make sure you have the authority to launch the attacks I’m going to show you. It’s not worth getting fired or embarrassed; ask before you hack.
And with that: let the bedlam begin!
Capturing cleartext passwords
I’m about to show you proof why no one should ever use Telnet to login to an appliance.
The Achilles Heel of Telnet is that all data is transmitted in the clear. Nothing is encrypted so anyone sniffing the wire can capture anything sent over the link.
Let’s say your boss comes to your desk and says he’s going to log into the router to check something and he’ll be right back. So you quickly run back to your desk, fire up Wireshark and start capturing data. This is obviously a bone headed thing to do and is worthy of an instant firing but I want to demonstrate how easy it is to capture data.
The real probably here is not only that you can capture his password but since most users share passwords across multiple sites you know have a password you can try on all his other commonly access resources like his email account, domain account and even bank account. This is why you should always always always login to routers using SSH because the entire communication path is encrypted end-to-end. If someone captures that data it’ll just show up scrambled.
Right click the data you capture and choose Follow TCP stream.
Lookie here:
There goes the telnet password and even the commands the user entered in the Cisco IOS.
This is nuts. It’s also proof that using a long memorable password isn’t enough. It doesn’t matter if you’re not using the crappiest password in the world, if your attack can capture passwords in the clear – you’re done.
Decrypting Encrypted Passwords in Wireshark
Normally if you capture encrypted traffic it looks like trash. It’s completely unintelligible.
Here’s what happens when I follow a SSL/TLS TCP stream while logging into my Twitter account.
So how could an attacker view the encrypted TCP stream?
He would need the private key of source!
Without the private key file, brute-forcing SSL/TLS encryption is futile.
This is why it’s super important the protect the private key (which probably resides on Twitter’s servers).
But let’s say I’m an unscrupulous Linux System Administrator at Twitter and I feel like sabotaging my career. The first thing I could do is copy ~/.ssh/id_rsa to my local computer. id_rsa is the private key file and by default Linux stores it in a hidden folder named ssh. (the dot prefix means the folder is hidden)
Here’s how to the unethical administrator could pull this off:
Press Ctrl + Shift + p in Wireshark to open the Preferences. Then, expand the Protocols option in the left pane and type ssl.
Click the Edit… button next to RSA keys list: in the right pane.
Click New
And browse to the private key file.
d
Then when you Follow the TCP stream everything will appear in plaintext. I can’t show you that part though because this is a fake private key I cooked up for this tutorial but this is how someone could view encrypted traffic in Wireshark.
The Bottom Line
Is WireShark cool or what? If you have any Wireshark tricks that I failed to mention please share in the comments below!
Connect with Vonnie on Twitter
