Information Organization in Vulnerability Analysis

All of this fancy organization and lists are just tools for the goal - making a list of everything that is wrong with an application.  When I start a test, I get a URL, a description of how the application works, credentials for two user accounts for each role, and a pat on the back.  This effectively emulates an attacker on “the inside” - they have already found a way in as they will.  Now they have to take the next step.  That’s what I do: take that next step before the attacker finds the app, and list all of the problems in the app that will give the attacker a leg up.

Truth is, though, I have 40 hours and they have all the time they need.  So, information organization is or the most importance to me.  I take copious notes, use full test plans, and track statistics to keep the apps I test ahead of the attackers.  So let’s talk about how I organize information to run a test.

The information about the test has to be protected.  When possible, I use a VPN protected repo to control the information, evidence, and reports related to an application.  I check out my details at the beginning of the day, check them in the end of the day.  Sounds like a dev?  Yup.  Worse, I use Subversion.  Yeah, go ahead and hate.  Remember, I don’t have branching and merging, so the SVN commands are a lot simpler.  Some of the folks I work with still use CVS so it could be worse.

Quick note: I have a pretty solid network in my home office.  I use a business class router, a grid wireless network, and I get help from people who know networking to set things up.  Do this.

All of the information for a test is stored with this structure:







I argue with myself about the order of year and application all the time, and even year and client.  Information architecture is a pain in the ass.  Did you know that the study of information architecture is called “ontology” and the study of treating cancer is called “oncology”?  There is a reason.  Anyway, let’s talk about what goes where.

  1. The Information folder is stuff that the client gives me about the test.  Sometimes it is empty.  Sometimes it has an email, WDSL files, documentation, the APK or IPA binary, source code, or osint I have performed.
  2. The Evidence folder is everything that I have that supports my findings.  The Burp state, screen shots, the notes and test plan (more on that in a sec), anything I stole, Nikto and SSLtest and other scans, databases, like that.
  3. The reports folder has twinkies.  No, that’s where I put the reports.  Mostly, it’s just THE report, but sometimes I save Burp or Nessus reports, summaries, code reviews - basically anything that is to be turned over to the client.

There are three files that are very important and they make up the core of the information architecture for an assessment that we start with.

  1. The Test Plan.  This is a big Excel spreadsheet with tests to run.  It is based on the OWASP Testing Guide, and The Web Application Hackers Handbook, Volume 2. I’ll probably release it later in the series. It goes in the Evidence folder.
  2. The Notes.  This is a text file, with  three sections.  At the top is the URL and credentials, plus any other salient information. Then there is a Notes section, where I put anything that I find that is interesting as I am doing recon.  “This URL has a filename as a parameter.”  or “Here is a file upload.”  Finally there is a findings section.  This should match with the test plan failures, and contain the textual evidence. This usually is a request and response pair, but we will cover it later in the series.
  3. The Report template.  I do have a report template, but unlike most, I don’t have a lot of text in there about my testing process.  No one has complained yet.  If you are a client, and hate the fact that I don’t double the size of the report with process text, let me know.  But, I do use a template, and I like it. I’ll cover what’s in it in the reporting chapter.

To make sure I have a good, clean set of evidence, I reset everything I use to default values before I start.  I use FireFox only for testing, not browsing or anything else, so clearing cookies is no big deal every test.  I clear the browser history, the cookies, the webdb, everything after each test.  

Comments are closed