Need help with base64_decode Hack

[jduck0]

I'm working on a test site with SMF 2.0.15. The site was installed with https. I am on a shared linux server hxxp:www.asiwebhosting.com/ [nonactive]
I've got the following packages installed:

Auto Lock Old Topics   2.0
Google Member Map   3.0.4
SMF Mobile Theme Selector
reCAPTCHA for SMF   1.0.0
SMFPacks WYSIWYG Editor   2.1.6

I had the site locked down fairly hard. There were only 3 writable php files. The settings.php and the index.php files in the cache folder. They all got hit last night. The file update date\time on the file didn't show a change, but the files were modified.

I disabled chown, chmod, and a few others in the php.ini file. I tested and couldn't change permissions with php after updating the ini file. None of the other files were touched.

I've attached a zip file, that contains a text file of the injected php and what the base64 decodes to. I couldn't find any known vulnerabilities in 2.0.15 for this type of hack. Any thoughts on what input isn't getting sanitized? one of the packages?

I had a very similar attack on the same test site using 2.0.11 about 6 months back. I chalked it up to running out of date forum software. Not real sure what is happening now. Need some help on where to look for holes.

[Kindred]

If you are on shared hosting, that is a likely vector, depending on your host and their configuration

[Aleksi "Lex" Kilpinen]

This particular code seems familiar. Go through all your index.* files, your session*.* files and your .htaccess files at least as part of cleaning up the mess. That is an _old_ hack, that years back attacked mostly Wordpress and phpbb installs.

[jduck0]

I did a quick check on the files, and only 3 were touched. The *.php files in the cache directory were writable, but weren't effected. With the exception of the settings file, the two index files, the cache directory, all files were set to 444 and all directories to 555. The 3 files impacted were set to 644.

Cleaning up was pretty easy. I did a bit of reading up and yeah this is an old hack that was an issue back in the SMF 1.x days. I've had this same hack happen last year. That's why all of the permissions were set so low.

I'm trying to figure out what the issue is with my site. This shouldn't be an issue in 2.0.15. It very well could be that its sitting on a low cost shared server. I would like to get a bit more exact on how the payload is getting delivered. Just not real sure how to get there. Server logs are pretty much non existent. I've requested them, but not holding out any hope of getting them.

[Aleksi "Lex" Kilpinen]

While waiting for the host to reply, specially since this wasn't the first time this happened, you should probably also go through all your files and folders to look for anything that's even a little out of place. Not only the public folders, but also all other folders you have access to on your hosting account. These types of attacks usually try to sneak extra files on your server, to gain access easier the next time.

[jduck0]

Not a bad idea. Its mostly CGI, but I haven't been through some of those folders in a long time. Will reply back if anything pops up.

[Illori]

just in case you should also change your hosting control panel password as well as any ftp accounts passwords as well.

[aegersz]

i did some research and found this advice on tightening up php.ini

i expect that you may have seen it but i am posting it for reference anyway.

https://www.thonky.com/how-to/prevent-base-64-decode-hack

[vbgamer45]

Don't follow that guide that will break SMF disabling all those php functions

[jduck0]

It always the simplest things we need to get reminded of sometimes.

Lex, I went digging through the site and sure enough I found some buried php files. That was a red flag for me, because up until this point the site has only been html and cgi. Haven't gone through and decoded everything yet, but it looks like the purpose of one of the files is to re-write the hack into any php files. Lots of base64_decode and strrev. They have been sitting there for over a year now at least.

Illori, first thing I did was change all of the passwords, cpanel, ftp, dbs, ect. Good reminder though, again the simple things.

Aegersz, I've got a short version of that file. I'm still working through the list on what all SMF needs. I'll repost when I get the most comprehensive list that doesn't interfere too bad with SMF. Right now its just chdir, mkdir, rmdir, chmod, and rename that way I can keep my read only files read only.

Still hoping to get some server logs to see if they show any activity. Going to mark this one as Solved for now. Thanks for the help!

[Aleksi "Lex" Kilpinen]

Well, let's hope you got it all, and this was the last time you have to deal with this.