Hacker News new | comments | ask | show | jobs | submit login
Ubuntu forums hacked (ubuntuforums.org)
65 points by reinhardt on July 20, 2013 | hide | past | web | favorite | 56 comments



>The passwords are not stored in plain text. However, if you were using the same password as your Ubuntu Forums one on another service (such as email), you are strongly encouraged to change the password on the other service ASAP.

Translation: the passwords were stored using dumb MD5/SHA1. Seriously, it's 2013, why can't 99% of the web get their act together when it comes to password hashing?


Ubuntuforums used vBulletin, which as of 2006 used MD5 + salt: http://www.vbulletin.org/forum/showthread.php?t=178091

Not sure what vB is using today.


Eep. Even salted, MD5 is never the greatest idea.

http://security.stackexchange.com/questions/19906/is-md5-con...


I know developers who will to this day insist that salted md5 is practically invulnerable and more than adequate as long as the salt is big enough.


That's quite unfortunate. The size of the salt doesn't really matter much, so long as it can't be pre-computed before the DB leak. Once the DB is leaked, the salt could be a hundred characters and it wouldn't help much more than a ten character one.


That is very interesting, but at this late hour I'm having trouble understanding how the DB leak affects the effective salt length.

With apologies for asking, is there an ELIM (Explain Like It's Midnight) version?

(I did read the security.stackexchange.com question linked in the GP - is the answer in there and I missed it?)

Thanks!


Sure: You can try a few billion passwords per second on modern hardware. The salt gets prepended on every try, so it doesn't count towards the complexity, it only helps with not precomputimg lists of hashed passwords and just comparing. Therefore, no matter how long the salt is, you still can try the same billion passwords a second, and a seven-character password will still only take 26^7 to be brute-forced.

Also, the salts are stored unencrypted in the database, right next to the hashes.


Thanks! Between your explanation and ReidZB's, that really clarifies the issues involved. Much appreciated.


Sure. The purpose of a salt in password storage is to prevent the pre-computation of a gigantic rainbow table, which essentially acts as a lookup table. (Rainbow tables use less disk space in exchange for more time per lookup.)

Here, the salt only needs to be sufficiently long to make the rainbow table huge enough that it can't be computed in a timely or efficient fashion. So, a salt that's only a single printable ASCII character in length is rather short and probably insufficient; an attacker could build a rainbow table of the top X most common passwords (taken from previous leaked password lists) with every possible character as a salt and then use this against a leaked DB.

On the other hand, a massive salt doesn't help much in this phase either. A salt of fifteen characters is more than sufficient to prevent a rainbow table from including all possible salts, so there's not much of a point in using something ridiculous like a 100-char salt.

But once the DB is leaked, assuming a rainbow table is not feasible, an attacker instead will swap over to brute-force attacks (usually trying dictionary lookups first to find the very weakest passwords, then doing other techniques like trying common words with letters replaced with 1337 digits, and so on). Here, the attacker knows the salt (by virtue of the DB being leaked) and so the most important factor is how fast the attacker can try potential passwords. This is where MD5 breaks, of course; it's far too fast. An attacker with virtually no funding can test billions of passwords per seconds (on a GPU), and so a large Bitcoin GPU farm could be repurposed to crack salted MD5'd passwords at an extremely scary rate.

In fact, the block size of MD5 is 512 bits (64 bytes), so all strings with less than 64 bytes should take about the same time to hash. Thus, even a 40-byte salt with MD5 won't affect password cracking rates until the passwords hit 20 characters long, and a password that long is rarely cracked anyway. Even a 64-byte salt would only make the hashing take about twice as long, and when you're testing billions of passwords per second anyways, twice as long doesn't sound like much. (Actually, if you prepend the salt to the password, I can think of an attack where only the partial blocks at the end of the salt affect the brute-force attempt, which would make the salt's length not affect the cracking rate at all.)

So in sum, before the DB is leaked, the salt needs to have enough entropy to prevent pre-computing all possible salt values. Once the DB is leaked, the attacker doesn't much care about the salt length anymore because they know now all the salts used.


Thanks very much for the detailed explanation! That is very helpful - I think I understand the issue now, and hopefully other readers have a better understanding too.


still md5 w/ salt as of latest vb5


It's an opportunity to finally kill it off and stop polluting google results.


Personally, I've found a lot of useful stuff there in the past.


It's an opportunity to kill what off?


ubuntuforums.org, presumably.


Ubuntu.


This is how much effort it takes to have a BCrypt (strong, slow, salted hash) database user system in Spring (not that they used Spring):

  <http auto-config='true'>
    <intercept-url pattern="/**" access="ROLE_USER" />
  </http>

  <beans:bean class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder" id="passwordEncoder" />

  <authentication-manager>
    <authentication-provider>
        <jdbc-user-service data-source-ref="dataSource" />
        <password-encoder ref="passwordEncoder" />
    </authentication-provider>
  </authentication-manager>
StackExchange's AskUbuntu.com is pretty good, as you can use OpenId, and if someone (illegally) hacks Google we are all fucked anways.


That'd be the admin panel on their vbulletin installation which has been publicly facing for more than a year.


vBulletin is (and always has been) terribly insecure. Only way to beef up security is to lock down admin panels, e.g. IP-restrict them.


They are testing a discourse instance: http://ubuntu-discourse.org/

Since Discourse is fully open source under GPL v2 anyone can validate its security (or lack thereof) at will on GitHub. And it is not written in PHP.


vB's biggest problem is that it's a horribly convoluted rat's nest. If you've ever seen the actual code, you can see why it's just not possible to lockdown everything since there's so much legacy code that would break as a result.


To my knowledge, that's sadly true of any PHP based message board (phpBB, SMF, etc).


I think this is very much a cultural problem within the PHP community. phpBB in particular is notorious for its unsustainable code and I think I figured out the reasons.

There are better ways of doing things (despite PHP's inherent warts) that some other projects have used quite successfully, and more importantly sustainably, but there's a very long history of doing things "because that's just the way it's always been done" and I don't see that changing anytime soon, I'm afraid.

I mean if you look at some of the tutorials out there, a lot of it is just appalling in terms of maintainability, efficiency and security (and that includes some very popular frameworks). There are a lot of cases where short-term, and often short-sighted, convenience trumps long-term goals.


I can remember setting up a osCommerce site years ago, and the _official_ way of installing 'extensions' was literally to follow instructions telling you to open XYZ file and add this code at this line number, etc.


Sounds like a call to action to me. Sooner than later someone needs to make a PHP based forum that isn't crap.


I've yet to see a single, practical, simple end-to-end tutorial published for free (like the vast majority of the "rubbish" ones) that even uses SPL. Of course, I see snippets here and there of the iterator et al. But nothing comprehensive.

Forget a full on forum, if someone took the time to use best practices to build a MVC/P app as a reference, there would be plenty adopters. I don't mean something that "hides" work, I.E. A framework like Code Igniter. These just introduce more magic into code that doesn't actually teach the why and how.



There have been a number of attempts at that. Unfortunately, most of them seem to also try to solve the problems of "PHP based" and "forum".


I think XenForo uses bcrypt: http://xenforo.com/


Xenforo overall takes security more seriously than phpBB, vBulletin, and IPB, possibly because they don't have as much legacy cruft to worry about.

For instance, vBulletin knows about (and doesn't plan to fix) a vulnerability that allows any moderator to privilege escalate to take over a server (and steal passwords) under default settings. They don't consider it a big deal because moderators should be considered trusted users.

Unfortunately, it's significantly harder to ensure that every moderator won't get their password stolen than it is to ensure that every admin won't get their password stolen. Recently, @rootinabox exploited that (and possibly other vulnerabilities) to hack a bunch of Pokemon sites that were running vBulletin.


Can you expand on how it's terribly insecure? Curious.


Sorry for the late reply. There's no single reason for it being so insecure, but you don't need to search for long to find vulnerabilities.

I think the main problem comes from the fact that much of the code still resembles the spaghetti that was written over 10 years ago. Even recent versions have problems with basic input sanitization, which makes injection attacks really easy. Social engineering is also a massive problem: if you can phish an admin login, you can essentially take over the entire web server because the admin panel is just too powerful.


He can't.


So far they are handling this better than Apple.


ubuntuforums.org timing out as of now but are we sure this is a malicious attack and not simply downtime?

If it is an attack, it just means a time bandit for the admins I suppose...



That's awfully well laid out for a defacement page.


Elegant, minimalist, nice logo, nice typography. If I get owned, I want it to be by these guys.


Thanks to grandparent for posting. For a split second, I considered setting this as wallpaper on my laptop.

Then I remembered how much work this kind of prank generates for the system administrators.


It's finally happened, the penguins are fed up with the Linux caricatures.


I didn't take a screenshot, but I can confirm there was a message. Viewing my browser history, it apparently linked to this page: http://ubuntuforums.org/signaturepics/Sput.html

The top was a splash image that linked to this twitter account: https://twitter.com/Sputn1k_

Below was some text (scraped from Chrome's history database):

    Shoutout to @rootinabox.

    None of this "y3w g0t haxd by albani4 c3bir 4rmy" stuff.
    Straight up, you dun goofed. It's as simple as that.
@rootinabox linked to this page: http://wedtm.com/blog/2013/07/11/cubeworldforum-dot-org/


A few weeks back cubeworldforum.org was hacked (the forum referenced in that blog post) due to an administrator having their password compromised. The hacker replaced the index with a page with music and what not. From @Sputn1k on twitter it looks like he's the guy that hacked cubeworldforum.org too[1], so the wedtm.com link that @rootinabox went to is probably him just copying HTML he used last time and forgetting to correct the href.

[1] https://twitter.com/Sputn1k_/status/354362220727111681


God damnit, script kiddies like this really piss me off. I hope that Twitter has some sort of IP logging for logins so that they can at least start to attempt to catch this guy. He broke the law, and he should be charged as such.


I've been amused more than anything at the number of script kiddies that take to twitter to brag about their activities. They're painting a big fat target on the backs of their heads, convinced that they will never slip up and leak packets. Granted, if they truly are careful they won't get caught --at least not because of their twitter bragging. It just seems like an absolutely pointless risk to be taking.


I see this response in reference to how he may have done it:

---

@Sputn1k_ @CubeWorldForum It's a fairly easy "hack". You set your forum avatar to a remote site that actually serves up a meta redirect.

---


You set your forum avatar to a remote site that actually serves up a meta redirect.

That's... interesting. Like a php-generated image containing a redirect header, or a referrer check set up in .htaccess? I didn't know images were hackable like that, beyond just sending an alternative image for nonexistent referrers?

If anyone needed a good argument against blindly hotlinking to other sites' content I guess this would be it.


Can't access the site either, but I've just found this post on Google+ https://plus.google.com/103751102959761372959/posts/We8fexT5...


It was hacked, and Canonical IS cut it off from the outside to diagnose the issue.


Yes, aren't the forums run by a user named "Ubuntugeek" or something of the sort?


No. The forums are run by a community team of admins. The underlying infrastructure is managed by Canonical IS.


Could be a new kind of meta-ddos. Announce a site has been hacked on Reddit/HN, and the news about the hack becomes the hack. :D


So are they going to email their user base to warn them to change their passwords? I thought I had an account at some point and I didn't get an email.


aren't ubuntu forums based on http://moinmo.in?


No, our wiki is moin based. The forums are vbulletin.


Ah, thanks.





Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: