August 1, 2011

Commercial Exploits: Documentation

Posted in Exploits, Pen-Testing at 16:47 by Alex McGeorge

I look at exploits a lot in my day-to-day, I also QA a lot of exploits both internally and for others. This is part 2 of a series on what makes a good commercial exploit.

Word Count: ~500

Penetration Testing Theory 101: Regardless of you opinion on the value and efficacy of defense products (AV, IDS/IPS, etc), the one trump card that defense always holds is full content packet captures. A lot of solutions are being brought to bare that make this much more scalable and easy to implement. You don’t want to be in a position where your target calls in someone who knows what the fuck they’re doing to pour over their logs, but that may inevitable. From an attacker perspective the answer is simple: make your important exploits count and use them as infrequently as possible. Give your adversary as little to go on as you can, make their jobs as difficult as you can.

Documentation speaks directly to the above. If you’re playing this game for high stakes you need to be aware of all the methods, details and potential consequences of an exploit before you use it. Documentation informs your decision on when to use the exploit.

All exploits:

  • Exploit type
  • When was this written?
  • If there’s a patch, when was it released?
  • What platforms/versions have been tested?
  • Is this localization dependent? If so what languages have been tested?
  • Is this one shot or is it repeatable?
  • What’s the success/failure ratio?
  • What happens in a crash scenario?
  • Is anything touched on disk? If so where and what?
  • What if any logs are generated by the service/application?
  • Does this trigger any of the major AV products? Heuristics?
  • What if any alerts are generated by the major IDS players?
  • What does this look like on the wire?
  • Is obfuscation possible? 1 Is it implemented?
  • Is encryption possible? Is it implemented?
  • What debugging and troubleshooting options do I have?
  • How well is the exploit code documented?
  • All the boring CVE, reference, CVSS, OSVDB reference data if it applies
  • Are there any “gotchas” with this exploit?

0day specific considerations:

  • Who else knows about this?
  • Are we reusing any code?
  • Are we using a method only we know about?
  • How was this bug found? 2
  • Did we buy this? Or find it ourselves?
  • Do we know of anyone else doing research in this direction?

This kind of data is a pain in the ass to track but it makes your exploit so much more valuable. It will limit how extensively I have to test it and it gives me a clear picture of where I can use it. Hopefully this gives you something interesting to ponder on your drive home from work.

This post is brought to you by: Skinny Puppy – Worlock

[1] Fortunately, most forensics teams have a finite amount of time to dissect what you did, drag that out as far as you can. Just because they figured out what you did (two weeks later) doesn’t mean they win.
[2] This may seem an odd one but it can speak to how long your 0day may remain unfound.

%d bloggers like this: