AMT exposed on WAN

[Guest]

How do you use AMT remotely with the firewall off ;-)

[n3by]

In my case AMT it is on WAN… and I am connecting from mobile or other site or MPS server.

[Guest]

@ecfx:

In my case AMT it is on WAN… and I am connecting from mobile or other site or MPS server.

That is pretty much the worst possible place to allow AMT access, especially with all the inherent security issues.

[n3by]

I disagree, if you can prove that Intel AMT 5 ( properly configured ) it is vulnerable then prove it, everything else are just speculation without support.
I see AMT on a wan firewall less exposed than pfSense itself.

[Guest]

@ecfx:

I disagree, if you can prove that Intel AMT 5 ( properly configured ) it is vulnerable then prove it, everything else are just speculation without support.
I see AMT on a wan firewall less exposed than pfSense itself.

https://www.extremetech.com/computing/230342-report-claims-intel-cpus-contain-enormous-security-flaw
https://www.wired.com/2017/05/hack-brief-intel-fixes-critical-bug-lingered-7-dang-years/
http://thehackernews.com/2017/05/intel-amt-vulnerability.html
https://www.ssh.com/vulnerability/intel-amt/

Specifically for your version, most hacks are done locally first but become unremovable because it can seal itself in in the PCH. Even desoldering the SPI flash won't help you there…
On top of the known exploits, there are other, not published problems, as well as research going on. Igor Skochinsky hacked the thing and installed a permanent rootkit in 2014.

There is no 'secure' way for BMC/IPMI/LOM/AMT systems to be directly connected to WAN.

[n3by]

first link speculate that Intel AMT it is insecure because it is closed source… nothing new, nothing proved.
second, third and forth links are for CVE-2017-5689 - AMT/ISM versions 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5, and 11.6 and that vulnerability has no effect if administrator account name it is changed from default admin as I proved some time ago. At this moment that vulnerability can be easy patched with AMT firmware update.

Reprogramming PCH for chip that support AMT it is something I did not found to be possible in any Intel doc until now so please provide some links if you can. I only dream to upgrade Q43 chip signature to Q45...

I can tell you from experience that if AMT it is enabled and properly configured to allow that it can be reprogrammed only with local access ( Windows with proper drivers or DOS ) and not remote.
If flash descriptor it is locked and ME manufacturing bit closed then only chance it is with Flash Descriptor Security Override - ME Debug Mode that require to open the computer and do a jumper / strap / mod or with external programmer - flash removed.
Even this reprogramming will require a special ME image prepared by an organization that have access to Intel & mother board BIOS blueprints.

Setting AMT for CIRA will lock down all AMT ports and access to that AMT will be possible only from MPS server. AMT Client will initiate secure communication to MPS server and only from that server will accept traffic.

[Guest]

@ecfx:

first link speculate that Intel AMT it is insecure because it is closed source… nothing new, nothing proved.
second, third and forth links are for CVE-2017-5689 - AMT/ISM versions 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5, and 11.6 and that vulnerability has no effect if administrator account name it is changed from default admin as I proved some time ago. At this moment that vulnerability can be easy patched with AMT firmware update.

Reprogramming PCH for chip that support AMT it is something I did not found to be possible in any Intel doc until now so please provide some links if you can. I only dream to upgrade Q43 chip signature to Q45...

I can tell you from experience that if AMT it is enabled and properly configured to allow that it can be reprogrammed only with local access ( Windows with proper drivers or DOS ) and not remote.
If flash descriptor it is locked and ME manufacturing bit closed then only chance it is with Flash Descriptor Security Override - ME Debug Mode that require to open the computer and do a jumper / strap / mod or with external programmer - flash removed.
Even this reprogramming will require a special ME image prepared by an organization that have access to Intel & mother board BIOS blueprints.

Setting AMT for CIRA will lock down all AMT ports and access to that AMT will be possible only from MPS server. AMT Client will initiate secure communication to MPS server and only from that server will accept traffic.

All of those protections are nice on paper, but all of them have been broken multiple times. Take SMM memory for example, you are not supposed to be able to modify that from the OS. But move the APIC address range and bam, you can break into SMM. Same goes for the Intel ME, which AMT depends on. The CVE for 6-11 was a WS-MAN vulnerability and just now on BlackHat 17 EU there is a new hack for ME 11+ allowing anyone to run unsigned code directly on the PCH. The AMT runs in there as well…

https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668

What I'm saying is: AMT and the ME have been hacked and broken time and time again, just as so many parts of the Intel x86 spec. ME 'locked' regions have been modified, firmwares exploited via stupid things like the ITK function that was meant to allow people to set a custom boot bitmap logo, and zero-interaction hacks in both the UEFI and legacy BIOS images with code supplied by Intel. Just because most of the known vulnerabilities are patched in most firmware updates (have you updated your firmware?) doesn't mean it's super safe and secure and ready to be connected to the internet straight away. Most of the exploits point to sloppy code and bad implementations, even known bugs in the EDK2 for UEFI appear in production firmware images for a large number of Intel and AMD systems.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5698
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5697
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5689

If you think it's secure because the non-introspectable firmware is said to be 'safe' by the vendors... well, why are you even running pfSense? Might as well stick with Windows Firewall and get a WAN IP for every PC ;-)

Most embedded networked systems are simply insecure, and especially with out of band remote management systems, it's a very bad idea to hang them on a WAN link with no protection.
Check popular systems like:

Dell's DRAC: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=drac
IBM IMM: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=imm
HP iLO: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ilo

If you search for any IPMI exploit: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ipmi
Plenty of those to go around, Intel-specific ones too.
And it's not like supermicro is bug-free either: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=supermicro

Most of those CVE's have been patched, but systems in the wild still have older versions and thus still have those problems. Plenty of automated scanners try to find and crack those systems, and using known vulns, it's very easy to do this on a massscan-scale.

[n3by]

@johnkeates:

…
If you think it's secure because the non-introspectable firmware is said to be 'safe' by the vendors... well, why are you even running pfSense? Might as well stick with Windows Firewall and get a WAN IP for every PC ;-)
...

That is not nice, I am not running pfSesne because it is the "safest firewall" available that is out of question for sure.

Listing all the vulnerabilities for other similar management system still not make Intel AMT look insecure than other but better with only two vulnerability exposed and both not for AMT 5.

The risk of having the AMT webpage accessed unauthorized and firewall computer turned ON-OFF remote it is very very low and damage doing that is minimum, and until now still it is not proven to be possible for AMT 5.
The risk of having AMT firmware reprogrammed remote and malware/spyware/rootkit installed in computer flash/BIOS it is 0.

I have multiple firewalls with AMT exposed to wan for ~3 years without any problem whatsoever and for me AMT it is a necessity because I can't travel ~1000km to turn on/off the firewall if required.

Remain to be seen what the future reserve us.

[stephenw10]

This is a valid discussion but was off topic so I split the thread.

Steve

[n3by]

I forgot to add one of the super cool feature why I also use Intel AMT on WAN:

• because I can have also a HW firewall; enabling Network Filters & Policies and building my rules on Intel AMT I can harden firewall and I am 100% sure that nothing can open privileged port or admin ports on pfSense wan because they are disabled from AMT.

Another possibility that need to experiment is to see how AMT react to DDOS…