Slashdot Mirror
BitchX 1.0c19 IRC Client Backdoored
JRAC writes "A recent Bugtraq submission has indicated that the popular IRC client, BitchX, contains a backdoor. So far, only certain 1.0c19 files, downloaded from ftp.bitchx.com are reported to contain the malicious code. The BitchX developers have been notified, so hopefully a fix will be issued soon. Looks like irssi wasn't the only one ;)"
If BitchX was some sort of closed-source product, how long might this have taken to show up? Many eyes lock down all backdoors.
Anti-GPL people (read Microsoft and their lackies) may try and take this as a weakness in OSS, but I look at it as a strength. If one of their developers gets something like this into one of their products (either on his/her own or with the blessing of the company, the world may never know). With OSS, it's out in the open for everyone to see/fix.
About 5 seconds into install, when the closed-source firewall running on the closed-source OS catches the closed-source IRC client trying to create the reverse telnet connection.
Because most companies have marketing people to hit them on the head and say no, this is not appropiate.
Feminism is the radical notion that women are people.
GNU/Linux downloads should be in signed archives like Netscape JAR files. JAR files are basically ZIP archives with a signature file stored inside the .zip in a standard place. When you unpack the archive, the unpacker checks the signature the same way a browser checks an SSL web site.
JAR files use a certificate chain ending in a certificate authority (usually a commercial one) but maybe the signed-download scheme could be signed against a certificate on the official developer's website. Of course that wouldn't be unspoofable, but it would be as secure as the current scheme of having a PGP public key on the developer website and signing against that. The main benefit is the checking would happen automatically, so it would be much harder to put crap into downloads. If someone makes a modified version, they would have to sign it themselves (with a signature pointing back to their own website) or else the unpacker would print a message saying the code was unsigned and the user should check it carefully before using it.
Interesting how there's a fairly serious bug in slashcode that was exploited yesterday but they don't publicize that. At least they fixed it quickly, but if you guys like to point out other peoples bugs, how about shining the light on yourself once in awhile? I'm sure other slashcode sites would have liked to have known about it.
SIG:Slashdot: indymedia for nerds.
Well, perhaps they wanted to spread it to dumb home users but not to anyone more professional. Perhaps they wanted to go longer without being caught.
Perhaps it's actually a DNS issues, and it's directing some people to a dummy server.
Viruses and worms have been mostly merely malicious. Same with cracking. And the malice involved is not very great. But what if people get serious about stealing data?
A few years ago I had an epiphany one night, and waltzed into a network security company the next day.
"Look", sez me, "Inbound connections and activity are, in the long run, not going to be the real threat. The real threat is trojaned applications that mine for data and somehow send it offsite. You need to be monitoring outbound activity for appropriateness. For example, eventually you're going to see corporate espionage where someone writes an attractive and actually useful little app, then social engineers a targeted person within an organization to download it and compromise security. This is just an example of the general problem."
They were actually pretty impressed, but the company's strategy was deliberately to avoid concerning itself with viruses or worms (more specifically, they wanted to stay only on the servers, monitoring network activity in a sophisticated manner). But it seemed to me that this was a natural extension of their product and technology. And they thought I was a pretty bright guy, but they didn't know what to do with me. Well, anyway. The irony is that they were only a year or so later bought by one of the big antivirus firms, mostly just to acquire their technology.
In this particular case, the BitchX irc app, it looks like an outside source injected some backdoor code into the application, and hacked the ftp server to distribute it in a selective manner, presumably to help lower the risk of detection. A lot of effort for not that great of a payoff, really. Here, as is often the case, it's mostly about proving how clever you are.
But we're starting to see rudimentary examples of what I was warning about with spyware and other apps that make outbound connections that are in some sense illicit. Firewalls monitoring outbound connections can only be so successful given that they're always going to let some through. I know that some of the client based firewalling/monitoring software looks at connections on a per application basis. That's a start.
Personally, my inclination is that we need a networking monitor that operates like a virus scanner -- on the client, in the background -- that accesses a secured database of allowed application to outbound connection mapping, with secured handling of exceptions or new applications referred to a security admin (ideally) or an admin. This way we don't have to use a brute-force approach that simply locks down all allowed applications and allowed outbound connections in a non-specific, usability-destroying way.
But whatever the solution, I have little doubt that this will be a growing problem which will make a transition from script-kiddie nuisance cracking to something much more sophisticated. Although I could be wrong.
I see your point. Still, would you say the same for all the Windows users that did not patch there IIS code when Red Code hit?
Anyone who has a box attached to the internet has a responsibilty to others. They have to be held accountable for something. It is true that nothing is crack proof and you can't expect people to have perfect security. However, they have to take reasonable steps to protect themselves and others. But, what are reasonable steps? Who can judge?
If someone breaks into a house and steals a handgun, that was not locked up securly, and then uses it to commit armed robbery; should the home owner be responsible for the robbery? Of course not. However, the home owner should be responsible for improperly storying his handgun. This is the kind of responsiblity I'd like to see. Did someone take reasonable steps to secure their server?
As for the IP in question at the beginning of this thread. At this time, I don't know any details so I'm not casting any blame.
UNIX/Linux Consulting
Well, what if your house was a known fire hazard that was like a fire stacked with tinder in the middle of a summer drought?
That is how I would see the house if it were an operating system with unpatched vulnerabilities in it.
Are you responsible if it burns down your neighborhood?
No answers here.. just an interesting question to mull over.
Jeremy
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
at which point it will no longer be usefull to anyone but idiots like you.
they have to be manually verified, and hardly anyone bothers
Guess what: I bother, and everyone I know bothers. Is "hardly anyone bothers" a fancy way of saying "I don't bother"?
Jailing a browser is tougher, but an IRC client should be easy. Somebody who's into IRC and security should do this as a demo.
The developers of BitchX did *NOT* put malicious code in the source. For one thing, there were two versions of the 1.0c19 source running around. It also seems that the security on *.bitchx.org was never even compromised. The problem lies somewhere with a 'man-in-the-middle' changing some DNS aliases somehow. This is why some people were able to download the real version that was actually released, and some people got the 'hacked' copy.
Also, even though the box doesn't appear to be compromised, it could happen. I hope one of you kids out there is the first one attacked when a new apache or ssh bug is found. You can never be completely secure, especially when you are running anonymous servers for people to download programs.
kthx.
ice-man@efnet.
How do you know the outbound connection isn't just a smoke screen? The point is you've already executed untrusted code, any number of things could have been done to your system without your knowledge. Stopping a single vector is not a solution and gives a false sense of security.
Of course, you wouldn't know anything about this, would you?
Oh yeah, gang rape is fucking hilarious until you're faced with the prospect of spending a few nights in jail.
pr0n - keeping monitor glass spotless since 1981.
> Very few sites are running Slash from CVS,
as the CVS tree is a pre-alpha version. We have not yet even
stamped it with a development release number (which will be 2.3.0
as soon as we feel it is stable enough for bleeding-edge users).
In spite of the fact that you haven't "stamped" the version with a release number, you had gone ahead and deployed a version of software which was open to and was, in fact, visibly exploited by XSS flaws. You then pretended that it never happened. No "whoops, we screwed up, here's what we did wrong so the rest of you can avoid our pitfalls" on the front page of the site that was exploited, no note on slashcode.com that people who have deployed the same version that you deployed are open to exploitation as well.
> Sites running CVS should stay as current as possible at all times,
of course. The courageous admins of those sites should probably
hang out on the IRC channel given on the slashcode.com homepage
(#slash on irc.openprojects.net).
This doesn't reflect reality. Many people pull down a CVS snapshot and run with it, but it's nice to know that you think that admins should spend what little free time they've got idling in IRC just in case there's another bug that you don't feel like publicizing is exploited.
Now that I think about it, doesn't that sound a whole lot like "security through obscurity"?
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.