Drupal.org compromised

https://drupal.org/news/130529SecurityUpdate

by chaosmachine • 13 years ago

140 81 13 years ago

drupal.org

geerlingguy3• 13 years ago

> Malicious files were placed on association.drupal.org servers via a third-party application used by that site.

I wonder what 3rd party app this was...

Ecio782• 13 years ago

Me too..

sigzero• 13 years ago

Yup, I just got an email.

bluetooth2• 13 years ago

A copy of the email (slightly different from the notice on the site):

Easier to read: https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe

Dear community member,

We respect the privacy of your information, which is why, as a precautionary measure, we are writing to let you know about an incident that involves your personal information. The Drupal.org Security and Infrastructure Teams have discovered unauthorized access to account information on Drupal.org and groups.drupal.org. Information exposed includes usernames, email addresses, and country information, as well as hashed passwords. However, we are still investigating the incident and may learn about other types of information compromised, in which case we will notify you accordingly.

This unauthorized access was made via third-party software installed on the Drupal.org server infrastructure, and was not the result of a vulnerability within the Drupal software itself. This notice applies specifically to user account data stored on Drupal.org and groups.drupal.org, and not to sites running Drupal generally.

We have implemented additional security measures designed to prevent the recurrence of such an attack, and to protect the privacy of our community members.

The next time you attempt to log into your account, you will be required to create a new password.

Below are steps you can take to further protect your personal information online. We encourage you to take preventative measures now to help prevent and detect the misuse of your information.

First, we recommend as a precaution that you change or reset passwords on other sites where you may use similar passwords, even though all passwords on Drupal.org are stored salted and hashed. All Drupal.org passwords are both hashed and salted, although some older passwords on groups.drupal.org were not salted. To make your password stronger:

* Do not use passwords that are simple words or phrases * Never use the same password on multiple sites or services * Use different types of characters in your password (uppercase letters, lowercase letters, numbers, and symbols).

Second, be cautious if you receive emails asking for your personal information and be on the lookout for unwanted spam. It is not our practice to request personal information by email. Also, beware of emails that threaten to close your account if you do not take the "immediate action" of providing personal information.

For more information, please review the security announcement and FAQ at https://drupal.org/news/130529SecurityUpdate. If you find any reason to believe that your information has been accessed by someone other than yourself, please contact the Drupal Association immediately, by sending an email to password@association.drupal.org.

We regret that this incident has occurred and want to assure you we are working hard to improve security.

Thank you, Holly Ross Drupal Association Executive Director

sergiotapia• 13 years ago

Easier to read: https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe

bluetooth2• 13 years ago

Thanks. I'll put that link in my comment.

gketuma• 13 years ago

for a minute i thought i will have to go check all modules downloaded or something like what happened to the rails gem repository. At this point they don't know yet, but hopefully it does not boil down to that.

danielhunt3• 13 years ago

I don't know if they've invalidated my password, or if the attacker has already accessed my account, but I can't login with my details.

I can't help but think that they would be better off just doing an UPDATE users SET password='';, and relying on the forgot-password functionality to let users get access again

edit I received my forgot-password email after 4-5 minutes waiting (their servers are under quite a bit of stress right now .. understandably) Once I was logged in via the forgot-password link, everything was quite snappy. Just give it a few minutes and it'll reach you too, then you can reset your password to something random. (I can't recomment 1Password[1] enough)

[1] https://agilebits.com/onepassword

pstinnett• 13 years ago

Also not able to login. I ran the forgot password functionality but their FAQ says it could take up to 15 min. to receive the email.

danielhunt3• 13 years ago

It took me about 4 minutes to receive the email - once I got it, the servers were quite responsive. Just give it a few minutes ... it'll get to you eventually

geerlingguy3• 13 years ago

I think they already reset all passwords, because I'm in the same boat. I put in a reset request, which was accepted, but didn't yet get the email with the reset link.

I'm guessing whatever mailing queue they have set up is completely back logged right now until it finishes sending out the general account compromise email (displayed elsewhere in this thread). At least, that's my best guess. I haven't gotten that email yet.

specto2• 13 years ago

Same here, I know I used one of three passwords, and I'd like to know which one I stupidly used.

danielhunt3• 13 years ago

I linked to this in my edit, but it's worth re-linking here: https://agilebits.com/onepassword

Use it. And never look back :)

specto2• 13 years ago

I much prefer lastpass, and keepass for everything else.

jtolj• 13 years ago

Ditto. I'm unable to login with my credentials, and have yet to receive the password reset I requested (although I assume they are getting a lot of those right now, so it may be queued). All these compromises sure are getting tiring. I've already been hit with Evernote, LivingSocial and Linode so far this year (that I'm aware of).

HiddenIncome3• 13 years ago

Your password was scrambled, which is why you cannot login.

> UPDATE users SET password='';

That would be an extremely bad idea. Never set pass to empty on Drupal 6 sites.

_jmar7773• 13 years ago

Moderately miffed that the email they sent out notifying how THEY allowed my password to be compromised included a lecture telling ME how to construct a strong password. Not the time, or place.

Besides, they claim it was salted, so it shouldn't really matter at this point whether my password was "Password123" or "@DJDF*$@!(DGEWGIRGHdfhEWROighMMMM...PIZZA".

itafroma5• 13 years ago

> Besides, they claim it was salted, so it shouldn't really matter at this point whether my password was "Password123" or "@DJDF*$@!(DGEWGIRGHdfhEWROighMMMM...PIZZA".

Salting a hash isn't a license to use incredibly weak dictionary passwords like "Password123". All it does is prevent against rainbow table attacks, where an attacker uses a pre-computed list of password-to-hash combinations to determine if you used one of them, and slightly slowing down a brute force attack. Due to the speed of brute force attacks these days, rainbow tables aren't really in vogue anymore anyway, so it winds up only buying a bit of time.

Ars Technica had a recent story about this: http://arstechnica.com/security/2013/05/how-crackers-make-mi...

_jmar7773• 13 years ago

> Salting a hash isn't a license to use incredibly weak dictionary passwords like "Password123"

Agreed.

> All it does it prevent against rainbow table attacks

Salts do prevent rainbow attacks, but they also assist in brute force attacks. The article you reference was over passwords that had simply been MD5 hashed, which is about as computationally significant as doing nothing at all these days . Even in the ridiculous case of using MD5 for hashing, though, a 16 byte salt raises the cost of brute forcing a password substantially.

My point isn't that strong passwords aren't important, it's that if the salt + hash procedure that was used is adequate, then the strength of any individual password becomes insignificant in relation to the strength of the password + salt. (Well, my real point was just to vent, but anyway...)

mjpa• 13 years ago

I'm not convinced by their salted claim, I thought Drupal 6 (what drupal.org is on) only did MD5() for passwords? Drupal 7 has the more securely hashed passwords.

HiddenIncome3• 13 years ago

Drupal.org runs D6 with the phpass module, basically the stuff that went into Drupal 7.

lotyrin• 13 years ago

They don't seem to mention this, but I'd say everyone that uses d.o git repos should definitely verify their set of authorized keys.

itafroma5• 13 years ago

Definitely, as well as check your repos for malicious code. Unlike GitHub, Drupal doesn't send out a notification when a key is added, edited, or removed.

bengrunfeld2• 13 years ago

And that's why you go with Wordpress...

pgrote• 13 years ago

Why?

Jgrubb3• 13 years ago

Because Wordpress has the most secure codez.

itafroma5• 13 years ago

According to the email (emphasis mine):

> This unauthorized access was made via third-party software installed on the Drupal.org server infrastructure, and was not the result of a vulnerability within the Drupal software itself.

There is ostensibly an argument to the effect of "well if they can't secure their infrastructure, maybe I can't trust them to secure the product code", but the Drupal infrastructure team is separate from the core maintainers and contributors. Your choice of CMS/CMF would've had precious little to do with this compromise.

bengrunfeld2• 13 years ago

Just my luck that a group of Drupal enthusiasts came upon my comment...

LeeHunter• 13 years ago

Oh really? http://techcrunch.com/2011/06/21/wordpress-org-possibly-hack...

Aldipower• 13 years ago

Drupal is at first a CMS and WordPress is at first a blogsystem. You can not really compare them in the full spectrum of possible sites.

bigiain2• 13 years ago

The difference there is becoming vanishingly small. There are _many many_ sites out there using WordPress as a straight CMS with no blog-like functionality.

I've used and deployed both - if I'd _ever_ been able to get one single client to understand the power of Drupal's taxonomies, I'd be developing and deploying Drupal sites everywhere. As it turns out for me, clients are _much_ happier with WordPress's backend/ecosystem/documentation.

r0s3• 13 years ago

You can save the patient by removing the brain, but this impedes potential.

biot2• 13 years ago

Drupal.org compromised. If I visit drupal.org, will I experience the compromise firsthand via some zero-day exploit? A situation like this really calls for an independent site to make security-related announcements from where you can reasonably trust the independent site to not have been affected.

gregknaddison3• 13 years ago

The site isn't being used to distribute an exploit. There were problems in the past and the page linked in this story describes what happened and what members of drupal.org should do to protect themselves.

biot2• 13 years ago

I didn't make my point very clearly, and I think it can be summed up with an offline analogy: "Toxic nerve gas spill in Disneyland. To learn more, visit the Information kiosk inside Disneyland."

callahad• 13 years ago

FWIW, a member of the Drupal community has made a pretty sweet Drupal / Mozilla Persona module (http://see.drupalpersona.me/), if you run a Drupal site and don't want to store password-derived data in your database at all.

HiddenIncome3• 13 years ago

Not saying that 2factor / persona auth modules aren't the eventual way forward, but the worst thing to do is to run out and do something like adding modules to your site. Installing modules that have any relation to authentication or security should be postponed until a careful review of the code and its consequences can be completed.

Ecio782• 13 years ago

While changing my password:

Drupal.org Site off-line The site is currently not available due to technical problems. Please try again later. Thank you for your understanding.

It looks like they are making some update...

kurtfunai2• 13 years ago

This is one of those cases where I completely forgot that I had an account, and now it has been compromised. I'm scratching my head wondering what information/password I had associated with it.

Makes a case for actively destroying accounts on services that you're no longer planning on using.

jdunck• 13 years ago

Or not sharing passwords between services.

kurtfunai2• 13 years ago

You're right, though I don't share passwords between services, I'm curious just the same.

sdfjkl• 13 years ago

Preferably both. Not sharing passwords is the obvious one, but if I stop using something I'd like to be able to delete everything related to me (except perhaps logfiles or whatever else needs to be retained for operational reasons up to a few weeks). And without having to call someone on the phone please or email support@ please.

blindhippo• 13 years ago

Or getting rid of passwords as a mechanism entirely.

Not that I have a solution, just whining :)

danso• 13 years ago

According to the OP, the compromise happened because of malicious software being placed onto association.drupal.org via a third party app used by that subdomain, and not because of a vulnerability in Drupal itself.

So...it'd be nice to know the details of what this third party app was and also, some basic details of the configuration of association.drupal.org. Not anything specific, but rather, how is the subdomain stack different than the one used on drupal.org?

gregknaddison3• 13 years ago

Definitely. We've been doing a ton of investigation into the issue and are trying to get all the details right before we make a detailed technical post. There are already some issues in the queues of some modules and patches committed to others that would help prevent this kind of problem in the future on drupal.org and other sites. We basically got to a point where we wanted to let users know their information had been compromised before we got to the point where we're satisfied with the details of the attack to be able to fully share what happened in the attack. There will be at least one more technical followup in the future and possibly more. Those followups will get into more details of the class of problem we faced and what we think can be learned from the event.

jkbyc3• 13 years ago

I hate when a site doesn't let me delete my account. Apparently, drupal.org hasn't been able to implement this feature in more than 11 years already:

https://drupal.org/node/8

itafroma5• 13 years ago

> https://drupal.org/node/8

While it was a long running thing that the Drupal product couldn't let users delete or disable their own accounts, the issue you linked was resolved[1] in 2009 (more than 4 years ago) and made it into Drupal 7.

Unfortunately, Drupal.org is still running on Drupal 6 and its upgrade to Drupal 7 has been met with repeated setbacks and delays[2] with no ETA[3]. Definitely unfortunate.

Edit: looks like they're accepting requests for account deletion via password@association.drupal.org for the time being.[4]

[1] https://drupal.org/node/8#comment-1188824

[2] https://association.drupal.org/node/17738

[3] https://association.drupal.org/comment/4263#comment-4263

[4] https://drupal.org/news/130529SecurityUpdate#comment-7475090

jacquesm2• 13 years ago

> Unfortunately, Drupal.org is still running on Drupal 6 and its upgrade to Drupal 7 has been met with repeated setbacks and delays[2] with no ETA[3].

In a nutshell, that line sums up everything that's wrong with drupal.

calebgilbert• 13 years ago

One can't delete their account on Hacker News either. Just sayin'. :p

jkbyc3• 13 years ago

Interesting, I didn't know. Is there some good reason for it?

reinhardt• 13 years ago

If only it was just Drupal. I went through the ~80 or so accounts I have logged in LastPass, including many I haven't used more than once, and the sites that allow deleting your account are a small minority. It is annoying to say the least and hold me back from opening any new accounts unless I'm pretty sure I'll use them.

jarek-foksa• 13 years ago

  - Do not use passwords that are simple words or phrases
  - Use different types of characters in your password (uppercase
    letters, lowercase letters, numbers, and symbols).

http://xkcd.com/936/

r0s3• 13 years ago

http://arstechnica.com/security/2013/05/how-crackers-make-mi...

6cxs2hd62• 13 years ago

I have a genuine not rhetorical question.

Use brcypt: http://codahale.com/how-to-safely-store-a-password/

Am I correct that this advice wasn't obvious in the early years of Drupal.org?

If so, what ought a site like Drupal.org do, today? Should they update the password storage to use bcrypt, and require all users to update their passwords? i.e. Proactively do in a constructive way, what they'd otherwise need to do in a crisis mode?

If so, why don't more sites do this? Is it ignorance? Inertia? Or concern that they'll lose users who can't be bothered?

mambodog• 13 years ago

When moving from a weak password hashing scheme to a stronger one you can keep old passwords around and just hash them again with the new system (that is, run your existing hashes through your new hashing function), and mark them as using the twice-hashed scheme. Your password comparison function can have a special case to use the twice-hashed scheme when comparing passwords on login. Users are migrated to the new scheme upon updating their password.

This is the approach which Drupal supports for migrating from Drupal 6 (which uses unsalted MD5) to Drupal 7 (salted SHA-512).

6cxs2hd62• 13 years ago

So if I understand correctly, they could use the same approach when updating to do what they really ought to -- use bcrpyt?

As a result the very oldest pwds would be thrice encoded -- from unsalted MD5 to salted SHA-512, and run that through bcrpyt?

MikeKusold• 13 years ago

I did some very light digging, and I found out that Drupal uses a stripped down version of PHPass.

"A cut-down and reworked version of phpass (supporting the portable hashes only and requiring PHP 5+) has been integrated into development versions of Drupal leading to the Drupal 7 release, after a lengthy discussion and many proposed patches against various development versions of Drupal. There's a notion of upgraded hashes - these are phpass portable hashes of md5() hashes (which were used by older versions of Drupal), with the final hash encodings prefixed with a "U" (for "upgraded"). A more recent lengthy discussion has resulted in Drupal 7 switching from MD5 to SHA-512 for the underlying cryptographic primitive in phpass' "portable" hashes (making them less portable) while preserving "read-only" support for the MD5-based portable hashes. There was no valid technical nor security reason for this change, so it was made purely for "political" reasons. Drupal 7's SHA-512 based phpass-like hash encoding strings use "$S$" as the hash type identifier.

There's also a module for Drupal 5 & 6 that makes the original phpass available with those versions of Drupal, including support for the more secure but not nearly as portable CRYPT_BLOWFISH and CRYPT_EXT_DES hashes."

SOURCE: http://www.openwall.com/phpass/

While MD5 is insufficient, SHA-512 (default D7) and CRYPT_BLOWFISH offer very good alternatives. Overall, from my understanding, the biggest issue with Drupal is websites that are either running an old version, or used to run an old version but never forced users to reset their password.

chx• 13 years ago

I am surprised noone mentioned Supergenpass. It was a bookmarklet originally but now there are browser extensions, mobile apps, a HTML+JS page you can store locally. It takes a master password which never leaves your machine and generates a hash based on the master password and the domain. Makes it superb easy to not share passwords and yet be able to log in on any computer.

easy_rider• 13 years ago

I don't get why passwords are still not salted 100% of the time at these higher profile OS vendors. I was working on a clients Wordpress. And i never really touch it. To my amazement i found out I could simply md5 (new password) inside the users table to change my forgotten user pass. Wtf?

Otto42• 13 years ago

This is for backwards compatibility. If you checked it again after you login, you'd find that it is not an MD5 password anymore.

WordPress uses salted and hashed passwords with the phpass library, and has since version 2.5, released in 2008. Prior to that, it used MD5 passwords.

As part of the conversion process, it detects an MD5 password in the database on login, and then hashes the password to the newer salted mechanism, overwriting the MD5 version in the database.

Drupal.org compromised

Related Stories