Backdoor Found In UnrealIRCd Source Archive 174
l_bratch writes "A malicious backdoor was added to the UnrealIRCd source archive some time around November 2009. It was not noticed for several months, so many IRC servers are likely to be compromised. A Metasploit exploit already exists."
It's nice that they're honest. (Score:5, Insightful)
Re:It's nice that they're honest. (Score:4, Insightful)
Well, unless you're Google, in which case you're raked over the coals and accused of being at the right hand of the devil himself...
The remediation advice is wrong (Score:2, Insightful)
FTA, "Obviously, you only need to do this if you checked you are indeed running the backdoored version, as mentioned above."
A skilled attacker will have replaced md5sum so that it returns the hash that corresponds to the good version, and in general installed a rootkit. The remediation advice they provide is broken.
If you have installed the affected software, you should probably assume you are owned, regardless of what any local tests tell you.
Re:Open source (Score:4, Insightful)
How is it a weakness? It's a weakness of the admin, but being open source didn't somehow make it easier to get malicious code into the source. People could just as easily hijack a binary file (and there's a good chance it would go unnoticed for a longer time).
Re:The remediation advice is wrong (Score:3, Insightful)
If you're running an ircd as root you deserve whatever you get.
Re:The remediation advice is wrong (Score:4, Insightful)
Yes, of course. Because its not even conceivable that the intruder has any local exploits.
Re:Windows safer than linux (Score:3, Insightful)
Re:Open source (Score:2, Insightful)
I'm implying that anyone who manages to get commit rights, or even a contributor who's good as obfuscating code, could implant a backdoor into a project. Remember the Debian SSL fiasco? Well, that sort of thing could happen maliciously. In a closed source development environment it's harder (note, I didn't say impossible) to get this sort of thing in, as the effort and/or expense required to inject a mole into the developer circle is higher and the personnel are typically more carefully vetted.
However, the strength of open source is that there are many people looking over each others' shoulders. In a closed source environment, if you manage to get your mole into an area of code development where there are only a small number of developers, well-hidden and obfuscated malicious code could stay buried potentially forever, as once those few guys move on (and they will in corporate land), nobody who comes after then will aggressively pursue legacy code as they won't want to break anything that's already working. Nothing short of a full code audit will catch it.
And thank you for making me explain myself in full.
Well yes... (Score:5, Insightful)
First, as others have said, the Unreal guys handled this intelligently and properly, so bravo for that.
Secondly, no offense to them, but the Unreal guys wouldn't have had this issue if they regularly verified mirrors. The Unreal guys have been less active in the past few years though, and their software is primarily used by many smaller networks, often with less experience as the IRCd is a bit slow and the codebase is long in the teeth (they're looking to replace this). Something like this was really bound to happen for their team. That said, still good work.
Thirdly, this is why IRC is never ran on its official low numbered port, but on 6667 - there is NO REASON to run IRCd as root - I don't care how safe you think the code is - it's too huge of a target.
So hopefully, anyone sane shouldn't have had more than a sandbox compromised, the patch the Unreal guys released will fix this, and we can all get on with stuff.
Just a few thoughts, oh, and IAAI and IAAIP (I am an IRCop and I am an IRCd Programmer).
Re:It's nice that they're honest. (Score:3, Insightful)
Re:It's nice that they're honest. (Score:2, Insightful)
Yes, because a single trojan in a server that:
1) no one uses (not a single user checked the hash of the download over seven months),
The hashes most probably _where_ checked by peopel, however they've been changed to reflect the backdoored .tar.gz on the website.
This is from the horses mouth a.k.a. Syzop:
[12:30:04] well the main site got hacked huh, so the md5sum on the website was reflecting the trojanized version
[12:30:18] but nobody checked the md5sum against the one mentioned in the announcement
Re:It's nice that they're honest. (Score:4, Insightful)
Embarassing, in that, "Yes we screwed up, and we shouldn't have." or embarassing as in, "Oh shit, open source really isn't any better than security through obfuscation!"?
If you mean the first, I'm with you. We all screw up - and sometimes we need a reminder that we can't duck, or blame on someone else to keep us on our toes.
If you mean the second, well, I call bullshit. Several people have already pointed out that closed source shops are frequently the victims of malware. You can find a half dozen gadgets or softwares that have been SHIPPED FROM THE FACTORY with malware of some kind, just in the last year.
Personally, I really prefer the situation at Unreal. It's open source. Everyone who gives a small damn had the opportunity to check it out. Anyone could have run any number of monitoring tools on the software, and caught it doing it's thing. When it was found, the administrators made an announcement. I like honesty and open communications.
It's a helluva lot better than, for example, a closed source shop pushing an update to your telephone which opens your communications up to government monitoring. The only way THAT was discovered, was the relatively dramatic decrease in battery life immediately after the update was pushed.
To each his own though. Those who put their faith in corporate masters are welcome to buy only proprietary stuff. I'll go with open source whenever possible!!
Re:It's nice that they're honest. (Score:3, Insightful)
A common way of mapping wireless networks is using software like Kismet, which is in fact what Google used, and which in its default configuration saves all packets received. If you claim it must be true that "some evil is involved" because they used standard widely used software rather than your 3-line script, you don't know what you're talking about.
Re:Well yes... (Score:3, Insightful)
It's there for a reason.
If a server is compromised, the "normal" ports cannot be set up as listeners without also escalating your breakin.
Re:It's nice that they're honest. (Score:5, Insightful)
3) was not included in the Debain repos, despite there being a willing maintainer, because of poor code quality- see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515130 [debian.org]
The lack or presence of a software in Debian does not mean anything about its quality.
Unfortunately there are are people, among the Debian devel, who are more political assholes than proper developers.
An example of utter garbage present in Debian is pdns [debian.org] (the software itself collapses after running for few hours, even minutes, depending on your load). Yet, each new Debian release contains a new version of that software. -- And that's not the only case.
Re:Well (Score:3, Insightful)
the more efficient way is to sign the hash.
Digital signatures actually ARE signed hashes. So I'm not sure what you're trying to invent there (and how it would be more efficient).
Re:Well yes... (Score:4, Insightful)
I am looking at it the other way around. There is not really any reasons now to require root access in order to listen on ports below 1024.
Amen. I'm glad I'm not the only one. In this day and age, where anyone can run a Unix box, the whole "root under 1024" thing is redundant. http://calum.org/posts/root-to-bind-to-ports-under-1024 [calum.org].
Make it a damn kernel config option at the very least, and let me decide.
Re:Well (Score:3, Insightful)
If you want to use a hash alone, you only check integrity, but not authenticity. The attacker may alter the hashes published on your server and you won't detect that.
And again, if you meant signed hashes, then that is exactly what digital signatures are. Signed hashes of the files. The recipient hashes the file, compares the hashes, and verifies the signature of the hash. That's how digital signing works, my friend.
Your posts contain no suggestions for improvement, but they may even weaken your security.
Re:It's nice that they're honest. (Score:3, Insightful)
Who's been claiming that things like this couldn't happen?
This is the reason that both deb's and rpm's went to signing all packages, and the reason that best practice requires that signatures not be hosted on the same server as the binaries. (OTOH, I've got to admit that these "best practices" aren't always followed. And I'm currently trusting a package from one site that doesn't sign it's debs with a signature I'm willing to trust. But if I were conscientious I wouldn't use that package.)
So, yeah, this is the kind of thing that "best practices" are intended to prevent, and we don't always follow the best practices, because they are less convenient. But if we care, we can tell whether best practices are being followed.
Now tarballs are a different kind of beast. Perhaps Slackware has some way to deal with the problem of tarball authentication that I don't know of. But lacking that I always feel that using a tarball is taking a risk. And that one should have one's eyes open to that problem. With a tarball you don't know who you're trusting. If you use hashcode verification stored on the same server as the tarball, then the hashcode doesn't prove anything. (For that reason Python always posts both the MD5 and the pgp key on their website [A separate server from their download server]. This is, at least close to, best practices for tarballs.)
Re:It's nice that they're honest. (Score:3, Insightful)
The GPG check can also fail if they just get you to add their private key into you list of trusted keys. This is a point that has occasionally bothered me. There doesn't seem to be any decent way to authenticate that the key you're being asked to add is one that should be trusted. Web of trust was a decent approach, but it didn't scale. It demanded personal meetings and the new person being vouched for by the old one. When it got expanded onto the web, the process got broken.
Someone needs to start thinking seriously about this. Someone with decent knowledge of security, and a knowledge of FOSS procedures. And someone friendly to FOSS. And with decent political connections within the community.
Re:It's nice that they're honest. (Score:2, Insightful)