Newsletters Select newsletters below and click the button to sign up!
Internetnews BloggersRecent Entries
Archives
Monthly ArchivesSearch The Blog
« GhostNet cyber-spy network busted by Canadians |
Sean Michael Kerner Blog
| Red Hat Fedora 11 Linux hits beta. Hail Leonidas! »
Red Hat Fedora reveals details on intrusion attack From the 'now we know' files:
Last August, Red Hat's Fedora project announced that its servers had been compromised -- now 6 months later (after an exhaustive investigation), Red Hat has revealed exactly what happened. According to Red Hat Fedora Project Leader Paul Frields, the compromise did not come by way of any vulnerable software on the Fedora servers but rather by way of an SSH key that wasn't properly secured. The SSH key belonged to a Fedora administrator and was used by the attacker to build modified version of openssh and rpm. That's pretty serious - as it means the attacker could have potentially messed up all Fedora packages -- but that's not what happened in the end. "The intruder did deploy the modified packages, and the modified SSH package may have captured passphrases for a short time," Frields reported. "However, the investigation supports the conclusion that the modified packages were discovered before anyone accessed the system to sign any packages using the modified RPM package."
So it's a bad news/good news scenario, in that the Fedora server were
in fact compromised by an attacker, but Fedora was able to catch the
issue quickly.
"To reiterate, our analysis supports our initial findings that the Fedora Project infrastructure delivered no software compromised by the intruder to any of its mirrors, or the master repository from which they synchronize content," Frields added. "Our investigation also shows that the intrusion affected only a few internal Fedora infrastructure servers. Most of the mitigation work done by the Fedora Infrastructure team was precautionary, and allows us to have higher confidence in our present and future work."It's also good news that no Fedora software was directly vulnerable -- as that would have meant that millions of Fedora servers around the world might have been vulnerable too. What this case is in its simplest form is a case of an administrator who wasn't fully secured and wasn't using an SSH passphrase (which might have mitigated this whole issue altogether). Fedora is now requiring all of is system administrator members to use SSH passphrases. In terms of hardening Fedora's infrastructure, Frields noted that they have additional SELinux, audit and intrusion detection capabilities throughout their systems. Bottom line in my view is that of course no one ever wants to be cracked - but Fedora has done the right thing here doing a full investigation and being open about what exactly happened. The lessons for all server administrators are obvious -- make sure you've got proper intrusion detection/prevention capabilities and make sure that your administrators are following proper best practices. 0 TrackBacksListed below are links to blogs that reference this entry: Red Hat Fedora reveals details on intrusion attack. TrackBack URL for this entry: https://swarm.jupitermedia.com/mt-tb.cgi/7766 4 CommentsLeave a comment |
||||||||||||||||||||||||||||||||||||||||||||
The correct term is cracked, no one wants to be cracked.
*SMK* you are correct (I had hacked originally) and i've made the change. ThnX!
KUDOS TO FEDORA
I LOVE THAT ENCRYPT ON INSTALL EVERY DISTRO SHOULD HAVE IT !! THANKS TO THE FEDORA ,RED HAT TEAMS FOR NIPPING THINGS EARLY
I AM IMPRESSED!
I can't stress that well enough. Whereas most companies, institutions and organizations would have let the issue vanish into obscurity, Red Hat actually did follow through on their promise to perform the requisite investigation and open up the results to the public. Having the information out there helps people understand and avoid the same pitfalls.
My question now, though, is what the exact details of the exploit was. What exactly do they mean by "an SSH key that wasn't properly secured" so that I'd know that my keys are properly secured? How was the private key copied?? On my system, $HOME/.ssh/ is only user-accessible and the files inside, as well. Was the same true in the exploit case?
This is the one case where Selinux does not help: rpm itself needs access to everything and to be able to manage Selinux access rights, that means that if you install a compromised rpm package it will be able for instance to not warn you that the package you are installing comes from a non kosher source or to remove SElinux restrictions from a daemon so the when the attacker remotely exploits a security hole he can access evything instead of being restricted to the files needed by the daemon.