Sejarah Patch Apple

Tahun ini, saya dan saya berbicara di konferensi VolgaCTF dan KazHackStan dengan pembicaraan tentang program Patch Diffing yang ditulis pada Objective-C, dan bagaimana menggunakannya untuk mencari dan menemukan kerentanan 0 hari dan 1 hari pada produk Apple. Anda dapat menonton video presentasi di sini , dan untuk membaca artikel, selamat datang di kucing.

Binary Diffing adalah proses membandingkan dua file yang dapat dieksekusi untuk menemukan persamaan dan perbedaan di antara mereka. Patch Diffing adalah kasus khusus Binary Diffing ketika file dengan kerentanan dibandingkan dengan file tetap (file dengan patch). Jadi, Anda dapat mengetahui koreksi apa yang telah dibuat pengembang dan memahami apa kerentanannya.

Beberapa tahun yang lalu (yaitu pada 2013), sebuah artikel diterbitkan tentang program Patch Diffing untuk Windows, yang juga kami bantu. Kami menyarankan Anda membiasakan diri dengan itu jika Anda tertarik pada topik ini sehubungan dengan OS Windows. Pada artikel yang sama, kita akan berbicara tentang analisis program untuk OS apel.

Bagaimana Binary Diffing dan Patch Diffing berguna?

Tugas utama Binary Diffing adalah untuk melacak perubahan apa yang telah dibuat pada aplikasi. Untuk melakukan ini, Anda perlu mengambil versi lama dan membandingkannya dengan yang baru untuk melihat perubahan apa yang ditambahkan pengembang dan bagaimana mereka diterapkan.

Mari kita lihat situasi di mana ini mungkin berguna:

• Analisis pengembangan program : Membandingkan versi baru dan lama, Anda dapat memahami bagaimana aplikasi berkembang, fungsionalitas baru apa yang ditambahkan, yang dihapus dan perubahan apa yang dialami kode yang ada.
• Mengimpor pengetahuan yang ada : Dalam program yang tidak menggunakan informasi simbolik, insinyur balik harus menghabiskan lebih banyak waktu mempelajari logika dan mencari kerentanan. Tetapi kebetulan bahwa dalam beberapa versi perangkat lunak, pengembang tidak sengaja atau sengaja meninggalkan informasi simbolik. Informasi ini dapat dipindahkan dari sana ke versi perangkat lunak yang Anda butuhkan. Misalnya , karyawan Google Project Zero yang menggunakan Binary Diffing dapat memperoleh karakter untuk versi baru Adobe Reader dari versi yang lebih lama untuk sistem operasi lain, yang membantu mereka menemukan kerentanan;
• Pelatihan tentang perangkat lunak nyata : menurut pendapat kami, Patch Diffing adalah cara yang bagus untuk dengan lancar beralih dari mempelajari masalah-masalah KKP kecil ke meneliti perangkat lunak nyata. Menjelajahi tambalan, Anda dapat melihat kerentanan nyata dalam produk perangkat lunak besar dengan semua fitur-fiturnya (sambil mengetahui dengan pasti bahwa kerentanan tersebut ada dalam kode). Dengan menjelajahi kesalahan dalam suatu produk, Anda dapat secara bertahap beralih ke menemukan kerentanan yang sama. Sebagai bonus, Anda dapat mencoba menulis eksploit untuk mereka;
• Membuat eksploitasi 1 hari : Ketika seorang pengembang telah merilis sebuah tambalan, Anda dapat dengan cepat menganalisisnya, menulis eksploit untuk kerentanan ini dan mendapatkan eksploit 1 hari. Pada saat yang sama, ada yang disebut Patch Gapping - waktu antara rilis patch dan instalasi langsung oleh klien. Selama waktu ini, eksploitasi 1 hari dapat bekerja dengan sukses dan menguntungkan penulisnya (instal pembaruan tepat waktu!) Sampai semua orang menginstal patch yang dirilis oleh pengembang. Ada situasi ketika kerentanan diperbaiki di perpustakaan, tetapi program masih menggunakan versi perpustakaan yang sudah ketinggalan zaman. Berikut adalah beberapa contoh menarik dari Patch Gapping untuk Chrome dan WebKit ;
• Mencari kerentanan 0-hari : Tidak peduli seberapa aneh ini terdengar, menganalisis tambalan, Anda juga dapat menemukan kerentanan yang sebelumnya tidak dikenal (kerentanan 0-hari). Pengembang juga salah, dan karena itu, dalam proses membuat tambalan, kerentanan mungkin tidak ditutup dengan benar. Jadi, dengan menganalisis tambalan, Anda dapat menemukan jalan keluarnya. Misalnya, pengembang Apache Struts memperbaiki kerentanan lima kali, tetapi tambalan hanya berfungsi di versi keenamnya! Selain itu, seringkali pengembang, yang dengan jelas memenuhi tugas yang ditetapkan kepadanya untuk memperbaiki kerentanan tertentu, mungkin tidak memperhatikan apa yang terjadi di bagian kode yang berdekatan. Mungkin ada kerentanan yang sama persis di dekatnya, dan dalam hal deteksi akan 0 hari. Penting untuk mempelajari pola kesalahan pengembang yang terdeteksi dan mencoba menemukan sesuatu yang serupa di program yang sama. Jika pengembang membuat kesalahan di satu tempat, maka kemungkinan mengulang kesalahan yang sama di tempat lain tinggi.

Ada mitos yang menyembunyikan informasi patch kerentanan meningkatkan keamanan. Namun, penyerang, sebagai suatu peraturan, telah mengembangkan infrastruktur untuk menganalisis tambalan, sehingga mereka akan dengan cepat menemukan data yang mereka minati. Menyembunyikan kerentanan mempersulit pekerjaan mereka yang bertanggung jawab untuk melindungi sistem, karena tanpa akses penuh ke informasi, tidak mungkin untuk memahami betapa pentingnya tambalan ini bagi perusahaan. Pada masalah ini, kami sangat menyarankan Anda membaca artikel "Rashomon of disclosure" dari peneliti Halvar Flake, di mana situasinya dilihat dari berbagai sudut.

Tidak selalu ditemukan kerentanan disembunyikan dengan sengaja. Pengembang mungkin tidak mementingkan beberapa kekurangan produk mereka dan memperbaikinya tanpa publisitas, seperti bug biasa.

Kami yakin ini tidak semua situasi di mana Anda dapat menggunakan Binary Diffing dan Patch Diffing, dan dalam komentar Anda dapat menulis skrip Anda sendiri.

Toolkit

Dari teori kita secara bertahap beralih ke praktik. Tentu saja, melakukan Binary Diffing secara manual adalah pekerjaan yang gila. Toolkit yang luas telah lama dikembangkan, terdiri dari program mandiri dan plugin untuk analisis biner populer: Diaphora, BinDiff, DarunGrim, YaDiff, rizzo, Realyze, Turbodiff, patchdiff2, pertandingan ulang dan lainnya.

Antarmuka BinDiff.

Antarmuka Diaphora

Dalam praktiknya, kami terutama hanya menggunakan dua yang pertama (mereka disajikan dalam tangkapan layar di atas). Sayangnya, sebagian besar alat yang ada saat ini tidak mendukung dengan kualitas pekerjaan, atau sepenuhnya ditinggalkan. Sekarang ada alat baru menggunakan ML, tetapi kualitasnya meninggalkan banyak yang harus diinginkan, meskipun mereka memiliki ide menarik untuk membandingkan file biner dari arsitektur yang berbeda.

Saya juga ingin secara terpisah mencatat alat yang baru saja muncul untuk membandingkan kode sumber terbuka dalam file biner: Pigaios dan Karta. Ini adalah arahan yang sangat menarik dan bermanfaat. Mereka mengumpulkan metrik dari kode sumber dan kemudian menggunakannya untuk membandingkan fungsi dalam file biner. Ini sangat berguna karena tidak ada karakter dan tautan statis. Tugas alat-alat ini adalah untuk memetakan fungsi dalam satu file ke fungsi di file lain.

Perbandingan tambalan untuk sistem operasi Apple

Sebagai aturan, aplikasi untuk OS apel menulis di Objective-C. Ini adalah ekstensi berorientasi objek untuk C, berdasarkan pada paradigma bahasa Smalltalk dengan runtime sendiri.

Jika kita membuka program pada Objective-C di beberapa binary analyzer (dalam kasus kami, ini adalah IDA), kita akan melihat sesuatu seperti ini: fungsi di C / C ++ akan memiliki nama abstrak, dan fungsi di Objective-C akan disebut sangat indah. (Kami akan segera mengatakan bahwa kami tidak mempertimbangkan situasi dengan kebingungan kode - ini adalah cerita terpisah.) Ini membuat reverse engineer lebih mudah: mudah untuk melihat objek mana yang dipanggil, metode mana yang digunakan, dan argumen apa yang dimilikinya. Juga, informasi simbolis ini sangat menyederhanakan pekerjaan dengan alat untuk membandingkan file biner. Ini memungkinkan Anda untuk dengan cepat dan dengan sejumlah kesalahan fungsi peta.

Ketika tidak ada simbol, alat harus menggunakan algoritma internal untuk analisis, heuristik, dll. Secara alami, mereka tidak selalu bekerja dengan benar.

Kasus penggunaan di mana patch diffing sangat berguna

Mungkin, presentasi ini (dalam format 45 menit) dan artikel ini tidak akan lahir jika baru-baru ini, Apple tidak mengejutkan komunitas riset dunia beberapa kali. Mari kita lihat kasus-kasus ini.

Kasus 1: CVE-2019-8606

Pada Mei 2019, iOS 12.3 untuk iPhone dirilis, di mana kerentanan yang memungkinkan untuk menginstal jailbreak diperbaiki. Pada bulan Juli tahun itu, Apple merilis versi 12.4, di mana jailbreak mulai bekerja lagi: karyawan secara tidak sengaja melepas patch pelindung. Versi yang dikoreksi dirilis hanya setelah satu bulan: selama ini setiap perangkat pada versi terbaru dapat dengan mudah mengalami operasi jailbreak. Semua ini ditemukan berkat patching diffing.

Kasus 2: CVE-2019-7278 dan CVE-2019-7286

Pengalaman pribadi dengan Patch berbeda pada konferensi Hack dalam Kotak dalam laporannya Menciptakan jailbreak iOS 0-hari dari patch keamanan Apple dijelaskan oleh peneliti keamanan Stefan Esser. Dia berbicara tentang CVE-2019-7278 dan CVE-2019-7286 - mereka terkenal untuk mereka yang ditemukan berkat Grup Analisis Ancaman Google selama penggunaan aktual mereka oleh penyerang (ITW, di alam liar). Apple menerima informasi tentang mereka, tetapi baik mereka maupun orang-orang dari Google tidak mengungkapkan rincian teknis. Kemudian Stefan bertanya-tanya apa yang digunakan para penyerang. Kami sangat menyarankan Anda membaca laporannya, karena juga berbicara tentang proses membandingkan komponen kernel dan ruang pengguna.
Fakta menarik: satu atau dua hari sebelum pidato Stefan, Project Zero Ian Beer menerbitkan serangkaian artikel “Penyelaman yang sangat mendalam ke dalam rantai Eksploitasi iOS yang ditemukan di alam liar” , yang agak membingungkan peta untuk peneliti;)

Kasus 3: checkm8

Perangkat Apple menggunakan dua bootloader: Bootrom dan Iboot. Yang pertama mulai berfungsi segera setelah perangkat menyala. Ini dalam memori read-only dan tidak dapat diperbarui. Iboot adalah bootloader tingkat kedua yang meningkatkan otentikasi yang berjalan di rantai boot.
Keunikan dari loader adalah mereka berbagi kode. Pada awal tahun lalu, spesialis membandingkan pembaruan untuk Iboot dan menemukan bahwa Apple memperbaiki kerentanan di tumpukan USB. Mengetahui bahwa kode yang sama digunakan di bagian Bootrom yang tidak diperbarui, mereka menyadari bahwa kerentanan ini juga ada di sana. Kemudian pengembangan eksploitasi checkm8 dimulai. Sekarang semua perangkat berbasis chip dari A5 hingga A11 (dari iPhone 4s ke iPhone X) sangat rentan, dan dimungkinkan untuk menjalankan kode Anda sendiri pada mereka. Pada saat yang sama, pada perangkat versi XR dan 11, kerentanan ini sudah ditutup, dan tidak ada laporan tentang ini dari Apple.
Jadi, mengetahui di mana itu ditambal dan bagaimana kode itu dibagi, Anda dapat menemukan beberapa hal yang sangat keren!

Kisah kami: CVE-2019-8574

Pada bulan Mei, Apple merilis pembaruan baru untuk perangkatnya. Kami melihat daftar kerentanan tetap dan menemukan utilitas sysdiagnose. Program ini mengumpulkan informasi diagnostik dari berbagai sumber dan mentransfernya kepada pengguna dalam bentuk arsip untuk analisis lebih lanjut, dukungan atau pusat layanan. Tampaknya mustahil memengaruhi cara dia mengumpulkan informasi. Deskripsi tambalan menyatakan bahwa kerentanan dapat digunakan untuk meningkatkan hak istimewa dan merupakan kesalahan kerusakan memori, yang semakin membuat kami semakin tertarik. Dan penulis menemukan dirinya tidak mempublikasikan deskripsi apa pun dari dirinya sendiri ...

Anda dapat memanggil sysdiagnose di macOS dengan menekan Ctrl + Option + Shift +., Atau menggunakan perintah sudo sysdiagnose. Pada perangkat iOS, Anda perlu menahan tombol daya dan tombol volume naik dan turun.

Patch Diffing Apple dalam prakteknya

Jika Anda ingin menambal perangkat Diffing Apple, Anda perlu mendapatkan dua versi pembaruan (lama dan baru). Di macOS, Anda dapat menganalisis file di Katalog Pembaruan Perangkat Lunak. Metode ini tidak selalu membantu, karena Apple menghapus beberapa pembaruan. Pembaruan juga dapat ditemukan di direktori / Library / Updates. Anda dapat menemukan firmware untuk perangkat iOS di situs web ipsw.me.
Untuk macOS, Anda perlu mengekstrak file yang dapat dieksekusi, file library, frameworks, dan kernel menggunakan utilitas Paket Mencurigakan.
Untuk perangkat iOS, masalahnya sedikit lebih rumit. Pembaruan itu sendiri adalah arsip ZIP. Dalam arsip ini Anda perlu menemukan file kernelcache: di dalamnya ada kernel dan ekstensinya. Namun, sebelum analisis, Anda perlu mengonversi file ke format Mach-O. Ini dapat dilakukan menggunakan utilitas img4tool, joker, jtool2 dan lainnya.
Firmware komponen-tanah-pengguna dapat ditemukan dalam gambar DMG terbesar: ini berisi sistem root dan file yang dapat dieksekusi. Namun, jika Anda melihat pustaka dan kerangka kerja bersama, mereka tidak akan ada di sana. Faktanya adalah untuk mengoptimalkan ruang mereka ditempatkan di dyld_shared_cache. File ini berisi semua perpustakaan di iPhone dan membutuhkan lebih dari 1 gigabyte, yang mempersulit analisisnya. Jika Anda perlu mengunduh bagian terpisah dari file ipsw, gunakan utilitas ipsw ( https://github.com/blacktop/ipsw ).

Patchdifting CVE-2019-8574

Untuk mempelajari patch CVE-2019-8574, kami mendapatkan file dari Library / Updates dan mengekstrak dua file executable sysdiagnose (lama dan baru) menggunakan Paket Mencurigakan, dan kemudian memeriksa pembaruan melalui utilitas untuk membandingkan kode biner, misalnya, Diaphora atau BinDiff (mereka banyak lebih baik dari hex editor).

Bagaimana cara kerja patch

Untuk arsitektur x86_64, kami hanya menemukan satu fungsi yang berubah. Ada lebih banyak perubahan dalam ARM, tetapi tidak signifikan.

Masalahnya dengan metode [SDTask start]: ia menambahkan cek baru. Pada gambar Anda dapat melihat bagaimana panggilan ke beberapa fungsi isAppleInternal dipanggil dan keberadaan substring / usr / lokal di beberapa jalur diperiksa.

Seperti yang dinyatakan sebelumnya, sysdiagnose mengumpulkan informasi dari berbagai sumber. Sumber dapat berupa file (misalnya, log peristiwa), atau output dari beberapa perintah informasi (misalnya, daftar proses atau utas menggunakan ps) - tugas tersebut disimpan dalam sysdiagnose sebagai objek SDTask. Metode [mulai SDTask] memulai pelaksanaan tugas. Pada gambar di bawah ini Anda dapat melihat kode di mana semua tugas dibentuk. Semua jalur file yang dapat dieksekusi dan argumennya ditulis langsung dalam program, dan ada tugas dari berbagai direktori, termasuk / usr / local.

Jadi, sebelum menginstal tambalan, tugas apa pun dapat dilakukan tanpa memandang di mana file yang dapat dieksekusi berada. Setelah menginstal tambalan, fungsi isAppleInternal disebut, yang memeriksa apakah perangkat tersebut merupakan perangkat uji internal Apple. Jika ini adalah perangkat internal, maka tugas dilakukan dengan cara standar, dan jika itu adalah sisi klien, keberadaan substring / usr / local / di jalur file yang dapat dieksekusi tugas diperiksa. Jika substring ditemukan, tugas tidak akan selesai.

Ingatlah bahwa dalam deskripsi kerentanan dikatakan bahwa ini adalah kesalahan kerusakan memori, tetapi dalam tambalan kami tidak melihat hal seperti itu ... Menurut pendapat kami, ini adalah kerentanan logis yang dieksploitasi dengan baik dan stabil.

Bagaimana cara memanfaatkannya

Untuk mengeksploitasi kerentanan, Anda harus melakukan langkah-langkah berikut:
Buat file yang dapat dieksekusi (skrip biner atau shell) yang diluncurkan oleh sysdiagnose dari / usr / local / bin, dan masukkan muatan kami di sana. Daftar file yang valid diberikan di bawah ini. Adalah penting bahwa pengelola paket minuman diinstal pada sistem: ini memungkinkan pengguna untuk membuat file di / usr / local / tanpa meningkatkan hak istimewa.

Perlu untuk memanggil sysdiagnose. Pada saat yang sama, muatan kami akan dieksekusi dengan hak pengguna root, dan hasilnya akan ditempatkan di arsip yang sysdiagnose formulir. Dengan demikian, kita mendapatkan eskalasi hak istimewa. Namun, menjalankan sysdiagnose itu sendiri membutuhkan hak yang lebih tinggi. Tetapi, seperti yang disebutkan di atas, sysdiagnose juga dapat diluncurkan menggunakan pintasan keyboard, dan ini berfungsi bahkan dari layar kunci macOS.
Kerentanan ini dapat digunakan untuk membuat berbagai program jahat.

/usr/local/bin/airplayutil /usr/local/bin/amstool /usr/local/bin/apsclient /usr/local/bin/audioDeviceDump /usr/local/bin/cdcontexttool /usr/local/bin/cddebug /usr/local/bin/cdknowledgetool /usr/local/bin/dastool /usr/local/bin/idstool /usr/local/bin/imtool /usr/local/bin/keystorectl /usr/local/bin/pmtool /usr/local/bin/xcpm /usr/local/efi/bin/efi-perf 

Yang menarik, kerentanan lain dapat dikaitkan dengan pengelola paket minuman, atau lebih tepatnya dengan kemampuan untuk menulis ke / usr / lokal / tanpa hak istimewa.

Kesimpulan

Dengan penelitian ini, kami ingin menunjukkan pentingnya dan kekritisan perbedaan patch tidak hanya untuk penyerang, tetapi juga untuk meningkatkan keamanan produk perangkat lunak. Sayangnya, tambalan tidak hanya dapat menutup kerentanan, tetapi juga memainkan ke tangan penyerang.

Namun demikian, pendekatan ini memungkinkan tidak hanya untuk mempelajari kerentanan yang diketahui, tetapi juga untuk mencari yang baru seperti mereka. Oleh karena itu, kami percaya bahwa perbedaan patch adalah suatu keharusan bagi setiap peneliti.