Breaking Code

February 10, 2010

New remote authentication vulnerability in Windows

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

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


Whoa. That’s kind of scary.

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

Below is the complete text of the advisory, except for the source code to the scripts, which were removed for brevity. The original advisory can be downloaded from:

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



January 18, 2010

Converting shellcode to executable files using InlineEgg

Filed under: Tools — Tags: , , , , , — Mario Vilas @ 7:42 pm

Today I found this through Twitter: a web service to convert shellcode to executable files. Here’s the link to it:

Then I thought: hey, why do we have to send our beautiful shellcodes to someone else on the Internet when we can do it all locally? 🙂

So I whipped up this quick Python script using CORE’s InlineEgg package. It was coded in a few minutes so don’t blame me if it’s got bugs 😉 instead let me know about it and I’ll try to fix it.

Enjoy! 🙂


  • Anand Sastry has tweaked the script to accept not only shellcode in binary form, but also shellcode encoded as a ‘\x’ ASCII string. Check it out!
  • Moved the source code to Github


Source code


January 14, 2010

Having fun with URL shorteners, part 2: parasitic storage

Filed under: Tools, Web applications — Tags: , , — Mario Vilas @ 5:50 am

In my previous post I briefly mentioned a rather creative use for URL shorteners: to store the contents of arbitrary files (a.k.a. “parasitic storage”). There was previous work on this area, namely a tool called TinyDisk that could implement a rudimentary filesystem on top of the TinyURL service. The bad news is, the site that hosted the tool appears to be down and I couldn’t get to play with it. 😦


After a deep, thorough investigation (read: 30 seconds of googling) I came to the conclusion that no source code sample was available to do this. Naturally, the solution was to roll my own! 😀 It’s a crude proof-of-concept but it works. My first idea was to break up the file to be uploaded into small chunks that could fit the maximum length allowed in an URL, then ask TinyURL to shorten each of them, and keep the shortened URLs to be able to download the file later.

I started to test the tolerance of the TinyURL API and found three interesting things. One, that I wouldn’t even need to disguise the data as valid URLs, because TinyURL makes no validation of any kind – all I had to do was make sure the data was encoded in a way that wouldn’t break the HTTP requests. I chose to use hex encoding, but I’m sure there are more efficient encodings that would do the job nicely. Two, I could send obscenely large URLs. Sending 256 Kb of POST data worked like a charm so I chose that for the chunk size. The next power of two (512 Kb) caused the TinyURL server to drop the connection without a reply but I haven’t determined if this was really a limitation in their server or in my Squid proxy – in any case I thought it was a good idea to leave it at that. The third thing I noticed was that after a while of sending repeated requests the TinyURL service would stop responding for a while, I guess this is a protection against spammers. Quite understandable given the fact that this API is anonymous and doesn’t require an API key like many other services. The solution is to wait a little while when this happens before making any more HTTP requests.

Now the problem is how to get the data back. A simple GET request won’t work behind proxies, because TinyURL blindly returns our data in a Location: header and predictably my Squid refused to parse it when I tried. The solution I found was the preview feature. Changing the into returns a webpage that contains the target URL – then we can parse the HTML to get the data back. It’s actually easier this way, because urllib2 tries to follow redirections by default and that would have called for some hacks on our part. Downloading the preview page is painless, but it also introduces more overhead (a 256 Kb block produces a preview page of a approx. 1 Mb).

That’s pretty much it… when we upload a file we break it into 256K blocks and send it to the TinyURL servers, then we store each returned short URL in a text file. Since all shortened URLs begin the same way ( we only need to store the code after the slash. The we download each block by asking for the preview page for each URL and extracting the data from the HTML page.


January 11, 2010

Having fun with URL shorteners

Filed under: Tools, Web applications — Tags: , , , , — Mario Vilas @ 2:14 am

I’ve taken some interest in URL shorteners recently. URL shorteners are the latest fad in web services – everybody wants to have their own, even if it’s not yet entirely clear how to profit from it, at least not for us mere mortals. They were born out of Twitter users need to compress their microblogging posts (some links are actually longer than 160 characters, believe it or not) and it’s spread everywhere on the Internet. Major web sites like Facebook, Google and Youtube are into it and -some say- it’s one step closer to destroying the Web as we know it.

Of course, this can also be used for evil purposes. 🙂

So I made myself a Python module to toy with these things. It can be used as a command line tool as well as a module to be imported in projects of your own, and contains no non-standard dependencies. You can download it from here:

For example, this is how you convert a long URL into a short one (the shortest possible choice is automatically selected):

    $ ./

And it’s reverse, converting that short URL back into the long one:

    $ ./ -l

You can also choose a specific URL shortener service. Let’s try Twitter’s new favorite,

    $ ./ -u

Now, the fun stuff 🙂 what would happen if we try to shorten, say, a javascript: link? We can find out with the -t switch (output edited for brevity):

    $ python -t "javascript:alert('Pwn3d');"
    RuntimeError: No data returned by URL shortener API
    RuntimeError: <h3>URL has wrong format! Forgot 'http://'?</h3>
            Short [1]:
            Long  [0]: http://javascript:alert('Pwn3d');
            Short [1]:
            Long  [0]: javascript:alert('Pwn3d');
            Short [1]:
            Long  [0]: http://xrl.usjavascript:alert('Pwn3d');

Most services either report an error condition or simply don’t return anything at all. Two services return a garbage response ( and But to my surprise TinyURL, the second largest URL shortener service is vulnerable to this! True, this is probably not news to many of you, and blocking this kind of links doesn’t provide that much of an advantage (clicking on a link with an unknown target is pretty much game over anyway) but I still fail to see the reason to support it in the first place. I can’t think of any legitimate reasons to shorten a javascript link.

Example of TinyURL's poor handling of javascript links

As a matter of fact, TinyURL seems to accept anything you send it, may it look like a valid URL or not. This has lead some people to build a rogue filesystem called TinyDisk, world readable, yet very hard (if not impossible) to trace back to it’s creator. The download link seems to be down but the Slashdot article is still there. I also found this article explaining how such a filesystem would work.

Back on the matter, the way people react to URL shorteners make them perfect for an attacker to hide the true target of his/her exploits, or bypass spam filters as it’s being done in the wild for quite some time now. There are some countermeasures. Many URL shorteners (including TinyURL) have a preview feature to let you examine the URL target before going there (for example, shows the sample javascript code we used above). The Echofon plugin for Firefox is a Twitter client that makes heavy use of URL shorteners, and among other things it automatically expands short URLs when the mouse hovers over them. The service offers URL expansion as well, both from the web and as a Firefox plugin.

But… how well do they behave when you shorten the URL multiple times? First, let’s try shortening a link with TinyURL three successive times:

    $ ./ -c 3 -u

The preview feature only seems to work for the first redirection (see for yourself). Now let’s try shortening our example URL three times, using random providers:

    $ ./ -v -c 3

I found the Echofon plugin fails to expand this short URL. However the service works like a charm – it even told me how many redirections I used! Click here to see it for yourself.

Example of Echofon expanding a short URL

Just for fun, how about an infinite recursion? First, we create a link to a shortened URL that doesn’t yet exist.

    $ python -v -c 5

Now let’s go to the TinyURL webpage and create the link manually. Voila! We have an infinite redirection. The service seems to break now (see for yourself) but this is of no consequence – the link doesn’t really take you anywhere. Other apps like wget get stuck in an infinite loop however. This is probably of no real use to an attacker but I thought it was fun to try it out. 🙂

As a final note: while writing this I came across this article describing even more risks inherent to URL shorteners: information disclosure. A dedicated attacker could dump randomly chosen shortened URLs to retrieve information like corporate intranet links, user IDs and even passwords. I liked the idea, so I whipped out a small script to test it out:

    from random import randint
    from shorturl import longurl, is_short_url

    characters = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
    while 1:
        token = ''.join([ characters[ randint(0, len(characters) - 1) ] for i in xrange(6) ])
            url = longurl('' % token)
        except Exception:
            print token
        if not is_short_url(url):
            print "%s => %s" % (token, url)

But the results of bruceforcing didn’t seem so great. Then again, one could also wonder how random this short URLs really are… maybe there’s a way to predict them, or at least reduce the number of URLs one has to try. One could also try a dictionary based approach for services like, which provide the users the ability to pick custom short URLs. Update: Those TinyURL links weren’t so random after all 😉 here’s an interesting project on URL scraping.

Read Part 2: parasitic storage


Source code

You can get the source code at Github.

December 13, 2009

Reusing Python generator objects

Filed under: Uncategorized — Tags: , — Mario Vilas @ 9:46 pm

Generators are one of those little things that I love about Python. Never heard of generators? Well, this is all much better explained here, but in a nutshell:

    def squares( size ):
        for x in xrange( size ):
            yield x * x

The above code returns a generator object. This object is iterable, and each item is returned by the yield statement. The return statement ends the iteration.

    >>> list( squares( 10 ) )
    [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
    >>> for value in squares( 5 ):
    ...     print value

Now, there’s a little problem I found… I wanted an object than, when iterated, returned a certain sequence of objects. No problem so far. But here’s the catch: once it finished returning the list, I wanted to be able to reuse the generator.

    >>> gen = squares( 5 )
    >>> list( gen )        # Works the first time...
    [0, 1, 4, 9, 16]
    >>> list( gen )        # But not the second!

So I came up with this solution:

    class Regenerator(object):
        Calls a generator and iterates it. When it's finished iterating, the
        generator is called again. This allows you to iterate a generator more
        than once (well, sort of, since the generator is actually recreated).
        def __iter__(self):
            return self
        def __init__(self, g_function, *v_args, **d_args):
            self.__g_function = g_function
            self.__v_args     = v_args
            self.__d_args     = d_args
            self.__g_object   = None
        def next(self):
            if self.__g_object is None:
                self.__g_object = self.__g_function( *self.__v_args, **self.__d_args )
            except StopIteration:
                self.__g_object = None

So, in the example we presented, this is what we’d do to be able to iterate the list of numbers more than once:

    def _squares( size ):
        for x in xrange( size ):
            yield x * x
    def squares( size ):
        return Regenerator( _squares, size )

And alas, it works! 🙂

    >>> gen = squares( 10 )
    >>> list( gen )
    [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
    >>> list( gen )
    [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
    >>> list( gen )
    [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]


August 31, 2009

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

Filed under: Tools — Tags: , , , , , , , , , , — Mario Vilas @ 10:01 pm

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

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

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

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


Python 2.x

Python 3.x

August 5, 2009


Filed under: Undocumented Windows — Tags: , , , , , , — Mario Vilas @ 2:32 am

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

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

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

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

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

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

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

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

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

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


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


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

May 28, 2009

Exegesis – A toolkit for abusing the broken PRNG in Debian OpenSSL

Filed under: Tools — Tags: , , , , , — Mario Vilas @ 9:05 pm

A new tool has just been released to exploit the Debian OpenSSL bug, it’s called Exegesis. It seems very interesing, it’s more complete and flexible than all of the existing ones. Definitely worth checking out!

Let’s see the description from it’s webpage:


So you have an ssh public authentication key and you 'lost' the
private key.  Did you generate that key in the last two years on
Debian or Ubuntu GNU/Lunix?  Yes?  Ok, great.  

$ cat
A== lamer@gnubuntu

First you'll need the fingerprint.

$ ssh-keygen -l -f ./
1024 b2:f0:f6:47:19:64:ff:8e:8f:90:75:bd:57:6c:71:0c ./

Now look for that fingerprint in the generated fingerprint database
files.  You can just use 'grep' for this.

$ grep b2:f0:f6:47:19:64:ff:8e:8f:90:75:bd:57:6c:71:0c dsa_1024_32_le.out
b2:f0:f6:47:19:64:ff:8e:8f:90:75:bd:57:6c:71:0c 25191 dsa 1024 32 0

Oh, it's your lucky day!  You're on the list.

The fingerprint database files have the following format:

  fingerprint pid key_type key_bits arch big_endian

  pid        The process id of the ssh-keygen which originally generated the key
  key_type   Either 'dsa' or 'rsa' depending on the type of key
  key_bits   The size of the key.  1024 and 2048 are common.
  arch       Either 32 or 64 depending on the processor which the key was created on
  big_endian Is 1 if the key was generated on a big endian box or 0 otherwise

So, the key we matched is a 1024 bit DSA key, generated on a 32 bit little endian
processor.  That sounds about right.

$ ./exegesis
Usage: ./exegesis [options]
  -B            Select big endian target (default is little endian target).
  -A            Selecet 64 bit target (default is 32 bit target)
  -o <file>     Output file.
  -t (dsa|rsa)  Type of key(s) to generate (default is rsa)
  -b bits       Key size to generate in bits (default is 1024 bits)
  -g            Generate all keys for a range of pids (all pids by default)
  -r start,end  Specify a pid range to generate (default is 1,32768)
  -p pid        Generate a key for a chosen pid value

$ ./exegesis -t dsa -b 1024 -p 25191

Whoah?! Is that really the private key?  Let's compare it to the
original key generated with ssh-keygen

$ ./exegesis -t dsa -b 1024 -p 25191 > key.out
$ md5sum id_dsa key.out
0aa477a9a01c6724708f9f362bcf0f7d  id_dsa
0aa477a9a01c6724708f9f362bcf0f7d  key.out

Generating Databases

$ ./exegesis -g -t dsa -b 1024 -o dsa_1024_32_le.out

Unlike inferior competing products, Exegesis models the backdoored PRNG
in Debian OpenSSL.  It uses a version of the OpenSSL random number and
key generating code that can be configured to behave like any of the
hardware platforms that affect the generated random numbers.

This means you can generate databases for each different relevant hardware
configuration without actually needing to run it on those architectures.


WARNING: Generating your own databases takes a very long time and may
         cause side effects such as acute boredom and drowsiness.


Since we know you're anxious to get started recovering all those misplaced
private SSH keys, this release of Exegesis conveniently includes, right out
of the box, ten starter databases at no extra charge!

$ md5 keysets/*
MD5 (keysets/dsa_1024_32_be.out) = d422aa60e3d6180ec65adb7179ebe43d
MD5 (keysets/dsa_1024_32_le.out) = d6f1e5f4d5dd9e84a05de47cc9e0e81a
MD5 (keysets/dsa_1024_64_le.out) = 89d34fe52f083c7e0c2297c2d8439bbc
MD5 (keysets/dsa_2048_32_le.out) = b81ca4cd84613c0fa19056036153fc62
MD5 (keysets/dsa_2048_64_le.out) = f914df33f27a11d7b2ab06446c6c13ec
MD5 (keysets/rsa_1024_32_be.out) = f5a13ffcbc63206d1c90850e2ad2e052
MD5 (keysets/rsa_1024_32_le.out) = 082b47d57e1d77366ce3795359926440
MD5 (keysets/rsa_1024_64_le.out) = 18c80767c00db8130da8a77f7e81f448
MD5 (keysets/rsa_2048_32_le.out) = 977b88495603c860abbd48a47847065a
MD5 (keysets/rsa_2048_64_le.out) = dcdd098089281388e1c3bc935dec5b7e


This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (


May 27, 2009

Using diStorm with Python 2.6 and Python 3.x

Filed under: Tools — Tags: , , , , , , , — Mario Vilas @ 12:14 am

diStorm is currently my favorite disassember for Intel platforms. It’s small, fast, compiles virtually anywhere, and it’s got Python bindings for 2.3, 2.4 and 2.5. The only problem so far was trying to use it with Python 2.6 and above – the library has to be recompiled for each new version. To solve this problem a pure Python module using ctypes is shipped – but it’s interface is different from the C module, forcing us to code different routines.

So my solution was to code my own ctypes-based diStorm bindings. It’s compatible with the C version and it works in all Python 2.x versions. The DLL library has to be present in the path for it to work.

I’ve also ported it to Python 3.x. Both versions are tested under Windows only, however it should work correctly under Linux – let me know if you try it!

Here is also an example script using diStorm to disassemble a raw binary file. Could come in handy for example to disassemble the shellcode contained in an exploit, or to find anything that resembles shellcode in a packet capture.



February 6, 2009

Manipulating windows belonging to other processes

Filed under: Tools — Tags: , , , , — Mario Vilas @ 4:51 pm

Hello again. 🙂

Here’s a Python script that can be used to write Windows UI fuzzers and testers. It requires the win32 python extensions that can be downloaded from here (already included in the ActiveState distribution).


Download the code:

« Newer PostsOlder Posts »

Blog at