Red Hat, Fedora Servers Compromised 278
An anonymous reader writes "In an email sent to the fedora-announce mailing list, it has been revealed that both Fedora and Red Hat servers have been compromised. As a result Fedora is changing their package signing key. Red Hat has released a security advisory and a script to detect potentially compromised openssh packages."
OpenSSH bug? (Score:4, Interesting)
when? (Score:2, Interesting)
Last week? Does that mean earlier this week, or the week before the week I'm in? At what point in whatever week was last week? If I did an install/update after a certain date am I covered?
It would be nice if they weren't so vague about the time frame. Maybe it is to encourage people to check and not assume they will not have problems, but in a situation like this, the more accurate a picture I have of what is going on, the better I feel.
roughly 30 kernel 0dayz circulating (Score:2, Interesting)
I can confirm that roughly 30 kernel 0dayz circulate in the underground. Working for all kernelz 2.6.X up to 2.6.27-rc3 :)
happy birthday.
Re:Nothing to see here. (Score:2, Interesting)
Or we could infer that the system was used for its purpose by the attacker. He signed those packages. Redhat looked at the logs, no other packages were signed. So the passphrase is still very likely to be save.
Probably a dictionary user/passwd (Score:1, Interesting)
While it seems likely there are some flaws in SSH (if you know, you know) that won't be posted here, the most likely attack was probably from those lame SSH dictionary scans on port 22. This is usually just an extreme annoyance to admins who must provide port 22 service and haven't heard of 'SSHguard'.
Since it seems impossible to educate people about good pass words, these lame attacks will sometimes succeed. Any corporate admin should run 'crack' often. Moving SSH to any port other than 22 will eliminate 99.9% of these lame scans. SSH is secure for today, if used properly. All suspected exploits of the code itself are unproven.
Nothing to be alarmed about here. Problems that affect corporations are unlikely to affect knowledgeable users. To them, computers are 'a necessary evil'. To us, that is our thing.
Re:Goes to show (Score:5, Interesting)
There are plenty things that can be done.
Mounting /home with noexec
Using the grsecurity patch, which can deny execution of files not in directories owned by root, as well as usage of network sockets.
Using SELinux
The tools are there. All that's needed is to use them.
The need to download random binaries to your home directory and run them is infrequent in Linux. The most frequent case is application installers, but many of those need root access anyway (nvidia drivers for instance), and most come with the distribution. A way to fix the occasional need to do this would be a sudo-like tool that needs to be used to execute a file, but doesn't grant root privileges.
Re:Nothing to see here. (Score:4, Interesting)
God, I seriously hope they don't have the passphrase saved so that you don't need to type it in to sign a package. If that is the case their security is very lax. Also, if it's saved, it almost certainly is compromised, because it's stored on disk somewhere. It would be trivial for the attacker to pull it out of whatever script or text file it's saved in.
Re:Nothing to see here. (Score:5, Interesting)
Re:Goes to show (Score:3, Interesting)
"Spammers need relays to send their spam through. You can run a relay just fine as a normal user"
Not if you don't have access to the firewall settings which will open the port that allows someone to connect to your relay.
"You can mess with the internals of Firefox without root access too, through plugins. Easy to put a password stealer in there."
Yes, but without access to the system FF folder, that plugin will go in your per-user plugin directory, and will only run for you. So only your passwords will be stolen, and not those of anyone else on the computer.
"Or you could mess with your desktop settings so that when you try to launch a browser, you get a compromised version instead."
Again, only works for one user.
Of course, the "only works for one user" argument is better if presented in reverse. If your less-computer-literate kid/spouse/parent can't accidentally run code that sets up a visible relay, or installs a system-wide password sniffer, or messes with your desktop, then your desktop/browsing experience will not be fucked with no matter what they accidentally do.
Furthermore, you'll be in a position to be able to clean their account up for them without having to wipe and reinstall the whole machine (including all your precious stuff) which you would have to do if system files had been cracked.
what i find interesting (Score:1, Interesting)
is that the hardware is a PCI card.
http://www.ncipher.com/cryptographic_hardware/hardware_security_modules/8/nshield/
Could that be flashed by software? Hope not.
Should be a dip switch on the card to disable/enable flash upgrade by compromised host PC.
Re:Nothing to see here. (Score:4, Interesting)
God, I seriously hope they don't have the passphrase saved so that you don't need to type it in to sign a package. If that is the case their security is very lax.
I don't know about anyone else, but I am surprised that their package signing machine is connected via a network to other machines.
Our code signing machine is locked in a cage and powered up only for purposes of code signing. Executables to be signed are written to a previously wiped USB drive which is attached to the signing machine only when packages are to be signed. The signing machine has not been connected to a network since before the keys were generated. The private key only exists on that machine and in a single separately encrypted backup.
I've always considered that to be a minimally paranoid means of keeping private keys private. Really paranoid would be "signed on one machine, checked and signed again on another machine."
What the compromised packages contained? (Score:3, Interesting)
Our RHEL5/x86_64 system has been affected by this problem: I have ran the script from Red Hat openssh blacklist page [redhat.com], and found that all four openssh packages (openssh, openssh-clients, openssh-askpass, openssh-server) had their checksum on the blacklist. I took the server down, created a backup snapshot of the root disk, and I am currently reinstalling it, while checking other volumes and the root volume snapshot for any signs of intrusion.
The most annoying thing is that Red Hat remains silent on the main problem: what the compromised packages contained, how to determine whether the possible attacker exploited the access offered by those packages or not, when exactly were the packages signed, what other precautions to do on other servers (notify users which use the same password as on a compromised server, check for other modified binaries, etc.). I have verified that I had a trojanized binaries on my system, but apart from that, it is not clear what else the possible attacker managed to do.
Red Hat says the packages were not distributed over RHN, so I wonder how I got them. I had another repository in my yum.conf: rpmforge. Maybe this was the source of the malware. My syslog (even a copy on a syslog server) did not say anything about upgrading openssh in the last month or so. However, on Aug 15 it upgraded the YUM RHN plugin. On the same day our dovecot stopped responding, saying the time went backwards (and yes, there was time move several weeks back and then forward, according to dovecot log). Also the rpm -qi said the package was built on Aug 13 13:13:03, and signed five minutes later. However, the install time reported by rpm on my system was July 25 (which would corelate with the time slip reported by dovecot).
Did anybody else met the trojanized openssh mentioned in the advisory? Please share your findings.
Posting as AC for obvious reasons, sorry.
Re:Goes to show (Score:4, Interesting)
Not if you don't have access to the firewall settings which will open the port that allows someone to connect to your relay.
They don't need your relay. If they're running on your machine, they can fetch their payload and then start sending it out through your local MTA or configured SMTP server. If you can send e-mail, so can they.
Yes, but without access to the system FF folder, that plugin will go in your per-user plugin directory, and will only run for you. So only your passwords will be stolen, and not those of anyone else on the computer.
Given that most computers running Firefox these days are single-user systems, whether running Linux, OS X, or Windows 98.
Then consider Linux systems. Most systems these days are set up with sudo access, as is OS X. All the bug has to do is watch to see when you run sudo yourself, and then bam, it has a (usually) five-minute window to run itself as root and infect the rest of your system.
It can also grab your ~/.ssh/known_hosts and then reach out to those to see which ones accept your private key; install itself there, and, again, watch for sudo access. It's not hard for someone to go from there out to infecting every machine you have access to, and root on every machine you have root on, and potentially every system that every user on that system has access to, and so on, and so on.
Re:Nothing to see here. (Score:2, Interesting)
So then you're able to go get a ticket authorizing you to access the "signing software" and sign a package. Possibly using LDAP attributes to control what tickets you are authorized to have granted?
Possibly a poorly secured LDAP system (or frontend)?