DNS Attack Writer a Victim of His Own Creation 196
BobB writes "HD Moore has been owned. Moore, the creator of the popular Metasploit hacking toolkit, has become the victim of a computer attack. It happened on Tuesday morning, when Moore's company, BreakingPoint, had some of its Internet traffic redirected to a fake Google page that was being run by a scammer. According to Moore, the hacker was able to do this by launching what's known as a cache poisoning attack on a DNS server on AT&T's network that was serving the Austin, Texas, area. One of BreakingPoint's servers was forwarding DNS (Domain Name System) traffic to the AT&T server, so when it was compromised, so was HD Moore's company."
Re:Did he take it well? (Score:5, Informative)
According to the article (you know the one that is linked above) he said this:
Correction to the article published (Score:5, Informative)
The reporter has published a correction [pcworld.com], which is also reflected on the Metasploit Blog [metasploit.com].
Along with everyone else in Austin (Score:5, Informative)
Since the attack wasn't on BreakingPoint, but rather than upstream DNS server, he pretty much just got swept up in the dragnet. These kind of attacks seem scarier than a direct attack, since you can do "everything right" with regard to patching, updating, firewalling, etc, and still get owned.
Retraction Posted (Score:5, Informative)
Re:Retraction Posted (Score:5, Informative)
Not so much a retraction, more a correction. The company were still a victim of the cache poisoning, it has just been made clear that they were a victim along with everyone else in Austin.
Re:DNS cache poisoning in the wild (Score:2, Informative)
When you are "outside", just make sure you are not using the DNS server provided by the hotel DHCP server. In Windows, simply set the ip addresses of your DNS servers to 208.67.222.222 and 208.67.220.220 (OpenDNS) and you should be safe.
Re:Good (Score:5, Informative)
Er, this isn't the same guy who discovered the DNS flaw.
Re:DNS cache poisoning in the wild (Score:5, Informative)
As I understand it, this kind of attack would be noticeable when attempting to use a secure (HTTPS) web connection, because the browser should throw up a certificate error. Is this true?
Yes, this is true. HTTPS connections require an SSL certificate which must be signed by a Certificate Authority (CA) that your browser trusts. Your browser ships with a database of CA certificates, and you can manually add your own if you want; any SSL cert signed by one of those CAs will be trusted, but any SSL cert signed by anybody else will display a warning message before allowing you to access the web site.
Unfortunately, there are legitimate HTTPS sites out there using self-signed SSL certificates. Chances are, you've probably seen one at some point, and you went ahead and accepted it anyway, because you figured the company is legitimate and they just skimped on getting an SSL cert signed by a real CA. I know I have. If DNS cache poisoning (or other techniques) can get your browser to think it's talking to a particular host when it really isn't, AND you accept an invalid SSL certificate, you're screwed.
Note that SSL serves two purposes: it encrypts data while it's being sent over the wire so nobody* can eavesdrop on the connection between your browser and the server, and it also provides authentication so you can be sure that your browser is really talking to the server it thinks it's talking to. Using a self-signed certificate (or a certificate signed by an untrusted CA) renders the second of these useless, but the data is still encrypted.
* And of course when I said "nobody"... There is a way to intercept SSL connections, but it requires that you install a special CA cert in your browser, which will make your browser trust whoever is intercepting the SSL connections. This makes it possible to set up a caching proxy server that can inspect and cache data being sent over HTTPS. This is crazy stuff you shouldn't think about.
Better checker is dnsentropy. (Score:4, Informative)
Re:DNS cache poisoning in the wild (Score:3, Informative)
Self-signed certificates (or more generally, certificates from a CA you don't already trust) are only vulnerable the very first time you see them -- after that you can certainly detect changes.
But generally speaking, if you're worried about identifying a remote entity and not just encrypting traffic, you *must* at some point transmit verification information out-of-band and trust the integrity of that transmission. Pre-installed CA certificates are one way to do this, but certainly not the only way, and probably not even the best -- they're just the currently most common low-end-user-cost method.
Re:In the words of the Bard ... (Score:3, Informative)
For tis the sport to have the engineer hoist with his owne petard.
Fixed it for you.
-- Olde English Grammar Nazi
Fixed it for thou.
Fixed it for thee.
Thou needest to learn thine conjugation [wikipedia.org] when thou useth an objective noun... eth.
I think I got something stuck in my teeth.
Re:Did he take it well? (Score:4, Informative)
Not true. I heard that a stand up comedian in London died on stage, and nobody noticed until the corpse went cold.
True - it was Tommy Cooper [independent.co.uk]
In 1984, once again in a packed London theatre, the big man clutched his chest and slumped to the floor, his trademark red fez clinging precariously to his outsize head. The audience, millions watching live on television at home and more than 1,000 packed into Her Majesty'sTheatre, roared their approval - thinking it was part of the act.
But the sound of the comedian gasping for breath, hauntingly amplified by his radio microphone, slowly stifled the laughter, as the crumpled clown fell grotesquely against the curtain.
Comment removed (Score:2, Informative)
Re:Did he take it well? (Score:2, Informative)
The quote in the original article has since been corrected (removed) by the original source, because it was a completely falsified quote.
djbdns (Score:2, Informative)