Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: pentest

{BruCON LT} A quick rant about WebApp crypto

After mulling over possible topics for a BruCON lightening talk I settled on a quick rant about how Web App testers in general are treating crypto. I know crypto doesn’t lend itself to a 5 minute format, and the generalisation (that Web App testers don’t check crypto) is a little broad… but I thought it was a good topic to bring into the small spotlight.

If you have any feedback on the slides (rush job, sorry), or the content in general then please let me know… feedback is gratefully received!

More details about the TYPO3 vulnerability (TYPO3-2009-SA-001) mentioned can be found in the advisories section of this site.

Penetration Testing Execution Standard

Well, after many months of hard work in the background, we’ve reached that point where it’s time to talk about PTES openly.

PTES (Penetration Testing Execution Standard) is a community driven project designed to clearly define what a penetration test is for both businesses and security service providers. Through a common language and scope for performing penetration tests, we hope to raise the overall quality of testing and really help businesses define what it is they need and expect from a penetration test.

As much as we hate to admit it ourselves, there’s a lot of low-quality testing taking place. Setting a standardized approach to scoping, performing and reporting a penetration test will ultimately help  bring up the level of penetration testing to where it should be (or where we hope it will be).

Now, we can’t hope to cover every eventuality, and we certainly won’t try to tell testers what nmap options to use, but we can try to define the minimum steps and coverage required to really differentiate a vulnerability scan from a penetration test. It may sound silly to some, but businesses don’t know what they’re getting some times… and thinking you’re secure is never a good option!

Currently we’re in pre-alpha stages, so please get involved. Let us know what you think. Comment, discuss, argue… This doesn’t work without a community behind it.

Note: Please take time to read what we’re attempting and look at the mind-map information before starting to flame… The only thing worse than trying and failing, is not trying at all!


SANS SEC660: Advanced Penetration Testing, Exploits, and Ethical Hacking – Post Mortem

I’d like to say that I’ve been rushed off my feet since getting back from SANS London 2010… but to tell you the truth I haven’t. This review is a little late mostly because I’ve lacked motivation over the past few weeks to write anything. That’s nothing to do with the class, as you’ll read, but sometimes you just have to take a few days and say “what the heck!”. Anyway, on with the action….

SANS SEC660: Advanced Penetration Testing, Exploits, and Ethical Hacking is a new class that was run for the first time at SANS London 2010. The class is designed to cover the ground between the SEC560 Network Penetration Testing class and the SEC709/710 that Stephen Sims has been running for a while now (Exploit development).

Day One (Advanced Penetration Testing Essentials)

Day one started off hot and heavy with some discussion of what the authors consider “advanced” penetration testing really is. Unlike some of the penetration testing we’re used to, this class seems to come at things from a slightly different viewpoint at times. “Product Penetration Testing” is an area that maybe not all testers are currently involved in, but it’s certainly something that larger internal penetration testing teams are starting to build into their testing regimes.


The first morning was spent laying the foundations of knowledge required to understand the topics coming in days three through six. This included a lot of theory on OS protections, compilers, shellcode and an (all too brief) introduction to SCAPY. The final segment of day one was spent looking at the Sulley fuzzing framework and running through a number of fuzzing labs.

Comments: Although this day was a little heavy on the theory, it was needed. With that said though, I’m not sure throwing these concepts in on day one was needed. I’d also like to have seen a longer SCAPY discussion with at least 1 lab, but we can’t have everything now can we 😉

Day Two (Network Attacks for Penetration Testers)

Day two was certainly a step back from day one. At the pace of the first day, I could imagine the second day being much more complex, but to be honest that wasn’t the case at all. Day two discussed network based attacks on technologies like NAC, VLANs and routing protocols. The fun here was actually getting to perform some of the attacks in a lab environment. Normally these attacks are discussed but not done due to hardware limitations. Although not everything was possible, it was certainly fun playing with VLAN hopping instead of just covering the theory.


Day two also introduced some discussions of MITM attacks (ettercap) and the use of tools like Evilgrade in penetration testing. The final bootcamp lab was back to the day one topics to perform file format fuzzing with WinDBG / CDB.

Comments: Although it was fun to play with some VLAN hopping exercises, I would have liked to have seen a Cisco router or two (nothing too flashy/expensive) for some live demos/labs on the routing protocol material.

Day Three (Attacking the Domain)

Day three was somewhat of an oddity for me. Although I enjoyed it, I thought the material covered was more akin to a 500 level class for the most part. That’s not to say it wasn’t useful, but the difficulty level was certainly lower than the rest of the course (maybe this should be day one!).


Day three centered around attack Windows Domains and Database systems and ran through the phases of testing from enumeration through to attacking systems. Although some of the concepts were simple ones, the information and techniques shown were interesting and maybe not as well-known to all testers. Labs included RDP MITM attacks with CAIN as well as attacks on MS-SQL.

The day finished up with some information on Restricted Desktops, and a short CTF style bootcamp.

Comments: As I mentioned I’m not sure the difficulty was really there when compared to the other days… it was certainly the calm before the storm!

Day Four (Exploiting Linux for Penetration Testers)

Day four was the day most people in class where looking forward to, and dreading at the same time. Linux exploitation… the start of the really technical stuff.


Kicking things off gently we covered a quick introduction to memory and Dynamic Linux Memory before getting stuck in to smashing the stack both with and without Linux OS protections (Stack Canaries, ASLR) in place.

The bootcamp was used to go back and try out some of the exploitation we’d covered during the day. Starting off with a bit of simple fuzzing to trigger the exploit, and working through a simple (yeah right) exploit.

Comments: This day made my head hurt… I’d have loved more time to play with the concepts and more labs, but you can only do so much in one day.

Day Five (Exploiting Windows for Penetration Testers)

Continuing on from where we left of on day four, we moved into exploitation on Windows platforms.


After a quick introduction on the differences between Linux and Windows platforms and executables, we moved into a lab heavy day using WarFTP for a majority of the exploit labs. Working through the day we covered basic exploitation , as well as bypassing DEP and discussed HEAP exploitation briefly (not full coverage). The day finished up with some shellcode basics and the bootcamp section.

Comments: And I thought the Linux day was hard! Even after running through all the labs I’m not sure I took everything in… Certainly one to look at again when I have time!

Day Six (Capture the Flag)

Day six, along with most of the SANS penetration testing classes, is a CTF style event. Although I can see the point of this, I’d have loved to dig more into some of the harder topics from days 4 and 5 instead of fumbling around in a CTF style day 6. Still, overall it was fun, and I’m sure our team would have done well if I’d not spent the whole time trying to exploit one of the Windows challenges (despite being warned that nobody ever does them).

Final Opinions

Overall I think I got a lot out of the class, even if I never will be one of the premier exploit developers. There was a number of points I can take and use in my testing, and that’s the real point isn’t it. If this stuff isn’t useful, then why bother!


Even though the class is not 100% exploit writing, I can see people who are interested in getting into this area being drawn to the SEC660 class. It’s a quick and wild ride, but a good grounding for further learning. If you expect to come out being the next HD Moore however, then you’d better think twice… this kind of thing take years of dedication and study to master… no 6 day class will ever offer that!

Even though programming knowledge isn’t needed for the class, I would highly recommend anybody looking to take the class to at least have some scripting experience. The LABS do include Python scripting, and although it’s nothing too technical, some experience with it really allows you to concentrate on the real goals of the class and not get distracted by Python syntax.

Considering this was the first run for SEC600, I think the class was very well put together. With a few tweak and alterations I can see SEC660 being a great extension to the SEC560 class.

[BruCON] Top 5 ways to destroy a company

Top 5 ways to destroy a company (Chris Nickerson)

No one cares about your findings. We work all day and the ignore your reports!

Well why does that happen?

  • What we give them isn’t important. Managers don’t care about shells!
  • They don’t care about what we care about!

What do they care about?

  • The product line
  • The brand
  • The employees
  • The bottom line

What do you know about the company’s product line? If you didn’t research it, then why not! Don’t you think you should care about what the company cares about.

How do you figure out whats important

  • Step 1: Your opinion doesn’t matter (unless you’re one of the execs that really are in the know)
  • Step 2: Think like them. You need to translate your speech to something they understand.
  • Step 3: Do work.. not on shells, on process, models, information

If you get paid to just go in and hack fuck somebody, then you’re a prostitute.

What kind of stuff are you looking for?

  • Secret
  • Confidential
  • Internal Use Only
  • Public

Going for the secret stuff is great, but what if the Confidential stuff gives you access to the secret stuff? what if the public stuff should be secret?

The business understand CIA (Confidentiality, Integrity, Availability)… all of these factors link into criticality. If you don’t do this, you’re a bad tester!

Customer needs to give you information on what assets exist, the risks, and therefore how critical it is to a company.

Sometimes you’re wrong… email isn’t the most important thing in your company!

You only have a limited time to test, you don’t have an unlimited time to test like blackhats do!

Top 5 ways to destroy a company

  • Tarnish the brand
  • Alter the product
  • Attack the employees
  • Effect financials directly
  • ** Your turn! **

Tarnish the brand (How to do it)

  • Understand the brand
  • Identify key words to market
  • Knowledge of the competitor advantage/disadvantage
  • Intelligence profiles on the “keepers of the brand”
    • Face of the brand
    • Executives
    • Key personnel
    • Entire marketing/design team
  • Reverse engineering the “go to market”
  • Take over the “indicators of quality”
    • False issues (product misdirection)
    • Negative reviews
    • Use by non standard customers
    • False company response

Alter the product (How to do it)

  • Compare listing of products/services depending on the organization
  • Chain of command for product development or service integrity
  • Historical review of the products timeline

Attack the product (How to do it)

Company specific!

  • Software companies
    • Create bugs
    • Make backdoor (then tell the media)
    • Cause errors in function
    • Add hidden features!
    • Divert their code to your servers….
  • Hospitals
    • Change patient diagnosis
    • Attack HVAC and crank the heat
    • Disable critical alerts
    • Attack crash carts to disable on the fly care
    • Attack narcotic dispensing stations
    • Alter patient doses
  • Manufacturing plants
    • Alter the product line (make something different)
    • Change design specs
    • Speed up the line… overflow
    • Slow down the line… underflow (deadlines)
    • Add or remove the product features
    • Decrease quality
    • Break shit.. a lot

Attack the employees (How to do it)

  • Profile who they are (Nessus doesn’t tell you that!)
  • Find out where they live
  • Figure out what “dangers” they might have at the office
  • Figure out there daily routine then make a kidnapping profile
  • Use the company against them
    • Food?
    • Manufacturing equipment?
    • General Terrorism
    • Release the horde?
  • Kill their benefits
  • Reduce their pay
  • Change their accounts (amex DOS)

If you affect their employees, you affect their money!

Directly affect the bottom line (What you will need)

  • Understand how they really make their $$$
  • Identify systems that generate income
  • Do they take credit cards?
  • Do they have cash?

No you know, go and take the money.

SQLi I can see your tables == Ineffective

SQLi I can see your tables to I made a new account and transferred all your money to == OMG!

What can we take away from this

  • Shell doesn’t do anything
  • Speak their language
  • Remove the white/black hat and do the work!
  • Stop trying trying to rationalize why you are right… and change the game!

We are not communication business impact… we are the ones that are ruining the world! It’s on us to fix it.