Exploit Development Framework Design
Perl, Ruby Python: use the language that suits your character. However, one of the things that differentiate python from the rest is its philosophy, which is: "there should be one-- and preferably only one --obvious way to do it" (where "it" is "a problem"). This philosophy gives python some interesting advantages over other similar languages. That will be explained later on.
This post is merely a summary of my research work on how to build a better exploitation framework ala metasploit-style.
The Problem
Metasploit is great but there are three things that makes the framework sometimes inconvenient: it's size, it's dependency of the ruby platform and of course it's speed. It will be great if for example we can take a single exploit (or a set of exploits) out of the framework and compile it into a standalone executable. On the advantage side, this type of solution will also allow us to ship the framework as a payload to already compromised systems and use it from there as a stepping stone for further propagation. It will also allows us to run exploits from compromised embedded devices as long as we can compile for their architecture, which is pretty cool.
I understand that it is possible to bundle the entire framework plus the ruby environment into one executable but such a solution is simply not elegant enough and not fully cross-platformed.
Introduction
Back in the days when Metasploit was written in Perl, there were a few other frameworks trying to do similar things but in C and C++. A solution based on C or C++ is a lot more interesting as it allows us to compile standalone versions of the framework and use them as we wish. It simply makes the framework very good for embedding and also quite suitable for delivering it as a payload to the systems we would like to compromise.
Nowadays, a C and C++ solution is often doomed to failure. The reason for this is because when building a framework you can easily get into a situation where you need to solve a pretty complicated problem. Both C and C++ lack the dynamicism and the degree of expression available in languages such as perl, python and ruby and therefore, while they remain very suitable for low level stuff, they start to loose their grounds when it is needed to build something that is more abstract and high level.
Some Solutions
Keeping all of the above in mind I started putting words into practice. In the spirit of a zen monk, I started thinking which parts of the metasploit framework are most valuable to a penetration tester so that they can be branched out. As it happens, the obvious answer is: "the exploits". The "Auxiliary" modules are great but they represent functionalities which are already available in other tools. So, the first idea was to take the exploits and payloads out and rewrite them into something that is more suitable.
I decided to see for myself if I can prototype a simple exploitation framework in C++ that all it should so is to implement several abstract interfaces for exploit development, a a class with common methods for payloads (empty of course) and of course a simple interface to run an exploit with a payload against a target. All of this was achieved in a "hello world" fashion exploiting a simple stack overflow on a proggie from the command line and of course without the need to circumvent any protection mechanisms in place.
Although I was pleased with the result of the prototype, I was not convinced that this is a good enough solution. Programming in C++ is fun, especially when you haven't done it for a couple of years, but still not as practicle as I would like it to be. We can most certainly build a DSL on the top of C and C++ by using Preprocessor Directives but when you are developing an exploit you want to make the process as painless as possible and C directives are only making it worse when hunting for a bug in the exploit. Not to mention that compiling something every time you make a change is not cool at all.
Being a pythonist and knowing the python mantra inside out, I thought that it should be possible to write all of the exploits and payloads in python and convert them into C or C++ at later stage as long as I stick to using a minimal set of the language features which can be directly translated with regexes and some basic parsing. After all, python looks like an executable pseudo code. Luckily for me, such a solution already exists and it is called shedskin.
Now shedskin is a lot more than a simple python to C++ translator. Not only it can convert a python program to C++ source but it also implements all of python's builtins and it has support for some of python's most useful modules such as re and socket. On the top of that, it is trivial to implement additional modules to the shedskin framework in python. This is a product I will happily pay for!
Analysis
I played quite a lot with the shedskin compiler tweaking things as I go. Although the parser is pretty advanced there are some restrictions enforced on the language. All of them are nicely covered in the shedskin's tutorial.
It was time to see if I do need the advanced python features for developing the exploits. I run through all Metasploit payloads and exploits and a pattern started to emerge. The majority of the exploits were pretty basic. They all came down to the following algorithm more or less:
- Select an exploit
- Pack a structure/payload that will be sent over a socket or will be dumped into a file
- Send/Save the payload
Obviously, there is no need for python sugar to implement that.
The Design
I did quite a lot of work investigating the best approach to tackle the problem of creating a good enough exploitation framework and I came up with the following basic idea:
We start with the same basic building blocks as found in metasploit. We need abstract classes for Exploits and Shellcodes and also classes that implement them to define more functional classes such as those that needs to be implemented when writing remote exploits for example (socket stuff). We use the basic python capabilities keeping shedskin in mind. As I mentioned, shedskin is quite advanced so most of the functionalities can be implemented without even taking it into consideration at all.
That will provide the core of the framework. All of the exploits now can be written on the top of this. The exploits themselves should reuse as much as of the builtin methods as possible as that their portability will be guaranteed.
A layer above that, we write as much as python sugar as we want. We simply don't care how we are going to write it because that part of the framework doesn't have to be compiled.
In summary, we layer the whole thing like this:
- Layer 01. Core Exploit Development Classes implementing the most basic set of python features
- Layer 02. Exploits implementing the Core Exploit Development Classes
- Layer 03. Python sugar to glue it all together
Conclusion
So, it is possible to write a good and well-designed exploitation framework in python that allows exploits to be separated and compiled in standalone native executables. Not only that, but we do not sacrifice from the dynamicism of the python language as while the core will be written in basic python, the rest will be as dynamic as we want. Imho, this is all possible due to python's mantra that "there should be one-- and preferably only one --obvious way to do it". It just makes it easier to write briliant tools such as shedskin.
Although I am quite excited to start writing such a beast right a way, I am going to
passthis time. I am starting to learn to say "NO" because I've got far too many things on my plate already. However, if anyone is interested in working on this, I will be very happy to facilitate the project as much as I can and give a hand where necessary.
I am very interested to hear your opinion and I am even more interested to get the opinion of the Metasploit team as they have a lot more experience in coding exploitation frameworks than me.
Archived Comments
HD
