Penyelidik keselamatan dari Universiti Tsinghua dan Universiti Nankai telah mendedahkan kelemahan kritikal dalam Dnsmasq , sebuah perisian DNS yang digunakan secara meluas dan terdapat dalam berjuta-juta router serta peranti rangkaian di seluruh dunia. Kelemahan ini, yang digelar sebagai Serangan SHAR ( Single-character Hijack via ASCII Resolver-silence ), membolehkan penyerang meracuni cache DNS dengan mengeksploitasi cara perisian mengendalikan pertanyaan yang mengandungi aksara khas.
Aksara Terdedah:
- Aksara khas yang mencetuskan senyap huluan: ~, !, *, _
- Perisian Terjejas: Dnsmasq (semua versi)
- Impak: Keracunan cache bagi mana-mana nama domain
- Jenis Serangan: Luar laluan, tidak memerlukan pemecahan IP
Masalah Teras: Respons Upstream Senyap
Kelemahan ini berpusat pada ketidakpadanan asas dalam cara komponen DNS yang berbeza mengendalikan pertanyaan dengan aksara khas. Apabila Dnsmasq menerima pertanyaan DNS yang mengandungi aksara seperti ~, !, atau*, ia akan meneruskan permintaan tersebut kepada pelayan DNS upstream. Walau bagaimanapun, sesetengah resolver upstream secara senyap membuang pertanyaan ini daripada membalas dengan mesej ralat yang betul. Ini mewujudkan situasi berbahaya di mana Dnsmasq menunggu selama-lamanya untuk respons yang tidak akan pernah datang.
Semasa tempoh menunggu yang panjang ini, penyerang boleh mengeksploitasi paradoks hari lahir untuk memecah secara paksa kedua-dua ID transaksi 16-bit dan port sumber 16-bit. Walaupun ini mewakili lebih 4 bilion kombinasi yang mungkin, realiti matematik adalah lebih menguntungkan penyerang daripada yang kelihatan.
Perdebatan Komuniti Mengenai Butiran Teknikal
Pendedahan ini telah mencetuskan perbincangan teknikal yang sengit di kalangan pakar DNS. Sesetengah ahli komuniti berpendapat bahawa pembingkaian aksara khas adalah mengelirukan, merujuk kepada RFC 2181 yang secara eksplisit menyatakan bahawa sebarang rentetan binari boleh digunakan dalam nama domain. Isu sebenar, menurut mereka, terletak pada resolver upstream yang secara salah membuang permintaan yang sah dan kegagalan Dnsmasq untuk mengendalikan respons yang hilang dengan betul.
Yang lain menyatakan bahawa penyedia DNS utama seperti 8.8.8.8 Google dan 1.1.1.1 Cloudflare membalas dengan betul kepada pertanyaan ini dengan mesej ralat yang sesuai, dengan berkesan menutup tingkap serangan. Ini menunjukkan bahawa kesan kelemahan berbeza-beza bergantung pada pelayan DNS upstream yang dikonfigurasi.
Pilihan Mitigasi:
- Segera: Tukar kepada Google DNS (8.8.8.8) atau Cloudflare (1.1.1.1)
- Keselamatan Pengangkutan: Dayakan DNS-over-HTTPS ( DoH ) atau DNS-over-TLS ( DoT )
- Jangka panjang: Laksanakan pengesahan DNSSEC
- Peringkat rangkaian: Gunakan kuki DNS untuk perlindungan tambahan
Implikasi Serangan Praktikal
Para penyelidik menunjukkan kadar kejayaan 100% merentasi 20 percubaan serangan, dengan masa pelaksanaan purata kira-kira 9,469 saat (sekitar 2.6 jam). Masa ini menjadikan serangan praktikal untuk senario dunia sebenar, terutamanya memandangkan banyak pemasangan Dnsmasq berjalan pada router pengguna yang mungkin tidak pernah menerima kemas kini keselamatan.
Kelemahan ini menjadi amat membimbangkan apabila digabungkan dengan teknik serangan sedia ada seperti SADDNS dan Tudoor , yang menurut penyelidik boleh diperkuatkan oleh kelemahan ini. Keupayaan untuk meracuni cache DNS tanpa memerlukan teknik lanjutan atau kedudukan rangkaian secara ketara menurunkan halangan bagi penyerang berpotensi.
Statistik Serangan:
- Kadar Kejayaan: 20/20 (100%) percubaan berjaya
- Purata Masa Pelaksanaan: ~9,469 saat (2.6 jam)
- Permukaan Serangan: brute force 32-bit (16-bit TxID + 16-bit source port)
- Paket Berkesan Diperlukan: ~65,535 (disebabkan paradoks hari jadi)
Strategi Mitigasi dan Penyelesaian Jangka Panjang
Walaupun penyelidik mengesyorkan pelaksanaan mekanisme pengesanan untuk kesunyian upstream dan had kadar yang serupa dengan PowerDNS , perbincangan komuniti mendedahkan bahawa penyelesaian asas terletak pada pengesahan kriptografi yang betul. DNSSEC , yang direka khusus untuk menangani serangan pemalsuan DNS, kekal sebagai pertahanan paling kukuh terhadap percubaan keracunan cache.
Walau bagaimanapun, realitinya ialah penggunaan DNSSEC masih terhad, dan banyak domain yang akan menjadi sasaran dalam serangan sedemikian tidak mempunyai tandatangan yang betul. Untuk perlindungan segera, pentadbir rangkaian boleh beralih kepada penyedia DNS awam utama yang mengendalikan pertanyaan yang cacat dengan betul, atau melaksanakan DNS-over-HTTPS ( DoH ) dan DNS-over-TLS ( DoT ) untuk menambah penyulitan pengangkutan.
Pendedahan ini menyerlahkan isu yang lebih luas dengan kelemahan protokol DNS yang sedia ada, yang telah diketahui sejak 1993 tetapi terus menjejaskan sistem moden disebabkan oleh penggunaan protokol yang meluas dan cabaran melaksanakan langkah keselamatan menyeluruh merentasi persekitaran rangkaian yang pelbagai.
Rujukan: [ Dnsmasq-discuss ] [ Laporan Keselamatan ] Kelemahan Kritikal Keracunan Cache dalam Dnsmasq