Malware Infection – Blocked by Day Limit

This week while working on a compromised site, I found an interesting variation of the Blackhole injection. We work with many sites injected with Blackhole, like this one:

Blackhole Injection

However, on this specific site, instead of the common injection we were expecting, there was an unocommon error:

Read More

Google Transparency Report – Malware Distribution

Google just released their Malware Distribution Transparency Report, sharing the amount of sites compromised or distributing malware detected by their systems (Safe Browsing program).

Google’s Safe Browsing program started in 2006 and since has become one of the most useful blacklists to detect and report on compromised sites. They flag around 10,000 different sites per day, which are being used for over 1 billion browser (Chrome, Firefox And Safari) users.

What is really scary from their report is the amount of legitimate compromised sites hosting malware compared to sites developed by the bad guys for malicious purposes. For example, in the first week of Jun/2013, 37,000 legitimate sites were compromised to host malware. At the same time, they only identified around 4,000 sites that were developed for the unique purpose of infecting people.


Read More

WordPress 3.5.2 Security and Maintenance Release

The WordPress team just pushed out a new version of WordPress (3.5.2) that has some security bugs fixed. Straight from their release post, these are the security changes:

  1. Blocking server-side request forgery attacks, which could potentially enable an attacker to gain access to a site.
  2. Disallow contributors from improperly publishing posts, reported by Konstantin Kovshenin, or reassigning the post’s authorship, reported by Luke Bryan.
  3. An update to the SWFUpload external library to fix cross-site scripting vulnerabilities. Reported by mala and Szymon Gruszecki.
  4. Prevention of a denial of service attack, affecting sites using password-protected posts.
  5. An update to an external TinyMCE library to fix a cross-site scripting vulnerability. Reported by Wan Ikram.
  6. Multiple fixes for cross-site scripting. Reported by Andrea Santese and Rodrigo.
  7. Avoid disclosing a full file path when a upload fails. Reported by Jakub Galczyk.


Read More

New Apache Module Injection

For the last few months we have been talking about the Darkleech Apache Module injection that is being used to insert malicious iframes into every site hosted on a compromised Linux server.

However, this past week we detected a new type of Apache module injection that is more subtle and increasingly difficult to detect. We don’t know if it is a new and improved version of Darkleech or a completely different tool written by a different group. Our team is still working on the binary and trying to scope the reach of this infection, so we will only post our preliminary analysis here.

Identifying the injection

The first sign of this injection can be identified remotely by an iframe injection like this one:

<iframe src=httpx://ajaxfamilies[.]org/go[.]php?sid=3 width=1 ..

That gets randomly prepended at the top of the pages loaded from the compromised server. That injection is conditional, so depending on the browser, referrer or IP address it may not show up. Google also says that 500+ sites have been distributing malware through this domain (ajaxfamilies.org):

Has this site acted as an intermediary resulting in further distribution of malware? Over the past 90 days, ajaxfamilies.org appeared to function as an intermediary for the infection of 562 site(s) including ajbridalwear.co.uk/, global-lcs.com/, trattamento-acque.net/.

Note that the domain ajaxfamilies.org might not be the only one being used (and it might change or rotate soon). However, from the servers we were able to gain access to, it was the main domain being used.

Apache Module injection

The injection is being done in the same way was before, by modifying one of the httpd configuration files (either conf/httpd.conf or conf.d/*.conf) and inserting a new module to be loaded:

LoadModule suphp5_module modules/mod_suphp5.so

Note that mod_suphp5 is a false module and not the popular mod_suphp one. We have also seeing it injected by overwriting the default mod_version.so with a fake one:

LoadModule version_module modules/mod_version.so

Those new modules are very small in size and have 0 detection rate by common anti virus software, according to virus total.

This is their identifier (size and md5 checksum):

$ ls -la *.so
-rwxr-xr-x 1 dcid dcid 15472 19 Jun 14:03 mod_suphp5.so
-rw-r–r– 1 dcid dcid 15472 17 Jun 18:53 mod_version.so
$ md5 *.so
MD5 (mod_suphp5.so) = 0a64f8d809d0a73d1b0b4139126e8f94
MD5 (mod_version.so) = 71e800af61521ff4390bf9845befa33a

It uses Apache’s portable memory pool to store the list of IP addresses that visited the site before and to decide when to inject the malware. It also has a backdoor part of it, allowing the remote attacker to run any command as the user Apache.

This module has some unique signatures that you can use to search for it. At this point we recommend looking for AWAVAUATUS1 on the modules directory:

$ grep -r AWAVAUATUS1 /etc/httpd/modules
Binary file /etc/httpd/modules/mod_version.so matches

You can also search for execl or getppid on the module directory and see if any suspicious file comes up. On the default Apache/PHP install, only libphp5 would have a call for execl or getppid on it.

If you suspect a site might be compromised, our sitecheck scanner should be able to identify this type of injection.

What’s next?

It seems the switch from site-level injections to server-level injections is really here to stay. If you don’t know how an attacker with just basic FTP or restricted access can get root, take a look at this series of posts we are doing:

We will also provide more information as we learn more about it.

Brazilian Protests Leading to Mass Defacements

Lately, Brazil is going through a series of political protests against the current administration and the large amount of over expenses related to the 2014 Soccer/FIFA World cup. When the police started to close down the protesters in the streets, they went online. We won’t go into much more politics, but those online protests recently switched from Twitter/Facebook discussions into a mass defacement of multiple high profiles sites (and Twitter accounts).

It includes the Twitter of the Veja Magazine (with over 2.5m followers – one of the biggest in Brazil):

Revista Veja compromised

And the site for Brazilian’s richest man, Eike Batista:

Screen Shot 2013-06-17 at 5.09.36 PM

Government sites affected too

And that’s not all, many government sites are getting hacked and defaced as part of the protest. All of them begging for the population to join them in the streets and in front of the soccer stadiums to show their dissatisfaction with what is happening. This is a small list of the ones defaced early today:

http://samu192.com.br/

http://www.juazeirinho.pb.gov.br/

http://www.camaradocabo.pe.gov.br/

http://www.macaeprev.rj.gov.br/

http://www.ciscel.mg.gov.br/

http://copa2014.gov.br/

http://www.saofelixdoaraguaia.mt.gov.br/

http://copaemcuiaba.com.br/

http://www.frentedetrabalho.sp.gov.br

We are also seeing some sites suffering from DDOS (denial of service) attacks. We don’t know exactly how those sites are getting hacked, but we will keep monitoring the situation and providing updates as they come. Note that none of the compromised sites were injected to host malware.

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

vBulletin Conditional Malware – myFTP.biz Malicious iFrames

We have to be honest here, there’s no fun in cleaning up infected .htaccess files. It’s boring, but it happens a lot! But it’s not the case here. I will also caveat that while in this specific instance we’ll be talking to one specific platform, we are seeing this same tactic spread across a number of other popular platforms as well like Joomla and WordPress.

There are different types of infection, some are automated (like the htaccess I mentioned) and some are targeted and well crafted, like the one we saw today.

One of our clients was receiving complaints from the site’s readers that when accessing the site it was trying to do a drive-by-download, install malicious software on their computer[s].

When checking the page source we found the following code in the headers:

Screen Shot 2013-06-12 at 12.57.21 PM

This code translates into a hidden iframe:

Read More

Plesk 0-day Remote Vulnerability in the Wild

Just last week another 0-day vulnerability on Plesk was released. It affects Plesk 9.2, 9.3 and 9.5.4 versions. If you have not yet, we recommend that you update Plesk immediately.

Note: In our latest analysis of servers with the Apache binaries or modules compromised (DarkLeech or Cdorked.A), Plesk is often one of the entry points.

Technical Analysis

The exploit was released last week by Kingcope with a sample exploit to “test” if a server is vulnerable. The vulnerability comes from this Plesk configuration:

scriptAlias /phppath/ “/usr/bin/”

This allows any one to execute the PHP interpreter. Upon calling the PHP binary, they can pass commands very similarly to the CVE-2012-1823 (PHP CGI bug):


Read More