Dependency Confusion

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

मूल जानकारी

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

  • गलत तरीके से लिखा गया: requests की जगह reqests आयात करें

  • अस्तित्व में नहीं है: कंपनी-लॉगिंग को आयात करें, एक आंतरिक पुस्तकालय जो अब मौजूद नहीं है

  • अनिर्दिष्ट संस्करण: एक आंतरिक मौजूद कंपनी-रिक्वेस्ट्स पुस्तकालय को आयात करें, लेकिन रिपॉ चेक सार्वजनिक रिपॉ करने के लिए करता है कि क्या अधिक वर्शन हैं।

शोषण

सभी मामलों में हमलावर को केवल एक दुराचारी पैकेज का नाम प्रकाशित करने की आवश्यकता होती है जिसे पीड़ित कंपनी द्वारा उपयोग की जाने वाली पुस्तकालयों का नाम है।

गलत तरीके से लिखा गया और अस्तित्व में नहीं है

यदि आपकी कंपनी को आंतरिक नहीं होने वाली पुस्तकालय आयात करने की कोशिश कर रही है, तो संभावना है कि पुस्तकालय का रिपॉ इसे सार्वजनिक रिपॉ में खोज रहा होगा। यदि कोई हमलावर ने इसे बनाया है, तो आपका कोड और मशीनें जिन पर चल रही हैं, संभावना है कि कम्प्रोमाइज़ हो जाएंगी।

Unspecified Version

It's very common for developers to not specify any version of the library used, or specify just a mayor version. Then, the interpreter will try to download the latest version fitting those requirements. If the library is a known external library (like python requests), an attacker cannot do much, as he won't be able to create a library called requests (unless he is the original author). However, if the library is internal, like requests-company in this example, if the library repo allows to check for new versions also externally, it will search for a newer version publicly available. So if an attacker knows that the company is using the requests-company library version 1.0.1 (allow minor updates). He can publish the library requests-company version 1.0.2 and the company will use that library instead of the internal one.

AWS Fix

This vulnerability was found in AWS CodeArtifact (read the details in this blog post). AWS fixed this by allowing to specify if a library is internal or external, to avoid downloading internal dependencied from external repositories.

Finding Vulnerable Libraries

In the original post about dependency confusion the author searched for thousands of exposed package.json files containing javascript project’s dependencies.

References

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Last updated