ТЕХНІЧНИЙ ОПИС

Зловмисники можуть шукати у відкритих репозиторіях коду інформацію про жертв, яка може бути використана під час вибору цілі. Жертви можуть зберігати код у репозиторіях на різних сторонніх вебсайтах, таких як GitHub, GitLab, SourceForge та BitBucket. Користувачі зазвичай взаємодіють із репозиторіями коду через вебзастосунки або утиліти командного рядка, такі як git.

Зловмисники можуть шукати в різних публічних репозиторіях різноманітну інформацію про жертву. Публічні репозиторії коду часто можуть бути джерелом загальної інформації, такої як мови програмування, що зазвичай використовуються, бібліотеки, а також імена співробітників. Зловмисники також могут виявити більш конфіденційні дані, включаючи випадково витеклі облікові дані або API-ключі. Інформація з цих джерел може виявити можливості для інших форм розвідки (наприклад, фішинг для отримання інформації), розгортання оперативних ресурсів (наприклад, компрометація облікових записів або інфраструктури) та/або отримання початкового доступу (наприклад, дійсні облікові записи або фішинг).

Примітка: Ця техніка відрізняється від «Code Repositories» (T1213.003), яка зосереджена на зборі даних (Collection) із приватних та внутрішніх репозиторіїв.

Репозиторії як відкриті двері в інфраструктуру Для сучасного розробника GitHub — це портфоліо, але для хакера — це детальна інструкція зі зламу та джерело безкоштовних “ключів” від вашої мережі.

  • Пошук секретів (Secrets Hunting): Зловмисники використовують інструменти на кшталт trufflehog або gitleaks для автоматичного сканування мільйонів коммітів у пошуках рядків, що нагадують паролі, приватні ключі SSH або токени AWS.
  • Аналіз залежностей: Вивчаючи файли package.json або requirements.txt, хакер бачить версії бібліотек, які ви використовуєте. Якщо у вашому коді є застаріла бібліотека з відомою вразливістю, він атакує саме її.
  • Історія коммітів: Навіть якщо ви видалили пароль у останньому комміті, він назавжди залишається в історії Git. Хакери переглядають історію змін, щоб знайти дані, які були «приховані» пізніше.

Сценарії розвідки:

  • «Випадковий public»: Розробник створив публічний репозиторій замість приватного для швидкого тестування і завантажив туди .env файл із доступами до робочої бази даних. Хакер знаходить цей файл за лічені хвилини.
  • «Корпоративний шпіонаж»: Аналізуючи активність розробників певної компанії на GitHub, зловмисники розуміють, над яким новим продуктом працює організація, які технології впроваджує та хто є провідним спеціалістом у команді.
  • «Пошук Hardcoded Credentials»: Хакер шукає в коді захардкоджені пошти адмінів або внутрішні URL-адреси (наприклад, internal.dev.ua), щоб зрозуміти структуру внутрішньої мережі.

Як захиститися?

  • Використання .gitignore: Завжди додавайте конфігураційні файли, логи та папки з секретами до .gitignore ще до першого комміту.
  • Pre-commit hooks: Встановіть локальні скрипти (наприклад, pre-commit), які будуть автоматично перевіряти ваш код на наявність секретів перед кожним збереженням змін у Git.
  • Secret Management: Використовуйте спеціалізовані сервіси для зберігання паролів (HashiCorp Vault, AWS Secrets Manager) замість зберігання їх у текстових файлах або зміних оточення.
  • Сканування репозиторіїв: Регулярно запускайте інструменти аудиту (GitHub Secret Scanning) для своїх публічних та приватних репозиторіїв, щоб вчасно виявити витоки.