Dependency Confusion
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
संक्षेप में, एक dependency confusion vulnerability तब होती है जब एक प्रोजेक्ट एक लाइब्रेरी का उपयोग कर रहा होता है जिसका गलत स्पेलिंग नाम, अस्तित्वहीन या अनिर्धारित संस्करण होता है और उपयोग की जाने वाली dependency repository सार्वजनिक repositories से अपडेटेड संस्करणों को इकट्ठा करने की अनुमति देती है।
गलत स्पेलिंग: Import reqests
instead of requests
अस्तित्वहीन: Import company-logging
, एक आंतरिक लाइब्रेरी जो अब मौजूद नहीं है
अनिर्धारित संस्करण: Import an internal existent company-requests
लाइब्रेरी, लेकिन repo सार्वजनिक repos की जांच करता है यह देखने के लिए कि क्या वहाँ बड़े संस्करण हैं।
सभी मामलों में हमलावर को केवल एक दुष्ट पैकेज का नाम प्रकाशित करने की आवश्यकता होती है जो पीड़ित कंपनी द्वारा उपयोग की जाने वाली लाइब्रेरी का नाम है।
यदि आपकी कंपनी एक लाइब्रेरी को आयात करने की कोशिश कर रही है जो आंतरिक नहीं है, तो बहुत संभावना है कि लाइब्रेरी का repo इसे सार्वजनिक repositories में खोजने जा रहा है। यदि एक हमलावर ने इसे बनाया है, तो आपका कोड और चलने वाली मशीनें बहुत संभावना है कि समझौता की जाएंगी।
डेवलपर्स के लिए यह बहुत सामान्य है कि वे उपयोग की जाने वाली लाइब्रेरी का कोई संस्करण निर्दिष्ट नहीं करते हैं, या केवल एक मेजर संस्करण निर्दिष्ट करते हैं। फिर, इंटरप्रेटर उन आवश्यकताओं के अनुसार नवीनतम संस्करण डाउनलोड करने की कोशिश करेगा।
यदि लाइब्रेरी एक ज्ञात बाहरी लाइब्रेरी है (जैसे python requests
), तो एक हमलावर ज्यादा कुछ नहीं कर सकता, क्योंकि वह requests
नाम की लाइब्रेरी नहीं बना सकेगा (जब तक कि वह मूल लेखक न हो)।
हालांकि, यदि लाइब्रेरी आंतरिक है, जैसे इस उदाहरण में requests-company
, यदि लाइब्रेरी repo बाहरी रूप से नए संस्करणों की जांच करने की अनुमति देता है, तो यह सार्वजनिक रूप से उपलब्ध एक नए संस्करण की खोज करेगा।
तो यदि एक हमलावर जानता है कि कंपनी requests-company
लाइब्रेरी संस्करण 1.0.1 का उपयोग कर रही है (छोटे अपडेट की अनुमति देता है)। वह लाइब्रेरी requests-company
संस्करण 1.0.2 प्रकाशित कर सकता है और कंपनी उस लाइब्रेरी का उपयोग करेगी बजाय आंतरिक लाइब्रेरी के।
यह vulnerability AWS CodeArtifact में पाई गई थी (पढ़ें इस ब्लॉग पोस्ट में विवरण). AWS ने इसे इस तरह से ठीक किया कि यह निर्दिष्ट करने की अनुमति देता है कि एक लाइब्रेरी आंतरिक है या बाहरी, ताकि बाहरी repositories से आंतरिक dependencies डाउनलोड करने से बचा जा सके।
Dependency confusion के बारे में मूल पोस्ट में लेखक ने हजारों एक्सपोज़ किए गए package.json फ़ाइलों की खोज की जो जावास्क्रिप्ट प्रोजेक्ट की dependencies को शामिल करती हैं।
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)