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

Comments

Password was *sniffed*

[enosys]

Apparently the password was sniffed . 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*

[radargeek]

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.

Re:Great

[Qzukk]

Probably the closest you'll get to a "good" system would be something like S/Key or Opie (debian packages: opie-server, opie-client, libpam-opie - Use OTP's for PAM authentication) for generating and using a one-time-pad of password systems. The issue in this is that you must generate the pad in some secure fashion, if someone sniffs your pad because you downloaded it over the network, you've lost.

You could easily keep a pre-generated giant pad itself on a usb drive or something similar.

SuckIt Exploit

[Elik]

I have dealt with this rootkit for nearly 4 months when it first appeared. The fairly safe methods for avoiding this is by 3 steps which I have used and it works well since then.

Move the /tmp to it own partition and set it as noexec, nosuid and give it plenty of space, around 200 to 500 megs for it.

Patch the kernel with either Grsecurity or Openwall Patch on 2.4.22 kernel and set it as mononthlic kernel, not modular with no open hooks for adding additional modules.

Then I installed the suphp module for PHP to run scripts as users instead of nobody, especially when people trying to exploit it. I get it at www.suphp.org and it works extremely well. Since the changes, I haven't seen any rootkits being successfully implemented on the servers I admin. And note the fact that I manages over 260 servers for various clients points to the track records.

Re:What's up with these anti-Linux attacks?

[sqrt529]

It was bitkeepers cvs, not kernel.org which was compromised.

Two useful utilities to flush out the rootkits

[Taco Cowboy]

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


Kernel Security Therapy Anti-Trolls

and

Kernel Security Checker

Have a nice day !

Re:Human Error

[hdw]

It is sad to see one weak password responsible for such a breach.

Eh? Why is everyone talking about a weak password?
The article says sniffed password.

I assume that they're not using cleartext password authentication which means that it wasn't sniffed on the wire, it's was sniffed on a (compromised) box the some user used to log in.
And if the clientbox is compromised it doesn't matter if you use password or a passphrased key.
Even keeping your key on something removable (like an USB keychain) doesn't help you, the cracker can easily snarf both key and passphrase :(

The only way to bypass that would be an external pinpad style device.

//hdw

Re:Debian physical site security?

[amck]

The primary Debian machines are in colo facilities
in the US and Netherlands (there are buildd machines available to debian developers in various locations). The machines are beefy enough - HP
recently donated a server with 48 GB RAM, for example. I believe the bandwidth out of ftp.debian.org is Gigabit ethernet (and having only that to the mirrors will be a bottleneck
when sarge is released!)

So, no, they're not in some dudes basement; we have good facilities courtesy of our sponsors.

- Alastair

Re:biometrics

[God! Awful 2]

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:What could be done better...

[wichert]

The 'almost' is explained later on in the article. The one missing update was a postgres fix which could
never have been used to gain root privileges