Bugtraq mailing list archives
Re: BOOTP/DHCP security
From: itudps () ntx city unisa edu au (itudps)
Date: Wed, 27 Nov 1996 20:24:18 +1030
On Wed, 27 Nov 1996, Geoffrey KEATING wrote:
Many networks rely more and more on BOOTP and DHCP protocols, not just for the address discovery but the other info that optionally goes along with it.
:
So what solutions have other people thought about/implemented to cope with the possibility of rogue address discovery servers being set up?
:
Examples of bogus information might include: o a new gateway that bounces everything to the real gateway but also keeps a copy of certain information, this would often be undetected in a typical large and busy commercial or educational network.[of course, you can do this with a packet sniffer just as easily].
Not necessarily! The big point is that these requests are usually broadcast and forwarded by the routers, so that you have a window of opportunity to get access to parts of the network normally not visible. A backbone with various subnetted segments off it is an example, where there is a smaller number of bootp/dhcp servers than there are subnets. Therefore requests will be forwarded everywhere and usually so will the replies, for ease of management. And it would also be normal for all these subnets to be able to talk to one another even though they are protected from active attacks. All you have to do is reply quicker than the genuine server giving information that tricks the recipient into sending information via some bogus host. A trojan gateway is only one possibility, and one that won't work in many configs at that. You could make the window of opportunity a bit larger at will by bogging down the genuine server with spurious requests (see bugtraq archives and phrack magazine for exhaustive details on doing this.)
o a different tftp host (sa parameter) that returns a hacked bootimage, the original having been got for free via tftp.[... and this with an active attack, bootp or not. TFTP really isn't secure in any way.]
Again, active attacks require you to be in the pathway to start with. Intercepting bootp/dhcp doesn't. In the typical subnetted network mentioned previously unless the attacker is on the backbone (in which case he has the crown jewels) he will only be able to perpetrate active attacks if the conversation is passing through his subnet, ie it will only be a small proportion of connections that are vulnerable. But, if he can convince the connection to come via his subnet in some way by faking the dhcp data he's in.
o dud replies to DHCP lease information: a premature expiry will cause Microsoft stacks to freeze and if the source IP for this was forged then the logs would indicate the original DHCP server did the damage. Very, very annoying.Ouch! I wonder if this could be made into a remote DoS attack?
That was what I was thinking: if one of the firewall penetration gurus here really thought hard about it could a way be designed to slip a dhcp packet through? Even some quite recent firewall products are alleged to be vulnerable to the ip-fragmentation/length checking bug so maybe its a case of bringing out old tricks.
This is particularly relevant to the relatively small number of sites that do a lot of remoteboot for security reasons (see ftp://lux.levels.unisa.edu.au/pub/doc/RemoteBoot.txt) but as I have shown there are other bad things that can be done as well.I don't see why you would do remoteboot for security reasons [and the URL gives me 'connection refused'], if you don't trust the network. I mean, I imagine you're thinking of something like diskless machines that are rebooted between sessions to prevent fake login screens.
This is a different topic. The article is accessible via ftp (not http as I said initially.) I think I have covered your comments there.
I suppose you could use some sort of authentication on DHCP responses (and on boot files loaded using TFTP, etc.). Preferentially, I guess you would use IP authentication, and have some sort of key distribution method... But then of course you have to load some information in beforehand, which reduces the advantages of DHCP.
This is just it. I followed it to a couple of levels of indirection but soon found that there was no point in having dhcp at all. I suppose there is some scope for a site-specific public key, but then you would have to have a way of programming this into PROMs from lots of manufacturers including printer manufacturers whose reputation for understanding these sorts of issues isn't good. An extension to the dhcp spec for inclusion of public key/private key 1024 bit encryption would be a start I suppose. I was wondering if anyone here knows about mobile IP, are there security angles that could be borrowed from that to meet this problem? -- 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)