Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Attack Code Published For DNS Vulnerability

samzenpus posted more than 6 years ago | from the protect-ya-neck dept.

Security 205

get_Rootin writes "That didn't take long. ZDNet is reporting that HD Moore has released exploit code for Dan Kaminsky's DNS cache poisioning vulnerability into the point-and-click Metasploit attack tool. From the article: 'This exploit caches a single malicious host entry into the target nameserver. By causing the target nameserver to query for random hostnames at the target domain, the attacker can spoof a response to the target server including an answer for the query, an authority server record, and an additional record for that server, causing target nameserver to insert the additional record into the cache.' Here's our previous Slashdot coverage."

Sorry! There are no comments related to the filter you selected.

Here we go... (4, Interesting)

LostCluster (625375) | more than 6 years ago | (#24312697)

This has to be the worst time ever to be a web surfer. How long until we see the major networks broadcasting the legit IP quads of sites we want to reach?

CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24312757)

to do most of his dirty work. Don't you wish you had AIDS too?

Re:CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24312785)

He's got something, that much is true. No one looks that ill and denies it unless he's trying to cover it up.

Re:CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

hostyle (773991) | more than 6 years ago | (#24312821)

Unless ... its a secret ploy to beat MS and Google at their fangled online health databases! hah!

Re:CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24312827)

Could be he is just an old fucker. He is and old fucker you know. He invented an Apple so that makes him really, really old. And they die every day.

Re:CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24312867)

I don't think Jobs did Apple. He did a computer called Next, which was between the Commodore and Amiga lines. He became Apple CE0 when the Ipod became popular. I think it was his design.

Re:CONFIRMED: Steve Jobs has AIDS !! (0)

Anonymous Coward | more than 6 years ago | (#24313699)

I assume you've never heard of Woz either

Re:CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24312891)

Mental retardation. Think about it.

Re:CONFIRMED: Steve Jobs has AIDS !! (3, Funny)

DurendalMac (736637) | more than 6 years ago | (#24312995)

For fuck's sake, whoever is DDoSing 4chan needs to stop already! The tards have spread out and are trolling the whole internet. At least the 4chan cesspool kept them all mostly in one place. Now they're left with nowhere to go and are taking their idiocy all over the internet!

Re:CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24313059)

Egzacly
I FRENCH

Re:CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24313193)

So I guess you could say there's some SERIOUS BUSINESS on the Internet.

Re:CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

LostCluster (625375) | more than 6 years ago | (#24313205)

Now they're left with nowhere to go and are taking their idiocy all over the internet!

We almost routed them to the right place. This is it.slashdot.org, they actually fit in at idle.slashdot.org.

Re:CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24313321)

apple fanbois can kiss my ubuntu-shaped ass//

Re:CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24313567)

this is actualy very annoying as sad as it sounds /b/ is just about the only place I ever talk to people about feelings and my love of strange things as it anonomass and accepting. It's like loosing a freind :(

Re:CONFIRMED: Steve Jobs has AIDS !! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24314193)

For fuck's sake, whoever is DDoSing 4chan needs to stop already! The tards have spread out and are trolling the whole internet. At least the 4chan cesspool kept them all mostly in one place. Now they're left with nowhere to go and are taking their idiocy all over the internet!

You can't fool me. Your post was just a roundabout way of suggesting that Steve Jobs' illness is the cancer that is killing /b/! :)

Re:Here we go... (-1, Offtopic)

kesuki (321456) | more than 6 years ago | (#24312881)

i run firefox with noscript, and removed google and yahoo from my trusted domains, you insensitive clod!

Re:Here we go... (4, Informative)

Carnildo (712617) | more than 6 years ago | (#24312999)

This has to be the worst time ever to be a web surfer. How long until we see the major networks broadcasting the legit IP quads of sites we want to reach?

There's nothing new about this. DNS cache poisoning attacks have been found before, and the internet hasn't melted down yet. If you're paranoid, run your own caching resolver.

Re:Here we go... (5, Interesting)

Martin Blank (154261) | more than 6 years ago | (#24313131)

You may still not be safe. If someone can fire off a XSS attack through your browser, it could do enough lookups to make you vulnerable. Combine this with a periodic other run to a controlled server to grab your source port for guessing (presuming that you have not patched), and you may have a problem.

Granted, it's unlikely that you would explicitly be targeted, and things like NoScript help defend against it, but there are still possible gaps. In fact, there are several tens of million of systems which will remain vulnerable for some time to come; I haven't seen many SOHO router firmware fixes released so far, and a lot of people point to their routers for their DNS.

Re:Here we go... (2, Informative)

afidel (530433) | more than 6 years ago | (#24313923)

Heck, MOST of the corporate firewalls don't do the right thing, so even if your clients and DNS server are patched you may STILL be vulnerable! Unless your firewall does transparent port passthrough (IE NAT but not PAT) you are vulnerable. For most firewalls this means you have to put a caching resolver in the DMZ and point internal servers and/or clients to it to be fully protected. Oh and don't forget things like anti-spam appliances, most are pointed directly out to the internet for DNS but not all are out in the DMZ.

Re:Here we go... (1)

LostCluster (625375) | more than 6 years ago | (#24313181)

Your own caching resolver will submarine you for a while, but eventually it has to come up from air and trust some other DNS resolver to see if the info hasn't changed.

Re:Here we go... (3, Informative)

Anonymous Coward | more than 6 years ago | (#24313569)

You can run your own recursive resolver which only talks to authoritative DNS servers. You can configure it to use random source ports if you want to make this attack much more difficult. Then an attacker would have to send you billions of spoofed packets to poison your DNS. That seems a little excessive for exploiting just one user. You could make it even more difficult by rate limiting your resolver (you're its only user after all).

Re:Here we go... (1, Interesting)

harlows_monkeys (106428) | more than 6 years ago | (#24313185)

There's nothing new about this

You are massively wrong [darkoz.com] . There has never been a DNS attack anywhere remotely as dangerous and effective as this one.

It is people making boneheaded statements like yours that make people think it is no big deal and they can put off patching.

Re:Here we go... (5, Insightful)

Anonymous Coward | more than 6 years ago | (#24313395)

Yes, there was. Before there was bailiwick filtering, spoofing was even easier. Back in the days, DNS servers would even accept "responses" with bogus data out of the blue. We've come a long way and we don't stop here. A patch of bad weather is ahead, but the sky is not falling.

Re:Here we go... (1)

spankymm (1327643) | more than 6 years ago | (#24313525)

You are massively wrong.

The metasploit code sends bulk randomly generated spoofed replies. If you look at Amit Klein's work on analyzing the PRNG's involved, there are *much* more effective attacks.

It is people making boneheaded statements like yours that make people think you are a tosser.

(Everybody still needs to patch/and or enable nat on egress, btw)

Re:Here we go... (1)

harlows_monkeys (106428) | more than 6 years ago | (#24313665)

Much more effective than 10 seconds?

Re:Here we go... (4, Informative)

spankymm (1327643) | more than 6 years ago | (#24314165)

Yes - go read Amit Klein's papers on trusteer.

Sending only a handful of more carefully calculated responses is also more likely to succeed if the victim is using mitigation techniques such as rate throttling.

Even using source port randomization doesn't help as much as a lot of people think. You don't get one 32-bit PRNG, you get 2x 16-bit PRNGs. Each of these can be attacked separately. If you could narrow each of these down to 10 likely guesses, you only have to send 100 replies.

Re:Here we go... (4, Insightful)

Anonymous Coward | more than 6 years ago | (#24313529)

This attack vector has been around for /years/. Just look at the list of affected systems. Some friends and I had stumbled on this a few years ago (yes, and the fact that you can insert yourself as an authoritative nameserver for that domain,) but we figured it was so obvious that it didn't need to be announced. That coupled with the fact that phishing wasn't really as popular back then. But now that the cat is out of the bag, as it were, you definitely want to patch your machines if they have not been. This is mostly dangerous to people who use Nameservers of large ISPs (which admittedly is a large portion of the internet userbase.)

I guess this is just a wake up call that if you find such large flaws in network systems that could possibly affect millions, if not billions of users, that you should try to get the word out and get the products fixed beforehand.

Re:Here we go... (0)

Anonymous Coward | more than 6 years ago | (#24313613)

Some friends and I had stumbled on this a few years ago (yes, and the fact that you can insert yourself as an authoritative nameserver for that domain,)

Yeah, right. You found a reliable way to spoof DNS and didn't consider it a big deal. Do you have any other wet dreams you would like to share?

Re:Here we go... (1)

harlows_monkeys (106428) | more than 6 years ago | (#24313661)

No, you did not stumble on this years ago. What you stumbled upon has long since been fixed. This attack gets around those fixes.

Re:Here we go... (2, Informative)

afidel (530433) | more than 6 years ago | (#24313953)

Most large ISP systems are already patched as they were part of the insider group that got the patches before they were publicly announced. As of yesterday Comcast had some unpatched DNS servers and so did AT&T wireless, but those were the only ones I had seen reported as being unpatched.

Re:Here we go... (3, Insightful)

Darkness404 (1287218) | more than 6 years ago | (#24313005)

This has to be the worst time ever to be a web surfer.

Ummm... No. Today I can easily surf the 'net with just about every ad blocked, have Flash blocked when I want it to, but re-enable it for say, YouTube, all at the click of a mouse. I can use an OS and browser that is free and open source. I can surf 100% anonymously easily. I can download every video game I played as a child in less than an hour. And I can hear just about any song I ever would want to hear in less than a minute.

Sure, some things suck today, BT throttling, the ISP's "No-Usenet" crusades, but all in all, it is a better time than the very early 2000s or the late 90s.

Re:Here we go... (4, Funny)

Vectronic (1221470) | more than 6 years ago | (#24313055)

"And I can hear just about any song I ever would want to hear in less than a minute."

Shit, you should check out some of the songs that are longer than a minute, there's some good ones out there, but, yes...those quick little punk ditties are good too.

Re:Here we go... (2, Funny)

Mordok-DestroyerOfWo (1000167) | more than 6 years ago | (#24313149)

Maybe he just speeds them up so they fit to a nice round minute. I for one would love to hear Freebird sped up so it lasts a minute.

Re:Here we go... (4, Interesting)

Vectronic (1221470) | more than 6 years ago | (#24313257)

lol... you should try it, then you wouldnt think so... I just did (in Sound Forge)... cut it down to 1:08, its just noise... cutting it down to 50% is alright though (4:35)... but somewhere around 65% (5:57) is about right, sounds kinda "proper".

Re:Here we go... (1)

Anpheus (908711) | more than 6 years ago | (#24313947)

Wow that is...

*head-desk* Whoa, uhm. What was I going to post? *looks at winamp* Why was I playing Freebird?

Google (5, Funny)

bdasd5 (1257940) | more than 6 years ago | (#24312699)

And here I am, thinking I was on Google.

Re:Google (1)

hostyle (773991) | more than 6 years ago | (#24312865)

Lookout! The DNS rockstars are coming for YOU!

The Book Of Internets, Chapter Three, Verse Twelve (5, Funny)

Aussenseiter (1241842) | more than 6 years ago | (#24312701)

And lo, all unpatched websites were rendered unto Goatse.

Re:The Book Of Internets, Chapter Three, Verse Twe (0)

Anonymous Coward | more than 6 years ago | (#24312783)

Welp, thats it. Might as well give up. They've won.

Re:The Book Of Internets, Chapter Three, Verse Twe (4, Informative)

Bryansix (761547) | more than 6 years ago | (#24312797)

It doesn't work that way. DNS local servers are either run by a corporation or by your ISP. Either one could be hacked now. So it's not if the website is patched. It is if the DNS server your computer is using is patched.

Re:The Book Of Internets, Chapter Three, Verse Twe (3, Insightful)

rs79 (71822) | more than 6 years ago | (#24313241)

Um... even if you run your own caching server, if your ISP runs a "transparent" web proxy it will do its own dns. You may in fact run DJB which is immune from this bug, but if your ISP runs an unpatched dns server you'll still be scrod despite running your own caching server.

Slick huh?

They need to take the dns lookup out of the web proxies.

Re:The Book Of Internets, Chapter Three, Verse Twe (3, Insightful)

blincoln (592401) | more than 6 years ago | (#24313565)

They need to take the dns lookup out of the web proxies.

The problem with doing that would be that it would then be impossible (at least using current DNS software, as far as I know) to allow clients on an internal network to have limited internet access without allowing them to perform DNS tunneling (and thereby upgrade their internet access to "full").

Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains...", "clients may only look up X distinct subdomains each of Y domains every Z hours" then the picture would probably change.

BIND 9 named views for access control (3, Interesting)

DragonHawk (21256) | more than 6 years ago | (#24313727)

Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains..."

I think you might be able to do that with the "views" feature of ISC BIND v9 named, although I've never tried. I know you can define ACLs for clients and control how they see the DNS using the ACL. You should be able to define forwarding zones for the domains you want to work, and blackhole everything else. I think.

http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#view_statement_grammar [isc.org]

Re:The Book Of Internets, Chapter Three, Verse Twe (4, Informative)

LostCluster (625375) | more than 6 years ago | (#24312803)

unpatched websites

Have you been following this story. It's not sites that need the patch, it's DNS servers. Site owners are powerless if the ISPs fail to protect their domain name from the an entry leading to the spoof site's IP address.

Re:The Book Of Internets, Chapter Three, Verse Twe (1)

Aussenseiter (1241842) | more than 6 years ago | (#24312853)

Slip of the digital tongue while attempting to make a quick funny. Please don't hurt me!

Re:The Book Of Internets, Chapter Three, Verse Twe (1, Insightful)

Anonymous Coward | more than 6 years ago | (#24312905)

My understanding is that it's DNS resolvers, not servers, which need to be patched.

Now if your windoze box doesn't do its own resolution, it forwards all requests to a caching resolver (e.g. at your ISP) then your ISP's resolver needs to be patched. Or if they run DJB's dnscache, it's not vulnerable because DJB recognised the problem years ago.

DNS sploit result (2, Funny)

hostyle (773991) | more than 6 years ago | (#24312723)

%> /usr/bin/treaceroute fruity.stuff

traceroute to fruity.stuff (1.2.3.4), 30 hops max, 42 byte packets
evil bit detected. re-routing ...

I know (4, Funny)

Daimanta (1140543) | more than 6 years ago | (#24312819)

I exploited this and let a huge cache of people visit my site(127.0.0.1) in stead of the site they wanted to go. It was kickass.

Re:I know (3, Funny)

Anonymous Coward | more than 6 years ago | (#24313707)

HAHA, fool! now that I know your ip address, I shall soon hack you into oblivion!

Re:I know (4, Funny)

Anpheus (908711) | more than 6 years ago | (#24313959)

Don't worry, I just disabled his intern

[CARRIER LOST]

And the "fix" isn't (0)

Anonymous Coward | more than 6 years ago | (#24312843)

And do please forgive me if I'm under the impression that the supposed "fix" really isn't one.

Re:And the "fix" isn't (3, Interesting)

cortana (588495) | more than 6 years ago | (#24312941)

The fix is DNSSEC.

Re:And the "fix" isn't (1)

LostCluster (625375) | more than 6 years ago | (#24313103)

Ever think that the government would let us have an unhackable Internet-used protocol for anything? If it was all secure, how'd the NSA get in?

Re:And the "fix" isn't (1)

Tiber727 (1324993) | more than 6 years ago | (#24313827)

They used the key in the magnetic container under the bumper of Al Gore's car.

Re:And the "fix" isn't (4, Interesting)

_Knots (165356) | more than 6 years ago | (#24313621)

DNSSEC is a steaming pile, though after thirteen years, many RFCs -- each of which read "This Time For Sure!" -- it may in fact be workable.

It is _a_ fix to this problem, but there are many simpler fixes that seemingly are being discarded for reasons I don't quite understand -- perhaps more full threat models are the target problem, but securing DNS doesn't make sense if we're then going to use HTTP to the addresses resolved! On the flip side, if we were using TLS everywhere, then dicking with DNS amounts to a DoS, which is much less powerful than the arbitrary redirection attacks we have now.

One such simpler fix is using EDNS0 to add a nonce RR (goes out in the Query, comes back in the Additional section). And while EDNS0 is subject to rollback attacks, DNSSEC depends on EDNS0. So that's not an excuse not to use it.

DNSSEC today (1)

DragonHawk (21256) | more than 6 years ago | (#24313821)

The fix is DNSSEC.

DNSSEC won't solve the present problem. Almost nobody has deployed it. In particular, the root zone does not use it, and I haven't seen mention of any GTLD or ccTLD zone doing so, either. Certainly not the big three (.COM, .NET, .ORG).

I am not saying cryptographically securing DNS is not a good idea. It is, and indeed, is the only viable long-term fix. I'm just saying that DNSSEC is not magic dust.

Re:DNSSEC today (1)

Anpheus (908711) | more than 6 years ago | (#24313967)

Hey-oh! .ORG is switching to DNSSEC.

Also, several country level TLDs use it.

DNS Glue poisoning was already known... (2, Informative)

nweaver (113078) | more than 6 years ago | (#24312851)

The interesting thing, DNS glue (additional) poisoning WAS known, just not widely. EG, the SECOND hit for "dns glue poison" in Google gets http://lists.oarci.net/pipermail/dns-operations/2006-May/000537.html [oarci.net] .

Quoting Emin Gun Sirer:
Incidentally, the client should be wary of trusting glue records unconditionally, as they are non-authoritative. A well-known cache poisoning attack works by tricking clients to believe glue records for all time and for all queries. Glue should be trusted for only the lookup in question for only the duration of that lookup. We'll assume that the clients treat glue properly (even though many do not).

Thus it was already known, two years ago, that trusting Glue records is "well-known cache poisoning attack". Just apparently, not well known enough by the authors of Bind, Microsoft's DNS server, Cisco, etc.

Re:DNS Glue poisoning was already known... (0)

Anonymous Coward | more than 6 years ago | (#24312909)

I knew I shouldn't have sent all those trojans to the glue factory... Now we have to deal with them infecting our DNS servers...

Re:DNS Glue poisoning was already known... (1)

pecosdave (536896) | more than 6 years ago | (#24312979)

Trojans to a glue factory..... .....are you playing practical jokes on your hooker?

Re:DNS Glue poisoning was already known... (2, Funny)

harlows_monkeys (106428) | more than 6 years ago | (#24313209)

That's not the attack. Try again.

Re:DNS Glue poisoning was already known... (2, Insightful)

szap (201293) | more than 6 years ago | (#24313419)

No, but it's a "feature" that makes the attack possible. Turn it off, or make it stricter, and the attack falls apart.

Re:DNS Glue poisoning was already known... (5, Insightful)

Anonymous Coward | more than 6 years ago | (#24313277)

Congratulations, you confused the mods. Bailiwick checking was added to all DNS resolvers in response to glue poisoning and made cache poisoning through spoofed glue records very difficult. The current problem is that the typical filter rules are insufficient for stopping a glue poisoning attack which appears to come from the authoritative server: Kaminsky found a way around the glue poisoning countermeasure. This means that a very dangerous kind of attack which was thought to be defeated is now possible again.

Re:DNS Glue poisoning was already known... (2, Insightful)

nweaver (113078) | more than 6 years ago | (#24313495)

Read the quotation again...

Emin Gun Sirer: "Glue should be trusted for only the lookup in question[Emphasis added] for only the duration of that lookup.

This says "No Bailiwick checking at all": glue (additional) records should NEVER be cached. Period.

Re:DNS Glue poisoning was already known... (1)

Martin Blank (154261) | more than 6 years ago | (#24313379)

The problem is that glue records are often used to pass the addresses of nameservers required to resolve the domain in question. If that glue record can be passed back with a false address to the nameserver, the entire domain can now be controlled. If you can pull this off with a TLD, then the attack becomes much more serious. It appears at first glance that in addition to TTL restrictions (com has a TTL of two days), bailiwick limitations may limit these kinds of attacks (com, for example, is served off of [a-m].gtld-servers.net). Even if bailiwick limitations wouldn't stop this case, it would take probably tens of thousands of days -- and hence many years -- to pull this off, and that's if you got the response just perfect. If there's a way to have a DNS server ignore a TTL or drop it from the cache and necessitate a lookup, though, there could be some more promise in this route.

Re:DNS Glue poisoning was already known... (4, Informative)

blueg3 (192743) | more than 6 years ago | (#24313515)

It only works because the DNS server caches the result of the glue record, against the recommendation of the above writer.

The glue record is necessary if, say, you need to provide the address of a nameserver when you provide the name of the authoritative nameserver for a query. You should use that glue record for that query only.

What happens is that an attacker queries lbixds.google.com (or some other nonexistent domain) and then sends the server he issued that request to a response to that query that also has a glue record giving a false address for ns.google.com. If the DNS server only used that false address for resolving lbixds.google.com, cached lbixds.google.com, and left it at that, then lbixds.google.com would be the only entry the attacker could poison -- basically useless. However, the DNS server caches the glue record giving the address for ns.google.com, too.

Re:DNS Glue poisoning was already known... (1)

g0at (135364) | more than 6 years ago | (#24314057)

... and then sends the server he issued that request to a response to that query that also has a glue record...

I don't understand what you mean there; I'm presuming you meant to say "...and the server issues a response to that query that also has a glue record..." In any case, I don't understand why a properly-designed resolver would pay any heed to such a reply. If it's asking the google.com authority to resolve "lbixds", and it receives an answer, why would it also expect (and cache) an unsolicited answer for the domain "ns" (in your example)?

-b

Re:DNS Glue poisoning was already known... (0, Redundant)

Lost Race (681080) | more than 6 years ago | (#24313381)

Bind

FYI, that's not a proper name, it's an acronym for "Berkeley Internet Name Daemon", and should properly be written as "BIND".

BIND is not a demon (2, Informative)

DragonHawk (21256) | more than 6 years ago | (#24313675)

it's an acronym for "Berkeley Internet Name Daemon"

Actually, BIND stands for "Berkeley Internet Name Domain". Berkeley did the seminal work for the original DNS implementation, and that's what they called their idea. BIND is a suite which includes a stub resolver, some utilities, and named (name daemon). (Along with some other stuff, now.)

If you want to get fancy, "ISC BIND named" is the proper name of the software we're talking about. ISC is the company, BIND is the product, named is the program.

See: http://www.isc.org/sw/bind/index.php [isc.org]

Meh - no big deal. (1)

pecosdave (536896) | more than 6 years ago | (#24312927)

If you use Verizons DNS you wont be able to tell the difference anyways. Seriously, I don't know if Verizon is paid to redirect DNS request or they just have really crappy security/maintinance on them.

I can't contact ftp.debian.org this last 2 days (0)

Anonymous Coward | more than 6 years ago | (#24312967)

is it related?

Re:I can't contact ftp.debian.org this last 2 days (1)

Trogre (513942) | more than 6 years ago | (#24314241)

* To: debian-mirrors-announce@lists.debian.org, debian-infrastructure-announce@lists.debian.org, debian-devel-announce@lists.debian.org, debian-user@lists.debian.org
    * Subject: ftp.debian.org update
    * From: Josip Rodin <mirrors@debian.org>
    * Date: Mon, 03 Dec 2007 20:52:00 +0100
    * Message-id: <E1IzHKi-0007AN-MH@keid.carnet.hr>
    * Mail-followup-to: debian-devel@lists.debian.org
 
Hi,
 
We're going to be changing ftp.debian.org setup a bit... but first,
a friendly reminder.
 
Many people seem to think that ftp.debian.org is the canonical location of
Debian packages and that it will be best for them to use that site for apt
or for mirroring. This is *not true*.
 
ftp.debian.org is merely one of several servers that get updated from an
internal Debian server. That address is presently located on a single server
in the United States, and it still exists mainly for backwards
compatibility.
 
In the future, it may get services reduced, or shut down, or converted into
a globally load-balanced name, or whatever. Please don't use it.
 
If you're using it now, please switch to a country-based DNS name
such as ftp.us.debian.org, ftp.ca.debian.org, ftp.uk.debian.org, ...
The list of those servers is at http://www.debian.org/mirror/list
...
 
--
Josip Rodin
mirrors@debian.org

Y2K 2.0? (1)

oneal13rru (1322741) | more than 6 years ago | (#24313053)

Oh noes, the world is going to crash down around us! Just saying, why overreact? If it isn't one thing, it's going to be something else, and as usual, I'm fairly sure the best solution is to grin and bear it, or to round up a digital posse and fix the little tards.

Unclear on the concept (2, Insightful)

DragonHawk (21256) | more than 6 years ago | (#24313771)

Oh noes, the world is going to crash down around us! Just saying, why overreact?

A problem you ignore will have full impact. A problem you prepare for and take counter-measures against is prevented from having a serious impact. That's the whole point.

We spent great effort fixing Y2K bus, thus prevented the bugs from causing serious damage. Therefore, you conclude, we should not have fixed the Y2K bugs.

I guess, since seat belts have saved lives, we should not wear them.

Get it now? :-)

See if you're vulnerable (4, Informative)

neokushan (932374) | more than 6 years ago | (#24313061)

There's a tool on the site below that apparently checks if the DNS you're currently using is vulnerable to such an attack. I checked my work DNS and my home DNS - both were fine. Apparently OpenDNS is secure as well, so there's probably nothing to worry about.

http://www.doxpara.com/ [doxpara.com]

Re:See if you're vulnerable (5, Informative)

maXXwell (172246) | more than 6 years ago | (#24313333)

The DNS OARC (http://dns-oarc.net) has an improved version:

http://entropy.dns-oarc.net/test/ [dns-oarc.net]

Re:See if you're vulnerable (1)

hal9000(jr) (316943) | more than 6 years ago | (#24313401)

Bugger. My Verizon DNS servers have great TXID randomness and poor source port randomness.

Re:See if you're vulnerable (2, Interesting)

afidel (530433) | more than 6 years ago | (#24314203)

Yeah, they're probably behind a firewall with PAT since Verizon was one of the ISP's involved in the private patch effort AFAIK. The problem is the DNS client/server patches are broken most firewalls and this was not known till people started testing after the patches were publicly released. You can use OpenDNS or L3's resolvers as I know those are patched and NOT behind a PAT firewall and are publicly available.

Re:See if you're vulnerable (2, Informative)

AnyoneEB (574727) | more than 6 years ago | (#24313351)

He also links to a way to check from the command line: porttest.dns-oarc.net -- Check your resolver's source port behavior [dns-oarc.net] . That method also allows you to test DNS servers other than the one you are using, so it provides a simply way to tell if your ISP has fixed their servers yet without changing your own config. The sidebar on doxpara just shows a 404 for me.

Re:See if you're vulnerable (3, Informative)

gQuigs (913879) | more than 6 years ago | (#24313423)

So.. What's their IP?

It looks like 66.240.226.139 to me...

Re:See if you're vulnerable (1)

Rigrig (922033) | more than 6 years ago | (#24313719)

Seems my ISP's DNS violates RFC 1149.5: It always uses port 5353 instead of port 4.

Guess now there's no need (2, Funny)

al0ha (1262684) | more than 6 years ago | (#24313087)

to watch the Black Hat DNS vulnerability webcast tomorrow. My only question is, what took so long?

Oh my. (0)

Anonymous Coward | more than 6 years ago | (#24313107)

Prepare to enter teh suck.

I digg! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24313121)

I'm very glad to see this story posted here on digg. I'm also quite happy with the new layout digg released this morning... it's better than ever, what with its new AJAXified comments.

Omg, do you know what would be awesome? Let's poison dns caches so that slashdot's hostname resolves to digg's servers. Slashdot readers are so stupid that they wouldn't even notice the change!

Viva le digg, cause we here at digg are fracking cool!

More edifying than TFA's script (3, Informative)

laburu (926935) | more than 6 years ago | (#24313455)

Re:More edifying than TFA's script (1, Funny)

PRMan (959735) | more than 6 years ago | (#24313601)

This link is in French. I'd rather read scripts. At least they're in Geek.

Use djbdns! (2, Interesting)

Neanderthal Ninny (1153369) | more than 6 years ago | (#24313489)

Even though it is not as popular as BIND but djbdns doesn't have this vulnerability. Remember Dan J Bernstein had the original idea in 2002 about this issue and Dan Kaminsky and Paul Vixie looked into this and found these vulnerabilities.

Re:Use djbdns! (1, Insightful)

Anonymous Coward | more than 6 years ago | (#24313787)

Please understand that there is a downside to massively randomizing your source ports -- you use a lot more of them! File descriptor consumption->exhaustion is an issue that a lot of folks are running into with the patched versions of BIND. People running djbdns no doubt ran into similar problems years ago and had to deal with them too.

So, before you jump all over ISC about dropping the ball, understand that a capacity/security tradeoff was made based on an assumption that it was difficult to exploit this knownweakness. Kaminsky discovered a not-so-difficult way to exploit it, and that's why the landscape changed.

If DNSSEC were implemented, this would all be a non-issue. After the immediate crisis subsides, expect a lot of recriminations and finger-pointing with respect to why DNSSEC is still undeployed after all this time.

DJBDNS (1)

vrrrtk (1132459) | more than 6 years ago | (#24313733)

Given that's a vulnerability in the DNS protocol I really wonder if the dnscache (djbdns) is affected by this one. Because it's said that djb's dns suite is immune to any type of cache poisoning attack. I better test it.

Re:DJBDNS (1)

afidel (530433) | more than 6 years ago | (#24314237)

It's not unless it's behind a PAT firewall, you'll need to put it in the DMZ for most firewalls. IPTables is Masquerade mode and PF can both be made to behave in a manner that doesn't remove the randomization of ports that DJBDNS and patch BIND and MS servers perform.

Only 1 thing comes to mind (0)

Anonymous Coward | more than 6 years ago | (#24313791)

... what a fucking douche bag

Help Please (1)

bobetov (448774) | more than 6 years ago | (#24314005)

Hey all, I see lots of comments re: OpenDNS as a good solution if your ISP sucks (as mine does) and has not patched.

But I can't trust my DNS to resolve correctly to OpenDNS.com or whatever.

Anyone got dotted quads for me?

In Soviet Russia (1)

Archangel Michael (180766) | more than 6 years ago | (#24314029)

DNS Cache poisons you.

Sorry, I had to.

Use OpenDNS if your ISP is vulnerable (5, Informative)

duplicate-nickname (87112) | more than 6 years ago | (#24314033)

I used one of the tests below and found that my ISP's DNS servers were vulnerable. Now I am using the OpenDNS [opendns.com] servers on all of my clients instead:

208.67.222.222
208.67.220.220

Their servers are not vulnerable, and you can create an account to enable things like antiphishing at the DNS level (much better idea then a browser plug-in).

If you find that your ISP's routers are vulnerable, your best bet is switch to OpenDNS...or just run your own caching server.

Microsoft's hamfisted "patch" (4, Informative)

bizitch (546406) | more than 6 years ago | (#24314039)

In case anyone is dumb enough to use a Microsoft DNS server as a authoritative internet DNS server -

MS has released two lovely patches -

KB951746 and KB951748

The problem with this fix is that it turns the DNS.EXE daemon into a UDP socket grubbing whore.

After the patch, the DNS.EXE daemon grabs no less than 2500 freaking UDP sockets.

This wreaks havoc on anything that - you know - needs UDP sockets on the same server.

So far Zonealarm, Blackberry BES and Sphericall VOIP software all break with this "patch"

Stay tuned for more fun to come ...

Re:Microsoft's hamfisted "patch" (1)

duplicate-nickname (87112) | more than 6 years ago | (#24314107)

It sounds more like Zonealarm, BES and Sphericall are broken. Why would they try to listen on a UDP port that is use? There are only 65,000+ ports available, why are they running into conflicts when only 2500 are in use? If the port is not in use, why are they not validating the data they are receiving through UDP?

Not to mention that similar conflicts are starting to show up on patched BIND servers that are running other services which rely on UDP.

Re:Microsoft's hamfisted "patch" (0)

Anonymous Coward | more than 6 years ago | (#24314161)

Authoritative DNS servers aren't relevant to this exploit; the exploit consists of forging responses to resolvers and thereby poisoning their caches.

Perhaps you meant something other than "authoritative internet [small "i", sic] DNS server". [Insert appropriate Princess Bride quote here]

help all the SOHO router people (2, Interesting)

paulbd (118132) | more than 6 years ago | (#24314045)

so, there are a lot of us in the following position, no doubt: we run a router (linksys, whatever) that gets DNS from our ISP. lets assume that the ISP is patched. our local machines use the router for DNS. do we need to patch the router? are its DNS request services even accessible to the external network? can it be compromised in the same way that the ISP DNS could be? i have been wondering this ever since news of this problem broke, and i have still not seen a clear answer.

Re:help all the SOHO router people (1)

duplicate-nickname (87112) | more than 6 years ago | (#24314061)

From my understanding, if you are using a DNS proxy on your router (which most SOHO routers seem to do now), then you might be vulnerable. I checked my 2wire (which has no option to turn off DNS proxy for DHCP clients) and they have not updated the firmware in forever. :/

See my post below about switching to OpenDNS instead.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?