What’s Better Than Catching Bad Guys?

Before coming to Adaptive Computing a couple of years ago I worked as a cyber research engineer.  I had the opportunity to do some crazy things that helped to catch some seriously bad people.  As much as it looks like great fun taking down bad guys on TV shows, what is even more fun (at least for those of us that don’t enjoy being shot at), is to figure out how to exploit a software package or electronic device so that it makes it possible for the boots on the ground to bag the bad boys.


I few years ago I was at a security conference where one presentation showed a subject walking into an office and slipping a small device into an open port on the back of a desk phone. The device obtained access to the network and exfiltrated data via a wireless connection.

Hacking devices like this isn’t like you see in the movies (big shock, I know!) where the white hat hacker types for 5 seconds in a terminal, and hacks a bad guys phone into exploding.  Yeah, it’s not like that – hacking can take an extremely long time to find a vulnerability that can be exploited.  The way that most software vulnerabilities are found is to have a software system that hammers on a the target program by sending it input that’s been modified in specific ways with some randomization built in to try to make the software crash.  The system catches the fact that a crash happens, and logs it to a database that can then be examined and the crash reproduced.

This system of malforming inputs is called “fuzzing” and is going on constantly. Large software companies, government agencies, and malicious hackers are all using it to find vulnerabilities in software.  The larger, more sophisticated operations use racks of servers in constant operation churning out lists of crashes that are then sorted and prioritized by vulnerability engineers who then examine the crashes for repeatability and potential exploitability.

As I found working for a defense contractor, priorities are always shifting, projects come and go, and hot opportunities are dropped in your lap on occasion that need immediate attention.  This looks like a great problem requiring a HPC/HTC workload management solution.  Some of the clusters that I’ve seen are using homespun frameworks to keep the machines busy, but have to be manually manipulated to change priorities or start and stop jobs.  The better approach to building a manageable and productive fuzzing cluster is to apply the mature workload and resource orchestration technology found in Moab, combined with the high throughput capabilities of Nitro. Moab allows jobs to be prioritized, pre-empted by high priority jobs, rescheduled to continue processing of lower priority jobs using proper access control, departmental accounting, and cluster management.

The cluster could consist of servers used for running VM’s of various software systems to be tested, or a rack of FPGA’s programmed to emulate specific hardware modules with embedded software, or even a bank of smartphones with controllers setup to interface with the phones JTAG and serial interfaces.  All of these resource types could be managed by Moab and jobs scheduled to keep them busy.

Nitro would form the backbone of the fuzzing executor – launching tasks continuously for some jobs or until the desired range of fuzzed input values is exhausted. Using Nitro’s API tasks could be submitted to Nitro and results gathered, processed and cataloged in a database.

Using smart scheduling products will improve the utilization of your fuzzing cluster and give you a competitive advantage over the bad guys so you can find and fix, or find an exploit software vulnerabilities before the bad guys do.  Now that’s what I call fun!