16 December 2011

The Importance of Patching...

Four days ago, I posted a question on Full Disclosure asking folks if they had seen increased activity related to some old vulnerabilities in the awstats package.  A couple of days ago SpiderLabs blogged about this and added some of the requests and IPs originating this traffic.  SpiderLabs also advised people to upgrade awstats to avoid being victims of this.  Yesterday, I did some digging and can add a few more IPs to SpiderLabs original list along with some additional information and advice. 

First, I have seen traffic from the following IPs in addition to those posted by SpiderLabs:
114.32.50.243
124.193.142.249
189.114.94.226
189.19.13.239
190.90.158.146
203.148.85.172
72.252.248.111

And now for the more important part...
If you add the IPs above to those posted by SpiderLabs, you will end up with a total of 64 unique IPs.  Looking at the 61 of 64 servers with a service on port 80, 42 responded to a wget with HTML that appears to be representative of legitimate business or end-user content. 

Taking a couple of examples, I see that a few of these servers are sitting on legitimate corporate networks and hosting content related to the business that holds the allocation for the assigned IP.  That being the case, it seems reasonable to me to assume that at least some of these servers were compromised in some fashion and that they did not voluntarily begin running these scans for the awstats package.   A couple of cases in point here…

The HTTP server running on port 80 at IP 118.97.50.11 serves a redirect to a secure web server running on port 443 at the same IP.  While the server running https via port 443 is using a self-signed certificate, the IP itself is allocated to Telkom Indonesia and the application presented indicates that it is the “Telkom Group Knowledge Management System”. 

Another case in point:  The domain www.infolution.fr resolves to 80.248.214.103.  As before, the IP is allocated to Infolution, a French information architecture society. 

I could provide more examples, but you probably get my point.  So, if these guys didn’t voluntarily self-install an awstats scanner, what allowed this to happen?  Not certain, but I can say that these servers (and many of the others) have something in common:  they are running old versions of Apache.  The first example is running Apache 2.2.3, released in 2006.  The second example is running a version 2.2.16, released in mid-2010.    This seems to be a very common condition. 

Looking a bit more closely at the 64 IPs, 48 of 64 are confirmed as running Apache.  Of the 48 Apache servers, 41 provide a version number.  Of the 41 servers, only 2 are running the current stable version (2.2.21).  The remaining 39 are all running old versions of Apache.  Here is the breakdown of old versions: 

Version
Count
Release Year
2.2.21
2
2011
2.2.15
1
2010
2.2.16
3
2010
2.2.12
1
2009
2.2.11
3
2008
2.2.8
6
2008
2.2.9
3
2008
2.0.61
1
2007
2.2.6
3
2007
1.3.36
1
2006
2.0.59
2
2006
2.2.3
8
2006
2.2.2
3
2005
2.0.52
4
2004

But wait, you say….  What about awstats?  Couldn’t that be what caused this?  Sure, but only 7 of the 64 servers seem to be running awstats at this time.  That doesn’t mean that awstats wasn’t the original problem, but it could have been Apache just as easily. Or WordPress, Joomla, PHP or any other random applications installed on these servers. Apache just seems to be the most common and exploiting some ancient Apache bug across a wide range of systems would be arguably easier than cracking each one open using a different vulnerability.  And some of these servers just have a generic Apache instance installed with no PHP or other applications.  So, in my mind, old Apache seems to be a very common link.  Not conclusive, just common. 

So, I’d add this to SpiderLabs recommendation:  Upgrade your Apache version (and your OS, PHP, Wordpress, Joomla, etc., while you are at it).  And if your IP is on the list published by SpiderLabs or in this post, you have a problem.  Follow your incident response plan and clean this up! 

14 December 2011

Track your Google search results with googdiff

Blackhat Search Engine Optimization (SEO) practitioners attempt to change or improve search engine results in ways that are unapproved by the search engines and which often involve deception.  Blackhat SEO techniques can be used to make fraudulent pages appear more prominent, siphoning money from legitimate companies and charities, or allowing the blackhat SEO to impersonate prominent individuals, ascribing their own views or opinions to the targeted individual for economic or political gain.
With 65% of the US market share for Internet search, Google is the de facto authoritative source of information for millions of Americans each day.  Users assume that the links appearing on Google’s first page of search results have a great deal of credibility and relevance.  By paying attention to the first page of search results and carefully noting how those search results change for your key search terms, you can more easily determine whether or not someone is misusing your online identity or overtaking your ranking on Google’s front page, costing you lost sales.
googdiff helps you monitor your online identity or the online identity of your business as revealed by Google’s front page search results, helping protect you from so-called “Blackhat” SEO (SEO) “consultants”.  This utility is available at http://code.google.com/p/googdiff/