Обеспокоенный всплеском кибератак, вышедших из-под контроля в средах разработки, GitHub усилил безопасность actions/checkout для блокировки атак типа «pwn request», которые используют небезопасное применение триггера рабочего процесса pull_request_target для выполнения кода злоумышленника с полными привилегиями рабочего процесса.
Обновление actions/checkout v7, анонсированное 18 июня, теперь автоматически блокирует и прерывает выполнение рабочих процессов при использовании в рамках событий pull_request_target или workflow_run, когда происходит попытка получить код из непроверенного форка pull request.
Отныне единственным способом обойти эти проверки будет явное отключение этой функции разработчиками путем добавления параметра allow-unsafe-pr-checkout в actions/checkout, как сообщил GitHub в журнале изменений V7.
Это изменение знаменует начало новой эры «безопасности по умолчанию», когда безопасность будет определяться системой GitHub, а не оставаться на усмотрение разработчиков. В рамках этих усилий 16 июля новые настройки по умолчанию будут перенесены во все поддерживаемые основные версии.
«Рабочие процессы, закрепленные за плавающим основным тегом (например, actions/checkout@v4), автоматически получат это изменение. На рабочие процессы, закрепленные за определенным SHA, минорным или патч-версией, откат не повлияет, и им потребуется обновление с использованием Dependabot или через установленные процессы обновления», — пояснили в GitHub.
Однако, поскольку атаки типа pwn request могут происходить и другими способами, в журнале изменений добавлено, что «в будущих выпусках может быть рассмотрено дальнейшее укрепление дополнительных событий».
Слепое пятно
Если и можно предъявить критику GitHub по этому поводу, так это то, что потребовалось так много времени, чтобы устранить слабость, известную уже много лет.
Проблема заключается в GitHub Actions, который позволяет триггерам запускать рабочие процессы, включая pull_request, обрабатывающий сторонние форки без предоставления доступа к секретам, таким как ключи API, служебные токены и учетные данные. Недостаток в том, что это ограничение мешает работе некоторой автоматизации, поэтому разработчики обращаются к альтернативному триггеру — pull_request_target, который предоставляет необходимый доступ.
В какой-то момент злоумышленники поняли, что если pull_request_target был небрежно настроен с использованием actions/checkout для извлечения недоверенного кода из форка, это открывало лазейку в репозитории и их секреты.
Иными словами, слабость pull_request_target заключается не в самом триггере, который является законным и безопасным при правильном использовании, а в его некорректном использовании. Как говорится в журнале изменений GitHub: «Извлечение заголовка непроверенного pull request из форка внутри одного из таких рабочих процессов обычно позволяет выполнить код, контролируемый злоумышленником, с полными привилегиями рабочего процесса».
Однако появление actions/checkout v7 должно усложнить это, автоматически блокируя рискованные рабочие процессы независимо от их конфигурации.
К сожалению, уже нанесен значительный ущерб. Репозитории с открытым исходным кодом недавно подверглись целенаправленным атакам хакерской группы TeamPCP с использованием различных методов, включая pwn requests.
Примечательным примером стала атака в прошлом месяце, в результате которой было скомпрометировано 170 пакетов npm (node package manager), включая экосистему TanStack Router, благодаря эксплойту pwn request. Достойно сожаления, что в отдельном инциденте, не связанном с pwn request, сама GitHub подверглась взлому, и злоумышленники вывели исходный код примерно из 3800 внутренних репозиториев компании.
Лучше поздно, чем никогда: GitHub принял меры, планируя серию реформ безопасности на платформе, включая, ранее в этом месяце, ограничение автоматического выполнения установочных скриптов в npm.
Эта статья изначально была опубликована на InfoWorld.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – John E. Dunn
