Expedite Trucking Forums - View Single Post

Turtle · 07-25-2008, 05:52 PM

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.

07-25-2008, 05:52 PM	#2 (permalink)
Turtle Senior Member Join Date: Apr 2006 Location: Murray, KY Zodiac Sign: Virgo Rating: Posts: 2,099	Re: New Hacker threat 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. __________________ Slow and steady, even in expediting, wins the race. ««««««««»»»»»»»» ««««««««»»»»»»»» What happens if a big *asteroid* hits the Earth? Judging from *exhaustive and repeated* realistic simulations involving a sledge hammer and a common frog, we can assume it will be pretty bad.