O post mais claro que vi sobre esse assunto é o de Matthew Garrett (incluindo os comentários).
Agora, Matthew lançou uma ferramenta para verificar seu sistema localmente: construa-o, execute-o com
sudo ./mei-amt-check
e informará se a AMT está ativada e provisionada e, se houver, as versões de firmware (veja abaixo). O README possui mais detalhes.
Para verificar sua rede em busca de sistemas potencialmente vulneráveis, verifique as portas 623, 624 e 16992 a 16993 (conforme descrito no próprio documento de mitigação da Intel ); por exemplo
nmap -p16992,16993,16994,16995,623,664 192.168.1.0/24
examinará a rede 192.168.1 / 24 e relatará o status de todos os hosts que responderem. Conseguir conectar-se à 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 da AMT ativada (pelo menos se elas responderem adequadamente: com a AMT, isso significa uma resposta HTTP em 16992 e 16993, a última com TLS).
Se você vir respostas nas portas 16992 ou 16993, conectar-se a elas e solicitar o /uso de HTTP retornará uma resposta com uma Serverlinha que contém a "Intel (R) Active Management Technology" em sistemas com a AMT ativada; essa mesma linha também conterá a versão do firmware da AMT em uso, que poderá ser comparada com a lista fornecida no comunicado da Intel para determinar se é vulnerável.
Consulte a resposta do CerberusSec para obter um link para um script que automatiza o procedimento acima.
Há duas maneiras de corrigir o problema "corretamente":
- atualize o firmware, assim que o fabricante do 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 AMT- interface de rede capaz - o restante é seguro; observe que a AMT pode funcionar com wi-fi, pelo menos no Windows, portanto, o uso de wi-fi embutido também pode levar a comprometimento).
Se nenhuma dessas opções estiver disponível, você estará no território de mitigação. Se seu sistema compatível com AMT nunca foi provisionado para AMT, você estará razoavelmente seguro; aparentemente, a ativação da AMT só pode ser feita localmente, e, pelo que sei, requer o uso do firmware do sistema ou do software Windows. Se a AMT estiver ativada, você poderá reiniciar e usar o firmware para desativá-la (pressione CtrlPquando a mensagem AMT for exibida durante a inicialização).
Basicamente, embora a vulnerabilidade de privilégios seja bastante desagradável, parece que a maioria dos sistemas Intel não é realmente afetada. Para seus próprios sistemas executando Linux ou outro sistema operacional semelhante ao Unix, a escalação provavelmente requer acesso físico ao sistema para ativar a AMT em primeiro lugar. (O Windows é outra história.) Em sistemas com várias interfaces de rede, como apontado por Rui F Ribeiro , você deve tratar interfaces compatíveis com AMT da mesma maneira que trataria qualquer interface administrativa (compatível com IPMI ou a interface host) para um hipervisor de VM) e isole-o em uma rede administrativa (física ou VLAN). Você não pode confiar em um host para se proteger: iptablesetc. 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 as coisas, mas apenas no sentido de que podem confundir a AMT e, assim, produzir resultados de varredura confusos se a AMT estiver ativada. amt-howto(7)fornece o exemplo de sistemas Xen em que a AMT usa o endereço fornecido a um DomU por DHCP, se houver, o que significa que uma varredura mostraria AMT ativo no DomU, não no Dom0 ...