Penetration Testing Interviews - Minimum Requirements

We have been interviewing a lot of people lately for penetration testing jobs. From the entry level through senior level. Unfortunately, most of the people we interview should not be interviewing for these positions at all. These are people that have made it through our initial company filters and yet we still have a lot of bad interviews. It is not the fault of our recruiters, rather the fault of the candidates that do not fully realize the requirements of a penetration tester.

Usually when one of these candidates sits down in a room, myself and my colleague can tell within a matter of minutes if they are full of shit, or if they have something to offer. After they pass the full of shit mile marker, the remainder of the interview is to really gauge their depth of knowledge. This post is a plea to potential candidates to satisfy a minimum set of requirements, which differ for each level of pen tester.

Generally, there are several things we (as well as other companies) look for in a solid penetration testing candidate. They must be technically sound, client presentable, have a strong passion for information security and fit in with the team.

Before I dive into each level and their respective requirements, one basic requirement that is consistent throughout all levels is this: Do not bullshit us. If you do not know an answer, just say you do not know an answer. If you even smell a little bit like bull shit, you will make getting the position close to impossible so just avoid it all together. While consulting is a bit of smoke and mirrors itself, you cannot bullshit a bunch of bullshitters. If you are planning on this tactic, your BS better be good enough to fool us. After all, if you sat in front of a client and BS'd your way through an answer and the client realized it, you would be in a tough situation. A client will never mind if you say "I am not sure, I will check with my team and get back to you on that." The only exception to this rule is if the interviewer says, "that's OK if you don't know the answer, how do you think that would work? Or, how would you approach it?" That is a question designed to see how you think, then it is perfectly fine to BS that answer.

Entry Level Penetration Tester, Minimum Requirements

We look for passion and technical aptitude at this level. Passion isn't just that "you love this stuff," prove to us that you love it. Do you have a blog? Awesome, show us. Do you have any personal projects? Awesome, show us. Do you play with vulnerable distributions? Perfect, tell us about them and what you did with them. Once we hired a guy because he showed us a picture of himself standing next to a bunch of Sun servers with a big grin on his face when he was 10. That isn't the only reason he got the job, but it helped his story. I often say that this job is more like a "jobby" - a job and a hobby. You get the point hopefully.

Passion is huge, but not the only requirement of an entry level pen tester. Here are the basic technical requirements... Know nmap enough to run it a few different ways. Know Metasploit enough to exploit a system, the differences in payloads and some of the auxiliary modules. Know the basics of Windows, Linux and networking. If you're not sure what to know here, then think like a hacker... For example, where are the passwords stored for each of these? A lot of pen testing can be taught but you are expected to come in with a basic set of skills. If you don't know what the difference between a /23 and a /24 network are, then you're not ready.

Mid Level Penetration Tester, Minimum Requirements

All of the above, plus you better understand a little more under the hood. A mid level person might really be an advanced entry level person or a someone that might be a senior, but we just couldn't tell for sure in the interview. They might need to "prove" they are a senior. Either way, there is a bit of a range in the mid level.

From a process perspective we're interested in how you would navigate a pen test. Do you have anything that resembles a methodology? Do you know how to use the information you gain from a system? You better know what pass the hash is, SQL injection, cross site scripting and what type shell you would use to get out of a network. Also, if you know this, you should know your favorite tool to do so and some of the possible switches with each. If you have taken OSCP, you should know all this already. In addition to these basics, a mid level pen tester is going to be on larger projects, likely client facing. Iron your shirt, don't wear birkenstocks and please pretend like you would be in front of a client during your interview so dress appropriately. A mid level pen tester should not need much training and should be able to hit the ground running pretty quickly.

Senior Level Penetration Tester, Minimum Requirements

All of the above, plus you better be an expert in something. Even better, be an expert in most things. you should be comfortable with the technical details of all kinds of systems. Most importantly, knowing the details about EXPLOITING systems. You should know about password cracking, exploitation of all kinds, pivoting, pilfering, lateral movement, privilege escalation and everything else pen test related. If you are not 100% familiar you should know enough theory to make a pretty educated guess. This guess I'm referring to is not BS as noted above, there is a big difference. Also, seniors are going to be put on the largest projects so you better be a good pen tester. You better know how to get some pwnag3 without a single vulnerability on a vulnerability scan. There is also a leadership quality here that is a major bonus. The entry and mid level guys will look up to you for advice and guidance, try to demonstrate that in your interview if possible.

My last plea for all positions is to get your OSCP first if possible. Every candidate that has their OSCP coming into the interview has a little bit of street cred and we can assume a certain level of knowledge is already there. Again, if you're lying it will come out very quickly.

I am on a quest to save everyone's valuable time, both yours and mine. Please understand that becoming a pen tester is a significant commitment and if you're at all casual or unsure about becoming one, you're not the right person for the job.

JBoss JMX Console Hash Grabbin

I came across a little trick that may come in handy on a pen test if you find a Windows server vulnerable to the "exposed jmx-console vulnerability."  There are Metasploit modules for this, but I try to avoid them because the payloads get popped by AV on Windows systems. Normally I can just use one of the many available WAR shells instead to get a shell on the box. However, in this situation I couldn't get any of my WARs up to the target system because the deployer didn't appear to be configured or wasn't working correctly.

Instead, I added a UNC path to a fake share on my system, and the system graciously handed me the hash from the account that JBoss was configured to run as.

First, make sure you have access to the jmx-console:

Next find "jboss.deployment:"

 

 

On this page, find the "void addURL()" and add the UNC path to your system running the SMB server. My preference for SMB capture is just to use Responder.py but you could also use the Metasploit SMB Capture module as well. Just make sure to have that running before you hit the "Invoke" button.

 

 

When you click "Invoke" you should see this message:

 

 

 If it works, you should immediately see your hash come across in your fake SMB server:

  

There you go! A fresh hash for your cracking pleasure. 

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.

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/