A graph algorithm a day keeps the CS doctor away…

Suppose we have an undirected graph (connected by lines rather than arrows) in which we can find one or more “islands” of nodes that form connections to each other, but not to nodes in other “islands”. In graph theory, these “islands” are called connected components. In the image below, we see a graph with three connected components:

Now, suppose we have a set containing all nodes, and we can visit each node to know what are its neighbors, that is, the other nodes it’s connected to. We want to find all the connected components and put their nodes into separate sets. How would we do that?

Luckily, according to the Internet (what would I do without it! get a “proper” job I guess) there’s a well known algorithm to solve this problem. and it would go more or less like this. Grab a random node from the graph, and add it to a new set. Now get all the neighbors of this node, discard the ones we already visited (so we don’t get stuck in an infinite loop), add them to the set, and keep doing the same thing from the beginning with each neighbor, recursively. When we’re done visiting neighbors, that means we finished finding one of the connected components – we can start over with a new random node we haven’t visited yet to find the next connected component, and so on until we visited all the nodes.

Confused? Let’s start over, this time with an example.

In the above example we’d start with a set containing 5 nodes (A through E), where B is connected to A and D, and C is connected to E. So let’s pick a random node, say C. We paint C in blue and get the neighbors, in this case it’s just E. Now we visit E, so we paint it blue and get the neighbors, now it’s C again. Since we already visited C (we know because it’s already painted blue) we discard it. Now we have no more nodes to visit, so we’re finished getting the first connected component.

But that was the easy one, and we’ve still got 3 more nodes to go. Let’s pick a random one from the ones we didn’t visit yet, that is, the nodes that remain gray (A, B and D), for example A. We paint it green and get the neighbors, which is just B. Now we visit B, paint it green and get the neighbors, A and D. But A was already visited (it’s green already) so we discard it, leaving only D. Finally we visit D, paint it green, and get its neighbor B. Since B was already visited we discard it. This leaves no more nodes to visit, and we’re finished.

But what was the problem I was trying to solve?

If you came here only looking for the graph theory bit then you can safely skip this part but if I can interest you with some tidbits on the internals of GoLismero, here’s a summary:

During the execution of the program, we have a given number of plugins all running concurrently, and a series of messages with data that are sent to each plugin for processing. Each plugin may also create new data objects and send them to the main process, who in turn re-sends it to the rest of the plugins. For example, the Web Spider plugin would crawl a website and create URL objects for each link it finds, and HTML objects for each page it downloads; then those objects are sent to other plugins that would analyze the URLs and the HTML pages looking for vulnerabilities, and creating Vulnerability objects describing each vulnerability they find. Another plugin may receive a vulnerability and exploit it -for example, an URL disclosure vulnerability- creating new URL objects, which in turn get sent to the Web Spider for crawling, and so on.

The data objects also contain references to each other — for example, if a data object contains an HTML page, it’ll also have a reference to another data object with the URL where it was found, and vice versa. If a vulnerability is found in that page, another data object will be generated with the description of the vulnerability, and it will also reference the URL where the vulnerability was found. The URL, in turn, will reference the vulnerability that was found on it.

More generally, this leaves us with an undirected graph of data objects, since any data object can reference any other data object, but references always go back and forth. Also, we store every data object in a database, where they can be consulted at any time by a plugin.

Now, this would be the problem: before we can send any data object to a running plugin, we have to make sure all other data objects it references are already stored in the database — otherwise, we might run into a race condition between the time the data object is sent to the plugins and the objects it references are stored in the database. If we fail to solve this, a plugin would occasionally find a data object references another object that can’t be found in the database.

To prevent this, a simple algorithm was needed to find clusters of objects that reference each other (a connected component). So as plugins send messages to the main process, the main process holds them until it can be sure it has a group of objects that aren’t referencing any data that hasn’t yet arrived. When the whole cluster is complete, it’s stored in the database and sent to the rest of the plugins.

Enough of this nonsense already, where’s the example code?!

Behold! Here it is, in all of its syntax-colored glory. (?)

Enjoy!

example-connected-components.py

    #!/usr/bin/env python
    
    # Finding connected components in a bidirectional graph.
    # By Mario Vilas (mvilas at gmail dot com)
    
    # The graph nodes.
    class Data(object):
        def __init__(self, name):
            self.__name  = name
            self.__links = set()
    
        @property
        def name(self):
            return self.__name
    
        @property
        def links(self):
            return set(self.__links)
    
        def add_link(self, other):
            self.__links.add(other)
            other.__links.add(self)
    
    # The function to look for connected components.
    def connected_components(nodes):
    
        # List of connected components found. The order is random.
        result = []
    
        # Make a copy of the set, so we can modify it.
        nodes = set(nodes)
    
        # Iterate while we still have nodes to process.
        while nodes:
    
            # Get a random node and remove it from the global set.
            n = nodes.pop()
    
            # This set will contain the next group of nodes connected to each other.
            group = {n}
    
            # Build a queue with this node in it.
            queue = [n]
    
            # Iterate the queue.
            # When it's empty, we finished visiting a group of connected nodes.
            while queue:
    
                # Consume the next item from the queue.
                n = queue.pop(0)
    
                # Fetch the neighbors.
                neighbors = n.links
    
                # Remove the neighbors we already visited.
                neighbors.difference_update(group)
    
                # Remove the remaining nodes from the global set.
                nodes.difference_update(neighbors)
    
                # Add them to the group of connected nodes.
                group.update(neighbors)
    
                # Add them to the queue, so we visit them in the next iterations.
                queue.extend(neighbors)
    
            # Add the group to the list of groups.
            result.append(group)
    
        # Return the list of groups.
        return result
    
    # The test code...
    if __name__ == "__main__":
    
        # The first group, let's make a tree.
        a = Data("a")
        b = Data("b")
        c = Data("c")
        d = Data("d")
        e = Data("e")
        f = Data("f")
        a.add_link(b)    #      a
        a.add_link(c)    #     / \
        b.add_link(d)    #    b   c
        c.add_link(e)    #   /   / \
        c.add_link(f)    #  d   e   f
    
        # The second group, let's leave a single, isolated node.
        g = Data("g")
    
        # The third group, let's make a cycle.
        h = Data("h")
        i = Data("i")
        j = Data("j")
        k = Data("k")
        h.add_link(i)    #    h----i
        i.add_link(j)    #    |    |
        j.add_link(k)    #    |    |
        k.add_link(h)    #    k----j
    
        # Put all the nodes together in one big set.
        nodes = {a, b, c, d, e, f, g, h, i, j, k}
    
        # Find all the connected components.
        number = 1
        for components in connected_components(nodes):
            names = sorted(node.name for node in components)
            names = ", ".join(names)
            print "Group #%i: %s" % (number, names)
            number += 1
    
        # You should now see the following output:
        # Group #1: a, b, c, d, e, f
        # Group #2: g
        # Group #3: h, i, j, k

The basic idea is this: given a set of tasks (nodes) and the tasks that need to be performed before them, build a dependency graph and find the sets of tasks that can be run concurrently while satisfying the dependencies. For example, suppose we have tasks A, B, C and D. Task A can be run directly, it has no dependencies. Tasks B and C must be run only after A has completed, so we say B and C depend on A. Then task D depends on B and C, which in turn depend on A.

Dependency graph example

What the algorithm does, instead of traversing the graph recursively, is iteratively finding and removing from the graph all nodes that have no dependencies – that is, no arrows coming out of them. In our example, the first iteration removes node A, the second iteration removes nodes B and C, and the last iteration removes node D. And these are precisely the three batches of tasks that can run concurrently – first task A runs, on completion tasks B and C can run in parallel, and once both are finished task D can be started.

If at some point there are still nodes in the graph but we can’t find any nodes without dependencies, that means we have a circular dependency.

Circular dependency graph example

Here’s an example of solving a larger graph, and detecting a circular dependency:

        $ ./example-dependencies.py
        A working dependency graph example:
        c -> a
        e -> c
        e -> d
        d -> b
        g -> e
        g -> f
        f -> a
        f -> b
        i -> a
        h -> g
        j -> b

        Batches:
        b, a
        i, d, c, f, j
        e
        g
        h

        A broken dependency graph example:
        a -> i
        c -> a
        e -> c
        e -> d
        d -> b
        g -> e
        g -> f
        f -> a
        f -> b
        i -> a
        h -> g
        j -> b

        Trying to resolve the dependencies will raise an exception:

        Traceback (most recent call last):
          File "example-dependencies.py", line 108, in 
            get_task_batches(nodes)
          File "example-dependencies.py", line 42, in get_task_batches
            raise ValueError(msg)
        ValueError: Circular dependencies found!
        a -> i
        c -> a
        e -> c
        g -> e
        g -> f
        f -> a
        i -> a
        h -> g
        $

Download

example-dependencies.py

Source code

#!/usr/bin/env python

# Dependency resolution example in Python
# By Mario Vilas (mvilas at gmail dot com)

# The graph nodes
class Task(object):
    def __init__(self, name, *depends):
        self.__name    = name
        self.__depends = set(depends)

    @property
    def name(self):
        return self.__name

    @property
    def depends(self):
        return self.__depends

# "Batches" are sets of tasks that can be run together
def get_task_batches(nodes):

    # Build a map of node names to node instances
    name_to_instance = dict( (n.name, n) for n in nodes )

    # Build a map of node names to dependency names
    name_to_deps = dict( (n.name, set(n.depends)) for n in nodes )

    # This is where we'll store the batches
    batches = []

    # While there are dependencies to solve...
    while name_to_deps:

        # Get all nodes with no dependencies
        ready = {name for name, deps in name_to_deps.iteritems() if not deps}

        # If there aren't any, we have a loop in the graph
        if not ready:
            msg  = "Circular dependencies found!\n"
            msg += format_dependencies(name_to_deps)
            raise ValueError(msg)

        # Remove them from the dependency graph
        for name in ready:
            del name_to_deps[name]
        for deps in name_to_deps.itervalues():
            deps.difference_update(ready)

        # Add the batch to the list
        batches.append( {name_to_instance[name] for name in ready} )

    # Return the list of batches
    return batches

# Format a dependency graph for printing
def format_dependencies(name_to_deps):
    msg = []
    for name, deps in name_to_deps.iteritems():
        for parent in deps:
            msg.append("%s -> %s" % (name, parent))
    return "\n".join(msg)

# Create and format a dependency graph for printing
def format_nodes(nodes):
    return format_dependencies(dict( (n.name, n.depends) for n in nodes ))

# The test code
if __name__ == "__main__":

    # An example, working dependency graph
    a = Task("a")
    b = Task("b")
    c = Task("c", "a")
    d = Task("d", "b")
    e = Task("e", "c", "d")
    f = Task("f", "a", "b")
    g = Task("g", "e", "f")
    h = Task("h", "g")
    i = Task("i", "a")
    j = Task("j", "b")
    k = Task("k")
    nodes = (a, b, c, d, e, f, g, h, i, j)

    # Show it on screen
    print "A working dependency graph example:"
    print format_nodes(nodes)
    print

    # Show the batches on screen
    print "Batches:"
    for bundle in get_task_batches(nodes):
        print ", ".join(node.name for node in bundle)
    print

    # An example, *broken* dependency graph
    a = Task("a", "i")
    nodes = (a, b, c, d, e, f, g, h, i, j)

    # Show it on screen
    print "A broken dependency graph example:"
    print format_nodes(nodes)
    print

    # This should raise an exception and show the current state of the graph
    print "Trying to resolve the dependencies will raise an exception:"
    print
    get_task_batches(nodes)

This time my friend Aladdin Gurbanov (@SeTx[X]) and I gave a presentation called “Take a walk on the wild side”, an introduction to the world of e-crime on the Internet. I’ll update this post when the slides and the video are online. They’ll be in Spanish only, sorry! Think of it a chance to practice what you learned in Spanish class.

Update: Unfortunately not all videos are available! A fragment of our talk is available at Ustream.

The organization had a really original gift for the speakers this year: a traditional Albacetean Teja black razor.

In case you missed it, today’s XKCD comic titled Click and Drag is simply amazing! Go check it out first, spend a few hours lost in it, and come back only when you’re done having fun. I’ll wait here.

…

Ok, you’re back. Naturally you’ll want to cheat on it at some point, to make sure you didn’t miss out on any hidden easter eggs! So let’s take a look at the web page.

The easiest route is loading the comic on Google Chrome, or Chromium. Just right click on the image and select “inspect element”. This quickly reveals how the neat trick works.

Taking a peek under the hood…

The “world” is divided into tiles of fixed size, and at all times the page loads the tile you’re currently viewing and the surrounding ones, in order to seamlessly stitch them together when scrolling. The clickable area is a map and the coordinates are used to build the URL to the images, which always follows the same pattern (north, south, and east and west coordinates). Trying out a few numbers reveals the “north” coordinate goes from 1 to 5, the “east” coordinate goes from 1 to 48 and the “west” coordinate goes from 1 to 33. Not all coordinates seem to work around the edges of the world (north 2 west 5 doesn’t work for example) and I couldn’t get south to work with manual tries. I suppose a couple empty images are used for those (one for black and one for white) but I didn’t confirm it.

The first thing I tried was just accesing the parent directory to see if directory indexing was enabled, but no such luck. Instead, I wrote this quick and dirty script in Python to download all images, using urllib to download them and shutil to write them to disk. Missing tiles are simply skipped.

This should be enough to check for easter eggs, but it’d be interesting of someone assembles a big image containing all the tiles. Let me know if you do!

Update 1: I originally missed the east coordinate, so the script was updated to try and bruteforce in all directions 1 to 10 north and south, and 1 to 50 east and west. This means a lot more HTTP requests, so I also added a pause between them as good netizens should.

Update 2: This seems to be the complete list of valid image URLs.

Update 3: A commenter pointed out somebody did assemble the entire world image! Check it out here.

Update 4: @prigazzi on Twitter pointed out this fully navegable map as well, based on Google Maps. Check it out! It’s IMHO the best one yet.

Update 5: The previous link no longer works, but this works pretty much the same way: xkcd-map.rent-a-geek.de

Source code:

#!/usr/bin/env python

from __future__ import with_statement

import time
import os.path
import shutil
import urllib2

def download(filename):
    if not os.path.exists(filename):
        url = "http://imgs.xkcd.com/clickdrag/" + filename
        print url
        try:
            fsrc = urllib2.urlopen(url)
            with open(filename, "wb") as fdst:
                shutil.copyfileobj(fsrc, fdst)
            print "=>", filename
        except urllib2.HTTPError, e:
            print "=>", "%s: %s" % (e.code, e.msg)
        print
        time.sleep(1)

for north in xrange(1, 50):
    for west in xrange(1, 50):
        filename = "%dn%dw.png" % (north, west)
        download(filename)
    for east in xrange(1, 50):
        filename = "%dn%de.png" % (north, east)
        download(filename)
for south in xrange(1, 50):
    for west in xrange(1, 50):
        filename = "%ds%dw.png" % (south, west)
        download(filename)
    for east in xrange(1, 50):
        filename = "%ds%de.png" % (south, east)
        download(filename)

Enjoy!

Edited 6-May-2013: updated Impacket to version 0.9.10

Download Impacket 0.9.10

impacket-0.9.10.win32.msi

impacket-0.9.10.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

Download Pcapy 0.10.4

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

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

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

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

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

Download Pcapy 0.10.3

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

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

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

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

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

Download Pcapy 0.10.2

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

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

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

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

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

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…

IDA Toolbag: “How many of you use IDA? And how many of you like it?”

I can assure you there were much fewer hands raised for the second question.

This talk was about a new tool called “IDA Toolbag“, by Aaron Portnoy and Brandon Edwards. In a nutshell, it’s a combination of a lot of ideas that were already present but not quite integrated before: a collaboration plugin, path finding and process stalking, plus some improvements on the code searching, all tied together and with (finally!) a properly designed GUI. The authors understandably put a lot more emphasis on the collaboration features of the plugin, which are much more advanced than any other public plugin that I know of, and I have to say it seems quite powerful.

However what drew my attention the most was the care they took in thinking of usability from step one and modeling the GUI after common reversing tasks with IDA. Most hackers seem to believe usability and graphic interfases in general are not important at all, if not downright useless. But you know, consoles with green letters are cool and all (I’m looking at you, Pancake ) but the fact is, the more time you spend mastering the use of a tool, the more time could have been spent on actually using the tool.

Properly designed GUIs may not give you “h4xx0r cred” but they help you work faster, thinking more about the problems you want to solve and less about how to use the tools to solve them. And for one, I’m happy to see when a reversing tool doesn’t get in the way of your reversing.

Ok, I’ll stop my rant now, don’t worry. Back on the tool. Basically you use it like this: after opening or creating the IDB, load the plugin by running the Python command “import toolbag”. This causes a parallel database to be created and stored embedded into a new section of the binary in the IDB file. It’s done like this due to some limitations on the IDA API to store arbitrary data in the IDB. The biggest advantage of this is since the plugin is using SQLite underneath you can simply query this new database using SQL queries or from Python code.

The plugin also adds a new detachable window with some tabs inside, each tab provides a piece of the plugin functionality. There are enhancements to the IDA code search and a new improved mini graph window. Most notably the viewing history is now kept in a tree rather than the usual “breadcrumbs” pattern used by IDA, making it impossible to get lost when examining the code. Makes sense: the breadcrumbs pattern is suitable for linear tasks, and when you’re examining a disassembled binary you never do it linearly – what you really do is traverse the call graph, following code or data references.

Inside this new database there’s a virtual filesystem. Pretty much everything you do can be stored as files here, and sent to other people through the network. That’s very useful for collaboration – you can send your source code comments, viewing history, etc. to other people so they can import it into their own IDB files. This importing/exporting process can be quite selective, so you don’t run into the risk of overwriting your own changes with someone else’s, and you don’t share more than you wanted to.

A caveat I see right now is the fact that the plugin uses the pickle module to marshall data. Although it’s wrapped with a custom marshalling module to prevent attacks, and the GUI shows you what it is you’re about to unmarshall, just in case I still wouldn’t accept collaboration data from strangers. (Then again I wouldn’t accept IDB files from strangers either!). The authors also warn you about the security implications of this. Bad stuff may also happen if the binary you’re analyzing already contains the magic extra section where the database is stored – but if you’re blindly opening malware with IDA without checking for this kind of stuff you kinda deserve to be pwned, I guess. In any case the magic section name is configurable, just pick something nobody else would guess and you’re safe. One more thing: the network queues are not encrypted, so always use a VPN.

The plugin also allows remote debugging using Kenshoto’s VTrace. The marshalling module described above is also used to send Python code to a listener process, so this feature is more generic than it may seem at first. You can code your own custom modules to be executed remotely, do your stuff asynchronously, collect information and incorporate it to the local database. I can think of a lot of uses for this and I’m sure you do too.

Another thing I liked is how customizable everything is. Pretty much everything is configurable by editing the config.py file. All of IDA’s functionality can be replaced with a custom wrapper so it may be used outside of IDA. And I haven’t checked yet but I guess VTrace could also be replaced with PyDbg, WinAppDbg or PyKd should the need arise.

the slides for this talk are not yet available, but the documentation in the webpage is pretty extensive and the video is online here: http://www.ustream.tv/recorded/21835515

Turning weird Windows kernel bugs into easy exploits

In this talk Cesar Cerrudo showed three quite useful tricks to exploit vulnerabilities in kernel land on Windows. The twist is these tricks allow you to take vulnerabilities that are tipically seen as very difficult to exploit, and turn them quickly into weaponized exploits without even needing to run kernel land shellcode.

The key idea here is that we often think of running shellcode as the goal, when it’s only a means to an end. The real end in privilege escalation exploits is to, well, escalate privileges. So if it’s possible to do so without arbitrary code execution, all the better! This basic idea is also present in Gera’s Insecure Programming challenges and the Shellcoder’s Handbook chapter on alternative payloads.

In this case, the focus is on manipulating the process tokens to gain system privileges. This allows for very quick and stable local exploits with no kernel payload. In order to obtain the memory addresses of various kernel structures, we have a handy undocumented API call in ntdll.dll called NtQuerySystemInformation() that returns, among other information, the kernel pointer to the structures associated with the given handle value. By passing it a process handle we can obtain the pointer to the KPROCESS structure, and knowing the exact Windows version we can find the pointer to the primary token. This is based on @j00ru‘s call gate exploitation paper: call_gate_exploitation.pdf.

Armed with this knowledge, we have three useful tricks we can play. The simplest is to just write a NULL pointer in SecurityDescriptor field of the structure. This effectively removes all ACLs from the handle, and now we can do whatever we want with it. With this we can exploit any vulnerability that allows us to write a NULL pointer in an attacker controlled address.

The second trick then is to manipulate the tokens themselves to add more privileges. In Windows Vista and above tokens are represented by a _TOKEN structure with three UINT64 fields called “Present”, “Enabled” and “EnabledByDefault”. Each field contains a bitmask of privileges. Interestingly, we only need to set the corresponding bit in the “Enabled” field to effectively acquire a privilege. So if our vuln allows us to write arbitrary values we can simply write all 1′s here… but what if we have something trickier, like DEC instruction pointing to a user controlled address? What Cesar proposes is this: disable all your privileges using the Win32 APIs except for the one that corresponds to the highest bit of the bitmask (which happened to be a pretty harmless privilege that came by default, called “SeChangeNotifyPrivilege”). When you trigger the bug and decrement this value, the result will have all bits set BUT the highest one – so you gained all privileges but one. (If you have an INC instruction instead, your only choice will be to read your current privileges using the Win32 APIs to find out the value of this field, and trigger the bug multiple times to increment the value to the one you need).

Before Vista things were different, though. What you have instead is a pointer to a list of tokens identified by numeric values (the _LUID_AND_ATTRIBUTES structure). The trick here is to get the address of the process primary token instead (using the NtQuerySystemInformation() API again) and modify this numeric values to match other, more interesting privileges. For example with a DEC you can change privilege 0×15 (I don’t recall what that was, but it came by default) into 0×14 (the debug privilege) to be able to debug any process you want. From then you can just inject your userland shellcode into any privileged process (LSASS.EXE to grab all the passwords, for example).

And finally the last technique requires a vulnerability that can write an attacker controlled value into an attacker controlled address. The idea here is to copy a the System user’s identity token into the process primary token to escalate privileges. This token can’t be obtained directly though. In order to get it, Cesar hooked the NtOpenThreadToken() function and called MsiInstallProduct(). Any other API that uses the System identity token will do, this is just the one he used for the demo. Once you have the token handle you have to duplicate it (ntdll closes the handle when it’s done with it). Then you can call NtQuerySystemInformation() as usual to get the pointer to it. One important detail: to prevent the reference counter from going haywire, make sure to duplicate this handle a couple times in some other process that never dies (like our old friend LSASS.EXE).

NFC credit cards: “We haven’t broken any security or tried to, because there is none!”

The talk on NFC credit card security by Renaud Lifchitz was both surprisingly simple and scary.

It turns out contactless credit cards just spit out all their info on the radio waves in plaintext to whoever wants to listen, and the closest thing to a “protection” is the required physical distance to receive the signal (3cm to 5cm). And using the proper equipment it can be boosted to 1.5m for active reading and 15m for passive sniffing, so much for THAT.

The stupidest thing about it is the standard for contactless cards was made by the same credit card companies that sponsor PCI… but the cards themselves are a far cry from being PCI compliant. But don’t worry, because the vendors say the NFC cards use “highly secure dynamic cryptograms”… EPIC FAIL!

In conclusion: don’t get yourself an NFC credit card. Hell, don’t get a credit card at all if you ask me! But if you absolutely must have one, get yourself an RFID wallet to carry it.

The slides can be downloaded from here: HES-2012-rlifchitz-contactless-payments-insecurity.pdf. There’s also a Google Code project with the command line tool shown during the talk.

Android exploitation: pwning the heap like it’s 1999

This talk by Georg Wicherski was about Webkit exploitation. To sum it up, instead of exploiting the libc heap implementation you can target another allocator called RenderArena, built on top of the libc allocator, that can only allocate RenderObject objects. The advantage of this is that the RenderArena allocator is extremely predictable, and RenderObject objects have a vtable that get overwritten with the pointer to the next heap block on double frees. This talk gives two exploitation techniques (dubbed “The Wicherski” and “The Refined Aubizziere”) specific to the RenderArena allocator for use-after-free and type confusion bugs in Webkit. I won’t go into the details because the slides explain all this better than me but here are a few selected slides, to give the general idea:

You can download the slides from here: HES2012-gwicherski-exploiting-a-coalmine.pdf

Social engineering: “Advertising and religion are forms of social engineering too”

I’m usually quite partial to technical talks, especially when they’re about exploitation. But I still liked this one a lot. Matias Brutti painted a good picture of what the real social engineering practice is during a pentest, and did so with plenty of humor (giving religion as an example of pre-technology social engineering cracked me up) and with none of the self-important bullshit that usually plagues this topic. There was also no NLP nonsense at all, I liked that too.

He also gave some practical examples of ruses that can be used to lure unsuspecting vict… ahem, I mean targets of your pentest to open a backdoored Office document. My favorite was the following: create a fake Excel spreadsheet with the salaries of all the bosses in the company, then send a spoofed email to a few non-technical folks complaining about how much does that damn pointy-haired boss earn compared to regular employees. Instant success! You don’t even need to mass mail it, the employees themselves will spread your backdoor much better than you would.

But be careful of what ruse you use. You might be a little too successful and end up pwning people outside the scope of your pentest (or even outside the company entirely!) and that would get you into a lot of trouble. Also make sure the topic of your ruse is something you can show later in your report… sex sells, but it makes you look bad when you have to show it to the CEO. (I once heard of a really nasty example of this. Legend has it some pentesting team once used this PDF file for a social engineering engagement. I’ll leave it to the readers to imagine the consequences! )

The talk ended with a set of free social engineering automation tools written by Matias himself. They help when gathering information for your targets and mass mail them, among other tasks. You can get the source code from Github: https://github.com/FreedomCoder

Autopwn with steroids: how math geeks can improve your pwnage

This talk was about how to mathematically plan a complete network infrastructure pentest from top to bottom, using whatever information is available at the time (target machines involved, software installed on them, vulnerable versions, open ports, etc.). The algorithm can also accept input during the execution of the plan and correct it to incorporate the new information, and the math is also backed by statistical information gathered from over 700 machines with different combinations of operating systems, hardware, etc.

I’m sure Carlos Sarraute gave a superb talk a usual, he really knows his stuff and already published some previous work on the same topic. But… unfortunately I arrived late so he was already past the introduction and knee-deep into the heavy math behind his work. (Suffice to say it involved statistics in four dimensional metaplanes to understand why I gave up almost instantly. I felt back in college, folks!)

Sorry to disappoint you all! I’m sure I can get him to explain it to me while drinking some beers another day…

The slides are not yet available, but in the meantime you can read Carlos’ related past works a the Core Security website.

Detecting crypto: that awkward moment when a typo in Wikipedia ruins your TEA

Joan Calvet presents a proof-of-concept tool to automatically detect crypto code in malware and identify the algorithm being used. The task is divided in three parts: the first is detecting the cryptographic functions by analyzing an execution trace of the binary, the second is to find the inputs and outputs of said code during the execution, and the third is to detect the algorithm being used.

The first part is possibly the hardest. Some shortcuts are taken to make it easier: a potential crypto function consists of one or more chained loops, for a particular definition of “loop”. This allows for a quick and easy detection method that works in many cases, but of course not in all. In particular, state machines are discarded as potential crypto code. However, unrolled loops are successfully detected, because the tool compares the instructions being executed rather than the memory addresses where they happen to be. I’m not sure what would happen if loops were transformed into recursive function calls, but most malware authors won’t alter crypto code much anyway (more on that later).

The second part is about determining what are the inputs and outputs. In principle this is easier since all it has to do is track memory reads to addresses in areas where no writes happen and visceversa. The tricky part is finding out where the different arguments are. Just taking consecutive memory addresses won’t do, since that’s bound to happen all the time in the stack. The author’s solution is to separate the arguments based on what instructions are used to access them.

The third part is the simplest: the tool has reference implementations of all the supported algorithms, and they are all tested in all possible combinations of parameters. This brute force solution works well even for algorithms like AES, provided you consider the S-boxes as part of the input. This is also the part I find severely lacking: it’s trivial to alter the crypto algorithm to defeat this. A simple XOR against a hardcoded constant will change the output enough so you can’t find it by comparing against the reference implementation, and you won’t lose any of its security. Joan seemed quite aware of this, and even showed a funny example on how it can fail.

He was testing the tool against some malware samples that were supposed to be using TEA. The tool failed, and manual analysis revealed the algorithm was TEA alright… but on closer inspection there was a subtle difference of implementation: a pair of parenthesis was misplaced in the original source code! The strangest part was this exact same bug was present in other malware families as well. After some googling, the mistery was solved. All of these bugged malwares came from Russia, and the Russian version of Wikipedia contained a faulty reference implementation, that was copied and pasted into the malware code. To me, that says a lot on how malware is developed… and it also teaches to distrust code randomly found on the Internet. Maybe I’m being paranoid, but… who’s to say the bug wasn’t intentional?

…And thanks for all the fish!

There were a lot more talks I’m completely and unfairly skipping here: Travis Goodspeed’s talk on pwning radio devices, Daniel Mende and Enno Rey messing with Cisco VoIP phones, Ralf Philipp Weinmann’s on baseband reverse engineering, just to name a few. The level of all the talks was excellent but I’ve really spent a lot more time on this blog post than I originally intended plus I’m not confident enough with some topics to be talking about them, so I’ll leave it to you all to go to the HES website and read the slides. You can also check out the videos at ustream.

Many thanks as well to Phillipe Langlois, Jonathan Brossard, Malard Arnaud, Matthieu Suiche and the rest of the team, you guys really know how to throw a geek party!

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

I’ve packaged the BeaEngine Disassembler along with its Python bindings into a no-frills Windows installer. Certainly easier than manual install, and it really helps me when installing it on virtual machines.

Enjoy!

Update: Just added another disassembler package, Pymsasid.

Update: Added precompiled Windows binaries for PyDasm on Python 2.6 and 2.7.

Update: My installers were added to the Python Arsenal for RE.

Update: The Pymsasid package was updated with a small change, so the importation works just the same as loading the .py files from the current directory (it’s just an “import *” in __init__.py)

Update: Added a simple setup script for Libdisassemble 2.0. Since I had to put the sources inside a package the import statement in your scripts will have to be adjusted if using this version. With a simple try/except block you can make scripts compatible with both versions as well, if you need to.

Downloads

BeaEngine win32 installer: BeaEnginePython-3.1.0.win32.exe

BeaEngine win64 installer: BeaEnginePython-3.1.0.win-amd64.exe

BeaEngine source installer: BeaEnginePython-3.1.0.zip (run “python setup.py install”)

Libdisassemble 2.0 win32 installer: libdisassemble-2.0.win32.msi

Libdisassemble 2.0 win64 installer: libdisassemble-2.0.win-amd64.msi

Libdisassemble 2.0 source installer: libdisassemble-2.0.zip (run “python setup.py install”)

PyDasm precompiled binaries: PyDasm-1.5-precompiled.zip (run “python setup.py install”)

Pymsasid source installer: pymsasid-0.3.1.zip (run “python setup.py install”)

In case you missed it, Aníbal Sacco released a new tool called Heappie! to analyze heap sprays in multiple platforms. It uses PyGame and PythonCard for the GUI and Kenshoto’s VTrace as the backend. It’s really cool, check it out

Now, I never get tired of saying how great VTrace is. It’s written in Python, supports multiple platforms and quite comfortable to develop with. But alas, I tend to prefer my own debugger (call me biased if you wish!). So today I went ahead and added WinAppDbg support to Heappie!. When WinAppDbg is installed, it’s chosen automatically as the backend. If not found, it falls back to VTrace. That way we don’t lose support for other platforms, since WinAppDbg naturally only works on Windows.

This patch also adds support for 64 bit versions of Windows, in case you were thinking this was just an exercise in self indulgence. Well, it is that, but not just that. Ahem.

TL;DR

Just download the file above, go to Aníbal’s blog to learn how to use it, and exploit all the bugs!

Download

Heappie-WinAppDbg.zip

Funny thing is, my old script was still working! Apparently the folks at Pastebin have left the legacy API still running. The old documentation is gone though, and now even to read the updated documentation you need to log in…

Now, this takes care of the API key problem, but there’s still the issue of Pastebin seeing your IP address. An HTTP proxy can fix that… provided you trust that proxy not to store your IP somewhere in the logs. The procedure is simple, just set the HTTP_PROXY environment variable to wherever your proxy is, and voilà! The standard Python module urllib will automatically connect through the proxy.

If you don’t have a trusty HTTP proxy, the best way to go is through the Tor network. You’ll need to install the Tor service itself and the Privoxy HTTP proxy in your machine, then set the HTTP_PROXY variable to 127.0.0.1:8123. This document from the Tor Project explains it in detail.

Once you’ve set up your proxy, download pastebin.py and send a file to Pastebin like this:

    $ python pastebin.py manifesto.txt
    manifesto.txt --> http://pastebin.com/ixSetT5f

The script accepts multiple filenames as well. You can also set the syntax highlighting format (useful for source code, config files or logs) as follows:

    python pastebin.py --format=apache /var/log/apache2/access.log /var/log/apache2/error.log

And set an expiration time, after which it gets automatically deleted. In the following example a SQL dump is uploaded and automatically deleted the next day:

    python pastebin.py dump.sql --format=sql --expire=1D

So, that’s pretty much it. There’s a limit of 512Kb per file uploaded, in order to bypass this you’ll have to split the file into multiple pieces (something similar to this but using pastes instead of URLs). I may do it another day, but for now it’s left as an exercise to the reader.

There’s one thing I don’t quite understand: why did the Pastebin folks think it was necessary to have a mandatory API key? Even if the legacy API had been shut down, it would still be possible to figure out how the web page was doing it and replicate it in Python. The API key being linked to the user account seems a bit strange too… Their intention might be to catch script kiddies uploading illegal stuff, but it may also be an attempt to do data mining on people’s posts. Who knows…

Download

pastebin.py