Retak OS X Lion Sandi
Oleh
chmood
Isu-isu yang dijelaskan dalam posting ini kini telah diselesaikan oleh Apple. Pengguna menjalankan OS X Lion 10.7.2 atau keamanan pembaruan 2011-006 tidak lagi dipengaruhi oleh kerentanan rinci di bawah (CVE-2011-3435 dan CVE-2011-3436). Untuk rincian lebih lanjut tentang pembaruan keamanan ini silahkan lihat Apple's advisory.
Pada tahun 2009 saya posting artikel tentang password Cracking Mac OS X. Sementara posting ini sudah cukup populer, itu ditulis untuk OS X 10.6 dan sebelumnya. Sejak rilis Mac OS X Lion (10.7) pada bulan Juli, saya telah menerima banyak permintaan untuk update. Biasanya, saya akan hanya diperbarui artikel yang ada tanpa perlu posting baru. Namun, selama penelitian, saya menemukan sesuatu yang menarik tentang OS X Lion yang saya ingin berbagi.
Dalam versi sebelumnya dari OS X (10,6, 10,5, 10,4) proses untuk mengekstrak pengguna hash password telah sama: mendapatkan pengguna GeneratedUID dan kemudian menggunakan ID yang untuk mengekstrak hash dari file shadow pengguna tertentu (Lihat posting saya sebelumnya untuk keterangan lebih rinci).
Ketika datang ke Lion, premis umum adalah sama (meskipun perbedaan teknis beberapa). Setiap pengguna memiliki file bayangan mereka sendiri, dengan setiap file shadow disimpan di bawah file Plist terletak di / var / db / dslocal / node / default / pengguna /.
Hal yang menarik ketika datang ke implementasi Lion, bagaimanapun, adalah hak istimewa. Seperti disebutkan di atas, semua versi OS X menggunakan file shadow. Untuk asing, file shadow adalah bahwa yang hanya dapat diakses oleh pengguna dengan hak istimewa tinggi (biasanya root). Jadi untuk semua platform OS X modern (Tiger, Leopard, Snow Leopard dan Lion) setiap pengguna memiliki file mereka sendiri shadow (database hash) yang datanya hanya dapat diakses oleh user root ... atau setidaknya seharusnya.
Tampaknya di desain ulang skema otentikasi OS X Lion langkah penting telah diabaikan. Sementara pengguna non-root tidak dapat mengakses file bayangan langsung, Singa benar-benar menyediakan pengguna non-root kemampuan untuk masih melihat data password hash. Hal ini dilakukan dengan penggalian data langsung dari Directory Services.
Jika kita memanggil aa layanan direktori listing pada pengguna bob dengan menentukan / Lokal / path kita dapat melihat informasi profil standar bob:
$ dscl localhost -read /Local/Default/Users/bob
Ini memberikan kita dengan tidak terlalu menarik. Namun, jika kita memanggil layanan direktori daftar menggunakan / Cari / path, kita melihat hasil yang berbeda:
$ dscl localhost -read /Search/Users/bob
Dari output, kita dapat melihat data sebagai berikut:
dsAttrTypeNative:ShadowHashData:
62706c69 73743030 d101025d 53414c54 45442d53 48413531 324f104474911f72 3bd2f66a 3255e0af 4b85c639 776d510b 63f0b939 c432ab6e 082286c4 7586f19b 4e2f3aab 74229ae1 24ccb11e 916a7a1c 9b29c64b d6b0fd6c bd22e7b1 f0ba1673 080b1900 00000000 00010100 00000000 00000300 00000000 00000000 00000000 000060
Catatan: SHA512 hash disimpan dari byte 32-96 (hijau) dan garam disimpan dari byte 28-31 (merah). Untuk informasi lebih lanjut tentang hash ini silakan lihat thread ini.
Atribut ShadowHashData ini benar-benar berisi hash yang sama disimpan dalam pengguna bob bayangan Plist berkas. Hal yang menarik tentang ini? hak akses root tidak diperlukan. Semua pengguna pada sistem, terlepas dari hak istimewa, memiliki kemampuan untuk mengakses atribut ShadowHashData dari profil setiap pengguna lain.
Karena Lions waktu yang relatif singkat di pasar, saya belum menemukan salah satu kerupuk utama mendukung OS X Lion hash (SHA512 + 4-byte garam). Untuk menyederhanakan retak hash ini saya telah membuat sebuah script python sederhana yang dapat didownload di sini.
Sekarang, jika password tidak ditemukan oleh file kamus Anda beruntung, kan? Nah, tidak ada! Mengapa retak hash ketika Anda hanya dapat mengubah password secara langsung! Tampaknya Layanan Direktori di Lion tidak lagi memerlukan otentikasi ketika meminta perubahan password untuk pengguna saat ini. Jadi, dalam rangka untuk mengubah password dari saat login user, cukup gunakan:
$ dscl localhost -passwd /Search/Users/bob
Dan voila! Anda akan diminta untuk memasukkan password baru tanpa perlu mengotentikasi.
Ada beberapa dugaan seputar keparahan serangan ini. Sementara kemampuan untuk mengubah password user yang sedang aktif adalah bukan hak istimewa eskalasi cacat per se, itu bisa dalam kondisi tertentu dapat digunakan untuk tujuan ini. Izinkan saya untuk memberikan skenario:
Seorang pengguna dengan hak administratif adalah browsing internet dengan Safari. Pengguna terjadi browse ke website hosting Java Applet berbahaya. Tanpa diketahui pengguna, mereka memungkinkan orang yang tidak bersalah mencari Java Applet untuk menjalankan. Applet akan melanjutkan untuk membuat koneksi kembali ke penyerang, memberikan penyerang dengan akses shell penuh. Sementara penyerang memiliki akses ke sistem, mereka disediakan hanya dengan hak pengguna terbatas (mereka masih tidak memiliki akses root). Hal ini akan membatasi apa penyerang bisa capai. Namun, dengan kerentanan yang dijelaskan di atas penyerang sekarang memiliki keuntungan: mereka dapat mengubah password dari pengguna saat ini. Sekarang ingat, pengguna saat ini adalah administrator. Jadi sekarang semua penyerang harus lakukan adalah sudo -s untuk menjadi root. Jika katakanlah korban tidak memiliki hak administratif, penyerang masih memiliki kemampuan untuk mengekstrak hash pengguna dari sistem dan mencoba untuk memecahkan mereka.
Sebagai tindakan sementara untuk mengurangi serangan ini (sebelum Apple merilis sebuah patch), dianjurkan untuk membatasi akses standar untuk utilitas dscl. Dapat dilakukan sebagai berikut:
$ sudo chmod 100 /usr/bin/dscl
Komentar