MasterCard की DNS टाइपो, लगभग 5 साल तक अनदेखी रही

 (krebsonsecurity.com)
1 पॉइंट द्वारा GN⁺ 2025-01-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • MasterCard ने mastercard.com के कुछ ट्रैफिक को निर्देशित करने वाले Akamai DNS सर्वर नाम में से एक को akam.net के बजाय गलती से akam.ne सेट कर दिया था, और यह टाइपो 30 जून 2020 से 14 जनवरी 2025 तक लगभग 5 साल तक बनी रही
  • सिक्योरिटी रिसर्चर Philippe Caturegli ने देखा कि Niger के country-code top-level domain के तहत akam.ne अनरजिस्टर्ड था, और 300 डॉलर व लगभग 3 महीने लगाकर डोमेन हासिल किया, ताकि इसके दुरुपयोग की संभावना रोकी जा सके
  • akam.ne पर DNS सर्वर चालू करते ही दुनिया भर से रोज़ाना लाखों DNS requests आने लगीं, और यही टाइपो करने वाले संगठनों में MasterCard सबसे बड़ा मामला था
  • अगर इस डोमेन का दुरुपयोग हुआ होता, तो गलत तरीके से रूट हुए ईमेल मिल सकते थे, प्रभावित वेबसाइटों के लिए SSL/TLS certificate हासिल किए जा सकते थे, और कुछ Windows credentials मैन्युअली प्राप्त हो सकते थे
  • MasterCard ने कहा कि “सिस्टम को कोई जोखिम नहीं था” और टाइपो ठीक कर दी, लेकिन बाद में Bugcrowd के जरिए LinkedIn पोस्ट हटाने का अनुरोध होने से disclosure के तरीके पर विवाद बना रहा

लगभग 5 साल तक छोड़ी गई DNS टाइपो

  • MasterCard mastercard.com नेटवर्क के कुछ ट्रैफिक को निर्देशित करने के लिए Akamai के shared 5 DNS servers इस्तेमाल करता है
  • 30 जून 2020 से 14 जनवरी 2025 तक इनमें से एक गलत नाम से सेट था
    • सही सर्वर नाम akam.net पर खत्म होना चाहिए था
    • समस्या वाला कॉन्फिगरेशन akam.ne की ओर इशारा कर रहा था
  • akam.ne पश्चिम अफ्रीका के Niger के country-code top-level domain के प्रबंधन दायरे में आने वाला डोमेन है

रिसर्चर ने पहले डोमेन सुरक्षित किया

  • सिक्योरिटी कंसल्टिंग कंपनी Seralys के संस्थापक Philippe Caturegli ने यह टाइपो खोजी
  • Caturegli ने माना कि akam.ne अभी रजिस्टर्ड नहीं होगा और Niger registry के जरिए डोमेन हासिल किया
    • लागत 300 डॉलर थी
    • रजिस्ट्रेशन में लगभग 3 महीने लगे
  • DNS सर्वर एक्टिवेट करते ही दुनिया भर से हर दिन लाखों DNS requests आने लगीं
  • यही टाइपो सिर्फ MasterCard ने नहीं की थी, लेकिन आने वाली requests के आधार पर वह सबसे बड़ा संगठन था

टाइपो डोमेन से पैदा हो सकने वाले जोखिम

  • अगर Caturegli ने akam.ne पर ईमेल सर्वर चालू किया होता, तो mastercard.com या अन्य प्रभावित डोमेनों की ओर जा रहे गलत तरीके से रूट हुए ईमेल प्राप्त कर सकते थे
  • एक्सेस का दुरुपयोग किया जाता तो प्रभावित वेबसाइटों का ट्रैफिक लेकर आगे भेज सकने वाले SSL/TLS certificate हासिल करने की संभावना भी थी
  • कर्मचारियों के कंप्यूटरों से Microsoft Windows credentials मैन्युअली प्राप्त हो सकने की संभावना भी बनी हुई थी
  • Caturegli ने ऐसे काम करने की कोशिश नहीं की, और MasterCard को बताया कि वे डोमेन उसे सौंप सकते हैं
    • सूचना में Krebs on Security के लेखक को भी reference में शामिल किया गया

MasterCard और Bugcrowd की प्रतिक्रिया

  • MasterCard ने कुछ घंटों बाद गलती स्वीकार की, लेकिन कहा कि operational security को वास्तविक जोखिम नहीं था
    • “सिस्टम को कोई जोखिम नहीं था”
    • “यह टाइपो ठीक कर दी गई है”
  • इसके बाद Caturegli को Bugcrowd के जरिए एक संदेश मिला
    • संदेश का आशय था कि Caturegli द्वारा akam.ne हासिल करने के बाद LinkedIn पर सार्वजनिक रूप से बताना ethical security practices से मेल नहीं खाता
    • इसमें यह भी शामिल था कि MasterCard ने वह पोस्ट हटाने का अनुरोध किया है
  • Caturegli ने जवाब दिया कि उन्होंने Bugcrowd program के जरिए कभी रिपोर्ट नहीं की, और समस्या सीधे MasterCard को रिपोर्ट की थी
  • उन्होंने कहा कि सार्वजनिक disclosure से पहले प्रभावित डोमेन रजिस्टर करके उन्होंने दुरुपयोग रोका, और उसका खर्च भी खुद उठाया

DNS cache से बढ़ सकने वाला प्रभाव क्षेत्र

  • आम तौर पर संगठन कम से कम 2 authoritative DNS servers रखते हैं, लेकिन जिन संगठनों पर requests अधिक आती हैं वे load balancing के लिए अधिक DNS server domains इस्तेमाल करते हैं
  • MasterCard 5 DNS servers इस्तेमाल करता है, इसलिए ऐसा लग सकता है कि attacker उनमें से सिर्फ एक पर कब्ज़ा करे तो कुल DNS requests का लगभग पांचवां हिस्सा ही देख पाएगा
  • असल इंटरनेट यूजर्स Cloudflare या Google जैसे public DNS resolvers पर निर्भर होते हैं, इसलिए प्रभाव बड़ा हो सकता है
    • बस एक resolver गलत nameserver से query करे और result cache कर ले
    • DNS record में लंबा TTL सेट करने पर बड़े cloud providers के जरिए गलत निर्देश फैल सकते हैं
  • Caturegli के अनुसार लंबा TTL इस्तेमाल करने पर traffic rerouting का दायरा सिर्फ पांचवें हिस्से से कहीं अधिक हो सकता है

समस्या वाला subdomain और पुराने registration के निशान

  • Caturegli द्वारा साझा किए गए screenshot में गलत सेट किया गया DNS server MasterCard के az.mastercard.com subdomain से जुड़ा है
  • यह subdomain वास्तव में कैसे इस्तेमाल होता है, यह स्पष्ट नहीं है
  • नामकरण नियमों के आधार पर यह Microsoft Azure cloud के production servers से जुड़ा डोमेन लगता है, और Caturegli ने कहा कि ये डोमेन Microsoft internet addresses में resolve होते हैं
  • akam.ne पहले भी रजिस्टर्ड रह चुका है
    • दिसंबर 2016 में um-i-delo@yandex.ru ईमेल इस्तेमाल करने वाले एक यूजर ने इसे रजिस्टर किया था
    • Yandex ने दिखाया कि यह अकाउंट Moscow के “Ivan I.” का है
    • DomainTools.com के passive DNS records के अनुसार यह 2016 से 2018 तक Germany के internet server से जुड़ा था, और 2018 में expire हो गया
  • एक पूर्व Cloudflare कर्मचारी ने Caturegli की LinkedIn पोस्ट के comments में मिलते-जुलते मामले पर एक report link की
    • यह ऐसे टाइपो डोमेन का मामला था जिसमें कुछ संगठनों ने AWS DNS server awsdns-06.net को शायद गलती से awsdns-06.ne टाइप किया था
    • DomainTools के अनुसार यह टाइपो डोमेन भी एक Yandex user के नाम रजिस्टर्ड था और उसी German ISP, Team Internet, पर hosted था

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

1 टिप्पणियां

 
GN⁺ 2025-01-23
Hacker News की राय

  • इस मामले की तरह सार्वजनिक रूप से रजिस्टर किए जा सकने वाले nameserver, dangling DNS समस्या का सिर्फ एक अपेक्षाकृत दुर्लभ उप-प्रकार हैं; ज्यादा आम मामला यह है कि domain सीधे किसी cloud provider के ऐसे IP address पर map हो, जिसे attacker हासिल कर सकता है
    cloud services का scope बड़ा होता है और अक्सर global visibility की कमी होती है, इसलिए cloud इस्तेमाल करने वाली कंपनियों के किसी-न-किसी subdomain में ऐसी vulnerability होने की संभावना काफी होती है
    bug bounty programs अक्सर “subdomain takeover” को blanket रूप से exclude कर देते हैं, लेकिन मिल जाने पर इसका आसानी से दुरुपयोग किया जा सकता है, और ऐसी configuration गलतियों से sensitive information लीक होने वाला internal और public data भी मौजूद है
    मौजूदा vulnerability disclosure माहौल में कंपनियों के लिए वास्तविक vulnerabilities को स्वीकार करने से बचना बहुत आसान है, और अच्छे इरादे वाले researchers के लिए ethical और legal constraints के कारण provider द्वारा मांगे गए स्तर का proof देना मुश्किल हो जाता है
    यह जोखिम भी कम आंका जा रहा है कि ऐसी vulnerabilities से वास्तव में TLS certificate issuance आसानी से संभव हो जाता है
    [1] https://dl.acm.org/doi/pdf/10.1145/2976749.2978387
    [2] https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf
    [3] https://pauley.me/post/2022/cloud-squatting/
    [4] https://arxiv.org/pdf/2204.05122

    • सिर्फ IP नहीं, बल्कि “ऐसे DNS records जो shared cloud resources की ओर point करते हैं जिन पर संगठन का अब नियंत्रण नहीं है” वाली समस्या भी एक बहुत बड़ी category है, और कंपनी जितनी बड़ी होती है यह उतनी ही ज्यादा फैली होती है
      उदाहरण के लिए, release हो चुके S3 bucket की ओर point करने वाला CNAME, Azure Website/WebApp instances, non-elastic IP की ओर point करने वाला A record, Route53 nameservers जो अब संगठन के AWS account से संबंधित नहीं हैं, delete या deactivate किए गए Heroku/Shopify/GitHub Pages accounts, और बंद हो चुकी transactional email कंपनी के domain की ओर point करने वाले MX records वगैरह
      कारण यह है कि IT decentralization की वजह से infrastructure ऐसे लोग बनाते हैं जिन्हें पूरी जानकारी नहीं होती, dismantle करते समय DNS भूल जाते हैं, subsidiaries/brands/regional organizations ज्यादा होने से policies की discovery और enforcement कठिन हो जाती है, देश-वार websites/apps बहुत होती हैं, और security team को बताए बिना इस्तेमाल किए गए external vendors जमा होते जाते हैं
      मैं इस क्षेत्र की एक Israeli cyber security company में Field CTO के तौर पर काम करता हूं; कल ही एक बड़ी computer components company और उनके domains, PageRank और links का इस्तेमाल करके “operate” हो रही करीब 12 Indonesian gambling sites के बारे में बात कर रहा था, और ऐसी बातचीत हर हफ्ते दोहराई जाती है
    • bug bounty का सभी “subdomain takeover” को invalid मान लेना बहुत generalized response है; इसे इस आधार पर अलग करना चाहिए कि domain हासिल करना कितना आसान है
      “अगर आप किसी तरह google.com takeover कर लें तो Google users compromise हो सकते हैं” कोई valid security vulnerability नहीं है, लेकिन अगर यहां की तरह unregistered/expired domain takeover compromise तक ले जाता है, तो उसे valid vulnerability माना जाना चाहिए
    • अगर bug bounty disclosures अपने-आप government agencies जैसे FCC को भी report हों और संबंधित company email cc में हो, तो यह ज्यादा effective हो सकता है
      अगर कंपनी report reject करना चाहती है तो उसे स्पष्ट evidence देना पड़े, और अगर उस report से निकला exploitation prove हो जाए या कंपनी बदलाव कर दे जिससे report की reproduction steps अब काम न करें, तो उसे bounty payment या fine के दायरे में लाया जा सकता है
    • किसी cryptocurrency exchange में application-level control के बिना, ज्यादा तेज load balancer तक पहुंच सकने वाले IP addresses को allowlist के रूप में manage किया जाता था
      बहुत सारे cloud IP allocate करके और बार-बार पुराने IP खोजकर, original से कहीं ज्यादा capacity हासिल कर ली गई और higher rate limits के साथ requests भेजी गईं
      अब शायद यह काम नहीं करेगा, और अब यह तरीका सबको पता है

  • इस कहानी में Bugcrowd वाला हिस्सा अप्रत्याशित है
    mail screenshot ऐसा लगता है जैसे वह “Platform Behavior Standards Team” से आया हो; अगर ऐसा है, तो या तो Bugcrowd ने platform के बाहर के behavior को regulate करने के लिए platform standards की बहुत व्यापक व्याख्या की, या Mastercard ने official Bugcrowd employee का impersonation किया
    दोनों में से कोई भी बात खास स्वीकार्य नहीं लगती
    [1] https://www.bugcrowd.com/resources/hacker-resources/platform...

    • एक interpretation यह है कि Bug Bounty platforms responsible disclosure को encourage करने के बजाय, उसे capture और block करने के लिए मौजूद हैं
      जो व्यक्ति अक्सर यह दावा करता था, वह देखे तो शायद इसे और अच्छी तरह समझा सकता है
    • wording भी बहुत खराब है
      यह ऐसे लिखा है जैसे पहले ही तय हो चुका हो कि गलती हो चुकी है, और विकल्प सिर्फ comply करना या यह पूछना है कि यह गलत क्यों है, इसकी अतिरिक्त explanation मांगी जाए
      यह समझाने का मौका नहीं है कि गलती मेरी नहीं है
    • मेरे अनुभव में BugCrowd report को actual company तक पहुंचने में delay कराने और उसे दलदल में फंसाने के लिए सब कुछ करता है
      कंपनी के नजरिए से bounty payment और internal review cost घटती है, और legally plausible deniability भी मिल जाती है
    • यहां Bugcrowd के कर्मचारी भी होंगे, तो वे उस email को explain कर सकते हैं

  • “कोई वास्तविक खतरा नहीं था” जैसे response से अगली बार security researchers इस कंपनी या दूसरी कंपनियों में impact evidence ज्यादा इकट्ठा करने के लिए और गहराई तक intrusion करने लग सकते हैं
    अगर आप चाहते हैं कि company spokesperson “कोई समस्या नहीं” कह सके, तो impact को कम करके आंका जाए तब भी researchers को स्वीकार्य हो इतना पर्याप्त compensation देना चाहिए
    researcher ने पहले ही सही तरीके से behave किया हुआ दिखता है, फिर भी news दबाने के लिए researcher पर दबाव डालना—क्या credit card company के पास ऐसा करने की कोई वजह थी, या यह PR प्रभारी की गलत job understanding थी, या information security mistake के लिए अंतिम जिम्मेदार व्यक्ति ने अपने tenure में embarrassment से बचने के लिए company resources इस्तेमाल किए—यह सवाल है

    • वजह है
      वे security researchers को अपने findings public करने से डराना चाहते हैं

  • कुछ साल पहले यूक्रेन में सभी या ज़्यादातर online transactions को masterpass नाम की सेवा से verify होना पड़ता था, और यह Mastercard के 3DS जैसा लगता था
    लेकिन corporate web में अक्सर जैसा होता है, SSL certificate expire हो गया, और उस पल से खास तरह के MasterCard cards से होने वाले सभी या ज़्यादातर online transactions पूरी तरह रुक गए
    Mastercard ने एक साल से ज़्यादा समय तक certificate renew नहीं किया, और customer के रूप में मेरी या bank IT department की कितनी भी कोशिशों के बावजूद संपर्क करने का कोई फायदा नहीं हुआ; बाद में उन्होंने service को चुपचाप बंद कर दिया
    देखने पर पता चला कि service Microsoft stack (IIS) पर लिखी गई थी, certificate chain अजीब तरह से लंबी थी और उसमें ऐसे intermediate certificates थे जिनका नाम कभी नहीं सुना था, और यह यूक्रेन से काफी दूर किसी third-world देश में host की गई थी

    • masterpass Mastercard का 3DS version है, और जब transaction suspicious लगे तो इसे globally इस्तेमाल किया जाता है
      Mastercard के नज़रिए से शायद उस देश की सभी transactions, भले ही पूरी तरह local parties के बीच हों, default रूप से suspicious मानी जाती थीं
      अमेरिका में मैंने इसे expired होते कभी नहीं देखा, और country-wise traffic processing कैसे होती है यह नहीं जानता, लेकिन सुनने में ऐसा लगता है कि traffic Mastercard के बजाय कहीं और route हो रहा था

  • यह बात खटकती है कि akam.ne को 2016 में Moscow के “Ivan I.” नाम के व्यक्ति ने Yandex email से register किया था, 2016–2018 के दौरान यह German servers से जुड़ा रहा और फिर expire हो गया
    इसी तरह AWS DNS server awsdns-06.net को गलती से awsdns-06.ne लिखने वाली organizations को target करने वाला typosquatting domain भी Yandex account से register हुआ था, और उसी German ISP Team Internet (AS61969) पर host था—यह हिस्सा खास तौर पर संदिग्ध है

    • “Ivan I” का मतलब संभवतः रूसी fake common name Ivan Ivanov है, जो English में “John Smith” जैसा नाम है

  • “अगर access का दुरुपयोग किया गया होता तो affected websites का traffic receive और relay करने के लिए SSL/TLS certificates हासिल किए जा सकते थे” और “हमारे systems को कोई खतरा नहीं था”—इन दोनों में से एक बात गलत होनी चाहिए
    दोनों पक्षों के पास झूठ बोलने या बढ़ा-चढ़ाकर कहने की वजहें हैं

    • एक पक्ष के पास अरबों डॉलर के पैमाने पर झूठ बोलने/बढ़ा-चढ़ाकर कहने की वजह है, और दूसरा पक्ष दिन भर sophisticated attackers के worst-case scenarios के बारे में सोचता है
      अगर बात CS:GO server की हो तो sophisticated attacker का worst attack बढ़ा-चढ़ाकर बताया जा सकता है, लेकिन दुनिया की सबसे बड़ी payment processing companies में से एक की बात हो तो यह अतिशयोक्ति नहीं है
    • certificates कैसे issue होते हैं, इसका ज़रा भी ज्ञान हो तो समझ आ जाएगा कि researcher सही है और MasterCard बकवास कर रहा है
      10 मिनट की research भी यही निष्कर्ष देगी
    • अगर कोई impact नहीं है, तो उसे उसके capture किए हुए DNS queries की पूरी list public करने की अनुमति दे दें
      ऐसा न करने की वजह यही है कि वह list malicious actors को infrastructure के clues देगी
      MasterCard या तो झूठ बोल रहा है, या अज्ञानी और अक्षम है
    • मुख्य बात काफी हद तक इस पर निर्भर करती है कि az.mastercard.com असल में क्या है और क्या करता है
      x@mastercard.com पर जाने वाले email receive करने वाली बात सही नहीं लगती, और यह बस एक subdomain है जिसका purpose पता नहीं है
      TLS शायद संभव होगा, लेकिन risk इस बात पर निर्भर करता है कि वह domain क्या है, और mastercard.com visit करने वाले users पर इसका सीधा असर शायद नहीं पड़ेगा
    • SSL/TLS certificate की बात हो तो सबसे पहले ACME-based certificate providers याद आते हैं
      domain DNS control होना ही काफी है, और TXT record या अपने control वाले HTTP server पर request भेजने का तरीका संभव है

  • यह साफ तौर पर Mastercard की बड़ी गलती है, लेकिन मूल top-level domain से सिर्फ एक अक्षर अलग domain को मौजूद रहने देना भी अपने आप में गलती जैसा लगता है
    जैसे .com और .co, .net और .ne; यह खुद समस्या बुलाने वाली structure है
    अगर ऐसे domains होते ही नहीं, तो register भी नहीं किए जा सकते थे और गलत DNS requests बस कहीं नहीं जातीं

    • ज़रूरी नहीं
      typo सिर्फ top-level domain में नहीं, name के किसी भी हिस्से में हो सकता है, और typo न भी हो तो popular site names से 1-bit अलग domains पकड़ने वाली bitsquatting से तरह-तरह की computer errors से traffic मिल सकता है
      examples वाला paper भी है
      [1] https://en.wikipedia.org/wiki/Bitsquatting
      [2] https://www.securitee.org/files/bitsquatting_www2013.pdf
    • किसी बड़ी company से उम्मीद थी कि वह Markmonitor के जरिए इस issue को handle करेगी
      मूल रूप से edit distance 1 वाले typo domains को जितना संभव हो साथ में register करके रखने का तरीका है
      Wikipedia के मुताबिक Akamai, Markmonitor customers में से एक है, इसलिए यह हैरानी की बात है कि यह domain पहले से registered नहीं था
    • सवाल है कि Niger और Colombia के ISO 3166-2 codes का क्या किया जाएगा
    • समझ नहीं आता कि यह किसी sensitive phone number से सिर्फ एक digit अलग phone number मौजूद होने से कैसे अलग है
    • ISO 3166-1 alpha-2 top-level domains निश्चित रूप से उपयोगी हैं, लेकिन address space की प्रकृति के कारण एक अक्षर वाली typos बहुत होती हैं
      non-country code domains भी country code top-level domains से एक अक्षर हटे हुए रूपों से overlap कर सकते हैं, इसलिए बड़ा अंतर नहीं है
      हालांकि ऐसी configuration errors अच्छे DNS checking tools पकड़ सकते हैं
      यह इस तरह दिखता है कि registered nameservers में से कोई resolve नहीं होता, या nameservers एक ही zone serial number या actual response return नहीं करते
      .is में domain register करने के लिए सही से काम करने वाले 2 nameservers देने पड़ते थे, लेकिन .com अब इतना सख्त नहीं है

  • वह domain name akamai को सौंप देना चाहिए था
    उसी address पर दूसरे requests भी आ रहे हैं, और akamai को इसे जिम्मेदारी से handle करना चाहिए

  • “हमने खुद अपनी जांच की और पाया कि हमारी कोई गलती नहीं थी” एक classic response है
    Mastercard एक multi-billion-dollar public company है जिसके पास दुनिया भर में कम से कम 3.4 अरब branded cards हैं, और जिसने 2024 की तीसरी तिमाही में global credit, debit और cash transactions के 44.3 अरब transactions process किए
    गलती स्वीकार करना market में short term में नुकसानदेह हो सकता है, लेकिन denial की culture company culture को खराब कर देती है
    यह ClownStrike से अलग नहीं है, और predatory, parasitic credit/debit networks में उथल-पुथल आने का समय हो गया है

  • “टाइपो ठीक कर दिया गया है और सिस्टम को कोई जोखिम नहीं था” जैसी बातें हमेशा एक जैसी होती हैं, और ऐसे बयान सच में गुस्सा दिलाते हैं

    • उनका हिसाब शायद ऐसा होगा
      समस्या मान लेने पर शेयर कीमत में लाखों डॉलर उड़ सकते हैं, लेकिन इनकार करने पर बस कुछ geeks थोड़ी और शिकायत करेंगे
      breach के सबूत के बिना मजबूर करना मुश्किल है, और अगर breach के सबूत हों तो जेल जाना पड़ेगा
    • असल मतलब कुछ ऐसा है: “हमने IT विभाग के एक ऐसे कर्मचारी से बात की जिसे कुछ पता नहीं था; उस कर्मचारी के पास exposure खोजने का कोई निजी incentive नहीं था, और वह 15 सेकंड में exploit करने का तरीका नहीं सोच पाया”
      जो लोग सच में जानते हैं, वे शायद ही कभी इतना सुरक्षित महसूस करते हैं कि पक्के तौर पर कह दें कि किसी चीज़ का exploit नहीं हो सकता