Kobold पत्र: HTML ईमेल के खतरे

 (lutrasecurity.com)
2 पॉइंट द्वारा GN⁺ 2024-04-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Kobold पत्र

  • जिन लोगों को तकनीकी रूप से HTML ईमेल संभालने पड़ते हैं, वे शायद inconsistent client implementations की वजह से नौकरी छोड़ देने या सभी mail clients को आग लगा देने जैसी भावना तक पहुँच चुके होंगे.
  • HTML ईमेल सिर्फ झुंझलाहट का कारण नहीं हैं, बल्कि गंभीर security risk भी बन सकते हैं.
  • मान लीजिए आपके बॉस ने बड़ी रकम transfer करने वाला ईमेल forward किया है; आपने CEO fraud के बारे में सुना है, इसलिए आप जाँचते हैं कि ईमेल सच में बॉस की ओर से आया है या नहीं.
  • ईमेल वास्तव में बॉस की ओर से हो सकता है, और अगर आपकी कंपनी ऐसा करती है, तो उस पर encrypted signature भी हो सकती है.
  • फिर भी आपको पूरा भरोसा नहीं होता, इसलिए आप बॉस को फोन करके ईमेल की authenticity verify करते हैं.
  • बॉस पुष्टि कर देता है, तो आप पैसे transfer कर देते हैं.
  • लेकिन अगर यह fraud न होता, तो यह लेख यहीं खत्म हो जाता.

Thunderbird

  • इस समस्या की रिपोर्ट 5 मार्च 2024 को Mozilla को की गई थी, और planned release date तथा अगले सेक्शन का draft 20 मार्च 2024 को Mozilla को भेजा गया.
  • संभावित mitigation पर चर्चा हुई, लेकिन उसका implementation बाद में करने की योजना थी.
  • Thunderbird में इसका exploitation आसान है. Thunderbird ईमेल को `

` से wrap करता है और इसके अलावा कुछ नहीं बदलता.

  • जब ईमेल forward किया जाता है, तो quoted ईमेल एक और `

` में wrap हो जाता है और DOM में एक स्तर नीचे चला जाता है.

  • इसे ध्यान में रखते हुए, निम्न proof of concept मिलता है:

      .kobold-letter {
        display: none;
      }
      .moz-text-html>div>.kobold-letter {
        display: block !important;
      }

    This text is always visible.

    This text will only appear after forwarding.
  • ईमेल में हमेशा दिखाई देने वाला टेक्स्ट और display: none; से छिपाया गया टेक्स्ट शामिल है.
  • ईमेल forward करते ही छिपा हुआ टेक्स्ट अचानक केवल नए recipient को दिखाई देने लगता है.

Outlook Web

  • इस समस्या की रिपोर्ट 5 मार्च 2024 को Microsoft को की गई थी, और planned release date तथा अगले सेक्शन का draft 20 मार्च 2024 को Microsoft को भेजा गया.
  • Microsoft ने 26 मार्च 2024 को तुरंत कार्रवाई न करने का फैसला किया और रिपोर्ट बंद कर दी.
  • Outlook Web (OWA) में स्थिति थोड़ी अधिक जटिल है. ईमेल `

` से wrap होता है, लेकिन सटीक class name बदल सकता है.

  • ईमेल की CSS webmailer की styles को प्रभावित न करे, इसके लिए Outlook ईमेल के सभी id और class के आगे x_ जोड़ता है और CSS को उसी हिसाब से adjust करता है.
  • इसे ध्यान में रखते हुए, निम्न proof of concept मिलता है:

      .kobold-letter {
        display: none;
      }
      body>div>.kobold-letter {
        display: block !important;
      }

    This text is always visible.

    This text will only appear after forwarding.
  • OWA में ईमेल दिखाए जाने पर CSS इस तरह दिखती है:
  • ईमेल forward करने के बाद, Kobold पत्र एक और `` में wrap हो जाता है और CSS फिर से update हो जाती है.

Gmail

  • इस समस्या की रिपोर्ट 5 मार्च 2024 को Google को की गई थी, और planned release date तथा अगले सेक्शन का draft 20 मार्च 2024 को Google को भेजा गया.
  • Gmail तकनीकी रूप से Kobold पत्र के प्रति vulnerable नहीं है, क्योंकि ईमेल forward करते समय वह सभी styles हटा देता है.
  • CSS हटने से पहले, ईमेल forward करते समय CSS से छिपाया गया Kobold पत्र अपने-आप दिखाई देने लगता है.

पिछला शोध

  • ऐसी संभावना का होना न तो चौंकाने वाला है और न ही नया.
  • अतीत में इसी तरह की समस्याएँ रिपोर्ट की जा चुकी हैं.

आगे की दिशा

  • उपयोगकर्ता HTML ईमेल को पूरी तरह disable करके या restricted mode में देखकर Kobold पत्र के प्रभाव को कम कर सकते हैं.
  • ईमेल clients के लिए mitigation implement करना कठिन है. `` के उपयोग को रोकना समस्या का समाधान कर सकता है, लेकिन इससे ईमेल ecosystem में पहले से मौजूद कई solutions टूट सकते हैं.
  • दुर्भाग्य से, निकट भविष्य में ईमेल clients के robust mitigation लागू करने की उम्मीद करना यथार्थवादी नहीं है.

GN⁺ की राय

  • यह लेख HTML ईमेल की vulnerabilities दिखाता है, खासकर 'Kobold पत्र' attack के बारे में, जिसमें ईमेल forward होने पर उसकी सामग्री बदल सकती है. यह ईमेल users में security awareness बढ़ाने वाली महत्वपूर्ण जानकारी है.
  • यह दिखाता है कि ईमेल clients CSS को जिस तरह handle करते हैं, उससे security vulnerabilities पैदा हो सकती हैं, और यह users तथा developers दोनों को security के प्रति सतर्क रहने की याद दिलाता है.
  • ऐसे attack खास तौर पर खतरनाक हैं क्योंकि वे किसी trusted source से आए हुए लगते हैं. यह ईमेल के जरिए होने वाले communication में हमेशा सावधान रहने की आवश्यकता पर जोर देता है.
  • तकनीकी दृष्टिकोण से, ईमेल client developers को ऐसे attacks रोकने के लिए CSS processing के तरीके में सुधार करना होगा. लेकिन इससे मौजूदा ईमेल design और compatibility issues पैदा हो सकते हैं, इसलिए सही संतुलन ढूँढना महत्वपूर्ण है.
  • यह लेख नई तकनीक या open source के बारे में नहीं है, लेकिन यह उन बातों की ओर इशारा करता है जिन पर ईमेल security से जुड़ी तकनीक अपनाते समय विचार किया जाना चाहिए. ईमेल client developers को ऐसे तरीके खोजने होंगे जो users की security मजबूत करें और usability भी बनाए रखें.

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

1 टिप्पणियां

 
GN⁺ 2024-04-05
Hacker News राय

  • “However, you are still not convinced, so you call your manager to ensure that the email is legit. He confirms, so you transfer the money.”

    • यह टिप्पणी इस बात पर ज़ोर देती है कि जब ईमेल के ज़रिए पैसे ट्रांसफर करने के अनुरोध पर संदेह हो, तो सिर्फ़ यह न पूछा जाए कि "क्या आपने यह ईमेल भेजा था", बल्कि अधिक ठोस तरीके से पूछा जाए, जैसे "क्या आप सच में चाहते हैं कि मैं पैसे इस तरह ट्रांसफर करूँ"। ऐसा करने से हमले के विफल होने की संभावना बढ़ सकती है। साथ ही, यह भी कहा गया है कि लेख में बताया गया हमला सफल होने के लिए बहुत ही विशेष और सीमित परिस्थितियों पर निर्भर करता है, इसलिए इतने जटिल हमले के वास्तव में सफल होने की संभावना पर संदेह जताया गया है.

  • The other day I was discussing the design for an "update" email that our designer was putting together...

    • यह टिप्पणी ईमेल डिज़ाइन से जुड़ा एक अनुभव साझा करती है। इसमें बताया गया है कि डिज़ाइनर द्वारा बनाए गए ईमेल के graphic header की वजह से subject देखने के लिए नीचे scroll करना पड़ता था, और यह भी हैरानी जताई गई है कि ईमेल forward होने पर mobile version desktop version में बदल जाता है। ईमेल में CSS के इस्तेमाल को ही अनावश्यक बताया गया है, और markdown जैसे सरल text markup के न अपनाए जाने पर असंतोष व्यक्त किया गया है.

  • I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...

    • यह टिप्पणी लंबे समय से इस बात की वकालत करती रही है कि ईमेल में HTML की जगह markdown या इसी तरह का कोई सरल text markup इस्तेमाल होना चाहिए। इससे email client के लिए यह तय करना आसान होगा कि संदेश को rich text के रूप में दिखाना है या plain text के रूप में, और यह उपयोगकर्ताओं की ज़रूरत के अधिकांश formatting को भी समर्थन दे सकता है। इसमें यह भी राय दी गई है कि marketing email में इस्तेमाल होने वाला उन्नत HTML इतना महत्वपूर्ण नहीं है.

  • The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...

    • यह टिप्पणी मज़ाक में कहती है कि HTML email बनाने के लिए नियुक्त developer, Outlook के अलग-अलग rendering व्यवहार की वजह से पागल हो सकता है। साथ ही, ईमेल के ज़रिए होने वाला यह हमला दिलचस्प बताया गया है.

  • Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?

    • यह टिप्पणी सुझाव देती है कि क्या ईमेल में Stylesheets की अनुमति न देकर और केवल tags पर inline style attributes की अनुमति देकर इस समस्या को हल किया जा सकता है। यह भी कहा गया है कि अगर email client में stylesheet को अपने-आप inline style में बदलने का चरण शामिल हो, तो उपयोगिता बेहतर हो सकती है.

  • HTML in email shouldn't be as big of a nightmare as it is.

    • यह टिप्पणी कहती है कि ईमेल में HTML उतना बड़ा दुःस्वप्न नहीं होना चाहिए जितना आज है। इसमें तर्क दिया गया है कि अगर सभी email client text बनाम HTML की जाँच करें और HTML होने पर rendering engine को WebKit पर स्विच कर दें, तो समस्या आसानी से हल हो सकती है। साथ ही, यह पूछा गया है कि क्या इसके लिए कभी कोई standard प्रस्तावित किया गया है.

  • Some possible mitigations from the top of my head (maybe ineffective):

    • यह टिप्पणी ईमेल-आधारित हमले को कम करने के लिए कुछ संभावित उपाय सुझाती है। उदाहरण के तौर पर, hidden elements के बारे में चेतावनी देना, या forward करते समय संदेश का स्वरूप गणना करके यदि उसमें बड़ा बदलाव हो तो पुष्टि माँगना शामिल है.

  • When efail came out, I wrote a blogpost about the security risks of HTML mail.

    • यह टिप्पणी बताती है कि HTML mail के security risks पर एक blogpost लिखा गया था। इसमें कहा गया है कि HTML email specification पुराना है और उसमें security considerations लगभग नहीं के बराबर हैं। सुरक्षित HTML email, HTML का एक subset होना चाहिए, लेकिन वह subset क्या हो, यह किसी ने स्पष्ट रूप से परिभाषित नहीं किया है, इसलिए सुरक्षा खामियाँ लगातार सामने आती रहती हैं.

  • This is really clever!

    • यह टिप्पणी सराहना करती है कि HTML email में CSS का उपयोग करके किसी खास text को केवल संदेश के forward होने के बाद ही दिखाई देना बहुत चतुराई भरा है। इसके कारण verified email की विश्वसनीयता के लिए बड़ा खतरा पैदा हो सकता है। साथ ही, इसमें यह जिज्ञासा भी व्यक्त की गई है कि email client ईमेल सामग्री को अतिरिक्त HTML tags में लपेटकर CSS और class names को क्यों बदलते हैं। यह भी सवाल उठाया गया है कि HTML email को render करने के लिए email client sandboxed iframe का उपयोग क्यों नहीं करते.