Pages

Monday, February 27, 2012

Sysax Multi Server 5.53 SFTP Exploit

****UPDATE****
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/

Sysax Multi Server SSH Username Exploit

3/3/2012 - UPDATE :
Today @sinn3r ported this exploit to the Metasploit framework

4/30/2012 - UPDATE:
This issue has been fixed by Sysax. Please download version 5.60 or later from their site.
********************

It's still raining Sysax exploits. This is the worst one yet - a pre authentication universal SEH overwrite.

It is pretty straight forward. Send 10,000 bytes in a username, control SEH and execute our egghunter to find our shell.

Nothing complicated with home path lengths or SID gathering either. The only small issue was with the shellcode, there were a number of bad chars but that was solved by using the alpha/mixed encoder. I tested this exploit on 3 different versions of their software and they're all vulnerable (<= 5.53). It's likely this bug has been around for a long time.

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/18535/




Tuesday, February 7, 2012

Sysax Multi Server 5.52 File Rename Exploit

****UPDATE****
4/30/2012:  This issue has been fixed by Sysax. Please download version 5.60 or later from their site.
****************

My assault on Sysax Multi Server continues. This time, the stack overflow happens in the "file rename" function from within the web server. This bug wasn't as straight forward as the last one I released and ended up being quite a little challenge. The 5.52 bug uses an egghunter, finds the SID and also figures out your home path that the administrator setup for you.

The SID is significant because it is your logon token that is required for all subsequent requests to the server. Unfortunately this exploit does require valid credentials and proper permissions. The user needs "write" access for files for this exploit to work.


The home path is also significant because the offset to overwrite EIP is directly related to this. More on that later.


This script is completely automated. All you need to provide is the IP, port, credentials and the OS you're exploiting. It works on XP and 2K3. Unfortunately, I have not mastered DEP bypass yet so the 2K3 exploit assumes DEP is turned off.

Diving into the script, I'll talk through my line of thinking and why things are the way they are. I'm a terrible programmer so I apologize in advance.

After we gather the required information we need to encode the supplied credentials. You'll notice a hex 0a which is how the server expects the credentials to come across.


Now, we'll log into the server so that the server generates a valid SID. We'll go grab the SID momentarily. All of this info was captured through the Burp proxy and translated over to python.


Now is when it begins to get interesting. To grab the SID we'll send our above login POST data and capture the response from the server. Then, we'll parse that response for anything that is "sid=". The regular expression in use looks for a 40 byte number that starts with sid=. The server puts this all in the javascript of the page the client receives. How nice of them?! You'll notice a rather large receiving buffer. This is to try and accommodate the situation where the user has a lot of data uploaded into their directory already.


When you view the source of the page after you log in, you'll see things like this all over noting the SID that has been assigned to you. This is what we're searching for in the regex above. Note, these SIDs expire which is why I had to automate this process.


Next, we'll parse that same data for the user's home path. If there is a file already uploaded then the path is directly in the source of the page again. If it is not, we attempt to upload a file for them and re-parse the data to try to find the path. We must get this value or the exploit will fail.


Here is an example of what we're looking for in the source of the server's response. You can see the path clearly.


If the regex doesn't match anything here is how we upload a file called "file.txt" then re-search and display the path. We don't really care about the actual path but just the length of the path.



Calculating the length of the path based on anything that is after C:\  The reason for this is because I calculated the offset based on C:\A  However, we'll see soon that we actually can't get this to work unless the full path is at least 16 bytes longer.



Basically, we need it to be 16 bytes because otherwise we can overwrite EIP but cannot jump to any controlled buffers. Adding a longer folder path changes this. As you can see here, ESP now points to a jump that we've dictated. We can control a few bytes now and it's just enough to jump back up the stack into a huge buffer. Since we have a limited buffer space, we'll just use a short negative jump, hit an egg hunter and have it find our shellcode and execute it.


Juicy buffer.


This is where all the magic happens. We'll use the pathlength that we calculated earlier to adjust our buffer. We also need to account for the egghunter shellcode and a little NOP padding. The 12 NOPs gets our buffer to be exactly where ESP points when we overflow the buffer. I probably need a little space here for some padding but it seemed to work as is.


This next part is where we'll stuff our shell into memory, the part that the egghunter will look for. The second part is the actual buffer overflow, the big red arrow.



At first, I could not find my buffer in memory. However, I realized that if I didn't close the socket the shellcode persisted in memory. I also noticed that when I sent the stage 1 shellcode, if I opened a recv() it would just hang. That's why you don't see one there either.



Putting it all together we the pwnag3 here.


The only problem I encountered is that the 2K3 exploit is less reliable than the XP one. I am still looking into this but for some reason the 2K3 box will sometimes return an HTTP 200 response when we try to overflow the buffer. The XP one seems to work every time though.

A full copy of the exploit can be found here: http://www.exploit-db.com/exploits/18476/

A copy of the 5.52 version of Sysax Multi Server software can be found here: http://www.mediafire.com/?x16mqi8nbbeo1nx