Reversemode
Home
Wednesday, 09 July 2014
 
 
BYTES & WORDS
Regarding SMB2.0 Negotiate BSOD published by Laurent Gaffié
Written by Rubén   
Tuesday, 08 September 2009

Today I wake up with an advisory published by Laurent Gaffié where a possible BSOD is announced. The advisory does not provide any technical detail and it is only based on empirical results so it needs to be verified. This is the result of my brief research. Change DoS to Remote Code Execution and Local Privilege Escalation.

Why?

Module: srv2.sys

Code (asm)

; int __stdcall Smb2ValidateProviderCallback(PVOID DestinationBuffer)
_Smb2ValidateProviderCallback@4 proc near


.text:000156B3 loc_156B3:                              ; CODE XREF: Smb2ValidateProviderCallback(x)+4D5j
.text:000156B3                                         ; Smb2ValidateProviderCallback(x)+4DEj
.text:000156B3                 movzx   eax, word ptr [esi+0Ch]; packet->SBM_Header->Process_ID_High
.text:000156B7                 mov     eax, _ValidateRoutines[eax*4]; BUG - out-of-bounds dereference.
.text:000156BE                 test    eax, eax
.text:000156C0                 jnz     short loc_156C9
.text:000156C2                 mov     eax, 0C0000002h
.text:000156C7                 jmp     short loc_156CC
.text:000156C9 ; —————————————————————————
.text:000156C9
.text:000156C9 loc_156C9:  ; CODE XREF: Smb2ValidateProviderCallback(x)+4F3j
.text:000156C9                 push    ebx
.text:000156CA                 call    eax ; Smb2ValidateNegotiate(x) ; Smb2ValidateNegotiate(x) - KABOOOM!!
  As you can see,[ ESI+0xC ] points to our packet, exactly to the ProcessIDHigh header field whose size is 16 bits. We can fully control this value. Later on this value is used as index to a Function Pointer within the function table _ValidateRoutines. Classic Bug, an out-of-bounds dereference since the code is not checking the size of the table before dereferencing the function pointer. This is the reason why this vulnerability is a Remote Code Execution and not only a DoS. And this is the reason why the exploit provided may or may not crash a machine. If the page pointed by the index is invalid the system will BSOD otherwise it might crash on another point or simply not to crash.

How to exploit it?

We see that ESI points to our packet, in addition this function table is located at .data which is located before .PAGE addresses so we can dereference a pointer in that area as well. We "only" need to find a suitable pointer to control the execution.

Vulnerable systems:
Vista, 7 RC and < 2008 Server R2 according to Microsoft.

Keep tuned, I'll post any further development regarding this issue.

More info on the blog (castilian) where I collaborate: http://blog.48bits.com

Last Updated ( Wednesday, 09 September 2009 )
Safenet is not so safe...
Written by Rubén   
Tuesday, 02 June 2009

Hi!
Time to VPN Clients...Reversemode proudly presents "Safenet SoftRemote IKE ireIke.exe service Remote Stack Overflow (Pre-Auth) "

ZDI Advisory

Safenet SoftRemote Overview
http://www.safenet-inc.com/softremote/

SoftRemote is an award-winning VPN client platform for desktop and mobile devices that delivers robust security, ease of use, and powerful policy management features. With an installed base of millions of users, SoftRemote has become the de-facto standard for VPN client software worldwide. Leading VPN vendors use the SoftRemote's OEM version within their custom solutions. Some of these products are:
● Juniper NetScreen Remote
● NetGear Prosafe VPN client
● WatchGuard Mobile User VPN Client

Thus, the vulnerability affects every “SoftRemote powered” product.



Preface

In this document we use Juniper NetScreen Remote as “scapegoat” to demonstrate the vulnerability since it is bundled with the vulnerable version of Safenet's SoftRemote OEM version. This fact does not mean that Juniper NetScreen Remote is the only product affected. As it was explained before, every product powered by Safenet's SoftRemote is vulnerable.

Technical Details
ireIke.exe service is prone to a remote stack overflow. Malicious attackers can anonymously exploit this flaw by sending a specially crafted UDP packet to the port 62514. Successful exploitation grants SYSTEM privileges to the attacker.
ireIke.exe service binds several ports for internal usage, this process can be traced by debugging the following function:
Module: ireIke.exe

.text:0043C8E0 sub_43C8E0 proc near ; CODE XREF: sub_41A8B0+295#p
.text:0043C8E0 ; sub_437F00+442#p ...
.text:0043C8E0
.text:0043C8E0 WSAData = WSAData ptr -190h
.text:0043C8E0 arg_0 = dword ptr 4
[...]
.text:0043CAF4 loc_43CAF4: ; CODE XREF:
sub_43C8E0+1ED#j
.text:0043CAF4 ; sub_43C8E0+208#j
.text:0043CAF4 mov eax, dword_46F2BC
.text:0043CAF9 push eax ; int
.text:0043CAFA push 0F432h ; 62514 – IPC socket
.text:0043CAFF push 11h ; int
.text:0043CB01 push 2 ; af
.text:0043CB03 call sub_43B850 ; binds
.text:0043CB08 add esp, 10h
.text:0043CB0B cmp eax, edi
.text:0043CB0D mov dword_46F280, eax
.text:0043CB12 jnz short loc_43CB34
.text:0043CB14 test byte_45ED58, bl
.text:0043CB1A jz short loc_43CB34
.text:0043CB1C push offset SourceName ; "IreIKE"
.text:0043CB21 push offset aSUnableToBin_1 ; "%s: Unable to
bind IPC socket!"
.text:0043CB26 mov dword_479FF8, ebx
.text:0043CB2C call sub_437020
.text:0043CB31 add esp, 8
ireIKE.exe after receiving the packet, uses the fifith byte as a “command”.
.text:00449E19 movsx eax, byte ptr [ebx+4] ; fifth byte
.text:00449E1D add eax, 0FFFFFFD8h ; command - 0x28
.text:00449E20 mov [esp+3F4h+var_3DC], ebp
.text:00449E24 cmp eax, 19h ; switch 26 cases 'commands'
.text:00449E27 ja loc_44AB78 ; default
.text:00449E27 ; jumptable 00449E35
cases 7,9,10,14,16-18,20-24
.text:00449E2D xor edx, edx
.text:00449E2F mov dl, ds:byte_44ABE4[eax]
.text:00449E35 jmp ds:off_44ABA8[edx*4] ; switch jump

Last Updated ( Tuesday, 02 June 2009 )
Read more...
Exploiting Novell/Netidentity Agent Remote Arbitrary Pointer Dereference.
Written by Rubén   
Thursday, 09 April 2009

Hi there, After months of inactivity I'm back with a hot exploit for a recently released flaw I discovered some time ago.

Extracted from the ZDI's advisory :
Vulnerability Details

This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Novell Netware. A valid IPC$ connection must be established in order to exploit this vulnerability.

The specific flaw exists within xtagent.exe during the handling of RPC messages over the XTIERRPCPIPE named pipe. Insufficient sanity checking allows remote attackers to dereference an arbitrary pointer which can be leveraged to execute code under the context of the system user.


Technically

xtagent.exe creates a named pipe which is used as an RPC endpoint ( its own RPC implementation though )

Module: xtagent.exe (4.91 SP4)

.text:0040129C lea ecx, [ebp+SecurityAttributes]
.text:0040129F push ecx ; lpSecurityAttributes
.text:004012A0 push 4E20h ; nDefaultTimeOut
.text:004012A5 push 800h ; nInBufferSize
.text:004012AA push 800h ; nOutBufferSize
.text:004012AF push 0FFh ; nMaxInstances
.text:004012B4 push 4 ; dwPipeMode
.text:004012B6 push 3 ; dwOpenMode
.text:004012B8 push offset Name ;
"\\\\.\\PIPE\\XTIERRPCPIPE"
.text:004012BD call ds:CreateNamedPipe
This pipe can be accessed only if a valid $IPC session can be established. No valid credentials are needed so you can also use a NULL session.

The pipe waits for remote commands which are referenced by the first dword within the received buffer.

Module: xtagent.exe
.text:004013A2 push eax ; lpOverlapped
.text:004013A3 lea edx, [ebp+NumberOfBytesRead]
.text:004013A6 push edx ; lpNumberOfBytesRead
.text:004013A7 push 800h ; nNumberOfBytesToRead
.text:004013AC push ebx ; lpBuffer
.text:004013AD push esi ; hFile
.text:004013AE call ds:ReadFile
.text:004013B4 test eax, eax
.text:004013B6 jz loc_401542
.text:004013BC mov edi, 18h
.text:004013C1 cmp [ebp+NumberOfBytesRead], edi
.text:004013C4 jb loc_401557
.text:004013CA mov eax, [ebx] ebx= user-controlled buffer
.text:004013CC dec eax
.text:004013CD cmp eax, 4 ; 5 RPC functions
.text:004013D0 ja loc_401508 ; default
.text:004013D6 jmp ds:off_4015E0[eax*4] ; switch jump
The buffer where ReadFile copies the received bytes is allocated, just one time per session, in the heap and then subsequently zeroed in each request. Module: xtagent.exe
mov eax, dword_40D55C
mov ecx, [eax]
push 800h ; buffsize
push eax
call dword ptr [ecx+68h] ; allocate buffer
mov ebx, eax
[...]
.text:00401397 mov ecx, 200h
.text:0040139C xor eax, eax
.text:0040139E mov edi, ebx
.text:004013A0 rep stosd ; memset(buffer,0,buffsize)
There are 5 functions we can reach through this named pipe. The flaw is that we can dereference an arbitrary pointer to a VTABLE thus controlling a call to an arbitrary address.

Module: xtagent.exe
.text:004015DD align 10h
.text:004015E0 off_4015E0 dd offset loc_4013DD
.text:004015E0 dd offset loc_401466 ; arbitrary pointer dereference #1
.text:004015E0 dd offset loc_4014C0 ; arbitrary pointer dereference #2
.text:004015E0 dd offset loc_401512 ; heap memory leak #1
.text:004015E0 dd offset loc_401512 ; heap memory leak #2
.text:004015F4 align 10h
So

Module: xtagent.exe
.text:00401466 mov eax, [ebx+8] ; edx controlled (points to sent buffer)
.text:00401469 mov [ebp+var_4], 0
.text:00401470 mov edx, [eax] ;eax controlled
.text:00401472 push eax
.text:00401473 call dword ptr [edx+8] ; edx controlled
We can control all remarkable registers, however we cannot exploit this issue in a reliable manner without knowing where ReadFile has read our controlled buffer.
Fortunately there are two functions which call to WriteFile with a user-controlled size so we can leak bytes from the heap that lies beyond our buffer, therefore we can calculate, based on the next chunk's metadata, where our buffer is located.

Module: xtagent.exe
.text:00401512 push 0 ; jumptable 004013D6 cases 3,4
.text:00401514 lea edx, [ebp+NumberOfBytesWritten]
.text:00401517 push edx ; lpNumberOfBytesWritten
.text:00401518 mov eax, [ebx+4] ; controlled
.text:0040151B push eax ; nNumberOfBytesToWrite
.text:0040151C push ebx ; lpBuffer
.text:0040151D push esi ; hFile
.text:0040151E call ds:WriteFile
graphically



That's all. You can grab more details by reading the exploit code.
  • Novell/NetIdentity Agente Remote Arbitrary Pointer Dereference

  •    Download exploit code.

    happy hunting!

    Last Updated ( Thursday, 09 April 2009 )
    << Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>

    Results 17 - 20 of 64