ÜberhackerII, Chapter 9: Ethernet Exploration,
continued...
Arp Troubleshooting
Did arp -a not work? Did you get a "permission denied"
message? This means your sysadmin does not allow your account
to use that command. If you can operate from a Windows computer,
perhaps through a remote administration tool, you are much more
likely to discover the arp command is available to you, as well
as ping and tracert. On NT/2000/XP/2003 you normally will also
be able to use nslookup. Otherwise, if you make friends with your
sysadmin, you may be able to get him or her to allow you to use
arp and any other command in this book. Or set up your own LAN.
Another problem you may encounter is that some network devices
seem to ignore broadcast pings unless they get a lot of them.
My Irix 6.2 box ignored the first five of my network pings. Yet
I am able to upload many megabytes to it over the same Ethernet
connection from the same box from which I was running the broadcast.
According to Vincent Larsen, it's because ping is a UDP protocol
rather than TCP. UDP is not guaranteed delivery, whereas TCP keeps
on sending the same packet until the recipient device acknowledges
it was received. That means you may uncover more NICs if you broadcast
more pings.
In case you are wondering, in the case above, why did I get so
many more computers in the arp table than replied to my broadcast
ping? Klemencic says, "Your ping program only sent out 5
requests, and accepted only 5 replies, even though every host
on the network replied. Remember that ARP will record the MAC
address of any computer who talked to you, and since you pinged
a broadcast address, every computer replied, and your computer
recorded their MAC addresses even though your ping program only
accepted replies from 5 of them. This is the difference between
a Layer 2 application and a Layer 3+ application. The ping program
works above Layer 2 and was instructed to only display the output
from 5 replies."
Why Are Arp Tables So Useful?
According to the information we get from the man arp command in
Sun OS, "The arp program displays and modifies the Internet-to-Ethernet
address translation tables used by the address resolution protocol
(arp)." When we use the -a switch, it will "Display
all of the current ARP entries by reading the table from the file
kmem (default /dev/kmem) based on the kernel file vmunix (default
/vmunix)."
According to man arp on my Linux computer, "Arp manipulates
the kernel's ARP cache in various ways. The primary options are
clearing an address mapping entry and manually setting up one.
For debugging purposes, the arp program also allows a complete
dump of the ARP cache."
An arp table (or cache) will show all the computers, printers,
portmasters, and anything else that has an Ethernet device that
has been active on a network. It will even show devices that at
least at the time of your broadcast will not respond directly
to your own ping, yet nevertheless are in your computer's arp
table. For example:
~> ping bofh.foosite.org
PING bofh.foosite.org (198.59.999.251): 56 data bytes
^C
--- bofh.foosite.org ping statistics ---
51 packets transmitted, 0 packets received, 100% packet loss
Notice that bofh doesn't answer my pings. Looks like it's down,
huh? Ah, but it showed up in the arp table! I just found a live
computer on this LAN that someone was trying to hide.
That bofh box is an example of why the network ping technique
won't reveal all devices connected to the Ethernet of a LAN. There
are ways to hide a box on a LAN from the arp table. One way is
to prevent them from responding to broadcast messages. This is
a good security practice.
MAC Addresses and OUI Databases
Now, let's look in detail at what we see in an arp table.
The numbers shown on the arp table such as 8:0:20:1a:55:88 designate
the MAC (media access control) addresses of Ethernet devices.
These could belong to computers that have their Ethernet interfaces
built into them, Ethernet cards, even printers or portmasters.
Everything that is connected to an Ethernet will have one of these
numbers. These are hexadecimal numbers (a=10, b=11, c=12, d=13,
e=14, f=15) and are known as "Organizationally Unique Identifiers"
(OUI).
The first portion of this number identifies its manufacturer.
For example, anything that starts with 8:0:20 is a Sun device
of some sort. In the example above we see eight Sun devices. The
second half of this number is used by that manufacturer to create
a unique address for each of its Ethernet interface products.
So how can we use these Ethernet numbers to find out what hardware
they represent?
There are a number of OUI databases on the Web. Just do a search
for "OUI" and "Ethernet." For a complete list
of what company each number corresponds to, send email to info.stds.oui@ieee.org.
A partial listing is at http://standards.ieee.org/regauth/oui/oui.txt.
This is a Web site of the IEEE, which assigns these numbers. For
the rest of this information, contact the responsible vendor.
A rather large collection of the IEEE assigned MAC vendor codes
and related technical information may be found at http://www.cavebear.com/CaveBear/Ethernet.
Each site has some material that the other lacks, so it is well
worth checking out both.
Stuart Carter had uncovered some problems with using OUI databases.
"This method doesn't seem to yield good results for me. Maybe
the chipset is different from the manufacturer, but only one result
out of around 6 looked likely as the correct vendor of the card.
Is it common to get these values messed up? Do smaller manufacturers
invent their own values?"
From this information you can often tell what kind of devices
are on the victim LAN. You may discover a MAC address that corresponds
to a built-in interface on a SPARC or SGI computer, or a network
printer. You may discover a "WinNIC" which only runs
on a Windows 95/98/ME computer.
Can you get MAC addresses from across the Internet? You can if
the victim network is using NetBIOS over TCP/IP and lets this
info out to the Internet. This is yet another reason to block
NetBIOS protocol from being routed into the Internet.
Sniffers
If you have root or administrative control over a computer on
your target LAN, you can do much more. You can run a sniffer,
which intercepts all network traffic and lays it out for your
analysis.
You need root or admin control because to run a sniffer you must
set up an Ethernet interface in promiscuous mode. This means it
will look at every packet that traveled on the cable to which
it is attached. Otherwise, an Ethernet interface will only look
at packets addressed to itself.
There are excellent sniffers that run on Windows, Macs (especially
OS X) and Unix-type computers. You will find many on the enclosed
CD.
Conclusion
You now have the tools you need to do some rather interesting
network hacking. How to leverage the knowledge you get from MAC
addresses and sniffing into breaking into computers is covered
in Chapter 18: Ethernet Hacking,
as well as in the chapters on breaking into Windows and Unix computers.
Further Reading
Switched, Fast, and Gigabit Ethernet, Third Edition, by
Robert Breyer and Sean Riley, Macmillan, 1999.
