The Grey Corner

I have just released a program named Vulnserver - a Windows based threaded TCP server application that is designed to be exploited.

I am (slowly, and when not occupied with other things) teaching myself to program in C, and this seemed like a good way to further develop my C programming skills.  This gave me an opportunity to see how software is exploited from the developers point of view, and crafting this software so it was exploitable using particular exploit techniques was an interesting challenge, and enabled me to look at exploitation from a new perspective.  And as an added bonus, it gives me the opportunity to claim that any bugs found in my code were put there deliberately.

I often find myself in need of an exploitable program in order to quickly test out shellcode, as well as other exploit techniques I am developing.  This program is ideal for that purpose, because it is small, easily portable, and extremely easy to debug.

I enjoy writing about how to exploit software, but finding exploits that are good to write about can be challenging.  In order to make for a good tutorial style document, you need to find an exploit, ensure the exploitable software is available to be downloaded and used, and if you don't want to continually cover the same ground, the exploit has to require some sort of unique technique in order to make things interesting.  It’s a lot easier to achieve this if you just write the vulnerable software yourself.

I have always liked exploitation exercises, such as the Sourcefire awbos,  and have always wanted to try writing something like that myself.  One thing I never liked about those exercises though was having to send data to these applications via command line arguments.  It makes debugging, fuzzing and exploit writing awkward, and it seems very unlike the way most real life exploits actually operate (especially on Windows).  Therefore, I created vulnserver, but unlike the awbos I implemented it in the form of a threaded TCP server app so you can exploit with ease over the network - making this feel a bit more like a "real" vulnerable server application.

The download package includes the usual explanatory text files, source code for the application as well as pre compiled binaries for vulnserver.exe and its companion dll file.  Working exploits are not included (but keep reading...).

To run vulnserver, make sure the companion dll file essfunc.dll is somewhere within the systems dll path (keeping it in the same directory as vulnserver.exe is usually sufficient), and simply open the vulnserver.exe executable.  The program will start listening by default on port 9999 - if you want to use another port just supply the port number as a command line option to the program - e.g. to listen on port 6666 run vulnserver.exe like so:

The program supports no other command line options.

The program will spit out its version number when you start it up, as well as the version number of its companion dll, so it's obvious what version you are running just in case I need to update it in future. Exploitation can be a finicky business, and changes to/recompilation of a program can change the buffer structure required to gain control of code execution, so I have made tried to make it as easy as possible to determine what version of the program and its associated dll you are running, so if you are following along with any guide you can ensure you have the same version of the application as used in the guide.  This is also something to be aware of if you want to compile the program yourself - different c compilers (even different versions of the same compiler) can produce binaries that exploit in different ways from the same code, and you will get a warning about this when you start the program too.

Once the program is running simply connect to the appropriate port using a command line client like netcat and issue commands separated by newlines.  Perhaps start with HELP to see what commands are available to you...

Vulnserver contains a number of bugs (exactly how many I'm not going to reveal just yet), and each one of them requires a different approach in order to create a successful exploit.  The difficulty of the exploits range from easy to medium difficulty - and the challenge is to execute a bindshell payload for each exploitable bug you find.

If you are at all experienced in analysing C code for vulnerabilities you should be able to spot the bugs pretty quickly by reading the source, but I’d suggest you instead attempt to find the vulnerabilities using fuzzing.  The program will give up its buggy secrets very quickly in response to the right fuzzer, appropriately used.  Connect using a basic TCP client like netcat, ask for HELP to see what type of commands are supported to use as a basis for fuzzing, and go from there.

This program has been released without working exploits for the moment, but for all but one of the exploitable bugs introduced into the program I have produced working exploits, so be assured that exploitation in multiple ways is definitely possible.  The one remaining exploit I have not yet completed is delayed until I can fix some issues with a certain type of publically available shellcode, which "does not always work". 

In the coming weeks, I am going to release a series of articles on how to find and exploit all of the exploitable bugs in this program, so if you can't find the bugs yourself don't despair.

I have confirmed this program runs, and is exploitable on Windows XP SP 2, Windows Vista SP? and Windows 7 systems with default configurations.

Vulnserver doesn't actually do anything other than allow exploitation - there is no useful functionality.  Integrating code to perform some other function didn’t seem to be a good use of binary space or my time considering the purpose of the program.  There has been some effort put in to make it appear as though the program is taking user input and providing responses, so it seems like a regular (albeit very basic) server application, but there's really no reason to run this unless you're actively exploiting it at the time.

You SHOULD NOT run this program on any critical system, and you should not allow this program's listening port to be accessible from any untrusted network, such as the Internet.  There is no malicious code included within this program (check the source to confirm), so this is NOT a virus or malware, but this program can be put to malicious use if an untrusted individual can access it.  That's kind of unavoidable considering what the program was designed for.  So run this only on a well protected (possibly isolated) test system, and only when you are actively using it to test exploitation methods - don’t just leave it running all the time.