[consulting] Iframe tags placed on index.php files attack possible solution

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
help that.

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.

Sam

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
>> http://www.expeditionpost.com
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>
>
>
>
> --
> Cary Gordon
> The Cherry Hill Company
> http://chillco.com
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/consulting/attachments/20090811/1df14b48/attachment-0001.htm>