More Info on Debian.org Security Breach

mbanck writes "James Troup (part of the Debian System administration team) has published more information on the recent compromise of four debian.org machines. The attack vector seemed to be a sniffed password of an unprivileged account, from which the attacker somehow managed to gain root and install the suckit rootkit and crack the other machines. As the machines were fairly uptodate with respect to security, an as-of-yet unknown local root exploit might be in the wild, so keep an eye on your boxen.Note that the main ftp archive running on a sparc machine was not compromised, so the exploit might not yet be ported to non-i386 architectures."

Boxen..

Here come the comments about the word "boxen..."

Re:Boxen..

Someone needs their ears boxen.

Re:So much for unbiased Slashdot

Look at all the posts...excuses and rationalizations. "Well, this serves as an example of weak passwords" or "non-root privileges," etc.

Actually, what I see is people warning of a possible security hole in the wild.

You never see that level of rational explanation when it comes to a user-transmitted e-mail Outlook worm. In fact, in those cases it magically becomes a "Microsoft hole," even though it's users running the executable!

This is because one of the "strong" points which is claimed by windows is that it's designed to be used by non-tech experts, while at the same time it offers NO protection from mistakes. If outlook were modified so that it cannot execute anything and you must manually save to disk and execute whatever you would see (beside a drop in virus infections) fingers pointed at the users instead of Microsoft.

Re:So much for unbiased Slashdot

Slashdot is NOT supposed to be unbiased. It's called /. for heaven's sake - if it was a Microsoft oriented site it would be \. (backslashdot.org)

Re:So much for unbiased Slashdot

Slashdotters are hypocrites and hold double-standards.

You're saying slashdot posters are inconsistant, but they're just different people who all happen to read slashdot. If you want to make a real argument, pick one person and attack their inconsistancies.

Another example is the political parties. You can't say that Democrats are inconsistant because of this, that, and the other. Democrats are a varied group, and they have many different perspectives and form their arguments in different, often contradictary ways. They just see a common means to their end, and each individual may be 100% consistant. (note: I'm not a democrat, I just used them as an example. This works with any political party that I can think of.)

Ultimately what you're doing is grouping variety of people together (slashdot readers) and then attacking the group as a whole for being inconsistant with respect to a separate issue (their perspectives about computer security).

You can do that to anyone. For example: "Blondes are so inconsistant. First they complain that the environment is being damaged, then the next week they're complaining about too much government regulation." Well, being blonde obviously has nothing to do with the topic, so of course you find inconsistancies in their viewpoint.

That type of reasoning is very simple-minded. The world is a complicated place with myriad possible groupings of people. Analogies that relate nations, corporations, SIGs, etc. to people often confuse the issue beyond repair. Microsoft isn't a "bully," it's just that the shareholders elect people that are likely to use aggressive business tactics and leverage the monopoly that they have to gain shareholder value. You can't punish MS in any way analogous to punishing a bully, because the shareholders could be long gone by now (however many years it takes to settle an antitrust lawsuit), because it's simply not a person, it's a group. Same with nations, it's a group and should not be personified. Think how much time the media has wasted talking about Bush as though he "doesn't play well with others." Nations are groups, not people.

Re:Boxen..

If you call your computers "boxen", I hope they get cracked and rootkitted.

Re:Boxen..

It's a perfectly good middle-english plural. Perhaps they just have rather olde boxen to develop on?

Two useful utilities to flush out the rootkits

Here are two useful utilities to flush out the SucKIT rootkit:


Kernel Security Therapy Anti-Trolls [freshmeat.net]

and

Kernel Security Checker [freshmeat.net]

Have a nice day !

Human Error

This incident reminds us of the importance of password security. It is sad to see one weak password responsible for such a breach. I think that it would be a good idea for the future to move away from the traditional unix password. An appropriate replacement would be something similar to RSA passphrase mechanism used by secure shell. A random passphrase with a minimum lenght would be idea. The user is the greatest security hole.

Re:Human Error

Random passphrase?

Repeat after me: The best password is the one that isn't stikie'd to the monitor and/or keyboard.

Re: Human Error

> Random passphrase? Repeat after me: The best password is the one that isn't stikie'd to the monitor and/or keyboard.

When it comes to internet-based attacks, my yellow stickies are the securest files on my system!

Re:Human Error

For some bizzare reason, I haven't found it necessary to be able to do that. All you need to do is learn how to make hard-to-guess, easy-to-remember passwords:
Choose a quote or sentence, take the first (or second if you really want it to be hard) letter of each word, use numbers instead of letters for words like 'to', and alternate capitalization for the rest:

"To be or not to be, that is the question" becomes
"2bOn2BtItQ" which should defeat any dictionary based attacks, and is incredibly easy to remember. Of course I also choose somewhat more obscure quotes or make up an interesting sentence.

-Chris

Re:Human Error

I say we cut out the user.

Re:Human Error

Clearly we need some way to move away from traditional passwords, but RSA keys isn't the way to go. They're impossible to remember, which means you need to store them on a computer. That makes them vulnerable to copying. You can password-protect them, of course, but then you're in the same situation as before (actually worse, for the same reason /etc/passwd is less secure than /etc/shadow).

That's not to say that RSA or some similar system won't be part of a good solution... but there definitely needs to be some other component. (For example, the private key might be encrypted by a biometric signature or keycard or similar. While that still leaves the system vulnerable to physical attacks, it more or less eliminates network-based ones as long as you use secure protocols.)

Re:Human Error

(For example, the private key might be encrypted by a biometric signature or keycard or similar.

I have yet to see a biometric signature that would solve this problem. Generally speaking, in biometric identification, information about the fingerprint/retina is stored on the disk and then compared against the data that is read in. The biometric information is not used *AS* the encryption key. So a biometric signature is just like a really big password, except that if someone cracks your password you can change it, but you can't (easily) change your fingerprints.

-a

Re:biometrics

Palm scanning only proves you have the hand of someone allowed to access a system. Retina scanning only proves you have the eyeball of someone allowed to access a system.

Well, the manufacturers of palm/retina scanners generally do include a feature that detects if the bodypart being scanned has a pulse. So you can't fool these scanners just by cutting off someone's hand or ripping out their eyeball. (Although it might be possible to manufacture fake contact lenses or glue-on fingerprints that would work.)

On the other hand, the basic weakness is that the biometric signature is still just a big password. You can "sniff" the signature by installing a fake reader. You can steal the signature off the harddrive of the domain controller. You can bypass the reader by splicing the wire. And your "password" is the same for every site.

Bottom line: I would sooner trust a token card.

-a

Re:Human Error

The biometric information is not used *AS* the encryption key.

And there's a good reason for that: It wouldn't work. Every time a biometric is scanned, the result is different. Biometric matching is hard because it's a process of evaluating the "closeness" of the livescan to the stored template and then deciding whether the two are close enough to be considered the same.

This means that trying to extract a set of bits from the scan which you could be sure would be the same every time is very difficult, and likely wouldn't net you many bits to use as a key. A set of bits that changes a little every time doesn't make a useful key.

Given some sort of a secure processor, you can store the key and the biometric template in there, and program it to refuse to use the key until it has been presented with a biometric scan which it considers to be close enough to the template. That gets you about half way to security, now you just need to find a way for the secure processor to verify that the livescan it receives is fresh, and not replayed. Oh, and it would be good if you could also be sure the livescan is a *live* scan. And don't forget to secure that template database well.

Making biometrics secure is hard. In practice, this means biometrics are only useful in two situations. The first is very low security, where the biometric is being used to raise the level of security from very, very low to very low. The second is very high security, where the biometric is to augment some other authentication methods, or when verification is only done in a very controlled environment, i.e. where you're watched closely by a human guard who knows how to ensure you're not trying to fool the scanner.

Re:Human Error

Er, the problem with biometric identification is that (1) its not testing who you are, just that the digital input matches some value and (2) you can't change what its testing.

You can't change who you are. Thus, once the key is compromised, it stays compromised.

Re:Human Error

A good method: Easy mental ciphers.

You pick a passphrase that you use for all of your systems. You then pick a unique seed for each system. Then, you do some quick mental math on it (pick an algo of your choice, just make it simple) and then you have the effective security of two passwords + unknown algorithm. It will make all of your passwords invulnerable to dictionary attacks (unless a rare circumstance has your resulting password being "password" or something)

For example, if you have a pass phrase of "MYBOXISSECURE" then you can use the box name as a seed, lets call the box "DEBIAN" and have the algorithm block the seed and then subtract, modulo 26.

MYBOXISSECURE
DEBIANDEBIAND
-------------
I'm too tired to do this and I'm on my windows sytem without perl.

Then reverse it or something. Walla! Pseudo-random passwords. Works great, and after a few times you will memorize the keystrokes and you won't need to do it by hand. You can even have a standard system for the passphrases amongst an entire group for the root password, so each system can have a different root password that everybody can just figure out as long as they know the passphrase. In addition, if you want to remove someone from the loop, just change the passphrases and redistribute to the trusted source.

It's a hack solution for the weak-password problem.

Re:Human Error

Uhh, I dunno if you noticed, but it wasn't a password alone that did this much damage. The account broken into was unprivellaged, meaning it was just a simple user account.

In theory, a secured system can have this happen to it and the attacker will have fun deleting a single home directory before they run out of damage to do.

In practice, a single local privelage escalation attack is all it takes. Maybe this will end up being a good thing in the end, we get to find a previously unknown local root exploit, fix it and improve the Debian security practices, all in one move.

Re:Human Error

So when an exploit is found in Windows, it is considered a bad thing that shows how lame of an OS it is.. but when it is found (or not?) in Linux it is a good thing?

Yes. In the past, Windows exploits get found one of two ways. The first way is when a virus is found in the wild. The virus is deconstructed, then Microsoft does a cost analysis to determine if it's worth patching the vulnerability that enables the virus. If so, then a binary only patch will be issued. The first you'll hear of it is when you're able to download the patch. The second way is when a white hat hacker or security analysis team at some college find an exploit. If they go public with it, they're criticised for not giving time for Microsoft to develop a patch. If they go to Microsoft with it first, then the cost analysis process starts, only because the public at large doesn't know a problem exists, there's a much smaller chance a patch will be issued. In either case, the patch may or may not work, and it may or may not break your system. Caveat emptor.

When an exploit is found in Linux, it gets fixed. The cause of the exploit gets scrutinized world over, and other developers privately consider whether their software might have the capacity to be exploited in the same way.

Password was *sniffed*

Apparently the password was sniffed [google.com]. This generally implies that it was obtained through monitoring network traffic and seeing it trasmitted in cleartext. A strong password wouldn't help here; only a good protocol would.

This was both user and admin stupidity I guess. Admins who care about security shouldn't permit access through cleartext passwords and users shouldn't send their password in cleartext if they care about their account. Unfortunately many users don't know about this risk.

Re:Password was *sniffed*

Why assume it was a cleartext password? It could of been encrypted, captured and crack via brute force or some other method.

Re:Password was *sniffed*

Ah, but the SucKIT rootkit is particularly useful as it captures all tty i/o at the kernel level: all interaction with sshd is captured in a "sniffer" file. No decryption or packet sniffing needed- the attacker owns the system completely if they have installed SucKIT. If you don't trust a computer that you have ssh'd into, never ssh or scp from the untrusted computer back into your trusted systems. If the untrusted computer has been compromised, any login sessions that you have from the untrusted computer will expose the passwords if a SucKIT rootkit has been installed.

Human Error or faulty security models?

SELinux would likely have prevented the root exploit from allowing this individual from doing as much harm as was done.

I think that it's time for the big names like Debian, Slackware, Red Hat etc to start implementing it on their network connected machines. It's being incorporated into the stock kernel for a reason. Use it!

Unknown Debian exploit?

Im sure glad my network runs on Windows!

Re:Unknown Debian exploit?

Im sure glad my network runs on Windows!

hey it is pretty nice - i'm having a look around right now!

In a nutshell - somehow

Quote from the article:

"Somehow they got root on klecker and installed
suckit."

What follows is an interesting read - but the guts are in that 'somehow'.

Re:In a nutshell - somehow

You're absolutely right. For some reason, everyone else seems to be overlooking the fact that there is (or appears to be) an unknown root exploit out there.

Yes, you can probably guess/crack/social engineer a password if you try hard enough. That's why security is about layers, compartmentalisation and multiple types of protection, not just a single password.

If this was your box, would you be more worried that someone had managed to sniff an (unprivileged) password? Or that any one of your users can now root your box? I know which one I would lose sleep over.

Here's to hoping that the root exploit is found and patched nice and quick. Even better if it something else that's been missed and is fixed in the latest patch.

Re:In a nutshell - somehow

For some reason, everyone else seems to be overlooking the fact that there is (or appears to be) an unknown root exploit out there.

Uhm, did you read James' post? Here's a quote:

Unfortunately due to the fact there is (I believe) an unknown local root exploit in the wild, we can't yet unlock the Debian accounts.

Surely this constitues something else than "overlooking" the root exploit? Deciding to keep the Debian accounts disables effectively stops the entire developement of Debian. Nobody has been able to upload packages in the last week, and lots of services are down.

James could have unlocked the accounts to make the developement pick up again rapidly (which would probably would be the only option in a corporate setting -- there's a release schedule that must be kept at all costs), but the admins are being thorough on this one.

In summary: James (and the other admins) are keeping the entire Debian Project in suspense for the purpose of tracking down this local root compromise and preventing it from being exploited again. You might want to think about that for a second, and see if "overlooking [the] unknown root exploit" is applicable here.

Diebold, take note

All vendors and site administrators should take note of the openness with which the problem was dealt.

When I go to buy a car, a computer, or a stereo, and the saleslizard is cagey about any problems that come up, my trust level goes down. If they tell me all about all the problems with the thing they're selling before I even notice them, my trust level goes up. It's like a cool drink on a hot summer day.

Contrasting with Debian, how long did it take to find out that Diebold ATMs had been hit by the Nachi worm?

I'm now more inclined to trust Debian, and less inclined to trust Diebold.

Re:Diebold, take note

More importantly, the openness of Debian is a much more important factor here. When I read these lines in the article:
The attack vector seemed to be a sniffed password of an unprivileged account, from which the attacker somehow managed to gain root and install the suckit rootkit and crack the other machines. As the machines were fairly uptodate with respect to security, an as-of-yet unknown local root exploit might be in the wild, so keep an eye on your boxen.
I got the distinct impression that Slashdot is transformig into a FUD channel for unsuspecting readers.

The fact that a 'clean' Linux system can be backed up and restored from any media, is of more relevance and importance to users. EVERY system connected to the internet has potential unknown vulns, those running Windows are often unpatched and have no disaster control system as well.

Viewed from this perspective, I don't think we need to keep an eye on our boxen just the backup tapes / disks/ CDs.

-

This attack has obviosly shocked the comunity.

Since Debian (even for those smart ones out there using slackware, like i do) is really considered one of the real distros, if we hear that redhat has been atacked, we would just say that they diserve it and go on, it would be delivered in the respective mail list, and that was it.
But this attack has a psicological impact. Debian itself has been attacked, and it seems to be a bug exploited just in part, on the other side, there are updates that the compromised machines never got aplied, and other big mistakes like a non-tared backup lying arround, with the original owner / permissions mask. This is really more that enough to get any netadmin running Debian to get paranoid.

One recommendation

Off-site logging of all accesses.

One of the first things that get wiped in an intrusion are the logs. All access logs should be copied in as near real-time as possible to a remote server that is not accessible from the machine being logged, i.e. a drop-box.

Re:One recommendation

One of the first things that get wiped in an intrusion are the logs

Try wiping logs printed out on a matrix printer...

Re:One recommendation

With physical access, all bets are off at the best of times.

Printing logs is a good idea in some circumstances; you will have a record of all actions and a remote intruder has no method of editing those logs. The main downside is the amount of paper it could use, plus it has to be kept supplied with paper & ink.

Re:One recommendation

To make sure my logs are secure, they are automaticly:

• posted to several usenetgroups
• posted as random comments to /.-stories (Along with some random anti-SCO/Microsoft propaganda so I don't get modded down and don't lose karma :)
• uploaded to the linux kernel CVS
• sent as email to all my friends

This way they are mirrored as many places as possible and hopefully cached by Google. Wipe that out!

Great

Right as I am downloading Debian.
I will check the md5sum.

Anyways Something to be said about passwords.. I am getting sick of passwords.. I have looked at the RSA keychains, But they cost too much.

So I ask are there any good one time password systems out there. That are opensource.. I have looked at going with smart cards but again with the money. (not to mention overkill for me)

I have found a few but none with a keychain.. I don't mind paying for a keychain, but I want the software to be opensource.

Re:Great

Probably the closest you'll get to a "good" system would be something like S/Key or Opie