Dangerous VBulletin Exploit In the Wild
An anonymous reader writes "vBulletin is a popular proprietary CMS that was recently reported to be vulnerable to an unspecified attack vector. Although vBulletin has not disclosed the root cause of the vulnerability or its impact, we determined the attacker's methods. The identified vulnerability allows an attacker to abuse the vBulletin configuration mechanism in order to create a secondary administrative account. Once the attacker creates the account, they will have full control over the exploited vBulletin application, and subsequently the supported site."
For the TL;DR crowd:
* Delete /core/install and /install directory in all 4.x and 5.x vBulletin installs or block access to same. Do it now.
Min
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
Did vBulletin change or something. I thought vBulletin was forum software, this states CMS. Or is CMS the preferred buzzword du jour?
Either way, this will mean more spam on lots of forums and more identity theft for those that use the same password for forums and bank accounts. Yawn.
When vBulletin itself suggests to remove all install directories after installing vBulletin, I'd put it down to lazy admins who can't be effed removing the said directories when advised to in the first place. Hence the "Be sure to delete the install directories, they are a security risk" disclaimer.
This is old news (2013-08-27) even by Slashdot's standards. Forums that were vulnerable have been probably all hacked (then fixed) already ;)
Deleting the install directory is a good idea for the install scripts to do.
There are two types of people in the world: Those who crave closure
Thought the exact same thing.
There are 2 of us....this is troubling.
Maybe, but what if something screws up? What if you want to test an installation setup and then try again? I don't know, you can't explain away incompetence of "admins," but you can argue some I guess. Most software developers would disagree with the notion of deleting the installer once install is complete - that's usually up to the user. You don't "make install" and the source code is gone, you don't install VLC and lose the DMG that it came on, you don't unzip and install forum software and then have no easy way to reinstall or fix a botched configuration.
So make a check box that the admin can 'remove installer files'.
This is relatively common for this type of software.
If you're going to warn the admins to remove the files, give them an automated way to do so.
There are two types of people in the world: Those who crave closure
and then you have the same problem you have now, they aren't going to check the "remove installer files" checkbox, and probably even uncheck it if it was defaulted to checked.
Our setup related scripts refuse to run if the software is already configured. Something like:
if ($config['basedir']) screwoff();
That's in case someone forgets to delete them.
People at work are always saying "the user is doing it wrong". They say that all the time because users do it wrong all the time. A guy named Murphy made it a law - if there's a wrong way to do it, someone will do it wrong. (That's the actual original Murphy's law.)
I'm constantly pointing out that yes, we KNOW that the users will do it wrong if we let them. We also know how to easily prevent those mistakes. Idiots exist, so idiot proof your software.