What's New!

Chat with
Hackers

How to Defend
Your Computer 

The Guides
to (mostly) 
Harmless Hacking

Happy Hacker 
Digests (old stuff) 

Hacker Links 

Hacker
Wargames 

Meet the 
Happy Hacksters 

Help for 
Beginners 

Hacker 
Bookstore 

Humor 

It Sucks 
to Be Me!

How to Commit
Computer Crime (not)! 

What Is a 
Hacker, Anyhow? 

Have a 
Great Life! 

News from the 
Hacker War Front

... more Überhacker II, Chapter 18: Ethernet Hacking: Wireless and Wired LANs

What to Do after Getting on a LAN

Now for the really fun stuff: what to do once you are on a LAN, whether wired or wireless. It turns out there are many things you can do on a LAN that you can't do over a routed connection via the Internet.

ARP (Address Resolution Protocol) Spoofing

"You computer has crashed!" "Your computer has crashed!" Several hackers competing in the 1999 Def Con Capture the Flag contest were hollering to me, telling me that Happy Hacker contestant Fangz appeared to be dead.

Gonzo, Vincent "Evil Kernel" Larsen and I had entered Fangz in the Bastard Operator from Hell contest. The idea was for all the Bastards to try to withstand the Capture the Flag players. The Bastard with the most services still standing at the end of the game would win. (Or so Def Con owner Jeff Moss had promised. When we won, his goons evicted us instead. That's what we got for thinking that a full-time employee of NSA contractor Secure Computing, Inc. was running an honest game.)

I turned on Fangz' monitor and gave a few commands. "Fangz looks OK."

The players insisted that I look at what they were seeing across the Ethernet. When their computers tried to connect to Fangz, they were getting the message:

Unable to connect to remote host: Connection refused

This was a crucial problem. Fangz had to keep its services running to be able to win the game. I rebooted. Still nothing. Then the light bulb finally lit up in my brain. I checked Fangz' MAC address with the command ifconfig. I then looked at the MAC address for Fangz as it appeared on a player's ARP table. It was different.

Someone was spoofing Fangz' IP address. We finally tracked down the culprit: the firewall of the Swedish team. I batted my grandmotherly eyelashes at them and they agreed to spoof someone else instead.

Their trick was ARP spoofing, a man-in-the-middle type of attack. In this kind of attack a man (or grandmother or whoever) gets into the middle of a transmission and tricks a computer into thinking it has connected to its intended target while actually connecting with an attack computer.

In this case the Swedes tricked everyone's ARP tables into linking the Swedes' MAC address to Fangz' IP address. Here are some ways to do this.

The simplest ARP spoofing is to change the attack computer's IP address to that of the victim, and then run a denial of service attack on the computer you are spoofing to keep it from answering. That leaves all network traffic going to your attack computer instead of the victim of the same address.

Under Linux, you can change your IP address on the fly:

~>ifconfig eth0 10.0.0.2

This presumes your NIC is called eth0, it might be ne0 or something else. This is kind of fun to do remotely because your screen freezes as if your attack computer had just crashed.

Working from Windows NT, I just set my Linux attack box "Lady" to 10.0.0.2, which is the same IP address as the victim of choice: "Guesswho." Lady is a 75 MHz Pentium, while Guesswho runs at 233 MHz, and the NT box, in recognition of its inefficient operating system, runs on a 450 MHz box. Now we use the NT box, which gets to be the victim, to try to connect to 10.0.0.2. Will it get the real one of the attackers? I first try ssh, and get the attacker. Of course this is not fair because in real life, the victim would realize what was wrong by the failure of the password or ssh key. However, I discover that it goes straight to the attack computer even though I haven't explicitly sent out any network traffic.

Next I send some network traffic out from the old 10.0.0.2, the Open Linux system Guesswho, to the NT box at 10.0.0.1

~>ping 10.0.0.1

Then the NT box ARP table shows:

10.0.0.2 00-20-78-16-fa-56

This is the MAC address of the original box, which I verify by sshing into it:

Welcome to your OpenLinux system!

Then I use the attacker to once again ping the NT box. We get a bit of a delay as the poor confused NT box rewrites its ARP table to:

10.0.0.2 00-c0-f0-37-56-6a

Then I get Guesswho (the victim) back into the ARP table by starting up a ping and just letting it run. Then I start the far slower Lady (attacker) with a continuing ping. Lo and behold, Lady takes over, even though she is the slower computer, getting responses from the NT box. Then Guesswho starts getting the pings echoed back to it, then Lady takes over again, then Guesswho. The duelling boxes appear to spend about an equal length of time being 10.0.0.2. At the end of this experiment, Guesswho reports 51% packet loss.

As you can see, so long as the victim normally doesn't send out much traffic on its own, spoofing it is as simple as just keeping some network traffic going. Even a slow computer can force its way into the ARP table just by being chatty. If you want to be absolutely certain of the spoof, you can also do a denial of service attack to crash the victim.

The problem with this, however, is that a smart sysadmin might start wondering why a previously quiet box is suddenly so active on the network. It especially can be suspicious if a denial of service attack is underway. Remember, a sniffer will see all packets going over the LAN.

No matter how smart you are as an attacker, you can't avoid the fact that a good defender learns the normal behavior of his or her network and investigates deviations.

Also, if the box you are spoofing starts putting out lots of network traffic (it may happen if you haven't given a knockout blow to the victim), and if your attack computer fights back to stay in the ARP table, there will be some really obvious screwups. Below is an example.

~>ping 10.0.0.1

PING 10.0.0.1 (10.0.0.1): 56 data bytes

64 bytes from 10.0.0.1: icmp_seq=0 ttl=128 time=0.4 ms

64 bytes from 10.0.0.1: icmp_seq=1 ttl=128 time=0.4 ms

64 bytes from 10.0.0.1: icmp_seq=2 ttl=128 time=0.4 ms

64 bytes from 10.0.0.1: icmp_seq=3 ttl=128 time=0.4 ms

64 bytes from 10.0.0.1: icmp_seq=4 ttl=128 time=0.4 ms

64 bytes from 10.0.0.1: icmp_seq=5 ttl=128 time=0.4 ms

64 bytes from 10.0.0.1: icmp_seq=6 ttl=128 time=0.4 ms

64 bytes from 10.0.0.1: icmp_seq=40 ttl=128 time=0.5 ms

64 bytes from 10.0.0.1: icmp_seq=41 ttl=128 time=0.4 ms

64 bytes from 10.0.0.1: icmp_seq=42 ttl=128 time=0.4 ms

64 bytes from 10.0.0.1: icmp_seq=43 ttl=128 time=0.4 ms

64 bytes from 10.0.0.1: icmp_seq=44 ttl=128 time=0.5 ms

See those icmp_seq numbers on 10.0.0.1? It's missing lots of packets, those from 7 through 39. If the sysadmin logs on remotely to the victim, the connection will be lost every time the ARP table switches MAC addresses. This will get the sysadmin riled up beyond belief and soon will be running his or her sniffer to track down the problem. However, if you first crash the computer you are spoofing, and then spoof its address, you have a good chance of getting away with it.

In the case of the Swedes who spoofed Fangz, they were running denial of service attacks, while Fangz was only speaking when spoken to. The other computers on the network kept on putting information into their ARP tables that associated the Swedish firewall's MAC address with Fangz' IP address. So whenever they tried to access Fangz' open shell account, DNS server, webserver, mail or pop server, ftp server, or Quake server, instead they got "connection refused."

However, you can't do this to just any network. Some sysadmins take the time to set their ARP table to static mode, typically with (under Unix):

~>arp -s <ip address> <MAC address>

However, this is not foolproof, as we will see below.

How to Defeat Switched Ethernet

Perhaps the most powerful way to run amok inside an Ethernet network is by spoofing MAC addresses. This can even work with switched Ethernet.

The truly deadly attack is to conduct a spoof at being any other computer by changing the MAC address of the attack computer to that of the victim.

I have seen books that say the MAC address (which is supposed to map to an Organizationally Unique Identifier (OUI), and should be unique for every Ethernet interface on the planet) is hard-burned into each Ethernet interface. However, many NICs do let you specify the MAC address. Greggory Peck, at one time the Happy Hacker Windows editor, reports that he once changed the MAC address of an old Sun computer. According to the book Maximum Linux Security by Anonymous, Novell Netware has a way to change MAC addresses, too. I hear rumors that a number of generic NICs also have rewriteable MAC addresses.

Oftentimes a NIC manufacturer will give you a program that lets you change the MAC address by changing a flash ROM (read only memory, except you can "flash" write to it under special circumstances).

Larsen says, "A real überhacker can change the MAC address, even if it is burned into ROM. If you completely build the packet (Ethernet headers and all) and control the card's transmitter, you can put whatever MAC address in the Ethernet packet you want."

SMAC by KLC Consulting (http://www.klcconsulting.net/smac/) will allow the MAC address be changed on the fly for Windows 2000 and Windows XP computers. For some Linux versions, it can be done with the ifconfig command:

~>ifconfig eth0 down

~>ifconfig eth0 hw ether <new MAC address>

~>ifconfig eth0 up

To change MAC addresses on a Unix-type computers, try "MAC Changer" from http://www.alobbs.com. It can:

  • Set specific MAC address of a network interface
  • Set the MAC randomly
  • Set a MAC of another vendor
  • Set another MAC of the same vendor
  • Set a MAC of the same kind (eg: wireless card)
  • Display a vendor MAC list (today, 6200 items) to choose from

Mark Bergman bergman@merctech.com points out, "This has been a well-known weakness for many years. many PC NIC cards allow you to change their MAC address. For example, this is a feature of all the Intel EtherExpress cards. Intel's documentation states "Using The PRO/100 ISA Keyword Options... NetworkAddress... Any legal Ethernet value that will override adapter's unique Ethernet hardware address."

Why is it an exceptionally bad thing when an attacker spoofs a MAC address? If the attacker's IP address maps to the "correct" MAC address, this defeats a static ARP table.

Worse, as one fellow who wishes to remain nameless explained to me, "If you can convince other computers on a LAN that your Ethernet interface is the Ethernet interface of the gateway. then you can potentially get around switched Ethernet."

Of course we still have the problem of two boxes with the same MAC address responding to packets. The crude solution is to run a DOS attack to shut down the victim box. This has the problem of alerting intrusion detection systems. What is the solution to this problem? According to Don Holzworth Don_Holzworth@rocketmail.com:

Well, actually I've been writing Ethernet adapter drivers and TCP/IP stacks on Unix systems since 1983. I can spend a good hour discussing the format of link level packets, the difference between 802.3/802.2, DIX Ethernet, Novell, and SubNetwork Access Protocol (SNAP). I've been known to bore even data communication developers. BTW, DLPI doesn't apply to SunOS, which is Berkeley based, only to Solaris which is SVR4 based. instead of flooding with packets to perform a denial of service attack, couldn't a machine on a local link listen to all traffic and send FINs to both sides of a selected TCP connection, impersonating the other end of the connection? That would seem to disrupt TCP very effectively with just 2 packets, and combined with spoofing the MAC address to cloak where the attack was coming from, it could be very difficult to find.

So how can one defeat MAC address spoofing? Q Bahl" qbahl@hotmail.com says there:

.is a very simple way of preventing MAC spoofing, at least with Cisco switches. It's called port level security. For each port on the switch, you can configure the MAC address of the device that's connected to it. Then, if someone attempts to connect another device to that port or change the MAC address of the device already connected to it, the port shuts itself down, and the attacker is denied access to the network. Granted, it is time consuming to set up, and add administrative overhead for things like users moving to a new area of the building or something like that. But it works, and prevents an extremely dangerous attack from ever happening.

More --->>


Carolyn's most
popular book,
in 4th edition now!
For advanced
hacker studies,
read Carolyn's
Google Groups
Subscribe to Happy Hacker
Email:
Visit this group

© 2013 Happy Hacker All rights reserved.