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.

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.

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

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.

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.

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.

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.

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.

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.