Il post più chiaro che ho visto su questo argomento è quello di Matthew Garrett (compresi i commenti).
Matthew ha ora rilasciato uno strumento per controllare il tuo sistema localmente:compilalo, eseguilo con
sudo ./mei-amt-check
e riporterà se AMT è abilitato e fornito e, in tal caso, le versioni del firmware (vedi sotto). Il README contiene maggiori dettagli.
Per scansionare la tua rete alla ricerca di sistemi potenzialmente vulnerabili, scansiona le porte 623, 624 e da 16992 a 16993 (come descritto nel documento di mitigazione di Intel); ad esempio
nmap -p16992,16993,16994,16995,623,664 192.168.1.0/24
eseguirà la scansione della rete 192.168.1/24 e riporterà lo stato di tutti gli host che rispondono. Essere in grado di connettersi alla porta 623 potrebbe essere un falso positivo (altri sistemi IPMI utilizzano quella porta), ma qualsiasi porta aperta da 16992 a 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 risposte sulle porte 16992 o 16993, ti connetti a quelle e richiedi / l'utilizzo di HTTP restituirà una risposta con un Server riga contenente "Intel(R) Active Management Technology" 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'avviso di Intel per determinare se è vulnerabile.
Vedi la risposta di CerberusSec per un collegamento a uno script che automatizza quanto sopra.
Esistono due modi per risolvere il problema "correttamente":
- aggiorna il firmware, una volta che il produttore del tuo sistema fornisce un aggiornamento (se mai);
- evitare di utilizzare la porta di rete che fornisce AMT, utilizzando un'interfaccia di rete non compatibile con AMT sul sistema o utilizzando un adattatore USB (molte workstation AMT, come i sistemi C226 Xeon E3 con porte di rete i210, hanno solo un'interfaccia di rete compatibile con AMT:il resto è sicuro; tieni presente che AMT può funzionare tramite Wi-Fi, almeno su Windows, quindi anche l'utilizzo del Wi-Fi integrato può portare a una compromissione).
Se nessuna di queste opzioni è disponibile, sei nel territorio della mitigazione. Se il tuo sistema compatibile con AMT non è mai stato predisposto per AMT, allora sei ragionevolmente al sicuro; l'abilitazione di AMT in quel caso può apparentemente essere eseguita solo localmente e, per quanto ne so, richiede l'utilizzo del firmware del sistema o del software Windows. Se AMT è abilitato, puoi riavviare e usare il firmware per disabilitarlo (premi Ctrl P quando viene visualizzato il messaggio AMT durante l'avvio).
Fondamentalmente, sebbene la vulnerabilità dei privilegi sia piuttosto sgradevole, sembra che la maggior parte dei sistemi Intel non sia effettivamente interessata. Per i tuoi sistemi che eseguono Linux o un altro sistema operativo simile a Unix, l'escalation richiede probabilmente 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 nello 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:iptables ecc. sono inefficaci qui, perché AMT vede i pacchetti prima del sistema operativo (e tiene i pacchetti AMT per sé).
Le VM 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 un DomU su DHCP, se presente, il che significa che una scansione mostrerebbe AMT attivo sul DomU, non sul Dom0...
Il semplice rilevamento delle porte aperte per questo servizio non è sufficiente, non indica se la versione è interessata o meno. Il nostro team ha creato uno script python disponibile sul nostro github:CerberusSecurity/CVE-2017-5689 che rileva se un sistema bersaglio è vulnerabile ad un attacco remoto.
Esempio di utilizzo:
python CVE_2017_5689_detector.py 10.100.33.252-255
Ciò dovrebbe consentirti di verificare se sei sfruttabile da remoto. Se sei interessato, abbiamo anche scritto un breve post sul blog all'indirizzo http://cerberussec.org/ con la nostra opinione su questa vulnerabilità.
Intel dispone di strumenti per Linux su :Linux Detection and Mitigation Tools
ce n'è un fork su GITHUB