WINS Fingerprint

[hdm at metasploit.com (H D Moore)]

This has been reported by a couple people, I am still trying to figure out 
why it isn't working correctly. If you get a chance, try attaching WinDbg 
and using the memory viewer to look at address 0x53df4c4. It should be 
overwritten by the heap pointer. If this address has something that 
doesn't point into 0x53xxxxxx, please let me know. 

The SP4++ box I have here is hit every time, I updated it with everything 
but the WINS patch set. It sounds like some other hotfix is updating the 
WINS service (and ntdll.dll, where those two 0x77 ptrs are being leaked 
from). If you get a chance, could you send me a copy of your wins.exe and 
ntdll.dll files? (offlist). I just want to compare the TimeDateStamp to 
see whether its a WINS version differnece or something else.

On Tuesday 01 February 2005 04:00, alucardSoD wrote:
> I was trying out the WINS exploit within the framework and it seems
> that the function pointer was not hijacked. The fingerprint was
>
> [*] Pointers: [0x05371e90] 0x0541ffa4 0x77f81f55 0x77f82518
>
> It did not seem to match any of the prototypes listed. However, the
> vulnerability probe verified it to be vulnerable.The closest to
> it is SP4++. I was able to run it again and connect to the service and
> do the overwrite the second, third time so apparently it did not die.

The exception handler will prevent the service from crashing, but failed 
overwrite attempts will push the base address for the next structure up 
and prevent this exploit module from working. It is somewhat possible to 
brute-force this, but each failed attempt pushes the base pointer and 
each successful write pushes it up by a different offset, make it really 
difficult to blindly predict the current address of the struct.

-HD