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 Lyman
Senior Consultant
mlyman@cigital.com
https://www.cigital.com/blog/static-analysis-tool-framework-blind-spot/
Copyright © 2016, Cigital

Who am I?
Mike Lyman
• Senior Consultant at Cigital
• mlyman@cigital.com
• 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 API
A 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

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to Static Analysis Tools and Frameworks: Overcoming a Dangerous Blind Spot (20)

More from Cigital (16)

Recently uploaded (20)

Static Analysis Tools and Frameworks: Overcoming a Dangerous Blind Spot