Google को DKIM replay attack के ज़रिए spoof किया गया: एक तकनीकी विश्लेषण

• हमलावर ने DKIM replay attack का इस्तेमाल करके Google के रूप में सफलतापूर्वक phishing email भेजा
• ईमेल का sender address और authentication result असली Google official mail जैसा दिखता है, इसलिए उपयोगकर्ता आसानी से धोखा खा सकते हैं
• हमलावर ने Google Sites का उपयोग करके एक ऐसी साइट बनाई जो official support page जैसी दिखे, जिससे भरोसा बढ़े
• SPF, DMARC, DKIM तीनों authentication पास हो जाते हैं, लेकिन मुख्य बात ईमेल को बिना body और signature header बदले फिर से भेजना है
• व्यावहारिक बचाव के तौर पर DKIM key को नियमित रूप से rotate करना और उपयोगकर्ता जागरूकता बढ़ाना सुझाया जाता है

---

शुरुआत: सामान्य दिखने वाला phishing mail

• सुबह एक परिचित को ऐसा ईमेल मिला जिसमें Google account से जुड़े कानूनी दस्तावेज़ों के अनुरोध की बात थी
• sender Google के official no-reply address के रूप में दिख रहा था, और उसमें न typo था, न संदिग्ध link, न कोई असामान्य domain; ईमेल बहुत परिष्कृत तरीके से लिखा गया था
• receiver के लिए उसकी सच्चाई परखना मुश्किल था, इसलिए विशेषज्ञ से जाँच करवाई गई

ईमेल का विस्तृत विश्लेषण

• ईमेल header और link preview की जाँच sandbox environment में की गई
• sender address, branding, language quality, attachment की मौजूदगी—सब कुछ सामान्य लगा
• लेकिन SPF, DKIM, DMARC authentication result जाँचने पर असामान्य संकेत मिले

phishing mail से जुड़ी सावधानियाँ

• संदिग्ध ईमेल के link पर click न करें और उसमें दिए गए निर्देशों का पालन न करें—इस पर ज़ोर दिया गया
• sandbox के बाहर ऐसे ईमेल का जवाब देने या attachment खोलने पर जानकारी लीक होना, corporate email compromise, account takeover, network compromise का खतरा होता है
• शक होने पर तुरंत विशेषज्ञ विश्लेषण और security team को रिपोर्ट करना ज़रूरी है

attack flow: Google Sites का उपयोग

• हमलावर ईमेल का link, यदि उपयोगकर्ता पहले से login हो, तो सीधे Google Sites पर ले जाता है
• Google Sites एक official google.com subdomain है जिसे कोई भी मुफ़्त में बना सकता है, लेकिन उसका content अपने-आप official support page नहीं होता
• इसका उपयोग internal wiki, project dashboard, documentation, event website आदि के लिए होता है, और इस हमले की तरह इसका दुरुपयोग भी किया जा सकता है

जब infrastructure पर भरोसा ही खतरा बन जाए

• Google Sites (2008 में लॉन्च) Google Workspace के साथ integrated है और आसान creation, deployment, SSL certificate और brand trust देता है
• हमलावर बिना अलग domain/hosting लिए, आधिकारिक दिखने वाली phishing site आसानी से और कम लागत में बना सकता है

DKIM replay attack की विस्तृत प्रक्रिया

चरण 1: असली Google email हासिल करना

• हमलावर [e-mail] खाते से आया एक वैध ईमेल प्राप्त करता है और उसका original body तथा header सहेज लेता है

चरण 2: signed message को दोबारा भेजने की तैयारी

• DKIM ईमेल body के कुछ हिस्सों और कुछ specific header पर digital signature लगाता है
• यदि original message और signature header वैसे ही बने रहें, तो दोबारा भेजे जाने पर भी authentication बना रहता है

चरण 3: Outlook के ज़रिए पुनःप्रेषण

• हमलावर Outlook account से attack mail भेजता है
• source और route information का कुछ हिस्सा बदल जाता है, लेकिन DKIM signature वैध बना रहता है

चरण 4: Jellyfish SMTP relay server का उपयोग

• Microsoft के Jellyfish system के ज़रिए मेल को route किया जाता है, जिससे origin server से दूरी बनाई जा सके

चरण 5: Namecheap PrivateEmail के ज़रिए भेजना

• Namecheap की PrivateEmail service मेल receive करने के बाद एक अतिरिक्त relay की भूमिका निभाती है
• इस प्रक्रिया में एक नया DKIM signature जुड़ता है, लेकिन यह DMARC मानदंड के अनुरूप नहीं होता
• फिर भी original Google DKIM signature match और valid होने के कारण DMARC verification पास हो जाता है

चरण 6: Gmail पर अंतिम delivery

• अंत में recipient को ऐसा ईमेल मिलता है जो Google की official mail जैसा दिखता है
• परिणामस्वरूप SPF, DKIM, DMARC तीनों authentication पास दिखाई देते हैं

नकली summons email खतरनाक क्यों है

• ‘summons’ वाला ईमेल recipient में डर, तात्कालिकता और भ्रम पैदा करता है
• यह असली summons जारी/डिलीवर करने की प्रक्रिया से अलग होता है; सामान्य स्थिति में यह physical delivery या official channel से होता है
• इस तरह की phishing बहुत विश्वसनीय होती है, इसलिए तकनीकी रूप से दक्ष उपयोगकर्ता भी आसानी से फँस सकते हैं

निष्कर्ष और बचाव

• अनपेक्षित और तात्कालिक ईमेल की स्थिति में हमेशा उसकी सत्यता की जाँच करें और विशेषज्ञ कार्रवाई लें
• किसी भी link पर click न करें, reply न करें, और कुछ भी execute न करें
• security team या जाँच विशेषज्ञ से analysis कराने की सलाह दी जाती है

अतिरिक्त: हमले को दोहराने की प्रक्रिया

• हमलावर Namecheap पर domain register करता है और मुफ़्त PrivateEmail service हासिल करता है
• Google Workspace (free trial) के लिए sign up करके domain verify करने के बाद malicious Google OAuth App बनाता है
• App Name field के ज़रिए मनचाहा नाम सेट किया जा सकता है, जैसे: Google Support
• Google द्वारा भेजे गए account alert PrivateEmail पर भेजे जाते हैं, और sender address तथा reply address में हेरफेर किया जा सकता है
• अंततः attack mail इच्छित target तक पहुँचा दिया जाता है

अक्सर पूछे जाने वाले सवाल

• DKIM replay attack: हमलावर वैध DKIM signature वाले सामान्य ईमेल को capture करके, उसी content और header के साथ दोबारा भेजता है
• SPF, DMARC की blocking limits: SPF केवल भेजने वाले server/IP को verify करता है; replay attack में यदि DKIM alignment बना रहे, तो DMARC भी पास हो सकता है
• detect करना कठिन क्यों है: body और header में बदलाव न होने पर केवल signature verification से पहचान करना मुश्किल होता है
• हमले में Google OAuth bypass: हमलावर malicious OAuth App बनाता है और Google द्वारा भेजे गए official alert को फिर से भेजकर भरोसा हासिल करता है
• बचाव: DKIM key का नियमित rotation (30 दिन या उससे कम अंतराल पर) और user education (संदिग्ध link से सावधानी, URL जाँच, रिपोर्टिंग संस्कृति को बढ़ावा) महत्वपूर्ण हैं

[GN⁺]

Hacker News की राय

• मैं इस समस्या का समाधान बना रहा हूँ (Google और Yahoo के पूर्व सह-लेखकों के साथ, और यह एक विश्वसनीय प्रोजेक्ट है)
  कृपया Draft: DKIM2 Motivation दस्तावेज़ देखें
  यह तरीका उपयोगकर्ता द्वारा डाला गया टेक्स्ट वास्तव में Google से भेजे जाने को नहीं रोकता, लेकिन Google की वास्तविक मंशा के बिना उस संदेश के दोबारा प्रेषित होने को रोकता है
  क्योंकि SMTP FROM/TO फ़ील्ड सुरक्षित रहते हैं
  Motivation draft में तकनीकी विवरण नहीं हैं; ड्राफ्ट संबंधित दस्तावेज़ों में देखे जा सकते हैं
  कृपया DKIM Working Group Documents लिंक देखें

  • Datatracker साइट candidate documents को ठीक से नहीं दिखाती, इसलिए सीधे लिंक दे रहा हूँ
    Draft: dkim2-dns
    Draft: dkim2-header
    Draft: dkim2-modification-algebra
    Draft: dkim2-bounce-processing
    Draft: dkim2-message-examples

  • मैं जानना चाहूँगा कि यह तरीका mailing lists या groups के लिए कैसे काम करेगा
    उदाहरण के लिए, बाहर से [e-mail] पर आए मेल को टीम सदस्यों तक अपने-आप फ़ॉरवर्ड करना आम है
    क्या अंतिम प्राप्तकर्ता के सिस्टम में mailing list forwarder पर भरोसा करने की सेटिंग चाहिए होगी, या कौन किस list में है यह ट्रैक करने वाली कोई internal logic होनी चाहिए?
    यह सत्यापित किया जा सके कि मूल प्राप्तकर्ता accounts-payable एक वैध प्राप्तकर्ता है

• मेरे साथ सचमुच ऐसा हुआ है कि computer hacking के आरोप में दोषी ठहराए जाने के बाद FBI ने मेरे Google account का पूरा डेटा ज़ब्त कर लिया था
  2016 में एक बार, और 2018 में फिर एक बार डेटा लिया गया
  असल में वे इस लेख में बताए गए तरीके से ऐसा नहीं करते
  मेरे अनुभव में, वे Google के किसी specific department को ईमेल भेजकर औपचारिक संचार करते हैं
  जाँच एजेंसियाँ आम तौर पर बहुत सावधानी से काम करती हैं ताकि जाँच के लक्ष्य को भनक न लगे

  • जो लोग उत्सुक हैं, उनके लिए विस्तार से बता रहा हूँ
    [e-mail] से मुझे इस तरह की ईमेल मिली थी:

Dear Google user,

Google received and responded to legal process issued by the United States Department of Justice (<FEDERAL DISTRICT>) compelling the release of information related to your Google account. A court order previously prohibited Google from notifying you of the legal process. We are now permitted to disclose the receipt of the legal process to you. The agency reference number or case number on the legal process is <DISTRICT COURT CASE NUMBER>.

For more information about how Google handles legal process, view our transparency report at http://google.com/transparencyreport/userdatarequests/….

Google is not in a position to provide you with legal advice or discuss the substance of the legal process. If you have other questions regarding this matter, you may wish to contact an attorney.

Please reply to this email and/or include the case identification number located in the subject line in any further communications regarding this matter.

Regards, 
Legal Investigations Support
Google LLC

Federal Grand Jury subpoena में आम तौर पर 1–2 साल की delayed notice माँगी जाती है ताकि service provider (जैसे Google) आपको सूचित न कर सके
subpoena केवल सामान्य रिकॉर्ड देता है (billing information, login records आदि), content (जैसे email) नहीं
ईमेल जैसे वास्तविक डेटा के लिए अलग search warrant चाहिए होता है, और Google आम तौर पर ऐसे search warrant लागू होने की अलग से सूचना नहीं देता

• आज शुक्रवार है, और इस टिप्पणी ने मुझे 10% ज़्यादा जगा दिया
  पीछे की कहानी विस्तार से जानने की इच्छा है

• दिलचस्प
  मैं सोच रहा हूँ कि क्या यह अनुरोध GDPR के "मेरे account से संबंधित सारा data दें" जैसे अनुरोधों में शामिल होकर मेरे पूरे account data export में रिकॉर्ड या tag के रूप में दिखता है

• मेरा अनुमान है कि search warrant शायद CFAA violation, wire fraud, या conspiracy जैसी धाराओं पर लिया गया होगा
  आशा है आपने अच्छा वकील रखा होगा और मामला ठीक से सुलझ गया होगा

• हाल ही में इसी तरह का हमला मुझे भी मिला
  हमलावर ने [e-mail] से मेल भेजा (ध्यान दें, यह वास्तव में gmail.com नहीं था), फिर Google के mail server से मिले delivery failure message (bounce) को [e-mail] पर फ़ॉरवर्ड किया और अंत में spam संदेश जोड़ दिया
  इस तरह सभी security checks पास हो गए
  postmaster error और phishing campaign का यह मिश्रण वाकई असामान्य है
  कोई non-technical व्यक्ति आसानी से इसमें फँस सकता है
  मेरे मामले में phishing mail में लिखा था कि मैंने construction tools जीते हैं

  • मुझे भी कई हफ्तों से ऐसे मेल मिल रहे हैं
    अब लगने लगा है कि Google ने mail को छोड़ ही दिया है

• यह लेख पढ़ते समय मैं बहुत उलझ गया था
  इसमें विस्तार से ऐसा बताया गया है मानो हमलावर ने ईमेल body में छेड़छाड़ कर phishing link डाल दिया हो, लेकिन वास्तव में ऐसा कोई सबूत या modification नहीं था
  DKIM signature में body का hash शामिल होता है
  तकनीकी रूप से I= फ़ील्ड से hash range सीमित की जा सकती है, लेकिन मैंने पुष्टि की कि Google छोटे मेल में यह option इस्तेमाल नहीं करता ([e-mail] से आए मेल देखकर)
  यानी DKIM और DMARC जाँच पास करने के लिए body बदली नहीं जा सकती, इसलिए phishing link भी मूल रूप से Google द्वारा भेजे गए कंटेंट का हिस्सा था (बस शायद किसी और इच्छित प्राप्तकर्ता के लिए)
  इसलिए असल बात "डरावना ईमेल गलत तरह से फ़ॉरवर्ड हो जाना" ज़्यादा है, और 'DKIM replay attack' जैसा शीर्षक इस क्षेत्र से कम परिचित लोगों को कहीं अधिक गंभीर लग सकता है
  संपादन: मैंने TFA का "The Takeaway?" पढ़कर समझा कि लेख वहीं समाप्त हो गया, लेकिन उसके नीचे के update में बताया गया है कि लिंक वास्तव में Google OAuth app name में डाला गया था और Google email template में शामिल हुआ
  यही इस हमले का सबसे महत्वपूर्ण हिस्सा है, लेकिन लेख की संरचना इतनी खराब है कि यह हिस्सा दब गया है, और ऐसा भ्रम पैदा होता है मानो कोई मनचाहा content भेजा जा सकता हो
  अतिरिक्त: दूसरे comments में यह भी बताया गया कि ईमेल screenshot बीच से काटा गया था ताकि Google email template का स्थिर हिस्सा दिखे ही नहीं
  यह हमला पहली नज़र में जितना लगता है, उससे कहीं ज़्यादा ढीला-ढाला है

  • यह लेख जानबूझकर भ्रामक तरीके से लिखा हुआ लगता है
    इसने screenshot में दिखे हिस्से को पूरा ईमेल जैसा पेश किया, जबकि उसके बाद शायद ऐसा टेक्स्ट आता जो चेतावनी का संकेत देता

  • मेरी समझ के अनुसार DKIM इसलिए validate हो रहा है क्योंकि हमलावर वास्तव में Google से मिला ईमेल जस का तस फ़ॉरवर्ड कर रहा है
    असली attack vector यह है कि Google से ऐसा ईमेल भेजवाया जा सकता है जिसमें कुछ टेक्स्ट हमलावर नियंत्रित करता है

• मेरी नज़र में यहाँ असली कमजोरी यह है कि Google OAuth app name में URL डाला जा सकता है, और वही Google के root domain से जाने वाले no-reply मेल में बिना भेदभाव render हो जाता है
  भले ही लिंक clickable न हो, अगर आसपास का टेक्स्ट काफ़ी धमकीपूर्ण हो तो पीड़ित खुद जाकर उसे खोल सकता है
  DKIM integrity बनाए रखने वाली forwarding services की कई परतें लग सकती हैं — यह बस अतिरिक्त रूप से शिक्षाप्रद पहलू है
  OAuth app name में URL, खासकर google.com वाले URL, को पूरी तरह ब्लॉक किया जाना चाहिए

• आखिरकार!
  कुछ महीने पहले मुझे लगभग यही ईमेल मिला था (Google Domains admin के रूप में)
  सच कहूँ तो वह मेल देखकर मैं भी सिहर गया था
  मैंने भी तुरंत लिंक पर क्लिक नहीं किया और इंतज़ार किया, साथ ही इस धोखाधड़ी के बारे में दूसरे संदर्भ ढूँढने की कोशिश की
  अजीब बात यह थी कि सभी email addresses masked थे, और उनका masking pattern उन emails से मेल नहीं खाता था जिन्हें मैं manage करता हूँ
  ईमेल खुद legit था, और Google पर खोजने पर body text भी मैच कर रहा था
  मेरे मामले में वह किसी deceased account से संबंधित ईमेल था, जो वास्तविकता से मेल नहीं खाता था
  फिर भी मुझे लगभग 100% शक था कि कहीं कोई Google को यह मनवाकर कि मैं मर चुका हूँ, मेरा पूरा Google account हड़पने की कोशिश तो नहीं कर रहा
  वाकई बहुत डरावना अनुभव था

• Step 3: हमलावर Outlook से ईमेल भेजता है
  जहाँ तक मुझे पता है, Received: header path को spoof करना असंभव है
  हर server अपना path information खुद जोड़ता जाता है
  इसीलिए ईमेल की उत्पत्ति जाँचते समय मैं हमेशा वही जानकारी देखता हूँ
  Google से आया मेल Microsoft server से होकर नहीं आना चाहिए

  • आख़िरी 'Trusted' server का header spoof नहीं किया जा सकता, बाकी path spoof किए जा सकते हैं

  • क्या आप हर ईमेल के headers हाथ से जाँचते हैं?
    या इसे दिखाने/visualize करने वाला कोई tool इस्तेमाल करते हैं?

• यह सचमुच डरावनी स्थिति है
  ज़रा कल्पना कीजिए कि इस लेख से सीखा गया सबक आपको अपने किसी रिश्तेदार को समझाना है
  यह कहना पड़े कि भरोसेमंद domain से आया मेल हो, और dkim/dmarc/spf सब पास हों, तब भी हमेशा शक करो — यह बात भारी लगती है
  लेकिन इस attack की क्षमता काफ़ी सीमित है
  उदाहरण के लिए, आप किसी और के Gmail account से संदेश spoof करके नहीं भेज सकते
  "जब संदेश फ़ॉरवर्ड होता है, तो DKIM signature तब तक सुरक्षित रहता है जब तक body और signed headers में बदलाव न किया जाए"
  हैरानी की बात यह है कि To: header DKIM signing target में शामिल नहीं है
  मुझे लगता है signing configuration बदलनी चाहिए, या email clients को कम-से-कम तब चेतावनी देनी चाहिए जब मेल वैध हो लेकिन To बदल गया हो

  • ज़रा सोचिए कि यह सबक किसी रिश्तेदार को समझाना है — कि हमेशा शक करते रहो
    पहले तो dkim/dmarc/spf क्या हैं, यह समझाना पड़ेगा
    असल में ये backend technologies हैं जिन्हें उपयोगकर्ता को जानने की ज़रूरत ही नहीं होनी चाहिए
    यह हमला जितना बताया जा रहा है, उतना डरावना नहीं है
    लेख में product बेचने के लिए कुछ अतिशयोक्ति लगती है
    To: header sign न होने वाली बात भी वास्तव में इतनी अर्थपूर्ण नहीं है
    व्यवहार में email का To हमेशा अंतिम प्राप्तकर्ता को ही नहीं दर्शाता

  • ईमेल में हर समय संदेह बनाए रखना बहुत समय से default स्थिति रही है
    From फ़ील्ड पर कभी पूर्ण भरोसा न करना ही सबसे अच्छा है

  • आपने कहा कि To: header का DKIM signature में न होना चौंकाने वाला है, लेकिन वास्तव में यह शामिल होता है
    इसलिए मूल To: मान को बनाए रखना पड़ा होगा
    reproduction section के screenshot में वही मूल To: पता दिखता है
    इसका मतलब यह नहीं कि डिलीवरी उसी पते पर हुई
    मूलतः ईमेल किसी भी पते पर, किसी भी To: मान के साथ पहुँचाया जा सकता है

  • मेरी मूल सलाह है: अगर कोई ईमेल आपसे कोई action लेने को कहे, तो खुद संबंधित website पर जाएँ
    किसी भी link पर क्लिक न करें
    यह थोड़ा असुविधाजनक है, लेकिन अंततः समस्या हल कर देता है
    खासकर bank या महत्वपूर्ण systems के लिए यह असुविधा पूरी तरह उचित है

  • इस तरह का threat model मेरे workplace में तो पहले से policy बन चुका है
    इंटरनेट पर हर चीज़ पर संदेह करना अच्छी practice है
    बहुत-से छोटे businesses और freelancers अब भी MFA जैसी चीज़ें इस्तेमाल नहीं करते, और करते भी हैं तो token theft का शिकार हो जाते हैं
    ऐसे accounts compromise हो जाएँ तो सचमुच internal user जैसे दिखने वाले malicious mails आने लगते हैं
    उपयोगकर्ता की नज़र में वे पूरी तरह legit लगते हैं
    इसीलिए ईमेल को हमेशा संदेह के साथ ही लेना चाहिए

• लेखक ने
  "Here is the URL from that email [...] https://sites.google.com[...]";
  यह लिंक ही पहला red flag था
  मेरा मानना है कि लेखक को यह बात तीन पैराग्राफ बाद नहीं, बल्कि शुरुआत में ही रखनी चाहिए थी

  • हर कोई google.com के subdomains नहीं जानता
    असली समस्या यह है कि (SSO में valid field की समस्या के अलावा) Google user content को अपने main domain के subdomains पर serve करता है
    Drive जैसी दूसरी services भी ऐसा कर सकती हैं

  • जो चीज़ आपको red flag लगे, वह ज़रूरी नहीं कि हमारे माता-पिता को भी लगे

• कुल मिलाकर यह उदाहरण दिखाता है कि email security की प्रणाली कितनी कमज़ोर है
  इस forum में इतने समझदार लोग हैं कि मुझे लगता है वे ऐसा कोई विकल्प निकाल सकते हैं जो इन समस्याओं को एक साथ हल करे
  मेरा यह भी मानना है कि Google को ऐसी sites main domain पर नहीं, बल्कि hostedbygoogle.com जैसे अलग domain पर host करनी चाहिए
  समझ नहीं आता कि अब तक ऐसा क्यों नहीं किया गया

  • व्यवहारिक रूप से जितने भी विकल्प संभव हैं, वे अंततः सारी control एक ही company को सौंपने वाले ढाँचे बन जाते हैं
    इससे email की बची हुई मुख्य उपयोगिता — यानी ऐसा सिस्टम जो किसी एक के पूर्ण नियंत्रण में न हो — खत्म हो जाती है
    तकनीकी समस्याएँ हल की जा सकती हैं, लेकिन लोग और हितों से जुड़ी समस्याएँ कहीं कठिन हैं
    जिनके पास समस्या हल करने के संसाधन हैं, उनके पास आम तौर पर पूरी तरह खुला platform बनाने की प्रेरणा नहीं होती
    जब तक सारा पैसा और control उनके पास न जाए, वे ऐसा प्रयास नहीं करेंगे
    और दूसरी ओर, हर कोई भी अपनी सारी control किसी एक company को नहीं सौंपना चाहता
    यही वजह है कि यह तकनीकी से अधिक business problem है
    (ठीक यही कारण है कि metaverse में सभी services का avatars/items साझा करना व्यवहार में लगभग असंभव है
    यह तकनीकी असंभवता कम, और rights holders के कभी सहमत न होने का मुद्दा ज़्यादा है)

  • Thiel-backed नया startup Shadowfax पेश है!
    हमारी सुरक्षित, केंद्रीकृत monopoly service अब AI और blockchain-powered layer के साथ आएगी और email की पुरानी प्रणाली को बदल देगी
    इसे पहले ही U.S. Department of Defense का contract मिल चुका है, और 2027 तक यह सभी internal और external federal government communications का standard बनने की राह पर है