2 poin oleh GN⁺ 2024-09-12 | 1 komentar | Bagikan ke WhatsApp
  • watchTowr Labs mendaftarkan domain dotmobiregistry.net yang sudah kedaluwarsa dengan biaya sekitar $20, sehingga dapat mengendalikan hostname server WHOIS .mobi lama, dan memastikan bahwa klien WHOIS lama serta alur verifikasi sertifikat TLS/SSL masih memercayai alamat tersebut
  • Server WHOIS resmi .mobi telah dipindahkan ke whois.nic.mobi, tetapi banyak alat masih terus melakukan kueri ke alamat lama, whois.dotmobiregistry.net, yang telah di-hardcode
  • Setelah server WHOIS sementara dideploy pada 30 Agustus 2024, hingga 4 September masuk lebih dari 135.000 sistem unik dan 2,5 juta kueri, memperlihatkan bahwa domain legacy yang terbengkalai masih terhubung luas ke infrastruktur internet nyata
  • Beberapa otoritas sertifikat TLS/SSL menggunakan verifikasi email berbasis WHOIS untuk memeriksa kepemilikan domain .mobi, dan dalam pengujian GlobalSign, whois@watchtowr.com muncul sebagai kandidat email verifikasi untuk microsoft.mobi
  • Para peneliti tidak benar-benar menerbitkan sertifikat berbahaya, dan kemudian NCSC Inggris serta ShadowServer mengambil langkah dengan mengarahkan domain tersebut ke sinkhole agar mem-proxy respons WHOIS .mobi yang sah

Domain kedaluwarsa seharga $20 yang hidup kembali sebagai infrastruktur WHOIS

  • Tujuan awal watchTowr Labs adalah menemukan RCE yang realistis untuk dieksploitasi dalam proses klien WHOIS mem-parsing respons server
  • Dalam eksperimen awal, mereka menyamar sebagai server WHOIS dan mengembalikan string panjang, lalu memastikan bahwa beberapa klien mudah crash
  • Namun, agar penyerang dapat mengendalikan respons WHOIS, biasanya diperlukan salah satu dari hal berikut
    • MITM yang mencegat trafik WHOIS di lapisan jaringan
    • Hak akses ke server WHOIS sebenarnya
    • Referral WHOIS yang mengarah ke server yang dikendalikan penyerang
  • Prasyarat semacam ini menjadi hambatan tinggi dalam serangan nyata, tetapi situasinya berubah ketika domain server WHOIS lama .mobi kedaluwarsa
  • Server WHOIS .mobi sebelumnya dipindahkan dari whois.dotmobiregistry.net ke whois.nic.mobi, dan domain lama dotmobiregistry.net sudah kedaluwarsa sekitar Desember 2023
  • Setelah mendaftarkan domain ini, watchTowr menempatkan server WHOIS di belakang whois.dotmobiregistry.net untuk memeriksa apakah klien WHOIS yang meng-hardcode alamat lama masih melakukan kueri

Permukaan serangan yang diciptakan oleh hardcoding alamat server WHOIS

  • WHOIS menggunakan server terpisah untuk tiap TLD, tetapi mekanisme standar bagi klien untuk menemukan server tersebut secara real-time masih lemah
  • Dalam praktiknya, alat WHOIS umum merujuk ke daftar teks yang dipublikasikan IANA dan meng-hardcode alamat server pada saat pengembangan
  • Ketika alamat server jarang berubah, masalahnya tidak begitu terlihat, tetapi jika alamat berubah dan domain lama kedaluwarsa, klien lama dapat terus melakukan kueri ke alamat yang sudah tidak dipakai
  • watchTowr merespons permintaan WHOIS yang masuk ke server lglass, dan mengembalikan informasi WHOIS palsu yang membuat seolah-olah semua target kueri dimiliki oleh watchTowr
  • Respons tersebut juga memuat ASCII art dan permintaan untuk menghentikan kueri

Skala dan sumber kueri yang teramati

  • Setelah server WHOIS dideploy pada 30 Agustus 2024, dalam beberapa jam saja lebih dari 76.000 IP sumber unik melakukan kueri
  • Selama sekitar dua hari, 1,3 juta kueri terkumpul di DB SQLite, dan per 4 September 2024 terkonfirmasi 2,5 juta kueri serta lebih dari 135.000 sistem unik
  • Sumber kueri mencakup registrar domain besar dan situs penyedia fitur WHOIS
    • domain.com
    • godaddy.com
    • who.is
    • whois.ru
    • smallseo.tools
    • seocheki.net
    • centralops.net
    • name.com
    • webchart.org
  • Layanan analisis keamanan juga menggunakan server WHOIS .mobi lama
    • urlscan.io menggunakan hasil WHOIS tersebut pada halaman domain .mobi
    • VirusTotal melakukan kueri ke server WHOIS sementara watchTowr dan menampilkan hasilnya
  • Banyak server email dan filter spam juga teridentifikasi
    • Filter spam dapat melakukan lookup WHOIS terhadap domain pengirim
    • Termasuk host mulai dari cheapsender.email hingga mail.bdcustoms.gov.bd, yang tampak seperti infrastruktur pemerintah Bangladesh
  • Alamat terkait .gov teridentifikasi dari beberapa negara
    • Argentina, Pakistan, India, Bangladesh, Indonesia, Bhutan, Filipina, Israel, Ethiopia, Ukraina, AS
    • Contoh terkait Brasil mencakup antispam.ap.gov.br dan master.aneel.gov.br
  • Untuk sumber .mil, Swedish Armed Forces muncul sebagai contoh
  • Sumber dari .edu dan perusahaan keamanan juga teridentifikasi, dengan Group-IB, Detectify, Censys, dan lainnya disebutkan
  • Jika server .gov dan server email melakukan kueri ke server WHOIS setiap kali menerima email dari domain .mobi, muncul kemungkinan untuk mengamati secara pasif siapa berkomunikasi dengan siapa

Kerentanan klien WHOIS lama dan kemungkinan RCE

  • watchTowr mencari preseden kerentanan parsing respons WHOIS, dan merangkum bahwa dari 26 hasil pencarian CVE terkait, hanya tersisa 3 bug yang dipicu oleh respons WHOIS yang salah
  • Sedikitnya kasus seperti ini mungkin terkait dengan anggapan bahwa eksploitasi nyata membutuhkan prasyarat sulit seperti kendali atas server WHOIS TLD
  • phpWHOIS CVE-2015-5243 adalah kerentanan yang memungkinkan RCE karena data yang diterima dari server WHOIS dijalankan dengan eval PHP
    • Kode rentan hanya melakukan escaping tidak sempurna terhadap " dalam string respons WHOIS sebelum meneruskannya ke eval
    • Analisis Netitude memberikan contoh payload seperti ”;phpinfo();//
    • Versi phpWHOIS yang rentan meng-hardcode whois.dotmobiregistry.net
  • Fail2Ban CVE-2021-32749 adalah kerentanan yang memungkinkan command injection karena output WHOIS diteruskan ke alat mail tanpa sanitasi yang memadai
    • Fail2Ban dapat mencari informasi pemilik IP yang diblokir melalui WHOIS dan menyertakannya dalam email admin
    • Namun, kerentanan ini terjadi pada lookup WHOIS untuk alamat IP, sehingga tidak dapat dijangkau langsung hanya dengan kendali atas server WHOIS domain .mobi yang diperoleh watchTowr
  • Untuk benar-benar mengeksekusi kode, tetap diperlukan klien yang masih melakukan kueri ke server WHOIS .mobi lama sekaligus implementasi klien yang rentan

Dampak hingga alur verifikasi sertifikat TLS/SSL

  • Beberapa otoritas sertifikat TLS/SSL mendukung metode yang mem-parsing email kontak administratif dari data WHOIS untuk memeriksa kepemilikan domain, lalu mengirim tautan verifikasi ke email tersebut
  • Contoh otoritas sertifikat atau reseller yang mendukung verifikasi kepemilikan berbasis WHOIS yang disebut watchTowr adalah sebagai berikut
    • Trustico
    • Comodo
    • SSLS
    • GoGetSSL
    • GlobalSign
    • DigiSign
    • Sectigo
  • Dalam pengujian GoGetSSL, ketika CSR fiktif watchTowr.mobi diunggah, whois@watchtowr.com yang disetel watchTowr tidak ditampilkan, dan hanya email placeholder yang tampak menunjukkan WHOIS belum berhasil
  • Dalam pengujian Entrust, record WHOIS sah untuk microsoft.mobi diparsing sehingga hanya email dari domain microsoft.com yang tampil sebagai kandidat verifikasi, sementara watchTowr.mobi tidak diparsing
  • Dalam pengujian GlobalSign, awalnya record WHOIS microsoft.mobi tampak tidak dapat diparsing, tetapi hasilnya berubah setelah watchTowr menyalin format output microsoft.mobi dari server WHOIS sah dan menyediakannya melalui server WHOIS mereka sendiri
  • GlobalSign melakukan kueri ke server WHOIS watchTowr, mem-parsing whois@watchtowr.com dari respons, dan menawarkannya sebagai email verifikasi untuk microsoft.mobi
  • watchTowr berhenti pada titik ini, dan tidak benar-benar menerbitkan sertifikat TLS/SSL berbahaya
  • Secara teori, alur serangannya adalah sebagai berikut
    • Menempatkan server WHOIS berbahaya pada hostname lama yang berwenang
    • Mencoba membeli sertifikat TLS/SSL untuk domain .mobi target
    • Otoritas sertifikat melakukan lookup WHOIS dan mengirim email verifikasi ke email penyerang, bukan ke pemilik sebenarnya
    • Jika penyerang mengeklik tautan tersebut, mereka dapat memperoleh sertifikat TLS/SSL untuk domain target
  • Dengan kemampuan ini, serangan seperti penyadapan trafik atau penyamaran sebagai server target secara teori dimungkinkan

Tindak lanjut dan masalah yang tersisa

  • Sebelum publikasi, NCSC Inggris dan ShadowServer Foundation bersama-sama merespons
  • Domain dotmobiregistry.net dan hostname whois.dotmobiregistry.net diarahkan ke sistem sinkhole yang disediakan ShadowServer
  • Sinkhole tersebut mem-proxy respons WHOIS yang sah untuk domain .mobi
  • Prosedur untuk memberi tahu pihak-pihak terdampak juga disiapkan
  • Kasus ini menunjukkan cacat struktural yang muncul ketika infrastruktur legacy, domain terbengkalai, pemrosesan berbasis WHOIS, dan prosedur verifikasi otoritas sertifikat TLS/SSL bekerja bersama
  • Pihak yang mampu melakukan MITM juga dapat memalsukan data WHOIS untuk mencoba jenis serangan yang sama, dan meskipun ada mekanisme seperti Certificate Transparency, serangan skala besar masih menghadapi hambatan operasional

1 komentar

 
GN⁺ 2024-09-12
Komentar Hacker News
  • Meski situasi ini mungkin terjadi karena akumulasi kesalahan banyak orang, ada satu hal yang jelas bisa mencegah serangan khusus ini: jangan pernah biarkan domain kedaluwarsa
    Server WHOIS untuk domain tingkat atas .MOBI dipindahkan beberapa tahun lalu dari whois.dotmobiregistry.net ke whois.nic.mobi, dan domain dotmobiregistry.net tampaknya dibiarkan kedaluwarsa sekitar Desember 2023
    Ketika sebuah perusahaan mulai memakai domain baru dengan alasan biayanya 10 dolar per tahun, domain itu pada dasarnya menjadi aset yang harus dibayar 10 dolar per tahun selamanya. Domain yang sekali terhubung dengan bisnis tidak bisa benar-benar diputus keterkaitannya

    • Ini adalah alasan paling jelas mengapa Verisign merupakan operator monopoli dan seharusnya diregulasi seperti utilitas publik semacam listrik dan air. Klaim bahwa ada pilihan dan tidak ada ketergantungan hampir seperti ilusi; begitu membeli dan mulai memakai domain, pada praktiknya Anda terikat selamanya. Verisign juga tahu itu, sehingga mereka berjuang mati-matian untuk mempertahankan monopolinya
    • Bahkan Google pun pernah sempat mengacaukan hal ini
      https://money.cnn.com/2016/01/29/technology/google-domain-pu...
    • Harus selalu memakai subdomain. Untuk perusahaan, satu domain seharga 10 dolar per tahun sudah cukup sepanjang masa hidupnya
    • Saya suka poin ini. Ini mengingatkan pada tulisan blog Backblaze yang menghitung probabilitas begitu banyak disk gagal hingga data pengguna hilang
      Pada akhirnya, menurut saya hasil perhitungannya sendiri tidak terlalu penting, karena kemungkinan lupa membayar akibat kartu kredit kedaluwarsa atau notifikasi perpanjangan tersaring sebagai spam lebih besar
      Bagaimana perusahaan raksasa tidak lupa membayar biaya domain? Apakah mereka menyerahkan perpanjangan untuk jangka waktu yang nyaris “tak terbatas” kepada registrar mahal? Ini tampak seperti masalah operasi bisnis yang cukup sulit
  • Rasanya suatu pagi nanti saya akan bangun dan melihat kabar bahwa seluruh internet lenyap karena seseorang melakukan sesuatu dengan Raspberry Pi yang tersambung ke hotspot Wi-Fi kafe terdekat dari kamar hotel di tempat terpencil

    • Ini mengingatkan pada kejadian di asrama kampus ketika seseorang mencolokkan router sembarang yang dibawa dari rumah dan merusak internet dengan menyebarkan alamat DHCP yang kacau. Rasanya seperti itu terjadi dalam skala global
    • Memang cukup banyak hal yang bertumpu pada harapan dan doa [0], tetapi internet secara desain dibuat tangguh [1]. Dalam kasus ini, cakupannya terbatas pada .mobi
      [0] https://xkcd.com/2347/
      [1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
    • Ini murni kebetulan saja terkait dengan “White House asks agencies to step up internet routing security efforts” baru-baru ini [1]
      [1] https://news.ycombinator.com/item?id=41482087
  • Mengapa alat-alat memakai daftar server WHOIS yang di-hardcode?
    Tampaknya ada cara standar untuk mendaftarkan ini di DNS, tetapi jika diuji sederhana, banyak domain tingkat atas tidak memiliki record-nya. Contoh yang berfungsi adalah dig _nicname._tcp.fr SRV +noall +answer, yang mengembalikan _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.
    Selain itu, ada juga draf internet yang sudah kedaluwarsa tentang hal ini: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...

    • Sekadar memiliki mobi.whois.arpa. CNAME whois.nic.mobi saja sebenarnya sudah bisa menyelesaikan masalah. Namun, bagian sulitnya adalah membuat semua orang menyepakati dan mengadopsi cara seperti ini
      Seperti yang dikatakan fanf2 di bawah, sepertinya bisa juga dengan menanyakan server WHOIS IANA terlebih dahulu. Jika menanyakan mobi ke https://www.iana.org/whois, sebagian responsnya mengembalikan whois: whois.nic.mobi
    • Di dunia nyata ada jauh lebih banyak string hardcode daripada yang Anda bayangkan, dan daripada yang semestinya ada
    • WHOIS mungkin jauh lebih tua daripada konsep SRV record
    • Alat seperti ini biasanya dibuat untuk kebutuhan sekali pakai, lalu dipublikasikan agar dipakai orang lain atau sebagai referensi bagi pembuatnya di kemudian hari. “Engineer” lain menyalin-tempelnya tanpa ragu, dan ketika itu masuk ke lingkungan produksi, jadilah CVE seperti ini
      Kurangnya kompetensi developer juga masalah, tetapi halusinasi AI akan membuat situasi ini makin buruk
  • Saya sudah terlalu sering melihat tim yang tidak menyadari bahwa begitu sebuah domain mulai dipakai secara bermakna, domain itu pada dasarnya harus diperpanjang hingga kematian panas alam semesta, atau setidaknya hingga kematian panas tim tersebut
    Baik untuk kasus seperti ini, URL lama tetapi penting yang masih tersisa di suatu tempat, maupun anggota tim yang mendaftar ke layanan dengan email domain lama, sangat sulit mengetahui kapan domain lama benar-benar boleh dilepas

  • Permukaan serangan yang muncul hanya dengan membeli satu domain kedaluwarsa dari server WHOIS lama benar-benar luar biasa besar

  • Solusi sebenarnya untuk WHOIS adalah RDAP
    Sayangnya, ini tidak wajib untuk domain tingkat atas kode negara, dan di antara domain tingkat atas non-kode negara pun banyak yang tidak berfungsi dengan benar
    https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
    https://resolve.rs/domains/rdap-missing.html

    • Bagaimana itu memitigasi masalah-masalah yang dijelaskan dalam tulisan tersebut?
  • Pekerjaan yang sangat keren
    Domain dotmobiregistry.net dan hostname whois.dotmobiregisry.net kini mengarah ke sistem sinkhole yang disediakan ShadowServer, dan disebutkan bahwa sistem ini mem-proxy respons WHOIS normal untuk domain .mobi
    Jika domain-domain ini memang akan dihentikan, sebaiknya mereka mengembalikan respons seperti 404. Jika dibiarkan terus berfungsi seolah normal, insentif untuk beralih ke domain resmi akan berkurang

    • Whois memang tidak mendukung kode status HTTP, tetapi sinkhole ShadowServer merespons seperti ini:
      Domain not found.
      >>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<
    • Dari artikelnya, tampaknya ini sudah rusak selama beberapa tahun, dan banyak klien tidak menyadarinya
  • Menurut saya pendekatan komputasi secara umum itu sendiri memang ditakdirkan gagal. Ia bergantung pada keamanan yang sempurna, dan mengasumsikan bahwa keamanan itu dicapai lewat pemeriksaan SBOM dan pembaruan yang sering
    Namun kenyataannya tidak akan pernah begitu. Untuk log4j saja, 40% dari seluruh unduhan masih merupakan versi yang rentan. Belum lagi jika vendor dalam rantai pasok tutup atau berhenti memelihara komponen
    Seperti tubuh kita yang selalu menjadi medan perang melawan mikroorganisme, segala sesuatu pasti selalu penuh bug dan penuh lubang

    • Tidak, secara perlahan tetapi pasti kita bisa menulis kode yang baik dan dapat dipercaya, lalu menggunakannya untuk membuat alat yang lebih baik, dan dengan alat itu membuat yang berikutnya
      Mungkin akan memakan waktu puluhan tahun, tetapi jalannya tampak cukup jelas. Tinggal mencurahkan usaha, menerapkan pengetahuan dari semua “pelajaran” yang didapat, dan tidak berhenti
  • Secara keseluruhan, saya suka nuansa “kami sebenarnya tidak ingin melakukan ini, tetapi situasinya terus membesar, dan di setiap tahap kami mendapatkan sesuatu yang lebih besar dari perkiraan”
    Jika orang-orang yang menentang mau mendengarkan dan memperbaiki parsing-nya, mungkin para penulis tidak perlu bersusah payah seperti ini

  • Kalau dibalik, apakah itu berarti kita harus percaya bahwa semua server WHOIS di seluruh dunia selalu asli dan aman?
    Khususnya dari sudut pandang otoritas sertifikat yang melakukan validasi TLS, mereka tentu tidak ingin mengetahui bahwa menjalankan whois somethingarbitrary.ru membuat mereka terekspos pada eksekusi kode jarak jauh karena server Rusia