Monthly Archives: November 2019

Responding to the recent ZombieLand 2 TSX Vulnerabilities

These vulnerabilities can only be exploited by attackers who have already compromised a system. Practice standard security precautions and install updates from hardware vendors and for your software (links provided below) when they become available. Resolution for vendors that offer cloud computing will have a more involved decision making process to consider (see below).

Early last week, security researchers disclosed security researchers disclosed further vulnerabilities within Intel’s processors.

How severe are these vulnerabilities?
These vulnerabilities ca be classed as medium severity. An attacker must already have compromised your system in order to exploit these vulnerabilities. This most recent set of vulnerabilities collectively known as ZombieLoad 2 or Transactional Synchronization Extensions (TSX) Asynchronous Abort affect Intel processors produced in the last approx. 2.5 years (August 2017 onwards).

For full technical details of these vulnerabilities, please see this page from Intel and this page from the security researchers. In summary these vulnerabilities according to the researchers allow “a malicious program to exploit internal CPU buffers to get hold of secrets currently processed by other running programs” leading to “these secrets such as browser history, website content, user keys, and passwords, or system-level secrets, such as disk encryption keys” being used by other running programs.

Of particular note are the performance implications for protecting virtual machines. If your organisation is running potentially untrusted code within virtual machines, protecting that environment will incur a performance penalty. You may need to carry out a risk assessment to determine if enabling these performance reducing mitigations outweigh the risk of putting your virtual machines at risk. Nested virtual machines will be most affected by the performance penalty.

How can I protect my organisation and myself from these vulnerabilities?
These most recent vulnerabilities can be mitigated by updating the firmware (defined) of your system. This is sometimes referred to as the UEFI / BIOS (defined) of your system.

They will be made available separately by the manufacturer of your motherboard of your system for servers, desktops and laptops or the motherboard (defined) manufacturer for any custom-built systems you may have. You will have to determine from the updates those vendors issue if they are available for the products that you own.

In addition, operating system vendors and virtualisation software vendors have made patches available (links provided below).

Thank you.


HP Enterprise:

Fedora (referring to the Xen virtual machine (see also below):

Red Hat:





Performance impact to Xen:

Security advisory:

Further information:

VMware Performance Impact Statement addressing mitigations for Machine Check Exception on Page Size Change (MCEPSC) CVE-2018-12207:

Potential Privacy and Security Issues of Virtual Assistants Highlighted Again

In late October security researchers published details of proof of concepts exploits affecting smart home devices e.g. Amazon Echoes (known as Amazon Alexa) and Google Home. These techniques allow for eavesdropping on conversations and the obtaining of passwords from users.

Why should these proofs of concepts be considered significant?
The proof of concept apps used by the researchers passed both Amazon’s and Google’s app validation processes and were briefly available to the public. Further modifications to the apps did not require a validation by either vendor.

The researchers demonstrated how their app can mislead a user into believing the smart device is no longer listening (and recording) when in fact it is.

Amazon Echo
For an Amazon Echo the device was made to keep listening by changing the de-activation intent (a phrase that can have values (words) within it to carry out custom actions. Instead the de-activation routine does not stop the device from recording you. This was done in a way that the owner of the Amazon Echo would not know anything was wrong since they will still hear the device speak “Goodbye” message. This was achieved by adding a Unicode (defined) character sequence (U+D801, dot, space) to the end of the intent sequence. Since these characters cannot be pronounced (and heard) by the device silencing the speaker but keeping the app active in order eavesdrop on a conversation. By adding more characters, the time can easily be extended.

Eavesdropping using the Amazon Echo is demonstrated in the following video from the SRLabs researchers:

Phishing a Password
To phish a password the researchers simply added an audible message in place of some of the unpronounceable characters to simply ask the user for their password by first telling them a security update for app is available and to supply the password to install the update. The researchers demonstrated the ability to convert the spoken sentence into text and send it to their proof of concept server. This is demonstrated in the following video:

Google Home
To perform the same actions with Google Home the researchers put the user into a loop and were able to capture recognised speech as text without alerting the user of the Google Home to this being carried out. This time the researchers used multiple “noInputPrompts” with SSML elements or the Unicode characters again to capture whatever is being spoken.

This is demonstrated in the following video:

Phishing a Password
This was carried out using the same technique as for the Amazon Echo above. This is demonstrated in the following video:

How can I protect my smart speaker / virtual assistant from these vulnerabilities?
Unfortunately, as the purchaser of these devices there is no action you can carry out to prevent these techniques being used against you. Instead the responsibility lies with Amazon and Google. They need to improve their app validation processes, as per the researcher’s findings:

“To prevent ‘Smart Spies’ attacks, Amazon and Google need to implement better protection, starting with a more thorough review process of third-party Skills and Actions made available in their voice app stores. The voice app review needs to check explicitly for copies of built-in intents. Unpronounceable characters like “U+D801, dot, space. “ and silent SSML messages should be removed to prevent arbitrary long pauses in the speakers’ output. Suspicious output texts including “password“ deserve particular attention or should be disallowed completely.”

My thanks to the SRLabs researchers who explain what needs to be done by the vendors to remediate these issues.

The well-known security researcher Karsten Nohl provides his informed opinion on this issue and how we should treat our usage of these devices.

Proof of concept attacks using laser beams
Smart speakers use specific microphones known as microelectro-mechanical systems (MEMS) microphones to convert the voices they hear into electrical signals they can understand and process. Such microphones however also respond to the application of light to them as proven by academic researchers who user lasers to have the devices call out the time, order a laser pointer online, set the devices volume to zero and open a garage door (or potentially the front door of a house).

What are the limitations of this technique?
The aiming of the laser can be imprecise which limits its distance and may also inadvertently hit other smart speaker devices. The researchers used a telescope, a telephoto lens and a tripod to focus the beam and to provide accurate timing.

Further limitations are detailed in this BleepingComputer article. My thanks to them for this detail and for the descriptions of this technique.

They also detail methods by which the owner of the smart speaker could be alerted to this technique being used to exploit it: “the victim may be alerted by the visibility of the light beam, unless infrared is used – but additional gear is necessary in this case, and the audio response from the target device confirm execution of the command”.

Both Amazon and Google provided statements that they are analysing the results of this research and are working with the researchers to improve security.

Thank you.

Exploits of BlueKeep Vulnerability Have Begun

In early November the security researcher Kevin Beaumont detected exploitation of the BlueKeep RDP vulnerability (patched in May 2019) within his honeypot network (defined).

How serious are these attacks?
At this time the attacks are not considered serious since the exploits are not using a wormable (automatic) means of spreading.

While this is true, Beaumont and Microsoft have cautioned that more stable exploits are likely to follow. Beaumont points to a blog post that discusses why the current exploits are mostly causing crashes upon systems and how to make the exploit more stable. Beaumont has stated over 724k system remain exposed to this vulnerability.

How can I protect my organisation or myself from this vulnerability?
For workstation systems, as recommended in my previous post, please install the Microsoft update if your system is vulnerable. Beaumont and Microsoft provide recommendations specific to organisations in their respective posts to both mitigate the vulnerability and to locate vulnerable systems within your network.

Thank you.

Blog Post Shout Out November 2019

While patching workstations and servers within organisations can be time consuming and occasionally disruptive to operations; critical infrastructure must remain online or at least minimise downtime.  I wish to provide a respectful shout-out to the following article from Amir Levintal,CEO and Co-Founder of Cylus who discusses these challenges and provides suggestions e.g. more resources, increased security awareness, and increased lobbying among regulators (among other suggestions) to overcome them:

How to Secure Critical Infrastructure When Patching Isn’t Possible: Kaspersky ThreatPost by Amir Levintal

I also wish to provide a respectful shout-out for the following article which highlights possible upcoming software updates for Amazon Kindles since vulnerabilities in the Universal Boot Loader were recently resolved:

Amazon Kindle, Embedded Devices Open to Code-Execution: Kaspersky ThreatPost by Tara Seals

Full-disclosure: I am not affiliated or sponsored by Kaspersky ThreatPost in any way. I simply wish to more widely highlight good advice on topical security issues.

Thank you.