[Editor's Note: In the article below, Yori Kvitchko kicks off a series of brief posts about quick and dirty but very useful techniques pen testers can apply to analyze stand-alone files (such as binaries, Flash files, etc.) that they encounter in penetration tests. There is a treasure trove of info in most stand-alone files you'll encounter, and the ability to quickly go through those files to pry out their secrets is hugely helpful in penetration tests. It's surprising how valuable these techniques really are in pen testing, given how easy they are to do. In this article, Yori focuses on looking for communication streams. -Ed.]
There is a mentality common to many software developers that we as penetration testers should always relish and keep in mind; if some feature I need to call or use is packaged inside of a self-contained individual executable file, it is safe, trustworthy, and out of sight. As a software developer myself, I often have to catch myself on this same line of thinking. Just because it's not easy to get to, doesn't mean that someone won't. Keeping this in mind, we as penetration testers shouldn't be afraid to break down the walls of an executable or app and get at its juicy innards.
Lets face it though, to some penetration testers, reverse engineering is a dark art that just feels out of reach, a practice only for the ninja masters. It's no simple task to move from web application analysis to following jump calls in IDA Pro. But, even before you've achieved ninja masterhood, there are a lot of practical things you can do to tease out important secrets and perhaps even vulnerabilities in stand-alone application binary files.
This set of blog posts is going to present a few reverse engineering techniques that I've found to be particularly useful over the last few years. Most importantly though, these are techniques that anyone can learn and use quickly and easily.
One of the juiciest types of applications you can encounter on a penetration test is internal tools. These tools, typically written with a "just get it working" mentality, often have shoddy security because no developer of internal tools thinks about an external threat getting access to them. We, of course, know that these tools are just a pivot away from being in our grasp. Here are some situations to be on the lookout for when you might have an opportunity to use these quick and useful binary analysis techniques:
- Any time you've compromised a machine with a standalone internal application installed, often an internal tool on a client machine. Be on the lookout for anything branded with the company's name.
- When target system personnel ask you to test the application as part of your penetration test.
- After getting access to an internal web server that has a Flash/Java/other client side application embedded into the hosted website.
- Any other time that you find a binary or application that can be considered in scope. Make sure to check shared drives and ftp servers for folders named "tools" or similar.
Dealing with a binary, it is often the communication channel that the binary uses that is most vulnerable to attack. So how do we figure out who the binary, Adobe Flash file, or other standalone application is communicating with? Many developers, due to its ease of use, choose to use HTTP as a form of sending data from and to an application. Keeping this in mind, the first thing I do when I analyze an application is run strings on it looking for HTTP or HTTPS URLs.
Linux:
$ <strong>strings app.exe | grep -E -i 'https?://'</strong>
Windows (requires the Strings utility from Microsoft Sysinternals):
C:\> <strong>strings app.exe | findstr /i /r "htt[ps]*://"</strong>
Nowadays, lots of standalone applications are nothing more than fancy frontends for a regular old web application. If you determine that there's a web server behind the application, your job just got that much easier. For some extra fanciness, take a memory dump of the running application (using a tool such as mdd or one of the other tools listed here) and run strings on that. You might find some crafted GET or POST requests with passwords or other interesting parameters.
Even if the application doesn't use HTTP, there are plenty of easy-to-analyze-and-manipulate data formats that the application might be using to communicate over the network. Before we analyze any network protocols though, we need to capture the traffic being sent by/to the application. We'll be focusing on Windows here since most of the juicy applications we want to analyze will be Windows client applications.
Fire up the application and find its PID. You can do this with Task Manager, Process Explorer, or the plain old command line as follows:
C:\> <strong>tasklist /FI "IMAGENAME eq app.exe"</strong>
Once we have the PID, lets say it's 6140, we can look at which IP addresses the application is communicating with. Open up your command prompt and run netstat, displaying PIDs and re-running every 1 second.
C:\> <strong>netstat -na -o 1 | findstr "6140"</strong>
If nothing immediately appears, try interacting with the application to get it to make an outgoing connection or open a listening port. Once you have an IP address, a simple Wireshark filter finishes up the job for us, isolating just the IP address we're interested in.
ip.host == 10.10.10.1
You can also look for DNS requests that were used to get that IP address with the following filter.
dns.resp.addr == 10.10.10.1
DNS names can sometimes offer clues as to the nature of the back-end. Don't forget to do an Nmap version scan on the port as well.
Once you have an isolated communication channel, use Wireshark's "Follow TCP Stream" and look for easily readable and easy-to-manipulate data formats. Some things to keep an eye out include HTTP, Base64, XML, CSV and any other plain-text protocol. The rest depends on how well you can take advantage of this new communication channel. Remember that you take advantage of proxies (like the OWASP ZAP Proxy or Burp's proxy) for HTTP and also forge your own communication with plain old Netcat. The rest is up to your imagination and the lack of imagination on the part of the developer.
In the next episode of this series, I'll provide additional quick and dirty tips for penetration testers in analyzing stand-alone binary files to pry out useful secrets.
-Yori Kvitchko
Counter Hack