In May 2017 Intel publicly confirmed the vulnerability in own firmware for vPro/AMT.
To download and patch such computers from Dell use links inside the PDF file from following link.
But as i mentioned in my linkedin post it’s possible to protect even noname computers (without updated BIOS) with compromised ME firmware — implementing SSL/TLS certificates for mutual authentication. In this post i will show how it can be done.
At first let’s consider that
- you know that your computer supports vPro/AMT, ME version, you know AMT type (ISM or full AMT and so on)
- you already use intel ME (you know how to press Ctl-P and configure AMT), but you have problem to find out fixed against vulnerability version of ME firmware
- AMT version is >= 7
We will use several free tools for vPro/AMT:
- Intel® Setup and Configuration Software (Intel® SCS) v11.2 (2017-09-15) or Intel AMT Configuration Utility (ACU) Wizard (just unpack and run ACUWizard.exe)
- Open Manageability Developer Tool Kit and inside it Manageability Commander Tool and Manageability Director Tool
Let’s consider that we configured already vPro/AMT from BIOS (pressing Ctl-P during Dell logo):
- 172.16.1.14
- password is configured and known
- “Configured Network Access” – allowed vpro/amt configuration over network.
- adminpc.itforce.local is not 172.16.1.14, for example 172.16.1.100 (by the way you cannot ping/access your vpro IP from the OS on the same computer because builtin intel NIC has two MAC addresses – one for vpro and another for OS; AcuWizard.exe uses not IP, but ME driver in OS – AcuWizard should be run only on vpro/amt computer, not remotely !!!)
After installation of Open Manageability Developer Tool Kit (prerequisite is Dot.Net framework) run Manageability Director Tool to create new CA and issue/generate certificates for each vPro/AMT computer, plus certificates for each admin console/workstation.
- run Manageability Director Tool and click on “Create Root Certificate”
- For “Common name” better to use FQDN (hostname is virtual non-existing computer name, never connected directly by any vpro and so on, needed just to create CA and name it)
- save as asked into your registry on adminpc (computer on which you are running Manageability Director Tool ) your new Root Certificate (to migrate/backup and restore – later we will export all these certificates)
- Result you can see below:
- To control it’s useful to run mmc, certificates – we will see the same certificate and where it was installed:
- now we need to generate certificates for each vpro/amt machine (before you need to select by mouse your CA certificate – there could be several CA certs for signing vpro certs):
- when you finish generating certs for all vpro/amt machines, it’s time to generate certs as well for admin consoles (in our case it’s adminpc.itforce.local) with Manageability Director/Commander Tool (we are configuring Mutual Auth)
- To lockdown the system you can harden it using other Certificate Types instead of “All permissions certificate”
- Now we have all necessary certificates.
- Before configuring the Mutual Auth we can access vPro/AMT thru browser like below (even when workstation is powered off):
- after login (as you see power — Off):
- We can using vpro/amt(even without Mutual Auth) remotely thru network conduct hardware inventory, power on/off, mount remotely iso/CD/DVD, change remote BIOS settings and so on regardless of OS (linux, windows), no matter of OS state – started/shutdowned/freezed with Blue Screen of Death.
- Now thru Manageability Commander Tool we can also access like below:
- To configure Mutual Auth, and also for backup/restore and migration of the system to other workstation we better to export to pfx files all our certificates (and surely place them/pfx and password in safe protected place)
- repeat above steps for all generated certificates
- OK, let’s finally configure Mutual Auth for vpro and complete the task of our post:
- below is the result of installing previously generated certificates into vpro ME on target AMT computer:
- So far we just installed into intel ME certificates, but not demanded to use them, so click on below yellow mark to start:
- on above picture step three we setup to use vpro00.itforce.local certificate as vpro00 ME certificate (to unlink later and delete from ME this certificate you may need to enter BIOS ME and disable completely ME on this computer and enable again, or run ACUwizard.exe without parameters for certificates, delete from MDTK connection and add vpro computer again). If you don’t complete step 5-8 on the above picture even with installed adminpc.itforce.local certificate, vPro/AMT engine will not know for what certificate/computer to allow access to vpro/amt (vpro ME doesn’t try to check FQDN thru DNS or ping back, it just match subject of certificate of connecting computer with this list and stored certificate, so connecting MDTK admin workstation can have any hostname, FQDN, IP and so on; just need to have correct certificate for adminpc.itforce.local to hand it to vpro ME to prove itself, and for vpro00.itforce.local/amtca certificates to check that connecting device is really our vpro00 device.). So each vpro ME has at least 3 certificates (one own, one for CA, one for each admin workstation). Each admin workstation has one CA cert, one own cert, and one for each needed vpro ME.
- step 4 (“Include Remote Authentication(console)”) enables and disables Mutual Authentication
- When you finished above setup, your connection to vpro/amt will reconnect thru ssl on port 16993, but with red alert:
- the reason is that we connect to vpro/amt not thru vpro00.itforce.local, but thru ip address 172.16.1.14. To fix it just use your DNS server or host file on all adminpc consoles.
- Final result :
ps
Again: If you failed with configuration of mutual authentication and lost access to vpro you can reset it without reboot just re-applying configuration by ACUwizard from OS (for this better to leave RDP or other access just in case), or from BIOS after pressing Ctl-P and completely disabling ME and enabling again.
Now even on intel ME with vulnerable/not-fixed ME engine we have protected vPro/AMT system, because rogue attacker doesn’t have necessary certificate to exploit vulnerability (without necessary certificates connection is dropped immediately – at first certificate check, and only after this appears login screen if you access thru browser)
There is also some limitations for SSL/TLS — IDE redirect in some cases doesn’t work. But anyway it’s recommended never to enable KVM/VNC and IDE redirection in production, and enable (can be done remotely from the same MDTK) only in emergency cases to fix and repair (restore from backup, re-image/format/install new OS and so on). So in emergency cases better to use VPN + IP filters (16992/16993/5900 ports are allowed only for admin IPs) and move temporarily from https access to http, and after incident enable again https. And surely better to patch the system if there is available hotfix from vendor.