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

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/

Dealing with WordPress Malware

A few months back I contributed to a post with Smashing Magazine on the top 4 WordPress Infections, it was released yesterday, and it couldn’t have been at a better time. If any one attended WordCamp Las Vegas you might even find some similarities. Fortunately in the process of preparing for the event and working with the team, we were able to compile a bit more information expanding on the things we originally discussed in the last post. It’s perfect timing for a number of reasons, and will complement this post very nicely.

WordPress Malware
The idea of this post, like many in the past, is to outline and discuss this past weekend’s presentation. In the process, hopefully you take something away. Unfortunately, the presentation was capped off with a live attack and hack, and I won’t be able to include that in this post, but I promise it’s coming.

**Note: If you plan to be at WordCamp Philadelphia 2012 you might be in for some treats, just saying. And if you don’t have it on the calendar, you should.

Read More

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

Pharma Hack Backdoor Analyzed – PHP5.PHP

Some of you might remember my last Pharma hack post, Intelligent (Pharma) SPAM Decoded, today I will spend some time looking a different variant of the same infection type but focus on a payload that is not encoded or embedded within an existing file, instead it resides in its own file – PHP5.php.

“Hmm, maybe it’s a good / system file, it does have PHP in it, I won’t bother looking at it…”

If you have ever come across this file and find yourself thinking this, we highly encourage you not to and take a minute to see if any of its components resemble what we’re about to share.

Dissecting the Payload


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.

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.