Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security Bug

35,000 vBulletin Sites Have Already Been Exploited By Week Old Hole 91

realized writes "Last week Slashdot covered a new vBulletin exploit. Apparently hackers have been busy since then because according to security firm Imperva, more than 35,000 sites were recently hacked via this vulnerability. The sad part about this is that it could have all been avoided if the administrator of the websites just removed the /install and/or /core/install folders – something that you would think the installer should do on its own." Web applications that have write access to directories they then load code from have always seemed a bit iffy to me (wp-content anyone?)
This discussion has been archived. No new comments can be posted.

35,000 vBulletin Sites Have Already Been Exploited By Week Old Hole

Comments Filter:
  • by Anonymous Coward on Wednesday October 16, 2013 @10:58AM (#45143219)

    Months old by the rest of the internet...

  • by Anonymous Coward

    How many abandoned forums overran by spambots are there out there? Quite a lot I reckon, this isn't surprising at all.

    • by Anonymous Coward

      Not many vBulletin ones I'd wager, since it's paid software. Plenty of phpBB ones and the like, though.

  • Right-o (Score:3, Interesting)

    by Anonymous Coward on Wednesday October 16, 2013 @11:04AM (#45143289)

    I just switched from using conventional passwords to 20+ character random strings and manage them with KeePassX. It took 3+ hours to go through all my 50+ different somewhat important accounts, but no way I'm using same passwords on different sites anymore.

    There have already been 5 serious leaks in services I use, including Adobe and my dedicated server provider.

    • Re:Right-o (Score:5, Interesting)

      by firex726 ( 1188453 ) on Wednesday October 16, 2013 @11:12AM (#45143361)

      Yea, it seems like I am getting an email monthly from one site or another I use telling me they were compromised and to change my passwords.

      • Yea, it seems like I am getting an email monthly from one site or another I use telling me they were compromised and to change my passwords.

        ...usually phrased like "Hi 'YOUR_USERNAME'. Your password, 'FOOLMETWICE', might have been compromised. Click here to change it.".

        The password manager I use has a "security audit" tab that lists sites using the same password, and passwords that I haven't changed in more than a few months, a year, or several years. I fixed all the dupes by giving them each unique passwords, and I have a monthly reminder to myself to update all the old ones.

    • Re:Right-o (Score:5, Interesting)

      by Archangel Michael ( 180766 ) on Wednesday October 16, 2013 @11:19AM (#45143443) Journal

      Personally, I start with the premise that the sites are already insecure. From there, I only provide information needed. I also create a unique email address for each site, so that if they are compromised, only my account on that site is compromised and nothing else is at risk. My private email address remains only for personal communication.

      To compromise my life would require the NSA, and I already figure that has happened, but that I am not interesting enough to act on it .... yet.

      • I don't sweat that so much. My personal email is right there above this message, after all. Good luck guessing my random as-strong-as-allowed password on any given site, though.

    • by smash ( 1351 )
      I did this exact thing when the PSN hack happened.
    • I did this too. It's nice not having to remember passwords anymore. I just keep my database and key backed up, and have a lot less "what was this password again" troubles.
  • A bit iffy??? (Score:5, Insightful)

    by NoNonAlphaCharsHere ( 2201864 ) on Wednesday October 16, 2013 @11:12AM (#45143359)

    Web applications that have write access to directories they then load code from have always seemed a bit iffy to me

    You misspelled "batshit-insane".

    • You misspelled "Cold Fusion".

    • Web applications that have write access to directories they then load code from have always seemed a bit iffy to me

      You misspelled "batshit-insane".

      By itself, that's not batshit-insane. Any web app that supports a user-friendly installation of plugins has to do that (Wordpress, Joomla!, ... ). If it only fetches plugins from its own, managed repository, it can be secure.

      But please, suggest a user-friendly alternative.

      • by Dracos ( 107777 )

        Yes, it very much is batshit-insane. To allow such a thing is to put an inordinate amount of trust in your web application and your http server, both of which should be considered insecure no matter how secure you think they are. WP goes one step further and allows its plugins to be edited from the admin interface, which is batshit-donkeyfuck-insane.

        There is always a trade off between security and user friendliness... these anti-features cross the line so far that they've disappeared beyond the horizon.

        • What would be the alternative though? Is it possible to have the same functionality in a secure way? If my application needs to write to certain directories, and that is not an option or else the application would be useless, then how can those directories be protected? Any CMS that needs to upload images, for example, would be affected by that, right? It can be fairly trivial to protect in that case (put the upload directory outside of the web root and just return the file data), but what about an appl

          • I should clarify in case this is the first reponse:

            we already route all requests for files in the upload directory to a PHP script via htaccess to authenticate users before they can access the file, and there is also an option in the application whether or not to allow PHP execution in that directory (if disabled, it returns the file contents instead of including and executing the file).

            Is that all that is necessary?

          • by Dracos ( 107777 )

            Uploading images or other files that will not be executed by the CMS is not the issue here. The ability to upload modules and plugins is a much greater risk. Being able to delete those things (as granted by write permission) can render the entire CMS inoperable. The further insanity of allowing code to be editable within the CMS is even more dangerous, as that can introduce simple breakage via a syntax error and be a good place for malicious code to hide, easily placed there by a compromised CMS account.

          • What would be the alternative though? Is it possible to have the same functionality in a secure way?

            You'd have a separate site for maintenance. This does sort of mandate some duplication of effort. Right now if you want to update your CMS core you have to do this through a shell, file manager, or ftp in most cases as it is. It's not a big stretch to have an admin site with its own codebase sufficient for performing updates. Content management etc would continue to be performed through the CMS as normal. You might or might not want to use the same auth tables.

    • Re:A bit iffy??? (Score:5, Interesting)

      by Bigbutt ( 65939 ) on Wednesday October 16, 2013 @11:53AM (#45143815) Homepage Journal

      First thing I did with my Wordpress site was check the 'net for suggestions on how to secure the site. I've blocked off the admin access areas through the httpd.conf file restricting it to my work and home IPs. I occasionally have to update the IP when my home dhcp address changes but it works fine for what I'm doing.

      [John]

      • I've found quite a few plugins to help secure WordPress. One of the ones I really like is Apocalypse Meow [wordpress.org]. This locks people out from even trying to log into your site after X attempts. (You define what X is but it defaults to 5.) If they go over the attempts, they get banned from trying to log in for a day (or however long you define). It also removes the WordPress version information from your site's HTML code which has no purpose except to tell hackers "try these methods to get into my website". It

  • Why Only Now? (Score:5, Interesting)

    by terrab0t ( 559047 ) on Wednesday October 16, 2013 @11:16AM (#45143407)

    If you watch your server access logs, you will regularly see bots checking for common install URLs of popular website software. I'm blown away that vBulletin's hasn't been targeted for years.

    • Re:Why Only Now? (Score:5, Interesting)

      by moteyalpha ( 1228680 ) on Wednesday October 16, 2013 @12:17PM (#45144103) Homepage Journal

      If you watch your server access logs, you will regularly see bots checking for common install URLs of popular website software. I'm blown away that vBulletin's hasn't been targeted for years.

      You are absolutely right. I was shocked at how quickly the knocking began. Within a day of registering a new address it already had obvious attempts to find a hole. The logs also show many other things that would worry people IF they knew it was happening. Very few people have the experience and skills to deal with it. It seems obvious that the intruder has the advantage. In a system with more than 2 to the 64th directions to guard against, the attacker has the advantage of surprise.
      Analogy: Open field, everybody has a gun, some have food, others want it.
      It could be that the only way to win is not to play at all. The problem is that the game has already started and this is no longer a choice. There is a dominant strategy. It is a conflict of interests. It is thus "Bellum Omnium contra omnes". No way to tell how it will end, but everybod has a "shot". ;)

    • by Cramer ( 69040 )

      I'm blown away that vBulletin's hasn't been targeted for years.

      IT HAS! This bullshit comes up every few years. All because people are too stupid and lazy to follow the instructions and remove the f'ing installer when done.

  • by thevirtualcat ( 1071504 ) on Wednesday October 16, 2013 @02:46PM (#45145897)

    I've used vBulletin for years. While it's never had a particularly stellar security record, it has only gone down hill since Internet Brands bought Jelsoft.

    The only remotely secure way to run vBulletin these days is to stick it in its own php-fpm pool with its own user account and insure that all files are 440 and all directories are 550. The upload directories (customavatar, attachment, etc) need to be 770 and then be excluded from PHP execution in your httpd config. Deleting "install/" goes without saying. (And we have it behind a Basic Auth, just in case someone forgets.)

    Even today, with that fairly verbose nginx config and a fully patched and up to date vBulletin, I still find delightful files in my upload directories like "r00t.php" and "shell.php".

    Oh? You're on shared hosting? Good luck with that...

    • Oh? You're on shared hosting? Good luck with that...

      Well, I wasn't on shared hosting...but then I installed vBulletin - ZING!

  • by pjrc ( 134994 ) <paul@pjrc.com> on Wednesday October 16, 2013 @03:13PM (#45146109) Homepage Journal

    My site uses vBulletin.

    This vulnerability is MUCH older than the 1 week mentioned in Slashdot's summary.

    Several weeks ago the vBulletin folks sent an email advisory to all registered users (eg, people who actually paid for the software) . In fact, they sent 2 messages. The first warned of this vulnerability and suggested immediately deleting the install folder, if it wasn't already deleted as recommeded. The 2nd message, only a couple days later announced a new version which fixed this bug, even if the install folder was not deleted.

    vBulletin has a web-based admin control interface, separate from the main forum. Even in the old, vulnerable versions, the admin section will not work if the install folder still exists. It just displays a message saying you must deleted the install folder before you're allowed admin access to your own forum. Any sites that were vulnerable to this bot must have been set up by just unpacking the zip file and then running the wizard to set up the database. It specifically tells you to delete the install folder at the end of that process. So anyone who got hit not only ignored that instruction, but also never even used the admin section of their forum, because it's intentionally disabled to force people to properly delete the install folder.

    Sure, there may be 30-some thousand forums out there with this problem, but every single one of them was set up so poorly that the forum owner never even accessed their admin interface.

  • Can someone please post a couple of links to show what the software looks like on a site. I have no idea what the typical layout and default look and feel is like.
  • I always assume that it's pretty standard practice to delete any /install folder. I mean seriously.. Not only are you keeping your installation tidy but obviously it prevents anyone from re-running any install scripts. So it either comes down to people being lazy or just not knowing. I forget how many "webmasters" or "developers" are out there that don't even know the basics. As sort of an argument point spin-off, better software has led to less hands on deployment and made it easier for more people to dep
  • by lapm ( 750202 )
    Sadly most people that install forum software of any type, just don't follow security bulletins, or read install instructions properly anyways. Damn computer amateurs...

E = MC ** 2 +- 3db

Working...