Tag Archives: Vulnerability Management

Adobe Flash zero day exploited in the wild. Remote code execution vulnerabilities are hacker’s favorites!

8 December 2018

On December 5th, 2018 Adobe published security bulletin APSB18-41[1] for critical vulnerability CVE-2018-15928 in the widely used Flash Player. Gigamon Applied Threat Research (ATR) reported the vulnerability on November 29th, 2018 to Adobe. They detected the issue some days before while analyzing a malicious word document that was uploaded to VirusTotal from a Ukrainian IP address. For a detailed analysis of the attack and the vulnerability see [2][3].

Successful exploitation of CVE-2018-15928 could lead to Arbitrary Code Execution in the context of the current user. Due to RedHat the CVSS3 Base Metrics is CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H with a CVSS3 Base Score of 8.8.

Zero days are not a rare phenomenon. Between 2013 and 2017[4] about 60% of the exploits were disclosed before the related CVE was published.

For about 20% of vulnerabilities in the NVD exploits are published in the exploit database[5]. Only about 1% of the vulnerabilities are exploited in the wild. Thus CVE-2018-15928 is a really rare event.

Remote code/script execution (RxE) vulnerabilities like CVE-2018-15928 represent about 20% of all vulnerabilities. 43% of the exploits published between 1988 and 2018 are related to RxE vulnerabilities.

Remote Code Execution Vulnerabilities. Data: 1988-2018

RxE Vulnerabilities. Data: 1988-2018

Exploits for Remote Code Execution Vulnerabilities. Data: 1988-2018

Exploits for RxE Vulnerabilities. Data: 1988-2018

About 5% of the RxE vulnerabilities are exploited in the wild.

This means, that RxE vulnerabilities are 5 times more often exploited in the wild then Non-RxE vulnerabilities. They are hacker’s favorites!

What does the mean for our vulnerability management strategy?

  • The remediation process must be started directly upon publication of an RxE vulnerability in the NVD or the disclosure of an exploit for an RxE in the exploit database.
  • In scope for the first remediation wave must be at least all systems facing the internet, e.g. workstations, servers in the DMZ or in public clouds.
  • Gathering intelligence about new vulnerabilities from a plethora of publicly available sources (OSINT) is a time-consuming task. A threat intelligence service can speed-up information gathering and reduces the workload of your IT security staff.
  • In addition, since remediation takes some time, it makes sense to invest in means for enhancing the resilience of application systems.

Expect the worst and be prepared. Or, to echo Hamlet:

To be, or not to be, that is the question:
Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing, end them? To die: to sleep;

Have a good weekend.


  1. Adobe. Security updates available for Flash Player | APSB18-42 [Internet]. 2018 [cited 2018 Dec 8]. Available from: https://helpx.adobe.com/security/products/flash-player/apsb18-42.html

  2. Gigamon Threat Research Team. Adobe Flash Zero-Day Exploited In the Wild [Internet]. Gigamon ATR Blog. 2018 [cited 2018 Dec 8]. Available from: https://atr-blog.gigamon.com/2018/12/05/adobe-flash-zero-day-exploited-in-the-wild/

  3. Qihoo 360 Advanced Threat Response Team. Operation Poison Needles – APT Group Attacked the Polyclinic of the Presidential Administration of Russia, Exploiting a Zero-day [Internet]. 2018 [cited 2018 Dec 8]. Available from: http://blogs.360.cn/post/PoisonNeedles_CVE-2018-15982_EN.html

  4. Jochem K. About 60% of exploits are published before the CVE. What does this mean for your cyber security strategy? [Internet]. IT Security Matters. 2018 [cited 2018 Dec 8]. Available from: https://klausjochem.me/2018/11/04/about-60-of-exploits-are-published-before-the-cve-what-does-this-mean-for-your-cyber-security-strategy/

  5. Offensive Security. Offensive Security’s Exploit Database Archive [Internet]. Exploit Database. [cited 2018 Nov 4]. Available from: https://www.exploit-db.com/

Advertisements

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.