March 18, 2005
DNS Posioning and Denial Of Service Attacks
DNS poisoning is a whole different attack method, and much more subtle than a DOS attack. When a cracker attempts to poison a DNS server, he or she tries to change the IP record for a specific domain, sending the requestor to a very different website, than the one you intended to access. In some cases, it is a completely different website or it could be a fake version of a known and usually trusted website. Usually, the cracker does this by posing as a company official with the authority to change the destination of a Domain name.
The Weak Link
The DNS request translation process is also a weak link in the Internet's infrastructure, as every Internet request (anyone browsing to a given website) has to start with a DNS server. Unless the IP is known locally, the request will be sent to a DNS server which is usually, a logically close location (on the same subnet). Criminal hackers have known for some time, that rather than flooding a specific domain and effectively hiding it from the rest of the world, in what's known as a DOS (denial-of-service attack), they can either change the DNS record or cripple the DNS system all together. The authoritative DNS server for that Domain (unless attacked) would still be sending out the correct information and the incorrect information would eventually be cleared out. With DNS servers scattered across the entire planet, stopping that entire infrastructure is less than likely as the new data would eventually propagate to different DNS servers. DNS servers share their information with other DNS servers, but only maintain a smaller subset of that information as each server has a limited cache for which to store such information. When a given DNS server receives a query that it cannot immediately answer, it either asks another DNS server if it has the address and the process continues until a DNS server that has the address responds. The answer propagates back to the original DNS server and the client browser then attempts a connection to, and then makes an HTTP request from that address.
DNS Cache Poisoning
Another, even more sophisticated technique involves corrupting or “poisoning” a domain name system table by replacing a legitimate Internet address with a fraudulent site address. When this happens, a worm, spyware, a Web browser-hijacking program, or other malware can be downloaded to the user's computer from the rogue location. According to a recent TechTarget article, once an end user's computer has been infected with the nefarious code, all future requests by that user's computer for the compromised URL will be redirected to the bad IP address -- even if the "victim" server resolves the problem at its site. Cache poisoning differs from another form of DNS poisoning, in which the attacker spoofs valid e-mail accounts and floods the inboxes of administrative and technical contacts. However, the objective is always the same, spoofing legitimate sites in order to profit from unwitting visitors.
Consider Panix, Amazon, and Google
January 15, 2005, an error by Melbourne IT (an Australian company that manages Internet Domain Name Registrations) allowed fraudsters using stolen credit cards to take control of Panix.com, Public Access Networks' Internet Domain. The mistakenly changed IP record deprived some Panix customers of e-mail access for two days, and shone a light on what some contend are holes in the system for managing Internet Domain Transfers. Ownership of the company was changed from New York, to Australia, and requests to reach the panix.com server(s) were redirected to the United Kingdom. E-mail to the domain was redirected to Canada.
Just for fun
German police reported on September 07,2004, that two days earlier, a 19-year-old from Helmstedt, Lower Saxony, has admitted to hijacking the domain eBay.de, the German ebay website; the DNS records change was reportedly done “just for fun”. The teenager further stated that he had jus read an article on how to make DNS transfers and decided he would give it a try. The domain hijack attack happened at the end of August when visitors to the eBay.de site were redirected to a different DNS server, meaning that they could not access auctions. Other known attacks have targeted Amazon.com, and Google.com. There were no immediate reports of identity theft having resulted from these specific events.
A Solution
Unfortunately, just watching the address bar on your Internet browser won't necessarily inform you of a hijack event. The URL and even the spoofed website, might look just fine unless you know exactly what to look at on that site. In order to remove pharming as a threat, servers would have to add another layer of authentication; they would need to prove their identity, and establish a trusted, secure link between your computer and the server. That would require the site to obtain an SSL certificate from a certificate authority, such as VeriSign. According to Eschelbeck, most Internet browsers already have the built-in-ability to request a server certificate from websites which they connect; the delay is in getting (mostly non-commercial) website and mail servers to begin issuing certificates.
Sites that already offer certificates are generally financial, or commercial and want to be sure they know who is connecting to them along with assuring customers that they are who you trust them to be. When you visit such sites, you will see a dialog box asking you if you want to trust the issuing certificate server and the certificate. If the name on the certificate doesn't match the site you're attempting to reach, you know that something is amiss, and hopefully, you not accept the certificate. Perhaps “your.bank.com” has been hijacked, on your next visit, your browser will know it's there is a problem based on the stored copy of the certificate you accepted on an earlier visit to “your.bank.com”. You would then be notified of the error and not log in to that (incorrect) site. There's a slight trade-off in login time, but the additional security is worth the delay. That being said, when surfing, always read any certificate before accepting it.
 |
Related:
Pharming for Your Identity
Phishing Hole Discovered in Internet Explorer
Internet Cookies
FTC Shuts Down Spyware Web Sites
Phishing Flaw in Alternate Browsers
 
|
