Kobold letters: HTML ईमेल के खतरे

 (lutrasecurity.com)
2 पॉइंट द्वारा GN⁺ 2024-04-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Kobold letters एक अटैक तकनीक है जिसमें HTML ईमेल शुरुआत में हानिरहित दिखता है, लेकिन फ़ॉरवर्ड होने के बाद दूसरे प्राप्तकर्ताओं के लिए फ़िशिंग संदेश में बदल सकता है
  • इसका मुख्य आधार ईमेल क्लाइंट द्वारा अनुमति दी गई CSS और फ़ॉरवर्डिंग प्रक्रिया में बदलने वाली DOM स्थिति है, जिनका उपयोग कुछ वाक्यों को छिपाने या फिर से दिखाने के लिए किया जाता है
  • Thunderbird और Outlook on the web में DOM संरचना और CSS री-राइटिंग के कारण फ़ॉरवर्ड होने के बाद छिपे हुए वाक्य दिखाई दे सकते हैं, जबकि Gmail में फ़ॉरवर्ड करते समय styles हटने से और भी सरल रूप में एक्सपोज़र संभव है
  • Mozilla, Microsoft और Google को यह समस्या 5 मार्च 2024 को रिपोर्ट की गई थी; Microsoft ने 26 मार्च को बिना तत्काल कार्रवाई के रिपोर्ट बंद कर दी, और Google ने 9 अप्रैल को पुष्टि की कि फ़िक्स पर काम चल रहा है
  • उपयोगकर्ता HTML ईमेल को बंद कर सकते हैं या restricted mode में देख सकते हैं, लेकिन `` को ब्लॉक करना मौजूदा ईमेल ecosystem के कई use cases को तोड़ सकता है, इसलिए क्लाइंट-स्तर पर mitigation आसान नहीं है

अटैक परिदृश्य और मुख्य विचार

  • एडमिन द्वारा फ़ॉरवर्ड किया गया ईमेल शुरुआत में हानिरहित inquiry mail जैसा दिख सकता है, लेकिन फ़ॉरवर्ड होने के बाद नए प्राप्तकर्ता को फ़िशिंग अनुरोध के रूप में बदल सकता है
  • प्राप्तकर्ता के लिए भेजने वाला कोई जाना-पहचाना व्यक्ति होता है, और कुछ मामलों में उस पर cryptographic signature भी लगा हो सकता है; फ़ोन पर फ़ॉरवर्ड होने की पुष्टि करने पर भी वह धोखा खा सकता है
  • मूल प्राप्तकर्ता एडमिन को अपने द्वारा फ़ॉरवर्ड किए गए ईमेल में फ़िशिंग वाला वाक्य दिखता ही नहीं, इसलिए फ़ॉरवर्ड की पुष्टि करने पर भी उसके लिए अटैक को पहचानना मुश्किल होता है

Kobold letters कैसे काम करते हैं

  • ज़्यादातर ईमेल क्लाइंट HTML ईमेल में CSS styling की अनुमति देते हैं
  • जब ईमेल फ़ॉरवर्ड होता है, तो मूल ईमेल की DOM position आमतौर पर बदल जाती है, और हमलावर इसी बदलाव के आधार पर CSS selectors लागू करता है
  • हमलावर ईमेल में ऐसे elements डाल सकता है जो context के अनुसार दिखें या गायब हो जाएँ
    • सामान्य स्थिति में display: none; से छिपे रहते हैं
    • फ़ॉरवर्ड होने के बाद DOM संरचना बदलने पर display: block !important; जैसे नियम से दिख जाते हैं
  • ऐसे elements सामान्यतः दिखाई नहीं देते, लेकिन केवल खास परिस्थिति में प्रकट होते हैं और फ़िशिंग जैसी गतिविधियों में दुरुपयोग हो सकते हैं; इसी वजह से इन्हें kobold letters कहा जाता है
  • HTML ईमेल को सपोर्ट करने वाले ईमेल क्लाइंट और वेबमेल व्यापक रूप से प्रभावित हो सकते हैं

Thunderbird में व्यवहार

  • Thunderbird से जुड़ी समस्या 5 मार्च 2024 को Mozilla को रिपोर्ट की गई थी, और 20 मार्च 2024 की public disclosure date तथा draft भी भेजा गया था
  • संभावित mitigation पर चर्चा हुई, लेकिन implementation बाद के लिए टाल दी गई
  • Thunderbird ईमेल को `

` से wrap करता है और इसके अलावा लगभग कोई बदलाव नहीं करता

  • ईमेल फ़ॉरवर्ड करने पर quoted मूल ईमेल फिर से `

` के अंदर चला जाता है और DOM में एक स्तर नीचे खिसक जाता है

  • उदाहरण CSS में .kobold-letter को डिफ़ॉल्ट रूप से छिपाया जाता है, और केवल .moz-text-html>div>.kobold-letter शर्त में दिखाया जाता है
  • मूल ईमेल देखने वाले को केवल वह paragraph दिखता है जो हमेशा दिखना चाहिए, लेकिन फ़ॉरवर्ड किया गया ईमेल पाने वाले को छिपा हुआ paragraph अचानक दिखाई देने लगता है
  • हमलावर DOM के भीतर relative position जानता है और CSS को नियंत्रित कर सकता है, इसलिए वह ईमेल के हिस्सों को छिपाकर या दिखाकर पूरी सामग्री बदल सकता है
  • अगर kobold letter को overlay की तरह style किया जाए, तो फ़ॉरवर्ड करने वाले द्वारा मूल मेल में जोड़े गए comments तक बदले जा सकते हैं, जिससे फ़िशिंग के अवसर और बढ़ जाते हैं

Outlook on the web में व्यवहार

  • Outlook on the web की समस्या 5 मार्च 2024 को Microsoft को रिपोर्ट की गई थी, और 20 मार्च 2024 की public disclosure date तथा draft भी भेजा गया था
  • Microsoft ने 26 मार्च 2024 को तत्काल कार्रवाई न करने का निर्णय लिया और रिपोर्ट को बंद कर दिया
  • OWA वेबमेल होने के कारण स्थिति अधिक जटिल है; ईमेल `

` जैसे containers में रखा जाता है, लेकिन सटीक class names बदल जाते हैं

  • Outlook ईमेल CSS का असर वेबमेल UI styles पर न पड़े, इसके लिए id और class के आगे x_ जोड़ता है और CSS को भी उसी अनुसार समायोजित करता है
  • उदाहरण में मूल ईमेल का CSS OWA में दिखाते समय इस तरह बदल जाता है
    • .rps_78fa .x_kobold-letter {display:none}
    • .rps_78fa > div > div > .x_kobold-letter {display:block!important}
  • फ़ॉरवर्ड होने के बाद class फिर से x_x_kobold-letter जैसा बदल जाता है और CSS भी फिर अपडेट हो जाता है
  • दूसरे नियम में .rps_78fa और div के बीच का > हट जाता है, इसलिए complex selectors बनाते समय इसे ध्यान में रखना पड़ता है
  • OWA का यह adjustment अटैक को स्वयं नहीं रोकता, लेकिन कई क्लाइंट्स पर एक साथ काम करने वाले kobold letter बनाना ज़रूर अधिक झंझटपूर्ण बना देता है

Gmail में व्यवहार

  • Gmail की समस्या 5 मार्च 2024 को Google को रिपोर्ट की गई थी, और 20 मार्च 2024 की public disclosure date तथा draft भी भेजा गया था
  • Google ने 9 अप्रैल 2024 को पुष्टि की कि फ़िक्स पर काम जारी है
  • Gmail ईमेल फ़ॉरवर्ड करते समय सभी styles हटा देता है, इसलिए CSS selectors के ज़रिए context के अनुसार visibility बदलने वाले संकीर्ण अर्थ के kobold letters के प्रति यह तकनीकी रूप से संवेदनशील नहीं है
  • लेकिन एक और सरल अटैक संभव है
    • मूल ईमेल में CSS से kobold letter को छिपाया जाता है
    • फ़ॉरवर्ड करते समय styles हटने पर छिपा हुआ element अपने-आप दिखने लगता है
  • यह तरीका सीमित है, और इसका उल्टा व्यवहार—यानी मूल में दिखना लेकिन फ़ॉरवर्ड होने के बाद गायब हो जाना—संभव नहीं है
  • Gmail ईमेल भेजने से पहले editor चरण में अभी CSS नहीं हटाता, इसलिए जब फ़ॉरवर्ड करने वाला comment लिख रहा होता है तब भी छिपा हुआ paragraph दिखाई नहीं देता
  • अंतिम ईमेल में styles हट जाने के कारण दूसरा paragraph दिखाई देने लगता है
  • अगर Gmail editor चरण में ही CSS हटा दे, तो फ़ॉरवर्ड करने वाला भेजने से पहले अटैक पहचान सकता है और समस्या कुछ हद तक कम हो सकती है

पहले के समान मामले और अंतर

mitigation और सीमाएँ

  • उपयोगकर्ता HTML ईमेल को पूरी तरह disable कर सकते हैं या Thunderbird के “plain HTML” जैसे restricted mode में देख सकते हैं
  • अगर ईमेल क्लाइंट `` के उपयोग को रोक दे, तो समस्या हल हो सकती है, लेकिन इससे ईमेल ecosystem के बहुत से मौजूदा use cases टूट सकते हैं
  • Gmail की तरह फ़ॉरवर्ड करते समय styles हटाने वाली implementation, styled corporate newsletters की अनुमति देते हुए HTML ईमेल के खतरों को सीमित करने वाला एक समझौता हो सकती है
  • निकट भविष्य में ईमेल क्लाइंट्स द्वारा मजबूत mitigation लागू किए जाने की उम्मीद करना व्यावहारिक नहीं है
  • उपयोगकर्ताओं को HTML ईमेल के खतरों के बारे में जागरूक रहना चाहिए और आवश्यक सावधानियाँ स्वयं अपनानी चाहिए

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

1 टिप्पणियां

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

  • “फिर भी भरोसा नहीं होता, इसलिए मैनेजर को फोन करके पुष्टि करता है कि ईमेल असली है या नहीं। मैनेजर हाँ कहता है, तो वह पैसे ट्रांसफर कर देता है” वाला हिस्सा बहुत बड़ी धारणा जैसा लगता है
    आम तौर पर “क्या आपने यह ईमेल भेजा था?” जैसा धुंधला सवाल पूछने के बजाय लोग शायद “क्या सच में आप इस तरह पैसे ट्रांसफर करने को कह रहे हैं?” जैसा ज्यादा स्पष्ट सवाल पूछेंगे, और तब मैनेजर का चौंकना स्वाभाविक है; उस बातचीत में हमला रुक जाने की संभावना बड़ी है
    यह एक दिलचस्प attack path जरूर है, लेकिन असल में इसके सफल होने की संभावना संदिग्ध है। लेख दिखाता है कि इस हमले के काम करने के लिए घटनाओं का काफी विशिष्ट और संकरा क्रम चाहिए, पर निजी तौर पर मुझे यह बहुत convincing नहीं लगता
    मुझे पता है कि phishing सच में काम करती है। लेकिन जो लोग phishing में फँसेंगे, उन्हें इतने sophisticated हमले की जरूरत नहीं होती; उल्टा, हमलावर अगर इतने विशिष्ट effort लगाए, तो सफलता की संभावना कम भी हो सकती है। साधारण phishing email से भी सफल होने की संभावना काफी होती है

    • मैं 10,000 कर्मचारियों वाली, जिनमें आधे engineer थे, एक कंपनी में काम करता था, और हर साल कुछ मामलों में कोई न कोई “CEO” या किसी अन्य senior executive के लिए company card से gift card खरीद लेता था
      उन executives की जानकारी LinkedIn या कंपनी की site पर आसानी से मिल जाती थी, और हैरानी की बात यह थी कि वे उदाहरण phishing-prevention training में ठीक इसी case के तौर पर मौजूद थे, फिर भी ऐसा हुआ
    • बल्कि बात लगभग उलटी है। यह अच्छी तरह documented तथ्य है कि सबसे साफ़-साफ़ और हास्यास्पद scams सबसे अच्छा काम करते हैं, क्योंकि इसी तरह सबसे आसानी से ठगे जाने वाले संभावित victims को filter किया जा सकता है
      https://www.microsoft.com/en-us/research/publication/why-do-...
    • यह व्यक्ति पर निर्भर करेगा। कुछ managers को दिन में कई बार ऐसे payments approve करने पड़ते हैं, इसलिए ऐसी बातचीत उन्हें झंझट लग सकती है, और कर्मचारी भी ऐसी बातचीत से बचना चाह सकते हैं
      हमलावर “मैं अभी business trip पर हूँ। अगर पक्का न हो तो मेरे personal mobile पर call करें...” जैसा वाक्य डाल सकता है, और फिर fake voice से जवाब भी दे सकता है
      target तक पहुँचने का अच्छा तरीका “double forwarding” हो सकता है। sender खुद को ऐसा कर्मचारी दिखाए जो मैनेजर का email admin काम देखने वाले व्यक्ति के आसपास के किसी कर्मचारी को forward करता है, और फिर वह कर्मचारी birthday greeting या sick leave notice जैसे दिखने में harmless कारण से mail फिर forward कर दे; तब असली target के लिए email का मूल source पहचानना मुश्किल हो जाता है
      इसके अलावा इस “feature” का ज्यादा creative दुरुपयोग करने के तरीके आसानी से सोचे जा सकते हैं। उदाहरण के लिए, किसी अनजान व्यक्ति से problematic content forward करवाकर फिर उसे blackmail करना भी संभव है
    • अगर ऐसे mails किसी बड़ी कंपनी के accounts payable department को भेजे जा रहे हों, तो यह इतना अवास्तविक नहीं हो सकता
      हर payment request email से आने पर संबंधित लोग हर बार line manager को phone नहीं करेंगे, खासकर अगर amount छोटा हो और pre-approval की जरूरत न हो
      मुझे याद है कि Google भी कभी ऐसे scam का शिकार हुआ था जिसमें कोई असली काम न होने पर भी किसी को payment कर दिया गया था। उस मामले में fake invoice शामिल था, लेकिन principle वही है
    • सिद्धांत रूप में, यह payment के recipient change जैसे ज्यादा sophisticated और targeted हमलों को संभव बना सकता है। ऐसे हमलों को detect करना कहीं ज्यादा मुश्किल होता है

  • कुछ दिन पहले मैं एक designer द्वारा बनाया गया “update” email design देख रहा था; सबसे ऊपर लगे बेहूदा बड़े graphic header की वजह से scroll किए बिना email title text तक नहीं दिख रहा था
    फिर उसने feedback माँगने के लिए दूसरा version forward किया, अचानक घबराकर बोला कि font कुछ छोटा दिख रहा है, और फिर कहा, “ओह, forward करने पर यह mobile version नहीं बल्कि desktop version में convert हो जाता है!”
    यह देखकर मैं अविश्वास में बस घूरता रह गया। यह email है—इसमें “desktop version” और “mobile version” का क्या मतलब? ऐसा कैसे हो सकता है? “convert” होने का क्या मतलब? बस copy ही तो हो रहा है। forward करने पर “टूट” जाता है, यह तथ्य ही दिखाता है कि यह तरीका कितना बेवकूफी भरा है। आखिर मेरे email में CSS क्यों होना चाहिए?
    italic जैसी चीज दिखाने के लिए Markdown जैसा कहीं ज्यादा सरल तरीका अपनाना चाहिए था, और अब तक ऐसा न होना समझ से बाहर है। इससे पता चलता है कि इस स्थिति को सच में सुधारने में कितनी कम रुचि है। सब कुछ सिर्फ उन अजीब corporate demands को पूरा करने के लिए है जो हर जगह logo और banner डालना चाहती हैं। HTML email सच में बेतुका है

    • अगर आप सिर्फ italic आदि दिखाना चाहते हैं, तो शायद आपको 1996 में आया text/enriched [1] चाहिए। लगभग सभी email clients में इसे पढ़ने का support होने की संभावना है
      [1] https://www.rfc-editor.org/rfc/rfc1896.txt
    • MJML जैसे responsive email frameworks सच में मौजूद हैं

  • मैं लंबे समय से कहता आया हूँ कि email में rich text के लिए HTML के बजाय Markdown से inline HTML हटाकर बना कोई रूप, या उससे मिलता-जुलता सरल text markup इस्तेमाल होना चाहिए
    तब email client आसानी से तय कर सकता है कि उसे rich text के रूप में दिखाना है या plain text के रूप में, और आम users को चाहिए होने वाली ज्यादातर formatting भी support हो सकती है: bold, italic, quote, inline image, code block, headings आदि
    बहुत advanced HTML इस्तेमाल करने वाले marketing emails के लिए यह अच्छा नहीं होगा, लेकिन मुझे नहीं लगता कि ऐसे use case की चिंता करनी चाहिए

    • मिलता-जुलता एक विकल्प RFC 1896 में परिभाषित text/enriched है। Apple Mail आदि भी इसे support करते हैं
      https://en.wikipedia.org/wiki/Enriched_text
      https://www.rfc-editor.org/rfc/rfc1896.html
    • कई Markdown parsers inline HTML की अनुमति देते हैं। कुछ languages में तो ज्यादातर ऐसा करते हैं, और इसे बंद करने की सुविधा देने वाले parsers केवल कुछ ही हैं। सच में बेवकूफी है
    • Lynx browser की तरह text terminal में HTML दिखाने का तरीका भी काफी अच्छा काम करता है, तो समझ नहीं आता कि किसी और markup language की जरूरत क्यों है
    • पर्याप्त adoption पाना मुश्किल है, क्योंकि email standards बदलना कठिन है
      अभी email में hyperlink लगाने का support तक नहीं है, और हाल में इसे ठीक करने की कोशिश की गई थी
      https://pastebin.com/kHQs50xm
    • रंग और size writing के बुनियादी और उपयोगी elements हैं

  • संगठन के लिए असली खतरा यह है कि जिस developer को HTML email बनाने का काम दिया गया, वह पागल होकर server room में खुद को बंद कर ले और “Outlook में rendering अलग क्यों दिख रही है” चिल्लाते हुए सारा hardware तोड़ दे
    खैर, गंभीरता से कहें तो यह बहुत दिलचस्प vulnerability है

    • इसलिए कुछ साल पहले से हमने email से जुड़े कामों के लिए बस HTML email coding service को पैसे देना शुरू कर दिया। Litmus test पास करने वाले HTML template को code करने के लिए बहुत specialized knowledge चाहिए, और मैं फिर कभी उसमें नहीं पड़ना चाहता

  • क्या इसे ऐसे ठीक नहीं किया जा सकता कि stylesheet की अनुमति न हो और tag के सिर्फ inline style attribute की अनुमति हो?
    usability के लिए email client एक automatic step जोड़ सकता है जो सभी stylesheet को inline style में “compile” कर दे
    इससे advanced CSS selector, जैसे hover वगैरह ही टूटेंगे, और मुझे पक्का नहीं कि उनकी सच में जरूरत है भी या नहीं

    • सहमत हूं। mail दिखाने से पहले सभी classes को inline style में bake कर दिया जाए तो शायद समस्या हल हो जाएगी। वैसे भी ऐसा करना समझ में आता है
      pseudo-class और media query काम नहीं करेंगी, लेकिन वे security risk हो सकती हैं और major mail clients में supported भी नहीं हैं: https://www.caniemail.com/features/css-at-media/
    • HTML email में Outlook और Gmail दशकों पुराने rendering engine इस्तेमाल करते हैं, इसलिए CSS को पहले से ही inline करना पड़ता है। Outlook तो सचमुच 2006 के आसपास वाला MS Word HTML engine इस्तेमाल करता है
      ऊपर से अगर सभी style attribute हटा देंगे तो mobile optimization और dark mode भी खत्म हो जाएंगे, क्योंकि media query को inline नहीं किया जा सकता
    • तब मौजूदा responsive email approach भी टूट जाएगी
      आम तौर पर default/desktop style पहले से compile होकर inline हो जाते हैं, और mobile devices पर पढ़ना आसान बनाने के लिए head के अंदर style tag में media query selector रखे जाते हैं

  • वाकई बहुत चतुर
    आधार यह है कि HTML email की CSS की वजह से कोई text message forward करने के बाद ही दिख सकता है। यह verified email की भरोसेमंदता के लिए बड़ा खतरा है
    Thunderbird, Outlook, Gmail के examples दिए गए हैं, और काम शानदार है
    मैं सारे mail mutt में पढ़ता हूं, इसलिए आधिकारिक तौर पर यह “दूसरों की समस्या” है
    तो किसी और बात पर शिकायत करूं: Mozilla को report करने की तारीख 05.03.2024 लिखी है। मैं मानता हूं कि little-endian date अमेरिकी middle-endian date से ज्यादा समझ में आती है
    लेकिन technologist होने के नाते ISO 8601 date format यानी 2024-03-05, hyphen हों या न हों, इस्तेमाल न करना गलत है :)

    • इतना ही नहीं, middle-endian date format इस्तेमाल करने वाला कोई भी व्यक्ति गलत है। कुछ लिखने के तरीकों में यह सबसे अतार्किक तरीका है
      little-endian में कम से कम यह खूबी तो है कि वह बाकी सभी numbers लिखने के तरीके के उलट है, लेकिन middle-endian तो बस पागलपन है। बेशक, इसलिए यही अमेरिकियों का तरीका भी है

  • जिन email clients का जिक्र है, उनमें से कुछ mail content को अतिरिक्त HTML tags से wrap करते और CSS व class names बदलते दिखते हैं
    मुझे हैरानी है कि email client HTML email render करते समय sandbox iframe क्यों नहीं इस्तेमाल करते। क्या अब भी कोई security risk है?

    • अतिरिक्त HTML forwarded email पढ़ने वाले client में नहीं बनता, बल्कि forward करते समय बनता है
      forward करने वाला व्यक्ति email में और text जोड़ना चाह सकता है, इसलिए यह expected behavior है
    • पहले iframe इस्तेमाल किए थे और समस्याएं आई थीं। rendering या security problem नहीं थी; मेरी याद में वह हिस्सा ठीक काम करता था
      बस अगर email में किसी website का link हो और sandbox iframe JavaScript allow न करे, तो वह security context iframe के अंदर link click करके खुली page तक जारी रहता था, जिससे website JS इस्तेमाल नहीं कर पाती थी
      समाधान allow-popups-to-escape-sandbox था, इसलिए अब इसके काम न करने की कोई वजह नहीं दिखती

  • घाव ठीक करने के लिए हाथ-पैर काट देने जैसा typical solution है। समस्या email standardization की कमजोरी है, जिसने ऐसी hacking को हावी होने दिया
    HTML कुल मिलाकर ऐसी चिंताओं के प्रति vulnerable है। फिर भी बहुत से emails HTML का बिना समस्या इस्तेमाल करते हैं। यह लेख जंगली दुनिया में मिली किसी चीज पर निजी frustration को security issue की तरह पेश करता हुआ लगता है

  • दिमाग में आने वाले संभावित mitigations ये हैं, हालांकि शायद असरदार न हों: hidden elements पर साफ warning देना, receiving और sending दोनों तरफ wrapping div की संख्या randomize करना, forward करते समय यह calculate करना कि वह असल में कैसा दिखेगा और अगर बड़ा फर्क हो तो confirmation मांगना
    या उल्टा तरीका अपनाना ज्यादा प्रभावी हो सकता है, क्योंकि इसमें दूसरे clients की मदद की जरूरत नहीं पड़ती

  • इसे “email संगठन के लिए खतरनाक क्यों है” कर देना चाहिए

    • उस स्तर पर तो यह बस “बाहरी दुनिया से communication संगठन के लिए खतरनाक क्यों है” हो जाएगा
      यह लेख HTML email के लिए unique attack path दिखाता है, लेकिन email के जरिए होने वाले ज्यादातर attacks को WhatsApp, Slack, Jira, Zoom या किसी भी ऐसे tool में आसानी से ले जाया जा सकता है जिससे लोग बाहरी दुनिया से communicate करते हैं