🌝 🔌 👩🏻‍🎓 Saya bisa menjadi Apple, dan Anda juga 💏 ⛹🏼 👩🏾‍🚒

Pengungkapan kepada publik tentang kode Apple yang menandatangani kerentanan pihak ketiga

Tidak seperti beberapa karya sebelumnya, kerentanan ini tidak memerlukan hak administrator, ini tidak memerlukan kode JIT atau kerusakan memori untuk memotong verifikasi tanda tangan kode. Yang Anda butuhkan adalah file Fat / Universal yang diformat dengan benar, dan verifikasi tanda tangan kode akan menunjukkan hasil yang valid.

Ringkasan

Menemukan jalan memutar yang digunakan oleh API pihak ketiga untuk menandatangani kode memungkinkan Anda untuk menyajikan kode apa pun yang ditandatangani oleh Apple.
Semua vendor dan proyek open source yang terkenal diberi tahu (lihat daftar di bawah). Tersedia tambalan untuk mereka.
Ada kemungkinan bahwa masalahnya memengaruhi program pihak ketiga lainnya yang menggunakan API penandatanganan kode resmi Apple.
Pengembang bertanggung jawab atas penggunaan yang tepat dari API penandatanganan kode. Ada demo hacking tools (PoC) untuk pengujian.
Hanya berlaku untuk macOS dan versi OSX yang lebih lama.

Vendor yang Terkena Dampak

VirusTotal - CVE-2018-10408
Google - Santa, molcodesignchecker - CVE-2018-10405
Facebook - OSQuery - CVE-2018-6336
Pengembangan Tujuan - LittleSnitch - CVE-2018-10470
F-Secure - xFence (juga LittleFlocker) CVE-2018-10403
Objective-See - WhatsYourSign, ProcInfo, KnockKnock, LuLu, TaskExplorer (dan lainnya) - CVE-2018-10404
Yelp - OSXCollector - CVE-2018-10406
Carbon Black - Cb Response - CVE-2018-10407

Pentingnya penandatanganan kode dan cara kerjanya di macOS / iOS

Penandatanganan kode adalah konstruksi keamanan yang menggunakan infrastruktur kunci publik (PKI) untuk menandatangani secara digital kode yang dikompilasi atau bahkan skrip untuk memastikan bahwa kode tersebut tepercaya dan bahwa kode tersebut asli. Pada Windows, Anda dapat secara kriptografis menandatangani hampir semua hal: dari .NET binaries hingga skrip PowerShell. Pada macOS / iOS, penandatanganan kode merujuk terutama ke binari Mach-O dan paket aplikasi untuk memungkinkan hanya kode tepercaya yang dieksekusi dalam memori.

Antivirus, sistem keamanan, dan respons insiden, serta alat forensik menganalisis tanda tangan untuk mengidentifikasi kode tepercaya di antara yang tidak dapat dipercaya. Verifikasi tanda tangan mempercepat analisis. Berbagai alat menggunakan informasi penandatanganan kode untuk menerapkan langkah-langkah keamanan: ini adalah daftar putih, antivirus, respons insiden dan sistem pencarian ancaman. Mengompromikan tanda tangan kode dalam salah satu OS populer berarti merusak konstruksi keamanan dasar, yang menjadi sandaran banyak operasi keamanan informasi rutin.

Masalah sudah ditemukan dalam tanda tangan kode ( 1 , 2 , 3 , 4 , 5 ). Tidak seperti beberapa karya sebelumnya, kerentanan ini tidak memerlukan hak administrator, ini tidak memerlukan kode JIT atau kerusakan memori untuk memotong verifikasi tanda tangan kode. Yang Anda butuhkan adalah file Fat / Universal yang diformat dengan benar, dan verifikasi tanda tangan kode akan menunjukkan hasil yang valid.

Detail Kerentanan

Inti dari kerentanan adalah bahwa loader Mach-O dan Code Signing API tidak digunakan untuk memverifikasi tanda tangan kode secara tidak benar. Perbedaan ini dapat dieksploitasi menggunakan biner Universal / Fat yang dibuat khusus.

Apa itu file Fat / Universal?

Fat / Universal adalah format biner yang berisi beberapa file Mach-O (file yang dapat dieksekusi, dyld atau paket), yang masing-masing berfokus pada arsitektur CPU tertentu (misalnya, i386, x86_64 atau PPC).

Prasyarat

Mach-O pertama dalam file Fat / Universal harus ditandatangani oleh Apple, bisa berupa file i386, x86_64, atau bahkan PPC.
Kode biner berbahaya atau kode asing yang ditandatangani sendiri harus dikompilasi di bawah i386 untuk macOS x86_64.
CPU_TYPE di tajuk Fat biner Apple harus disetel ke jenis atau jenis prosesor yang tidak asli yang bukan asli chipset host.

Tanpa melewati SecRequirementRef dan SecCSFlags yang sesuai, antarmuka program Code Signing API ( SecCodeCheckValidity ) akan memeriksa biner pertama dalam file Fat / Universal untuk mengetahui asal tanda tangan (misalnya, Apple) dan memverifikasi keaslian tanda tangan. Kemudian API akan memeriksa semua binari lain dalam file Fat / Universal untuk kepatuhan Tim Identifier dan keaslian tanda tangan, tetapi tanpa memeriksa akar kepercayaan dari otoritas sertifikasi . Alasan mengapa kode berbahaya atau kode "tidak ditandatangani" harus i386 adalah karena API Penandatanganan Kode dikonfigurasi secara default untuk memeriksa tanda tangan kode untuk arsitektur CPU asli (x86_64).

Salah satu alasan mengapa kode yang ditandatangani sendiri berhasil lulus tes adalah karena bahkan dalam binari Apple utama bidang TeamIdentifier diatur ke not set . Ilustrasi di bawah ini menunjukkan biner Mach-O yang valid, ditandatangani oleh Apple (python.x64), di sebelah Mach-O yang ditandatangani sendiri (ncat.i386). Keduanya memiliki `TeamIdentifier = tidak diset`.

Sebagai contoh, saya menandatangani biner menggunakan ID pengembang dan mencoba lipo untuk menggabungkannya dengan biner Apple menjadi satu file Fat / Universal. Jenis penandatanganan kode ini gagal.

PoC awal saya adalah ncat (dari nmap), yang saya sebut ncat.frankenstein. Di sini, file Fat yang dihasilkan berisi biner Python x86_64 yang ditandatangani Apple dan biner ncat i386 yang ditandatangani sendiri (adhoc). Biner yang ditandatangani sendiri mudah dibuat dengan codesign -s - target_mach-o_or_fat_binary . Begini tampilannya di MachOView:

Jika Anda menjalankan file ini, maka python x86_64 akan mulai:

Dan tanda tangan kode sedang diverifikasi:

Bagaimana saya menjalankan biner yang ditandatangani sendiri oleh ncat?

Ini dilakukan dengan menetapkan tipe CPU_Type yang tidak valid atau CPU non-asli (misalnya, PPC). Kemudian loader Mach-O melompati biner Mach-O dengan tanda tangan yang valid dan mengeksekusi kode jahat (tidak ditandatangani oleh Apple):

Kemudian ncat.frankenstein dieksekusi, dan hasil validasi akan valid :

Kami menerbitkan ncat.frankenstein dan empat contoh lainnya sehingga pengembang dapat memeriksa kerentanan dalam produk mereka.

Rekomendasi

Di baris perintah

Tergantung pada bagaimana Anda memverifikasi kode yang ditandatangani. Jika Anda menggunakan codesign, maka Anda mungkin terbiasa dengan perintah berikut:

codesign –dvvvv - tempat pembuangan otoritas sertifikasi dan TeamIdentifier (ID pengembang)
codesign –vv - verifikasi ketat semua arsitektur

Tetapi untuk memeriksa jenis penyalahgunaan ini dengan benar, Anda perlu menambahkan persyaratan sertifikat jangkar dengan perintah berikut:

codesign -vv -R='anchor apple' ./some_application_or_mach-o # untuk kode yang ditandatangani oleh Apple
codesign -vv -R='anchor apple generic' ./some_application_or_mach-o # untuk kode yang ditandatangani oleh Apple dan Apple

Perintah seperti itu akan menunjukkan kesalahan saat memeriksa kode dengan tanda tangan orang lain:

Anda dapat menggunakan perintah spctl , tetapi membutuhkan analisis yang cermat dari output dari perintah. Misalnya, biner Mach-O dengan tanda tangan Apple (/ bin / ls) dan Safari mengembalikan yang berikut:

Dan ini adalah hasil dari aplikasi yang ditandatangani oleh Apple:

Perhatikan baris “(kode ini valid tetapi sepertinya bukan aplikasi)” untuk / bin / ls, yang tidak lulus tes. Sebagai perbandingan, berikut adalah hasil dari file ncat.frankenstein Fat / Universal:

File ncat.frankenstein Fat / Universal tidak menunjukkan bahwa kode tersebut valid. Oleh karena itu, saya tidak dapat merekomendasikan spctl untuk secara manual memeriksa biner Mach-O offline. Cukup gunakan codesign dengan bendera yang sesuai.

Untuk pengembang

Biasanya, pengembang memeriksa biner Mach-O atau Fat / Universal menggunakan SecStaticCodeCheckValidityWithErrors () atau SecStaticCodeCheckValidity () API dengan bendera berikut:

Bendera ini harus memastikan bahwa semua kode dimuat ke dalam memori dalam file Mach-O atau Fat / Universal ditandatangani secara kriptografis. Namun, API ini tidak memberikan validasi yang tepat secara default, sehingga pengembang pihak ketiga perlu mengisolasi setiap arsitektur dalam file Fat / Universal dan memverifikasi bahwa identitasnya cocok dan kuat secara kriptografis.

Cara terbaik untuk menguji setiap arsitektur bersarang dalam file Fat / Universal adalah dengan memanggil SecRequirementCreateWithString terlebih dahulu dengan persyaratan "jangkar apel", kemudian SecStaticCodeCheckValidity dengan kSecCSDefaultFlags | kSecCSCheckNestedCode | kSecCSCheckAllArchitectures | kSecCSEnforceRevocationChecks dengan mengacu pada persyaratan; seperti yang ditunjukkan dalam kode sumber yang ditambal dari WhatsYourSign .

Dengan meneruskan "jangkar apel" ke fungsi SecRequirmentCreateWithString, panggilan ini bekerja mirip dengan perintah codesign -vv -R='anchor apple' , yang membutuhkan rantai kepercayaan Penandatanganan Perangkat Lunak Apple untuk semua binari yang bersarang di file Fat / Universal. Selain itu, dengan melewati flag dan persyaratan untuk SecStaticCodeCheckValidity, semua arsitektur diperiksa untuk persyaratan ini, dan pemeriksaan pencabutan diterapkan.

Demonstrasi

Alat codesign Apple dan kebutuhan untuk menggunakan flag -R .

LittleSnitch - memeriksa file Fat / Universal pada disk tidak berfungsi, tetapi LittleSnitch dengan benar memeriksa proses dalam memori.

LittleFlocker - F-Secure membeli LittleFlocker, dan sekarang disebut xFence.

F-Secure xFence (sebelumnya LittleFlocker)

Alat Objective-See

Penjelajah tugas

WhatsSign Anda

Facebook OSquery adalah hasil dari sampel malware dan / bin / ls sebagai contoh yang valid.

Penerbitan Google Santa - Fileinfo menunjukkan bahwa ncat.frankenstein masuk daftar putih:

Tolak eksekusi ncat (tidak ditandatangani) dan izin eksekusi ncat.frankenstein:

Log Santa.log yang menampilkan acara dari contoh sebelumnya:

Respon karbon hitam

VirusTotal - contoh bash_ppc_adhoc sebelum menginstal tambalan di VirusTotal:

Tanggal pengungkapan

02/22/2018: Laporan dan PoC dikirim ke Apple untuk mem-bypass sistem keamanan pihak ketiga.

03/01/2018: Apple menjawab bahwa pengembang pihak ketiga harus menggunakan kSecCSCheckAllArchitectures dan kSecCSStrictValidate dengan SecStaticCodeCheckValidity API, dan dokumentasi pengembang akan diperbarui sesuai dengan itu.

03/06/2018: sebuah laporan dan PoC dikirim ke Apple untuk mem-bypass flag dan secara ketat memeriksa codesign .

03/16/2018: Informasi tambahan dikirimkan ke Apple.

03/20/2018: Apple mengatakan tidak melihat ini sebagai masalah keamanan yang harus ditangani secara langsung.

03/29/2018: Apple menyatakan bahwa dokumentasi dapat diperbarui, tetapi "[...] pengembang pihak ketiga harus melakukan pekerjaan tambahan untuk memverifikasi bahwa semua identitas dalam biner universal adalah sama jika mereka ingin memberikan hasil yang bermakna."

04/02/2018: kontak pertama dengan CERT / CC dan kolaborasi selanjutnya untuk memperjelas ruang lingkup dan dampak kerentanan.

04/09/2018: semua pengembang pihak ketiga terkenal yang terpengaruh oleh kerentanan tersebut diberitahu melalui koordinasi dengan CERT / CC.

04/18/2018: kontak terakhir dengan CERT / CC dengan rekomendasi bahwa mengungkapkan informasi kepada publik di blog adalah yang terbaik untuk memberi tahu pengembang pihak ketiga lainnya yang menggunakan API Penandatanganan Kode Apple secara pribadi.

06/05/2018: kontak terakhir dengan pengembang sebelum dipublikasikan.

06/12/2018: pengungkapan informasi.

Kesimpulannya

Terima kasih kepada semua pengembang pihak ketiga atas kerja keras dan profesionalisme mereka dalam menyelesaikan masalah ini. Kerentanan penandatanganan kode terutama bug yang merusak moral, terutama bagi perusahaan yang mencoba memberikan keamanan yang lebih baik daripada standar dalam sistem operasi.

GMO GlobalSign Russia ACTION untuk Pelanggan Habr

Anda dapat memperoleh informasi tambahan dengan menghubungi manajer GlobalSign melalui telepon: +7 (499) 678 2210, atau mengisi formulir di situs web, yang menunjukkan kode promosi CS002HBFR.

Saya bisa menjadi Apple, dan Anda juga