Wireshark is a great tool to capture network packets, and we all know that people use the network to login to websites like Facebook, Twitter or Amazon. So there must be passwords or other authorization data being transported in those packets, and here’s how to get them.
Capturing interesting network packets
The first thing you need to do is to capture the network packets that contain the passwords (or other credential types, but let’s say we’re focusing on passwords for now). Capturing network packets in general is easy – you can do it on almost any PC where you’ve got administrative rights. “Normal” user rights aren’t enough in most cases, because you need to enable Promiscuous Mode on the network card to be able to capture packets that are not send to your PC. This may sound complicated, but it basically works like this:
- All the packets on the network that actually arrive at your PCs (or Mac) will be inspected to check if they have a destination that matches the network card
- if the destination address is a match, the packets will be passed up to the CPU and processed
- if the destination address in the packet does not match the address of the network card the packets will simply be ignored
Take a good look at number 3 – this means that if your network card sees packets that are sent from other PCs to other servers (without your PC being involved at all), your card will not even really look at them except to find out that it doesn’t care. So if you want to grab stuff that others are sending to each other, you’ve got a problem.
Now, if you want to tell your network card “hey, accept everything! Forget the destination thing filtering, I want it all!” you need to enable a special mode on the network card. That mode is called “Promiscuous Mode”, and Wireshark does it by default:
By the way, if you’re capturing on a wireless card, you’ll need “Monitor Mode” enabled as well, or you’ll not see packets with their radio information. This is something you can’t do on Windows with Wireshark except if using AirPCAP adapters. Monitor Mode is basically turning your WiFi card into a “receive only” listening device for radio waves (which also means you cannot use it to communicate with the network while it’s in that mode), and is required to see packets from and to other devices.
Now, if you’re running Wireshark in promiscuous mode on an Ethernet card, you might wonder why you’re still not seeing packets of other PCs talking to the internet. The reason for this is that PCs are connected to network devices called “switches”. And switches do one thing that makes it almost impossible to have packets on the cable to your network card that do not need to be there: they forward packets only to the port where the receiver is, and the capture will never see any of it. Which looks like this:
So, again, you can’t capture what you wanted, even with promiscuous mode enabled on your card. Simply because the packets do not even make it to your network card at all. So how can you get the packets? Is there a “promiscuous mode” you can enable on the switch? Sort of. It’s called a SPAN port (“Switch Port ANalyzer”) using Mirror and Monitor ports, which was initially designed to debug the switch itself, but can be used to grab network packets you want. What it does is to have the switch make copy of packets you want from one port (“Mirror”), and send them to the port (“Monitor”) where your Wireshark/Sniffer is running:
To tell the switch you want a SPAN session with mirror and monitor ports, you need to configure it, e.g. like this on some Cisco devices:
Switch(config)#monitor session 1 source interface gigabitEthernet 1/3 both Switch(config)#monitor session 1 destination interface gigabitEthernet 1/24
This tells the switch to send everything coming in and out of port 3 to port 24. Now, to be able to configure a switch like this, you need
- a switch that can be configured (meaning, “dumb” cheap switches without a console or web interface are no good; this includes almost all embedded switches you find in DSL or cable routers that have more than one port)
- administrator/root access to the switch
It comes down to this: if you don’t have both requirements in place, you can’t capture packets of others, just your own. The only exception is using ARP spoofing or other attacking techniques – which, you may have guessed it, are most likely illegal unless you’re authorized to use them on a test network.
The real big question
Now, the real big question is often something like this: “how can I capture packets from someone on another network than my own?”. So let’s say you’re at home, running Wireshark on your computer, and you want to capture packets of a friend sitting in his own home, at his own computer. This is like trying to read a postcard she or he is sending via snail mail – you need to be at the right spot at the right time to see it pass you by, or you can’t read it (this should be obvious). It’s the same with network packets on a remote network – you need to get physical access to the path of the packets, or you can’t capture any of them. So if you want to capture packets with someone’s Facebook password in it, you need to either be
- physically connected to the network they’re using, e.g. when it’s also your own home or work network and you’re spying on your family or on coworkers
- physically connected to the Facebook network (which, unless you’re working for Facebook, is not going to happen. And if you are, you don’t need to capture packets for this kind of thing I guess – just steal the credentials from database or whatever they use)
- physically connected to any network in between those two (have you ever tried to get into a data center where nobody knows you? Yeah, that won’t happen).
So basically, it’s highly unlikely you will get access to their packets if they’re not on your network. And even if they are on the right network, you need administrative access to the switches. Which (sadly) is not completely impossible because many of them still run with default credentials, so they’re easily hijacked.
Finding the passwords
Let’s say we somehow managed to get the packets we wanted, and they do contain the passwords we want. Which means that one of three things is the case:
- the network protocol transporting the packets is unencrypted
- the network protocol is encrypted, and we do not have the encryption keys
- the network protocol is encrypted, but we have the encryption keys
In the first case, things are simple – load the captured packets into Wireshark and look through all packets to find passwords, e.g. by using “Follow TCP stream” from the popup menu on a FTP connection:
Which will show a new window like this, with the password easily readable, because that function extracts all readable characters as a text output:
Okay, now if you’re looking at the traffic generated when logging into a web site you’ll most likely end up staring at a HTTPS connection, meaning that it was encrypted using SSL or TLS. If that is the case, your options are either giving up (because let’s face it, you’re not going to break that encryption without the keys, at least not anytime soon), or you get access to the encryption keys. Again, there are two options here:
- Decrypt traffic with the “Session Keys log” file
- Decrypt traffic with the private key of the web server
Option 1: Session Keys Log file
You can decrypt HTTPS traffic in a quite simple way by using the Session Keys log file written by Firefox or other browsers. For that, the browser needs to be configured to dump those encryption keys to a log file, and you need to get that log file. And, to clarify: I’m talking about the web browser of the person you want to steal the password from. Now, if you’re talking about decrypting your own HTTPS traffic, that strategy will work, e.g. following this tutorial.
If you’re trying to decrypt HTTPS traffic of other users without valid access to their computers, it won’t work. You’d have to steal their session key file from their hard drive (which is illegal, by the way) after reconfiguring their web browser to store the encryption keys to disk in the first place (unless they did that themselves, which is highly unlikely, and if they are, they’re probably better at network captures than you are, so better run and hide), and then somehow grab their traffic at a location you should most likely not have access to.
TL;DR: if you try to decrypt HTTPS sessions of other users, the session key log file method won’t work for you.
Option 2: Private Key of the Web Server
The other option requires you to have access to the private key of the web server, which allows you to decrypt all connections to that server. Most security professionals reading the last sentence will now mutter something under their breath along the lines of “yeah, like THAT’S going to happen…” or “good luck with that…”.
Just to give you an idea how likely it is for you to get a hold on the private SSL/TLS encryption keys to the Facebook servers let me ask you one thing: can you get a copy of the original recipe for Coca Cola? No? Why not? Right – for the same reason why you won’t get the private crypto keys from Facebook. They just don’t want anyone to be able to decrypt ALL the traffic except for the parties involved, just like Coca Cola doesn’t want you to have their most valuable secret.
In one case I literally had to have a written order from the company’s CEO before the server admins of that company would hand over the private keys, and only handed over personally via encrypted USB stick, never via email. And this was for a network forensics job where I was authorized to decrypt the packets for investigative reasons.
And now for the real bad news – thanks to Tom for pointing it out to me, as I was too lazy to go into this at the time I wrote this post: Wireshark can only decrypt the packets if the key exchange used the RSA method, not DH, since DH key exchanges uses a randomly created public/private key pair to encrypt the session key in the ClientKeyExchange handshake message. Elliptic curve stuff and Perfect Forward Secrecy is a deal breaker, too, so doing this gets harder every day, because thanks to the Snowden leaks everyone is beefing up their encryption:
We stress that point in our Wireshark trainings: >75% srv/clients now prefer PFS (DHE & ECDHE key exch.) pic.twitter.com/8YmfOOp45s
— Debookee (@debookee) August 4, 2016
TL;DR: You’re not going to decrypt HTTPS to Facebook, Amazon, Twitter, or anyone else using strong crypto correctly when you can’t use the first method.
If you’re disappointed by now I can totally understand. You can’t get easy access to packets of other users, and you can’t decrypt the sessions that hold the things you want to see most. If at all, you can only look at unencrypted stuff, and only on networks you have administrative access to. Which, let me remind you, is a good thing – it makes sure that it’s hard for others to read your private stuff, too. Or steal your logins. So if you have a valid reason to get those packets, you still can – capture at the right location, get the encryption keys, and go ahead reading the clear text in Wireshark.
It’s funny how often the password “reading” question is asked in forums like the Wireshark Q&A site or on Twitter, mostly by people who have never really used Wireshark (or any other Sniffer / packet analysis tool) before. And there are many articles out there that pretend to tell you how to do it, mostly being simple click-bait. They never really tell you what you’re up against, and I don’t like to see that kind of thing – it’s like pretending to teach something and then not keeping the promise. So this blog post was written like click-bait in the beginning on purpose – get attention, but then keep the promise, even if it tells you “most likely, you can’t, and why” 😉
By the way, some final statistics: you’re not the only one interested in stealing passwords – 7 out of 10 search queries leading to my blog end up at this exact post.