Re: arpwatch

["B. McAninch" <lists () planbproduktions com>]

The _protocol_standard_ dictates that an ARP request is 
broadcasted to ff:ff:ff:ff:ff:ff and an ARP reply is returned via 
unicast. This permits all hosts on the local network segment to 
receive the request and only the requesting host to receive the 
reply. 

As we know, most protocol-based attacks exploit inherent weakness 
in a protocol or by not following the protocol's standard - nmap is a great 
example of this.

In my personal experience, I've had hosts reply to both unicast and
broadcast ARP requests, as well as accept unicast or broadcast ARP 
replies, and update their cache entries. This essentially creates four 
possible attack "subtypes":

1. ARP request sent to the broadcast address
2. ARP request sent directly to the target host via unicast
3. ARP reply sent to the broadcast address
4. ARP reply sent directly to the target host via unicast

Attacks 1 and 2 are possible since a host (by protocol standards)
receiving an ARP request updates its own ARP cache entry for the host 
sending the request - this is done to reduce network chatter.

Attacks 3 and 4 are possible since ARP is a stateless protocol. 
The host receiving the reply doesn't keep track of whether or not 
it just sent an ARP request or not, it just happily accepts the reply
and updates its ARP cache entry for the replying host.

Aside from sniffing on switched networks, imagine this - you 
broadcast flood (and I mean flood) an entire network segment with 
unsolicited ARP replies. These replies all have their IP's spoofed as 
the gateway's IP, telling all hosts the default gateway's MAC address 
is in fact a non-existent MAC address. Unless the hosts have static 
ARP cache entries for the gateway's MAC address, they will no longer 
be able to communicate outside the local network segment - a very 
easily implemented DoS-style attack ;-)

My 2 cents: 

1st cent: TCP/IP Illustrated vol. 1 - W. Richard Stevens
2nd cent: http://www.packetfactory.net/libnet/dist/libnet.tar.gz

Cheers,

Bryan

----- Original Message ----- 
From: "Kim Oppalfens" <Kim.Oppalfens () azlan com>
To: "'zidan'" <zidan00 () fastmail fm>; <Gunter.Luyten () student kuleuven ac be>
Cc: <security-basics () securityfocus com>
Sent: Friday, September 12, 2003 12:43 AM
Subject: RE: arpwatch


> It doesn't really matter that you can't see the unicast traffic since
> arpspoofing is done with broadcast packets.
>
> Kim Oppalfens 
>
>
> -----Original Message-----
> From: zidan [mailto:zidan00 () fastmail fm] 
> Sent: donderdag 11 september 2003 20:29
> To: Gunter.Luyten () student kuleuven ac be
> Cc: security-basics () securityfocus com
>
> I don't agree, arp requests are broadcasts. but response is not broadcast,
> its unicast.
> the answering source to the asking destination.
>
> what I don't understand, is how can the arpwatch station can see this packet
> if this is a switched network
>
> -Z
> --
>   zidan
>   zidan00 () fastmail fm


---------------------------------------------------------------------------
Captus Networks 
Are you prepared for the next Sobig & Blaster? 
 - Instantly Stop DoS/DDoS Attacks, Worms & Port Scans 
 - Precisely Define and Implement Network Security 
 - Automatically Control P2P, IM and Spam Traffic 
FIND OUT NOW -  FREE Vulnerability Assessment Toolkit 
http://www.captusnetworks.com/ads/42.htm
----------------------------------------------------------------------------