In light of recent news about Intel’s AMT vulnerability, does anyone know the risk of running pfSense on a system that has this vulnerability? What if the system is old enough junk that it’s unlikely to receive a timely patch from the vendor?
Is there any way to mitigate the risks of continuing to use such a system?
Would the firewall be capable of blocking AMT connections?
I've seen a lot of conflicting reporting. Most agree, however, that if you don't use the on-board NICs, you should be OK. Intel PCIe dual port NICs are pretty cheap. Intel quad port are a little more dear, but there are hardware recycles that sell used Intel NICs at pretty reasonable prices.
Note: These NICs are in demand, so be alert to possible Chinese counterfeits.
If you buy an Intel NIC designed presumably for an enterprise environment, how would you know whether or not it also supports the vulnerable AMT protocols?
As I understand it, the AMT hardware is physically linked to one specific on-board NIC. Supposedly, it is not capable of using any other NIC, on-board, or otherwise, should other NICs be available.
In this respect, AMT seems to be similar to some IPMI implementations. Some IPMI implementations have a dedicated NIC. But, in the event that an IPMI implementation does not have a dedicated NIC, you must use a specific, shared on-board NIC, otherwise you can not access IMMI functionality. This second, shared example seems to mirror the AMT functionality.
BTW - Steve tells us (starting at 13:30) that AMT uses ports 16992, 16993, 994, 995, 623, 664 and 5900. I wouldn't be surprised if it also used other ports, but those are the ones that we know about ... so far. So, if you're not running a default deny policy on your pfSense box, definitely filter these ports.
If you are vulnerable to the AMT vulnerability, there is nothing you can do on the machine's operating system to prevent this, since the packets arriving on that NIC aren't even being forwarded to the OS and "stay on" the NIC itself. If you have another firewall before the pfSense box though, you can filter the ports there.
In any case you first have to evaluate if you are even vulnerable. From what I have read there are several factors that come into play. If one of the following doesn't apply to your machine, you aren't affected by the vulnerability:
Finally, you can always disable AMT in the BIOS/UEFI if you aren't using it and to my knowledge that should do the trick to protect you, at least for online attacks.
Yes, you are correct. but I'm not talking about a built-in Windoz firewall. I run a stand alone pfSense firewall with a default deny policy. Nothing gets in unless solicited and nothing goes out, except on ports 80 and 443 without my express approval. Beyond that, I must white list the individual server, or network, before it can be accessed.
That's great, but the OP's question was if there was a ...
And in that situation there is nothing you can do with pfSense to protect it since the packets for the AMT ports aren't even being forwarded to the operating system. PfSense has no idea that those packets are even arriving at the NIC. Even if it did, there was nothing pfSense could do to block it since it's behind the part that is vulnerable.
Just to clarify, I saw this as two separate inquiries. The initial inquiry: Can I use an AMT equipped machine for a pfSense deployment. Answer: Yes, just don't use the on-board Ethernet ports. AMT is hard coded to use only a single, designated on-board Ethernet port. It is unable to communicate via an add-on PCIe network card.
Inquiry/assertion number two: If a machine is vulnerable to the AMT bug, there is absolutely nothing that you can do to mitigate the problem. Answer: I interpreted this as a more generic statement about all AMT equipped machines, in general and not specifically related to the OP's original question about a firewall deployment. To this I answered, that you can use a firewall, pfSense being my preferred solution, to effectively quarantine any other machines with AMT capabilities on your network, by blocking off the ports that they use for comms, such as 169932, 16993, and etc. This is necessary, because the Windoz built-in firewall will not block AMT comms. This pfSense machine can be non AMT equipped, as mine is, or AMT equipped with a non-AMT compliant CPU, or AMT equipped with add-in PCIe NICs, etc.
Additionally, you mention that AMT can be disabled in BIOS. I'm not sure that this is strictly true, although there always seem to be edge cases, eh? The reports that I've seen have all stated that there is no way to turn AMT completely off in BIOS, or otherwise. While this is a scary prospect, IIRC, even if all the AMT hardware and software components are present and correct, AMT still must be configured by your friendly enterprise IT department before it will respond to pings, so the likelihood that consumer grade hardware is vulnerable is unlikely. More troubling would be server grade hardware and business class laptops, whose default AMT configuration states are likely all over the map.
Another troubling aspect of this AMT dilemma, at least for someone like me, who is using a business class laptop, is the built-in Intel Theft Recovery feature. In the event of theft, an IT department can remotely log into my laptop, delete the hard disk contents and lock the machine. I would assume that this functionality piggybacks on the AMT capabilities of this machine, but I have seen nothing to clarify/verify this concern, nor do I fully understand what the default configuration of this "feature" exposes me to. Needless to say, my Lenovo will not be leaving home, until I have a more complete understanding of these various attack vectors.
Full disclosure: I am not an Intel employee with intimate knowledge of how AMT works. I merely relate my best understanding of the situation after doing considerable reading on the topic. I have a couple of Supermicro based servers running at home and I also have a Lenovo business class laptop, so I am keen to understand this vulnerability. YMMV! Trust, but verify!
I might not have been precise there. What I meant was that you can disable AMT in the firmware of the ME. Intel mentions this in their mitigation guide and that (together with disabling/removing LMS) should apparently do the trick, as long as you don't need AMT.
I am not quite certain about that either. From what I have read on various blogs, that seems to be the case, but from how I read Intel's mitigation guide, since it is configured through the OS, it might be possible for malware on your system to provision it and effectively create a backdoor.
2: Disabling or removing the Local Manageability Service (LMS) to mitigate unprivileged local attacker from gaining system privileges
In my opinion the best thing to do is to follow their guide and you should be safe. But I have no real experience with Intel enterprise hardware, so I am just guessing.
PS: Here is some more info on the topic, if anyone is interested. I asked this question a few days ago actually myself:
Linked in there is this:
Wouldn't using the onboard nic in a PFsense to only connect to your internal LAN and using another NIC for outside access mitigate this issue? At that point PFsense can deny those ports to the outside and any attempt to use this vulnerability to load an ISO on the router would break their connection.
What I mean is they would have to gain access to your network through another infected system to even try to target the router. This would be more of an issue for any servers that may exist in a DMZ or have open access to the rest of your network.
If you trust the device(s) connected to the on-board NIC, I guess you could use it, but since gigabit ethernet NICs are quite cheap these days, I wouldn't take the risk myself.
Just to be safer, I went ahead and picked up an Intel NIC and am not using the built in NIC anymore. Thanks everyone for helping me better understand the issue.