Tag Archives: Critical Vulnerabilities

Puzzling: Five years old critical vulnerabilities exploited in November 2017

26 November 2017

Section Exploited Vulnerabilities of the Recorded Future Cyber Daily is sometimes really frightening. On November 9th, 2017, 249 successful exploits of CVE-2012-1823, a vulnerability in PHP, were recorded. This is hard to believe because CVE-2012-1823 was published on May 11th, 2012. Although a patch was available at the date of publication, it seems that the operators of this systems were not able to implement them within the past five years.

However, it would have been of urgent need in this case. CVE-2012-1823 is a so-called RCE (Remote Code Execution) vulnerability, which allows remote attackers to execute arbitrary code on a victim’s computer, and, in the worst case, to hijack the victim’s network.

RCE vulnerabilities are included in the critical vulnerabilities. Critical vulnerabilities are

  • exploitable from the network
  • need only low or medium skills to exploit
  • need no authentication
  • cause great damage, have high severity
  • allow remote attackers to execute arbitrary code on the victims computer

If an application system is operated in the DMZ, critical vulnerabilities must be patched directly upon publication to prevent attackers from getting onto your network. Or at least, between the time of publication and an exploit or proof of concept shows up. Since examples of how to exploit this PHP vulnerability were available in early May 2012, immediate action was required.

The big question is: Why were this vulnerable PHP versions not directly patched?

Exploitation of older vulnerabilities is not an isolated case. The HPE 2016 Cyber Risk Report shows, that in 2016

  • 47% of successful exploits use five or more years old vulnerabilities.
  • 68% of successful exploits use three or more years old vulnerabilities, 47% of them were critical vulnerabilities.
  • Stuxnet, CVE-2010-2568, was used in 29% of successful exploits.

An analysis of the critical vulnerabilities by vendors shows, that more critical vulnerabilities were found in non-Microsoft products than in Microsoft products.

Critical vulnerabilities 2010 - 2016

Critical vulnerabilities 2010 – 2016 by vendors. Click to enlarge.

But automated patch management is only available for Microsoft and few of the other vendors’ (e.g. Adobe, Oracle, SAP) products. Thus, we can expect that many critical vulnerabilities remain unpatched, which results in an ever-growing pool of opportunities for cyber criminals.

An ever growing pool of opportunities

An ever-growing pool of opportunities. Click to enlarge.

1) For the chart above I assumed that 50% of critical vulnerabilities remain unpatched. This assumption is based on the analysis of the 2017 NIST NVD data as of August 31st, 2017.

Since no automated patch management exists for PHP we can expect, that CVE-2012-1823 was rarely patched. But the worst is yet to come: From the HPE 2016 Cyber Risk Report we learn, that even six years old Microsoft vulnerabilities (Stuxnet, CVE-2010-2568) are not patched.

How to tackle this issue? From my point of view, the cause is compliance driven security. We often do patching of everything to meet compliance with a certain standard, instead of focusing on the real important issues, e.g., the critical vulnerabilities. Or, in other words, we close a lot of mouse holes while the barn door remains wide open.

WIth this, we must move from patching to vulnerability management, and priority patching for the critical vulnerabilities. Through a differentiated inspection of vulnerabilities we get out of the patch treadmill and can start working on the important cyber security issues.

By the way, if you haven’t subscribed to the Recorded Future Cyber Daily yet, consider to do it this week.

Have a great week.


To panic, or not to panic, that is the question: A simple panic calculator

22 October 2017

Last week, I had some interesting discussions about when to panic if a new vulnerability is published. With the concept of critical vulnerabilities in mind, this is an easy task:

My Panic Level Calculator

My Panic Level Calculator

To be honest, the panic in the media about the WPA2 / Krack vulnerability published last week appears somewhat exaggerated. CVE-2017-11292 however, a remote code execution vulnerability in Flash Player published on 16 October 2017, was not discussed in the media at all, although Kaspersky found an exploit on 10 October 2017.

Please keep in mind that critical vulnerability must be mitigated before an exploit is available on the market. The flash player vulnerability shows, that immediate action is required.

Have a great week!

Critical vulnerabilities require immediate action – How to prevent Equifax like attacks

23 September 2017

Critical Vulnerabilities are

  • exploitable from the network (Access Vector: Network),
  • require only low or medium skills to exploit (Access Complexity: Low or Medium),
  • require no authentication (Authentication: None),
  • cause great damage (Severity: High), and
  • allow remote attackers to execute arbitrary code on the victims’ computer

Among the vulnerabilities with CVSS vector (AV:N/AC:L/Au:N) or (AV:N/AC:M/Au:N) which cause great damage the last property makes the difference.

The infographic below shows that the number of critical vulnerabilities (320) is very small compared to the total number of vulnerabilities in 2016.

Critical Vulnerabilities 2016

Critical vulnerabilities 2016. Click to enlarge.

Nevertheless, immediate action is required because the reach of attacks is technically unlimited if critical vulnerabilities can be exploited.

Once an attacker has exploited a critical vulnerability in the DMZ he is able to execute arbitrary code on this computer. With this, he can probe the network for other computers with critical vulnerabilities or leverage Windows built-in weaknesses, configuration issues, and tools to explore the network until he finally gets to a computer which has a connection across a firewall to the company network.

Both, NotPetya and WannaCry exploited critical vulnerabilities. While WannaCry was just annoying, NotPetya caused multi-million dollar damage in companies across the world.


The TEAM approach for handling risks shows the direction for dealing with critical vulnerabilities.

Transfer: No insurer will take the risk because in the case of a critical vulnerability on a server in the DMZ both the probability of occurrence and the impact are high.

Eliminate: Is not possible, because this will result in loss of business.

Accept: No option because the probability of occurrence and the impact are high.

Mitigate: Patching is the only possible response in this case. Isolation of the system from the network will result in loss of business.


Under normal conditions, patches are available at the time of disclosure.

Rule: Critical vulnerabilities should be patched faster than exploits show up on the market.

With this, immediate action is required because very often exploits are available yet at the time of disclosure. In addition, we cannot expect that only ethical hackers publish vulnerabilities.


Critical Vulnerabilities Mitigation Process

Critical vulnerabilities mitigation process.

In the Equifax attack the critical vulnerability CVE-2017-5638 in the Apache Struts framework was used. A patch was available at the time of disclosure but apparently not applied.

Patching the Apache Struts framework is a challenging job.

Firstly, it is a challenge to identify the systems with the vulnerable framework installed.

Secondly, patches must be carefully tested prior implementation to avoid business loss.

Finally, the patches must be implemented manually because automated patch management is not available.

Thus, an up-to-date asset repository, a current QA system, and actual automated test routines are required to get the job done in the required short time frame.

To be honest, the Equifax attack remains a mystery for me. The IT shop of a billion dollar company should be able to deal with critical vulnerabilities in the required short time. Perhaps someone simply underestimated the risk.

For more details on the Equifax attack see Steven Bellovin’s post Preliminary Thoughts on the Equifax Hack published at CircleID.

Have a great weekend.