Bagaimana tag sederhana bisa menjadi risiko tinggi untuk bisnis?

Keamanan dengan contoh nyata selalu menarik.

Hari ini kita akan berbicara tentang serangan SSRF, ketika Anda dapat memaksa server untuk membuat permintaan sewenang-wenang ke Internet melalui tag img.



Jadi, saya baru-baru ini terlibat dalam pengujian penetrasi pada dua proyek secara bersamaan, pada dua di antaranya kerentanan ini terungkap. Tangkapan layar diambil langsung dari laporan, oleh karena itu semua informasi yang tidak perlu dioleskan.

Deskripsi serangan

Nama serangan: server membuat permintaan acak ke Internet selama pembuatan dokumen PDF.

Deskripsi: PDF dibuat di sisi server dari halaman html yang sepenuhnya diterjemahkan dengan semua sumber daya eksternal. Dokumen berisi data yang dimasukkan oleh pengguna. Tanpa pemfilteran yang tepat, Anda bisa mengganti sumber daya eksternal Anda dalam rendering server. Dalam hal ini, biarkan itu file it-band.by/10gb.blob ( ukurannya seharusnya 10 Gb).

Skenario terburuk:

1. Serangan DDo dari dalam ketika sistem perlu mengunduh 100 gigabyte data untuk rendering untuk membuat beberapa dokumen PDF sekaligus. Akibatnya, ini menyebabkan kurangnya sumber daya jaringan atau memori, yang pada gilirannya dapat menyebabkan sistem mati.
2. Seorang pengguna jahat dapat menggunakan server sebagai platform untuk menyerang sumber daya lainnya.
3. Seorang pengguna jahat memperoleh alamat IP eksternal dari server internal untuk serangan langsung, melewati firewall aplikasi web (WAF) dan penyeimbang.

Penilaian risiko (Kemungkinan * Dampak): Sedang (5) * Tinggi (7) = Tinggi (35) (dalam kedua sistem, risiko dinilai tinggi, meskipun dengan rasio yang berbeda)

Yang menarik:

1. Satu sistem menggunakan wkhtmltopdf untuk membuat html2pdf, yang kedua menjalankan Firefox, memuat halaman di sana dan mengambil tangkapan layar. Bagaimanapun, kedua sistem segera membuat kedua halaman, jalankan semua kode di sana, dan hanya kemudian membuat PDF dari ini.
2. Perlindungan server XSS dipasang pada kedua sistem, tetapi alih-alih menggunakan data input yang keluar, kedua sistem menggunakan pemurnian html, yang menghapus semua iframe, skrip, css, formulir, dan sebagainya. Tetapi pemurnian html di kedua sistem dianggap img src="https://it-band.by/10Gb.blob?t=12345.1"/ kode html aman.

Sekarang, ikuti langkah-langkah dan tangkapan layar

1) Buat file seperti itu secara lokal, dalam upaya untuk mengisinya secara keseluruhan atau sebagian.



2) Pada awalnya, Anda perlu menemukan bidang pengguna yang rentan.

Sistem 1. Gagal memasukkan hanya satu tag img





Sistem 2. Saya berhasil menyisipkan sekitar 20 tag segera



3) Selanjutnya, kami menghasilkan dokumen PDF.

Sistem 1. Generated PDF



Sistem 2. PDF yang Dihasilkan



4) Dan sekarang kita naik ke server kami untuk melihat apakah ada permintaan untuk file 10Gb.blob besar kami.

Sistem 1. Kami mendapatkan alamat IP server dan perangkat lunak yang digunakan untuk membuat dokumen PDF, nmap menunjukkan port terbuka lain, yang belum pernah dilihat sebelumnya oleh alamat IP yang ditemukan.



Sistem 2. Dapat dilihat bahwa server mencoba mengunduh 20 file dari 10 gigabytes. Kami juga mendapatkan alamat salah satu server dan versi Firefox yang digunakan.



Hasilnya Di kedua sistem, kesalahan sudah diperbaiki. Dalam sistem pertama, alih-alih memurnikan html, melarikan diri dilakukan baik selama pemrosesan data pengguna dan selama pembuatan dokumen PDF; dalam sistem kedua, semua tautan absolut ke sumber daya eksternal terputus selama pemrosesan data pengguna.

Diperbarui.

Sementara saya sampai ke publikasi artikel, kasus dari 2 sistem ditambahkan.

Sistem lain (sebut saja Sistem 3) tidak lulus pemeriksaan untuk jenis kerentanan ini di dua tempat sekaligus: melalui Injeksi HTML dan Injeksi CSS.

Sistem 3. Injeksi html dengan mengunduh 20 kali gambar langsung 13 Mb (total 260Mb)



Sistem 3. Injeksi CSS



Sistem 3. Apa yang kita lihat di server penyerang saat merender PDF (semua 20 unduhan dari gambar 13MB berhasil)



Apa output untuk Sistem 3:

1) Mendapat alamat server yang di-render, dan apa yang mereka gunakan untuk rendering. Dalam hal ini, HeadlessChrome.

2) Pembuatan satu dokumen PDF memakan waktu sekitar 5 menit, kemudian kromnya jatuh. Bayangkan, jika Anda menjalankan 10 ribu permintaan seperti itu, maka untuk sementara server generasi akan, pada prinsipnya, berhenti merespons permintaan dari pengguna lain.

Sistem 4. Serangan SSRF di sini dilakukan bukan melalui tag img, tetapi melalui XSS, ketika muatan favorit saya dieksekusi di server selama rendering dan server meluncurkan kode Javascript sewenang-wenang saat membuat Dokumen PDF. Dibandingkan dengan kasus-kasus sebelumnya, adalah mungkin untuk melakukan serangan yang lebih kompleks pada sistem lain.



Sistem 4. Rendered PDF dengan kode JS arbitrer dieksekusi di sisi server



Premis 1. Sistem membutuhkan pengembangan tidak hanya aturan firewall yang masuk, tetapi juga yang keluar, atau pengembangan infrastruktur dengan segmen jaringan atau server yang terpisah, yang umumnya tidak ada akses ke luar.

Premis 2. Ketika menemukan bahkan kerentanan terkecil, Anda harus selalu mencari skenario terburuk penggunaan dan dampaknya pada bisnis. Bisnis hanya dapat bekerja dengan risiko, sisi teknis, sayangnya, tidak begitu menarik bagi mereka.

Informasi di atas disediakan hanya untuk tujuan pendidikan dan pendidikan, bagaimana melakukan sistem mereka tidak perlu.

Denis Koloshko, CISSP, Penetration Tester