Наткнулись на статью о том, как хакеры могут взломать self-hosted GitLab через уязвимости в CI/CD, и мерах защиты. Автор фокусируется на сценарии с глобальными
instance runners, где аутентифицированный пользователь может выполнить код на runner-хосте. После небольших вводных описывается сценарий атаки:
⚪️ Доступ к GitLab: аутентификация через SSO (например, Azure AD)
⚪️ Создание тестового репозитория: проверка доступных runners в
Settings → CI/CD → Runners⚪️ Запуск тестового job: YAML с командами (id, uname -a, ip a, curl) для разведки (тип
executor: shell — уязвимый, без контейнеризации)⚪️ Reverse shell: замена на
bash-reverse shell на порт 443 (HTTPS-трафик не блокируется)⚪️ Доступ к хосту: выполнение как
gitlab-runner (не sudo, но доступ к файлам других jobs)⚪️ Поиск секретов: просмотр builds других пользователей (например, .env, SSH-ключи)
⚪️ Пивотинг в облако: через AWS metadata (IMDSv2) — получение IAM-роли (
VulnerableSSMRole), перехват токена, аутентификация через awscli⚪️ Компрометация других EC2: через SSM (Systems Manager) — выполнение команд (например, запись файла как root) на всех инстансах с SSM Agent
В конце — рекомендации.
👉 Читать статью
@DevOpsKaz 😛