R2con 2016 reverseme challenge

Poster by Hackerstrip

Back in September 2016 I attended R2con, the first public and international congress about Radare. Needless to say, it was pretty awesome 😀 and I recommend everyone interested in reverse engineering to go there next year. During the conference, Riscure proposed a simple reversing challenge using Radare to play with. You can find the challenge here. This is my (very short and dumb) writeup of it.

The challenge consisted of reversing an ELF binary and figuring out a password. When running the binary, you had to enter the password to get a message saying that you won the challenge. No modifying was allowed, just reversing. Now, this in itself was super easy since it was meant as an introduction, but I didn’t know how to use r2 well enough so it took me a while to solve it. 😀

The first problem I ran into was that it used a different version of libcrypto than my distro so I had to set up a VM. I suppose I could have installed another libcrypto and have them coexist, or used a chroot jail or whatever, but just firing up a VM seemed like the easiest choice to me – especially since I’m already used to Vagrant for this kind of thing.

After that, it was time to fire up Radare:

$ chmod +x RHme2_prequalification_challenge # (did not have the +x bit in Github)
$ ./r2 ./RHme2_prequalification_challenge

Then analyzed everything with the “aaaa” command and launched the UI with “=H” (because I’m lazy). Using the UI I quickly listed the strings, found the relevant ones, then looked for references to them. Turns out everything was right there in main() so this step wasn’t really needed! 😀

So, going back to the console, using visual mode we can see the code right away:

Gotta love ASCII art graph view

There was some code before the AES decryption that may be some kind of obfuscation, but I didn’t bother with it statically because it was easier to just put a breakpoint at the memory compare after decryption to see what the hardcoded password was.

Turns out to run Radare as a debugger you need to specify -d before opening the file. I got stuck there for a while because I’m such a n00b. #shame 😀

So, after running “r2 -d”, setting the breakpoint with “db 0x0040081d” then executing the program with “dc”, I got prompted for a password. Just typed anything and continued, after that the breakpoint was hit.

From the code I knew the argument with the decoded password should be in the rbx register, so using the “dbr” command to show the registers, then the “s” command to change the pointer (another odd concept for those of us coming from gdb!) and finally using the “x” command I could see the memory contents:

Gotcha!

Running the program again and trying out that password confirmed it was correct. TA-DA!

Well, now that I’ve made you waste your time reading this, here’s a much better writeup for it. Enjoy! 😉 #trolling

Heartbleed and ASLR misconceptions

TL;DR: Someone was wrong on the Internet and I just couldn’t help myself. If you already know how memory allocation works you’ll find this post boring and you can skip it. But if you don’t, read on… 🙂

I was just reading an article called “A look at Heartbleed and why it really isn’t that bad” and, while I usually tend to agree with anyone who tries to fight against FUD, in this case it happens to be dangerously wrong. I’d write this as a blog comment rather than an entry on my own, but Tumblr seems firmly stuck in the 90’s and won’t even give me that option so here it goes…

In a nutshell, the article downplays the severity of the Heartbleed attack based on the Address Space Layout Randomization (ASLR) feature of most modern operating systems, that causes memory allocations to be randomized as a mitigation for buffer overflows. The reasoning goes: since memory allocations are random, and the Heartbleed bug allows you to read memory at random as well, the odds of reading important data are pretty much close to zero – therefore the Heartbleed attack is useless and you shouldn’t change your passwords.

Ouch.

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! 😉

Updated Impacket/Pcapy installers for Python 2.5, 2.6 & 2.7

Hi folks! In a previous post I talked about using Impacket and Pcapy on Python 2.6. Since those installers are now out of date, here are fresh ones for various versions of Pcapy and Python, built against WinPcap 4.1.2. There’s also a new Impacket MSI installer that works against all Python versions.

Enjoy! 🙂

Edited 6-May-2013: updated Impacket to version 0.9.10
Edited 18-Feb-2014: updated Impacket to version 0.9.11

Download Impacket 0.9.11

impacket-0.9.11.win32.msi

impacket-0.9.11.win-amd64.msi

Download Pcapy 0.10.5

pcapy-0.10.5.win32-py2.5-winpcap4.1.2.msi

pcapy-0.10.5.win32-py2.6-winpcap4.1.2.exe

pcapy-0.10.5.win32-py2.7-winpcap4.1.2.exe

pcapy-0.10.5.win-amd64-py2.6-winpcap4.1.2.exe

pcapy-0.10.5.win-amd64-py2.7-winpcap4.1.2.exe

Hackito Ergo Sum 2012

Hi everyone. Last week I’ve attended Hackito Ergo Sum 2012, and I wanted to share with you some of the things that I found most interesting during the talks. This won’t be a detailed review of each talk, but rather an account of a few details on the talks that I personally found more interesting, in no particular order. If you’re looking for a detailed review of each talk check out this blog.

Oh, by the way. I totally made up the names of the talks. I think it’s more fun that way. 🙂

The event took place at the headquarters of the French Communist Party, and I have to say the conference room was quite impressive. It was an underground dome all covered with white metallic plates and lamps behind, giving a peculiar visual effect.

An additional advantage of this place is that some security agencies can’t send their spooks there. Hurray to the ridiculously outdated cold war laws! 🙄

One thing I didn’t like though, was that the slides were projected in a sort of tilted curved screen, making it a bit difficult to read the slides unless you were sitting in the middle. I don’t think I was the only one with this problem because I saw a lot of heads tilted sideways… 😉

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

“Hiding” your Python source with ROT13

First of all I want to make something clear: this is an absolutely lame way to obfuscate your code. I guess some antivirus, IDS or other kind of security scanner may fail to properly analyze the code if it’s encoded like this, but you can’t really fool a human.

Anyway, it was fun 🙂 and that’s my main motivation to write this blog in the first place, soooo… here it is! A Python source code obfuscator that uses ROT13.

How does it work? Simply put, by misusing the Python source encodings feature. I stumbled upon this idea while reading a thread in Stack Overflow. Python allows us to use any supported form of text encoding for our source code, by placing a magic comment in either the first or second line of the script:

    #!/usr/bin/env python
    # -*- coding: <codec-name-goes-here> -*-

This is useful for example to use UTF-8 and other encodings that allow non-english characters. But Python also has some other fun encodings, like ROT13 (the ancient Roman empire encryption system). The following snippet from Stack Overflow shows how to do it:

    #!/usr/bin/env python
    # -*- coding: rot13 -*-

    cevag "Uryyb fgnpxbiresybj!".rapbqr("rot13")

The only caveat is, ASCII strings are not decoded when you run the script, so you have to do it yourself. Unicode strings on the other hand are decoded automatically.

    #!/usr/bin/env python
    # -*- coding: rot13 -*-

    cevag h"Uryyb fgnpxbiresybj!"

There are some other fun encodings like “base64”, “uuencode”, “zlib” or “bz2” that you can experiment with too. If you try them let me know how it went. 🙂

I wrote a quick script to use the ROT13 trick. Naturally the source code itself is also encoded in ROT13, decoding it is left as an exercise for the reader. Enjoy!

Download

Source code: rot13src.py

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