Dependency Confusion

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

{% embed url="https://websec.nl/" %}

Basic Information

संक्षेप में, एक dependency confusion vulnerability तब होती है जब एक प्रोजेक्ट एक लाइब्रेरी का उपयोग कर रहा होता है जिसका गलत स्पेलिंग नाम, अस्तित्वहीन या अनिर्धारित संस्करण होता है और उपयोग की जाने वाली dependency repository सार्वजनिक repositories से अपडेटेड संस्करणों को इकट्ठा करने की अनुमति देती है।

गलत स्पेलिंग: Import reqests instead of requests
अस्तित्वहीन: Import company-logging, एक आंतरिक लाइब्रेरी जो अब मौजूद नहीं है
अनिर्धारित संस्करण: Import an internal existent company-requests लाइब्रेरी, लेकिन repo सार्वजनिक repos की जांच करता है यह देखने के लिए कि क्या वहाँ बड़े संस्करण हैं।

Exploitation

{% hint style="warning" %} सभी मामलों में हमलावर को केवल एक दुष्ट पैकेज का नाम प्रकाशित करने की आवश्यकता होती है जो पीड़ित कंपनी द्वारा उपयोग की जाने वाली लाइब्रेरी का नाम है। {% endhint %}

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