Monday, August 26, 2013

JackCR ISSA 2013 Netwars Challange - Answers

ISSA 2013 Netwars Challange

Response by @BryanNolen


Introduction


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


Challenge Background


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.

REQUEST

HEAD / HTTP/1.1
Connection: Keep-Alive
User-Agent: Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:Port Check)
Host: 172.16.150.20

RESPONSE

HTTP/1.1 200 OK
Date: Fri, 08 Feb 2013 22:47:07 GMT
Server: Apache/2.2.12 (Ubuntu)
X-Powered-By: PHP/5.2.10-2ubuntu6
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
Pragma: no-cache
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
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.

58.64.132.100 - - [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)"
58.64.132.100 - - [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)"
58.64.132.100 - - [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)"
58.64.132.100 - - [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?
58.64.132.100

6. Were there any additional ip addresses used in the attack? If so, what are they?
One additional IP address was observed, 58.64.132.141

7. What file was initially placed on the machine by the attacker
ogfcmxaiaexofkdozkvz.php

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?
ls
Bonus - the attacker launched a perl based backconnect shell to port 4444 that was base64 encoded in ogfcmxaiaexofkdozkvz.php
[https://github.com/bryannolen/DFIR-PUBLIC/blob/master/Reports/JackCR%20ISSA%202013%20-%20Backconnect%20Shell%20Transcript.txt]

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://58.64.132.100/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?
ogfcmxaiaexofkdozkvz.php
timeserver.bash
webstat.txt
webstat.php
linux-rootkit.tar.gz

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
dump_172.16.150.20_Joomla_08-02-2013-18-46-37.sql
dump_172.16.150.20_Joomla_08-02-2013-18-46-37.sql

19: What are the md5 hashes of all the files taken?
6b9caaac96c3e3f34d09a8288dba874a    dump_172.16.150.20_Joomla_08-02-2013-18-46-37.sql
c38154a80b3ab96272d576b550d5cd63  dump_172.16.150.20_mysql_08-02-2013-18-47-33.sql

20. What directory was created by the attacker?
/var/tmp/.www

21. What are the contents of this directory?
linux-rootkit.tar.gz
linux-rootkit/
linux-rootkit/kontrol
linux-rootkit/kontrol.c
linux-rootkit/kontrol.ko

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)

TURIKISH:

Sistem yetki unitesi

Kullanim: /var/tmp/.www/linux-rootkit/kontrol <password>


ENGLISH:

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?
netstat -nap

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        58.64.132.141: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.

No comments:

Post a Comment