PHP Callback Functions: Another Way to Hide Backdoors

We often find new techniques employed by malware authors. Some are very interesting, others are pretty funny, and then there are those that really stump us in their creativity and effectiveness. This post is about the latter.

Everyone who writes code in PHP knows what the eval() function is for. It evaluates a string as PHP code. In other words, it executes the code. But there are certainly many other ways to run a code, which are not always so obvious. The most popular and commonly used one is the preg_replace() function.

According to its description, the preg_replace functions “performs a regular expression search and replace.” Unfortunately, when using the “\e” modifier, this function also runs the code. Yes, there are more ways of running the code without using the eval() function. Example could be the create_function(), or the assert() function. All these options of running the code makes malware analysis all that more complex a process.

Read More

New iFrame Injections Leverage PNG Image Metadata

We’re always trying to stay ahead of the latest trends, and today we caught a very interesting one that we have either been missing, or it’s new. We’ll just say it’s new.. ;)

We’re all familiar with the idea of iFrame Injections, right?

Understanding an iFrame Injection

The iFrame HTML tag is very standard today, it’s an easy way to embed content from another site into your own. It’s supported by almost all browsers and employed by millions of websites today, use Adsense? Then you have an iFrame embedded within your site too.

Pretty nifty, I know. Like with most things though, the good is always accompanied with the bad.

Read More

Another Fake WordPress Plugin – And Yet Another SPAM Infection!

We clean hundreds and thousands of infected websites, a lot of the cleanups can be considered to be somewhat “routine”. If you follow our blog, you often hear us say we’ve seen “this” numerous times, we’ve cleaned “that” numerous times.

In most cases when dealing with infected websites, we know where to look and what to remove, generally with a quick look we can determine what’s going. Despite our experience and passion for cleaning up a hacked website, there are always surprises lurking and waiting for us, almost every day.

Some of the most interesting routine cases we deal with are often websites with SPAM. SPAM is in the database, or the whole block of SPAM code is stored in some obscure file. We also deal with cases where the SPAM is loaded within the theme or template header, footer, index, etc. Sometimes these SPAM infections are conditional (e.g. They only appear once per IP), sometimes not.

More often than not however, these infections is not too difficult to identify and remove. In the case we’re writing about in this post, we were able not only to remove malware, but also take a look at what’s going on behind the curtain.

Read More

Sucuri – Decoding Obfuscated PHP

We are happy to release a new tool for you Do It Yourself (DIY) types. Every now and then you might come across a variety of obfuscated injections in your PHP files and might find yourself wondering,

Wonder what that does?

Not to fear, Sucuri is here and we have a cool little tool that will help you take a look up it’s skirt. If nothing else this will you developers better understand how good is used for evil.

The one very cool thing about it is that it will decode as many layers as possible until it reaches a layer it is unable to decode. In our testing we have found a few strands that have gone down 20 different layers of obfuscation before it got to a point where it needed human intervention. Here is an example of 13 layers with a final output: http://ddecode.com/phpdecoder/?results=54a91431e44ab48462d4db6a59ae3db8

You can decode your obfuscated PHP here: http://ddecode.com/phpdecoder/

Secure Website Development – Importance of Developing Securely

We clean hundreds of sites every day and often their problems are associated with the same issues: outdated and sometimes unnecessary software, weak passwords and so on. But sometimes the issue is not as superficial, sometimes it goes a bit deeper than that. You know your server is updated, your CMS is also (ie., WordPress, Joomla, Drupal), yet you still get infected! How is that possible?!

That’s the question we hope to address in a series of posts related to developing with security in mind. This unfortunately is not something tailored for end-users, unless as an end-user you’re responsible for the development of your website. It is however good for end-users to read as it’ll help better understand other possible vectors affecting their infection or reinfection scenarios.

Read More

Sucuri is Hiring: Senior PHP Developer

It’s that time again. We’re actively looking for a Senior PHP Developer to join the family. If you are passionate about web-based malware, and you want to help build awesomess, we want to hear from you.

Details can be found here Sucuri employment.

PHP-CGI Vulnerability Exploited in the Wild

When the PHP-CGI vulnerability was disclosed, we knew it would be just a matter of days before it started to be exploited in the wild.

Well, it didn’t take long. Since the weekend, we started to see scanners looking for that vulnerability on our servers and honeypots. And now we are seeing sites getting compromised through it as well.

Understanding the Attack

So far we noticed that the attack starts in two ways, either by checking if the server is vulnerable using the ?-s option (which shows the source of the page):

Read More

WordPress 3.2 and PHP support – Security effect

WordPress 3.2 is going to be released very soon and one of the biggest changes is that they will drop support for PHP4 and all versions of PHP5 bellow 5.2.4.

WordPress.org has provided some informative posts about their reasons for dropping support for these PHP versions.

But how will that affect their user base? And how many users are still using these old versions of PHP? We did some scanning and reached around 90 thousand self-hosted WordPress sites that had their PHP version displayed (via the Powered By header).

These are the numbers we found in our analysis (version with less than 0.2% were not displayed):

0.9% – PHP/4.3
5.1% – PHP/4.4
6.0% – PHP/5.1
0.7% – PHP/5.2.0
0.4% – PHP/5.2.1
0.4% – PHP/5.2.3
8.3% – PHP/5.3
76.4% – PHP/5.2.4+

What does this mean? It means that for 84% of the users, based on our numbers, nothing will happen. They will be able to continue using WordPress happily without major changes.

However, almost 15% of the users may experience problems when upgrading to WordPress 3.2 because of their current environment. They will have to contact their hosting, or try to figure out how to update PHP manually.

One of the great benefits in WordPress is the automatic update functionality. However, our analysis estimates that the move to require PHP 5 could leave roughly 15% of WordPress users with no easy update path. When you think of the big market share that WordPress owns, this makes for a very large amount of websites that will potentially remain out of date and vulnerable to attacks.

Will we see a higher number of outdated WordPress instances due to the move? It does seem the number will increase, at least until hosting providers step up their game (which I hope they will do soon).

If you’re running WordPress and aren’t sure what version of PHP your running, contact your hosting provider. Ask them, and if they’re running anything below 5.2.4, we recommend asking them to upgrade as soon as possible (or consider switching hosts). You can also scan your site here to see which version of PHP you are using: http://sitecheck.sucuri.net.

So what do think? Good move by WordPress? Bad environment management by hosting providers? Can and will this lead to more hacked sites?

We’d love to hear from you, make sure to leave us a comment.