Dependency Confusion
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Basic Information
संक्षेप में, एक dependency confusion vulnerability तब होती है जब एक प्रोजेक्ट एक लाइब्रेरी का उपयोग कर रहा होता है जिसका गलत स्पेलिंग नाम, अस्तित्वहीन या अनिर्धारित संस्करण होता है और उपयोग की जाने वाली dependency repository सार्वजनिक repositories से अपडेटेड संस्करणों को इकट्ठा करने की अनुमति देती है।
गलत स्पेलिंग: Import
reqests
instead ofrequests
अस्तित्वहीन: Import
company-logging
, एक आंतरिक लाइब्रेरी जो अब मौजूद नहीं हैअनिर्धारित संस्करण: Import an internal existent
company-requests
लाइब्रेरी, लेकिन repo सार्वजनिक repos की जांच करता है यह देखने के लिए कि क्या वहाँ बड़े संस्करण हैं।
Exploitation
सभी मामलों में हमलावर को केवल एक दुष्ट पैकेज का नाम प्रकाशित करने की आवश्यकता होती है जो पीड़ित कंपनी द्वारा उपयोग की जाने वाली लाइब्रेरी का नाम है।
Misspelled & Inexistent
यदि आपकी कंपनी एक लाइब्रेरी को आयात करने की कोशिश कर रही है जो आंतरिक नहीं है, तो बहुत संभावना है कि लाइब्रेरी का repo इसे सार्वजनिक repositories में खोजने जा रहा है। यदि एक हमलावर ने इसे बनाया है, तो आपका कोड और चलने वाली मशीनें बहुत संभावना है कि समझौता की जाएंगी।
Unspecified Version
डेवलपर्स के लिए यह बहुत सामान्य है कि वे उपयोग की जाने वाली लाइब्रेरी का कोई संस्करण निर्दिष्ट नहीं करते हैं, या केवल एक मेजर संस्करण निर्दिष्ट करते हैं। फिर, इंटरप्रेटर उन आवश्यकताओं के अनुसार नवीनतम संस्करण डाउनलोड करने की कोशिश करेगा।
यदि लाइब्रेरी एक ज्ञात बाहरी लाइब्रेरी है (जैसे python requests
), तो एक हमलावर ज्यादा कुछ नहीं कर सकता, क्योंकि वह requests
नाम की लाइब्रेरी नहीं बना सकेगा (जब तक कि वह मूल लेखक न हो)।
हालांकि, यदि लाइब्रेरी आंतरिक है, जैसे इस उदाहरण में requests-company
, यदि लाइब्रेरी repo बाहरी रूप से नए संस्करणों की जांच करने की अनुमति देता है, तो यह सार्वजनिक रूप से उपलब्ध एक नए संस्करण की खोज करेगा।
तो यदि एक हमलावर जानता है कि कंपनी requests-company
लाइब्रेरी संस्करण 1.0.1 का उपयोग कर रही है (छोटे अपडेट की अनुमति देता है)। वह लाइब्रेरी requests-company
संस्करण 1.0.2 प्रकाशित कर सकता है और कंपनी उस लाइब्रेरी का उपयोग करेगी बजाय आंतरिक लाइब्रेरी के।
AWS Fix
यह vulnerability AWS CodeArtifact में पाई गई थी (पढ़ें इस ब्लॉग पोस्ट में विवरण). AWS ने इसे इस तरह से ठीक किया कि यह निर्दिष्ट करने की अनुमति देता है कि एक लाइब्रेरी आंतरिक है या बाहरी, ताकि बाहरी repositories से आंतरिक dependencies डाउनलोड करने से बचा जा सके।
Finding Vulnerable Libraries
Dependency confusion के बारे में मूल पोस्ट में लेखक ने हजारों एक्सपोज़ किए गए package.json फ़ाइलों की खोज की जो जावास्क्रिप्ट प्रोजेक्ट की dependencies को शामिल करती हैं।
References
Last updated