('binary' encoding is not supported, stored as-is) In-Reply-To: <20030729162007.7689.qmailat_private> >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
This archive was generated by hypermail 2b30 : Fri Aug 01 2003 - 10:38:16 PDT