Category Archives: Opinion

Intel AMT flaw lets attackers take control of laptops in 30 seconds

20 January 2018

Intel’s Active Management Technology (AMT) offers impressive management features to company IT shops:

  • Asset discovery
  • Out-of-band management functions to fix systems even if the OS went down
  • Contain the impact of malware

As any other software, AMT has configuration issues and vulnerabilities. For example, in 2015 default factory settings could be leveraged by an attacker to gain full control over devices from the network. Last year, four vulnerabilities were published in the NVD Database.

The latest configuration issue published on January 12, 2018 by F-Secure researchers allows attackers with physical access to compromise systems easily:

Just press CTRL-P during boot and log into Intel Management Engine BIOS Extension (MEBx) using the default password “admin”. With this, an attacker can reconfigure the system to allow for example remote access once the system is booted and left unattended.

This type of attack is called Evil Maid Attack. It is used especially by cyber criminals and nation state actors to compromise systems.

Although Intel made recommendations to mitigate this issue, the F-Secure report makes clear, that the OEM’s did not implement them and that the system managers did not change the AMT password on delivery to the users.

With this, we have no choice but to set individual AMT and BIOS passwords on all laptops and mobile devices with AMT enabled. This is going to be a hard job in companies with some thousand devices.

A risk based approach makes sense: Start with the top management and employees which have access to business-critical information.

Have a great weekend.


Spectre and Meltdown – No need to enter Panic Mode

7 January 2018

Spectre Icon


When I read about Meltdown and Spectre in the Reuters Technology News early on Wednesday morning I digged directly somewhat deeper to find details about the access vectors and severity. From a quick view of the published material I concluded that these vulnerabilities were only locally exploitable and would have medium to high impact. No need to panic.

Media coverage was very high the next morning. Even the German local radio stations brought details about Spectre and Meltdown in the news, although there was no ground for public panic.

The following table shows the Meltdown and Spectre vulnerability details:

Meltdown and Spectre Vulnerability Details, CVSS V3 Metrics

Meltdown and Spectre Vulnerability Details, CVSS V3 Metrics

Sources: [1] NIST NVD, [2] RedHat Customer Portal[3] NIST NVD
Abbreviation list: AV: Access Vector, AC: Access Complexity, PR: Privileges Required, UI: User Interaction, C: Confidentiality, I: Integrity, A: Avaliability

To exploit these vulnerabilities an attacker must have either local access to a system on your network (Access Vector Local) or access to your local network (Access Vector Adjacent Network).

But why should an attacker, who got access to a system on your network, exploit e.g. Meltdown to extract passwords from the memory of a process? The access complexity is high; thus, the likelihood of early detection goes up.

We can expect that cyber criminals don’t behave irrationally. They choose the attack method with low chance of detection. And recent publications suggest this:

According to the Ponemon 2017 Cost of Data Breach Study the Mean Time to Identify (MTTI) a data breach in 2016 was 191 days, down from 201 days in 2015. If cyber criminals would behave irrationally, the MTTI would be much shorter.

Thus, there is no need for panic. Just apply the latest patches and check the performance of critical systems.

Have a great week.

Concerns about using open source libraries from an IT security point of view

18 December 2017

Some days ago I participated in a discussion about the necessity of using open source libraries in industrial software development and the data scientist workbench. IT security is often perceived as spoil sport in such discussions …

To be honest, I like open software. I prefer for example Firefox on Windows 10 because the configuration of Edge is really annoying. However, when it comes to the use of open software libraries in scientific or industrial software development projects or by data scientists I have two major concerns:

1. I have just no clue what the open software libraries do in addition to their intended use.

This sounds a bit paranoid. The question is:

Can we make sure, that no malicious code snippets are hidden in an open software library which send the company’s secrets to a cyber criminal’s command and control server, or which encrypt all data?

In my opinion this is not possible. Reviewing e.g. the 300 thousand lines of code of the OpenSSL-1.0.2 project is a herculean task, which has to be repeated for every patch and release. We can automate the software review process with advanced code analyzers. With such analyzers, we can make sure that open source code has no or few critical errors. But analyzers cannot find malicious code snippets, they just make sure that such snippets cause no critical errors during program execution.

Advanced Persistent Threat (APT) solutions may detect malicious behavior. But when a developer or data scientist includes open software into his code, the threat type changes from external to insider threat, thus APT solutions are no longer effective.

Eventually, we have to trust the developers of open software. Thus, the use of open software depends largely on the risk appetite of an organization.

2. I have no idea how to fix vulnerabilities in software which uses open software libraries.

Firefox gets security patches immediately after vulnerabilities are published. For example, the remote code execution vulnerability CVE-2017-7827, published 11/15/2017, was patched on the morning of 11/17/2017. When I logged in to my Linux box in the evening, even a patch for the Firefox ESR version was installed.

The OpenSSL-1.0.2 library mentioned above can be used potentially in many applications, in the worst case, some of them may be connected directly to the internet. The developers of Firefox take care of security bugs in this library. Who cares in the case of self-developed software? And how fast? Just remember the Equifax data breach some months ago. The reason for this really costly data breach was an unpatched vulnerability in the Apache Struts framework …

The focus of open software developers is innovation. Thus, the use of open software will be a major driver in the digital transformation, and we should foster this use to stay at the cutting edge of digital transformation.

Nevertheless, we must be aware of the risks of this use and take proper precautions for their mitigation.

Have a great week.

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.

Oh dear! Oh dear! I shall be too late! – The White Rabbit

29 October 2017

WannaCry, NotPetya, and now: Bad Rabbit. The good news is that Bad Rabbit isn’t spreading as fast as WannaCry and NotPetya. According to a DARKReading report from October 25th the outbreak appears to die down already.

The bad news is, that it happened again. Like the White Rabbit in Alice’s Adventure in Wonderland, IT departments seem to mutter only “Oh dear! Oh dear! I shall be too late!”, instead of increasing the security baseline of their company networks.

Bad Rabbit uses similar techniques as WannaCry and NotPetya for spreading in the networks:

Open SMB shares, Mimikatz alike ways to dump credentials from the affected systems, a hardcoded list of credentials, … For more technical details see this post from Malwarebytes Labs.

The methods to avoid this are well-known and easy and cheap to implement:

  • Run a user awareness campaign.
  • Reduce the number of users and administrators working with permanent administrative privileges to zero. This is a leadership task!
  • Apply the measures to mitigate Pass-the-Hash attacks to all Windows systems and networks.
  • Limit the functionality of technical users to local systems and the lowest possible privileges. Use individual passwords, eliminate default passwords.
  • Review all firewall rules. Question every required connection. Limit the use of the SMB protocol as far as possible. Eliminate the use of unsecured protocols as far as possible. Patch the systems at the endpoints of firewall rules.

The above list is not exhaustive, but if implemented, the attacker’s ability to explore the network is clearly reduced.

It appears to me, that everyone is waiting for Windows 10 to solve some of the issues. This however is the wrong approach. Windows 10 cannot be introduced with a big bang. In particular in the production, lab, and building automation domain, it will take a few years until we can shutdown Windows XP/7 completely. And during this years, our networks are at risk.

With this, there is no time to lose. The White Rabbits returns.

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!

Top secret information about Australia’s military hacked – SME’s overstretched with Cyber Security Frameworks

15 October 2017

Lisa Martins report Top secret information about Australias military hacked, published on October 12th, 2017 at, about a one year old attack on an Australian defense contractor is another example that small businesses are technically and organizationally overstretched with the challenges of cyber security.

The best approach for SMEs would be to set up a cyber security framework like the NIST Cyber Security Framework or an ISO 27001 based framework. But the effort to do this is for small businesses just too high.

For SMEs to stay ahead of the cyber security curve a light version of such frameworks is required, with focus put on actively managing the risk.

The Strategies to Mitigate Cyber Security Incidents of the Australian Signals Directorate (ASD) puts focus on the basics. If carefully implemented and regularly assessed, the security level goes up and this kind of attacks are no longer possible. Even large businesses can raise their security level when implementing the ASDs recommendations.

But when it comes to critical infrastructures a full implementation of a cyber security frameworks is the only way to survive in the long-term. By the way, the first task in the NIST CSF core is asset management…

Have a great week.