Hello,
Stéphane Graber [2016-05-31 17:59 -0400]:
> The difficulty is with forging the source address. You can use any IP
> which the machine already has, but you can't typically use anything
> else.
Then that indeed means that you actually can't do this attach as
unprivileged user on the local host, as the source IP must also match.
Then the other measures like randomized IDs are irrelevant for the
local host and mostly just make it harder to forge remote attacks.
> That's why such attacks usually involve a second computer (or container
> or VM) on which you have root access and which is attached to the same
> subnet as the first. It doesn't need to be in the path (so no MITM),
> just to be closed to the target and have a route to it.
>
> As you have root access to that second computer, you can write a tiny
> bit of code that runs on it and will send any raw packet that you need.
This is much less "interesting", though. With a separate computer in
the same wifi network you can always snoop traffic and immediately
repsond with forged answers to all DNS queries in 1 of 32768 cases (on
average). So disabling the cache actually makes things *worse* here,
as clients will make a lot more DNS queries thus you have a higher
chance of being lucky once.
On a switched ethernet this is harder of course as you can't normally
see the entire traffic. But I'm fairly sure you can reset the
switches' routing tables by iterating through the IP range of your
network once and sending a packet with each source address, or
similar. And you can always set up a DHCP server and hand a rogue DNS
server through that. Again, disabling caching doesn't help here.
> So if I was to perform such an attack, I'd have a tiny service on my
> laptop which listens on a port for a string containing the IP address of
> the DNS server to impersonate and its port.
>
> Then I'd have another piece of software on the machine I want to poison
> which does the DNS query for the record I want to poison, immediately
> looks up the source port and DNS server IP which was used and send those
> to my laptop. My laptop then immediately replaces those two in a
> pre-generated PCAP containing 32768 UDP packets (one for each of the
> transaction IDs) and dumps the generated pcap onto the wire.
> This entirely avoids having to go through the whole kernel stack to
> generate a real UDP connection. You just dump all 32768 packets into the
> network card in one shot.
Sending 32768 packets at once doesn't buy you anything -- if the first
one is right (presumably ID 0), you already won, and if it's wrong,
the DNS transaction is already aborted, and The the other 32767
packets spam will just go into the void. You need to actually do 32768
fresh DNS queries -- and after you miss the first time, you need to
wait for the TTL of the cached entry before you can actually do
another attempt.
So again, disabling caching does not change the chances here at all.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
