Another day, another data breach:
Full news on the GTAGaming breach is here: https://t.co/KuNSuol442 (vBulletin again)
— Troy Hunt (@troyhunt) August 23, 2016
Yesterday it was a different one:
vBulletin… “Epic Games: Information Regarding Recent Forum Compromise” https://t.co/YqQlSRbtLU
— Troy Hunt (@troyhunt) August 23, 2016
A couple of weeks ago it was this one:
vBulletin… again https://t.co/dNBbuzRHbW
— Troy Hunt (@troyhunt) August 10, 2016
A little before that there was this:
In news that should surprise absolutely nobody, Disney’s hacked forum software was running on vBulletin https://t.co/s6Uw4xXyl0
— Troy Hunt (@troyhunt) July 30, 2016
A fortnight earlier:
In the year’s least surprising news, the Ubuntu forums breach was due to a SQL injection risk in vBulletin https://t.co/v5uoa9MhJB
— Troy Hunt (@troyhunt) July 17, 2016
And it goes on and on and on beyond which any of you really want to sit here and read through in entirety. Clearly, there is a problem with sites hosting vBulletin getting hacked, but I’m not here to say “the entire problem is vBulletin”. Let me explain.
<meta name="generator" content="vBulletin 3.8.7" />
Now let’s be clear about the genre of this edition of vBulletin; version 3 launched in March 2004 and in case you can’t quite remember that far back, there was no Facebook. Well there kinda was, but it wasn’t public as Zuck had only just kicked off the coding and it wasn’t yet even Facebook, it was “Thefacebook”:
A lot of water went under the bridge thereafter and almost 7 years later, version 3.8.7 of vBulletin hit. That was more than 5 years ago and a number of subsequent updates followed:
But even whilst maintaining vBulletin 3 with minor releases, things moved on well beyond this. In December 2009 there was “an extensive rewrite” which brought version 4 and then in February 2013, version 5 arrived. When GTAGaming was hacked, they were two major releases behind the current generation and four and a half years behind in their patches for the major version they were running. And this is the real story with vBulletin – installations going unloved.
When you look at the history of vBulletin sites being hacked, it’s rarely 0-day vulnerabilities so we’re usually not looking at an attack and saying “Wow, we’ve never seen that before!”. Of course this does sometimes happen but vBulletin issues patches, people take them then we all move on. In theory. But in all seriousness, the next time you see vBulletin in the press, take a look at the version number of the site in question and see just how out of date it was.
But let’s take a step back for a moment and stop talking about vBulletin specifically. Managing a software product is like having children; they need constant care and attention and if you neglect them, bad things tend to happen. Let me give you an example from a couple of years ago that beautifully illustrates the problem:
Back in October 2014, Drupal had a little issue. Ok, a big issue in that a SQL injection vector was discovered and it was now “highly critical” that anyone running it patch their things. Urgently (emphasis mine):
You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.
So basically, you go to bed one night and all your Drupal things are cool. You have a full night’s sleep, you get up the next morning and now you’ve gotta assume that all your Drupals have been pwned during the night. Discovering how to exploit the risk is trivial too, in fact you can find attacks published in multiple places both in shadier corners of the web and via the likes of Exploit Database:
Discovering sites running a product like Drupal 7 is then a simple Shodan search away:
There’s over 52k easily discoverable sites in one go because as with many frameworks, Drupal likes to shout about its presence via response headers. The point being that going from a vulnerability being announced to discovering an exploit to finding sites at risk is a trivial series of steps. There are groups of individuals actively doing just this against vBulletin forums right now because it’s such easy pickings.
But here’s the crux of all this and what I alluded to in the title of this post: When you’re managing your own installation of a software product, you’re entirely responsible for patching it. Quickly! Whether it’s vBulletin or Drupal or any other product on any other technology stack, the same thing applies. However, if you’re not responsible for managing it, things suddenly get a whole lot easier.
Earlier this year I relaunched this blog on a brand new platform. It all runs on Ghost Pro which is the managed version of their excellent blogging platform. Some people were aghast: “Dude, you can totally manage your entire blog yourself, why would you pay someone to do it?!”. I explain it more in the launch blog post but in short, I just don’t want the responsibility. I’ve never patched it, I’ve never had to fix outages (there’s been some, but I didn’t have to fix them), I’ve never had to scale it out and I’ve never had to worry about all the sorts of things that you should worry about when you’re the one responsible for managing the product.
Which brings me back to vBulletin. You can go and get vBulletin Cloud right now for just $15/m. That’ll only get you 25GB of bandwidth so you wrap CloudFlare around it and serve 7 times the amount for free (CloudFlare stats for troyhunt.com show 86% of the bandwidth being served from their cache). Yes, you can go and get a Digital Ocean Droplet for $5/m but c’mon, we’re talking $10/m the difference here – 33 cents a day! If you’re really at the point where you can’t justify 33 cents a day then I’m sorry, but you just shouldn’t be in a position where you’re responsible for other people’s sensitive personal information.
This is a critical fact that people self-managing vBulletin (or any system, for that matter) neglect: When you stand up that cheap forum for a bit of fun and thousands of people register, you’re now responsible their Gmail, Facebook and banking credentials. Let that sink in for a moment… We’ve known about this for years and we’ve also known about how weak vBulletin password hashing can be. Yes, people will exercise poor password management and they’ll reuse credentials everywhere but when you’re responsible for an old vBulletin installation you’ve neglected to patch, it’s your negligence that allows malicious parties to exploit the negligence of those who signed up to your site.
If you’re managing your own installation of vBulletin, you almost certainly shouldn’t be. And as for GTAGaming, their fate following the attack has been sealed:
We have now closed the forums permanently
Don’t be another vBulletin statistic, hand over the management of the site to them and focus on running a successful community instead.