Nasty, Hidden Virus on Simple Machines

[MrPhil]

It's a dedicated server.

Okay, that's somewhat good.

Actually, that's bad in the sense that it rules out a common attack route. Dedicated server security can be better than shared, but if you or your host are lax, the bad guys still may be able to get in. It's just usually harder than on a shared server.

In theory, you can make everything read-only. It is recommended at minimum to keep the cache directory and Settings.php writable. If you allow attachments or uploaded avatars, you'll need to set those as well.

Settings.php should always be read-only, once you have the settings settled down. I see that the morons are still writing the timestamp of the last database error directly to the Settings.php, despite my telling them repeatedly that's a stupid thing to do. There is absolutely no need to rewrite Settings.php on a regular basis -- use a separate file for the database error timestamp (see my sig > Fixes). Users are still getting Settings.php emptied out, perhaps not as frequently as in SMF 1.x. Once you've got the settings right, lock down the file 444.

As for attachments, avatars, and such, you may just have to prevent uploads to those directories while you're getting the attacks sorted out. There's no real harm in making the directories read-only (555) for a while. Caching can probably be turned off with little impact on performance -- you may want to try that. Do you have any files or directories that are "world writable" (666 or 777)? Unless you absolutely need that for selected directories because PHP runs as a random user (not as owner or in your group), you should have more restrictive permissions (755 or at worst, 775). Check your higher level permissions (such as public_html/ or the equivalent) -- if they're 755 and lower level directories are 777, that could be letting the hacker in. Talk with your host about whether 750 would work for you (or just try it).

Also, while you're locking things down, check all the files in every directory to see if they are supposed to be there. On that earlier infection on DreamHost I found a PHP-based shell tool hidden a few directories deep.

Keep an eye out for "hidden" files (starting with a period) that may not show up in your host File Manager or FTP. Make sure you can see any (such as .htaccess). Also don't just "eyeball" file names -- hackers generally aren't dumb enough to give obvious names like "spreadInfection.php" to their files -- they'll be something important and official sounding, such as PermissionsCheck.php and the like. Compare your list of files to a fresh copy of SMF to make sure of what's supposed to be there. Also compare file sizes and last modified dates -- has a file been changed later than you can account for? An automated checking tool would be good for this (even better, doing an MD5 checksum on each file).

So far the only consistent factor has been Simple Machines.

While that might be possible, it really depends on the skills of those involved. Statistically, it's more likely there is some automated attack being done by a script kiddie than some targeted attack directly against you.

If SMF is the only "commercial" software you have, it may be the only one for which they have source and can find any vulnerabilities. It's always possible that they've found an entry that no one at SMF knows about. Just as likely, though, is that your host has a security problem of their own that is allowing the hacker to get in as "owner" and do whatever they want. Have you been looking at access logs to see who is in there, from what IP address? If they're bypassing the regular login process, even that may fail to reveal anything. I would definitely have your host monitoring all activity on your site, on the chance that someone is getting in through a back door.

[青山 素子]

It's a dedicated server.

Okay, that's somewhat good.

Actually, that's bad in the sense that it rules out a common attack route. Dedicated server security can be better than shared, but if you or your host are lax, the bad guys still may be able to get in. It's just usually harder than on a shared server.

It's good in the fact that it eliminates a large portion of possible entry points. It also means that the user can take more action to find out the cause than if they were on a shared environment.

The whole trick to debugging and similar things like this troubleshooting is to divide up tasks and systemically remove them from consideration.

Settings.php should always be read-only, once you have the settings settled down. I see that the morons are still writing the timestamp of the last database error directly to the Settings.php, despite my telling them repeatedly that's a stupid thing to do.

I wouldn't call them morons. Anyway, the entire developer pool went through a turn-over not too long ago, so I'm fairly sure they were a bit more occupied with getting the product cleaned up and ready than fixing what is a silly but small issue - there were much bigger things to handle.

There is absolutely no need to rewrite Settings.php on a regular basis -- use a separate file for the database error timestamp (see my sig > Fixes). Users are still getting Settings.php emptied out, perhaps not as frequently as in SMF 1.x. Once you've got the settings right, lock down the file 444.

Save the preaching for the Bug Reports board or something. This topic is about trying to help a user determine why they are having issues on their website.

As for attachments, avatars, and such, you may just have to prevent uploads to those directories while you're getting the attacks sorted out. There's no real harm in making the directories read-only (555) for a while.

Agreed. If you can disable attachments and avatar uploads for a while, it would be useful to see if that has any affect.

Caching can probably be turned off with little impact on performance -- you may want to try that.

For a small enough site, agreed. If it's a busy site you might notice some performance impact, but it will be up to you to determine if it's too bad to leave off for a while.

Also, while you're locking things down, check all the files in every directory to see if they are supposed to be there. On that earlier infection on DreamHost I found a PHP-based shell tool hidden a few directories deep.

Keep an eye out for "hidden" files (starting with a period) that may not show up in your host File Manager or FTP. Make sure you can see any (such as .htaccess). Also don't just "eyeball" file names -- hackers generally aren't dumb enough to give obvious names like "spreadInfection.php" to their files -- they'll be something important and official sounding, such as PermissionsCheck.php and the like. Compare your list of files to a fresh copy of SMF to make sure of what's supposed to be there. Also compare file sizes and last modified dates -- has a file been changed later than you can account for? An automated checking tool would be good for this (even better, doing an MD5 checksum on each file).

I find the "find" tool works great. Doing some checks for files that have been modified in the last x days should give a small list of things to check. It'll also return hidden files (dot-files) that exist and have been modified in that time period. That's how I found the PHP shell file.

Once you get a good check of all the files, a tool like AIDE or Tripwire is useful as you'll get a report when the file changes (both tools look at checksums of files to see if the contents changed).

It's always possible that they've found an entry that no one at SMF knows about. Just as likely, though, is that your host has a security problem of their own that is allowing the hacker to get in as "owner" and do whatever they want.

I'd argue that it's more likely to be a server or environment issue than an SMF issue. It's really easy to mess up on a configuration and much less likely that only one group/person found a specific SMF security hole that is only being used against a single target.

[Dame2]

I need to weigh in here with my own issues.  My forum members (and I have a very large forum) have been reporting since December 10th that they have either been infected with malware from my site, in particular the forum, or their AV has been blocking attempted intrusions.   Some have been very specific as to where they were reading in the forum when this occurred.

An analysis of the 20 or so reports showed 3 Norton users reporting that Norton had blocked Malicious Toolkit from their computers.  The rest reported either attempts to install or actual infections of several variants of rogue antivirus viruses (Win 7, VISTA 2012, Antivirii 2011) while using AVG, McAfee, Avast and MSE.    Users of malwarebyte reported they were getting nothing. 

I contacted Google Webmaster Help.  A Google Diagnostic Scan of my site on December 10 showed that no malware has been delivered from my site in the previous 90 days.   Google did a more thorough scan of 30 pages on December 24th and still found nothing suspicious coming from my site.   My hosting provider, who happens to be MonteCarloHosting.net [nofollow] (owner Christian is a mod on one of the SMF forum boards), did a server scan and found nothing.   My forum is on a dedicated server.  Our AV software, Zone Alarm, was not finding anything.  My moderators were not getting any AV alerts or infections. 

My husband, the IT guy, did a clean reinstall of the SMF software after reading this thread.  All passwords were changed.   I deleted unused themes and the one mod package I was using.  Also upgraded to 2.0.2 within hours of it being released (was on 2.0) .    Google Adsense ad were also turned off the forum for two days.   

However, last night when I turned the ads back on, I promptly got an alert from Zone Alarm asking for permission to run a program from my local settings/temp directory which appeared to be malware by its name, a long string of letters and numbers followed by .exe.    I took a screen shot of my desktop at the time which shows I am on SMF, which ads were displaying and the AV notice.   I have already reported the possible problem to Google and turned off my ads again.   Not happy about that.   I'm still monitoring members to see if anyone is still getting malware while on the site.   

[Illori]

that does not sound like an smf issue, it sounds like an issue with your ads. there is nothing we can do to help that.

[Flavious]

Dame2,

Sounds exactly like what we have going on. I am 98% sure it was an exploit in simple machines that allowed the virus to write to files on the server. Both times we've had issues, Simple Machines released a "security patch" right after we found we had an issue. In both cases, Simple machines will not say what the Security issue was, which is very disappointing. I can't help if I don't know what they changed.

Worse, I'm not sure that using the upgrade package on Simple machines gets rid of it. It looks more like the exploit in Simple Machines allows this thing to write to anywhere in your root directory - meaning you can replace all the simple machines files and it won't get rid of it. I've had 3 outside groups look at it, and all fingers point to simple machines. The server checks out, the other software checks out, and I've checked every single google ad with the help of google.

We have two ad servers on the site - google and a server we built ourselves. I experimented with shutting one off, then the other, and there really was no change. We have inspected *every* line of code elsewhere on the site, and we even searched the database(s) and came up with nothing.

This issue has cut my traffic from 200,000 visitors a month down to 50,000. We are seriously looking at building our own forum or if we have to, using vbulletin.

Some have been very specific as to where they were reading in the forum when this occurred.

When we were having problems, some users put into posts what they were seeing, in some cases posting code that caused the AVG software to go off. Delete the post and that problem stops.

I contacted Google Webmaster Help.  A Google Diagnostic Scan of my site on December 10 showed that no malware has been delivered from my site in the previous 90 days.   Google did a more thorough scan of 30 pages on December 24th and still found nothing suspicious coming from my site.   My hosting provider, who happens to be MonteCarloHosting.net (owner Christian is a mod on one of the SMF forum boards), did a server scan and found nothing.   My forum is on a dedicated server.  Our AV software, Zone Alarm, was not finding anything.  My moderators were not getting any AV alerts or infections. 

Ditto, except my server is at another provider, whom I do not want to embarrass here.. in case they have done everything right.

[青山 素子]

Moving this to the top so it's seen:

Flavious, here's what I'll do. I'm fairly convinced that SMF itself isn't at fault here, so I'm offering my time to inspect your server environment, run some checks, and even help configure a tool like AIDE or TripWire so you can get some proactive alerts if something should happen. The place I work normally charges close to $200 per hour for my time doing something like this, but I'll do this for free on my personal time as long as you agree to allow me to publish any findings as to the cause, if I should be able to determine it.



Dame2, if the issue only showed up after you turned advertising back on, it sounds like an infected ad. This has been known to happen. If you can pin down the ad causing the issue, you can usually report it to the ad network and get it removed.

Sounds exactly like what we have going on. I am 98% sure it was an exploit in simple machines that allowed the virus to write to files on the server. Both times we've had issues, Simple Machines released a "security patch" right after we found we had an issue. In both cases, Simple machines will not say what the Security issue was, which is very disappointing. I can't help if I don't know what they changed.

If you have that much certainty, you must have some evidence aside from timing. Please send the evidence to security>at<simplemachines.org and it will be reviewed by the developers.

I'm not aware of any vendor that will provide exploit code for their own product. To determine the issue, look at the patch that was provided. The changes will point at the problem code. If the issue was found externally and released, there are several places you can find exploit code.

Worse, I'm not sure that using the upgrade package on Simple machines gets rid of it. It looks more like the exploit in Simple Machines allows this thing to write to anywhere in your root directory - meaning you can replace all the simple machines files and it won't get rid of it. I've had 3 outside groups look at it, and all fingers point to simple machines.

Once again, please send the details to that above e-mail address. If three outside groups found evidence, certainly you can notify the vendor, right?

By the way, SMF can't trump filesystem security. If you want to be sure, make every single file and directory in your web root read-only.

If you want to get serious to tracking this thing down, install AIDE or Tripwire and keep all your request logs. When you get a ping on a changed file from the tool, check request and error logs for around the time of the file creation - at worst a 24 hour period if you can't narrow the hours.

As a system administrator professionally, I've had to investigate several breached servers. The usual suspect is rarely the cause. Nine out of ten times, the breach is due to:

• Unpatched third-party code due to the client not using the product anymore and forgetting it was still accessible
• A really poor server security configuration, usually lack of partitioning among services and multiple websites
• Badly-written custom code allowing various injection or directory-traversal attacks

Recurrent infections usually stem from a continued problem with the above or failure to clean out the entire infection, keeping a back-door open for the attacker. If you have poor logging in place, it's usually easier to rebuild an environment from scratch than audit everything.

Also, when I speak of an "attacker", 98% of the time it's some automated thing out there blasting sample exploit code blindly hoping to get a hit. It's almost never an actual intelligent human actively doing things.

[Flavious]

I will take you up on that... if it happens again. I believe we found where the original bugger was written and from where it was writing files. Since deleting that, we have not had an issue, and yes, I am crossing my finger. I can get more details if you like.

To be fair, we have three possible sources of where it originally got on the server: Simple Machines and two pieces of custom PHP written way back in 2005. One of those has been eliminated, the other is highly unlikely to have an issue, but it is being upgraded to try and eliminate any possible holes.

If we take care of that, and get it again... then I'm going to need as much help as I can to get it taken care of. For now I'm just trying to convince all the users we lost that it's safe to come back. That's going to be a very difficult sell.

Thanks for the offer and a truly appreciate all the ideas we got from here.

[青山 素子]

I'm curious, personally. If you don't want to post publicly you can send me a PM. If you don't want to disclose in PM, let me know and I'll provide my e-mail address.

[Dame2]

If it was an SMF problem, it has not since reoccurred.  There were several publishers reporting problems on Google AdSense Help forum of malware in an ad.   I know of at least another large forum whose members were also reporting malware coming through Google ads and that forum is not using SMF.     My forum members are not particularly geeky and it took nearly two weeks before we finally started getting good screen shots of the malware alerts so we could see what they were getting.  A common denominator emerged....there was a particular originating IP address on one particular Google ad channel.    Google has been, as usual, quite tightlipped about it with no admission that the malware was coming through one of their ads. 

Although about 2 dozen people reported getting malware alerts from their AV, only about three or four actually got infected.  If a person has a good, up to date AV software, it quarantined the virus or blocked it totally.  It was a good reminder to everyone to keep their browsers, AV, AV definitions, add ons and plug-ins up to date with the latest versions and to become more "street smart" about surfing the Internet (as in "don't click on a pop-up telling you your computer is infected and directing you to click on something which does download a rogue AV to your computer"). 

[Flavious]

Interesting... I see tons of people now are having problems with SMF getting hacked... we are sure now it came in from the old version of SMF. Everything else has been eliminated. We got the virus PRIOR to SMF releasing the patch. Lesson learned: Check those updates daily. Thanks for all the help everyone.

[青山 素子]

I see tons of people now are having problems with SMF getting hacked...

I looked around on the general support boards and only saw a few reports. Am I missing somewhere that those "tons" of people are posting?

we are sure now it came in from the old version of SMF. Everything else has been eliminated. We got the virus PRIOR to SMF releasing the patch. Lesson learned: Check those updates daily.

Given the last patch was released in December of 2011, even a monthly review should have brought up some awareness of the update. Also, are you sure that the issue you encountered was the exact thing fixed in the update? Simply not having recurring issues isn't enough to state that with any kind of authority.

[Flavious]

I see tons of people now are having problems with SMF getting hacked...

I looked around on the general support boards and only saw a few reports. Am I missing somewhere that those "tons" of people are posting?

we are sure now it came in from the old version of SMF. Everything else has been eliminated. We got the virus PRIOR to SMF releasing the patch. Lesson learned: Check those updates daily.

Given the last patch was released in December of 2011, even a monthly review should have brought up some awareness of the update. Also, are you sure that the issue you encountered was the exact thing fixed in the update? Simply not having recurring issues isn't enough to state that with any kind of authority.

No, because I couldn't get any answers as to *what* the update fixed. Is there a list somewhere that I missed? When the patch came out, all I recall it said was 'security issue" or something to that effect, and I could get no more details on it than that...

[Aleksi "Lex" Kilpinen]

You can see all the exact code changes in the Updates site, and the changelogs on the downloads page.

[OCJ]

Just for the head count ... my smf site was also hit by a trojan recently. Several people reporting a virus/infection on the site with different brands of firewall. Site has just been cleaned out and hopefully it wont come back. Dont know how it got in ... smf or mods perhaps? There was also an installation of menalto gallery 3 but thats all.
SMF 2.02, SPortal 2.3.5

[nend]

What site was this on? Why the lack of information on the infected site? I read the whole post and the author didn't supply the information.

[青山 素子]

Just for the head count ... my smf site was also hit by a trojan recently. Several people reporting a virus/infection on the site with different brands of firewall. Site has just been cleaned out and hopefully it wont come back. Dont know how it got in ... smf or mods perhaps?

While possible, in my experience, where the software on the site is the latest patched version with no known vulnerabilities, it's a hosting configuration issue over 90% of the time.

There was also an installation of menalto gallery 3 but thats all.
SMF 2.02, SPortal 2.3.5

A security update for Gallery 3 and 2 has been recently released. The issues that it solves are minor and XSS-related things, so I don't know that such a thing would be the root issue.

If you want to try and find the root cause, start by looking at your server logs around when the reports started coming in, and work backwards looking for suspicious activities.

[nend]

Another good tool to go along with that is if you have some sort of analytics, then use it. I do use it to track trends but allot of times I also use this to track malicious usage through the site and figure out what they where looking for and what they where poking at. I learned quite a bit of how a bot figures out forum type this way, which helps with developing anti-bot measures. I am sure though you can use it to figure out any malicious activity going on there. However there are quite a bit of limitations and not every bot has to load the analytics, so it may just give you nothing.

[OCJ]

Not sure about the originator of this thread but unfortunately people don't give details when they report the site has a virus or trojan - even people over on simple portal - 3 reported firewall blocking the site but no details. So I have none.
I couldn't get any warning with comodo or avg and over 10 site scanning services.


One friend/site member reported it also - will ask if he has any details.

The linked site in my signature was infected.

[青山 素子]

not every bot has to load the analytics, so it may just give you nothing.

This is why raw server access and error logs are best. You can see the raw IPs (impossible with many of the hosted analytics packages), view the URLs, and track activity and referrers. Also, since these are generated on the server for every access, nobody can avoid being logged.

[OCJ]

This was one possibly on my site before ...

Trojan Downloader : Win32/Karagany.I

Alert level: severe.