Security issue

The manipulation of the vBSEO plugin code does not happen via AdminCP. Therefore an entry in the Administator-logs should show up, but there isn't any. We haven't any new unwanted "members" in our admin/mod team too.

The manipulation is most likely using an external backdoor, and it doesn't seem to use a way where it leaves tracks in the server logfiles.

Originally Posted by Mert Gökçeimam

Did your board get effected from centiyo exploit earlier ?

Sorry we are asking too much questions but we are trying to identify what can be the cause for this exploit and since we can't find any logs we are currently hunting fish in dark waters.

Yes, it did.

Originally Posted by Lagaf

The manipulation of the vBSEO plugin code does not happen via AdminCP. Therefore an entry in the Administator-logs should show up, but there isn't any. We haven't any new unwanted "members" in our admin/mod team too.

The manipulation is most likely using an external backdoor, and it doesn't seem to use a way where it leaves tracks in the server logfiles.

Agreed. I cannot find anything in the AdminCP logs or in the Apache logfiles that looks out of the ordinary. That's not to say there is not something in the Apache logs that shouldn't be there, it's just that I don't see anything that I would consider fishy. Are there any specific phrases/etc. that I should search for in them that anyone can think of?

Some possible things to check:

• rogue remote access hosts to mysql
• change all root/ssh/vb/vbseo/etc passwords
• run some grep commands to possibly find something in logs
  
  Code:

  grep -r 'base64' /path/to/access_log

  and things of the sort

Originally Posted by Mert Gökçeimam

Hello ,

Both Brian and I explained several times that vBSEO doesn't have any security hole. If you have logs that can proof othewise , please create a support ticket and supply us the logs.

Guys, common Ithis is what vbulletin answers me:

Simon,

There are no known security exploits in 3.8.4 PL2. However there are exploits in the vBSEO add-ons with you are using, including this one:

http://www.vbseo.com/f3/alert-huge-security-hole-vbseo-3-3x-41463/

That looks like the same issue.

Best regards,
Steve Machol
Customer Support Manager, vBulletin

vBulletin Home Page
http://www.vbulletin.com/
vBulletin Community Forums
http://www.vbulletin.com/forum/


This keeps on coming back. no matter if I use the latest version of both vbulletin and vbdseo. Only thing what works is reinstalling vbseo, or shut down vbseo, seems to be the vbseo is the cause of this, you can like it or not, but it is what it is. So deal with this asap, how can you let a hack/exploit like this let go for over 7 days???

I can't send you my logfiles, I have over 100k visitors per day, my ht-access log is 2 GIG, how do you ever going to find anything there???

Dudes get this fixed!!

Simon

Originally Posted by Brian Cummiskey

Some possible things to check:

• rogue remote access hosts to mysql
• change all root/ssh/vb/vbseo/etc passwords
• run some grep commands to possibly find something in logs
  
  Code:

  grep -r 'base64' /path/to/access_log

  and things of the sort

My MySQL server is only on a private network (no public IP address assigned to the box at all), only accessible via my web servers on their private LAN IP's so that isn't it. It's coming in through the web somehow. All passwords have been changed in the past, yet it happened again. I have searched for base64 in the logs and turned up with nothing so that wasn't it either. Yet, one would think that in order for the code to be injected into the database, that phrase would need to be visible somewhere in the access logs. I'm stumped as well.

Realistically, all that you guys are doing when you disable/re-enable vBSEO is rebuilding the datastore, which gets rid of the injected code and temporarily fixes the problem.

Simon, would you be willing to provide root server access to your box so our team can investigate? As of this moment, we have 0 logs or anything that points to anything as an entry point, be it vbseo or otherwise. We are working to find this, but as it hasn't happened to anything we staff own or have access to, and no one has been able to produce anything, it's a wild goose chase at this point in time.

Originally Posted by gcc llc

My MySQL server is only on a private network (no public IP address assigned to the box at all), only accessible via my web servers on their private LAN IP's so that isn't it. It's coming in through the web somehow. All passwords have been changed in the past, yet it happened again. I have searched for base64 in the logs and turned up with nothing so that wasn't it either. Yet, one would think that in order for the code to be injected into the database, that phrase would need to be visible somewhere in the access logs. I'm stumped as well.

Realistically, all that you guys are doing when you disable/re-enable vBSEO is rebuilding the datastore, which gets rid of the injected code and temporarily fixes the problem.

Can you also please search for global_start in your access and error_logs .

Originally Posted by Brian Cummiskey

Simon, would you be willing to provide root server access to your box so our team can investigate? As of this moment, we have 0 logs or anything that points to anything as an entry point, be it vbseo or otherwise. We are working to find this, but as it hasn't happened to anything we staff own or have access to, and no one has been able to produce anything, it's a wild goose chase at this point in time.

I have send you a PM

Simon

Originally Posted by Mert Gökçeimam

Can you also please search for global_start in your access and error_logs .

No, I don't see global_start in any of the logs either.

Simon has provided access and we are investigating.

If any of the affected boards are running MySQL binary log (MySQL :: MySQL 3.23, 4.0, 4.1 Reference Manual :: 5.3.4 The Binary Log) we could find a query that updated the db datastore (please provide details via the ticket in this case). If not, I'd recommend to enable binary log (for some time) just in case if attack repeats.

This might be related:

vBa CMPS Security Alert! 3.2.2 & 4.0 RC1 Released - vBadvanced Forums

Originally Posted by Oleg Ignatiuk

If any of the affected boards are running MySQL binary log (MySQL :: MySQL 3.23, 4.0, 4.1 Reference Manual :: 5.3.4 The Binary Log) we could find a query that updated the db datastore (please provide details via the ticket in this case). If not, I'd recommend to enable binary log (for some time) just in case if attack repeats.

We are running MySQL 5.0.77. Not sure if the version matters or not. I will enable the binary log and see what comes up. For what it's worth, I read the security bulletin on CMPS as well, but we are not running that on the affected board. I appreciate everyone's input so far!

The server we are testing against is not using vBa, so this desn't appear to be related.