Global
Pay-per-Click Hijacking
- URL: http://www.secureworks.com/research/threats/ppc-hijack
- Date: April 1, 2005
- 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.153 www.abx4.com A 216.55.185.46 7sir7.com A 72.9.233.153 7sir7.com A 216.55.185.46 123xxl.com A 72.9.233.153 123xxl.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.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/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=aHR0cDovL3VzMDEueG1 sc2VhcmNoLmZpbmR3aGF0LmNvbS9iaW4vZmluZHdoYXQuZGxsP2NsaWNrdGhyb3VnaCZ5PT Q3MTYxJng9OW5ZNEZ2WXc5dG0zNEI0UFkxcFQ6RWJ1MFRlVDlraXQzOWFpOVlBMlEyMUlTR VJOSllSQ2ZlaXRNejhISTFwZFhsQWhGRTFKRmpXMWZFdU5SRHJuTXRwSlRMZkpZOGFkVEQw bmp2VHpTOG1RdEVUaTlpWWNKVk1zSzR4RjR6QWlUMXJCZ2lXNWMxUmdrQnJqYWVoaztlO2w 0dHhXa0REMXpnWUVPUjtKVGkkJFo=&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=aHR0cDovL3VzMDEueG1sc2VhcmNoLmZpbmR3aGF0LmNvbS9iaW4 vZmluZHdoYXQuZGxsP2NsaWNrdGhyb3VnaCZ5PTQ3MTYxJng9OW5ZNEZ2WXc5dG0zNEI0 UFkxcFQ6RWJ1MFRlVDlraXQzOWFpOVlBMlEyMUlTRVJOSllSQ2ZlaXRNejhISTFwZFhsQ WhGRTFKRmpXMWZFdU5SRHJuTXRwSlRMZkpZOGFkVEQwbmp2VHpTOG1RdEVUaTlpWWNKVk 1zSzR4RjR6QWlUMXJCZ2lXNWMxUmdrQnJqYWVoaztlO2w0dHhXa0REMXpnWUVPUjtKVGk kJFo=&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("aHR0cDovL3VzMDEueG1sc2
VhcmNoLmZpbmR3aGF0LmNvbS9iaW4vZmluZHdoYXQuZGxsP2NsaWNrdGhyb3VnaCZ5P
TQ3MTYxJng9OW5ZNEZ2WXc5dG0zNEI0UFkxcFQ6RWJ1MFRlVDlraXQzOWFpOVlBMlEy
MUlTRVJOSllSQ2ZlaXRNejhISTFwZFhsQWhGRTFKRmpXMWZFdU5SRHJuTXRwSlRMZkp
ZOGFkVEQwbmp2VHpTOG1RdEVUaTlpWWNKVk1zSzR4RjR6QWlUMXJCZ2lXNWMxUmdrQn
JqYWVoaztlO2w0dHhXa0REMXpnWUVPUjtKVGkkJFo="), "\n"'
When run, it gives us:
http://us01.xmlsearch.findwhat.com/bin/findwhat.dll?clickthrough &y=47161&x=9nY4FvYw9tm34B4PY1pT:Ebu0TeT9kit39ai9YA2Q21ISERNJYRCfeitM z8HI1pdXlAhFE1JFjW1fEuNRDrnMtpJTLfJY8adTD0njvTzS8mQtETi9iYcJVMsK4xF4 zAiT1rBgiW5c1RgkBrjaehk;e;l4txWkDD1zgYEOR;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=aHR0cDovL3VzMDEueG1sc2VhcmNoLmZpbmR3aGF0LmNvbS9iaW4vZmluZHdoYXQuZ GxsP2NsaWNrdGhyb3VnaCZ5PTQ3MTYxJng9OW5ZNEZ2WXc5dG0zNEI0UFkxcFQ6RWJ1M FRlVDlraXQzOWFpOVlBMlEyMUlTRVJOSllSQ2ZlaXRNejhISTFwZFhsQWhGRTFKRmpXM WZFdU5SRHJuTXRwSlRMZkpZOGFkVEQwbmp2VHpTOG1RdEVUaTlpWWNKVk1zSzR4RjR6Q WlUMXJCZ2lXNWMxUmdrQnJqYWVoaztlO2w0dHhXa0REMXpnWUVPUjtKVGkkJFo=&b=MC 4xMDY=&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?click through&y=47161&x=9nY4FvYw9tm34B4PY1pT:Ebu0TeT9kit39ai9YA2Q21ISERNJYRCf eitMz8HI1pdXlAhFE1JFjW1fEuNRDrnMtpJTLfJY8adTD0njvTzS8mQtETi9iYcJVMsK4xF 4zAiT1rBgiW5c1RgkBrjaehk ;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:Eb u0TeT9kit39ai9YA2Q21ISERNJYRCfeitMz8HI1pdXlAhFE1JFjW1fEuNRDrnMtpJTLf JY8adTD0njvTzS8mQtETi9iYcJVMsK4xF4zAiT1rBgiW5c1RgkBrjaehk;e;l4txWkDD 1zgYEOR;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:fsZ5ayQVdQAZfL2WNPUZ; 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=KZMjj80XATqyWBrQMptGL8y iuD9bOvU8YXYlgr6Or%2B5ExvqkHQSc4Z6WXLkcQS0jMQI3FkOK89WkrL02Rys0P3XX sn%2FjXIv6wQhwyg6e7Fc9UlibqQC22SqOzjIGjnR2J1fzJXm99C2EYeKgUJMEL4vt4 F8k2ZqFhRAKwU6jkQVCNoBrvhNDD8czhD0KaKoHGZYhCEhk5XenHk0B1P7PpE4PW0pm s8Au8vrnpXoAfaRjPSjCSfMB%2BWmNoFuk%2F6s1uWPRogWapWCoBs4%2FZL0wwWip6 Yh554WmzS9%2B95%2F3iA5unSBj1dDsgGcWuh7XELqN84gXLqjNt%2BRCPE1jV%2BfL wE2syPjDwx3rwWeVTfrLFFTdHYtUqMgLB%2BFT7JngruQnVNmOuNbN5JN7Tr7TcCK%2 FMeg%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%2B5ExvqkHQS c4Z6WXLkcQS0jMQI3FkOK89WkrL02Rys0P3XXsn%2FjXIv6wQhwyg6e7Fc9UlibqQC2 2SqOzjIGjnR2J1fzJXm99C2EYeKgUJMEL4vt4F8k2ZqFhRAKwU6jkQVCNoBrvhNDD8c zhD0KaKoHGZYhCEhk5XenHk0B1P7PpE4PW0pms8Au8vrnpXoAfaRjPSjCSfMB%2BWmN oFuk%2F6s1uWPRogWapWCoBs4%2FZL0wwWip6Yh554WmzS9%2B95%2F3iA5unSBj1dD sgGcWuh7XELqN84gXLqjNt%2BRCPE1jV%2BfLwE2syPjDwx3rwWeVTfrLFFTdHYtUqM gLB%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?click through&y=48052&x=QHGJxc2e6U:s45dVEpIKrhlPkAl;nO7RWaQoShQ51wdAwf2VAbyH5 0PkdyltQwJVCJ68xh34qSBHnq:U2IFdsSs;7H70EbUNgh588c:FhAPLZbLhB:29prGo3FLd eK628AFrMy3q8SljC: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 companies are 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.
