कैसे चालीस मिनट के समझौता किए गए AI कोड ने तकनीकी दिग्गजों के डिजिटल खजाने खाली कर दिए

एक आधुनिक एंटरप्राइज सुरक्षा स्टैक की लाइसेंसिंग और कर्मियों की फीस में लाखों डॉलर खर्च होते हैं। ये संगठन एक मजबूत सुरक्षा घेरा बनाए रखने के लिए शीर्ष स्तर के भेद्यता स्कैनर (vulnerability scanners) और सख्त एक्सेस कंट्रोल तैनात करते हैं। फिर भी, मार्च में चालीस मिनट की एक छोटी सी अवधि ने साबित कर दिया कि एक लोकप्रिय AI टूल में एक ही दुर्भावनापूर्ण डिपेंडेंसी इन सुरक्षा घेरों को पूरी तरह से बायपास करने के लिए पर्याप्त है। LiteLLM सप्लाई-चेन हमले के परिणामस्वरूप दुनिया के कुछ सबसे सुरक्षित वातावरणों से टेराबाइट्स संवेदनशील क्रेडेंशियल्स चोरी हो गए, जिनमें Microsoft, Amazon और Samsung द्वारा प्रबंधित वातावरण भी शामिल थे।

जोखिम के दृष्टिकोण से, यह घटना एक प्रणालीगत विफलता को उजागर करती है कि हम AI-संचालित सॉफ़्टवेयर बनाने के लिए उपयोग किए जाने वाले टूल की जांच कैसे करते हैं। यह उल्लंघन स्वयं आर्टिफिशियल इंटेलिजेंस में किसी खामी के कारण नहीं हुआ। यह इसलिए हुआ क्योंकि AI को तैनात करने के लिए हम जिस DevOps इंफ्रास्ट्रक्चर का उपयोग करते हैं वह कमजोर है। जब 2,500 संगठनों के डेवलपर्स ने Python Package Index से LiteLLM के संस्करण 1.82.7 और 1.82.8 डाउनलोड किए, तो उन्होंने अनजाने में अपने सबसे संवेदनशील सिस्टम में एक डिजिटल ट्रोजन हॉर्स को आमंत्रित कर लिया।

सुरक्षित स्कैनर का विरोधाभास

इस उल्लंघन का सबसे चौंकाने वाला पहलू इसकी उत्पत्ति है। संक्रमण की शुरुआत Trivy पर एक सप्लाई-चेन हमले के साथ हुई, जो एक व्यापक रूप से सम्मानित ओपन सोर्स भेद्यता स्कैनर है। संगठन विशेष रूप से सुरक्षा खामियों को खोजने के लिए Trivy का उपयोग करते हैं। सुरक्षा प्रदान करने के लिए बने टूल को संक्रमित करके, हमलावरों ने पूर्ण विश्वास की स्थिति प्राप्त कर ली। पर्दे के पीछे, हमलावरों ने Trivy डेवलपर्स द्वारा अपने ऑटोमेशन टोकन को प्रबंधित करने के तरीके में एक चूक का फायदा उठाया। हालांकि टीम ने एक समझौता किए गए टोकन को बदलने (rotate) का प्रयास किया, लेकिन वे बीस दिनों तक इसे पूरी तरह से रद्द (revoke) करने में विफल रहे। इस चूक ने खतरे के कारकों को डाउनस्ट्रीम बिल्ड में दुर्भावनापूर्ण कोड को फोर्स-पुश करने के लिए तीन सप्ताह की अवधि दे दी।

यह संक्रमण LiteLLM में आने से पहले KICS और Telnyx Python SDK सहित अन्य सॉफ़्टवेयर पैकेजों में फैल गया। यह एक वास्तुशिल्प विरोधाभास पैदा करता है जहाँ हमले की सतह को मजबूत करने के लिए डिज़ाइन किए गए टूल ही शोषण का प्राथमिक जरिया बन जाते हैं। क्लाउड वातावरण का ऑडिट करने के अपने अनुभव में, मैं अक्सर पाता हूँ कि टीमें अपने सुरक्षा उपकरणों पर आँख मूंदकर भरोसा करती हैं। वे मान लेते हैं कि यदि कोई स्कैनर आधिकारिक और लोकप्रिय है, तो उसकी अखंडता की गारंटी है। यह घटना साबित करती है कि ऐसा अनुमान एक गंभीर भेद्यता है।

क्लाउड के केंद्र में चालीस मिनट की खिड़की

LiteLLM के लिए सक्रिय संक्रमण की वास्तविक अवधि उल्लेखनीय रूप से संक्षिप्त थी। केवल चालीस मिनट के लिए, समझौता किए गए संस्करण आधिकारिक Python Package Index (PyPI) रिपॉजिटरी पर उपलब्ध थे। उस कम समय में, दुनिया भर के स्वचालित CI/CD पाइपलाइनों और डेवलपर्स ने दुर्भावनापूर्ण कोड खींच लिया। आधुनिक सॉफ़्टवेयर वितरण की गति का अर्थ है कि चालीस मिनट लाखों सिस्टम को संक्रमित करने के लिए पर्याप्त समय से अधिक है।

सुरक्षा फर्मों CloudSEK और Hudson Rock ने चोरी किए गए डेटा वाली 195TB फ़ाइल प्राप्त करने के बाद इसके परिणामों का विश्लेषण किया। जानकारी की मात्रा चौंका देने वाली है। डंप में क्लाउड कुंजियाँ (cloud keys), रिपॉजिटरी टोकन, SSH कुंजियाँ और Kubernetes सीक्रेट्स शामिल हैं। ये डिजिटल साम्राज्य की मास्टर कुंजियाँ हैं। सक्रिय रूप से कहें तो, यह तथ्य कि चालीस मिनट की खिड़की टेराबाइट्स डेटा दे सकती है, यह दर्शाता है कि संक्रमित कोड उच्च-मूल्य वाले रहस्यों की पहचान करने और उन्हें बाहर निकालने में अत्यधिक कुशल था।

मेमोरी स्क्रैपिंग और संग्रहीत रहस्यों की विषाक्त संपत्ति

हमले का तंत्र सरल और विनाशकारी दोनों था। LiteLLM के समझौता किए गए संस्करणों में संक्रमित मशीन की मेमोरी तक पहुँचने के लिए डिज़ाइन किया गया कोड था। अधिकांश डेवलपर्स का मानना है कि यदि कोई रहस्य टेक्स्ट फ़ाइल में सहेजा नहीं गया है, तो वह सुरक्षित है। यह एक भ्रम है। दुर्भावनापूर्ण कोड ने सिस्टम मेमोरी की सामग्री को खंगाला, पर्यावरण चर (environment variables) और सक्रिय सत्र टोकन की तलाश की।

जब डेटा को अनुचित तरीके से संभाला जाता है, तो वह एक विषाक्त संपत्ति बन जाता है। इस मामले में, "डेटा" में 434,000 CI/CD पाइपलाइनों को प्रबंधित करने के लिए आवश्यक क्रेडेंशियल्स शामिल थे। ये पाइपलाइन सॉफ़्टवेयर विकास की असेंबली लाइनें हैं। यदि किसी हमलावर के पास पाइपलाइन के क्रेडेंशियल्स हैं, तो वे कंपनी द्वारा अपने ग्राहकों को जारी किए जाने वाले हर भविष्य के अपडेट में अपना कोड इंजेक्ट कर सकते हैं। शोधकर्ताओं ने नोट किया कि इनमें से कई क्रेडेंशियल्स मेमोरी में बैठे सादे-टेक्स्ट चर थे, जो पूरी तरह से असुरक्षित थे। एकत्र किए गए डेटा में सक्रिय डेटाबेस पासवर्ड और तीसरे पक्ष की API कुंजियाँ शामिल हैं जिनमें किसी भी पहचान संबंधी जानकारी की कमी है, जिससे शोधकर्ताओं के लिए सही पीड़ितों को सूचित करना भी मुश्किल हो गया है।

किशोरों का खतरा और डेवऑप्स अदूरदर्शिता की वास्तविकता

हमले की जिम्मेदारी TeamPCP पर है, जो मुख्य रूप से किशोरों से बना एक समूह है। हालांकि उनके तरीकों में उच्च जटिलता के जीरो-डे कारनामे शामिल नहीं रहे होंगे, लेकिन उनकी सफलता निर्विवाद है। स्वतंत्र सुरक्षा शोधकर्ता केविन ब्यूमोंट ने नोट किया कि ये हमलावर उन संगठनों के चारों ओर चक्कर लगा रहे हैं जो वर्तमान में AI उत्पादों को बाजार में लाने की जल्दी में व्यस्त हैं।

यह जल्दबाजी डेवऑप्स अदूरदर्शिता (DevOps myopia) पैदा करती है। संगठन सॉफ़्टवेयर सप्लाई चेन सुरक्षा की बुनियादी स्वच्छता के बजाय AI एकीकरण की गति को प्राथमिकता देते हैं। जब मैं एन्क्रिप्टेड चैनलों के माध्यम से व्हाइट-हैट हैकर्स के साथ संवाद करता हूँ, तो आम सहमति हमेशा एक ही होती है: यदि लक्ष्य दरवाजा खुला छोड़ देता है तो आपको किसी परिष्कृत शोषण की आवश्यकता नहीं है। AI में "अगली बड़ी चीज़" पर ध्यान केंद्रित करके, कई फर्मों ने अपनी डिपेंडेंसी की अखंडता को सत्यापित करने की बुनियादी आवश्यकता को नजरअंदाज कर दिया।

अधूरे क्रेडेंशियल रोटेशन की विफलता

शायद इस कहानी का सबसे चिंताजनक हिस्सा प्रभावित संगठनों का प्रतिक्रियात्मक रवैया है। उल्लंघन का खुलासा होने के बाद, कई बड़ी तकनीकी कंपनियों ने दावा किया कि उन्होंने अपनी कुंजियाँ पहले ही बदल दी हैं और यह घटना कोई बड़ी बात नहीं थी। हालांकि, सुरक्षा समुदाय द्वारा सत्यापन प्रयासों ने एक अलग कहानी बताई।

केविन ब्यूमोंट ने बताया कि एक प्रमुख अमेरिकी प्रौद्योगिकी कंपनी द्वारा सभी क्रेडेंशियल्स रोटेट किए जाने का दावा करने के बाद, उन्होंने उनके सार्वजनिक-सामना वाले बुनियादी ढांचे के खिलाफ लीक हुई कुंजियों का परीक्षण किया। लगभग हर कुंजी अभी भी काम कर रही थी। यह घटना प्रतिक्रिया के प्रति एक सतही दृष्टिकोण का सुझाव देता है। कुंजी को रोटेट करना उसे रद्द (revoke) करने के समान नहीं है। यदि पुरानी कुंजी अभी भी द्वितीयक सिस्टम या लीगेसी वातावरण में मान्य है, तो उल्लंघन सक्रिय रहता है। इस परिमाण के उल्लंघन की स्थिति में, एक संगठन को यह मान लेना चाहिए कि संक्रमित वातावरण के लिए सुलभ हर रहस्य से समझौता किया गया है। आंशिक रोटेशन अनिवार्य रूप से कोई रोटेशन नहीं होने के बराबर है।

सप्लाई चेन लचीलेपन के लिए व्यावहारिक कदम

यदि आपका संगठन LiteLLM, Trivy, या किसी AI प्रॉक्सी इंफ्रास्ट्रक्चर का उपयोग करता है, तो निष्क्रिय प्रतिक्रिया का समय बीत चुका है। हमले की सतह का आकलन करने के लिए पिछले छह महीनों में आपकी CI/CD पाइपलाइनों से गुजरने वाले प्रत्येक क्रेडेंशियल के विस्तृत ऑडिट की आवश्यकता होती है।

तत्काल शमन चेकलिस्ट:

• संस्करणों को सत्यापित करें: LiteLLM संस्करण 1.82.7 और 1.82.8 के लिए अपने वातावरण का ऑडिट करें। भले ही आपने अपडेट कर लिया हो, लेकिन डेटा संभवतः उस समय के दौरान चोरी हो गया था जब वे संस्करण सक्रिय थे।
• आक्रामक क्रेडेंशियल निरसन (Revocation): केवल पासवर्ड अपडेट न करें। आपके पर्यावरण चर में मौजूद प्रत्येक क्लाउड कुंजी (AWS/Azure/GCP), Kubernetes सेवा खाता टोकन और Git व्यक्तिगत एक्सेस टोकन (PAT) को अमान्य करें और रोटेट करें।
• ऑडिट लॉगिंग और इग्रेस (Egress): मार्च महीने के दौरान अज्ञात IP पतों पर असामान्य आउटबाउंड ट्रैफ़िक की तलाश करें। यदि टेराबाइट्स डेटा की चोरी ठीक से कॉन्फ़िगर की गई होती, तो इग्रेस फ़िल्टरिंग अलर्ट ट्रिगर होने चाहिए थे।
• पिनिंग और हैशिंग लागू करें: आगे बढ़ते हुए, अपनी CI/CD पाइपलाइनों को किसी पैकेज के "नवीनतम" संस्करण को खींचने की अनुमति न दें। डिपेंडेंसी पिनिंग का उपयोग करें और अपने बिल्ड वातावरण में प्रवेश करने से पहले प्रत्येक बाहरी लाइब्रेरी के SHA-256 हैश को सत्यापित करें।

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

स्रोत:

• CloudSEK Threat Intelligence Report on LiteLLM Supply Chain Attack
• Hudson Rock Analysis of TeamPCP Data Dump
• MITRE ATT&CK Framework: Supply Chain Compromise (T1195)
• NIST Software Supply Chain Security Guidance

अस्वीकरण: यह लेख केवल सूचनात्मक और शैक्षिक उद्देश्यों के लिए है और पेशेवर साइबर सुरक्षा ऑडिट या घटना प्रतिक्रिया सेवा का स्थान नहीं लेता है।