One Sad Mind
Costin Raiu, Kaspersky Labs,
<craiu@pcnet.ro>
Introduction:
Approximately during the same period the ".X" version of the VBS
worm VBSWG struck around the world, I received a call from a friend who
is administering a small cluster of servers for a web development firm
in Romania.
My friend was bothered by the fact that their web server was
apparently hacked into, and had the entry page replaced by a black one,
containing an offending message, regarding the US Government and something
(someone?) named "PoizonBOx".
I paid my friend a quick visit; there, we checked the server
logs and managed to find some suspicious entries related to an IP address
in South America. However, the respective address seemed apparently dead,
not responding to ICMP or TCP 'ping's, so we patched the server after identifying
the vulnerability used to compromise it, then I went back home.
It took only a couple of hours until I received a forwarded CERT
alert which cast some light over the incident I investigated at my friend's
site. "CERT Advisory 2001-11" covers a computer worm that hacks Solaris
systems and subsequently attacks random Microsoft IIS v4 and v5 servers
from the Internet by replacing their root page with a custom one, stating
the message I mentioned before, a worm they named "Sadmind".
The Worm
The "Sadmind" worm is interesting combination of 6 Sparc ELF and
10 script/text files, that travels between machines running the Sparc version
of the Solaris operating system. Sometimes, the worm travels as 17 files
instead of 16, because of a traditional Unix crash 'core' image file, that
is usually present in the worm directory, which is copied along with the
worm code during replication.
To replicate, the worm makes use of a very popular buffer overflow
in "/usr/sbin/sadmind", a component of the system administration suite
software "Solstice". The code used in the worm to exploit this bug was
originally written by someone going by the nick "elux",
elux@synnergy.net.
However it is my belief that the respective person has nothing to do with
the worm's author. The former one probably just took the exploit code and
wrote the worm code around it.
Two ELF executables are used to break into remote systems - one
named "brute", authored by the person named "elux", and one named "sadmindex-sparc",
originally written by someone who calls himself "Cheez
Whiz". "brute" is basically a brute-force wrapper for the real exploit;
because the buffer overflow in the "sadmind" program requires a very precise
stack offset to work, "brute" attempts to try various offsets in order
to find the right one. During such attempts it's quite likely for the "sadmind"
program to crash, so attacked systems usually have entries reporting "Segmentation
Fault - core dumped" or "Bus Error"
in their syslogs.
Besides the above two, the worm is using another ELF executable
to search for suitable hosts, Solaris systems for infection and MS IIS
servers to deliver the payload. This executable, named "grabbb" is again
written by a third party, someone going by the nick "scud", from a larger
organization known by the name "teso". (the source of "grabbb" along with
the other "teso" projects is available on the group's web page, which is
http://www.team-teso.net/)
This small program attempts to connect to a range of IP addresses to
either a specific TCP/IP port, or a range of ports, and grabs the output
(usually known as "banner") sent by the respective host(s) after the connection
is initiated. It does this using multiple sockets at the same time, and
is generally quite flexible, allowing a multitude of options to control
timeouts, and so on.
The remaining 3 executable files, "nc", "wget" and "gzip" are
standard and widely used utilities in the '*nix' world. "nc", short for
"netcat" is exactly as its name suggests, a network-aware "cat" program,
which can basically create a link between stdout/stdin and a remote system
via the TCP and UDP protocols. "gzip" is nothing else than the popular
"GNU ZIP" implementation, used to compress and decompress data, while "wget"
is a simple tool which can download files from remote ftp and http servers.
The remaining 10 text/script files are used to propagate the
worm and attack IIS servers. The scripts are written both in Perl and the
standard Bourne Shell, and to be sure that the worm will run on systems
without Perl installed, the worm takes care to download and install Perl
5.005, from a FTP host in China - "bak-px.online.sh.cn".
That, along with a couple of other reasons, suggests that "Sadmind" was
written by some Chinese hacker, same as the recent "Ramen" worm for example.
Execution and Replication
Whenever an infected system is restarted (or infected, see below),
the main worm entrypoint, named "/dev/cuc/start.sh" is launched from the
"/etc/rc2.d/S71rpc" system script. "start.sh" will first check for the
presence of a directory named "/dev/cub", and create it if needed. This
directory will further be used by the worm for the logs and inter-components
communication tasks.
Next, "start.sh" will launch three other scripts, respectively
"time.sh", "sadmin.sh" and "uniattack.sh". The worm will create 5 different
instances in memory of "sadmin.sh" and "uniattack.sh", obviously, with
the purpose of increasing the overall "attack power". Compared to the others,
"time.sh" will only be started once, and will be responsible for two main
tasks - first, to terminate idle sessions spawned by the worm to attack
MS IIS servers, and secondly, to deliver the local payload of the worm.
The local payload is executed after the worm managed to crack
2000 IIS servers, when all the local files named "index.html" will be replaced
with a custom one, which looks like the following:
"sadmin.sh" is the part of the worm responsible with the propagation
of the worm code to other Solaris systems. In order to find other potential
targets, the worm uses a small Perl script to generate 16 random bits which
fill the first 2 bytes of a TCP/IP address, such as "a" and "b" in the
generic "a.b.c.d" TCP/IP address.
The worm will then systematically iterate the remaining two bytes,
checking if any of the respective addresses run the "portmap" service,
that is, if port 111 of the remote host is open.
To implement the check in a reasonable fast way, the "grabbb"
program I mentioned before is used, with settings to wait 3 seconds for
each connection attempt, and running 25 parallel checks ("threads") at
the same time.
Next, the worm will sequentially check the list of hosts that
seemed to run the portmap service, and use the common tool "rpcinfo" to
check for a registered
service with the index "100232", nothing else than the "sadmind" system
administration daemon. If such a service is found, the worm attempts to
hack it, using the "brute" pre-compiled executable. The "brute" copy present
in the worm was probably modified by the author to deliver its payload
on port 600 - that is, to add a root shell in "inetd.conf" with the name
"pcserver", listening on port 600 for remote connections. Obviously, if
the hacking attempts succeeds, the worm will continue by adding a standard
"+ +" line to the root's ".rhosts" file, allowing anyone to freely authenticate
with the respective machine as "root" via rlogin, rcp and
so on.
Next, the worm will archive a copy of itself from "/dev/cuc/"
using the "tar" utility, and use "rcp" to copy it to the target system.
After that, the worm connects to the remote system on port 600, adds a
line to "/etc/rc2.d/S71rpc" to execute "start.sh" upon each system reboot,
gets a copy of Perl 5.005 from the Chinese site I mentioned in the first
part, installs it using "pkgadd" and exits, but not before taking care
to launch the worm on the remote system as well.
The other important script, "uniattack.sh" will similarly generate
random IP addresses, and after checking for a HTTP daemon listening on
port 80, it will attempt to hack them using a recent bug in MS IIS v4 and
5 servers, which is described in the Microsoft Security Bulletin "MS00-078".
(http://www.microsoft.com/technet/security/bulletin/MS00-078.asp)
The Perl script that implements the attack is quite large, over
700 lines of code, mainly because the worm will attempt to use 14 different
methods to exploit the vulnerability.
The payload consists in replacing the entry page of the IIS server
with one containing the same message as the one that will replace the local
"index.html" files on the Solaris system after 2000 successful cracks.
Interesting detail, in Netscape Navigator 4.x, the page will not always
look as expected, that is, with big red letters on a black background -
sometimes the page will be black font on black background, sometimes black
font on white background. This is probably due to a bug in NN 4.x, since
both IE and Netscape Navigator 6 seem display it correctly.
Logs
The worm maintains logs of both hacked Solaris systems and compromised
IIS servers. The logs are stored in the "/dev/cub" directory, and they
are named "result.txt" for the file that stores the compromised IIS servers,
and "sadminhack.txt" for the file that contains the IP addresses of the
Solaris systems to which the worm managed to replicate.
Besides those, the worm will also create a large amount of files
containing results from the "grabbb" utility, also in the "/dev/cub" directory,
with names of the form "a.b.txt", where "a" and "b" are two random bytes
representing the upper half of the IP address classes tested by the "sadmin.sh"
and "uniattack.sh" scripts.
Using the respective files, one can trace the servers infected
by the worm, and hopefully notify their administrators about the infection.
Origin and Authoring
As I was saying, there are a couple of reasons that advocate the
Chinese origin of the worm. First, from the message the worm puts into
cracked web pages, the author didn't seem to be a fan of "PoizonBOx".
"PoizonBOx" is the name of a group of pro-US
hackers that hacks Chinese web sites and replaces their start pages with
various statements and anti-Chinese messages.
For the curious, there is a pretty complete list of such sites
hacked by the members of "PoizonBOx" at http://defaced.alldas.de/defaced.php?attacker=PoizonB0x&p=1
, and moreover, I believe the group can be contacted by e-mail at "poizonb0x@linuxmail.org".
Secondly, the worm does contain a possible contact address for
the author as "sysadmcn@yahoo.com.cn", which
again, is the local Chinese version of Yahoo.COM.
That, along with the usage of the Chinese FTP site "bak-px.online.sh.cn"
leads to the conclusion that the author had at least some strong Chinese
connections if he wasn't himself Chinese.
Again, regarding the author, he probably had some average Perl
and Bash knowledge, but wasn't by far an expert. For example, in many places
through the worm source, he uses constructions such as the following "j=`/bin/echo
"$j+1"|/bin/bc`" to increment a variable, instead of the usual (traditional?)
"j=`expr $j + 1`". Add to that the fact that the whole worm replication
is based on programs coded by other people ("elux", "scud", "Cheez Whiz")
and you'll get an image of him/her, which is probably no better than some
script-kiddie, compiling a couple of programs together, and launching them
over the Internet to show his message to the whole world.
Ending
There are a couple of conclusions we can get from the "Sadmind"
story. First, the fact that a worm exploiting a 2-year old vulnerability
can actually spread is yet another proof that too many users, and even
worse, system administrators, don't really pay enough attention to security
updates or keeping their systems patched.
Another bad thing is that despite the fact that many sites around
the net have been hacked for some time, the worm-infiltrated entry page
is still there, meaning that probably nobody cares to check those machines
for long periods of time. Such machines are the best infection vector a
virus author can dream about, systems just standing there with no one to
look over, while they deliver the virus or its payload against thousand
of other computers. Also, the recent increase in the number of worms attacking
*nix systems is only one of the proofs that the AV world will soon have
to be paying more attention to Linux, Solaris and the others, since I'm
sure we haven't yet seen the worse, nor that "Sadmind" will be the last
piece of malware designed for some *nix flavor...
Name: Solaris/SadMind.A
(worm)
Aliases: SunOS/BoxPoison.worm
Type: network
propagated Sun Sparc Solaris worm
Payload: Attempts to exploit a bug
in IIS 4 and 5 servers, and replaces
their index page with a custom one (see picture)
After hacking 2000 IIS servers, replaces all local "index.html"
files with one similar to those used in hacked servers
Detection and disinfection:
On Solaris systems: delete "/dev/cub" and "/dev/cuc", remove the
worm-added line from "/etc/rc2.d/S71rpc"
On IIS servers: reinstall the affected pages from backup