Corelan Exploit Development Live Training Review

My team had the opportunity to take Peter Van Eeckhoutte's live exploit development boot camp last week. This is a review of the 2012 version of his course.

A course outline can be found here: https://www.corelan-training.com/index.php/training/corelan-live/

We sat the course over a Saturday and Sunday. My one and only complaint for the course which I'll get out of the way now, is that this should really be AT LEAST a 3 day course. We spent 14 hours each day working with Peter. It was very intense and it melted my brain. By the end of the second day, mental exhaustion parlayed with the complex material began to set in. I really think I would have got more out of the last 5 hours of the course, if it were on a third day. Peter on the other hand, doesn't skip a beat. I bet he would still be talking if we were willing to sit with him that long!

Now that the bitching is out of the way, on to the good stuff. This is a fantastic course and I highly recommend it. The material Peter has put together is high quality and he's clearly put in a huge number of hours perfecting it. The course is a combination of walking through slides and lab exercises. All the students came prepared with VMs specific to Peter's requirements. His labs start easy and eventually get very hard. However, you can tell he has done this so many times because all of the labs work as designed. We literally had one "live demo fail" which he quickly recovered from. If your lab isn't working, he can look at your code (which by the way, he has never seen before and the quality is probably shit) and instantly give you hints on where the problem is. 

Peter is a great instructor because of his teaching style and he's exceptionally good at this stuff. Everyone I talked to after the course said they have never learned so much in a short period of time. As a graduate of the Offensive Security courses, I can appreciate some of the struggle that comes with exploit dev, but at a certain point, if someone tells me to "Try Harder" one more time, I'm going to rage. Peter's approach is different. He certainly makes you suffer, but when he see's you're truly stuck, he throws you a little "nugget" that usually gets you where you need to be. I witnessed this myself as well as with other students. There were numerous "AH HA" moments with this style.

Within the first five hours of the first day, I realized the course was money well spent. He has so many tricks that I had never seen before. The best part is that he is completely transparent and willing to share anything you want to know. You just have to ask him what he's doing and he's more than happy to tell you. There was one specific moment when half the class was blown away when we learned a trick for a problem that had caused some of us trouble before. Money. Well. Spent.

Something he doesn't mention in his description of the course is the use of mona. Mona is the python tool Peter and his team wrote that integrates with Immunity Debugger. I've used it before but now I will probably use it all the time. It's an incredible tool! Mona provides insight into the layout of the stack and registers that you simply cant get with the naked eye. That fucking thing can order you a pizza, put your kid to bed, all the while giving you stack pivot options. It's absolutely brilliant.

Who is this course tailored to? We had guys that had zero experience and some who had decent experience. I think you need to know the basics to get the most out of this course. If you have never opened Immunity, there are going to be diminishing returns after about hour six on the first day. If you're comfortable with basic buffer overflows, know how to read an exploit, and can write scripts, you're going to spend more time learning new stuff than futzing around with your tools. This class moves fast, there is no time to figure out how to fire up mona. You'll be lost if you're at this level.

An important point to note about the course is that you probably will not get to every section in the syllabus. Depending on the expertise in the class, he may skip things, spend more time on others etc. I wasn't sure how this would eventually work out but he knows what he is doing. He's also very flexible so if you ever want to spend more time on X or Y, he'll gladly oblige. 

The learning continues after the course... As a bonus, when you're done with the course you get access to a private IRC and forum that Peter monitors and says he is available for questions. If you have the chance to take this class either at a CON or are able to bring him out to your office, you should certainly do so. Kudos to Corelan, excellent job.

Burp proxy error: Received fatal alert: unexpected_message

I kept receiving this error in Burp when I was doing an web app pen test: Burp proxy error: Received fatal alert: unexpected_message

This problem isn't a Burp issue, rather a Java issue. It is because of the the Java TLS renegotiation issue documented here: http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html

But who cares, how do you fix it? The link above mentions using -Dsun.security.ssl.allowUnsafeRenegotiation=true but that never worked for me, nor did any of the other blog posts on this issue. I ended up removing my current version of Java and installing an older version which didn't include the fix for the TLS vulnerability I noted above.

JRE 6u35 worked for me: http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html#jre-6u35-oth-JPR

Sysax FTP Automation Server Privilege Escalation

Sysax FTP Automation Server <= 5.33 has a privilege escalation vulnerability. By default the "Sysax Scheduler" service runs as SYSTEM. The problem is that you can point the scheduler to any file you want and it will be executed as SYSTEM. Not much to this one, here is an example of exploitation:


https://vimeo.com/51865264

Sysax has been notified and fixed this in version 5.34. Now, you're required to enter credentials and the system executes the file under the context of that user.

GXPN Review

I recently passed the SANS "GIAC Exploit Researcher and Advanced Penetration Tester" (GXPN) exam. This was the first SANS certification I have attempted. It was a completely different cert for me since all of mine are of the Offensive Security or ISC2 flavor. Offsec is completely hands on and the CISSP is well, the CISSP. I did the OnDemand version of GXPN which meant I had ondemand access to the narrated slides + video demonstrations. If the topics in the syllabus are fairly new to you, the OnDemand might be the right option. It was pretty nice to see the actual video demonstrations that the instructor was showing the students in the real class.

This course (SEC 660) covers a ton of topics. A lot of them I have hands on experience with, especially Windows exploit development and network attacks. The areas I was most interested in was Linux Exploitation and Windows ROP gadgets. I was pleasantly surprised by a number of other topics as well.

I've taken the OSCE, which was significantly harder than this exam, but there was no *nix exploitation in that course. In fact, you can't really compare the two courses at all. I've done a detailed review of the OSCE here, and as you see here, the GXPN covers many more topics. OSCE is far more focused Windows exploitation.

However, I do think the two courses compliment each other. Where the OSCE lacks in descriptions and theory the GXPN picks up. In fact, the GXPN prides itself on filling the gaps of where industry papers and publications lacked details. Rather than assuming the reader knows that the FS:00 in the TIB is the SEH frame for example. I do appreciate the details and it certainly helps with a more holistic view of each topic. While mundane and boring at times, it's mostly good stuff.

A surprise benefit was the escaping restricted desktops and crypto sections. I wasn't expecting to enjoy the crypto but they (SANS) do have a valid point discussing it in an "advanced" course. You're not necessarily attacking crypto itself, rather its implementation. A broken implementation could lead to total domination. There were a number of real examples given which really opened my eyes.

I was pretty familiar with all the MITM attacks and think that the only thing they need to add is NBNS attacks to that section. That attack is such a gold mine. I'm not really so sure any of the MITM attacks are "advanced," I mean if you're not pulling those attacks off on internal networks, you're doing your clients a big disservice.

I took the first practice test before studying and scored a 75%, the second practice test the day before my exam was 85%. I finished the final exam with an 85%. I probably could have studied studied a little more :) If the topics seem foreign to you, you should really allow yourself time to get used to them all before diving into the exams. It seems like the practice tests were a pretty good gauge for me. I have heard people signing up and passing SANS exams in a week or weekend, I don't think that is possible with this one. The concepts tested are related to many aspects of the course, so it's not like you can look everything up like you might be have done in the other SANS exams.

All in all, the GXPN is pretty solid. However, if I had to pay for it personally, I might have a different opinion. You will get out of this course what you put into it. If you diligently go through each lab, you'll likely walk out of the exam +90%.

GOOD LUCK!

ActFax Local Privilege Escalation Exploit

ActFax 4.31 Build 0225 has a local privilege escalation exploit in the user/group import function. ActFax installs as LOCALSYSTEM by default, hence the escalation.

My exploit creates the file that you can import into ActFax. After the file is imported you'll be presented with a command prompt, running as SYSTEM. This was all tested on XP SP3.

The exploit is here: http://www.exploit-db.com/exploits/20915/

Here is a demo of the exploit in action:


https://vimeo.com/48419659

The vulnerable functionality is here:

From an exploit perspective, this one was a bit tricky. At first, it seemed very straight forward. Overwritten EIP and ESP pointing to a huge buffer. However, there were only a few JMP ESP or CALL ESPs available in the system executable. The problem was, some of the bytes were being converted from lower case to upper case. This broke all the valid JMPs and CALLs.

There are other alternatives to get to your shellcode, such as PUSH ESP RET etc. But those were not available either. So, I consulted Corelan again and noticed a different strategy I've never tried before, the "Blind Return." https://www.corelan.be/index.php/2009/07/23/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-2/

Basically I had to find a RET that didn't get mangled, and I did. The RET actually sends us back to the very front of the shellcode so space isn't an issue.

Sysax Admin Interface Local Priv Exploit

Sysax has an administrative interface that when enabled, is bound to 127.0.0.1 on port 88. This interface has a buffer overflow vulnerability in the "e2" parameter of the "scriptpathbrowse2.htm" functionality. The exploit I wrote is a local privilege escalation exploit but the vulnerability could be remotely exploitable in the right circumstances. The user would simply have to enable the functionality and bind it to 0.0.0.0

This is the option you need set for the local exploit to work:

 

The same issue exists for the following other pages:

• force_homepath_browse2.htm 
• pathbrowse2.htm
• newaccountbrowse2.htm

Basically any place you can browse for a file or "go up to parent directory" the BoF exists.

Here is a demo of the exploit:
https://vimeo.com/44341842

Exploit:
http://www.exploit-db.com/exploits/19293/

Sysax has fixed this in version 5.64.

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 http://www.ascii-code.com/ 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:
http://vimeo.com/43368964

Exploit is here:
http://www.exploit-db.com/exploits/18981/

Sysax has been notified and they have fixed the issue in version 5.62 which can be downloaded here: http://sysax.com/download.htm

Exploiting Forgot Password Functionality

On a recent pen test, I ran across a web app that implemented poor "forgot password" functionality. After a lot of manual testing and a custom python script, I ended up gaining administrative access to the portal. This is another example of a type of vulnerability that does not show up on vulnerability scans and why hiring pen testers is a better idea than simply relying on the output of those scans.

This particular app accepted a username and password as you can see here:

When I clicked on the forgot password button, I was presented with this:

Interesting. A hint question that is blank. I wondered if I would get a valid question with a valid account? Well, I didn't have a valid account but had a few ideas :) After a few obvious guesses, we see a valid question:

This is pretty interesting for a number of reasons. First, there are different responses for valid accounts and invalid accounts which means we could enumerate accounts. More on that later. The other interesting thing is the question is about the user's "favorite color." How many possible colors are there? Maybe 20? Hard to figure this one out? Nope! If the user was smart when they saw this, they'd simply use an answer that was NOT a color but it became apparent that most did not adopt that strategy. After about 30 seconds, I had guessed the right color and was presented with a password change box?!

Hopefully you can see why this is a fundamentally broken way to handle password resets. Not only can we enumerate the users, we can also brute force the answers to  easy questions, and finally, we can reset the password to anything we want. There is no email link to the users inbox to verify anything at all.

Now that I understood the functionality of the web app, I wrote a python script to automate the process of enumerating valid user accounts. The script reads a list of usernames from a text file, sends the login name to the "forget password" function of the app. Then, it parses the response from the server using a regex function in python. If the parsed response has anything after the "Hint Question:" we know we probably have a valid user account.

I've sanitized the script and tried to generalize it so that others can use it in the future. I built in basic error handling. If the connection dies while you're brute forcing, the script will know the last word that was tried and pick up from there when you fire the script off again.

For this to work, you need to find the difference in responses from the server for a good query and a bad query. When you figure that out, put a string of text into the regex portion of the script that is unique to the good query. The way I did this was  review both the good and bad responses from the server and used the comparison tool built into burp.

 When you run the script the output will look like this:

In my situation, I was able to enumerate 82 valid user accounts. Of those 82 accounts a large chunk of them had easily guessed password hint questions. I was able to run through each of them and ended up getting an account that had full administrative control over the app. Game Over.

After gaining admin control I also found another very old problem, masked passwords on web forms. After de-masking all the passwords, I now had over a hundred usernames and passwords which were used on other sites and services.

My script can be found here. Keep in mind, I suck at programming and there might be better ways to do this but at a minimum, it can be used as a framework.

Sysax Directory Traversal Exploit

Hello Sysax, its me again. I keep wondering when you are going to call me and offer me a free license or a candy bar, or something. The phone hasn't rung yet, I'll keep waiting.

There is a directory traversal vulnerability in Sysax Multi Server v5.55 and below. Due to the fact that the software installs and runs as LOCALSYSTEM by default, you can retrieve any file you want.

The issue occurs here:

http://TARGET/scgi?sid=46de6680d6e99131e29ac1d58a49b286fce6e228&file=c:\SOMEDIRECTORY\../../../../../../../boot.ini

I wrote a tool that exploits this vulnerability. It's a shitload of overkill for a directory traversal because you can just use your browser and get the same results, it was worth the exercise. The tool will grab any file of your choosing, as long as it is not in use. You must have valid credentials to log into the application and you also need have an existing sub folder or a file in your "home directory." Reason being, the directory traversal only occurs after your home directory. There may be others but I couldn't find one anywhere else. However, if you don't have a file or folder in your home directory, the script will attempt to upload a file for you. Keep in mind, if the admin is using My Documents folders for example, a Desktop.ini (hidden file) is likely already in there.

The vendor attempted to fix this in version 5.57 but their fix did not work. I will update this blog when they fix the issue.

****Update 4-25-2012****
The vendor has just notified me that this has been fixed in version 5.60

The vulnerable software is here:
http://www.mediafire.com/download.php?iebrbz2n04vm6sr

The exploit is here:
http://www.exploit-db.com/exploits/18695/

Here is a video demo of the tool:
https://vimeo.com/39704656

CIFS Null Session to Domain Admin

I am beginning to love CIFS Null Sessions (CNS). I have had incredible success on pen tests when this vulnerability is discovered and quite often Domain Admin was right around the corner... We've seen clients ignore it time and time again but I cannot stress how problematic it can be for your network.

This post will become a living document and I'll update is as I encounter CNS and subsequent actions that are useful.

Not all CNS are useful, but when you can enumerate things like user accounts and password policies, your CNS can become very valuable. My favorite tool for CNS enumeration is winfo.exe.

For example, looking at the output of winfo, what does this information tell us about the environment?

Key Observations:

1. Except for the 60 day rotation, they have a terrible password policy. 3 character minimum?! Damn! This also indicates they probably have lots of other problems on their network if their password policy is so weak.
2. The lockout duration is 10 minutes and then a locked out account is automatically reset. This is probably the most important piece of information. Why? Because locked out accounts don't require an human Administrator to unlock them. Their employees are probably trained on an account lockout to just wait it out and try again.
3. The lockout threshold is 5 so we get about 3-4 brute force password tries on each account if we want to be "stealthy" and not lock them out. However, even if we do lock an account out, it likely wont raise any red flags since it will auto-reset in 10 minutes!

There are so many issues with that password policy, it's mind blowing.

In addition to that juicy information, if you're lucky enough to get a list of user accounts from winfo, you can begin to tailor a brute force attack based on your discovered insider information. The way I like to do this is to use the smb_login module against a domain controller, or some other file server with port 445 open.

When you're configuring the module try to pick a single password that you think will have the best chance of working. The module I configured below will try the the following combinations: username as the password, blank password and the word "password." That's a total of three tries for each user in our enumerated list which is less than the 5 that will lock out the account. I picked "password" because their password policy above was so bad, it just seemed like it had to work ;) If you wanted to squeeze one more password in, just create a text file with 2 passwords in it and set the PASS_FILE option and remove your SMBPass option instead.

Running the module in my situation against 2000 user accounts yielded 12 valid sets of credentials. But what the hell can we do with these accounts if they're just basic low level user accounts that may/may not have access to anything?

First place I look is the NETLOGON share on the domain controller. Since you have a valid domain account, you'll automatically have access to the NETLOGON share. In my case, I looked through all their logon scripts that are stored in this location and found a few that sounded "interesting." Opening them up revealed hard coded domain credentials in the scripts. They were even nice enough to make this account a Domain Admin. Game over.

Why do admins do this? As a former admin, I know exactly why. When you try to remove administrative privileges from all your employee computers as a best practice, you'll run into situations where you want to install printer, software or make changes to their systems that require admin access. You can either touch every machine manually, or script it, with credentials that have the rights to make the changes you want. Often these scripts will get left up there and forgotten forever.

I used to do this too but was diligent about disabling this "service account" when we were done using it and also removing the script from the NETLOGON share.

Here are some other ideas if you're not this lucky on what you can do with your newly discovered accounts:

1. See if the accounts appear to be service related. For example, "faxingaccount" probably has to do with their fax server. Figure out the fax server and test these credentials. If it's a local admin account, you're probably in business.
2. Try these accounts against file shares. It's possible they're a part of employee file access groups.
3. Use an LDAP browser with these credentials to browse AD. You can get a feel for how the company is organized, how their organization AD units are structured and I have even seen passwords written in the comments fields of accounts. 

Chaining all these attacks together from one CIFS Null Session can really be devastating.

Happy pwnag3!

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/

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

Sysax Multi Server 5.50 Exploit

Jan 26, 2012:
None of the stuff below matters because my original exploit sucked, but I managed to convert it to a Metasploit module and automate the SID gathering process:  http://www.exploit-db.com/exploits/18420/


Jan 15, 2012:
Here are the notes and assumptions for the Sysax bug I found:

1. HTTP has to be enabled as a connection protocol which is not a default setting. This essentially turns the FTP server into a web based file transfer service.
2. This exploit requires authentication.
3. The authenticated user needs to have "create" permission for folders enabled, which is also not a default setting.
4. This exploit requires a "SID" parameter. This can be found by logging into the web app and clicking on the "create folder" link. The SID is in your address bar. It's 40 bytes long between the = and &. I could not figure out how this was generated by the system so this is a manual process.
5. Sysax Multi Server runs as LOCALSYSTEM by default ;)

I suspect there are other bugs in this web app. During fuzzing, I was able to get this app to crash but this was the only bug that would consistently crash the app.

Bravo to the vendor for quickly addressing this issue 2 days after I reported it and posting a fix, version 5.52.

The vendor already removed the old version from their site. To get a copy of the vulnerable 5.50 version you can get it from here: http://www.mediafire.com/?ctj75imtvl1d353

For the exploit, go here: http://www.exploit-db.com/exploits/18382/