GitHub под ударом: украдены облачные секреты
Следите за новостями по этой теме!
Подписаться на «Гик Гайд (3 апельсина) / Цифра сегодня»
Киберпреступники использовали несколько функций GitHub, чтобы распространять вредоносные программы для кражи данных и похищать учетные данные для облачных сервисов и другие секреты. Исследователи компании Aikido обнаружили, что злоумышленники задействовали 4 837 скомпрометированных аккаунтов GitHub и отправили запросы на изменение к 61 764 репозиториям. Не менее 1 835 проектов запустили вредоносный код, после чего данные были переданы атакующим.
GitHub — платформа для совместной разработки программ. Каждый проект хранится в репозитории — папке с исходным кодом, настройками и другими файлами. Изменения в открытый проект обычно предлагают через pull request, или запрос на внесение изменений: другие разработчики проверяют его и решают, принять или отклонить.
В GitHub есть и Actions — сервис автоматизации, который может выполнять задачи, в том числе связанные с pull request. Наборы команд для таких задач называются workflows, или рабочими процессами. Если это необходимо для работы, workflow может получать доступ к секретным данным проекта. Именно эта возможность превратила автоматизацию в удобный вход для похитителей учетных данных.
По данным Aikido, массовые запросы сначала служили разведкой: злоумышленники проверяли, в какие проекты аккаунты могли вносить изменения. Исследователи не установили, как именно были украдены или скомпрометированы сами учетные записи. Кампания получила название wfx-loot — по имени вредоносной программы и обозначению похищенных секретов, которое использовали атакующие. Запросы назывались «docs: dependency audit notes» («документация: заметки об аудите зависимостей»), а ветки — wfx-docs.
Из более чем 60 тысяч похожих pull request свыше 10 тысяч были направлены в репозитории, которыми скомпрометированные аккаунты не владели, но могли редактировать. Получив возможность записи, атакующие внедряли вредоносный код одним из трех способов: меняли уже существующие workflows GitHub Actions, добавляли shell-скрипт, запускающийся при установке npm-пакета, или создавали новый файл workflow во временной ветке. npm — популярный менеджер пакетов для JavaScript, а shell-скрипты — команды, выполняемые командной оболочкой.
Во всех вариантах использовалась полезная нагрузка примерно из 1 500 строк кода. Она искала в зараженной среде секреты GitHub Actions, токены аутентификации, учетные данные AWS, Azure и Google Cloud, конфигурации Docker и Kubernetes, SSH-ключи, API-ключи сервисов искусственного интеллекта, включая OpenAI и Anthropic, а также историю команд разработчиков. Кроме того, вредоносная программа проверяла файлы .env, закрытые ключи и учетные данные npm, PyPI, HashiCorp Vault и Terraform.
На краже уже доступных секретов программа не останавливалась. Она пыталась расширить права доступа: обменивала украденные токены на облачные сессии, подделывала сервисные учетные записи и создавала новые учетные данные. Чтобы не потерять доступ после смены скомпрометированных паролей и ключей, вредоносный код также менял настройки AWS и Azure.
Aikido сообщает как минимум о 1 835 репозиториях, где вредоносная нагрузка действительно запустилась и откуда были похищены учетные данные. Затем атакующие отменяли внесенные изменения и удаляли журналы запусков workflow — иногда меньше чем через минуту. Это помогало скрыть следы и затрудняло обнаружение атаки.
Кампания, по-видимому, затронула и цепочку поставок программного обеспечения: Aikido обнаружила скомпрометированные PHP-пакеты на Packagist и две затронутые версии Go-модулей. При этом исследователи допускают, что публикация этих пакетов могла стать побочным результатом злоупотребления автоматизированными процессами, а не заранее намеченной целью.
Aikido рекомендует владельцам репозиториев, где запускался вредоносный код, считать скомпрометированными все секреты и облачные учетные данные, доступные соответствующим workflows, и срочно заменить их. В исходной публикации также отмечалось, что атакующие заявляли о 4 800 уже скомпрометированных аккаунтах; точное число, приведенное исследователями, — 4 837.
Источник: BleepingComputer.
PEREC.RU
Кибератаки на инструменты разработки давно перестали быть историей про загадочного хакера в капюшоне. Теперь достаточно украденного аккаунта, аккуратно названного запроса на изменение и автоматизации, которой доверили ключи от облака. Цифровой взлом стал похож на офисную рутину: доступ уже выдан, процесс настроен, остается лишь надеяться, что никто не догадается использовать инструкцию буквально.
Здесь особенно поучителен контраст между назначением GitHub Actions и результатом. Автоматизация должна избавлять разработчиков от повторяющейся работы, но при небрежном обращении превращается в курьера, который сам собирает секреты, раскладывает их по пакетам и относит неизвестному адресату. Технология не предала людей — она просто исполнила им выданные права доступа. У машин, как выяснилось, нет встроенного чувства неловкости.
Атака показывает, что безопасность проекта — это не только пароль от аккаунта и не только код, который виден в репозитории. Важны также выданные автоматизации полномочия, токены, ключи облачных сервисов и журналы действий. Если один workflow способен получить доступ ко всему сразу, он становится не помощником, а связкой ключей, оставленной на коврике у двери.
Отдельное удовольствие — скорость заметания следов. Изменения отменяют, логи удаляют, а владелец проекта получает шанс обнаружить проблему уже после того, как секреты начали жить собственной бурной жизнью. В такой системе «мы всё автоматизировали» звучит не как достижение, а как просьба к злоумышленнику не забыть нажать кнопку.
Никаких доказательств, что каждый затронутый пакет был целью отдельной операции, исследователи не приводят. Вероятно, часть последствий возникла из-за злоупотребления автоматической публикацией. Но для пострадавших разница между намеренным ударом и побочным эффектом примерно такая же, как между пожаром по плану и пожаром из-за плохо настроенного тостера: помещение всё равно нужно проветривать.
Практический вывод неприятен своей простотой: доступные автоматизации секреты следует считать потенциально раскрытыми, если подозрительный код успел выполниться. Их нужно заменить, а права процессов — пересмотреть и ограничить необходимым минимумом. Это скучная работа, не обещающая эффектного пресс-релиза, зато именно она мешает следующему «случайно аффилированному» скрипту получить ключи от всего хозяйства.
Платформы будут добавлять новые удобные механизмы, компании — подключать их ради скорости, а кто-то обязательно решит, что секреты можно раздать широкому кругу процессов и потом просто удалить журнал. Так устроен прогресс: сначала мы автоматизируем рутину, затем автоматизируем масштаб последствий. И только после инцидента выясняем, что кнопка «отменить изменения» не умеет возвращать украденные облачные учетные данные.
