Bagaimana cara mendeteksi dan mengurangi eskalasi kerentanan hak istimewa Intel pada sistem Linux (CVE-2017-5689)?

26

Menurut posting pusat keamanan Intel tertanggal 1 Mei 2017, ada kerentanan kritis pada prosesor Intel yang dapat memungkinkan penyerang untuk mendapatkan hak istimewa (eskalasi hak istimewa) menggunakan AMT, ISM dan SBT.

Karena AMT memiliki akses langsung ke perangkat keras jaringan komputer, kerentanan perangkat keras ini akan memungkinkan penyerang mengakses sistem apa pun.

Ada peningkatan kerentanan hak istimewa dalam Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM), dan Intel® Small Business Technology versi firmware versi 6.x, 7.x, 8.x 9.x, 10 .x, 11.0, 11.5, dan 11.6 yang dapat memungkinkan penyerang yang tidak memiliki hak pribadi untuk mendapatkan kendali atas fitur pengelolaan yang disediakan oleh produk ini. Kerentanan ini tidak ada pada PC konsumen berbasis Intel.

Intel telah merilis alat deteksi yang tersedia untuk Windows 7 dan 10. Saya menggunakan informasi dari dmidecode -t 4dan dengan mencari di situs web Intel, saya menemukan bahwa prosesor saya menggunakan Intel® Active Management Technology (Intel® AMT) 8.0.

Produk yang terpengaruh:

Masalahnya telah diamati dalam firmware firmware pengelolaan Intel versi 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5, dan 11.6 untuk Intel® Active Management Technology, Intel® Small Business Technology, dan Intel ® Pengaturan Standar. Versi sebelum 6 atau setelah 11.6 tidak terpengaruh.

Deskripsi:

Penyerang lokal yang tidak memiliki hak pribadi dapat menyediakan fitur kemudahan mengelola yang mendapatkan jaringan tanpa hak atau hak istimewa sistem lokal pada SKU pengelolaan yang dikelola Intel: Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM), dan Intel® Small Business Technology (SBT)

Bagaimana saya dapat dengan mudah mendeteksi dan mengurangi eskalasi kerentanan hak istimewa Intel pada sistem Linux?

linux security hardware x86 vulnerability GAD3R
sumber
1
Kasus ini semakin rumit ketika banyak dari kita menggunakan VM; untuk mesin nyata apakah cukup untuk memindai keberadaan layanan di UDP 16992? +1
Rui F Ribeiro
2
Langkah-langkah pencegahan: gunakan SPARC (saya tahu, saya tahu, bukan solusi yang layak). Punya +1
Fox
3
@Fox cukup mengejutkan, CPU ME dalam prosesor Intel adalah SPARC saat ini ;-).
Stephen Kitt
2
@StephenKitt Benarkah? Saya mungkin harus memikirkan kembali pendirian saya pada chip Intel! Hampir semua mesin saya adalah PPC atau SPARC, jadi saya harus mengakui bahwa bias saya nyata
Fox
3
Lihat juga Apakah saya terpengaruh oleh eskalasi kerentanan hak istimewa AMT / ISM / SBT Intel?
Gilles 'SANGAT berhenti menjadi jahat'

Jawaban:

18

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 ...

Stephen Kitt
sumber
Apakah tidak ada cara lokal untuk mendeteksi AMT dari Linux pada mesin? Menggunakan /proc/cpuinfoatau dmidecode?
dolmen
Apakah itu berarti bahwa jika suatu sistem tidak menanggapi port-port ini, maka ia aman dari kerentanan ini atau dapatkah ia masih dieksploitasi secara lokal?
comfreak
Mitigasi pada laptop dapat berupa penggunaan NIC USB dan bukannya bawaan.
Michael Mol
1
Anda menulis "perhatikan bahwa AMT dapat bekerja melalui wi-fi, setidaknya di Windows". Saya pikir kerentanan ini bekerja secara independen dari OS?
Wurtel
1
@wurtel kerentanannya adalah OS-independen pada antarmuka kabel, tetapi pada wi-fi AMT tampaknya membutuhkan kerja sama dari driver OS yang menjalankan: itu tidak mencegat paket, itu bergantung pada OS meneruskan paket yang sesuai untuk itu (seperti yang saya mengerti) - perhatikan bahwa saya belum menguji sisi ini).
Stephen Kitt
8

Hanya mendeteksi port terbuka untuk layanan ini tidak cukup, itu 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.

Penggunaan sampel:

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 posting blog pendek di http://cerberussec.org/ dengan pendapat kami tentang kerentanan ini.

CerberusSec
sumber