Re: Dishonest Forks? | Was - Re: [Namedroppers-honest] Brian Smith asks: Who is Dean Anderson?

Wow, I think for the first time I understand where you're confused.


On Mar 10, 2010, at 8:20 PM, Dean Anderson wrote:
> 
> Ah yes.  I was afraid I would forget some detail.  Its the same
> difference, though. One attack packet can potentially answer several
> queries.
> 
> 
>> How this affects the attack Kevin Day pointed out is it eliminates the
>> benefit an attacker receives by flooding an open dnscache instance
>> with query packets.  If each forged response packet can only match 1
>> outstanding query rather than any of up to 200 outstanding queries,
>> then it's roughly 200x harder for an attacker to forge a response.
> 
> Except that patch does the exact opposite of this.  One successful
> forged packet, and all waiting responses will get exactly the same
> (spoofed) answer.  The patch ensures consistency in when a spoof is
> successful.
> 
> A typical unix system will issue the same query several times during,
> say a login, from different processes.  Unmodified, a spoofer would have
> to spoof each and every response successfully to have a consistent set
> of log files.
> 
> But with Kings patch, no worries. Get one spoof though sucessfully
> (still takes 26 million packets), and no one will be the wiser.
> 
> So its worse.
> 

I think you misunderstand how this class of spoofing works in general. What you are describing is the scenario where you wait for someone to happen to look up the name you want to try to poison. This isn't at all what we're discussing. Waiting for someone to log in to a service, or to try looking up a domain name due to a browser request or something like that is *extremely* unlikely to succeed. Trying to poison a resolver's cache of www.facebook.com by waiting for someone to look up that domain and flooding the resolver with replies to www.facebook.com with the wrong IP simply does not work. You only get one window to attempt this per TTL period of the domain. This is window is on the order of tens of ms long and has hours before the window opens again. The patch/paper/etc have absolutely nothing to do with this kind of poisoning whatsoever.

What everyone else is talking about is this scenario:  If I want to poison www.facebook.com, I don't wait for a user to try looking up www.facebook.com and happen to collide with the response. Instead, I send 200 queries(how many outstanding queries dnscache will allow open at once) to the resolver for "00000001.facebook.com", and flood it with as many replies as I can for "00000001.facebook.com" with additional glue records tacked on for "www.facebook.com" giving the IP address I want it to resolve to, with an extremely long TTL. If *any* of my spoofed replies make it in before the real reply to that open port, with the correct port/query ID, the glue for "www.facebook.com" I tacked on gets trusted (since it's in bailiwick) and cached for a very very long time. Now when a legit user looks up www.facebook.com, they get my incorrect IP. If this didn't work after a few milliseconds, I assume that dnscache has now cached the response to 000000001.facebook.com, so I move on to 00000002.facebook.com and try again. 

I also discussed in the paper how to use dnscache's lack of SOA caching to avoid playing the "keep changing the query name" game, but that's irrelevant here.


Humor me for a minute here. Lets get back to the poisoning model you describe and see if I understand, and why it's no big deal. Please indicate where our thoughts diverge:


** Without the patch **
We have a hypothetical unix system that users are allowed to log into.
We have an attacker who wishes to make the log files on this server show a different hostname than where he's logging in from.
On logging in, several services make identical DNS queries (looking up the in-addr.arpa for the logging in IP) so quickly that all of them are outstanding at the same time. Lets say there are 3 of these services, so 3 outstanding requests at once.
An attacker will begin sending spoofed replies just before logging in, sending spoofed packets for that PTR lookup to give a false name. (no fancy glue record poisoning, just flat out giving false answers to the query that we know is being asked)
Lets say the authoritative server for this is rather far away, 100ms, and the attacker is on an extremely fast connection that can do 10,000 spoofed packets per second, and the victim server can keep up with that.
The attacker has a 100ms window, which allows him to send 1000 spoofed packets. He has 3 possible combinations of port number and query ID to try to collide with.  The odds of any packet successfully colliding is: 3/(65536*65536) or 0.000000000698492. He has 100ms to send 1000 packets though, so his probability of exploitation is 0.000000698491931. Or roughly 1 in 1,431,655 for any of his packets to collide with the 3 open queries before the real result gets there.
Assuming at least a 6 hour TTL between tries, it will take 490 years to have a 50% chance of success at poisoning any one of the records once.
If the attacker does succeed, 1 of the 3 services will have received the wrong answer.


** With the patch **
We have a hypothetical unix system that users are allowed to log into.
We have an attacker who wishes to make the log files on this server show a different hostname than where he's logging in from.
On logging in, several services make identical DNS queries (looking up the in-addr.arpa for the logging in IP) so quickly that all of them are outstanding at the same time. Dnscache only opens one query to look up this PTR record, because the patch makes it merge identical outgoing requests into a single connection.
An attacker will begin sending spoofed replies just before logging in, sending spoofed packets for that PTR lookup to give a false name. (no fancy glue record poisoning, just flat out giving false answers to the query that we know is being asked)
Lets say the authoritative server for this is rather far away, 100ms, and the attacker is on an extremely fast connection that can do 10,000 spoofed packets per second, and the victim server can keep up with that.
The attacker has a 100ms window, which allows him to send 1000 spoofed packets. He has 1 possible combination of port number and query ID to try to collide with.  The odds of any packet successfully colliding is: 1/(65536*65536) or 0.000000000232831. He has 100ms to send 1000 packets though, so his probability of exploitation is 0.000000232830644. Or roughly 1 in 4,294,967 for any of his packets to collide with the open query before the real result gets there.
Assuming at least a 6 hour TTL between tries, it will take 1470 years to have a 50% chance of success at poisoning any one of the records once.
If the attacker does succeed, all three of the services will have received the wrong answer, but the odds of doing so are 3x less likely.

While I have a feeling you're fixating on the last line, the problem is that *nobody spoofs this way*. The fact that these generous terms give a 50% chance of success measured in *hundreds of years* either way, makes the whole issue moot. This patch is largely a no-op in this case. It makes the spoofing 3x harder, but makes the spoofing an all-or-nothing proposition to 3 services.  It's a wash, and anyway, a system that actually works the way this hypothetical login system does has got to be rare.

Now lets look at this again from the angle of a smart attacker who isn't trying to spoof the way you describe, but actually attempting to break things the way we're trying to fix.

** Without the patch **
We have an attacker who wants to poison www.facebook.com to go to an address he controls.
He opens 200 simultaneous queries for 00001.facebook.com, and floods the server with responses for 00001.facebook.com but with a glue record for www.facebook.com pointing to the IP he wants to. Each spoofed reply can collide with any of the 200 queries since they're identical.
Each spoofed packet has a 200/(65536*65536) chance of colliding with any of the open queries, or 1 in 21474836.
After 100ms, the real replies to 00001.facebook.com arrives at the victim, closing those queries. During the 100ms, the attacker got off 1000 packets, so his odds of poisoning were 1000 in 21474836 or 1 in 21474.
The attacker sends 200 new queries for 00002.facebook.com and repeats the above scenario until success.
10000 attempts per second gives him odds of 1:2147 in the first second. A 50% chance of success requires 17 minutes of attacking.
Once there is a successful collision, dnscache will cache the glue record for www.facebook.com until the TTL of my choosing expires (days/weeks if I want.)

** With the patch **
We have an attacker who wants to poison www.facebook.com to go to an address he controls.
He opens 200 simultaneous queries for 00001.facebook.com, and floods the server with responses for 00001.facebook.com but with a glue record for www.facebook.com pointing to the IP he wants to. The server is smart and combines those 200 identical queries into one outgoing request.
Each spoofed packet has a 1/(65536*65536) chance of colliding with any of the open queries, or 1 in 4294967296.
After 100ms, the real replies to 00001.facebook.com arrives at the victim, closing those queries. During the 100ms, the attacker got off 1000 packets, so his odds of poisoning were 1000 in 4294967296 or 1 in 4294967.
The attacker sends 200 new queries for 00002.facebook.com and repeats the above scenario until success.
10000 attempts per second gives him odds of 1:429496 in the first second. A 50% chance of success requires 59 hours of attacking.
Once there is a successful collision, dnscache will cache the glue record for www.facebook.com until the TTL of my choosing expires (days/weeks if I want.)


The patch made the attack require 59 hours of constant 10kpps flooding instead of 17 minutes. That's all we're claiming to do here. 10kpps flooding is extremely optimistic, btw. I was unable to sustain that level of attacking against several of my test boxes. 1000pps is more likely, so multiply all the attack times above by a factor of 10 for something more realistic.

If this hasn't put us both on the same page, please point out one of the lines above as one you disagree with. I know this is complicated, but I don't know any way to state this more simply.


-- Kevin