SpamChannel: 20 लाख से अधिक डोमेनों से spoofing ईमेल भेजना और व्यावहारिक रूप से शैतान बन जाना [PDF]

 (media.defcon.org)
1 पॉइंट द्वारा GN⁺ 2023-09-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DEFCON 31 2023 की प्रस्तुति SpamChannel में Cloudflare Worker के जरिए ईमेल भेजने की कोशिश के दौरान 20 लाख से अधिक डोमेनों को प्रभावित करने वाली spoofing समस्या पर चर्चा की गई है
  • मुख्य प्रयोग की शुरुआत ईमेल ट्रांसमिशन को मैन्युअल तरीके से नहीं, बल्कि प्रोग्रामिंग तरीके से संभालने और उसे Worker deployment flow से जोड़ने से हुई
  • Cloudflare Workers को JavaScript, TypeScript, WASM आधारित serverless computing environment के रूप में प्रस्तुत किया गया है
  • मूल प्रक्रिया npm create cloudflare@latest से प्रोजेक्ट बनाना और npx wrangler deploy से deploy करना है
  • Workers से ईमेल भेजने का सुराग Cloudflare ब्लॉग की MailChannels integration पोस्ट से मिलता है

SpamChannel प्रस्तुति की शुरुआत

  • SpamChannel DEFCON 31 2023 में Marcello Salvati(@byt3bl33d3r) द्वारा प्रस्तुत एक PDF है, जिसमें 20 लाख से अधिक डोमेनों से spoofing ईमेल भेजने के विषय को कवर किया गया है
  • प्रस्तुति का लक्ष्य निम्न शर्तों के तहत ईमेल ट्रांसमिशन को लागू करना है
    • ईमेल को प्रोग्रामिंग तरीके से भेजना
    • Cloudflare Worker के माध्यम से भेजना
  • कानूनी जिम्मेदारी के संबंध में “अपराध मत करो” जैसी disclaimer भी शामिल है

Cloudflare Workers और ईमेल ट्रांसमिशन के संकेत

  • Cloudflare Workers को serverless computing environment के रूप में पेश किया गया है, और इसमें JavaScript, TypeScript, WASM का उपयोग होता है
  • बुनियादी उपयोग flow इस प्रकार है
    • npm create cloudflare@latest
    • worker.js बनाना
    • npx wrangler deploy
    • deploy के बाद https://<YOUR_WORKER>.<YOUR_SUBDOMAIN>.workers.dev फ़ॉर्मेट के पते पर Worker का उपयोग किया जा सकता है
  • शुरुआती दस्तावेज़ Cloudflare Workers Get started guide से जुड़े हैं
  • ईमेल ट्रांसमिशन का सुराग Cloudflare ब्लॉग की Sending email from Workers with MailChannels पोस्ट में देखा जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2023-09-24
Hacker News की राय

  • प्रेज़ेंटेशन वीडियो: https://www.youtube.com/watch?v=NwnT15q_PS8
    या यह यहाँ भी है। मेरे Firefox में वीडियो फ़ॉर्मैट नहीं चला, लेकिन VLC में प्ले हो गया: https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20vid...

  • SPF इस प्रेज़ेंटेशन में बताए गए तरीकों से कहीं ज़्यादा तरीकों से टूटा हुआ है। ईमेल सुरक्षा हार्डनिंग/डिलिवरेबिलिटी सपोर्ट इंजीनियर के तौर पर काम करते हुए, मेरी सलाह हमेशा SPF के बजाय DKIM + DMARC पर फोकस करने की होती है
    लेगसी कारणों से SPF अभी भी ज़रूरी है, लेकिन डिलिवरेबिलिटी या impersonation रोकने के लिए उस पर निर्भर नहीं रहना चाहिए
    स्लाइड 54 कहती है कि DKIM + DMARC इस अटैक में मदद नहीं करते, लेकिन यह पूरी तरह सही नहीं है
    DMARC p=reject पॉलिसी को सुरक्षित रूप से तभी चालू किया जा सकता है जब आपने सभी delegated senders पर DKIM सेट किया हो, और उस स्तर पर पहुँचने के बाद SPF में ? neutral modifier इस्तेमाल करके third-party senders के लिए SPF हटाना शुरू किया जा सकता है
    उदाहरण के लिए v=spf1 include:relay.mailchannels.net ~all बदलकर v=spf1 ?include:relay.mailchannels.net ~all हो जाता है
    इससे MailChannels से आया मेल DMARC-सक्षम receivers के लिए SPF में neutral माना जाएगा और वे DKIM का उपयोग करेंगे, जबकि पुराने लेगसी मेल सर्विसेज़ को भी neutral result स्वीकार करना चाहिए
    यह परफेक्ट समाधान नहीं है, लेकिन ईमेल वैसे भी कभी 100% भरोसेमंद या सुरक्षित नहीं हो सकता

    • तो फिर SPF की समस्या क्या है, यह जानने की जिज्ञासा है। TCP में source IP spoofing काफ़ी मुश्किल है, इसलिए मुझे हमेशा संदेह रहा है कि DKIM का SPF पर क्या फायदा है
      मैं SPF को सिर्फ़ $myIP की अनुमति देने के लिए सेट करता आया हूँ। मेरे domain name से spam भेजने के लिए पहले ISP या registrar को hack करना होगा, और उस स्तर पर वे मेरे domain का TLS certificate भी ले सकते हैं
      बड़े संगठनों में भी, जिन्हें कई sending systems को allowlist करना पड़ता है, जब DKIM records forge करना संभव नहीं है तो कोई वैध SPF sender में से एक होने का दिखावा कैसे करेगा, यह मुझे समझ नहीं आता
      submitted presentation जैसी स्थिति, जहाँ कोई भी public तौर पर इस्तेमाल कर सकने वाली IP range को allowlist कर देता है, बस मूर्खतापूर्ण configuration है
      पूरे mail exchange को spoof करने के लिए कुछ bytes की एक email पर terabytes traffic चाहिए होगा, और STARTTLS enforce हो तो यह असंभव हो जाता है

  • हम production में Cloudflare Workers + MailChannels इस्तेमाल कर रहे हैं। डराने वाली बात है
    हम पहले से ही CF Workers से असली server पर migrate करने का काम कर रहे थे, अब लगता है MailChannels भी छोड़ना पड़ेगा
    security risk सुविधा जितना क़ीमती नहीं है

    • जून 2023 के बाद से, जब तक आप DNS में _mailchannels record publish नहीं करते, Workers से MailChannels के जरिए email नहीं भेज सकते
    • साफ़ कहें तो, यह issue इस बात में है कि MailChannels sender को इस रूप में authenticate नहीं करता कि वह sending domain का verified owner है। CF Workers समस्या नहीं हैं

  • “DKIM signature नहीं है, लेकिन DKIM implement करने वाले domain से आई हर email पर banner दिखाना” — मेरी समझ में यह ज़्यादातर असंभव है। क्योंकि पक्का जानने का कोई तरीका नहीं है कि किसी domain ने DKIM implement किया है या नहीं
    सिद्धांत रूप में "_domainkey.example.com" पर DNS query करके देखा जा सकता है कि NXDOMAIN आता है या NOERROR। बाद वाला आम तौर पर subdomain होने का संकेत देता है, और इसलिए इसका मतलब हो सकता है कि DNS में कुछ DKIM keys मौजूद हैं
    लेकिन selector name पता नहीं चल सकता, और यह भी नहीं पता चल सकता कि वह key active है या बाद में activate करने के लिए है
    एक domain में कई authenticated senders हो सकते हैं, जिनमें से कुछ DKIM signatures इस्तेमाल करते हों और कुछ नहीं
    सभी DNS servers standard को ठीक से follow नहीं करते, इसलिए NXDOMAIN/NOERROR distinction भी बस मोटे तौर पर ही काम करता है

    • अगर कोई provider mail traffic का statistically significant हिस्सा देखता है, तो वह सभी या लगभग सभी DKIM selectors देख सकता है
      उद्धृत वाक्य का मतलब लगता है कि MailChannels से आए उन mails को reject किया जाए जिनमें DKIM signature नहीं है

  • “MailChannels के मुख्य ग्राहक वे web hosting providers हैं जो भेजी जाने वाली emails के domains के owner नहीं हैं” — यह कुछ समय में सुना गया सबसे खराब बहाना है
    web hosting providers आम तौर पर host किए जाने वाले domains के “owner” नहीं होते, लेकिन वे यह निश्चित रूप से जानते हैं कि वे कौन-से domains host कर रहे हैं। domains को customer account/directory पर route करना ही web hosting का मूल काम है
    ज़रूरत बस इतनी है कि cPanel जैसी integration domain list report करे और हर domain को randomly generated key से bind कर दे
    यह सब end users को परेशान किए बिना automate किया जा सकता है, और किया जाना चाहिए

    • mailing lists का क्या करेंगे? mail forwarding का क्या?

  • अच्छा होगा अगर DMARC specification आगे बढ़कर ऐसा तरीका दे कि validation में SPF नहीं, बल्कि सिर्फ DKIM का इस्तेमाल किया जा सके। अफसोस, Google Calendar invites जैसी चीज़ें अभी भी DKIM में fail हो जाती हैं

    • अगले DMARC release में DMARC validation से SPF को हटाने का option शामिल होने की काफी संभावना है। Google team इसे IETF DMARC mailing list में push कर रही है:
      https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...
      मुझे यह बहुत अच्छा idea लगता है, क्योंकि domain owner DMARC इस्तेमाल करते हुए भी specify कर सकेगा कि “मेरे domain के traffic को सच में authenticate करने वाला mechanism सिर्फ DKIM हो”
      industry में SPF और DMARC की कमजोरियों को bypass करने के कई तरीके हैं, जैसे SPF macros, जो SPF evaluation के समय ही पता चलने वाले criteria के आधार पर authentication को dynamically adjust करते हैं
      लेकिन कोई भी workaround “मेरे domain के लिए कृपया सिर्फ DKIM इस्तेमाल करें” कहने से बेहतर नहीं है

  • हाल ही में मैंने अपने domain के लिए email setup खुद किया, और खासकर उस ISP की वजह से बेहद frustrate हुआ जिसने तय कर रखा है कि “अपने equipment से email भेजने के लिए business account होना चाहिए”; ऐसी बातें सच में गुस्सा दिलाती हैं
    मैं network का responsible member बनने के लिए जी-जान लगाकर कोशिश करता हूँ, और अपने systems को सही तरह से configure करने के लिए current state-of-the-art तक गहराई में जाकर सब समझता हूँ
    लेकिन यह जानकर हैरानी होती है कि ऐसे लोग न सिर्फ मौजूद हैं, बल्कि practically open relay की तरह लापरवाही से चलते हैं, और लगभग आधा Internet उसकी कीमत चुकाता है

  • संक्षेप में, बात यह है कि कई SPF records में शामिल open relays मिले हैं

    • जिन 20 लाख domains ने SPF records के जरिए खुद को open रखा था, उनमें से 1 हज़ार से कम ने DKIM/DMARC records set किए थे, और यहां तक कि DKIM configure करके छोड़ देने पर भी Gmail में वे अब भी authenticated के रूप में pass हो जाते हैं
    • उससे भी बुरा। platform ने खुद domain ownership verification करने की कोशिश तक नहीं की, इसलिए किसी के भी नाम से भेजना संभव था
    • strict sense में यह open relay नहीं है। अगर MailChannels spam और phishing को aggressively control नहीं करता, तो यह Internet पर मौजूद ही नहीं रह पाता
      DEFCON presentation ने किसी बड़े hole के अस्तित्व को prove नहीं किया, बल्कि Internet email के शुरुआती दिनों से मौजूद एक तथ्य दिखाया
      S/MIME या DKIM जैसे message signatures इस्तेमाल न करने पर sender domain को पर्याप्त रूप से authenticate नहीं किया जा सकता
      DKIM होने पर भी DKIM replay attacks के जरिए बड़े पैमाने पर abuse संभव है

  • ARC headers का spam score पर असर दिलचस्प है। एक personal mail server चलाने वाले के तौर पर, क्या सिर्फ अपने emails में बेकार-सा ARC headers का set जोड़ देने से deliverability बढ़ाई जा सकती है?

    • मैं कहना चाहूँगा कि ऐसा नहीं है। क्योंकि अगर यह सच होता, तो अलग-अलग providers में फैले मेरे सभी inbox spam से भर जाते
      organized और knowledgeable spammers इस तरह की हर चीज़ की गहराई से पड़ताल कर रहे होंगे, और निश्चित ही इसे breakthrough के लिए इस्तेमाल कर रहे होंगे
    • email industry ARC को बड़े receivers के spam filters bypass करने का perfect तरीका नहीं मानती। DEFCON presenter ऐसे निष्कर्ष पर पहुँचने के लिए पर्याप्त रूप से तैयार नहीं था

  • लगता है यह मई 2022 में भी पहले ही confirm हो चुका था: https://news.ycombinator.com/item?id=30533032

    • CEO ने शायद ऐसा कहा था:
      “हमारे पास व्यापक spam और phishing detection capabilities हैं और हम abuse handle कर सकते हैं”
      आह, अच्छा :D