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