It's worse than that - an attacker on the same local network as the target machine can tie up the legitimate DHCP server by reserving all available addresses and then start advertising themselves as an alternate DHCP server (to inject the malicious routing to the target).
That is true, I was thinking specifically about the metadata and SSH keys. But DHCP can also set DNS servers, NTP servers, and other things that can either cause disruptions or be used to facilitate a different attack.
There might be a persistence issue, it seems like part of this attack was that the IP was persisted to /etc/hosts even after the real DHCP server took over again. But even just writing to /etc/hosts could open the door redirecting traffic to an attacker controlled server.
if you are on a public wifi, particularly if you can control an evil dhcp server, there are sooo many other ways to attack someone's pc client and network. this is just another. it doesn't even seem that unexpected.
anyone understand what exactly is the system broadcasting to the new DHCP server? I can't imagine any system is so bad to the point of sending anything more sensitive than a user name
At least on linux that's not true as NetworkManager + dhclient is affected through malicious dhcp packets. There could be attack vectors almost everywhere.
> It's plausible that on a badly configured network this port could be exposed to the Internet.
It's also plausible that an attacker could find one of these in the local coffee house or any other place that offers public wifi and get at it from the internal side that way, or war driving for access points using weak passwords or WEP, or small office corporate networks with mischievous employees, or an attacker compromising a single PC on the LAN and then using this to change the DNS handed out by the router's DHCP and compromising the others, ...
People put too much trust in even their home internet connections. A few weeks ago my home internet connection (Wave-G delivered via ethernet(dhcp) to my apartment) stopped working. I noticed instead of my router having its normal public ip, a 10/8 address had been assigned. After poking at the router address from the dhcp reply, I found myself looking at a Comcast cable modem.
Turned out a neighbor had moved in, and for whatever reason plugged the LAN side of a cable modem into the ethernet port on their wall, and had begun fighting the ISP's dhcp service.
No, the attacker just has to be on the network. When on the network the attacker can deploy various techniques to become the DHCP server. Since it's (relatively) easy to become a DHCP server on a network, it's considered a big deal when the DHCP server can trick you into doing something like in this case decloaking your VPN traffic.
There are plenty of cheap colos that do no filtering on their public networks. Some are saving money by putting a number of machines on a single ethernet segment, some are saving IPs by not having a /31 (or, much more often, a /30) for each client, and some both, so a compromised machine could easily run a DHCP server and scan any takers. You're right that no sensible network would forward packets to a misconfigured IPMI, though.
That still leaves very real things that've happened - the IPMI switches to the public interface and can no longer be reached on the managed local interface, and then you're rebooting several times in hopes it'll switch back and making aliases on a public interface to see if you can talk to it on the public segment. It's not professional at all.
> I can do a rough inventory of my IPv4 home network (120 devices) by looking at hostnames for DHCPv4 leases, no such thing exists for IPv6.
You mean, you can do a rough inventory of IPv4 devices that are well-behaved and want to be found.
Unless you have enterprise-y network gear, which can do port isolation and preferably 802.1x auth, it's trivial for a host to poison your switch's ARP tables to check whether the address it wants to use it free, and then simply use that address without requesting it from the DHCP server[1].
The DHCP server will check that no hosts are using that address (usually via ICMP) before assigning any leases to it, but won't (at least for any common DHCP servers) register a lease for any host it discovers, so the rogue device doesn't even need to worry about changing addresses when a new host joins the network. At best, you might discover the presence of such a device by checking your DHCP server's logs.
Since no common consumer-grade NAT implementations check whether the internal host has a valid lease before establishing NAT state, the rogue internal device is free to communicate with any external host. Even better, the rogue device can send packets with a from-address of other devices on your network, allowing it to punch arbitrary holes in your NAT.
As other commenters mentioned, you can get a similar level network surveillance for IPv6 using mDNS, but at least IPv6 isn't lulling you into a false sense that you can see all the devices on your network in the lease table.
[1] Actually, it doesn't even need to do that... it can simply start using an address and then change to another address if connectivity seems to be a problem.
Very clever. Apparently by default, Windows, OS X and Linux recognize an ethernet device, load it as a network device and perform a DHCP request, even when the machine is locked or password protected. Ouch.
It doesn't "wreck your network", rather, when it keeps its DHCP lease beyond the allowed time (due to being in "screen off" mode during the expiration) it wrecks things for itself and whomever is unlucky enough to have gotten reassigned the same IP address.
Not a security hole, just a "doesn't play well with others", and I can't think of a way to avoid this without going outside of DHCP (e.g. assuming bad behavior and therefore using a big enough pool and not reassigning IP addresses for a long time).
The vulnerability is known since DHCP accepts any routes it receives (by design) and because ISPs could always MITM your connection and log everything.
always the breathless sensationalized vulnerability headlines...
it's interesting, but of limited usefulness - the device has to accept responses from a dhcp server. if an attacker controls a dhcp server, he's either on the network already or has already had to do a lot worse than installing a couple static routes to get there.
it's not nothing - a compromised home gateway could use this technique to sneak into a corporate VPN via a users' laptop, but if you have a compromised home gateway, you have a lot of other problems that could lead to the same result.
reply