Analysis
Download and Verification
To begin the analysis, I downloaded .unlock and verified that the signatures matched the ones listed at the download page:
csh% wget http://project.honeynet.org/scans/scan25/.unlock
--22:39:46-- http://project.honeynet.org/scans/scan25/.unlock
=> `.unlock'
Resolving project.honeynet.org... done.
Connecting to project.honeynet.org[63.107.222.112]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17,973 [text/plain]
100%[====================================>] 17,973 72.53K/s ETA 00:00
22:39:46 (72.53 KB/s) - `.unlock' saved [17973/17973]
csh% md5sum .unlock
a03b5be9264651ab30f2223592befb42 .unlock
csh% man -k sha
sha [dgst] (1ssl) - message digests
sha1 [dgst] (1ssl) - message digests
shasum [sha1sum] (1) - compute and check SHA1 message digest
[...spurious output deleted...]
csh% which sha
sha: Command not found.
csh% which sha1
sha1: Command not found.
csh% which shasum
shasum: Command not found.
csh% locate sha1
/usr/bin/sha1sum
[...spurious output deleted...]
csh% sha1sum .unlock
4b018cdfdbcf71ddaa789e8ecc9ed7700660021a .unlock |
 | Two Signatures? |
|---|---|
The implementation details for MD5 and SHA1 are described in Applied Cryptography (Second Edition) in Chapter 18. The composition of two signatures provides extra protection against a birthday attack. It escapes me at the moment why an attacker would care very much to substitute a different file with the same checksums. As pointed out by Nick DeBaggis in Scan 23, the security here is really dependent on the security of the Honeynet website (and its DNS) itself. If an attacker is able to substitute the .unlock file, presumably they could also alter the web page to list new checksums. A solution to the brute-force substitution attack would be to list the checksums as part of a message which is digitally signed by a well-known key. |
What is .unlock
The next step in analyzing a file is to determine what type of file it is. Up-to-date versions of the GNU implementation of file do a pretty good job of identifying files:
csh% file .unlock .unlock: gzip compressed data, deflated, last modified: Fri Sep 20 03:59:04 2002, os: Unix |
csh% gunzip -c .unlock > unlock-2 csh% file unlock-2 unlock-2: GNU tar archive csh% tar -tvf unlock-2 -rw-r--r-- root/wheel 70981 2002-09-20 06:28:11 .unlock.c -rw-r--r-- root/wheel 2792 2002-09-19 14:57:48 .update.c csh% tar -xf unlock-1 csh% file .unlock.c .unlock.c: ASCII English text, with CRLF, LF line terminators csh% file .update.c .update.c: ASCII C program text, with CRLF, LF line terminators |
Answers
Q1 Answer
Which is the type of the .unlock file? When was it generated?As indicated by the file command, .unlock is a compressed file. The uncompressed file is a tar archive containing C source files.
csh% file .unlock .unlock: gzip compressed data, deflated, last modified: Fri Sep 20 03:59:04 2002, os: Unix csh% gunzip -c .unlock > unlock-2 csh% file unlock-2 unlock-2: GNU tar archive csh% tar -tvf unlock-2 -rw-r--r-- root/wheel 70981 2002-09-20 06:28:11 .unlock.c -rw-r--r-- root/wheel 2792 2002-09-19 14:57:48 .update.c |
The tar archive within the compressed file was "last modified" on 20-Sept-2002 (as given by the output of the first file command). Generally, compressed source archives are built in one fell swoop using GNU tar's -z option, so I think it's likely that this was the date that the compressed file was created. (Note that the date given is in the local timezone, which is Pacific time on my machine.)
Q2 Answer
Based on the source code, who is the author of this worm? When it was created? Is it compatible with the date from question 1?The comments at the top of the files indicate that <contem@efnet> wrote .unlock.c and <aion@ukr.net> wrote .update.c.
Googling for contem@efnet results in several hits, the summaries indicating that this person or group is resposible for several instances of malicious code. EFNET is almost certainly a reference to the IRC network of the same name.
The only reference to a date that I could find within the source code was the version number #define'd in .unlock.c: 20092002 (20-Sept-2002). This is consistent with the date information discovered in Q1.
Q3 Answer
Which process name is used by the worm when it is running?The worm changes its process name by rewriting argv[0] to be the string "httpd ", which could fool anyone looking at the process listing into thinking it was just a webserver process.
Q4 Answer
In wich format the worm copies itself to the new infected machine? Which files are created in the whole process? After the worm executes itself, wich files remain on the infected machine?The function sh() actually contains the raw transfer of the worm. Within that function is a call to encode(), which uuencodes the .unlock file we previously identified as a compressed tar file.
The files created by the whole process are (all located within the /tmp directory): .unlock.uu, .unlock, .unlock.c, .update.c, httpd, and update. All but /tmp/.unlock are deleted after the worm is executed.
Q5 Answer
Which port is scanned by the worm?Port 80 (as given by the define SCANPORT) is scanned by the worm.
Q6 Answer
Which vulnerability the worm tries to exploit? In which architectures?The worm tries to exploit an Apache SSL vulnerability, as described in CA-2002-23. The source contains a table of architectures (the implication is that they are i386 based) which can be exploited:
struct archs {
char *os;
char *apache;
int func_addr;
} architectures[] = {
{"Gentoo", "", 0x08086c34},
{"Debian", "1.3.26", 0x080863cc},
{"Red-Hat", "1.3.6", 0x080707ec},
{"Red-Hat", "1.3.9", 0x0808ccc4},
{"Red-Hat", "1.3.12", 0x0808f614},
{"Red-Hat", "1.3.12", 0x0809251c},
{"Red-Hat", "1.3.19", 0x0809af8c},
{"Red-Hat", "1.3.20", 0x080994d4},
{"Red-Hat", "1.3.26", 0x08161c14},
{"Red-Hat", "1.3.23", 0x0808528c},
{"Red-Hat", "1.3.22", 0x0808400c},
{"SuSE", "1.3.12", 0x0809f54c},
{"SuSE", "1.3.17", 0x08099984},
{"SuSE", "1.3.19", 0x08099ec8},
{"SuSE", "1.3.20", 0x08099da8},
{"SuSE", "1.3.23", 0x08086168},
{"SuSE", "1.3.23", 0x080861c8},
{"Mandrake", "1.3.14", 0x0809d6c4},
{"Mandrake", "1.3.19", 0x0809ea98},
{"Mandrake", "1.3.20", 0x0809e97c},
{"Mandrake", "1.3.23", 0x08086580},
{"Slackware", "1.3.26", 0x083d37fc},
{"Slackware", "1.3.26",0x080b2100}
}; |
Q7 Answer
What kind of information is sent by the worm by email? To which account?Once the worm is started on a new machine, it sends an email to <aion@ukr.net> indicating the machine's hostname, IP address (encoded as an integer), and the IP address of the machine which infected it.
Q8 Answer
Which port (and protocol) is used by the worm to communicate to other infected machines?As given by the #define of PORT near the top of the file, the port used to communicate with other infected machines is port 4156. The code fragments which use this define all use UDP as the protocol for communication.
Q9 Answer
Name 3 functionalities built in the worm to attack other networks.Provide a "bounced" connection which allows the attacker to use the infected machine as a stepping stone to accessing TCP ports on other machines. Similarly, there is a "route" option, which provides the same functionality for UDP ports.
Implementations of various floods, including UDP flood, TCP flood, DNS flood, and IPv6 TCP flood.
Q10 Answer
What is the purpose of the .update.c program? Which port does it use?It is a backdoor listening on port 1052/tcp. If the correct password is given ("aion1981"), then an interative shell is launched and hooked up to the connection.
Bonus Question Answer
What is the purpose of the SLEEPTIME and UPTIME values in the .update.c program?The UPTIME definition controls how long the program sits in a loop listening for connections on the backdoor port. The SLEEPTIME definition controls how long the program sits idle, not accepting connections to the backdoor.
The particular values chosen (10 seconds listening, and 5 minutes sleeping) are what's interesting about this backdoor. Since the backdoor is accepting connections only 3.2% of the time, the probability is that a random scan of open ports (either via nmap or netstat) will not show the backdoor.