Re: Analyze binary for holes

[xenophi1e <oliver.lavery () sympatico ca>]

In-Reply-To: <20030729162007.7689.qmail () www securityfocus com>

> WINDOWS:
> I have no idea how to recognize a vulnerable program in the Windows 
> word.Is there anything like SUID-roor, etc??

Howdy,

I can't claim to be an authority on this, but I've had a bit of luck with 
this technique...

First off, there's no equivalent to SUID root, but if you're just looking 
for local priv elevation vulnerabilities, check out the various Shatter 
attack things that have been buzzing about lately, like Paget's paper and 
BH briefing, Brett Moore's SEH posts, or my iDefense paper. Local priv 
elevation on windows is wide open.

If you want to find full-fledged buffer overflows then the first thing 
you need is a copy of IDA-Pro disassembler. IDA is the only reversing 
tool I've found for windows that's any good (anyone have another good 
suggestion?). Second thing you need to do is find a target application. 
Then...

1) Fire up IDA and disassemble your target (simple enough).

2) IDA will xref all the calls to library functions, like strcpy, 
sprintf, and other fun stuff. Find a list of common vulnerable functions 
on windows (there are more than just the standard CRT ones) and dig 
through the instances one by one. If found then goto 5.

3) If you can't find anything obvious above, then search through the 
disassembly for 'sub esp, <big number>'. This is in almost every function 
prolog, but if you look for instances where a function is reserving a lot 
of stack for local vars, you'll often find stupid inline strcpy loops and 
that sort of thing (the IE HTML conversion bug was one of these). If 
found then goto 5.

4) Still no luck? Then either move on, as there's still no shortage of 
stack overflows on windows, or look for heap overflows and logic errors, 
which require a lot more creativity.

5) IDA has a really handy xref charting feature. Using a debugger and 
xref charts it's pretty simple to figure out how to get execution into 
your vulnerable function, and with luck you can even supply broken input. 
This bit was covered in a good phrack article a while back...

This is a simplified explanation. Looking for bugs using a bottom-up 
approach isn't great by itself. Combine the instructions above with a 
little top-down brute forcing, a debugger, and a little imagination and 
you'll find something without too much trouble, I suspect.

Cheers,
~x