Il post più chiaro che ho visto su questo problema è quello di Matthew Garrett (inclusi i commenti).
Matthew ha ora rilasciato uno strumento per controllare localmente il tuo sistema: crealo, eseguilo con
sudo ./mei-amt-check
e indicherà se AMT è abilitato e sottoposto a provisioning e, se lo è, le versioni del firmware (vedi sotto). Il file README ha maggiori dettagli.
Per eseguire la scansione della rete alla ricerca di sistemi potenzialmente vulnerabili, eseguire la scansione delle porte da 623, 624 e da 16992 a 16993 (come descritto nel documento di mitigazione di Intel ); per esempio
nmap -p16992,16993,16994,16995,623,664 192.168.1.0/24
eseguirà la scansione della rete 192.168.1 / 24 e segnalerà lo stato di tutti gli host che rispondono. Essere in grado di connettersi alla porta 623 potrebbe essere un falso positivo (altri sistemi IPMI usano quella porta), ma qualsiasi porta aperta dal 16992 al 16995 è un ottimo indicatore di AMT abilitato (almeno se rispondono in modo appropriato: con AMT, ciò significa una risposta HTTP su 16992 e 16993, quest'ultima con TLS).
Se vedi le risposte sulle porte 16992 o 16993, la connessione a queste e la richiesta /tramite HTTP restituiranno una risposta con una Serverlinea contenente "Tecnologia Intel (R) Active Management" su sistemi con AMT abilitato; quella stessa riga conterrà anche la versione del firmware AMT in uso, che può quindi essere confrontata con l'elenco fornito nell'advisory di Intel per determinare se è vulnerabile.
Vedi la risposta di CerberusSec per un link a uno script che automatizza quanto sopra.
Esistono due modi per risolvere il problema "correttamente":
- aggiornare il firmware, una volta che il produttore del sistema fornisce un aggiornamento (se mai);
- evitare di utilizzare la porta di rete che fornisce AMT, sia utilizzando un'interfaccia di rete non compatibile con AMT sul sistema, sia utilizzando un adattatore USB (molte stazioni di lavoro AMT, come i sistemi C226 Xeon E3 con porte di rete i210, dispongono di un solo AMT- interfaccia di rete capace - il resto è sicuro; nota che AMT può funzionare su Wi-Fi, almeno su Windows, quindi l'uso di Wi-Fi integrato può anche portare a una compromissione).
Se nessuna di queste opzioni è disponibile, ci si trova nel territorio di mitigazione. Se il tuo sistema compatibile con AMT non è mai stato predisposto per AMT, allora sei ragionevolmente sicuro; abilitare AMT in quel caso apparentemente può essere fatto solo localmente e, per quanto ne so, richiede l'uso del firmware del sistema o del software Windows. Se AMT è abilitato, è possibile riavviare e utilizzare il firmware per disabilitarlo (premere CtrlPquando viene visualizzato il messaggio AMT durante l'avvio).
Fondamentalmente, mentre la vulnerabilità dei privilegi è piuttosto brutta, sembra che la maggior parte dei sistemi Intel non siano effettivamente interessati. Per i tuoi sistemi che eseguono Linux o un altro sistema operativo simile a Unix, l'escalation probabilmente richiede l'accesso fisico al sistema per abilitare AMT in primo luogo. (Windows è un'altra storia.) Sui sistemi con più interfacce di rete, come sottolineato da Rui F Ribeiro , dovresti trattare le interfacce compatibili con AMT allo stesso modo in cui tratteresti qualsiasi interfaccia amministrativa (compatibile con IPMI o l'interfaccia host) per un hypervisor VM) e isolarlo su una rete amministrativa (fisica o VLAN). Non puoi fare affidamento su un host per proteggersi: iptablesecc. Qui sono inefficaci, perché AMT vede i pacchetti prima del sistema operativo (e mantiene i pacchetti AMT su se stesso).
Le macchine virtuali possono complicare le cose, ma solo nel senso che possono confondere AMT e quindi produrre risultati di scansione confusi se AMT è abilitato. amt-howto(7)fornisce l'esempio dei sistemi Xen in cui AMT utilizza l'indirizzo fornito a una DomU tramite DHCP, se presente, il che significa che una scansione mostrerebbe AMT attivo sulla DomU, non su Dom0 ...