Di seri sebelumnya
Belum lama ini, saya berbicara tentang dua kerentanan Steam:
CVE-2019-14743 dan
CVE-2019-15316 . Ada keseluruhan cerita tentang bagaimana saya mencoba mendaftarkan mereka, saya tidak berhasil, saya dilarang, dan hanya setelah pengungkapan publik dan bantuan dari komunitas saya berhasil mencapai hasil. Valve berpura-pura meminta maaf dan membatalkan panggilan saya di HackerOne, jadi saya memutuskan untuk mentransfer kerentanan berikutnya melalui layanan ini. Ketiga kalinya (
harus ada lelucon yang jelas tentang Half-Life 3 ), semuanya berjalan kurang lebih sukses.
Deskripsi Kerentanan
Kerentanan ini memungkinkan Anda untuk membuat file dengan konten yang dikendalikan sebagian (atau menambahkan konten yang dikendalikan sebagian ke file yang ada). Versi layanan rentan adalah 5.31.28.21 (data dari file SteamService.exe). Pertama, saya akan menjelaskan bagaimana cara mengeksploitasi kerentanan, dan kemudian saya akan menjelaskan konsekuensi yang mungkin terjadi.
Langkah 1. Lingkungan
Anda harus menghentikan aplikasi Steam dan menghentikan Layanan Steam Client jika sedang berjalan. Paling sering, pengguna tanpa hak administrator tidak dapat memulai dan menghentikan layanan apa pun. Namun khusus untuk layanan ini, Valve menetapkan hak yang memungkinkan semua pengguna untuk berhenti dan memulainya.
Buat folder di tempat mana pun yang dapat diakses pengguna (misalnya, "C: \ test"). Di folder ini, Anda perlu menyalin file Steam.exe dan steamclient.dll dari folder sumber Steam (secara default, ini adalah "C: \ Program Files (x86) \ Steam"). Buat subfolder log kosong ("C: \ test \ logs").
Sekarang mari kita perbaiki registri: di cabang "HKLM \ Software \ wow6432node \ valve \ steam", ubah nilai parameter "InstallPath" menjadi "C: \ test \ 1 \ ..". Biasanya, untuk pengguna non-administrator, cabang registri di dalam HKLM tidak dapat ditulisi, tetapi tidak dalam hal ini. Saat memasang Valve, mereka menetapkan hak tersebut untuk cabang mereka di dalam HKLM sehingga di dalamnya semua tindakan tersedia untuk semua pengguna ("Kontrol penuh" untuk grup "Pengguna").
Langkah 2. Mari kita lakukan tes kecil
Luncurkan Layanan Klien Steam. Setelah berhenti (ini akan terjadi secara otomatis setelah beberapa detik), periksa isi folder “C: \ test \ logs” - kami menemukan file “service_log.txt” di sana. Isi log akan seperti ini:
08/27/19 13:45:01 : ERROR: SteamService: Invalid file signature C:\test\1\..\bin\SteamService.dll
Perhatikan bahwa jalur "C: \ test \ 1 \ .." sama dengan jalur "C: \ test", jadi Windows menggunakan yang kedua untuk bekerja, dan yang pertama masuk ke pesan. Hapus file "service_log.txt" dan lanjutkan.
Langkah 3. Tambahkan lebih banyak teks.
Fakta menarik: ketika Windows bekerja dengan jalur yang berisi "\ ..", secara otomatis menyederhanakan jalur tersebut. Tidak melakukan pemeriksaan untuk pementasan folder.
Misalnya, jalur "C: \ 1 \ <test> \ .." akan dikonversi menjadi "C: \ 1" meskipun faktanya kurung sudut tidak dapat digunakan dalam nama folder.
Pada langkah pertama, kami mendaftarkan path di registri, sekarang kami akan menambahkan jeda baris untuk itu. Ini dapat dilakukan dengan menulis kode sederhana, tetapi dapat dilakukan dari antarmuka regedit juga. Cukup buka cabang registri "HKLM \ Software \ wow6432node \ valve \ steam" dan pilih "Ubah data biner .." di menu konteks parameter "InstallPath". Sesuatu seperti hex editor akan muncul di mana Anda dapat melakukan pengeditan yang diperlukan.
Kami akan melakukan uji peluncuran layanan lainnya dan memeriksa hasil tindakan kami.
Setelah tes, Anda harus kembali menghapus file "service_log.txt".
Langkah 4. Arahkan ulang file yang dibuat
Pengguna tanpa hak administrator tidak dapat membuat tautan simbolik dari satu file ke file lainnya. Tetapi ada fokus - Anda dapat menggabungkan jenis tautan lain yang tersedia untuk pengguna tanpa hak administrator untuk mendapatkan efek yang dekat dengan symlink dari file ke file.
Pertama, buat titik reparasi NTFS (nama lain untuk titik mount NTFS) dari folder "C: \ test \ logs" hingga "\ RPC Control \". "\ RPC Control \" bukan folder biasa dalam arti biasa, itu tidak dapat dilihat, misalnya, di explorer. Ini adalah direktori objek sistem, di dalamnya ada, misalnya, yang bernama mutex, events, dan objek serupa lainnya. Mengapa pengalihan melalui titik reparasi NTFS bekerja untuknya tidak jelas, kemungkinan besar, intinya adalah untuk menggunakan abstraksi yang sama untuk folder dalam sistem file dan direktori objek. Dari direktori objek, Anda dapat membuat symlink ke file tanpa hak administrator. Buat symlink dari formulir "\ RPC Control \ service_log.txt" <-> "C: \ Path \ to \ file".
Akibatnya, semua panggilan ke "C: \ test \ logs \ service_log.txt" akan dialihkan ke file "C: \ Path \ to \ file". Untuk membuat pengalihan seperti itu ada dua persyaratan dasar - folder dari mana titik reparasi NTFS harus kosong, dan itu juga harus bisa ditulisi oleh pengguna. Untuk memenuhi kondisi pertama, setelah setiap pengujian kami menghapus file "service_logs.txt", kondisi kedua dipastikan oleh fakta bahwa kami membuat folder sumber di tempat yang dikontrol pengguna.
Ada utilitas khusus yang membuat pasangan symlink - CreateSymlink dan tersedia untuk diunduh di
GitHub . Penggunaan Utilitas:
CreateSymlink.exe <> <>
Dalam kasus kami, itu akan menjadi:
CreateSymlink.exe "C:\test\logs\service_log.txt" "C:\\\"
Menyatukan semuanya, kita dapatkan bahwa ketika Layanan Klien Steam dimulai, sebuah file akan dibuat di sepanjang jalur yang ditentukan saat membuat symlink, dan file ini akan berisi konten yang dapat kita kontrol (baik, kecuali untuk baris pertama dan terakhir). Jika kita menentukan jalur ke file yang ada, konten akan ditambahkan ke akhir file. Semua ini akan dilakukan atas nama Layanan Klien Steam dengan hak istimewa NT AUTHORITY \ SYSTEM.
Dampak
Sekarang saya akan daftar efek yang mungkin dari yang paling penting dan naik.
- Dos
Jika tujuan symlink adalah untuk mengatur "C: \ Windows \ System32 \ config \ SAM" atau "C: \ Windows \ System32 \ config \ SECURITY", maka tidak mungkin bahwa OS akan dapat boot setelah reboot. - Pengalihan pengguna di Internet
Tetapkan tujuan symlink "C: \ Windows \ system32 \ drivers \ etc \ hosts" dan tambahkan baris seperti "127.0.0.1 google.com" di sana.
Hasil:
- EoP Horisontal
Peningkatan horizontal dalam hak istimewa adalah perubahan dalam hak di mana kami mendapatkan akses bukan pada hak yang lebih tinggi, tetapi pada hak dengan tingkat yang sama, tetapi relatif terhadap objek lain, misalnya, dengan hak pengguna lain.
Tetapkan tujuan symlink "C: \ ProgramData \ Microsoft \ Windows \ Start Menu \ Program \ StartUp \ run.bat" dan tambahkan baris seperti "start C: \ test \ 1.exe" di sana.
Semua file dari folder C: \ ProgramData \ Microsoft \ Windows \ Start Menu \ Program \ StartUp dijalankan oleh pengguna saat mereka masuk. Dengan demikian, satu pengguna dapat memaksa pengguna lain untuk menjalankan kode. Dari file bat, semua baris akan dieksekusi secara bergantian. Yang pertama dan terakhir tidak akan melakukan apa pun, tetapi perintah yang diterapkan "mulai C: \ test \ 1.exe" akan bekerja.
Dengan diperkenalkannya perintah seperti itu, ada satu kehalusan - karakter "\" akan diperhitungkan selama normalisasi path, jadi untuk operasi yang benar perlu menambahkan beberapa "\ .." ke path dalam registri. - EoP vertikal
Eskalasi hak istimewa vertikal adalah eskalasi biasa, misalnya, dari pengguna tanpa hak administrator ke NT AUTHORITY \ SYSTEM.
Cukup sering Anda dapat menemukan perangkat lunak yang mengeksekusi skrip teks dengan hak tinggi. Kami dapat menambahkan perintah ke skrip tersebut dan menjalankan kode kami dengan izin tinggi. Saya tidak menemukan skrip seperti itu di OS yang bersih, jadi Anda tidak bisa mendemonstrasikan eksploit semacam itu. Tapi sebagai contoh, saya bisa menentukan file bat yang dibuat oleh NVIDIA dan VmWare atau skrip logon untuk OS di domain.
Selain itu, untuk meningkatkan, Anda dapat memeriksa kemampuan untuk membuat file xml, ini-file dengan format yang rusak. Sayangnya, ada terlalu banyak opsi - membuat tugas untuk TaskSheduler, bekerja dengan .manifest dan unduhan perpustakaan lainnya, dan banyak lainnya. Tampak bagi saya bahwa hasil yang dijelaskan di atas sudah cukup untuk memahami hasil dari kerentanan.
Garis waktu
Untuk melengkapi gambar, saya akan memberikan jadwal waktu yang membosankan tentang kerentanan ini.
08/26 - Menemukan kerentanan.
27 Agustus - unban pada h1, menerbitkan sebuah laporan.
12.09 - koreksi telah dirilis .
Kesimpulan
Di sinilah saya menyelesaikan posting penelitian Steam - 3 kerentanan yang ditemukan dengan analisis yang cukup dangkal, ini tidak cukup. Untuk lebih dalam, Anda membutuhkan lebih banyak waktu dan keinginan. Sayangnya, sikap Valve dan ketidakmampuan karyawan HackerOne adalah hambatan yang sangat kuat.
Saya ingin sekali lagi berterima kasih kepada semua pembaca yang membantu membuat Steam lebih aman. Saya berterima kasih kepada Valve karena telah memperbaiki kerentanan dan membantah teori konspirasi saya. Saya berterima kasih kepada HackerOne karena menyediakan platform, meskipun pada kenyataannya mereka pada dasarnya mencegah saya mengkomunikasikan kerentanan kepada Valve.
Artikel ini dalam bahasa Inggris.