Skip navigation
All Places > Metasploit > Blog > 2006 > March


March 2006 Previous month Next month

Originally Posted by hdm



In October of 2004, Michal Zalewski posted to the Bugtraq mailing list about his MangleMe utility. This CGI script generated random chunks of malformed HTML and managed to shake out flaws in almost every modern web browser.  A few months later, Michal posted about the results of his JPEG fuzzer, which was also able to crash Internet Explorer in a few different ways. A year or so has passed and it was time for a another fuzzer :-)


Inspired by Michal's work, I created a javascript COM fuzzer to locate common flaws in ActiveX controls. After a weekend of tweaking and testing, I compiled a list of nearly 60 flaws in Internet Explorer.  With a few exceptions, these flaws were limited to an unexploitable crash, but the sheer number of flaws was amazing. After some digging around, I ran across  a public tool called axfuzz that performed a similar set of tests, duplicating many of the crashes identified by my fuzzer.  Shane Hird released axfuzz in February of 2005 and even took the time to contact Microsoft about his results. Microsoft's response wasn't very helpful:


"COM objects can be called from an object tag and if they are not actually ActiveX controls they can cause IE to terminate."


Microsoft acknowledges that any Internet web site is allowed to shut down Internet Explorer...and this is OK. Why would they bother fixing any other IE denial of service flaw when they take this approach to COM objects? A good example of this issue is the OutlookExpress.AddressBook component, which is installed by default on most versions of Windows. Creating an instance of this object in IE 6.0 is enough to kill the browser.


Excluding the object instantiation flaws, there were a number of interesting bugs found by the fuzzer. Some objects provide the ability to access an arbitrary item of an internal array, even if that array hasn't been populated,  allowing for some odd exploit scenarios (fill the heap to cover where the array should be, work through the list of dereferences). One of the strangest cases was triggered by setting an object property to a static value, over and over again, eventually triggering a pointer overwrite. It seems like even a single dword heap overflow can become exploitable with enough work. Another fun case was a memory corruption bug triggered by freeing a COM object (forced redirect to another page) that had one of its attributes set to an instance of a similar object.


Nearly all of these flaws have been reported to the vendor (with case numbers received) and the COM fuzzer will be made available once the big issues have been patched. If you are impatient, you could always reproduce the crash issues with axfuzz, or try out iDefense's COMRaider tool.


One of the coolest things about exploiting COM bugs via Internet Explorer is that even if you aren't allowed to create a given COM object, the associated libraries are still mapped into the process. If you find a way to control code execution, you can pick your own return address (DLL bounce) by attempting to create a COM object that uses a library which happens to have the opcodes you need at a reliable address. In many cases, this method can used as an alternative to heap filling, especially if you have partial control of the address. Scan the DLL set looking for something with the appropriate IMAGE_BASE address (say, using msfpescan in framework-2.5), figure out what COM objects use that DLL, create a new object, and then trigger your bug :-)


COM and ActiveX is fun, but it is limited to browsers based on Internet Explorer. The next project was to write a DHTML element fuzzer that could test all modern browsers for common implementation flaws. The process was simple - make a list of all known DHTML elements, their properties, their methods, and then beat the crap out of them until something gives. The fuzzer was called hamachi (because lunch was sushi and project names don't need to be unique, damnit), and was uploaded to the web site. The first version received a ton of feedback, usually along the lines of "wow, [some browser] crashed quick!".  Aviv Raff contacted me about making some improvements to the code and we have both been adding new techniques since.


Hamachi has found flaws in Firefox 1.0.7, Mozilla 1.7, Konqueror 3.5.1, Opera 8.5, Safari, and Internet Explorer. The vendors have not been officially notified (due to lack of time), but the fuzzer code is public and nothing stops them from sending a link to their QA departments :-)


Considering how many browser bugs are turning up, maybe its time we develop a consistent, reusable API for exploiting browsers. So many exploits are using Skylined's heap spraying technique, we may as well add animated progress bars, DHTML layers, and trance background music to the Metasploit Framework modules :-)



Originally Posted by skape



Like most binary analysis tools, an emphasis is placed on the generation of graphs that describe the behavior and relationships of different aspects of a program, function, or component. For instance, a Control Flow Graph (CFG) describes the paths that could be taken from an entry node (such as a function's entry point) to a terminator node (such as where a function returns).


For the purpose of this post, we'll use the following disassembly of a function that was taken from an executable:



000000B9 push ebp
000000BA mov ebp,esp
000000BC push ecx
000000BD mov eax,[ebp+0x8]
000000C0 mov cl,[eax]
000000C2 mov [ebp-0x4],cl
000000C5 mov edx,[ebp+0x8]
000000C8 movsx eax,byte [edx]
000000CB cmp eax,0x63
000000D0 jnz 0xdd
000000D2 mov cl,[ebp-0x4]
000000D5 add cl,0x5
000000D8 mov [ebp-0x4],cl
000000DB jmp short 0xfe
000000DD mov edx,[ebp+0x8]
000000E0 movsx eax,byte [edx]
000000E3 cmp eax,0x64
000000E8 jnz 0xf5
000000EA mov cl,[ebp-0x4]
000000ED add cl,0xa
000000F0 mov [ebp-0x4],cl
000000F3 jmp short 0xfe
000000F5 mov dl,[ebp-0x4]
000000F8 add dl,0x1
000000FB mov [ebp-0x4],dl
000000FE movsx eax,byte [ebp-0x4]
00000102 mov esp,ebp
00000104 pop ebp
00000105 ret



Aside from the standard CFG, it is also possible to generate many other graphs that help describe the behavior of this example function. For instance, one might be interested in understanding how data propagates within the context of a function or a set of functions. This would be useful in cases where you want to see what areas of code come in contact with data that you control, either directly or indirectly. One of the most obvious applications for this is fuzzing, where you can immediately identify the areas of code that are affected by a buffer that you introduce. This type of graph will be referred to as a Data Dependency Graph (DDG). It will show how memory reads and writes are affected both in terms of what address they read from or write to and in terms of what values they read or write. Here's a DDG that was generated for this example function:



In this graph, the blue edges represent a value dependency. This means that the instruction derives the value that is written to a location in memory from the instruction that the edge points to. The red edges represent an address dependency. This means that the instruction derives the address it is reading from or writing to from the instruction that the edge points to. As we can see from the graph, all of the instructions either directly or indirectly depend on the value assigned to ebp for the address that they operate on in the case of this function.


Another type of graph that may be useful is a Code Dependency Graph (CDG). In this graph, the execution order dependencies of instructions can be seen such that it's obvious that instruction X must execute before instruction Y for a specific code path. These dependencies are determined by looking at which instruction was last to affect a register, an area of pseudo-virtual memory, the stack, or a processor flag that a given instruction depends on. For instance, if a function has an xor eax, eax followed by an inc eax, it's obvious that the inc must follow the xor because the xor was the last to modify the value of eax. This simple logic can be used to determine execution order dependencies. One of the ways in which this type of graph can be useful is when researching things like instruction re-ordering for the purpose of generating code that has an equivalent behavior but different form (also referred to as polymorphism). A great example of where a graph like this was used was during the development of the Shikata Ga Nai encoder in the Metasploit Framework. For this example, though, a graph that describes the code dependencies of the example function is shown below:



In this graph, the blue edges represent a register dependency. This means that the dependent instruction expects to derive the value of a specific register from the instruction pointed to by the edge. The red edges represent a memory dependency. This means that the instruction depends on a specific portion of pseudo-virtual memory being set by the instruction pointed to by the edge. The green edges represent a processor flag dependency. This means that the dependent function is expected to derive the state of the processor flag from the instruction it depends on. What all this means, in the end, is that instructions can be moved around in any order, so long as they do not invalidate the dependencies of another instruction by doing so.


Again, these types of graphs have been described and used before by others, so don't take this post as to claim that they are something original. Instead, it's simply meant to illustrate the types of things that MSRT will be designed to support. In fact, the code responsible for collecting the data that is used to generate these graphs is encapsulated in two separate analysis modules, both of which currently total around 100 lines of code each. With that said, the library still has a long way to go.

Originally Posted by skape



One of the goals of the Metasploit Project is to provide a useful and friendly outlet for security related research. Examples of this can be seen in the Metasploit Framework, the Opcode Database, and the Metasploit Anti-Forensics tools. Though the focus of the project has been mostly oriented toward exploitation research, the interests of those involved in the project generally don't stop there. Most recently, I've been spending some time designing and implementing a library that can be used to help perform automated binary analysis. Depending on time and sustained interest, I hope to be able to release this library as the Metasploit Reversing Toolkit (MSRT). The library is currently being prototyped in Ruby.


The primary goal for this library will be to provide a powerful and simple interface for those who wish to perform binary analysis and for those who wish to implement and test ideas pertaining to binary analysis. It's important to note that I don't claim to be a binary analysis ninja (I'm no halvar :) and that I don't foresee this toolkit as being as powerful as IDA in many regards. However, it's my hope that it will still be a useful environment for testing ideas. Failing that, it's at least an interesting and challenging distraction :).


In my next post I'll give examples of some of the things the library is already capable of providing in terms of analysis. Stay tuned.

Originally Posted by hdm



This is the official blog of the Metasploit Project and a brain-dumping ground for the Metasploit development team.

Filter Blog

By date: By tag: