This is a note targeted at family and friends who might find that they are not able to connect to the Internet from July 9, 2012 onwards.
This only affects those whose machines were are running Windows or Mac OSX and have a piece of software called DNSChanger installed. The DNSChanger modifies a key part of the way a computer discovers other machines on the internet (called the Domain Name Server or DNS).
Quick introduction to DNS:
For example, you want to visit the website, http://www.cnn.com. You type this in your browser and magically, the CNN website appears in a few seconds. The way your browser figured out to reach the http://www.cnn.com server was to do the following:
a) The browser took the http://www.cnn.com domain name and did what is called a DNS lookup.
b) What it would have received in the DNS lookup is a mapping of the http://www.cnn.com to a bunch of numbers. In this case, it would have received something like:
http://www.cnn.com. 60 IN A 157.166.255.18
http://www.cnn.com. 60 IN A 157.166.255.19
http://www.cnn.com. 60 IN A 157.166.226.25
http://www.cnn.com. 60 IN A 157.166.226.26
c) The numbers you see in the lines above (157.166.255.18 for example) are the Internet Protocol (IP) number of the server on which http://www.cnn.com resides. You notice that there are more than one IP number. That is for managing requests from millions of systems and not having to depend only on one machine to reply. This is good network architecture. For fun, let’s look at http://www.google.com:
http://www.google.com. 59 IN CNAME www.l.google.com.
http://www.l.google.com. 59 IN A 173.194.38.147
http://www.l.google.com. 59 IN A 173.194.38.148
http://www.l.google.com. 59 IN A 173.194.38.144
http://www.l.google.com. 59 IN A 173.194.38.145
http://www.l.google.com. 59 IN A 173.194.38.146
http://www.google.com has 5 IP #s associated to it but you notice that there is something that says CNAME (stands for Canonical Name) in the first line. What that means is that http://www.google.com is also the same as http://www.l.google.com which in turns has 5 IP#s associated with it.
d) The beauty of this is that in a few seconds, you got to the website that you wanted to without remembering the IP # that is needed.
What is this important? If you have a cell phone, how do you dial the numbers of your family and friends? Do you remember by heart their respective phone numbers? Not really or at least not anymore You probably know your own number and a small close group (your home, your work, your children, spouse, siblings). Even then, their names are in your contact book and when you want to call (or text) them, you just punch in their names and your phone will look up the number and send out.
The difference between your cell phone directory and the DNS is that, you control what is in your phone directory. So, a name like “Wife” in your phone could point to a phone number that is very different from a similar name in your friend’s phone directory. That is all well and good.
But on the global Internet, we cannot have name clashes and that is why domain names are such hot things and people have snapped up pretty much a very large chunk of names during the dot.com rush in the late 1990s.
Now on to the issue at hand
So, what’s that got to do with this alarmist issue of connecting to the Internet from July 9, 2012?
Well, it has to with the fact that there as a piece of software – malware in this case – that got added to those running Windows and Mac OSX. In all computers, the magic to do the DNS lookup is maintained by a file which contains information about which Domain Namer Server to query when presented with a domain name like http://www.cnn.com.
For example, on my laptop (which runs Fedora), the file that directs DNS looks is called /etc/resolv.conf. This is the same for a Mac OSX file and I think it there is something similar in the Windows world as well. Fedora and Mac OSX share a common Unix heritage and so many files are in common.
The contents of my /etc/resolv.conf file is:
# Generated by NetworkManager
domain temasek.net
search temasek.net lan
nameserver 192.168.10.1
The file is automatically generated when I connect to the network and the crucial line is the line that reads “nameserver”. In this case, it points to 192.168.10.1 which happens to be my FonSpot wireless access point. But what is interesting is that my FonSpot access point is not a DNS server per se. In the setup of the FonSpot, I’ve got it to look up domain names to Google’s public DNS server whose IP #s are 8.8.8.8 and 8.8.4.4.
Huh? What does this mean? Simply put, when I type in http://www.cnn.com on my browser, that name’s IP# is looked up first by my browser asking the nameserver 192.168.0.1 which is the FonSpot will then return to my browser that it should go ask 8.8.8.8 for an answer. If 8.8.8.8 does not know, hopefully 8.8.8.8 will give an IP # to my browser to ask next. Eventually, when an IP # is found, my browser will use that IP # and send a connection request to that site. All of this happens in milliseconds and when it all works, it looks like magic.
What if you don’t get to the site? What if the entry in the /etc/resolv.conf file pointed to some IP # that was a malicious entity that wanted to “hijack” your web surfing? There is a legitimate reason for this. For example, when you connect to a public wifi access point (like Wireless@SG for example), you will initially get a DNS nameserver entry that belongs to the wifi access provider. Once you successfully logged into that access point, then your DNS lookup will be properly directed. This technique is called “captive portal”. My FonSpot is a captive portal btw.
The issue here is that those machines who have the malware DNSChanger have the DNS lookup being hijacked and directed elsewhere. See this note by the US Federal Bureau of Investigation about it.
It appears that the DNSChanger malware had set up a bunch of IP# to redirect maliciously all access to the Internet. If your /etc/resolv.conf file has nameserver entries that contain numbers in the following range:
85.255.112.0 to 85.255.127.255
67.210.0.0 to 67.210.15.255
93.188.160.0 to 93.188.167.255
77.67.83.0 to 77.67.83.255
213.109.64.0 to 213.109.79.255
67.28.176.0 to 67.28.191.255
you are vulnerable.
Here’s a test I did with the 1st of those IP#s on my fedora machine:
[harish@vostro ~]$ dig @85.255.112.0 www.google.com ; <<>> DiG 9.9.1-P1-RedHat-9.9.1-2.P1.fc17 <<>> @85.255.112.0 www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34883 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 464951 IN CNAME www.l.google.com. www.l.google.com. 241 IN CNAME www-infected.l.google.com. www-infected.l.google.com. 252 IN A 216.239.32.6 ;; AUTHORITY SECTION: google.com. 32951 IN NS ns2.google.com. google.com. 32951 IN NS ns4.google.com. google.com. 32951 IN NS ns3.google.com. google.com. 32951 IN NS ns1.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 33061 IN A 216.239.32.10 ns2.google.com. 33061 IN A 216.239.34.10 ns3.google.com. 317943 IN A 216.239.36.10 ns4.google.com. 33297 IN A 216.239.38.10 ;; Query time: 305 msec ;; SERVER: 85.255.112.0#53(85.255.112.0) ;; WHEN: Sun Jul 8 21:40:07 2012 ;; MSG SIZE rcvd: 242
Some explanation of what the is shown above. “dig” is a command “domain internet groper” that allows me, from the command line, to see what a domain’s IP address is. With the extra stuff “@85.255.112.0″, I am telling the dig command to use 85.255.112.0 as my domain name server and get the IP for the domain http://www.google.com. Currently 85.255.112.0 is being run as a “clean” DNS server by the those who’ve been asked to by the FBI.
Hence, what will happen on July 9th 2012 is that the request by FBI to give a reply when 85.225.112.0 is used, will expire. Therefore the command I executed above on July 8th 2012 will not return a valid IP number from July 9th 2012. While the Internet will work, there would be people whose systems have been compromised to point to the bad-but-made-to-work-OK DNS servers, will find that they can’t seem to get to any site easily by using domain names. If they instead used IP#s, they can get to the site with no issue.
A quick way to check if your system needs fixing is to go to http://www.dns-ok.us/ NOW to check. If it is OK, ie your system’s /etc/resolv.conf is not affected (or the equivalent for those still running Windows).
See the announcement from Singapore’s CERT on this issue.
