In my first post on the Attack Surface Analyzer, we looked at the basic function and how it fits into the SDL. For this post, we’ll take a deeper look at some of the information the tool provides and a bit about the process used to get that information.

As I mentioned in the previous post, the Attack Surface Analyzer takes a snapshot of the current state of the system. You then install the software you want to test, and take another snapshot or “scan”, to use the tool’s native terminology. The final step is generating the attack surface report by instructing the tool to compare the two scans.

Keep in mind that you have to perform the two scans then generate the report. When I was first testing, it appeared to me that the “generate report” step included the secondary scan but it does not. After seeing blank reports when I knew significant system changes had been made, I finally figured this out.

So what do you get in the report? To test this, I used the Attack Surface Analyzer to evaluate an Apache HTTPD server installation on a Windows 7 machine. Apache seemed like a good candidate and I figured it would make some significant changes in the attack surface.

The report has three tabs – Report Summary, Security Issues, and Attack Surface. Let’s start with the Security Issues the Attack Surface Analyzer identified for the Apache installation.

Directories with weak ACLs

A handful of the Apache directories have ACLs that are “vulnerable to tampering” by the TrustedInstaller account.

Processes With NX Enabled

NX is short for No Execute and refers to a bit that helps prevent certain types of attacks, such as buffer overflows. That’s an oversimplified explanation DEP, but the relevant part is that the report tells you which new processes are running without this security feature enabled.

Processes With Impersonation Tokens

Impersonation tokens allow an unprivileged process to act with additional privileges. As it turns out, this finding was not actually relevant to Apache, it just happened to be something else that changed and was captured by the scan. In this case it was a wireless network adapter utility. I thought it was worth leaving in the list as an additional example of the type of things examined by the Attack Surface Analyzer and also to let you know that this can happen.

Services Vulnerable to Tampering

This is similar to the file ACL issue, only this time relevant to the Apache 2.2 service.

So that gives us a few examples of Security Issues identified by the Attack Surface Analyzer. Now let’s look at the actual Attack Surface Report. Here you get information like:

  • Number and description of new services created
  • New process information, including full command line, ownership, and process flags
  • ActiveX, DCOM, COM, and File Extensions
  • Network information, including new listening ports
  • Named pipe information, including whether they allow network access and null sessions

Keep in mind that these are all just examples and not a thorough listing of all the capability of the Attack Surface Analyzer. I’ll be doing some further tests to determine what other type of information can be generated, but wanted to pass along what I’ve seen so far.

To repeat the message from the previous post, I think the Attack Surface Analyzer has value beyond just the development process. At the very least, it may be a nice addition to your change control process and is worth checking out.