Bugtraq mailing list archives
Re: BOOTP/DHCP security
From: itudps () ntx city unisa edu au (itudps)
Date: Thu, 28 Nov 1996 08:39:32 +1030
[ 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
Current thread:
- Re: BOOTP/DHCP security itudps (Nov 27)
- <Possible follow-ups>
- Re: BOOTP/DHCP security itudps (Nov 27)
- Re: BOOTP/DHCP security Benedikt Stockebrand (Nov 27)
- Re: BOOTP/DHCP security itudps (Nov 27)
- CIAC Bulletin H-08: lpr Buffer Overrun Vulnerability David Crawford (Nov 27)
- Re: BOOTP/DHCP security Valdis.Kletnieks () vt edu (Nov 28)
- Irix: more suid fun/exploits Yuri Volobuev (Nov 28)
- Re: BOOTP/DHCP security Alan Cox (Nov 28)