ThinkPHP6.0.13 Analisis Kerentanan Penyahserialisasian

Saya terbiar sedikit baru-baru ini, dan saya berasa tidak selesa jika saya tidak menemui sesuatu untuk dilakukan. Saya bercadang untuk mencari beberapa kelemahan untuk dianalisis, jadi saya bercadang untuk melihat beberapa kelemahan dalam TP. 0.13 ialah versi terkini TP Pada bulan Ogos, seorang induk menyerahkan satu Isu menunjukkan bahawa TP mempunyai masalah penyahserialisasian Beberapa pakar di Internet telah menganalisisnya, tetapi terdapat banyak titik putus, dan beberapa kaedah tidak menjelaskan kegunaannya. jadi saya pun cuba menganalisisnya secara terperinci. Di bawah ialah analisis POC

Lihat pertama pada titik permulaan POC

mendapati bahawa titik permulaan adalah kelas psr6cache. atau kaedah __wakeup, ia dispekulasi bahawa ia sepatutnya berada dalam kelas abstrak kelas induknya AbstractCache. Ikuti kelas AbstractCache

seperti yang ditunjukkan dalam rajah, dan berjaya mencari kelas permulaan rantaian penyahserikatan ini. Di sini kita boleh mengawal atribut autosave kepada false untuk memasukkan kaedah simpan.

Kembali ke kelas Psr6Cache untuk melihat kaedah ini

Anda boleh mendapati bahawa kami boleh mengawal kedua-dua atribut pool dan atribut utama. Oleh itu, mungkin terdapat dua laluan untuk memanggil kaedah dengan nama yang sama (getItem) kelas yang berbeza. Atau cuba cetuskan kaedah __panggilan secara langsung. Mari kita lihat cara pengarang POC membenarkan penyahserikatan diteruskan.

Pengarang lulus dalam exp menggunakan kaedah pembina, dan exp sebenarnya membuat instantiated kelas Saluran. Kami memasuki kelas Saluran untuk melihat

Terdapat kaedah __panggilan dalam kelas Saluran, jadi pengarang memilih untuk mencetuskan __panggilan untuk meneruskan rantaian. Kaedah panggilan ini menerima dua parameter Kaedah ini berkod keras (getItem), dan parameter boleh dikawal (iaitu, atribut utama yang boleh dikawal sebelum ini)

Ikuti log Lihat kaedah. Ia menerima tiga parameter (tetapi ia sebenarnya tidak berguna untuk rantaian berikutnya) Lulus dalam kaedah rekod

diikuti dengan kaedah rekod

Kemudian kembali dan semak POC pengarang dan mendapati bahawa atribut malas kawalannya adalah palsu, biarkan fungsi memasuki cawangan if terakhir untuk melaksanakan kaedah simpan

Kemudian Kaedah simpan harus menjadi kaedah yang lebih kritikal Mengikuti kaedah simpan, terdapat tiga perkara yang boleh dieksploitasikan.

Menurut POC, tidak sukar untuk mendapati bahawa pengarang memilih untuk mengawal atribut logger dan menggunakan pembina untuk memberikan nilai kepadanya, menjadikannya objek daripada kelas Socket

Dalam kelas ini kita dapati kaedah kompleks dengan nama yang sama dengan bilangan operasi yang besar.

Mari teruskan melihat cara pengarang membinanya. Tatasusunan mempunyai kandungan berikut

Kuncinya terletak pada dua nilai kunci ini Pengarang mengawal konfigurasi dan membenarkan atur cara berjalan ke cawangan yang memanggil kaedah panggilan

Pada masa yang sama, atribut aplikasi boleh dikawal Pengarang menjadikan atribut aplikasi sebagai objek kelas Aplikasi Kami memasuki kelas Aplikasi

Di sini kita mula-mula melihat kewujudan kelas App Dalam kes kaedah, kaedah ini ditemui dalam kelas induknya

Berterusan, berikut ialah satu-satunya operasi yang dilakukan pada kelas Apl, yang mengawal nilai atribut kejadian. Tujuan mengawal nilainya di sini adalah untuk memasuki kelas Permintaan dan melaksanakan kaedah url

Pengarang membuat satu-satunya manipulasi Minta kelas di sini, Ia adalah untuk mengawal nilai atribut url. Ia boleh dilihat bahawa jika atribut url wujud, maka cawangan pertama akan dimasukkan, dan nilainya adalah sama dengan dirinya sendiri.

Pada masa yang sama, kami mendapati bahawa nilai lengkap yang kami masukkan sebelum ini adalah benar. Oleh itu, hasil akhir yang dikembalikan ialah $this->domain().$url Kami telah mengawal url tersebut, jadi apakah kaedah domain yang dikembalikan?

OK, kita tidak perlu melihat perkara ini. Selepas menganalisis begitu banyak, kami mendapat nilai akhir $currentUri, iaitu:

http://localhost/

currentUri diluluskan sebagai tatasusunan Dipanggil, mengikut panjang rantai, mencapai panggilan, perjalanan penyahserikatan kami hampir tamat

Lihat panggilan, kelas Apl tidak dapat mencari kaedah ini, di dalamnya Kaedah ini ditemui dalam kelas induk

yang boleh dilihat di sini. Terdapat tiga cabang dalam fungsi ini, jadi ke mana ia akhirnya akan pergi? Menurut apa yang kami luluskan dalam $config['format_head'] sebelum ini, pertama sekali, objek yang kami lalui bukanlah contoh atau subkelas Penutupan, dan ia tidak memenuhi syarat cawangan kedua

Jadi masuk cawangan ketiga. Kami membuat susulan kaedah invokeMethod(). $callabel yang diluluskan di sini ialah [new thinkviewdriverPhp,'display'] dan $vars ialah ['http://localhost/']

Perhatikan bahawa kami lulus dalam Kaedah $ ialah tatasusunan, jadi cawangan pertama dimasukkan. Berikan thinkviewdriverPhp baharu (iaitu objek) kepada $class, dan 'display' (iaitu nama kaedah) kepada $method baharu.

Kemudian penghakiman dibuat di bawah Jika $class ialah objek, maka nilainya adalah dirinya sendiri Kerana kita lulus dalam objek, tiada perubahan di sini. Kemudian masukkan kod paling kritikal

dan anda boleh melihat objek new thinkviewdriverPhp dan paparan kaedah dihantar ke ReflectionMethod.

Pada akhirnya, panggil kaedah invokeArgs, masukkan objek thinkviewdriverPhp baharu dan hantarkan $args

Jadi apakah itu args?

Selepas membuat susulan, kami mendapati ia adalah fungsi pemprosesan Kerana saya malas dan hampir selesai analisis pada ketika ini, saya tidak akan membacanya dengan keras dan memberi kesimpulan secara langsung. Bahagian utama $vars yang kami luluskan, iaitu, ['http://localhost/'] dikekalkan dan dimasukkan ke dalam parameter seterusnya

Melihat lebih jauh, fungsi ini (invokeArgs) boleh dibandingkan dengan call_user_func(), jadi kod kunci terakhir sebenarnya hanyalah dua baris ini

, iaitu,

$reflect = new ReflectionMethod(new \think\view\driver\Php,’display’);
return $reflect->invokeArgs(new \think\view\driver\Php,’ ’)

Rakan-rakan yang sering menonton tp deserialisasi akan tahu bahawa ia sudah berakhir! Lagipun, kaedah paparan dipanggil. Tetapi apakah sebenarnya operasi memanggil kelas ReflectionMethod di atas? Kita boleh menunjukkan ini dengan bantuan contoh berikut. Jadi perkara ini sangat serupa dengan call_user_func

Akhir sekali, terdapat kaedah paparan Tidak banyak yang perlu diperkatakan perintah

Kesimpulan

Rantai TP adalah sama menarik (dan rumit) seperti biasa, terutamanya penggunaan kelas ReflectionMethod yang terakhir Jika anda tidak memahami kelas ini dan gabungan kaedah dalam kelas boleh mencapai fungsi yang serupa dengan fungsi call_user_func, maka. ia adalah mudah untuk terlepas ini.

[Cadangan tutorial berkaitan: rangka kerja thinkphp]

Atas ialah kandungan terperinci ThinkPHP6.0.13 Analisis Kerentanan Penyahserialisasian. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!