Information about file2store.info redirect. Solution?

[Hoffi]

I created a Cron Job that checks the Datastore and rebuild it. Look at vbulletin.org

Use that AddOn only as warning, not as a solution!

[djbaxter]

That means the issue is with your add-ons, not vB. At the very least you should upgrade to the latest versions of vBSEO and vBSEO Sitemap, then contact them if you have further issues.

No, it does not. It's in the datastore. Disabling a product and then re-enabling it just clears the datastore but the infection gets reinjected , apparently automatically.

Btw: at 8:47 pm I disabled another plugin than vbseo and the redirect disappeared.

It's not vBSEO. It's occurring on numerous vBulletin forums without vBSEO. That's a red herring and a time waster.

At this moment the redirect is not yet back, but it can take a day.

It installs a cookie titled vbsp under your domain. If you delete that cookie, you'll be able to see the exploit again earlier than 24 hours. We are battling this on one vBulletin 3.87 PL2 forum and it returns in an hour or two.

We still do not know where it comes from.

- vbulletin looked into it and according to them it was in the datastore plugin bit, but not in de plugins themselves. Despite that the redirect keeps turning back after rebuilding the datastore

Yes. Exactly my experience.

I've been hit by this @#?ing hack five times now and I'm really sick of it. I thought I fixed it last week when I updated vbSEO and vbSEO Sitemap Generator to the latest versions. Today I did a search in Chrome incognito window that would show me my forums, and the damn script is back!

If I disable vbSEO and the sitemap generator, I don't get the re-direct.

When I enabled Sitemap Generator, I don't get the re-direct.

When I enabled vbSEO, I don't get the re-direct.

So is there some file that is generated when vbSEO and the Sitemap generator are turned on and that file is getting hacked?

This entire thing baffles me - I've never had such a persistent problem like this before!

No. By disabling and reenabling ANY add-on product, you are clearing the datastore. It doesn't matter what product you disable. It will get rid of the redirect temporarily but it will return, usually with a few hours to a day or two.

The exploit is being injected into the datastore table directly. Every forum I've run into has some hacks. Though I should have really compiled a list.

Easy temp fix is to enable and disable a plugin, to rebuild the cache.

Exactly. But that's strictly temporary. It does not remove the infection.

I created a Cron Job that checks the Datastore and rebuild it. Look at vbulletin.org. Use that AddOn only as warning, not as a solution!

Hoffi, on the 3.87 PL2 forum I mentioned above, the redirect exploit when it returns is now also deleting the cron job for your product - repeatedly. Do NOT rely on your add-on to tell youy when the exploit returns. The only way to tell is to do the base64 search in your database or use Google or Google Reader to access a thread on your forum (after ensuring that the cookie it drops is removed).

[Zachery]

Are you on a shared webhost?
Are you using ANY third party addons, or non default vBulletin code?
Are you 101% positive that you and anyone else who can connect to cpanel, ssh, ftp is not comprimised in some way.

[djbaxter]

Are you on a shared webhost?

No. Dedicated server.

Are you using ANY third party addons, or non default vBulletin code?

Yes of course.

Are you 101% positive that you and anyone else who can connect to cpanel, ssh, ftp is not comprimised in some way.

All passwords have been changed. The Admin CP is now residing in a non-default folder and is IP protected. FTP is now on a non-default port and also IP protected.

[Zachery]

So why haven't you disabled all of your third party addons?

[djbaxter]

So why haven't you disabled all of your third party addons?

And then what? What sort of strategy is this? Are you really trying to say that vBulletin cannot possibly have a vulnerability which allows so many installations nto be victimized? Are you really trying to suggest that we all have the same add-ons installed and that's why we're being victimized? Isn't this is just a repetition of the vBSEO red herring to get people off the backs of vBulletin?

Maybe it's a vulnerability in the vBulletin plug-in system itself.

Why haven't YOU made a list of all the third party add-ons on all the installations you have investigated, so you could look for commonalities?

[djbaxter]

See https://www.vbulletin.com/forum/show...19#post2185219

[djbaxter]

With the help of the security people at RealWebHost.net, we have now positively identified the method for injecting this exploit as well as specific vulnerabilities that permitted it on a 3.83, since updated to 3.87 PL2: As it turns out, it was a server configuration and security issue combined with some specific attributes of vBulletin installations which gave the intruder direct access to the MySQL database.

The key is first to check your settings in cPanel for Remote MySQL: Unless you are using a database on a remote server, i.e., NOT on localhost, this setting should say "There are no additional MySQL access hosts configured". If you have a specific database intentionally enabled, that too is okay. What should NEVER be there is the character % - this is a wildcard which allows ALL other servers to connect to the database. If you see the wildcard enabled, DELETE IT.

Then, make sure you change your passwords to strong passwords for both cPanel and MySQL to ensure that no one can change this setting back without your knowledge.

Then, pick any add-on, disable it, then re-enable it to clear the datastore.

Finally, download the file tool_reparse.php from http://www.vbulletin.org/forum/showthread.php?t=220967 and let it find discrepancies in your compiled templates and rebuild them.

[farhanisfarhan]

Have you looked at your access logs? Specifically, for plugin.php being accessed from an IP that isn't yours?

I was affected by this for a while, I ended up .htaccess protecting my admincp, with a global IP deny, except for mine.

Didn't work for me....

[furnival]

Didn't work for me....

The solutions posted in the latest posts above did not work for me either. Remote access to my DB is disabled and all important folders are protected by IP-based htaccess. Still the redirect exploit reappears sometime after I clear the datastore

[djbaxter]

Something is resident on your server that is regenerating the exploit.

1. Did you check the files via AdminCP -> Maintenance -> Diagnostics -> Suspect File Versions? Delete all suspicious non-vBulletin files that you don't recognize, re-upload any that say contents not as expected, and get rid of any image files that shouldn't be there.

2. Have you changed ALL your passwords for server access, MySQL access, FTP access, and AdminCP access?

3. Have you checked your Admins group to ensure that someone hasn't created an unauthorized admin account?

[furnival]

DJBaxter, Thanks, your advice throughout this thread was invaluable. In my case uninstalling a couple of modifications with known security risks seems to have fixed this. I run the "Check 4 Hacking" modification (available at vb.org) scheduled task to check for Base 64 coded inserts in my templates but these days it never finds any inserted code.

[Loco.M]

Here is the source of your quote which DOES work if you follow the directions fully...

http://www.theadminzone.com/forums/showpost.php?p=597122&postcount=81

With the help of the security people at RealWebHost.net, we have now positively identified the method for injecting this exploit as well as specific vulnerabilities that permitted it on a 3.83, since updated to 3.87 PL2: As it turns out, it was a server configuration and security issue combined with some specific attributes of vBulletin installations which gave the intruder direct access to the MySQL database.

The key is first to check your settings in cPanel for Remote MySQL: Unless you are using a database on a remote server, i.e., NOT on localhost, this setting should say "There are no additional MySQL access hosts configured". If you have a specific database intentionally enabled, that too is okay. What should NEVER be there is the character % - this is a wildcard which allows ALL other servers to connect to the database. If you see the wildcard enabled, DELETE IT.

Then, make sure you change your passwords to strong passwords for both cPanel and MySQL to ensure that no one can change this setting back without your knowledge.

Then, pick any add-on, disable it, then re-enable it to clear the datastore.

Finally, download the file tool_reparse.php from http://www.vbulletin.org/forum/showthread.php?t=220967 and let it find discrepancies in your compiled templates and rebuild them.

oh oops, I see this is your quote ;p

[JonB93]

Hey everyone , I know this thread is old but it can be very valuable for others experiencing this issue. I too experienced it for the past week and couldn't figure it out. Thanks to this thread, I did find a % in remote MYSQL in my cpanel. I deleted it, rebuilt my datastore and so far so good. We'll see how it works within the next 24 hours. I also changed my cpanel ftp passwords, as I'm sure that was my backdoor for someone to be able to create this connection initially! Scary!