Pos paling jelas yang pernah saya lihat tentang masalah ini adalah milik Matthew Garrett (termasuk komentar).
Matthew sekarang telah merilis alat untuk memeriksa sistem Anda secara lokal: bangun, jalankan dengan
sudo ./mei-amt-check
dan itu akan melaporkan apakah AMT diaktifkan dan disediakan, dan jika ya, versi firmware (lihat di bawah). The README memiliki rincian lebih lanjut.
Untuk memindai jaringan Anda untuk sistem yang berpotensi rentan, pindai port 623, 624, dan 16992 hingga 16993 (seperti yang dijelaskan dalam dokumen mitigasi Intel sendiri ); sebagai contoh
nmap -p16992,16993,16994,16995,623,664 192.168.1.0/24
akan memindai jaringan 192.168.1 / 24, dan melaporkan status semua host yang merespons. Mampu terhubung ke port 623 mungkin salah positif (sistem IPMI lain menggunakan port itu), tetapi port terbuka dari 16992 hingga 16995 adalah indikator yang sangat baik dari AMT yang diaktifkan (setidaknya jika mereka merespons dengan tepat: dengan AMT, itu berarti respons HTTP pada 16992 dan 16993, yang terakhir dengan TLS).
Jika Anda melihat respons pada port 16992 atau 16993, menyambungkan ke porta tersebut dan meminta /menggunakan HTTP akan mengembalikan respons dengan Servergaris yang berisi "Teknologi Manajemen Aktif Intel" pada sistem dengan AMT diaktifkan; baris yang sama juga akan berisi versi firmware AMT yang digunakan, yang kemudian dapat dibandingkan dengan daftar yang diberikan dalam nasihat Intel untuk menentukan apakah itu rentan.
Lihat jawaban CerberusSec untuk tautan ke skrip yang mengotomatiskan hal di atas.
Ada dua cara untuk memperbaiki masalah "dengan benar":
- tingkatkan firmware, setelah pabrik sistem Anda memberikan pembaruan (jika pernah);
- hindari menggunakan port jaringan yang menyediakan AMT, baik dengan menggunakan antarmuka jaringan yang tidak mampu AMT pada sistem Anda, atau dengan menggunakan adaptor USB (banyak workstation AMT, seperti sistem C226 Xeon E3 dengan port jaringan i210, hanya memiliki satu AMT- antarmuka jaringan yang mampu - sisanya aman; perhatikan bahwa AMT dapat bekerja melalui wi-fi, setidaknya pada Windows, sehingga menggunakan wi-fi bawaan juga dapat menyebabkan kompromi).
Jika tidak satu pun dari opsi ini tersedia, Anda berada di wilayah mitigasi. Jika sistem Anda yang berkemampuan AMT tidak pernah disediakan untuk AMT, maka Anda cukup aman; mengaktifkan AMT dalam kasus itu tampaknya hanya dapat dilakukan secara lokal, dan sejauh yang saya tahu membutuhkan menggunakan firmware sistem Anda atau perangkat lunak Windows. Jika AMT diaktifkan, Anda dapat mem-boot ulang dan menggunakan firmware untuk menonaktifkannya (tekan CtrlPsaat pesan AMT ditampilkan saat boot).
Pada dasarnya, meskipun kerentanan hak istimewa cukup buruk, tampaknya sebagian besar sistem Intel tidak terpengaruh. Untuk sistem Anda sendiri yang menjalankan Linux atau sistem operasi mirip Unix lainnya, eskalasi mungkin memerlukan akses fisik ke sistem untuk mengaktifkan AMT. (Windows adalah cerita lain.) Pada sistem dengan beberapa antarmuka jaringan, seperti yang ditunjukkan oleh Rui F Ribeiro , Anda harus memperlakukan antarmuka yang mendukung AMT dengan cara yang sama seperti memperlakukan antarmuka administratif apa pun (yang mendukung IPMI, atau antarmuka host untuk VM hypervisor) dan mengisolasinya pada jaringan administratif (fisik atau VLAN). Anda tidak dapat mengandalkan host untuk melindungi dirinya sendiri: iptablesdll. Tidak efektif di sini, karena AMT melihat paket sebelum sistem operasi (dan menyimpan paket AMT untuk dirinya sendiri)
VM dapat memperumit masalah, tetapi hanya dalam arti bahwa mereka dapat membingungkan AMT dan dengan demikian menghasilkan hasil pemindaian yang membingungkan jika AMT diaktifkan. amt-howto(7)memberikan contoh sistem Xen di mana AMT menggunakan alamat yang diberikan kepada DomU melalui DHCP, jika ada, yang berarti pemindaian akan menunjukkan AMT aktif pada DomU, bukan Dom0 ...