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 chock 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.