- Author: Joe Stewart
Search hijackers are not a new phenomenon; however, their purveyors are becoming more and more aggressive in capturing clicks from web users.
Often, attempting to find the entity behind the hijack becomes an endless task of following layer after layer of obfuscation. Below we attempt to peel back the layers of one major search hijack incident in a step-by-step illustration.
The incident in question involves DNS hijacking, and was widely reported in the beginning of 2005. The hijack was simple, and the vulnerability old and well-known. It involved a rogue DNS server sending bogus authority records in a DNS reply packet, in which it claimed to be the authoritative server for all of the .com TLD. Vulnerable hosts would then direct queries for any .com sites to the rogue DNS server. See the incidents.org March 31 Handler's Diary for details.
Update:
Several people have asked how to stop the hijacking from occurring on their computer. End users may not be able to prevent cache poisoning - the problem lies with the user's ISP or company DNS servers. Users may direct the persons responsible for maintenance of the DNS servers to Microsoft's KnowledgeBase article 241352, which explains how to secure Windows DNS servers against this type of cache poisoning (or "cache pollution", as Microsoft calls it). Modern *nix-based DNS servers are not vulnerable to this type of attack. This vulnerability in Windows DNS services has been common knowledge for nearly four years now.
At the time of this writing, the hostile websites and IP addresses were:
www.abx4.com A 72.9.233.153www.abx4.com A 216.55.185.467sir7.com
A 72.9.233.1537sir7.com A 216.55.185.46123xxl.com A
72.9.233.153123xxl.com A 216.55.185.46
We decided to follow along and see where the hijack would lead in the end. Since we're not vulnerable to the attack, we substituted the attacker's webserver IP 216.55.185.46 for the real IP of www.cnn.com on our machine by adding the following line to /etc/hosts:
216.55.185.46 www.cnn.com
We then began to follow the trail as if we were a victim user visiting www.cnn.com. We operated as if we were unknowingly hijacked and perhaps naive enough to click on the links presented to us, which is not unimaginable for a less-than-savvy websurfer.
We will present the raw HTTP request headers and responses below in order to demonstrate layers that may be invisible to the user. Our requests are presented in green, and the remote webserver's replies are in red.
Also, it is not recommended to visit any of the links below - it has been reported that remote malware installs on vulnerable IE installations have been associated with this scheme. We didn't encounter any exploit links in the path we followed, but that may be due to the use of Firefox as opposed to IE - some hostile sites actively check the User-Agent field and only deliver exploits to hosts they believe will be vulnerable. In any case we do have prior evidence of the initial hosts in the chain installing malware in the past.
Starting up Firefox and typing in www.cnn.com:
GET / HTTP/1.1
Host: www.cnn.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Our hijacker's webserver answers with the following:
HTTP/1.1 302 Found
Date: Fri, 01 Apr 2005 14:19:34 GMT
Server: Apache/2.0.52 (FreeBSD) PHP/4.3.10
Location: http://error404.web-search.la/error.html
Content-Length: 313
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://error404.web-search.la/error.html">here</a>.</p>
<hr>
<address>Apache/2.0.52 (FreeBSD) PHP/4.3.10 Server at www.cnn.com Port 80</address>
</body></html>
We've been redirected now to error404.web-search.la/error.html. This happens invisibly, when our browser makes the following request for us:
GET /error.html HTTP/1.1
Host: error404.web-search.la
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
The hijacker's webserver responds with the following:
HTTP/1.1 200 OK
Date: Fri, 01 Apr 2005 13:50:02 GMT
Server: Apache/2.0.48 (Unix)
Last-Modified: Fri, 01 Apr 2005 09:19:45 GMT
ETag: "68840e-14e-82d42e40"
Content-Length: 334
Connection: close
Content-Type: text/html; charset=ISO-8859-1
<html><head>
<title>404 Not Found</title>
</head><body>
<script language="JavaScript" src="http://vparivalka.org/G7/anticheatsys.php?id=36381"
type="text/JavaScript"></script>
<h1>Not Found</h1>
The requested URL was not found on this server.<p>
</body></html>
<iframe src="http://www.web-search.la/" width=700 height=570></iframe>
So, a 404 error - but with an iframe that loads the content of http://www.web-search.la/ into the same page.
GET / HTTP/1.1
Host: www.web-search.la
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Referer: http://error404.web-search.la/error.html
This returns a page resembling a search engine. It also includes javascript that loads www.lycos.la in another browser window automatically.
GET / HTTP/1.1
Host: www.lycos.la
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
www.lycos.la is another, slightly different search engine page (with no relation to Lycos.com as far as we can tell). Put together, the result so far looks like this:
Now, we want to proceed as if we were actually interested in some of the links on the page. So, on the web-search.la page, we'll click on "New Cars":
GET /iresults.php?qq=New+cars HTTP/1.1Host: www.web-search.la
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Referer: http://www.web-search.la/
The search results:
Ok, a well-known auto manufacturer is the top result. Let's click and watch what happens:
GET /iresults.php?rd=1&qq=New+cars&subaff=&pos=1&go=aHR0cDovL3VzMDEueG1sc2VhcmNoLmZpbmR3aGF0L
mNvbS9iaW4vZmluZHdoYXQuZGxsP2NsaWNrdGhyb3VnaCZ5PTQ3MTYxJng9OW5ZNEZ2WXc5dG0zNEI0UFkxcFQ
6RWJ1MFRlVDlraXQzOWFpOVlBMlEyMUlTRVJOSllSQ2ZlaXRNejhISTFwZFhsQWhGRTFKRmpXMWZFdU5SRHJuTXR
wSlRMZkpZOGFkVEQwbmp2VHpTOG1RdEVUaTlpWWNKVk1zSzR4RjR6QWlUMXJCZ2lXNWMxUmdrQnJqYWVoaztl
O2w0dHhXa0REMXpnWUVPUjtKVGkkJFo=&b=MC4xMDY=&se=ZmluZHdoYXQ=&mode=&al=http://81.9.3.77/click.php HTTP/1.1
Host: www.web-search.la
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Referer: http://www.web-search.la/iresults.php?qq=New+cars
At this point we begin to be redirected through a series of servers and scripts:
HTTP/1.1 302 Found
Date: Fri, 01 Apr 2005 13:53:45 GMT
Server: Apache/2.0.48 (Unix)
X-Powered-By: PHP/4.3.8
Location: http://81.9.3.77/click.php?surfer_ip=x.x.x.x&aff=4895&qq=New+cars&subaff=&pos=1&go=aHR0cDovL3VzMDEueG1sc2VhcmNoL
mZpbmR3aGF0LmNvbS9iaW4vZmluZHdoYXQuZGxsP2NsaWNrdGhyb3VnaCZ5PTQ3MTYxJng9OW5Z
NEZ2WXc5dG0zNEI0UFkxcFQ6RWJ1MFRlVDlraXQzOWFpOVlBMlEyMUlTRVJOSllSQ2ZlaXRNejhISTFw
ZFhsQWhGRTFKRmpXMWZFdU5SRHJuTXRwSlRMZkpZOGFkVEQwbmp2VHpTOG1RdEVUaTlpWWNK
Vk1zSzR4RjR6QWlUMXJCZ2lXNWMxUmdrQnJqYWVoaztlO2w0dHhXa0REMXpnWUVPUjtKVGkkJFo
=&b=MC4xMDY=&se=ZmluZHdoYXQ=&mode=
Content-Length: 0
Connection: close
Content-Type: text/html; charset=ISO-8859-1
The redirect above sends us to 81.9.3.77 with a boatload of parameters. Looking at the parameters we can see they seem to resemble base-64 mime encoding. A simple Perl one-liner can show us what is hidden in the URL:
perl -MMIME::Base64 -e 'print decode_base64
("aHR0cDovL3VzMDEueG1sc2VhcmNoLmZpbmR3aGF0LmNvbS9iaW4vZml
uZHdoYXQuZGxsP2NsaWNrdGhyb3VnaCZ5PTQ3MTYxJng9OW5ZNEZ2WXc5
dG0zNEI0UFkxcFQ6RWJ1MFRlVDlraXQzOWFpOVlBMlEyMUlTRVJOSllSQ
2ZlaXRNejhISTFwZFhsQWhGRTFKRmpXMWZFdU5SRHJuTXRwSlRMZkpZOG
FkVEQwbmp2VHpTOG1RdEVUaTlpWWNKVk1zSzR4RjR6QWlUMXJCZ2lXNWM
xUmdrQnJqYWVoaztlO2w0dHhXa0REMXpnWUVPUjtKVGkkJFo="), "\n"'
When run, it gives us:
http://us01.xmlsearch.findwhat.com/bin/findwhat.dll?click
through&y=47161&x=9nY4FvYw9tm34B4PY1pT:Ebu0TeT9kit39ai9YA
2Q21ISERNJYRCfeitMz8HI1pdXlAhFE1JFjW1fEuNRDrnMtpJTLfJY8ad
TD0njvTzS8mQtETi9iYcJVMsK4xF4zAiT1rBgiW5c1RgkBrjaehk;e;l4
txWkDD1zgYEOR;JTi$$Z
So, hidden in our URL is another URL, this time for findwhat.com. Let's see what happens when our browser follows it:
GET /click.php?surfer_ip=x.x.x.x&aff=4895&qq=New+cars&subaff=&pos=1&go=a
HR0cDovL3VzMDEueG1sc2VhcmNoLmZpbmR3aGF0LmNvbS9iaW4vZmluZHdoYX
QuZGxsP2NsaWNrdGhyb3VnaCZ5PTQ3MTYxJng9OW5ZNEZ2WXc5dG0zNEI0UFk
xcFQ6RWJ1MFRlVDlraXQzOWFpOVlBMlEyMUlTRVJOSllSQ2ZlaXRNejhISTFwZFhsQ
WhGRTFKRmpXMWZFdU5SRHJuTXRwSlRMZkpZOGFkVEQwbmp2VHpTOG1RdEV
UaTlpWWNKVk1zSzR4RjR6QWlUMXJCZ2lXNWMxUmdrQnJqYWVoaztlO2w0dHhXa
0REMXpnWUVPUjtKVGkkJFo=&b=MC4xMDY=&se=ZmluZHdoYXQ=&mode= HTTP/1.1
Host: 81.9.3.77
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Referer: http://www.web-search.la/iresults.php?qq=New+cars
HTTP/1.1 302 Found
Date: Fri, 01 Apr 2005 14:26:55 GMT
Server: Apache/*.*.** (Unix) PHP/4.3.8
X-Powered-By: PHP/4.3.8
X-Accelerated-By: PHPA/1.3.3r2
Set-Cookie: fwcl=1; expires=Sun, 03-Apr-2005 02:26:55 GMT
Location: http://us01.xmlsearch.findwhat.com/bin/findwhat.dll?clickthrough&y=47161&x=9
nY4FvYw9tm34B4PY1pT:Ebu0TeT9kit39ai9YA2Q21ISERNJYRCfeitMz8HI1pdXlAhFE1JFj
W1fEuNRDrnMtpJTLfJY8adTD0njvTzS8mQtETi9iYcJVMsK4xF4zAiT1rBgiW5c1RgkBrjaeh
k;e;l4txWkDD1zgYEOR;JTi$$Z
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
Well, we were redirected once again, this time to findwhat.com. Surprise, surprise.
What is FindWhat? It's a "Performance-Driven Marketing" company - meaning a pay-per-click search engine:
Note the first parameter passed to FindWhat is "y=47161". This is likely the affiliate ID, passed in so the affiliate can get credit (any payment) for the click delivered. So far, no HTML has been displayed to the browser. It continues on, this time requesting the URL from findwhat.com:
GET /bin/findwhat.dll?clickthrough&y=47161&x=9nY4FvYw9tm34B4PY1pT:Ebu0TeT9kit39a
i9YA2Q21ISERNJYRCfeitMz8HI1pdXlAhFE1JFjW1fEuNRDrnMtpJTLfJY8adTD0njvTzS8mQtE
Ti9iYcJVMsK4xF4zAiT1rBgiW5c1RgkBrjaehk;e;l4txWkDD1zgYEOR;JTi$$Z HTTP/1.1
Host: us01.xmlsearch.findwhat.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Referer: http://www.web-search.la/iresults.php?qq=New+cars
And now, (drum roll), yet another redirect:
HTTP/1.1 302 Object Moved
Location: http://redirect.findresolution.com/rdr/1728/number=10938471;z
P3P: CP="NOI COM NAV"
Content-Type: text/html
Expires: Tue, 14 Mar 2000 05:00:00 GMT
Cache-Control: Private
Set-Cookie: uid=ap78uhy22MkZq:JJeJdMGq5c05Q%3BGMOvBHQg:fsZ5ayQVdQAZfL2WN
PUZ; expires=Wednesday, 01-Jan-2020 00:00:01 GMT; path=/; domain=findwhat.com
Connection: close
<HEAD><TITLE>302 Moved Temporarily</TITLE>
<META HTTP-EQUIV="Refresh" CONTENT="0;URL=http://redirect.findresolution.com/rdr/1728/number=10938471;z">
</HEAD>
<BODY bgcolor=#6666cc alink=#ffff99 vlink=#ffff99><font face=sans-serif,arial color=white><br>
The website you are looking for is located below.<br>You are seeing this message because your web browser does not
<br>properly support redirects. Please upgrade your browser to eliminate<br>this message while using FindWhat.com!<br>
<P><font size=+2><b><A HREF="http://redirect.findresolution.com/rdr/1728/number=10938471;z">
PLEASE CLICK HERE TO CONTINUE</A></b></P></font>
</BODY>
Ok, our browser is happily following along - still nothing has been displayed to the end user.
GET /rdr/1728/number=10938471;z HTTP/1.1
Host: redirect.findresolution.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Referer: http://www.web-search.la/iresults.php?qq=New+cars
Another redirect - This time to ad.doubleclick.net:
HTTP/1.1 302 Found
Date: Fri, 01 Apr 2005 14:26:57 GMT
Server: Apache/2.0.51 (Fedora)
Location: http://ad.doubleclick.net/clk;13418303;10938471;z?http://www.mbusa.com/MBServlet/
RedirectServlet?src=739&target=HOME&LEAD_TYPE=CORPB&site=%s
Content-Length: 431
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://ad.doubleclick.net/clk;13418303;10938471;z?
http://www.mbusa.com/MBServlet/RedirectServlet?src=739&target=HOME&LEAD_TYPE=CORPB&site=%s">here</a>.</p>
<hr />
<address>Apache/2.0.51 (Fedora) Server at redirect.findresolution.com Port 80</address>
</body></html>
Our browser follows the redirect from DoubleClick invisibly in the background:
GET /clk;13418303;10938471;z?http://www.mbusa.com/MBServlet/RedirectServlet?src=739
&target=HOME&LEAD_TYPE=CORPB&site=%s HTTP/1.1
Host: ad.doubleclick.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Referer: http://www.web-search.la/iresults.php?qq=New+cars
Cookie: id=8000004c65df440
And now, we are finally at the end of the chain. Just kidding, it's another redirect:
HTTP/1.0 302 Moved Temporarily
Content-Length: 0
Location: http://www.mbusa.com/MBServlet/RedirectServlet?src=739&target=HOME&LEAD_
TYPE=CORPB&site=N2502.ResolutionMedia
Hey, we're at least on mbusa.com finally:
GET /MBServlet/RedirectServlet?src=739&target=HOME&LEAD_TYPE=CORPB&site=N2502.ResolutionMedia HTTP/1.1
Host: www.mbusa.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Referer: http://www.web-search.la/iresults.php?qq=New+cars
Well, ok, one more redirect, for old times' sake:
HTTP/1.1 302 Found
Server: Netscape-Enterprise/6.0
Date: Fri, 01 Apr 2005 14:26:57 GMT
Content-length: 0
Content-type: text/html; charset=ISO-8859-1
Set-cookie: JSESSIONID=0000FJojQ5iX7V3NzWiDpauaMdR:v13mn3gd;Path=/
Set-cookie: UserOnMachine=37772616&36546905;Expires=Wed, 31-Mar-2010 14:26:58 GMT;Path=/
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Set-cookie: SRCORIGIN=739;Path=/
Cache-control: no-cache="set-cookie,set-cookie2"
Location: http://www.mbusa.com/brand/index.jsp
Content-language: en-US
Now we are finally presented with a page, as if we had clicked on a legitimate advertisement for Mercedes:
But what if we follow the links in the lycos.la page we were presented with?Lets choose "Air Travel":
And let's follow the Travelocity link:
GET /click.php?id=297d341bd64df475dcc962e88f33a805 HTTP/1.1
Host: www.lycos.la
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Referer: http://www.lycos.la/search.php?q=Air%20Travel
Cookie: PHPSESSID=aa783a83e8505b47da15d177b50615d1
Similar to the click.php redirector above, we are sent to "go.php"with an encoded URL
(although it doesn't seem to be base-64-encoded ascii):
HTTP/1.1 302 Found
Date: Fri, 01 Apr 2005 13:55:06 GMT
Server: Apache/2.0.48 (Unix)
X-Powered-By: PHP/4.3.8
Set-Cookie: PHPSESSID=aa783a83e8505b47da15d177b50615d1; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: http://66.230.182.46/go.php?c=KZMjj80XATqyWBrQMptGL8yiuD9bOvU8YXYlgr6Or%2B5ExvqkHQSc4Z6WXL
kcQS0jMQI3FkOK89WkrL02Rys0P3XXsn%2FjXIv6wQhwyg6e7Fc9UlibqQC22SqOzjIGjn
R2J1fzJXm99C2EYeKgUJMEL4vt4F8k2ZqFhRAKwU6jkQVCNoBrvhNDD8czhD0KaKoHG
ZYhCEhk5XenHk0B1P7PpE4PW0pms8Au8vrnpXoAfaRjPSjCSfMB%2BWmNoFuk%2F6s1u
WPRogWapWCoBs4%2FZL0wwWip6Yh554WmzS9%2B95%2F3iA5unSBj1dDsgGcWuh7XE
LqN84gXLqjNt%2BRCPE1jV%2BfLwE2syPjDwx3rwWeVTfrLFFTdHYtUqMgLB%2BFT7Jngru
QnVNmOuNbN5JN7Tr7TcCK%2FMeg%2FTxWvZJI8WuPJNju7WKg%3D&v=2
Content-Length: 0
Connection: close
Content-Type: text/html; charset=ISO-8859-1
So our browser follows the redirect:
GET /go.php?c=KZMjj80XATqyWBrQMptGL8yiuD9bOvU8YXYlgr6Or%2B5ExvqkHQSc4Z6WXLkcQS0jM
QI3FkOK89WkrL02Rys0P3XXsn%2FjXIv6wQhwyg6e7Fc9UlibqQC22SqOzjIGjnR2J1fzJXm99C2EYeKgUJ
MEL4vt4F8k2ZqFhRAKwU6jkQVCNoBrvhNDD8czhD0KaKoHGZYhCEhk5XenHk0B1P7PpE4PW0pms8Au
8vrnpXoAfaRjPSjCSfMB%2BWmNoFuk%2F6s1uWPRogWapWCoBs4%2FZL0wwWip6Yh554WmzS9%2B95
%2F3iA5unSBj1dDsgGcWuh7XELqN84gXLqjNt%2BRCPE1jV%2BfLwE2syPjDwx3rwWeVTfrLFFTdHYtUqMgL
B%2BFT7JngruQnVNmOuNbN5JN7Tr7TcCK%2FMeg%2FTxWvZJI8WuPJNju7WKg%3D&v=2 HTTP/1.1
Host: 66.230.182.46
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Referer: http://www.lycos.la/search.php?q=Air%20Travel
Just like before, the result of the first redirect is a redirect to findwhat.com:
HTTP/1.1 302 Found
Date: Fri, 01 Apr 2005 14:28:17 GMT
Server: Apache/2.0.52
X-Powered-By: PHP/4.3.9
Location: http://us01.xmlsearch.findwhat.com/bin/findwhat.dll?clickthrough&y=48052&x=QHGJxc2e6U:
s45dVEpIKrhlPkAl;nO7RWaQoShQ51wdAwf2VAbyH50PkdyltQwJVCJ68xh34qSBHnq:U2IFdsSs;7H70Eb
UNgh588c:FhAPLZbLhB:29prGo3FLdeK628AFrMy3q8SljC:73ObI47b5pWO:qc;OUxrU8xpkAZ
Content-Length: 0
Connection: close
Content-Type: text/html
This time our suspected affiliate ID is 48052 - multiple people? Or just the same rogue affiliate with multiple accounts?
At this point, we know what happens - a redirect through ad.doubleclick.net, which finally brings us to:
GET /flights HTTP/1.1
Host: travelocity.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Referer: http://www.lycos.la/search.php?q=Air%20Travel
At this point we can see clearly what is happening - the big-name companiesare advertising on legitimate networks that utilize pay-per-click search engines to drive traffic to the ads. Unfortunately, the pay-per-click model lends itself to abuse by rogue affiliates who will hijack users in order to drive up their click count and revenue.
At the heart of the pay-per-click model is findwhat.com. While it is a legitimate enterprise itself, it is the entity that pays the affiliates who are actively employing trojans and dns cache poisoning to drive traffic to the advertisers. FindWhat has a policy prohibiting certain activities of this type, and will likely terminate any affiliate account reported to them for abuse. However, terminating the account only means that FindWhat benefits from the hijacker's activity without having to pay the hijacking affiliate. It's a win-win situation for them. FindWhat's estimated earnings for 2004 were between $167.5 and $179.5 million dollars. There is no way to determine how much of that revenue was generated by traffic from hijacked machines.
This flowchart shows the flow of traffic and the flow of money in the scheme described above:
It doesn't seem too far-fetched to imagine that the persons responsible for the DNS hijacking could be apprehended simply by serving FindWhat with a subpoena to find out where they've been sending the checks for the affiliate IDs being passed in the search redirects. However, this activity has persisted for years now without much law enforcement interest, and as each new affiliate comes on board they invent their own scheme to abuse the PPC system. Clearly it seems that through the chain of advertiser to consumer and back again, the end user is ultimately paying to have him or herself hijacked.