4/30/2012: This issue has been fixed by Sysax. Please download version 5.60 or later from their site.
****************
The exploit madness continues with Sysax. This time Sysax Multi Server can be pwn3d by requesting a long remote path through the SFTP module. Like my other Sysax exploits, this one is post authentication and the offset is based on the length of the user's home path. The home path must be at least 19 bytes long for it to work.
For example, C:\AAAAAAAAAAAAAAAA is 19 bytes long, which is what I used in my exploit script. Unfortunately, unlike the last exploit, there is no way to dynamically figure out the home path so this bug is less useful than others. Regardless, here are the details.
I am using paramiko for the python SSH connection (apt-get install python-paramiko) to the server as well as egghunter because of some tight buffer space. This is also an SEH exploit. The important point to note in regards to the SEH is that this exploit would not work using a PPR from the main program executable (sysaxservd.exe). This is due the null byte in the PPR address prevents the exploit from working. However, there is a non safeSEH compiled DLL that I did find, called RPCNS4.dll. In Server 2003, this DLL IS compiled with safeSEH so it will not work on 2K3.
Here is a screenshot of the Sysax user settings required for this exploit to work, notice that no special/elevated permissions are necessary.
Either of the two check boxes in the red box yield the same results.
The meat of the exploit is in this line:
remotepath = junk + nseh + seh + "\x90" * 10 + egghunter + "\x90" * 1000 + shell + "\x90" * 100
When you look at the application at the time of the crash in your debugger, you will see a short space of buffer that we control after we hit our NSEH jump. However, the 1000 nops and the shell do get stuffed into memory somewhere else. The exact location doesn't matter because our magic egghunter will find it for us!
Manually searching through memory to see if we can find that egg ourselves....
Blam.
After executing our exploit without the debugger, we have success!
The software is here: http://www.mediafire.com/?d3nquu1j3n3u57v
(exploit-db is hosting the wrong version of the software)
The exploit is here: http://www.exploit-db.com/exploits/18534/
No comments:
Post a Comment