Ever since Intel ME has made the news, partial and (sometimes) contradictory information about it has been scattered all over the internet. What follows is a discussion of the official functionality that AMT offers, from the perspective of someone concerned about security, with a particular focus on networking, including the difference between wired and wireless connections. My intention is to be comprehensive, because a summary like this was long overdue.
Overview of AMT remote management functionality
The Intel ME Interface Driver
Intel AMT docs say that a driver (called the Intel ME Interface Driver) has to be installed and running in the operating system, for ME and OS applications to communicate. The docs mention that the driver is included in Linux kernels since 3.4-rc5, which can be confirmed. What about the Xen kernel?
The Xen project docs do mention support for Intel AMT. However, no Intel ME Interface driver is shipped with the Xen kernel. What is possible on a Xen system however (and on any other system, independently of the Intel ME Interface driver), is to enable the AMT virtual serial console. What this capability consists of is described next.
AMT capability: virtual serial console
This is also known as a serial-over-lan (SOL) console; it allows to redirect the BIOS, bootloader and OS kernel to a console exposed over the network (culminating in shell access, once the kernel is fully loaded). BIOS can be configured separately for this; the rest requires configuration of the bootloader (GRUB), including arguments for the kernel it loads, so that they know to redirect themselves to the port of the SOL console. This document from Intel shows examples of how the SOL console can be used on Windows, including during the booting process; this is what the console output for GRUB/Xen looks like, after everything was configured. In addition to the Xen docs linked in the previous paragraph, there is even a man page on die.net containing a concise summary of how to use Intel AMT (including the SOL console) on Linux/Xen.
The ports AMT is listening on
Once enabled, all Intel AMT services are accessible from the network via ports 16993, 16995 and 664:
TCP/UDP messages addressed to certain registered ports are routed to Intel AMT when those ports are enabled.
Contrary to the above quote, which says that packets are routed to AMT only when the ports are enabled, at least back in 2017 disabling AMT using the official way via the Intel CSME (aka the ME BIOS Extension; this method corresponds to the third entry in this list of possible ways to disable ME) did not seem to restore the ability of the operating system to receive packets on those ports (i.e traffic was still being intercepted regardless of AMT being officially turned off). Read the comments on that link carefully; they contain important technical information regarding possible solutions to this. OP was eventually able to regaing control of the ports by switching off the on-board ethernet NIC and using a different one instead; however, it is very possible that Intel AMT could ship with drivers for any kind of card!
Recap so far
The question we’d like to answer is: could AMT ever hijack a Qubes machine, at a useful level (spanning from BIOS down to an AppVM), while listening to ports on the network interface?
It is clear at this point that even as part of official functionality, AMT can provide via network access, at the minimum, a virtual serial console, which is available even during BIOS start up; that means, completely independent of the operating system. This requires only configuration in the BIOS (using the Intel CSME/ME BIOS Extension). If, furthermore, the bootloader also has the required configuration (which has to be added manually) and/or the kernel of the operating system has the necessary drivers (which is likely, whether it’s Windows or Linux), then a network connection to AMT also exposes the kernel and the user land. And what can AMT do then? Here’s an example: filtering packets to and from applications running on the operating system, as a way to isolate the system “in case of a malware attack”.
But there is another important aspect that needs to be mentioned now: the various differences that wired and wireless network connections make for AMT functionality.
Wired vs. wireless
Limitations at operating system level
The current AMT docs specify that remote management at the application level (c.f BIOS/bootloader/kernel level via SOL console) is not available at all under Linux, over WiFi; only over ethernet. And even under Windows, “if the user turns off the wireless transmitter/receiver using either a hardware or software switch, Intel AMT cannot use the wireless interface under any conditions”. This is quite an interesting limitation on machines which are WiFi-only.
Limitations in traffic interception
The same page says that, (only) when Windows is using a wireless connection, it is the Intel ME Interface Driver, which might redirect the relevant traffic to AMT; in other words, Intel AMT will not intercept traffic directly:
Messages received on a wired LAN interface go directly to Intel AMT. [But] messages received on a wireless interface go to the host wireless driver. The driver detects the destination port and sends the message to Intel AMT.
But then there’s an apparent contradiction:
When there is a problem with the [WiFi driver of the operating system] and the host is still powered up (in an S0 power state only), Intel AMT can continue to receive out-of-band manageability traffic directly from the wireless network interface.
Does Intel AMT intercept network traffic directly at the NIC, or is it reliant on Windows to redirect it?! The explanation is given here. It appears that either the operating system, or Intel AMT directly, must intercept traffic arriving at the wireless card; they can’t do it simultaneously, as in the case of a wired connection. So in order for the operating system and its applications to have internet access, AMT must surrender its own monitoring. But as long as the operating system is not actively controlling the WiFi card (e.g Windows WiFi driver fails, the computer is asleep, rebooting etc.), then Intel AMT happily takes over the wireless card - provided it has the WiFi access point credentials (more on this in the next section).
Another interesting bit on the same page specifies how Intel AMT has a special mode where it can protect its control over the WiFi connection with High priority, never surrendering it back to the operating system. And “there is no external API for setting this mode”. Come on, guys.
Limitations regarding WiFi access point credentials
Configuration of WiFi credentials for AMT to use is actually optional, but only as long as the OS driver is active, because then the credentials will just be synchronised from the existing connection. If Intel AMT was not configured with its own credentials and neither does the operating system have an active connection, then AMT will (apparently) not have network access. This seems pretty logical.
Limitations of WiFi card
Officially, “the Wireless adapter must be Intel AMT compliant. […] Any wireless adapter other than one from Intel will not have wireless Intel AMT capabilities.” The Intel 8265 and AX210 wifi cards are both vPro (i.e AMT) compatible; these cards are extremely common, for example in Thinkpads. But as mentioned earlier in the case of shutting down traffic interception over ethernet connections, it is also conceivable that Intel ME could ship with drivers for other NICs.
Recap of how AMT works over WiFi
AMT is available over WiFi, when the system has a compatible WiFi card and the operating system (whatever it is) is not actively controlling the card; some additional management functionality for application-level stuff is only available for Windows (but this doesn’t make much of a difference, when the proper configuration is in place for a SOL console). Here is a summary from Intel of the differences in AMT over wired vs wireless. It stresses that AMT must have some kind of credentials for the WiFi access point and it must be enabled manually. AMT behaviour is, of course, intended to be responsible (of course), so it doesn’t just connect to public WiFi networks whenever it has a chance. In contrast, with a wired connection, everything is on and active by default.
In closing
It took a long time, but it seems that eventually I’ve answered my own question, as stated in the first post. If by any chance you are here because you’re trying to secure your wealth and found this information useful - please share. I’m smart and kind, but very poor.
0x241C3b8275598B2ECF5a49F21e07114fFD1DF94C
bc1qzr4pc9ecyrgrmsm8g2p0z2yhrh4wuc67sgq9pq
47TxGuxXJ96h4sFRddLzLsWLC6HjCMtUndeYQt4z2FBeaHBzYJFzyS6HDb5FGJqwxQ4rym9WzmWF7NqnacsPUqu4MTVaKSh
P.S.:
I suppose I would be remiss if I didn’t point out that Intel AMT has received a significant level of scrutiny, over more than a decade (and in particular, more scrutiny than AMD’s own equivalent did; although in AMD’s case, a network stack was not discovered, which led researchers to conclude it was not as important to neutralise it). As a result of this interest, several vulnerabilities in Intel AMT were discovered and subsequently fixed, meaning it is battletested to an extent; this also lead to (however limited) assurance that there are no undocumented features. As of 2017, the opinion of me_cleaner devs (the unofficial tool used to neutralise ME) is that a backdoor is unlikely. And for whatever it’s worth, part of Intel ME lore is also a candid anon comment from someone purportedly on the Intel ME team.