| Posted by WilliamP, 10-30-2010, 10:46 AM | | Our vBulletin forum site continues to get attacked weekly. Our dedicated server is with Liquid Web and their security team has worked on this for nearly four weeks now and cannot find where the attack is coming from. We seem to clear it out for a few days and it sneaks back in.
Here is one of the pages that it is showing up on:
And this is the malicious script/iframe that injects itself at the top in the beginning of the page:
Of course when we look at any of the templates from which the page is created, we find nothing.
We have scanned our .php files for the following:
base64_decode
ListDirs
include(http:
FilesMan
ob_start(ob_gzhandler")
preg_replace(/.*/e,"\x
But we have not found any files that have any variance from the original.
We have looked through our plugins and not found any strange looking code.
Our vBulletin is on version 3.8.5 and we have not upgraded to 3.8.6 due to a known vulnerability.
We thought that the issue might be with OpenX/OpenAds... our previous ad server software, but we eliminated it from the server completely and no longer use it.
Would something like DotDefender prevent these kinds of attacks?
We are definitely scratching our heads and any help is appreciated.
|
| Posted by WilliamP, 10-30-2010, 11:03 AM | | Something we just realized... every page that Google has warned us about has a YouTube embedded using AME (Auto Media Embedder). We are removing it and all traces of it to see if that is where the issue is coming from. Something tells me it has to be it.
|
| Posted by ServerManagement, 10-30-2010, 03:46 PM | | These almost always come from insecure scripts. Have you checked the versions of OpenX/OpenAds as well?
Another common area is from weak passwords or viruses on your own computer that is sniffing the password to your account as you use ftp or email.
A good firewall configuration and strong modsecurity ruleset is a very good place to start for security. Make sure this is done, along with upgrading your scripts, changing your passwords, and scanning your own computer.
|
| Posted by cpanellover, 10-30-2010, 04:22 PM | | hi,
I would try the following open /includes/config.php and at the top right after the " |
| Posted by FastServ, 10-30-2010, 04:25 PM | | Might seem simple, but make sure you're scoured the FTP logs for unusual activity. The other thing to do is check the modification times of infected files then scan the Apache logs for GET/POST requests matching the timestamp. Usually it's a POST and points you in the right direction.
|
| Posted by WilliamP, 10-30-2010, 09:52 PM | | We removed OpenX/OpenAds completely. All staff changed their passwords and I changed nearly every password I have. ESET finds nothing on my computers thus far. I may need another malware scanner.
Removing the AME plugin indeed stopped the injection of code into the post. I posted at vBulletin, but they offered no help.
While it is possible that it was merely the AME plugin, from what I understand the injection exploit simply places the malicious code in the first plugin in your product list and AME would generally be one of the first. It supposedly puts a base64 iframe in a plugin for one of the first mods on your mod list.
I will check the FTP logs and pass along this info to our server security team.
|
| Posted by cpanellover, 10-31-2010, 08:00 AM | | hi,
create a support ticket at vbulletin.com they don't like to discuss security issues in public for obvious reasons but they should not leave you on your own to get things resolved.If you are not the licence owner then you can't open a support ticket then have the licence owner do this
|
| Posted by WilliamP, 10-31-2010, 10:22 AM | | I may try that, but I think they will tell me that it has to do with plugins and that I should not install any plugins not supported by vBulletin... and I none of them are supported.
|
| Posted by cpanellover, 10-31-2010, 04:31 PM | | possible but it looks like a hole in the way vBulletin handles plugins not a problem with one plugin in particilar otherwise other people would have the same issue and vb.org(vBulletin modifications site) is verry strict about plugins with security holes also does it have any effect when you put those PHP crypt functions(base64_encode & base64_decode) under "disable_functions" in php.ini offcource if you need them for legitimate use you can't do this
Last edited by cpanellover; 10-31-2010 at 04:35 PM.
|
| Posted by WilliamP, 10-31-2010, 04:44 PM | | Good point!
|
| Posted by RivalHost-Todd, 11-01-2010, 09:32 AM | | I would advise caution implementing DotDefender from Applicure. We recently rolled it out on a couple of production servers to prevent the very issues you have experienced. Support is from Israel I believe and takes weeks to get issues resolved IF at all. If you're expecting a sense of urgency from their support you won't get it.
|
| Posted by WilliamP, 11-01-2010, 11:03 AM | | I opened a ticket with vBulletin and here is their response:
We're not aware of any vulnerability within vBulletin 3.8.6 for this however any issue with a plugin will relate specifically to their code. vBulletin just gives the code a 'hook' to attach to and allow it to run during a certain process - we do nothing specifically with a plugin's code.
Exactly what I suspected... neither party wants to accept responsibility or apparently even investigate if they have an security issue.
|
| Posted by Scott.Mc, 11-01-2010, 11:14 AM | | And this is the malicious script/iframe that injects itself at the top in the beginning of the page:"
Have you saw that code at the top of your page ? Since on one hand you seem to mention you clean it (how?) then on the other you don't seem to know where it's coming from.
If you are able to clean it once you should have an idea of where it's coming from based on what you cleaned. If it's writing to all of your files and in turn injecting that way it narrows down what the possibilities are and the logs should show this.
|
| Posted by WilliamP, 11-01-2010, 12:26 PM | | Yes... I copied that directly from "View Source"... however, we nor any of the security techs at Liquid Web could figure out how it was injecting itself into the page. We could not find the code in any of our templates or files.
It was cleared by restarting Apache.
I am guessing that it was perhaps an issue with the previous version of vBSEO that we had (with a known exploit) and has now been updated... or maybe even the OpenX/OpenAds ad delivery program (with known vulnerabilities) that has now been uninstalled. I am again guessing that one of these allowed the code to be injected into our AME plugin in vBulletin. Even though we had updated vBSEO and deleted OpenX, the code was still residing in our AME plugin and resurfacing every few days after restarting Apache.
AME has been uninstalled, which cleared up the last incident of the code appearing. Hopefully a combination of all we did has eliminated the source of entry that initially got the whole thing started. We should know in a few days if it does not resurface.
|
| Posted by Scott.Mc, 11-01-2010, 12:29 PM | | The "security techs" should be providing more information and listing the possible options. If this was appearing on your pages (also note the position of it) then it narrows down the sources drastically. Secondly if it was cleared by restarting apache then your system has most likely been compromised and is not coming from a plugin...... You really should have what information you actually have available reviewed because frankly 4 weeks and still making guesses at every single possibility (When you have the real answers already infront of you) is simply unacceptable IMHO.
|
| Posted by WilliamP, 11-01-2010, 12:54 PM | | We have not been satisfied with how this has been handled by Liquid Web and fully believe we need a more secure server. We are actively looking for a new dedicated server and server management that can provide us better protection... and someone that understands vBulletin and the potential for exploits.
We will most likely know within a few days if the code is still in our system. What we will not know for sure is how it initially got there, UNLESS it is in fact still there, then we may can figure it out.
|
| Posted by LiquidWebBenny, 11-01-2010, 02:11 PM | | Can you give me a ticket or account number? I would like to investigate why you are still having problems.
Thanks.
|
| Posted by WilliamP, 11-01-2010, 02:37 PM | | Hi Benny...
Current Open Ticket: 2363396
Closed Tickets: 2366322 and 2343907
|
| Posted by LiquidWebBenny, 11-01-2010, 02:41 PM | | Thank you. I'm looking into it now.
|
| Posted by WilliamP, 11-01-2010, 02:50 PM | | I also sent you a PM with additional info.
|
| Posted by Techbrace, 11-01-2010, 03:26 PM | | Are you sure the vulnerbility code disappeared after an apache restart? If so, that will be a more severe issue. I highly doubt it though and I think it was just a coincidence. Were you able to locate the file that contained the malicious code? Mostly it will be there in decoded form (base64_decode, gzinflate etc.).
|
| Posted by WilliamP, 11-01-2010, 03:55 PM | | Google reviewed our site and cleared us after each Apache restart. The first time I am fairly particular we did not do anything before restarting Apache. After the restart we did upgrade vBSEO to their latest version at the advice of a few others, just to be safe. The code returned a few days later, at which time we decided it best to do away with OpenX due to its know vulnerabilities and no support for the new version upgrade, which it seems everyone was having issue with. LW scanned our files and found a couple of suspect files, but we never could connect them to this code, however, we deleted them for safe measure. Again, we restarted Apache and it cleared things up, Google reviewed our site for a second time and all was good. A few days later it surfaced again. That is when we realized that every page Google was reporting had the YouTube video embedded via the AME - Auto Media Embedder plugin. We uninstalled it and the problem went away and Google once again cleared us upon another review. I think... I am not 100% sure since LW never responded to my posts in the ticket, but I think they may have restarted Apache again right after we uninstalled AME because our forum went down for a few minutes.
|
| Posted by Techbrace, 11-01-2010, 04:01 PM | | Do you use mod_cache with Apache?
|
| Posted by WilliamP, 11-01-2010, 05:12 PM | | I do not think we do, but I am not sure.
|
| Posted by khunj, 11-02-2010, 02:44 AM | | That trick has been around for the past 2 months.
Check your DB, you'll find the obfuscated JS code and of course check your plugins as well, one of them has been tampered with to read that DB table.
There is indeed a 'base64_decode' function call, but in most cases it was splitted into several parts to hide it.
|
| Posted by WilliamP, 11-02-2010, 11:04 AM | | There have been a few individuals that have looked through and scanned our databases and found nothing. It could indeed have been in the AME plugin... and if it was, it is gone now because it has been deleted. The question is how did it get through the server and into vBulletin? This is almost impossible to know at this point... and potentially impossible to know unless they are caught in the act.
|
| Posted by khunj, 11-02-2010, 12:53 PM | | In the 5 cases I had to deal with, it came from a vulnerable vBSEO version <3.5.2.
Upgrading to 3.5.2 will clean-up the base64 code from the DB which is pretty obvious to find despite the various obfuscation tricks used to hide it.
The code calling it could be anywhere inside one of your plugin.
If your site is the one advertised in your signature, then it should be OK as it is running vBSEO 3.5.2.
But you need to take into consideration that the hack involved cookies + remotely hosted PHP scripts and that makes a pretty bad vulnerability cocktail (cookie stuffing, XSS), so you should really think about changing your forum admin pass and also ask your members to do the same. Changing the DB pass would be a good idea too.
|
| Posted by Steven, 11-02-2010, 01:14 PM | | You need to get someone else to look at it besides liquidweb. Their support in these issues are extremely lacking - I would not be surprised if your server is grossly out of date either from what I have seen over there.
|
| Posted by LiquidWebBenny, 11-02-2010, 01:18 PM | | William, We tried to call you last night but didn't get an answer. We did leave you a voicemail. Is there a better number we can call you at?
Can you provide me with examples? I would very much like to investigate that, and remedy it if you are correct.
|
| Posted by WilliamP, 11-02-2010, 01:36 PM | | Hi Benny...
I am not sure what number you guys called, but I have zero voicemails at any of my numbers.
I will PM you my cell phone number.
|
| Posted by LiquidWebBenny, 11-02-2010, 02:02 PM | | Thanks, got it. A supervisor should be calling you shortly. Too, we'll want to make sure that the number we have on your account is accurate.
|
| Posted by WilliamP, 11-02-2010, 02:35 PM | | I am back in the office now.
Thanks!
|
| Posted by LiquidWebBenny, 11-02-2010, 02:37 PM | | Fantastic. I'll tell the supervisor to call you ASAP.
|
| Posted by WilliamP, 11-02-2010, 02:46 PM | | Thanks for the info... we have indeed changed our passwords.
|
| Posted by Techbrace, 11-02-2010, 02:56 PM | | If your apache is compiled with mod_cache, that could be it. The original content might have been removed, but the cached contents were being served by the Apache and they got cleared once you restarted Apache. That's a possibility.
|
| Posted by Steven, 11-02-2010, 05:26 PM | | Sending you a pm.
|
|
 Add to Favourites
 Print this Article
|
