

Drupal.org compromised - chaosmachine
https://drupal.org/news/130529SecurityUpdate

======
bluetooth
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
Easier to read: <https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe>

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

------
danielhunt
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>

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

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

Use it. And never look back :)

------
jarek-foksa

      - 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/>

~~~
r0s
[http://arstechnica.com/security/2013/05/how-crackers-make-
mi...](http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-
out-of-your-passwords/3/)

------
6cxs2hd6
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
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).

~~~
6cxs2hd6
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
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.

------
jkbyc
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>

~~~
itafroma
> <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>

~~~
jacquesm
> 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.

~~~
Jgrubb
Respectfully, there are vastly better examples of "everything that's wrong
with Drupal".

An unwillingness to push through an upgrade to a site containing millions of
user accounts and tens of millions of pages of content before it's ready is,
to me, an example of what's right with Drupal.

------
geerlingguy
> 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...

~~~
Ecio78
Me too..

------
kurtfunai
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
Or not sharing passwords between services.

~~~
blindhippo
Or getting rid of passwords as a mechanism entirely.

Not that I have a solution, just whining :)

~~~
StavrosK
Mozilla Persona, I will suggest.

------
_jmar777
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".

~~~
mjpa
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.

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

------
callahad
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.

~~~
HiddenIncome
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.

------
chx
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.

------
biot
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.

~~~
gregknaddison
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.

~~~
biot
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."

~~~
gregknaddison
You made your point, but I blame the ambiguity on an overly brief title and no
context in the original HN post. If the title said "User information on
Drupal.org compromised" that would be more accurate and let you know that you
probably don't have to worry about a browser-attack-zero-day. And, of course,
if you're the kind of person who worries about a browser-attack-zero-day
you're probably also the kind of person who has a Virtual Machine running a
guest Tails linux with no plugins and javascript disabled so that you can
visit sites like this without worrying.

Going back to your Disneyland scenario, a closer analogy might be "An attacker
stole souvenir photos of visitors to Disneyland. To learn more, visit the
information kiosk at the front entrance of Disneyland." I say photo because
it's something somewhat private (like a hashed password) and I moved the kiosk
to the front door of disneyland (i.e. outside of where new photos are taken)
because people who want to learn more don't have to set a new password on
Drupal.org.

------
lotyrin
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.

~~~
itafroma
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.

------
danso
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?

~~~
gregknaddison
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.

------
easy_rider
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
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.

------
Ecio78
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...

------
gketuma
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.

------
sigzero
Yup, I just got an email.

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

~~~
itafroma
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.

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

