Quantcast

How not to suck at pen testing 6: Penetration testers code of ethics

Black Hills Information Security’s John Strand lists the essential rules, which are intended to make pen testing more efficient as the industry is moving on.

Pen testers should lead the way

Pen testers should lead the way

John Strand: The whole gist of this entire presentation is we need to keep moving forward as network pen testers. We need to continue to find new things to do, not just proving that we can break into organizations, but actually trying to find the clipping levels of where the organizations can detect us. We need to move forward and actually start going through the vulnerability assessment findings and look at the Informationals and the Warnings and the Lows to dig through to find those risks that are missed by just a tool that’s looking for something that’s a High or a Critical.

And the thing that’s hardest for me to say – because it comes across as a bit harsh to other people – right now I believe firmly that the people that are in this room and the pen testing, kind of the offensive security community, are the pointy end of the stick. We are spearheading a lot of what happens in computer security. If you don’t believe me, sit down and talk to anybody that does forensics, or ‘forensicshateor’, as they like to be called from time to time, and ask them “Hey, what do you know about MiniCats?” Many times they’ll just look at you blankly and have no idea. “What do you know about impersonating tokens?” You’ll hear a lot of people in forensics – not all, but you’ll hear a lot of them say “Is that even possible?”

As I said, we are many times the pointy end of the stick. And if we start slacking off, and I see indications of us slacking off, the rest of the industry is going to follow. A lot of the cutting edge research is being done by the people at these Cons, it’s being done by the people at these presentations. And we need to continue to push that as much as we possibly can. So, this is bad for all of us if we allow the things that are occurring to continue to occur. And if you are at a pen testing firm that is a “pen test puppy mill”, as I said, I feel sorry for you. I don’t mean that in kind of a derogatory way, I genuinely feel bad because I come across a lot of people that are just running Nessus results and then turning that into a report and just turning those things as quickly as they possibly can. It’s time to stand up and try to push back a little bit.

I know that that’s hard, I know that that’s difficult, and you are going to fail. And as I say in almost all my presentations, you are going to fail doing the right thing. But I would rather fail doing the right thing than live my entire life doing the compliant thing. That’s not something I want to go to my grave and say “Ah, my environment is PCI compliant.” That’s not what we are here for. That’s not the way we want to go out.

Stick to these rules

Stick to these rules

To that end, I created something called “Penetration Testers Code of Ethics”. If you can try to live by this Code of Ethics in what you do in your job and anytime you try to break into anything, you are going to be okay. First, I will never copy and paste automated results, ever. I got into an argument with Ron Gula about that, and he said “You know, I don’t think anybody should ever copy and paste anything from Nessus because that’s our copyrighted work.” I was like “He’s kind of a jerk.” I got to thinking about it, and as time passed I realized he was right, not necessarily because it’s copyright or legal issues, but because it’s lazy. We shouldn’t do that, that’s not what people are paying us to do.

Also, I will never completely trust my scan results. That’s why you go to the Lows and Informationals. That’s where you are going to find beautiful things. That’s where you are going to find vulnerabilities that the tools missed. That’s where you are going to find vulnerabilities that every pen testing firm that came before you missed. And that is awesome. That is a great feeling when someone says “We have hired ten firms before you, and you are the only one to catch this.” That’s probably one of the best feelings in the world in this industry.

I will strive to get caught (after being awesome). Be stealthy, be great at what you do, take over domains, do what you do, but then strive to get caught. And there’s a couple of reasons for this. First reason is we can give them a clipping level. And the second reason is, after you’ve destroyed their network, it gives them a little tip of the hat and you say “Hey, your security team is doing really-really good, they caught us doing these things, but here are some things they can do to make it better.” If you approach pen test as adversarial “they suck, we rock”, you are not going to be very good at this, you’re really not, because your best customers in the future are going to be your current customers. And the more they like you the more you are going to be invited back.

I will go beyond the scan results; I will continue to look at things outside of the organization. We talked about using Recon-ng and finding vulnerabilities that standard scanners don’t pick up. I will try to be a hacker in the original sense of the word. For example, I thought it was pretty cool – I got a Pebble. And I like Pebble, I think it’s a great watch. It’s now completely obsolete and it’s out of date. And then these guys up front – can you guys hold up your arms – show up with those things and I’m like “What the hell are those?” And they’re like “They’re not watches.” I don’t know what that means, but it’s more badass than what I have here.

You should fall in love with every organization you try to break into.

But that’s cool, right? You go deeper. It isn’t just about getting the T-shirts, it isn’t just about getting the cool packs that we have, it isn’t about getting the cool patches and the stickers and looking the look. Remember being a hacker is a way of life. You take things apart, you’re constantly learning, and most of you are here in this room because you have that already. And we need to continue to have that curiosity about every pen test we do. As I said, you should fall in love with every organization you try to break into, get to know them a little bit. It shouldn’t just be a scan result. Go to their websites. I know that that’s a novel idea for some people, but go to their websites, see what’s there, see what their business is, it’s just kind of a good idea.

I will always stay in scope. This one is actually much harder than it looks. This could be in a presentation all in its own, but I’ll give you one example. We were pen testing a casino, and they gave us their Class C. And we started scanning the Class C, started attacking the Class C. We found a server with the default user ID and password, and we got in, and it was a casino that was completely different than the casino that we were pen testing. And we said “Hey, do you guys own that casino?” And they are like “No…” We said “Well, these are the IP ranges that you gave us,” and they said “Oh yeah, our servers are in that range, we don’t know what they are, we were hoping you could tell us.” Don’t let that happen to you, boys and girls.

And then finally, my reports will rock. I think that’s something that everybody on the team hates me for. But I insist that we have a narrative for every single pen test we did as far as what we did, why we did it, was it successful or was it a failure. A lot of us are insecure about the things that we do that didn’t work. Your customers are paying you for that. It isn’t just about providing a report that says “These are all the successful things that we found, and these are all the vulnerabilities, and look how awesome I am.” If you struggled on something, your customer needs to know that you struggled on something. That’s good. That shows them that there are areas in their network that are fairly strong, and you eventually overcome them hopefully, and then you can explain that to them, but they have to see that struggle. It’s just so important to make sure that it works appropriately.

If you struggled on something, your customer needs to know that you struggled on something.

And now I want to show you kind of a quick preview of Joff’s presentation coming up. We’ve got actual scripts for dumping out, finding out user agent strings, firewall logs, frequency analysis, pivoting activity, how PsExec and all these tools work. We talk about looking at various logs and different PowerShell scripts for all of the different components for looking at workstation variance, going through and pulling out LDAP “computer” objects, going through and pulling out Run and RunOnce execute keys, installed software, looking at the certificate stores – just a lot of cool stuff, so please check that out. And if you want a copy of these slides and you would like to get on the list for the webcast that we have coming up, swing by the Security Weekly booth, bring me your business card or write your email address down, and we will sell it to the vendors. On behalf of all of them, we say thank you. No, we never would do that, ever. That’s not in our DNA.

So, any questions in our last few moments before we get out of here?

Question: What if you don’t block all DLLs, or what if you don’t whitelist all DLLs? And what if you don’t restrict the Run Keys, like RunOnce and RunOnce execute?

John Strand: Those are two different issues. One is persistence, and actually they are both persistence, because a lot of the bad guys, whenever they create backdoors, actually inject themselves into existing Dynamic Link Libraries, and then they persist through that mechanism in many situations. But the issue is what is being written to that directory where DLLs are being executed. A lot of application whitelisting implementations just, basically, start in baby steps, where they list out what directories things are allowed to execute from, and then they slowly start going through and trying to whitelist all the dynamic link libraries from that point on. So, you’ve got to start at that level and slowly work your way up. The idea of trying to whitelist all of them is great, but it’s going to take time to implement, and there are baby steps that you can take for that.

You just run one DLL, but are you whitelisting the JAR files that are being executed as well? What most organizations do is they do “*.jar” – that’s bad, don’t do that. And remember there’s a lot more autostart entry points in Windows than just those, so you have to make sure those are set up as well.

Alright, that’s it. Thank you very much, everybody! I greatly appreciate it! And thanks to Joff for coming up and doing a preview for us.
 

Read previous: How not to suck at pen testing 5: Hunt teaming

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: