20 dolara RCE peşindeyken tesadüfen .mobi yöneticisi olma olayı

 (labs.watchtowr.com)
2 puan yazan GN⁺ 2024-09-12 | 1 yorum | WhatsApp'ta paylaş
  • watchTowr Labs, yaklaşık 20 dolara süresi dolmuş dotmobiregistry.net alan adını kaydederek eski .mobi WHOIS sunucusu ana bilgisayar adını kontrol etti ve eski WHOIS istemcileri ile TLS/SSL sertifika doğrulama akışlarının hâlâ bu adrese güvendiğini doğruladı
  • .mobi için resmî WHOIS sunucusu whois.nic.mobi adresine taşınmış olsa da, birçok araç eski adres olan whois.dotmobiregistry.neti hardcode edilmiş şekilde tutup sorgulamayı sürdürüyordu
  • 30 Ağustos 2024'te geçici bir WHOIS sunucusu dağıtıldıktan sonra 4 Eylül'e kadar 135.000'den fazla benzersiz sistemden 2,5 milyon sorgu geldi; bu da terk edilmiş eski alan adlarının gerçek internet altyapısına ne kadar geniş bağlandığını ortaya koydu
  • Bazı TLS/SSL sertifika otoriteleri, .mobi alan adı sahipliğini doğrulamak için WHOIS tabanlı e-posta doğrulaması kullanıyordu; GlobalSign testinde microsoft.mobi için doğrulama e-postası adayı olarak whois@watchtowr.com gösterildi
  • Araştırmacılar gerçek bir kötü amaçlı sertifika çıkarmadı; sonrasında Birleşik Krallık NCSC ve ShadowServer bu alan adını sinkhole'a yönlendirip meşru .mobi WHOIS yanıtlarını proxy'leyecek şekilde önlem aldı

20 dolarlık süresi dolmuş alan adı WHOIS altyapısı olarak yeniden canlandı

  • watchTowr Labs'in asıl hedefi, WHOIS istemcilerinin sunucu yanıtlarını ayrıştırma sürecinde gerçekçi şekilde istismar edilebilecek bir RCE bulmaktı
  • İlk deneylerde WHOIS sunucusu gibi davranıp uzun dizeler döndürdüler ve bazı istemcilerin kolayca çöktüğünü doğruladılar
  • Ancak saldırganın WHOIS yanıtını kontrol edebilmesi için normalde şu koşullardan biri gerekiyordu
    • Ağ katmanında WHOIS trafiğini ele geçiren bir MITM
    • Gerçek WHOIS sunucusuna erişim yetkisi
    • Saldırganın kontrol ettiği bir sunucuya yönlenen bir WHOIS referral
  • Bu önkoşullar gerçek saldırılarda yüksek engel oluşturuyordu; ancak .mobinin eski WHOIS sunucusu alan adının süresi dolunca durum değişti
  • .mobi WHOIS sunucusu geçmişte whois.dotmobiregistry.netten whois.nic.mobiye taşınmıştı ve eski alan adı dotmobiregistry.net yaklaşık Aralık 2023'te süresi dolmuş durumdaydı
  • watchTowr bu alan adını kaydettikten sonra, eski adresi hardcode eden WHOIS istemcilerinin hâlâ sorgu gönderip göndermediğini görmek için whois.dotmobiregistry.net arkasına bir WHOIS sunucusu yerleştirdi

WHOIS sunucu adresinin hardcode edilmesinin oluşturduğu saldırı yüzeyi

  • WHOIS, her TLD için ayrı sunucu kullanıyor ancak istemcinin bu sunucuyu gerçek zamanlı bulmasına yönelik standartlaşmış mekanizma zayıf
  • Uygulamada WHOIS araçlarının, IANA'nın yayımladığı metin listesini referans alıp sunucu adreslerini geliştirme aşamasında hardcode etmesi yaygın
  • Sunucu adresi sık değişmediğinde sorun daha az görünür oluyor; ancak adres değişip eski alan adı süresi dolduğunda, eski istemciler terk edilmiş adrese sorgu göndermeyi sürdürebiliyor
  • watchTowr, lglass sunucusuna gelen WHOIS isteklerine yanıt verdi ve sorgulanan tüm alan adlarının sahibi watchTowr'muş gibi görünen sahte WHOIS bilgileri döndürdü
  • Yanıtlara ASCII art ve sorguların durdurulmasına yönelik bir istek de eklendi

Gözlemlenen sorgu ölçeği ve kaynakları

  • WHOIS sunucusu 30 Ağustos 2024'te devreye alındıktan sonra birkaç saat içinde 76.000'den fazla benzersiz kaynak IP sorgu gönderdi
  • Yaklaşık iki gün içinde SQLite veritabanında 1,3 milyon sorgu birikti ve 4 Eylül 2024 itibarıyla 2,5 milyon sorgu ile 135.000'den fazla benzersiz sistem tespit edildi
  • Sorgu kaynakları arasında büyük alan adı kayıt şirketleri ile WHOIS işlevi sunan siteler vardı
    • domain.com
    • godaddy.com
    • who.is
    • whois.ru
    • smallseo.tools
    • seocheki.net
    • centralops.net
    • name.com
    • webchart.org
  • Güvenlik analiz servisleri de eski .mobi WHOIS sunucusunu kullanıyordu
    • urlscan.io, .mobi alan adı sayfasında ilgili WHOIS sonucunu kullanıyordu
    • VirusTotal, watchTowr'un geçici WHOIS sunucusunu sorgulayıp sonucu gösteriyordu
  • Çok sayıda posta sunucusu ve spam filtresi de tespit edildi
    • Spam filtreleri, gönderen alan adı için WHOIS sorgusu yapabiliyor
    • Bunlar arasında cheapsender.emailden mail.bdcustoms.gov.bd gibi Bangladeş devlet altyapısı izlenimi veren ana bilgisayarlara kadar örnekler vardı
  • .gov ile ilişkili adresler birçok ülkede görüldü
    • Argentina, Pakistan, India, Bangladesh, Indonesia, Bhutan, Philippines, Israel, Ethiopia, Ukraine, USA
    • Brezilya örnekleri arasında antispam.ap.gov.br ve master.aneel.gov.br yer alıyordu
  • .mil kaynakları arasında Swedish Armed Forces örnek olarak verildi
  • .edu ve güvenlik şirketi kaynakları da görüldü; Group-IB, Detectify ve Censys bunlar arasında sayıldı
  • .gov sistemleri ve posta sunucuları .mobi alan adlarından e-posta aldığında WHOIS sunucusunu sorguluyorsa, kimin kiminle iletişim kurduğunu pasif olarak gözlemleme ihtimali doğuyor

Eski WHOIS istemcisi zafiyetleri ve RCE olasılığı

  • watchTowr, WHOIS yanıtı ayrıştırma zafiyetlerine dair önceki örnekleri araştırdı ve ilgili CVE sonuçlarında 26 kayıt içinden yanlış WHOIS yanıtıyla tetiklenebilen hata sayısının yalnızca 3 olduğunu belirtti
  • Bu kadar az örnek bulunması, gerçek istismar için TLD WHOIS sunucusunun kontrolü gibi zor önkoşullar gerektiği düşüncesiyle ilişkili olabilir
  • phpWHOIS CVE-2015-5243, WHOIS sunucusundan alınan veriyi PHP eval ile çalıştırdığı için RCE sağlayabilen bir zafiyet
    • Zafiyetli kod, WHOIS yanıt dizisinde yalnızca \" ifadesini eksik şekilde escape ettikten sonra bunu evale veriyor
    • Netitude analizi, ”;phpinfo();// gibi örnek bir payload veriyor
    • Zafiyetli phpWHOIS sürümleri whois.dotmobiregistry.net adresini hardcode etmişti
  • Fail2Ban CVE-2021-32749, WHOIS çıktısının mail aracına düzgün temizlenmeden aktarılması nedeniyle komut enjeksiyonu mümkün kılan bir zafiyet
    • Fail2Ban, engellenen IP'nin sahibi bilgisini WHOIS ile sorgulayıp yönetici e-postasına ekleyebiliyor
    • Ancak bu zafiyet IP adresi WHOIS sorgularında ortaya çıktığı için, watchTowr'un ele geçirdiği .mobi alan adı WHOIS sunucusu kontrolü tek başına buna doğrudan ulaşamıyor
  • Gerçek kod çalıştırma için yine de hem eski .mobi WHOIS sunucusunu sorgulayan istemciler hem de zafiyetli istemci uygulaması birlikte gerekli

Etki TLS/SSL sertifika doğrulama akışlarına kadar uzandı

  • Bazı TLS/SSL sertifika otoriteleri, alan adı sahipliğini doğrulamak için WHOIS verisindeki yönetici iletişim e-postasını ayrıştırıp bu adrese doğrulama bağlantısı göndermeyi destekliyor
  • watchTowr'un listelediği WHOIS tabanlı sahiplik doğrulamasını destekleyen sertifika otoriteleri veya reseller örnekleri şunlardı
    • Trustico
    • Comodo
    • SSLS
    • GoGetSSL
    • GlobalSign
    • DigiSign
    • Sectigo
  • GoGetSSL testinde, hayali watchTowr.mobi CSR'ı yüklendiğinde watchTowr'un ayarladığı whois@watchtowr.com görünmedi; bunun yerine WHOIS başarısız olmuş gibi duran bir placeholder e-posta gösterildi
  • Entrust testinde microsoft.mobi için meşru WHOIS kaydı ayrıştırıldı ve yalnızca microsoft.com alan adına ait e-posta adresleri doğrulama adayı olarak gösterildi; watchTowr.mobi ise ayrıştırılmadı
  • GlobalSign testinde başlangıçta microsoft.mobi WHOIS kaydını ayrıştıramıyor gibi görünüyordu; ancak watchTowr, meşru WHOIS sunucusundaki microsoft.mobi çıktı biçimini kopyalayıp kendi WHOIS sunucusuna uygun şekilde sunduğunda sonuç değişti
  • GlobalSign, watchTowr'un WHOIS sunucusunu sorguladı ve yanıttaki whois@watchtowr.com adresini ayrıştırarak microsoft.mobi için doğrulama e-postası olarak sundu
  • watchTowr bu noktada durdu ve gerçek bir kötü amaçlı TLS/SSL sertifikası çıkarmadı
  • Teorik saldırı akışı şöyleydi
    • Geçmişte yetkili olan ana bilgisayar adına kötü amaçlı bir WHOIS sunucusu yerleştirmek
    • Hedef .mobi alan adı için TLS/SSL sertifikası satın almaya çalışmak
    • Sertifika otoritesinin WHOIS sorgusu yapıp doğrulama e-postasını gerçek sahip yerine saldırganın e-posta adresine göndermesi
    • Saldırganın bağlantıya tıklayarak hedef alan adının TLS/SSL sertifikasını alması
  • Bu yetenek teoride trafiği ele geçirme veya hedef sunucuyu taklit etme gibi saldırıları mümkün kılabilir

Sonraki önlemler ve kalan sorun

  • Açıklama öncesinde Birleşik Krallık NCSC ile ShadowServer Foundation birlikte müdahale etti
  • dotmobiregistry.net alan adı ve whois.dotmobiregistry.net ana bilgisayar adı, ShadowServer'ın sağladığı sinkhole sistemine yönlendirildi
  • Bu sinkhole, .mobi alan adları için meşru WHOIS yanıtlarını proxy'liyor
  • Etkilenen tarafları bilgilendirmeye yönelik bir süreç de hazırlandı
  • Bu olay, eski altyapı, terk edilmiş alan adları, WHOIS tabanlı işleme ve TLS/SSL sertifika otoritesi doğrulama süreçleri birlikte çalıştığında ortaya çıkan yapısal kusurları gösteriyor
  • MITM yapabilen aktörler de WHOIS verisini sahteleyerek aynı tür saldırıları deneyebilir; sertifika şeffaflığı gibi mekanizmalar bulunsa da büyük ölçekli saldırılarda operasyonel engeller sürüyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-12
Hacker News görüşleri

  • Bu noktaya gelinmesinde birden fazla kişinin hatası üst üste binmiş olsa da, bu spesifik saldırıyı önleyebilecek tek bir şey açık: alan adının süresinin asla dolmasına izin vermemek
    .MOBI üst düzey alan adının WHOIS sunucusu birkaç yıl önce whois.dotmobiregistry.net adresinden whois.nic.mobi adresine taşındı ve dotmobiregistry.net alan adı da görünüşe göre 2023 Aralık civarında süresi dolmuş halde terk edildi
    Bir şirket yıllık 10 dolar diye yeni bir alan adı kullanmaya başladığında, o alan adı fiilen sonsuz dek yılda 10 dolar ödenmesi gereken bir varlığa dönüşür. Bir kez işle bağlanan alan adının o bağını tamamen koparmak mümkün değildir

    • Verisign'ın neden tekel işletmecisi olduğunu ve elektrik ya da su gibi kamusal bir hizmet gibi düzenlenmesi gerektiğini gösteren en açık örnek bu. Seçenek olduğu ve bağımlılık yaratmadığı iddiası neredeyse bir yanılsama; bir alan adını satın alıp kullanmaya başladığınız anda fiilen sonsuza kadar ona bağlı kalırsınız. Verisign da bunu bildiği için tekelini korumak adına umutsuzca savaşıyor
    • Google bile bunu bir kereliğine batırmıştı
      https://money.cnn.com/2016/01/29/technology/google-domain-pu...
    • Her zaman alt alan adı kullanmalısınız. Şirket için, var olduğu sürece yıllık 10 dolarlık tek bir alan adı yeterlidir
    • Bu noktayı seviyorum. Backblaze'in kullanıcı verisini kaybedecek kadar çok diskin bozulma olasılığını hesapladığı blog yazılarını hatırlatıyor
      Sonuçta hesaplanan değerin kendisinin çok da önemli olmadığını düşündüm, çünkü süresi dolmuş kredi kartı ya da spam filtreleme yüzünden yenileme bildirimini kaçırıp ödemeyi unutma olasılığı daha yüksek
      Dev şirketler alan adı ücretlerini ödemeyi nasıl unutmuyor? Bunu pahalı kayıt aracılarına mı bırakıyorlar; üstelik süresi neredeyse “sonsuz” sayılacak yenilemelerle? Oldukça zor bir iş operasyonu problemi gibi görünüyor

  • Bir sabah uyanıp, ücra bir yerdeki otel odasında birinin yakındaki kafenin Wi‑Fi hotspot'una bağladığı bir Raspberry Pi ile bir şeyler yapması yüzünden internetin toptan yok olduğu haberini görecekmişim gibi hissediyorum

    • Üniversite yurdunda birinin evden getirdiği rastgele bir router'ı takıp hatalı DHCP adresleri dağıtarak interneti bozduğu günleri hatırlattı. Sanki onun dünya çapında yaşanan versiyonu gibi
    • Aslında epey çok şey umut ve duaya bağlı duruyor [0], ama internet tasarım gereği sağlam yapılmıştı [1]. Bu olayda kapsam .mobi ile sınırlı kaldı
      [0] https://xkcd.com/2347/
      [1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
    • Bunun yakın zamandaki “White House asks agencies to step up internet routing security efforts” [1] ile bağlantılı olması tamamen tesadüf
      [1] https://news.ycombinator.com/item?id=41482087

  • Araçlar neden WHOIS sunucu listesini hardcode ediyor?
    Bunu DNS'e kaydetmenin standart bir yolu var gibi görünüyor, ama basitçe test edildiğinde pek çok üst düzey alan adında kayıtların eksik olduğu görülüyor. Çalışan örnek dig _nicname._tcp.fr SRV +noall +answer; dönen sonuç da _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.
    Ayrıca bununla ilgili süresi dolmuş bir internet taslağı da var: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...

    • Sadece mobi.whois.arpa. CNAME whois.nic.mobi bile olsa sorun zaten çözülebilirdi. Ama herkesi böyle bir yöntem üzerinde uzlaştırıp benimsetmek zor
      Aşağıda fanf2'nin dediği gibi, IANA WHOIS sunucusuna da sorgu atılabilirdi. https://www.iana.org/whois üzerinde mobi sorgulandığında, yanıtın bir kısmında whois: whois.nic.mobi dönüyor
    • Gerçek dünyada, insanın hayal ettiğinden de, olması gerekenden de çok daha fazla hardcode edilmiş string var
    • WHOIS muhtemelen SRV kaydı kavramından çok daha eskidir
    • Bu araçlar genelde tek seferlik bir ihtiyaç için yazılır ve başkaları kullansın ya da kişi ileride referans alsın diye yayımlanır. Sonra başka “mühendisler” hiç tereddüt etmeden kopyala-yapıştır yapar ve bu üretim ortamına girince bugünkü gibi bir CVE'ye dönüşür
      Geliştirici yetersizliği zaten bir sorun, ama AI halüsinasyonları bu durumu daha da kötüleştirecek

  • Bir alan adını anlamlı bir şekilde bir kez kullanmaya başladıktan sonra, fiilen evrenin ısıl ölümüne kadar, en azından ekibin ısıl ölümüne kadar onu yenilemek gerektiğini fark etmeyen çok fazla ekip gördüm
    İster böyle durumlar olsun, ister bir yerlerde kalmış eski ama kritik bir URL, ister ekipten birinin eski alan adı e-postasıyla bir servise kayıt olması; eski bir alan adını gerçekten bırakmanın güvenli olduğu zamanı bilmek fazlasıyla zor

  • Eski bir WHOIS sunucusunun süresi dolmuş tek bir alan adını satın almanın yarattığı saldırı yüzeyi gerçekten muazzam

  • WHOIS için gerçek çözüm RDAP
    Ne yazık ki ülke kodlu üst düzey alan adları için zorunlu değil ve ülke kodu olmayan üst düzey alan adları arasında da düzgün çalışmayan çok yer var
    https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
    https://resolve.rs/domains/rdap-missing.html

    • Bu, yazıda anlatılan sorunları nasıl hafifletiyor?

  • Gerçekten harika bir çalışma.
    dotmobiregistry.net alan adı ve whois.dotmobiregisry.net ana makine adı artık ShadowServer’ın sağladığı sinkhole sistemini işaret ediyor ve bu sistemin .mobi alan adının normal WHOIS yanıtlarını proxy’lediği belirtiliyor.
    Eğer bu alan adları kullanımdan kaldırılacaktıysa, 404 benzeri yanıtlar döndürmek daha iyi olurdu. Bunları normalmiş gibi çalışır halde bırakmak, resmî alan adına geçiş için teşviki azaltıyor.

    • WHOIS HTTP durum kodlarını desteklemiyor, ama ShadowServer sinkhole’u şu yanıtı veriyor:
      Domain not found.
      >>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<
    • Yazıdan anlaşıldığı kadarıyla bu durum yıllardır zaten bozuktu ve birçok istemci bunu fark etmemiş gibi görünüyor.

  • Bilgisayarlara yönelik genel yaklaşımın kendisinin başarısız olmaya mahkûm olduğunu düşünüyorum. Mükemmel güvenliğe bel bağlıyor ve bu güvenliğin SBOM denetimleri ile sık güncellemeler sayesinde sağlanacağını varsayıyor.
    Ama bu hiçbir zaman böyle olmuyor. Sadece log4j’de bile toplam indirmelerin %40’ı savunmasız sürümler. Tedarik zincirindeki bir şirketin kapanması ya da bir bileşenin bakımının bırakılması durumunda ise söylemeye bile gerek yok.
    Nasıl ki bedenimiz sürekli mikroorganizmalarla bir savaş alanıysa, her şey her zaman hatalarla ve açıklarla dolu olmaya mahkûm.

    • Hayır, yavaş da olsa iyi kod ve güvenilir kod yazmak mümkün; bununla daha iyi araçlar yapmak ve sonra o araçlarla bir sonrakini üretmek de mümkün.
      Muhtemelen onlarca yıl sürecek, ama yol oldukça açık görünüyor. Emek vermek, her türlü “dersten” edinilen bilgiyi uygulamak ve durmamak yeterli.

  • Genel olarak “Biz aslında bunu yapmak istememiştik ama durum giderek büyüdü ve her adımda beklediğimizden daha büyük bir şey elde ettik” havasını sevdim.
    Karşı çıkanlar söyleneni dinleyip ayrıştırmayı düzeltseydi, yazarlar belki de bu kadar uğraşmak zorunda kalmazdı.

  • Buna tersinden bakarsak, dünyadaki tüm WHOIS sunucularının her zaman gerçek ve güvenli olduğuna inanmak mı gerekiyor?
    Özellikle TLS doğrulaması yapan sertifika otoriteleri açısından, whois somethingarbitrary.ru komutunu çalıştırıp Rusya’daki bir sunucu yüzünden uzaktan kod çalıştırma riskine maruz kaldığınızı bilmek isteyeceğiniz bir şey olmazdı.