Cache Poisoning dan Cache Deception
Cache Poisoning dan Cache Deception adalah jenis serangan keamanan pada aplikasi web yang menggunakan cache. Meskipun keduanya berhubungan dengan cache, namun keduanya memiliki perbedaan.
Cache Poisoning terjadi ketika seorang penyerang memasukkan konten jahat ke dalam cache, sehingga konten tersebut disajikan dari cache kepada pengguna lainnya. Tujuan dari cache poisoning adalah untuk membuat klien memuat sumber daya yang tidak diharapkan atau terkontrol oleh penyerang. Respons yang tercemar akan disajikan hanya kepada pengguna yang mengunjungi halaman yang terkena dampak selama cache dicemari. Dampak yang ditimbulkan dapat berkisar dari tidak ada dampak hingga sangat besar tergantung pada seberapa populer halaman tersebut.
Untuk melakukan serangan cache poisoning, penyerang harus terlebih dahulu mengidentifikasi input yang tidak dipersyaratkan (parameter yang tidak perlu muncul pada permintaan yang di-cache tetapi mengubah halaman yang dikembalikan), dan mencari cara untuk mengeksploitasi parameter tersebut sehingga dapat menghasilkan respon yang dicache.
Penyerang dapat melakukan identifikasi terhadap input dengan menggunakan Param Miner untuk memaksa parameter dan header yang mungkin mengubah respons halaman. Kemudian, penyerang dapat memeriksa cara input tersebut disanitasi dan bagaimana input tersebut memengaruhi respons dari header. Apakah penyerang dapat mengeksploitasi input tersebut (melakukan XSS atau memuat kode JS yang dikontrol oleh penyerang, melakukan DoS, dll.) ? Setelah mengetahui cara mengeksploitasi input tersebut, penyerang dapat mengambil respons yang telah dicache.
Ada beberapa header HTTP yang dapat membantu penyerang dalam melakukan serangan cache poisoning, seperti X-Cache, Cache-Control, Vary, dan Age. Namun, penyerang harus berhati-hati dalam menggunakan header saat melakukan cache poisoning karena beberapa header bisa digunakan dengan cara yang tidak diharapkan sebagai keyed.
Di sisi lain, Cache Deception terjadi ketika seorang penyerang memasukkan konten sensitif milik pengguna lain ke dalam cache, lalu penyerang mengambil konten tersebut dari cache. Dalam kasus ini, penyerang tidak menyajikan konten yang telah dicemari pada pengguna lain, tetapi memanfaatkan konten sensitif tersebut untuk kepentingannya sendiri.
Dalam melakukan Cache Deception, penyerang perlu mengetahui bagaimana sistem cache bekerja dan mencari cara untuk memasukkan konten yang sensitif ke dalam cache. Kemudian, penyerang dapat mengambil konten yang telah dicache untuk digunakan sesuai dengan keinginannya.
Kesimpulan Cache Poisoning dan Cache Deception adalah jenis serangan keamanan pada aplikasi web yang menggunakan cache. Kedua serangan ini berbeda dalam cara penyerang memanfaatkan cache, di mana pada Cache Poisoning, penyerang memasukkan konten jahat ke dalam cache, sedangkan pada Cache Deception, penyerang memasukkan konten sensitif milik pengguna lain ke dalam cache.
Contoh Exploit
Easiest example
pada sebuah website terdapat header yang dapat dimanipulasi seperti X-Forwarded-For oleh pengguna jahat dengan memasukkan kode XSS yang berbahaya. Ketika orang lain mengakses halaman tersebut, mereka juga akan terkena serangan XSS yang sama. Hal ini dapat dimanfaatkan oleh penyerang untuk melakukan serangan pada banyak orang secara bersamaan.
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
Perlu diingat bahwa ini akan meracuni permintaan ke /en?region=uk bukan ke /en.
Menggunakan pemalsuan web cache untuk mengeksploitasi kerentanan penanganan cookie
web cache poisoning dapat dimanfaatkan untuk mengeksploitasi kerentanan dalam penanganan cookie. Cookie bisa tercermin pada respons dari suatu halaman. Jika kamu bisa menyalahgunakannya untuk menyebabkan XSS, misalnya, kamu bisa mengeksploitasi XSS pada beberapa klien yang memuat respons cache berbahaya.
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
Perlu diingat bahwa jika cookie yang rentan digunakan secara luas oleh pengguna, permintaan reguler akan membersihkan cache.
Penggunaan beberapa header untuk mengeksploitasi kerentanan keracunan cache web
terkadang dibutuhkan beberapa input yang tidak diberi kunci untuk mengeksploitasi kerentanan web cache poisoning. Contohnya, jika Anda menyetel X-Forwarded-Host ke domain yang dikendalikan oleh Anda dan X-Forwarded-Scheme ke http, maka Anda dapat menemukan pengalihan terbuka (Open Redirect) jika server meneruskan semua permintaan HTTP ke HTTPS dan menggunakan header X-Forwarded-Scheme sebagai nama domain untuk pengalihan tersebut. Dengan demikian, Anda dapat mengontrol halaman yang dituju 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
Contoh permintaan yang diberikan di atas adalah contoh dari HTTP GET request yang dikirimkan ke server dengan header Host, X-Forwarded-Host, dan X-Forwarded-Scheme.
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 pada respons menunjukkan User-Agent. Maka, Anda perlu mencari cara untuk mengambil User-Agent dari korban dan meracuni cache menggunakan user agent itu:
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: USER-AGENT KORBAN
X-Host: attacker.com
Dalam contoh permintaan yang diberikan, permintaan GET dilakukan dengan mengirimkan header Host dan User-Agent yang tepat, serta header X-Host yang dimanipulasi untuk menunjuk ke domain yang dikendalikan oleh penyerang. Hal ini dimaksudkan untuk meracuni cache dan kemudian mengeksploitasi celah keamanan yang ada.
Mengeksploitasi Keracunan Cache HTTP dengan menyalahgunakan HTTP Request Smuggling.
Belajarlah di sini tentang bagaimana melakukan serangan Cache Poisoning dengan menyalahgunakan HTTP Request Smuggling.
Pengujian otomatis untuk Web Cache Poisoning
Vulnerability Scanner, yang dapat diakses melalui tautan Github https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner. Alat ini dapat melakukan pengujian secara otomatis untuk mengidentifikasi kerentanan web cache poisoning dengan berbagai teknik dan sangat dapat disesuaikan. Contoh penggunaannya adalah dengan menjalankan perintah wcvs -u example.com.
Contoh Kerentanan
Apache Traffic Server (CVE-2021-27577)
Pada kasus tersebut, ATS (Apache Traffic Server) meneruskan fragmen di dalam URL tanpa menghilangkannya dan membuat kunci cache hanya menggunakan host, path, dan query (mengabaikan fragmen). Sehingga permintaan /#/../?r=javascript:alert(1) dikirimkan ke backend sebagai /#/../?r=javascript:alert(1) dan kunci cache tidak mengandung payload di dalamnya, hanya host, path, dan query. Dengan demikian, serangan cache poisoning bisa dilakukan dengan memanipulasi URL dan memasukkan payload berbahaya dalam fragmen.
GitHub CP-DoS (Denial of Service on GitHub):
Dalam konteks ini, terjadi serangan CP-DoS pada GitHub. Pada serangan ini, si penyerang berhasil memanfaatkan kerentanan pada server GitHub sehingga menghasilkan respon caching dengan kode status 405 (Method Not Allowed) yang tidak benar. Hal ini dilakukan dengan mengirimkan nilai yang buruk dalam header “content-type” pada permintaan yang dikirimkan ke server. Karena kunci cache server GitHub juga mencakup informasi cookie, maka serangan hanya dapat dilakukan pada pengguna yang tidak terotentikasi (tidak masuk log in) karena pengguna yang terotentikasi biasanya akan memiliki kunci cache yang berbeda karena adanya informasi session yang berbeda.
GitLab + GCP CP-DoS (Denial of Service pada GitLab dan Google Cloud Platform):
GitLab menggunakan GCP bucket untuk menyimpan konten statis seperti gambar, file CSS, dan file JavaScript. GCP Bucket mendukung header khusus seperti x-http-method-override, yang memungkinkan pengguna untuk mengganti metode HTTP yang sebenarnya dengan metode yang ditentukan dalam header.
Dalam serangan ini, pengirim dapat mengirimkan header x-http-method-override: HEAD untuk memalsukan respons cache menjadi mengembalikan body respons yang kosong. Ini karena ketika permintaan asli dikirim dengan metode HEAD, server hanya mengirim header tanpa body.
Selain itu, header x-http-method-override juga dapat mendukung metode PURGE, yang dapat digunakan untuk menghapus cache dari server. Namun, ini membutuhkan konfigurasi khusus di server dan biasanya hanya digunakan oleh administrator.
Rack Middleware (Ruby on rails)
Penerapan aplikasi Ruby on Rails seringkali disertai dengan middleware Rack. Kode Rack di bawah ini mengambil nilai dari x-forwarded-scheme dan menggunakannya sebagai skema permintaan (request). Ini berarti bahwa jika header x-forwarded-scheme dikirim dengan nilai yang berbeda dari http atau https, maka aplikasi Ruby on Rails akan menggunakan skema yang dikirim dalam header tersebut untuk memproses permintaan, dan ini dapat dimanipulasi oleh penyerang untuk melancarkan serangan cache poisoning.
Pengiriman header x-forwarded-scheme: http akan menghasilkan pengalihan 301 ke lokasi yang sama yang akan menyebabkan DoS (Denial of Service) pada sumber daya tersebut seperti contoh di atas. Ini berarti server akan terus mengalihkan permintaan ke dirinya sendiri, yang dapat membebani server dan membuatnya tidak responsif untuk permintaan lain dari klien. Hal ini dapat memengaruhi ketersediaan layanan yang disediakan oleh server tersebut.
aplikasi mungkin juga mendukung header X-forwarded-host dan mengalihkan pengguna ke host tersebut, sehingga memungkinkan untuk memuat file javascript dari server penyerang. Hal ini dapat menyebabkan penyerangan yang disebut sebagai “Javascript injection” atau “Cross-site scripting (XSS)” di mana attacker dapat memanipulasi javascript di dalam website korban untuk melakukan tindakan berbahaya seperti mencuri data pengguna. Oleh karena itu, sangat penting untuk memeriksa dan mengamankan header seperti X-forwarded-host untuk mencegah serangan XSS.
403 and Storage Buckets
sebelumnya Cloudflare menggunakan cache untuk respons 403 (forbidden) sehingga ketika seseorang mencoba mengakses S3 atau Azure Storage Blobs yang terbuka secara publik menggunakan header Authorization yang buruk, maka akan menghasilkan respons 403 yang dicache oleh Cloudflare. Namun, sekarang Cloudflare tidak lagi menggunakan cache untuk respons 403 tersebut, namun tetap bisa saja berhasil jika digunakan dengan proxy lain yang masih menggunakan cache untuk respons 403. Hal ini bisa menjadi masalah keamanan karena attacker masih bisa mengakses sumber daya terlarang meskipun sudah diatur sebagai 403.
Injecting Keyed Parameters
sering kali cache dikonfigurasi untuk hanya memasukkan parameter GET tertentu dalam kunci cache. Contohnya, Fastly menggunakan Varnish untuk meng-cache parameter ukuran dalam permintaan, namun jika Anda mengirimkan parameter "siz%65" dengan nilai yang salah, kunci cache akan dibuat dengan parameter ukuran yang benar, tetapi backend akan menggunakan nilai di dalam parameter yang di-URL encode tersebut. Dengan demikian, ini dapat menyebabkan masalah dalam sistem cache dan menyebabkan potensi kerentanan keamanan.
saat melakukan URL encoding pada parameter size yang kedua, akan menyebabkan cache mengabaikannya tetapi akan digunakan oleh backend. Jika parameter tersebut diberikan nilai 0, maka akan menghasilkan respon 400 Bad Request yang bisa di-cache. Dalam hal ini, penting untuk memperhatikan bahwa terkadang cache hanya menyertakan parameter GET tertentu dalam kunci cache, sehingga mengubah nilai parameter atau cara encoding-nya dapat memengaruhi kinerja cache dan backend.
User Agent Rules
User Agent Rules adalah aturan yang digunakan oleh developer untuk memblokir request yang cocok dengan user-agent tertentu. Hal ini dilakukan untuk mencegah serangan dari beberapa tool seperti FFUF atau Nuclei yang sering menghasilkan banyak traffic. Namun, ironisnya, penggunaan aturan ini dapat memicu masalah cache poisoning dan DoS yang tidak diinginkan. Misalnya, jika user-agent yang diblokir di-cache oleh server, maka serangan yang dilakukan dengan mengubah user-agent dapat menyebabkan cache poisoning dan memicu DoS. Oleh karena itu, penggunaan User Agent Rules harus dilakukan dengan hati-hati dan dengan mempertimbangkan dampak yang mungkin terjadi.
teknik ini berhasil digunakan pada beberapa target dengan user-agent dari berbagai alat atau scanner yang berbeda.
Illegal Header Fields
Format nama header dijelaskan dalam RFC7230 sebagai berikut:
dalam teori, jika sebuah nama header mengandung karakter selain yang terdaftar dalam tchar, maka seharusnya akan ditolak dengan respons 400 Bad Request. Namun dalam praktiknya, tidak semua server mematuhi RFC ini. Cara paling mudah untuk mengeksploitasi hal ini adalah dengan menargetkan Akamai yang tidak menolak header yang tidak valid, tetapi meneruskannya dan menyimpan setiap kesalahan 400 sebagai cache selama header cache-control tidak hadir. Dengan cara ini, penyerang dapat memanfaatkan header yang tidak valid untuk melakukan serangan cache poisoning dan memicu respons error 400.
Pengiriman header yang berisi karakter ilegal, seperti backslash (\), dapat menyebabkan kesalahan 400 Bad Request yang dapat dicache. Hal ini adalah salah satu pola yang paling sering diidentifikasi dalam pengujian yang dilakukan. Dengan mengirimkan header seperti itu, dapat memanfaatkan celah dalam pengamanan server untuk melakukan serangan terhadap sistem yang dituju.
Cari header baru
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
Cache Deception
Teknik ini bertujuan untuk membuat klien (client) memuat sumber daya yang akan disimpan oleh cache dengan informasi sensitif dari pengguna lain.
Pertama-tama, perlu dicatat bahwa ekstensi seperti .css, .js, .png, dan sejenisnya biasanya dikonfigurasi untuk disimpan dalam cache. Oleh karena itu, jika Anda mengakses www.example.com/profile.php/nonexistent.js, cache kemungkinan akan menyimpan respons tersebut karena melihat ekstensi .js. Namun, jika aplikasi membalas dengan konten sensitif pengguna yang disimpan di www.example.com/profile.php, Anda dapat mencuri konten itu dari pengguna lain.
Hal lain yang perlu di uji :
www.example.com/profile.php/.jswww.example.com/profile.php/.csswww.example.com/profile.php/test.jswww.example.com/profile.php/../test.jswww.example.com/profile.php/%2e%2e/test.js- Use lesser known extensions such as
.avif
contoh kasus lain dalam melakukan serangan Cache Deception dapat kamu temui disini, jika mengakses sebuah halaman yang tidak ada, misalnya 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 sendiri dan mengamati informasi rahasia pengguna yang telah mengakses sebelumnya. Penting untuk diperhatikan bahwa server cache harus dikonfigurasi untuk menyimpan file berdasarkan ekstensi file (.css) dan bukan berdasarkan tipe konten.