How to detect and mitigate the Intel escalation of privilege vulnerability on a Linux system (CVE-2017-5689)?
The clearest post I’ve seen on this issue is Matthew Garrett’s (including the comments).
Matthew has now released a tool to check your system locally: build it, run it with
sudo ./mei-amt-check
and it will report whether AMT is enabled and provisioned, and if it is, the firmware versions (see below). The README has more details.
To scan your network for potentially vulnerable systems, scan ports 623, 624, and 16992 to 16993 (as described in Intel’s own mitigation document); for example
nmap -p16992,16993,16994,16995,623,664 192.168.1.0/24
will scan the 192.168.1/24 network, and report the status of all hosts which respond. Being able to connect to port 623 might be a false positive (other IPMI systems use that port), but any open port from 16992 to 16995 is a very good indicator of enabled AMT (at least if they respond appropriately: with AMT, that means an HTTP response on 16992 and 16993, the latter with TLS).
If you see responses on ports 16992 or 16993, connecting to those and requesting / using HTTP will return a response with a Server line containing “Intel(R) Active Management Technology” on systems with AMT enabled; that same line will also contain the version of the AMT firmware in use, which can then be compared with the list given in Intel’s advisory to determine whether it’s vulnerable.
See CerberusSec’s answer for a link to a script automating the above.
There are two ways to fix the issue “properly”:
- upgrade the firmware, once your system’s manufacturer provides an update (if ever);
- avoid using the network port providing AMT, either by using a non-AMT-capable network interface on your system, or by using a USB adapter (many AMT workstations, such as C226 Xeon E3 systems with i210 network ports, have only one AMT-capable network interface — the rest are safe; note that AMT can work over wi-fi, at least on Windows, so using built-in wi-fi can also lead to compromission).
If neither of these options is available, you’re in mitigation territory. If your AMT-capable system has never been provisioned for AMT, then you’re reasonably safe; enabling AMT in that case can apparently only be done locally, and as far as I can tell requires using your system’s firmware or Windows software. If AMT is enabled, you can reboot and use the firmware to disable it (press CtrlP when the AMT message is displayed during boot).
Basically, while the privilege vulnerability is quite nasty, it seems most Intel systems aren’t actually affected. For your own systems running Linux or another Unix-like operating system, escalation probably requires physical access to the system to enable AMT in the first place. (Windows is another story.) On systems with multiple network interfaces, as pointed out by Rui F Ribeiro, you should treat AMT-capable interfaces in the same way as you’d treat any administrative interface (IPMI-capable, or the host interface for a VM hypervisor) and isolate it on an administrative network (physical or VLAN). You cannot rely on a host to protect itself: iptables etc. are ineffective here, because AMT sees packets before the operating system does (and keeps AMT packets to itself).
VMs can complicate matters, but only in the sense that they can confuse AMT and thus produce confusing scanning results if AMT is enabled. amt-howto(7) gives the example of Xen systems where AMT uses the address given to a DomU over DHCP, if any, which means a scan would show AMT active on the DomU, not the Dom0...
Simply detecting the open ports for this service is insufficient, it doesn't indicate if the version is affected or not. Our team has created a python script available at our github : CerberusSecurity/CVE-2017-5689 that detects if a target system is vulnerable to remote attack.
Sample usage:
python CVE_2017_5689_detector.py 10.100.33.252-255
This should allow you to be able to check if you are remotely exploitable. If you are interested, we also wrote a short blog post at http://cerberussec.org/ with our take on this vulnerability.
Intel has tools for linux at : Linux Detection and Mitigation Tools
there is a fork of it at GITHUB