#14: The Prime Directive, malware, and having a ball

The Prime Directive in pentesting... "Don't do anything outside the scope document". It's like the Fight Club rule. You don't go outside the scope of the pentest. You don't go playing around in environments you shouldn't, even if it's there.

But what happens when the scope document was made by someone other than people with an intimate knowledge of the assets involved, and can be called ambiguous at best? Is this like Star Trek, where breaking the Prime Directive is bad, but you do your best to notify as best you can, and stop when or if someone raises a flag?

When your organization engages a company to do a pentest, defining what systems are being tested and locking your scope down is paramount to having a good operation. Even after the document is agreed upon, speaking with the pentester doing the operation can clear up any issues that can arise. If the pentester does happen to exceed scope, don't berate him unnecessarily. Thank him for notifying them of the findings, and then explain to them that they are outside of scope. If they continue to do so, you should report them. Often, they may have seen something so glaring that they are ethically bound to mention it. I know that if I was doing a pentest or evaluation and it was a bank or business I used, I would definitely find a way to let them know.

You want to get the most bang for your money, so you give the pentester a decent amount of time to test things. You may even want to run preliminary nmap scans, nikto scans (if web apps are involved), or vulnerability scanners. This is very important info for the beginning of a pentest, but often takes the longest to do by the pentester. This is menial stuff that is a waste of good pentesting time. Plus, a professional pentest shouldn't be adversarial in nature. Unless, of course, it's supposed to be... :)

I know in my last post, we were going to have an interview with Michael Gough (Twitter @hackerhurricane) from MI2 Security about Malware and APT attacks. In talking with him after our monthly ISSA meeting, we figured out that we could do a multi-part interview on Malware and APT. He also mentioned in our ISSA meeting that there had been 6 additional retailers that had been breached. We found out today (25 January) in a blog post from Brian Krebs, that Michaels' and it's subsidiary Aaron's Brothers were hit. That leaves 5 more retailers to through.

My guess is that WalMart is involved, and the only other one I'd imagine would be Kohl's... I don't know why, but those two are always on my mind when this story keeps coming up.

I never have had as much fun doing security as when I started this podcast, blog, and learning how to market ourselves. We are learning a lot about different subjects. It's also taken me out of my comfort zone quite a bit, because I'm not good at talking with people that I don't know, or soliciting input from strangers. I want to get my name, my brand out there, and my palms get sweaty just asking people if they'd like to come on our podcast. I'm sure that it will get easier. It's like learning to edit audio or video, you're gonna suck at it at first.

Episode 3 will be up late tomorrow night, just in time for your earballs to enjoy on your Monday morning commute. Hope you enjoy it. Our meeting with Michael Gough will take place Wednesday, and we'll be able to bring you that two or three parter in the weeks to come...

#02: Vulscan and Nmap

While searching around on the Internet, it is amazing the things you'll find.  Nmap's ability to run custom scripts is a very powerful tool.

Vulscan, found at http://www.computec.ch/projekte/vulscan/ can be used in conjunction with Nmap as a 'poor man's Nessus' for a lack of better terms.  Using Nmap's operating system guess algorithms, you can then follow certain vulnerability databases, like OSVDB, CVE, and ExploitDB.  So far, I have tested this with a couple of servers at work...  but unfortunately, the servers are web sites, and for some reason, Nmap can't figure out what the OS fingerprint is.  I am wondering if the fingerprinting isn't somehow being affected by my router, because it's showing up as...

Nmap output from a webserver at work

Sorry for the size...  I'm still figuring this "import image" thing out... But I am damn sure we aren't running "Apple embedded" anything at work...  So, I thought I would try going through a different Internet connection, that being tethered to my phone.

LOL...  it's even worse tethered to my phone.  That same webserver that I scanned from my home, now on my phone is saying that it's a "Panasonic Webcam".  What the hell?  Guess I need to investigate further.  More on that later...

I fully intend to continue testing with Vulscan, maybe as a quick vuln scanner.  We just bought Nessus at work, and pairing OpenVAS with Vulscan will allow us to catch even more issues than previously.

#01: The tools we use...

**My opinions are not my employers, and thusly are mine and mine alone**

I am slowly coming around to understanding the nature of tools like Metasploit, Nmap, and the like. I thought that to become a security researcher, you have to understand exactly what the underlying code does, and you're required to grow your Unix-y beard and ponytail like everyone else.  I felt like Metasploit was a 'cheat' that people used to become pentesters.  I have been around long enough to see people get into positions they clearly were not ready for, and earned certifications because they could write a good test, yet had no knowledge of what they were doing.

I equate Metasploit to the blender a chef would use in a kitchen.  It's a tool, that automates a process that is time consuming or laborious.  Or a wrench that a mechanic would use to tighten bolts.  Everyone in a job has their tools, those little time savers that make work more efficient.  Someone else created the blender, and the wrench, but we gain an advantage by using them.

I always thought that I'd need to make my own exploits and learn C and Assembly, and I'd need to learn how to solder well enough to make my own circuits for hardware malware, etc.  While I would still love to have an in-depth knowledge of those ideas, I have realized that I ended up with a bit of scope creep, and that I need to dial it back a bit to keep from being overwhelmed.

That's why I'm learning Python, and someone else suggested Ruby (since Metasploit uses that)...  I do want to learn more about C, but right now, I just have the basics.  Plus, there isn't much in the way of C programming being used at my office, so I need to learn concepts that will relate directly to my job so I can keep my edge sharp...

So, Python and Ruby it is...  Also, gotta get back to shell scripting... I used to do it a lot in the past, but vulnerability scanning, and justification of firewall ACLs for PCI-DSS doesn't have a place for shell scripting...

I want to do a post once a week, even if it's just stream of consciousness shit.  The C|EH All-in-One book is a hard slog though... Just through the chapter on Social Engineering.  I realize now that we probably should give some kind of training on a regular basis to spot social engineering trickery, as well as proper disposal of papers with info on them... ooh... I wonder how difficult the shred bins locks are to pick...  Yep, even when you reduce scope, scope creeps back...