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: https://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»
Notice how 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_lengthbytes 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.
Unfortunately, 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 binaries 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.
Source:https://www.theregister.co.uk/2017/05/05/intel_amt_remote_exploit/
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
