Bugtraq mailing list archives

BOOTP/DHCP security


From: itudps () ntx city unisa edu au (itudps)
Date: Wed, 27 Nov 1996 14:11:53 +1030


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. Apple, Microsoft and Unix sites are all moving to them.

So what solutions have other people thought about/implemented to cope with
the possibility of rogue address discovery servers being set up?  Since
the requests are broadcast, and OS+daemon can fit on a floppy disk in some
cases and is just a free add-on in others, it is very easy to offer back
incorrect, or worse still subtly incorrect information. Especially if the
real server is fairly heavily loaded and may not respond as quickly as
someone's desktop P150 temporarily running a free BOOTP/DHCP daemon under
just about any OS you like. At least this isn't a hack people can do from
outside an organisation by default, unless BOOTP forwarding has been
turned on in the gateway.

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.

o a different tftp host (sa parameter) that returns a hacked bootimage,
the original having been got for free via tftp.

o an incorrect subnetmask or equivalent that stops the machine working and
if the bogus server only answers once a day the evidence will be gone as
soon as the user restarts. Nuisance value but it would take a while to
track down.

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.

This is particularly relevant to the relatively small number of sites that
do a lot of remoteboot for security reasons (see
http://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.

--
 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: