Pemalsuan permintaan server, operasi Blind SSRF

Ada hal yang disebut SSRF. Banyak yang telah ditulis tentangnya, tetapi tetap saja, saya akan memberi tahu Anda secara singkat.
Katakanlah Anda pergi ke situs, mengisi profil dan mendapatkan item "unggah avatar". Dan Anda punya pilihan - mengunggah file atau menentukan tautan.

Dalam hal ini, kami tertarik pada poin kedua. Jika kami menyediakan tautan ke sumber daya yang berisi gambar, maka aplikasi web:

1. Unduh itu
2. Periksa apakah gambar itu adalah gambar
3. Periksa ukurannya, karena mungkin tidak pas
4. Tampilkan ke pengguna (untuk memotong)

Jadi disini. Jika situs tidak memeriksa dari mana ia mencoba mengunduh gambar dari, ini adalah kerentanan (sebagai aturan). Selain itu, vektor serangan pada fitur kecil seperti mengunduh gambar sangat luas sehingga tidak ada cukup banyak pertemuan di bilah untuk menelusuri semua opsi.



Saya pernah ditanya - “Apa yang bisa saya lakukan jika saya hanya dapat menempatkan satu tautan http? Itu tidak memberi apa-apa! "
Aku memberitahumu.

Opsi termudah adalah mencoba mengidentifikasi layanan di dalamnya. Jika kita berbicara tentang gambar, Anda dapat mencoba melihat jalur standar seperti favicon.ico, logo atau direktori ikon, menyarankan bahwa Apache digunakan. Dengan mengirimkan permintaan, kami dapat beralih ke alamat lokal yang populer, serta subdomain situs yang berfungsi dalam infrastruktur internal. Ini semua jenis bambu, jira, gitlab dan hal-hal lain yang dicintai oleh semua perusahaan.

Untuk apa itu perlu? Tetapi karena pengetahuan adalah kekuatan. Bagaimanapun, bahkan secara membabi buta, Anda dapat menggunakan berbagai kerentanan dan eksploitasi. Mengetahui vendor atau versi server web atau layanan yang digunakan, Anda mempersempit kisaran serangan yang dapat Anda terapkan. Mungkin tidak sekarang, tetapi di masa depan, mengetahui informasi teknis tentang infrastruktur internal akan membantu Anda dalam mengeksploitasi kerentanan lainnya.

Yah, kami dilarang mengizinkan kami memasukkan alamat IP. Misalkan kita memiliki beberapa sumber daya penting di dalam infrastruktur dan alamat IP-nya adalah 192.168.1.1

Pertama-tama, kami secara mental memulai domain yang akan kami berikan IP ini. Biarkan saja my-test-site.com. Dalam kehidupan nyata, Anda harus membuat subdomain yang alamatnya akan diarahkan ke IP yang kami butuhkan, tetapi lebih lanjut tentang itu nanti.

Kata sandi brute force

Mari bermimpi bahwa kita memiliki router di dalamnya. Direktori / admin / berada di bawah otentikasi Dasar. Dengan mengubah tautan, kita dapat memilih login dan kata sandi untuk router. Tapi ini cukup sederhana, kami hanya membentuk tautan formulir

http://login:password@my-test-site.com/admin/

Dengan demikian, nilai sebelum titik dua akan menjadi login, setelah itu - kata sandi. Dan melalui tanda @ akan ada domain tempat data ini akan dikirim. Harap dicatat bahwa itu tidak berfungsi dengan semua jenis orang kontak di mana Anda perlu mengisi formulir. Oleh karena itu, diperlukan otentikasi Dasar - jendela sembul dengan respons 401 dari server.

Jika kami beruntung dan situs akan mengembalikan setidaknya kode respons (200, 401, 503), itu akan jauh lebih mudah. Kemudian kita dapat dengan jelas mengamati proses dan melihat kemenangan kita:

http://admin:password@my-test-site.com/admin/ - 401
http://admin:admin@my-test-site.com/admin/ - 401
http://admin:123456@my-test-site.com/admin/ - 200

Dengan mengirim selusin atau dua permintaan seperti itu, Anda dapat mencoba menemukan kata sandi untuk router ini. Dan kemudian beralih ke skrip untuk menyimpan DNS Anda sendiri atau bahkan /reboot.cgi

Dan jika tidak ada jawaban dan selalu sama?

Di sini timing akan membantu kami.

Pengaturan waktu

Semuanya butuh waktu. Ketika saya meluangkan waktu Anda untuk membaca artikel, maka layanan membutuhkan waktu Anda untuk merespons.
Keunikannya adalah kita dapat mencoba mengakses sumber daya internal dan mengukur timing untuk menjawab pertanyaan - apakah ada layanan di sana atau tidak?
Setelah mengirim banyak permintaan, Anda dapat memilah-milah layanan internal, port, dan bahkan direktori dan file, dengan mengandalkan anomali jawaban.

1302 ms - http://test.company.com
1307 ms - http://db.company.com
5483 ms - http://jira.company.com
1410 ms - http://docs.company.com
1366 ms - http://kafka.company.com

Subdomain jira merespon paling lama, kemungkinan besar ada di dalam, dan perbedaannya terlihat karena fakta bahwa server web mencoba memuat halaman, dan kemudian menyadari bahwa ini bukan gambar. Dan yang penting bagi kita bukanlah fakta "Siapa yang menjawab paling lama?", Tetapi justru "Siapa yang menjawab tidak seperti orang lain?" Karena timing bisa seperti penundaan - misalnya, jika Anda menemukan file atau skrip besar yang membutuhkan waktu lama untuk dieksekusi. Atau sebaliknya, jawaban cepat.

1302 ms - http://test.company.com
1307 ms - http://db.company.com
423 ms - http://jira.company.com
1410 ms - http://docs.company.com
1366 ms - http://kafka.company.com

Dalam kasus ini, jawabannya mengatakan bahwa itu adalah 401 atau pengalihan yang tidak memproses pengurai gambar. Atau mungkin situs itu dapat diakses, tetapi setelah memeriksa byte pertama atau tipe konten, aplikasi web kami menolaknya sebelum mengunduh halaman sepenuhnya. Situs-situs lain dalam contoh ini tidak menunggu koneksi (atau nama host tidak sadar)

Mekanisme verifikasi IP

Banyak situs telah memasukkan cek bahwa alamat IP tidak internal. Namun logikanya mungkin salah, dan terkadang Anda masih bisa membuat aplikasi terhubung ke alamat IP internal. Misalnya, situs memeriksa dalam dua blok logis. Pertama, ia memeriksa untuk melihat apakah host yang menunjuk ke IP eksternal diberikan kepada saya secara akurat. Jika setelah berhasil melewati pemeriksaan pertama, situs membuat koneksi, sementara tidak melakukan caching alamat IP dari paragraf sebelumnya, Anda bisa menggunakan trik lucu.

Pada permintaan pertama domain my-test-site.com, berikan IP eksternal, misalnya 123.123.123.123
Dan segera setelah melewati validasi, mulailah mengirim IP internal ke domain yang sama.

Dalam hal ini, Emil Lerner membuat layanan keren - 1u.ms!

Domain 1u.ms menjawab dengan alamat IP yang Anda tentukan.

Format domain harus sebagai berikut:

make-%IP%-rebind-%IP-rr.1u.ms

Sebagai contoh

make-123.123.123.123-rebind-127.0.0.1-rr.1u.ms

permintaan pertama akan dijawab dengan alamat 123.123.123.123, dan permintaan kedua akan dijawab sudah di 127.0.0.1 (jika satu demi satu, dalam 5 detik).

Omong-omong, alamat IP dapat ditulis tanpa titik, jika Anda memerlukan subdomain:

make-123-123-123-123-rebind-127-0-0-1-rr.1u.ms

By the way, sebelum membuat dan setelah rr, Anda dapat menulis kata-kata sewenang-wenang untuk mencegah penggunaan data yang di-cache:

bo0om-make-123-123-123-123-rebind-127-0-0.1-rr-test.1u.ms

Dan untuk melihat log - analog dari tail -f:
curl http://1u.ms:8080/log
(atau tautan yang sama di browser)

Pemindaian Port Menggunakan DNS

Bahkan, mengelola catatan DNS, Anda dapat mencoba memindai port. Trik kecil akan membantu kita dengan ini.

Misalkan kita memiliki domain my-test-site.com.

Biasanya, ini berisi setidaknya satu catatan A untuk membuka sumber daya.
Katakanlah IP situs kami adalah 172.217.20.46 (diambil dari google.com). Tetapi kita dapat menentukan beberapa entri seperti itu! Bayangkan kami membuatnya dan catatan DNS kami terlihat seperti ini:

my-test-site.com 172.217.20.46
my-test-site.com 192.168.1.1

Apakah sumber daya kita akan dibuka? Ya akan. Dan semua karena catatan pertama lebih dulu.

Sekarang ubah catatan DNS seperti ini:

my-test-site.com 192.168.1.1
my-test-site.com 172.217.20.46

Apakah sumber daya kita akan dibuka? Akan lagi :)

Dan semua karena sumber daya akan mencoba untuk boot dari IP pertama yang ditentukan, dan jika ada masalah dengan itu, itu akan pergi ke yang kedua.

curl "my-test-site.com" -v
* Trying 192.168.1.1...
* TCP_NODELAY set
* Immediate connect fail for 192.168.1.1: Host is down
* Trying 172.217.20.46...
* TCP_NODELAY set
* Connected to my-test-site.com (172.217.20.46) port 80 (#0)
> GET / HTTP/1.1
> Host: my-test-site.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=UTF-8
< Referrer-Policy: no-referrer
< Content-Length: 1561
< Date: Tue, 21 Jan 2020 16:35:08 GMT

Dengan menggunakan fitur ini, Anda dapat mengetahui port mana yang terbuka dan mana yang tidak. Memang, banyak (tetapi tidak semua) perpustakaan akan mencoba untuk datang pertama ke sumber pertama, yang terdaftar pertama dalam catatan DNS, dan kemudian ke yang kedua.
Di sini kami telah menunjukkan tautan ke sumber kami dalam memuat avatar.

Dengan menentukan domain kami, mengubah port, kami mencoba menggunakan metode pengecualian untuk menentukan port mana yang tersedia.

http://my-test-site.com:22 - 172.217.20.46:22
http://my-test-site.com:80 - 172.217.20.46:80
http://my-test-site.com:8080 -
http://my-test-site.com:9200 - 172.217.20.46:9200
http://my-test-site.com:3306 -

Karena kami menetapkan 192.168.1.1 sebagai catatan pertama, kami menyimpulkan bahwa alamat ini menjawab perpustakaan di 192.168.1.1 (port 8080 dan 3306), bahkan jika itu salah, tetapi ia menjawab. Jadi port ini terbuka dan ada layanan pada mereka. Dalam hal ini, itu tidak akan beralih ke alamat kedua.

Layanan 1u.ms di sini juga dapat membantu, dalam hal ini kita akan memiliki konfigurasi berikut:

make-%IP%-and-%IP%rr.1u.ms

jenis

make-192.168.1.1-and-172.217.20.46rr.1u.ms

Ini akan mengembalikan dua entri, semua fitur lain dari paragraf sebelumnya.

Omong-omong, pendekatan ini dapat digunakan untuk DNS Rebinding yang lebih cepat, memaksa browser untuk beralih dari server "hung" ke server yang berfungsi. Saya pikir ini akan lebih cepat daripada menunggu sebentar untuk memperbarui cache DNS. Namun, dengan Chrome, misalnya, trik ini tidak akan berfungsi, karena membutuhkan IP acak.

Tangkapan lain adalah bahwa server DNS yang digunakan aplikasi web menentukan alamat domain dapat memiliki built-in round robin - mengubah urutan catatan, sehingga mendistribusikan beban secara merata di semua server. Misalnya, 8.8.8.8 menolak fitur ini, tetapi pada 1.1.1.1 hadir.

Arahan ulang

Coba pengalihan! Yah, pertama, pengalihan dapat mengurangi jumlah permintaan untuk aplikasi web, misalnya, saat memindai port menggunakan DNS. Jika jawabannya mencapai Anda, arahkan ke port atau domain lain. Jika tidak, mungkin dia tersandung port terbuka.

Tetapi hal terbaik, tentu saja, adalah mencoba mengubah protokol menggunakan pengalihan. Dalam praktik saya, ada kasus-kasus ketika pengalihan ke file: /// etc / passwd bekerja dan menunjukkan isi file. Dalam versi dengan blind ssrf, Anda dapat mencoba mengubah protokol menjadi gopher (saat ini masih ada), dan Anda sudah dapat mengirim surat menggunakan perintah ke SMTP dan sihir lainnya.

Penolakan layanan

Apakah bootloader akan berhenti jika saya memberikan file input berukuran 10 GB? Atau gambar 225.000 kali 225.000 piksel, menempati 141,4 GB RAM. Ini dapat memengaruhi kinerja situs. Benar, server yang mogok tidak akan membuat kami senang, jadi ingatlah itu.

Dan semuanya

Mungkin ini yang bisa saya sebutkan sekarang. Ini tidak memperhitungkan kerentanan yang terkait dengan unduhan (tempat dimuat, bagaimana disimpan, yang diperiksa pada saat yang sama) dan potongan pihak ketiga (ingat imagetragick dan gifoeb ). Jika Anda punya ide lain, tinggalkan komentar.

Saya tidak bisa tidak memberikan SSRF sebuah Alkitab yang menggambarkan sebagian besar kasus pada serangan ini. Dan juga halaman dengan SSRF di repositori PayloadsAllTheThings favorit semua orang, yang secara aktif didukung oleh komunitas.
Ngomong-ngomong, banyak serangan berlaku untuk sisi-server (di server) dan sisi-klien (di browser). Penyerang - serang, jadilah kreatif. Membela - membela diri, menjadi lebih cerdik daripada menyerang.

https://bo0om.ru/blind-ssrf
Zen