Quantcast

How not to suck at pen testing 2: Thinking beyond the Reds

Some information security engagements described by John Strand demonstrate that the Criticals in pen test reports are not the only things to look at.

A number of years ago Ethan Robish, who was with Black Hills Information Security, was doing a pen test for a customer of ours that had multiple pen tests from “pen test puppy mills”, that was being pen-tested about every single quarter. And the pen test puppy mills did the same thing: they ran the scan, they printed out the report, they handed the report in, and they said “You know what? You guys are great, there’s no Criticals, there’s no Reds. Completely ignore all the mediums, lows and informationals, because who cares about those?”

Not quite what Ethan found

Not quite what Ethan found

So Ethan started going through the findings and he saw something that caught his attention. It was RoboCop riding a unicorn (see right-hand image). No, that’s not what he found…
Directory listing

Directory listing

He saw a website with the name ‘hello.php’ (see left-hand image). Now, its name is not an evil backdoor name at all, it was just innocuously called ‘hello.php’. And he thought “What the heck, I want to know what ‘hello.php’ is.” So he surfed to it and he saw this. I’m going to give you guys a couple of tips. Number one: if you’re on a pen test and you go to a website, and there’s a skull and crossbones in the upper left-hand corner – that’s generally a bad site. Tip number two: if you’re doing a pen test in 2013-2014, and the skull and crossbones right next to it has ‘2009’ – that’s also a bad site.

What this was is a PHP backdoor. How many pen testers here love WordPress? I just see the guys sitting and smoking pot, going “You know what we need? We need a way that people can upload crap to our servers without authenticating. Dude, make that happen!” And for years pen testers rejoiced at this capability, where somebody had uploaded a backdoor to the server and it had been compromised for years. For years. And it was hard, because when we went to the customer we said “Hey, we found this critical backdoor on one of your servers,” – they said “Well, was it Red or Purple in the report?” That’s what we’ve been trained to look for, right? It’s like Pavlov’s dog – ting, it’s time for steak! We need to move past that, because this is wrong, and this is the type of stuff that people are paying you to do, whether or not you’re an external consultant or you’re doing it internally for an organization.

Directory indexing

Directory indexing

Another one (see right-hand image). A couple of nights ago, or actually a couple of months ago – time flies – we were doing a network pen test. This is a company that we had tested quite regularly, and we were really just slugging through these informational and low warnings, and there’s just thousands of them. One of my favorites, directory indexing, is a goldmine. Do yourself a big favor – if you can go into your Nexpose, your Nessus configuration, any finding that has ‘share indexable directory’, anything like that – crank that puppy up the high so that every time it shows up, it is bright-red critical and you look at it.

This was a customer that, I guess, had a lot of other customers, and they sent out a lot of emails on behalf of those customers. You think MailChimp, but it’s not them. Anytime there was an error, the application would actually drop a log file into the temp directory. And the log file would name out all of the customer data: the user IDs, their passwords, all of the good stuff that you would ultimately look for in a pen test. And their application was generating error logs. If you are in the pen testing field, error logs are your best friend, especially for custom applications, because they bleed all kinds of horrible things.

If you are in the pen testing field, error logs are your best friend.

As you can see, we had hundreds of these CSV files that would get to a certain size and then they would roll over within a certain time period, and it was just riddles with personally identifiable information, user IDs and passwords for all of their customers. Not unlike some of those major breaches that have happened over the past couple of months, this would have been public, this would have been one of those massive breaches that would have shown up on the front page of USA Today. This was not Red, this was not Purple, there was no leet hacking, there was no 0day involved in this – it was just an issue of treating your scan results, treating your data as your eyes to try to learn as much as you possibly can about a network.

SMTP server found

SMTP server found

Another thing that we like to play with – sometimes you don’t really have anything. It says “Oh, there’s SMTP server found.” I love notifications and warnings like “We found SMTP server”; or another one of my favorites is “We found a Telnet server”. Now, what would you ultimately do if you find a Telnet server open on the outside of the Internet? You’re going to go to it, right? Take the banner, then do a lookup – what type of device it is – try the default user IDs and passwords, and nine times out of ten you are going to get in with those.

But this (see right-hand image above) was neat. This is one that was done by Brian. He found out that you could connect into their SMTP server. And if you try to send an email to an email outside of that SMTP server, it would pop up an error and say “Sorry, that domain isn’t in my list of allowed recipient hosts”. However, he discovered that if you send an email, while logging directly into SMTP server, to an internal email address from an internal email address, it would say, oh, that’s fine, you can perfectly do that. No problems whatsoever, completely bypassing all spam filters, completely bypassing any other filters.

Now, why would this be configured this way? This is an easy configuration change to make it not do this. But what are people scanning for? What’s the biggest worry you would have with SMTP server exposed on the open Internet? Relay, right? This wasn’t a relay server, because I couldn’t send emails outside of that organization. But you could spam the inside of the organization all day long, with absolutely no problems whatsoever.

A couple of years ago, we had something very similar, where we could access their internal SMTP server from a compromised workstation, and I could shoot email to anybody from the organization from anywhere I wanted it to be. So I shot an email that was titled “TEST: Sale!! We are going bankrupt!!!!!! Everything must go!!!” from Abraham Lincoln, thepresident@whitehouse.gov. In it, it said “Theater sucks.” And I remember the customer getting really-really frustrated with me and saying “That’s just in poor taste!” And I said to the customer “Too soon..?”

It’s not only about scanning

It’s not only about scanning

This also requires us, as network penetration testers, to go beyond the scanning results (see right-hand image). Somebody earlier today was demonstrating how you could harvest anybody’s Social Security Number. That’s awesome! Do you think the bad guys will use that against you? Absolutely! That’s outside of the bounds of how normal pen testing is done. They run a vulnerability assessment scanner, they keep just to that vulnerability assessment scanner results. We have to go beyond the scanning results. Everything is not going to come in a standard Excel spreadsheet that you need to deal with.
 

Read previous: How not to suck at pen testing – John Strand

Read next: How not to suck at pen testing 3: Mitigating structural weaknesses

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: