Postingan paling jelas yang pernah saya lihat tentang masalah ini adalah postingan Matthew Garrett (termasuk komentarnya).
Matthew kini telah merilis alat untuk memeriksa sistem Anda secara lokal:bangun, jalankan dengan
sudo ./mei-amt-check
dan akan melaporkan apakah AMT diaktifkan dan disediakan, dan jika ya, versi firmware (lihat di bawah). README memiliki detail lebih lanjut.
Untuk memindai jaringan Anda dari sistem yang berpotensi rentan, pindai port 623, 624, dan 16992 hingga 16993 (seperti yang dijelaskan dalam dokumen mitigasi milik Intel); misalnya
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 positif palsu (sistem IPMI lain menggunakan port itu), tetapi port terbuka apa pun dari 16992 hingga 16995 adalah indikator yang sangat baik untuk mengaktifkan AMT (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, sambungkan ke port tersebut dan minta / menggunakan HTTP akan mengembalikan respons dengan Server baris berisi "Intel(R) Active Management Technology" 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 saran Intel untuk menentukan apakah rentan.
Lihat jawaban CerberusSec untuk tautan ke skrip yang mengotomatiskan hal di atas.
Ada dua cara untuk memperbaiki masalah “dengan benar”:
- tingkatkan versi firmware, setelah produsen sistem Anda memberikan pembaruan (jika pernah);
- hindari penggunaan port jaringan yang menyediakan AMT, baik dengan menggunakan antarmuka jaringan yang tidak mendukung AMT di sistem Anda, atau dengan menggunakan adaptor USB (banyak stasiun kerja AMT, seperti sistem C226 Xeon E3 dengan port jaringan i210, hanya memiliki satu antarmuka jaringan berkemampuan AMT — sisanya aman; perhatikan bahwa AMT dapat bekerja melalui wi-fi, setidaknya di Windows, jadi menggunakan wi-fi bawaan juga dapat menyebabkan kompromi).
Jika tidak satu pun dari opsi ini tersedia, Anda berada di wilayah mitigasi. Jika sistem berkemampuan AMT Anda 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 memerlukan penggunaan firmware sistem atau perangkat lunak Windows Anda. Jika AMT diaktifkan, Anda dapat mem-boot ulang dan menggunakan firmware untuk menonaktifkannya (tekan Ctrl P ketika pesan AMT ditampilkan selama boot).
Pada dasarnya, meskipun kerentanan hak istimewa cukup parah, tampaknya sebagian besar sistem Intel sebenarnya tidak terpengaruh. Untuk sistem Anda sendiri yang menjalankan Linux atau sistem operasi serupa Unix lainnya, eskalasi mungkin memerlukan akses fisik ke sistem untuk mengaktifkan AMT sejak awal. (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 Anda memperlakukan antarmuka administratif apa pun (kemampuan IPMI, atau antarmuka host untuk hypervisor VM) dan mengisolasinya di jaringan administratif (fisik atau VLAN). Anda tidak bisa mengandalkan host untuk melindungi dirinya sendiri:iptables dll. tidak efektif di sini, karena AMT melihat paket sebelum sistem operasi melihatnya (dan menyimpan paket AMT untuk dirinya sendiri).
VM dapat memperumit masalah, tetapi hanya dalam arti bahwa mereka dapat membingungkan AMT dan menghasilkan hasil pemindaian yang membingungkan jika AMT diaktifkan. amt-howto(7) memberikan contoh sistem Xen di mana AMT menggunakan alamat yang diberikan ke DomU melalui DHCP, jika ada, yang berarti pemindaian akan menunjukkan AMT aktif di DomU, bukan Dom0...
Mendeteksi port terbuka untuk layanan ini saja tidak cukup, tidak menunjukkan apakah versi terpengaruh atau tidak. Tim kami telah membuat skrip python yang tersedia di github kami :CerberusSecurity/CVE-2017-5689 yang mendeteksi jika sistem target rentan terhadap serangan jarak jauh.
Contoh penggunaan:
python CVE_2017_5689_detector.py 10.100.33.252-255
Ini akan memungkinkan Anda untuk dapat memeriksa apakah Anda dapat dieksploitasi dari jarak jauh. Jika Anda tertarik, kami juga menulis postingan blog singkat di http://cerberussec.org/ dengan pendapat kami tentang kerentanan ini.
Intel memiliki alat untuk linux di :Alat Deteksi dan Mitigasi Linux
ada garpu di GITHUB