vBSEO Security Bulletin - vBSEO 3.3.2 Released

Guys, i have pulled all of these posts out of public view. It helps no one while it may hurt those who have not yet had the chance to upgrade.

I would ask at this point to please stop discussing the specifics of the bug for the sake of those customers.

Thank you.

Originally Posted by reborg

The exploit is not limited to only attachment and/or avatar or profilepic folders. Any folder / directory can can be written to by the web server is vulnerable, especially if the .htaccess file is writable by the web server user id.

Sure thing Brian, sorry - no problem if you delete them. Reborg, did not mean to sound that way. The first post was an answer to the statement above, which is expressly referring to this exploit but has actually no effect on it, and is thus wrong and could do harm. That's all there is. Do not get it too personally, man, and I am free to talk to you via PM if you want to.

Thanks.

I also prefer we do not discuss specifics and discuss generic file system protection.

It does not matter what is the exact exploit.... the nature of how to protect a file system is the same. So before dropping off, let me repeat some key points.

(1) Exploits that use the web server (forums, vb, vbseo, etc.) run under the process ID of the web server (user and group ID).

(2) Regardless of the exploit, you do not want any files or directories in your filesystem to be write-able by the web server unless it is absolutely necessary, for example, the customavatar files, the attachments, the site_maps, etc.

(3) No file or directory outside of your web server filesystem should be write-able by the user ID of the web server (except maybe /tmp)

(4) For directories that are write-able by the web server process - these files and directories are vulnerable, regardless of the nature of the exploit.

(5) So, you must assume that there will be an exploit in the future, because there will always be a vulnerability.

(6) If you protect your filesystem properly, any exploit via the web server will have minimal impact, regardless of the exploit.

Originally Posted by ant

The first post was an answer to the statement above, which is expressly referring to this exploit but has actually no effect on it.

No, the discussion has never been about "your particular exploit".... calling the exploit an injection attack or otherwise is not relevant. You missed the entire point and you seem to be still missing it because you are focused on your (a) single exploit.

We are discussing the bigger picture... how to mitigate against a web server based attack.

vbSEO and vB use a web server. Their processes run under the UID and GID of the web server. You can greatly limit any damage by properly managing the file system security.

As I said (this is the 3rd time at least), the exact nature of one exploit is not important. What is important is the protection and integrity of the file system knowing that an exploit can happen any time, any day.

Yeah, all good points.

About point (1), a lot people are still running suPHP (even though it is not recommended with vBulletin, I remember - and it has poorer performance than PHP), so they must take that into consideration and rethink their filesystem with this in mind, as the script will run with the same ownership assigned to the file.

All points are very important, and I'd like to stress the fact that they are even more important in shared hosting setups. If you setup a directory to 777, on some hosts that are not enforcing a solid enough file system structure, it means that anybody on the server can do something in that directory if he/she knows the path.

For the final post reborg, I give up because I do not know how to explain anymore. Last word on it is yours.

I will give one more example. Here is some sample output from tripwire.

Code:

### Warning: Policy Update Changed Object.
### An object has been changed since the database was last updated.
### Object name: Conflicting properties for object /root/.viminfo
### > Inode Number
### Continuing...
### Warning: Policy Update Changed Object.
### An object has been changed since the database was last updated.
### Object name: Conflicting properties for object
### /website/www/vbseo_sitemap/data/downloads.dat
### > Size
### > Modify Time
### > CRC32
### > MD5

Notice that tripwire found a change in a vbseo sitemap file....

Now, if you were running tripwire, you could detect any file system change... Tripwire is free. Install it and protect your filesystem !

Prevention, detection, correction.......

There are also packages that incorporate all this stuff - grsec, tripwire, mod_security, mod_evasive, and hardened kernel - in one easy to install RPM repository; they can be used also by inexperienced people. AtomicRocketTurtle's stuff is great if you are on Plesk (but it is based on paid subscriptions), and I remember something similar for cPanel but I cannot remember the name.

Yes, I recommend tripwire regarding the file system because it is free.

Here is another example where I created a single file and tripwire found it:

Code:

-------------------------------------------------------------------------------
Rule Name: Apache Forum Files (/website/www)
Severity Level: 66
-------------------------------------------------------------------------------

Remove the "x" from the adjacent box to prevent updating the database
with the new values for this object.

Added:
[x] "/website/www/trip_test"

Modified:
[x] "/website/www"

So, if an attacker finds a vulnerability and exploit it, and they write to the file system, you can catch them quite easily.

We started out discussing prevention. Then, we moved to "detection"... I think I'll give it a rest and not talk about "correction".

The purpose of my posts were to inform that vB forum owners can protect against web server code vulnerabilities , and they should. There will surely be another vulnerability announced in the future. If you have good controls in place, the vulnerability is much less of a risk to you and your forums.

Over and out ....

It may sound obvious, but I have seen many doing otherwise.

With intrusion detection systems, it is also important that a copy of the DB is stored somewhere outside the server where the detection takes place. No point in having a detection system if somebody can gain access to the checksum DB

Wish I was a badass Russian hacker, oh well.

good thing this was all patched up now

Question is, how much downtime and loss of revenue will some vBseo clients experience?

Thanks for the updated patch

Great work Brian!!!!!!!!

Water under the bridge...

Originally Posted by NICEGUY77

Question is, how much downtime and loss of revenue will some vBseo clients experience?

Thanks for the updated patch

Great work Brian!!!!!!!!

Credit goes to Oleg for fixing it, not me.

Any idea of how many sites were hit and damage reports?

While several customers did get hit, the numbers that we know about (ie, reported to us/looking for help) is very small. It was reported to us in a timely fashion through proper channels, our developers worked on tracking it down and patching it, and we released the patches in a timely fashion.

I don't have any solid figures, nor would we ever say X forums got hit, but I'd put a rough guesstimate figure somewhere around .0001% of our customer base was effected on a serious level from this exploit. I'm sure there are many out there who have not patched/refuse to patch/haven't checked their email/etc, so i do expect to see a few more cases come in over the next few weeks.