Pocket PC Exploit Development: New Platform, New Beginnings, and a POC Exploit
A short while after I posted my last article, tragedy struck. My Windows CE 2.11 palmtop broke traveling between floors in my building.
Fortunately, I had a backup plan. My HP iPAQ Pocket PC was ready to go.
My palmtop breaking may have actually been a good thing, because it meant that I was finally free of Windows CE 2.11 and ready to move on to a more modern OS, Pocket PC 2003.
Pocket PC 2003 sports modern features like:
- CreateProcess() being a powerful API command with usable options rather than a glorified ShellExecuteEx()
- Modern Winsock commands that allow for more sophisticated network communications
- Modern Windows features and more native applications similar to the ones found on a Windows XP system
- A more agreeable ROM API that makes it easier to extract programs
- A well documented Structured Exception Handler and virtual memory structure
- A more enticing and relevant target, as Windows CE 4.2, the basis for Pocket PC 2003, is commonly used in equipment such as voting machines and warehouse IoT devices
- A much larger library of potentially vulnerable 3rd party applications
iPAQs also run enhanced ARM v4 XScale processors, freeing me from the restrictive SH-3 instruction set and giving me access to x86-based features such as MMX registers and more Unicode filter friendly instructions.
This allows me to throw out many of the restrictions I set for myself in the last article, the most significant of which being sticking with network protocol based exploits. Now, using the enhanced debugging commands introduced in Windows CE 3.0, I am free to start pursuing file format exploits.
To accomplish this, I first needed to build a harness that could receive files from a fuzzer. Here are some of the tools I used to get started:
- Peach Fuzzer Community Edition 3.1 — Find it here. Note that they have taken down all of the documentation, but I’ve been able to put together a list of useful links that will be in the References section. Peach sports a variety of fuzzing strategies. It also has network based payload delivery and fault detection capabilities required for this project. Other fuzzers such as AFL might work, but they require a much more complicated wrapper to be able to fuzz remotely.
- Python 2.7 — Essential for automating some of the more tedious work that goes into building PITs (format descriptor files) for Peach Fuzzer
- Visual Studio 2008 — The Windows CE 4.2 platform builder is almost impossible to get a copy of, and the ARM descriptor files seem to have disappeared. Visual Studio 2008, however, has most of the same debugging capabilities, along with a fantastic Pocket PC 2003 ARMv4 emulator that makes debugging a breeze. As a physical iPAQ owner, this is as close to the real thing as you need to do anything short of kernel and driver exploitation.
I want to emphasize that in the future this project will be expanded to attacks on on systems running Windows CE 6.0, but for now Windows CE 4.2 is a good starting point. It lacks many of the exploit mitigations introduced in Embedded Compact 6.
To test my harness I would occasionally require some enhanced permissions and Kernel level access. I knew that in some versions of Windows CE the functions SetProcPermissions() and SetKMode() existed (mentioned in the last article), which would grant me the access I required. I wanted to do a bit of reverse engineering to see what commands were present in this edition.
Author’s note: I am aware that kernel mode permissions work very differently in Windows CE than they do in standard Windows operating systems, but I required expanded memory access permissions. To learn more about the differences, visit this article by Microsoft.
Extracting coredll.dll was a cinch in this CE edition. A wonderful individual on the XDA Forums created a tool called ROM Extractor. It can extract a limited set of executable and system files from the Pocket PC ROM.
Using ROM Extractor on my physical iPAQ, I was able to dump Coredll. This gave me the ability to verify the existence of SetKMode() and SetProcPermissions(), as well as to discover an interesting function, LoadKernelLibrary().
I did a bit of reading and found out that this function could be used to load a DLL that relied only on Kernel function calls directly into Kernel memory space. I based my simplest harness design and Peach PIT on this command. I fed it mutated versions of the name “coredll.dll”, which failed to load because it’s already loaded on startup. Eventually I got a nice crash.
Too nice, in fact, for the emulator to handle. I realized that I would need to pursue Kernel based crashes on silicon rather than in the emulator, and set out to find a suitable target in user-space.
My target criteria was as follows:
- A native Pocket PC application, something with “Microsoft” in the name
- A fairly simple well known file format, no OLE or WMA
- Initial Denial of Service impact, something that I can publish quickly, but clear Remote Code Execution potential that can be pursued in later research
Instead of bothering with injection and other complicated methodology, I opted for a simple approach: Using a debug loop to catch and record exceptions. I used hooking only to dismiss dialog boxes and terminate finicky programs.
This approach had it’s upsides and downsides. It saved me from another week of delays, as process injection is fairly complex. Debugging also saved me from dealing with notoriously unreliable exit codes. Windows CE processes that encounter unhandled exceptions often like to hang indefinitely, and give normal exit codes when forcefully terminated. Most importantly, it allowed me to access debugging messages and unhandled exceptions in real time.
However, it was a lot less efficient than injection as it required writing files to disk. It also required a lot more timing-based planning and multithreading than I would’ve liked. For example, to trigger links and dialog boxes, I had to send fake keystrokes and messages to the program. It required a lot of user input tracing and I broke out Spy++ a fair few times during the process.
Author’s note: Windows CE files are stored in the RAM by default. Due to differences inherent to WinCE, my method isn’t as inefficient as it may seem on first glance.
I started with what I knew. I did a fair bit of research on targets such as early Internet Explorer and Microsoft word exploits. I eventually landed on one of the classics of Windows exploit development, maliciously crafted MP3 playlist files. These exploits usually require no authentication and the attack scenario is very plausible. A user downloads a playlist file full of links to their favorite songs, unaware of the danger that lurks in the tags. This time, the target was Windows Media Player 10 for Pocket PC. WMP10 uses the ASX playlist format. ASX is XML based, so I figured it would be similar to targeting HTML, which wasn’t panning out, and simpler than Windows CE RTF, which was a peculiar variation of the traditional format.
Author’s note: I’m still working on extracting Windows Media Player from the ROM.
I started by doing some research on Windows Media Player exploits. I didn’t have an exact version string at this point, but I knew it was an old one. Most Windows Media Player ASX exploits are variants of CVE-2000–1113, a buffer overflow based on the length of XML tags.
I started by generating a very small ASX playlist with one video entry. I did this on a physical Windows CE device, and changed the format to ANSI to make things easier on myself.
I then created a Peach PIT based on the below diagram, with red indicating a variable and black indicating an immutable object. I did this based purely on my research on traditional HTML and XML fuzzing, which may have been why I was having so much trouble with Internet Explorer exploits. I’m still learning vulnerability research skills.
In just a few minutes, I caught my first fault.
I also started getting some very nice debug messages thanks to the Microsoft’s generous developers, who forgot to remove them in the release build.
Unfortunately, this also rendered the process incapable of termination and impossible to restart without resetting the emulator and killing the harness, so I only have the ability to find one bug at a time for now.
When I examined the crash, I found that the REF “href” tag had been replaced by 3,243 ASCII characters with hex values that ranged from 0xBB to 0xFF.
I did some manual minimization, and managed to reduce the crash string to 3,000 A’s.
The string caused a buffer overflow and an unhandled access violation. The program counter was not overwritten. The crash only occured when the ASX file was opened at the same time as WMP, either as an argument or by double clicking on the playlist, which made it perfect for the scenario I outlined earlier. It killed WMP before it started up fully. It required minimal user interaction to work, unlike many MP3 player exploits that require the user to press play and risk them seeing an error message.
I packaged the Denial of Service vulnerability into a proof of concept script and sent it off for verification.
I initially hoped to pursue this crash to Remote Code Execution, as the previously mentioned CVE was. However, after submission, I discovered something that may put a dampener in that hope: CVE-2006–6134, a very similar exploit for Windows Media Player 10 on Windows XP. This vulnerability was initially submitted with a DOS impact, but rated likely to have RCE impact if pursued further. Research on this vulnerability has indicated that the one I found may also be heap based. This is one of the few restrictions from my last article that still stands. Exploitation of heap based buffer overflows in Windows prior to the development of Vectored Exception Handling was very difficult and required the programmer to make some serious mistakes. VEH stores overwritable pointers on the heap that were previously stored on the stack. VEH was introduced to Windows CE in version 6.0, so this might be something to pursue later in the series. For now, however, I can test this vulnerability to make absolutely sure that it is heap-based before I table it. Many Windows CE 4.2 applications are only loosely based off of their Windows XP and NT counterparts, and this vulnerability may be more exploitable than I currently predict.
Update: Not looking heap based. I’ll have to do more analysis but the heap viewer doesn’t seem to be showing anything, so I may have to do some RCE analysis.
Tools
All of the tools I used to hunt, identify, and verify this bug can be found on my Github page:
References
