[3699] in bugtraq
Re: BOOTP/DHCP security
daemon@ATHENA.MIT.EDU (itudps)
Wed Nov 27 15:02:22 1996
Date: Wed, 27 Nov 1996 20:24:18 +1030
Reply-To: itudps <itudps@ntx.city.unisa.edu.au>
From: itudps <itudps@ntx.city.unisa.edu.au>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To: <199611270655.RAA28612@discus.anu.edu.au>
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
