Server being taken down "Hacked By BlackHacker"

Portal Home > Knowledgebase > Articles Database > Server being taken down "Hacked By BlackHacker"

Posted by Pradeepteam, 06-13-2010, 12:36 PM
Hello, We have lots of sites on the server and unfortunately they are being hacked by hackers and most of the sites are showing "Hacked By BlackHacker" They are taking on almost every site . We scanned the server and dint find anything through Clamscan. We have no passwords changed. We request you to please let us know a solution for this. "Hacked By BlackHacker" Code is shown below Last edited by bear; 06-13-2010 at 01:23 PM.
Posted by 4Drive, 06-13-2010, 12:43 PM
From which country you are?
Posted by Pradeepteam, 06-13-2010, 12:45 PM
We are from INDIA, You seem to be from pakistan any help ?
Posted by 4Drive, 06-13-2010, 01:15 PM
Ya, i am from Pakistan but i am not a security expert, i 'll love to solve your problem but i don't know what to do. There is also an email in that source of page, did u contact them? - Peace
Posted by Pradeepteam, 06-13-2010, 01:17 PM
No, we do not wish to, It makes the problem go more . Waiting for some expert to take a look.
Posted by 4Drive, 06-13-2010, 01:45 PM
can i have a link to your main page?
Posted by Pradeepteam, 06-13-2010, 01:48 PM
We cannot damage our privacy that way.
Posted by fwaggle, 06-13-2010, 02:19 PM
Are you running suPHP and suexec? If you aren't, there's probably not much to be alarmed at - if your scripts are running as www, and one of them has a vulnerability that allows arbitrary code execution, that can allow that arbitrary code to simply go through and modify all files that it has access to write to, including on other peoples sites. Anything that's +w to either everyone or the web server user is fair game, and sometimes the likely culprit is configuration files. Prepend some naughty output to most webapp's configuration files, end it with a die() or an exit() and all a visitor will see is the naughty stuff. Is it every site on the server, or just some? Are they being done one at a time, or does it look like they were all done at once? If you're running suPHP or something similar, I'd probably suspect the server's rooted. Format+reinstall, restore user data from backups (you have backups, right?). If you suspect a machine's rooted, it's not worth the guessing game of trying to figure out if you've cleaned everything or not. Start from scratch. If you're still unsure of where to go from here, I believe guys like Scott or Steven (from admingeekz and rack911 respectively) can help you figure out what's going on... for a fee.
Posted by kbeezie, 06-13-2010, 02:26 PM
while maybe not directly related to your problem. stop using FTP and start using SFTP/SCP. Too many people have been "hacked" simply because their FTP traffic has been compromised.
Posted by Pradeepteam, 06-13-2010, 02:26 PM
Hi, Thanks a lot for your brief reply. We are running it as suPHP and run it as CGI. We noticed most of the wordpress, joomla, ecommerce sites having index.php have been hacked. We have backups but are you guessing that the entire server is compromised ? Even after we re install, It might happen right ? Kindly advice.
Posted by kbeezie, 06-13-2010, 02:30 PM
Normally when a client comes to me with an iframe injection attack, or hijacked page its due to using FTP to transfer their files. What happens is sometimes there's a trojan or virus on their system that listens in on port 21. FTP is insecure and when you connect the trojan then has your FTP's user name and password (Check your FTP logs to see if you had multiple logins finding specific files and changing them). As a result even if you changed your password the trojan would just pick it up again. So your best bet is you run a virus scan on your system (updated) and see if there are any infections, change your password via the panel or SSH, and use SCP/SFTP for file transfers. Like I said may not be your problem, you may have a poorly written script, or something with an exploit, but also as I said most of the time when one of my clients comes to me with such a problem it usually boils down to compromised FTP credentials.
Posted by Pradeepteam, 06-13-2010, 02:34 PM
Hello, But its not one or two sites of MINE that have been hacked, Many such and each site belonging to some person of different country. We have been using some sites for one year with out this problem. We use licensed version of Anti Virus and we are making sure that the System is clean.
Posted by kbeezie, 06-13-2010, 02:49 PM
by the way I meant antivirus on the user's computers who have access to the site's files, not the server itself. Also if that is not the case then my next best guess based on so little information would be you're using software that is either old, or has an exploit.
Posted by Pradeepteam, 06-13-2010, 02:51 PM
In such case, we cannot ask all the clients , end users to have updated version of antivirus on their systems because its not their site getting in trouble, Its the entire server . So , we guess we need to take proper measures from servers end to avoid this. Can you suggest us the way avoid this or find the hacker living on the server?
Posted by kbeezie, 06-13-2010, 02:56 PM
Well if its possible that a single compromised user affected the entire server instead of just the user I'd look at how you're hosting each user (as their scripts, accounts, etc shouldn't be able to see outside of their home folder). Also have you attempted to look at access, error, ftp logs around the time the intrusion happened? Do you perhaps have a server technician on hand to do the above? But when you notice an automated attack against index.php files especially of popular scripts, that just screams the FTP exploit to me, which means one of your users is infected. But it still disturbing that one user's account can affect all the other's sites if that is the case. (unless of course the user of the root login is infected...) PS: only showing us the HTML code of the hijacked page is too little information. Last edited by kbeezie; 06-13-2010 at 03:00 PM.
Posted by Pradeepteam, 06-13-2010, 02:58 PM
Yes , we have accounts and they cannot view anything outside their home folder.
Posted by jdbravo, 06-13-2010, 03:10 PM
First you need to check if the attacker get a root access, please give us information about your OS, versions, are you using a webhosting panel? paste here ls -l index.php, check the last logins to your server using last command.
Posted by fwaggle, 06-13-2010, 03:13 PM
So is it many accounts on the server or just one account with multiple sites on it? You mention one person from another country, but I can't tell if maybe english isn't your first language. If it's localized to one account, I wouldn't panic - most likely outcome is one account compromised. If it's multiple accounts, and you're using suPHP or suexec, I'd really start to consider the possibility of the server being compromised completely. While I am loath to suggest people keep using plaintext authentication methods, particularly today where your microwave probably has enough computing power to encrypt things... I'm personally skeptical about this claim. In order for this to be the case, you'd have to have some device somewhere in the path of the data compromised to be able to snatch credentials over the wire. In the case of switched networks, I personally think this is far less likely than the credentials just being stolen at the end of the pipe - which can happen with encrypted protocols almost as easy.
Posted by Pradeepteam, 06-13-2010, 03:14 PM
No, the password does not seemed to be changed . We have neither got any alerts of root login by the hacker. We checked the login history and its ours and data centers. We are using Centos 5.5 Control Panel - Cpanel / WHM
Posted by Pradeepteam, 06-13-2010, 03:17 PM
Hello, Sorry for our bad english. Yes, there are many Cpanel accounts of different users got hacked but only index.php file has been altered. Rest of the files are as they are. But if the server is compromised and we restore from our latest backups, Is it not there any chance that hacker might attack the server again ?
Posted by kbeezie, 06-13-2010, 03:20 PM
Password not being changed is no indicator of not being compromised, it could be just as likely that the root login has become known and as such no need to change the password.
Posted by jdbravo, 06-13-2010, 03:31 PM
If you dont fix the problem, the attacker may do it again. First you need to know how the attacker altered your files. If you are running SuExec or PhpSuExec and you have it correctly configured is possible that all your server is compromised. SuExec by default does not allow to have files with write permissions to the group or others users. Please paste here ls -l index.php The legitimate content of the file is still in the file? because if the content is still there you can do bash script to clean your files.
Posted by fwaggle, 06-13-2010, 03:35 PM
Don't sweat it, you're doing fine. Not a problem, they probably did a find to get all those files. As stated above, password not being changed is no indication of there being no root compromise. Was the password easy to be cracked? Is there any extra uid 0 accounts? Any keys in root's authorized_keys[2]?, and is permitrootlogin enabled? It could be anywhere (or it could be nowhere, and you'd never know), that's why I always suggest if you suspect a root compromise, to format + reinstall, then restore backups. Perhaps, but maybe next time you can not have the outdated software or whatever it was that was the source of the compromise. It could be that because it was a mass defacement, that it was just a case of low-hanging-fruit, and the attacker won't even make an effort if you've plugged the hole. As stated by the above poster, if you don't plug the hole, the attacker will almost definitely do it again.
Posted by Gary4gar, 06-13-2010, 04:33 PM
Bad Security Practices. Best thing is to Format fully and start over again. and do full security hardening. now wait for few days before restoring from backups. to if attackars might have got hold of a 0zero day exploit. If you are not hacked again, then start restoring old account, One by Once - examining files related to account closely and assisting customers to upgrade to latest versions of Scripts.
Posted by VL-Adam, 06-13-2010, 04:40 PM
My recommendation is that you go to a server management company to clean and secure your server.
Posted by Pradeepteam, 06-13-2010, 10:06 PM
But our server is managed. We are performing clamscan , Does it solve the issue.
Posted by PPOwens, 06-13-2010, 11:52 PM
More than likely they have spread the exploit or shells, which ever they are using, but if you block them out this time and take action on security, they wont be able to use what they have there.
Posted by Pradeepteam, 06-13-2010, 11:52 PM
We noticed a script on an account and found its C99 How to stop it now ? Do we need to re install OS and start again ? We have one week back backups, This might cause a huge problem to users Any suggestions on how to stop it execute or find, delete.
Posted by madlymasterful2018, 06-14-2010, 02:47 AM
If possible please send me your link to your website. Let me scan from my end..
Posted by Pradeepteam, 06-14-2010, 02:49 AM
We have now removed the C99 shell script , Scanner ? Can you provide us link to scan ?
Posted by khunj, 06-14-2010, 05:48 AM
You should not re-install. Those hacks are done by 13-15 years old script kiddies using remote file inclusion. Look at the modified files timestamp, then check your HTTP logs at that time for weird POST requests followed by several GET all from the same IP. That way you will find the vulnerable script (mostly Joomla/OSCommerce or Wordpress plugins/modules).
Posted by Pradeepteam, 06-14-2010, 06:07 AM
Can you please provide us steps , guidelines to prevent them get execute on the server again ?
Posted by Gary4gar, 06-14-2010, 07:13 AM
The problem is -- you are not giving any info. Anyone here trying to help you would be walking blind. making guesses on what might have happened. I hope someone where has some magical powers to know whats wrong with server and fix it without even seeing it Good Luck find that man
Posted by PPOwens, 06-14-2010, 08:43 AM
Removing it wont solve your problem, you might as well just give the link to the world, well google does that for you. I have sent a PM, i can provide the info or i can do it for you to block the script kiddies toys.
Posted by bear, 06-14-2010, 09:01 AM
I certainly hope that the PM wasn't an offer to do it for pay. That would be against our rules.
Posted by server prodigy, 06-14-2010, 09:46 AM
If your server is "managed" you need to find a new host who takes security seriously. Users will make mistakes and do stupid things but a good host can secure the system so it's protected against such things. It sounds like you need to hire someone to manage your server, period. Unless or until you can learn all the necessary skills you can count on your server being hacked like this on an ongoing basis.
Posted by mellow-h, 06-14-2010, 10:17 AM
Couple of things will help you protect these attacks: 1. Install mod_security with gotroot rules. 2. Mount tmp with noexec 3. Install lfd and run the directory watch. It seems one of your user account is hacked and it has downloaded the malicious file. This file is running using the /tmp directory most likely. Hiring a server management company would be a better idea in this time considering your situation.
Posted by fwaggle, 06-14-2010, 11:12 AM
C99 doesn't (usually) run from /tmp, and if it did, mounting /tmp noexec wouldn't stop it.
Posted by mellow-h, 06-14-2010, 11:38 AM
I didn't really mean C99 shell. Mass index.php replaces are sometimes done using the bds script. Those are exploited usually using the /tmp
Posted by fwaggle, 06-14-2010, 03:50 PM
Sure, but there are holes in that interpretation of your response too. 1) Mounting /tmp noexec does almost nothing to prevent execution (despite what it's name may imply) because "execution" is such a muddy concept, precious little of which has anything to do with file systems. Mounting /tmp noexec is on par with renaming/removing/chmoding wget - it'll break (some) canned hack scripts and that's it. 2) If there was a script being run out of /tmp that was finding and modifying index.php, because OP says his server's running PHP su'd, one could logically conclude that the machine's been rooted (unless there's some really whacked out permissions on web accessible directories), at which point the only real-world solution - that doesn't involve playing whack-a-mole with invisible moles - is a reinstall. 3) mod_security with a decent rule set would probably stop C99 and many of the exploits, but we're still playing guessing games as to how the machine was originally compromised. The only part of your post I can agree with is hiring outside help.
Posted by CodyRo, 06-14-2010, 04:10 PM
This needs a sticky - unless you're literally running binaries on /tmp it's useless.. the majority of hacks and such are from simple scripting languages (python, php, perl) that interpret the script (see: read). @OP Format the machine as who knows the point of entry / what sort of goodies have been left behind. Once you do that ensure permissions are correct, strong password, up-to-date software and if you're a bit paranoid an IDS / firewall services that don't need to be open to the public (SSH).
Posted by mellow-h, 06-14-2010, 04:30 PM
Are you stating it is possible to run scripts from tmp through http when it is mounted as noexec and nosuid? /tmp/bds provides pretty much access of a root, and this backdoor shell can be used in suexec environment if the tmp directory is allowed to execute binaries and I believe my reply was intended to prevent that: http://forum.configserver.com/showthread.php?p=3334 My target was no way intended with c99 shell, c99 shell is a different backdoor and to my knowledge it is not really used to mass replace index files rather used to injections. If you got a paid subscription with gotroot, you surely can prevent those injections with their rules, if you keep them up-to-date.
Posted by fwaggle, 06-14-2010, 04:33 PM
Unequivocally, yes. It's not limited to interpreted scripts either (pardon my very poor programming abilities, I'm sure there's a lot more elegant ways of accomplishing this): I might be wrong on this, but I'm not aware of any systems where noexec restricts LD_PRELOAD. Even if it did, and even if interpreters were all patched to respect noexec, you still have issues with any other directory the owned user can write to. I highly doubt there's nothing. Personally, considering it won't stop much at all, I'd rather just audit stuff being executed out of /tmp. Have your IDS send you a giant alert any time something's run from /tmp and you've got an early warning system that probably 99 out of 100 script kiddies are going to bump right into... or you can have a "security measure" (but not really) that a good one out of ten hackers will just waltz right by.
Posted by mellow-h, 06-14-2010, 04:46 PM
Couple of things I would like to mention, first, the backdoor shell used to mass replace is a binary and second, Cpanel doesn't allow access to GCC as long as the provider doesn't explicitly allow so. Setting environment is also locked for privileged users only. Last edited by mellow-h; 06-14-2010 at 04:50 PM.
Posted by fwaggle, 06-14-2010, 05:10 PM
You're acting as if there's only one way for a hacker to accomplish anything - if that were the case, there'd be no hackers. One could do an iframe injection on index.php with find -exec, and a one-liner with echo or cat or something similar. It could be trivially done in perl, python, etc. Could be easily done inside PHP directly from the remote file includes - the only reason kiddies resort to things like bds and c99 is because most of them aren't very smart. The ones who are, those are the ones you should be genuinely terrified of. If you're using a common flavor OS, the binary needn't be compiled on the machine you're attacking - what do you think shellcode is? Got a link about restricting setenv()? Last edited by fwaggle; 06-14-2010 at 05:14 PM.
Posted by mellow-h, 06-14-2010, 05:48 PM
The way you are stating the hacking method seems it is pretty possible to leak any server. If thus so, there shouldn't be any shared hosting alive. I doubt there wasn't any geek trying to attack hostgator or some other providers in last 6 years. I couldn't set setenv() from the cpanel Jailshell. If you open your backdoors, then why a kid would stop hacking you? And the way you are stating about the exploitation seems unavoidable from what you are explaining and defending. That seems pretty weird IMO.
Posted by fwaggle, 06-14-2010, 06:07 PM
Security's a process, not a goal. I wouldn't consider any server unhackable, but that doesn't mean that the risk can't be managed intelligently. Even if you can't setenv() from an exploited process context (which I've got a sneaking suspicion is a different set of circumstances from a jailed shell, but I know very little about cPanel so I'll just keep quiet), you can accomplish the same feat using the dynamic loader itself... or if there's any binary anywhere on the machine that's got any kind of workable exploit on it (which often things that aren't of a security nature aren't listed as security issues, they're listed as "bugs" to be fixed at leisure) then you could inject code that way. Any file that can be read, can be executed - you're a fool to think otherwise. Having /tmp mounted without noexec is hardly "opening your backdoors", and that's not to say you can't have your IDS kill the process off after it's run. You could mount the filesystem noexec, but I'd be concerned that a hacker that's paying attention will notice this and use another method (which could be as simple as perl /tmp/script.pl) and bypass the IDS. The point is, if someone gets to the point of having any malicious code on your machine, all bets are off and you should be switching from seeking to prevent it, to detecting it so you can take appropriate action. Detection is as much a part of security as prevention is. You're making gross assumptions about how hackers will behave based on the common tools, and in my experience any time you insult the intelligence of hackers out there, you're a mere one pissed-off kid away from hating life.
Posted by mellow-h, 06-14-2010, 06:12 PM
Most importantly, until your server is rooted, how can these scripts actually going to harm the servers with proper permission bits set for other users? My given suggestions were just to help protecting those well known vulnerable scripts. It is more important to investigate issues like this from being in the server, not just by hearing the OP's words. Last edited by mellow-h; 06-14-2010 at 06:18 PM.
Posted by CodyRo, 06-14-2010, 09:11 PM
Interesting, never thought about using LD_PRELOAD.. I would have thought this would have been restricted. Regardless this is just another reason noexec isn't really a decent method of preventing execution of scripts (or binaries in this case). Thanks for the insight
Posted by Sheps, 06-15-2010, 04:48 PM
LD_PRELOAD is a linker setting, which is only triggered once when the process is forked. You would not be able to exploit the httpd process like that. You could potentially exploit the users account however by editing the .bashrc or .bash_profile and waiting for them to login. This would not cause the problems seen here though. At least from what I have seen.
Posted by StevenG, 06-16-2010, 10:56 PM
OK, to replace the files in a users home directory, the uid running that process needs to be able to write to them. This means that user fred cannot or should not be able to overwrite files in user daisies home directory. That goes for apache as well, as suexec, suphp etc, the uid or gid running them need to be able to write. Make sure everybodies public htdocs isn't world writeable. If you can find something that is running with a superuser uid/gid then it's possible using LD_PRELOAD or phps dl() function directly, to include rogue code as example here. Cpanel jailshell only comes into play for ssh access, any process using php, perl or anything else, via the web server or cpanel, is not using any jailshell.
Posted by rive0108, 07-25-2010, 12:22 PM
As for this type of hacking I have looked at some of the sites hacked, and one thing is always the same... the webmaster fails to secure the site...they leave the backdoor wide open , and wonder how they got hacked. Here is what you do to secure your site (before you are hacked-after the fact its a useless endevour): 1. use .htaccess in the /public_html/ direcory in it set up the Options All- indexes directive setup AuthUserFile Directive 2. Use .htaccess in any directory where a User can upload images and/or files to the server: In this file implement Options -ExecCGI Then set the AddHandler cgi-script .pl .py .php .jsp. htm .shtml .sh .asp .cgi .php3 .exe .html .js .dll This will prevent the above scripts (whether hidden in an image file or not) from executing if called. 3. Go through the entire script and change all 'mysql_escape_strings' to "mysql_real_escape_strings", and in those strings where a User can enter data, also use (strip_tags). Pay special attention to the 'referers' and make sure that you properly secure the "checkref()" function(s) The main way they get in is an unsecured site's /uploads directory, and then by looking in the directory and calling to execute the file. other methods entail cross site scripting (XSS using js), and Injection Points (sqli), so you need to determine whether this can be done on your site or not- If it can be, then securing the server wont help you much, and the scripting of your site needs to be re-written. I am not saying my site <> cant be broken, but it'll take a better hacker then "blackhacker" or his "inept" lackeys to comprimise my site. They appear to just hack those sites where it is blantantly obvious that the site is vulnerable (newbie unsecured sites), They are incapable of hacking a hardened site, where real hacking skills are required in an attempt to break it. One more thing, and this is critical! make sure your site/script uses MD5 hashes for passwords, and follow these rules when creating passwords for the db, server and admin. ALWAYS, use random, alpha-numeric-symbol-upper case/lower case passwords at least 8 digits long. NEVER use the same password twice. NEVER enter/or otherwise use a "rainbow" table to generate your password (ALWAYS create your password(s) manually) In my case I use a password for my script admin login, and another password via AuthUserFile Directive to secure the directory. Both are 12+ digits long, and conform to the above guidlines. MD5 passwords, generally while not impossible to break, are very very difficult. Using the above guidlines for password creation will make it all but impossible even if brute force methods are used. also- Most "hackers" assume the admin account is id number one, so be sure to reorder the member/user id's so that the admin user is no longer the first in the table. Also...... DISABLE FTP Accounts when not actively using them! Install good antivirus on your computer (you get what you pay for) Trojans and keyloggers are well known means to gain creditentials to your website. Be wary of perpetual logins, There are methods where a hacker can get your cookie data (usually by getting you to respond to an email). This is a well known hacking method using spoofed cookies/creditentials. In my case I do not use perpetual logins for my admin account, and I run NOD32 antivirus, UAC, Windows Defender, a software firewall, and a hardware firewall. Security doesnt happen by itself folks, be proactive, or be hacked. Its your call. I am done here. Sorry for the multiple posts-I was not able to edit and combine them all into a single post. Later. Last edited by bear; 07-25-2010 at 01:09 PM.
Posted by bear, 07-25-2010, 01:10 PM
Happy to fix that for you. wht:

Add to Favourites Print this Article