Debian Locks Out Developers

daria42 wrote in with an update to an earlier story about a Debian server that was compromised. He explains: "The Debian GNU/Linux project has discovered a compromised developer account was used to gain access to a server compromised this week. A local kernel vulnerability was then used to gain root access. Due to this, a number of developers with weak passwords have been locked out of their system accounts." To be fair, they'll most likely be let in once everything's back to normal. Of course, they'll probably need to set safer passwords too.

Comments

Ah. balance

[Kid Zero]

That wonderful feeling of making the password hard to guess, but easy to recall.

Re:Ah. balance

[JebusIsLord]

Yeah, instead you have to worry about the locations of their memory keys!

Re:Ah. balance

[finiteSet]

That wonderful feeling of making the password hard to guess, but easy to recall.

If you are like me, it seems like almost everyday the bank or eBay is emailing about a new upgrade to the system, one that requires entering your old and new passwords, social security numbers, bank account numbers, and so on. Accordingly, I've developed some simple tips for coming up with making a hard-to-crack but easy-to-remember password:

• Short but strong: you can make the password relatively short (e.g. one character) so that it is easy to remember, but random enough to be hacker-proof. Do you really think someone would guess 'q' or 'z' ?
• Long but simple: if you are unsatisfied with the previous strategy, try this one on for size: the longer the better. So instead of 'a', you might want to use 'aaaaaaaaaaaa'. ('0000000' works, too.)
• Mirror Mirror: use your username as your password and cut the memory load in half!
• Long and strong: for the absolutely mission critical stuff, you may have to spice it up. Pair a common dictionary word, like 'dog', 'log' or 'hog' with a small digit ('1', '2', and so on), and you're golden.
• Final Notes: don't forget to recycle your old passwords and - please - keep a public list!

Re:Ah. balance

[Millenniumman]

"and starting today, all passwords must contain letters, numbers, doodles, sign language and squirrel noises."

Re:Ah. balance

[arivanov]

Ahem.

That was my first reaction as well. If you are using ssh, passwords are "the wrong idea" (TM). A password is guessable while a private key is not. That is the way it is designed.

Not that it would have helped in this case though. The attacker compromised the developer machine first and from there on compromised the server. Once you are in full control of a user machine it is game over as far as any resources it accesses are concerned.

While at it, I can also understand an admin on a large linux shell machine which still allows passwords.

Due to Theo and Co's knee jerk (hello Theo) attitude to non-OpenBSD OSes there is no way to make ssh public key authentication plug cleanly in the OS authentication chain. The reason is that ssh continues to be developed from the perspective "PAM sucks, we here do not do that". That is a purely political OpenBSD position which belongs to the realm of OpenBSD and should have nothing to do with OpenSSH. If OpenSSH is to really support linux without "OpenBSD is better TM)" being involved it will have to support PAM properly, natively, all the way and for all authentication methods including public keys. This is the way of the land.

As this is not the case yet, if you want to limit access to public key only you have to turn off PAM for ssh. Alternatively, if you manage a big machine (or network) and you need PAM you end up turning on passwords and praying.

Re:Ah. balance

[Mark Hood]

Not in this case - if you read the summary, even.

They got in with a developer's password, then used a local exploit to get root permissions.

I.e. they didn't know (or need to know) the root password. So in this case, having two 8 character passwords was exactly as secure as having one 8 character password.

Mark

Re:Ah. balance

[BecomingLumberg]

Well, the parumutaions change depending on whether or not the program displays that you are correct with the first password. Cracking a 16 digit password would square the time it took to crack, where two eight digit passwords separatly would simply double it.

Re:Ah. balance

[aymanh]

Talking about openssh's security, here's a vital patch:
-PermitRootLogin yes
+PermitRootLogin no

A couple more:

Protocol 2
PermitEmptyPasswords no
LoginGraceTime 2m
MaxAuthTries 6

And it's always a good idea to restrict SSH access to trusted IP addresses in /etc/hosts.allow.

back to normal

[Coneasfast]

To be fair, they'll most likely be let in once everything's back to normal. Of course, they'll probably need to set safer passwords too.

Um. What exactly does this mean? If everything isn't back to normal, shouldn't they lock out ALL developers? That's what I would do.

Re:back to normal

[Ohreally_factor]

They're only locking out the developers who used the password "tux".

kernel exploited...

[scum-e-bag]

Schulze said the particular Linux vulnerability only
    exists in kernel versions:

• 2.6.13 up to versions before 2.6.17.4
• 2.6.16 up to versions before 2.6.16.24

    Schulze advised admins to upgrade their software if they were
    using these versions but said the current stable version of
    Debian was not affected as it run kernel 2.6.8.

I guess this means that there are a lot of ubuntu users out there who are vunerable right now... how long for the patch?

Also, the article seems to be a little out. Shouldn't it be just 2.6.12 -> 2.6.17.4 as this includes 2.6.16 -> 2.6.16.24

Re:kernel exploited...

[scum-e-bag]

According to the ubuntu-security-announce lists, the current up to date kernel version is 2.6.15-26.44 This was released 3 days ago, before the debian server compromise was announced. According to the zdnet report, this version falls within the exploitable.

I made a mistake in my initial post, slip of finger, 2.6.13* not 2.6.12*

libpam-cracklib

[dduardo]

Time to enforce a 200 character minimum for passwords.

Re:libpam-cracklib

[teslar]

You're laughing, but in practice I have too often seen restrictions on the maximal security of passwords.
Take for instance my online banking system (which in its defense has other security measures alongside the password, but still):

• no more than 10 characters please
  
• upper/or lowercase does not matter, lowercase will automatically be converted to uppercase
  
• alphanumeric characters only

Seriously, what's the point of this?? Why am I forced to use weak passwords just because some developper somewhere can't figure out how to allow a " or a \ in a string?

password requirements

[PetriBORG]

Hopefully then they will also implement a good set of password rules and enforce them to protect themselves from future problems. Where I work they require 3 out of the 4 rules to be met such as mixed case, numbers and special characters... of course they also make us change our password every 30 days so i've discovered that people have taken to doing things like Asdf1234 and then when the password requires changing changing it to Asdf2345... Doh.

Re:password requirements

[Bostik]

Hopefully then they will also implement a good set of password rules and enforce them...

I have a suggestion. Dump the password based access altogether. These are Debian developers, who by their position already NEED to both know and understand how to use GPG for signing their uploads. The concept of public-key access control/validation is their bread and butter.

Allow only public-key SSH access to Debian machines. Period.

That way, to compromise Debian server(s), any potential attacker would need to daisy-chain their targets. Break a developer's home or work box first, get their keys and their passphrases. Only then can they proceed to bigger targets.

I wonder...

[MSFanBoi2]

Why when this happens on a Windows server is "OMG! Windows is insecure! M$ is evil!!!!"

But with this its "Oh just set more difficult passwords"...

Re:I wonder...

[Anonymous Coward]

Did you fail to understand what a remote exploit is?

Here, let's try an analogy. In this case someone left the door to the building unlocked. A burglar got in. He then methodically cracked the safe, and took the money from within.
  Following this, "MSFanBoi" posts to slashdot making a false equivalency between that and the Win building where the locks were defective and the money was taken from where it was sitting on the floor. (The windows exploits being criticised are remote, the linux exploit was local-only. In the latter, you have to actually break in before they are useful.)
  Do you still fail to see the difference?

If only they'd...

[a_greer2005]

been running with the stability and security of Windows Server, they wouldnt have had this happen. They would have kept their service up and agile for the furtherance of the enterprising endvors of hacking...er...uhhh...computer science research.

Bill G.

ssh2 keys?

[saleenS281]

Why don't they just have the developers use ssh2 keys? I didn't know anyone actually used passwords on secure systems for authentication...

B...b...b...

[htnprm]

...but it's Linux!

Secure Passwords lead to Insecure Passwords

[cloricus]

I have noticed what you talk about though I've seen it go to further extremes. While at work (we run a mainly Windows network with a few hundred users) I've done further education (out side of Uni) at Australian TAFEs (basically vocational collages) in Queensland - the TAFE I went to runs a pure Windows network with around twenty thousand plus users over several sites...Any one who has been to one of these TAFEs understands how much of a raping they have taken from Microsoft, and I say raping because they run the 'perfect Windows network' following all of Microsoft guidelines etc which mean some machines take over fifteen minutes to log in and are laggy as all hell once they are in.

Anyway onto the topic. They also follow the recommended guidelines for passwords which includes at least one capital, two numbers, over six chars, and cannot be any of your previous passwords (with I believe a 80% match so you can't just add a 1 or a 2 to it) and these roll every thirty days. Now as a geek I have my own unique password system where no two are the same, they are long, and they have numbers, and at least one capital - unfortunately there is only five or six possible combinations that meet the password system for each item meaning after five months going to this TAFE (I was there a year part time) I ran out of passwords. This put me on the tred mill that every one else had been on for a few months (they did a fresh roll over to XP from 98 at the start of last year) of forgetting the password (that I made up to get into the system after my old one expired) or where I wrote it down (yes, every one wrote down their passwords in blatant places so they could find them again, which to me makes passwords null anyway) and then starting to use generic passwords that every one else was using that month for example t4f3IsShit or fUkp455words and the like. As you can probably see this just ends up a mockery of the idea.

So basically the point I'm trying to make is you have to be careful with what you mean by a 'good set of password rules' as if you go overboard even to the slightest extent (as I've seen happen time and time again) passwords just become a joke and you may as well not have them.

Personally I've found that if you teach people/users what a secure password is, teach them not to tell it to any one, get them to use firefox to avoid keyloggers, and then enforce a six to twelve month roll over no problems ever come up. That's my happy medium and 2cents anyway. :)

*gasp*!

[grasshoppa]

Goodness, no! This might push them behind schedule!

Re:So?

[TCM]

How the hell could this be modded insightful? The whole point of changing passwords is so that the compromise of one password doesn't lead to unlimited access or the compromise of future passwords.

If a password is so secure that it can't be guessed, then why change it? If it's so weak that it gets guessed monthly, changing just one digit doesn't do shit.

And if the system gets compromised, you reinstall and choose a totally different password.

Seriously, this must be the most stupid advice I've seen and it's currently +2, Insightful. Scary.

Re:WTF?!!!

[linvir]

Old password:
> ******
New password:
> *****
Retype new password:
> *****

WARNING
This is a really stupid password, the kind that would put this entire computer at risk.
Are you sure you want to continue?
[ Y / n ]
> Y

BASTARD
Okay then, fuck you. Your account has been completely cleared out, to help you understand the importance of choosing a secure password.

Now, let's try again, shall we?
Old password:
>

Re:Passwords

[ozbird]

John the Ripper most likely. Great tool - recovered the root password for a SGI box a friend bought on eBay in less than a second (your password may vary.)

Re:Weak Passwords ?? If they know that ...well

[Anonymous Coward]

Believe me, the Debian project does not store passwords in the clear.

As administrators they have access to the shadow file that contains hashed versions of all the passwords. What they did was run a cracking utility against the shadow file to pick out weak passwords. Usually these cracking utilities use brute force dictionary attacks to try and randomly guess the password. If the utility was able to guess a password quickly, that password was definitely not secure. It's as simple as that.

I encourage you to read more about the topic, it's a fascinating one. Wikipedia has an interesting article at http://en.wikipedia.org/wiki/Password_cracking/.

Accounts with bad passwords locked, not all

[dondelelcaro]

The story title is a bit misleading; only accounts with bad passwords or those who (for $DEITY knows what reason) appeared to have private keys on gluck were locked out. Everyone who has sane passwords and/or only uses ssh keys to log into their accounts still have access.

Of course, anyone who could actually log in already knows this because they've read d-d-a (or have already logged in.) In any event, rather troubling that the PRCTL bug managed to find its way into the kernel, but good that the intrusion was caught relatively quickly and neutralized.

Your new Debian password.

[Savage-Rabbit]

Dear Mr finiteSet,
To punish you for using such a weak password to your Debian developer account we have changed your password to the following:
!_@m_@n_!ns3ns!t!v3_cl0d_wh0_us3s_w3@k_p@ssw0rds_b ut_!_pr0m!s3_n0t_t0_d0_!t_@g@!n_s0_l0ng_@s_!_l!v3

Enjoy
The Debian team

Chip and Pin

[giafly]

I use my credit card Chip and Pin number as my password. If you do the same, you'll be completely secure, because it's the one thing that cannot be forged. Don't just take my word for it, check out these quality endorsements:

• "Your PIN cannot be forged" - Halifax Bank
• "the PIN can't be forged" - Alliance & Leicester
• "the PIN, unlike a signature, cannot be forged" - extra direct Banking

howto: strong passwords

[dune73]

If you are in need of a strong password, use the following recipe:

Think of a sentence with 6-10 words with a number in it.
- The number can be inside one of the words.
- If you manage to have multiple Capital words in the sentence, your password gets stronger.

Then take the first letter and write the numbers as digit, include the point,
question mark, exclamation point at the end and you got a strong password.

Today i ate two buns for breakfast! -> Tia2bfb!
I have seen six dups on Slashdot this week. -> Ihs6doStw.
Can you memorize all four new passwords? -> Cyma4np?
And today: A new password for my debian account! -> At:1npfmda!

Works fine for me and is fairly easy to memorize.