Downloaded .unlock to a floppy diskette and checked MD5 against the one listed on the Project Honeynet website. Commands bolded in blue.
md5sum .unlock a03b5be9264651ab30f2223592befb42
MD5 .unlock = a03b5be9264651ab30f2223592befb42 (From Project Honeynet)
After downloading and verifying the file, I ran FIRE (Forensic and Incident Response Environment, nee Biatchux). I prefer to perform forensic examinations from a bootable Linux CD running in RAM, with nothing mounted except the drive I am looking at, just in case something goes awry. FIRE boots from a CD and provides menu options for either an X or Ncurses environment from which to perform forensic examinations. In this case I booted FIRE into an X environment.
Knowing nothing about the file, I decided to try to view it. This would probably yield no useable results, but what the heck. As expected, cat .unlock and strings .unlock produced no tangible results. Looks like a binary file with a bunch of unintelligble ASCII characters. So, I fire up biew .unlock and look at the file in binary and hex mode (F2 to change viewing modes). Binary is gobbledygook, hex is not much better, but based on the first two bytes (1F 8B) of the file, it appears to be a GZip archive. A search on Google turns up RFC 1952 on GZIP file format specification version 4.3.
| Field | ID1 | ID2 | CM | FLG | XFL | OS | XLEN | |
| Value | 1F | 8B | 08 | 00 | 78 FF 8A 3D | 00 | 03 | EC 3C |
The relevant information out of the file header is the first two bytes, identifying the file as a GZip archive, the fifth through eighth bytes, which represent the time last modified (in seconds since the Epoch, 00:00:00 UTC, 1 January 1970), and the 10th byte which represents the applicable OS file system (based on the table shown below).
The file is from a Unix file system, but the interesting thing to note is that the time last modified appears to be in the future. A quick trip to the Unix Date/Time Calculator confirms this suspicion.
The file appears to have been created almost 32 years in the future. Hmmmm....
So, wanting to see what computing will look like in 3 decades, I copied .unlock to my /tmp directory,
[root@FIRE] floppy> cp .unlock /tmprenamed it unlock.tgz,
[root@FIRE] floppy> cd /tmpand unzipped the file.
[root@FIRE] tmp> tar xzvf unlock.tgzThis yields two files .unlock.c and .update.c. From a check of the file properties,
[root@FIRE] tmp> ls -la
.unlock.c appears to have been created on September 20th of this year at 06:28 and .update.c appears to have been created on September 19th of this year at 14:57.Initial analysis of the .unlock.c file
[root@FIRE] tmp> more .unlock.cimmediately shows the following information:
by contem@efnet Virtually connects computers via the udp protocol on the specified port. Uses a newly created peer-to-peer protocol that incorperates uses on unstable or dead computers. The program is ran with the parameters of another ip on the virtual network. If running on the first computer, run with the ip 127.0.0.1 or some other type of local address. Ex:
Computer B: ./Program Computer_A Computer C: ./Program Computer_A Computer D: ./Program Computer_C Any form of that will work. The linking process works by giving each computer the list of avaliable computers, then using a technique called broadcast segmentation combined with TCP like functionality to insure that another computer on the network receives the broadcast packet, segments it again and recreates the packet to send to other hosts. That technique can be used to support over 16 million simutaniously connected computers. Thanks to ensane and st for donating shells and test beds for this program. And for the admins who removed me because I was testing this program (you know who you are) need to watch their backs. I am not responsible for any harm caused by this program! I made this program to demonstrate peer-to-peer communication and should not be used in real life. It is an education program that should never even be ran at all, nor used in any way, shape or form. It is not the authors fault if it was used for any purposes other than educational. |
From the above banner and other behavior observed in the code, it would appear that .unlock is a tarred and gzipped version of the Slapper Worm, which is based on the Peer-to-Peer UDP Distributed Denial of Service (PUD) proof-of-concept code. A search in Google produces many results that support this hypothesis. It is interesting to note that the Unlock variant of the Slapper worm is called by different names across the Internet. I found references to it as Variant A(Aion), Variant B and Variant C. The reference as Variant A(Aion) was singular, and appears to have been corrected later to Variant B by the AV vendor. There is no clear cut winner of Variant B versus C, so from this point on I will refer to it simply as "the worm."
From Symantec website: (http://securityresponse.symantec.com/Avcenter/venc/data/linux.slapper.worm.html)
"Linux.Slapper.Worm is a family of worms that use an OpenSSL buffer overflow exploit to run a shell on a remote computer. Each variant of the family targets vulnerable installations of the Apache Web server on Linux operating systems, which include versions of SuSe, Mandrake, RedHat, Slackware, and Debian. The worm also contains code for a Distributed Denial of Service attack.
When a variant of the Linux.Slapper.Worm family attacks a computer, it attempts to connect on port 80. It sends an invalid GET request to the server to identify the Apache system. After the worm finds an Apache system, it tries to connect on port 443 to send the exploit code to the SSL service that is listening on the remote computer.
The worm uses a Linux shell code exploit, which runs only on Intel platforms. This code requires the presence of the shell command /bin/sh in order to execute properly. The worm uuencodes its own source code and sends it to the remote system. There it decodes the file, compiles it using gcc (requiring permissions to the compiler for the Apache user), and runs the resulting binary file. All worm files are placed in the /tmp directory.
The worm binary is executed with an IP address as a parameter. This IP address is the address of the attacking computer, and is used to create a peer-to-peer network of worm-infected systems for Denial of Service attack purposes. Each compromised system listens on a UDP port to receive further instructions. The port changes from one variant to another.
The worm sweeps class B-sized networks, looking for Apache servers. The first byte of the network address is picked randomly from the following list, and the second byte is random:
3, 4, 6, 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 24, 25, 26, 28, 29, 30, 32, 33, 34, 35, 38, 40, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 61, 62, 63, 64, 65, 66, 67, 68, 80, 81, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239
[The worm] is transmitted as a uuencoded archive that contains two source files. It has the following characteristics:
UDP listening port: 4156 uuencoded file: .unlock.uu Archive file (.tgz format): .unlock Source code files: .unlock.c, .update.c Compiled binary files: httpd, update
One of the [worm's] binaries is named httpd, which is the also name of the Apache server executable. This was done to avoid drawing the attention of administrators when they check the names of the running processes using the "ps" command. The .C variant periodically listens on port 1052/TCP and provides a shell to an attacker who is connecting to this port.
Please note that file names beginning with a dot ( . ) will not appear in a normal directory listing obtained using the ls command. The files can be seen by using the ls -a command."
From F-Secure website: (http://www.f-secure.com/v-descs/slapper.shtml)
"This is a slightly modified variant of Slapper.A. This variant uses a different port - port 4156 instead of 2002 - and different file names. It uploads itself as /tmp/.unlock.uu, decodes the file to /tmp/.unlock and uses tar to decompress its content. Then the worm compiles the extracted source code /tmp/.unlock.c to /tmp/httpd, starts it and removes all files except /tmp/.unlock.
This variant also sends IP addresses of infected hosts via email propably to the virus writer.
This variant can be removed from the host by shutting down Apache, killing the worm's process (httpd) and deleting the file /tmp/.unlock. The appropriate updates should be applied before the Apache is restarted."
1. Which is the type of the .unlock file? When was it generated?
Based on the hex dump of .unlock beginning with 1F 8B 08 00, it appears that the file is a GZip archive. This holds true when the file is renamed and unzipped. Two files are present in the archive, .unlock.c and .update.c, and appear to have been created on the 20th and 19th of September 2002, respectively. The 20092002 version number present in .unlock.c would appear to support this assumption.
As for when the .unlock file was generated, that is hard to say. It appears to have been created sometime around the 20th of September, 2002, but the modified time (mtime) in the header of the GZip archive lists an invalid date (30 April, 2034). All other indications are that the file was created sometime towards the end of September.
2. 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?
Based on the code, it would seem that the author of the original proof-of-concept code found in .unlock.c would be contem@efnet. A search of Google for Efnet turns up www.efnet.org - the Eris Free Network, purportedly the "largest and oldest IRC network". There is not currently a publicly-viewable member or channel named Contem, so infer what you will. Additionally, the code appears to have been modified for use in this Slapper variant by Aion (aion@ukr.net). Ukr.net is an ISP in Ukraine that offers free mail accounts, and if you believe what you read, a 21-year old man was arrested in Ukraine and charged as the author of the Slapper worm in connection with accessing that e-mail account from a traceable location. The code found in .update.c appears to be solely the work of Aion.
Additionally, exploit code appeared on Packetstorm called wc.tar.gz including two versions of a client for the worm code and a README file. In Aion's own words (a little disjointed, but still understandable):
README
"i try to find client for slapper worm but nothing. most of ppl change worm to attack host and put on them they own backdoors, (aside backdoor is nice when admin's kill only one of worm or backdoor (one of them stay online)) but slapper has a nice backdoore functions, the problem is that there are no comments in source so it was hard to create something usefull.
i put nontested backdoore to slapper.a (aion) & i have a little problem use them (if you find source of timecontrol backdoore .update.c don't use it) so i have about 20.000 servers whith time-to-time working trojan (2packetstormsecurity: if you need this list i can mail it to you) so i write simple client to worm (only 2 function are supported)
there are two file wc*.c ver.04 & ver.07, ver.04 - is interactive, enter command & if you luck you see result (there are still a lot of problems (i don't know how fixed them): audp_recv is blocking, so if server don't answer program is halt if don't use fork()&alarm(). worm answer many times (up to 5-9) i can't find explain in source, so if you enter> cat /etc/Passwd you see result 5 times or more.)
ver.07-it all in one (by default launch sh on 1052(tcp)/Pass aion1981) (interactive shell much beter then use ver.04, you can kill them, at and of session, and run ver.07 when you need it again) (with simple modification you can use other tag's (lika flood,mailscan,etc)) (compile: gcc -o wc wc*.c -lcrypto)
usage: wc* ip port (port included becouse most ppl change them in they modification of worm) (use script with ver.07 if you need mass host attack) (use tcpdump udp src port PORT to see did servers answer)
NOTE!!!: (there are a very big problem) only first time worm accept connection from one host, e.g. if you run twice ver.07 only first try will success, to connect to worm again you need to wait (maybe much more then hour ???), so once you connect to worm, do all what you need in one session. (but hold enter in ver.04 you can flood them & worm accept you)
thanks go to slapper author for a wonderfull work, it realy very nice, but imho author don't have enought time to finish them, or somthing. the worm has a great net engine but with stealths functions his have a very big problem (save to /tmp/.*bug*,list in ps like /tmp/.bugtraq, don't unlink work files, etc) this all can be done in one maybe two hour (but if do this kind of work on them, i think security center's find them much later that they are) so if someone try to write worm, pls ask help from other hackers.
aion (ai0n@ukr.net) (my box aion@ukr.net is full)"
Based on the version number found in the .unlock.c file, it seems logical that the code was created on or around the 20th of September 2002. This would also be compatible with the timestamps on the two source files. It does not answer the question of the mtime stamp in the archive's header. Taking into account the additional exploit code from Packetstorm, this seems reasonable as the client code was created and packaged with the README file quoted above on the 26th and 27th of September.
3. Which process name is used by the worm when it is running?
The worm compiles .unlock.c and names itself httpd, the common name for the Apache executable. This is done in an attempt to hide the process among other Apache processes running on the target machine.
4. In which format does the worm copy itself to the new infected machine? Which files are created in the whole process? After the worm executes itself, which files remain on the infected machine?
The worm copies itself to a newly infected host in the form of a uuencoded file .unlock.uu in the /tmp directory. .Unlock.uu is then decoded and the resultant file, .unlock, is untarred/unzipped into the C source code files .unlock.c and .update.c. .Unlock.c and .Update.c are compiled into httpd and update, respectively. All files except .unlock are later deleted.
The list of files is as follows:
5. Which port is scanned by the worm?
The worm randomly scans Class-B networks, searching for Apache servers on port 80. It sends an invalid GET request to determine the version of Apache running, and then attempts its exploit over port 443 if the Apache server meets its version and architecture requirements.
6. Which vulnerability the worm tries to exploit? In which architectures?
The worm attempts to exploit a vulnerability in OpenSSL on Gentoo, Debian, Redhat, SuSE, Mandrake and Slackware versions of Linux. The following is the section of code that represents the operating systems and the versions of Apache with the appropriate hex string to exploit the vulnerability in each case. It is interesting to note that while the worm will only run against certain distros and versions of Apache, it is the OpenSSL implementation that is vulnerable, not the OS or Apache in and of themselves.
7. What kind of information is sent by the worm by email? To which account?
The worm sends IP addresses and hostnames of infected hosts to the aion@ukr.net account. The actual SMTP format of the e-mail follows:
helo test
mail from: test@microsoft.com
rcpt to: aion@ukr.net
data
hostid: <host IP>
hostname: <hostname>
att_from: <hostname><host IP>
.
quit
8. Which port (and protocol) is used by the worm to communicate to other infected machines?
The worm listens on UDP port 4156 for DDoS commands from its peer network. The worm maintains its scan-and-propagate state, which systems it has infected, which system infected its current host, a list of other infected systems and the routes to them through the use of an implementation of a stateful protocol across UDP. The commands defined within the worm are as follows:
Aion has actually created two clients to connect to infected hosts, named wc04.c and wc07.c. These files are referenced in the text of the README file above.
9. Name 3 functionalities built in the worm to attack other networks.
The worm has built-in functionality to launch a distributed denial-of-service attack against other hosts/networks using either a UDP Flood, TCP Flood, IPv6 TCP Flood, or DNS Flood. The worm also scans the local disk for valid e-mail addresses. Additionally, the worm searches for valid Apache servers to replicate itself to.
10. What is the purpose of the .update.c program? Which port does it use?
The worm is coded to allow backdoor communications with the infected host for only 10 seconds before sleeping for 5 minutes. During that 10 second window, one can connect to the infected host on port 1052 and execute a command from the shell using the password "aion1981". .Update.c is the C source code that allows for this functionality.
It would also appear that from the text of Aion's README, that the sporadic availability of the backdoor functionality was either unintentional or not as successful as he had hoped, and that it drove the creation of the client code. From the README:
"i put nontested backdoore to slapper.a (aion) & i have a little problem use them (if you find source of timecontrol backdoore .update.c don't use it) so i have about 20.000 servers whith time-to-time working trojan"
Bonus Question: What is the purpose of the SLEEPTIME and UPTIME values in the .update.c program?
The SLEEPTIME and UPTIME variables are used to make the worm 1) sleep for 5 minutes and 2) listen on port 1052 for 10 seconds, respectively. It makes one wonder how you would control your infected hosts if they are only available for 10 seconds every 5 minutes and you don't have any way of knowing when that is. Could be that was what was wrong with the update.c code and prompted Aion to release the client code.
John Payton
Computer Sciences Corporation
jpayton3_at_csc_dot_com