Para peneliti keamanan dari Tsinghua University dan Nankai University telah mengungkapkan kerentanan kritis dalam Dnsmasq, sebuah software DNS yang banyak digunakan dan ditemukan di berbagai router serta perangkat jaringan di seluruh dunia. Celah keamanan ini, yang dijuluki SHAR Attack ( Single-character Hijack via ASCII Resolver-silence ), memungkinkan penyerang untuk meracuni cache DNS dengan mengeksploitasi cara software menangani query yang mengandung karakter khusus.
Karakter yang Rentan:
- Karakter khusus yang memicu upstream silence: ~, !, *, _
- Perangkat Lunak yang Terpengaruh: Dnsmasq (semua versi)
- Dampak: Cache poisoning pada nama domain apa pun
- Jenis Serangan: Off-path, tidak memerlukan fragmentasi IP
Masalah Inti: Respons Upstream yang Senyap
Kerentanan ini berpusat pada ketidaksesuaian mendasar dalam cara komponen DNS yang berbeda menangani query dengan karakter khusus. Ketika Dnsmasq menerima query DNS yang mengandung karakter seperti ~, !, atau*, software ini dengan patuh meneruskan permintaan tersebut ke server DNS upstream. Namun, beberapa resolver upstream secara diam-diam membuang query ini alih-alih merespons dengan pesan error yang tepat. Hal ini menciptakan situasi berbahaya di mana Dnsmasq menunggu tanpa batas waktu untuk respons yang tidak akan pernah datang.
Selama periode menunggu yang diperpanjang ini, penyerang dapat mengeksploitasi birthday paradox untuk memaksa kedua transaction ID 16-bit dan source port 16-bit. Meskipun ini mewakili lebih dari 4 miliar kombinasi yang mungkin, realitas matematisnya jauh lebih menguntungkan penyerang daripada yang terlihat.
Perdebatan Komunitas Mengenai Detail Teknis
Pengungkapan ini telah memicu diskusi teknis yang intens di antara para ahli DNS. Beberapa anggota komunitas berargumen bahwa framing karakter khusus menyesatkan, menunjuk ke RFC 2181 yang secara eksplisit menyatakan bahwa string biner apa pun dapat digunakan dalam nama domain. Masalah sebenarnya, menurut mereka, terletak pada resolver upstream yang salah membuang permintaan yang valid dan kegagalan Dnsmasq dalam menangani respons yang hilang dengan benar.
Yang lain mencatat bahwa penyedia DNS utama seperti Google 8.8.8.8 dan Cloudflare 1.1.1.1 dengan benar merespons query ini dengan pesan error yang sesuai, secara efektif menutup jendela serangan. Hal ini menunjukkan bahwa dampak kerentanan bervariasi secara signifikan tergantung pada server DNS upstream mana yang dikonfigurasi.
Opsi Mitigasi:
- Segera: Beralih ke Google DNS (8.8.8.8) atau Cloudflare (1.1.1.1)
- Keamanan Transport: Aktifkan DNS-over-HTTPS (DoH) atau DNS-over-TLS (DoT)
- Jangka panjang: Implementasikan validasi DNSSEC
- Level jaringan: Deploy DNS cookies untuk perlindungan tambahan
Implikasi Serangan Praktis
Para peneliti mendemonstrasikan tingkat keberhasilan 100% di 20 upaya serangan, dengan waktu eksekusi rata-rata sekitar 9.469 detik (sekitar 2,6 jam). Waktu ini membuat serangan praktis untuk skenario dunia nyata, terutama mengingat bahwa banyak instalasi Dnsmasq berjalan pada router konsumen yang mungkin tidak pernah menerima pembaruan keamanan.
Kerentanan ini menjadi sangat mengkhawatirkan ketika dikombinasikan dengan teknik serangan yang ada seperti SADDNS dan Tudoor, yang menurut para peneliti dapat diperkuat oleh celah ini. Kemampuan untuk meracuni cache DNS tanpa memerlukan teknik canggih atau posisi jaringan secara signifikan menurunkan hambatan bagi penyerang potensial.
Statistik Serangan:
- Tingkat Keberhasilan: 20/20 (100%) percobaan berhasil
- Waktu Eksekusi Rata-rata: ~9.469 detik (2,6 jam)
- Permukaan Serangan: brute force 32-bit (16-bit TxID + 16-bit source port)
- Paket Efektif yang Dibutuhkan: ~65.535 (karena birthday paradox)
Strategi Mitigasi dan Solusi Jangka Panjang
Sementara para peneliti merekomendasikan penerapan mekanisme deteksi untuk keheningan upstream dan pembatasan tingkat serupa dengan PowerDNS, diskusi komunitas mengungkapkan bahwa solusi fundamental terletak pada validasi kriptografi yang tepat. DNSSEC, yang dirancang khusus untuk mengatasi serangan spoofing DNS, tetap menjadi pertahanan paling kuat terhadap upaya cache poisoning.
Namun, kenyataannya adalah adopsi DNSSEC tetap terbatas, dan banyak domain yang akan menjadi target dalam serangan semacam itu tidak memiliki penandatanganan yang tepat. Untuk perlindungan segera, administrator jaringan dapat beralih ke penyedia DNS publik utama yang menangani query yang salah format dengan benar, atau menerapkan DNS-over-HTTPS ( DoH ) dan DNS-over-TLS ( DoT ) untuk menambahkan enkripsi transport.
Pengungkapan ini menyoroti masalah yang lebih luas dengan kerentanan inheren protokol DNS, yang telah dikenal sejak 1993 tetapi terus mempengaruhi sistem modern karena penyebaran protokol yang luas dan tantangan dalam menerapkan langkah-langkah keamanan komprehensif di lingkungan jaringan yang beragam.
Referensi: [Dnsmasq-discuss] [Security Report] Critical Cache Poisoning Vulnerability in Dnsmasq