ISSA 2013 Netwars Challange
Response by @BryanNolen
@JackCR recently posted the ISSA 2013 Netwars challenge on his blog [http://blog.handlerdiaries.com/?p=63]
I have already provided a quick write up on getting the memory image from it working [http://strangelyrelevant.blogspot.com.au/2013/08/jackcr-issa-2013-netwars-challange.html], so now let's dive into the actual forensics.
Participants were invited to download and boot an ISO file containing a Live CD version of Security Onion which had been customised for the event.
One the desktop were 3 data files and the challange questions.
Network Capture issa-2013-challenge.pcap
Disk Image issa-2013-challenge.sda1.dd
Memory Capture vmss.core
There were 25 questions to be answered, and though the course of this post I will provide my answers as well as details as to how I came to my conclusions.
Rather than using the supplied analysis environment, I have opted to extract the evidence files over to a seperate VMDK volume which I can then mount on normal analysis systems.
Baselining the Evidence Provided
Using the files command, we can easily determine the basic formats of the the evidence provided:
issa-2013-challenge.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)
issa-2013-challenge.sda1.dd: Linux rev 1.0 ext3 filesystem data, UUID=bc8f66b6-48cb-4dfa-a554-cb91b9b83dd7 (large files)
vmss.core: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'GuestVM'
Based on this we can make the following assumptions
We have a partition image, rather that a whole disk image, and that the partition is ext3 formatted.
The memory dump is in 32bit ELF format which rules out a dump from VirtualBox (which uses ELF64 format instead)
We need to convert the memory dump to be able to process it in volatility
We are dealing with Intel archetecture and not some weird ARM/MACH/SPARC system
A Word of Warning
Please note in this post I will use /path/to/image/ to represent the full path to where I hve mounted my evidence VMDK. You will need to change this to match your system if you want to replicate what I have done.
Answering the Questions
1. What time did the attack begin?
Based on the datestamp given in the first 200 OK header, the initial recon began at Fri, 08 Feb 2013 22:47:07 GMT. Looking in the packet capture, there was also ICMP ping activity 2 minutes before this.
This is co-related with the apache logs showing the initial HEAD request at 08/Feb/2013:17:47:07 -0500 with the same user agent as observed on the wire.
HEAD / HTTP/1.1
User-Agent: Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:Port Check)
HTTP/1.1 200 OK
Date: Fri, 08 Feb 2013 22:47:07 GMT
Server: Apache/2.2.12 (Ubuntu)
Set-Cookie: 5d3dc44c722468d70ab42839bbac9eb6=9ae4e1bd64c90d2202cdc7b0638b479a; path=/
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Expires: Mon, 1 Jan 2001 00:00:00 GMT
Last-Modified: Fri, 08 Feb 2013 22:47:07 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Keep-Alive: timeout=15, max=100
Content-Type: text/html; charset=utf-8
2. What was the initial indicator?
Request for "HEAD /" followed by "GET /" wuth a user agent matching a know scanning tool.
3. What tool was used to scan the webserver?
Nikto 2.1.5 as disclosed in the User Agent presented to the web server during recon.
User-Agent: Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:Port Check)
4. What application was exploited to compromise the webserver?
The attacker targeted the content management system (Joomla 1.5), specifically the tiny_mce plugin.
220.127.116.11 - - [08/Feb/2013:18:33:42 -0500] "GET /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/upload.php?type=file&folder= HTTP/1.1" 200 3055 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
18.104.22.168 - - [08/Feb/2013:18:33:42 -0500] "POST /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/upload_file.php?folder=/images/stories/&type=file&feid=&obfuscate=3bc6aeeecd3d028411bb8a479e93c359&sessidpass= HTTP/1.1" 200 283 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
22.214.171.124 - - [08/Feb/2013:18:33:42 -0500] "GET /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/upload_process.php?folder=/images/stories/&type=file&feid=&filetotal=1 HTTP/1.1" 302 737 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
126.96.36.199 - - [08/Feb/2013:18:33:42 -0500] "POST /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/edit.php?type=file&folder= HTTP/1.1" 200 8283 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
5. What was the ip address of the attacker that compromised the webserver?
6. Were there any additional ip addresses used in the attack? If so, what are they?
One additional IP address was observed, 188.8.131.52
7. What file was initially placed on the machine by the attacker
8. What directory was it located in?
From the apache webroot /images/stories/ which maps to /var/www/images/stories
9. What allowed the upload of that file?
Exploit in the tiny_mce plugin for Joomla 1.5
10. What was the first operating system command executed by the attacker?
Bonus - the attacker launched a perl based backconnect shell to port 4444 that was base64 encoded in ogfcmxaiaexofkdozkvz.php
11. How did the attacker attempt to escalate privileges?
By using a exploit in the way PAM reads /etc/motd executed though a custom script located on the attackers server at "http://184.108.40.206/timeserver.bash" and downloaded to the target server via a wget command executed in the backconnect session.
12. What was the timestamp that privilege escalation was attempted?
Fri, 08 Feb 2013 23:37:49 UTC
13. Is the machine still at risk for this method of privilege escalation? Why?
Yes, the exploit relies on a vulnrability in PAM, which was not patched at the time of attack.
14. What files were placed on the webserver by the attacker?
15. How was the attacker able to place each file on the machine?
ogfcmxaiaexofkdozkvz.php was uploaded via the aforementioned Joomla exploit.
timeserver.bash and webstat.txt / webstat.php were retrieved from the attackers machine via wget, executed through the backconnect shell
linux-rootkit.tar.gz was uploaded via the webshell
16. What additional tool was placed on the machine that gave the attacker direct access?
webstat.php - a full featured PHP webshell.
17. How did the attacker access this tool?
By accessing it through their web browser.
18. What did the attacker take from the webserver?
Dumps of the MySQL databases
19: What are the md5 hashes of all the files taken?
20. What directory was created by the attacker?
21. What are the contents of this directory?
22. Was the attacker able to successfully execute the tool in this directory? How do you know?
At this stage it does not appear so. The output from the the tool appears to be how to use instructions. Looking at the packet capture the command was never executed with the correct password ("fabrika" based on the .c file)
Sistem yetki unitesi
Kullanim: /var/tmp/.www/linux-rootkit/kontrol <password>
System power unit
Use: /var/tmp/.www/linux-rootkit/kontrol <password>
23. What was the exact netstat command that was executed at Fri Feb 08 2013 18:53:37? What ports were listening based on the output from that command?
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp6 0 0 :::80 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 172.16.150.20:80 220.127.116.11:1070 ESTABLISHED -
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 2390 - @/com/ubuntu/upstart
unix 2 [ ] DGRAM 2447 - @/org/kernel/udev/udevd
unix 5 [ ] DGRAM 3473 - /dev/log
unix 2 [ ACC ] STREAM LISTENING 3790 - /var/run/mysqld/mysqld.sock
unix 2 [ ] DGRAM 5354 -
unix 2 [ ] DGRAM 3783 -
unix 2 [ ] DGRAM 3615 -
unix 3 [ ] DGRAM 2479 -
unix 3 [ ] DGRAM 2478 -
unix 3 [ ] STREAM CONNECTED 2444 - @/com/ubuntu/upstart
unix 3 [ ] STREAM CONNECTED 2441 -
24. How was the attacker able to gain access to the database credentials?
Read the contents of /var/www/configuration.php via web shell.
25. List the points of remediation that need to occur as a result of the analysis performed.
Upgrade system from Ubuntu 9.10 to 13.04. Update Joomla Disable/Delete unneeded modules Reset ALL credientials (user and database) Install Web Firewall (mod_security, cloudflare etc.) Change permissions on web folders so they are NOT writable by the apache account unless absolutly needed.