Saturday, July 31, 2010

MS10-020 Vulnerabilities in SMB Client

Recently I try to search and study more on SMB protocol vulnerability, the intention is to include these vulnerability support to Dionaea. And, I came across this most recent vulnerability that that reported in Microsoft Bulletin : MS10-020 Critical Vulnerabilities in SMB Client Could Allow Remote Code Execution.

From the Security Bulletin, it stated :

"The vulnerabilities could allow remote code execution if an attacker sent a specially crafted SMB response to a client-initiated SMB request. To exploit these vulnerabilities, an attacker must convince the user to initiate an SMB connection to a specially crafted SMB server. "

I found a detailed full disclosure on http://seclists.org/fulldisclosure/2010/Apr/201 and the POC has provided in http://g-laurent.blogspot.com/2010/04/ms10-020.html

A Windows7 clean images has setup in my VM, and the POC has initiated in another Ubuntu images. This POC will served as the simple crafted SMB server which will reply only this few request before the problematic Trans2 response:

a.Negotiate Protocol Response
b.Session Setup AndX Response, NTLMSSP_CHALLENGE, Error: STATUS_MORE_PROCESSING_REQUIRED
c.Tree Connect AndX Response
d.NT Create AndX Response, FID: 0x4000

After answer to these request, it crafted the SMb Trans2 Response, QUERY_FS_INFO, with appends 8 additional bytes at the end of the packet and an incorrect "Data Offset" field as 0xffff. This additional bytes is BBBBAAAA, which can be replaced further by EBP and EIP.

The normal SMB_COM_TRANSACTION2 Server Response Format:
Server Response Description
================ ============
UCHAR WordCount; Count of data bytes; value = 10 + SetupCount
USHORT TotalParameterCount; Total parameter bytes being sent
USHORT TotalDataCount; Total data bytes being sent
USHORT Reserved;
USHORT ParameterCount; Parameter bytes sent this buffer
USHORT ParameterOffset; Offset (from header start) to Parameters
USHORT ParameterDisplacement; Displacement of these Parameter bytes
USHORT DataCount; Data bytes sent this buffer
USHORT DataOffset; Offset (from header start) to data
USHORT DataDisplacement; Displacement of these data bytes
UCHAR SetupCount; Count of setup words
UCHAR Reserved2; Reserved (pad above to word boundary)
USHORT Setup[SetupWordCount]; Setup words (# = SetupWordCount)
USHORT ByteCount; Count of data bytes
UCHAR Pad[]; Pad to SHORT or LONG
UCHAR Parameters[ParameterCount]; Parameter bytes (# = ParameterCount)
UCHAR Pad1[]; Pad to SHORT or LONG
UCHAR Data[DataCount]; Data bytes (# = DataCount)

This crafted response can be seen clearly from the screenshot


Windows 7 crashes and it need startup repair after that. The POC works!


This POC can only be triggered at SMB client side, with the crafted response packet from the SMB Server. So, till now I guess this vulnerability won't suitable to include in Dionaea, as Dionaea should alway acts as a legitimate SMB server. Let see then.

I more curious about how this type vulnerability can be found, simply by luck or series of fuzzing?

Thursday, July 29, 2010

Analysis of 12fb...c640

After commit several changes for the SMB RPC struct to Dionaea project, I found this capture yesterday and it adopted the struct that I committed. From Dionaea blog http://carnivore.it/2010/06/19/the_story_of_7867de...3e33e7, I guess I meet the variant of the piecework.

Part 1 :
With the logfile as here, the attacking process can be analysed as below:

1. [192.168.1.99:445->90.183.XX.XXX:2548] state: none->established
2. SMB Negociate Protocol Request
3. SMB_Negociate_Protocol_Response
4. SMB Sessionsetup ESEC AndX Request, with NTLMSSP security blob
5. SMB Sessionsetup ESEC AndX Response, with NTLMSSP security blob
6. SMB Sessionsetup ESEC AndX Request ( NTLM Authenticate )
7. SMB Sessionsetup ESEC AndX Response
8. SMB Treeconnect AndX Request
- Make connection to \\60.51.XX.XX\IPC$
9. SMB_Treeconnect_AndX_Response
10.SMB NTcreate AndX Request
- pipe samr
11.SMB_NTcreate_AndX_Response
12.SMB Trans Request / DCERPC_Header / DCERPC_Bind
- TransferSyntax = 8a885d04-1ceb-11c9-9fe8-08002b104860
- UUID = 12345778-1234-abcd-ef00-0123456789ac
- Accepting Bind for samr
13.SMB_Trans_Response
13.SMB Trans Request
- Calling samr Connect4 (3e)
- opnum: (int) 62
14.SMB_Trans_Response
15.SMB Trans Request
- Calling samr EnumDomains (6)
- opnum: (int) 6
16.SMB Trans Response
17.SMB Trans Request
-Calling samr LookupDomain (5)
-opnum: (int) 5
18.SMB_Trans_Response
19.SMB Trans Request
-Calling samr OpenDomain (7)
-opnum: (int) 7
20.SMB Trans Response
21.SMB Trans Request
-Calling samr EnumDomainUsers (d)
-opnum: (int) 13
22.SMB Trans Response
23.SMB Trans Request
-Calling samr Close (1)
-opnum: (int) 1
24.SMB Trans Response
25.SMB Trans Request
-Calling samr Close (1) (I not sure why the attacker repeat the samr Close process twice)
-opnum: (int) 1
26.SMB Trans Response
27.SMB Close
28.SMB Close
29.SMB Tree Disconnect
30.SMB Tree Disconnect

Until now, another line that catch my eye:
[28072010 22:11:01] logsql dionaea/logsql.py:423-info: reject connection from 90.183.XX.XX:3171 to 192.168.1.99:139 (id=104279)
The connection rejected since Dionaea is not support the Netbios protocol which run on port 139.

Again, the attacker tried to connect to port 445 again, after the failure on port 139.
[28072010 22:11:02] connection connection.c:3654-message: connection 0x983a8e0 accept/tcp/none [192.168.1.99:445->90.183.XX.XX:3170] state: none->established

Part 2 :
The attacker continue the process :
1.SMB Negociate_Protocol_Request
2.SMB Negociate Protocol Response
3.SMB Sessionsetup ESEC AndX Request, with NTLMSSP security blob
4.SMB Sessionsetup ESEC AndX Response, with NTLMSSP security blob
5.SMB Sessionsetup ESEC AndX Request (NTLM Authenticate)
6.SMB Sessionsetup ESEC AndX Response
7.SMB Treeconnect AndX Request
-\\60.51.XX.XX\IPC$
8.SMB Treeconnect AndX Response
9.SMB NTcreate AndX Request
10.SMB NTcreate AndX Response
-pipe \svcctl
11.SMB NTcreate AndX Response
12.SMB Trans Request
-Accepting Bind for SVCCTL
-uuid: (string) 367abb81-9844-35f1-ad32-98f038001003
-transfersyntax: (string) 8a885d04-1ceb-11c9-9fe8-08002b104860
13.SMB Trans Response
14.SMB Trans Request
-Calling SVCCTL OpenSCManagerA (1b)
-opnum: (int) 27
15.SMB Trans Response
16.SMB Trans Request
-Calling SVCCTL CloseServiceHandle (0)
-opnum: (int) 0
17.SMB Trans Response
18.SMB Trans Request
-Calling SVCCTL OpenSCManagerA (1b)
-opnum: (int) 27
19.SMB Trans Response
20.SMB Trans Request
-Calling SVCCTL CreateServiceA (18)
-opnum: (int) 24
-From the StubData, it try to create a service "Windows Genuine Logon Manager" that link to cmd.exe /c "net share admin$"
21.SMB Trans Response
22.SMB Trans Request
-Calling SVCCTL CloseServiceHandle (0)
-opnum: (int) 0
23.SMB Trans Response
24.SMB Treeconnect AndX Request
-\\60.51.XX.XX\ADMIN$
25.SMB Treeconnect AndX Response
26.SMB NTcreate AndX Request
-FileName : \csrss.exe

Til this stage, Dionaea has reported the download link for the pieces
[28072010 22:11:07] incident incident.c:203-debug: url: (string) smb://90.183.XX.XX/csrss.exe
[28072010 22:11:07] SMB dionaea/smb/smb.py:326-info: OPEN FILE! csrss.exe

27.SMB NTcreate AndX Response
28.SMB Trans2 Request
-Setup = [TRANS2_SET_FILE_INFORMATION]
29.SMB Trans2 Response
30. 2 alert triggered as below:
[28072010 22:11:08] SMB dionaea/smb/smb.py:94-critical: === SMB did not get enough data
31.SMB Write AndX Request
- The file has started download
- Remaining = 57344
- ByteCount = 4033
- From the Data field, it show the file start with b'MZ\x90\x00\x03\x00\x00\x00\...This program cannot be run in DOS mode.\r\r\n$\x00\x00\x00\......x00\x00\x00\x00\x00'"
- We can conclude that it is a PE file, and the filesize is 57344bytes.
31. [28072010 22:11:08] SMB dionaea/smb/smb.py:362-warning: WRITE FILE!
32.SMB Write AndX Response
33. 2 alert triggered as below:
[28072010 22:11:08] SMB dionaea/smb/smb.py:94-critical: === SMB did not get enough data
34.SMB Write AndX Request and SMB Write AndX Response has until the file transfer finish
- It totally transfer 57344 bytes, which is 4030 bytes at the 1st attempt, following by 13 attempt of 4032 and the last attempt is 898 bytes.

Part 3

After the file transfer is completely done :
1.SMB Trans2 Request
-Setup = [TRANS2_SET_FILE_INFORMATION]
2.SMB Trans2 Response
3.SMB Close
4 The bistream has recorded in path: (string) /opt/dionaea/var/dionaea/binaries/smb-QsOzHt.tmp
5.Here the file that downloaded
[28072010 22:11:14] incident incident.c:203-debug: file: (string) var/dionaea/binaries/12fb7332920a7797c2d02df29b57c640
[28072010 22:11:14] incident incident.c:203-debug: md5hash: (string) 12fb7332920a7797c2d02df29b57c640
6. The file has uploaded to Anubis,Norman and luigi.informatik.uni-mannheim.de for analysis
7. SMB Close

Part 4

The attacker continue after the file has downloaded by Dionaea,
1.SMB Trans Request
-Calling SVCCTL OpenSCManagerA
-opnum: (int) 27
2.SMB Trans Response
3.SMB Tree Disconnect
4.SMB Tree Disconnect
5.SMB Trans Request
-Calling SVCCTL CreateServiceA (18)
-opnum: (int) 24
-The attacker hope to create a new service as "Microsoft Windows Genuine Updater" with the path "%SystemRoot%\\csrss.exe\"
6.SMB Trans Response
7.SMB Trans Request
-Calling SVCCTL CloseServiceHandle (0)
-opnum: (int) 0
-SMB Trans Response
8. Upload to 3 Sandbox has completed.

There are a few SMB_Echo packet along the way, I decided to drop it off and only focus to these several connection. The attack first seen from [28072010 22:10:55], end at [28072010 22:11:24], overall duration is 29 seconds

Analysis done :)


Note: I found that my dionaea has showed this message and it halt after the overall process, is a bug or random error?
[28072010 22:11:25] thread threads.c:90-critical: Threadpool is crowded 4/2, suspending *all* activity

Sunday, July 18, 2010

Mid-term of Dionaea project

It has reached the mid-term evaluation of the Google Summer of Code 2010. I glad that it is a nice learning curve for me and my work has improved Dionaea features from time to time. This could be a good way to take note about my progress for the past 8 weeks til today, before I forgot.

My work simply more focus on the smb rpc stack improvement as this is the lack-off part for Dionaea. Here the summary of the progress :

Prior to week 1
We have seen that some malware will try to propagate with ipc connection. It is crucial for Dionaea to support these IPC sessions, such as response to the ipc connection, network sharing enumeration and addition, user enumeration and file copying across the network.

Done
- Intensive reading for theory
- POC for ipc connection, share and user enumeration, share addition and file copying

Week 1 (24-30 May)
- Support for several RPC SRVSVC calls has added
- The ipc connection and user enumeration worked.
- For the network share enumeration, Dionaea has support the SRVSVC SHARE_INFO_1 struct which can be tested with smbclient. I have added the support for SHARE_INFO_502 struct for the detailed network enumeration

Week 2 (31-6 June)
- Support for network share addition and file copy over the network functions have done.
- SRVSVC SHARE_INFO_2 struct has added as it is needed for NetShareAdd. For now, Dionaea may support SHARE_INFO_1, 2 and 502.

Week 3 (7-13 June)
- Receive and study the beauty code of RPC call by Markus.
- Made change of the original 'ugly and raw' code implementation of the past 2 weeks.

Week 4 (14-20 June)
- Code cleaning has done, as several classes for RPC SAMR and SRVSVC have added. This classes have made the further SAMR and SRVSVC support easier as the classes have reused in several handler.
- NDR support for RPC_UNICODE_STRING has added

Week 5 (21-27 June)
- Start moving in to work on Dionaea support for NMAP NSE. The main focuses is smb-enum-users.nse and smb-enum-shares.nse.
- several SAMR and LSARPC classes added
- smb-enum-user.nse support has completed

Week 6 (28-4 July)
- Continue the Dionaea support for NMAP NSE
- SRVSVC SHARE_INFO_0 support has added as it is needed to response correctly for smb-enum-shares.nse. Up to now, Dionaea able to support SHARE_INFO_0,1,2 and 502 struct
- smb-enum-shares.nse and smb-enum-domains.nse done

Week 7 (5-11 July)
- Add the part for NTLM authentication without OID
- Add the ASN BER identifier encoding function which is used to construct the SecurityBlob of NTLMv2 authentication
- Dionaea repo has encountered faulty merge as conflict happened between different commits. Revert the reverted merge solve the problem . Nice reference
http://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt

Week 8 (12-18 July)
- Start work on dionaea support for metasploit exploit
- Determined the msf OS fingerprinting method
- Dionaea can support and response well to metasploit ms08-067 exploit, with the correct OS type and language fingerprint


More to go for the coming weeks..

Sunday, July 4, 2010

Dionaea : bind_bottom_up and bind_top_down

Dionaea has ported with Scapy stack for the packet disectation and smb implementation. In dionaea code smb.py, there are some bind_bottom_up() and bind_top_down() function which dealing the SMB_HEADER layer and other underlying layer. This 2 function is important as it will lead to the layer stack over with each other by manipulating the correct parameter.

Example of these function in Dionaea,

bind_bottom_up(SMB_Header, SMB_Negociate_Protocol_Response, Command=lambda x: x==0x72, Flags=lambda x: x&0x80)

I always confuse with the different between both usages. And here i found a nice documentation and explaination in Scapydoc from secdev.

bind top down
bind top down(lower, upper, fval)
Informs upper layer that, when stacked on lower, it must overload lower’s
fields whose names are the keys of the fval dictionnary with their associated
values.

bind bottom up
bind bottom up(lower, upper, fval)
Informs lower layer that, when dissected, if all of its fields match the fval
dictionnary, the payload is upper