New Hacker threat
- Thread starter redytrk
- Start date
People have been hijacking Web sites for years using the same DNS protocol flaw that was "recently discovered". One of the more amusing instances was back in the early 90's when the FBI hijacked a software pirate site, just days after the same pirate group had hijacked whitehouse.gov.
Before the World Wide Web it was all FTP, gopher, finger, whois, and other network tools and applications. There was no such thing as a browser, so name resolving wasn't a big deal. Everything was done with IP addresses, anyway. Ever since the first Doman Name Server went live in conjunction with the invention of the WWW, there was a known problem with the way DNS did things. Initially all DNS servers were public, but the known DNS Attack flaw quickly had corporations and others moving to their own private DNS servers. The firewall out front and the ISP is still vunerable, but at least the corporate DNS server behind the firewall is safe.
Attacks against DNS, and particularly the concept of DNS cache poisoning has been known for a long, long time, with all the gory details first being publicly released back in 1989, although they had been known and discussed at length during the codifying of the original DNS RFC's (Request for Comment, the strict protocols, rules and definitions) that were finalized and last updated in November 1987.
DNS was never designed with security in mind, and therefor has a number of security issues. One class of many vulnerabilities is DNS cache poisoning, which tricks a DNS server into believing it has received authentic information when, in reality, it has not. This "newly discovered" threat is merely a different take on DNS cache poisoning with a few additional, very inventive ways at exploiting the vunerability, but it's still basically the same exploit.
The original DNS protocol is described in RFC 1034 and RFC 1035, and is an excrutiatingly dry read unless you are a geek.
RFC 1034 - Introduces domain style names, their use for Internet mail and host address support, and the protocols and servers used to implement domain name facilities.
RFC 1035 - Describes the details of the domain system and protocol, and assumes that the reader is familiar with the concepts discussed in a companion RFC 1034.
DNS responses are not cryptographically signed, leading to many attack possibilities. DNSSEC (DNS Security Extensions) modifies DNS in the RFC protocols to add support for cryptographically signed responses with both public and private key encruption, much like the SSL layers of your banking Web site. There are various extensions to support securing zone transfer information as well. They've been working in DNSSEC for more than 15 years, and I wouldn't be surprised if it's not another 15 before they finally get it all hammered out. That, or a third party software maker will come out with a better system and beat 'em to the punch.
Back in 1993 the IETF (Internet Engineering Task Force, a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet) undertook the task of trying to figure out a way to solve the DNS flaw without having to completely redo the entire Internet infrastructure. Backwards compatibility and co-existence with "insecure DNS" was listed as an explicit requirement. Like everything else on the Internet that gets done by committee via RFC's (Request for Comment), things move deliberately, albeit slowly.
In 2004 these DNS Security Extensions (DNSSEC), the "recently discovered" exploit itself, and the progress at getting it fixed was openly discussed in RFC 3383 ( http://www.ietf.org/rfc/rfc3833.txt ). The recent coordinated effort at releasing the patches is the long-awaited result of the work of the IEFT and it's groups.
Incidentally, the Flying J ISP's DNS servers is still wide open and unprotected (at least and until they ever get around to patching it), so you should never set it to "Obtain DNS Server Address Automatically" when using the J, or probably any other truck stop ISP.
The easiest way to secure yourself to make sure the URL address you use actually takes you to the place you want to go instead of a hijacked site is to use a secure DNS server.
In the article referenced above, they list 4.2.2.1 and 4.2.2.2 as DNS servers that are known to have been patched. Why, I have no idea, since those servers are well known to have not been patched and are not secure and are wide open (I just checked). A far better alternative is to simply use the OpenDNS servers at
208.67.222.222
208.67.220.220
For details on how to set your connection to use a specific DNS instead of obtaining one automatically from your ISP, go here and pick your hardware, then operating system.
https://www.opendns.com/start
OpenDNS, incidentally, is also responsible for Phishtank.com, a community-based effort that collects data on phishing sites. The data about scam sites is also fed to anti-phishing features built into Web browsers like Firefox.
Before the World Wide Web it was all FTP, gopher, finger, whois, and other network tools and applications. There was no such thing as a browser, so name resolving wasn't a big deal. Everything was done with IP addresses, anyway. Ever since the first Doman Name Server went live in conjunction with the invention of the WWW, there was a known problem with the way DNS did things. Initially all DNS servers were public, but the known DNS Attack flaw quickly had corporations and others moving to their own private DNS servers. The firewall out front and the ISP is still vunerable, but at least the corporate DNS server behind the firewall is safe.
Attacks against DNS, and particularly the concept of DNS cache poisoning has been known for a long, long time, with all the gory details first being publicly released back in 1989, although they had been known and discussed at length during the codifying of the original DNS RFC's (Request for Comment, the strict protocols, rules and definitions) that were finalized and last updated in November 1987.
DNS was never designed with security in mind, and therefor has a number of security issues. One class of many vulnerabilities is DNS cache poisoning, which tricks a DNS server into believing it has received authentic information when, in reality, it has not. This "newly discovered" threat is merely a different take on DNS cache poisoning with a few additional, very inventive ways at exploiting the vunerability, but it's still basically the same exploit.
The original DNS protocol is described in RFC 1034 and RFC 1035, and is an excrutiatingly dry read unless you are a geek.
RFC 1034 - Introduces domain style names, their use for Internet mail and host address support, and the protocols and servers used to implement domain name facilities.
RFC 1035 - Describes the details of the domain system and protocol, and assumes that the reader is familiar with the concepts discussed in a companion RFC 1034.
DNS responses are not cryptographically signed, leading to many attack possibilities. DNSSEC (DNS Security Extensions) modifies DNS in the RFC protocols to add support for cryptographically signed responses with both public and private key encruption, much like the SSL layers of your banking Web site. There are various extensions to support securing zone transfer information as well. They've been working in DNSSEC for more than 15 years, and I wouldn't be surprised if it's not another 15 before they finally get it all hammered out. That, or a third party software maker will come out with a better system and beat 'em to the punch.
Back in 1993 the IETF (Internet Engineering Task Force, a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet) undertook the task of trying to figure out a way to solve the DNS flaw without having to completely redo the entire Internet infrastructure. Backwards compatibility and co-existence with "insecure DNS" was listed as an explicit requirement. Like everything else on the Internet that gets done by committee via RFC's (Request for Comment), things move deliberately, albeit slowly.
In 2004 these DNS Security Extensions (DNSSEC), the "recently discovered" exploit itself, and the progress at getting it fixed was openly discussed in RFC 3383 ( http://www.ietf.org/rfc/rfc3833.txt ). The recent coordinated effort at releasing the patches is the long-awaited result of the work of the IEFT and it's groups.
Incidentally, the Flying J ISP's DNS servers is still wide open and unprotected (at least and until they ever get around to patching it), so you should never set it to "Obtain DNS Server Address Automatically" when using the J, or probably any other truck stop ISP.
The easiest way to secure yourself to make sure the URL address you use actually takes you to the place you want to go instead of a hijacked site is to use a secure DNS server.
In the article referenced above, they list 4.2.2.1 and 4.2.2.2 as DNS servers that are known to have been patched. Why, I have no idea, since those servers are well known to have not been patched and are not secure and are wide open (I just checked). A far better alternative is to simply use the OpenDNS servers at
208.67.222.222
208.67.220.220
For details on how to set your connection to use a specific DNS instead of obtaining one automatically from your ISP, go here and pick your hardware, then operating system.
https://www.opendns.com/start
OpenDNS, incidentally, is also responsible for Phishtank.com, a community-based effort that collects data on phishing sites. The data about scam sites is also fed to anti-phishing features built into Web browsers like Firefox.
Sorry, I'm kind of a network geek.
Short answer, the DNS attack has nothing to do with how you connect to the Internet.
Long answer...
An ISP is an Internet Service Provider, so yeah, if you access the Internet through Verizon, they are providing Internet acess for you. But while it may be an ISP, the difference is how you connect to the ISP. You can connect to an ISP via a phone line (dial-up or DSL), a cable or satellite modem, WiFi, or with an Aircard or Smartphone through your cell phone carrier.
WiFi connections can be spoofed, to make you think you are connecting to the Flying J, for example, but in reality you are connecting to a laptop in a truck 3 rows over. Everything you do on the Intenet goes through, and can be seen and captured, by the laptop. This really isn't a big issue, but it's something to be aware of. There are safeguards in the computer to help prevent such a thing, and to alert you if it thinks there is a possibility of it going on.
ISP connections through the phone line, like dial-up and DSL, those are hard wired connections and cannot be spoofed. The lines can be tapped, just like a voice phone call, but that's not something many people would do.
Same with cable and satellite modems, they are hard wired and cannot be spoofed.
Aircard cell phone connections are via a radio signal, and while they are not going to be spoofed, the radio signals can be intercepted and monitored, but most of that traffic is scrambled and encrypted, so anyone intercepting it won't get much use out of it.
But these are just the connections to your ISP, to get you onto the Internet. Connecting to the Internet has nothing to do with what happens to you after you get there. That's where the DNS comes into play. And for that matter, if you never open your Web browser and you instead use non-Web clients and tools, like a Usenet Newsreader, an FTP client, and an external e-mail client like Eudora, resolving Domain Names via DNS is a non-issue.
But, if you use your Web browser, then the DNS Attack vunerability is a real issue, regardless of how to connect to the Internet, WiFi, Aircard, Cable, doesn't matter.
Every computer on the Internet has an IP address (Internet Protocol address), like a phone number. It's in the form of xxx.xxx.xxx.xxx, or, as in the case of the EO Web site, it's 69.20.16.56. Every data packet that leaves your computer has your IP address stamped on it. The bazillions of data packets running around the aethernet all have a FROM: and TO: address stamped on them.
It's a lot easier and people friendly to remember something like [noparse]http://www.expeditersonline.com[/noparse] than it is to try and remember 69.20.16.56, but either one will get you to Expediters Online.
When you type [noparse]http://www.expeditersonline.com[/noparse] into your browser's URL address bar, that text is sent to a Domain Name Server (DNS server) where it looks up [noparse]http://www.expeditersonline.com[/noparse] and sees that it corresponds to (resolves to) the IP address of 69.20.16.56, so your computer is sent to 69.20.16.56. (or the server located at, 122704-www1.expeditersonline.com)
The best analogy I can come up with is Web sites and their corresponding IP address is like Voice Dialing on your cell phone, and your phone book is the DNS server. You say, "Call Mom," and the phone matches up what you said with what it can find in your phone book, then calls the number. When you input [noparse]http://www.microsoft.com[/noparse], the computer goes to it's own address book (a DNS server somewhere) and looks up the phone number (65.55.21.250) for Microsoft, then dials that number. Same thing. In the URL address bar of you browser, you can type 66.55.21.250 and it'll take you right to Microsoft's site without youy having to waste time going through a DNS server.
Sooo, for example, let's say I have a spare server sitting at home, and I do a site rip (copy most or all of the Web pages) from EO, and put it all on my server. Then, I do the DNS cache poisoning attack on as many DNS servers as my computer can get its grubby little bytes on, including the ones at
NS3.EXPEDITERSONLINE.COM and
NS4.EXPEDITERSONLINE.COM
as well as the ones at
NS.RACKSPACE.COM and
NS2.RACKSPACE.COM (where EO's servers are hosted)
and change the address for EO to be xxx.xx.xx.xxx (the IP address of my own computer) instead of 69.20.16.56. Then, whenever anyone out there types in [noparse]http://www.expeditersonline.com[/noparse] and their computer checks any of the DNS servers that I have attacked and changed, they will be sent to my computer instead of EO's server. They'll log on to EO and it'll look like EO, only it'll be my computer instead.
And since those servers get their data from the above mentioned DNS servers at EO and Rackspace, the attack will be populated to other DNS servers that are otherwise secure. Pretty soon most or all of the Web traffic going to and from EO will be going to and from my server, instead. I'd get everyone's password. Golly.
But I could also rig up a special message, like a popup window, that asks users to confirm personal information, and some would fall for it.
That's not really that big a problem for users of OE, but it sure could be a problem for users of a bank, or Paypal, or Amazon.com.
And it won't matter how you connect to the Intenet, Aircard, WiFi, cable or dial-up, all this DNS shenanigans happens after your connected. And that's why, with whatever connection you use to get on the Internet, you need to go in to the Internet Connection preferences and set a static DNS server address instead of letting the ISP give you one automatically. If your ISP, be it Road Runner, Verizon Wireless, or the Flying J, has their DNS servers compromised, and you try to access one of the redirected DNS IP addresses, you won't end up where you think you are, and you won't even know it.
Last edited: