{% hint style="success" %}
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.
{% embed url="https://websec.nl/" %}
У підсумку, вразливість змішування залежностей виникає, коли проект використовує бібліотеку з неправильно написаною назвою, неіснуючою або з непозначеною версією, а використовуваний репозиторій залежностей дозволяє збирати оновлені версії з публічних репозиторіїв.
- Неправильно написана: Імпорт
reqests
замістьrequests
- Неіснуюча: Імпорт
company-logging
, внутрішньої бібліотеки, яка більше не існує - Непозначена версія: Імпорт внутрішньої існуючої бібліотеки
company-requests
, але репозиторій перевіряє публічні репозиторії, щоб дізнатися, чи є новіші версії.
{% hint style="warning" %} У всіх випадках атакуючому потрібно лише опублікувати шкідливий пакет з назвою бібліотек, які використовує компанія-жертва. {% endhint %}
Якщо ваша компанія намагається імпортувати бібліотеку, яка не є внутрішньою, ймовірно, репозиторій бібліотек буде шукати її в публічних репозиторіях. Якщо атакуючий створив її, ваш код і машини, що працюють, ймовірно, будуть скомпрометовані.
Досить поширено, що розробники не вказують жодну версію використовуваної бібліотеки або вказують лише основну версію. Тоді інтерпретатор спробує завантажити остання версію, що відповідає цим вимогам.
Якщо бібліотека є відомою зовнішньою бібліотекою (як python requests
), атакуючий не може багато зробити, оскільки він не зможе створити бібліотеку з назвою requests
(якщо він не є оригінальним автором).
Однак, якщо бібліотека є внутрішньою, як requests-company
в цьому прикладі, якщо репозиторій бібліотеки дозволяє перевіряти нові версії також зовні, він буде шукати новішу версію, доступну публічно.
Отже, якщо атакуючий знає, що компанія використовує бібліотеку requests-company
версії 1.0.1 (дозволяє незначні оновлення). Він може опублікувати бібліотеку requests-company
версії 1.0.2, і компанія буде використовувати цю бібліотеку замість внутрішньої.
Цю вразливість було виявлено в AWS CodeArtifact (читайте деталі в цьому блозі).
AWS виправив це, дозволивши вказувати, чи є бібліотека внутрішньою чи зовнішньою, щоб уникнути завантаження внутрішніх залежностей з зовнішніх репозиторіїв.
В оригінальному пості про змішування залежностей автор шукав тисячі відкритих файлів package.json, що містять залежності проектів на JavaScript.
- https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
- https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d
{% embed url="https://websec.nl/" %}
{% hint style="success" %}
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.