mjg59 | Intel's remote AMT vulnerablity

Intel just announced a vulnerability in their Active Management Technology stack. Here's what we know so far.

Background

Intel chipsets for some years have included a Management Engine, a small microprocessor that runs independently of the main CPU and operating system. Various pieces of software run on the ME, ranging from code to handle media DRM to an implementation of a TPM. AMT is another piece of software running on the ME, albeit one that takes advantage of a wide range of ME features.

Active Management Technology

AMT is intended to provide IT departments with a means to manage client systems. When AMT is enabled, any packets sent to the machine's wired network port on port 16992 or 16993 will be redirected to the ME and passed on to AMT - the OS never sees these packets. AMT provides a web UI that allows you to do things like reboot a machine, provide remote install media or even (if the OS is configured appropriately) get a remote console. Access to AMT requires a password - the implication of this vulnerability is that that password can be bypassed.

Remote management

AMT has two types of remote console: emulated serial and full graphical. The emulated serial console requires only that the operating system run a console on that serial port, while the graphical environment ~~requires drivers on the OS side~~ requires that the OS set a compatible video mode but is also otherwise OS-independent[2]. However, an attacker who enables emulated serial support may be able to use that to configure grub to enable serial console. Remote graphical console seems to be problematic under Linux but some people claim to have it working, so an attacker would be able to interact with your graphical console as if you were physically present. Yes, this is terrifying.

Remote media

AMT supports providing an ISO remotely. In older versions of AMT (before 11.0) this was in the form of an emulated IDE controller. In 11.0 and later, this takes the form of an emulated USB device. The nice thing about the latter is that any image provided that way will probably be automounted if there's a logged in user, which probably means it's possible to use a malformed filesystem to get arbitrary code execution in the kernel. Fun!

The other part of the remote media is that systems will happily boot off it. An attacker can reboot a system into their own OS and examine drive contents at their leisure. This doesn't let them bypass disk encryption in a straightforward way[1], so you should probably enable that.

How bad is this

That depends. Unless you've explicitly enabled AMT at any point, you're probably fine. The drivers that allow local users to provision the system would require administrative rights to install, so as long as you don't have them installed then the only local users who can do anything are the ones who are admins anyway. If you do have it enabled, though…

How do I know if I have it enabled?

Yeah this is way more annoying than it should be. First of all, does your system even support AMT? AMT requires a few things:

1) A supported CPU
2) A supported chipset
3) Supported network hardware
4) The ME firmware to contain the AMT firmware

Merely having a "vPRO" CPU and chipset isn't sufficient - your system vendor also needs to have licensed the AMT code. Under Linux, if lspci doesn't show a communication controller with "MEI" or "HECI" in the description, AMT isn't running and you're safe. If it does show an MEI controller, that still doesn't mean you're vulnerable - AMT may still not be provisioned. If you reboot you should see a brief firmware splash mentioning the ME. Hitting ctrl+p at this point should get you into a menu which should let you disable AMT.

How about over Wifi?

Turning on AMT doesn't automatically turn it on for wifi. AMT will also only connect itself to networks it's been explicitly told about. Where things get more confusing is that once the OS is running, responsibility for wifi is switched from the ME to the OS and it forwards packets to AMT. I haven't been able to find good documentation on whether having AMT enabled for wifi results in the OS forwarding packets to AMT on all wifi networks or only ones that are explicitly configured.

What do we not know?

We have zero information about the vulnerability, other than that it allows unauthenticated access to AMT. One big thing that's not clear at the moment is whether this affects all AMT setups, setups that are in Small Business Mode, or setups that are in Enterprise Mode. If the latter, the impact on individual end-users will be basically zero - Enterprise Mode involves a bunch of effort to configure and nobody's doing that for their home systems. If it affects all systems, or just systems in Small Business Mode, things are likely to be worse.
We now know that the vulnerability exists in all configurations.

What should I do?

Make sure AMT is disabled. If it's your own computer, you should then have nothing else to worry about. If you're a Windows admin with untrusted users, you should also disable or uninstall LMS by following these instructions.

Does this mean every Intel system built since 2008 can be taken over by hackers?

No. Most Intel systems don't ship with AMT. Most Intel systems with AMT don't have it turned on.

Does this allow persistent compromise of the system?

Not in any novel way. An attacker could disable Secure Boot and install a backdoored bootloader, just as they could with physical access.

But isn't the ME a giant backdoor with arbitrary access to RAM?

Yes, but there's no indication that this vulnerability allows execution of arbitrary code on the ME - it looks like it's just (ha ha) an authentication bypass for AMT.

Is this a big deal anyway?

Yes. Fixing this requires a system firmware update in order to provide new ME firmware (including an updated copy of the AMT code). Many of the affected machines are no longer receiving firmware updates from their manufacturers, and so will probably never get a fix. Anyone who ever enables AMT on one of these devices will be vulnerable. That's ignoring the fact that firmware updates are rarely flagged as security critical (they don't generally come via Windows update), so even when updates are made available, users probably won't know about them or install them.

Avoiding this kind of thing in future

Users ought to have full control over what's running on their systems, including the ME. If a vendor is no longer providing updates then it should at least be possible for a sufficiently desperate user to pay someone else to do a firmware build with the appropriate fixes. Leaving firmware updates at the whims of hardware manufacturers who will only support systems for a fraction of their useful lifespan is inevitably going to end badly.

How certain are you about any of this?

Not hugely - the quality of public documentation on AMT isn't wonderful, and while I've spent some time playing with it (and related technologies) I'm not an expert. If anything above seems inaccurate, let me know and I'll fix it.

[1] Eh well. They could reboot into their own OS, modify your initramfs (because that's not signed even if you're using UEFI Secure Boot) such that it writes a copy of your disk passphrase to /boot before unlocking it, wait for you to type in your passphrase, reboot again and gain access. Sealing the encryption key to the TPM would avoid this.

[2] Updated after this comment - I thought I'd fixed this before publishing but left that claim in by accident.

(Updated to add the section on wifi)

(Updated to typo replace LSM with LMS)

(Updated to indicate that the vulnerability affects all configurations)

Flat | Top-Level Comments Only

From: (Anonymous)

>Not in any novel way. An attacker could disable Secure Boot and install a backdoored bootloader, just as they could with physical access.

I don't think this is actually possible with physical access — a properly configured system will at least require a supervisor password to disable Secure Boot.

>modify your initramfs (because that's not signed even if you're using UEFI Secure Boot)

This is not true if you've rolled your own Platform Keys and sign&boot plain kernel images (with initramfs bundled into them).

From:

mjg59

> I don't think this is actually possible with physical access — a properly configured system will at least require a supervisor password to disable Secure Boot.

I don't think AMT lets you bypass a supervisor password, so you'd have the same problem there. The point I was trying to make (not terribly clearly) was that it doesn't give you any means of persistence that physical access wouldn't also give you.

> This is not true if you've rolled your own Platform Keys and sign&boot plain kernel images (with initramfs bundled into them).

True, there are some niche configurations where you wouldn't have to worry about this.

Secure Boot won't save you at all

From: (Anonymous) - Date: 2017-05-02 07:04 am (UTC) - Expand

From: (Anonymous)

> I don't think this is actually possible with physical access — a properly configured system will at least require a supervisor password to disable Secure Boot.

That's assuming the case can't be opened to allow the supervisor password to be cleared by the usual physical methods.

From: (Anonymous)

Are Apple Macs impacted by this at all?

From:

mjg59

No. Apple hardware has an ME, but Apple don't ship the AMT firmware for it.

From: (Anonymous)

Is it enough to scan your entire subnet for TCP port 16992 listeners good enough to test for this? If not is there a good way to scan for it rather than looking for devices on each computer?

From:

mjg59

Should be fine.

From: (Anonymous)

You'll want to check 16993 as well. If you want to drill a little deeper, you'll want to look for servers responding with HTTP 200 status and "Server: Intel(R) Active Management Technology {version number}" or "Server: AMT".

From:

squirrelitude

I configured AMT on my work-provided Thinkpad T430s laptop (default password admin, new password must meet requirements) and connected it to ethernet.

When I scanned my home LAN with nmap -p16992,16993,16994,16995,623,664 192.168.1.0/24 I only found that one machine listening on any of the ports:

Nmap scan report for 192.168.1.142
Host is up (0.0036s latency).
PORT      STATE  SERVICE
623/tcp   open   oob-ws-http
664/tcp   closed secure-aux-bus
16992/tcp open   amt-soap-http
16993/tcp closed amt-soap-https
16994/tcp closed unknown
16995/tcp closed unknown

I also confirmed that AMT was the culprit:

$ curl -sS http://192.168.1.142:623 -i
HTTP/1.1 303 See Other
Location: /logon.htm
Content-Length: 0
Server: Intel(R) Active Management Technology 8.1.2

$ curl -sS http://192.168.1.142:16992 -i
HTTP/1.1 303 See Other
Location: /logon.htm
Content-Length: 0
Server: Intel(R) Active Management Technology 8.1.2

The logon.htm page says "Web browser access to Intel® Active Management Technology is disabled on this computer, or the page in the address bar is unavailable."

Note that making those curl calls from the machine itself results in connection refused! (No matter whether I call via localhost or wlan0 or eth0 LAN IPs.) It has to be from another machine.

The machine in question is willing to try to listen on those ports at the OS level, but an attempt to connect and send data is intercepted by AMT. That's another way you could tell, I suppose.

I did not observe these behaviors when connected over WiFi instead of ethernet.

Edited (formatting) Date: 2017-05-02 02:29 pm (UTC)

Re: Is a port scan good enough?

From:

sketch242 - Date: 2017-05-02 03:34 pm (UTC) - Expand

Re: Is a port scan good enough?

From:

squirrelitude - Date: 2017-05-02 03:42 pm (UTC) - Expand

Re: Is a port scan good enough?

From: (Anonymous) - Date: 2017-05-17 08:45 am (UTC) - Expand

Re: Is a port scan good enough?

From:

leo_sosnine - Date: 2017-05-02 06:47 pm (UTC) - Expand

Re: Is a port scan good enough?

From: (Anonymous) - Date: 2017-05-02 08:42 pm (UTC) - Expand

Re: Is a port scan good enough?

From:

leo_sosnine - Date: 2017-05-02 09:40 pm (UTC) - Expand

Re: Is a port scan good enough?

From: (Anonymous) - Date: 2017-05-02 09:23 pm (UTC) - Expand

Re: Is a port scan good enough?

From:

sketch242 - Date: 2017-05-03 03:39 pm (UTC) - Expand

Re: Is a port scan good enough?

From:

mjg59 - Date: 2017-05-03 03:47 pm (UTC) - Expand

From: (Anonymous)

Hi Matthew,

best read so far on that Topic, thanx for this.

is it enough to have iptables enabled with a input-policy set to drop/reject or will the packages bypass this?

thanx in advance,

homer

From: (Anonymous)

If you mean an iptables firewall on a distinct physical machine placed in front of the machines you're trying to protect, then it will be enough to prevent remote attacks.

If you mean an iptables firewall on the same physical machine as the one you're trying to protect, it will be useless; like Matt mentioned in the second paragraph, the OS never even gets to see these packets, the ME steals them off the Ethernet adapter.

Re: IpTables

From:

bens_dad - Date: 2017-05-02 07:56 am (UTC) - Expand

From: (Anonymous)

> any packets sent to the machine's wired network port on port 16992 or 16993

AMT isn't limited to wired networking hardware. If the machine has a supported Intel WiFi module, this will also work over wireless networks.

From: (Anonymous)

From the mitigation document, the list of ports is as follows:

16992, 16993, 16994, 16995, 623, and 664.

From: (Anonymous)

I'm assuming that AMT acts like an iLO for the desktop. Would this mean that the IP address used would be different to that of the OS?

Looking in the intel management and security status utility, the Network information on the advancex tab shows 0.0.0.0 which Im assuming means that AMT is not provisioned/configured.

Would this assumption be correct?

From: (Anonymous)

Would this mean that the IP address used would be different to that of the OS?

AMT can function in two modes: independent IP (with VLAN and IPv6 support in later versions) and cloning of DHCP-provided IP. In the former AMT listens to DHCP traffic to sniff out the network configuration and binds that to itself as well as the local OS. After that it intercepts all packets intended for AMT ports so that the local OS won't see them.

Static configuration of the host OS won't assign an IP to AMT. Using a separate NIC won't configure AMT, obviously ;)

Re: Does AMT require a different IP?

From: (Anonymous) - Date: 2017-05-02 03:21 pm (UTC) - Expand

From: (Anonymous)

AMT has two types of remote console: emulated serial and full graphical. The emulated serial console requires only that the operating system run a console on that serial port, while the graphical environment requires drivers on the OS side.

Sadly this is incorrect. The full-blown graphical capability of AMT is providing a fully functional OS-independent VNC server that can be connected to by any proper VNC client. It is disabled by default and can be configured to require a simple (max. 8 char) VNC password.

Whether your AMT has this capability or not depends on the OEM. This feature is, along with many AMT functions, configurable in the factory. You can even put your AMT-capable motherboard into the manufacturing mode most of the time (it requires physical fiddling).

From:

mjg59

Thanks - I meant to remove that before publishing but missed that sentence. I've updated the post.

From: (Anonymous)

I do have a Communication controller with HECI in the description but ctrl+p does not seem to do anything when booting.

I have also tried setting the "boot next" entry to "MEBx Hot Key" with efibootmgr and that also does nothing.

Scanning my laptop (from another machine) for open TCP ports 623,664,16992-16995 does not yield any results so I suppose I'm safe.

I do not recall if I have had access to MEBx at any point in time, I do remember permanently disabling computrace and I'm not sure if after disabling AMT it will become "unreachable".

What I do know is that lenovo issued a firmware update for this machine not too long ago and if I recall correctly it was described as critical on their website (they have since issued another update and the page for the previous update seem to be gone). The changelog had this to say about the update:

[Important updates]
1. [Important] Update includes a security fix.
(Note) If the UEFI BIOS has been updated to version 1.25 or higher, it is no longer able to roll back to the version before 1.25 for security improvement.

[New functions or enhancements]
N/A

[Problem fixes]
N/A

From: (Anonymous)

The sensor hub on modern Intel x86's is also a HECI device but a different one so you can have HECI without having vpro.

Re: How do I know if I have it enabled

From: (Anonymous) - Date: 2017-05-02 05:42 pm (UTC) - Expand

From: (Anonymous)

Good thing that Purism actively avoids the problem (https://puri.sm/learn/avoiding-intel-amt/)... short of Intel changing its mind on AMT and the ME, it's pretty much the best solution.

From: (Anonymous)

If you are curious too: Thinkpad x230 without vPro CPU (According to Intel, see i5-3230M (https://ark.intel.com/products/72164/Intel-Core-i5-3230M-Processor-3M-Cache-up-to-3_20-GHz-rPGA#tab-blade-1-0-7)) still have a MEI controller built in. Anyone knows what's the difference?


$ lspci | grep MEI
00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04)

From:

leo_sosnine

Just scanned my subnet and noone seems to have these ports open, I guess it's not enabled even if supported

I wonder what's the percentage of active computers that have AMT enabled & configured, it could be a rather small number

From: (Anonymous)

We are getting connections to the ports specified with ncat -u. Is that a reliable test? We can't connect with any other method.

From:

mjg59

No, -u is connecting via UDP and AMT is only listening on TCP. If you can't connect via TCP (from a remote machine) then you're fine

From: (Anonymous)

What about remote provisioning?
https://en.wikipedia.org/wiki/Intel_AMT#Provisioning_and_integration

What would prevent an attacker on the local network(For instance in a WiFi cafe) from:
- Buy a certificate to do remote provisioning
- Running a DHCP server that responds faster than the WiFi cafe's DHCP server
- Remote provision the laptop they want
- Then bypassing that remote provisioning

Would this work on recent AMT versions?, or is it only a concern for GM45 as this was the chipset used by Vassilios Ververis in his research?

Is it possible to gain code execution from AMT, in a programable way, to the machine trough either:
- Remote storage
- The keyboard

I've only old GM45 laptops that can have AMT, so I've no way to check that.

If both assumptions are correct, then worms can be a grave concern.

In the long term, I see no other way than having completely free software computers to avoid such issues. This would permit people to still benefit from security updates.

Denis.

From: (Anonymous)

The current state of boot security:
and the Management Engine is in a position to just do whatever it wants and fuck all of you.

https://mjg59.dreamwidth.org/39339.html

From: (Anonymous)

Hi Guys , in linux do this :
-> sudo su
-> lspci | grep EHCI

In the article says that is HECI but the correct is EHCI.

From: (Anonymous)

> lspci | grep HECI

00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)

Re: A little mystake in your article

From:

mjg59 - Date: 2017-05-03 03:47 pm (UTC) - Expand

From: (Anonymous)

> Remote graphical console seems to be problematic under Linux but some people claim to have it working

You can add me to the list of people who claim to have it working :)

If someone wishes to fiddle with it, install node and http://www.meshcommander.com/meshcentral2 . Start it and point your browser at it (I think it defaults to port 1024). You'll have to add a device, enable KVM in its properties page, and then you can open the graphical console.

Note that the version I downloaded, at least, restricts AMT passwords more than the AMT firmware does - I patched meshcentral but in hindsight it's probably easier to change the device's password.

From: (Anonymous)

A few more things.

1) Enabling kvm is a very important step that's easy to miss. Meshcentral doesn't give you any helpful hints if you forget it.

2) When the remote graphical console is in use, the _physical_ display will have an alternating yellow/red border and will periodically go blank. Impossible to miss and highly annoying (if you're OK with the remote access). I suspect there's a way to disable this when connecting with one of the expensive/"secure" tools, as otherwise the poor person being helped would start bleeding from the eyes.

3) On the device I've used it with, a monitor must be plugged in or the remote graphical console won't work.

4) When the OS initializes NICs, it may cause AMT to lose connectivity. I tried to give my ME its own hostname in the BIOS config (which should fix this), but got incomprehensible errors when I tried to change the option. On multi-NIC systems, one solution is to prevent the OS from using the NIC shared with AMT.

From: (Anonymous)

SemiAccurate have addressed the discrepancy between their initial announcement (https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/) and Intel's advisory (https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr):

https://semiaccurate.com/2017/05/03/consumer-pcs-safe-intel-meamt-exploit/

From: (Anonymous)

I've worked with AMT before. When AMT is enabled, the OS will forward packets when connected to any WiFi network. Explicit network configuration is only required for AMT to connect to WiFi while the OS is not running. Furthermore, by default AMT will only connect to known WiFi networks when the machine is plugged in to external power, but that can by configured to listen while on battery power too.

If you ping a machine, you can usually tell if it's the OS or AMT ME responding to the ping based on the ttl, as AMT ME will use a 255 ttl, as opposed to other OSes that respond with a ttl of 64.

From: (Anonymous)

When the PC is not running but is plugged in and AMT is communicating over Ethernet, do the blinkenlights on the NIC flash or not?

Are exploits known to disable these LEDs, as with the Apple iSeeYou vulnerability?

From: (Anonymous)

the led's wouldnt need to be active, the chip probably uses active-low outputs to drive them.
so if the led's anodes are connected to the 5v line rather than the 5v standby line - no - they wont light.

btw, AMD has a similar MCU in it's core chipset - this whole setup just stinks of intelligence agency's!