Members from the Honeynet.BR team have captured a new worm from the wild. The
file (.unlock), was used by the worm to infect the honeypot. Your
mission is to analyze the captured file in order to answer the questions below.
Be sure you review the submission rules at the SotM challenge page before
submitting your results.
After downloading and verifying the MD5 checksum, I used the file
command to determine the content type of the given file:
[cow:~/]$ file .unlock .unlock: gzip compressed data, deflated, last modified: Fri Sep 20 12:59:04 2002, os: UnixIt turned out to be a gzipped archive, which after unzipping and re-checking with file, contained an tarball archive:
[cow:~/]$ mv .unlock .unlock1.gz [cow:~/]$ gunzip .unlock1.gz [cow:~/]$ file .unlock1 .unlock1: GNU tar archive [cow:~/]$ tar xvf .unlock1 .unlock.c .update.c [cow:~/]$ file .*.c .unlock.c: ASCII English text, with CRLF, LF line terminators .update.c: ASCII C program text, with CRLF, LF line terminatorsSo, it appeared the obtained file contains two source files, which based on the findings of
file, appears to come from a non-Unix box.
In addition to the conclusion from the latter run file command, we
can exactly pinpoint the changes made by the attacker. We can conclude this
from the fact that not every line is terminated with the CRLF
characters.
One of the first things I noticed was the appearance of two names:
contem@efnet and aion. After feeding the first name to my
favorite seach-engine [2], it returned a few hundred hits
related to this name. One of the higher rated hits linked to the PacketStorm
Security site, reveiling that the worm was last modified on September the 12th,
2002.
Searching on both names returned a single Russian site (I don't speak Russian,
so it was all jibberish to me), which on itself contained a link to an
advisory of ISS[3]. In this advisory, they give some
detailed background information about a worm called Slapper. To be more
precise, the advisory names aion's version Slapper.B.
So, we now've got a name for our worm.
All this information, and all we did was look briefly into the sources and
entered some terms in a search engine! It was time to look deeper into the
sources of Slapper.B and start answering the questions.
.unlock file? When was it
generated?
The type of the file, according to the file command, is gzip
compressed data, deflated. Further investigation results in the archive
being a gzipped tarball. It was last modified (by which we can
deduce that it was generated) on friday, the 20th of September 2002, at
12:59. The host on which this archive was created was an Unix host.
The original author goes by the name contem@efnet, while there
are made modifications by -the presumable attacker- who names himself:
aion.
The dates of the files are:
.unlock.c, September the 20th, 15:28.
.update.c, September the 19th, 14:28.
.unlock.c file is not compatible with the creation
time of the archive. We could deduce from this -and the fact that both files
are sometimes using some CRLF line termination- that the attacker has packed
these files on another system (Linux?) than where he made the last file
modifications (Windows?).
The worm hides himself under the name of httpd , which would
appear as a "normal" Apache deamon to the unwary. But if you look closer, you
would see there's a extra space after the name, which should avoid clashes with
the already running Apache server.
After the worm has found a new victim and has gained access to it, it performs the following steps:
rm -rf /tmp/.unlock.uu /tmp/.unlock.c /tmp/.update.c
/tmp/httpd /tmp/update /tmp/.unlock
cat > /tmp/.unlock.uu << __eof__
(here the worms' source archive is UU-encoded and sent to the victim host)
__eof__ uudecode -o /tmp/.unlock /tmp/.unlock.uu tar xzf /tmp/.unlock -C /tmp/ gcc -o /tmp/httpd /tmp/.unlock.c -lcrypto gcc -o /tmp/update /tmp/.update.c /tmp/httpdFrom this, we can see that the only file left here is the/tmp/update rm -rf /tmp/.unlock.uu /tmp/.unlock.c /tmp/.update.c /tmp/httpd /tmp/update exit
.unlock
file. It is used to allow the worm to propagate itself to its new victims.
The worm scans hosts for open ports 80. If it can connect to a Apache server,
it pulls apart the server fingerprint (e.g. Server: Apache/2.0.39 (Unix)
mod_ssl/2.0.39 OpenSSL/0.9.6b) and from the information in this string,
it determines wheter to try to exploit the OpenSSL implementation at port 443.
The worm has already appeared in the wild and was reported on the Bugtraq
mailing list as vulnerability under the ID #5363, with the name: OpenSSL SSLv2 Malformed Client
Key Remote Buffer Overflow Vulnerability. The worm tries to exploit
vulnerable OpenSSL modules of Apache webservers running on Linux hosts.
The versions of OpenSSL which are vulnerable to this exploit are:
OpenSSL versions up to and including 0.9.6d and 0.9.7 beta1
The versions of Apache that are vulnerable / scanned for are:
Gentoo: Apache ?,
Debian: Apache 1.3.26
Red-Hat: Apache 1.3.6, 1.3.9, 1.3.12, 1.3.19, 1.3.20,
1.3.22, 1.3.23, 1.3.26
SuSe: Apache 1.3.12, 1.3.17, 1.3.19, 1.3.20, 1.3.23
Mandrake: 1.3.14, 1.3.19, 1.3.20, 1.3.23
Slackware: Apache 1.3.26
Gentoo persumably hides the exact version number of their Apache, but this (of
course) wouldn't mean that all Gentoo hosts are vulnerable to this worm.
Also funny to mention is that if the worm isn't able to determine the exact
architecture from the servers' fingerprint, it just assumes it's dealing with a
Red-Hat machine using Apache 1.3.23 (which is probably a default RH7.0
installation).
freemail.ukr.net, a free Ukrainian
mail service. The account used is aion@ukr.net.
The worm uses UDP port 4156 to communicate with all other machines. The
protocol creates a decentral peer-to-peer network of victim hosts, which can
communicate and forward messages for each other.
The attacker is able to start three kinds of flooding attacks (additional information regarding the specific attack-details is taken from ISS' advisory):
.update.c program? Which port does
it use?
The .update.c program opens port 1052 and waits for a password
(aion1981). After it has received this password, it opens a
backdoor -by means of an interactive shell- which allows the attacker access to
the machine.
This allows the attacker to access each node of his DDOS network individually
to gain knowledge about its host or to start other attacks.
SLEEPTIME and
UPTIME values in the .update.c program?
The trojan program tries to hide itself from getting unwanted attention by only
listening for 10 seconds each 5 minutes. If it doesn't receive a connect call
within these 10 seconds, it closes the port and sleeps for 5 minutes. After
which he tries again and again until the attacker connects to it.
Based on the answer of question 7 and the password of the trojan
(.update.c), we can deduce that the attacker is probably an
Russian speaking person, probably from the Ukraine, and 21 years old. He
re-used sources, which date from the 11th of September 2002 (and was published
on PacketStorm Security[1] under the name pud), and
made his last modification on the 20th of September 2002 (according to both the
timestamp and version string).
From observing the source code, the attacker is familiar with C programming,
though probably only from observating other persons' code rather than crafting
it himself (he treats all pointers as arrays). Nevertheless, he's smart and has
enough knowledge to glue all parts together to get a working DDOS worm.
This particular variant of the Slapper worm can easily be defeated, by creating
an empty, root-owned, read-only, immutable .unlock.uu file. Since
the worm tries to write his source archive into this file while not checking
for any errors, the propagation will fail.
Another solution would be placing the /tmp on a separate partition
which is mounted without execution rights (e.g. mount /tmp -o
noexec).
file - to determine file types and gain insight knowledge
about the original file.
GNU's tar / gzip - to extract the files from the archive.
(g)VIM 6.0 - to review the files.