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:constrúyalo, ejecútelo con
sudo ./mei-amt-check
e informará si AMT está habilitado y aprovisionado, y si lo está, las versiones de firmware (ver más abajo). El LÉAME 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
escaneará la red 192.168.1/24 e informará el estado de todos los hosts que respondan. Poder conectarse al puerto 623 puede ser un falso positivo (otros sistemas IPMI usan ese puerto), pero cualquier puerto abierto del 16992 al 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, conéctese a ellos y solicite / usar HTTP devolverá una respuesta con un Server lí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 proporcionada en el aviso de Intel para determinar si es vulnerable.
Consulte la respuesta de CerberusSec para obtener un enlace a un script que automatiza lo anterior.
Hay dos formas de solucionar el problema "correctamente":
- actualice el firmware, una vez que el fabricante de su sistema proporcione una actualización (si alguna vez);
- evite usar el puerto de red que proporciona AMT, ya sea usando una interfaz de red no compatible con AMT en su sistema o usando un adaptador USB (muchas estaciones de trabajo AMT, como los sistemas C226 Xeon E3 con puertos de red i210, solo tienen una interfaz de red compatible con AMT; el resto son seguros; 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 la seguridad).
Si ninguna de estas opciones está disponible, se encuentra en territorio de mitigación. Si su sistema compatible con AMT nunca ha sido aprovisionado para AMT, entonces está razonablemente seguro; Aparentemente, habilitar AMT en ese caso solo se puede hacer localmente y, por lo que sé, requiere usar el firmware de su sistema o el software de Windows. Si AMT está habilitado, puede reiniciar y usar el firmware para deshabilitarlo (presione Ctrl P cuando se muestra el mensaje AMT durante el arranque).
Básicamente, aunque la vulnerabilidad de los 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 sistemas con múltiples interfaces de red, como lo señaló 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 de VM) y aislarlo en una red administrativa (física o VLAN). Usted no puede confiar en un host para protegerse:iptables etc. son ineficaces aquí, porque AMT ve los paquetes antes que el sistema operativo (y guarda los paquetes AMT para sí mismo).
Las máquinas virtuales pueden complicar las cosas, pero solo en el sentido de que pueden confundir a 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 un DomU sobre DHCP, si lo hay, lo que significa que un escaneo mostraría AMT activo en el DomU, no en el Dom0...
La simple detección de los puertos abiertos para este servicio es insuficiente, no indica si la versión está afectada o no. Nuestro equipo ha creado un script de python disponible en nuestro github:CerberusSecurity/CVE-2017-5689 que detecta si un sistema de destino es vulnerable a un ataque remoto.
Ejemplo de uso:
python CVE_2017_5689_detector.py 10.100.33.252-255
Esto debería permitirle verificar si es remotamente explotable. Si está interesado, también escribimos una breve publicación de blog en http://cerberussec.org/ con nuestra opinión sobre esta vulnerabilidad.
Intel tiene herramientas para Linux en:Herramientas de detección y mitigación de Linux
hay una bifurcación en GITHUB