A postagem mais clara que eu já vi sobre essa questão é Matthew Garrett (incluindo os comentários).
Matthew lançou agora uma ferramenta para verificar seu sistema localmente: construa-o, execute-o com
sudo ./mei-amt-check
e informará se a AMT está habilitada e provisionada e, se estiver, as versões de firmware (veja abaixo). O README tem mais detalhes.
Para verificar sua rede em busca de sistemas potencialmente vulneráveis, faça a varredura das portas 623, 624 e 16992 a 16993 (conforme descrito no próprio documento de atenuação da Intel ); por exemplo
nmap -p16992,16993,16994,16995,623,664 192.168.1.0/24
varrerá a rede 192.168.1 / 24 e informará o status de todos os hosts que responderem. Ser capaz de se conectar à porta 623 pode ser um falso positivo (outros sistemas IPMI usam essa porta), mas qualquer porta aberta de 16992 a 16995 é um indicador muito bom de AMT habilitado (pelo menos se eles respondem apropriadamente: com AMT, isso significa uma resposta HTTP em 16992 e 16993, a última com TLS).
Se você visualizar respostas nas portas 16992 ou 16993, se conectar a essas e solicitar / usando HTTP retornará uma resposta com uma linha Server contendo "Intel (R) Active Management Technology" em sistemas com AMT ativado; Essa mesma linha também conterá a versão do firmware AMT em uso, que pode ser comparada com a lista fornecida em Aviso da Intel para determinar se é vulnerável.
Veja a resposta da CerberusSec para obter um link para um script que automatiza o acima.
Existem duas maneiras de corrigir o problema "corretamente":
- atualize o firmware, assim que o fabricante do seu sistema fornecer uma atualização (se houver);
- evite usar a porta de rede que fornece AMT usando uma interface de rede não compatível com AMT em seu sistema ou usando um adaptador USB (muitas estações de trabalho AMT, como os sistemas C226 Xeon E3 com portas de rede i210, têm apenas uma interface de rede compatível com AMT - o resto é seguro, observe que a AMT pode funcionar via wi-fi, pelo menos no Windows, portanto, usar wi-fi integrado também pode levar à comprometimento).
Se nenhuma dessas opções estiver disponível, você estará em território de atenuação. Se o seu sistema compatível com AMT nunca foi provisionado para AMT, você está razoavelmente seguro; ativar a AMT nesse caso aparentemente só pode ser feito localmente e, até onde eu saiba, é necessário usar o firmware do sistema ou o software do Windows. Se o AMT estiver habilitado, você pode reinicializar e usar o firmware para desativá-lo (pressione Ctrl P quando a mensagem AMT for exibida durante a inicialização).
Basicamente, embora a vulnerabilidade de privilégio seja bastante desagradável, parece que a maioria dos sistemas da Intel não é afetada. Para os seus próprios sistemas que executam o Linux ou outro sistema operacional semelhante ao Unix, o escalonamento provavelmente requer acesso físico ao sistema para ativar o AMT em primeiro lugar. (O Windows é outra história.) Em sistemas com múltiplas interfaces de rede, como apontado por Rui F Ribeiro , você deve tratar as interfaces compatíveis com AMT da mesma maneira que trataria qualquer interface administrativa (compatível com IPMI ou a interface do host para um hypervisor de VM) e isolá-lo em uma rede administrativa (física ou VLAN). Você não pode confiar em um host para se proteger: iptables etc. são ineficazes aqui, porque a AMT vê pacotes antes do sistema operacional (e mantém os pacotes AMT para si).
As VMs podem complicar, mas apenas no sentido de que podem confundir AMT e, assim, produzir resultados de varredura confusos se a AMT estiver ativada. amt-howto(7) dá o exemplo de sistemas Xen onde a AMT usa o endereço fornecido a uma DomU sobre DHCP, se qualquer, o que significa que uma varredura mostraria AMT ativa no DomU, não no Dom0 ...