Essential Weapons in a Security Researcher’s Arsenal: Part 1

Building Better Defenses is Hard to do Without the Right Tools

We talk a lot about cybercrime, but what about security researchers? The Black Hat conference brought out several people from behind the scenes who research the next generation of attacks, conduct forensics analysis, and build the appropriate measures to improve security. But building better defenses can be like building a house – it is hard to do without the right tools. With that in mind, in this two-part series, we will be taking a look at a list of ten tools used by different researchers. In some cases, I have listed categories of tools instead of individual tools themselves. Some of the tools are old– but have proven their worthiness time and again – while others are new, and were revealed for the first time at Black Hat.

So without further ado, let’s start with some of the better known weapons in a researcher’s arsenal:

For MacGyver: Wireshark

For the MacGyver in you, you’re looking for that Swiss army knife. The one that will tell you what traffic is passing through your network while helping you find the source that is hogging your database server. This same tool can intercept traffic passing through the router to check whether the credentials to a certain application are sent encrypted, as well as show you the innards of some 100 different network protocols. But it doesn’t stop there – if you’re developing your own protocol and you want to test its flow, this tool will also come in handy. Look no further, for you have the ultimate network protocol analyzer: Wireshark.

For the Translator: A Hex Editor

When you open a PDF file with a PDF viewer, you’ll see the file as we humans are used to viewing: with text and images. But to a computer, this file contains just 1s and 0s. Researchers find it easier to view these 1s and 0s in groups of 16, where each group is assigned a digital value 0-9 or A-F (representing the values 10-15). The hex editor allows you to view this hexadecimal format and will also translate that code to a human-readable character (or at least, those that are translatable).The researcher in you will find lots of value from reading this format: from understanding the bits and bytes passing on the network (yes, there are still some protocols which Wireshark cannot dissect), to analyzing where that piece of malicious code appears in the malware. Interested in editing that code and seeing what happens? This is what the hex editor is all about!

For the Mailman: A Packet Editor Combined with a TCP Relay

This mailman does not only re-route the messages on their way, but also modifies the packet’s content. If you have a server that keeps crashing upon the receipt of certain messages and you would like to re-route the messages from their particular destination in order to inspect them in a testing environment, a TCP relay is what you are looking for.

But what if you want to take this inspection one step further? You know your server’s behavior to a certain type of input. But what happens if it receives a different parameter than expected? Following the behavior through the GUI, or a script, may require following several steps. Or maybe the GUI does not provide you with the option of several configurations, although you do know that the server can receive them. All you really want is to directly test the behavior against a particular packet with the modified input. In this case, you need a packet editor. The packet editor will allow you to manually craft those packets which you can then inject into a session.

By combining the power of a TCP relay together with the power of a packet editor, you can get that extra-capability of injecting crafted packets at real-time in order to test different server behaviors. It will help you in the most simple and most common of all scenarios – modifying the packet contents between a client application residing on your machine and a particular server. It will of course also help you in more complex environments. For example, say the server address is hard-coded in the client-application. However, you do not want the server to start processing the packet. The preferred setup would be to grab the message when it arrives at the server, but before the request is processed. Then re-route the message to your test environment, change the packet’s content according to your heart’s desire, and send this modified packet back to the original server for processing.

For the Safety Inspector: A HTTP Proxy

This is the security tool for the researcher testing the security of Web applications. The HTTP proxy is needed for the modification of HTTP traffic and for SSL monitoring. The proxy is added as a plug-in to the browser (even Mozilla provides such an add-on), and starts to monitor all HTTP traffic coming in and out of the machine. Most HTTP proxies also feature recording capabilities that can save the traffic and replay it later for an offline analysis. This simple interception helps researchers answer questions such as: What is the Web app’s behavior when a HTTP request packet is modified? How does a Web server react to certain input? What details are passed encrypted?

For the Mechanic – A Debugger and A Decompiler

Want to look under the hood of the malware? Or maybe you have an executable that given a certain input it crashes? You really need to get to the root of the issue. The answer – you need a debugger and a decompiler.

The debugger will help you test the flow of the program. If it’s malware, it will help you find what the malware does. Take for example mobile malware, which intercepts text messages and copies them to a dropbox (something of the sort a ZitMo – Zeus in the Mobile malware). By debugging the application, the researcher can understand the flow of the malware and find how the malware is intercepting the text messages.

The decompiler will present the researcher with the code. Returning to our mobile malware example, the decompiler provides the researcher with the technical details of how it operates. A helpful tip when decompiling Java applications: look for those drivers which come with a “-g” extension. These provide the debugging information that can certainly help for code clarification.

Next Column

For part 2 of this series we will look at some of the other items in a researcher’s security toolbox.