Tag Archives: Stuxnet

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.

Isolation of Everything

9 January 2016

I am currently preparing a presentation on IT security matters for the plant safety group of the Verband der Chemischen Industrie (VCI). Plant safety and IT security are closely linked, in particular because more and more safety equipment (e.g. safety relief valves) have built-in computers and networking options which allow data gathering and remote configuration and testing up to a certain extend.

To create awareness for the new challenges I searched for examples of successful cyber-attacks in the process industry. Stuxnet comes immediately into mind but is somewhat behind the times. In December 2014 a cyber-attack on a German steel mill was widely reported in the press.

On January 8, 2015 Kim Zetter wrote in WIRED ‘A Cyberattack Has Caused Confirmed Physical Damage for the Second Time Ever’. A post from Greg Masters in SC Magazine on December 23, 2014 was titled ‘Cyberattack fells German iron plant’.

An attacker has to pass some hurdles to get from the Internet to the Process Control System. Usually Process Control Systems (PCS) are well protected by a cascade of firewalls which isolate the control systems from the process plant network and the process plant network from the office network.

But, as in many other cases, the starting point was a phishing attack. In the BSI publication ‘The State of IT Security in Germany 2014’ published on December 17, 2014 we read:

The attackers used spear phishing e-mails in tandem with sophisticated social engineering to gain initial access to the steel mill’s office network. From there they worked their way progressively into the production networks.

The sentence ‘From there they worked their way progressively into the production networks.’ is of particular interest. It indicates a problem that is widely ignored by the plant operators because the firewalls give them a false sense of security.

For simplifying IT operations very often the same Active Directory is used for managing the Windows accounts of the plant operators in the office network and the plant network. But network isolation and segmentation by firewalls blocks traffic only on the OSI layers 1 .. 3, not on layer 7, where Active Directory works. Once an attacker manages to get on the office network it’s only a matter of time when he finds an operator account that grants him access to the plant network.

Thus a first step towards enhanced security in process plants is to isolate the Active Directories in the office and the plant network. In addition, access to email and internet from the plant network must be blocked, if possible with technical means.

The general design principle is ‘Isolation of Everything’ – Cyber attackers raise only a weary smile (LOL) at the Layer over Layer (LoL) approach with firewalls.

Have a good weekend.