christianmanivong
0052ba7884
An `amt` driver (napalm_amt.AmtDriver), a ManagementControllerDriver for the management controller of Intel vPro machines, with its own lean WS-Management client (requests + ElementTree, HTTP Digest, ports 16992/16993). It reads the machine's identity, hardware with the SMBIOS system UUID, firmware (AMT with build, BIOS), power state and the hardware event log, reports what AMT listens on (plain HTTP or TLS, KVM incl. port 5900, IDE-R), and switches the machine's power. AMT cannot be reset over WS-Management, so there is no reboot_host. Discovery recognises AMT by its ports and its Server header. Tested against Intel's published AMT 12 recordings (go-wsman-messages, Apache-2.0, see NOTICE). `python -m napalm_amt.record` records a real AMT read-only; the first test devices are two Lenovo ThinkCentre M910x.
58 lines
2.9 KiB
Markdown
58 lines
2.9 KiB
Markdown
# Security
|
|
|
|
## Plain HTTP (16992) versus TLS (16993)
|
|
|
|
Out of the box, AMT talks WS-Management on **16992 over plain HTTP**. HTTP Digest (MD5)
|
|
keeps the password off the wire. Everything else travels in the clear, including the
|
|
machine's inventory and every power command, and nothing stops a man in the middle from
|
|
replaying or changing them. TLS on 16993 needs a certificate and key provisioned into AMT
|
|
(`AMT_PublicKeyManagementService`, `AMT_TLSSettingData`); MEBx alone cannot set it up.
|
|
|
|
`get_management_protocols` reports `http` enabled while AMT accepts plain connections from
|
|
the network. Like IPMI over LAN for a server BMC, that is worth a finding in netOrk.
|
|
|
|
The driver verifies AMT's certificate on 16993 by default (`verify_ssl=True`). A
|
|
self-signed certificate needs `verify_ssl` set to its CA file, or `False`.
|
|
|
|
## Accounts
|
|
|
|
MEBx setup leaves one account, `admin`, with every right. AMT can hold more Digest
|
|
accounts, each limited to *realms* (`AMT_AuthorizationService`). Reading needs the
|
|
hardware asset, general info and event log realms; power control needs remote control.
|
|
A separate account for netOrk keeps `admin` out of it, but is not required.
|
|
|
|
AMT locks an account out for a while after repeated failed logins and writes the failures
|
|
to its event log ("Authentication failed N times"). The driver reports that entry as
|
|
Critical.
|
|
|
|
## KVM, SOL and IDE-R
|
|
|
|
- The **KVM console** goes over the redirection port (16994, or 16995 with TLS), behind
|
|
the AMT login. With **port 5900** enabled, AMT additionally speaks plain VNC, protected
|
|
only by an eight-character RFB password. Worth a finding when on.
|
|
- **User consent** (opt-in) asks the person at the machine for a code before KVM starts.
|
|
It is mandatory in Client Control Mode and optional in Admin Control Mode, which MEBx
|
|
setup gives.
|
|
- **IDE-R/USB-R** (virtual media) lets whoever holds the login boot the machine from a
|
|
remote image.
|
|
|
|
## Known vulnerabilities
|
|
|
|
AMT's firmware has a long CVE history. Most important is **CVE-2017-5689**
|
|
(INTEL-SA-00075): AMT 6 to 11.6 accepted an empty Digest response, so anyone on the
|
|
network got in without a password. Fixed firmware came through the PC vendors (Lenovo:
|
|
ME firmware updates). Many later advisories cover ME/AMT 11.x (SA-00086, SA-00112,
|
|
SA-00213, SA-00241, SA-00295 and others).
|
|
|
|
`get_firmware_inventory` reports AMT's version with its build (`11.8.50.3399`), and AMT
|
|
sends the same version without a login in its `Server` header. That version is what netOrk
|
|
needs to match advisories, and what a finding for outdated AMT firmware would rest on.
|
|
|
|
## Power control
|
|
|
|
`set_power_state` switches the machine itself, like a power button. It checks the action
|
|
against the power state and AMT's list of accepted states first, and refuses `On` for a
|
|
running machine. `ForceOff`, `ForceRestart` and `PowerCycle` do not ask the operating
|
|
system. The graceful actions need the operating system's cooperation, and AMT lists them
|
|
only where the host supports them.
|