var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); document.write(unescape("%3Cscript src='" + gaJsHost + "' type='text/javascript'%3E%3C/script%3E")); CLASS="ARTICLE" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#840084" ALINK="#0000FF" >

Scan 25, November-2002

Bo Adler


Table of Contents


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
           => `.unlock'
Resolving done.
Connecting to[]: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
[...spurious output deleted...]
csh% sha1sum .unlock
4b018cdfdbcf71ddaa789e8ecc9ed7700660021a  .unlock
You can see that I never had to verify a SHA1 checksum before, and had to hunt around for the correct command. I searched the man pages on my Redhat-7.3 machine for possible commands, but the only promising entries didn't actually exist on my machine. Since nothing turned up, the next course of action was to check the files actually on my disk to see if anything had a suggestive name. Redhat includes the locate command for this purpose; every week a cron job runs and indexes the names of all the files on the machine. Only a handful of files include the string "sha1" in their name, and it was easy to spot the correct executable.

NoteTwo 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.


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 wrote .unlock.c and 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.

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 indicating the machine's hostname, IP address (encoded as an integer), and the IP address of the machine which infected it.

var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); document.write(unescape("%3Cscript src='" + gaJsHost + "' type='text/javascript'%3E%3C/script%3E")); >