Tag Archives: Remote Code Execution Vulnerability

Blockchain unchained?

3 June 2018

Blockchain technology is a digital platform for applications where seamless traceability and full transparency is required.

For example, in pharmaceutical industry blockchain could give full traceability of drugs across the entire supply chain up to the patients.

Another interesting application is mobile voting. From the Brookings publication “How blockchain could improve election transparency” (1) on the use of blockchain for internet voting in the West Virginia primaries in May this year we learn that “all data of the election process can be recorded on a publicly verifiable ledger while maintaining the anonymity of voters, with results available instantly”.

This sounds very promising.

Blockchain Grid

Picture By Davidstankiewicz, for details see below (5)

Unfortunately, every software has bugs. On May 28th, 2018 Swati Khandelwal reported in “The Hacker News” about a remote code execution (RCE) vulnerability in the blockchain-based EOS smart contract system (2).

If an attacker exploits this RCE he could destroy the integrity of the entire system:

“Since the super node system can be controlled, the researchers said the attackers can “do whatever they want,” including, controlling the virtual currency transactions, and acquiring other financial and privacy data in the EOS network participating node systems, such as an exchange Digital currency, the user’s key stored in the wallet, key user profiles, privacy data, and much more.”

Although it is not clear whether the voting system used in West Virginia is based on the Blockchain 3.0 platform there is urgent need for action. EOSIO set up a bug bounty program (3) to improve their code. But should we rely on bug bounty programs for such important issues like elections or patient safety?

From the Qihoo 360 security researchers report (4) we learn that the vulnerability is created by “a buffer out-of-bounds write” error. This means that this vulnerability could have been avoided by performing a static code analysis prior to release.

The big question is: How many errors of this type are still included in the blockchain infrastructure? A bug bounty program is a good approach to improve security, a static code analysis is indispensable in my view. In particular when the outcome of an election can be influenced or patient safety is endangered.

Have a great week.


1. Desouza KC, Somvanshi KK. How blockchain could improve election transparency [Internet]. Brookings. 2018 [cited 2018 Jun 1]. Available from: https://www.brookings.edu/blog/techtank/2018/05/30/how-blockchain-could-improve-election-transparency/

2. Khandelwal S. Critical RCE Flaw Discovered in Blockchain-Based EOS Smart Contract System [Internet]. The Hacker News. 2018 [cited 2018 Jun 1]. Available from: https://thehackernews.com/2018/05/eos-blockchain-smart-contract.html

3. eosio. Calling all Devs: The EOSIO Bug Bounty Program is Live [Internet]. Medium. 2018 [cited 2018 Jun 3]. Available from: https://medium.com/eosio/calling-all-devs-the-eosio-bug-bounty-program-is-live-7219c625a444

4. Chen Y, Peng Z. EOS Node Remote Code Execution Vulnerability — EOS WASM Contract Function Table Array Out of Bounds – 奇虎360技术博客 [Internet]. 2018 [cited 2018 Jun 1]. Available from: http://blogs.360.cn/blog/eos-node-remote-code-execution-vulnerability/

Picture Credits

5. By Davidstankiewicz [CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0)%5D, from Wikimedia Commons


Some thoughts on “Identity is the new perimeter”

28 January 2018

With the increasing adoption of cloud services, the traditional perimeter security approach becomes less and less effective. The on-premise security layer, which protects users against cyber-attacks, is just no longer existent if users have direct access to a company’s cloud services from any location, at any time and, in the best case, from any device.

The four “A”s, Authentication, Authorization, Administration and Audit, become more and more important in a [hybrid] cloud based working environment.

“When identity and access management (IAM) works well, it means the right people have the right access to the right resources when they need them with appropriate governance in place from wherever the data or application is needed.” [1]

The magic word is “right”: With IAM we control the access of well-known groups of people to well-known resources. Unfortunately, cyber attackers do often not belong to these groups.

NIST NVD Statistics: Privileges Required

From the NIST NVD we learn, that 67% of the vulnerabilities published in 2017 need no privileges for exploitation.

Privileges None means: “The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.” [2]

This holds e.g. for remote code execution (RCE) vulnerabilities. An RCE allows an attacker to get full control of the victim’s computer or service, in the worst case with administrative privileges. With this, the entire new perimeter is bypassed. For an RCE example see CVE-2017-11459. [3]

Identity becomes an important part of a new perimeter but can never replace the perimeter.

NIST NVD 2017 Statistics: User Interaction Required

The NIST NVD data give another important insight for shaping a company’s security strategy: In 41% (5958) of 14647 vulnerabilities the user must interact with the attacker for their exploitation.

This means that well-made user awareness training can prevent lots of cyber-attacks.

Have a great week.

[1] AusCERT 2017 – Identity is the new perimeter
Anthony Caruana, 05/30/2017, CSO Online
Last seen: 01/28/2018

[2] Common Vulnerability Scoring System v3.0: Specification Document
Last seen: 01/28/2018

[3] CVE-2017-11459
Last seen: 01/28/2018

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.