To patch or not to patch this is not the question – New Remote Code Execution Vulnerability in Drupal CMS

21 October 2018

Lindsey O’Donnell’s report “Two Critical RCE Bugs Patched in Drupal 7 and 8” [1] published yesterday on Threatpost gives website operators every reason to enter panic mode.

The vulnerabilities are not published in the NIST NVD yet, but Drupal released two security advisories [2] [3] with details.

Why panic? In the past 16 years 177 vulnerabilities [4] related to Drupal were published. That sounds like a lot but consider that 1,075,609 websites were powered with Drupal core in October 2018 [5].

Fortunately, only 13 exploits were published since 2002. On 29 March 2018 the remote code execution vulnerability CVE-2018-7600 (Drupalgeddon2) was published. Within 20 days after publication three exploits were available. Thousands of sites were compromised in the aftermath.

CVE-2018-7602 (Drupalgeddon3) was published on 19 July 2018. In this case exploits were available 81 and 86 days before the CVE was published.

Drupal Exploits since 2010

Table: Drupal Exploits since 2010. Click to enlarge.

The table above shows the vulnerabilities with published exploits for the Drupal CMS since 2010. Negative values in column Number of days exploit published after CVE published indicate that the exploit was published before the CVE was published. These are the magic zero-day exploits, the worst-case scenario for website operators because a warning time does not exist.

Except of the green highlighted exploit all exploits were used in the wild, means, they were used in attacks. In addition, except of the green highlighted exploit all CVE were remote code execution or injection vulnerabilities.

For the newly published remote code execution vulnerabilities we can expect

  • that exploits will be published with a probability of about 7% and
  • that if exploits are published, they will be published before or at the day the CVE is published.

With this, website operators must directly patch once they become aware of a new remote code execution vulnerability.

In addition, I would recommend to take additional preventive measures, e.g. to implement a Web Application Firewall or a Host based Intrusion Detection/Prevention System to make the installation more resilient against new vulnerabilities. If the website is operated on Linux it makes sense to activate  AppArmor [6].

Have a great week.


  1. O’Donnell L. Two Critical RCE Bugs Patched in Drupal 7 and 8 [Internet]. Threatpost | The first stop for security news. 2018 [cited 2018 Oct 20]. Available from: https://threatpost.com/two-critical-rce-bugs-patched-in-drupal-7-and-8/138468/
  2. Drupal ST. Drupal Core – Multiple Vulnerabilities – SA-CORE-2018-006 [Internet]. Drupal.org. 2018 [cited 2018 Oct 20]. Available from: https://www.drupal.org/sa-core-2018-006
  3. 3.Drupal ST. Mime Mail – Critical – Remote Code Execution – SA-CONTRIB-2018-068 [Internet]. Drupal.org. 2018 [cited 2018 Oct 20]. Available from: https://www.drupal.org/sa-contrib-2018-068
  4. CVE Details. Drupal Drupal : CVE security vulnerabilities, versions and detailed reports [Internet]. CVE Details. The ultimate security vulnerability datasource. 2018 [cited 2018 Oct 21]. Available from: https://www.cvedetails.com/product/2387/Drupal-Drupal.html?vendor_id=1367 
  5. Drupal.org. Usage statistics for Drupal core | Drupal.org [Internet]. 2018 [cited 2018 Oct 21]. Available from: https://www.drupal.org/project/usage/drupal
  6. theMiddle. AppArmor: Say Goodbye to Remote Command Execution. [Internet]. Secjuice.com. 2018 [cited 2018 Oct 21]. Available from: https://www.secjuice.com/apparmor-say-goodbye-to-remote-command-execution/
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/

DeepLocker: AI Powered, Ultra-Targeted and Evasive Malware

19 August 2018

Mohit Kumar’s report on DeepLocker (1) published on 9 August 2018 in The Hacker News made me jump. Is AI becoming the doomsday machine of the 21st century?

DeepLocker is the result of a study (2) performed by IBM Researcher Marc Stoecklin and his colleagues on the question how the use of AI will change cyber-attacks:

“DeepLocker has changed the game of malware evasion by taking a fundamentally different approach from any other current evasive and targeted malware.”

The good news is that DeepLocker still needs a carrier app. Marc Stoecklin writes:

“DeepLocker hides its malicious payload in benign carrier applications, such as a video conference software, to avoid detection by most antivirus and malware scanners.”

Seven Phases Cyber Kill Chain

Cyber Kill Chain

DeepLocker is hence not invincible. A compromised carrier app will have another fingerprint than the not compromised version, at least until the carrier app is not compromised during development.

With this, program reputation, a must-have in every Next Generation Endpoint Protection Solution (NGEPS), can stop a malicious app very early in the Cyber Kill Chain (CKC).

The bad news is that reverse engineering is hardly possible. Marc Stoecklin writes:

“What is unique about DeepLocker is that the use of AI makes the “trigger conditions” to unlock the attack almost impossible to reverse engineer. The malicious payload will only be unlocked if the intended target is reached. It achieves this by using a deep neural network (DNN) AI model.”

Although I am fond of reading malware analysis papers I won’t miss them. From my point of view, it is only important that the NGEPS blocks the payload from being executed. In terms of the Cyber Kill Chain this means: ideally in the delivery phase, the latest in the installation phase.

For more details on DeepLocker please see the presentation (3) Marc Stoecklin delivered at the Black Hat 2018 conference.

Don’t panic, but be prepared: Skynet will gain world supremacy soon …

Have a great week.


  1. Kumar M. Researchers Developed Artificial Intelligence-Powered Stealthy Malware [Internet]. The Hacker News. 2018 [cited 2018 Aug 13]. Available from: https://thehackernews.com/2018/08/artificial-intelligence-malware.html
  2. Stoecklin MP. DeepLocker: How AI Can Power a Stealthy New Breed of Malware [Internet]. Security Intelligence. 2018 [cited 2018 Aug 13]. Available from: https://securityintelligence.com/deeplocker-how-ai-can-power-a-stealthy-new-breed-of-malware/
  3. Stoecklin MP, Kirat D, Jang J. DeepLocker – Concealing Targeted Attacks with AI Locksmithing [Internet]. Black Hat USA 2018. 2018 [cited 2018 Aug 19]. Available from: https://www.blackhat.com/us-18/briefings/schedule/#deeplocker—concealing-targeted-attacks-with-ai-locksmithing-11549

Digital Carelessness – a disease without a chance of cure

12 August 2018

Two messages this week showed that there is no cure in sight for the fatal disease called digital carelessness.

ONE: Two remote code execution (RCE) vulnerabilities found in certain HP Inkjet printers (1).

CVE-2018-5924: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CVE-2018-5925: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

This sort of vulnerabilities is particularly popular in the cyber crime scene because they are network exploitable (Attack Vector AV:Network), attack complexity is low (AC:L), no privileges required (PR:None) and no user interaction is required (Ui:None).

Under normal conditions, Inkjet printers are operated inside the company network. Thus there is no need to enter into panic mode because the vulnerability can not be exploited from the internet.

Unfortunately, some HP Inkjet printers are, for whatever reason, accessible from the internet. A Shodan search reveals that 539 HP DesignJet printers are directly connected to the internet. One of the vulnerable printer models is the HP DesignJet T520 24-in ePrinter, Product number CQ890A, Firmware version 1829B. For a complete list of the affected printers please see the HP Security Bulletin HPSBHF03589 (2).

HP DesignJet T520 Map

HP DesignJet T520 Map. Click to enlarge.

As of today, 79 printers of this type are directly attached to the internet. Some of them are ready for printing and with this prone to CVE-2018-5924 or CVE-2018-5925 because the HP JetDirect Line Printer Daemon port 515 is open.

But why should an attacker exploit these RCE vulnerabilities if he can hijack the printer because basic security is not configured?

HP advised its customers to update the firmware of the affected printers as soon as possible. This is the best opportunity

  • to configure basis security,
  • to eliminate the http protocol, and
  • to close unnecessary open ports.

TWO: TSMC Chip Maker Blames WannaCry Malware for Production Halt

Taiwan Semiconductor Manufacturing Company (TSMC), the world’s largest makers of semiconductors and processors, was hit by a variant of the WannaCry ransomware last week. According to TSMC, its computer systems were not directly attacked, but instead, were exposed to the malware when a supplier installed corrupted software without a virus scan.

“We are surprised and shocked,” TSMC CEO C.C. Wei said, “We have installed tens of thousands of tools before, and this is the first time this happened. (3)

It doesn’t matter how often installations went well in the past. It’s always the next installation that counts.

Have a good week.


  1. Zorz Z. HP plugs critical RCE flaws in InkJet printers [Internet]. Help Net Security. 2018 [cited 2018 Aug 6]. Available from: https://www.helpnetsecurity.com/2018/08/06/hp-inkjet-printer-vulnerabilities/
  2. HP Customer Support. HPSBHF03589 rev. 2 – HP Ink Printers Remote Code Execution. 2018 [cited 2018 Aug 6]. Available from: https://support.hp.com/us-en/document/c06097712
  3. Wu D. iPhone Chipmaker Blames WannaCry Variant for Plant Closures. Bloomberg.com [Internet]. 2018 Aug 6 [cited 2018 Aug 12]; Available from: https://www.bloomberg.com/news/articles/2018-08-06/iphone-chipmaker-blames-wannacry-variant-for-plant-closures

Chrome’s new Site Isolation feature protects users from the Spectre vulnerability

14 July 2018

Spectre

Spectre

A new variant Spectre V1.1 (1) was published on July, 10 2018 by Vladimir Kiriansky and Carl Waldspurger. The vulnerability is tracked in CVE-2018-3693 (2). The good news is that the CVSS V3 score is 5.6 (Medium) with attack vector Local.

As with the original Spectre vulnerability CVE-2017-5753 (3) published in January 2018 the greatest risk for business users and consumers bears in malicious websites weaponized with drive-by downloads or viruses (4) using the Spectre POC code.

The virus issue is easy to mitigate. The inbuilt auto-update feature of anti-malware solutions ensures that the latest pattern updates are available within few hours after a virus shows up in the wild.

But the internet issue is much harder to solve, in particular for consumers and SME. Fortunately, Goggle announced on July 11, 2018 a new feature Site Isolation for the Chrome browser that mitigates the risk borne from the Spectre vulnerability.

Chrome is based on a multi-process architecture. Different tabs are rendered by different renderer processes. With site isolation enabled, cross-site iframes are rendered in different processes than the parent frame and data exchange between the parent and the iframe processes is blocked. For a technical overview see Charlie Reis’s post ‘Mitigating Spectre with Site Isolation in Chrome’ (5). Further details are available from the Chromium Projects (6).

Site Isolation is available since Chrome 67. Input chrome://flags/#enable-site-per-process to check if the feature is enabled:

Chromium Strict Site Isolation Feature

Chromium Strict Site Isolation Feature

If you use an older version of Chrome Site Isolation is the best opportunity to update to the latest version.

Have a great weekend.


  1. Beltov M. CVE-2018-3693: New Spectre 1.1 Vulnerability Emerges [Internet]. SensorsTechForum. 2018 [cited 2018 Jul 14]. Available from: https://sensorstechforum.com/cve-2018-3693-new-spectre-1-1-vulnerability-emerges/
  2. CVE-2018-3693 Detail [Internet]. NIST NVD. 2018 [cited 2018 Jul 14]. Available from: https://nvd.nist.gov/vuln/detail/CVE-2018-3693
  3. CVE-2017-5753 Detail [Internet]. NIST NVD. 2018 [cited 2018 Jul 14]. Available from: https://nvd.nist.gov/vuln/detail/CVE-2017-5753
  4. FortiGuard SE Team. Meltdown/Spectre Update [Internet]. Fortinet Blog. 2018 [cited 2018 Jul 14]. Available from: https://www.fortinet.com/blog/threat-research/the-exponential-growth-of-detected-malware-targeted-at-meltdown-and-spectre.html
  5. Reis C. Mitigating Spectre with Site Isolation in Chrome [Internet]. Google Online Security Blog. 2018 [cited 2018 Jul 14]. Available from: https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html
  6. The Chromium Projects. Site Isolation – The Chromium Projects [Internet]. [cited 2018 Jul 14]. Available from: https://www.chromium.org/Home/chromium-security/site-isolation

Windows 2008 Server End of Life: The best chance to move to the cloud

30 June 2018

Windows 2008 Server End of Life is near. Within the next months many companies are busy with the replacement of Windows 2008 based infrastructure and application servers to avoid the next Wannacry or NotPetya.

It appears to me that this is the best opportunity to migrate at least application servers to the cloud. And, in the best case, to get rid of the servers at all by transforming the application to SAAS. If technical or the organizational limitations do not allow this at least the transformation to PAAS and IAAS should be considered.

What stops us from doing this? Very often it is the fear of loss of access to critical business data or the fear of loss of the data at all. At least in the latter case technical protection measures can be applied to mitigate this issue.

Transparent database encryption

Transparent database encryption (TDE) is often the matter of choice. All encryption is performed transparently by the database service, with no impact on the application and the users because only the database files or critical attributes in tables are encrypted. User interaction is required only during database startup to activate the encryption engine.

Unfortunately, TDE provides only encryption at rest. Thus TDE stops infrastructure admins from using unauthorized copies of a database or a virtual database server because they cannot activate the encryption engine. Once the database is started all users and database administrators have access.

Application level encryption

With Application level encryption (ALE) all encryption is performed by the application. Data is encrypted when entered in or retrieved through the application. Thus data is encrypted during transfer and at rest.

As long as the access is not routed through the application server the data are accessible for no one. Even infrastructure or database admins are barred unless they have access to the encryption key.

The security problem is shifted towards that of operational security of the application server. A solution to this problem could be to encrypt the data in the database with a key that is encrypted against the users access keys. This ensures that the encrypted data cannot be decrypted without access to at least one users key.

The remaining risk is that an attacker reads the keys or the plain text data from the process memory of the application service.

The effort to implement application level encryption is high because the application has to be changed. In addition, a key infrastructure must be set up to avoid data loss in the case a user key is e.g. inaccessible. But the gain in information and operational security is high.

The pros and cons of the encryption concepts in summary.

Table 1: Database Encryption Concepts Summary

Table 1: Database Encryption Concepts Summary

With Application Level Encryption, outsourcing or cloud adoption is made easy.

Have a good weekend.