How to remote hijack computers using Intel's insecure chips: Just use an empty login string
Exploit to pwn systems using vPro and AMT
Code dive You can remotely commandeer and control computers that use vulnerable Intel chipsets by sending them empty authentication strings.
You read that right. When you're expected to send a password hash, you send zero bytes. Nothing. Nada. And you'll be rewarded with powerful low-level access to a vulnerable box's hardware from across the network – or across the internet if the management interface faces the public web.
Remember that the next time Intel, a $180bn international semiconductor giant, talks about how important it treats security.
To recap: Intel provides a remote management toolkit called AMT for its business and enterprise-friendly processors; this software is part of Chipzilla's vPro suite and runs at the firmware level, below and out of sight of Windows, Linux, or whatever operating system you're using. The code runs on Intel's Management Engine, a tiny secret computer within your computer that has full control of the hardware and talks directly to the network port, allowing a device to be remotely controlled regardless of whatever OS and applications are running, or not, above it.
Thus, AMT is designed to allow IT admins to remotely log into the guts of computers so they can reboot a knackered machine, repair and tweak the operating system, install a new OS, access a virtual serial console, or gain full-blown remote desktop access via VNC. It is, essentially, god mode.
Normally, AMT is password protected. This week it emerged this authentication can be bypassed, potentially allowing miscreants to take over systems from afar or once inside a corporate network. This critical security bug was designated CVE-2017-5689. While Intel has patched its code, people have to pester their hardware suppliers for the necessary updates before they can be installed.
Today we've learned it is trivial to exploit this flaw, allowing anyone to gain control of vulnerable systems without a password.
AMT is accessed over the network via a bog-standard web interface: the service listens on ports 16992 and 16993. Visiting this with a browser brings up a prompt for a password, and this passphrase is sent using standard HTTP Digest authentication: the username and password are hashed using a nonce from the AMT firmware plus a few other bits of metadata. This scrambled response is checked by the AMT software to be valid, and if so, access is granted to the management interface.
But if you send an empty response, the firmware is fooled into thinking this is correct and lets you through. This means if you use a proxy to change the response to an empty string, or otherwise set up your browser to send empty HTTP Digest authentication responses, you can bypass the password checks.
Essentially, behind the scenes, your browser would normally send something like this to the AMT service, which includes the hashed response string containing the username, password and server nonce:
GET /index.htm HTTP/1.1 Host: 192.168.1.2:16992 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://192.168.1.2:16992/logon.htm Connection: keep-alive Authorization: Digest username=»admin», realm=»Digest:048A0000000000000000000000000000», nonce=»Q0UGAAQEAAAV4M4iGF4+Ni5ZafuMWy9J», uri=»/index.htm», response=»d3d4914a43454b159a3fa6f5a91d801d», qop=auth, nc=00000001, cnonce=»9c5beca4011eea5c»
Well, screw that – using a proxy between you and the device, or a similar traffic-editing tool, just strip out the response hash to send instead:
GET /index.htm HTTP/1.1 Host: 127.0.0.1:16992 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Authorization: Digest username=»admin», realm=»Digest:048A0000000000000000000000000000», nonce=»qTILAAUFAAAjY7rDwLSmxFCq5EJ3pH/n», uri=»/index.htm», response=»», qop=auth, nc=00000001, cnonce=»60513ab58858482c»
response is now empty. And yet Intel's bouncer lets you in, even though you flashed the doorman no password – no valid ID – at all:
HTTP/1.1 200 OK Date: Thu, 4 May 2017 16:09:17 GMT Server: AMT Content-Type: text/html Transfer-Encoding: chunked Cache-Control: no cache Expires: Thu, 26 Oct 1995 00:00:00 GMT
If you poke around inside Intel's firmware, you'll find this gem that lies at the heart of the matter – machine code that decompiles into C that looks pretty much like this:
if(strncmp(computed_response, user_response, response_length)) deny_access();
As you may well know, this standard function compares no more than
response_length bytes in the two supplied strings to check if they are identical or not. The two strings compared here are the authentication response sent by person trying to log in (
user_response) and the response expected by the service (
computed_response). If both strings match, the function returns zero, indicating the password is good and as expected, and the code continues on to grant access. If the strings differ, the function's return value is non-zero, meaning the password is wrong, so access is denied. So far so good.
response_length is calculated from
user_response, so if an empty string is supplied, the length is zero, no bytes are checked, no bytes are therefore different, and – as expected –
strncmp() returns zero, indicating success, and access is granted. Thus, an empty response string slips through as valid when it's actually invalid.
Intel should really check the two strings are the same length, since valid responses are always 32-byte MD5 hashes.
Thanks go to Embedi, which reverse engineered the code [PDF] and also reported the flaw to Intel back in March. Tenable also poked around in the service and came to the same conclusion earlier this week.
Intel has published some more info on the vulnerability here, which includes links to a tool to check if your system is at-risk, support contact details, and a list of mitigations to reduce the threat. That tool is apparently Windows-only; there's info here for Linux peeps.
There is also this third-party tool, here, for disabling AMT from Windows.
We're told the programming blunder is present in various, but not all, Intel processor chipsets from today's Kaby Lake family back to silicon sold in 2010: it mainly affects business PCs, professional workstations and small servers, rather than devices aimed at normal folk. However, Chipzilla admitted today that "consumers and small businesses" may end up using processors with the vulnerable tech present.
If you're using a vPro-enabled processor and have provisioned AMT versions 6 to 11.6 on your network, you are definitely at risk of the above vulnerability. This also affects Intel's Standard Manageability (ISM) and Small Business Technology (SBT) products. We recommend you use Intel's utility to double check whether or not you are being silently menaced by this bug.
How bad is this bug? Pretty bad. "The exploit is trivial, a maximum of five lines of Python, and could be doable in a one-line shell command," said SSH inventor Tatu Ylonen.
"It gives full control of affected machines, including the ability to read and modify everything. It can be used to install persistent malware – possibly in the firmware – and read and modify any data. For security servers, it may allow disabling security features, creating fake credentials, or obtaining root keys.
"Disable AMT today. Mobilize whomever you need. Start from the most critical servers: Active Directory, certificate authorities, critical databases, code signing servers, firewalls, security servers, HSMs (if they have it enabled). For data centers, if you can, block ports 16992, 16993, 16994, 16995, 623, 664 in internal firewalls now.
"If you have anything connected to the Internet with AMT on, disable it now. Assume the server has already been compromised."
The last time we looked on Shodan, there were more than 8,000 potentially vulnerable systems on the public internet. There will be thousands upon thousands more on internal corporate networks.
Now we play the waiting game: Show us the fixes
So where are we at with these patches, which must be distributed by the machine vendors presumably because they need to sign off on the firmware updates before they're put into customers' hands. We pinged some of the major suppliers of Intel-powered biz boxes for a status update. Here's what we got back:
A spokeswoman told us the PC maker will be in touch with its customers with details of the firmware updates, adding that the HP Inc is "working closely with Intel to validate and implement their firmware update and assist our customers in mitigation of potential risks." The complete list of affected products is here: there is a staggering shedload of products hit by this bug.
"This vulnerability is a security flaw that originated in the development and deployment of Intel's manageability firmware," the HP Inc rep told The Register.
"HP and Intel are working closely together to ensure there are appropriate fixes and tools for customers and their specific environments. HP is coordinating with our customers on a deployment plan. Our top priority is mitigating security issues and deployment complexity for our customers."
Patches are due to arrive toward the end of this month and into June, depending on the product family.
The PC slinger has an extensive page here detailing which machines are affected, and when fixes are likely to land – mostly from May 24 onwards into June. ThinkCentre, ThinkPad, ThinkServer, and ThinkStation lines are affected.
"Lenovo is fully aware of the firmware vulnerability in some versions of Intel’s manageability features that impacts certain Lenovo as well as other manufacturers’ PC devices," a spokesman for Lenovo told us.
"Lenovo’s Product Security Incident Response Team (PSIRT) is working closely with Intel on a permanent solution to the vulnerability. In the meantime, Lenovo is recommending all customers take the following steps to mitigate the problem:
"The network vulnerability can be mitigated by un-provisioning the Intel manageability SKU (AMT and ISM) or disabling the Intel manageability technology within the Intel MEBx. The local vulnerability can be mitigated by disabling or uninstalling Local Manageability Service (LMS) on Intel manageability SKUs (AMT, ISM, and SBT)."
That local vulnerability is a real but separate issue: if you have vPro and AMT present and enabled on your computer but not provisioned, you are still at risk from a local privilege escalation, as detailed in Intel's original advisory.
The Japanese IT giant has a page here listing steps to check if you're affected and how to get the firmware updates needed.
Hewlett Packard Enterprise
No one was available to comment nor confirm availability of any patches, if necessary.
No one was available to comment nor confirm availability of any patches, if necessary.
The networking and server equipment supplier says it is not affected. "Cisco PSIRT is aware of this issue," a Cisco spokesperson told us.
"At this time, our investigation has not identified any affected Cisco technology. If something new is found that our customers need to be aware of and respond to, we will make sure our customers know what it is and how to fix it through our established disclosure processes."
Apple's x86-powered Macs are not affected as they do not ship with Intel's AMT software. ®