Exploring Artifacts in Heap Memory

[Usr6]

Please welcome the latest addition to Mandiant’s free forensic gadget grab bag: Heap Inspector. This tool is the manifestation of a very simple idea a colleague and I came up with several months ago when discussing the prevalence of heap sprays as a staging mechanism for most exploits in the wild today (and why anti-virus/HIPS did not recognize and block heap sprays in progress). The idea was simple: a heap spray stores identical copies of the same block of data hundreds of times on the heap, so why not hash each chunk in an application’s heap space and report repeating patterns? The idea grew into a full-featured tool to visualize and search an application’s heap space in near real-time. I presented Heap Inspector at a turbo talk this year at Blackhat USA 2011.

Heap Inspector is a heap visualization and analysis tool. It has the ability to collect a process’s heaps using both API and raw methods. Features include searching heaps for string or byte patterns (including regex), dumping heap chunks to a file, and viewing chunks in a hex editor pane. Heaps are displayed visually in a bar chart format known as the heap hash map, allowing the user to view allocations spatially. A similar chart called the heap data map overlays regular expression matches for useful patterns on top of the heap bars. This visualization allows an investigator to quickly discover evidence of a heap spray attack and other useful information stored in an application’s heap memory.

What can I do with Heap Inspector?

In general terms, Heap Inspector allows an investigator to visualize and search data stored in application heap memory. This is a simple yet extremely powerful ability, particularly in the context of host-level forensics. I will discuss two specific use cases: detecting heap spray attacks (post-mortem) and searching for personally identifiable information (PII).

Detecting Heap Spray Attacks

A heap spray is an attack technique used to stage shellcode. It is meant to increase the reliability of successfully exploiting a memory corruption vulnerability with an accompanying exploit. This technique is very effective, because it stores the same attack data (which typically contains a nop sled and shellcode) in a large portion of the process’s heap memory. Commonly used against applications that host JIT engines (flash, java, etc) such as web browsers and document readers, heap spray based exploits are prolific among modern exploits seen in the wild (CVE-2011-0609, CVE-2010-1297, CVE-2010-3973, CVE-2010-3971, just to name a few).

Heap Inspector uses a very simple but powerful concept to make a heap spray stand out in the user interface: the heap hash map. This map consists of heap chunks drawn as colored rectangles according to their calculated CRC32, overlaid onto their respective heap. The hash map consists of the CRC32 hash of every heap chunk within tolerance (i.e., greater than a user-supplied base size and frequency of occurrence). Since heap sprays work by allocating the same block of data (a nop sled plus shellcode) hundreds of times on the heap, all of these blocks will have the same hash and will appear as a single contiguous chunk in the UI hash map, as shown below.

fullpic

Figure 1: Visualization of successful heap spray in Adobe Reader (CVE-2010-2883)

The nop sled can be seen in the tool tip popup, and the shellcode can easily be extracted by clicking on the chunk address hyperlink, which will switch to the hex editor view pane. Also of note in this screenshot is the heap is abnormally large (515 MB), an obvious indicator of a heap spray.

fullpic

Figure 2: Extracting the shellcode in heap memory from an exploit of CVE-2010-2883

Once extracted, the shellcode can be analyzed statically in a disassembler or dynamically in an emulator to determine its exact functionality. In summary, the heap hash map makes it trivial to determine the trustworthiness of any suspect document (PDF, MS Word, Excel, etc) simply by running it in a sandbox or virtual machine.

Searching for Personally Identifiable Information

Similar to the heap hash map, the heap data map is used to visualize heap allocations, but in this case only heap chunks that match a supplied list of regular expression are drawn on the map. Several default regular expressions are included with Heap Inspector, such as File/UNC Path, GUID, IPv4 address, SQL queries, URL/domains, Social security numbers, and credit card numbers. You can create, import and export your own regular expressions. As shown below, only regular expressions that are matched in heap memory will be displayed.

fullpic

Figure 3: A portion of the heap data map for Microsoft Outlook

In addition to the graphical heap data map, the search tab provides a simple interface to search for regular expressions in application heap memory. The screenshot below shows an active conversation found in Skype’s heap memory. There are many other useful items stored in Skype’s memory, such as Delphi executable files, SQL statements, and various URLs and configuration data. As a side note, since Heap Inspector reads memory that’s in use by the application, anti-debugging and obfuscation tricks do not work (Skype employs various anti-debugging measures to prevent attaching with a debugger).

fullpic

Figure 4: Active Skype conversation discovered by searching for the keyword ‘skillz’

The search feature is a powerful tool not only for auditing the data stored and used by an application, but also for reverse engineering internal memory structures. By further analyzing the storage structure of the Skype conversation excerpt above, it could be possible to develop a generic byte signature or regular expression. Such a pattern could then be used for generic Skype conversation detection in subsequent searches with Heap Inspector.

How is Heap Inspector different than other tools?

There are many ways to collect data stored in memory, such as attaching with a debugger or dumping physical memory using a host of available tools. The most powerful and interactive of these options is a debugger such as Windbg, which requires technical expertise and cryptic low-level commands. Physical memory acquisition and analysis is powerful but also requires technical expertise and knowledge of memory structures and operating system internals. It also has the disadvantage of being a “smear” of the contents in memory and instantly stale once acquired.

In general, Heap Inspector seeks a middle ground between technical savvy and functionality. It is as close to “real time” as you can get without using a debugger and does not require the technical savvy to navigate memory contents. Typically in memory analysis, an investigator is dealing with either an entire process dump or an entire physical memory dump, which can be an overwhelming amount of data to cull through. By collecting data only from an application’s heap, an investigator can focus on data that’s being actively allocated and used by the program.

With regards to string searching functionality, most investigators are familiar with tools such as SysInternals’ strings utility, which will dump all strings in a binary. Similarly, many memory analysis tools allow an investigator to collect all strings in a process address space, which will include strings from the process’s image. In contrast, Heap Inspector only collects strings from the heap, which represents dynamically allocated data used through the life of the program. This distinction is important because it eliminates a large portion of data that might not be useful.

Finally, when applied to heap spray detection, Heap Inspector uses a simple CRC32 frequency-of-occurrence concept to detect and visualize a successful heap spray. All of the current research and tools related to heap spray detection and prevention that I reviewed use a combination of binary instrumentation, emulation, hooking and/or dynamic code analysis to make an informed decision about the contents of heap data. While this has the added benefit of detecting and preventing heap spray attacks in “real time”, it has the notable drawbacks of adding overhead and generating false positives/negatives.

Final Thoughts

Currently, Heap Inspector only supports live system analysis by injecting into running processes. This method uses API techniques. In future versions of the tool, raw methods to parse heap structures by using the PEB will be employed so that offline memory images can be analyzed.

Also, since the heap spray detection is post-mortem, Heap Inspector will only detect the heap spray after the attack was successful. A future release of the tool might include the capability to detect such an attack in progress. However, several tools and research already exist for this purpose and rely on some variations of binary instrumentation and dynamic code analysis. If you are interested in heap spray prevention, I would recommend taking a look at Microsoft’s EMET and Didier Steven’s HeapLocker tool. For more details, see the whitepaper included with Heap Inspector.

Download Heap Inspector

Sursa

Edited August 7, 2011 by Usr6