Why You Should Care About Legacy Patches

June 02, 2015 | Heroix Staff

As we noted in previous posts on security best practices and unsupported releases, unpatched applications and operating systems can be a significant security vulnerability.  Verizon’s 2015 DBIR includes a survey of the Common Vulnerabilities and Exposures (CVEs) observed in security incidents in 2014.  They found that “Ten CVEs account for almost 97% of the exploits observed in 2014”, with the top 10 threats ranging in age from 1999-2014:

CVE-2002-0012  SNMP V1 trap vulnerabilities
CVE-2002-0013 SNMP V1 GetRequest, GetNextRequest and SetRequest vulnerabilities
CVE-1999-0517 SNMP default (public) or null community string
CVE-2001-0540 Malformed RDP requests cause memory leak in Windows NT/2000 Terminal Services
CVE-2014-3556 I/O buffering bug in nginx SMTP proxy allows for command injection attack into encrypted SMTP sessions.  (Fixed in nginx 1.7.4)
CVE-2012-0152 Windows 7/2008 Terminal Server denial of service vulnerability
CVE-2001-0680 QPC’s QVT/Net 4.0 and AVT/Term 5.0 ftp daemon can allow remote users to traverse directories
CVE-2002-1054 Pablo ftp server allows arbitrary directory listing
CVE-2002-1931 PHP Arena paFileDB versions 1.1.3 and 2.1.1 vulnerable to cross site scripting
CVE-2002-1932 Windows XP and 2000 do not send alerts when Windows Event Logs overwrite entries

While these CVEs covered the majority of the observed incidents, patching only the applicable CVEs in this list is not a shortcut to 97% safety.  Thousands of vulnerabilities exist, more are discovered on a daily basis, and any vulnerability present on your system is subject to exploitation.  Even if you do get everything in your environment patched you will still need to apply new patches in a timely manner.  To get an idea of exactly what “timely manner” means we can use the DBIR’s examination of how much time it took for newly discovered CVEs to be exploited after they were published:

Half of the CVEs exploited in 2014 fell within two weeks. What’s more, the actual time lines in this particular data set are likely underestimated due to the inherent lag between initial attack and detection readiness (generation, deployment, and correlation of exploits/signatures).

The timeline between a bug’s discovery and exploitation puts “timely manner” somewhere between “drop everything and do it now” and “wait for the next maintenance window” depending on the severity of the problem and your organization’s sensitivity to patch associated downtime.

This prompts the question: Should you set all your software to update automatically and clean up after any patch bugs and outages that might cause software issues?  In a previous post we looked at the topic of automatic patch updates, and listed some criteria for determining when to apply patches.  Your patching policy will be a balance between catching up on old vulnerabilities, patching new ones in a timely manner, and maximizing availability for your users.

Regardless of how well caught up you are on patches there will be unavoidable holes in patch coverage and security.  As with the Shellshock bug last September, the initial patches needed to be revised and patches were not available for all platforms at the same time.  The nature of zero day exploits is that the bug is already there, you just don’t know about it.  Effective patch management will minimize but not eliminate your security risks.  You still need to monitor your systems for unexpected behavior that could indicate a security problem.