Strike Back at Silent Bob: Scan and Block Ports Used by Intel AMT

The Intel Active Management Technology (AMT) vulnerability (now referred to by many as “Silent Bob”) is one of those truly brutal, ugly ones that make you queasy to even think about. Like Heartbleed or Venom. If your organization had exposure to it, a threat actor could own your domain controller, which is basically the worst possible outcome, isn’t it?

Figure 1: SSH creator calling for disabling AMT ports.

Tatu Ylolen, creator of the cryptographic network protocol Secure Shell (SSH), has been shouting (tweeting) from the rooftops about the Intel AMT vulnerability for weeks. And, for a time, the SSH tracking page1 contained the bold statement, “THIS VULNERABILITY IS EVEN WORSE THAN I EVER IMAGINED!” Tatu’s discomfort came from his assumption that every Intel Xeon processor, anywhere—from laptops, to firewalls, to telephone networks, or what have you—was vulnerable via this authentication back door.

It was never a remote code execution vulnerability, as some had previously stated; the Intel AMT vulnerability is a flaw in the authentication code. The AMT management console uses HTTP-Digest for authentication, which is fine, but if you send a truncated (or even a zero-length) digest, the authentication succeeds anyway. Ooops!

Figure 2: Authentication success!

While Intel didn’t come out and tell everyone exactly what the problem was, the guys at Tenable figured it out within minutes,2 and even show how simple it would be to exploit via Burp Suite. They’ve updated Nessus3 to scan for it, and everyone is broadly recommending that we all disable ports 16992, 16993, and 623 for good measure.

So yeah, the vulnerability is really bad, but how exposed is everyone?

Turns out, maybe not so much. The early doom-saying on the SSH page was a bit hyperbolic. Consider this; the AMT service runs on ports 16992 and 16993 only when you have a compatible CPU, compatible chip-set, supported network interface in the "first network interface" slot, Intel AMT blob in the BIOS, and BIOS provisioned to enable AMT.

Most of the systems with all of these conditions being true will come from major PC vendors, like Dell, HP, and Lenovo, that serve customers with well-developed PC fleet administration tools. And ideally, systems of that complexity would never be connected to untrusted networks, would they?

Figure 3: SHODAN Port 16992 Results

A quick SHODAN search for port 16992 finds a moderate number of hosts (about 33,000). Delving a little deeper into the data shows that, indeed, most of the responses look like they are coming from Intel AMT management servers.

One question that some architects are asking is why did it take nearly a decade to find this vulnerability, especially if it was suspected to be present all along? Tatu Ylolen suggests that if Intel had made the AMT management software open source, this would have been found much earlier.

Figure 4: Speed Guide port 16993 activity spike beginning in March 2017

Speed Guide shows a massive spike in the searches for port 16993 in the three months preceding the release of the Intel vulnerability. It is unclear if these scans were from whitehat researchers who were attempting to determine the extent of the exposure, of if it was a malicious actor armed with foreknowledge of the problem. If it was the latter, then that’s scary, isn’t it?

Either way, 33,000 vulnerable hosts is a large enough number that responsible architects should be wondering if they or their customers or partners have exposed Intel AMT servers.

Recommendation

We at F5 Labs echo the recommendations that you explicitly block ports 16992 and 16993 if you haven’t already. Unless you are actively using the Intel AMT management plane, we recommend you block these ports even for east-west traffic to prevent lateral movement by attackers.

Also note that the very handy nmap tool4 has an AMT script that can be used to find vulnerable AMT servers on the network. Run a quick scan to find out how many vulnerable servers you have, if any.

% nmap -p 16992 --script http-vuln-cve2017-5689 <target>