Proactively Hardening Systems: Application and Version Hardening

Tuesday, May 20, 2014

Tripwire Inc

Bd07d58f0d31d48d3764821d109bf165

By: Michael Thelander 

The first article in this series examined configuration hardening, essentially looking at ports, processes and services as the “doors, gates and windows” into a network where security configuration management becomes the job of determining which of these gateways should be open, closed, or locked at any given time. Now it’s time to look at application and version hardening.

Application and Version Hardening

If configuration hardening settings are “conditional,” meaning they must find and keep that balance between security and productivity, hardening against known vulnerabilities in applications and versions is much more black-and-white.

If an exploit path has been found in an operating system or application the vendor rushes to create a patch or upgrade that removes the vulnerability. “Hardening” in this sense means “make sure the holes are known and that the most current security patches are deployed.”

To go back to our “secure house” analogy for a moment, imagine that the house I’m protecting has three external doors and that they all use Secure-A-Door Model 800 high-strength locks.

But a tester at the Secure-A-Door factory (or worse a professional burglar) has just discovered an interesting thing: if you slide a credit card along the door jamb at 15 degrees while pulling up on the handle, the Secure-A-Door 800 pops open like a Coke can.

One of most famous examples of this exploitation began in 2008. That’s when the makers of the Conficker worm discovered and exploited an underlying weakness in Port 445 of the Windows operating system.

The worm created a remote procedure call that dropped a DLL on the system, unloaded two distinct packets for data and code, and hid itself in a remote thread to make itself at home. (It was infinitely more complex and clever than that, but you get the idea.)

In effect, the worm popped the Secure-A-Door Model 800, let itself in, repaired the lock, installed a new phone line to listen for orders, and sat in a comfy chair waiting for instructions. It was able to leverage the Internet, could register new domain names in which to hide, and created an extensive botnet that by 2010 had infected, according to Panda Security, as many as 18 million PCs – 6 percent of the world’s PC population at the time.

This type of design failure or exploit is usually repaired by a patch. In the case of Conficker, Windows Security bulletin MS08-067 made the danger known to the worldwide Microsoft community and introduced a patch to prevent easy violation of Port 445.

The MS bulletin was in turn translated by the Common Vulnerabilities and Exposures (CVE) site as CVE-2008-4250 and given a Common Vulnerability Scoring System (CVSS) rating of 10—the most severe rating possible.

Vulnerability management systems, unlike security configuration management systems that check to see that doors and gates and windows are locked, do their part in system hardening differently. They make sure the proper patch levels are maintained and that any available defenses have been utilized, by:

  • Proactively discovering whether I have any Secure-A-Door Model 800 locks installed
  • If I do, reporting on whether they’re the corrected “B” version made after October 2012
  • Verifying that any “bad” ones I have are only on inside doors and don’t serve as a primary defense

Vulnerability management systems enable continuous hardening by making sure that CVE-2008-4250 – and its many thousands of friends – are understood, mitigated, and more-or-less unexploitable when the right steps are taken.

More mature solutions provide an ongoing assessment of overall risk based on whether these vulnerabilities are mitigated or ignored.

This was cross-posted from Tripwire's The State of Security blog.

10685
Operating Systems SPAM Viruses & Malware Privacy Vulnerabilities Webappsec->General
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.