Kerentanan konfigurasi Nginx dengan pengaturan blok alias yang salah

Beberapa server Nginx tetap rentan terhadap teknik Nginx Alias ​​​​Traversal, yang diusulkan pada konferensi Blackhat pada tahun 2018 dan memungkinkan akses ke file dan direktori yang terletak di luar direktori root yang ditentukan dalam arahan “alias”. Masalah hanya muncul pada konfigurasi dengan direktif "alias" yang ditempatkan di dalam blok "lokasi" yang parameternya tidak diakhiri dengan karakter "/", sedangkan "alias" diakhiri dengan "/".

Inti masalahnya adalah file untuk blok dengan direktif alias disajikan dengan melampirkan jalur yang diminta, setelah membandingkannya dengan mask dari direktif lokasi dan memotong bagian jalur yang ditentukan dalam mask ini. Untuk contoh konfigurasi rentan yang ditunjukkan di atas, penyerang dapat meminta file “/img../test.txt” dan permintaan ini akan berada di bawah topeng “/img” yang ditentukan di lokasi, setelah itu sisa ekor “.. /test.txt” akan dilampirkan ke jalur dari direktif alias “/var/images/” dan pada akhirnya akan meminta file “/var/images/../test.txt”. Dengan demikian, penyerang dapat mengakses file apa pun di direktori “/var”, dan bukan hanya file di “/var/images/”, misalnya, untuk mendownload log nginx, Anda dapat mengirimkan permintaan “/img../log/ nginx/akses.log".

Dalam konfigurasi di mana nilai direktif alias tidak diakhiri dengan karakter "/" (misalnya, "alias /var/images;"), penyerang tidak dapat mengubah ke direktori induk, tetapi dapat meminta direktori lain di /var yang namanya dimulai dengan sama yang ditentukan dalam konfigurasi. Misalnya, dengan meminta "/img.old/test.txt" Anda dapat mengakses direktori "var/images.old/test.txt".

Analisis repositori di GitHub menunjukkan bahwa kesalahan dalam konfigurasi nginx yang menyebabkan masalah masih terjadi di proyek nyata. Misalnya, masalah diidentifikasi di bagian belakang pengelola kata sandi Bitwarden dan dapat digunakan untuk mengakses semua file di direktori /etc/bitwarden (permintaan/attachments dikeluarkan dari /etc/bitwarden/attachments/), termasuk “vault .db", sertifikat dan log, untuk memperolehnya cukup mengirim permintaan "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log ", dll. .P.

Metode ini juga bekerja dengan Google HPC Toolkit, yang mengalihkan permintaan /static ke direktori "../hpc-toolkit/community/front-end/website/static/". Untuk mendapatkan database dengan kunci pribadi dan kredensial, penyerang dapat mengirimkan permintaan “/static../.secret_key” dan “/static../db.sqlite3”.

Sumber: opennet.ru