Sniffing Ethernet
by Veghead
It is incredible to think that as I sit here typing this document, my keystrokes are being broadcast to every other machine in the college over the Ethernet. Likewise, everyone else's keystrokes are being sent to my machine - students and super-user alike. With some very simple bits of software, you can see all of this valuable stuff.
Packet sniffing is certainly not a new concept; it's probably been around for as long as there were packets to sniff. This is how it works: Any information sent over an Ethernet LAN is broken into small bundles of data - called packets. Each Ethernet packet also contains the address of its sender and the address of the person it's intended for. Every Ethernet card in the world has a unique address that is six octets (bytes) long. Normally these cards sit on the network listening to its activity; every time a packet arrives, it checks to see if the destination address of the packet is the same as its address, and if so, passes it onto any driver software. If not, it obediently ignores it.
Now comes the fun bit. You can shove the Ethernet card into what is known as "promiscuous mode," from which point on all packets will be made available to the driver software - no matter who they are intended for. This will include packets of all descriptions - Telnet sessions, logins, admin packets, you name it. With the right software you can look at these packets and become educated in many things that you're not supposed to know.
All you need in order to do this is a PC with an Ethernet card, some sniffer software, and an Ethernet. The lovely people at FTP Software, Inc. have devised a standard known as "the packet driver specification" - an easy to understand, uniform way to use a network card. Even better than that, if you Gopher or FTP to ftp.ftp.com you will find binary file packet drivers for a wide variety of network cards. Look out for two files called UTILITY.EXE and SOURCE.EXE as well. These are self-extracting archives and are full of goodies.
UTILITY.EXE contains one program called PKTALL.COM. This is a simple and effective packet sniffer.
To get started, install a packet driver on your PC. There are plenty of READMEs at ftp.com about how to do this. (You will need to specify an interrupt number. If in any doubt, use 0x60. Also, if you choose to use the NDIS driver, I've found you get better results with no other protocols being bound to the MAC - if this is all double-dutch, then forget you read it.)
Next step is to run the sniffer software. A command like:
assumes that your packet driver is on interrupt 0x60 - the -v switch means verbose, and the -p switch puts the network card into promiscuous mode.
This will start displaying hex dumps of all packets flowing along the cable and will send them to a file called: sniff
After letting it run for a few minutes, press any key and it will stop and return you to DOS. You can now inspect contents of each packet with any text editor or text reader.
See below for an example of what you might find in the sniffage.
The sidebar shows what some of the numbers in this packet mean.
Offset from Start of Packet [Hex Bytes] 00-05 Destination Ethernet Address [00:40:10:02:19:B5] 06-0B Source Ethernet Address [00:00:8E:06:0C:19] 0C-0D Type [0800] (Means this packet contains an Internet datagram) 0E Lower-Nibble - IP Header Length [45] (In 32-bit words) 17 IP Protocol [06] (0x06 means that this is a TCP packet) 1A-1D Source IP Address [158.223.1.1] 1E-21 Destination IP Address [158.223.11.30] Offset from Start of TCP Header (In this case, total offset 0x0022) 00-01 TCP Source Port Number [17] (0x17 = decimal 23, a Telnet session) 02-03 TCP Destination Port Number [0521] 0C Upper-Nibble - TCP Header Length [05] (In 32-bit words) 15+ Data [56656768656164205B315D2024] (This is my UNIX ksh prompt)These offsets can vary slightly depending on the size of each header. A full description can be found in the RFCs (available from ds.internic.net) if you can be bothered to plow through them.
I decided to write a program that would filter out all the unnecessary crap and display the contents of telnet sessions. The program ended up being called TNT (TelNet Tapper) and takes an IP number as its command line argument. It will sit on the network in promiscuous mode and look for any packets with the IP destination/source fields the same as the one you specified. When one arrives, it simply dumps the contents of the data field to the screen. (In fact, it separates data going from port 23 from that going to 23 and displays them in different parts of the screen. Just so you can distinguish between what the host and the user are saying.)
The upshot of this is that typing TNT 158.223.11.30 will display a pretty accurate replica on your screen of any Telnet sessions going to/from 158.223.11.30 including any passwords that aren't normally echoed.
This is a very simple example. It's also a very simple program. Yet it can let you snoop in on whatever anyone is doing on your local subnet. (I get terrible twinges of paranoia whenever I'm doing anything slightly dodgy on our network ever since I wrote this - I wonder why?)
But with control over any network card, receiving is only half the fun. You can make it transmit anything you like - that includes false Ethernet/IP addresses, ARP replies... your imagination is the limit. Malicious programmers could quite easily adapt TNT to actually break TCP pipes by sending "KILLS" pretending to be one half of the connection. Spoofing any protocol could not be easier.
Recently, hackers were in the news after gaining root access using a technique referred to as "IP spoofing." Sound familiar? Regular readers of 2600 will remember the hacker who set up a UNIX sniffer listening to the network interface of a .net host (the source code was published in Phrack, Issue #46).
As I said before, it's not a new idea. It's not a complicated idea. Yet many installations seem to be turning a blind eye to it. There have been attempts to make certain protocols more secure, such as "secure-NFS," but I have no doubt that if any of these protocols were ever to make it big, it would only be a matter of time before someone is kind enough to publish an article in 2600 explaining it.