ColdFusion for Pentesters Part 2

On a recent pentest I ran into a ColdFusion box that was a bit problematic to pwn. Chris Gates gave a presentation in 2012 that I reference all the time "ColdFusion for Pentesters": http://www.slideshare.net/chrisgates/coldfusion-for-penetration-testers It is chalked full of excellent information about owning ColdFusion and a must read. The cliff notes version of his presentation is that ColdFusion is a security nightmare and can be your best friend on a pentest. This post should really be called "ColdFusion for Pentesters Part 1.15," but you get my drift.

I see ColdFusion all the time on client engagements. If you're not finding it, you're probably not looking in the right places. We use Nexpose and it doesn't even tell you that ColdFusion 7 or 8 is installed (yet another vuln scan fail). The only place that gives you a clue is down around "Severity 5" on your vuln report, under a vulnerability called "Unprotected access to ColdFusion scripts under /CFIDE/." Usually if you see this vulnerability, you have access to the administrative interface which can be the beginning of the end.

On this particular pentest I found a ColdFusion 7 box. This is a gem to find because there is a directory traversal vulnerability that always works. It always works because the product is end of life, therefor Adobe won't release a patch. Through that vuln I got the password.properties file and was able to crack the password hash. Now I had administrative access to the ColdFusion admin panel, this was business as usual...nothing fancy.

The next step (noted in Gates presentation) is to fire up the "Scheduled Tasks" function and then leverage the "System Probes" function. Essentially, this allows you to pull an exe onto the box and use the system probe to execute the file. Well, I looked for the system probes link but it was not there. I later learned that system probes are only available on enterprise versions of the software:

As you can see I was running "Standard:"

Well, shit. Back to the drawing board.

I decided to try and leverage the "Save output to a file" check box for other types of files:

What about ASP? There are lots of nice ASP shells that don't get popped by AV. So, I hosted an ASP shell on a box that I controlled, checked the box and made sure to "save the output file" in the webroot. Then, I fired off the scheduled task. I could tell from my weblogs on my evil server that the box reached out for the file as planned, but when I tried to browse the file on the victim I got a 500 error. To make sure the file was there, I used the "Debugging & Logging > Code Analyzer" feature. This little thing lets you browse to the contents of the file server which allows you to select and SEE EVERY FILE ON THE SERVER. So, I opened it up and saw that my evil shell was indeed in the web root.

I can't expand these directories because they're sensitive, but take my word for it, you can see everything. At least I now knew that my file was getting there. I kept fighting the box by using very basic ASP pages, just to see if it would render correctly, and they did....but when I tried to use ASP that called system files like cmd.exe or ipconfig.exe etc, I would get a 500 error. So, ASP didn't appear to be a good option.

What about a ColdFusion shell? There are a lot less ColdFusion options but holy hell did I find a beauty: http://code.google.com/p/fuzzdb/source/browse/trunk/web-backdoors/cfm/cfExec.cfm?r=180

Not only does this thing allow you to execute commands, but it also decrypts all the data source passwords for you, on the fly. This is another vulnerability in the server, also noted in Gates presentation. To make a long story short, the data source passwords are browser masked and encrypted with a static key. Decrypting them is trivial and this shell does it all for you so you don't even need Hernan Ochoa's script. But first, we needed to get the shell onto the target web server. I simply repeated the same steps with Scheduled Tasks and boom, the shell is alive. Just browsing to the shell reveals all the data source passwords and my execute and upload buttons:

I only made one modification to this shell. Since it had no file upload functionality, I borrowed other code I found and added it to the file so we could upload our own files :)  The shell you see above is here: http://pastebin.com/3HKGQCWF

At this point it was an easy victory, upload my own meterpreter, execute the new file with the same shell, profit from new meterpreter running as SYSTEM.

ActFax RAW Server Exploit

I was bug hunting the other day and came across an interesting one. The exploit itself will probably never be used by anyone, ever, but it was fun to write and I learned a few things along the way. The bug has been fixed in a beta version which can be found here: http://www.actfax.com/download/beta/actfax_setup_en.exe

The bug is in how ActFax handles "data fields" when remotely sending faxes to be processed by the server.

Finding the Bug

I started looking at ActFax, looking for places I could input data or send data to the server. I came across all the other functions the server had, and wondered why a "fax" server would have these features:

A LPD server? FTP server? RAW server? After reading the help menu, I learned that these were ways that other computers could send unprocessed faxes to the server.

ActFax allows you to compose documents that you want to fax and then transmit them to the server electronically so it can convert them to faxes and send them out. The way it knows who/where/why to send the fax is by the use of data fields, mentioned earlier. Consulting the help menu we get an idea of how this works:

Basically, we start a data field by using "@F" and then the code we want, then our data and the string is terminated again with another "@". That trailing @ will come in handy later....

Here is the help topic that showed me every possible data field the server would accept. There are about 50 of them:

Fuzz Time

With over 50 different fields, a basic fuzzer was in order. However, first I had to decide what protocol to use for my fuzzer. ActFax allows you to use LPD, RAW and FTP to transfer faxes. For the sake of simplicity and after a bit of research, lets go with RAW :) I assigned a arbitrary port to the RAW server to enable it, and I was off. Here is the basic fuzzer http://pastebin.com/sM47zRhU

That fuzzer template was stolen from here: http://www.redteamsecure.com/labs/post/18/build-your-own-ftp-fuzzer 

Crash Time

Running the fuzzer yielded interesting results. It looked like there was a crash around 600 bytes or so on the @F506 data field:

Looking at Immunity at the time of the crash, we see:

However, after further inspection, we didn't control SEH or EIP, so exploitation was likely not possible with this buffer setup. As these things typically go, we need to start messing with the buffer a little bit. I decided to double the buffer size and send a single command to the @F506 data field. This one looked a little more promising:

This looks favorable, EIP overwritten and two registers pointing to our buffer.

Next step is to figure out which bytes overwrite EIP and our favorite tool to do this is metasploit's pattern_create tool. Since I usually start with a basic python script, I prefer to just generate this with !mona and stuff it into a variable into my python script:

Adding the pattern to our basic python script results in the following http://pastebin.com/9jssLzwQ

When we run our new script we see EIP overwritten with our cyclical pattern:

As you can see from above, now we have our offset and are well on our way to pwnag3...... or so we think :)

Tight Spaces

Our first problem.... when we dump the contents of ESP, we see our cyclic pattern but then there are a bunch of zeros and then what looks like the beginning of our cyclic pattern:

Based on this we have an interesting situation. ESP points to our buffer but then it's abruptly cutoff. So, it appears we only have a little bit of space to work with so lets figure out how much space this is. If you right click on ESP and "Follow in stack" and then double click at the first address on the stack (blue arrow) we can look at how much space we have. Keep in mind the offset numbers you see are in HEX.

Scrolling down the zeros stop at 22C in HEX, which is 556 in decimal. This means at the time of the crash, from where ESP points to the end of our buffer is 556 bytes.

To confirm this, we'll modify our script to test our theory http://pastebin.com/J037QmVH

This looks good - EIP is overwritten by our "B"s, our "front" variable (C's) is where EAX is pointing and our "A"s are where ESP is pointing. Just as we planned. You might wonder why I'm not talking about JMP EAX here, after all there is a lot more space there to work with. Shouldn't we just jump there?

Sumamama Bitch

As I was recreating this for the blog post, I discovered something interesting. My original research did not show the EAX register pointing to anything useful at all. This is a good lesson, look what happens to our exploit after just a few bytes are changed. As you can see below, here are the 4 byte's I was "missing":

By changing this from 556 to 560 bytes and filling up the remaining space, the register layout changed completely. Now EAX is zero'd out and ESP and ESI point to the beginning of our buffer and nothing is pointing the beginning of our buffer. This is what I originally thought was the only buffer/register layout! Oh well, it was worth the work in the end! In hindsight, I should have messed with the buffer sizes to make sure I didn't over look THIS:

3FC = 1020 in decimal.... that's plenty of space :)


Back to Business

Based on all this information, we know that without doing anything fancy, we only have about 560 (4 more bytes than originally thought) bytes for our shellcode. Normally this is plenty of space for staged shellcode, but the thing that dictates the amount of space that shellcode uses is bad characters. That is our next step, discovering bad chars. However, for the sake of brevity I'll spare you those details. I like to use the !mona bytearray and !mona compare functions to help me with this. You can reference corelan's tutorial here.

Basically all the characters from 00 - 19 were bad....as well as HEX 40 which is "@" and that will effectively terminate the data field in ActFax, which we don't want to do. A character set that satisfies this would be the alpha_mixed encoder but that will likely put us over our 560 controlled bytes.

I decided to keep going down this road for one reason. Even though we only have 560 bytes, we still do have the beginning of our buffer as well.....right after our 560 user controlled bytes. A general buffer structure is looking like this:

buff = 1024bytes + EIP + 560bytes

The 1024 bytes at the beginning would be plenty for the remainder of our shell. So we're shooting for something like this as our final buffer structure:

buff = shellcodechunk2 + filler + EIP + shellcodechunk1
We know that shellcodechunk1 has to be 560 bytes or less, or it will overflow into shellcodechunk2.

The key is to just make sure we're exact on the length of shellcodechunk1 so it can roll right into shellcodechunk2, without screwing up our shell. Lets keep our shells happy. One of the issues with this exploit is that due to so many bad chars, I could only find about 3 valid JMP ESPs and those were in ole32.dll. It's not ideal to use system files that could change with a service pack or patch, but that was my only option. Also, a ROP chain was also out of the question because of the limited characters, so bypassing DEP was also not possible. Lame, but that's the nature of this bug.

A final python script, with metasploit shellcode is here http://pastebin.com/TMH4GjkG

However, like corelanc0d3r said in his training, we need metasploit modules, not shitty python scripts. So the conversion process begins....seemed like it would be very straight forward because my original script worked perfectly.

I'll go through the issues I faced converting this exploit to a MSF module in the next blog post. The end result is this http://www.exploit-db.com/exploits/24467/

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.