Following my previous venture, more
accurately 'wander', into Extending WAFL - ASP.NET MVC and a very
cool, tangential trip off into Continuous Integration Land, I'm now
re-gaining focus on using the AppScan Source Framework-4-Frameworks
(F4F) APIs to write support for handling the ASP.NET MVC 3.0 framework.
As detailed in this post by Dinis Cruz:
There are several, non-trivial, pieces to constructing
the full data flow picture of a modern MVC application and ASP.NET
MVC 3.0 contains a particular flavor of Auto-Binding of data - which we happen to know from previous research, has 'interesting' security
implications, which can be found at the end of the post.
The First Piece of the DataFlow Puzzle:
→ The controllers (equivalent
to WebService's methods, which need to be marked as
Getting back into the Eclipse IDE, and
loading up the EJB example found at <F4FEjbExample.zip>, this
time I got straight to the point of identifying what I needed to
- Tell the Analysis Engine that
this new Handler should be run if given the appropriate
- Find all Controllers within the
source code for the application and extract the .NET class
- Convert these signatures to the
“Fully Qualified VDB (Vulnerability DataBase) Signatures”
necessary, and create:
Tainted CallBacks - Defined in Ounce-Terminology as "This is a Source and
it can be called with user-controllable data”
Controller found, generating the appropriate elements into the .wafl file created for the scan.
Following the AppScan_Source_Utilities
manual regarding the F4F API, the first task was accomplished easily:
→ Create a Manifest.txt within the
project, which would be exported in the .jar file which simply identifies the Handler class
within the .jar, and specifically the isApplicable() method explained below.
→ Extend the F4FHandler abstract
class and implement the isApplicable() method,
using any logic you like, to determine whether or not to run the handleApp() - where
the actual framework analysis is performed:
straight to the point on this one and testing out the most basic integration:
- Debug Logging Message - in isApplicable() function");
Saving this snippet of code and Exporting the .jar file into the <appscan_install_dir> was verified as properly invoking this method in the WAFL log file:
<-Start->2013-01-26 13:57:58,462<-Sep->WARN<-Sep->com.ibm.wala.andromeda.util.logging.TaintLogger<-Sep->com.ibm.appscan.frameworks.highlevelapi.aspnethandler.AspNetHandler.isApplicable(AspNetHandler.java:129)<-Sep->ASP.NET - Debug Logging Message - in isApplicable() function<-Sep->
To investigate a bit further into the details of how the built-in Framework support worked, I opened up the O2 – JavADecompiler and loaded some of the more interesting jars found in <appscan_source_install>\walalib\. Of specific interest was looking into classes and methods contained in the
com.ibm.appscan.frameworks.aspdotnet.jar -- which I could notice classes
being invoked when examining a <project_name>_frameworksCLIDotNet.log (created in the “working
directory” for the target project) generated while scanning
a known (not MVC) C# application.
I soon had my plan of attack, as simple as it was, to solve Step 2 and 3, identifying all Controllers within the code, translating their signatures to the proper Fully-Qualified-VDB-Signature and creating the Tainted Callback using the VDB Signatures.
The code for this is contained in the handleApp() method of the AspNetHandler class:
The essential reason that this has become so simplistic - I can just retrieve a list of all classes in the application and their respective methods - is because of the [well-designed APIs allowing] integration of Another Fully Functional Static Analysis Engine
into the AppScan Source Product. This SAST Engine, known as WALA
, is actually very well known around the IBM Research (and AppScan) Community and came to us via our most honorable colleagues at the IBM Thomas J. Watson Research Center
Even though this is such a simple use case - the power of having this entire alternative way of representing a target application and then being able to perform very in depth analysis (see screenshot of just a sample of the classes in one of the WALA jars) on the representation - AND THEN - being able to communicate that information to the main Analysis Engine through WAFL...
I Think I'm Finally Starting To See The Light Trickling Through The Visibility Fog
There is some seriously fertile ground here for
investigation. It's making me reminisce of " The 5 Phases
Of Analysis" approaches that were once popular with the Ounce
ART (Advanced Research Team) and jOHN's Python Robots some ages
But to finish this post off, below are links to the
aspnethandler.jar that was exported by Eclipse (needs to be placed in
the <appscan_source_install>\waflgens\ directory) and to the
.walf file created while scanning MvcMusicStore, showing the Tainted
Callbacks for all of the Controllers.
MvcMusicStore WAFL File
Given that previously we had a completely blank WAFL file
generated and that now we actually have the first step in attaining
some good visibility into ANY ASP.NET MVC 3.0 Application, I'm going
to close up shop on this post... but.
Before I do, I did promise a touch of light bedtime reading on some Auto-Binding Vulnerabilities,
the presence of which is just now starting to gain recognition under the
newly minted Mass Assignment Vulnerability category.
To the best of my knowledge,
the first instance of this was discovered by my colleagues at Ounce
Labs, Ryan Berg and Dinis Cruz, and published in this Ounce Labs
Press Release, issued in 2008:
Ounce_Labs_Spring_Vulnerabilities.pdfFollowing up on that work, Dinis released:
SpringMVC Sample App - BlackBox Exploits
More recently released, and very pertinent, is a nice presentation by fellow O2 User, Michael Hidalgo:
Exploiting.NET MVC Using The O2 Platform
Enjoy the Visibility And Share