search

microsoft / AttackSurfaceAnalyzer

Attack Surface Analyzer can help you analyze your operating system's security configuration for changes during software installation.
MIT License
2.76k stars 281 forks source link

COM Objects as first class citizens #149

Closed FritzSandsTM closed 5 years ago

FritzSandsTM commented 5 years ago

In addition to a report for New Attack Surface (yeah, I know, next release), the tool should also output a variety of text files for different added attack surface that can then be consumed by tools.

For example, a file listing new COM objects by CLSID (OK likely two files -- 32-bit and 64-bit) that could then feed into a consistency checking tool. A file listing new EXE file paths that could feed into a tool to check the PE Header (for things like the NX flag and ASLR flag being set, etc.).

gfs commented 5 years ago

I'm going to break down this request into two objectives I think you're trying to complete.

  1. Identify all the com objects on the system
  2. Feed the results from ASA into a follow-on tool

Here's my thoughts:

  1. Definitely can add COM objects as a first class citizen. I'm going to hijack this Issue to track that.
  2. I don't think your proposed approach is the correct one. The example data you want (new exe paths) is actually already a part of the JSON report that you can parse. You should look to the data in the JSON and see if what you want is already in there. I'm definitely invested in improving the quality of the results in the JSON, however, so if there is data you'd like to see in the report that is not already included that would be great to hear.

Continuing, check the PE Header (for things like the NX flag and ASLR flag being set, etc.) sounds like something that ASA could do automatically and include in the report. I found a fully managed library for parsing PEHeaders http://secana.github.io/PeNet/ #169

FritzSandsTM commented 5 years ago

If we are expecting the user to parse JSON output for things (e.g. new exe paths) to feed into other tools, then we should consider also releasing parsing scripts when we have them. Remember, many of the users are not always coders.

gfs commented 5 years ago

Is there a specific tool you're thinking of? We can't possibly export special outputs for every tool that exists - or even scripts. I'm not sure what a parsing script is going to do to help, it'll give you another structured data format that you have to parse anyway to get it in the format your other tool wants.

FritzSandsTM commented 5 years ago

I was thinking of generic "Text file of with new line separators". Suitable for feeding, for example, into a PowerShell script. So you can have a text file of "new exes" to pipe into an applet that checks PE headers and text file of "new CLSID values" that you pipe into an applet to check COM registration, etc. Just thinking out loud here. Make it modular rather than all in one exe.

gfs commented 5 years ago

It seems that it wouldn't be a huge change to gather that data inside ASA. Is there a reason you'd prefer it to be outside the report? It really seems to be that collecting a bunch of different files from different tools is going to make analysis significantly more complex not simpler. Also, just passing the list of changed files to check the PE headers doesn't actually tell you if the PE Header itself changed.

davidwallis commented 5 years ago

I was thinking of generic "Text file of with new line separators". Suitable for feeding, for example, into a PowerShell script.

Eww.. No.. please don't.. you have the ability to use convertFrom-Json see https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/convertfrom-json?view=powershell-6 that will allow you to bring the JSON in neatly :)

gfs commented 5 years ago

The work to check PE headers and report the results in already in 2.0, so consider that part of this issue closed. #200.