Breaking Codehttps://breakingcode.wordpress.com
When a meth lab's not an option, get into infosec instead.Sat, 31 Jan 2015 21:52:50 +0000enhourly1http://wordpress.com/https://s2.wp.com/i/buttonw-com.pngBreaking Codehttps://breakingcode.wordpress.com
Heartbleed and ASLR misconceptionshttps://breakingcode.wordpress.com/2014/04/12/heartbleed-and-aslr-misconceptions/
https://breakingcode.wordpress.com/2014/04/12/heartbleed-and-aslr-misconceptions/#commentsSat, 12 Apr 2014 12:13:59 +0000http://breakingcode.wordpress.com/?p=845]]>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.

This is based, I presume, on the following (wrong) assumptions:

ASLR means that every single memory allocation for every single variable in memory is 100% random.

The Heartbleed attack is also completely random, since it reads past the end of a memory buffer that was allocated randomly.

All memory (be it code, static data, stack data or heap data) are mixed up randomly in memory with no grouping of any kind.

The memory space is somehow shared across all processes, except for root processes that can freely access all of the RAM (yes, weird, but the author seems to imply that for some reason!).

If those assumptions were correct then the conclusion would be sound, but unfortunately, they are not. Memory allocation is a little more complicated than that. I’ll try to make a brief description of how memory layout works. There are much smarter people than me out there who have described it better, so if you’re interested in the topic, Google and Duck Duck Go are your friends. ;)

There are many other factual errors in the article, like confusing files with memory, mentioning Perfect Forward Secrecy when it’s not relevant at all, assuming the attack captures passwords from a database instead of from other users requests on transit, and so on. In fact, there are so many errors I suspect the author may just be pulling a prank on gullible readers! Still, let’s try to make things clearer. :)

We must begin by making the distinction between memory space and memory addresses. Memory space is contiguous and shared for the entire machine, since there is only one RAM. However, the RAM is not accessed directly by user programs, but through the use of memory addresses that are assigned by the operating system. This mechanism is what prevents one program from directly accessing the memory of another program – each one is assigned a set of memory addresses, which maps to wherever the OS wants in RAM. It’s not user permissions or configuration that prevents it then, or whether the program is running as root or not, but simply that the same memory address for two different programs are mapped to different places in RAM. (There is an exception to this in which the OS can create shared memory between one or more programs, by mapping addresses to the same place in RAM, but it’s a special mechanism in which both programs cooperate to share a piece of memory and it’s not relevant to the Heartbleed bug). So whether the services that have the bug are running as root or not is not important at all, what’s important is what kind of information do these services have in their own memory.

The next thing we need to know is how memory allocation works. From the perspective of a high level language, like Python or Ruby, memory is a kind of magic: you just start using a new variable and it’s simply there, no questions asked. :) That’s because such languages have mechanisms in place to shield the programmer from knowing how memory allocation actually works. More often than not, programmers who have never played with low level languages have some interesting misconceptions about it…

In reality, memory is allocated in pages, where each page is 4096 bytes long (could be a different size for non-Intel architectures, or in some other circumstances, but let’s pretend it’s always that size). In order to create new variables, you need some memory to hold their values, so the program needs to request this memory to the operating system. This is where the ASLR feature takes place: in older operating systems like, say, Windows NT, the new pages were assigned memory addresses in a sequential way, so it was easy to predict where data was. But in newer operating systems each page is given a random memory address.

…well, not exactly. If you request the operating system for a larger area than just 4096 bytes, you need those bytes to have contiguous memory addresses, or you wouldn’t know how to access them. So the only thing that’s random is the address of the first byte of contiguous memory you request. Also, it can’t be 100% random: since all pages are 4096 bytes in size, and you can only request a whole number of pages, it stands to reason that these random memory addresses will always be aligned to 4096 bytes. In fact, for efficiency reasons and depending on the operating system, they may even be aligned to larger numbers like 64 kilobytes. Still random, but not SO random. And that’s not the end of it.

See, 4096 bytes is an awful lot of space. You can’t just request a new page from the OS every time you need room for a single variable, which may only be a handful of bytes long. So what programs do is place variables inside two structures called stack and heap. What they do is request memory in pages, use the room to store many variables in them, and track down which variable is stored where in order to know which bytes in each page are available for new variables to be put in. As more and more variables are created, the stack and heap begin requesting new pages – and as variables are destroyed, the memory space they live in is marked as free to be reused by newly created variables.

The stack is used when creating variables that live in the scope of a function call, that’s why it’s called a stack: when you call another function, the local variables for it are stacked on top of the previous function. And when the function returns, its local variables are removed from the top of the stack, leaving their memory space free for the next call. All stack space is, by force, contiguous, at least for a single thread (each thread gets its own separate stack). Therefore, while the base memory address of the stack is random thanks to ASLR, the relative locations of variables within it are not – they are deterministic! They will depend on the order in which functions are called and how many local variables each one has. If you have a bug that lets you access memory past a stack variable, you’ll be accessing other variables in the stack without problems, despite of ASLR.

The heap, on the other hand, is for variables that can live outside the scope of a single function call. When you create a new variable with the new() operator in C++, or when you call the malloc() function in C, what the program is really doing is grabbing some available bytes from one of the pages of the heap and marking it as used by that variable. When you destroy that variable by calling free() in C or delete() in C++, you’re marking that space as free so other variables can use it. It follows then, that ASLR doesn’t help you all that much here either: even though the pages of the heap are more or less random (since they don’t all have to be contiguous as it happens with the stack) the variables stored in it are still grouped together. This mechanism is also deterministic, but since a server may have multiple users doing things at any given time, the pattern of memory use will depend on lots of factors you don’t know (user activity, basically), so the exact memory layout is hard to predict. Still, variables are being grouped together, and they won’t likely be nearby anything else like executable code or static data, which is not allocated in the heap nor the stack. So if you can read memory past the end of a variable, you’re likely to read data from other nearby variables, quite possibly related to what the vulnerable code was doing (in this case, decrypting SSL traffic from users).

In conclusion: while it’s always healthy not to panic:) and the Internet has definitely seen worse bugs time and again, let’s not get carried away: if you used any service that contained the bug, you should be changing your passwords just to be on the safe side.

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.

Filed under: Programming, Tools Tagged: ctypes, debugger, fuzzer, LinkedIn, open source, python, reverse engineering, tool, vulnerability research, win32, WinAppDbg, Windows]]>https://breakingcode.wordpress.com/2013/12/20/winappdbg-1-5-is-out/feed/0mvilasA Python example on finding connected components in a graphhttps://breakingcode.wordpress.com/2013/04/08/finding-connected-components-in-a-graph/
https://breakingcode.wordpress.com/2013/04/08/finding-connected-components-in-a-graph/#commentsMon, 08 Apr 2013 21:30:26 +0000http://breakingcode.wordpress.com/?p=778]]>Today I’ve been coding a solution for a problem we’ve encountered with @ggdaniel (cr0hn) during the development of GoLismero 2.0. It called for an implementation of an algorithm to find connected components in an undirected graph. You can find the source code at the bottom of this post.

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

#!/usr/bin/env python# Finding connected components in a bidirectional graph.# By Mario Vilas (mvilas at gmail dot com)# The graph nodes.classData(object):
def__init__(self, name):
self.__name = name
self.__links =set()
@propertydefname(self):
returnself.__name
@propertydeflinks(self):
returnset(self.__links)
defadd_link(self, other):
self.__links.add(other)
other.__links.add(self)
# The function to look for connected components.defconnected_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 =1for 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

Filed under: Programming Tagged: algorithms, LinkedIn, python]]>https://breakingcode.wordpress.com/2013/04/08/finding-connected-components-in-a-graph/feed/3mvilasExample graph with three connected components. Image from Wikipedia.connected-components-1connected-components-2connected-components-3An example dependency resolution algorithm in Pythonhttps://breakingcode.wordpress.com/2013/03/11/an-example-dependency-resolution-algorithm-in-python/
https://breakingcode.wordpress.com/2013/03/11/an-example-dependency-resolution-algorithm-in-python/#commentsMon, 11 Mar 2013 13:36:12 +0000http://breakingcode.wordpress.com/?p=754]]>I’ve been toying with dependency resolution a bit today, since it’s one of the features we plan to add to GoLismero 2.0 plugins with @ggdaniel (cr0hn). So I came up with this short example that’s reasonably fast and doesn’t use recursion at all, unlike many of the examples that I found on the net.

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:

Filed under: Programming Tagged: algorithms, LinkedIn, python]]>https://breakingcode.wordpress.com/2013/03/11/an-example-dependency-resolution-algorithm-in-python/feed/2mvilasDependency graph exampleCircular dependency graph exampleNavaja Negra (Black Razor) Conferencehttps://breakingcode.wordpress.com/2012/12/02/black-razor/
https://breakingcode.wordpress.com/2012/12/02/black-razor/#commentsSun, 02 Dec 2012 17:39:05 +0000http://breakingcode.wordpress.com/?p=725]]>Just came back today from the Navaja Negra (Black Razor) Conference in Albacete, Spain. Had a great time there, seen lots of old and new faces (they literally filled the room!) and after the talks had a taste of the Albacete nightlife, and a fantastic dinner where I left my mobile phone on the table unattended, and my fellow speakers kindly reminded me in a polite and civilized manner of the importance of locking one’s phone.

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. There’s also a summary of the conference (in Spanish) at the MADESYP Academy blog.

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

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.

Filed under: Just for fun Tagged: LinkedIn, python, web]]>https://breakingcode.wordpress.com/2012/09/19/quickpost-cheating-on-xkcd/feed/7mvilasclick-and-drag-how-it-works[Quickpost] Updated Impacket/Pcapy installers for Python 2.5, 2.6 & 2.7https://breakingcode.wordpress.com/2012/07/16/quickpost-updated-impacketpcapy-installers-for-python-2-5-2-6-2-7/
https://breakingcode.wordpress.com/2012/07/16/quickpost-updated-impacketpcapy-installers-for-python-2-5-2-6-2-7/#commentsMon, 16 Jul 2012 15:10:51 +0000http://breakingcode.wordpress.com/?p=678]]>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.10Edited 18-Feb-2014: updated Impacket to version 0.9.11

Filed under: Tools Tagged: fuzzer, LinkedIn, network, open source, python, recon, reverse engineering, SMB, sniffer, tool, vulnerability research, Windows]]>https://breakingcode.wordpress.com/2012/07/16/quickpost-updated-impacketpcapy-installers-for-python-2-5-2-6-2-7/feed/10mvilasHackito Ergo Sum 2012https://breakingcode.wordpress.com/2012/04/20/hackito-ergo-sum-2012/
https://breakingcode.wordpress.com/2012/04/20/hackito-ergo-sum-2012/#commentsFri, 20 Apr 2012 22:27:19 +0000http://breakingcode.wordpress.com/?p=542]]>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! :roll:

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.

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 0x15 (I don’t recall what that was, but it came by default) into 0x14 (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”… :roll: 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.

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:

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 :D 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! :)

Filed under: Conferences Tagged: conference, credit cards, IDA, LinkedIn, math, PCI, pentest, python, reverse engineering, RFID, social engineering]]>https://breakingcode.wordpress.com/2012/04/20/hackito-ergo-sum-2012/feed/0mvilasUnderground domes. Great for a hacker conference. Or a supervillain secret hideout.Beautiful and deadly, like a flock of laser-armed swans.I also liked to pretend I was inside a spaceship.You gotta take the power back! \m/(*~*)\m/Yo, Dawg! Hackers using pretty windows? No way!Totally heroic pose, envisioning a future where hackers dare to use pretty windows with many colors. Or maybe he was just pointing at the wall. But I like the first explanation better.You can tell I didn't get a good sit for this one. :(Whoever designed this standard must have been drunk, stoned, or both.1234So I was like "yeeeeeeeeah... I need another beer"It came from outer space! No, wait, that's another movie.MSDN Help Plugin for OllyDbg / Immunity Debuggerhttps://breakingcode.wordpress.com/2012/04/09/msdn-help-plugin-for-ollydbg-immunity-debugger/
https://breakingcode.wordpress.com/2012/04/09/msdn-help-plugin-for-ollydbg-immunity-debugger/#commentsMon, 09 Apr 2012 15:49:49 +0000http://breakingcode.wordpress.com/?p=514]]>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. :)

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.