| 7:00 pm on May 31, 2009 (gmt 0)|
Repost of my answer the other day, seems to be a popular topic:
Standard Frame Injection Attack
I'll guess you're on a shared server, when the hacker infiltrates the server they usually infect many, if not all, sites on the server.
Your host will most likely tell you it's your fault and you need to change your FTP password which is a very common answer (dodge) from hosts with a real problem that don't know how to control it.
However, check your site to make sure you don't have any vulnerable PHP scripts installed like an out of date Word Press, Joomla, or something else that could compromise your account.
Best thing to do IMO is to update everything including who hosts the site
| 7:01 pm on May 31, 2009 (gmt 0)|
That's called an iframe injection. The page served by that iframe can do almost anything, and its code may even change everytime it loads. Unless you are a security expert, I would not recommend trying to find out the specifics.
The most common use I've seen for iframe injection is to attampt to install some kind of malware - make the page visitor part of a botnet, install a keylogger, hijack the intended urls, etc.
Best advice - update your server software to the most recent versions and patches, change your password, and upload clean source code for your pages. If you are on shared hosting, let your web host know about it.
| 9:03 pm on May 31, 2009 (gmt 0)|
the site is on dreamhost private server. all of the sites under that user account were infected with this iframe code. it does not seem like any of the other user accounts/sites were affected. all of this happened on may 27 at 11:30p. I could tell by the date modified of each file.
im thinking someone/thing hacked in through ftp and then ran a script to append all the html php files with that iframe code.
the biggest question is how did they get the ftp login info if that is in fact how they did it?
luckily for me I had a tar backup that saved me. although when i looked further I found a few files that semantec identified as viruses. PHP.RSTBackdoor
| 9:08 pm on May 31, 2009 (gmt 0)|
It's usually easier to hack in via old PHP apps that haven't been updated.
I'm always amused by the assumption it's FTP unless you're not running secure FTP and/or using wifi so that it's easy to sniff the user name and password because knowing both is really hard to do unless your user name is "root" or "admin" or something insecure.
If you don't already, I would disable normal FTP and only use Secure FTP from now on.
| 9:29 pm on May 31, 2009 (gmt 0)|
so ive heard joomla is one that gets alot of these types of attacks. what others are known? is plogger one?
| 9:39 pm on May 31, 2009 (gmt 0)|
You should check the version on all your software, hard to tell which one but they should all be kept updated.
| 1:45 pm on Jun 1, 2009 (gmt 0)|
If you can do this
Where "login_name" is any form object name on one of your pages and it gives you an alert, this tells you your input data is passed through your script unfiltered and is vulnerable to XSS. The same is true when you attempt to pass a mysql injection with any select statement, such as an encoded " or 1=1."
| 3:29 pm on Jun 1, 2009 (gmt 0)|
|the biggest question is how did they get the ftp login info if that is in fact how they did it? |
First, check your FTP log for unauthorized logins. That will tell you if it was done by FTP.
Most often, the way they get in is by "remote file inclusion" <- web search term, not by FTP.
However, there is currently a wave of attacks being called "gumblar", which is an FTP password stealing malware. So in addition to cleaning your site and checking for potential RFI vulnerabilities in your PHP code, you should also do a thorough antivirus/antispyware scan on your PC. If you use AVG free, switch to something else or use a couple of online scanners.
The way gumblar works is, your PC gets infected from some other website. The virus scans your PC for FTP logins, sends them somewhere else, where an automated process uses your password data to log in to your website.
| 11:29 am on Jun 2, 2009 (gmt 0)|
You should check your PHP configuration...
More specifically, you might wanna make sure that register_globals and allow_url_fopen are set to OFF.
This could help prevent future RFI attempts...
And don't use FTP ever ! Use SFTP instead...
| 7:11 pm on Jun 3, 2009 (gmt 0)|
I found this file in one of my directories. What can someone do with this type of thing? Could they use this to append html php files with the iframe code?
[edited by: incrediBILL at 8:07 pm (utc) on June 3, 2009]
[edit reason] removed malicious code sample [/edit]
| 7:50 pm on Jun 3, 2009 (gmt 0)|
A Google search on
"find all writable files in current dir'=>'find . -type f -perm -2 -ls"
turns up a sans.org diary entry explaining some of the things it can do.
That search snippet is in section of your code that looks like it came from the r57 shell script.
The write() function could be used to insert the iframes, and it even restores the file's timestamp back to what it was before the file was altered, to cover its tracks.
[edited by: SteveWh at 7:51 pm (utc) on June 3, 2009]
| 8:00 pm on Jun 3, 2009 (gmt 0)|
what is the r57 shell script?
Also, i noticed that piece about the replacing the time modified. but unfortunate for them that didnt work and thats how i know what they did. it all happened may 27 at 11:30p
| 8:13 pm on Jun 3, 2009 (gmt 0)|
The shell script allows someone to access your operating system to list, create and remove files and directories as well as execute code on your server.
You should probably run a chkrootkit program to see if anything else is obviously compromised.
If it's a dedicated server I might request an OS reload on the server, but if it were my server I'd request a new migration server and transfer all my stuff to the new box just to make sure nothing was overlooked like password sniffing programs or a botnet zombie.
[edited by: incrediBILL at 8:16 pm (utc) on June 3, 2009]
| 8:24 pm on Jun 3, 2009 (gmt 0)|
if its on a private server at a bigger hosting company wouldn't you think there would be some limitations on what someone could do?
I mean the possibility of needing an OS restore?
| 9:24 pm on Jun 3, 2009 (gmt 0)|
I neglected to say nice detective work finding this file.
If you mean some limitations on what the hacker could do, no, not really.
I left out a link previously, but will provide it plus another one here in hopes that they are probably within the link guidelines.
This is the SANS.org writeup:
This is Symantec's writeup on the PHP.RSTBackdoor Trojan that you found:
Look at the actions it "allows the attacker to perform".
Before doing the OS restore, find out how this could have happened, because if you don't fix that first, you'll just have to restore again in a day or two when the site gets compromised again.
Research to discover whether you are using the latest versions of all PHP scripts.
If you are writing PHP code for the site yourself, it is possible that query string input is not being sanitized properly. Research how to prevent remote file inclusion and rewrite all your code so that if someone sends your script a query string like this, your script doesn't do anything with it:
Your script might be expecting "page" to be numeric, but if it doesn't check to make sure it IS numeric, then it can allow a hack script to get run and installed.
THEN, after you've researched and fixed the security hole, do an OS restore and rebuild the site using the latest versions of all scripts.
Based on what appears to be the r57 shell script you found (I thought it was just pieces of r57, but evidence suggests you have it in its entirety) and the Trojan you found, the chances that your server is extremely compromised are much higher than for a normal run of the mill hack.
You could, however, rebuild the site without an OS-restore. If it gets hacked again right away, you'll know the full server rebuild from scratch would have been the better way to go, and you can do it then.
[edited by: SteveWh at 9:27 pm (utc) on June 3, 2009]