DigiCert स्क्रीनसेवर हमला: Code Signing भरोसे की असली परीक्षा

SecurityWeek के अनुसार, मैलवेयर ने दो endpoints को संक्रमित किया: एक 3 अप्रैल को पहचाना गया और दूसरा 14 अप्रैल को । उसी रिपोर्ट के मुताबिक, हमलावरों ने संक्रमित सिस्टम से DigiCert के internal support portal की ओर pivot किया । वहां authenticated support analysts के पास ग्राहक खातों में सीमित तरीके से proxy करने की सुविधा थी, जिससे pending certificates से जुड़े कुछ functions, including initialization codes, तक पहुंच बन सकी । BleepingComputer ने भी दायरा सीमित बताया और लिखा कि यह exposure पहले से approved, लेकिन अभी deliver न हुए EV Code Signing प्रमाणपत्रों के initialization codes तक था ।

EV Code Signing क्यों इतना संवेदनशील है

Code Signing प्रमाणपत्र software distribution की trust chain का हिस्सा हैं: वे यह भरोसा दिलाने में मदद करते हैं कि software किस स्रोत से आया है और रास्ते में बदला तो नहीं गया। DigiCert एक बड़ी Certificate Authority है, जिस पर browsers और operating systems भरोसा करते हैं; उसके Code Signing प्रमाणपत्र software developers इस्तेमाल करते हैं ।

EV यानी Extended Validation प्रमाणपत्रों को आम तौर पर अधिक भरोसे के संकेत के तौर पर देखा जाता है। यही वजह है कि उनका दुरुपयोग खतरनाक है। ThreatNoir ने बताया कि हासिल किए गए कुछ Code Signing प्रमाणपत्र मैलवेयर साइन करने में इस्तेमाल हुए । Vectra ने इसी व्यापक पैटर्न की ओर इशारा किया है: threat actors EV certificates से malicious files साइन कर भरोसे का फायदा उठा सकते हैं, और जो संगठन केवल signature-based trust पर निर्भर रहते हैं वे कमजोर पड़ते हैं ।

क्या यह DigiCert की Root keys का समझौता था?

उपलब्ध रिपोर्टों में compromised support endpoints, internal support functions और initialization codes तक पहुंच का जिक्र है । इन्हीं स्रोतों के आधार पर Root keys या CA signing keys के compromise का दावा साबित नहीं होता।

यह फर्क महत्वपूर्ण है। Root या CA key compromise कहीं व्यापक संकट होता, जबकि उपलब्ध जानकारी इस घटना को support और certificate issuance workflow के दुरुपयोग के रूप में दिखाती है । फिर भी जोखिम वास्तविक था, क्योंकि Code Signing भरोसे का वही संकेत है जिसे सुरक्षा उत्पाद और users अक्सर legitimacy के संकेत के रूप में पढ़ते हैं ।

नुकसान का आकार: आंकड़े क्यों अलग दिखते हैं

इस incident पर सार्वजनिक रिपोर्टिंग में संख्याएं अलग-अलग हैं, क्योंकि वे अलग categories गिनती हैं।

• ThreatNoir सीमित संख्या में Code Signing प्रमाणपत्रों की बात करता है और कहता है कि उनमें से कुछ मैलवेयर साइन करने में इस्तेमाल हुए ।
• Risky Business ने 27 stolen Code Signing certificates की रिपोर्ट की, जिनका बाद में मैलवेयर साइन करने में इस्तेमाल हुआ ।
• ThreatLocker ने 60 total revoked Code Signing certificates का आंकड़ा दिया ।

इसलिए 27 और 60 को सीधे-सीधे विरोधाभास मानना सही नहीं होगा। एक संख्या stolen या abused certificates के बारे में हो सकती है, दूसरी revoked certificates के बारे में। सुरक्षा के नजरिए से सबक फिर भी साफ है: भरोसेमंद दिखने वाले कुछ प्रमाणपत्र भी मैलवेयर अभियान को वैधता का मुखौटा दे सकते हैं ।

रोकथाम और सफाई: रद्दीकरण, pending orders और उसके बाद

BleepingComputer के अनुसार, DigiCert ने पहचाने गए प्रमाणपत्रों को discovery के 24 घंटे के भीतर revoke किया और revocation date को उनके issuance date पर set किया । उसी रिपोर्ट में कहा गया कि प्रभावित समय-सीमा की pending orders को एहतियातन cancel किया गया । ThreatNoir ने भी लिखा कि प्रभावित certificates 24 घंटे के भीतर revoke किए गए और उस window की pending orders cancel की गईं ।

लेकिन revoke करना अंतिम समाधान नहीं होता। सुरक्षा टीमों को signed binaries की जांच certificate data, hashes, file behavior, network activity और threat intelligence के साथ मिलाकर करनी पड़ती है, क्योंकि EV signatures को हमलावर भरोसे के shortcut की तरह इस्तेमाल कर सकते हैं ।

Microsoft Defender ने भ्रम और बढ़ाया

इसी दौर में Microsoft Defender से जुड़ी false positive समस्या ने triage को और मुश्किल बनाया। BleepingComputer ने रिपोर्ट किया कि Microsoft Defender ने DigiCert certificates को गलत तरीके से Trojan:Win32/Cerdigent.A!dha के रूप में flag किया । daily.dev के सारांश के अनुसार, 30 अप्रैल के signature update के बाद legitimate DigiCert root certificates गलत तरीके से mark हुए; Microsoft ने बाद में Security Intelligence update 1.449.430.0 से fix जारी किया और हटाए गए certificates restore किए ।

कंपनियों के लिए इसका मतलब था कि उन्हें तीन चीजें अलग-अलग पहचाननी थीं: सचमुच misuse हुए certificates, signed malware की alerts, और legitimate certificates पर false positives ।

सुरक्षा टीमों के लिए मुख्य सबक

• Digital signature को verdict नहीं, signal मानें। Valid या EV signature यह guarantee नहीं देती कि file सुरक्षित है। हमलावर EV certificates से malicious files साइन कर भरोसे का फायदा उठा सकते हैं ।
• Certificate details जरूर जांचें। issuer, serial number, certificate chain, timestamp और revocation status जैसे संकेत signed binary की जांच में जरूरी हैं। इस मामले में revocation और revocation date को issuance date तक ले जाना containment का अहम हिस्सा था ।
• Behavior-based detection को प्राथमिकता दें। process tree, persistence, network connections, sandbox results और hashes को signature के साथ जोड़कर देखें; signed malware का मकसद ही भरोसे की जांच को आसान बनाना होता है ।
• Support और admin portals को high-risk zone मानें। इस incident ने दिखाया कि सीमित support functions भी संवेदनशील बन सकते हैं, अगर उनसे customer accounts या certificate initialization codes तक access मिलता है ।
• False positives के लिए disciplined process रखें। Defender वाले episode ने दिखाया कि certificate alert हमेशा वास्तविक infection नहीं होती; legitimate DigiCert root certificates भी गलत तरीके से flag हुए और बाद में Microsoft update से restore किए गए ।

निष्कर्ष

DigiCert incident ने Code Signing को बेकार साबित नहीं किया; उसने यह दिखाया कि Code Signing अकेला काफी नहीं है। उपलब्ध रिपोर्टों के आधार पर यह Root या CA keys की पूर्ण compromise कहानी नहीं, बल्कि support systems और certificate issuance workflow के दुरुपयोग की घटना थी । फिर भी इसका असर बड़ा था: अगर मैलवेयर भरोसेमंद दिखने वाली signature पहन ले, तो defensive judgment को signature से आगे जाकर behavior, context और revocation data तक देखना ही होगा।