Salam kepada semua orang yang memutuskan untuk membaca artikel baru saya tentang analisis kerentanan. Terakhir kali, dalam serangkaian pendek tiga artikel, saya berbicara tentang kerentanan Steam (
1 ,
2, dan
3 ). Pada artikel ini saya akan berbicara tentang kerentanan produk serupa - Origin, yang juga merupakan peluncur game. Kerentanan yang ditemukan diberi nomor CVE-2019-19247 dan CVE-2019-19248.
Kali ini tidak akan ada permainan dengan pisang anban. Sejarah komunikasi dengan divisi keamanan Electronic Arts Inc awalnya berjalan pada level profesional. Ketika saya dihubungi, mereka memberi saya nomor registrasi, laporan itu diperiksa dan dikonfirmasi dengan cermat. Tidak ada email saya yang diabaikan, dan untuk sedikit diskusi, sebuah confkall diselenggarakan. Pemeliharaan laporan ini sangat sederhana bagi saya, yang banyak terima kasih kepada Adrian Stone, Elise Murphy dan karyawan EA lainnya yang bekerja dengan laporan saya.
Posting dan
saran blog keamanan .
Sekarang untuk kerentanan. Saya menemukan dua kerentanan seperti "eskalasi hak istimewa" (lpe - eskalasi hak istimewa lokal atau eskalasi eskalasi hak istimewa) di klien Origin Windows. Jenis kerentanan ini memungkinkan setiap pengguna Windows untuk mendapatkan lebih banyak hak daripada yang semula dikeluarkan oleh administrator. Dalam hal ini, kita berbicara tentang dua peningkatan "khas" - dari pengguna mana saja ke NT AUTHORITY \ SYSTEM (akun dengan izin maksimum di OS). Kerentanan pertama agak membosankan, jadi di bagian selanjutnya saya akan menjelaskan secara singkat. Tetapi yang kedua cukup menarik, di bagiannya saya akan memberi tahu Anda bagaimana saya mencarinya.
CVE-2019-19248
Kerentanan ini terdiri dari dua bagian:
- Membuat folder di jalur arbitrer (dengan hak Akses Penuh);
- Gunakan klausa 1 untuk mendapatkan hak istimewa NT AUTHORITY \ SYSTEM.
Sekarang tentang poin pertama secara lebih rinci:
Persiapan lingkungan
Penting untuk menutup klien Asal dan menghentikan Layanan Klien Asal (secara teori, layanan itu sendiri akan berhenti jika Anda menutup klien, tetapi untuk berjaga-jaga).
Untuk folder "C: \ ProgramData \ Origin" haknya adalah "All-Full Access", yang memungkinkan kita untuk menghapus isinya sepenuhnya.
Pembuatan Tautan
Sekarang buat beberapa tautan. Tautan pertama akan dari tipe NTFS Reparse Point (NTFS Mount Point) - jenis tautan yang menunjuk dari folder ke folder: “C: \ ProgramData \ Origin” <-> “\ RPC Control”. Untuk membuat titik reparse tidak perlu hak administrator. Hanya perlu bahwa folder sumber kosong dan pengguna memiliki izin menulis untuk itu (mereka dihapus pada langkah terakhir, hak diperiksa di sana). "\ RPC Control" bukan folder dalam sistem file, tetapi jenis khusus folder - direktori objek. Anda tidak dapat melihatnya dengan penjelajah biasa, tetapi Anda dapat melakukan titik reparse di sana, tampaknya karena abstraksi umum yang digunakan dalam perut Windows.
Sekarang kita akan membuat tautan simbolis yang biasa "\ RPC Control \ CatalogCache" <-> "C: \ Path \ To \ Target \ Folder". Dalam sistem file, membuat tautan simbolik tanpa hak administrator dilarang, tetapi aturan ini tidak berlaku untuk direktori objek. Karenanya, tautan kami akan berhasil dibuat. Sebagai hasil dari kombinasi kedua tautan ini, panggilan ke "C: \ ProgramData \ Origin \ CatalogCache" akan dialihkan ke "C: \ Path \ To \ Target \ Folder".
Baca lebih lanjut tentang tautan semacam itu di
sini . Di repositori yang sama,
Anda bisa mengunduh utilitas untuk bekerja dengan tautan.
Luncurkan
Pada langkah terakhir, jalankan klien. Di awal karyanya, ia akan meluncurkan "Layanan Klien Asal" dan, menemukan bahwa tidak ada folder "C: \ ProgramData \ Origin \ CatalogCache", ia akan mencoba untuk membuatnya. Sebagai hasil dari menavigasi melalui symlinks, itu akan membuat "C: \ Path \ To \ Target \ Folder" dan memberikan folder ini "Akses All-Full".
Apa yang diperlukan untuk diperoleh pada titik operasi pertama. Mari kita beralih ke yang kedua.
Operasi membuat folder di jalur arbitrer
Di sini Anda dapat bekerja dengan banyak cara.
Sederhana dan cukup andal adalah membuat folder "C: \ Windows \ system32 \ LogonUI.exe.local". "LogonUI.exe" (aplikasi yang berjalan dari NT AUTHORITY \ SYSTEM, bertanggung jawab untuk pengoperasian layar pemilihan pengguna dan layar kunci) berkat mekanisme .local-redirection ("redirection dotlocal"), ia akan memuat perpustakaan dari sana di sepanjang jalur "C: \ Windows \ system32 \ LogonUI.exe.local \ amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.648_none_fb45a0e93062a6d2 \ comctl32.dll. " Secara umum, mekanisme itu sendiri cukup umum, sehingga dapat memiliki banyak tujuan.
Cara yang panjang namun menarik adalah dengan mengurangi hash kata sandi administrator melalui penipuan khusus. Lebih detail di
sini .
Total
Kerentanan dieksploitasi dengan cukup mudah, Anda hanya perlu bekerja sedikit pada poin kedua - menemukan target dan menulis dll yang sesuai. Selain itu, Matt Nelson juga melaporkan kerentanan ini, dan tulisannya dapat ditemukan di
sini .
CVE-2019-19247
Ini adalah salah satu kerentanan favorit saya. Ini menunjukkan seberapa hati-hati Anda harus berhubungan dengan kriptografi yang digunakan.
Semuanya dimulai dengan fakta bahwa saya menginstal game melalui Origin. Semuanya berjalan terlalu lancar - beberapa klik dan setelah beberapa menit mengunduh game dapat diluncurkan. Tidak segera, tetapi saya mengerti apa yang terjadi: permainan dipasang di sepanjang jalur "C: \ Program Files \ GameName", tetapi tidak mengajukan satu pertanyaan pun melalui UAC. Saya dengan cepat memeriksa haknya, semuanya standar - pengguna biasa tidak dapat menulis ke “C: \ Program Files”. Sedikit penelitian lebih lanjut dan saya menemukan bahwa permainan itu tidak "ditentukan" oleh klien Origin itu sendiri, tetapi oleh Origin Client Service-nya.
Saya mulai membuat asumsi tentang bagaimana klien mengirimkan informasi ke layanan untuk memeriksa apakah sesuatu dapat dieksploitasi.
Metode pengiriman informasi ternyata sederhana - sebuah pipa bernama. Saya belajar tentang ini dari log instalasi - dalam teks biasa ditunjukkan bahwa pipa OriginClientService menerima perintah untuk bekerja dengan file dan folder.
Membuka IDA, mengunggah klien di sana.
* pekerjaan yang dilakukan di IDA: 1 *Cukup cepat, saya menemukan bahwa perintah dikirim ke pipa secara umum dalam bentuk teks. Di dekatnya saya menemukan daftar perintah dan, tanpa basa-basi lagi, mengirim perintah dengan jenis "salin" C: \ test \ payload.dll "" C: \ Windows \ pwn.dll "ke pipa. Untuk mengantisipasi hasil cepat, saya memeriksa folder "C: \ Windows" dan tidak menemukan yang baru di dalamnya. Tetapi ada sesuatu yang baru di log - beberapa kata tentang fakta bahwa klien di pipa tidak lulus verifikasi tanda tangan digital.
Membuka IDA, mengunggah layanan di sana.
* pekerjaan dilakukan di IDA: 2 *Saya menemukan bahwa tim tidak diharapkan dari siapa pun. Saat menghubungkan ke pipa, layanan akan memeriksa siapa yang terhubung. Proses pid diekstraksi dari koneksi, jalur ke file yang dapat dieksekusi diekstraksi dari pid, tanda tangan diperiksa kebenarannya dan dikeluarkan oleh EA.
Kedengarannya seperti suara, tetapi tidak cukup. Anda dapat mengambil "Origin.exe" hukum (file yang dapat dieksekusi klien), salin di suatu tempat di folder Anda. Tempatkan dll dari daftar impor "Origin.exe" di folder ini. Misalnya, version.dll muncul. Saya menyebut pendekatan ini "reverse dll injection": dalam injeksi dll reguler, kami menyalin dll ke file exe, tetapi sekarang kami telah melakukan yang sebaliknya. Saya dengan cepat menulis dll proxy untuk version.dll, menambahkan kode dengan mengirim perintah ke pipa. Muatan masih belum disalin. Kita membaca log - "apa artinya, perintah tidak dapat didekripsi!?". Saya melewatkan enkripsi.
Membuka IDA, mengunggah klien di sana.
* karya yang dilakukan di IDA: 3, bypass tanda tangan: 1 *Karena klien mengirim perintah terenkripsi dalam pekerjaannya yang biasa, maka saya bisa. Di sana saya melihat, kemudian saya melihat, hasilnya adalah ini: Enkripsi AES, menginisialisasi vektor konstan, kuncinya dibaca dari file. Kami praktis menyalin bagian ini dan IDA ke dalam kode, kompilasi, periksa. Lagi-lagi tidak ada. Tetapi log sekali lagi memberikan informasi yang berguna - Anda tidak dapat menentukan File Program sebagai jalur target.
Membuka IDA, mengunggah layanan di sana.
* pekerjaan dilakukan di IDA: 4, bypass tanda tangan: 1, bypass enkripsi: 1 *Jadi, memang benar bahwa ada pemeriksaan untuk mendapatkan perintah yang ternyata file tidak dapat disalin di mana-mana. Dan jalur dengan "\ .. \" tidak dapat ditulis. Kami melihat apa tim lain.
Bekerja dengan registri - sekali lagi ada banyak batasan. Tetapi meluncurkan file terlihat menarik. Setidaknya cek tidak terlalu terlihat. Edit kode, kirim perintah “ExecuteProcess“ C: \ test \ payload.exe ””. Anda mengerti ... Tidak ada.
Log lagi berbicara tentang tanda tangan. Oh, kami sudah memenangkannya. Kami menunjukkan dalam kode yang kami sebut Origin.exe yang kami salin untuk memuat dll proxy kami lagi, tetapi dengan hak sistem. Tambahkan cek dan luncurkan konsol. Kami mulai dan konsol dengan hak AUTHORITY NT \ SYSTEM muncul - akhirnya semuanya bekerja.
* pekerjaan yang dilakukan dalam IDA: 4, bypass tanda tangan: 2, bypass enkripsi: 1 *Jadi, Anda perlu mem-boot ulang, menjalankan putaran terakhir, dan masih mengagumi konsol dengan hak maksimal. Mulai ulang, periksa, dan ... tidak ada. Bagaimana bisa begitu? Itu hanya berhasil.
Diagnostik menunjukkan bahwa Layanan Klien Asal belum dimulai, jadi saya memulainya. Tapi itu tidak dimulai. Lebih tepatnya, itu dimulai, tetapi segera ditutup. Saya memulai klien Asal dan layanan dimulai secara normal. Setelah itu, exploit bekerja dengan benar lagi. Mungkin saja untuk berhenti di sana, tetapi ini bukan cara saya - saya ingin memanfaatkan sepenuhnya.
Membuka IDA, mengunggah layanan di sana.
* pekerjaan dilakukan di IDA: 5, tanda tangan bypass: 2, enkripsi bypass: 1 *Ternyata saat startup memeriksa parameter apa layanan dimulai. Tidak ada yang langsung menarik di sana. Base64 dari pid terenkripsi dari proses yang file-nya diverifikasi oleh tanda tangan. Kedengarannya rumit, tapi kami sudah melewati enkripsi, dan tanda tangan juga. Kami sedang menulis beberapa kode dan exploit penuh sudah siap.
Total
Eksploitasi bekerja. Pekerjaan itu dilakukan di IDA: 5 kali, tanda tangan bypass: 3 kali, bypass enkripsi: 2 kali.
Kesimpulan
Kerentanan tetap: pengembang dari EA memperkenalkan mode operasi terbatas khusus untuk klien, yang menetapkan batasan serius untuk bekerja dengan folder dan pipa Asal.
Kerentanan garis waktu:
1 April 2019 : melaporkan laporan kerentanan dengan pipa;
7 April 2019 : mengirim laporan kerentanan dengan folder arbitrer;
... SURAT SANGAT BANYAK (Saya menghitung 40) ...
10 Desember 2019 : pengungkapan yang disepakati.
Terima kasih atas perhatian Anda, saya berharap Anda agen keamanan yang sama.
Artikel ini dalam bahasa Inggris.