The author of the presentation moves on to express his viewpoint on the correct way of handling structural vulnerabilities found during a security assessment.Another kind of offset one was antivirus. I know that this isn’t leet at all, but a couple of weeks ago we did a webcast called “Sacred Cash Cow Tipping” on bypassing AV engines, and we bypassed all of the AV engines that are up here (see right-hand image). It was an awesome, pure technical challenge, and it wasn’t all that difficult. In fact, I shot an email to most of the guys the night before and said “Hey, did you bypass Symantec?” And most of them were like “Oh, crap, I got to sober up for a little while to bypass the AV. I’ve been drinking wine with my wife for the past two hours.” But it shouldn’t be that big of a deal, and we were able to bypass all of them relatively easily. There wasn’t much difficulty in bypassing them.
Why does this matter and how does it tie into this presentation? I say this in a lot of presentations: computer security is like architecture and structural engineering. And I want to explain exactly what that means. My wife is a structural engineer, and I like to read her books. And everything in structural engineering I’ve noticed is all about failure, and she gets really uncomfortable when I bring that up. Everything in her books is about failure. What is the failure point for a beam spanning this side of the room to the other side of the room? What is the failure point for a column in the corner of the building? What is the failure point, believe it or not, for doors: if there is some type of failure, how much weight can doors hold before they collapse?
That’s structural engineering. And think about what that’s based upon. That’s based upon thousands of years of jackasses breaking things. We are those jackasses. That is our calling. We are the people that are finding the flaws in components, the different components that make up our architectures today. We are the ones that are going through and finding those failure points. And the reason why this is important is because we need to demonstrate to management that yes, Symantec can be bypassed; yes, McAfee can be bypassed; in fact, all of them can be bypassed. This is a structural weakness for AV. It’s not about finding the right antivirus solution, it’s about mitigating that structural weakness.
There’s not a single component in this building that is completely impervious to any type of load that you would put on it. Everything fails at certain points. When we are pen testing, we are finding those failure points in those components. And then we need to share that with our customers, we need to share that with the other people within our organization so that they better understand the limitations of the materials they are working with in their IT infrastructure. That’s why we do this. It’s more in line to show people what is possible and then try to move them to a better place to start thinking about how they are going to mitigate these overall vulnerabilities.We have the slides and we have the presentations (see right-hand image). We couldn’t do all the AV engines in one presentation, so everybody on the team created a slide deck and videos demonstrating that. The reason why we created separate slide decks and separate videos demonstrating bypass live was because I really don’t want to get sued. It’s not something that’s really high on my list of things to accomplish. I call it a “Mitnick complex”. I love his comment today: “I don’t want to go back to prison.” I don’t want to get sued, it’s not something that I want to do. But we went through and we created all these videos so that, if somebody did come back and they’d say “You didn’t bypass our AV,” we can actually prove it. What else can we do? Well, stepping beyond the organization, once again, going back to Kevin Mitnick and Dave Kennedy, Dave talked about Jigsaw. And what was Jigsaw used for? Harvesting contacts, right? And Recon-ng is a great tool written by Tim Tomes that has a number of modules for harvesting contacts. One of the things that we like to do is harvest the contacts from an organization and then use services like ‘PwnedList’, ‘Have I been pwned?’, ‘BreachAlarm’, and then, basically, check to see if any of those email addresses associated with the target organization have been compromised on third-party sites where the attackers post all the user IDs and passwords that they have harvested (see left-hand image above). So the question is: how bad can it be? It can actually be very-very bad (see right-hand image). These are some that I pulled a month ago: rand.org, nsa.gov; disney.com has 10308; Northrop Grumman has 6607 – these are user IDs and passwords that are floating around on the open Internet. I was giving this presentation, and I used to do live demos. You should never do live demos. It doesn’t matter how smart you are, the demo gods are going to kill you. I was doing a live demo and I actually showed some information of a company, and somebody came up and they said “You know, that’s kind of a gray area that technically may be illegal with you showing user IDs and passwords of organizations.” So, I pick on Circuit City now. It’s like “This guy really hates Circuit City, he hacks them all the time…” But you can see what we get (see left-hand image). We can see the actual email addresses associated with the Circuit City employees, who are now unfortunately all terminated. We can also see their passwords, because many websites store those user IDs and passwords. Is your Nessus or Nexpose scan going to actually show you this vulnerability? Never. This requires it to go outside of the bounds, to start thinking beyond what it is that we’re getting from just our scanning results and trying to go deeper. I also want to spend a few seconds and talk a little bit about getting caught (see right-hand image). It was discussed earlier why getting caught is important, and I want to kind of help establish a couple of frameworks and some examples. This is something that we’ve been doing at BHIS for a long time, and we strive to get caught, but a lot of times we treat it more scientific. We have an actual Excel spreadsheet, we show the different types of malware, the different types of activities that we did. And the idea is to find that clipping level – where can they actually detect you – and then give them a gap analysis on what they can do to get to the next level so that they can, basically, start detecting the more advanced attacks. I’m really sick and tired of pen tests where pen testers are, basically, saying “Hey, we hacked you, we’ve got domain admin and we’re done.” That’s not a pen test. That’s just you trying to prove that you’re awesome, and it usually comes across as a jerk. We don’t want to do that. Instead, what we want to do is something like this (see left-hand image), and this is actually probably one of the better organizations that we tested. This is just a small section of the spreadsheet. You generate a whole bunch of different types of malware – custom malware, ascii shell code injection, encoded malware, raw malware – a number of different ways of trying to get it to the target organization, and you simply record. Did they detect it? Yes or no. Fail or pass. So, then whenever you go to the organization you can say “These are the holes in your overall security architecture, and these are the things you can do to try to mitigate these overall holes.” And that’s great! A kind of side effect and bonus of this is, if you do screw up and you get caught you can be like “That’s awesome, we’re going to put that in the Excel spreadsheet, you guys did good.” It’s like, oops, I really shouldn’t have sent that unencoded Meterpreter into the organization.
Read previous: How not to suck at pen testing 2: Thinking beyond the Reds