MS06-036 Windows DHCP Client - Broadcast Attack

[darkking]

MS06-036 - DHCP Client Service

Vulnerability in DHCP Client Service Could Allow Remote Code Execution (91438b)

http://www.microsoft.com/technet/security/Bulletin/MS06-036.mspx

The DHCP API has a stack-based overflow in the misuses of additional DHCP options. By appending a severely long domain name (option 15) we can overwrite the SEH at the end of the stack. The trick to this exploit is that it converts your ascii buffer to unicode on the stack, ergo you become limited it the options you can choose.

You have to try 10 or so additional option 250s without null termination.

There's a check in dhcpsvc.dll ( 5.0.2195.6685 ) @ offset 7736f3dc

(JMP from 0x773656AF):

7736F3DC > 3D F4010000 CMP EAX,1F4

7736F3E1 . 72 05 JB SHORT dhcpcsvc.7736F3E8

7736F3E3 . B8 F3010000 MOV EAX,1F3

7736F3E8 > 8BC8 MOV ECX,EAX

The exception is triggered at:

(134.17c): Access violation - code c0000005 (first chance)

....

eax=00101f14 ebx=00000df1 ecx=01bdffe8 edx=7ffc101c esi=000007c1 edi=0000000b

eip=77f87adb esp=01bdf2f4 ebp=01bdf300 iopl=0 nv up ei pl nz ac po nc

cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000216

ntdll!RtlOemToUnicodeN+0x4d:

77f87adb 6689791e mov [ecx:0x1e], di ds:0023:01be0006=????

Throwing the exception will allow us to take over the flow of execution. However our original string gets mangled via the RtlOemToUnicodeN() function. A filtered copy of our payload is pushed onto the stack and will overwrite SEH. However this limits our range of return locations significantly.

Some Non-Ascii Characters get converted and give us different address ranges we can use to return to:

# C5 converts to 253C

# BB = 2557

# AA = 00AC

# DD = 258C

# EE = 03B5

# 88 = 00D6

# 99 = 00EA

# F3 = 2591

# B0 = 2264

# 8F = 00c5

Given some of these unique values we can overwrite the SEH with, we're looking for a jmp/call ebx or a pop/pop/retn. Instead we just chose a static location in hopes that our original ascii payload sits there.

so we chose a nice fatty location on the stack with a huge sled.

(Obviously more time can be spend into making this 100% reliable, however I would certainly never release it. There is a pointer on the stack at esp+8 that

will alow us to utlize a pop+pop+ret combination. If you can find a valid region of static memory we can fit past our ascii filter, then you will return at

the end of our filtered buffer on the stack. From there it would be trivial to write a unicode stage-2 to search through the stack looking for our ascii payload. See Aitel's BlackHat presentation on unique ways of bypassing unicode filters and advanced stack & heap overflows.)

This is not a very quiet exploit, and is only practacle for live penetration tests, however:

Combined with an arp spoofing trick, you can make the node invisible by changing the mac address ever so often. The only way to track this down would be to

log into the 1st hop route and tracking the mac -> switch -> switch -> port# and the issue a shutdown port#

There you have it, I gave you the hack and the fix all at one! We believe in security by identifying both sides of the equation and addressing them as a whole: hack, and anti-hack. Lets call it the karma of exploitation research.

Usage: ./bl4ck_ms06_036.py eth0 10.0.1.5

(the ip really doesn't matter since it's not used in the first place)

MS06-036 DHCP Client

Credits: BlackSecurity