On May 1, 2017 Intel disclosed the AMT vulnerability (INTEL-SA-00075), but details of that vulnerability were not made public. However, Tenable researchers were able to overcome this challenge and make Tenable the first to deliver Intel AMT vulnerability detection capabilities to customers, just minutes after Intel’s announcement yesterday. This is the story of how we did it.
The hunt
The first thing our research team tried was to set up a known vulnerable target. After some searching, we found a Dell computer that had Intel AMT support but there was a problem. It was not configured/provisioned for what we needed.
The Intel Management Engine Interface (MEI) driver was installed but the Local Management Service (LMS) was not. Intel AMT documentation says the AMT configuration tool ACUWizard.exe requires LMS to be running.
So we searched and found a software package for installing LMS on the vendor's website. After LMS was installed, we were able to configure/provision AMT on the computer, giving us access to AMT via the web interface.
Next, we logged in to the web interface and browsed the menu items:
A logical vulnerability
During this process, we found out that the HTTP Digest authentication method was used to access the web interface. In a blog post written by Embedi (the company of the researcher who discovered the vulnerability) a bullet point stood out:
With 100 percent certainty it is not an RCE but rather a logical vulnerability.
One hypothesis we had was that this logical vulnerability may be related to authentication. After all, a logical vulnerability that seems to involve decision-making and authentication certainly falls into this category (i.e., deciding whether a login credential is right or wrong). If correct, this would give a remote attacker access, as suggested by the Intel advisory.
Drawing on past experience when we reported an authentication-related vulnerability in which the length of credential comparison is controlled by the attacker (memcmp(attacker_passwd, correct_passwd, attacker_pwd_len)), we tested out a case in which only a portion of the correct response hash is sent to the AMT web server. To our surprise, authentication succeeded!
Next, we reduced the response hash to one hex digit and authentication still worked. Continuing to dig, we used a NULL/empty response hash (response="" in the HTTP Authorization header).
Authentication still worked. We had discovered a complete bypass of the authentication scheme.
With a simple find_and_replace regex (find: response\s*="[0-9a-f]+", replace: response="") in Burp Suite, we could fire up a web browser configured to use the proxy, and log in to the AMT web interface with the user admin and any password.
Coordinated disclosure
With our findings confirmed, the next question was whether the authentication bypass vulnerability that the Tenable Research team had just discovered was the same one described in the Intel AMT advisory, or if was in fact another critical vulnerability.
As any good researcher knows, it is important to get this disclosure part right – the discovery of a possible zero-day in widely distributed firmware isn’t something you take lightly.
Tenable reached out to Intel on May 3 with our proof-of-concept, asking if this was the same vulnerability previously disclosed by Intel on May 1. On May 4, Intel responded confirming that it was the same vulnerability and requested we wait to share our findings until 12:00 p.m Pacific time that day.
That meant that within minutes of the Intel deadline, Tenable was able to give customers a detection plugin (Nessus plugin 97999) to help them know exactly where they are exposed to the Intel AMT vulnerability so they can continue to confidently manage cyber risk to the business.