LWN: Comments on "Details of the DNS flaw revealed"

DNS hacking: Blacklisting source IP address

darwish07 — Sat, 23 Aug 2008 12:06:35 +0000

Yes, I agree. but what I meant is that UDP puts less restrictions on the sender IP address.

IP forging can happen more easily with UDP since no handshake or any kind of replies are needed. Only the forged packet is enough.

Details of the DNS flaw revealed

paulj — Fri, 22 Aug 2008 09:07:24 +0000

That's a deficiency in BGP though, or at least a mark of it being designed in days when the internet was a smaller place. It's something which people are trying to address in various ways.

Details of the DNS flaw revealed

dlang — Thu, 21 Aug 2008 23:23:57 +0000

the concept of what IP addresses "can't come from that segment" falls apart when you get into
the core of the Internet where dynamic routing (via BGP) is used. the dynamic routing is
designed so that it can send anyone's traffic anywhere if that's the best way for it to get
there.

The birthday paradox doesn't apply

mejd — Thu, 21 Aug 2008 14:43:01 +0000

What is true is that each sub-domain can be attacked independently, and each must fail for the
overall attack to fail.  On an unpatched server an n-pronged attack will fail with probability
(65535/65536)**n --- n still has to be very large.

The birthday paradox refers to collisions of transaction ids amongst whole groups of requests
and answers where any answer could apply to any request.

Details of the DNS flaw revealed

forthy — Thu, 21 Aug 2008 08:13:59 +0000

We need to accept that the whole TCP/IP frame was designed for a cooperative environment, not a hostile one. Forging IP source addresses is already something a secure network should not allow, and in fact it should be not difficult to implement IP filters in routers that drop all forged IP sources (i.e. those that can't come from that segment). The lack of authentication everywhere is another problem. All the security stuff like signed mails, DNSSEC, etc. is worthless if unsigned data is still accepted as good.

IMHO, the internet protocols need to be redesigned from scratch. But then, there will be serious transition problems - IPv6 already causes those, even though much of the protocols are unchanged, and thus also their problems are not fixed. For the transition period, we'll need protocol translators. However, these translators are causing security problems, as well, because the problems in the old protocols aren't fixable. The good thing is that you can phase out the old protocols over time, and put pressure on sensitive services to migrate first (the last IPv4 devices in such a network will probably be the printers on the LAN, because they don't cause much security problems).

DNS hacking: Blacklisting source IP address

dlang — Sat, 16 Aug 2008 08:21:55 +0000

actually, there are large chunks of the Internet that do not check the source IP when routing
the packets.

and once you get a hop or so from the source (real or forged) this is nessasary becouse the
routers could be dealing with packets from just about anywhere.

in theory every company/personal router and every ISP border router (both to the customers and
to other ISPs) has such filters.

in practice relativly few of them do.

this is even true of the major international peering points. every year or so you hear of a
country that got knocked off the Internet due to mistakes that someone makes with BGP routing
configuration. these useually get detected and fixed within a short time and so don't make the
news, but every once in a while the outage lasts long enough to get attention.

I've been at the recieving end of enough forged attacks to know that it's definantly possible.

although I'll admit that with botnets getting as large as they are, forged packets are not
used as much as they used to be.

DNS hacking: Blacklisting source IP address

giraffedata — Fri, 15 Aug 2008 20:42:23 +0000

This is UDP, The attacker source IP address can be changed when every new packet is sent without affecting the end result.

The source IP address is not UDP; it's basic IP. The attacker can't simply choose the source IP address because whoever routes his IP packet into the Internet will not accept it if its source IP address is someone else's (and the attacker isn't trusted as a router for that someone).

You have to pull off a pretty high level hack of the Internet before you can spoof a source IP address.

Details of the DNS flaw revealed

tialaramex — Fri, 15 Aug 2008 12:00:34 +0000

The manual steps in DNSSEC deployment mean that even if by some miracle tomorrow the root
servers offered a signed zone and began accepting requests to sign KSKs from the TLDs, it
would be years before the majority of public domains were secured, so the increase in
resources required would be gradual, rather than overnight.

The root server operators seem to have made it plain that for /them/ at least the performance
is not a problem. Several ccTLDs have deployed as islands, so they obviously don't think
performance is a problem.

There is the enumeration problem, but again that doesn't affect the root because its contents
are public. Some ccTLDs have said that they don't believe this is a problem for them either,
because local regulations mean the list of domains and registrants is public anyway. And even
for some of the domains where enumeration isn't acceptable, there are solutions to deploy
today if the will existed, and better solutions on the horizon.

Details of the DNS flaw revealed

tialaramex — Thu, 14 Aug 2008 22:00:53 +0000

I don't understand your scenario. Can you flesh it out a bit? It seems to me that I would
expect SERVFAIL in this type of scenario (spoofing is successful, the answer should be signed,
but the spoofed answer isn't signed).

What happens exactly, there's ISC BIND running somewhere, as a recursive server for the client
resolver ? What if anything in your scenario is actually configured as DNSSEC secured and has
a good trust anchor? What is it requesting? What does it receive?

Or maybe you have a link to a bug report which explains all this?

There are extensive test zones available, so you don't need to rely on hypotheticals, every
combination people could think of exists (in these test zones, and no doubt soon on the public
Internet due to ordinary incompetence). If your scenario requires a CNAME which is unsigned
but which points to a signed A record from the same zone, there's a test for that. How about a
correctly signed CNAME, plus an A record signed with an expired key and a TXT record which is
correctly signed but by a key which is not yet valid (DNSSEC pre-issues keys)? We can do that.

Nothing needs to be spoofed, because the test zones contain everything a spoofer might want to
send (and plenty of things no-one ever has any reason to send but which might conceivably
exist anyway)

Details of the DNS flaw revealed

lysse — Thu, 14 Aug 2008 12:15:41 +0000

> No, even if you do all of those things, (at least with ISC BIND)

Well...

Some stupid ideas

rvfh — Thu, 14 Aug 2008 10:51:44 +0000

In this case, one could ask for each value (or only the ones under attack) twice:
- ask value, return to requester with short TTL (a few seconds)
- wait a bit
- ask value again, if matches use given TTL (or limit it to a few hours)

Anyway, it seems the solution is in the repetition, to decrease the probability of success of
the attack.

Some stupid ideas

NAR — Thu, 14 Aug 2008 10:08:04 +0000

I think this is a good idea. RFC 1035 states that "TTL is a 32 bit signed integer that specifies the time interval that the resource record may be cached", so this actually would not break the DNS specification.

Some stupid ideas

rvfh — Thu, 14 Aug 2008 06:02:07 +0000

Yeah, the last thing we want is to turn a defensive measure into a DoS vulnerability :-)

Some stupid ideas

njs — Wed, 13 Aug 2008 23:46:23 +0000

You don't even have to wait -- you know something funny is going on from the very first bogus
packet you receive (since the attacker has to send thousands of bogus packets before one of
them will chance to be valid).

That still doesn't tell you what to do, though.  Besides page the sysadmin, I mean, which
isn't going to be very effective on a consumer router.

I guess one of the pieces of information you can extract from the bogus packet is what cache
entry the attacker is trying to poison, and then treat that entry more carefully -- e.g., you
could put a flag on that entry, and when you receive an apparently valid value, if the flag is
set then you clear the flag but *don't* cache the value you received; this would mean that an
attacker had to spoof you on two transactions in a row without sending any bogus packets in
between in order to successfully poison your cache.  You can tune how many bogus packets are
required to set the flag and how many valid responses are required to clear the flag to
trade-off between safety and joe-job potential, but really if someone is flooding you with
thousands of UDP packets then running even dozens of extra queries is not going to be your
performance bottleneck.

Details of the DNS flaw revealed

hmh — Wed, 13 Aug 2008 21:29:43 +0000

Read up on DNSSEC and look-aside validation.

ISC and friends have worked around the politic crap about signing the root.  It is some other
pesky details that are causing issues for DNSSEC deployment.

And server/network performance IS one of them.

Details of the DNS flaw revealed

kh — Wed, 13 Aug 2008 21:21:37 +0000

No, even if you do all of those things, (at least with ISC BIND), you are still vulnerable to
an unsigned spoofed response that gets there before the signed response (which would then be
ignored.)

Details of the DNS flaw revealed

tialaramex — Wed, 13 Aug 2008 21:14:13 +0000

DNSSEC does get you something today because an answer is not "correct" if it is unsigned, or
the signature is invalid, and you were expecting a signed response.

If your resolver can determine a chain of trust from an anchor (ideally the root servers, but
today it might be the Swedish ccTLD registry) down the DNS hierarchy to the requested address,
then it can (and if configured to do so) will authenticate the response.

At the anchor you use a locally configured key to verify the signed information about the next
level, and if that information contains a public key, you can use that to verify the next lot
of signed information, and so on until you've reached the point in the hierarchy you were
interested in, or you don't get a key and fall back to unauthenticated DNS.

If you install the Swedish TLD's DNSSEC public key and configure your resolver and/or
recursive server to use it, then you will have working DNSSEC today, for however many 2LDs
there are in their registry which have decided to use DNSSEC, and for any of their 3LDs and so
on as appropriate. Once you have set this up, any queries for these addresses will either give
you the authentic answer, or fail in some way (e.g. because the owner forgot to update their
key and doesn't have a system which handles it automatically), spoofing becomes impossible.

Some stupid ideas

darwish07 — Wed, 13 Aug 2008 20:46:00 +0000

The packets does not have to be with the same IP source address and UDP port. 

This is UDP, The attacker source IP address can be changed when every new packet is sent
without affecting the end result.

Details of the DNS flaw revealed

rfunk — Wed, 13 Aug 2008 19:34:59 +0000

That sounds a lot like my understanding of what DNSSEC is, or wants to be.  
But it doesn't work if you don't have that whole chain of trust going all 
the way to the root.

Some stupid ideas

drag — Wed, 13 Aug 2008 19:13:46 +0000

>  Although I don't know what to do with that information...


Block him with firewall rules, would be my guess, or build it into the DNS server to deny
them. Similar to setting up rules to block people that attempt to brute force a ssh password
or whatnot.

Of course that would lead to interested DOS possiblities. Like having some goofy webpage or
emailing somebody with a html email  that have images that link to thousands of non-existent
servers with fake dns names.

Details of the DNS flaw revealed

drag — Wed, 13 Aug 2008 19:02:21 +0000

The only thing that I could see working is to 'establish a tree of trust' going from 'trunk'
root dns servers to 'branches' to the 'leaves'. 

Each DNS server would have to register with the ones it communicates with and uses something
like TLS or PGP signing to communicate with one another so that the identify of the sender is
confirmed by the signature data contained in a packet (once you get a signature then you
wouldn't have to sign each packet, just as long as the data can be compiled and have it's
final checksum confirmed then that's fine). Then when a person requests a DNS address the
message will have to transverse up the tree to the nearest DNS system (or 'common link') in
the chain of trust and then back down (this would probably require a separate routing
protocol, or tying into existing protocols, for finding these paths).

The DNS server would have to establish it's identity with it's neighbors when it's first
brought up, and that's were the next window of vulnerability will be.

That's a lot of overhead, though.

Some stupid ideas

rvfh — Wed, 13 Aug 2008 18:53:43 +0000

An improvement would be to not accept the first answer, and wait a bit to make sure only one
matching answer is received. If more than one, try again!

Also, if the bad guy is sending loads of wrong answers, this seems easy-ish to guess that we
are under attack. Although I don't know what to do with that information...

Details of the DNS flaw revealed

njs — Wed, 13 Aug 2008 18:31:44 +0000

djbdns doesn't do anything magic, and the first good answer still wins; it's just that the
patch everyone else had to apply -- to enable source port randomization, which makes it harder
for an attacker to provide a "good answer" -- was already built-in to djbdns.  Now that
everyone's had to patch, djbdns is just as resistant (or not, see the end of the article) as
everyone else.

Details of the DNS flaw revealed

njs — Wed, 13 Aug 2008 18:29:17 +0000

That doesn't help, because there's no way to securely work out the sender of a UDP packet.
The attacker just has to forge the source address on their UDP packets -- and if they forge it
to be the *real* DNS server, then they might even trick you into blacklisting the real server.

Details of the DNS flaw revealed

jake — Wed, 13 Aug 2008 18:25:13 +0000

djbdns has always had source port randomization which is the technique used to alleviate the
current problem.  Few other DNS implementations used source port randomization, but those that
did were also not vulnerable to this attack.  Or perhaps not *as* vulnerable is a better way
to put it.  After the big patch last month, all of the major DNS implementations have roughly
the same level of vulnerability to this attack.

jake

Details of the DNS flaw revealed

smoogen — Wed, 13 Aug 2008 18:16:32 +0000

Could someone explain why djbdns is not vulnerable to this attack (or I have been told the
entire scenario). What does djbdns do so that "The key to DNS cache poisoning is that the
first good answer wins."

Details of the DNS flaw revealed

kh — Wed, 13 Aug 2008 17:45:26 +0000

The other problem with DNSSEC is that it does not get you anything today - a first correct
answer sent as a plain DNS response will still cause the DNS server to ignore subsequent
responses.

It seems like there should be some way to block responses from a client after a given number
of incorrect UDP port injection attempts - at least then an attacker would have to distribute
his attack across many different attacking computers instead of sending millions of
unsolicited responses from a single computer.