La publicación más clara que he visto sobre este tema es la de Matthew Garrett (incluidos los comentarios).
Matthew ahora ha lanzado una herramienta para verificar su sistema localmente: compílelo, ejecútelo con
sudo ./mei-amt-check
e informará si AMT está habilitado y aprovisionado, y si es así, las versiones de firmware (ver más abajo). El archivo README tiene más detalles.
Para escanear su red en busca de sistemas potencialmente vulnerables, escanee los puertos 623, 624 y 16992 a 16993 (como se describe en el propio documento de mitigación de Intel ); por ejemplo
nmap -p16992,16993,16994,16995,623,664 192.168.1.0/24
analizará la red 192.168.1 / 24 e informará el estado de todos los hosts que responden. Ser capaz de conectarse al puerto 623 puede ser un falso positivo (otros sistemas IPMI usan ese puerto), pero cualquier puerto abierto de 16992 a 16995 es un muy buen indicador de AMT habilitado (al menos si responden adecuadamente: con AMT, eso significa una respuesta HTTP en 16992 y 16993, este último con TLS).
Si ve respuestas en los puertos 16992 o 16993, conectarse a ellos y solicitar el /uso de HTTP devolverá una respuesta con una Serverlínea que contiene "Intel (R) Active Management Technology" en sistemas con AMT habilitado; esa misma línea también contendrá la versión del firmware AMT en uso, que luego se puede comparar con la lista dada en el aviso de Intel para determinar si es vulnerable.
Vea la respuesta de CerberusSec para un enlace a un script que automatiza lo anterior.
Hay dos formas de solucionar el problema "correctamente":
- actualizar el firmware, una vez que el fabricante del sistema proporcione una actualización (si alguna vez)
- evite utilizar el puerto de red que proporciona AMT, ya sea mediante el uso de una interfaz de red no compatible con AMT en su sistema, o mediante el uso de un adaptador USB (muchas estaciones de trabajo AMT, como los sistemas C226 Xeon E3 con puertos de red i210, solo tienen un AMT- interfaz de red capaz: el resto es seguro; tenga en cuenta que AMT puede funcionar a través de wi-fi, al menos en Windows, por lo que el uso de wi-fi incorporado también puede comprometer).
Si ninguna de estas opciones está disponible, está en territorio de mitigación. Si su sistema compatible con AMT nunca se ha aprovisionado para AMT, entonces está razonablemente seguro; aparentemente, habilitar AMT en ese caso solo se puede hacer localmente y, por lo que puedo decir, es necesario usar el firmware de su sistema o el software de Windows. Si AMT está habilitado, puede reiniciar y usar el firmware para deshabilitarlo (presione CtrlPcuando aparezca el mensaje AMT durante el arranque).
Básicamente, si bien la vulnerabilidad de privilegios es bastante desagradable, parece que la mayoría de los sistemas Intel no se ven realmente afectados. Para sus propios sistemas que ejecutan Linux u otro sistema operativo similar a Unix, la escalada probablemente requiera acceso físico al sistema para habilitar AMT en primer lugar. (Windows es otra historia). En los sistemas con múltiples interfaces de red, como lo señala Rui F Ribeiro , debe tratar las interfaces compatibles con AMT de la misma manera que trataría cualquier interfaz administrativa (compatible con IPMI o la interfaz de host para un hipervisor VM) y aislarlo en una red administrativa (física o VLAN). No puede confiar en un host para protegerse: iptablesetc. aquí no son efectivos, porque AMT ve los paquetes antes que el sistema operativo (y guarda los paquetes de AMT para sí mismo).
Las máquinas virtuales pueden complicar las cosas, pero solo en el sentido de que pueden confundir AMT y, por lo tanto, producir resultados de escaneo confusos si AMT está habilitado. amt-howto(7)da el ejemplo de los sistemas Xen donde AMT usa la dirección dada a una DomU a través de DHCP, si la hay, lo que significa que un escaneo mostrará AMT activo en la DomU, no en la Dom0 ...