Section 4.7. Bait and SwitchURL Redirection

4.7. Bait and SwitchURL Redirection

One alternative to disguising the URL of a site is to post the address of a second site and have that redirect any traffic it receives to the target address. You think you're going to site A but you end up at site B.

This takes some effort to set up as the owner has to have control of one or more of these proxy web sites. The benefit to them is that it hides the identity of their main web site, the one that actually sells a product or steals your identity. Nowhere in any of the junk emails does that address occur. As one proxy site gets exposed, and its address is added to spam blacklists, it is easy to set up another proxy site and to be back in business. The effort and cost of setting up these sites is minimal and much easier than having to move the primary site from one address to another.

There are two main ways to accomplish this sort of redirection. You can add a special tag to a web page on the proxy site that tells your browser to go to the target. Or, you can add a line to the web server configuration file that intercepts the request for a specific page and tells the browser to fetch it from the target location.

4.7.1. Page-Based Redirection

The easiest way to implement redirection is to create a web page and add a meta tag to the HEAD section of the document. meta tags are used for various purposes, such as adding keywords for search engines. One class of these uses a http-equiv attribute, which adds its content to the HTTP headers that are sent back to the browser immediately before the content of the page. By setting the http-equiv attribute to refresh, you can tell the browser to load a second page at some interval after loading this page. This is sometimes used to reload dynamic web pages or to create a simple slideshow effect. But we can redirect a browser to a different page immediately if we set the delay to zero seconds and include the target URL in the content attribute of the tag. Here is an example that tells the browser to immediately start loading the target URL:

     <meta http-equiv="refresh" content="0; URL=http://www.craic.com"> 

If we changed 0 to, say, 5, then the current page would be displayed for 5 seconds before the target began to load.

Under normal circumstances you won't even see this first web page. But if things are running slowly for some reason, then you might notice it for a second or two before the target appears. The benefit of this approach is its simplicity. The owner only has to copy a web page onto the proxy site, and it will work immediately.

4.7.2. Server-Based Redirection

The better way to redirect users is to modify the configuration file for the web server. Almost 70% of sites on the Internet run the Apache web server, so I will only consider that software here. The operation of the server is configured in the file httpd.conf. Server-based redirection can be achieved in several different ways. One of the easiest is to include a one-line Redirect directive in the file and restart the server. The format of this is simply:

     Redirect <old url> <new url> 

The old URL is the local path to the HTML document on this proxy server and the new URL is the complete URL of the page on the target site. Here is an example that would take any request for redirect.html and redirect it to O'Reilly's home page:

     Redirect /redirect.html http://www.oreilly.com 

Note that I do not need to actually have a file called redirect.html because the web server intercepts the request before trying to retrieve the page. It sends an HTTP response back to the browser, telling it the requested page is no longer located there and giving it the new address. The browser then sends a second request to the target server for the real page. The user is none the wiser to any of this and simply sees the target page appear. Because the only page downloaded to the browser is the intended one, there is no risk of the dummy page appearing.

The downside of this approach is that the owner must either have access to the Apache configuration file or must persuade the server administrator to make the changes on their behalf. Either way, it demands a higher level of sophistication on the part of the people responsible for the site.

A second approach that is widely used by phishing web sites is to generate a web page from a server-side script, typically written in Perl or PHP. That script generates the HTTP headers for the page before it outputs the contents of the page itself. Including a Location header will direct the browser to fetch the specified URL instead of displaying the following content. For example, the following header would redirect the browser to the O'Reilly web site:

     Location: http://www.oreilly.com 

4.7.3. Determining the Mechanism

The observant user will know when a page has been redirected because the URL in the browser address bar will not be what you expected. You can go one step further and determine which of the two redirection methods was actually used in any given case.

The way you do this is by looking at the HTTP headers that are returned to your browser by the initial request. I talk about headers and how to access them in Chapter 6, but here is a taste of how useful they can be.

With page-based redirection, the browser fetches the requested page from the proxy site, and then acts upon the refresh directive, fetching the target page. As far as the proxy server is concerned, this is a regular http transaction and it sends back a numeric response code of 200. In plain language, the server is telling the browser that everything is OK and here is the content that you requested. Here are the edited headers that are returned by the program wget when given a URL that redirects using a meta tag:

     HTTP request sent, awaiting response...      1 HTTP/1.1 200 OK      [...]

With server-based redirection, the initial page is never sent to the browser. Instead, the server responds with a set of headers that include a response code of 302. All codes in the 300 series signify server redirection in slightly different flavors. 302 stands for "Moved Temporarily," and it's the one you will see most frequently. It also supplies a Location header that contains the target URL. So this type of redirection results in two sets of headers. The first comes from the proxy, informing the browser of the redirection. The second comes from the target server, giving the browser an OK response followed by the content. Those headers look like this:

     HTTP request sent, awaiting response...      1 HTTP/1.1 302 Found      [...]      4 Location: http://www.craic.com      [...]     Location: http://www.craic.com [following]      [...]     HTTP request sent, awaiting response...      1 HTTP/1.1 200 OK

This pattern of headers is exactly what I see when accessing the URLs contained in the many emails that I have received recently, trying to sell me replica Rolex watches. These point to a variety of web sites with cryptic names, all of which redirect me to online-replica-store.com.

4.7.4. Redirection via eBay

There is a third way to handle redirection that, frankly, is beyond belief. The following URL was contained in an email that appeared to be from eBay, asking me to update my credit card number.

     http://cgi4.ebay.com/ws/eBayISAPI.dll?MfcISAPICommand=RedirectToDomain&     DomainUrl=http%3A%2F%2F%32%31%31%2E%31%37%32%2E%39%36%2E%37%2F     UpdateCenter%2FLogin%2F%3FMfcISAPISession%3DAAJbaQqzeHAAeMWZlH     hlWXS2AlBXVShqAhQRfhgTDrferHCURstpAisNRqAhQRfhgTDrferHCURstpAi     sNRpAisNRqAhQRfhgTDrferHCUQRfqzeHAAeMWZlHhlWXh

We know what's going on here. It appears to be from eBay, but it's a safe bet that hexadecimal encoded text contains a @ character with the real URL to the right of it. Here is the string after decoding:

     http://cgi4.ebay.com/ws/eBayISAPI.dll?MfcISAPICommand=RedirectToDomain&     DomainUrl=http://211.172.96.7/UpdateCenter/Login/?MfcISAPISession=     AAJbaQqzeHAAeMWZlHhlWXS2AlBXVShqAhQRfhgTDrferHCURstpAisNRqAhQRfhgT     DrferHCURstpAisNRpAisNRqAhQRfhgTDrferHCUQRfqzeHAAeMWZlHhlWXh

There is the target host on the second line: 211.172.96.7. But look at what is missing. There is no @ character, so this is not using the username trick. This is a genuine eBay URL! The scammer has figured out that eBay has a script that will redirect visitors to different sites, presumably within the eBay domain. But they have dropped the ball in a big way by allowing it to redirect you to any site that is supplied in the DomainURL parameter. So the scammer has eBay handle the redirection that takes a visitor to the fake site. You can feed any URL to the script and it works fine.

     http://cgi4.ebay.com/ws/eBayISAPI.dll?MfcISAPICommand=RedirectToDomain&     DomainUrl=http://www.cnn.com

Can this be true? Can one of the leading targets for phishing attacks have left open a security hole so large that you could drive a whole truck full of secondhand collectibles through it?

There are two things that you have to do when you come across situations like this. The first is to laugh out loud. The second is to email the company involved and warn them about the problem, which I did. It turns out that in order to email eBay's security people, you first have to open an account on eBay! I provided a detailed description of the issue and sent it in. So far the only responses I have received are an automated acknowledgement with advice on how to spot phishing attempts, and a "Welcome to eBay!" message.

Perhaps the script has been set up like this on purpose, as a honeypot with which to entice the scammers. By looking at the URLs being fed to the script, eBay could quickly identify the fake sites and shut them down. But that cannot have been the case here because the redirect and the fake site both worked fine. At the very least, that script should have spotted URLs that were outside the company and returned a page warning that this was a phishing attempt. The outlook for scammers looks bright if vulnerabilities like this go unnoticed. At the time of writing, this redirection still works.