Sunday, June 3, 2012

Sysax Create SSL Certificate Buffer Overflow

My latest exploit is a buffer overflow in the Create Certificate function of Sysax Server <= 5.60. To get to this part of the application, you likely already have administrative access to the machine which makes this bug kind of useless. However, it was an interesting exercise for a number of reasons.

For one, there is no way to invoke the SSL certificate function from the command line. Two, you cannot get to this functionality remotely through the web administration UI. That leaves us only one option, to paste ASCII directly into the vulnerable field and try to get code execution!

A buffer overflow is possible in each of these fields:

Since we have to literally copy and paste our exploit into one of these fields, we know that we will be limited by ASCII printable characters only. That means that if a keyboard cant type it, we can't use it. The reason this gets tricky is because our assembly addresses also have to be ASCII printable friendly. Basically, we can use anything from HEX 0x20 to 0x7E.

If you look at this chart you can see that from HEX 0x00 to 0x1F are all control characters, which are not on a keyboard. The chart also states the printable range is 0x20 to 0x7F. I don't understand this because 0x7F is for DELETE. How to you type a DELETE? In any case, I'm not including that in my valid set of characters for this exploit. For this, our valid range is 0x20 to 0x7E

On to the exploit development.... First, I copied 5000 A's into the Server Name field:

As you can see we have a clean SEH overwrite so we should simply be able to write a regular SEH exploit. Not so fast. Remember our character issue? We've got to find a PPR address that works within our character set. After !mona nosafeseh we see the following possible files to look for the PPR:

Lets look at the first non SEH enabled file, RPCNS4.dll which starts at 0x5d920000. The 5d is a "]" in ASCII so that is going to be fine. However, the 92 is not in our acceptable range so this entire DLL is out, we can't use it. Looking at the second file, the main executable, you should see a problem immediately. The 00 is another hex value that does not translate to an ASCII printable character.  

Bummer! This SEH approach wont work. I tried a number of different buffer lengths looking for a regular EIP overwrite, but could not find one. Lets keep looking. Here is what we get when pasting the same number of A's into the Country field:

That looks better! From here, it's smooth sailing. Here is a video demo of this exploit:

Exploit is here:

Sysax has been notified and they have fixed the issue in version 5.62 which can be downloaded here:

No comments: