Breaking Code

April 12, 2014

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.

(more…)

December 20, 2013

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:
  • 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:

Download links:

Documentation:

Online

Windows Help

HTML format (offline)

PDF format (suitable for printing)

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! ;)

July 16, 2012

[Quickpost] 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

(more…)

May 5, 2010

The forgotten bug: silently patched vulnerabilities

Filed under: Vulnerabilities — Tags: , , , , , — Mario Vilas @ 10:39 am

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! :shock:

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. ;)

April 2, 2010

Using Impacket/Pcapy with Python 2.6 on Windows

Filed under: Tools — Tags: , , , , , , , , , , — Mario Vilas @ 5:30 pm

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

(more…)

February 10, 2010

Quickpost: New remote authentication vulnerability in Windows

A new security advisory has been published today on a new remote vulnerability (MS10-012, CVE-2010-0231) in the SMB protocol on many Windows versions, ranging from the now ancient Windows NT to the latest Windows 7. This would allow an attacker to authenticate to almost any Windows box, read and write any files, or alternatively upload an executable file and run it. Just let me quote the following, it’s what caught my eye the most:

Given that Windows NT 4 was relased in ~1996 this vulnerability has been
present for ~14 years. If it is confirmed this vulnerablity is also
present in older systems such as Windows NT 3.1, released in ~1993,
Windows NTLMv1 authentication mechanism could have been vulnerable for
~17+ years
.

Whoa. That’s kind of scary.

Kudos to Hernan Ochoa and Agustin Azubel for this great find! :)

Below is the complete text of the advisory, except for the source code to the scripts, which were removed for brevity. The original advisory can be downloaded from: http://www.hexale.org/advisories/OCHOA-2010-0209.txt.

Update: Hernan Ochoa has also written an article regarding the risk assesment for this vulnerability.

(more…)

The Silver is the New Black Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 2,480 other followers