Pentest-laboratorium "Pentestit Test lab 12" - bagian penuh

Setiap tahun, Pentestit meluncurkan lab pengujian penetrasi baru, Lab Uji, dan artikel ini akan mencakup lab ke-12, yang disebut "z 9r347 39u411z3r" atau, jika diterjemahkan, "The equalizer hebat".

Koneksi ke laboratorium

Koneksi ke laboratorium adalah melalui koneksi VPN (karena saya melewati laboratorium pada mesin yang menjalankan Linux, maka semua tindakan akan dijelaskan secara khusus untuk platform ini). Untuk masuk ke jaringan pribadi, Anda harus melakukan langkah-langkah berikut:

1. Daftarkan di sini .
2. Simpan file konfigurasi dari sini .
3. Buka pengaturan jaringan dan pilih "tambah VPN".
4. Impor dari file (tentukan file yang diunduh dengan konfigurasi).
5. Tentukan login dan kata sandi untuk koneksi (diberikan pada tab "bagaimana menghubungkan").
6. Kami terhubung ke VPN dan ping gateway 192.168.101.1. Jika ping lewat, berarti Anda telah berhasil terhubung ke laboratorium.

Pencarian target

Kami memiliki akses ke jaringan 192.168.101.X dengan mask 255.255.255.0. Pertama-tama, Anda perlu menemukan "host langsung" di jaringan. Ini dapat dilakukan dengan mudah dengan utilitas nmap:

nmap -sn 192.168.101.0/24 

Jadi kami menemukan tiga host, salah satunya kita sudah tahu (gateway):

1. 192.168.101.1
2. 192.168.101.12
3. 192.168.101.13

Langkah kedua adalah memindai host yang ditemukan untuk port yang terbuka dan tertutup.

 nmap -sV -Pn 192.168.101.12-13 -p- 

Dari laporan itu jelas bahwa 192.168.101.13 tidak tersedia, jadi kami mulai dari 192.168.101.12. Server web berputar pada port 80. Tetapi ketika Anda mencoba mengaksesnya, pengalihan ke site.test.lab terjadi , yang tidak diketahui oleh kami (DNS tidak dikonfigurasikan untuk pengalihan ini). Verifikasi dilakukan dengan menggunakan peramban dan utilitas curl.

 curl http://192.168.101.12:80/ curl http://site.test.lab/ 

Buat entri di file / etc / hosts untuk site.test.lab. Sekarang, kita dengan tenang pergi ke situs.



Langkah pertama adalah mengumpulkan informasi tentang situs tersebut. Yang paling penting adalah mesin situs (CMS - sistem manajemen konten). Untuk melakukan ini, gunakan utilitas wig.

 wig -u http://site.test.lab/ 

Untuk analisis, kami mendapat laporan - Wordpress digunakan. Mari kita uraikan output wig:

1. Entri IP dan judul.
2. Nama, versi, dan jenis perangkat lunak.
3. Halaman-halaman penting.
4. Utilitas yang bisa Anda gunakan.
5. Kemungkinan kerentanan dengan tautan ke CVE.

Untuk memindai CMS WordPress dan, yang lebih penting, plugin yang diinstal (mereka sebagian besar rentan), utilitas wpscan paling cocok.

 wpscan --url http://site.test.lab/ --enumerate p --random-user-agent 

Kami mendapatkan informasi yang kami butuhkan: versi WordPress, kerentanan dan plugin yang diinstal. Faktanya adalah bahwa kerentanan ini tidak akan memberi kami akses yang diinginkan. Sangat berguna untuk menentukan plugin mana yang digunakan. Dalam hal ini, ini adalah "wp-survey-and-poll". Penting untuk dipahami bahwa pemindai hanya boleh digunakan untuk mendapatkan informasi tentang perangkat lunak. Karena tidak ada database kerentanan tunggal, pemindai mungkin tidak menunjukkan semua eksploitasi yang ada. Sebagai hasil pemindaian, kami memiliki:

1. Versi WP: 4.9.8.
2. Dua puluh tujuh belas: ya, v. 1.9
3. Plugin: wp-survey-and-poll v. 1.5.7

Utilitas searchsploit dirancang untuk dengan mudah mencari basis data exploit-db exploit terbesar, yang diunduh dan disimpan ke PC Anda. Untuk versi 4.9.8, tidak ada kerentanan ditemukan dalam database. Jika kami memeriksa plugin, kami akan menemukan dua kerentanan.

 searchsploit "WordPress Survey Poll" 

Pelajari lebih lanjut tentang kerentanan ini. Ini adalah injeksi SQL reguler mengikat dalam cookie. Kami perlu menjawab pertanyaan dan mengganti permintaan kami dengan cookie. Tekniknya sangat sederhana: (ekspresi apa pun) ATAU 1 = 2 akan kembali salah, maka DBMS bukannya menyelesaikan jawaban kami akan menampilkan bagian kedua dari UNION dari permintaan gabungan. Ini semua adalah kolom, salah satunya (No. 10) akan ditampilkan pada halaman. Tetapi operasi dari segmen jaringan ini tidak mungkin, seperti yang kemudian diketahui, karena memblokir WAF.

Token MAIL

Setelah kegagalan di situs, Anda perlu menemukan titik masuk lainnya. Di situs tersebut, Anda dapat menemukan info@test.lab login, yang akan kami gunakan untuk memilih informasi otentikasi. Ayo pergi ke port lain. Web berputar pada 8080, tetapi token CSRF digunakan. Pada 25 smtp, kata sandi yang tidak berfungsi. Kami hanya memiliki port 143 yang tersisa - ini adalah layanan IMAP. Untuk brutus, saya menggunakan alat hydra. Ternyata, kata sandinya sangat sederhana.

 hydra -l info@test.lab -P '/root/rockyou.txt' imap://192.168.101.12 

Karena kami menemukan nama pengguna dan kata sandi untuk surat tersebut, kami masuk ke 192.168.101.12:8080. Sekarang Anda perlu menganalisis semua surat dengan benar. Selain itu, perlu untuk mengumpulkan semua informasi, karena mungkin berguna nanti. Inilah yang saya temukan:

1. Kotak masuk: Konfigurasi VPN.
2. Dalam keluar: Token untuk pengaturan MAIL.
3. Nama pengguna sviridov@test.lab

VPN melalui VPN

Kita perlu memperluas jauh ke jaringan perusahaan. Kami memiliki konfigurasi VPN, tetapi kami tidak dapat memutuskan koneksi dari yang utama. Teknik ini disebut VPN over VPN - ketika kita menghubungkan VPN di dalam VPN di dalam VPN, dll. Untuk VPN, nama pengguna dan kata sandi diperlukan. Kami hanya tahu 2 pengguna (info dan sviridov) dan kata sandi salah satunya. Kami mencoba terhubung menggunakan nama pengguna dan kata sandi yang dikenal, jika tidak berhasil, kami akan bersikap kasar. Untuk menghubungkan, lakukan langkah-langkah berikut:

1. Buat file userVPN.txt, di mana baris pertama adalah nama pengguna dan yang kedua adalah kata sandi.
2. Tambahkan path ke file ini ke konfigurasi VPN di kolom auth-user-pass
3. Anda membuat skrip bash OverVPN.sh dengan konten berikut: openvpn --config configuration_path_to_file_ &
4. Tetapkan haknya: chmod 770 ./OverVPN.sh
5. Jalankan: ./OverVPN.sh

Kami beruntung, info@test.lab pengguna berhasil masuk, dan kami diberitahu bahwa jaringan baru 172.16.0.0/16 tersedia.



Pertama-tama, Anda perlu menemukan "host langsung" di jaringan, seperti yang Anda lakukan terakhir kali:

 nmap -sn 172.16.0.0/16 

Jadi kami menemukan empat host.



Pindai setiap host. Pada 172.16.0.1 tidak ada yang ditemukan. Saya berani berasumsi bahwa ini adalah 192.168.101.13 kita yang sudah lama dikenal di jaringan lain. Melalui dia kita terhubung ke jaringan ini. Pada 172.16.0.10, hanya server Web pada port 80 yang tersedia. Pada 172.16.0.17 kita melihat seluruh "tempat pengujian" untuk pengujian. Pada 172.16.1.2 tidak ada. Kemungkinan besar ini adalah layanan VPN lain.

Token DNS

Karena yang berikutnya dalam daftar token adalah DNS, kami akan mulai menganalisis layanan DNS pada port 172.16.0.17. Kerentanan utama adalah mendapatkan catatan DNS - transfer zona DNS (yang disebut permintaan AXFR). Kami menjalankannya menggunakan utilitas nslookup dan menggali.

Yang pertama mengetahui zona dan nama server yang bertanggung jawab atas zona ini.

 nslookup > set type=ANY > set port=53 > SERVER 172.16.0.17 > test.lab 

Yang kedua akan melakukan transfer.

 dig @172.16.0.17 ns1.test.lab axfr 

Server DNS ini tidak merespons. Tapi dia tahu tentang sisa DNS di jaringan. Utilitas dnsrecon memungkinkan Anda untuk benar-benar melakukan operasi apa pun dengan dns. Dapatkan sisa DNS di jaringan dan tambahkan ke file / etc / hosts.

 dnsrecon -d test.lab -n 172.16.0.17 -t brt 

Saat memindai host 172.16.0.17, kami mendapatkan tokennya.

 dnsrecon -d test.lab -n 172.16.0.17 -a 

Token Helpdesk

Tugas selanjutnya dalam daftar: helpdesk. Kami menemukan dan menambahkan domain yang serupa. Selain itu, ini adalah satu-satunya layanan yang berjalan pada 172.16.0.10. Ada bentuk otorisasi yang sederhana, tidak ada CMS yang digunakan. Seperti biasa, kami mencoba masuk sebagai pengguna terkenal. Dan kami diam-diam pergi di bawah info@test.lab pengguna. Kami melihat formulir permintaan, setelah permintaan token, kami tidak mendapatkan apa-apa. Tampaknya kami tidak memilikinya, tetapi, seperti yang terjadi pada tugas-tugas seperti itu, tersedia untuk pengguna lain. Setelah sedikit meninjau halaman, kami menemukan kemampuan untuk mengubah kata sandi.



Setelah memindai formulir pencarian dan perubahan kata sandi dengan berbagai pemindai, kami tidak menemukan apa pun. Lihatlah kode sumber halaman ganti kata sandi. Jika Anda memperbaruinya beberapa kali, Anda akan melihat bahwa bidang tersembunyi dengan token CSRF tidak berubah. Artinya, ini bukan token CSRF. Ini adalah base64, decode dan dapatkan nomornya.





Karena tidak ada cookie yang dikirim, jelas bahwa ini adalah id pengguna. Rencananya adalah sebagai berikut: kami mengubah kata sandi untuk semua id, dan untuk id di mana hasil yang berhasil diperoleh, kami memilih login menggunakan kata sandi kami.


Hanya dua id yang berhasil merespons permintaan perubahan kata sandi. Sekarang tinggal memilih nama pengguna. Root dan admin tidak memberikan hasil, tetapi sviridov@test.lab memberi kami token.

Token iklan

Sebelum Anda pergi jalur VPN, mari kita lihat layanan di 172.16.0.17. Gali SAMBA workgroup TEST (dari analisis nmap). Pertama-tama, Anda perlu mencari tahu pengguna di domain:

 enum4linux -U 172.16.0.17 

Enum4linux mendefinisikan domain, pengguna dalam domain, informasi mereka dan informasi lainnya. Di antara pengguna, kami mengambil token. Omong-omong, semua login lebih baik untuk disimpan.

Token PENGGUNA

Dari helpdesk, tugas belajar bahwa pengguna sviridov diberi akses ke jaringan, mis., Konfigurasi vpn. Kami juga mengambil kata sandi dari helpdesk. Kami mencoba untuk terhubung ke 192.168.101.13 menggunakan konfigurasi yang ada, tetapi ganti nama pengguna dan kata sandi pengguna di userVPN.txt.



Tidak ada yang terjadi. Kemudian kami mencoba untuk terhubung ke 192.168.101.12. Kami terhubung dan jaringan 192.168.0.0/24 dan 172.16.0.0/16 tersedia untuk kami.



Sekarang lagi perlu untuk melakukan pengintaian jaringan. Dua jaringan 172.16.0.0 dengan topeng 255.255.0.0 tersedia untuk kami, di mana kami menemukan delapan host, dan jaringan 192.168.0.0/24, yang tidak dipindai. Tampaknya firewall diaktifkan di semua host. Kami memindai dengan opsi -Pn, dan dalam laporan kami benar-benar mendapatkan semua host dan port yang difilter di mana-mana. Kami perhatikan ada host di jaringan yang memiliki port 22 terbuka:

• 192.168.0.10
• 192.168.0.15
• 192.168.0.30
• 192.168.0.100
• 192.168.0.205
• 192.168.0.240

Karena satu-satunya hal yang ada pada jaringan 192.168.0.0/24 adalah enam host dengan port ssh terbuka, kami akan menggulir semuanya untuk dapat terhubung di bawah salah satu pengguna yang kami kenal.



Karena ada enam host, kami mengotomatiskan pencarian menggunakan utilitas kerangka metasploit. Kami akan menggunakan modul tambahan / pemindai / ssh / ssh_login.

 > use auxiliary/scanner/ssh/ssh_login > set RHOSTS 192.168.0.10 192.168.0.15 192.168.0.30 192.168.0.100 192.168.0.205 192.168.0.240 > set USERPASS_FILE '/root/CTF/PT12/userspass.txt' > exploit 

Kami pergi ke semua host di bawah kedua pengguna dan mencari informasi. Setelah berjalan jauh pada 192.168.0.100 kami menemukan kesalahan dalam hak akses. Direktori rumah pengguna tersedia untuk dilihat oleh semua orang. Kami menemukan token di dalamnya. Tetapi penulisnya adalah sviridov. Masuk di bawah Svridov dan berikan token.



Tidak ada yang lebih menarik yang ditemukan. Rute ip tidak memiliki jaringan lain. Di cron hanya ada pembersih. Di / tmp / banyak yang tidak bisa dipahami:

• 1.sh - tidak memberikan apa pun.
• Client.jar tidak memulai karena tidak ada JVM. Aneh mengapa dia dibutuhkan sama sekali.
• Ganti nama menjadi DAGESTAN_SILA nmap.
• Dua biji untuk meningkatkan hak istimewa.
• Dan banyak sekali sampah yang berbeda.

Token VPN

Pada jaringan 172.16.0.0/16, port 80 terbuka di semua host. Layak menjelajah situs di semua host:

• Pada 172.16.1.10 kami menemukan token !!! Menyetujui tugas VPN. Rupanya tugasnya adalah menebak untuk terhubung ke 192.168.101.12 sebagai pengguna sviridov.
• Pada 172.16.1.12 formulir otorisasi.
• Pada otentikasi dasar 172.16.1.15 .

Sangat mudah, teruskan.

Token SIEM

Kita pergi ke 172.16.1.12 . Kita membaca apa itu Prewikka. Prewikka adalah antarmuka pengguna utama untuk sistem SIEM Prelude, yang diimplementasikan melalui Web. Akses ke antarmuka adalah melalui browser web. Otentikasi dilakukan menggunakan akun lokal atau melalui direktori LDAP. Eksploitasi tidak dapat ditemukan. Login dan kata sandi Google secara default. Kegagalan, karena mereka ditunjukkan selama instalasi sistem. Tetapi Anda dapat mencoba contoh dari dokumentasi: prelude: preludepasswd - tidak cocok. Mari kita coba pengguna yang sudah kita kenal (dan kita hanya tahu kata sandi dua). Sviridov muncul. Penting untuk dicatat bahwa hanya administrator yang memiliki akses ke sistem SIEM. Dapat dikatakan bahwa kita mendefinisikan admin.

Kami mengamati bahwa data untuk bulan ini sedang ditampilkan. Kami menerjemahkan jurnal sebulan sebelumnya dan melihat data yang dicatat.



Perhatikan saja domain yang kita tambahkan ke / etc / hosts:

• (admin.test.lab) 172.16.1.25
• (vpn-admin.test.lab) 172.16.1.10
• (repositori.test.lab) 172.16.1.15
• (situs.test.lab) 172.16.0.14

Di antara log repository.test.lab, kami menemukan token.



Karena kami menemukan dan menambahkan entri baru untuk site.test.lab di / etc / hosts, mari kembali dan mengeksploitasi kerentanan di situs.

Token situs

Kembali ke site.test.lab, yang sekarang sesuai dengan 172.16.0.14. Mari kita lihat apakah WAF bekerja untuk itu. Kami mengirim beban kami dari contoh dan mendapatkan versi DBMS. Selanjutnya, kami mencari tahu basis data mana yang digunakan. Jika cocok dengan data default, maka Anda dapat langsung mendapatkan nama dan hash pengguna, karena secara default tabel dengan pengguna adalah: wp_users. Nama basis data (wordpress) sama, oleh karena itu, kami mencari nama pengguna dan kata sandi. Sayangnya, ini tidak memberikan apa-apa. Pengguliran kata sandi juga gagal.

Selanjutnya (saya tidak akan menjelaskan tekniknya, ini adalah dasar-dasarnya) kita mengikuti jalur yang biasa dalam hal ini - kita mendapatkan nama-nama semua tabel. Di antara mereka ada token tabel yang diperlukan. Cari tahu apa kolom dan tipe data. Maka kami mengerti bahwa kami perlu mendapatkan nilai nama.

Token repositori

Di SIEM kami menemukan log untuk repository.test.lab. Mari kita coba masuk menggunakan data yang ditemukan. Anda dapat kembali lagi dan mencari log untuk semua layanan yang ada di sana.



Kami lulus, kami mencoba masuk. Berhasil !!! Kami melihat beberapa file dan token.

Token terbalik

Selain token, ada dua file lagi di repositori. Salah satunya untuk menentukan Reverse adalah file bin. Mari kita lakukan analisis dasar dari file yang dapat dieksekusi:

• Strings - utilitas yang menampilkan semua baris dari file. Dalam hal ini, kami melihat banyak garis base64. Decoding tidak memberikan apa-apa.
• Ltrace adalah utilitas yang memotong panggilan fungsi perpustakaan. Dalam hal ini, tidak ada fungsi perpustakaan yang dipanggil.
• Strace adalah utilitas yang memotong semua syskol (panggilan sistem). Kami belum menerima data yang berguna.

Kami belum menerima data yang berguna. Untuk tugas-tugas semacam ini, saya lebih suka menggunakan Angr untuk solusi otomatis (saya akan menulis lebih banyak tentang perpustakaan angr di artikel berikutnya). Saya memberikan kode dengan python.

 import angr import claripy proj = angr.Project('./bin') simgr = proj.factory.simgr() simgr.explore(find=lambda s: b"ACCESS GRANTED!" in s.posix.dumps(1)) s = simgr.found[0] print(s.posix.dumps(0)) 

Kami mendapatkan token sebagai jawaban.

Token DB

Sekarang mari kita mencari tahu file jar. Anda perlu memahami apa yang dia lakukan. Java adalah bahasa yang didekompilasi, jadi kami mendapatkan kode sumber. Ada banyak program yang memungkinkan Anda melakukan ini (yang terbaik: JAD, JD-gui, Javasnoop, Intellij Idea Decompiler, JD-plugin Eclipse). Saya menggunakan JD-gui untuk dekompilasi dan Intellij Idea untuk membangun proyek. Dapatkan proyek sumber dengan mengikuti langkah-langkah ini:

1. Jalankan jd-gui. Di Linux, ada masalah startup yang dapat dipecahkan seperti ini - buat file bash dengan konten berikut:
   java --add-opens java.base/jdk.internal.loader=ALL-UNNAMED --add-opens jdk.zipfs/jdk.nio.zipfs=ALL-UNNAMED -jar /usr/share/jd-gui/jd-gui.jar
2. Unduh client.jar dan simpan.
3. Buka Ide Intellij → Proyek Impor. Tentukan jalur ke folder file.
4. Buat proyek dari sumber yang ada.

Mari kita menganalisis kode aplikasi untuk membayangkan apa gunanya. Langkah pertama adalah mengatur parameter koneksi dan SSL. Panggilan terjadi di alamat 172.16.0.55 pada port 5074. Selanjutnya, kami menerima pesan yang meminta Anda memasukkan salah satu nomor untuk memilih permintaan. Bergantung padanya, parameter tertentu dilewatkan ke fungsi Reqvest. Fungsi Reqvest mengembalikan permintaan yang dihasilkan dalam format json. Kami mengirim permintaan dan mendapat tanggapan.


Ada kesulitan: host 172.16.0.55 tidak tersedia untuk kami. Tetapi kami menemukan aplikasi serupa pada 192.168.0.240 di Sviridov. Ini berarti bahwa perutean dikonfigurasi sedemikian rupa sehingga ada akses ke server aplikasi dari komputernya. Karena kami memiliki akses melalui SSH, kami dapat meneruskan port ke lokal kami. Untuk meneruskan port, gunakan utilitas sshuttle.

 sshuttle -r sviridov@192.168.0.240 172.16.0.0/16 

Hasilnya, kami mendapatkan akses ke jaringan.



Sekarang kami sedang menguji aplikasi dalam mode debug, tetapi untuk mengubah sesuatu, Anda perlu membangun kembali proyek. Saat mencoba menjalankan aplikasi melalui F9, kami mendapatkan kesalahan. Untuk memperbaikinya, Anda harus:

1. Hapus perulangan.
2. Kesalahan pada json. Hapus seluruh folder dari proyek.
3. Pilih proyek dalam menu konteks: Buka Pengaturan Modul atau F4
4. Di tab Dependensi, pilih "+" dan tentukan file jar. Jadi dari proyek yang sudah selesai, kita akan memuat pustaka yang sudah dirakit yang rusak oleh dekompiler.

Sekarang aplikasi mulai berhasil, dan kita dapat mulai mencari kerentanan. String kueri, seperti yang telah kita ketahui, dibentuk di dalam fungsi Reqvest. Mari kita ubah sedikit kode untuk memahami bagaimana sistem merespons setiap input kami. Kami menambahkan baris di mana kami akan mengontrol parameter yang dikembalikan dan menampilkannya di konsol. Selanjutnya, kami akan melakukan empat pertanyaan yang mungkin. Seperti yang bisa kita lihat, string JSON dilewatkan. Dan sistem, yang sedikit mengingatkan pada HelpDesk, akan mengembalikan permintaan pengguna kepada kami. Ngomong-ngomong, ternyata basis data berputar di server, karena aplikasi mengembalikan kita kepada pengguna di mana permintaan dibuat.


Agar lebih mudah untuk mengubah dan menyempurnakan parameter, kami membuat fungsi terus-menerus mengembalikan string yang sama.



Karena database digunakan di server, hal pertama yang perlu diperiksa adalah keberadaan injeksi SQL:

1. Kami akan mengirimkan beban yang paling tidak berbahaya - fungsi penundaan. Permintaan dengan penundaan 10 detik membutuhkan waktu lebih lama daripada penundaan 0 detik. Ada suntikan TIDUR.
2. Periksa apakah rentan terhadap BLIND. Karena kesimpulan untuk kondisi yang benar tidak berubah, aplikasi rentan terhadap injeksi BLIND.
3. Pertama, Anda perlu mengetahui jumlah kolom dalam output. Untuk melakukan ini, kami sedang membangun permintaan UNION bersama. Kami memilah-milah jumlah kolom sampai tidak ada output. Jadi output muncul dengan 5 kolom.
4. Sekarang Anda perlu mengetahui informasi layanan: DBMS (versi @@) dan nama basis data (basis data ()). Nama basis data adalah untuk mengetahui apa yang harus dihubungi, dan DBMS adalah lingkungan tempat beroperasi. Jadi kami mengetahui bahwa MySQL digunakan, dan nama database adalah "reqvest".
5. Sekarang, melalui information_schema lingkungan, kami mencari tahu tabel apa yang ada. Kami tertarik pada token.
6. Kami mencari tahu kolom apa yang ada di tabel token.
7. Tampilkan konten dari tabel token.

Tugas ini ternyata sangat menarik !!!

Token api pengguna

Setelah menemukan enam host tersembunyi di jaringan 192.168.0.0/24, saya memikirkan fakta bahwa ini mungkin berada di 172.16.0.0/16. Lakukan pemindaian yang sama pada port utama. Karena hasilnya terlalu besar, kami akan mencari kata kunci "terbuka". Kami menemukan dua host lagi dengan web terbuka.



Yah, karena mereka mencoba menyembunyikan 172.16.1.20:8000 dari kami, kami pergi ke sana dan melihat aplikasi AJAX. Yah, seperti biasa, kami memindai direktori. Segala sesuatu yang ditemukan dirb sudah tersedia untuk kita.



Halaman kontak tidak berguna bagi kami. Halaman login membutuhkan otorisasi. Dan dukungan berisi beberapa jenis file barcode. Ini sepertinya sebuah stego, jadi untuk sekarang mari kita tinggalkan. Omong-omong, jika Anda pergi ke halaman ini beberapa kali, maka gambar yang berbeda akan muncul. Kami akan menyimpan semuanya, hanya ada 4. Mereka diterjemahkan sebagai "support_team".

Mari kita lihat direktori apa yang ada di sana. Kami mengamati lima direktori: contac, get_user_list, recover_password, login, dukungan. Jadi jika Anda melihat direktori get_user_list, mereka akan memberi tahu kami bahwa ada dua parameter - string login dan string kata sandi. Kami melihat, kami memilih pengguna dan kata sandi - itu tidak memberikan apa-apa. Dalam barcode, support_team dicoba sebagai login. Dan lagi, kebrutalan tidak memberikan apa pun di mana pun.



Dengan tidak sengaja memasukkan tanda kutip, kami menemukan reaksi aneh.
login=support_team“&password=“ and “1=1“

Dan kami diperlihatkan daftar pengguna.



Saat mencoba masuk sebagai pengguna mana pun, kami mendapatkan kesalahan yang sama. Temukan pengguna yang benar: pasangan login. Kami akan menulis skrip yang akan melewati semua pasangan dan memilih yang lulus ujian.


Jadi kami menemukan Medvedev.



Pulihkan kata sandinya. Passing langsung tidak akan berfungsi, karena "+" akan dikenali sebagai spasi, dan "&" sebagai pemisah. Kami menyandikan URLencode dan menerima token.

Token gambar

Jadi, kami menemukan gambar untuk stego. Mari kita perbaiki. Menggunakan file, binwalk, dan hex editor, kami memeriksa file untuk lampiran. Karena itu, mereka tidak akan menganalisis utilitas stegsolve. Dalam gambar terbesar kami menemukan bit dropdown pada posisi 2 dan 1 rgb. Ini adalah metode LSB.



Lebih lanjut, karena saya tidak memuntir, saya tidak menerima apa-apa. Harus memahami lebih dalam menangani. Untuk melakukan ini, gunakan perpustakaan python PIL untuk bekerja dengan gambar. Kami melihat gambar, dan kami melihat bahwa piksel mengambil tiga nilai - 0, 255 dan 249. Mari kita membangun peta biner dari gambar. Karena 0 dan 255 adalah nilai normal untuk barcode, kita akan menulis "0" sebagai ganti mereka, dan "1" bukannya 249. Selanjutnya, kami akan mencoba membagi kartu kami menjadi enam belas karakter dan menghapusnya dari semua baris yang hanya mengandung enam belas nol. Selanjutnya, tulis posisi unit dari setiap baris, dan terjemahkan dari bentuk heksadesimal menjadi string untuk mendapatkan token.

Token saya

Jadi Ada juga my.test.lab di file / etc / hosts, di mana kita belum pergi. Formulir otorisasi. Kami memiliki pengguna info, sviridov dan medvedev. Berhasil masuk ke info. Ada bilah pencarian. Atas permintaan token, kami diberi lima gambar kuda poni. Tidak ada, Kami akan memindai. Saat menggunakan wapiti, kami dilarang. Dengan beberapa pertanyaan untuk memeriksa SQL-inj dan XSS, kami juga mendapatkan larangan. Kami mengirim permintaan sederhana untuk menguji SSTI: {{7 * 7}}. Dan kodenya dieksekusi, karena dalam jawaban kita mendapat 49.



Masih menentukan mesin template yang digunakan di server. Ini diperlukan untuk mengetahui lingkungan mana (variabel, fungsi, konstanta, dll.) Yang dapat digunakan. Ini dapat dengan mudah dilakukan sebagai berikut.



Kita sudah tahu bahwa itu adalah Jinja2 atau Ranting. Karenanya, kami mengirim permintaan berikut: {{7 * “7“}}. Kami mendapat respons positif. Ini adalah mesin template python Jinja2, yang dengan mudah dikonfirmasi oleh permintaan {{self}}.





Mari kita lihat konfigurasi: {{config}}. Di sana kami menemukan kunci rahasia, yang merupakan token.

API Token

Kami belajar dari dokumentasi bahwa jinja2 menghasilkan cookie tergantung pada kunci rahasia server. Untuk mengeksploitasi kerentanan, kita memerlukan manajer flask-session-cookie- script . Kita perlu memeriksa apakah kunci rahasia ini berfungsi. Untuk melakukan ini, kita perlu mencoba mendekripsi sesi pengguna info di dalamnya. Cookie didekripsi secara bebas.



Mengetahui format cookie, kami sekarang dapat masuk sebagai pengguna mana pun. Untuk melakukan ini, Anda juga harus membuat cookie. Setelah kegagalan yang lama, saya melihat korelasi antara blok tengah dan waktu sistem. Kami mengubah tanggal hingga awal blok tengah bertepatan. Mencapai 2060. Pengguna token dan sviridov yang dibuat, tetapi tidak memberikan apa-apa, jadi saya memutuskan untuk menghasilkan untuk admin. Setelah berhasil mengganti cookie, kami mendapatkan beberapa kunci rahasia pengguna, yang tidak mereka mengerti.



Butuh tiga hari untuk mencari RCE (eksekusi kode jarak jauh) melalui SSTI. Faktanya adalah kita hanya dapat mengoperasikan modul yang dimuat di server dan fungsinya. Untuk memulainya, kami mencari tahu apa fungsinya. Kami akan melakukan ini melalui cookie labu.

 {{"".__class__.__mro__[1].__subclasses__()}} 

Kami memasukkan ke dalam cookie, menyegarkan halaman dan melihat bahwa alih-alih nama pengguna, semua kelas python yang dimuat di server ditampilkan. Di antara mereka adalah Popen, yang akan memungkinkan kita untuk membaca file di server.





Sekarang tinggal membaca file di sepanjang path / var / www / api / token. Kami akan mengakses kelas dengan indeks (untuk popen itu 94). Di dalamnya, kita memanggil fungsi terbuka untuk membuka file (kita memecah jalur ke file, jika tidak filter WAF) dan membacanya dengan fungsi read ().

 {{[].__class__.__base__.__subclasses__(+)[94].__init__.__globals__['__builtins__']['open']('/var/www'+'/api/token','rb').read(+)}} 

Sebagai hasilnya, kita mendapatkan file sebagai satu set byte, yang kita salin, buka interpreter python dan tempel sebagai string. Selanjutnya, tulis baris ini ke file. Mari kita lihat jenis file di utilitas file. Ini adalah arsip * tar.gz. Kami membuka dan mengambil token.

Token admin

Tugas terakhir tetap ada. Arsip menyimpan kunci untuk terhubung melalui ssh. Dari analisis SIEM, Anda dapat mengetahui host mana yang harus dihubungkan.



Pertama-tama, Anda perlu mengonfigurasi hak akses ke kunci, karena ini diperiksa saat menghubungkan (harus 600). Kemudian kami terhubung, tetapi kami diberitahu bahwa akses ditutup dan kesalahan ada di kuncinya.



Saat melihat format kunci, kami perhatikan bahwa isinya tidak sesuai dengan file lengkap. Untuk melakukan ini, kita memerlukan informasi otentikasi yang kami terima ketika membuat koneksi dan hash SHA yang dapat diambil dalam SIEM.



Tetapi sekarang ketika mencoba untuk terhubung, di bawah Sviridov (dia adalah admin), kita diberitahu bahwa kuncinya tidak cocok. Kita perlu memilah-milah semua pengguna yang sudah kita miliki.



Untuk menguji kunci dan pengguna, kami menggunakan modul kerangka kerja metasploit - pemindai / ssh / ssh_login_pubkey. Dan seperti yang Anda lihat, ini adalah sidorov kunci pengguna.



Temukan di sistem file token.

 find | grep token 

Selanjutnya, periksa hak dan serahkan token.

Kesimpulan

Jadi Pentestit Test Lab 12 berlalu.



Saya ingin mengucapkan terima kasih banyak kepada penyelenggara laboratorium ini, tetapi beberapa tugas lebih untuk CTF daripada untuk pengujian penetrasi. Saya harap artikel ini akan membantu seseorang belajar dan menemukan sesuatu yang baru, dan seseorang akan diingatkan tentang saat ketika dia sendiri melalui laboratorium ini dari token ke token. Sekarang kita sedang menunggu tanggal 13 ...

Kami berada di saluran telegram: saluran di Telegram .