Slashdot Mirror


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

24 of 545 comments (clear)

  1. Human Error by jefbed · · Score: 5, Insightful

    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.

    --
    AntiRight, download now!
    1. Re:Human Error by Tyler+Eaves · · Score: 5, Funny

      Random passphrase?

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

      --
      TODO: Something witty here...
    2. Re:Human Error by SugoiMonkey · · Score: 5, Funny

      I say we cut out the user.

    3. Re:Human Error by Anonymous Coward · · Score: 5, Insightful

      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.

    4. Re: Human Error by Black+Parrot · · Score: 5, Insightful


      > 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!

      --
      Sheesh, evil *and* a jerk. -- Jade
  2. Re:Boxen.. by Stormie · · Score: 5, Funny

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

  3. Diebold, take note by RealProgrammer · · Score: 5, Insightful

    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.

    --
    sigs, as if you care.
  4. One recommendation by heironymouscoward · · Score: 5, Insightful

    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.

    --
    Ceci n'est pas une signature
  5. Password was *sniffed* by enosys · · Score: 5, Informative
    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.

    1. Re:Password was *sniffed* by radargeek · · Score: 5, Informative

      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.

  6. Re:Boxen.. by AndroidCat · · Score: 5, Funny

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

    --
    One line blog. I hear that they're called Twitters now.
  7. Re:In a nutshell - somehow by Kulic · · Score: 5, Insightful

    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.

  8. Human Error or faulty security models? by Anonymous Coward · · Score: 5, Insightful

    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!

  9. Ammended for the rest of us: by Anonymous Coward · · Score: 5, Funny

    Law #1: If Bill can persuade you to run his program on your computer, it's not your computer anymore.

  10. What could be done better... by rxed · · Score: 5, Insightful

    Quote: "All the compromised machines were running recent kernels[1] and were
    up-to-date with almost all security updates[2]."

    Well, it seems that 'almost' just isn't good enough. Perhaps there is more to the break in (like unknown holes)?

    Sniffing passwords? They must be using 'almost patched' version of SSHd.

  11. Re:#1 on Ten Immutable Laws of Security by prockcore · · Score: 5, Funny

    Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore.

    That's why I've been saying for years that all my computers are owned by Bill Gates.

  12. Unknown Debian exploit? by t0ny · · Score: 5, Funny

    Im sure glad my network runs on Windows!

    --

    Manipulate the moderator system! Mod someone as "overrated" today.

    1. Re:Unknown Debian exploit? by flacco · · Score: 5, Funny
      Im sure glad my network runs on Windows!

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

      --
      pr0n - keeping monitor glass spotless since 1981.
  13. local root == remote root by Markus+Registrada · · Score: 5, Interesting
    This is a good demonstration that the distinction always made between local privilege-elevation bugs and remote exploits is academic hair-splitting. It's rarely difficult to get unprivileged access through a buggy non-privileged service. (Web-server plug-ins are a reliable source of entry points.) Once you're in, privilege elevation takes you the rest of the way.

    Certainly the distinction is useful to security students and analysts, but it's misleading for everybody else. "Oh, that one's just a local exploit; not so bad." The OpenBSD advocates promote the fallacy: "only one remote exploit in this millennium!" (or something like that), encouraging us to ignore almost equally damaging exploits in non-core services that provide access to local accounts and more damaging attacks.

    There's a similar fallacy in distinguishing security holes from other bugs. Without a depth of analysis that hardly anybody can ever afford, almost any bug might actually be a security hole, too. The OpenBSD people get this one right -- to them, any bug is a security hole until proven otherwise, and they encourage running latest versions -- but almost everybody else gets it wrong. When I fixed a double-free segfault in lib[mumble], nobody posted security warnings about every program that relies on it. despite that double-free bugs can often be exploited.

    Debian gets this wrong, and very selectively backports only proven security holes, ignoring the myriad bugfixes that might just as easily be security holes as well. To find holes in stable-branch services, just look for bug fixes in later versions, particularly in libraries used by those services. Failing that, look at new features added shortly before the library-version used. Chances are the last new feature added has bugs that haven't been noted yet, and that might be exploitable.

    This might be a good place to mention that the CVS codebase is almost irreparably insecure. The practical implications are: (1) A remotely-accessible CVS server should never be run on a host that does anything else that matters, or that has access to anything else; (2) An anonymous CVS server should never be the same CVS server that is used for checkins, or even run on the same machine. The pserver should be a slave that only gets read access to a copy of the archive. (3) Checkins on remotely-accessible servers should result in patches logged to another archive kept on another, not-remotely-accessible machine. Patches from that server should be posted to the mailing list.

  14. Sad day for Debian by swordsaintzero · · Score: 5, Interesting

    As long as a machine is connected to the internet there is going to be a method to compromise it. My question is this why Debian? They are the only Linux distribution that is truly built by volunteers to gain any mindshare of real note. (not sure about slack so please dont sick bob dobs on me) This is not imhop the work of rank amatuer crackers with there first root kit. These were servers being run by experienced admins using a distro known for stability which when patched and up to date usually means somewhat difficult to hack. I seriously doubt these guys were running winders attempting this either. Wtf is happening to the community when people with talent are attacking a distro that yet again imhop doesnt suck. These guys need to be found and buried. Not by the police but by the commmunity. Last but not least (places tinfoil hat on head) could this have been funded by M$ trying to discredit linux. I cant see the glory angle so its got to be money or power. (no glory in getting called a dick when you tell your friends what you did)

    --
    Panel F, Relay #70
  15. Re:#1 on Ten Immutable Laws of Security by Gleef · · Score: 5, Insightful

    Not that I even like Microsoft's security list, since it's very Windows-centric, I'll bite.

    Law #1 doesn't apply here. The intruder sniffed a password, and ran his own software. As far as I know, nobody was tricked into running malicious software. Law #1 should read, for real OS's
    "Law #1: If a bad guy can persuade you to run his program on your account, its not your account anymore."

    The first failure, as per this list was Law #5 "Weak passwords trump strong security." Someone didn't properly protect their password, this gave the attacker their foot in the door.

    The second failure was the unidentified privilege escalation. This doesn't appear to fit any of the laws (they appear to be written assuming privilege escallation is trivial, I guess that says something about Windows). Except perhaps, Law #10: "Technology is not a panacaea". Just because we run well designed software that has few security holes doesn't mean that we run perfectly designed software that has no security holes.

    Occasionally something slips through the cracks, like here, and it's good to know that real people are paying real attention, and that there are effective ways of bringing necessary systems back up in a trusted fashion. Eventually, this escallation will be found, fixed, and machines patched.

    --

    ----
    Open mind, insert foot.
  16. SuckIt Exploit by Elik · · Score: 5, Informative

    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.

    --
    -- Amazing how the Internet still humms along.... -- Dispite all the flaws of Micro$oft in their software!
  17. Re:In a nutshell - somehow by Anonymous Coward · · Score: 5, Interesting
    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.

  18. Re:So much for unbiased Slashdot by jadavis · · Score: 5, Insightful

    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.

    --
    Social scientists are inspired by theories; scientists are humbled by facts.