Halo semuanya! Hari ini kami ingin membicarakan tentang serangan lama dan hampir terlupakan yang disebut DNS rebinding. Pembicaraan pertama tentang hal itu dimulai kembali pada tahun 2007, tetapi kemudian para ahli dari bidang keamanan informasi praktis tidak memperhatikannya sehubungan dengan kekhasan operasi serangan ini, serta dengan sedikit konsekuensi nyata, seperti yang tampak saat itu. Hari ini kami akan mencoba meyakinkan mereka tentang yang sebaliknya, dan Anda, khususnya, dengan menunjukkan bahwa di dunia modern serangan ini telah menemukan angin kedua dan tidak lagi tampak tidak berbahaya.
Apa itu rebinding DNS?
Pertimbangkan skema berikut:
Kami memiliki komputer korban dengan IP 192.168.0.2 di jaringan lokal, dan juga memiliki router dengan alamat IP 192.168.0.1. Tujuan penyerang yang mengelola server dengan alamat 13.37.13.37 dan nama domain hacker.com (juga, server DNS kami sendiri yang berisi informasi tentang domain berputar di ip-shnik) adalah untuk mendapatkan akses ke router di jaringan lokal.
Untuk menggunakan teknik rebinding DNS, kita perlu memancing korban ke situs jahat kami. Misalkan kita berhasil.
Sekarang mari kita periksa secara rinci bagaimana serangan itu bekerja.
Pertama-tama, browser mengakses server DNS dengan permintaan A-record:
Rantai server DNS mengarah ke server kami, yang, pada gilirannya, memberikan respons standar yang berisi alamat IP sebenarnya dari situs jahat, dan juga menunjukkan TTL yang kami butuhkan, dalam hal ini 59.
Selanjutnya, browser membuat permintaan HTTP standar untuk IP yang diterima.
Pada tahap selanjutnya, server merespons dengan halaman HTML dengan kode javascript mengakses domain kita sendiri.
Sekarang, hingga TTL kedaluwarsa dan pengguna di situs, javascript yang diterima di atas akan dieksekusi. Setelah TTL selesai, browser akan kembali meminta A-record.
Saat ini, javascript kami terus berjalan, dan server DNS yang kami kelola akan merespons dengan catatan A dengan alamat IP dari jaringan lokal tempat penyerang ingin menjangkau.
Karena domain, port dan protokol tetap tidak berubah, SOP tidak dilanggar, dan sebagai akibatnya, browser mengakses domain pew.hacker.com, namun, itu sudah akan mengetuk router yang didambakan dan tidak terjangkau.
Sebagai hasilnya, kami dengan tenang menerima respons dari router dan mengalihkannya ke diri kami sendiri dengan menyematkan fungsionalitas yang sesuai dalam kode javascript yang dimuat sebelumnya.
Jadi, mari kita simpulkan hal-hal di atas:
- Pengguna mengunjungi situs, menerima alamat IP asli dan TTL pendek
- Saat berada di situs, browser melakukan panggilan ke domain yang sama di mana pengguna berada. Segera setelah cache kedaluwarsa, browser kembali meminta IP domain.
- Lebih jauh, server DNS kami mengeluarkan alih-alih alamat asli, alamat IP dari layanan internal (dalam kasus kami, router)
- Setelah permintaan melewati domain ke router, dan hasilnya dikirim kepada kami oleh javascript yang dimuat sebelumnya oleh pengguna.
Kami berhasil menemukannya! Banyak yang mungkin memiliki pertanyaan yang masuk akal: "Jadi apa?", Karena untuk operasi Anda perlu mengetahui alamat IP layanan internal, menjaga pengguna untuk waktu tertentu, dll.
Ya, bagaimanapun, dengan munculnya layanan streaming, hosting video, situs porno tua yang baik dan platform lain di mana orang-orang menggantung untuk waktu yang lama, penyerang akan memiliki cukup waktu untuk melakukan serangan. Adapun alamat, mereka sering standar atau mudah diprediksi.
Tapi ini semua dalam teori, tetapi bagaimana dalam praktiknya? Kami memilih 4 area yang paling relevan pada tahun 2019, di mana ada insiden terkait dengan serangan rebinding DNS, ini adalah:
- IoT
- Dompet crypto
- Aplikasi desktop
- Awan
Mari kita melihat setiap topik secara berurutan dan mencari tahu apakah semuanya benar-benar tidak berbahaya?
Iot
Rumah Google
Beranda Google adalah asisten cerdas dari Google. Perangkat ini memiliki (atau dulu) API yang tidak memerlukan otentikasi apa pun untuk mengontrol perangkat. Ini menyediakan sejumlah fitur, seperti:
- Memutar konten
- Pindai
- Mulai ulang
- Koneksi ke jaringan WIFI, dll.
Skenario serangan sampel: penyerang dapat mendanonimisasi pengguna dengan mendapatkan koordinat titik WIFI terdekat. Jelas, tidak ada VPN yang bisa menyelamatkan Anda.
Speaker wifi sonos
Kolom-kolom dari Sonos ini meningkatkan server web di jaringan lokal UPnP, yang memberikan akses ke sejumlah halaman menarik:
- 192.168.1.76:1400/support/review - memuntahkan output dari beberapa perintah UNIX
- 192.168.1.76:1400/tools - memungkinkan Anda menjalankan beberapa perintah UNIX
Dalam hal ini, penyerang memiliki kemampuan untuk mengeksekusi perintah traceroute untuk memindai topologi jaringan internal.
Termostat Radio CT50
Ini adalah salah satu kasus favorit kami. Model termostat ini juga memiliki API tanpa otorisasi apa pun dan memungkinkan Anda untuk mengubah:
- Mode Iklim
- Suhu
- Mode lampu latar dan pengaturan lainnya
Akibatnya, seorang penyerang dapat membuat korbannya banyak berkeringat, tetapi berbicara serius, serangan seperti itu pada termostat, misalnya, di fasilitas medis dapat menyebabkan konsekuensi yang agak tidak menyenangkan.
Roku tv
TV Roku masih memiliki penyakit yang sama - API tanpa otentikasi.
API memungkinkan Anda untuk:
- Jalankan berbagai aplikasi
- Mainkan konten
- Lakukan permintaan pencarian pada sistem, dll.
Dalam hal ini, maksimum yang mengancam pengguna adalah kebocoran data sensitif, yang juga tidak menyenangkan.
Router WIFI apa pun
Hampir setiap orang memiliki perangkat IoT ini sekarang. Bukan rahasia lagi bahwa banyak pengguna biasa tidak mengubah kata sandi standar dari panel admin router mereka. Dengan bantuan DNS rebinding, tidak ada yang menghalangi kami untuk mencoba masuk dengan kredensial standar dan mendapatkan akses ke panel admin. Jika IP lokal tidak dapat ditemukan, WebRTC datang untuk menyelamatkan.
Ringkasan IOT
Kami menyoroti beberapa fitur yang disediakan oleh rebinding DNS ketika bekerja dengan IoT:
- Kemampuan mendeanonimisasi pengguna
- Kemampuan untuk memindai jaringan lokal
- Mock pengguna
- Apa pun, tergantung pada fungsi perangkat IoT
Dompet crypto
Geth
Sekarang mari kita bicara tentang dompet cryptocurrency. Kasus pertama yang diperiksa adalah klien untuk dompet ethereum yang disebut Geth. Di sini kotak Pandora ada di layanan JSON-RPC. Untuk memulai, mari kita cari tahu apa itu. JSON-RPC adalah protokol panggilan prosedur jarak jauh dalam format JSON. Itu semua terlihat seperti ini:
Sebagian besar klien menjalankan layanan ini di localhost: 8545, dan pada gilirannya, menyediakan satu set fungsi yang menarik, seperti eth_sendTransaction dan sebagainya.
Sekarang contoh bagaimana Anda bisa mendapatkan saldo dan alamat dompetnya tanpa sepengetahuan pengguna dan menggunakan serangan rebinding DNS:
Dompet EOSIO keosd
Selanjutnya, kami memiliki klien untuk dompet EOSIO. Keosd sendiri dimulai di localhost: 8900 dan secara otomatis menandatangani tindakan aplikasi apa pun selama 15 menit setelah memasukkan data otorisasi. Setelah mempelajari API, Anda dapat menemukan fungsionalitas yang menarik. Untuk kejelasan, menggunakan permintaan yang ditunjukkan di bawah ini, Anda bisa mendapatkan kunci publik pengguna:
Ringkasan dompet Crypto:
- seorang penyerang dapat mencuri uang pengguna
- seorang penyerang dapat memodifikasi berbagai pengaturan pengguna
- kemampuan mendanonimisasi pengguna
Aplikasi desktop
Klien transmisi
Saya ingin memulai blok insiden yang terkait dengan aplikasi Desktop dengan kerentanan yang relatif sensasional pada klien torrent Transmisi.
Di sini masalahnya terletak pada JSON-RPC yang sama, yang kami periksa sedikit lebih tinggi. Dalam hal ini, ini memungkinkan Anda untuk mengubah pengaturan pengguna, misalnya, mengubah folder untuk mengunduh file:
Di satu sisi, tampaknya tidak ada yang serius, tetapi jika Anda menentukan pangsa seseorang yang dikontrol oleh penyerang alih-alih folder (jika klien menggunakan klien Windows), Anda dapat mencegat hash pengguna, yang dapat digunakan di masa depan.
uTorrent web client
Kamerad ini memiliki gudang layanan JSON-RPC yang sama yang memungkinkan Anda untuk mengubah file konfigurasi pengguna, serta mengunduh file.
Otentikasi diperlukan dalam kasus ini, tetapi kredensial tersedia dari http://localhost:19575/users.conf . Bagaimana ini bisa digunakan?
Pertama, buat permintaan berikut:
Setelah menerima token, kami mengubah folder unduhan ke folder tempat program yang berjalan saat sistem dimulai:
Dan akhirnya, kami memberikan perintah untuk mengunduh muatan yang diperlukan:
Akibatnya, evil.exe akan diluncurkan setelah reboot berikutnya.
Minikube
Minikube adalah utilitas baris perintah untuk mengonfigurasi dan menjalankan klaster Kubernetes mode tunggal di mesin virtual di komputer lokal.
Itu selalu hang pada 192.168.99.100, dan antarmuka berbasis web tersedia di port 3000. Akibatnya, penyerang memiliki peluang untuk membuat wadah jahat dengan folder bersama dengan sistem utama.
Pertama-tama, Anda perlu mendapatkan token csrf.
Selanjutnya, Anda perlu membuat wadah, dan untuk ini kirim permintaan berikut:
Mari kita lihat apa yang dia lakukan. Di dalamnya, kami menunjukkan bahwa ketika memulai wadah kami perlu meneruskan shell terbalik, dan juga me-mount folder Users dari sistem utama:
Ruby on Rails
Ada permata untuk kerangka kerja Ruby on Rails yang memungkinkan Anda untuk mengeksekusi kode Ruby langsung di browser.
Mari kita coba mencari tahu apa yang kita butuhkan untuk ini?
Pertama-tama kita harus pergi ke halaman yang tidak ada:
Selanjutnya, kami mencoba mengakses konsol melalui browser:
Akhirnya, kami membentuk permintaan untuk meluncurkan aplikasi kalkulator (dalam contoh ini, vektor untuk MAC OS X):
Aplikasi desktop blizzard
Tidak hanya pengembang dan pengguna biasa yang rentan terhadap serangan seperti DNS rebinding, tetapi juga gamer. Di sini kita lagi menghadapi masalah layanan JSON-RPC yang menonjol dalam kasus ini pada localhost pada port 1120. Layanan memungkinkan untuk melakukan pembaruan, mengubah pengaturan, dan berbagai opsi layanan lainnya.
Dalam hal ini, otentikasi didukung, tetapi meneruskannya dengan membuat permintaan dari localhost tidak sulit:
Sebagai hasilnya, Anda dapat mencapai sesuatu yang serupa:
Rincian lebih lanjut dapat ditemukan di sini .
Ringkasan Aplikasi Desktop:
- seorang penyerang bisa mendapatkan RCE pada sistem utama (juga jangan lupa tentang VM Escape)
- seorang penyerang bisa mendapatkan akses ke data sensitif, dll.
Awan
Nah, dan akhirnya, hal yang paling menarik tetap - awan. Intinya adalah bahwa layanan cloud sering digunakan untuk meng-host perangkat lunak yang menganalisis pengguna yang datang ke situs. Misalnya, mengklik tautan dari tajuk Referer dengan browser tanpa kepala untuk menuliskan sumber daya tempat klien pergi ke situs. Vektor serangan ini juga dapat digunakan, karena pada dasarnya browser tanpa kepala adalah browser web lengkap tanpa antarmuka grafis, tetapi dengan dukungan untuk DOM, JS dan yang lainnya.
Kembali ke domba jantan kita, apa yang bisa kita lakukan dalam kasus ini? Memang, untuk serangan, kita perlu menunda pengguna (dalam hal ini, bot) di halaman. Nah, untuk ini kita dapat menggunakan gambar pada halaman yang memiliki panjang konten lebih dari yang sebenarnya. Akibatnya, bot akan berpikir bahwa gambar tersebut belum diunggah dan akan tetap ada di halaman kami, dan kemudian kami menggunakan teknik rebinding DNS standar kami.
Akibatnya, karena kami akan mengirimkan permintaan dari proxy, kami dapat melakukan banyak hal lucu. Sebagai contoh:
- memindai jaringan internal
- masuk ke layanan internal (secara teoritis)
- mencuri data otorisasi dari layanan lain, dll.
Ayo langsung ke Amazon. AWS EC2 memiliki fitur seperti Instance Metadata Service. Ini memungkinkan entitas EC2 untuk menggunakan API REST yang terletak di 169.254.169.254, yang mengungkapkan informasi tentang instance.
Misalnya, berikut adalah daftar pendek layanan serupa untuk berbagai cloud:
Sekarang mari kita lihat sebuah kasus di mana kita menikmati AWS.
Pertama, biarkan bot membuat permintaan ke API:
Dalam jawabannya, kita bisa mendapatkan informasi rahasia, misalnya, kredit dalam skrip yang berjalan saat mesin mulai:
Selanjutnya, kita bisa mencabut nama simpul yang akan kita teruskan bekerja:
Selanjutnya, kita akan mengajukan banding berikut dengan nama yang sudah dikenal dan - bingo!
Kami menerima berbagai informasi pengguna, seperti AccessKeyId, SecretAccessKey, Token, dll.
Setelah menerima data ini, kami dapat menggunakannya untuk otorisasi melalui klien konsol:
Hasil total:
Mari kita sorot titik lemah umum yang kami perhatikan saat menggunakan serangan rebinding DNS:
- API tanpa otentikasi
- Layanan lokal tanpa otentikasi
- Mengabaikan parameter Host untuk meminta
- Menggunakan http, bukan https
Dengan demikian, meskipun berbagai argumen dari para ahli di bidang keamanan informasi praktis, serangan jenis ini lahir baru di era IoT, layanan cloud, cryptocurrency dan sebagainya, bahkan meskipun perlu untuk menunda klien di sisi penyerang, karena di dunia bioskop online, hosting video dan layanan lain yang menyediakan konten kepada pengguna, tidak sulit untuk melakukan ini. Karena itu, berhati-hatilah saat bepergian di dunia online, saat membeli asisten pintar lain, dan ketika berkembang, tentu saja.
Sumber: