[consulting] Iframe tags placed on index.php files attack possible solution
sam at samcohen.com
Tue Aug 11 17:58:00 UTC 2009
I ad a client hit by this exact attack recently. Someone gained access to
their hosting account/ftp passwords -- and no security patches are going to
The good thing is that it only affects files that end in a body tag -- so in
all drupal only page.tpl was changed -- and a handful of files from tinymce
If your client gets hit with one of these, and if restoring a backup isn't
practical, check the ftp log and you can see exactly which files were
injected and just fix those. (and of course change the password)
Whenever possible I try not to even give clients ftp or hosting panel access
anymore -- I put their email on google apps, their stats on analytics, so
there's almost no reason they ever need to login to their hosting account.
On Tue, Aug 11, 2009 at 1:38 PM, Cary Gordon <listuser at chillco.com> wrote:
> Those aren't all that mysterious. Those are SQL injection attacks that use
> .js to pull all sorts of fun tricks. The only solution is to either do a
> database restore or write a script to remove these from your database.
> Keeping your site up to date with the latest security releases and
> patches greatly reduces your vulnerability to such attacks.
> On Mon, Aug 10, 2009 at 11:10 PM, rajasekharan <websweetweb at gmail.com>wrote:
>> Hello Drupalers,
>> You may have heard or even experienced the attack where some mysterious
>> iframe tags are placed right after the
>> <body> and before the </body> tag in you index.php file, header.php,
>> login.php and footer.php.
>> This even causes the php files to break as the iframe tags are placed
>> randomly within the index.php file (failing to find the <body> tag)
>> resulting in
>> php errors.
>> The attack causes your website to be blacklisted and marked as an attack
>> site in the search engines. Even the web browsers
>> scare people away from visiting the site with nice blood red alert signs
>> (not that I blame them).
>> This problem exists for users of all content management systems such as
>> wordpress, phpbb, joomla, fauxBB and so on. I might have the solution to
>> this problem.
>> The problem starts at the website owner's computer being infected with
>> some virus. The virus listens to the FTP transactions and relays the
>> FTP information to someone else. Most attack victims have reported having
>> used FileZilla so the virus may even be finding and reading
>> FileZilla's xml/registry database (or may simply be a conincidence).
>> The attacker uploads a PHP file to the server and starts executing it and
>> immediately removes it. I was unable to find any offending script in one of
>> my clients'
>> websites where the attack had taken place. The malicious script is
>> (probably) running as a background process (may be using ignore_user_abort
>> or similar) while the script file has been deleted (which is possible in
>> linux). This is why sometimes the offending code return to the pages inspite
>> of the FTP password being changed. But the attack always stops after the
>> server has been restarted. I am
>> still not certain if the background process theory is correct as I have
>> not been able to verify it yet.
>> The only solution I can think of is to change the password and restart the
>> server. If the server is in a shared host, it may be possible to kill the
>> offending script's process. You can find out if there are any php threads
>> running for a long time via SSH using the ps -aux command and
>> kill it using kill [procid].
>> Please let the list know if you face the same problem.
>> Raj Sekharan
>> consulting mailing list
>> consulting at drupal.org
> Cary Gordon
> The Cherry Hill Company
> consulting mailing list
> consulting at drupal.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the consulting