Возможность для злоумышленников использовать автоматическое выполнение установочных скриптов в npm окончательно прекратится с ожидаемыми изменениями от GitHub в июле. Разработчики по-прежнему смогут активировать эту функцию, но по умолчанию она будет заблокирована.
В версии V12 меняются настройки по умолчанию, как сообщил GitHub в своем журнале изменений, отметив: «это превращает поведение npm install, которое сегодня выполняется автоматически, в то, которое вы явно разрешаете».
В частности, в публикации говорится: «allowScripts по умолчанию отключено: npm install больше не будет выполнять скрипты preinstall, install или postinstall из зависимостей, если они явно не разрешены в вашем проекте. Это включает нативные сборки node-gyp; пакет с binding.gyp и без явного скрипта установки по-прежнему блокируется, поскольку npm неявно выполняет пересборку node-gyp для него. Скрипты prepare для зависимостей из git, file и link блокируются таким же образом».
Аналитики, консультанты и пользователи в целом одобрили это изменение, но заявили, что оно лишь сузит подверженность атакам на цепочки поставок, а не устранит их.
Атаки, вероятно, переместятся в другие места
Сону Капур, сопровождающий CVE Lite CLI в проекте OWASP Incubator, заявил, что это изменение, вероятно, вынудит атаки на цепочки поставок, использующие автоматическое выполнение, переместиться в другие места.
«Это не устраняет риск атак на цепочки поставок npm, это убирает основной путь автоматического выполнения», — сказал Капур. «Злоумышленники все еще могут перейти к другим путям: вредоносный код пакета, который выполняется во время выполнения приложения, скомпрометированные учетные записи сопровождающих, путаница с зависимостями (dependency confusion), опечатки в именах (typo-squatting), отравленные рабочие процессы GitHub Actions, вредоносные транзитивные зависимости или украденные токены публикации. Это закрывает одну очень опасную дверь, но не защищает весь дом».
Тем не менее, атаки, использующие эту настройку, регулярно применялись в атаках на цепочки поставок.
Однако Алан Паркинсон, директор фирмы Threat Detective, занимающейся безопасными медицинскими устройствами, отметил, что более изощренные злоумышленники уже обошли эту уязвимость.
«Вектор атаки через установочные скрипты известен годами», — сказал Паркинсон. «Большинство групп безопасности пометили его как низкий риск и перешли к угрозам с более высоким риском. То, что повысило его значимость, — это не изменение технической возможности эксплуатации, а череда громких жертв и открытое стремление некоторых злоумышленников к известности».
Он добавил: «Скрипты pre и post install изначально не были хитрым вектором атаки. Запуск кода из хука установки — это грубо и шумно, поэтому это вызвало такой заметный ущерб. Более способные акторы уже переходят к другим методам, так что v12 в основном закрывает дверь для менее изощренных злоумышленников».
Хотя GitHub отказался от интервью, Зак Штайндлер, ведущий инженер GitHub, ответил на вопросы по электронной почте. Он заявил, что объем и темпы атак на цепочки поставок вынудили изменить настройки по умолчанию.
«Мы видели, как злоумышленники нацеливались на эти возможности для быстрой пропаганды атак от одного скомпрометированного пакета ко многим. Годы исследований в области безопасности и удобства использования показали, что недостаточно сделать безопасную функциональность доступной; безопасный путь должен быть путем по умолчанию, чтобы он получил широкое распространение», — сказал Штайндлер.
Он добавил: «Мы считаем, что эти изменения — отличный способ обеспечить высокие стандарты безопасности по умолчанию, при этом предоставляя некоторым пользователям возможность вернуться к функциональности, которая может им понадобиться в определенных обстоятельствах».
Изменение давно назрело
Санчит Вир Гогиа, главный аналитик Greyhound Research, заявил, что GitHub был последним из репозиториев, кто внес это изменение настроек по умолчанию. «Конкуренты пошли первыми: Yarn, pnpm и Bun по умолчанию блокируют сторонние установочные скрипты по-своему», — сказал Гогиа. «Npm не изобретает новую доктрину. Он наконец-то принимает ее».
Штайндлер не стал оспаривать комментарий Гогиа.
«Непросто быть хранителями крупнейшего репозитория пакетов в мире. Общественный консенсус относительно того, какие функции безопасности должны быть стандартными и когда допустимо вносить ломающие изменения, со временем меняется. Судя по нашим постоянным беседам с сообществом, было ясно, что пришло время внести это изменение», — сказал Штайндлер.
«Недавние атаки вызывают тревогу», — отметил он, — «но управление этими репозиториями пакетов — это многодесятилетнее усилие, а не просто момент времени. По мере развития атак будут развиваться и наши оборонительные возможности безопасности. Мы в этом надолго».
Гогиа сказал, что это изменение, хотя и запоздалое, является хорошим.
«Npm убирает одно из самых удобных мест для сокрытия рисков в цепочке поставок программного обеспечения: код, который выполняется в тот момент, когда разработчик вводит install», — сказал Гогиа. «С npm v12 выполнение становится чем-то, что должно быть одобрено, зафиксировано в проекте и передано на рассмотрение. Это не корректировка дизайна. Это изменение философии контроля».
Плохие настройки по умолчанию становятся инфраструктурой
У Гогиа был свой взгляд на то, почему GitHub так долго ждал.
«Npm ждал, потому что его рискованная настройка по умолчанию приобрела свою клиентуру. Еще в 2016 году позиция самого npm заключалась в том, что удобство установочных скриптов перевешивает риск червя, при этом для осторожных предусмотрен флаг отказа от этой функции (opt-out). Этот компромисс был задокументированным продуктовым решением, а не упущением», — сказал он.
«Проблема с плохими настройками по умолчанию в том, что они становятся инфраструктурой», — добавил он. «Нативные сборки модулей, установщики браузеров, такие как Playwright и Cypress, потоки загрузки Electron и хуки Husky — все это развивалось вокруг автоматического выполнения. Отключение этого стало не столько технической корректировкой, сколько конституционной реформой».
Ответственность сменила владельца
Настоящее давление для внесения изменений, однако, исходило от регуляторов.
«Более глубокий ответ заключается в том, что ответственность сменила владельца. Как только такое регулирование, как EU Cyber Resilience Act и правила раскрытия информации для ценных бумаг, возложили сбои в цепочке поставок на корпоративные балансы, задокументированная небезопасная настройка по умолчанию стала неоправданной», — сказал Гогиа.
Капур согласился с тем, что давно устоявшиеся процедуры позволили этой уязвимости безопасности просуществовать дольше, чем следовало.
«Причина, по которой это, вероятно, не было сделано раньше, — совместимость», — сказал он. «Установочные скрипты используются не только злоумышленниками. Многие легитимные пакеты используют их для компиляции нативных модулей, загрузки бинарных файлов для конкретных платформ, генерации файлов или выполнения шагов настройки. Изменение настройки по умолчанию нарушает предположения, которые существовали в экосистеме npm годами. Вот почему эти изменения в области безопасности часто приходят медленно. Более безопасная настройка по умолчанию очевидна с точки зрения безопасности, но болезненна с точки зрения совместимости экосистемы».
Кроме того, он отметил: «Более важный момент заключается в том, что менеджеры пакетов переходят от неявного доверия к явному доверию. Это правильное направление. Разработчики должны одобрять, каким зависимостям разрешено выполнять код во время установки. Но одобрение не должно стать слепой галочкой. Команды должны иметь представление о том, какой пакет хочет запустить скрипт, является ли он прямым или транзитивным, почему он там находится и принадлежит ли он проекту вообще».
Капур добавил, что это изменение имеет значение, поскольку выполнение во время установки часто происходит в привилегированных средах с доступом к токенам, секретам, внутренним реестрам, артефактам сборки или путям развертывания. «Даже если скрипт напрямую не скомпрометирует продакшн, он может украсть достаточно контекста для поддержки следующего этапа атаки», — сказал он.
Ценность в боли
Консультант по кибербезопасности Брайан Левин, исполнительный директор FormerGov, согласился с тем, что закрытие этой уязвимости — очень хорошее дело.
«Кажется, что практически каждая крупная атака на цепочку поставок за последнее десятилетие имела один и тот же первородный грех: код, который выполнялся автоматически, потому что экосистема это позволяла. Npm наконец закрывает эту дверь по умолчанию — это давно назрело, но это действительно значимо. Это менеджер пакетов для сотен миллиардов загрузок в месяц», — сказал Левин.
«Когда npm меняет свои настройки по умолчанию, он меняет положение дел в области безопасности практически в каждой корпоративной среде разработки на планете. Возможно, это был последний крупный репозиторий кода, который все еще допускал такого рода автоматическое выполнение».
Левин добавил, что это изменение может не просто устранить уязвимость, но и новый процесс может существенно улучшить безопасность.
«На самом деле в этой боли миграции есть что-то ценное. Требование от разработчиков явно одобрять, каким пакетам разрешено запускать код, и фиксировать этот список в системе контроля версий — это форма управления цепочками поставок программного обеспечения, которой многие организации никогда не имели», — сказал Левин. «Это создает аудируемую запись, что имеет значение, особенно для регулируемых отраслей».
Эта статья изначально была опубликована на InfoWorld.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Evan Schuman
