Ввели код с бумажки? Теперь у хакера полный доступ к вашим репозиториям

В последнее время киберпреступники всё чаще выбирают в качестве вектора атаки не вредоносное ПО, а тонкую манипуляцию в духе социальной инженерии. Теперь под прицелом — сами разработчики. Специалисты компании Praetorian зафиксировали новую волну атак, в которой злоумышленники эксплуатируют законный механизм авторизации GitHub — OAuth 2.0 Device Code Flow. Хотя этот способ авторизации был создан для удобства входа на устройствах с ограниченными возможностями ввода, именно он стал удобной лазейкой для похищения токенов доступа.

Суть атаки заключается в том, что преступники получают временный код устройства через GitHub API и передают его разработчику, притворяясь службой поддержки или внутренним администратором. Как только ничего не подозревающий сотрудник вводит код по указанной ссылке — всё, игра сделана: злоумышленник получает полноценный OAuth-токен и доступ к приватным репозиториям, CI/CD-среде и конфиденциальным секретам компании.

Такой подход особенно опасен, поскольку основан на доверии и правдоподобности. GitHub не проверяет, совпадают ли инициатор генерации кода и пользователь, который его подтверждает. А значит, кто угодно может инициировать процесс, а обманутый пользователь — непреднамеренно его одобрить.

Сценарий атаки выглядит следующим образом:

1. Преступник инициирует запрос кода устройства с нужными правами — например, доступом к пользователю, репозиториям и workflow.
2. Отправляет код и ссылку сотруднику компании через e-mail, телефон или SMS, представляясь техподдержкой.
3. Жертва вводит код на странице авторизации GitHub, тем самым давая злоумышленнику «зелёный свет».
4. Атакующий получает полноценный токен с расширенными правами.
5. С помощью него можно выкачивать исходный код, внедрять вредоносные изменения, получать доступ к секретам и запускать атаки на поставщиков ПО.

Один из инцидентов показал, как злоумышленники получили внутренний доступ в компанию и автоматически создавали коды устройства, подставляя их в ложные обращения через звонки. В другом случае использовался автоматизированный инструмент под названием «GitPhish» — он сам создавал валидные коды через фальшивую страницу GitHub Pages, подсовывая пользователю реалистичный интерфейс и живой код авторизации.

Ситуацию осложняет то, что отключить этот механизм авторизации в GitHub нельзя. Поэтому всё внимание — на защитные меры. Специалисты советуют внедрить следующие подходы:

• Анализ журналов событий: отслеживать события org_credential_authorization.grant и внимательно изучать их частоту и права, особенно если это повторяется у разных пользователей.
• Мониторинг сетевого трафика: зафиксировать аномальные всплески посещений страницы github.com/login/device, которые могут указывать на активную фишинговую кампанию.
• Ограничение доступа по IP: допускается настройка allow-listing на корпоративном уровне, но нужно учитывать возможные сбои в CI/CD.
• Анализ поведения после авторизации: например, резкое увеличение количества операций клонирования репозиториев, обращения к конфиденциальным данным, сканирование секретов и прочие нетипичные действия после выдачи нового токена.

Учитывая рост числа подобных атак, важно подготовить оперативные планы реагирования и повысить осведомлённость среди сотрудников. Ведь в условиях современной цифровой среды основная угроза может скрываться не снаружи, а внутри собственного GitHub-аккаунта.