Wednesday, May 14, 2014

What Did Microsoft Just Break with KB2871997 and KB2928120

Microsoft recently released two patches that will likely impact your future pentests. The first was KB2871997.  Some have dubbed this the "Pass the Hash Fix" but it is hardly that. The second patch that will likely impact your pentests is KB2928120. This is known as the Groups.xml GPO preferences bug that Chris Gates published here.  In this blog post, I'll walk through my testing and validation of these patches from my lab. Hopefully I am able to boil all the confusion down to "which of my old tricks did Microsoft just break?"

First lets dissect the "pass the hash killer", KB2871997. tl;dr => local accounts can no longer be used to access remote systems, either via simple network logon or interactive login. This includes using tools like PSEXEC or even browsing to C$ remotely. On the surface it would seem that this patch would effectively eliminate the attack vector where you compromise a system, dump the hashes and then find that the local admin hash is the same on all systems which usually results in total domination.

HOWEVER, in my testing, the above holds true for any local account on the system EXCEPT the default Administrator (SID 500) account. Keep in mind, a renamed administrator account is still a SID 500. As long as the account is of the SID 500 flavor, it appears to still work as it has in the past.

To recap, for the sync'd local admin password attack vector to be squashed by patch KB2871997, the network admin needs to disable the default local admin account, create a new regular local user and then add that user to the administrators group. If they do all that and you dump the local hash, it cannot be replayed across the network, either using the hash or the actual credentials. Windows 7 disables the Administrator account by default, but in many corporate environments I've found this account to be re-enabled and often just renamed.... which means SID 500 and the patch should not stop you.

I tested the above using WMI, psexec_command from MSF and powershell. Each one had the exact same results: access denied for all local accounts except SID 500. Another key point is that you can STILL pass the hash. Domain hashes and SID 500 hashes can all be passed.

Here you can see a PSEXEC to a member of my domain, using an account named "renamedAdmin" which is the original SID 500. PSEXEC works fine:

Same results with PTH. "renamedAdmin" works fine, "rdptest" does not:

As you can see, rdptest is a part of my local admin group but is not the SID 500:

KB2871997 also does sort of address the mimikatz issue of pulling clear text credentials out of memory. This is most commonly exploited by running mimikatz on systems where people have RDP'd to the system. Prior to the patch, even if a user logged off their RDP session properly, rather than just disconnecting, the credentials could be harvested at any time using mimikatz. KB2871997 now will cause the operating system to clear those credentials from memory only when the user properly uses the RDP log off function. If the user simply disconnects, i.e. "x'ing out" of the screen, mimikatz will still be able to pull clear text credentials. In my testing, Windows wouldn't immediately clear memory, but within 30 seconds or so the credentials are gone. Bottom line, most users just X out of their RDP session so your mimikatz tricks should still work.

Moving on to the GPO Preferences issue. tl;dr => the patch only disables the ability to store passwords for NEWLY added local accounts. If the network admin has ever used this functionality in the past to store a password, they would have had to MANUALLY remove the Groups.xml file from the SYSVOL share or delete and re-add their user post patch. Otherwise, simply browse to SYSVOL like normal and grab the Groups.xml file and decrypt away using Chris Gates script.

After adding the patch, when we go to our previously created admin account and double click it, we're presented with a new warning message:

 Next, you can see that the password appears to still be stored but we're unable to change it:

 When creating a new account, you can see we're unable to set a password, since those fields are greyed out:

Finally, the following screenshots show you that the Groups.xml file is still in SYSVOL and can still be decrypted:

This jives with what MS says here: "Note that Microsoft is not automatically disabling these Group Policies because we do not want to disrupt existing environments which rely on this feature."

The takeaway from both of these patches is that neither one completely fixed anything. Keep your eyes open for SID 500 and also keep checking for Groups.xml, it might still be there waiting for you :) Please let me know if your testing contradicts anything I have said... I want to make sure I have the exact details! 

Testing environment is Windows 7 client using a 2008 R2 DC.

Wednesday, December 18, 2013

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.

Tuesday, November 5, 2013

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

Tuesday, April 16, 2013

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": 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 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:

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:

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.

Wednesday, February 6, 2013

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:

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

That fuzzer template was stolen from here: 

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

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

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

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

Thursday, December 13, 2012

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:

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.

Wednesday, December 5, 2012

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:

But who cares, how do you fix it? The link above mentions using 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: