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 ;)"
Local inmates confirmed that there was a problem with people entering into BitchX's backdoor. The suspect is a large man calling himself 'big mamma.'
Fault loves the past, worry loves the future, but content enjoys the present.
Am I the only one who felt a qualm about using this package because of the name?
BitchX - "I 0NZ0R J00, B1TCH!"
www.eFax.com are spammers
Is that when the vulnerability was first submitted they also submitted some interesting finds about the ftp server on BitchX.com serving trojaned and clean versions, depending on the originating IP, demonstrating that the server had been 0wned (more than likely).
Sad that the developers didn't notice sooner, and it makes you wonder how many boxes have now additionally been 0wned because of this.
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
From the post, "There is something very strange going on with the FTP server on ftp.bitchx.org. In some cases, it serves up the trojaned version; in others, the original, safe version. It seems to be client / client-behavior based (we're not sure exactly what)."
The post continues, "To add a little more to this; we've confirmed that if you come off of what appears to be a cablemodem/dsl IP you are likely to get a trojan'd copy. If you come off of a more static link, you are likely to get a clean copy."
Very strange.
Your reality is lies and balderdash and I'm delighted to say that I have no grasp of it whatsoever. - Baron Munchausen
This reminds me of the good old days, when people distributed like 20 different scripts for the irc2 client, all of which had some backdoor or another. Most of them listened for ctcp commands and would pass them directly to shell. CTCP GROK JUPE CMD ORD -- bonus points to anyone who can name all 4 scripts that had those backdoor commands. Then there were amusing tidbits like scripts that would flood anyone using the authors nick without the right hostmask. Then there was the 'Folder's Crystals' script -- it set your display to off, so you saw nothing even while you joined a channel and were saying, "I've just had all my files secretly replaced by folgers_crystals... let's see what happens!" (meanwhile, the script was executing rm -rf ~).
Of course, back then, you could blame people for running something they didn't understand, since it was on the order of getting a whack-a-bill game by email and just running it, whereas tainted downloads aren't quite as shameful, but ah, it does bring back the memories of the Wild Days of irc...
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.
... that Linux is gaining popularity among the crackers. This scenario is well known and has been explained for years. But it remained largelly theoretical until this year, it seems to me.
So, now we can expect people that mostly ignored us to come and crack our servers, install backdoors into our releases. They're probably going to write better viruses, too. I guess this is the price you pay when you become mainstream.
For years we've told the world how secure our OS was. Err, could be, once configured properly. The time has come, now, to do this.
Hey... nice "copy and paste" from the BugTraq posting...
u bscribe: <mailto:bugtraq-unsubscribe@securityfocus.com&g t;i vered-To: mailing list bugtraq@securityfocus.com
_ __
----- BEGIN BugTraq POST -----
Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
Precedence: bulk
List-Id: <bugtraq.list-id.securityfocus.com>
List-Post: <mailto:bugtraq@securityfocus.com>
List-Help: <mailto:bugtraq-help@securityfocus.com>
List-Uns
List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
Del
Delivered-To: moderator for bugtraq@securityfocus.com
Received: (qmail 31935 invoked from network); 2 Jul 2002 08:55:04 -0000
Message-ID: <20020702085626.305.qmail@web21002.mail.yahoo.c om>
Date: Tue, 2 Jul 2002 01:56:26 -0700 (PDT)
From: gcsb <gcsbnz@yahoo.com>
Subject: XSS in Slashcode
To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-UIDL: "[K!!WR\"!nkN"!NSF"!
There is a nasty Cross Site Scripting(XSS) vuln in
Slashcode. This was used a day or so go on
slashdot.org and resulted in most of the site being
taken down for an hour or so. The maintainers of
slashcode have patched the problem in CVS but have not
even mentioned it anywhere that I can find. This
leaves all sites using slash vulnerable to this
exploit.
An example exploit (incomplete) is as follows:
<p > onMouseOver..insert javascript here...>
I am dissapointed that the slachcode maintainers have
silently fixed this on slashdot.org yet made no
mention of the problem elsewhere so that other sites
can patch themselves. No wonder there are so many
"trolls" on slashdot.org...ah well.
If you run a site using slashcode, get the latest CVS.
That is all. Move along.
_______________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
----- END BugTraq POSTING -----
You didn't even reformat the exploit code so that it showed up properly... sheesh.
- Jester
Is this truly suprising? With the proliferation of "secret" functionality in everything from DVD's to Palm applications, it seems that a lot of developers take great delight in doing something "on the sly" that will get them noticed.
While the vast majority of these "easter eggs" are completely harmless, it's only logical to assume that they present an opportunity for malicous activities. I mean, who among us doesn't have SOME "H4X0R" history? Doesn't it follow that some of that will come out when the opportunity to put in a "gift" presents itself?
Also, this seems to me to be one of the down sides of the Open Source fight. Most of the accomplished hackers that I know are strong advocates of Open Source. It leads me to believe that most of the proponents of Open Source are or were at some time at least a script kiddie with delusions of grandeur.
Nobody I know has the time to actually check every line of code in a 200 Meg build for one or two lines of backdoor code, especially when the application is DESIGNED to make and break connections.
The Dopester
"Yes, I'm a Karma Whore, but I'm doing it to pay my way through school."
Many don't digitally sign their sources with a secure key, and thus there is absolutely no way to verify that those sources are the ones the developer intended to release.
Many think that a simple md5sum alongside the sources is enough. IT IS NOT. Any attacker who replaces the sources can as easily replace the md5sum, which can be generated by anyone.
A digital signature (I suggest using gpg) can only be generated by YOU if you keep it in a secure place, and use it to sign the sources. The public side of this key should be widely distributed and preferably signed (that is recognized) by third parties... the most trustworthy these third parties can be, the better.
After the huge attack on the network where such sites as Apache were hosted, other Apache projects which did not sign their packages suddenly started signing them. They got scared. You should be too.
A lot of people instinctively trust their dns resolutions (oops) and also think that if they go to http://www.mozilla.org they will get their favorite browser for sure. They are also wrong. dns can be spoofed under certain conditions, so they could be going to crackersR.us instead, and downloading a neat trojaned source, for instance.
The more a project grows in fame, the more it will become a likely target for these kinds of attacks, so the more need to a degree of responsability that should not be needed, but it unfourtunately is since the danger is ubiquitous.
Be carefull, be very carefull.
Also avoid using user root period.
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.
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.
Grow up, nothing is perfectly secure. Let's stop arguing which OS is vulnerable and find the evil do-ers who did this. Let's smoke them out from there parents basement and deliver a Slashdot can of whoop ass.
This post is quite inaccurate and we will be responding, also on bugtraq, momentarily. The author of the post did not contact the Slash development team, or we could have corrected some of his misconceptions.
Ah, yes. But the best was just colliding people, pre-TS. I wrote a script that made connection(s) to remote servers, usually far from you and your intended victim. If they changed nicks (which people often did to avoid being collided by a split off server rejoining their nick), the script would order the remote client to change nicks. Since the direct connection would propagate faster than the serverserverserver links (usually you'd pick a server 5+ hops away), by the time the nick change propagated there, it would cause a collision. Combine that with a traditional collide from a split server, and it was unavoidable. I remember taking #jews back from a bunch of nazis using that script.
The naming thing isn't necessarily an open source issue, more of a "started by one guy working out of his house who's got a messed up sense of humor and is giving the software away for free so he doesn't have to worry about sales" issue. The same thing comes up whether it's open or closed.
The popular emulator Dos/Windows "Nesticle" comes to mind.
"Tell me it aint so. Something insecure in a Linux/Unix app? "
Sheesh. For the first time in living memory we have had TWO security patches to install IN THE SAME WEEK! Omigod the walls are closing in! I must migrate immediately to Microsoft products, they'll save me!
Once more unto the breach, dear friends, once more, Or close the wall up with our American dead!
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.
Waste many months of otherwise useful time writing an IRC client. Make sure it gets really popular by adding neato colors. Oh, and give it a name that's sure to offend my mother.
Wait until everyone trusts me, then throw something slightly more interesting into the mix. Like a blatant back door. Hope no one notices.
Screw with my FTP server and make it looked hacked, to ensure deniability.
Assume global emperorship.
Of course, if I had done it, I would have made it more subtle. Perhaps a hard-to-find buffer overflow in CTCP handling, or such...
(The preceding was a JOKE...)
Granted, exploit could be hidden from such a simple check but it still seems that above would be enough to prevent backdoors.
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
No, you're not thinking of the good ol' days. You're thinking of the fucked up new days, when people stopped manipulating the irc protocol itself and started unleashing 400Mbps DOS attacks on servers because, "That bastard IRCop shouldn't have killed me". There's a far cry from producing nickname collisions because the irc protocol is weak to using thousands of compromised machines to generate hundreds of megs in smurf traffic.
> 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.
Just because you can use something for one of its intended uses does not relieve you of responsibility for its other uses. When a computer owner takes the responsibility of hooking a computer up to the internet, he should also take responsibility for making sure that there can be no malicious use of it--or be willing to face the consequences when someone else (i.e. the government or someone distributing a white-hat virus) takes it upon themselves to stop the irresponsible user from inflicting themselves on others. Living in a free society requires taking responsibility for one's own actions, even if (some might argue especially if), one didn't know that what he/she was doing could be harmful to others.
Bottom line, if you're not tech-savvy enough to secure your own computer, either get tech-savvy enough or hire someone trustworthy to do it (you'd be amazed how many broke nerd college students will secure your computer and check it on a regular basis for a pizza every time they work on it--my husband would have starved in college otherwise)...but I'm guessing I'm preaching to the choir here...
Denver Isuzu Suzuki
RPM, the standard packaging system according to the Linux Standards base, had support for PGP (IIRC) around three years ago. This was replaced / upgraded to GPG a couple of years ago. Every package in Red Hat Linux (and most other popular distros) is signed (unless someone screws up - there was a case where 2 packages weren't properly signed, but signed replacements were made avaliable soon after). RPM will print a strong warning if the signature isn't correct (and maybe fail the operation - dunno, my signature's have always been correct).
Dpkg also recently added GPG support, buy you have to trust individuals rather than a specific company - no packager is going to lose their job if they're working in Albania on Debian trojaning packages.
This is only an issue with OSS because they are often the product of one person, unfettered by marketing departments and financial considerations. Sometimes this is good (honest disclosure of a programs bugs and limitations, and realistic schedules for new versions such as "when it's done"), and sometimes this is not so good (you get juvenalia like BitchX, which aside from its bad habits seems to be a full-featured, powerful IRC client).
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
...Time is the best teacher, unfortunately it kills all of its students.