There have been some reports to us about an issue with Intel Active Management Technology, Intel Small Business Technology, and Intel Standard Manageability [1]. It might be a good idea to review Intel’s security bulletin INTEL-SA-00075, which outlines a Privilege Escallation vulnerability. 

What they really mean is that if you are actively using an AMT management solution, your managed stations are remotely exploitable.  If you are not using such a system, then you are locally exploitable.

The document also states very clearly that "This vulnerability does not exist on Intel-based consumer PCs.” [1].  However, the affected and resolved firmware table indicates which generation of the Core CPU architecture is affected.  This seems to be a bit of a contradiction to me.  I also find it very odd to see a security advisory on Intel AMT that does not mention vPro (the matching feature on the workstation) even once.  You'll also see below that an unmanaged but vPro equiped Windows machine will likely show some of the markers for this issue.  If this issue could be leveraged to compromise unmanaged but vPro equiped desktops, laptops and other equipment, this could get very bad, very quickly (or worse than it is now anyway). 

The more we look at this though, the more it seems that any host with a vulnerable version of the service installed is itself vulnerable (see below).  Many vendors install the affected Intel code as part of their factory image.  So the "does not exist on consumer PCs" statement does not hold water for me.

Anyway, the affected / resolved firmware version (from the Intel advisory) is here:

Yes, that's all the way back to gen 1 Core CPUs (Nehalem era , 2007) right up to the latest Kaby Lake chips.

Intel released an update on April 25, and advises that the system or system board manufacturers should be releasing their firmware versions to affected customers.  That is, if your vendor releases a patch for your system - there are a LOT of older computers out there - and newer ones too - that will likely never see this update!

Intel has published a mitigation guide and it can be accessed online [2]. One item of note from the guide is checking to see if ports are listening with netstat. The IANA assigned ports are: 16992, 16993, 16994, 16995, 623, and 664.

    netstat -na | findstr "\<16993\> \<16992\> \<16994\> \<16995\> \<623\> \<664\>"

On my laptop:

C:\>netstat -na | findstr "\<16993\> \<16992\> \<16994\> \<16995\> \<623\> \<664\>"
  TCP    0.0.0.0:623            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:16992          0.0.0.0:0              LISTENING
  TCP    [::]:623               [::]:0                 LISTENING
  TCP    [::]:16992             [::]:0                 LISTENING

 

What's behind the listening port 16992? Let's look with curl, and we'll see that a simple connect / get gives up the AMT version.  A great way to verify your patch (or disable) progress over the network, but also a good way for an attacker to find a pivot host.

C:\> curl -v http://192.168.122.62:16992
* About to connect() to 192.168.122.62 port 16992 (#0)
*   Trying 192.168.122.62... connected
* Connected to 192.168.122.62 (192.168.122.62) port 16992 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.0 (amd64-pc-win32) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.
2.3
> Host: 192.168.122.62:16992
> Accept: */*
>
< HTTP/1.1 303 See Other
< Location: /logon.htm
< Content-Length: 0
< Server: Intel(R) Active Management Technology 9.0.22
<
* Connection #0 to host 192.168.122.62 left intact
* Closing connection #0

(Update 2 May): Fellow Incident Handler Adrien pulled this screenshot, which is up on a default workstation install:

Intel's mitigation guide [2] posts a detailed document on removing the supporting code in Windows by disabling or removing the affected service, either from the command line or in Group Policy.  What it boils down to is you want to stop and disable the LMS Service (Local Management Service), then delete LMS.exe.  On my (not managed by AMT)  laptop, this shows up in the services list as "Intel(R) Management and Security Application Local Management Service".  LMS.EXE is located in  C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\LMS.

Another good resource to review is the Intel SCS System Discovery tool [3]. The tool site also notes registry locations for discovery.

    HKLM\SOFTWARE\Intel\Setup and Configuration Software\SystemDiscovery (32-bit and 64-bit operating systems)
    HKLM\SOFTWARE\Wow6432Node\Intel\Setup and Configuration Software\SystemDiscovery (64-bit operating systems)

You can sleuth for these using powershell just as easily, or even a batch file and the "reg query" command (comes up with nothing on my laptop):

C:\>reg query "HKLM\SOFTWARE\Intel\Setup and Configuration Software\SystemDiscovery"
ERROR: The system was unable to find the specified registry key or value.

C:\>reg query "HKLM\SOFTWARE\Wow6432Node\Intel\Setup and Configuration Software\SystemDiscovery"
ERROR: The system was unable to find the specified registry key or value.

Or, in PowerShell:

So as you'd expect, I'm locally vulnerable (watch out for the next crop of malware and metasploit modules!), but not remotely vulnerable.   Now that I've dumped the LMS service, I'm (as far as I know) OK (for now) on this front.

Another possible method of discovery would be over the network, using nmap. Try:

nmap -iL <yourTestList.txt> -p 16992-16995,623,664 -oG <outputFileScanTest.txt>

Preference for Grepable format here, see man pages for output types.

If you need to generate IP lists try this handy script (total shout out to Violent Python!) [5]

#!/usr/bin/env python
# Get our List
# The Variable has to be encapsulated in " " or this poorly written script will error out.
targets = input('Enter 3 Octet IPv4 Target List \(e.g., \"10.10.10.\"\) Please encapsulate in \" \": ')
# Open the list File
scanTargets = open('scanTargets.txt','w')
# Write our list to the file
for x in range(1,255):
            targets.write(str(targets)+ "%s\n" % x)

We are tracking this one, if you have anything to share please send it in and we will update this diary, or use our comment form

What should you do right away?  Go back to the Critical Controls (https://www.cisecurity.org/controls/) - get a good, complete hardware inventory together, and get a good software inventory - know what's in your organization and on your network, and know what's running on that gear.  This includes elevator controls, industrial presses, MRI machines, point of sale stuff, TVs, DVRs and photocopiers - all of it!  Without knowing what's on your network, the best you'll do is to get a reasonable percentage of affected systems - you'll never patch the machines you don't know about. 

This bug is something that's going to stick with us for a good. long. time.

References:
[1] https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr
[2] https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20Mitigation%20Guide-Rev%201.1.pdf
https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
[3] https://communities.intel.com/docs/DOC-5765

=================
Richard Porter
Rob VandenBrink

 

********** Update 3 May 2017 **********

Of course we saw a spike in internet-wide scanning for tcp/16992 after Intel's release of this advisor.

More interestingly though, we saw an uptick of scanning for tcp/16992 *prior* to the Intel announcement, starting early April - see for yourself here:  https://isc.sans.edu/port.html?port=16992