WinAppDbg 1.5 is out!

What is WinAppDbg?

The WinAppDbg python module allows developers to quickly code instrumentation scripts in Python under a Windows environment.

It uses ctypes to wrap many Win32 API calls related to debugging, and provides an object-oriented abstraction layer to manipulate threads, libraries and processes, attach your script as a debugger, trace execution, hook API calls, handle events in your debugee and set breakpoints of different kinds (code, hardware and memory). Additionally it has no native code at all, making it easier to maintain or modify than other debuggers on Windows.

The intended audience are QA engineers and software security auditors wishing to test / fuzz Windows applications with quickly coded Python scripts. Several ready to use utilities are shipped and can be used for this purposes.

Current features also include disassembling x86/x64 native code, debugging multiple processes simultaneously and produce a detailed log of application crashes, useful for fuzzing and automated testing.

What’s new in this version?

In a nutshell…

• full 64-bit support (including function hooks!)
• added support for Windows Vista and above.
• database code migrated to SQLAlchemy, tested on:
  • MySQL
  • SQLite 3
  • Microsoft SQL Server

  should work on other servers too (let me know if it doesn’t!)

• added integration with more disassemblers:
  • BeaEngine: http://www.beaengine.org/
  • Capstone: http://capstone-engine.org/
  • Libdisassemble: http://www.immunitysec.com/resources-freesoftware.shtml
  • PyDasm: https://code.google.com/p/libdasm/
• added support for postmortem (just-in-time) debugging
• added support for deferred breakpoints
• now fully supports manipulating and debugging system services
• the interactive command-line debugger is now launchable from your scripts (thanks Zen One for the idea!)
• more UAC-friendly, only requests the privileges it needs before any action
• added functions to work with UAC and different privilege levels, so it’s now possible to run debugees with lower privileges than the debugger
• added memory search and registry search support
• added string extraction functionality
• added functions to work with DEP settings
• added a new event handler, EventSift, that can greatly simplify coding a debugger script to run multiple targets at the same time
• added new utility functions to work with colored console output
• several improvements to the Crash Logger tool
• integration with already open debugging sessions from other libraries is now possible
• improvements to the Process and GUI instrumentation functionality
• implemented more anti-antidebug tricks
• more tools and code examples, and improvements to the existing ones
• more Win32 API wrappers
• lots of miscellaneous improvements, more documentation and bugfixes as usual!

Where can I find WinAppDbg?

Project homepage:

• http://winappdbg.sourceforge.net/

Download links:

• Windows installer (32 bits)
• Windows installer (64 bits)
• Source code

Documentation:

Online

• Tutorial
• Reference

Windows Help

• Tutorial
• Reference

HTML format (offline)

• Tutorial
• Reference

PDF format (suitable for printing)

• Tutorial
• Reference

Acknowledgements

Acknowledgements go to Arthur Gerkis, Chris Dietrich, Felipe Manzano, Francisco Falcon, @Ivanlef0u, Jean Sigwald, John Hernandez, Jun Koi, Michael Hale Ligh, Nahuel Riva, Peter Van Eeckhoutte, Randall Walls, Thierry Franzetti, Thomas Caplin, and many others I’m probably forgetting, who helped find and fix bugs in the almost eternal beta of WinAppDbg 1.5! 😉

MSDN Help Plugin for OllyDbg / Immunity Debugger

Hi everyone! I just wrote a quick OllyDbg 1.x plugin and I wanted to share it. If you don’t know what that means, read my other article instead at the Buguroo Blog which has a more detailed explanation on what it is and how to use it. This post is more about why I wrote it and how it works.

Anyway. After a conversation on Twitter about how it’s becoming increasingly harder to find the venerable WIN32.HLP file – and how it was becoming ever more outdated, I came to realize I didn’t know of any OllyDbg plugin to use the more modern and up to date MSDN documentation. I asked around and no one else seems to have written such a plugin, so I wrote my own.

It’s sort of a dirty hack – in general there’s no easy way of overriding existing features in Olly, the plugin API is rather meant to add new functionality. So after messing about with it for a while I came up with an easy hack – the plugin just hooks the WinHelp() API call to detect when WIN32.HLP is about to be opened, and launches the default web browser instead. Any other help file is launched normally.

The next step would be to search the MSDN looking for the API call the user requested. Then again, a quick hack came to the rescue 🙂 since instead of figuring out how to perform MSDN searches it was much easier to just use a Google search with the “I Feel Lucky” button. You can find out more here about the unofficial Google Search API.

The plugin is also compatible with the newer Immunity Debugger which is based in OllyDbg, and was tested on both.

To install, just copy the DLL file in the plugins folder (by default is the same where the main EXE lives). You do need to have set the win32.hlp file in the configuration at some point (so Olly actually tries to open it, otherwise the plugin never finds out). It doesn’t need to be the real file though, any file named “win32.hlp” will do the trick, even if it’s 0 bytes long. 🙂

Enjoy!

Download

OllyMSDN.zip

The forgotten bug: silently patched vulnerabilities

Last month, Microsoft released the security bulletin MS10-024 with a patch for a denial of service vulnerability in Exchange and the Windows SMTP service:

“This security update resolves one publicly disclosed vulnerability and one privately reported vulnerability in Microsoft Exchange and Windows SMTP Service. The more severe of these vulnerabilities could allow denial of service if an attacker sent a specially crafted DNS response to a computer running the SMTP service.”

However, researcher Nicolás Economou found an interesting surprise in this patch: two additional, undisclosed vulnerabilities had also been patched… and they were far more severe than the ones reported! From the Core Security advisory:

“Nicolas found that the Windows SMTP Service does its own DNS resolution of MX records rather that use the DNS resolver from the operating system while investigating CVE-2010-0024.

Furthermore, he found that the patch referenced in MS10-024 fixed two severe bugs that were not disclosed as such in the bulletin and had no CVE identifiers assigned to them. Basic analysis of the vulnerabilities disclosed in this advisory indicates that the threat of DNS spoofing attacks against Windows SMTP service and Microsoft Exchange or of exploitation of CVE-2010-0024 was underestimated in MS10-024.

An attacker may leverage the two previously undisclosed vulnerabilities fixed by MS10-014 to spoof responses to any DNS query sent by the Windows SMTP service trivially. DNS response spoofing and cache poisoning attacks are well known to have a variety of security implications with impact beyond just Denial of Service and Information Disclosure as originally stated in MS10-024.”

In fact, the two “new” vulnerabilities were quite crass. Both Exchange and the SMTP service were doing their own manually crafted DNS queries using incremental transaction IDs, which is a big no-no when implementing DNS because it makes it real easy for attackers to guess the transaction ID and spoof replies, as is a well known fact for… say… the last 16 years or so? But as it turns out, attackers didn’t even need to guess the transaction IDs… because they weren’t even being used when parsing the DNS responses! 😯

This omission may be easily attributed to the “embarrasment factor” 🙂 but it’s still a terrible idea to patch vulnerabilities silently: IT administrators, unaware of the real danger of the problem, may give the patch a lower priority. A denial of service just means having the mail server down for a while until it restarts, so the patch can wait – it’d be worse if the server didn’t work at all because patching went wrong. On the other hand, a DNS poison vulnerability means having an attacker browse through everyone’s emails and taking over all other services you may have on the same machine – patching becomes much more worth the risk.

Of course, this isn’t the first time this happens. Practically every vendor did this at one time or another. A quick Google search for “silently patched vulnerability” shows some 1.400.000 hits at the time I’m writing this, showing this is neither new or uncommon – and that even small software vendors may easily get caught. Especially thanks to the rise of binary diffing tools that can pinpoint precisely where and how the code was patched.

Thanks Alfredo Ortega for pointing out this advisory and providing such a cool sounding title. 😉

Using Impacket/Pcapy with Python 2.6 on Windows

Hello everyone! Today we’ll be installing Impacket and Pcapy for Python 2.6 on Windows. The Impacket module lets you parse network packets, this is very useful for example when developing a sniffer. The Pcapy module interfaces with WinPcap to do the actual packet capture.

From the CORE Security webpage:

What is Impacket?

Impacket is a collection of Python classes focused on providing access to network packets. Impacket allows Python developers to craft and decode network packets in simple and consistent manner. It includes support for low-level protocols such as IP, UDP and TCP, as well as higher-level protocols such as NMB and SMB. Impacket is highly effective when used in conjunction with a packet capture utility or package such as Pcapy. Packets can be constructed from scratch, as well as parsed from raw data. Furthermore, the object oriented API makes it simple to work with deep protocol hierarchies.

What is Pcapy?

Pcapy is a Python extension module that interfaces with the libpcap packet capture library. Pcapy enables python scripts to capture packets on the network. Pcapy is highly effective when used in conjunction with a packet-handling package such as Impacket, which is a collection of Python classes for constructing and dissecting network packets.

There is a problem though – Pcapy hasn’t been updated in quite a while, so there is no MSI installer for Python 2.6. I’ve built it myself and hosted in here in the blog, so you don’t have to. 🙂 I’ve also built an EXE installer for Impacket, it’s not really needed since it’s a pure Python module, but why not?

So this is the list of files we’ll be needing:

WinPcap_4_1_1.exe

pcapy-0.10.5.win32-py2.6.msi

Impacket-0.9.8.0.win32.exe

Installation is now pretty much straight forward. After running all the installers, let’s try it out with this example script to dump all connection attempts by sniffing SYN packets:

    C:\Documents and Settings\Mario Vilas\Desktop>python connections.py
    Available network interfaces:
            1 - \Device\NPF_GenericDialupAdapter
            2 - \Device\NPF_{5BE055D9-461D-4F51-99DD-188224D1A6D0}
            3 - \Device\NPF_{9B7DC2FB-7660-4E68-B4EC-DB9682C76E40}
            4 - \Device\NPF_{166A618C-4230-42E7-93AD-298D1145F5BC}
            5 - \Device\NPF_{BE987C8D-D523-49B8-8B95-DDDBAA46EB3F}

    Choose an interface [0 to quit]: 2
    Listening on: \Device\NPF_{5BE055D9-461D-4F51-99DD-188224D1A6D0}
    Connection attempt 10.0.2.15 -> 192.168.254.254
    Connection attempt 10.0.2.15 -> 192.168.254.254
    Connection attempt 10.0.2.15 -> 192.168.254.254
    Connection attempt 10.0.2.15 -> 192.168.254.254
    Connection attempt 10.0.2.15 -> 192.168.254.254
    Connection attempt 10.0.2.15 -> 209.85.227.106
    Connection attempt 10.0.2.15 -> 209.85.227.104
    Connection attempt 10.0.2.15 -> 209.85.227.104
    Connection attempt 10.0.2.15 -> 209.85.227.104
    Connection attempt 10.0.2.15 -> 209.85.227.100
    ^C

Below is the source code to the script. Enjoy! 🙂

Updates

• A newer version of Impacket is hosted at Google Code, so I built a new installer. The previous version of the installer, based on the version of Impacket found in the Core Security webpage, is still available here: Impacket-0.9.6.0.win32.exe

• Ge0 has built Pcapy for Python 2.7 using MingW to avoid having a depencency against the Visual Studio runtimes. You can download it from here: pcapy.pyd

Download

connections.py

Source code

Using diStorm with Python 2.6 and Python 3.x, revisited

In a previous post, we’ve seen how to wrap the diStorm disassembler library in Python, using ctypes. This still left us with the task of building the dynamic link library for our platform and installing it manually, which is not as easy as it may seem – among other small problems you may find, the new versions of Visual Studio try to force the use of the latest C++ runtime redistributables, which may not be present in most Windows installations.

Today, I’m introducing a new ctypes wrapper for diStorm, this time with all binaries prebuilt and packaged together. The installer script automatically detects the target platform and installs the right binary. It comes with the following prebuilt binaries:

• Windows on x86 and AMD64 processors
• Linux on x86 and AMD64 processors (built using Ubuntu, but should work in other distros)
• Mac OS X on x86 and PowerPC processors (untested, I don’t have a Mac to play with yet)

Since the installer code is pretty much generic, it should be easy to add new platforms by simply creating the corresponding subdirectory and placing the python code and prebuilt binary in it. Contributions are welcome! 🙂

Download

Python 2.x

• Source code (all platforms): distorm-1.7.30.zip
• Source code (all platforms): distorm-1.7.30.tar.gz
• Windows 32 bits installer: distorm-1.7.30.win32.exe
• Windows 32 bits MSI installer: distorm-1.7.30.win32.msi
• Windows 64 bits installer: distorm-1.7.30.win-amd64.exe
• Windows 64 bits MSI installer: distorm-1.7.30.win-amd64.msi

Python 3.x

• Source code (all platforms): distorm-1.7.30.zip
• Source code (all platforms): distorm-1.7.30.tar.gz
• Windows 32 bits installer: distorm-1.7.30.win32.exe
• Windows 32 bits MSI installer: distorm-1.7.30.win32.msi
• Windows 64 bits installer: distorm-1.7.30.win-amd64.exe
• Windows 64 bits MSI installer: distorm-1.7.30.win-amd64.msi

DBG_CONTINUE vs. DBG_EXCEPTION_HANDLED

Something odd just happened to me while trying out my debugger on Windows XP 64 bits – whenever I stepped on or traced an instruction, the instruction pointer would go back to the same instruction the first time. The second time, it worked. So I had to step twice on each instruction to debug a program.

This was clearly wrong, but I couldn’t see anything in my code that would produce that. Furthermore, in 32 bits the exact same code was working alright!

After scratching my head for a while, I went to MSDN in search of enlightment, and found this info at the help page for ContinueDebugEvent:

DBG_CONTINUE (0x00010002L): If the thread specified by the dwThreadId parameter previously reported an EXCEPTION_DEBUG_EVENT debugging event, the function stops all exception processing and continues the thread. For any other debugging event, this flag simply continues the thread.

DBG_EXCEPTION_NOT_HANDLED (0x80010001L): If the thread specified by dwThreadId previously reported an EXCEPTION_DEBUG_EVENT debugging event, the function continues exception processing. If this is a first-chance exception event, the search and dispatch logic of the structured exception handler is used; otherwise, the process is terminated. For any other debugging event, this flag simply continues the thread.

But I remembered seeing a certain DBG_EXCEPTION_HANDLED value when porting SDK constants and structures to my Win32 API wrappers. So I looked it up and it’s value turned out to be 0x00010001L, which was exactly DBG_CONTINUE minus one, so it wasn’t not just an alias but really a different value, possibly with a different meaning.

So I tried replacing DBG_CONTINUE by DBG_EXCEPTION_HANDLED when handling exceptions in my code and, what do you know, single steping and tracing began to work again!

Apparently, when handling exception events, 32 bits Windows treats DBG_CONTINUE as an alias of DBG_EXCEPTION_HANDLED, while in 64 bits Windows it’s an alias of DBG_EXCEPTION_NOT_HANDLED. This means we can’t possibly write a debugger for 64 bits without using this undocumented value! 😦

Luckily for us, DBG_EXCEPTION_HANDLED seems to work well in 32 bits Windows, at least with XP (didn’t test Windows 2000 yet), so the same code may be used for all versions of Windows. It also works with current versions of Wine, judging from this commit from 2005.

Speaking of Wine, browsing through the sources I found several other “undocumented” status codes:

• DBG_TERMINATE_PROCESS
• DBG_TERMINATE_THREAD
• DBG_CONTROL_C
• DBG_CONTROL_BREAK
• DBG_COMMAND_EXCEPTION

However the last three don’t seem to be supported by Windows XP, as shown in the following disassembly of NTOSKRNL.EXE:

That still leaves us with two new undocumented status codes to play with 🙂