On 2016-06-01 03:21 AM, Martin Pitt wrote:
> 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.
The scenario is wanting to poison the cache on a multiuser system with the help
of another machine on the same network acting as a helper. Having local access
to the multiuser system enables generating known queries, and spying on the
source port being used, at which point you can instruct the other machine to
send the crafted UDP packet to the known source port.
Since you can't predict the random IDs, you would need to perform ~65k queries
to get the required ID collision. Once you do hit it, the cache is now poisoned
for all other local users.
>
>> 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.
This scenario requires that you are able to MITM the network. If you can MITM
the network, you can spoof responses to 100% of the non-dnssec queries. If you
are able to MITM the network, there is no difference whether cache is enabled or
not.
>
> 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.
This is the more interesting scenario. A network where you can't MITM the
multiuser computer running the local resolver, but you do have a computer on the
local network, or at least closer than the dns server is a common enterprise
scenario. Having access to the multiuser computer allows generating identical
requests, and spying on the source port.
If caching is disabled, you can only poison a single request. If caching is
enabled, and you successfully poison a lookup, you've now poisoned it for all
other local users.
>
>> 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.
Yes, you need to perform ~65k requests in order to hit a transaction ID
collision. You don't actually have to wait for the TTL to expire if you miss, as
receiving a response with an invalid ID invalidates the query, even if the
correct response comes from the real dns server afterwards. So you simply need
to try ~65k times.
Generating 65k requests is pretty trivial.
>
> So again, disabling caching does not change the chances here at all.
>
It doesn't change the chances. It changes the result. If there is no cache, all
you've successfully done is poison a single lookup, your own. If there is
caching, you've successfully poisoned the resolver for all other local users
until the TTL expires.
Marc.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
