[3702] in bugtraq
Re: BOOTP/DHCP security
daemon@ATHENA.MIT.EDU (itudps)
Wed Nov 27 20:31:26 1996
Date: Thu, 28 Nov 1996 08:39:32 +1030
Reply-To: itudps <itudps@ntx.city.unisa.edu.au>
From: itudps <itudps@ntx.city.unisa.edu.au>
X-To: Benedikt Stockebrand <benedikt@devnull.ruhr.de>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To: <87k9r79sux.fsf@devnull.ruhr.de>
> [ Concerning rogue BOOTP/DHCP servers ]
>
> I assume you've got the resources to have a machine spend some cycles
> on checking for these attacks.
>
> (1) Make this machine check for bogus MACs in its ARP cache mapped to
> the servers IP address. This forces the attacker to use a network
> card with a configurable MAC and usually stops attacks from machines
> belonging to the network (unless you've got this kind of card
> installed).
arpmon does some of this checking:
curiosity.cob.ohio-state.edu ~ftp/pub/arpmon/
(It requires libpcap which won't work on Linux without hacking, btw. I've
run arpmon under Solaris.)
But I don't see your point here, unless I am misunderstanding something.
Consider a desktop machine with IP address X. Now start a bootp server on
that machine, it still has address X but it is answering bootp requests.
The arp cache won't see it as doing anything different.
> (2) Make it run its interface in promiscuous mode and check all
> bootp/dhcp/tftp/rarp requests. If there are lots of multiple replies
> to the same request this is a strong indication that an attack takes
> place. This scanner could probably be implemented most easily by
> hacking up tcpdump or similar, but using an unmodified tcpdump (with
> appropriate options) and a separate filter program should already do
> the trick on a moderately loaded network.
This will work but I question how manageable it is.
It is common to have multiple rarp/bootp/dhcp servers in a network for
redundancy and speed issues, and also tftp although there is no provision
in the RFC yet for tftp fault tolerance. So lets say you have 10 address
servers, only 3 of which are adjacent to your scanner. The IP addresses of
the servers will change from time to time as network emergencies come and
go. Also some won't respond to requests at all, at least as seen by a
remote monitor. So having a static list of address servers on the network
isn't going to help much, and if there are upwards of 20 people
maintaining the network how are you going to reasonably work out whether a
change in IP address actually means something or not?
Especially when a wise cracker will only respond to a few requests. After
all if he captures the traffic of half the network it won't take long to
notice. In fact I suppose the thing would be to use a rogue server for
just a single response and use it to do damage at the second level -
pointing to a known bogus dns/wins/gateway or whatever. Then shutdown the
server and walk away. You are then left with tracking some unknown
infiltration technique chosen from a very long list of possibilities and
you don't even know the attack has taken place.
I can't see any alternative to authentication at the request packet level,
which means a change in the RFCs and clients.
You can avoid changing clients if you teach the address servers and the
routers about public and private keys, but getting routers to include new
functionality is probably about as hard as getting the clients to change
even though there are fewer of them. Commercial lethargy and all that.
IPv6 we want you.
--
Dan Shearer email: Dan.Shearer@UniSA.edu.au
Information Technology Unit Phone: +61 8 302 3479
University of South Australia Fax : +61 8 302 3385
