The team here at VDA Labs has deep experience with finding bugs in software. We do this by using a variety of different tools that examine software at different levels – static analysis, dynamic testing, source code review, and even fuzz testing. Fuzz testing is a technique where inputs to a specific program are modified in a variety of ways in order to attempt to crash the software – which could then potentially be turned to malicious use. VDA’s founder, Jared DeMott, has actually co-authored books on the topic in the past, so you could say we are quite familiar with this technique. So when we hear about a new approach to fuzzing, or a novel way of managing the process, we get quite excited. That is why we have recently dove into working with Microsoft’s new product, Microsoft Security Risk Detection (MSRD).
What is Microsoft Security Risk Detection?
Security Risk Detection is an exciting toolset released by Microsoft that allows organizations the ability to perform fuzz testing against compiled code. This product brings 15 years of innovation from internal fuzz testing projects at Microsoft. Third-parties are now able to take advantage of the same technology that has been used to secure major Microsoft projects like Windows and Office. Security Risk Detection raises the fuzzing suite bar by utilizing cutting edge technologies, like cloud-based distributed fuzzing and Artificial Intelligence (AI) Neural fuzzing. Microsoft’s own internal research has shown that they were able to take the industry leading open source fuzzing suite American Fuzzy Lop (AFL), perform deep learning, and then develop a model that found 62 times the number of security crashes in target applications above and beyond what AFL could find on its own. For more information about the Microsoft Security Risk Detection offering, you can visit https://www.microsoft.com/en-us/security-risk-detection/ and https://channel9.msdn.com/Events/Speakers/david-molnar.
What is a Fuzzing Test Harness?
Modern fuzzers execute a target application repeatedly, using modifications to input with the goal of identifying issues like exceptions, hangs, leaks, or crashes. The Security Risk Detection fuzzing suite is primary designed for file format fuzzing and requires an entry-point executable (EPE). The EPE must take a file path as input. Many applications are designed this way, and can take input directly from the command line, but others are not. In cases where we want to use Microsoft Security Risk Detection to fuzz input that is not reachable from the command line, we need to write our own EPE, also known as a “testing harness.” For example, if we wanted to assess the security of a client/server application, a testing harness would need to perform many actions, like starting the server process prior to sending network input from a client connection. Or if we wanted to fuzz test the inputs of functions in a DLL (loaded library), since there is no entry point defined we would need to write a testing harness to pass input from the command line into DLL functions. Sure, this is not as easy as uploading your application and hitting a button, but it is very achievable (email@example.com if you’d like help). We’d like to demonstrate a testing harness we wrote that works for fuzzing libraries with the Microsoft Security Risk Detection fuzzing suite.
An Example Test Harness for Library Fuzzing
To better facilitate an actual example, we first created a library (DLL) with a vulnerable function. We used Microsoft Visual Studio 2017 to put a function called “VulnFunction” inside a DLL that will cause a stack overflow in the dangerous “strcpy” API call if input of over 1000 chars is passed in (yes, it’s a trivial bug, but don’t get hung up on that, this is all about demonstrating a harness – the general process works for many cases).
Since we can’t directly run the Microsoft Security Risk Detection fuzzer suite against a DLL, we next create our “test harness.” Again, we used Microsoft Visual 2017 and developed a basic program that accepts a file path via the command line, reads the contents of the file safely into the heap, then passes the contents of that file (now stored temporary in the heap) into “VulnFunction” that we created above. We had to add the library we wanted to fuzz, in this case “VulnDll” as a reference to our “test harness” project. This allows us to successfully take input from a file, which Microsoft Security Risk Detection can create during each fuzzing iteration, and then pass that input to the DLL function we want to fuzz. This basic “test harness” for library fuzzing is shown below.
Finally, we feed this “test harness” and vulnerable DLL to the Microsoft Security Risk Detection fuzzing suite and observe what happens. Now that we have done the hard work of building a “test harness,” Microsoft has made the process of getting their fuzzer running on our target application pretty easy. Basically, the target application and some seed inputs are all uploaded to a Virtual Machine. This process is documented by Microsoft. After starting our job and letting it run for a couple hours, the following was observed. As can be seen below, the fuzzer has a result.
After opening the “VDA Test Harness” job, we observed that an exception was encountered. All the debug details and the actual fuzzing input that caused the exception are downloadable. Next, we clicked on the “Logs” tab to view more detailed output from Windbg.
After looking through the debugger logs below, we observed that an “Access violation” error occurred, and the specific location was in the target DLL inside “VulnFunction,” which is where we placed the stack overflow vulnerability.
In summary, Microsoft Security Risk Detection is an awesome fuzzing suite built on years of research at Microsoft and it is now available to third-parties. While the fuzzing suite is built to work best with file fuzzing, anyone can quickly develop their own “test harness” that allows the ability to fuzz libraries. This concept can be taken further to even fuzz network communication. VDA Labs is the MSRD consulting partner. So if you need training on using MSRD in CI/CD, help with a harness, or you just plain want us to do the fuzzing for you — we’d be happy to help. Stay tuned for upcoming blogs about additional things we are doing with Microsoft Security Risk Detection. For example, we’ve had a sneak preview of the awesome new web scanning tool Microsoft is building into this platform, to complete the dynamic testing picture. More to come! 🙂