Terms of Use For FixedByVonnie

By proceeding to access fixedByVonnie.com, you expressly acknowledge, and agree to, all of the following:

fixedByVonnie.com is a personal website and blog owned by Security Plus Pro LLC, which is being presented for informational purposes only. The views on this website are solely those of the website owner (and not those of any employer or of any professional associations affiliated with the website owner).  Any views expressed in this website and any information presented on this website, or in any of its blog entries, should not be relied on for any purpose whatsoever other than as the personal opinions of the website owner.  The website owner expressly disclaims any and all liability for any information presented on this site.  The owner of this website and its blog posts shall not be held liable, and shall be held harmless, for any errors or omissions in any information or representations contained in this website, or in any of its blog entries.  The website owner also expressly disclaims any liability for the current or future availability of any such information. The website owner makes no representations as to the accuracy or completeness of any information on this website or which may be found by following any link on this website. The website owner shall not be held liable for any losses, injuries, damages, claims, or causes of action, from the display or use of any information on this website or in any of its blog entries. If you use the information on this website, or on any of its blog entries, you do so solely at your own risk.

Wireshark 301: Spying on what people are downloading (Part 2 of 2) - fixedByVonnie

Wireshark 301: Spying on what people are downloading (Part 2 of 2)

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:

Telnet Passwords

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.

Encrypted TLS/SSL traffic in Wireshark

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.

SSL Preferences

Click New

SSL Decrypt Profile

And browse to the private key file.

 

Fake Twitter SSL private keyd

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!

About

Connect with Vonnie on Twitter

Posted in Linux, Mac OS X 10.10 Yosemite, Mac OS X 10.8 Mountain Lion, Mac OS X 10.9 Mavericks, Windows, Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Vista, Windows XP Tagged with: , , , ,
  • Ed Force

    Vonnie,

    This is scary stuff, so what can I do to prevent someone doing this to me? I think most people would like to know more about ways to protect themselves from being spied or hacked.

    • Axl Ghanim

      yes I’m with you on that.