Monday, November 22, 2010

MS10-054 Microsoft Windows SRV.SYS SrvSmbQueryFsInformation Pool Overflow DoS

Another SMB protocol vulnerability that catch my eye these few days - MS10-054 Microsoft Windows SRV.SYS SrvSmbQueryFsInformation Pool Overflow DoS. My curiosity as the same : How it work?

This vulnerability has first discovered Laurent GaffiƩ in early 2010. He also discovered the issue in ms10-020 vulnerability previously. Summary from the advisory :

"A vulnerability in the Windows kernel can be triggered via SMB in Microsoft
Windows versions ranging from Windows 2000 through to Windows 7. This vulnerability allows an attacker to trigger a kernel pool corruption by sending a specially crafted SMB_COM_TRANSACTION2 request.Successful exploitation of this issue may result in remote code execution with kernel privileges, while failed attempts will result in a Denial of Service condition. Microsoft haspublished a patch to resolve the issue"

What is SMB_COM_TRANSACTION2 ?
From [MS-CIFS].pdf, SMB_COM_TRANSACTION2 subcommands provide support for a richer set of server-side file system semantics. The "Trans2 subcommands", as they are called, allow clients to set and retrieve Extended Attribute key/value pairs, make use of long file names (longer than the original 8.3 format names), and perform directory searches, among other tasks.

The subcommand can be find in http://manubatbat.free.fr/doc/smb/6.2.htm

The original SMB_COM_TRANSACTION2 request is in this format :

SMB_Parameters
{
UCHAR WordCount;
Words
{
USHORT TotalParameterCount;
USHORT TotalDataCount;
USHORT MaxParameterCount;
USHORT MaxDataCount;
UCHAR MaxSetupCount;
UCHAR Reserved1;
USHORT Flags;
ULONG Timeout;
USHORT Reserved2;
USHORT ParameterCount;
USHORT ParameterOffset;
USHORT DataCount;
USHORT DataOffset;
UCHAR SetupCount;
UCHAR Reserved3;
USHORT Setup[SetupCount];
}
}
SMB_Data
{
USHORT ByteCount;
Bytes
{
SMB_STRING Name;
UCHAR Pad1[];
UCHAR Trans2_Parameters[ParameterCount];
UCHAR Pad2[];
UCHAR Trans2_Data[DataCount];
}
}

How MS10-054 works?
The culprit is the MaxDataCount field! It indicates the maximum number of data bytes that the client will accept in the transaction reply. Windows will allocate a pool chunk with the MaxDataCount size without any sanity check. By allocating ZERO size of pool chunk, it could be a trouble if freeing the memory chunk.

PoC can be found in the full disclosure adviosry http://seclists.org/fulldisclosure/2010/Aug/122 . I have try to test the PoC and it work with the target machine is in "WORKGROUP" domain and has a user namey "Y0" (0 is the zero).

C:\Python26>python.exe test.py 192.168.56.101 C
[+]Negotiate Protocol Request sent
[+]Session Query sent

C:\Python26>python.exe test.py 192.168.56.101 C
[+]Negotiate Protocol Request sent
[+]Session Query sent
[+]Malformed Trans2 packet sent
[+]The target should be down now

C:\Python26>

And the WinXP VM freezee...

For the PoC packet, we can clearly see the culprint "MaxDataCount = 0".

After all, the working exploit has included in metasploit modules/auxiliary/dos/windows/smb/ms10_054_queryfs_pool_overflow.rb

Wednesday, November 17, 2010

VirtualBox and Vmware network setup

Just figure out this.

1. Connect Virtual Box images and VMware Player Images.

Settings
Virtual Box - VirtualBox Host-Only Ethernet Adapter
Vmware's setting in vmnetcfg.exe : Bridged to VirtualBox Host-Only Ethernet Adapter
Vmware image : Network connection: Bridged

It works! All images can ping each other well. The IP that assigned for the VM images
- Host Machine : 192.168.56.1
- VirtualBox Ubuntu 9.04 image : 192.168.56.101
- VirtualBox Ubuntn 9.10 image : 192.168.56.102
- VMWare Backtrack image : 192.168.56.103

The traffic between images can be captured with wireshark that set to the VirtualBox Host-Only adapter. Another drawback that is the internet connection not work for all images, although the Host Machine able to acccess internet well.

Lets' improve

2. Create internal network for 2 VirtualBox images + internet

Setttings
Virtual Box Ubuntu 9.04 image
- Enable 2 Network Adapters
- Setting for Adapter 1 : NAT
- Setting for Adapter 2 :
 Attached to "Internal Network", Name:"intnet"
IP setting: 192.168.4.1
Subnet mask : 255.255.255.0
Gateway : 10.0.3.2 ( which same as the NAT gateway)

Virtual Box Ubuntu 9.10 image
- Enable 2 Network Adapters
- Setting for Adapter 1 : NAT
- Setting for Adapter 2 :
 Attached to "Internal Network", Name:"intnet"
IP setting : 192.168.4.2
Subnet mask : 255.255.255.0
Gateway : 10.0.3.2 ( which same as the NAT gateway)

Both images can access internet and ping each others, and most importantly it is the internal network. The network packets cannot captured with wireshark listening on Host Machine, unless the wireshark is listening inside VM images.

Reference
https://opensourceexperiments.wordpress.com/2008/04/13/case-study-configuring-internal-networking-work-for-talking-two-linux-guest-os-ubuntu-on-windows-vista-host/

Monday, November 15, 2010

Simple steps to improve Dionaea SMB stack

SMB protocol is one of the core protocol that supported by Dionaea. The attacks on Port 445 will be received and logged in the sqlite database. Dioanea emulates SMB protocol and the related functions in SMB stack have written in Python. If you are running Dionaea and you found the unsupported RPC calls, you are most welcomed to improve Dionaea's SMB stack.

This is my work out. The process:
1. Dig out the unsupported function, in this case is the unsupported RPC call
2. Refer to MSDN Library for further detail about the function call
3. Find the application/test suite that can trigger the function well. Observe the original request and reply of the function, by using a clean Windows Image
4. Code it out!
5. Test, debug, test, debug, BINGO!!
6. Commit to the tree

Example:
1. Recently I found that this lines always appear in /opt/dionaea/var/log/dionaea.log, and I realised this unsupported RPC SRVSVC call with Opnum 21 hit my sensor frequently.
[13112010 09:02:07] rpcservices dionaea/smb/rpcservices.py:104-info: 
Unknown RPC Call to SRVSVC 21
.....
[13112010 12:21:37] rpcservices dionaea/smb/rpcservices.py:104-info:
Unknown RPC Call to SRVSVC 21
.....
[13112010 13:38:34] rpcservices dionaea/smb/rpcservices.py:104-info:
Unknown RPC Call to SRVSVC 21
.....

With the query to database /opt/dionaea/var/dionaea/logsql.sqlite, 68 hits of such unsupported RPC call attacked the sensor that running not more than 72 hours.
Here the database query result:
COUNT(*) | dcerpcrequest_uuid | dcerpcrequest_opnum | dcerpcservice_name 
68 4b324fc8-1670-01d3-1278-5a47bf6ee188 21 SRVSVC
1 12345778-1234-abcd-ef00-0123456789ac 34 samr

2. Refer to MSDN Library http://msdn.microsoft.com/en-us/library/cc247243%28v=PROT.13%29.aspx, it is the NetServerGetInfo method which used to retrieve current configuration information for the targeted server. The method structure quite simple:

NET_API_STATUS NetrServerGetInfo(
[in, string, unique] SRVSVC_HANDLE ServerName,
[in] DWORD Level,
[out, switch_is(Level)] LPSERVER_INFO InfoStruct
);

3. With some googling time, I managed to find the way that I can observe the original request and response of such NetServerGetInfo method. Here the simple Win32 program that can be used to test the NetServerGetInfo method. It worked well with a clean WindowsXP image as target and packet detail can be studied with Wireshark.
http://www.installsetupconfig.com/win32programming/networkmanagementapis16_49.html

Note: To make this simple program work, the targeted WindowsXP need Guest account to be enabled. This spend me quite some time to figure it out as the System error 17XX keep appeared.

4. It is the time to code the method and let Dionaea support it! The RPC methods has resided in http://src.carnivore.it/dionaea/tree/modules/python/scripts/smb/rpcservices.py and it seperated clearly in classes such as ATSVC, DCOM, IOXIDResolver,lsarpc and others. Find the SRVSVC class and define the NetServerGetInfo handler.

5. Test the code with the Win32 program that compiled previously. Observed the packet in Wireshark. Test, debug, test, debug.. and it worked well as similiar with the Windows image. Further code test can be done by put it into the real network. The code works!

Observation with readlogsqltree.py

2010-11-14 10:30:16
connection 21150 pcap tcp reject 192.168.1.50:139 <- 118.X.180.91:47775
2010-11-14 10:30:16
connection 21151 smbd tcp accept 192.168.1.50:445 <- 118.X.180.91:47774
dcerpc bind: uuid '4b324fc8-1670-01d3-1278-5a47bf6ee188'
(SRVSVC) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
dcerpc request: uuid '4b324fc8-1670-01d3-1278-5a47bf6ee188'
(SRVSVC) opnum 15 (NetShareEnum ())
dcerpc request: uuid '4b324fc8-1670-01d3-1278-5a47bf6ee188'
(SRVSVC) opnum 21 (NetServerGetInfo ())

Waiting next coming attack :)

6. Commit to the tree. Example : http://src.carnivore.it/dionaea/commit/?id=974002a510a13f4565d58b458da665bd4e165e7c

7. After the commit, the added handler need to observe from time to time. Sometime the real world attack will be different from what what have coded. It need minor changes in certain packet field to make it work.

This is one of the ways to improve SMB stack. Simple and exciting. Feel free to write yours. If you need the git tree access, feel free to contact Markus nepenthesdev@gmail.com


Cheers,