Attacks/Breaches
10/1/2013
12:31 PM
Gunter Ollmann
Gunter Ollmann
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Penetration Testing With Honest-To-Goodness Malware

When did penetration-testing methodologies stop replicating the vectors attackers make?

Popular fiction usually dictates that the primary cyberfoe of big business is a young, nerdish, and exceedingly smart computer hacker with a grudge against practically anyone and everyone. It may be this particular cliched (and false) stereotype of a hacker that many business analysts and executives have, in turn, used as justification for testing the defenses of their organizations in a particular way. While some may supplement this image of a hacker with concrete bunkers filled with uniformed cyberwarriors if they feel worthy of state-initiated attacks, it is a sad fact that many of the methodologies currently employed by organizations to evaluate their tiered defenses are tired and dated.

The reality of the situation is that organizations are much more likely to be breached through fairly average malware than through the deliberate and chained exploitation of system vulnerabilities. That's not to say "classic" hacking isn't a problem, but the scale of the threat today is like battling mosquitoes while ignoring the lion gnawing at your arm.

Modern penetration-testing methodologies continue to follow a very predictable pattern,and practically every assessment I've ever been involved in or have overseen during the past decade has yielded vulnerabilities that were critical in nature. While these vulnerabilities are flagged for remediation and are often fixed within days of identification, the organization is still left to battle a barrage of social-engineering attacks designed to install malware on victim devices and to serve as jump points into other sectors of the business.

In recent years, organizations have increased the number and sophistication of the defensive layers they use to battle malware-based intrusion. In general, these defenses have improved the security stature of those organizations that make the investment. However, the increased need for roaming user support, BYOD, encrypted communications, and third-party app markets has, in turn, exposed those same organizations to new kinds of attack vectors for which they have little appreciation of the dynamics of the threat or the ability to quantify the status of their recently deployed anti-malware defenses.

It has become necessary for penetration-testing methodologies to better reflect the true nature of the threat and to replicate the methods used by an attacker. In particular, penetration testers need to now incorporate malware and malware-specific delivery techniques into their testing routines.

As trivial as it may seem, including malware into a penetration test or security assessment is not a simple task. The variety of delivery vectors and the effort needed to stage an attack is something few penetration testers have had to involve themselves with in the past. There's also the complexity of crafting malware-based payloads that not only report back their successes, but also provide for rapid cleanup after an engagement is over.

That said, it would be remiss of security consultants or ethical hackers to not test the robustness and capability of their clients' networks to counter malware-based threat vectors. The choice to not employ malware for lateral movement and compromise within a client's network may be a reflection of inadequate scoping or a poor understanding of the modern threat spectrum.

Regardless, the onus is on security consultants to duplicate the means and capability of a modern hacker -- and, by foregoing malware, they are playing to outdated threats and past stereotypes.

-- Gunter Ollmann, CTO, IOActive Inc. 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
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
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
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.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.