$20 में RCE की कोशिश करते-करते गलती से `.mobi` एडमिन बन जाने की घटना

 (labs.watchtowr.com)
2 पॉइंट द्वारा GN⁺ 2024-09-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • watchTowr Labs ने लगभग $20 में एक्सपायर हो चुका dotmobiregistry.net डोमेन रजिस्टर किया, जिससे उसे पुराने .mobi WHOIS सर्वर होस्टनेम पर नियंत्रण मिल गया, और यह पुष्टि हुई कि पुराने WHOIS क्लाइंट और TLS/SSL सर्टिफिकेट वेरिफिकेशन फ्लो अब भी उसी पते पर भरोसा करते हैं
  • .mobi का आधिकारिक WHOIS सर्वर अब whois.nic.mobi है, लेकिन कई टूल अब भी पुराने पते whois.dotmobiregistry.net को hardcoded रखकर क्वेरी भेज रहे थे
  • 30 अगस्त 2024 को अस्थायी WHOIS सर्वर तैनात करने के बाद 4 सितंबर तक 135,000 से अधिक unique systems और 25 लाख क्वेरियां आईं, जिससे पता चला कि छोड़ा हुआ legacy डोमेन अब भी वास्तविक इंटरनेट इन्फ्रास्ट्रक्चर से व्यापक रूप से जुड़ा है
  • कुछ TLS/SSL certificate authorities .mobi डोमेन ownership verification के लिए WHOIS-आधारित email verification का उपयोग कर रहे थे, और GlobalSign टेस्ट में microsoft.mobi के verification email candidate के रूप में whois@watchtowr.com दिखा
  • शोधकर्ताओं ने कोई malicious certificate वास्तव में जारी नहीं कराया, और बाद में UK के NCSC तथा ShadowServer ने उस डोमेन को sinkhole से जोड़कर वैध .mobi WHOIS responses को proxy करने की व्यवस्था की

$20 का एक्सपायर डोमेन WHOIS इन्फ्रास्ट्रक्चर बनकर फिर जीवित हो गया

  • watchTowr Labs का मूल लक्ष्य यह खोजना था कि WHOIS client जब server responses को parse करते हैं, तब कहीं व्यावहारिक रूप से exploitable RCE तो नहीं बनता
  • शुरुआती प्रयोगों में उन्होंने WHOIS server बनकर लंबी strings लौटाईं और देखा कि कुछ clients आसानी से crash हो जाते हैं
  • लेकिन आम तौर पर किसी attacker को WHOIS response नियंत्रित करने के लिए इनमें से किसी एक चीज़ की ज़रूरत होती थी
    • network layer पर WHOIS traffic को intercept करने वाला MITM
    • वास्तविक WHOIS server का access
    • attacker के नियंत्रण वाले server की ओर जाने वाला WHOIS referral
  • ये शर्तें वास्तविक हमले में ऊँची बाधा थीं, लेकिन .mobi के पुराने WHOIS server domain के एक्सपायर हो जाने से स्थिति बदल गई
  • .mobi WHOIS server पहले whois.dotmobiregistry.net पर था और बाद में whois.nic.mobi पर शिफ्ट हो गया, जबकि पुराना डोमेन dotmobiregistry.net लगभग दिसंबर 2023 में एक्सपायर हो चुका था
  • watchTowr ने यह डोमेन रजिस्टर करने के बाद whois.dotmobiregistry.net के पीछे WHOIS server लगाया, ताकि देखा जा सके कि पुराने पते को hardcode किए हुए WHOIS clients अब भी वहां क्वेरी भेजते हैं या नहीं

WHOIS server address की hardcoding से बना attack surface

  • WHOIS में हर TLD के लिए अलग server होता है, लेकिन client उस server को real time में कैसे ढूँढे, इसके लिए standardized mechanism कमजोर है
  • व्यवहार में IANA द्वारा प्रकाशित text list के आधार पर WHOIS tools अक्सर server address को development के समय hardcode कर देते हैं
  • जब server address बहुत कम बदलता है तो समस्या कम दिखती है, लेकिन पता बदलने और पुराना डोमेन एक्सपायर होने पर पुराने clients छोड़े हुए पते पर क्वेरी भेजते रह सकते हैं
  • watchTowr ने lglass server पर आने वाली WHOIS requests का जवाब दिया और नकली WHOIS data लौटाया, जिसमें हर query target का मालिक watchTowr दिखता था
  • response में ASCII art और queries बंद करने का अनुरोध भी शामिल था

देखी गई क्वेरियों का पैमाना और स्रोत

  • 30 अगस्त 2024 को WHOIS server तैनात करने के कुछ ही घंटों में 76,000 से अधिक unique source IPs ने क्वेरी की
  • लगभग दो दिनों में SQLite DB में 13 लाख क्वेरियां जमा हो गईं, और 4 सितंबर 2024 तक 25 लाख क्वेरियां तथा 135,000 से अधिक unique systems दर्ज हुए
  • क्वेरियों के स्रोतों में बड़े domain registrars और WHOIS सुविधा देने वाली साइटें शामिल थीं
    • domain.com
    • godaddy.com
    • who.is
    • whois.ru
    • smallseo.tools
    • seocheki.net
    • centralops.net
    • name.com
    • webchart.org
  • security analysis services भी पुराने .mobi WHOIS server का उपयोग कर रही थीं
    • urlscan.io .mobi domain pages पर वही WHOIS result इस्तेमाल कर रहा था
    • VirusTotal ने watchTowr के अस्थायी WHOIS server को query किया और उसका result दिखाया
  • mail servers और spam filters भी बड़ी संख्या में दिखे
    • spam filter sender domain पर WHOIS lookup कर सकते हैं
    • इनमें cheapsender.email से लेकर mail.bdcustoms.gov.bd जैसे, बांग्लादेशी सरकारी इन्फ्रास्ट्रक्चर जैसे दिखने वाले hosts भी शामिल थे
  • .gov से जुड़े पते कई देशों में देखे गए
    • Argentina, Pakistan, India, Bangladesh, Indonesia, Bhutan, Philippines, Israel, Ethiopia, Ukraine, USA
    • Brazil के उदाहरणों में antispam.ap.gov.br, master.aneel.gov.br शामिल थे
  • .mil स्रोतों में Swedish Armed Forces का उदाहरण भी सामने आया
  • .edu और security vendors के स्रोत भी मिले, जिनमें Group-IB, Detectify, Censys का उल्लेख है
  • अगर .gov सिस्टम और mail servers .mobi domains से email प्राप्त करते समय WHOIS server को query करते हैं, तो कौन किससे संपर्क कर रहा है इसे passively observe करने की संभावना बनती है

पुराने WHOIS client vulnerabilities और RCE की संभावना

  • watchTowr ने WHOIS response parsing vulnerabilities के पुराने उदाहरण खोजे और संबंधित CVE search results में 26 में से गलत WHOIS responses से trigger होने वाले bugs सिर्फ 3 बचे बताए
  • ऐसे कम उदाहरण शायद इस धारणा से जुड़े हों कि वास्तविक exploitation के लिए TLD WHOIS server control जैसी कठिन पूर्वशर्त चाहिए
  • phpWHOIS CVE-2015-5243 एक vulnerability है जिसमें WHOIS server से मिले data को PHP eval से चलाया जाता है, जिससे RCE संभव है
    • vulnerable code WHOIS response string में सिर्फ \" को अधूरे तरीके से escape करके eval को भेजता है
    • Netitude की analysis ”;phpinfo();// जैसा example payload दिखाती है
    • vulnerable phpWHOIS versions में whois.dotmobiregistry.net hardcoded था
  • Fail2Ban CVE-2021-32749 में WHOIS output को mail tool तक ठीक से sanitize किए बिना भेजा जाता था, जिससे command injection संभव थी
    • Fail2Ban blocked IP के मालिक की जानकारी WHOIS से लेकर admin email में जोड़ सकता है
    • लेकिन यह vulnerability IP address के WHOIS lookup में होती है, इसलिए watchTowr को मिला .mobi domain WHOIS server control अकेले इसे सीधे trigger नहीं करता
  • वास्तविक code execution के लिए अब भी ऐसा client चाहिए जो पुराने .mobi WHOIS server को query करे और साथ ही उसकी implementation vulnerable भी हो

असर TLS/SSL certificate verification flow तक

  • कुछ TLS/SSL certificate authorities domain ownership verify करने के लिए WHOIS data से administrative contact email parse करके उस पते पर verification link भेजने का विकल्प देती हैं
  • watchTowr द्वारा सूचीबद्ध WHOIS-आधारित ownership verification समर्थित certificate authorities या resellers के उदाहरण इस प्रकार हैं
    • Trustico
    • Comodo
    • SSLS
    • GoGetSSL
    • GlobalSign
    • DigiSign
    • Sectigo
  • GoGetSSL टेस्ट में काल्पनिक watchTowr.mobi CSR अपलोड करने पर watchTowr द्वारा सेट किया गया whois@watchtowr.com नहीं दिखा, और WHOIS सफल न होने की स्थिति जैसा placeholder email दिखा
  • Entrust टेस्ट में microsoft.mobi का वैध WHOIS record parse हुआ और verification candidates में सिर्फ microsoft.com domain के emails दिखे, जबकि watchTowr.mobi parse नहीं हुआ
  • GlobalSign टेस्ट में शुरू में लगा कि microsoft.mobi WHOIS record parse नहीं हो रहा, लेकिन जब watchTowr ने वैध WHOIS server के microsoft.mobi output format की नकल कर उसे अपने WHOIS server पर परोसा, तो परिणाम बदल गया
  • GlobalSign ने watchTowr के WHOIS server को query किया और response से whois@watchtowr.com parse कर उसे microsoft.mobi के verification email के रूप में पेश किया
  • watchTowr यहीं रुक गया और किसी malicious TLS/SSL certificate को वास्तव में जारी नहीं कराया
  • सिद्धांततः attack flow इस तरह हो सकता है
    • पहले के authoritative hostname पर malicious WHOIS server तैनात किया जाए
    • target .mobi domain के लिए TLS/SSL certificate खरीदने की कोशिश की जाए
    • certificate authority WHOIS query करे और verification mail वास्तविक मालिक की जगह attacker के email पर भेज दे
    • attacker link पर क्लिक करे और target domain के लिए TLS/SSL certificate हासिल कर ले
  • ऐसी क्षमता होने पर traffic interception या target server impersonation जैसे हमले सिद्धांततः संभव हो सकते हैं

बाद की कार्रवाई और बाकी समस्या

  • public disclosure से पहले UK के NCSC और ShadowServer Foundation ने मिलकर प्रतिक्रिया दी
  • dotmobiregistry.net डोमेन और whois.dotmobiregistry.net hostname को ShadowServer द्वारा उपलब्ध sinkhole system से जोड़ दिया गया
  • यह sinkhole .mobi domains के लिए वैध WHOIS responses को proxy करता है
  • प्रभावित पक्षों को सूचित करने की प्रक्रिया भी बनाई गई
  • यह मामला दिखाता है कि legacy infrastructure, छोड़े हुए domains, WHOIS-आधारित processing और TLS/SSL certificate verification procedures साथ मिलकर कैसे structural flaws पैदा कर सकते हैं
  • MITM क्षमता रखने वाला पक्ष भी WHOIS data spoof करके इसी तरह के हमले की कोशिश कर सकता है, और certificate transparency जैसी व्यवस्थाओं के बावजूद बड़े पैमाने के हमलों में operational बाधाएँ बनी रहती हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-09-12
Hacker News की राय

  • इस स्थिति तक पहुंचने में कई लोगों की गलतियां जुड़ी रही होंगी, लेकिन एक बात साफ है जो इस खास हमले को रोक सकती थी: डोमेन को कभी expire न होने दें
    .MOBI top-level domain का WHOIS server कुछ साल पहले whois.dotmobiregistry.net से whois.nic.mobi पर migrate हुआ था, और लगता है कि dotmobiregistry.net domain दिसंबर 2023 के आसपास expire होकर छोड़ दिया गया था
    जब कोई कंपनी सालाना 10 डॉलर कहकर कोई नया domain इस्तेमाल करना शुरू करती है, तो वह domain असल में हमेशा के लिए सालाना 10 डॉलर वाला asset बन जाता है। एक बार किसी domain का business से connection बन जाए, तो उस connection को पूरी तरह खत्म नहीं किया जा सकता

    • यह दिखाने का सबसे साफ कारण है कि Verisign क्यों monopoly operator है और उसे बिजली-पानी जैसी public utilities की तरह regulate किया जाना चाहिए। यह कहना कि विकल्प हैं और lock-in नहीं है, लगभग भ्रम जैसा है; domain खरीदकर इस्तेमाल शुरू करते ही आप व्यावहारिक रूप से हमेशा के लिए उससे बंध जाते हैं। Verisign भी यह जानता है, इसलिए अपनी monopoly बचाने के लिए पूरी ताकत से लड़ता है
    • Google ने भी कभी थोड़े समय के लिए इस मामले में गड़बड़ की थी
      https://money.cnn.com/2016/01/29/technology/google-domain-pu...
    • हमेशा subdomain इस्तेमाल करना चाहिए। किसी कंपनी के पूरे जीवनकाल के लिए सालाना 10 डॉलर वाला एक domain पर्याप्त है
    • यह बात मुझे पसंद आई। Backblaze के वे blog post याद आते हैं जिनमें वे यह calculate करते थे कि इतने disk fail होने की probability कितनी है कि user data खो जाए
      आखिर में मुझे लगा कि calculation खुद ज्यादा मायने नहीं रखता, क्योंकि expired credit card या spam filtering की वजह से renewal notification छूट जाने और payment भूल जाने की संभावना ज्यादा है
      बड़ी कंपनियां domain fee चुकाना कैसे नहीं भूलतीं? क्या वे महंगे registrar को लगभग “infinite” अवधि के renewal का जिम्मा देती हैं? यह काफी कठिन business operations problem लगता है

  • ऐसा लगता है कि किसी सुबह उठूंगा और खबर देखूंगा कि किसी दूर-दराज जगह के hotel room में बैठे किसी व्यक्ति ने पास के cafe Wi‑Fi hotspot से जुड़े Raspberry Pi पर कुछ किया और पूरा internet गायब हो गया

    • university dorm में होने वाली वे घटनाएं याद आती हैं, जब कोई घर से लाया कोई भी router लगा देता था और गलत DHCP addresses बांटकर internet खराब कर देता था। बस वही चीज global scale पर होने जैसा लगता है
    • सच है कि काफी सारी चीजें उम्मीद और दुआओं पर टिकी हैं [0], लेकिन internet design के स्तर पर मजबूत बनाया गया था [1]। इस मामले में scope .mobi तक सीमित था
      [0] https://xkcd.com/2347/
      [1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
    • हाल में “White House asks agencies to step up internet routing security efforts” [1] से इसका संबंध होना पूरी तरह संयोग ही है
      [1] https://news.ycombinator.com/item?id=41482087

  • tools WHOIS server list को hardcode करके क्यों इस्तेमाल करते हैं?
    लगता है DNS में इसे register करने का कोई standard तरीका है, लेकिन simple test करने पर कई top-level domains में record missing हैं। काम करने वाला उदाहरण dig _nicname._tcp.fr SRV +noall +answer है, और _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr. return होता है
    साथ ही, इस पर एक expired internet draft भी है: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...

    • सिर्फ mobi.whois.arpa. CNAME whois.nic.mobi होने से भी समस्या हल हो सकती थी। हालांकि सभी को इस तरीके पर सहमत कराकर adopt करवाना मुश्किल है
      नीचे fanf2 ने जैसा कहा, IANA WHOIS server से पहले query करना भी ठीक हो सकता है। https://www.iana.org/whois पर mobi query करने पर response के हिस्से के रूप में whois: whois.nic.mobi लौटता है
    • reality में, जितना हम सोचते हैं और जितना होना चाहिए, उससे कहीं ज्यादा hardcoded strings मौजूद हैं
    • WHOIS शायद SRV record की concept से भी बहुत पुराना होगा
    • ऐसे tools आम तौर पर one-off जरूरत के लिए बनाए जाते हैं, और फिर दूसरे लोगों के इस्तेमाल या खुद बाद में reference के लिए public कर दिए जाते हैं। दूसरे “engineers” बिना हिचक copy-paste करते हैं, और जब वह production environment में चला जाता है तो इस बार की तरह CVE बन जाता है
      developer skill की कमी भी समस्या है, लेकिन AI hallucination इस स्थिति को और खराब करेगी

  • मैंने बहुत सारी teams देखी हैं जो यह नहीं समझतीं कि किसी domain को meaningful तरीके से एक बार इस्तेमाल करना शुरू कर दिया, तो उसे व्यावहारिक रूप से universe की heat death तक, कम से कम team की heat death तक, renew करना पड़ेगा
    चाहे ऐसा मामला हो, या कहीं बचा हुआ पुराना लेकिन important URL, या किसी team member ने पुराने domain email से किसी service में sign up किया हो—यह जानना बेहद मुश्किल है कि पुराने domain को सच में कब छोड़ा जा सकता है

  • पुराने WHOIS server के एक expired domain को खरीदने भर से बनने वाला attack surface वाकई बहुत बड़ा है

  • WHOIS का असली समाधान RDAP है
    दुर्भाग्य से यह country-code top-level domains के लिए अनिवार्य नहीं है, और non-country-code top-level domains में भी कई जगह यह ठीक से काम नहीं करता
    https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
    https://resolve.rs/domains/rdap-missing.html

    • वह लेख में बताई गई समस्याओं को कैसे कम करता है?

  • बहुत शानदार काम
    dotmobiregistry.net डोमेन और whois.dotmobiregisry.net hostname अब ShadowServer द्वारा दिए गए sinkhole system की ओर इशारा करते हैं, और बताया गया है कि यह system .mobi डोमेन के वैध WHOIS responses को proxy करता है
    अगर ये डोमेन retire किए जाने वाले थे, तो 404 जैसा response लौटाना बेहतर होता। इन्हें सामान्य रूप से चलते रहने देने से आधिकारिक डोमेन पर switch करने की प्रेरणा घट जाती है

    • Whois HTTP status codes support नहीं करता, लेकिन ShadowServer sinkhole इस तरह response देता है:
      Domain not found.
      >>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<
    • लेख को देखकर लगता है कि यह कई सालों से पहले ही टूटी हुई स्थिति में था, और कई clients ने इस पर ध्यान नहीं दिया

  • मुझे लगता है कि computers को लेकर कुल approach ही fail होने के लिए तय है। यह perfect security पर निर्भर है, और मान लिया जाता है कि वह security SBOM जांच और बार-बार updates से हासिल हो जाएगी
    लेकिन ऐसा कभी नहीं होगा। सिर्फ log4j को ही लें, तो कुल downloads में से 40% vulnerable versions के हैं। supply chain में कोई vendor बंद हो जाए या किसी component का maintenance रोक दे, तो बात ही अलग है
    जैसे हमारा शरीर हमेशा microbes के साथ युद्ध का मैदान रहता है, वैसे ही हर चीज हमेशा bugs और holes से भरी रहने वाली है

    • नहीं, धीरे-धीरे लेकिन निश्चित रूप से अच्छा code और भरोसेमंद code लिखा जा सकता है, और उससे बेहतर tools बनाए जा सकते हैं, फिर उन tools से अगली चीजें बनाई जा सकती हैं
      शायद इसमें कई दशक लगेंगे, लेकिन रास्ता काफी साफ दिखता है। मेहनत करनी है, हर “सबक” से मिला ज्ञान लागू करना है, और रुकना नहीं है

  • कुल मिलाकर “हम यह करना नहीं चाहते थे, लेकिन स्थिति बढ़ती गई, और हर चरण में हमें उम्मीद से बड़ी चीज मिलती गई” वाला माहौल अच्छा लगा
    अगर विरोध कर रहे लोगों ने बात सुनी होती और parsing ठीक कर ली होती, तो शायद लेखकों को इतनी मेहनत न करनी पड़ती

  • इसे उलटकर देखें, तो क्या हमें भरोसा करना चाहिए कि दुनिया के सभी WHOIS servers हमेशा असली और सुरक्षित हैं?
    खासकर TLS validation करने वाली certificate authorities के नजरिए से, वे यह जानना नहीं चाहेंगी कि whois somethingarbitrary.ru चलाने पर रूसी server की वजह से वे remote code execution के जोखिम में आ जाती हैं