Ввели код с бумажки? Теперь у хакера полный доступ к вашим репозиториям
NewsMakerПреступникам даже не нужно ничего взламывать. Вы и так отдадите всё добровольно.
В последнее время киберпреступники всё чаще выбирают в качестве вектора атаки не вредоносное ПО, а тонкую манипуляцию в духе социальной инженерии. Теперь под прицелом — сами разработчики. Специалисты компании Praetorian зафиксировали новую волну атак, в которой злоумышленники эксплуатируют законный механизм авторизации GitHub — OAuth 2.0 Device Code Flow. Хотя этот способ авторизации был создан для удобства входа на устройствах с ограниченными возможностями ввода, именно он стал удобной лазейкой для похищения токенов доступа.
Суть атаки заключается в том, что преступники получают временный код устройства через GitHub API и передают его разработчику, притворяясь службой поддержки или внутренним администратором. Как только ничего не подозревающий сотрудник вводит код по указанной ссылке — всё, игра сделана: злоумышленник получает полноценный OAuth-токен и доступ к приватным репозиториям, CI/CD-среде и конфиденциальным секретам компании.
Такой подход особенно опасен, поскольку основан на доверии и правдоподобности. GitHub не проверяет, совпадают ли инициатор генерации кода и пользователь, который его подтверждает. А значит, кто угодно может инициировать процесс, а обманутый пользователь — непреднамеренно его одобрить.
Сценарий атаки выглядит следующим образом:
Ситуацию осложняет то, что отключить этот механизм авторизации в GitHub нельзя. Поэтому всё внимание — на защитные меры. Специалисты советуют внедрить следующие подходы:
В последнее время киберпреступники всё чаще выбирают в качестве вектора атаки не вредоносное ПО, а тонкую манипуляцию в духе социальной инженерии. Теперь под прицелом — сами разработчики. Специалисты компании Praetorian зафиксировали новую волну атак, в которой злоумышленники эксплуатируют законный механизм авторизации GitHub — OAuth 2.0 Device Code Flow. Хотя этот способ авторизации был создан для удобства входа на устройствах с ограниченными возможностями ввода, именно он стал удобной лазейкой для похищения токенов доступа.
Суть атаки заключается в том, что преступники получают временный код устройства через GitHub API и передают его разработчику, притворяясь службой поддержки или внутренним администратором. Как только ничего не подозревающий сотрудник вводит код по указанной ссылке — всё, игра сделана: злоумышленник получает полноценный OAuth-токен и доступ к приватным репозиториям, CI/CD-среде и конфиденциальным секретам компании.
Такой подход особенно опасен, поскольку основан на доверии и правдоподобности. GitHub не проверяет, совпадают ли инициатор генерации кода и пользователь, который его подтверждает. А значит, кто угодно может инициировать процесс, а обманутый пользователь — непреднамеренно его одобрить.
Сценарий атаки выглядит следующим образом:
- Преступник инициирует запрос кода устройства с нужными правами — например, доступом к пользователю, репозиториям и workflow.
- Отправляет код и ссылку сотруднику компании через e-mail, телефон или SMS, представляясь техподдержкой.
- Жертва вводит код на странице авторизации GitHub, тем самым давая злоумышленнику «зелёный свет».
- Атакующий получает полноценный токен с расширенными правами.
- С помощью него можно выкачивать исходный код, внедрять вредоносные изменения, получать доступ к секретам и запускать атаки на поставщиков ПО.
Ситуацию осложняет то, что отключить этот механизм авторизации в GitHub нельзя. Поэтому всё внимание — на защитные меры. Специалисты советуют внедрить следующие подходы:
- Анализ журналов событий: отслеживать события org_credential_authorization.grant и внимательно изучать их частоту и права, особенно если это повторяется у разных пользователей.
- Мониторинг сетевого трафика: зафиксировать аномальные всплески посещений страницы github.com/login/device, которые могут указывать на активную фишинговую кампанию.
- Ограничение доступа по IP: допускается настройка allow-listing на корпоративном уровне, но нужно учитывать возможные сбои в CI/CD.
- Анализ поведения после авторизации: например, резкое увеличение количества операций клонирования репозиториев, обращения к конфиденциальным данным, сканирование секретов и прочие нетипичные действия после выдачи нового токена.