Good Morning, In playing with the new rs_iis.c (http://www.rs-labs.com/) proof of concept exploit in the lab. In order to better understand how the exploit works, I've set up a scenario with an attacking machine located on the same logical segment as a web server with OllyDbg installed. I've noticed from the documentation that the RET will likely have to change for the exploit to work, and have read that if you you brute force the RET, while having a debugger attached to the inetinfo process on the server, you will see the correct RET when the IIS service crashes. So, what I've done is used a perl script to run the RET with every possible combination for from 0x0000 to 0xffff against a web server with OllyDbg attached to the inetinfo process. In order to save some time, I have the script checking to make sure IIS has not crashed in between RET address attempts (via simple TCP SYN) so it doesn't try to brute force a dead service. I'm not sure if this step is necessary, as I've noticed Win2k will restart the service when it is terminated unexpectedly, but what the heck. AFAIK, here's what should happen when the exploit is run. Please feel free to interject your thoughts: 1) The debugger will break when the first exception is produced by running the exploit against the server. (So it looks like brute forcing the RET until IIS crashes is what I need to do here? Does that sound right?) 2) From here, you're supposed to set a breakpoint at "non-unicoded RET value" and resume execution until you reach that point. 3) Next, you look for the shellcode in memory and make sure the RET points to a NOP before the shellcode. I'm finding that when a couple of interesting sticking points: 1) I fire up OllyDbg, attach to inetinfo, and select RUN (because it defaults to paused). 2) I run the exploit against the machine, using the default RET of 0x4804, and I get: "Server is vulnerable but the exploit failed! Change RET value (e.g. 0xce04) and try again (when IIS is up again) :-/" 3) An interesting note is that in OllyDbg, it says that the process was terminated with exit code 0. I also see in the event log on the server that the IISADMIN and WWW services have terminated unexpectedly, and that IIS was stopped and restarted by NT AUTHORITY\SYSTEM (to recover the web service). 4) So now I'm to the point where I should be able to find the "non-unicoded RET" value and set a breakpoint there. I'm just not too sure what to do here. I've got the debug output, a web server that is still able to serve content (which sounds okay so far), and a crashed inetinfo process, but I think I need help tracking down this RET address with OllyDbg. If you guys have experience in debugging a web app like this and feel like helping out, or have a link to a good tutorial, I would really appreciate the info. Thanks, Jeremy
This archive was generated by hypermail 2b30 : Fri Mar 28 2003 - 08:27:40 PST