/tmp/minisuhosin exploit
Today I discovered a random process running on one of my servers with the process name minisuhosin (/bin/sh minisuhosin). I believe this to be a new (past few days) edge exploit as there is very little information on this on google. Infact, the only other info I could find on it was this post here.
The first thing that I would like to state is that in the case that I dealt with, the account had both osCommerce and WordPress installed, although the exploit only seemed to be present in the WordPress directory. The contents of the .htaccess file was as follows
AddType application/x-httpd-php .php .phtml .php3 .php4 .php5 .htm .html
php_value auto_prepend_file /tmp/25454b22bf39c75795851f39d5e347c4
As the above mentioned blog post confirms, the file claims to be mini suhosin, and indeed this is not the case. From what I could tell, there was a single parent process which was constantly spawning child processes of the same name and then killing them. Whilst I am not aware of the full extent of the exploit (I will need some more time), the intent of the script only seems to target the website which was exploited.
It appears to try and load some javascript which returns some webpage containing some junk, most of which my firewall blocked (a java applet and a pdf). For reference, I have put this script here. It should allow you to tell if you have been subjected to the same exploit. On the basis that both myself and the site linked above, the filename was the same, I would look out for the “/tmp/25454b22bf39c75795851f39d5e347c4” file.
In terms of prevention. Make sure that all of your scripts are up-to-date and that your /tmp directory is mounted with noexec.
If you have any insight into this exploit, please share your knowledge in the comments box below.
January 31st, 2011 at 11:29 pm
Hi Ben, I’ve encountered this intrusion recently as well twice now. Once in late December 2010 and again towards the end of January. In the first case an old OSC was present and the 2nd case both OSC and WP were present. Here is some additional info to check for.
The attacker likes to drop in a php shell file with a filename starting with google followed by a long string of numbers. Check your server for any files starting with google. I found a couple on one webserver in one case. This shell has plenty of tools for the intruder to take advantage of.
The first time I encountered this the attackers main purpose seemed to be to host spam on the server. Pharmaceutical products mostly. These were in plain html files. Some files on the web server had base64 encoded strings inserted at the top of them to fetch content from a free hosting account. Not sure what for as the account was suspended prior to figuring this out.
However, next time the attacker also placed base64 encoded strings on almost every file on the webserver. When decoded these one’s contained the following:
ח6ι^kn95=߯|/someserverpath/shop/admin/includes/javascript/tiny_mce/plugins/ibrowser/scripts/phpThumb/cache/source/sh.php5ͶwW_ێtMuw
Upon looking in the directory: /someserverpath/shop/admin/includes/javascript/tiny_mce/plugins/ibrowser/scripts/phpThumb/cache/ I found numerous files with numeric names as well as the sh.php file which is a proxy shell and an index.php – all of these placed there by the intruder. The files with the long numeric names contain the spam the intruder is trying to host. I assume this is an improvement over their methods to make their content more difficult to detect than plain text html with obvious viagra and cialis filenames.
I would not assume that the intruder will always use the same path to place his files.
Good luck with your investigation.
Anonymous…
February 1st, 2011 at 12:10 am
Additional info: the attacker also infected a few of the shopping cart header files (both public and admin) with a trojan (contained in an eval statement that passes a base64 encoded string to gzip) intended to be dropped onto the computer of anyone visiting your site. Recommend doing a grep -in on all your website files (and wordpress files) for eval statements or gzip statements in php/html files. The trojan was identified by Eset Nod32 as a variant of kryptik.ab
check /shop/includes/header.php to see what you should grep for in your other files
February 1st, 2011 at 2:28 am
Hi,
Thanks for the comment, I suspended the account in question as soon as i noticed this. I see that there was one of these google files present that I admittedly missed (it looks like a c99 shell style script).
In cases such as these, my opinion is always to just delete everything and start from scratch anyway, so this should ensure the account is clean. I have, however saved a copy of the userdir for further investigation should it be required!
On the basis of your reply, this exploit must lie purely with OSCommerce, fortunatly, this user will be moving over to Zen Cart, so the same exploit should not be possible.
I would be interested to know where this security hole is though and how it was able to break in so-to-speak. I’m suprised that my fairly tight mod_security rules didn’t manage to prevent the attack, although thinking about it, it may have something to do with OSCommerces use of register_globals?
Regards
Ben
February 1st, 2011 at 8:54 am
Thanks Ben,
Personally I wouldn’t rule out wordpress just yet but osc is definitely the more common thread in the attacks. I am unable to say exactly how these attackers got in because upon analysis of the break-in we found many potential avenues of attack. One of these attacks could have also easily come through some outdated Interspire products or pure sql injection but there was no obvious sign of sql injection. I know for certain register globals was on in at least one of these cases but the Interspire vulnerability did not require register globals to be used. The intruders files were all over so it was difficult to say exactly where the first point of entry actually was or if they were testing multiple vulnerabilities to further their hack’n’spam efforts.
However I would agree with you and urge anyone still using OSC to find a new solution.
I do know that once the intruder is in their script is very quickly able to bypass php’s safe mode and other security features. It’s written to dynamically handle postgresql and mysql among other things.
On smaller sites it is certainly feasible to clean files manually and reinstall any larger software packages without too much trouble. A fresh start never hurts though.
What surprised me was that on further investigation I found reference to the tmp file name (the fake minisuhosin) appended to almost every html and .htaccess file on the site in question. This placed a “sitemap” link at the bottom of every page (after the closing html tags in the files and inside a span tag) that links the intruder from any page on your site to their shell. Meanwhile the base64 decode was prepended to almost every php file. While the eval/gzip portion that contained the trojan was only in a few select places – the oscommerce header.php being one of them. However it is likely that these attack methods will be refined and may change in future attacks like this.
I do wish that ext3 had support for file creation timestamp since then it would be easy to determine which of the attackers files showed up first and when. Last modified is not necessarily a clear indication.
Anonymously anonymous.
February 1st, 2011 at 4:39 pm
I’m pretty sure that this was OSC, or as a result of register_globals which is required by OSC in connection with WP (aka some flaw with WP when register_globals is enabled).
After further investigation, I suspect the date of infection to be the 24th Jan, although I don’t believe that the minisuhosin aspect of it hit until around the 26th.
You’ll never guess what I just found though! Literally as I’m writing this reply, after running a “find * -user nobody -ctime -30”, I found 6 interesting files in the images directory. One is another shell style script (named images_resize.php (“Web Shell by boff”)), Two html files containing the hackers tags, one base64 / gzip encoded file called pic.php, a file named minisuhosin, and a mini.log file.
The minisuhosin file iterates through a given dir parsed to it by the looks of it searching for writeable directories (“find $dir -perm /+w -type d -print”). It then echo’s them out to the mini.log. It then searches for web files in the directory (php, htm or phtml). If it finds a “web file”, it then populates the .htaccess files with the htaccess code (“printf “$htaccess” >> $path”).
There is also evidence of other attempted attacks on this installation, one being the “CVE-2010-4170 : systemtap Local Root Privilege Escalation Vulnerability”.
On your last point, yes, it is a shame ext3 doesn’t have support for the file creation timestamp.
Regards (and unfortunately not anonymously)
Ben
February 9th, 2011 at 10:03 pm
Just out of curiosity – check your php lib directory for a file called sys.php or anything else out of place – we found something that looked like it was being used for session hijacking. Don’t know if it’s related to this intrusion or not. This would load a hacking tool for all users on the server using that install of php. Be interested to know if you find anything. The code in the file was base64 encoded, string reversed, and encoded again, with some strings being encoded yet again. If you see ‘edoced46esab’ you’re looking at encoding that’s just been reversed to avoid detection via grep or other text pattern matching.
February 9th, 2011 at 10:47 pm
I’m afraid there isn’t, it doesn’t sound like it actually shares any characteristics with the above mentioned post.
February 11th, 2011 at 12:56 am
Good to know. Thanks.
February 25th, 2011 at 7:59 am
Today I found out that one of the sites I’ve been working on was attacked in all the manners discussed in the above posts. Don’t know for how long the exploit has been present, but many files used by the attacker were modified 2 days ago (22 Febr) and some others were at least two months old.
The site uses OSC. There were about 8-12 php files inside the images folder, php code (including eval() ) was inserted inside includes/languages/espanol/cookie_usage.php, the /tmp/25454b22bf39c75795851f39d5e347c4 also inserted, malicious .htaccess files all over the site (also affected another site hosted inside the same server), etc.
There where also other files which I’m not sure if were part of the same attack
-in images folder
– a folder named “12” with several number-named directories, all containing files in.php, in.txt and out.txt. Last two contained lot of domain names.
– a 0.php …. a very complex php file with a lot of utilities for the attacker
– in /tmp
– a shell script: “backs”. Intended to run a backdoor
– pcraw.php: prints information about the server
Three months ago I also found out some administrator users which weren’t supposed to be there (example admin11 … what a suspicious name! ). So if this is related with the discussed attack, probably an sql injection provided the attacker with an osc administrator account he used to upload a file inside the images folder using the form for creating new products inside the store… the rest is history.
Any new theories of how the attack was performed ¿Could my theory be right?
February 25th, 2011 at 8:38 am
I forgot to mention…
Attacker left a note (don’t know if the attacker for this exploit or another one):
“hacked by misafir”
In file images/m.txt
… how considered …
February 27th, 2011 at 4:45 pm
There were two tags claiming to be some Malaysian hacking group in my instance. I’m sure the attack is a flaw to to with register globals. Basically, use this as an excuse to get as far away from OSC as possible.
March 12th, 2011 at 1:56 am
OK I have the same thing as everyone is describing here, the google.php files with a bunch of numbers and it was also OScommerce.
I also got some other special gifts such as wpil.php, put.php, up.php, conf.php, class.php5, help.php5 and some amazing results from the hackers work.
They installed r57shell 1.4 not cool.
They had tools that were able to search all apache or world readable stuff, which is pretty much the whole server listing all in a log file.
They installed a script called wpil.php and uh989d.php which found all wordpress sites on the box and retreived the sql UID & password. With that info posted links to drugs and other garbage sites on every single blog post that existed on every site that was running wordpress. They were nice and didn’t trash the posts, just add their links.
They also placed web folders with their html, images etc and these were called bmo verify-bmo on-bmo which came from bmo.tar.gz which I see they linked in spam messages.
What a violation….
March 13th, 2011 at 1:28 am
@MikeD, It sounds like they had a bit of a field day on your server. Did you manage to identify if it was definitely this attack that was the point-of-entry?
March 31st, 2011 at 9:38 pm
Here’s a handy PHP script to clear the tmp-minisuhosin exploit from infected .htaccess files — run it in the top-level of your site 🙂
Hmmm, the comments have mangled that script … copy it from here into a .php file:
tobylyons.net/public/scripts/tmp-minisuhosin-exploit-disinfecter-v1.txt
April 1st, 2011 at 8:23 pm
Thanks @richa,
I haven’t had time to test it, although it looks pretty sound. I’ve also put a mirror of your code here with credits.
April 2nd, 2011 at 3:34 pm
No probs — here’s another useful PHP de-hacking tool.
This one lists the contents of /tmp, lets you inspect anything you think looks suspicious, and then delete it. Best not to leave this script installed on your website, because it potentially lets anybody read or delete your temporary session files — so trash it after use!
http://www.tobylyons.net/public/scripts/tmp-folder-reader-and-deleter-v1.txt
May 19th, 2011 at 3:36 pm
we too have a osc site that has been exploited the same way. they were adding a second language in the admin and the language was loading an image file. We deleted the file upload script built in to osc, removed the language page in admin, changed the login to .htaccess, wrote a script to autodelete files with certain key phrases in it and notify us of what files were deleted. I cannot find out how they can still upload to the images directory. I would be very happy to find out how they are doing that. I would assume there is another backdoor, but i cannot find it. it is obviously not obvious.
June 18th, 2012 at 6:35 pm
I have a simple WordPress blog site that’s been hacked by a very similar variant of this a few times. Each time, I’ve reset the account passwords and further hardened the site via the .htaccess file.
Just a couple of days ago, a 293k file named fbmo.tar.gz was somehow inserted into the root folder of my site. It triggered the creation of a “fbmo” folder along with about 2 dozen other folders, each populated with a handful of files along with their own “fbmo” folders.
My brother has experienced the same thing and we’re both hosted with PowWeb, which is where we believe the vulnerability really lies. Several times, PowWeb has suspended our sites, citing that we’re using them for phishing. We’ve documented these instances and asked for their help, but the PowWeb Tech Support guys want nothing to do with this – aside from wanting to upsell us on a pricey security module to safeguard our sites.
I’d be very interested to know how many of the others who’re getting hit by this are either hosted by PowWeb or one of its sister subsidiaries of Endurance International Group Inc. I’ll just bet that’s a common theme to this.
June 18th, 2012 at 9:11 pm
Hi Rob,
Without full file system and log file access, you’re really fighting a bit of a losing battle if PowWeb aren’t on your side. From experience, it’s most likely that a plugin or theme is causing your problems. I found a few instances where timthumb had been compromised for example; Timthumb is included in quite a few themes, and hasn’t been fixed in most of them! I’m sure there are other similar vulnerabilities.
My advice would be to remove any un-used or non-essential themes and plugins, install BulletProof Security and cross your fingers.
It’s also possible that the exploit hid a backdoor somewhere; so it’s worth giving your home directory a virus scan if possible. If PowWeb use cPanel, most hosts install ClamAV which will allow you to run a scan very easily.
Anyway, I’ll stop now before I start mumbling too much :p
Cheers
Ben