On November 8th, a security researcher (twitter: @h0t_max) announced they have found a vulnerability using the JTAG bus via USB to attack the Intel IME. This vulnerability is present in most, and possibly all, Intel Skylake and newer processors, with some reports claiming that “all Intel procs from 2008 and newer are susceptible.”
Let’s pause there. If you’re wondering what that fearsome word salad means, you’re not alone. To bring everyone to the same page, here’s a mocha breve we’ve disguised as a skinny latte.
Intel’s IME, AMT, and JTAG Explained
Let’s set some definitions for this conversation.
IME: the Intel Management Engine performs system tasks while the computer is booting (before Windows starts), while it’s in use, and in standby or sleep modes (when Windows is suspended).
AMT: Intel’s Active Management Technology is a chip on your computer which is used to manage the computer remotely, even if Windows is crashed or the computer is inactive.
For those familiar with server-based Out Of Band Management (OOBM) and “Intelligent Platform Management Interface (IPMI)” technologies like HP’s ILO or Dell’s iDRAC systems, AMT is the desktop/laptop version of those tools, but integrated with the Intel CPU.
The synopsis from DigitalTrends regarding an earlier vulnerability further elaborates upon the potential risk:
“…IME is invisible in regards to the overall system setup, and in some cases includes Intel’s Active Management Technology (AMT) so that it can continue to perform no matter what operating system is installed. Thanks to AMT, the ME system can sneak past the x86 Intel processor and access any region of the system memory. It also runs its own TCP/IP server, which is capable of bypassing an installed firewall to send and receive packets. The ME system cannot be disabled by the installed operating system or x86-based firmware, especially on systems that are newer than the Intel Core 2 processor series.”
For security people, that’s the stuff of nightmares, and it comes pre-built in the computer(s)!
JTAG: Joint Test Action Group is the name of a working group (like IEEE or ASME) that wrote a common standard in the 90’s for equipment manufacturers and engineers to use to work directly with hardware, without needing to go through the OS, for things like debugging hardware problems and flashing new firmware to a component. Oftentimes, they use a dedicated port on a system board, but recently the trend has been to use USB to get to the JTAG functions on hardware.
Which Brings Us Back to @h0t_max
So, that security researcher found a way to use the deep-level hardware access that the JTAG bus has to computer components, to reach the Intel Management Engine, which is used to remotely manage and control everything on your computer, even when it’s powered off.
Because the IME and AMT function below the OS, this vulnerability can be used to modify, bypass or disable the security features of an OS, including antivirus & firewalls, and potentially affect or bypass hardware-integrated security functions like UEFI and TPM.
Whether or not your organization needs to hit red-alert panic mode depends on your risk profile, which we’ll dig into shortly.
Many security and risk management teams (ours included) have been warning organizations about the Intel AMT and IME for some time, especially since there are already known vulnerabilities, including this one in May 2017 and another in June 2016.
The May of 2017 finding is especially noteworthy, because the AMT was able to be controlled, “with an empty credential string over a network.” It was like flashing a blank piece of paper as a security badge, and the AMT said “OK!” and rolled over. Go Intel.
The IME/AMT requires programs interacting with it to present cryptographic keys that are given to the developers by Intel. The researcher’s announcement last week implies that they (may) have found a way around that. (But if the IME/AMT thinks “ ” is the same as “MyPasswordString”, that might not have been hard.)
Knowledge Is Power
When the Security Teams at Critical Insight perform risk and vulnerability assessments for our clients, we commonly find a pair of problems that go hand in hand:
- Computers (laptops, desktops) have Intel’s IME/AMT enabled, and the organization doesn’t know it.
- Organizations aren’t patching Intel’s IME/AMT, because they don’t know they have it.
Because the IME/AMT is part of Intel’s Secret-Sauce, and has a high potential for misuse, they keep details about it on the down-low. Security professionals know that sending an employee with a laptop out to airports, hotels, and Starbucks with a generally-undocumented network-accessible hardware management interface known to have vulnerabilities is a notable risk. Their most common guidance is to simply disable the IME/AMT out of an abundance of caution.
However, that doesn’t fix the potential risk. The IME/AMT can be re-enabled in and by software, so if some crafty malware gets hold of your system, it could re-enable the IME/AMT without having to try very hard. Security and IT folks can end up playing Whack-A-Management Engine trying to keep the IME/AMT disabled across an entire fleet of laptops and desktops. It’s easy to throw one’s hands up and say, “eh, forget it—nobody knows about this thing anyway.”
Assessing the Risk
To start, we know that the researchers report that they are “able to execute unsigned code on computers running the IME through USB.” ‘Executing unsigned code’ of course means ‘Bad-actors can make it run whatever code, programs, or malware they want it to run.’
This specific exploit requires a USB port, which means it needs to be physically performed on the computer. As it stands today, this is not something that a cleverly disguised email attachment or a hacked website can leverage. Someone needs to plug in a USB device, in the same way a Bash Bunny or PwnPlug requires.
For laptops taken offsite (home, remote offices, road warriors), this is of concern. If an employee working at the local Starbucks leaves their computer to pick up their order at the counter, a bad-actor walking past the computer can plug in an infected USB device, and (a) turn on the IME, and/or (b) tell it to do something specific and, most likely, malicious. The risk associated with the briefly unattended employee laptop, whether at the airport gate check-in or trade show, is all too common.
For computers running on-site (desktops), the outsider risk remains – a bad actor or malicious insider walking past a computer plugging in a specially crafted USB device could enable the IME/AMT, and have it change a hardware configuration setting, or run code or malware. There’s also the “parking lot USB Flash” attack, where an employee finds a malicious USB flash drive in the parking lot and, thinking “Hey! Free flash drive!” they go back to their desk and plug it in. But neither of these are new, and neither of these scenarios are specific to this particular IME/AMT exploit.
One open question which remains to be answered is whether the exploit works if DLP endpoint technologies are present and configured to block USB ports or limit them to only approved USB devices. The same applies to app whitelisting tools like AppLocker and Carbon Black (which, we hear, stops MimiKatz.) If the exploit requires x86 code to run at first, it may be a much more controllable risk than the initial reports imply.
If the exploit can run from a USB device without needing to run a program in the OS… well, buckle up and stay tuned. We’ll keep you posted here.
Risk Summary
Given that the risk is primarily physical in nature, the risk vectors are more limited than a traditional malware-centric or network-based attack. The exploit has to be presented in person to take hold. The risk & likelihood is higher for employees with laptops, especially if they travel and/or use their laptops in public places (airports, coffee shops, trade shows) and are not diligent about keeping a watchful eye on strangers plugging in rando flash drives, but any Intel Skylake based computer with exposed USB ports is at risk.
The impact, however, is potentially very high. I say “potentially” because the specifics about the exploit have not yet been released. To have such deep hardware access – commands, diagnostics, firmware flashing – to an out-of-band remote management subsystem made available just by plugging in a USB device is problematic, especially if other system security functions like UEFI and the TPM can also be affected.
5 Steps to Take Now
Pop Quiz, Risk Manager. Should you:
a) Panic?
b) Hammer & nail large pieces of crooked wood over your USB ports? Or,
c) Just let this play out?
We’ll go with option d: All of the Above.
The status quo for a long time has been “If I have physical access to your computer, it’s mine.” However, this new exploit to the hardware management system doesn’t change the risks of a bad-actor with physical access to your computer. There are still a myriad of ways that someone with physical access to a computer can own it, pwn it, and have it for lunch; if it isn’t this specific physical attack, it would be one which implants malware and remote access tools, steals credentials, or just toasts your computer. The USB/JTAG attack against the IME just makes that process faster for the bad-actor.
The standard infosec guidance still applies:
- Train your employees to NEVER plug in unknown USB devices
- Turn them in to Lost & Found or give them to IT/InfoSec staff
- Also train them to NEVER plug in unknown USB devices
- Disable USB ports when & where you know they aren’t necessary
- Use Application Whitelisting tools like AppLocker or Carbon Black
- Use DLP technology for hardware control wherever possible
- Keep the IME patched, and if possible, disable the IME outright
The Real Problem Is the IME/AMT Itself
My concern is specific to the IME/AMT, and not this exploit. As noted above, any physical attack is going to be bad news for the victim computer; this exploit hasn’t changed that or made it any worse (yet).
But the bigger story here is Intel’s secrecy around the IME, combined with how deeply it’s embedded in hardware, and so persistently pervasive in the OS. This has come back to bite the IT industry yet again.
Because we don’t have all the details about this new finding yet, I’m going to refrain from judgment on the exploit itself.
However, the exploit in May 2017 which accepted admin commands when you present no password—which is just stupid—was especially disappointing when coming from a major technology manufacturer like Intel.
Triple-so when it works against a network-accessible system-level management platform you can’t easily disable, which accepts IP requests on a non-standard port that software firewalls can’t block, and most people aren’t even aware they’re running. Any half-baked secure software development processes should have caught that before it was ever released to general use—the fact that Intel did not is worrisome.
Worse, because many environments are running AMT/IME and they don’t even know it, this vulnerability, and likely many others in the platform, will be lingering around for years on systems where patches aren’t applied because admins don’t receive or ignore the advisories, or they don’t think it’s used in their environment.
What about “all Intel-based computers since 2008”?
The publicized attack itself – using JTAG over USB to get to the IME – only works on Skylake and newer CPUs. The Skylake product line was first released in 2015, so this sounds contradictory at first. Because the IME has been in use since 2008, the question many security folks are wondering now is whether @h0t_max found a vulnerability that can be exploited across the generations of Intel chips and IME platforms. If so, then this is bigger than currently advertised. But that’s a big “if” until more details come out.
And what’s this about MINIX and Berkeley?
MINIX is a lightweight Unix-like operating system that was written in the late 80’s/early 90’s, primarily to teach students about OS principles and software development. Intel used MINIX in the ME-11 chip, designing the IME to run using MINIX instead of Unix/Linux or writing their own. But they did so without telling anyone, and after calling the MINIX authors to ask for specific features to be implemented. The authors suspected Intel had used MINIX somehow, given the requests, but were surprised to learn what it was being used for, and just how widely. The project owner, a Mr. Tanenbaum, wrote an open letter to Intel thanking them.
Conclusion
Don’t panic about this exploit in particular. Be aware of it, patch it when the patch comes out, and disable it if you can.
Reiterate to your staff that strange USB devices should be treated like the monkey in Outbreak, and never plugged into your staff’s computer “just to see what was on it.”
But be frustrated that, yet again, a not-well-known management technology that doesn’t like to be disabled is vulnerable over the air (wifi), over the wire (ethernet), and now by USB.
We can also learn from companies like Google, who are diligently working to eradicate the IME/AMT from their fleet.
I’m sure your PC reseller and their Intel sales reps want your feedback on that.