Enhanced Security Testing –

Do Automate debuggers

Nitin Kumar, Lead Software Engineer

Varun Bhal, Lead Software Engineer

Adobe Systems

ABSTRACT

In today's era, Applications play a central role in how and why business operate and companies are producing them in large numbers. It is not enough to be a software company, it must be fast moving software company.

With enhancing functionalities and capabilities, testing of these applications has become more important keeping in mind with strict deadlines. An approach of traditional testing for functionalities is no longer enough, Security testing for corner cases, crashes, known vulnerabilities type can make a difference in the field for applications. However, with limited budget and no direct revenue can sometime be a bottleneck and some of testing aspect may be ignored or traded off. Also, finding of intermittent issues can attract bad publicity if not handled in proper way.

Automation surely helps identifying the issues proactively with less cost, more regression.

In this paper, we will be presenting some of the scenario/security testing coverage which can be automated with readily available debuggers.

Application focus: Desktop Applications (Primarily)

Platform: Windows (Primarily), Mac, Linux

Security issues covered: Crash dump analysis, DLL Hijacking

In this talk, we will elaborate architecture to implement automation with windbg to cover few security issues.

1. Crash dump analysis automation (via Windbg), also can be extended to lldb and cdb- If an application can create dump file in daily automation for any intermittent crashes, these crashes can be analyzed via automation and report is sent for unique issues.

2. DLL Hijacking issue finding for windows installer files Just a simple check for this vulnerability for each release will make sure that this simple vulnerability is not exposed to the field.

3. Also, we will touch upon various usage of debuggers which can easily be automated with minimal scripts and less infrastructure.

Value to the audience:

1. Awareness about these techniques would help to think for more scenarios which can be explored for automation.

2. There are many free and powerful tools and automating those does not require lot of time but surely increase quality testing coverage.

Crash Dump Analysis Automation:

Crash dumps are very common term used in any desktop applications, anything wrong with the application, create a crash dump and we will analyse it later. But, how often does someone look at all the crash dumps?

Automation for the crash dump analysis can provide coverage of corner cases where crash happens rarely. For large set of crash dumps, it will remove duplicate set of crash dumps, also a definite call stack will help developer/Quality engineer to help identify the issue quickly.

Tools used: Windbg, python for scripting

Workflow Diagram:

DLL Hijacking:

DLL Hijacking is an attack that exploits the way Windows applications search and load Dynamic Link Libraries. Most Windows applications will not use a fully qualified path to load any required DLLs.

An attacker can place a fake DLL for a known program in a location that is searched before the real DLL’s location and confirm that the malicious DLL is loaded, resulting in executing the unwanted code. When programs are not written to specify the exact location of a required DLL, Windows will search for the DLL by name in a specific order.

For instance, let’s say that the application, testing.exe requires a DLL named xyz.dll that is usually in the Windows system directory. If the application does not specify the exact path for xyz.dll, Windows will search for the dll in the directory from which the application has been loaded first.

If a malicious hacker has placed his own version of xyz.dll in the same directory as testing.exe, then that DLL will be loaded instead of the real DLL. Windows just tries to find the first file that has the same name and does not verify if the file is the one that is required.

The vulnerability requires an attacker to convince someone to open a file using a vulnerable program such as Microsoft Word, PowerPoint or others from a remote network location. If the vulnerable application tries to load an external DLL from the same location, the attack will most likely be successful.

This vulnerability is an old one and Microsoft has provide many guidelines to remove these but these are still persistent. To avoid having this vulnerability, either someone has to test for each executable, installer and other files before release

Or,

One can write a simple automation around debuggers and test it within few minutes and can be added in testing routine.

We have been working on automating these 2 application of debuggers. However, these debuggers are very powerful and may be used in various testing scenarios such as scanning process memory, identifying the root cause of various crashes, verify handling of specific type of exceptions, old issues regression.

References & Appendix

1. Debuggers- windbg tutorial https://www.codeproject.com/Articles/6084/Windows-Debuggers-Part-A-WinDbg-Tutorial

2. https://en.wikipedia.org/wiki/Dynamic-link_library

Author Biography

1. Nitin Kumar – Lead Software EngineerWorking as Lead software engineer on Security testing and automation development for Adobe flash player.www.linkedin.com/in/nownitin

2. Varun Bhal – Lead Software EngineerWorking as Lead software engineer in automation development for Adobe flash player.

THANK YOU!