vBulletin Redirect Exploit

[MattF]

One of these exploits you've mentioned recently wouldn't happen to be a base64 encoded file they upload to the server by any chance, would it? Something which uses a search engine link forwarding strategy type affair?

 

[djbaxter]

That's possible based on prior instances of the redirect issue. However, in the current case, no base64 was found in the vBulletin database.

 

[MattF]

Cheers. Was just curious as someone posted a file over on CF the other day wondering what the unencoded version was and did. Wondered if it might have been a related thing.

 

[el canadiano]

It's not vBSEO because it affects forums that have never had vBSEO installed. Lately, it seems vBulletin blames vBSEO every time they can't figure out what's causing the issue. It's getting old.

Wow. I feel pretty bad for them being rude to you, no offense or anything.

 

[djbaxter]

From vBSEO (applies even if you don't use vBSEO):


vBulletin Security Patch for 4.X and 3.X - vBulletin SEO Forums

Everything we have seen points to insecure folder and server security, not software.

Google redirecting to filestore123.info - vBulletin SEO Forums

No offense, but the support for this has been really sad here. I mean, instead of just pointing to a jumbled mess of a thread where people are trying to figure it out. How about a concise thread with all the fixings? I realize it is not vbseo's fault, but since it directly effects vbseo, and all the vbseo customers could potentially have this problem, having a concise thread would be nice.

Anyhow... Here's what I've gathered as I am also having this issue.

THE BUG...

The fact that people can upload custom avatars, custom signature pics, or custom images into the signature line. What is happening is that a PHP file, disguised as a .gif is uploaded and then run remotely. It throws base64 code into vbseo which forces a javascript redirect and cookie. The cookie means the redirect only happens once, but it is annoying, and is a drop in traffic. On a side note, more malicious code COULD be uploaded.

WHAT YOU MIGHT READ...

Many of the yahoos here want you to chmod 755 any writable directory. But what they fail to realize is that your signaturepics and customavatars directory must be 777 for people to upload. I read that far too often in that other thread.

WHAT YOU MUST DO...


STEP 1:

Is add an .htaccess file to every writable directory that someone can upload photos into.

RedirectMatch 404 .*php\.

The other code for .htaccess I've read is this one

[COLOR=#3e3e3e][FONT=Courier New]<Files ~ "\.(php\d*|cgi|pl|phtml)$">[/FONT][/COLOR]
[COLOR=#3e3e3e][FONT=Courier New]order allow,deny[/FONT][/COLOR]
[COLOR=#3e3e3e][FONT=Courier New]deny from all[/FONT][/COLOR]
[COLOR=#3e3e3e][FONT=Courier New]</Files>[/FONT][/COLOR]

Not sure which one is more correct at this point, but both should work. Most folks have been going with the second one.

Thankfully .htaccess has a recursive effect, so if you put it in the offending directories, that should solve the issue.

The directories you need to add this file to is:

• customavatars
• signaturepics
• customprofilepics
• attachments

STEP 2:

Reupload the crawlability_vbseo.xml file as a product. This will clear out the cache and fix your site immediately... As long as nothing else has been compromised.


Step 3:

I would say disallow uploads to your server. At least break it up. Have a different usergroup for premium members, or however you break it out on your site, and allow them to upload files. But keep the uploads only to them, not to the new folks and spammers.
If you're allowing uploads to the new members, you're keeping yourself open to this type of attack.

Step 4:

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.

Step 5:

Lastly, if you have been hacked, change your passwords. Just in case.


......................

So that's what I've gathered in a nutshell. Hopefully that will help someone out instead of just being pointed to a ton of threads, with half of them having misinformation

 

[wanksta]

Minstral which version of the htaccess file would you use?

RedirectMatch 404 .*php\. perhaps?

 

[djbaxter]

Sorry. I posted that in a hurry and it didn't all copy over. I'll edit it in a moment.

This is the version I am using in all writable image folders:

Options +FollowSymLinks
Options All -Indexes
<Files ~ "\.(php\d*|cgi|pl|phtml)$">
order allow,deny
deny from all
</Files>

 

[wanksta]

Sorry. I posted that in a hurry and it didn't all copy over. I'll edit it in a moment.

This is the version I am using in all writable image folders:

Options +FollowSymLinks
Options All -Indexes
<Files ~ "\.(php\d*|cgi|pl|phtml)$">
order allow,deny
deny from all
</Files>

Do I need to input any other code in the .htaccess file or will that code be all that is required in the htaccess file?

Thanks!

 

[djbaxter]

That is all that's required for the .htaccess file for the writable image directories. Don't use this one for the other directories.

 

[wanksta]

Minstrel what's the go with directories with other sub-directories within them?

For instance

-attachments
--1
--2
--3
--5
--etc

If I put this htaccess file in the attachment directory does the contents of the htaccess file effect all the sub-directories of /attachement/?

Thanks!

 

[MattF]

So in other words, they're using file extensions rather than actual filetype checking for determining whether a filetype is legit or not?

 

[djbaxter]

Minstrel what's the go with directories with other sub-directories within them?

For instance

-attachments
--1
--2
--3
--5
--etc

If I put this htaccess file in the attachment directory does the contents of the htaccess file effect all the sub-directories of /attachement/?

Thanks!

I'm not sure about that myself. To be safe, I just uploaded the htaccess file to all of them.

 

[djbaxter]

So in other words, they're using file extensions rather than actual filetype checking for determining whether a filetype is legit or not?

Yes. That's one of the exploits.

 

[wanksta]

I will I am just worried vBulletin makes extra directories in folders where write permission is granted in the process of uploading for whatever reason.

I think vBproGarage for instance makes a directory per upload which makes it impossible to implement this 'fix'.

Thanks

 

[djbaxter]

Even if you make this change in the standard vBulletin folders it should help, especially if you include the "Options -Indexes" line.

 

[BrandonSheley]

Is this exploit one of those where when you land on a site, you are immediately redirected to a site that tells you your computer is infected with malware, download some product now?

Sorry. I posted that in a hurry and it didn't all copy over. I'll edit it in a moment.

This is the version I am using in all writable image folders:

Options +FollowSymLinks
Options All -Indexes
<Files ~ "\.(php\d*|cgi|pl|phtml)$">
order allow,deny
deny from all
</Files>

Thanks for this!!
We updated the PL last night and I'm checking the site today.
I'll add this "just in case".. It wouldn't mess anything else up on the site I assume, right?

 

[djbaxter]

Thanks for this!!
We updated the PL last night and I'm checking the site today.
I'll add this "just in case".. It wouldn't mess anything else up on the site I assume, right?

It shouldn't. I've implemented it on four sites and it hasn't messed up anything there.

 

[SiteOwnersClub]

Thanks for this!!
We updated the PL last night and I'm checking the site today.
I'll add this "just in case".. It wouldn't mess anything else up on the site I assume, right?

No it won't.

It basically just stops any php, perl, cgi, or dl files from being executed/run from those folders.

As long as you do not put it in a folder with php, perl, cgi, or dl files (like the includes folder), you will be fine.

With that .htaccess file in each of the upload folders, even if someone managed to upload a php script, they would not be able to execute/run it.

 

[djbaxter]

No it won't.

It basically just stops any php, perl, cgi, or dl files from being executed/run from those folders.

As long as you do not put it in a folder with php, perl, cgi, or dl files (like the includes folder), you will be fine.

With that .htaccess file in each of the upload folders, even if someone managed to upload a php script, they would not be able to execute/run it.

Yes. That's exactly right.

 

[MattF]

It's poor form, from a coding standpoint, if that's the only checks they do on image uploads though. That particular exploit is easily preventable and should never have existed.