Help in securing vB 3.0.xx for the CSRF vulnerability
 

OK friends, here is the problem.

I have been using vB 3.0.xx in my site, for two simple reasons, (a) that I had no good reason to upgrade, 3.0.xx was covering my needs and (b) because my site is heavily hacked/improved with lots of modifications, some of them downloaded from here and some of them done by myself. When vB released 3.5, with the new coding conventions, I decided that the hassle was too much, and the benefits too little, so I stayed with 3.0.xx and have never regretted it.

All these years, I have been paying my vB license fees, for the simple reason that I was hoping that Jelsoft will have the decency to provide me with security updates/fixes. Remember that I am using the same major release as the current one, so I was under the impression that Jelsoft would at least make sure that my version is secure.

Enter the latest vulnerability announcement and Jelsoft position, that they do not offer any security fix for older releases. I find this absurd, but that's not the point here. The point is that I am forced to either upgrade to 3.7 and loose all my special code in my site, or to stay with a vulnerable version of vB.

I have been in touch with vB people and they do not recognize this problem, their position is that this vulnerability is not very serious and that they can't support previous releases (we are still at the same major release, mind you) and this is a security issue. I understand that they can't provide a patch for 3.0.xx, but what I was looking for, was at least some concise, concrete instructions on how to plug this hole in their software. Instead, they have send me a couple of files, which were supposed to help me patch my version (one is an explanation of how to patch 3.6.xx and the other is a diff file showing all differences between 3.6.9 and 3.6.10), unfortunately the code is in vB 3.6 not in vB 3.0. As a result these files are next to useless for me. For example, the code does not use md5 for the token, but sha1 or something, which I am not even sure it can be used in the php release I am using.

Implementing the fix on the end-user side is relatively easy, all one has to do, is to add the following line in the php files he wants to protect:

and add this line in the templates which use POST to submit a form:

My problem is how this "securitytoken" is generated and added in the $bbuserinfo array, and of course, where is the token checked, when submitted by a form which uses POST.

Can someone help on this? Can someone help me figure out the code which has to be added (in 3.0.xx coding standards) and where, in order to generate the token and check it?

As I explained upgrading will be a huge problem, due to all the different code I have implemented in my site (my users will go crazy, I am not even sure if the site can be upgraded with all the different columns I've added to tables etc), and keep using a vulnerable release is of course plain stupid, so all help on this will be appreciated.

I dont really have an answer ready for you. You will need to compair the 3.6.9 & 2.6.10 versions and "translate" the changes to 3.0.

I would however suggest that you reconsider your choice. You will only run into this kind of issues more and more (since 3.0 is not maintained anymore). I would suggest to make the effort once to upgrade to 3.7, so that future updates will go easier (hardly any code edits needed anymore).

I wish I could produce for you a file with all the diffs my code has from the standard 3.0.17 vB code. I do not believe there is a single php file in my installation, which hasn't been changed either little or a lot. I understand that you do not need to touch vB code per se now, with the hooks system (I think that's what they call it), but porting all the mods I have done in my code to the new coding scheme is a herculian task.

When vB went from 3.0.xx to 3.5, I found the new coding method so strange that I completely gave up on it. For example:

In 3.0.xx you knew that $bbuserinfo was an array that contained the user information. Wherever you wanted to use the user id, you used $bbuserinfo[userid]. If you look at 3.6 code, inside php there is $vbulletin->userinfo and in templates there is $bbuserinfo. Why? it didn't make sense for me, so I gave up.

Now, even if I do upgrade to vB 3.7, it would take me months to get all the code I have in my site in "plugins" form and add it again. I understand that Jelsoft doesn't cosnider 3.0.xx as a supported release, but we are not talking about a bug fix here, we are talking about a security issue. Microsoft, even though they are in Vista now, they still issue security updates for XP. I was expecting Jelsoft to do the same, since we are still at the same major release. Unfortunately, they don't. I understand that the majority of vB sites have moved to 3.5/3.6 and now to 3.7, but there are sites out there which are using older versions because they do not need the additional functionality or for their own reasons. Security updates should be available, even if not in the form of a patch, but in the form of clear instructions (in vB 3.0.xx code) on how to close the vulnerability. That's the only reason I was paying Jelsoft money all those years.

Sorry Marco, I guess I am just venting, because of the task in front of me (upgrade) or the decision to live with a potentially hackable site. I like neither routes, but unfortunately I have to select one of them.

Although I understand your frustration, I know how it would feel to be in your shoes. Regardless, a choice like you said needs to be made. Don't take it from me, but the logical course of action here would be to simply perform the upgrade, however long it takes. This can be done in parallel to your live board; simply copy your DB and make an exact copy of your board and start apply all the changes as needed.

You really have 3 options here:
a) Find a way to secure your boards (if this is even possible) and continue running on your current version. The downside, this is inevitably a dead end because you cannot run this version of VB forever, you will need to upgrade eventually. It's inevitable, the sooner you do it, the better.

b) Perform the upgrade as suggested parallel to your live boards. The downside, it won't be easy and will take a while, but in the end it will be truly worth it and your users will thank you for it.

c) Give up now, and jump out a window.

A small suggestion, something I've learned over the years:
However small a change you make, I've learned to keep small records of literally almost every change I make. All the template changes I have made are saved in html files. All my php edits (however little I have) are saved in txt files with specific instructions on how to reapply them (incase of upgrade). And so forth. The more documentation you have of your changes, the easier it will be for you in the future to avoid such a problem you are facing now.

I hope this helps you. Good luck.

The CSRF vulnerability is not classified as critical as it relies on people being misled into clicking links which performs actions which were not intended. This vulnerability is present in a lot of scripts.

As long as you, your admins, and your moderators are smart ("web-smart"), there is no need to patch vBulletin.

The patch is extensive, if it was not, a "patch level (PL)" release could have been made.

I have a heavily hacked board and it wasn't until last December that I finally upgraded to 3.6.8 from 3.0.12. I found that most of my hacks were very easy to translate to products/plugins. Of course, there were many that were released here, but I had several custom hacks that I wrote just for us and so I had to translate those all myself. I set up a test site and did it all on there. It took me a couple of months, but I feel it was time well spent to finally be using the hooks/plugins system.

In regards to this CSRF, I have heard that what needs to happen is someone posts an image/link on your site that one of your moderators then follows offsite which then grabs some information from you. Perhaps tell your mods not to click on any link unless they trust the person?

I guess I will be against everyone and help you find the solution without upgrading.

All the code I am getting is from 3.7.0 files.

The security token is defined on line 1334 of class_core.php with this code.
Then this code is checked in init.php at line 398 - 460 with this code.
This code replace the following code in 3.7 R3 before the CSRF patch was released.
You just need to do something similar or come up with another way of doing it.

In fairness, Microsoft supports the version prior to the current release. They no longer support Windows 98 or ME. To apply that to this scenario, you are a couple fairly major releases behind.