.htaccess Tricks in Global.asa Files


As you might know a lot of hacks use Apache configuration .htaccess files to override default web site behavior: add conditional redirects, create virtual paths (e.g mod_rewrite), auto-append code to PHP scripts, etc.

In the world of IIS/ASP there is also an equivalent — Global.asa files. This file contains common declarations for all ASP scripts and should be placed in an ASP application root directory. If this file exists, ASP sessions include this file automatically.

Read More

Demystifying File and Folder Permissions

File and Folder Permissions

If you have poked around a server before you have probably encountered file permissions. In fact, all computer file systems offer permissions based on the same core ideas. The file permissions in Linux, Mac, and Windows computers are very similar to the file and folder permissions in Apache, Nginx, and IIS servers. You can right-click any file on your computer and choose Properties (Windows) or Get Info (Mac) to see an example. You can also log into your server (using an FTP client like FileZilla) to do the same thing to your server files and directories.

For the purposes of this article, we’ll be discussing website files and folders on your server.

You may have heard references to things like chmod, 775, read/write, or user groups. This post is going to explain the bare bones of permissions, giving you clarity into these terms. This is important for those of us who are just starting to interact with servers, and for those who have always been curious to know more about file permissions. Ultimately, knowing how permissions work on your server will strengthen your security posture. In other words, knowledge about security concepts helps you develop a keen sense that stops you from doing things like granting full 777 permissions on a file (even if your theme documentation tells you to), or noticing when you have strange file permissions that could be the warning signs of an intruder.

Read More

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://" 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://cloudflare.com/server-status/ (FIXED)
http://disney.go.com/server-status/ (FIXED)
http://tweetdeck.com/server-status/ (FIXED)

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.