This concludes parts 1, 2 and 3 of our Sniffing Networks series. This part is a little less technical, but I still recommend that you be familiar with the first three parts.

In part 3 of our series, I showed you how to use Wireshark to sniff traffic and hopefully gather some passwords. It’s a lot of digging through a haystack to find a needle. It works, and if you know some of the protocols, you can search for keywords to help you. But if you’re just lazy, there are two excellent tools for just passwords: dsniff on Unix, and Cain & Abel on Windows.

Both tools do a little bit more than sniffing and support things like ARP spoofing and man-in-the-middle attacks. dsniff is old and not updated much any more, but it’ll pick up clear text passwords quite well. Cain & Abel is kept fairly up-to-date. However, both only deal with protocol specific passwords. So you’re not going to sniff any webpage passwords through them. You’ll still have to look for those passwords manually.

Cain & Abel is a whole lot more than just a sniffer; I suggest you play with it. However, what we’re concerned about is the sniffing capabilities. If you select the sniffer tab at the top, and the passwords tab at the bottom, then click on the “Start Sniffer” button near the top, you will see any protocol passwords it can see. In the screenshot, I had to force a cleartext password to go across the wire, as almost everything on our network is encrypted. I logged into an FTP server anonymously. Cain & Abel picked that up.

Cain & Abel

As you can see down the left side, there are a few types of passwords that can be picked up.

Dsniff is all command line, and doesn’t pick up as many protocols, but it works for most of them. In the screenshot, I used the -d option, but it’s not necessary.

Dsniff

You can see that it can be pretty easy to sniff cleartext passwords, so don’t use them!

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

This continues part 1 and 2 of our Sniffing Networks series. This part is a little bit more technical, and a solid understanding of the concepts in Part 1 and Part 2 of this series is recommended.

Now that you have the concept of ARP spoofing down and how MAC addresses translate to IP addresses, you can actually start sniffing. There are many tools that will do all of this for you, but we’ll get to those in a later part. I feel that it’s essential that you understand what those tools are doing before you use them. Instead we’ll use Wireshark (Ethereal) to look at raw packets to understand what we’re actually seeing on the wire. First things first, if you don’t already have Wireshark installed, go get it. It’s available for Windows, OS X and most flavors of Unix (the GUI runs under X11, so you might need to set that up). Also, you’re going to see more interesting things if you have a *wired* Ethernet connection rather than a wireless one.

Start up Wireshark. Make sure you’re not running VMware/Parallels/etc. If you’re running under OS X look here for how you can see any interfaces). First, make sure you have some interfaces to sniff on. Go to Capture->Interfaces.

You’ll see a list of all interfaces on your system. In my case, en0 is my wired Ethernet (and the primary network connection for this machine). Go ahead and click on “Start” to start sniffing on this interface. Suddenly the main window will fill with all kinds of stuff, so what the heck is it? (Feel free to click Stop at any time)

This screenshot is from our office network, so you’re not likely to find any clear text passwords in it (unless the protocol doesn’t support non-clear text passwords). You’ll see quite a few ARP requests at the beginning, as several machines are looking for the .30 computer (which is our domain controller). The main window shows all of the packets that were captured in a terse format. The bottom sections show the raw packet (in hex), and for each type of packet Wireshark knows about, it’ll break down the packet for you in easy to read chunks. The following screenshot is with the ARP packet detailed information expanded. Since we talked about it last time, it might make the most sense to you if you haven’t seen other types of packets.

The ARP packet is from a printer to the broadcast Ethernet address (ff:ff:ff:ff:ff:ff) asking about 192.168.1.143. You can view the Ethernet packet “wrapper”, and then the actual ARP request which is using IP. Later on in the stream, you should see a response to this packet. Unless you’re debugging the network or verifying that any packets you sent out did in fact make it on the network, most people ignore ARP requests and the TCP/IP headers for packets. What you’re interested in is the content of those TCP packets. Wireshark shows these too!

This screenshot shows some HTTP traffic. IP address 72.233.107.118 sent to 192.168.1.145 an HTTP response of 200 and then sent some JavaScript code. Now, once you’re at this level, you will need to be familiar with all of the protocols you want to understand. HTTP is an important one. You might want to also consider learning about AOL’s AIM protocol (they don’t encrypt passwords), POP, and IMAP. Those are the ones likely to net you some passwords in the clear.

The last feature of Wireshark that merits a discussion is “Follow the HTTP stream.” TCP/IP packets are limited in size, so you might not get all of the request or response in one packet. Wireshark will “glue” them together for you. Select the request or response you want to follow, and then right click and “Follow TCP stream”. A new window will pop up that shows you what the full “conversation” was.

This is where you’re going to find passwords or other useful information (such as what a popular web application is on that network).

Stay tuned for part 4 where I’ll go over “easy” tools that just show you passwords, and you don’t have to think too much about what you’re sniffing.

Each Tuesday, Security Musings features a topic to help educate our readers about security. For more information about Gemini Security Solutions’ security education capabilities, contact us!

This entry continues where Sniffing Networks Part 1 left off. If you didn’t read it, as long as you understand how switches work and why we have MAC addresses, you’ll be able to understand this entry.

The physical wire may talk in MAC addresses, but when’s the last time you typed a MAC address into a browser location bar? (You haven’t, except by accident, and certainly not expecting to get anywhere with it.) Computers talk in IP addresses, not MAC addresses, so how does the switch know what port to send the packet on to if it’s only given the IP address? Address Resolution Protocol, or ARP. ARP is another table that lives in each router (and computer) to map IP addresses to MAC addresses. Not only does each switch and router have an ARP table, each computer does as well (since there can be multiple interfaces on a system). You can look at your ARP table by typing arp -a in most operating systems. Below, I’ve included screenshots of arp -a in OS X (on a fairly large network), and Windows (on a “private” VMware network).

OSX ARP table

Windows ARP

As you can see, the information is presented differently on each system, but the fundamental information is the same: IP address to MAC address mapping. The OSX screenshot has a lot of “ghost” entries because the network is more dynamic – the 192.168.0.0 network is the wireless interface (en2), and I had used the machine to provide “Internet sharing” over both of the Ethernet ports to a system that hadn’t yet had wireless configured on it. The “ghost” entries, where the (incomplete) is found are laptops that come and go on the network (and they just happen to be off at the moment). Once I reboot this machine, that table will be fairly empty. It will very quickly fill up with the gateway and DNS information, since that’s accessed almost immediately. And if it’s a windows network, it’ll start talking to all of the other machines and fill up pretty quickly. What does this mean for sniffing? This is how ARP spoofing is done.

In order for all of these tables to be built, ARP and RARP (Reverse ARP) packets are being sent over the network. When a machine needs to talk to another IP address, it has to find out what the MAC address is, so it sends out an ARP packet saying “who has IP address“. Someone (hopefully the legitimate machine), says “I have it”. If the machine is on another network, the router that knows how to get to that network will say “I have it” in place of that machine. The asking machine then dutifully stores that information for future use, so it can be polite and not shout to the network again. Some machines send what’s called a gratuitous ARP when they boot to let everyone else know they’re there – this happens a lot when a machine boots up, so that any old MAC addresses are flushed out of the cache of other machines on the network.

It’s the gratuitous ARP that sniffers take advantage of. They send out this unsolicited message that says, “Look! Here I am! This is my IP and MAC address.” All other machines dutifully update their ARP tables and start sending packets destined for that IP address to the attacker/sniffer. You can see where this leads.

How do you detect ARP spoofing? Watching the ARP table for changes is a start. Both arpwatch for Unix and Xarpv2 for Windows will notify you if an ARP table changes. However, there are legitimate uses for ARP spoofing. You know when you go to a hotel and you’re redirected to a login/payment page? That’s likely using ARP spoofing. So, your watcher would notify you, and it’d be a false alarm. ARP spoofing is also used in high availability computing so that one machine can “take over” for another when needed.

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

First, what is network sniffing? It’s listening to the bits on the wire (or in the air) that are sent between computer systems. Really, it’s all 1s and 0s that are sent in a particular format. That particular format is usually “Ethernet” or 802.3, but can also be 802.11 (wireless) or single/multi-mode fiber. There are ways of sniffing by “vampiring” the physical wires, but we’re going to start a step above that and assume you have a computer that can already connect to the network somehow.

A basic introduction to how 802.3 works would be useful, so here we go. Because of the way Ethernet works, the machines on the network have to take turns transmitting or their transmissions will interfere with each other. There’s one signal that is sent out first to see if the wire is clear. If it is, then that machine starts sending its data. If not, an exponential back off timer starts, and the machine asks again once that timer goes off. As long as the wire is shared, every single machine on that wire can hear what every other machine is sending. You now see how easy it is to listen in on other conversations Hubs and repeaters are considered part of the same physical wire. All they do is boost the signal and rebroadcast to all their other ports. Switches are one step above that and place a physical barrier between network segments. They don’t indiscriminately rebroadcast to all of their ports. They just re-broadcast to the one port that has the destination machine. How do they do that, as in how do they know what port to broadcast on? That’s where MAC addresses come in – Media Access Control. These addresses are (supposed to be) unique for every single network connected system manufactured. In practice – not so much, although it’s generally “good enough” – except when you ship an entire box full of Ethernet cards to a university, and they all have the exact same MAC address…

The MAC address is sent with every single packet that is sent on the wire. The switch remembers which ports have what MAC address (and so do a lot of machines). This is stored in a table on the switch – with a limited amount of memory. If the switch gets overloaded, it will tend to revert to hub operation – rebroadcasting to all ports. One packet at least will be broadcast to all ports until the switch knows what port a specific MAC address is on. In normal operation (i.e., not *trying* to break the switch) and with a properly planned network, the switch has enough memory to maintain the table for the number of ports it has (and the bandwidth it’s expected to provide). However, what if there is a hub connected to the switch? That means X more MAC addresses the switch has to remember above and beyond the number of ports that it has. There used to be a rule of thumb – never have more than 3 hubs/switches connected together. This was part of the reason. You’d see degraded network performance because the MAC table couldn’t keep up (it also had to do with the physical limitation on Ethernet cable lengths).

So, you now have a switch, and if you don’t happen to be on the port that the packets are being sent to, you can’t “hear” their communication. But, if you “break” the switch and make it revert to broadcasting to everyone, you can “hear” the traffic. Another way to “break” the switch is to keep telling the switch that you are the destination’s MAC address, and the switch will start rerouting everything to you instead. If you want to sniff something useful, you’d better be prepared to keep routing the traffic to the “real” machine (and not through the switch you just “broke”), or you won’t get very far.

Most of this applies to wireless networks as well, although they use a slightly different method of telling other systems that they want to transmit.

For anyone who wants to delve more in-depth on how Ethernet works, the Ethernet Wikipedia page has a good discussion, and any good college textbook on networking will discuss Ethernet and several other technologies as well.

Each Tuesday, Security Musings features a topic to help educate our readers about security. For more information about Gemini Security Solutions’ security education capabilities, contact us!