Perimeter
11/20/2012
11:31 AM
Gunter Ollmann
Gunter Ollmann
Commentary
Connect Directly
RSS
E-Mail
50%
50%

The Business Of Commercial Exploit Development

A closer look at the debate surrounding this market

Over the past 15 years of cybersecurity discussion, it's doubtful that you'll have failed to notice the biannual flare-ups concerning vulnerability disclosure. Whether it's due to the slow fuse of a software vendor silently patching a legacy vulnerability, or the lightning strike of a zero-day being dropped at a security conference, these brushfires rage with fury for a short period until the tinder and media gets exhausted ... until the next time.

More recently, these flare-ups have come to envelop the exploit development business, and there's a tremendous amount of confusion and (dare I say it) misinformation being thrown into the mix. The passion and vigor with which a small number of very vocal players are driving their agendas is obscuring many of the true facts of the business.

The commercial exploit development business goes by many names -- depending on which agenda you're seeking to push and, frankly, who your customers are likely to be. For example, I have traditionally used the term "weaponization" of vulnerabilities, vendors of protection products often use the term "proof of concept," while those employed in the production of exploit material simply refer to it as "product."

Most security professionals greatly underestimate the amount of effort and time that goes in to the creation of stable, reliable exploits. There's also a misconception that all vulnerabilities can be turned in to exploits. Oh, that's so far from the truth to be laughable. It may take a few hours for an automated fuzzer to uncover a batch of bugs within a particular software package, and it may take a few days for a bug hunter to personally crawl through those discovered bugs and determine which are, in fact, security vulnerabilities, but it will likely take many weeks of skillful effort and determination to turn a handful of those vulnerabilities into something that could be used to gain control or manipulate the software package from a "hacker" perspective. Therefore, the process of turning a vulnerability into an exploit is an expensive proposition.

This season's brushfires have centered on small boutique companies that specialize in weaponizing vulnerabilities that happen to sell to government entities. Companies that are willing to craft and sell exploits for vulnerabilities that haven't yet been disclosed to the vulnerable software vendors have been analogous to magnesium flares thrown into a tinder-dry California forest at the height of summer (as far as the anti-exploit-sale lobbyists are concerned).

The construction, deployment, and use of exploits are a critical component of modern security practices. Both commercial and freeware penetration testing tools include thousands of exploits -- and are typically employed to categorically prove that a particular vulnerability exists within the environment under test. In other realms -- such as clandestine statecraft -- reliable exploits can be considered specialized skeleton keys for accessing information that could prevent a physical altercation. Regardless, the business of exploit development is a core component of modern cybersecurity doctrine. The question of whether exploit development is "ethical," "moral," or legally justifiable is more a reflection of how well someone understands the business in its entirety.

The heated debate and subsequent focus on those magnesium flare companies exemplifies the rather poor understanding of how vulnerabilities are discovered and weaponized, and who's consuming the exploits.

I use the term "boutique" to describe these vendors for a reason. Compared to the mainstay of the exploit development ecosystem, they're offering a niche, high-priced product. These small companies are like the booths at the annual arts and craft fair that take over the car park outside of an Ikea store. Each booth offers an assortment of themed homemade artwork for a high, but not extortionate price. While some of the artwork is fascinating and interesting, in the grand scale of things, they're novelties. At the end of the day, if you want a functional set of chairs you'd probably just go to the store that the parking lot happens to belongs to. In that analogy, that store is likely to be a major defense contractor.

For the past two years, at least the major defense contractors (in all the G20 countries) have been establishing or greatly expanding their "cyberwarfare" capabilities for sale to their long-standing government customers. Apart from the public posting of recruitment flyers and occasional disclosure from freelance bug hunters who've sold a vulnerability to one of the contractors, there's very little discussion of their participation within the ecosystem. Defense contractors tend to shun media attention -- it's not good for business (unlike the boutique exploiters). But based on the resources they're able to throw at the problem and the scale of recruitment going on, the bulk of the exploit market is being served by them. And rightly so! Pretty much all of the major defense contractors have had strong research arms (and contractual requirements) for information warfare tools since before the Internet even existed.

There's one other area of the debate I wanted to touch on, and that’s the role of commercial security consulting practices. The myopic focus on boutique exploit development shops as an unethical scab on the industry (not my words), and the assumption that if these businesses did not exist the whole business would go away, is ignorant of how easily any organization or government can "game" the system.

As a security consultant for many years and having worked many contracts for clients around the world, the most efficient and cheapest way of acquiring zero-day vulnerabilities and the exploits to accompany them is to simply go forth and hire a team of reverse engineers and bug hunters. The majority of large security consulting businesses have a stable of highly skilled and trained reverse engineers and, given an appropriately scoped statement of work, can deliver exploits for any software package of choice. In fact, this is more often than not becoming a standard line of business for high-end consulting practices. It's not even nefarious.

Let me give you a (not entirely made up) example. A large national telecommunications provider in an Arab state had to choose between three vendors' software products as part of the solution evaluation process. One component of the evaluation was, "Does the software introduce new vulnerabilities to the system?" In order to determine that, a team of four reverse engineers were contracted to spend three months on-site at the regional facility to identify all the bugs they could within each of the software packages and to develop "proof of concept" code to show whether the vulnerability was remotely exploitable. The product with the least severe vulnerabilities would then win that category of the evaluation.

For the consultants, this is an increasingly standard contract. The client wants to diligently evaluate any new products from a security context prior to purchase and deployment, and they're paying top dollar for any findings. At the end of the engagement, the vulnerabilities, exploits, and report all belong (exclusively) to the client. More often than not, the contract expressly forbids the consultants and their company from disclosing these new findings to the original software vendors. I suspect that the volume of "zero-day" exploits generated around the world through these kinds of contracts exceeds the combined output of defense contractors and "boutique" weaponization companies by quite a margin.

As for gaming the system... the fact that the three software packages were the same packages that a competitor in another country to the client uses is irrelevant (and likely unknown to the consultants). What the client does with that information afterward is entirely its business.

So the next time someone is fanning the latest brushfire and proclaiming that weaponized exploit development is evil and that purveyors of such exploits should be regulated or licensed as arms dealers, try to look beyond the marketing hype of a single boutique shop and its pretty driftwood chairs.

Gunter Ollmann is CTO of Damballa

Gunter Ollmann serves as CTO for IOActive Inc. where he is responsible for the strategic vision of the security services portfolio, driving new research areas and bringing new services to market. With over two decades in the information security arena, Gunter has stared down ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
cammywrites
50%
50%
cammywrites,
User Rank: Apprentice
11/25/2012 | 7:32:00 PM
re: The Business Of Commercial Exploit Development
Really interesting read ... Thanks.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2003-1598
Published: 2014-10-01
SQL injection vulnerability in log.header.php in WordPress 0.7 and earlier allows remote attackers to execute arbitrary SQL commands via the posts variable.

CVE-2011-4624
Published: 2014-10-01
Cross-site scripting (XSS) vulnerability in facebook.php in the GRAND FlAGallery plugin (flash-album-gallery) before 1.57 for WordPress allows remote attackers to inject arbitrary web script or HTML via the i parameter.

CVE-2012-0811
Published: 2014-10-01
Multiple SQL injection vulnerabilities in Postfix Admin (aka postfixadmin) before 2.3.5 allow remote authenticated users to execute arbitrary SQL commands via (1) the pw parameter to the pacrypt function, when mysql_encrypt is configured, or (2) unspecified vectors that are used in backup files gene...

CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Chris Hadnagy, who hosts the annual Social Engineering Capture the Flag Contest at DEF CON, will discuss the latest trends attackers are using.