static analysis tools and frameworks: overcoming a dangerous blind spot

Copyright © 2015, CigitalCopyright © 2016, Cigital

Static Analysis Tools and Frameworks:Overcoming a Dangerous Blind Spot

Mike LymanSenior Consultant

[email protected]

https://www.cigital.com/blog/static-analysis-tool-framework-blind-spot/

Copyright © 2016, Cigital

mailto:[email protected]

https://www.cigital.com/blog/static-analysis-tool-framework-blind-spot/


Who am I?

Mike Lyman• Senior Consultant at Cigital• [email protected]• 9+ years of software security focus• 19 years in the security business• CISSP/CSSLP• @mlyman87


Who are you?

• Developers?• Managers?• Testers?• Part of a security team?

Are you using static analysis tools?

What are your concerns with these tools?


Agenda

• Intro to static analysis tools

• Static analysis concepts

• Frameworks

• The blind spot• How to overcome it

• .Net Web API walkthrough


Testing with static analysis tools is often referred to as Static Application Security Testing

(SAST).


SAST tools

• Tools that look at source code for certain types of bugs

• As simple as “glorified grep” • simple pattern recognition

• As complicated as compilers • control and data flow analysis

• Often a combination of both

• Free and commercially available


SAST concepts

• Taint: data from untrusted sources is considered tainted• Source: source of data• Sink: function that consumes data

• Taint flows through the data flows until it is either:• removed through validation or sanitization • consumed by a sink

• If taint reaches sink, bad things can happen• Examples:• Buffer overflows• Command injection• SQL injection


Frameworks

• Speed up development• Provide a lot of basic functionality• Allows a focus on core functionality

• Might be completely separate from your language• Java and Spring

• Might be tightly coupled• C# and .Net (but with some advanced features that are available

as separate downloads)


The blind spot


The blind spot

• What is going on under the hood?• Obvious question: Are there security bugs in the framework itself?• Not so obvious: Do frameworks introduce problems for your code?• New sources of tainted data?• New dangerous sinks?• Pass through functions that pass on or add taint?

• How do the data flows work with the framework?

• Does your SAST tool understand this?

• Using non-framework 3rd party libraries can cause the same issues.


Does your tool know about these issues?

• New frameworks and new versions appearing faster than we can keep up – can the tool vendor?

• Are there enough users to get the vendor’s attention?

• Even if you have the source code, can the tool trace the data flows?

• If your static analysis tool cannot see or understand the framework it cannot report issues – false negatives!


False positives are annoying. False negatives are dangerous!

False positives are annoying. False negatives are dangerous!


How do you know you have a problem?

• Penetration testers find code implementation problems • SAST doesn’t

• Functionality analysis• What functionality does the framework (or 3rd party library) provide?• What types of problems can be introduced there or occur there?• Create vulnerable test cases• Scan the test cases

• Binary analysis • Decompile and analyze

• Watch for questions on the tool’s support forums

• Ask the vendor


How do you fix it?

• Teach the tool to handle the issues through custom rules

• May need pre-scan processing

• Supplement with a different tool

• Pressure the vendor

• If you find actual bugs in the framework, report them


.Net Web APIA Walkthrough


The setup

• Customer is creating micro-services based on the .Net Web API (System.Web.Http.ApiController).

• Penetration testers find code implementation issues.

• SAST doesn’t understand the Web API or asynchronous calls, despite both being available for years.

• Need to enable SAST tools to find these issues.


Non-live walkthrough

• Code taken from the stub program is created when you create a new Web API C# application.

• These code snippets don’t necessarily contain security bugs. They are used to illustrate the discovery method used to figure out how to get the SAST tool to understand code derived from the APIController.

• Images of MSIL code taken from ILSpy.


The .Net ApiControl (WebAPI) provides automatic routing and databinding for HTTP methods.

Databinding can be simple types (shown here) or complex custom classes.

Data coming into these controllers via the automatic routing and databinding is part of http requests and should be considered tainted input.

The SAST tool in use does an okay job of identifying tainted data sources both for things that followed the Get, Post, etc. naming conventions and for custom named methods mapped to HTTP methods (via attributes).

The job isn’t perfect and needs to be supplemented with custom rules, especially after implementing some of the solutions discussed in the following slides.


Real SAST problems arise with async methods and awaits. The SAST tool is blind to problems here. Data coming into these methods is not identified as tainted data.

The initial instinct is to craft custom rules looking at C# in these methods. This approach doesn’t work here.

Since custom rules based on C# don’t work, more research is necessary to include examining the assemblies themselves with ILSpy.


ILSpy can take the assemblies and show you the MSIL and then take the MSIL back to either C# or VB.Net.

The C# version of ChangePassword that comes from the decompiled assembly looks vastly different than the C# on the previous slide. Since the SAST tool in use looks at the compiled assemblies with its data flow rules, rather than the original C# source code, it’s now apparent why custom rules based on the original C# aren’t working.

The compiler replaces the original code in the async method and generates a nested class to implement a state machine to handle the asynchronous task.

The problems are now occurring in the generated class.


The generated nested class creates a state machine that manages the async call. Most of the work is done in the MoveNext method (collapsed in the image above) as it steps through the various states until the task is complete. Analysis shows that this is where a large part of the custom rules effort is needed.


We now know where to look. However…

• It is clear that custom rules need to be built based on the generated, nested classes. However, they didn’t exist before compile time.

• A pre-scan step examines the compiled assemblies using FXCop and Mono.Cecil, and generates custom rules on the fly.

• The custom rules are used to scan the assemblies with the SAST tool.

• It still fails to work properly.


Now what?

• The generated classes are nested: private classes with private methods. The SAST tool appears to ignore them.

• Another pre-scan step is created to use Mono.Cecil to modify the assemblies by making the generated methods and classes public.

• The dynamically generated rules start working.


Confirmation

• Test cases are created in C# with known dangerous sinks to test if the SAST tool works with the custom data source rules.

• Test cases confirm proper data flows are identified from tainted sources, to the known dangerous sinks, and issues raised by the tool.

• Due to compiler generated code, this didn’t provide complete test coverage.

• Test cases are injected directly into the compiled assemblies using Mono.Cecil and we can confirm that the rules work.


Problem discovery recap

• Gained a deeper understanding of .Net Web APIs and asynchronous methods.

• Discovered the main tool’s custom rules had to look for MSIL syntax – not C#.

• Observed that taint sources existed within compiler-generated classes and methods that SAST couldn’t see.

• Noticed that visibility issues hid problems from SAST tools.• Private vs. public access modifiers• Nested compiler created classes


Solutions recap

• Created custom rules based on MSIL syntax.

• Created a pre-scan step to dynamically incorporate custom source rules based on generated MSIL for classes inherited from ApiController.

• Created a pre-scan step to modify class and method visibility in generated assemblies.

• Created test cases in C# to test dynamic rules.

• Created a process to inject MSIL test cases into compiled assemblies for more complete test coverage.


Questions?

static analysis tools and frameworks: overcoming a dangerous blind spot

Software