Tuesday, March 20th 2018
CTS-Labs Releases Masterkey Exploit Proof-of-Concept Video
CTS-Labs, the cyber security research firm that claims to have unearthed severe security vulnerabilities with AMD "Zen" CPU architecture, posted its first proof-of-concept demo video. This video deals with the "Masterkey" class of exploits, specifically Masterkey-1. The Masterkey class makes for 3 of the 13 vulnerabilities the firm discovered. As a quick refresher, Masterkey is an exploit of the Secure Boot feature, specifically getting around the feature's system integrity check on AMD "Zen" powered systems, by using a specially programmed system BIOS. Any privileged program (even from within Windows), can flash your system BIOS, and get around Secure Boot in the following system reboot (or even brick your system by writing a non-bootable BIOS image). The BIOS can then tinker with the ring -3 (minus 3) software running on Secure Processor, and survive reboots or OS re-installs. It would also be undetectable by traditional antivirus programs that can't have ring -3 access while running on top of an operating system.
In the video, we're shown a somewhat step-by-step process of infecting a TYAN-made server motherboard with a modified BIOS that has the Masterkey exploit. The demo BIOS by CTS, which has ARM Cortex A5-compatible code for the Secure Processor, makes it flicker its status code between "1337" and "7331" during POST, and go on to boot the OS as if nothing happened. It can be made to do anything once you've reached that far. CTS-Labs claims that it has a more elaborate shell code for Secure Processor that probably does more insidious things, but it won't be showing that to the public in this video. The objective of this demo appears to be to establish a proof-of-concept.The video follows.
CTS-Labs stated that it's currently filming similar proof-of-concept videos for each of the other exploits.
In the video, we're shown a somewhat step-by-step process of infecting a TYAN-made server motherboard with a modified BIOS that has the Masterkey exploit. The demo BIOS by CTS, which has ARM Cortex A5-compatible code for the Secure Processor, makes it flicker its status code between "1337" and "7331" during POST, and go on to boot the OS as if nothing happened. It can be made to do anything once you've reached that far. CTS-Labs claims that it has a more elaborate shell code for Secure Processor that probably does more insidious things, but it won't be showing that to the public in this video. The objective of this demo appears to be to establish a proof-of-concept.The video follows.
CTS-Labs stated that it's currently filming similar proof-of-concept videos for each of the other exploits.
50 Comments on CTS-Labs Releases Masterkey Exploit Proof-of-Concept Video
This exploit can override Administrator/Supervisor passwords in the UEFI if set beforehand?
Usually, even from Windows, you need that in order to flash it. This seems that from the get-go, there will be no password, however I'm not finding this hurdle being mentioned as a portential mitigation for the MASTERKEY exploit too.
So, to sum video up:
This was done "remotely" within local network.
This required admin access to be available from the get go on the target system.
This requires attacker to know exactly which board is used by the target system.
This is an incredibly targeted attack which makes it pretty much useless unless you're doing just that, a very targeted attack on some servers.
Yes, this will affect almost a marginal percent of Epyc installations.
That's the crux of it.
Yes, this is more an enterprise targeted scenario than an enduser one, but don't deny it is a problem. That makes you part of what? Certainly not the solution.
The continued stream of info from the group, whose short selling interests have been disclosed, is really quite unsettling. Moreso that news sites aren't using disclaimer headings.
Effectively, CTS-Labs current AMD research is aimed at profiting from short selling and as such, sites ought to inform readers of such. It is, without doubt (as they have admitted) financially motivated.
Correct way to handle this would have been to notify AMD and let them fix it.
Instead they decided to leak some to stock shortseller Viceroy (intentionally or unintentionally, doesnt matter) before publishing amdflaws site. This along with the disclaimer (about financial gains from the exploit publishing/usage) on amdflaws site makes them more likely to face litigation than kudos.
No, they didn't do the strictly ethical "I will not mention this until you fix it" thing, but that has little impact on the bug itself. The company has been called iffy by myself since day 1, so the idea their ethics may be a little off kilter isn't exactly news to me.
Here's the $h't. <attached>
Oh, and we'll say that ya'll can't fix it.
ktnxbye"
It involves a detailed phone conversation transcript and Anandtech's critique of the knowledge gleamed. It does not deny the exploit but it clearly finds CTS to be 'financially motivated'.
www.anandtech.com/show/12536/our-interesting-call-with-cts-labs
Isn't it much easier and more reliable to install a rootkit to the MBR?
I'm still not convinced any hacker would consider this worth the effort...