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!
