Analisis contoh penggunaan kelemahan JIRA untuk mengakses rangkaian penghala Internet Protokol tidak terklasifikasi tentera AS

Berikut menerangkan penyertaan pengarang dalam Jabatan Pertahanan A.S. (DoD) Menggodam projek ujian awam kerentanan Pentagon, menggunakan kelemahan JIRA CVE-2017-9506 untuk membina permukaan serangan SSRF dan mencapai penghala protokol Internet yang tidak dikelaskan untuk akses ketenteraan A.S. (NIPRnet), dan digabungkan dengan teknik kerentanan lain, memperoleh satu siri maklumat sensitif sistem intranet DoD. Disebabkan sifat sulit proses dan kandungan ujian, artikel ini hanya menyentuh perkara ini tanpa mendedahkan terlalu banyak butiran teknikal dan senario terperinci Ia hanya untuk pembelajaran dan perkongsian, dan saya harap pembaca akan bersabar dengan saya.

JIRA ialah alat perisian pengesanan dan pengurusan yang sangat baik yang dibangunkan oleh Syarikat Atlassian di Australia Ia boleh menjejak dan mengurus pelbagai jenis isu, termasuk kecacatan, tugasan, keperluan, penambahbaikan, dsb. Banyak syarikat terkenal dan organisasi perisian sumber terbuka menggunakan JIRA kerana ia menggunakan teknologi J2EE dan boleh digunakan merentas platform.

Bermula dari awal - Menemui laman web aplikasi JIRA DoD

Semasa menyertai projek ujian awam kerentanan Jabatan Pertahanan (DoD) AS, saya mendapati terdapat dua laman web khas yang digunakan penjejakan projek Selepas analisis awal alat pengurusan JIRA, saya percaya bahawa tidak ada kelemahan yang boleh dieksploitasi, jadi saya tidak terus menggali lebih mendalam.

Kemudian, saya menemui siaran di Twitter yang mengeksploitasi kelemahan JIRA untuk melaksanakan serangan SSRF:

Ini bermakna ini:

Hati-hati, pengguna JIRA! Penyerang boleh mengeksploitasi kerentanan JIRA CVE-2017-9506 untuk mencuri data intranet anda. Ini adalah kelemahan ubah hala terbuka, tetapi dalam beberapa kes, ia boleh dieksploitasi untuk mengubah hala ke alamat pautan tempatan sistem JIRA dalaman, yang membawa kepada pendedahan maklumat sumber dalaman tertentu seperti kunci AWS.

Kerentanan JIRA CVE-2017-9506 penerangan

Organisasi penyelidikan keselamatan Belanda Dontpanic memberikan anggaran punca CVE-2017-9506: JIRA mengandungi Terdapat komponen yang dipanggil IconUriServlet dalam pemalam pengesahan dan kebenaran Atlassian OAuth, yang digunakan untuk menerima permintaan GET dengan nilai parameter consumerUri daripada klien, tetapi komponen IconUriServlet juga boleh digunakan untuk membuat permintaan HTTP GET lain yang dilaksanakan oleh pelayan Ini jenis permintaan yang dimulakan oleh JIRA sebagai proksi tidak langsung dijawab oleh pelayan dan kemudian dikembalikan kepada klien melalui JIRA Semasa proses ini, dengan membina permintaan, maklumat dalaman pelayan boleh dibocorkan dan dikembalikan kepada klien dalam. kandungan respons.

Kaedah pengesahan kerentanan diberikan oleh Dontpanic:

https://%basepath%/plugins/servlet/oauth/users/icon-uri?consumerUri=https://google . com

Ganti basepath dengan pautan laman web sistem JIRA Selepas mengakses halaman di atas, jika halaman google.com muncul secara normal, ia membuktikan bahawa kelemahan itu wujud dalam sistem JIRA jika halaman 404 muncul apabila mengakses, kelemahan itu tidak wujud. Ambil perhatian bahawa anda menambah permintaan untuk tapak web yang anda ingin uji pada penghujung consumerUri! ! !

Menguji kelemahan laman web aplikasi JIRA DoD

Setelah membaca dengan teliti penerangan CVE-2017-9506, saya rasa seperti telah menjumpai harta karun dan segera beralih ke dua Jabatan Pertahanan laman web yang saya temui sebelum ini, ingin mengesahkan kebolehlaksanaan teknologi eksploitasi kerentanan ini. Selepas menguji salah satu laman web, saya mendapati bahawa saya berjaya melompat ke halaman Google, yang bermaksud mesti ada kelemahan dalam laman web!

https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://google.com

Mengikut peraturan AWS, mana-mana kejadian boleh mendapatkan semula contoh metadata contoh sendiri dengan meminta alamat metadata 169.254.169.254 yang ditetapkan oleh AWS (untuk kaedah berkaitan, sila rujuk arahan rasmi AWS). Untuk tujuan ini, saya membina pautan berikut untuk memulakan permintaan:

https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http: //169.254. 169.254/latest/meta-data/local-hostname/

Sebenarnya boleh melihat nama hos dalaman! Okay, biar saya cuba dapatkan kunci AWS:

https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http:/ /169.254.169.254/ latest/meta-data/iam/security-credential

Tetapi ia nampaknya tidak berkesan. Selepas membaca dokumentasi rasmi AWS dengan teliti, saya menggunakan semula pautan berikut untuk mendapatkan ID contoh, alamat IP peribadi dan maklumat lain:

https://website.mil/plugins/servlet/oauth/users / icon-uri?consumerUri=http://169.254.169.254/latest/dynamic/instance-identity/document

Sangat bagus, semuanya berjaya menjawab!

Pada ketika ini, saya fikir ia sepatutnya dapat menjelaskan masalah itu, jadi saya hanya menulis laporan kelemahan dan menyerahkannya tanpa ujian lanjut Walau bagaimanapun, selepas itu, kakitangan klasifikasi projek DoD mengklasifikasikan kerentanan itu sebagai risiko sederhana kelemahan, tetapi saya fikir ini pastinya merupakan kelemahan berisiko tinggi yang serius. Selepas bercakap dengan Jabatan Pertahanan, saya meminta kebenaran untuk ujian mendalam untuk menguji kesan muktamad kerentanan itu.

Ujian mendalam - mencapai akses kepada Rangkaian Penghala Protokol Internet Tidak Sulit (NIPRnet) dan mendapatkan maklumat sensitif lain

Penemuan peninjauan awal

Mula-mula, saya mulakan dengan pengesanan port asas dan mendapati sistem sasaran telah membuka port 21, 22, 80, 443, dan 8080. Dengan maklumat port ini, saya boleh menguji pengembalian pelbagai mesej ralat dan menilai sasaran melalui maklumat ini, penempatan pelayan dan rangkaian dalam sistem, seperti yang ditunjukkan di bawah, maklumat tindak balas selepas permintaan ke port sistem sasaran 8080:

Kedua, saya menyemak protokol dan kamus DICT dalam direktori fail gopher Protokol pelayan, protokol FTP, protokol akses direktori ringan LDAP dan protokol lain telah diuji untuk permintaan. Contohnya, sistem mengembalikan respons berikut yang tidak menyokong LDAP:

Penemuan penggunaan komprehensif

Semasa merekod maklumat ini, saya terfikir untuk PortSwigger sekali lagi Ketua penyelidik James Kettle berkongsi penyelidikannya "Cracking the Lens: Targeting HTTP's Hidden Attack-Surface" pada Persidangan Black Hat 2017 Amerika Syarikat James Kettle membina permintaan HTTP berniat jahat dan maklumat pengepala Pengepala untuk menggariskan penyembunyian perkhidmatan HTTP dalam sistem sasaran. . Permukaan serangan, pada akhirnya, dia menggunakan teknologi ini untuk 'menyamar' sebagai identiti IP dalaman Jabatan Pertahanan AS, dan berjaya menceroboh dan mengakses sistem rangkaian dalaman terhad DoD dan sumber berkaitan. Saya masih ingat bahawa dalam perkongsian Kettle, dia juga menunjukkan dua laman web dalaman DoD yang telah digunakannya untuk ujian pencerobohan: (Sumber maklumat laman web defensivecarry.com)

https://safe.amrdec .army.mil /safe/

https://dots.dodiis.mil/

Menggabungkan dua tapak web dalaman DoD yang disebut oleh James Kettle ini, gunakan saya menjumpai dua tapak web DoD JIRA dan memulakan permintaan kepada mereka Tujuannya adalah untuk menguji sama ada akses kepada dua tapak web dalaman DoD yang disebutkan oleh James Kettle boleh dicapai dengan cara ini. Akhirnya, selepas saya menggunakan salah satu tapak JIRA untuk membuat permintaan kepada dua tapak dalaman DoD yang disebut oleh James Kettle, salah seorang daripada mereka menunjukkan permintaan itu tamat masa:

The maklumat amaran kerajaan AS (USG) lain yang dikembalikan, seperti berikut:

Semasa proses ujian ini, saya juga menemui perkhidmatan web dalaman DoD yang lain Melalui perkhidmatan web dalaman ini, I sebenarnya Ia berjaya mengakses Rangkaian Penghalaan Protokol Tidak Sulit (NIPRnet) tentera AS, yang digunakan secara dalaman oleh DoD untuk mengendalikan maklumat sensitif yang lebih rendah daripada tahap terperingkat. Disebabkan prinsip kerahsiaan, saya tidak akan mendedahkan kaedah dan kaedah khusus secara terperinci di sini.

Peroleh maklumat sensitif dalaman dengan menilai kandungan respons

Selepas saya menggunakan tapak web JIRA kedua untuk memulakan permintaan kepada dua tapak web dalaman DoD yang disebut oleh James Kettle, maklumat respons dikembalikan pada asasnya Tiada apa yang boleh ditawarkan.

Selepas ujian, akhirnya saya mendapati bahawa pembukaan port sistem dalaman DoD boleh dinilai berdasarkan masa tindak balas. Contohnya, apabila meminta port 22 daripada sistem dalaman, respons mengambil masa 1,000 milisaat, manakala apabila meminta port 21, respons mengambil masa hampir 10,000 milisaat Dari perbezaan masa ini, beberapa keadaan port boleh diagak. Di samping itu, disebabkan kekurangan respons mesej ralat yang terperinci, saya tidak dapat membuat pertimbangan mengenai protokol tertentu dalam sistem, tetapi saya ingin menekankan bahawa fokus artikel ini ialah: melalui pelayan web dalaman, saya boleh mengakses DoD's penghalaan protokol tidak sulit Bersih (NIPRnet)! Saya juga menggunakan plug-in Burp's Collaborator untuk mengesan kebocoran maklumat dalam pertukaran data antara pelayan dan peminta selepas permintaan kepada pelayan web dimulakan.

Sebagai contoh, IP dalaman boleh diperolehi daripada 'X-Forwarded-For' dalam pengepala permintaan saya menggunakan pemalam Kolaborator Burp untuk menanyakan semua IP dalaman yang interaktif, walaupun saya dapat menanyakan. IP dalaman dan maklumat perkhidmatan Rangkaian yang berkaitan, tetapi pengambilan metadata AWS tidak boleh dicapai pada pelayan web.

Akhirnya, selepas saya menyerahkan dua kelemahan yang terlibat kepada DoD, kedua-dua kelemahan itu dinilai sebagai kritikal, saya memikirkan dua kelemahan SSRF yang saya laporkan kepada DoD pada awal tahun ini untuk melihat sama ada kelemahan di atas boleh dieksploitasi secara mendalam menggunakan kaedah SSRF ini.

Penggunaan JIRA SSRF secara mendalam

Dua kelemahan SSRF yang saya laporkan pada awal tahun ialah penapis aplikasi web tertentu boleh digunakan untuk memulakan permintaan sambungan HTTP ke alamat IP tertentu, contohnya, dengan menyerahkan permintaan CONNECT IP , untuk menghitung perkhidmatan aplikasi dalam sistem sasaran, ia juga boleh memulakan maklumat permintaan yang disahkan kepada IP dalaman atau IP luaran sistem sasaran dengan menukar maklumat pengepala hos, seperti. sebagai militarywebsite.mil@internal_IP. Apabila saya menguji kaedah SSRF ini pada dua tapak web JIRA ini, saya mendapati bahawa dalam persekitaran permintaan yang sebelum ini mendorong tamat masa, ralat SSL dan respons lain, kaedah Blind SSRF juga boleh digunakan untuk menghitung IP dalaman dan perkhidmatan rangkaian. Oleh itu, eksploitasi kerentanan SSRF pada ketika ini akhirnya dinilai sebagai risiko sederhana oleh DoD.

Teknik lain untuk mengeksploitasi kelemahan JIRA SSRF

Semasa ujian menyeluruh saya terhadap kelemahan di atas, saya mendapati bahawa dalam beberapa kes, ralat tindanan akan berlaku secara tidak dapat diterangkan dan membocorkan pelbagai maklumat sensitif, contohnya,. menggunakan maklumat pengepala HTTP yang tidak lengkap http:// atau http://[::]. Maklumat sensitif bocor semasa ralat tindanan ini termasuk IP pangkalan data, versi pangkalan data, pemalam aplikasi, seni bina sistem pengendalian dan sistem lain:

Apabila ralat tindanan berlaku, anda masih boleh terus mendapatkan maklumat mendalam daripada tapak web sasaran Contohnya, saya mendapati kadangkala tapak web sasaran akan menghala ke contoh Altassian yang lain, seperti masa tertentu Semasa ujian, saya mendapati bahawa kejadian pertemuan Altassian telah digunakan dalam nama subdomain tapak sasaran Ujian membuktikan bahawa kejadian ini juga dipengaruhi oleh kerentanan kebocoran maklumat.

Ringkasan dan ulasan

Pengarang menerangkan kelemahan JIRA yang ditemui semasa mengambil bahagian dalam projek ujian awam kerentanan Jabatan Pertahanan A.S. dan secara ringkas memperkenalkan keseluruhan proses ujian eksploitasi kerentanan. Mari kita selesaikan bersama-sama :

1 Dua daripada tapak web DoD yang digunakan dengan kejadian JIRA mempunyai kerentanan pemalam keizinan CVE-2017-9506 Penyerang boleh menggunakan kerentanan ini untuk mendapatkan maklumat sumber dalaman sistem tapak web sasaran dan membentuk permukaan serangan SSRF ;

2 Digabungkan dengan kaedah eksploitasi CVE-2017-9506, saya memperoleh ID contoh JIRA, alamat IP peribadi, satu siri respons ralat dan maklumat lain daripada tapak web DoD yang terdedah;

3 Ketua penyelidik PortSwigger Komprehensif James Kettle berkongsi dua tapak web DoD yang disebutkan Menggunakan kaedah permintaan CVE-2017-9506, didapati tapak web DoD yang diminta mengembalikan maklumat USG (Amaran Kerajaan) yang sah

4 dalam langkah 3 proses , saya mencapai akses kepada Rangkaian Penghalaan Protokol Bukan Kerahsiaan DoD (NIPRnet) melalui perkhidmatan web dalaman yang saya temui, digabungkan dengan kaedah eksploitasi CVE-2017-9506; >5 digabungkan dengan eksploitasi CVE-2017-9506 Kaedah ini menghasilkan semula serangan SSRF pada tapak web DoD yang terdedah, melaksanakan IP dalaman dan penghitungan perkhidmatan rangkaian, dan memperoleh maklumat sensitif sekiranya berlaku ralat tindanan berikutnya.

Atas ialah kandungan terperinci Analisis contoh penggunaan kelemahan JIRA untuk mengakses rangkaian penghala Internet Protokol tidak terklasifikasi tentera AS. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!