Tag Archives: Critical Vulnerabilities

CVE-2021-21972 – Kritische Schwachstelle in vSphere Client. Was hätte Peter F. Drucker dazu gesagt?

6. März 2021

Am 23. Februar 2021 veröffentlichte VMware(1) die Schwachstelle CVE-2021-21972(2) im vSphere HTML 5 Client. Bei CVE-2021-21972 handelt es sich um eine kritische Schwachstelle, vergleichbar mit Schwachstelle CVE-2019-19781 im Citrix Application Delivery Controller, die 2020 im Angriff auf die Uni-Klinik Düsseldorf verwendet wurde.

Schwachstelle CVSS V3 Vektor
Kritische Schwachstelle AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Definition
CVE-2021-21972 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H VMware vSphere RCE
CVE-2019-19781 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Citrix Application Delivery Controller RCE, Uni-Klinik Düsseldorf, 2020

Die Ausnutzung einer kritischen Schwachstelle führt zum vollständigen Verlust der Integrität des Systems (I:High), den ich höher bewerte als den vollständigen Verlust der Verfügbarkeit oder der Vertraulichkeit. Der vollständige Verlust der Integrität hat zur Folge, dass der Angreifer unerkannt und unbemerkt beliebige Änderungen am System vorzunehmen. Das kann in der Prozessindustrie, wie das Beispiel Triton(3) zeigt, zu Explosionen führen.

CVE-2021-21972 ist wie CVE-2019-19781 eine Remote-Code-Execution-Schwachstelle. RCE-Schwachstellen ermöglichen dem Angreifer, beliebigen Code im Systemkontext, also mit den höchsten Berechtigungen, auszuführen.

In beiden Fällen ist die Access Complexity AC:Low. Der Angreifer benötigt nur wenig Knowhow zur Durchführung des Angriffs. Steht das betroffene System in der DMZ, so kann prinzipiell jeder der ca. 4 Mrd. Internetteilnehmer mit wenig Aufwand einen Angriff starten und das System übernehmen.

Eine kritische Schwachstelle sollte also umgehend nach ihrer Veröffentlichung gepatcht werden. Ist dies nicht möglich, so sollten direkt risiko-reduzierende Maßnahmen ergriffen werden, um einem Verlust der Integrität vorzubeugen. Sind weder Patches noch risiko-reduzierende Maßnahmen bekannt, so sollte der Zugriff vom Internet auf das betroffene System deaktiviert werden.

vSphere Client-Systeme in Region Kassel

vSphere Client-Systeme in Region Kassel, Quelle: Shodan

Im Fall CVE-2019-19781 dauerte die Bereit-stellung des Patches einen Monat. Zudem wurde die Schwachstelle bereits vor der Veröffentlichung in Angriffen genutzt.
CVE-2019-19781 war also ein Zero-Day-
Exploit. Das ist bei CVE-2021-21972 nicht der Fall. VMware(1) veröffentlichte mit der Schwachstelle Patches und Workarounds. Workarounds sind notwendig in der Zeit bis der Patch ausgerollt und aktiviert ist. Damit konnten die ca. 6.500 betroffenen vSphere Clients, die direkt vom Internet erreichbar sind, effizient geschützt werden. Da bereits am Tag nach der Veröffentlichung ein Exploit(4) verfügbar war mussten die Systeme umgehend gepatcht werden. Und IT-Abteilungen haben dies schnell, effizient und mit viel persönlichem Einsatz getan.

Die große Frage ist: Warum sind diese vSphere Client-Systeme überhaupt vom Internet erreichbar? Kritische Systeme wie die Managementsysteme für eine VMware-Infrastruktur sollten nie vom Internet erreichbar sein. Das gilt nicht für den Citrix Application Delivery Controller. Dessen Aufgabe ist die sichere Bereitstellung von internen Ressourcen für Anwender, die vom Internet zugreifen. Im Fall VMware haben wir Probleme geschaffen, die wir bei Veröffentlichung einer neuen Schwachstelle mit großer Effizienz lösen. Hierzu sagt Peter F. Drucker(5):

“There is surely nothing quite so useless as doing with great efficiency what should not be done at all.”

Ist CVE-2021-21972 ein Einzelfall? Leider nicht. Nur zwei Beispiele:

  • Stand 6.3.2021 listet Shodan 1,265,880 Systeme mit offenem SMB Port, obwohl WannaCry 2017 solche Systeme für den Zugriff auf interne Computernetzwerke nutzte.
  • Shodan listet 3,974,926 Systeme, die per RDP erreichbar sind, obwohl CVE-2019-0708 (BlueKeep) mit hohem Aufwand weltweit gepatcht wurde um Angriffe von WannaCry-Ausmaßen zu verhindern.

In beiden Fällen müssen wir die Frage stellen: Ist das notwendig? Wie viele IT-Experten, die wir dringend für Digitalisierungsprojekte benötigen, arbeiten an der Lösung von IT-Problemen, die nicht existieren sollten? Können wir uns eine derartige Verschwendung von Expertise leisten?

Peter F. Druckers Veröffentlichung “Managing for Business Effectiveness” aus dem Jahr 1963 ist wieder top aktuell.

Schönes Wochenende.

Quellen

  1. VMSA-2021-0002 [Internet]. VMware. [zitiert 25. Februar 2021]. Verfügbar unter: https://www.vmware.com/security/advisories/VMSA-2021-0002.html
  2. NIST Information Technology Laboratory. NVD – CVE-2021-21972 [Internet]. NIST National Vulnerability Database. 2021 [zitiert 5. März 2021]. Verfügbar unter: https://nvd.nist.gov/vuln/detail/CVE-2021-21972
  3. Sobczak B. SECURITY: The inside story of the world’s most dangerous malware [Internet]. 2019 [zitiert 11. Mai 2019]. Verfügbar unter: https://www.eenews.net/stories/1060123327
  4. Klyuchnikov M. Unauthorized RCE in VMware vCenter [Internet]. PT SWARM. 2021 [zitiert 6. März 2021]. Verfügbar unter: https://swarm.ptsecurity.com/unauth-rce-vmware/
  5. Drucker PF. Managing for Business Effectiveness. Harvard Business Review [Internet]. 1. Mai 1963 [zitiert 6. März 2021]; Verfügbar unter: https://hbr.org/1963/05/managing-for-business-effectiveness

BSI: Hackerattacke auf Uniklinik Düsseldorf wäre verhinderbar gewesen

16. Januar 2021

Am 11. Januar 2021 berichtete RP Online[i], die „Hackerattacke auf Uniklinik Düsseldorf wäre verhinderbar gewesen“. Laut RP Online sagte der Präsident des BSI auf einen Kongress zur inneren Sicherheit, der Hackerangriff „hätte schon mit dem einfachen Grundschutz des BSI verhindert werden können“. Der Bericht wurde auf LinkedIn am 12.1.2021 geteilt und kommentiert.

Hat das BSI recht? Hätte die Vorgehensweise nach BSI Grundschutz den Angriff verhindert?

Welche Schwachstelle wurde von den Angreifern für den initialen Zugriff genutzt?

Heise Online[ii] berichtet am 22.9.2020, dass vermutlich die Shitrix bezeichnete Schwachstelle CVE-2019-19781 zum Einstieg ins das Netzwerk der Uniklinik verwendet wurde. CVE-2019-19781 ist eine Schwachstelle in den Citrix Produkten Citrix Application Delivery Controller, Citrix Gateway und Citrix SD-WAN WANOP Appliance. Diese Citrix-Produkte werden zur Absicherung des externen Zugriffs auf das private Netzwerk einer Organisation eingesetzt. Sie werden in der Internet-DMZ betrieben und sind in der Regel für alle Internetteilnehmer sichtbar und damit von diesen angreifbar.

Laut Citrix[iii] handelt es sich bei CVE-2019-19781 um eine Remote-Code-Execution-Schwachstelle (RCE). Der Access-Vector[iv] ist CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, die Severity ist 9.8.

Die folgende Tabelle zeigt die zeitliche Entwicklung von der Schwachstelle bis zum Patch.

16.12.2019 Citrix veröffentlicht mitigierende Maßnahmen[v] für CVE-2019-19781, da die Schwachstelle bereits in Angriffen genutzt wurde.
17.12.2019 Citrix veröffentlicht die Schwachstelle[iii].
18.12.2019 Warnung[vi] des BSI, Risikostufe 3.
27.12.2019 Veröffentlichung in der NIST NVD Datenbank[iv].
11.1.2020 Veröffentlichung des ersten Exploit EDB-ID 47901[vii] in der Exploit Datenbank.
13.1.2020 Update Warnung[viii] des BSI, Risikostufe 4.
19.1.2020 Citrix veröffentlich die ersten korrigierten Programmversionen.
24.1.2020 Für alle Programmversionen sind Patches vorhanden.

Citrix berichtet[iii] am 17.12.2019, dass „Exploits of this issue on unmitigated appliances have been observed in the wild. Citrix strongly urges affected customers to immediately upgrade to a fixed build OR apply the provided mitigation which applies equally to Citrix ADC, Citrix Gateway and Citrix SD-WAN WANOP deployments.” Damit handelte es sich bei CVE-2019-19781 um eine Zero-Day-Schwachstelle. Hier ist Eile geboten. Deshalb ist es nicht ungewöhnlich, dass Citrix bereits einen Tag vor der Schwachstelle mitigierende Maßnahmen[v] veröffentlicht hat.

Welche Optionen hat man in derartigen Szenarien?

Option Patchen/Mitigieren

Das Australien Cyber Security Centre (ASCS) macht im Abschnitt System Patching des “Australian Government Information Security Manual”[ix] klare Vorgaben:

Security Control: 1144; Revision: 9; Updated: Sep-18; Applicability: O, P, S, TS; Priority: Must Security vulnerabilities in applications and drivers assessed as extreme risk are patched, updated or mitigated within 48 hours of the security vulnerabilities being identified by vendors, independent third parties, system managers or users.

CVE-2019-19781 hat Severity 9.8, die Ausnutzung der Schwachstelle führt zum vollständigen Verlust der Integrität des Systems. Damit fällt die Schwachstelle in diese Kategorie. Da kein Patch verfügbar war, müssen die von Citrix am 16.12.2020 veröffentlichten mitigierenden Maßnahmen spätestens am 19.12.2019 umgesetzt sein.

Im BSI Grundschutz, Edition 2020[x] vermisst man im Abschnitt OPS.1.1.3: Patch- und Änderungsmanagement diese klaren Hinweise. OPS.1.1.3.A1 gibt folgenden Hinweis: „Patches und Änderungen SOLLTEN nach Wichtigkeit und Dringlichkeit klassifiziert und entsprechend umgesetzt werden.“

Das SOLLTEN ist hier irritierend. SOLLTE bedeutet im Sinne des Grundschutzes, „dass eine Anforderung normalerweise erfüllt werden muss, es aber Gründe geben kann, dies doch nicht zu tun“. Das ist bei CVE-2019-19781 nicht angemessen, da Citrix bereits von “Exploits in the Wild” berichtet hatte. Hier ist ein MÜSSEN im Sinne des Grundschutzes erforderlich.

Folgt man der Einstufung „Risikostufe 3“ in der BSI Warnung von 18.12.2019, so würde man aus meiner Sicht nicht umgehend mitigierende Maßnahmen ergreifen.

Option Firewall mit IPS (virtuelles Patchen)

Nextgen Firewalls mit IPS (Intrusion Prevention System) können gerade bei Zero-Day-Schwachstellen über die Möglichkeit des virtuellen Patchens Cyberangriffe abwehren. Der Firewall entdeckt im Datenstrom Versuche, die Schwachstelle CVE-2019-19781 auszunutzen und blockt diese.

IPS hätte in diesem Fall mit hoher Wahrscheinlichkeit den Angriff nicht verhindert. Checkpoint hat etwa erst am 9.1.2020 ein passendes IPS Muster bereitgestellt, Fortinet am 13.1.2020

Option Application Whitelisting

Die betroffenen Citrix –Systeme können als virtuelle Appliance oder als Anwendung auf einem Linux-System (Bare-Metal) betrieben werden.

Im Fall der Appliance ist Application Whitelisting nicht möglich, da der Betreiber keine Zusatzsoftware installieren kann.

In einer Bare-Metal-Umgebung kann der Systemverantwortliche eine Application Whitelisting-Lösung einsetzen. Da Linux-Server als sicherer wahrgenommen werden als Windows-Server, wird häufig auf zusätzliche Sicherheitslösungen verzichtet.

Application Whitelisting hätte die Übernahme des Citrix Systems in der Bare-Metal-Umgebung mit hoher Wahrscheinlichkeit verhindert, da bei der Übernahme des Systems Code eingeschleust und ausgeführt wird.

Option System von Netzwerk trennen

Liefert der Hersteller weder Patches noch Hinweise auf mitigierende Maßnahmen, so ist die Trennung vom Netzwerk eine mögliche Option. Systemverantwortliche, IT-Manager und IT-Security-Manager sollten diese Option immer vorbereiten und trainieren. Das Risiko aus dem Verlust des Remotezugriffs auf Dienste muss in Relation zu dem Risiko gesetzt werden, das sich durch die Einschränkungen im Betrieb der kritischen Infrastruktur (Universitätsklinik) für die Bevölkerung ergibt.

Wichtig! Systemverantwortliche müssen vorab vom Management autorisiert werden, die Trennung durchzuführen, und dürfen nicht zögern, die Trennung durchzuführen.

Zusammenfassung

Mit Patchen/Mitigieren, Vorgehensweise nach ASCS, hätte die Uniklinik Düsseldorf den Angriff mit hoher Wahrscheinlichkeit verhindern können.

Nach BSI Grundschutz hängt es aus meiner Sicht ausschließlich von der Einschätzung des Systemverantwortlichen ab, ob die mitigierenden Maßnahmen mit der gebotenen Geschwindigkeit umgesetzt werden. Für den Betrieb einer kritischen Infrastruktur ist diese Vorgehensweise zu unverbindlich. Der Angriff hätte aus meiner Sicht durch BSI Grundschutz nicht verhindert werden können.

Die Option System vom Netzwerk trennen hätte den Angriff sicher verhindert.

Firewall IPS hätte den Angriff wahrscheinlich nicht verhindern können, da die Muster zur Exploit-Erkennung zu spät bereitstanden.

Die Option Application Whitelisting hätte den Angriff nur in der Bare-Metal-Umgebung verhindern können.

Haben Sie sich schon mit der Option System vom Netzwerk trennen beschäftigt? Insbesondere in kritischen Infrastrukturen? Über ein Feedback würde ich mich sehr freuen.

Schönes Wochenende.

[i] RP ONLINE. Bundesamt für IT-Sicherheit: Hackerattacke auf Uniklinik Düsseldorf wäre verhinderbar gewesen [Internet]. RP ONLINE. 2021 [zitiert 16. Januar 2021]. Verfügbar unter: https://rp-online.de/nrw/staedte/duesseldorf/uniklinik-duesseldorf-hackerattacke-waere-laut-bsi-verhinderbar-gewesen_aid-55626401

[ii] von Westernhagen O. Uniklinik Düsseldorf: Ransomware „DoppelPaymer“ soll hinter dem Angriff stecken [Internet]. Heise Online Security. 2020 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.heise.de/news/Uniklinik-Duesseldorf-Ransomware-DoppelPaymer-soll-hinter-dem-Angriff-stecken-4908608.html

[iii] Citrix. CVE-2019-19781 – Vulnerability in Citrix Application Delivery Controller, Citrix Gateway, and Citrix SD-WAN WANOP appliance [Internet]. Support Knowledge Center. 2019 [zitiert 16. Januar 2021]. Verfügbar unter: https://support.citrix.com/article/CTX267027

[iv] NIST National Vulnerability Database. NVD – CVE-2019-19781 [Internet]. NATIONAL VULNERABILITY DATABASE. 2020 [zitiert 16. Januar 2021]. Verfügbar unter: https://nvd.nist.gov/vuln/detail/CVE-2019-19781

[v] Citrix. Mitigation Steps for CVE-2019-19781 [Internet]. Support Knowledge Center. 2019 [zitiert 16. Januar 2021]. Verfügbar unter: https://support.citrix.com/article/CTX267679

[vi] Bundesamt für Sicherheit in der Informationstechnik. BSI – CERT Bund -Meldungen – CB-K19/1093 [Internet]. Service. 2019 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.bsi.bund.de/SharedDocs/Warnmeldungen/DE/CB/2019/12/warnmeldung_cb-k19-1093.html

[vii] Project Zero India. Citrix Application Delivery Controller and Citrix Gateway – Remote Code Execution (PoC) [Internet]. Exploit Database. 2020 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.exploit-db.com/exploits/47901

[viii] Bundesamt für Sicherheit in der Informationstechnik. BSI – CERT Bund -Meldungen – CB-K19/1093 Update 2 [Internet]. 2020 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.bsi.bund.de/SharedDocs/Warnmeldungen/DE/CB/2020/01/warnmeldung_cb-k19-1093_update_2.html

[ix] Australian Cyber Security Centre. Australian Government Information Security Manual [Internet]. 2019 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.cyber.gov.au/sites/default/files/2019-04/Australian%20Government%20Information%20Security%20Manual%20(APR19)_0.pdf

[x] Bundesamt für Sicherheit in der Informationstechnik. IT-Grundschutz-Kompendium [Internet]. Reguvis Fachmedien GmbH; 2020 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium/IT_Grundschutz_Kompendium_Edition2020.pdf

Have you patched these top 10 routinely exploited vulnerabilities?

16 May 2020

On Tuesday, CISA published the alert (AA20-133A) on the „Top 10 Routinely Exploited Vulnerabilities“(1). A day later, Zeljka Zorz raised the absolutely legitimate question „Have you patched these top 10 routinely exploited vulnerabilities?“(2) on HELPNETSECURITY.

A query against the NIST NVD and the Exploit-DB shows a gloomy picture:

Top 10 Exploited Vulnerabilities

Top 10 Exploited Vulnerabilities

For the red highlighted vulnerabilities the exploit was available at the day of publication in the NVD. For the green highlighted vulnerabilities the exploit was published shortly after the vulnerability. So, the question should be:

How fast did you patch these top 10 routinely exploited vulnerabilities?

These are telling examples and they are not isolated:

Exploit Publication Date relative to CVE Publication Date

Exploit Publication Date relative to CVE Publication Date

The data from 2013 – 2019 for critical vulnerabilities show:

  • 41% of exploits were published before or at the same day the CVE was published, and
  • 43% of Exploits were published in the range between 10 days before and 10 days after the CVE.

Time is crucial in cyber space operations. In high risk domains, critical vulnerabilities should be patched at least 24 hours after the patch is available. If a vendor cannot provide a patch in time mitigting measures should be applied, in the worst case, systems must be removed from the internet.

Remind the Equifax case (CVE-2017-5638) from 2017.

Have a good weekend.

References

  1. CISA. Top 10 Routinely Exploited Vulnerabilities [Internet]. National Cyber Awareness System. 2020 [zitiert 16. Mai 2020]. Verfügbar unter: https://www.us-cert.gov/ncas/alerts/aa20-133a

  2. Zorz Z. Have you patched these top 10 routinely exploited vulnerabilities? [Internet]. Help Net Security. 2020 [zitiert 14. Mai 2020]. Verfügbar unter: https://www.helpnetsecurity.com/2020/05/13/routinely-exploited-vulnerabilities/

What is the Most Secure Web Browser?

23 September 2018

For some weeks now I am busy with patch strategy and vulnerability management. When new critical vulnerabilities shows up two questions must be addressed:

  1. How fast must we patch the vulnerable systems?
  2. What vulnerabilities must be patched with highest priority? Or mitigated, if a patch is not available in due time.

Speed is the key in cyber security. The faster we find and patch vulnerable systems the greater is the chance that cyber criminals cannot exploit the vulnerabilities.

The exploit is the weapon in cyber warfare. A vulnerability as such increases the potential risk only. Once an exploit is published that can leverage the vulnerability, the vulnerability becomes a real risk. And if the exploit is “in the wild”, i.e. if the exploit is actively used by cyber criminals for attacks, the IT organization is on red alert.

Unfortunately, no one knows when an exploit spreads in the wild. Therefore, the cautious answer to the above questions is:

“The moment an exploit for a critical vulnerability is published it must be patched directly, at least on critical systems. If a patch is not available proper protective measures must be applied to mitigate the risk effectively.”

Browsers are the most critical systems because they are used in a hostile environment. Browsers are very complex applications, thus prone of errors.  Between 2013 and 2017 about 11% of 40671 vulnerabilities in total were found in the 4 major browsers Chrome, Firefox, Internet Explorer and Edge.

Market Share Browsers 2013 - 2017

Market Share Browsers 2013 – 2017. Data source: StatCounter

Browser Vulnerabilities 2013 - 2017

Browser Vulnerabilities 2013 – 2017

It remarkable to see that 67% of all browser vulnerabilities are related to IE, Edge and Firefox although they have only a small market share (11% in 2017).

Exploit publication date relative to CVE publication date

Exploit publication date relative to CVE publication date 2013 – 2017

The graphic above shows the number of exploits that are published within one month before the CVE is published compared to the number of exploits published within one month after the CVE is published.

Except for Chrome and Firefox the majority of exploits is published after the vulnerability is published. Nevertheless, we have to patch immediately on publication of a CVE.

How many exploits spread in the wild? This question is hard to answer. The Symantec attack signatures give a useful indication. “An attack signature is a unique arrangement of information that can be used to identify an attacker’s attempt to exploit a known operating system or application vulnerability.” 

Exploits in the Wild 2013 - 2017

Exploits in the Wild 2013 – 2017

This is an amazing result, isn’t it.

Have a great week!

Data sources

  1. NIST. NVD Database. https://nvd.nist.gov/
  2. Offensive Security. Exploit Database. https://www.exploit-db.com
  3. Andrea Fioraldi. CVE Searchsploit.
    https://github.com/andreafioraldi/cve_searchsploit/tree/master/cve_searchsploit
  4. NIST. EXPLOIT-DB Reference Map. http://cve.mitre.org/data/refs/refmap/source-EXPLOIT-DB.html
  5. Symantec.com. Attack Signatures.  https://www.symantec.com/security_response/attacksignatures/

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.

Mitigation

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.

Urgency

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.

Equifax

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.