Why You Should Be Looking for Zero Day Vulnerabilities During Pen Tests
Penetration testing is a creative endeavor: The goal is to find vulnerabilities an attacker would exploit, using the same tools and methods the attacker would use. Experienced attackers don't shy away from researching for new vulerabilities in standard products - in fact, finding a zero day in a third-party component is sometimes the easiest way of breaking into a system. Unfortunately, while most penetration testers check for known vulnerabilities in standard libraries and services, many implicitly assume that these components don't have any unknown vulnerabilities - or simply aren't confident enough to tackle them. At the same time, almost every pen tester I know complains about a lack of research time! If you are one of these pen testers and want to up your game, this article is for you.
With a bit of creativity, you can turn even the most trivial network scan into a mini research project. The trick is to see every project you do as an opportunity for zero-day-hunting: Hack the standard components you encounter whenever time allows. Not only does this make penetration testing more satisfying for you - it also adds value for the client, as long as you follow proper procedure and get the issues fixed.
Web Application Penetration Tests
In web app tests, what you can do depends on the type of the target application and the amount of time you have available. "Enterprise” Java and .NET apps will usually depend on many standard frameworks and libraries. Very often, you'll also find dependencies on lesser-known libraries that were plugged in for some specific functionality. If so, the more obscure libraries should be your first target: Download the sources, set up a test app, and go ahead with code review and debugging.
You can also go for the bigger fish: If you're testing Java web apps over and over again, why not start reviewing the code of the underlying web container and frameworks? Web frameworks like Spring, Struts, Hibernate have found to be vulnerable many times in the past and there may still be interesting things to find. Even if you don’t find any vulnerabilities, learning about these frameworks will make you a better tester. Set up a Eclipse/Tomcat environment on a VM and fire it up whenever you're testing a J2EE app and have some extra time to spare.
The same approach can be used with other web technologies. Don’t shy away from reading the sources of PHP, MySQL or even Apache and its countless modules. The better you understand these standard services, the better you’ll get at penetration testing, and you’ll have a high chance of encountering zero-days along the way.
A few years ago, I had an SQL injection in an ASP .NET app but couldn't achieve code execution. I was pretty much stuck testing the web app so I wrote a simple fuzzer for Microsoft SQL Server. Lucky as I am, I discovered a remote code execution vulnerability and used that to own the Windows server. The whole process took two days which was well within the time budget (granted, this was 2009 and exploiting Windows vulns was a bit easier than it is today). Now imagine how good it felt to deliver that report :) Most zero days I found came out of similar mini-research-projects started during client engagements.
In another engagement, a colleague and I were reviewing the code of a web banking application. The application itself seemed pretty secure, but it was running on a rather unusual applicaton server - Sybase - so we decided to test that server as well. Sure enough, we found multiple vulnerabilities that allowed us to compromise the system. Going live with this setup would have exposed the client to a serious security risk, as a motivated attacker could have easily found the same vulnerabilities!
Network Penetration Tests
Network penetration tests (especially internal ones) are the perfect opportunity for getting some research done. Almost every company runs some services that you won’t easily get to test anywhere else. This may include appliances, backup software, security management, and many others. Many of these apps are not that well-researched, so you’ll have an easier time finding vulnerabilities.
Say, you encounter a VOIP appliance in your client's network. You've tested the appliance for known vulnerabilties and weak passwords and done some blackbox testing on the web interface but ended up emtpy-handed. So that's it - security test complete right? Well, not necessarily. If the admins have done their homework, and there are no major misconfigurations or unpatched services in the network, finding a zero day vulnerability in this appliance might well be the fastest way to get root. In this case, it could be worthwile to install a trial version of the product for a more detailed inspection.
To illustrate this process, I’ll share a war story from an internal network penetration test that yielded a small security advisory. We had run most our standard tests and were waiting for Nessus and some other tools to finish (a common situation in larger-scale network tests). In the meantime, we were browsing through the nmap results and stumbled upon the following host:
There’s a whole bunch of worthwhile targets in that list but one in particular triggered our alarm bells. Ever heard of “File Replication Pro”? We hadn’t either so we checked out their website. Looked like a small enterprise, most likely consisting of one or two guys - probably not a company with a highly sophisticated secure SDLC. We also deduced that a file replication software needed fairly high privileges to do the file replicating. A potential gold mine!
The first step was to find out everything we could about the app. This included reading the documentation, enumerating the ports opened by the application, sniffing network traffic between systems, and so on. We also downloaded the demo version and set it up on a VM. We found that the server came bundled with a variety of JARs, including standard packages such as openJMS and AXIS, as well as some proprietary components. These components implement an administrative web app as well as an RPC service responsible for the actual transfer of files between machines.
We reverse engineered the RPC implementation and found some interesting calls, including one called COMMAND that - well, you can probably guess from the name what it does. The syntax for executing RPC was something like this:
$ echo -e "net.diasoft.s2s.action=RPC\nGetDirList\nRPC_PARAMS_BEGIN\n\n[COMMANDS…]\n" | nc frp.example.com 9200
The RPC interface was protected with a password, which was stored in a local configuration file. Fortunately, this wasn't a big problem because there was also an unauthenticated local file disclosure vulnerability in the administrative web application:
We code-lifted the RPC client from the demo app to create a quick-and-dirty exploit, which got us code execution as SYSTEM (and subsequently domain admin). Have a look at the exploit code if you're interested.
Following our pen test report, the client decided to deinstall the vulnerable software, making the network more secure in the process. In the meantime, the vendor has fixed the vulnerability. A win-win situation!
There are many types of engagements and all of them have some interesting aspects about them. Remember that security flaws can be found everywhere - cryptographic algorihms, network devices and protocols, operating systems, and everything else ever created by humans. Many of these are assumed to be secure simply because they have been around for decades. Keep an open mind and investigate something new whenever you can!
Experienced attackers will exploit zero day flaws, and so should you. Testing PHP web apps? Why not start testing PHP as well? You’ll develop your skills and discover new vulnerabilities along the way.
About the Author
Bernhard Mueller is an full-stack hacker, security researcher, and winner of BlackHat's Pwnie Award.
Follow him on Twitter: @muellerberndt