Get rid of network CREAPs

Last week, I was helping an enterprise-level security team identify seriously at-risk systems.  My scope included Windows and UNIX hosts, regardless of what applications these systems were hosting.  As a Qualys customer, they already scan close to 800 servers on a weekly basis, so I had fresh vulnerability information that I could analyze.  The team’s current approach to prioritizing patch efforts consist of a Top-25 report, which they customize to include not just the vulnerable system, but also the system admin and their manager.  These reports are discussed at management meetings, so they’re a great way to create traction and accountability.  After all, no one wants to see their name on that report week after week! Bullseye

I like the Top-25 approach, but it only shows systems across the enterprise that have the most weaknesses, regardless of attack vector or the presence of a working exploit.  Knowing which  systems have the most weaknesses is important, but it does not highlight the greatest risks.  For example, which database servers have at least one weakness that could give a remote intruder (or “trusted” user) root access if the hole was exploited?  After all, it only takes one weakness of this sort to cause mayhem of data-breach proportions.  Pinpointing these systems versus systems with the most weakness is critical.

With that in mind, I customized their report templates to search for what I call “Confirmed Remotely Exploitable And Patchable” vulnerabilities, or CREAPs for short.  We all know that creeps are bad, but CREAPs are really bad…they meet all of the following criteria:

  • Exploiting the weakness could lead to unauthorized root or admin access, or, critical files can be read or modified by unauthorized users.
  • An active exploit is published for the vulnerability through public or private sources like Canvas, SAINT, Metasploit, Core IMPACT
  • Local access is not required to exploit the weakness; the hole can be exploited over the network
  • A patch is available to fix the vulnerability

 

Sample of the Metasploit Framework 3.0 Beta ru...

When CREAP analysis is performed, volumes of vulnerability information become more meaningful.  A 200 page vulnerability report can be reduced to a dozen pages, listing just those systems that can be readily exploited using publicly available software.  But these weakness also have a published patch, making them “serious, but fixable.”  Now let’s pause for a moment — I’m certainly not suggesting that only CREAPs matter when it comes to patch management.  What I am suggesting, however, is that CREAPs pose a significant threat to networked servers and databases.  Consider how easy it is for cyber-criminals (and professional pen-testers like me) to gain access to an internal PC with a simple but effective phishing attack, or a “weaponized” Adobe PDF attachment.  Once the bad guys are on a PC or laptop behind the corporate firewall, it’s easy to locate and exploit mission critical systems with REAPs.

Many organization have no idea how many high-risk server or PC-level vulnerabilities there are on the network.  Others know exactly how many there are and a paralyzed by the sheer number of weakness. I once worked with a state agency to deploy a vulnerability management solution.  After one week of analysis, we found over 8,000 high-risk weakness across the enterprise.  With such a massive number, where do you start?  You have to start somewhere — beginning with CREAPs will yield the greatest return for the effort spent.  With limited budget, staff, and time, that’s the kind of return you need.

As always, feedback is welcome.   — Simon

Enhanced by Zemanta

Leave a Reply

Your email address will not be published. Required fields are marked *