$8 से कम cloud लागत में 512-bit DKIM key कैसे क्रैक की गई

 (dmarcchecker.app)
3 पॉइंट द्वारा GN⁺ 2025-01-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • शीर्ष 10 लाख वेबसाइटों की जांच में 1,024-bit से कम DKIM public keys 1,700 से अधिक मिलीं, और प्रयोग में यह जांचा गया कि redfin.com की 512-bit RSA DKIM key का वास्तव में दुरुपयोग हो सकता है या नहीं
  • DKIM record के p tag को decode कर RSA modulus n और public exponent e=65537 प्राप्त किए गए, फिर CADO-NFS से modulus का factorization किया गया
  • Hetzner के 8 dedicated vCPU, 32GB RAM server पर लगभग 86 घंटों में n को दो prime numbers p, q में विभाजित किया गया, और इसी आधार पर RSA private key दोबारा बनाई गई
  • दोबारा बनाई गई private key से security@redfin.com sender mail पर signature करने पर Gmail·Outlook ने उसे reject किया, लेकिन Yahoo Mail, Mailfence, Tuta ने dkim=pass लौटाया
  • redfin.com की p=reject; pct=100 DMARC policy में DKIM pass होने से DMARC pass हो गया, इसलिए mail providers को 1,024-bit से कम RSA DKIM signatures reject करने चाहिए

512-bit DKIM keys के बचे रहने की समस्या

  • शीर्ष 10 लाख वेबसाइटों के SPF, DKIM, DMARC records की जांच में 1,024-bit से कम लंबाई वाली public DKIM keys 1,700 से अधिक मिलीं
  • 1,024-bit से कम RSA keys असुरक्षित मानी जाती हैं, और DKIM में 2018 के RFC 8301 के बाद से इनके उपयोग को phase out करने की सिफारिश है
  • प्रयोग का लक्ष्य key1._domainkey.redfin.com में मिली 512-bit RSA public key थी
  • उद्देश्य यह जांचना था कि क्या केवल public key से private key restore कर, असली domain sender की तरह email पर signature किया जा सकता है
  • साथ ही यह भी verify किया गया कि Gmail, Outlook.com, Yahoo Mail जैसे बड़े email providers छोटी key से बने DKIM signature को pass करते हैं या नहीं

DKIM public key से RSA components निकालना

  • DKIM record के p tag में public key ASN.1 DER format में encode होने के बाद फिर Base64 में encode होकर रहती है
  • Python के Crypto.PublicKey.RSA.import_key से public key पढ़कर RSA components निकाले गए
    • Modulus n: 10709580243955269690347257968368575486652256021267387585731784527165077094358215924099792804326677548390607229176966588251215467367272433485332943072098119
    • Public exponent e: 65537

CADO-NFS से modulus का factorization

  • RSA private key बनाने के लिए modulus n को दो prime numbers p और q के product में तोड़ना होता है
  • Factorization के लिए CADO-NFS का उपयोग किया गया
    • CADO-NFS बड़े integers के factorization में इस्तेमाल होने वाले Number Field Sieve(NFS) algorithm का implementation है
  • स्थानीय computer को कई दिनों तक व्यस्त रखने से बचने के लिए Hetzner cloud server किराए पर लिया गया
    • Server specs 8 dedicated vCPU, AMD EPYC 7003 series, 32GB RAM थे
    • OS Ubuntu था
    • काम के लिए पर्याप्त memory सुनिश्चित करने हेतु 32GB swap जोड़ा गया
  • cado-nfs.py में modulus n input देकर factorization चलाया गया
  • पूरी job 8-vCPU server पर लगभग 86 घंटे चली, और n निम्न दो prime numbers में factorize हुआ
    • p = 97850895333751392558280999318309697780438485965134147739065017624372104720767
    • q = 109447953515671602102748820944693252789237215829169932130613751100276125683257
  • अधिक शक्तिशाली server या कई systems पर distributed execution इस्तेमाल करने से समय घटाया जा सकता है, और CADO-NFS distributed work को सरल बनाता है

RSA private key को दोबारा बनाना

  • p, q, e मिलने के बाद Python और PyCryptodome से RSA private key बनाई गई
  • गणना में निम्न values और प्रक्रिया इस्तेमाल हुई
    • n = p * q
    • phi = (p-1) * (q-1)
    • d = inverse(e, phi)
    • RSA.construct((n, e, d, p, q))
  • परिणाम PEM format की RSA private key था, जिसे OpenDKIM configuration में integrate कर test mail signing के लिए इस्तेमाल किया गया

Mail providers के हिसाब से DKIM verification results

  • दोबारा बनाई गई private key को OpenDKIM में डालकर security@redfin.com FROM address से कई email hosting services को test mails भेजे गए
  • अधिकांश providers ने 512-bit key को असुरक्षित मानकर DKIM signature reject किया, लेकिन तीन ने dkim=pass लौटाया
  • Provider-wise results इस प्रकार हैं
    • Gmail: FAIL
    • Outlook: FAIL
    • Yahoo Mail: PASS
    • Zoho: FAIL
    • Fastmail: FAIL
    • Proton Mail: FAIL
    • Mailfence: PASS
    • Tuta: PASS
    • GMX: FAIL
    • OnMail: FAIL
  • redfin.com के पास v=DMARC1;p=reject;pct=100;... स्वरूप का valid DMARC record है
  • redfin.com के लिए DKIM verification pass होने से DMARC verification भी pass हुआ, और BIMI requirements भी पूरी हुईं

लागत और operational कदम

  • 30 साल पहले 512-bit RSA public key तोड़ना supercomputer-level task था, लेकिन आज cloud server पर US$8 से कम में संभव है
  • यदि 16 cores या उससे अधिक वाला powerful home computer हो, तो यह और तेज़ और सस्ता भी किया जा सकता है
  • 512-bit या 768-bit DKIM keys बनाए रखने का कोई कारण नहीं है, और email providers को 1,024-bit से कम RSA keys से बने DKIM signatures को automatically reject करना चाहिए
  • Yahoo, Mailfence, Tuta को experiment results और recommendation भेजे गए
  • Domain owners को DNS settings में पुराने DKIM records जांचने चाहिए
    • DKIM record के p tag में Base64 characters की संख्या गिनकर आसानी से जांचा जा सकता है
    • 1,024-bit RSA public key में Base64 आधार पर कम से कम 216 characters होते हैं

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

1 टिप्पणियां

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

  • 14 साल पहले भी 512-bit DKIM RSA key को तोड़ना संभव था: https://blog.jgc.org/2010/06/facebooks-dkim-rsa-key-should-b...

    • कुछ समय तक कमजोर DKIM keys इस्तेमाल करना अनौपचारिक रूप से एक feature जैसा माना जाता था
      दलील यह थी कि छोटी key होने पर DKIM signature लंबे समय तक सबूत के तौर पर नहीं टिकता, इसलिए बाद में यह साबित करना मुश्किल हो जाता है कि कौन-सा email असली था, और इस तरह deniability बनी रह सकती है
      बेशक इसका मतलब यह नहीं कि ज्यादातर कंपनियां छोटी keys इसी वजह से इस्तेमाल करती थीं; मतलब बस इतना है कि छोटी keys को पूरी तरह बुरा नहीं माना जाता था
      DKIM deniability निजी तौर पर मेरे लिए लंबे समय से दिलचस्प विषय रहा है [1]; ऐसी छोटी keys साफ तौर पर समाधान नहीं हैं, लेकिन मैं इन्हें DKIM को लेकर उलझी सोच और हर email signing scheme के निहितार्थों को स्वीकार न करने वाले community माहौल का नतीजा मानता हूं
      [1] https://blog.cryptographyengineering.com/2020/11/16/ok-googl...
    • उस व्यक्ति की कहानी याद आती है जिसने इसे Google hiring challenge समझकर DKIM key तोड़ दी थी
      https://www.wired.com/2012/10/dkim-vulnerability-widespread/
    • 1999 में सैकड़ों computers से RSA-155 को factorize करने पर यह सामने आया कि 512-bit key को व्यावहारिक रूप से तोड़ा जा सकता है, और कहा गया था कि आज सामान्य hardware से यह कुछ हफ्तों में संभव है
      मोटे तौर पर 14 साल में यह समय कुछ हफ्तों से घटकर 8 घंटे रह गया
    • संदर्भ के लिए, parent comment लिखने वाले CloudFlare CTO हैं
    • उस blog का http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-... के comments में भी उल्लेख था

  • अगर मजे के लिए आजमाना हो, तो 4096-bit DKIM key बनाकर देखिए
    online DKIM/SPF checkers DNS देखकर सब कुछ ठीक बताते हैं, लेकिन test mail fail हो जाता है
    वे लगभग STATUS: Fail, DKIM: Pass, SPF: Pass जैसी शानदार explanation दिखाते हैं
    DKIM entry में 2048-bit से बड़ी key इस्तेमाल करना allowed और valid है, लेकिन verifier के लिए 2048-bit से बड़ी key को अनिवार्य रूप से handle करना जरूरी नहीं था
    इसे खुद भुगतकर सीखने में मेरे कुछ बाल झड़ गए

    • साथ में, check failure देखने के लिए strict DMARC policy set करनी होगी
      दिलचस्प बात यह है कि sites कहती हैं कि तीनों entries सही और valid हैं, फिर भी mail को fail treat करती हैं
      शायद इसलिए कि DNS record checking और email verification अलग-अलग software handle करते हैं
    • नए RFC, RFC8301, में requirements हैं
      इसमें कहा गया है कि verifiers को 512-bit से 2048-bit तक की keys वाले signatures verify करने में सक्षम होना चाहिए, और वे बड़ी keys भी verify कर सकते हैं
      मैंने एक साल पहले इसी विषय पर master's thesis लिखी थी; आजकल बड़े mail providers सभी 4096-bit support करते हैं और कुछ 16384-bit तक भी support करते हैं

  • मुझे हैरानी है कि सभी encryption में कुल मिलाकर key size काफी ज्यादा क्यों नहीं बढ़ाया जाता
    समाधान न सही, समय खरीदने वाला कदम तो लग सकता है
    computational performance तेजी से बढ़ रही है और quantum computers की बातें भी लगातार हो रही हैं, लेकिन लगता है सब चुप बैठे हैं
    बेशक बड़ी keys की computation cost ज्यादा होती है, लेकिन हमारे पास भी compute resources बढ़े हैं, तो उन्हें सिर्फ attack के लिए नहीं, defense में भी इस्तेमाल करना चाहिए
    client side पर TLS 1.2 की जगह TLS 1.3 force करने जैसा सरल काम भी बहुत कुछ तोड़ देता है, HN site भी शामिल है

    • पुराना है, लेकिन अब भी relevant लेख: https://www.schneier.com/blog/archives/2009/09/the_doghouse_...
      ये numbers device technology level से नहीं, बल्कि thermodynamics द्वारा allow की गई अधिकतम सीमा से जुड़े हैं
      निष्कर्षतः AES-256 या RSA-4096 को brute force से तोड़ना भौतिक रूप से असंभव है
    • हम पहले से ऐसा कर रहे हैं
      1024-bit keys कई cryptosystems में 10 साल से ज्यादा समय से phase out हो रही हैं
      एक पीछे रह गए अपवाद को छोड़ दें तो ऐसा ही है; और 2048-bit keys को खतरा सिर्फ quantum computers से है, जो RSA itself को ही खतरे में डालता है
      progress linear नहीं होती, इसलिए 1024 कमजोर हुआ तो 2048 भी mechanically जल्द ढह जाएगा—ऐसी बात नहीं है; 1024 पर भी आज वास्तविक attack आसान नहीं है
    • RSA-2048 अभी तक टूटा नहीं है, और उसके बाद RSA इस्तेमाल करने वाली ज्यादातर जगहों पर पहले से common RSA-4096 पर भरोसा किया जा सकता है
      DKIM उन exceptions में से एक है
      DKIM side में Ed25519 के widely adopted होने का इंतजार है, फिर कई असुविधाएं दूर हो जाएंगी
    • इस्तेमाल enforce करने के लिए आखिरकार कुछ न कुछ तोड़ना पड़ता है
      आम तौर पर वह दर्द service operators के बजाय सीधे users पर आता है, और उम्मीद की जाती है कि users इतनी शिकायत करेंगे कि operators ध्यान दें
      लेकिन users इस बात की भी काफी संभावना रखते हैं कि वे ऐसे competitor के पास चले जाएं जो security जैसी छोटी चीज को revenue रोकने न दे
    • 8 साल पहले जब मैं email industry में काम करता था, तब भी 512-bit DKIM बेहद दुर्लभ था
      असल में यह पूछने जैसा है, “हम वह काम क्यों नहीं कर रहे जो हम पहले से कर रहे हैं?”

  • CADO-NFS इस्तेमाल करें तो यह हैरानीजनक रूप से आसान है
    कुछ हफ्ते पहले काम के सिलसिले में मैंने desktop computer से 512-bit RSA DKIM key factorize की थी और सिर्फ 28 घंटे लगे
    खास तौर पर वह AMD Zen 5 9900X था
    दुर्भाग्य से 1024-bit key अभी hobby-level effort से मुश्किल है, लेकिन 2010 में 768-bit key factorize करने वाले पैमाने का academic project हो तो संभव हो सकता है: https://eprint.iacr.org/2010/006.pdf

  • कल Bank of America से account setup की समस्या के बारे में एक email मिला
    यह सही है कि मैंने नया account बनाया था, और email को यह बात, कंपनी का नाम वगैरह पता था
    कोई link नहीं था, सिर्फ BofA business number पर call करने का निर्देश था, और BofA website पर number verify करने पर वही निकला, इसलिए मैंने call किया
    लेकिन किसी ने नहीं बताया कि मुझे email क्यों मिला या account में क्या समस्या है, और agent को इस email भेजे जाने का record भी नहीं मिला
    मुझे 100% यकीन है कि यह email Bank of America से आया था
    इसमें phishing जैसा कुछ नहीं था, न link, न कोई malicious phone number
    SPF, DKIM, DMARC सभी Google के ARC-Authentication-Results में pass थे, और DKIM key भी 2048-bit थी
    जब मैंने Bank of America से जांच करने को कहा, तो उन्होंने कहा कि “यह phishing message रहा होगा” और phishing से सावधान रहने के तरीकों का link भेज दिया
    शायद account creation के दौरान किसी system ने बहुत जल्दी consistency check चला दिया और email generate कर दिया — एक साधारण error होने की संभावना ज्यादा है
    लेकिन चूंकि उन्होंने इसे “phishing” कहा, इसलिए मैंने पूरा material attach करके CTO को FedEx भेजा
    बात दो में से एक है: या तो DKIM key leak हो गई है और उन्हें तुरंत public warning जारी करनी चाहिए, या अक्षम employees और IT systems ने मुझे चक्कर कटवाकर मेरा एक घंटा बर्बाद किया
    किसी भी स्थिति में, मैं पूरी जांच और समाधान चाहता हूं

  • कुछ DNS providers बेहद खराब हैं और सिर्फ 1024-bit लंबाई वाली key तक ही set करने देते हैं
    उदाहरण के लिए wordpress.com ऐसा है

    • 1024-bit को crack करना 512-bit से कई orders of magnitude ज्यादा कठिन है
      संदर्भ के लिए, आखिरी crack किया गया RSA number RSA-250 था, यानी 829-bit, और 2020 में इसमें 2700 core-years लगे थे [1]
      जबकि RSA-155, यानी 512-bit, 1999 में ही factorize हो चुका था
      यह खतरनाक स्थिति नहीं है
      [1]: https://sympa.inria.fr/sympa/arc/cado-nfs/2020-02/msg00001.h...
    • NIST 2035 तक 2048-bit RSA तक को ban करना चाहता है
      वजह यह है कि यह पर्याप्त security level नहीं देता
    • RSA-1024 को RSA-512 से लगभग 80 लाख गुना बेहतर माना जा सकता है, इसलिए इसे crack करने में सिर्फ compute cost ही करीब 6.4 करोड़ dollar होगी
      यह NSA को रोकने के स्तर का नहीं है, लेकिन यह देखते हुए कि DKIM कई protection layers में से एक है, spammers को रोकने के लिए पर्याप्त लगता है
    • DKIM record बस DNS TXT record होता है
      मुझे जिज्ञासा है कि क्या TXT record size की कोई limit है, या फिर वे DKIM जैसा दिखने वाला TXT record parse करने की कोशिश करके fail होते हैं और उसे add करने से मना कर देते हैं

  • अच्छे demonstration के लिए 512-bit key crack करना, भले ही पहले किया जा चुका हो, बहुत valuable security research है
    “यह उन जगहों की list है जो अभी भी 512-bit इस्तेमाल कर रही हैं, इसलिए इन्हें migrate करना चाहिए” यह publicly कहना भी जायज है
    लेकिन production में चल रही real-world key को सीधे crack करना मुझे निजी तौर पर ethical line पार करने जैसा लगता है, इसलिए असहज करता है
    मैं lawyer नहीं हूं, लेकिन यह crime भी हो सकता है, और थोड़ा unnecessary लगता है

    • संबंधित company को vulnerability बताई गई और fix होने के बाद article publish किया गया
      original में now no longer available खोजें
      आम तौर पर जब किसी online system के vulnerable होने को दिखाया जाता है, तो good faith में vulnerability reproduce की जाती है, research document की जाती है और review का अनुरोध किया जाता है
      चाहे cryptosystem crack करना हो, locked game console पर arbitrary code execution पाना हो, voting machine data manipulate किया जा सकता है यह prove करना हो, या Google Meet Q&A comments edit किए जा सकते हैं यह दिखाना हो — process वही है
      सिर्फ यह कहना कि system vulnerable है, ignore किया जा सकता है, लेकिन vulnerable है यह कहना और prove करना ignore करना मुश्किल बना देता है
      और अगर इसके साथ industry-standard disclosure deadline रखकर करीब 60 दिनों तक contact की कोशिश के बाद vulnerability public करने की बात कही जाए, तो ignore करने की गुंजाइश लगभग खत्म हो जाती है
    • key crack करना crime नहीं है
      वह बस math है
      उस math पर निर्भर करके fraud करना या किसी jurisdiction के कानून का उल्लंघन करने वाले emails भेजना illegal है
      मूल बात math नहीं, बल्कि action और intent है
      यह बताना कि कोई बेवकूफी कर रहा है, भी illegal नहीं है, लेकिन वे आपकी जिंदगी मुश्किल बनाने की कोशिश कर सकते हैं
    • यही बात बहुत सी security research पर लागू होती है
      जैसे “bug exploitable है यह दिखाना ठीक है, लेकिन proof-of-concept code लिखना line cross करना है”
      समस्या यह है कि जब तक आप यह नहीं दिखाते कि यह वास्तव में संभव है, ज्यादातर लोग security research की बात नहीं सुनते
    • 1024-bit से छोटी keys इस्तेमाल करने वाले करीब 1700 domains में से वास्तव में नाम सिर्फ एक का public किया गया
      इसके बजाय DKIM RFC ठीक से follow न करने वाले 10 बड़े email providers में से 3, यानी Yahoo, Tuta, Mailfence, को notify करने के बाद public किया गया
    • अगर सिर्फ public information इस्तेमाल की गई और result से कुछ नहीं किया गया, तो real world में use हो रही key crack करना अपने-आप में crime नहीं होने की संभावना ज्यादा लगती है

  • यही वजह थी कि मुझे Hover से DNS management बंद करना पड़ा
    यह 255 characters से लंबे TXT records support नहीं करता, और मुझे ऐसा कोई example भी नहीं मिला जहां Hover पर split records काम करते हों
    आखिर में Digital Ocean इस्तेमाल करना पड़ा
    अगर यह समस्या फिर 10 साल चलने वाली है, तो अच्छा होगा कि elliptic curve cryptography standard बन जाए

  • “ज्यादातर providers ने 512-bit key को सही तरह unsafe पहचाना और DKIM signature reject किया, लेकिन तीन बड़े providers — Yahoo Mail, Mailfence, Tuta — ने dkim=pass report किया” वाले हिस्से में, मुझे जिज्ञासा है कि Google में सच में DKIM signature unsafe होने के कारण fail हुआ था या SPF failure की वजह से

    • DKIM verification RFC 8301 के अनुसार dkim=policy (weak key) result के साथ fail हुआ
      यह ठीक उसी requirement के अनुसार है कि “verifiers को 1024-bit से कम RSA key इस्तेमाल करने वाले signatures को valid signature नहीं मानना चाहिए”

  • 512 बिट का नंबर बड़ा है या छोटा, यह इस पर निर्भर करता है कि वह symmetric cryptography है या asymmetric cryptography
    asymmetric cryptography को हमेशा symmetric cryptography से 8 गुना कमजोर मान सकते हैं
    DKIM asymmetric तरीका है, इसलिए 512-bit DKIM symmetric hash के हिसाब से 64-bit के बराबर है और यह बहुत पहले ही टूट चुका स्तर है
    160-bit SHA-1 तक को भी टूटा हुआ माना जाता है
    अगर DKIM को 512-bit SHA-3 जैसी strength चाहिए, तो कम से कम 4096-bit की जरूरत होगी, और तब भी इसमें SHA-3 की retransmission attack mitigation तकनीकें शामिल नहीं होंगी

    • DKIM कोई encryption algorithm नहीं है
      यह email header में signature डालकर verify करने का standard है
      दुर्भाग्य से DKIM सिर्फ rsa-sha1 और rsa-sha256 signatures ही support करता है: https://datatracker.ietf.org/doc/html/rfc6376/#section-3.3
      अच्छा होगा अगर DKIM को revise करके Ed25519 या उससे मिलते-जुलते signatures की अनुमति दी जाए
    • RSA encryption elliptic-curve cryptography से 10 गुना कमजोर है
      उदाहरण के लिए, 224-bit ECC लगभग 2048-bit RSA जैसा है
      दोनों asymmetric तरीके हैं
      इसके उलट, asymmetric elliptic-curve की strength symmetric cipher AES जैसी होती है
      बेशक, यह quantum computers के सामने कमजोर है