Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
Loading site search ...

Buggy Malware: Iframes Eat Web Pages

   29 Oct 09   Filed in Website exploits

Yesterday, when I wrote about hidden iframes I forgot to mention one interesting side effect of the new iframes with “onload” scripts – they eat web pages.

Actually, those iframes don’t eat web pages themselves – it is done by buggy software that hackers use to inject hidden iframes into legitimate web pages.

Here’s the story:

When people at Sophos first detected this new type of iframes, the malicious code was injected at the very bottom of web pages right after the closing </html> tag.

<iframe frameborder="0" onload="if (!this.src){ this.src='http...

This is the most simple way (except for complete replacement) to inject something into existing files. You don’t have to worry about the file structure and the injected code can hardly break anything. The downside of this method is the injected code can be easily detected when a webmaster looks through the HTML code: file’s beginning and its end are the most prominent places.

That’s why a few days later hackers started to inject their iframes in the middle of existing HTML code where site owners can easily overlook them. To be more precise, they now inject the iframes right after the <body> tag.

<body><iframe frameborder="0" onload="if (!this.src){ this.src='http://...

Frequent updates

In this attack, hackers introduce new domain names for iframes every day. And every day they update injected code on compromised web sites so that the iframes always point to the most current malicious domain. This way they are always one step ahead of malware blacklists.

The bug

When they update the injected code, they remove old iframes and then insert new iframes. And it looks like their software that does this replacement is buggy.

On some site I started to notice that the end of HTML code was missing as if it had been truncated.

For example these were the last two lines of one infected web page:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "ht

You can see here truncated Google Analytics code that webmasters usually place at the very bottom of HTML files.

I started to monitor infected pages. With every update of iframe code, some of them they became shorter and shorter.

It looks like when hackers moved the iframe code from the bottom to the middle, they started to remove N bytes at the end of files, where N is the length of the previous version of the iframe code. And now, that the iframes are always in the middle, they just forgot to remove the rules that truncate files.

Another hypothesis is they try to keep the original file size of infected files. So when they add N bytes to a file (by injecting an iframe), they also remove N bytes at the end of the file. But when they replace previous versions of iframes they forget to deduct the length of the iframe code they replace. This makes infected files shorter with every iframe update.

I should mention that not all infected files affected by this bug. It looks like this truncation is some edge case that hackers forgot to test. After all they don’t really care if they damage some sites. They just need a code that simply works most of the time.

To webmasters: It’s bad when your site is hacked. But it’s even worse when hackers damage your HTML files and you don’t have a backup copy to restore them. I know most of you regularly back up websites, but I also know that some webmasters don’t bother with backups and think that their files are safe online.

The moral is: regularly back up. And if you have a clean backup you can easily recover from this iframe attack.

Similar posts:

Reader's Comments (7)

  1. |

    How can I prevent hackers from attack my website again

    Please help

    Thank you

  2. |

    [...] This post was mentioned on Twitter by Denis, cedricpernet. cedricpernet said: RT @unmaskparasites: [blog] Buggy Malware: Iframes Eat Web Pages [...]

  3. |

    I have noticed this behavior even with the old style iframe injections. This truncating behavior started sometime early this year with the “giantbest” and “litetop” domain series.

  4. |

    i had this problem too ,
    the only solution is changing your ftp password !

  5. |

    Good discovery with a somewhat humorous aspect to it: the poor quality control in code being turned out by hackers.

    It’s good to make backups and to keep several generations of backups, but it’s also possible to back up too often.

    Let’s say you’re really paranoid, backup every day, and keep 7 backup generations. If it takes 8 days to discover that your site got hacked, you find that all 7 backups are infected.

  6. |

    [...] have had a few correspondences with other security researchers regarding this threat (1, 2) who like me originally thought that the 'onload' attribute wasn't legal in an iframe. Two things [...]