×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Drupal.org User Accounts Compromised

samzenpus posted about a year ago | from the protect-ya-neck dept.

Security 60

An anonymous reader writes "The Drupal.org team released a bulletin this evening notifying users of a breach in their infrastructure. From the bulletin: 'The Drupal.org Security Team and Infrastructure Team has discovered unauthorized access to account information on Drupal.org and groups.drupal.org. This access was accomplished via third-party software installed on the Drupal.org server infrastructure, and was not the result of a vulnerability within Drupal itself. This notice applies specifically to user account data stored on Drupal.org and groups.drupal.org, and not to sites running Drupal generally. Information exposed includes usernames, email addresses, and country information, as well as hashed passwords... All Drupal.org passwords are both hashed and salted, although some older passwords on some subsites were not salted.' Users are encouraged to update their Drupal.org passwords and the passwords of any accounts that could be linked via the compromised information."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

60 comments

vulnerability fatigue (-1, Troll)

Anonymous Coward | about a year ago | (#43855863)

Anyone else sick to death of Drupal-related security issues?

Re:vulnerability fatigue (-1)

Anonymous Coward | about a year ago | (#43856181)

But open sores software is more secure because of the many eyes reading duh codez. This was clearly Microsoft's fault.

Re:vulnerability fatigue (2)

SplatMan_DK (1035528) | about a year ago | (#43859585)

Anyone else sick to death of Drupal-related security issues?

Trolling as AC ... and making it clear you really didn't RTFA ... ;-)

The breach was in a 3rd party module installed on the servers, and is totally unrelated to the Drupal codebase.

Trolling fail! :-)

Re:vulnerability fatigue (0)

Anonymous Coward | about a year ago | (#43863377)

You replied. Trolling win.

third-party software? (0)

Anonymous Coward | about a year ago | (#43855907)

ie. modules? Why so non-descript? What happened?

--Sam

Re:third-party software? (3, Interesting)

Crudely_Indecent (739699) | about a year ago | (#43855957)

They probably don't know what happened.

If I was a hacker, attempting to gain user account passwords - here's how I'd do it:
1. I'd breach the server and install something that would capture newly submitted raw passwords prior to them being salted/hashed
2. I'd inform the site owner that I'd hacked them and provide some proof. The site owner then warns everyone to change their passwords.
3. New, fresh, raw, non-salted, non-hashed passwords come flowing in.

Rainbow tables and brute-force password cracking is resource intensive. Why not grab 'em while they're in the clear?

Re:third-party software? (0)

Arancaytar (966377) | about a year ago | (#43856033)

Who on Earth would find out that a system has been compromised and not immediately reinstall or reimage it before doing anything else?

Re:third-party software? (0)

Anonymous Coward | about a year ago | (#43856079)

So the vulnerable software in the image will let the attacker right back inside?

Take down, issue warning, find vulnerability, reimage, patch vulnerability, put back up.

Re:third-party software? (0)

Anonymous Coward | about a year ago | (#43859147)

99% of commercial companies whose clients just want 'uptime'?

Re:third-party software? (4, Informative)

Wraithlyn (133796) | about a year ago | (#43856139)

This is why you rebuild your compromised environment. Which is exactly what the bulletin says they did.

Re:third-party software? (1)

cheater512 (783349) | about a year ago | (#43856183)

Why not do #1 and leave it at that?
Slower but far less fuss and it could stay there for years instead of hours.

Re:third-party software? (1)

lipanitech (2620815) | about a year ago | (#43859121)

There not going to say exactly what happened until there Intrusion Investigation is over that's just good security practices I am sure in the next month or two we will get a more detailed report. Right now there is cleanup and prevention mode.

Researchers (0)

Anonymous Coward | about a year ago | (#43859367)

Those rascally Researchers are up to their shenanigans again!

Silly Researchers.

Re:third-party software? (0)

Anonymous Coward | about a year ago | (#43860161)

Well thats why in my web apps I do pre-hashing client side before sending to the server. The server never sees any sort of cleartext password ... ever

Re:third-party software? (0)

Anonymous Coward | about a year ago | (#43861843)

So now your hash has become the password. Congratulations, you're back at square one.

Re:third-party software? (0)

Anonymous Coward | about a year ago | (#43860579)

That's why I'd recommending changing your passwords ELSEWHERE if you use the same passwords elsewhere (not advisable but perhaps you may not really care).

No point changing the passwords on Drupal until you are confident enough that they've secured their system.

If only SSO ... (0)

atom1c (2868995) | about a year ago | (#43855965)

If only a federated single sign-on strategy were leveraged with individual provider revocation strategies in place, at least these thousands of affected individual wouldn't have to reset their passwords on yet another d'oh-prone website.

Re:If only SSO ... (2)

muphin (842524) | about a year ago | (#43855995)

or if this "federated single sign-on strategy" were compromised, all accounts on all websites would be affected.

Re:If only SSO ... (2)

manu0601 (2221348) | about a year ago | (#43856369)

No, there is no central place in federated single sign-on . In order to compromise all accounts, you would need to compromise aill identity providers.

Re:If only SSO ... (1)

atom1c (2868995) | about a year ago | (#43860795)

Thank you, manu0601. There are lots of folks who don't fully understand the technicalities behind a federated SSO solution.

Re:If only SSO ... (0)

Anonymous Coward | about a year ago | (#43856837)

He said federated, not centralised. Ever heard of Kerberos, DCS, etc? Each account has a ticket provider and a ticket identifier associated with it, when the user wishes to login they collect a ticket from the ticket provider of their choice by authenticating with that provider and then handing the ticket to the service they wish to sign into.

This problem could have been solved years ago, as it was in every enterprise system. If browser vendors and the W3C didn't have such an extreme case of NIH syndrome, they could have simply added Kerberos to http and web browsers and no one would care about this today.

I use FSSO at work, I use FSSO at home (federated with friends so they can login here and I can login there). This is just another case of the web being extremely backwards.

Re:If only SSO ... (1)

atom1c (2868995) | about a year ago | (#43860917)

@muphin, as @manu0601 stated below, you would need to compromise all identity providers in order for all SSO-member websites to be affected.

The security strategy I suggested (Federated SSO) would allow the compromised identity provider (e.g. Drupal.org) to have its federation membership trust revoked (either voluntarily or involuntarily) plus allow unaffected identity providers to take proactive measures to all related accounts (e.g. Example.com sending a warning [or simply resetting their access rights] to its users who had previously trusted Drupal.org).

Unfortunately, instead of embracing and investing into a federated SSO arrangement, most companies try to roll their own [derivative] security schemes which lack industry membership and then fail... most commonly after a major security breach whereby millions of users' identities AND credentials are compromised -- as opposed to simply their site-specific SSO token and whatever information a particular member site collected.

Iranians (0)

Anonymous Coward | about a year ago | (#43856063)

It was probably those Iranians. Quick, somebody call homeland security.

Passwords? More like passsentences. (5, Funny)

Anonymous Coward | about a year ago | (#43856127)

As a recent Ars Technica article has uncovered, it is possible for a dedicated and knowledgeable attacker to reveal as many as 90% of passwords in a database. The sophistication of password cracking has never been higher, and common advice such as "use a mix of numbers, symbols, and uppercase letters" is no longer sufficient to fully ward a salted and hashed password from either compromise or ultimate flavor.

While brute force cracking is rendered useless by any properly implemented password system, hackers have responded by tailoring dictionary attacks using techniques such as the following:

  • * Uppercase, in languages such as English, Japanese, or Spanish, typically appears at the beginning of a password, while symbols and numbers usually show up at the end.
  • * Combinations of words, such as the famous "horsebatterystaple" or the lesser known "walruspusflange", while suggested to extend the length of a password and reduce its susceptibility to brute forcing techniques, may nevertheless leave it vulnerable to directory combining attacks. Common passwords attached to each other sometimes reveal other passwords.
  • * Upwards of 50% of passwords contain the winner of the most recent Super Bowl, World Series, or Eurovision Song Contest, or some combination of letters used to spell such.
  • * Custom password dictionaries are available for passwords created by mashing the palm of the hand from left to right on the keyboard, and more are in development for mashing right to left (for RTL languages.)

So, how to keep your password safe in this age of uncertainty? Well, there is no sure way. But consider the following to stay one step ahead of the bad guys:

  • * Use a password length of 100 characters or greater, including a mix of uppercase letters, numbers, and symbols.
  • * Work out what your usual password is in EBCDIC, and enter it using the Alt key and your keypad.
  • * Invent a language with a million characters, get it accepted in Unicode, and develop a gigantic keyboard for it. Or learn written Chinese.

Once compromise happens, you have to assume your passwords will be known by the attackers before you do. Regularly changing your password is part of good Internet hygiene, so you may want to look for software that can automatically do this for you every minute or so. You may also want to consider two factor verification, typically a password and an application on your cellphone that gives you an access code, or three factor verification, which includes with the preceding an application on your friend's cellphone that gives a second access code that he'll send you on request. You cannot be too safe these days.

Re:Passwords? More like passsentences. (2)

magic maverick (2615475) | about a year ago | (#43858143)

Your post is almost totally plausible. Where it particularly falls down though is that Japanese doesn't have any conception of capital and lower case letters. The kanji are just Chinese characters (by and large), and the kana only have one form for most (there are small versions of some kana, but they play a different role in words to the large versions, unlike in English where the capitals still play the same role in the word, but affect grammar). (Though there are two types of kana, the point still stands.)
And smashing the keyboard to get dictionaries is funny. I had to think about it for a bit, and you know, it's still plausible. But, build the dictionaries from the home row keys I think. (Most of my "random" passwords have asfd in them.)

And of course the trouble with using spaces and non-latin chars in your passwords is that many systems just don't accept them. Or accepts them when initially entering your password, but silently fails; so you end up not knowing what your password is, because the system has converted the Japanese kanji to something weird, and then doesn't do the same conversion for login.

Re:Passwords? More like passsentences. (0)

Anonymous Coward | about a year ago | (#43863505)

But, build the dictionaries from the home row keys I think. (Most of my "random" passwords have asfd in them.)

That's why it's best to use software to generate the random strings- humans are notoriously bad at creating random strings.

And of course the trouble with using spaces and non-latin chars in your passwords is that many systems just don't accept them.

Well that's certainly true. Which is why it can help to use a password manager application which can generate different strings for different sites, and allows you to set custom lengths and character sets. You should have a generator which can kick out strings that potentially contain all of the allowed character space, as opposed to restricting it to just the "standard" alpha-numerics.

One thing the parent didn't touch on, is the use of "passphrases" instead of passwords. On the surface it sounds like a good idea, and if the person doing the attack is using a simple all-possible-combinations approach there is an argument to be made for them. But most attackers don't do that, and haven't for a very long time. They start the brute force attempt by running through a Dictionary (and, of course, permutated Dictionary). It's not until they exhaust the non-random string space that they move on to the "all possible combinations" approach. So in essence, each word in a passphrase only holds about as much entropy as a single character when faced with a Dictionary assault.

Re:Passwords? More like passsentences. (2)

pongo000 (97357) | about a year ago | (#43862403)

Combinations of words, such as the famous "horsebatterystaple" or the lesser known "walruspusflange", while suggested to extend the length of a password and reduce its susceptibility to brute forcing techniques, may nevertheless leave it vulnerable to directory combining attacks. Common passwords attached to each other sometimes reveal other passwords.

A silly and false assertion. Assume standard passwords in use. Your "dictionary" would consist of a list of characters ([A-Za-z]), digits ([0-9]), and punctuation. I don't know how many tokens that is, but let's say it's less than a 100. So you end up with a "dictionary" of 100 tokens.

The passphrase "dictionary" at Diceware [std.com] consists of 7776 tokens. There is simply no way the argument can be made that a "dictionary" of 100 tokens is somehow more secure than a "dictionary" of 7776 tokens, provided that tokens are selected randomly from either dictionary. That's the key, randomness. Not what you use as your tokens.

Re:Passwords? More like passsentences. (0)

Anonymous Coward | about a year ago | (#43868357)

Well, if we're getting real about this, then you can't ignore the constraint of password lengths. Whether you're dealing with a strict limit on the number and type of characters imposed by the password system or a fuzzier limit on what users are willing to remember and feed in on a regular basis, information density is a factor.

Let's assume a maximum password length of 21 characters (because it makes the following math easier.) If the second dictionary has an average token length of 4.2 characters (according to the site), we can consider the average maximum length password to contain 5 tokens, for something like 7776^5 possibilities. If the first dictionary has a fixed token length of 1 character, its maximum length password would contain 21 tokens, for 10^21 possibilities. It works out to being a few orders of magnitude in favor of the first dictionary.

I still suggest using the "horsebatterystaple" approach for ease of memorization, but mutating it in less predictable ways, perhaps removing or changing a letter or two in each word and using symbols, caps, and digits within the center of the password on non-word boundaries.

And remind me (0)

Anonymous Coward | about a year ago | (#43856199)

why I need to pick a "secure password" again?

Re:And remind me (1)

Nareth (1580251) | about a year ago | (#43856331)

Because if many weak passwords exist in the database it makes it easier to work through the salts. See the recent ars technica article.

Re:And remind me (0)

Anonymous Coward | about a year ago | (#43858155)

Well, if you had have had a strong password, I wouldn't have guessed it and been able to post as you!

Re:And remind me (2)

SplatMan_DK (1035528) | about a year ago | (#43859653)

why I need to pick a "secure password" again?

Doh! Because if your password is "secure" it can't easily be decrypted in the exact scenario described here? :-)

All the weak passwords are the ones to fall first. If you used something along the lines of "sFr95y/Gfd0w2_z+3xnMCIr4yl,cdjEO" (and perhaps a password manager to keep track of it) this particular story wouldn't really matter to you at all... ;-)

- Jesper

Re:And remind me (0)

Anonymous Coward | about a year ago | (#43860791)

If you used a strong password you'd still have to change it later for the fear the same attacker might have got the plaintext version when you logged in to the compromised site.

There have also been many cases where the site stores it plaintext or unsalted - and you only find out after it gets hacked.

So I don't really bother with strong passwords for random web stuff - the site is more likely to get pwned in other ways than my specific account brute forced. Use different passwords for different sites, so that if one falls the rest don't.

Use strong passwords for other things- disk crypto, vpn or similar. Maybe use a strong password for your webmail account if the password resets for your other websites go to it. Note that some webmail providers may require you to have low security password reset procedures - e.g. anyone who can read a text message to your phone can reset it (text messages to phones are generally not encrypted at the provider and weakly encrypted over the air).

what is the third party software? (1)

manu0601 (2221348) | about a year ago | (#43856377)

They blame a third party software but fail to name it...

Re:what is the third party software? (1)

Anonymous Coward | about a year ago | (#43856477)

They're currently conducting an investigation.

Re: They're currently conducting an investigation. (0)

Anonymous Coward | about a year ago | (#43856699)

Where? In your pants?

Re: They're currently conducting an investigation. (0)

Anonymous Coward | about a year ago | (#43857333)

That doesn't even make sense.

Re:what is the third party software? (3, Insightful)

kbahey (102895) | about a year ago | (#43857297)

It is known, but they did not name it publicly because the investigation is still ongoing.

Big surprise (0)

Anonymous Coward | about a year ago | (#43856781)

Big surprise... you know because Drupal is known for their excellent securely written software. ;)

Re:Big surprise (0)

Anonymous Coward | about a year ago | (#43859115)

Did you read their official post about it? It's unrelated to the CMS software.

Re:Big surprise (1)

SplatMan_DK (1035528) | about a year ago | (#43859685)

Big surprise... you know because Drupal is known for their excellent securely written software. ;)

Big surprise ... you know because you really didn't RTFA.

The problem was in a 3rd party module and is absolutely unrelated to the Drupal codebase itself.

Trolling failed! ;-)

- Jesper

Re:Big surprise (0)

Anonymous Coward | about a year ago | (#43863583)

Big surprise... you know because Drupal is known for their excellent securely written software. ;)

Big surprise ... you know because you really didn't RTFA.

The problem was in a 3rd party module and is absolutely unrelated to the Drupal codebase itself.

Trolling failed! ;-)

- Jesper

1. You replied, so trolling win.
2. The issue might not lie within the Drupal codebase, but the people involved are the same so there is still some relation between the two.

The End of Passwords (3, Insightful)

rueger (210566) | about a year ago | (#43856873)

I'll admit to a) reusing the same password on most forums, since it largely wouldn't matter if someone accessed them. b) using shorter passwords for most stuff, and long complex ones for the handful of places that actually need security, a c) Using the "Forgot Password?" link on most web sites that I don't visit often and just accepting whatever reset they offer.

It's time to acknowledge that passwords are an idea that has come and gone. Too much hassle. Too many different password specifications from site to site. Too many to remember. Too many poorly constructed sites trying to tell users that bad security is their fault for not have super long and complex passwords. Too many sites where I actually now have three or four user IDs and passwords because I couldn't remember the last password I used there, or had changed my e-mail address since last visiting.

And too many sites, banks especially, that still demand to know my mother's maiden name, or worse yet, arcana from my youth that I don't even remember. My first pet's name? My favourite TV show? I have no idea. Or likely would answer that differently a month from now.

It's no wonder that most people ignore all of the password edicts that are thrown at them, and never change anything, and use the same password everywhere.

Surely we can develop some new way of confirming people's identity that allows us to abandon the idea of passwords? I vote for an RFID pinky ring with a plug in USB reader on my computer.

Re:The End of Passwords (1)

cen1 (2915315) | about a year ago | (#43857131)

Guity as charged. I reuse the passwords too but not on every single site. For random forums and less important stuff I use the same password but for those which could potentially leak my credit card details or some other imprtant information I usually create unique strong passwords.

Re:The End of Passwords (1)

Asteconn (2468672) | about a year ago | (#43858825)

Sounds like you need a simple mechanism for unique passwords. I have a suggestion for you to consider. Personally - I "salt" a standard password with the name of the website: the first initial of each of the words in a site's name for example. If my 'standard' password was for example "Aware20130530ness", and I was signing up for slashdot, I can simply add the letters to the start of the password, resulting in "sdAware20130530ness"

Re:The End of Passwords (3, Insightful)

SplatMan_DK (1035528) | about a year ago | (#43859737)

Sounds like you need a simple mechanism for unique passwords. I have a suggestion for you to consider.

Personally - I "salt" a standard password with the name of the website: the first initial of each of the words in a site's name for example. If my 'standard' password was for example "Aware20130530ness", and I was signing up for slashdot, I can simply add the letters to the start of the password, resulting in "sdAware20130530ness"

Right, clever boy, and now that you have revealed this, it will be trivial for any cracker to include this pattern in their decryption script ... if it isn't already there (which is not impossible at all). Commonly used patterns such as the one you describe can be identified mathematically and easily applied to the decryption process. The added work of even 100 patterns absolutely pales in comparison to real brute-force, so you should expect crackers to get past your "salt" real easy.

Making patterns like yours from the name of the website, or information in the usertable, is standard operating procedure when cracking.

Stop doing it. It does little to help you. At the very least you should use a pattern containing characters not present in the website name, and not present in your user properties on the site in question.

- Jesper

Re:The End of Passwords (1)

bill_mcgonigle (4333) | about a year ago | (#43860073)

I've "given up" too. Until the pony is delivered, LastPass [lastpass.com] is a good solution. It supports Firefox, Chrome, and Dolphin on Android (have to subscribe to get the mobile support), which covers my needs, and uses local strong encryption so the LastPass people's can't get at your data. My first dog's name was jRffr9CDMNhD (I just generated that automagically with Alt-G - different for every site). It should be %6mjDYs*uwysVz%YYwTz2!7rcAt8!B%H, but too many websites don't sanitize input and have length limitations. Conveniently the length and character class differences are just a click away. Inconveniently, almost no websites will tell you what kind of data they will accept for a given field (that would make a nice form field spec enhancement).

Yes, it's basically using a short key without the benefits of PKI, but compared to using human-recalled passwords, it's better.

Browsers should really have implemented this sort of password manager 5 years ago, and also provided a usable UI for doing client-side certificates 10 years ago, but here we are today with nothing like that in sight.

Salting is partially false security (0)

Anonymous Coward | about a year ago | (#43858355)

While salting is a good idea - protects against rainbow attacks it doesn't help much when its a targeted attack against a particular individual.

Case scenario: If a user registered using a corporate email address that allows an attacker to identify a corporation he'd want to target. He'd single out the hash and brute force it and most probably the target would have reused the password on corporate sites - salting wont make a difference.

Re:Salting is partially false security (0)

Anonymous Coward | about a year ago | (#43859151)

Please provide actual technical details that make sense so that there's a reason to invest in your hysteria.

Re:Salting is partially false security (1)

SplatMan_DK (1035528) | about a year ago | (#43859555)

Please provide actual technical details that make sense so that there's a reason to invest in your hysteria.

From a technical standpoint he is totally correct, so what "hysteria" would that be exactly?

Salting does little other than prevent mass-cracking on large lists of userdata. So if someone takes the Drupal.org userlist and targets a few (2-5) individuals, rather than attempting to decrypt all passwords, the salt will have very little impact.

Calling this simple fact "hysteria" only makes your ignorance on the subject more clear - said with all possible respect and no trolling intended.

- Jesper

Re:Salting is partially false security (0)

Anonymous Coward | about a year ago | (#43862987)

The only thing a salt does is ensuring that brute-forcing must take place after you have obtained the encrypted password list. Without salt you can do the brute-forcing beforehand by using rainbow tables.

What method was used? (2)

SplatMan_DK (1035528) | about a year ago | (#43859483)

While current phpass implementations support bcrypt it has not always been so, and the framework support many different methods.

The article doesn't admit which method was used (suggesting they're not proud of their choice perhaps?). Does anyone know what method was used?

The articles at Ars mentioned by multiple ./ers here, were based on MD5 (which is totally unsuitable for passwords btw). So don't panic until the method used by drupal.org has been revealed.

- Jesper

Re:What method was used? (0)

da6s (2935785) | about a year ago | (#43860955)

Drupal.org is built on Drupal 7 and therefore stores passwords salted and hashed with SHA-512. See user_hash_password() [drupal.org] in the Drupal API docs.

Re: What method was used? (2, Informative)

Anonymous Coward | about a year ago | (#43861473)

Nope. They're in the upgrade process. It's currently based on Drupal 6... Which is md5 by default

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...