vBulletin Redirect Exploit

[djbaxter]

From Zachery at vBulletin:

http://www.vbulletin.com/forum/showthread.php/380561-vBulletin-3.x-and-4.x-Redirect-Security-Exploit?p=2168592&viewfull=1#post2168592

For anyone having their search engine traffic redirected, I've only found plugin code in a vbseo plugin point in the datastore table. Enabling, and disabling a single plugin normally rebuilds the pluginlist in the datastore and fixes the problem.

Note that at least one other person in that thread identified a different plugin (i.e., from vBulletin.org, not vBSEO) as the problem. Also, this doesn't identify the entry point precisely so even if it is a contaminated plug-in and rebuilding the datastore "solves" the problem, what's to stop the problem from reappearing?

 

[wanksta]

I use vBSEO Sitemap Manager only do you think there might be an issue with it?

 

[wanksta]

Sorry and one more final question regarding the htaccess 'fix':

Should <File> or something be here to accompany the close </file> tag at the bottom?
Options +FollowSymLinks
Options All -Indexes
<Files ~ "\.(php\d*|cgi|pl|phtml)$">
order allow,deny
deny from all
</Files>

 

[djbaxter]

I use vBSEO Sitemap Manager only do you think there might be an issue with it?

No. I don't think this has anything to do with vBSEO. That's become the official vBulletin explanation for any security issue. As I said, some of the forums hit by the redirect weren't even using vBSEO and at least one person found the redirect code inside an entirely different add-on.

It may well be that the redirect is introduced via an executable image file (see how to protect writeable directories above) and once it executes it lodges inside one of the cached files in the datastore.

 

[djbaxter]

Sorry and one more final question regarding the htaccess 'fix':

Should <File> or something be here to accompany the close </file> tag at the bottom?
Options +FollowSymLinks
Options All -Indexes
<Files ~ "\.(php\d*|cgi|pl|phtml)$">
order allow,deny
deny from all
</Files>

It's already there in this line:

<Files ~ "\.(php\d*|cgi|pl|phtml)$">

 

[wanksta]

It's already there in this line:

<Files ~ "\.(php\d*|cgi|pl|phtml)$">

Thank you minstrel I thought I would check as I will be uploading this file in many writeable places on my server.

The exploit certainly sounds like an exploit via uploading of malicious gifs as per the info you've provided.

 

[ITzzJake]

We've recently seen both malware alerts and redirection exploits on vBulletin 3.x and 4.x versions. The redirects take links to your site to a link that looks like

[noparse]http://file2store.info/download.php?id=038CBCD4[/noparse]

This is an exploit first reported in 2010: see http://www.vbulletin.com/forum/showthread.php/345283-Secutity-Redirction-to-file2store.info

After trial and error and some research by myself and Linda Buquet at 5 Star Forums, we were led to this:

http://developer.yahoo.com/yui/



If you know how to do it, you can upgrade the YUI version for your installation. Do NOT use the built in vBulletin YUI files since they are an older version (still, as of vBulletin 4.13).

In the meantime, do this:

1. Admin CP >> Settings >> Options >> Server Settings and Optimization Options
2. Scroll down to Use Remote YUI
3. Set this to Google

What about just selecting "None" instead of "Google"?

 

[djbaxter]

What about just selecting "None" instead of "Google"?

No, because that will use the files included with vBulletin, which (prior to 4.14) are the old 2.7.2 version.

 

[ITzzJake]

No, because that will use the files included with vBulletin, which (prior to 4.14) are the old 2.7.2 version.

Gotcha. Thanks for the quick response.

 

[BirdOPrey5]

I don't understand, I've tried to upload gif files with png or jpg extensions (and vice-versa) and I aways get an error the extension doesn't match the file type so it has to be checking.

 

[BrandonSheley]

Is there a quick way to add the htaccess file to a set of folders?
One client has over 130 folders in their gallery setup
I may just download that gallery folder and use CMD to add the file to all folders, I don't have SSH access to the server.

 

[Jim McClain]

You should not have to add .htaccess to child folders. Those folders are dynamically created and don't require a .htaccess file for each and every one.

From Apache Tutorial: .htaccess files:

.htaccess files (or "distributed configuration files") provide a way to make configuration changes on a per-directory basis. A file, containing one or more configuration directives, is placed in a particular document directory, and [highlight]the directives apply to that directory, and all subdirectories thereof[/highlight].

 

[djbaxter]

You should not have to add .htaccess to child folders. Those folders are dynamically created and don't require a .htaccess file for each and every one.

From Apache Tutorial: .htaccess files:

Thanks for that. I've never been certain.

 

[BrandonSheley]

You should not have to add .htaccess to child folders. Those folders are dynamically created and don't require a .htaccess file for each and every one.

From Apache Tutorial: .htaccess files:

thank you for that

 

[BrandonSheley]

I still have a client that's getting nailed with this redirect.
We've done everything listed in this thread, anymore ideas?

thx

 

[Adam H]

Note down all the plugins installed, save the skin. delete every file on the server and reupload fresh vbulletin , plugins etc all over again, Change the config file info to match your database again.

It could be left over files allowing them access again or it could be a matter of your clients computer having an infected FTP client. A good antivirus will pick most things , Nod32 is more than recommended for local machines.

Deleting the files would have been the first thing i had done as well as changing all FTP and cpanel details after i had deleted all files.

Just remember to disable all hooks from the config file before hooking up the database connection again because obviously you will need them disabled to over write them when installing them all again so you dont loose any settings , things like VBSEO urls and Post thanks etc.

Also dont forget to back up all attachement, signature , avatar folders etc and run them though a scanner

 

[djbaxter]

I still have a client that's getting nailed with this redirect. We've done everything listed in this thread, anymore ideas?

I have a 3.x forum (I'm not the owner, just tech admin) which is still getting hit, too. What version is your client running, Brandon?

To remove it temporarily, do this:

1. Disable one of the plugins (doesn't matter which one) and then re-enable it. This will flush the datastore and get rid of the redirect. The problem is, that seems to be only a temporary fix.

2. Make sure if the forum is running vBSEO that the latest version is installed.

3. Try this suggestion (this is the next step for me as well):

Remove any evil .gif files off your server

To do this, ssh to your server and run this command:

find /home/main -regex '.*\.gif$' -exec grep php {} \;

Change the /home/main to fit your main root directory. Delete the matches in those upload directories!! I usually check them first, but remove them.

It may be that the redirect came back on the forum I'm associated with because we didn't remove the original exec disguised as a gif? If so, it's not in the regular customavatars or customprofilepics folders because those are protected by .htaccess from running executables.

 

[BrandonSheley]

Thanks Adam and David,
I'll look over what you both have written and make the neccessory changes.
They are using the latest vbulletin version 4.1.4 ATM.

 

[djbaxter]

See http://www.vbulletin.org/forum/showthread.php?threadid=265866 - also works with vBulletin 3.x - again. it's not a fix but it will at least alert you.

 

[djbaxter]

Another possible fix for the file2store.info redirect exploit

Despite implementing the fixes posted here and elsewhere, some forums continue to be plagued by the file2store.info redirect exploit. I have the impression that it is mostly 3.x forums who have persistent problems.

The scenario is that some of the suggestions seem to "fix" the problem temporarily but it retuirns within an hour, a few hours, a day, or a couple of days. To complkicate the issue, the exploit also drops a cookie named vbsp onto your computer (under your forum domain) so you won't see it again for 24-48 hours unless you remove the cookie.

I found this at vBulletin.org: http://www.vbulletin.org/forum/showthread.php?t=220967

A common method of defacing vBulletin sites is to edit the parsed template html directly via the database. It makes it harder for administrators to find the issue, and can be a pain in the ass to cleanup if you're not familiar with working with the database.

This very tiny addon will make it easier to clean your defaced site.

What it does:
Checks all of the templates in the database;
- Makes a new parsed version from the unparsed template.
- Compares the current parsed template to the new parsed template
- If they differ it updates the template, then rebuilds all of the styles.

How do you use it?
- Upload to your admincp folder
- Browse to it
- Let it run

Download Now
tool_reparse.php (1.7 KB, 437 downloads)

Supporters / CoAuthors
•Link14716
•Zachery

Here is the explanation behind how the template system and this tool works.

Templates are stored in two ways. There is the unparsed template, which you edit in the Admin CP. It is the template as you know it. Then, there is the parsed template, which is the template after it has been ran through a function to convert things like <if> tags into valid PHP parsable code.

A common method of defacing vBulletin forums is for a hacker to directly edit the parsed version of the template in the database, leaving the unparsed template alone. When you go to edit the template in the Admin CP, you won't see anything different, but the parsed version of the template has changed.

What this tool does is it takes all of the unparsed templates from the database and creates a new parsed version from it. If the newly generated parse is different than the parsed version currently in the database, it will update the template, overwriting the old, probably compromised, parsed template. This process is not "danger".

On one 3.83 forum which has just been upgraded to vBulletin 3.87 PL2, we are having a very persistent problem with the exploit, despite trying all of the suggestions in the various threads on the exploit.

I just uploaded and ran the tool_reparse.php file from the admin directory on that forum.

When I ran this tool, it DID rebuild the templates as follows:

Updating style information for each style

New AFF ... (Templates) (StyleVars) (Replacement Variables) (CSS) (Controls) Done.

If I understand the vBulletin.org thread correctly, this means it found a discrepancy between the compiled and non-compiled versions of the templates and fixed it.


You might want to try this on your forum if you are still being harrassed by this annoying exploit. I would advise you to remove the tool_reparse.php file after running it.