Author | Thread |
|
01/13/2008 11:27:32 AM · #1 |
I have a number of websites using PHP and running under Linux.
Despite the security permissions being properly set to 644 (and likewise for the parent folders), I've found that hackers have managed to change the PHP code to put they're links to sex sites in the headers/footers, and their popup ads.
I can't find anything on the web that explains how they do this, nor how to prevent it.
I guess it's possible they are hacking passwords, but I kind of doubt that.
Before I go posting in a bunch of external forums I thought I'd see if we have any security experts here. Is there another explanation?Anyone here an expert, or know a good site to read about securing your site from this type of attack? |
|
|
01/13/2008 11:30:43 AM · #2 |
It really depends on your scripting. Did you write the PHP yourself? Is it something you downloaded? What version PHP? There's too many variables to adequately address why this has happened to you without specifics. |
|
|
01/13/2008 11:38:53 AM · #3 |
The answer is both. I am not sure how it matters--they are actually modifying the files, not injecting code at run time (to the extent that I understand that hack, which isn't to a large extent.)
A good example of the latest file they hacked was simply a redirection link. The file, index.php:
header("Location: //example.org/links/exmple/problemreport/example.html");
?>
|
|
|
01/13/2008 11:44:09 AM · #4 |
Neil, is it possible that the problem isn't with your code, but with the server's security? If they breach security on the server, they can modify files at will.
Edit for typo
Message edited by author 2008-01-13 11:44:30. |
|
|
01/13/2008 11:46:32 AM · #5 |
In that case, kirbic is probably on the right track. If it's a shared server at some host, I'd bring it to their attention. If it's your server, try prodding it with a security probe to see if there are any obvious vulnerabilities. |
|
|
01/13/2008 11:48:48 AM · #6 |
Fritz--I was thinking that. It's a VSP, and there are of course lots of other people on the server.
But still, if the unix permissions are 644, how does the OS let someone other than me modify the file? Wouldn't they need a root account password?
Here's a temp link to phpinfo on my server, if anyone sees anything there...
This is controlled at a level above my securitylevel, but if there's something poorly set, I can ask my service provider.
|
|
|
01/13/2008 11:51:35 AM · #7 |
PHP 4.3.11 - there's your problem. :-) That's ancient and buggy, vintage 2005 PHP. Upgrade right away to the latest 4, if that's what you want, which is 4.4.8. Better yet, go to version 5.2.5. Your version of PHP has a header injection bug that was fixed in 4.4.2, at the beginning of 2006. |
|
|
01/13/2008 11:54:57 AM · #8 |
Personally, I would change hosting companies :-/ Almost everyone runs in a shared hosting, so the hole could be another site on that same server (or as someone mentioned the security of the server from outside - less likely).
Message edited by author 2008-01-13 11:55:32.
|
|
|
01/13/2008 11:58:16 AM · #9 |
To answer your question about permissions, it's not necessary for the files to be incorrectly secured in order for an injection hack to succeed (as you probably know). The script process likely runs under your user id, so the header injection could theoretically run PHP code to modify your files. Since your one line script runs the header() command, this is the likeliest scenario. |
|
|
01/13/2008 11:58:18 AM · #10 |
Wayyy old php version...it's not even supported for security fixes.
Originally posted by nshapiro:
But still, if the unix permissions are 644, how does the OS let someone other than me modify the file? Wouldn't they need a root account password?
|
They probably have it ;)
But even if they don't .. if the rest of the sofware is in the above state there's probably a lot of security flaws that can give a root account without a password.
-N.
|
|
|
01/13/2008 12:11:11 PM · #11 |
Originally posted by Louis: To answer your question about permissions, it's not necessary for the files to be incorrectly secured in order for an injection hack to succeed (as you probably know). The script process likely runs under your user id, so the header injection could theoretically run PHP code to modify your files. Since your one line script runs the header() command, this is the likeliest scenario. |
Well I have a lot to learn about security!
But with what little I know, I don't understand, with a hard coded URL, and a protected file, how could they inject anything here?
This is just one example. Recently, my wordpress installation was hacked. Same issue, security was set.
I don't know why Hostrocket hasn't updated PHP for that server. But I will ask. (And I'll check my other servers.)
Anyone know a good book on securing Linux servers and PHP that will get me up to speed relatively quickly (or a security cookbook ;) )
|
|
|
01/13/2008 12:27:07 PM · #12 |
Originally posted by nshapiro: Originally posted by Louis: To answer your question about permissions, it's not necessary for the files to be incorrectly secured in order for an injection hack to succeed (as you probably know). The script process likely runs under your user id, so the header injection could theoretically run PHP code to modify your files. Since your one line script runs the header() command, this is the likeliest scenario. |
Well I have a lot to learn about security!
But with what little I know, I don't understand, with a hard coded URL, and a protected file, how could they inject anything here?
This is just one example. Recently, my wordpress installation was hacked. Same issue, security was set.
I don't know why Hostrocket hasn't updated PHP for that server. But I will ask. (And I'll check my other servers.)
Anyone know a good book on securing Linux servers and PHP that will get me up to speed relatively quickly (or a security cookbook ;) ) |
Having said all this, the hacked file is not necessarily the file causing the problem. Some other PHP script is the more likely culprit. The way to trace this is to look at the file modification time of the hacked file. Then, comb your website access logs (the raw logs, not any analysis of those logs) for suspicious hits to your site correlating with those times. You'll find the offending script that way.
Edit to add: again, the file permissions are irrelevant because the script is running under your user id, with all your permissions, and is likely executing injected code that modifies files, all under your user id.
Also, your host should be able to help. If they have any kind of decent support, they'll assist you as a matter of course, and if they're any kind of decent host at all, it's in their interest to get to the bottom of this.
Message edited by author 2008-01-13 12:31:30. |
|
|
01/13/2008 12:35:46 PM · #13 |
Does the script/application in your /photodir allow file uploads from the general public? Have you masked out, say, .php files?
|
|
|
01/13/2008 01:44:57 PM · #14 |
Originally posted by kirbic: Neil, is it possible that the problem isn't with your code, but with the server's security? If they breach security on the server, they can modify files at will.
|
My suspicion is that kirbic is exactly right. On shared servers there are that many more opportunities for a machine to be compromised because so many people have a chance to make stupid mistakes, pick bad passwords, etc. Using any number of known arbitrary code execution exploits attackers can gain root access at a host OS level, enabling them to mess with any file on the server regardless of it's permissions (since root can change the permissions on files that even it can't write to). The fact that, as was pointed out above, the PHP version running is WAY outdated and insecure leads me to believe that the hosting operator either doesn't understand security or doesn't care about it. PHP may have been the way they got in as likely as other unpatched services on the server.
As a security consultant I've seen many MSPs and ISPs that are, at best, ambivalent about security and, at worst, clueless. It is unfortunate. The fortunate part for you is that they made changes that you could spot. I've done forensic workups on a number of cases where the attacker ran rootkits that hid their presence allowing them to hang around for weeks or months and harvest sensitive information undetected.
A major bank client once showed me some tests they'd run where they put credit card account information (not a real account, of course) on standard install Windows machines and attached them to the internet. In the most extreme case a *physical card* made up with that information showed up in use in a major US city in less than a half an hour. The average for seeing the information stolen was less than 1 hour. An unpatched server will not stand any better chance.
I would change hosting companies *today* if your site is in any way tied to your livelihood or has sensitive information on it. Chances are, once a box is "pwned" the only way they will get rid of the attacker is to format the server and start over. Based on what you've said I doubt that will happen.
Good luck with it,
Greg
=== Edited for typos (twice). Wow, I really should read before hitting post! :-) ===
Message edited by author 2008-01-13 13:49:12.
|
|
Home -
Challenges -
Community -
League -
Photos -
Cameras -
Lenses -
Learn -
Help -
Terms of Use -
Privacy -
Top ^
DPChallenge, and website content and design, Copyright © 2001-2025 Challenging Technologies, LLC.
All digital photo copyrights belong to the photographers and may not be used without permission.
Current Server Time: 09/10/2025 10:47:21 PM EDT.