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

Password was *sniffed*

[enosys]

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*

[Anonymous Coward]

The password was sniffed by the trojaned sshd on an unrelated machine.

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.

The root of the problem

[Anonymous Coward]

The root of the problem is with the root account.

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

I would think that it's time for the big players 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!

Re:One recommendation

[Malcontent]

Why not run something like LIDS [lids.org]. You can lock access to your logfiles so that only certain processes can run them.

It looks like a bit of work to set up and administer but you'd think that an organization like Debian would make sure all their computers would be running it.

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:Boxen..

[Li0n]

Debian = Debra + Ian Murdock

Re:But wait....

[Anonymous Coward]

Not only isn't Akamai just a proxy/cache server, they just hold signed files. If someone managed to hijack/compromise those, the downloaded updates would not verify on the user's machine, so it's pretty much a void argument.

Re:One recommendation

[SuperQ]

that's the whole point of LIDS.. LIDS provides kernel hooks to add extra level of access restrictions to the root UID. read up on LIDS before you speak.

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 [freshmeat.net]

and

Kernel Security Checker [freshmeat.net]

Have a nice day !

Re:ldap?

[Anonymous Coward]

The accounts are stored in LDAP tree at db.debian.org[1]. However, when the compromise was noticed, all accounts are locked down, and they still are. Which is very very bad with regard to the continous developement of the Debian distribution, as I and all other developers can't log in to the developement machines, package uploads aren't being processed, many crucial internal services (such as testing propagation) are down.

That's what he meant by his comment - the Debian Project is effectively halted by this - and obviously that can't go on for long.

[1] You can obtain a listing of these by running the command ldapsearch -h db.debian.org -x -b dc=debian,dc=org '(objectClass=debiandeveloper)' from a internet-connected host.

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

SELinux

[Anonymous Coward]

Hmm... maybe SELinux would have stopped this? Doesn't it prevent hooking into system routines? If so, then it's a great excuse to see better SELinux support in debian :)

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

Re:Something big is missing

[wichert]

One if the reasons we are taking so long with all this is that we simply do not know how exactly root was gained. When we do do and we have a fix we will gladly reveal that along with a security advisory detailing how you can protect your systems as well.

Re:Human Error or faulty security models?

[Coryoth]

2.6 does indeed have the LSM integrated in - that's step of abstraction up from the original SELinux. It is essentially a set of appropriate hooks into the kernel for running SELinux style security. There are actually other packages (LIDS for instance) that use this system.

The end result is: We will soon have a very strong security model built in to the standard stable kernel. The sad thing is that it will be off by default, and you will still need the set of userland tools that use it.

We have an excellent opportunity (with the 2.6 release) to seriously increase the security of Linux systems. People need to start promoting LSM modules and programs NOW so that we can get this to be the default state of most installed Linux boxes.

Jedidiah

Re:biometrics

[ChaosDiscord]

Well, the manufacturers of palm/retina scanners generally do include a feature that detects if the bodypart being scanned has a pulse.

One would hope so, but the evidence [schneier.com] isn't as promising.