Section 6.4. Redirection
6.4. RedirectionI have already mentioned server-based redirection in Chapter 4 as a way to disguise the true location of a web site. I want to revisit the topic here in the context of server header lines. The series of events that take place during page redirection can be illustrated in the following block of headers. In this case the browser originally requested the URL http://www.ora.com, which is an alternate name for the O'Reilly web site. The first block of headers is returned by the server that hosts that site. Connecting to www.ora.com[208.201.239.37]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 302 Found 2 Date: Mon, 11 Apr 2005 23:45:45 GMT 3 Server: Apache/1.3.33 (Unix) mod_throttle/3.1.2 4 Location: http://www.oreilly.com/ [...] Location: http://www.oreilly.com/ [following] [...] Connecting to www.oreilly.com[208.201.239.37]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 200 OK The first header line, number 1 in the example, includes the response code 302 Found. Any code in the 300 series denotes some form of redirection and 302 should be used in cases where the file has been moved temporarily to another server. In practice, this is used whether the change is permanent or temporary. Whenever a 3xx code is returned, the server must also tell the browser where it can find the requested page. It does this by including a Location header. Here the new location is http://www.oreilly.com, which is the primary O'Reilly web site. I have edited out some of the headers that are not relevant here. Given the new location, the browser sends a second request to that server, which returns with a 200 response code followed by the requested content. There are several ways in which redirection is used by spammers and con artists. A very common use is to help get around spam filters and blacklists. Spammers are getting very good at constantly modifying the text used in their messages. If anti-spam software sees the same text in multiple examples of spam, then it can use that as a diagnostic with which to filter out future examples. But regardless of the text of the message, a spammer still has to include the URL of the site that is selling the fake Viagra, software, and so on. URLs are strings like any other, and if the same URL is used repeatedly, then the filters will recognize it. It takes time and money to set up a web site, so to protect that investment, spammers use intermediary sites. Emails include a link to one of these sites, but when someone goes to that site it redirects them to the real site. Once spam filters recognize the URL of an intermediary, the spammer creates a new one and sends out a fresh batch of emails that link to it. The intermediary sites are expendable and easy to set up. The primary site remains protected, at least for a while. A good example of this occurred around the end of 2004 when a site selling replicas of expensive watches began an extensive spam campaign. In this edited set of HTTP headers, you can see that a request to the site ayyc.com, listed in the email, was redirected to onlinereplicastore.com at a different IP address. Connecting to www.ayyc.com[218.38.136.38]:80... connected. [...] 1 HTTP/1.1 302 Found [...] 5 Location: http://www.onlinereplicastore.com/ [...] Connecting to www.onlinereplicastore.com[211.115.213.182]:80... connected. [...] 1 HTTP/1.1 200 OK In fact there was no need for them to use an intermediary site on a different server. Only the URL had to be different from the primary site. You can see that in this example where both sites are hosted on the same machine, with IP address 222.223.134.66. Connecting to thh.selyn.com[222.223.134.66]:80... connected. [...] 1 HTTP/1.1 302 Found [...] 5 Location: http://www.online-replica-store.com/affiliate/?id=sales [...] Connecting to www.online-replica-store.com[222.223.134.66]:80... connected. [...] 1 HTTP/1.1 200 OK Comparing the two examples, you can see that the primary site is different between the two. Either the operators were trying to keep an extra step ahead or, more likely, the first site was closed down in spite of their best efforts. Redirection can also be used in a directly malicious way. The next example is part of an attempt to install a trojan or virus on a Windows machine. It represents one step in a complex series of events that is initiated by clicking on a link in piece of spam. The browser requests a page from a web site (http://jeysiksnet.netfirms.com/redir.php) but is instead redirected to a file that is already located on their hard drive (C:\WINDOWS\Help\iexplore.chm). --11:39:08-- http://jeysiksnet.netfirms.com/redir.php => `redir.php' [...] Connecting to jeysiksnet.netfirms.com[204.92.117.19]:80... connected. [...] 1 HTTP/1.1 302 [...] 5 Location: URL:ms-its:C:\WINDOWS\Help\iexplore.chm::/iegetsrt.htm [...] URL:ms-its:C:\WINDOWS\Help\iexplore.chm::/iegetsrt.htm: Unsupported scheme. The attack makes use of Microsoft Compiled HTML Help files, which have the .chm suffix. In certain circumstances, these have the ability to execute the code contained within another file. In this kind of attack, the file that is executed (/iegetsrt.htm) will contain a virus or some other form of malicious code. Because this was run on a Linux machine, which does not support the ms-its protocol that the attack relies on, the exploit fails. This final example has two redirection steps. The intent here is to decouple the first web site, for which a link is included in the original spam message, from the third web site that runs the phishing scam. The added twist is that both the intermediary and final sites can be replaced as needed. In between these two sits a controller web site that redirects requests to whatever site is currently operating. I've split the headers into three blocks to make it easier to follow. The URL contained in the initial email points to host 64.157.14.221. Toward the end of that long URL is a second URL that points to the controller site. A PHP script on the first site extracts this and writes it out as a Location header in its response to the browser. --11:03:59-- http://64.157.14.221/csBanner/banners/realstat.php? PROGID=stat3214&MAILID=73&MakeCopy=0&GetCopy=0&GROUPID=261& EMAILADDR=noaddr& REDIRURL=http://216.130.184.67/cgi-bin/sblogin/receive.pl [...] Connecting to 64.157.14.221:80... connected. [...] 1 HTTP/1.1 302 Found 2 Date: Sat, 29 Jan 2005 19:03:59 GMT 3 Server: Apache/1.3.33 (Unix) PHP/4.3.9 4 X-Powered-By: PHP/4.3.9 5 Location: http://216.130.184.67/cgi-bin/sblogin/receive.pl The new URL points to a Perl script on the controller site at 216.130.184.67. In Chapter 5, I discuss why PHP scripts are heavily favored over Perl scripts in this kind of scam. The fact that we have a Perl script here adds weight to the idea that this site is under the complete control of the scammer. The controller site responds by redirecting the browser to the final site. Location: http://216.130.184.67/cgi-bin/sblogin/receive.pl [following] [...] Connecting to 216.130.184.67:80... connected. [...] 1 HTTP/1.1 302 Found 2 Date: Sat, 29 Jan 2005 19:08:04 GMT 3 Server: Apache/1.3.26 (Unix) PHP/4.3.10 4 Location: http://64.157.14.221/autorank/images/.../template/logon.htm The final site returns a fake bank logon page to the browser. Location: http://64.157.14.221/autorank/images/.../template/logon.htm [following] [...] Connecting to 64.157.14.221:80... connected. [...] 1 HTTP/1.1 200 OK 2 Date: Sat, 29 Jan 2005 19:03:59 GMT In this example, the final site is on host 64.157.14.221, which happens to be the same as the first host! While this round trip may seem illogical, the mechanism that the operator has built into the scam provides a great deal of flexibility in replacing sites on the fly in case any of them are shut down by their ISPs. Tricks like this allow the con artists to prolong the life of their scams, which increases the chances of finding a victim. |
