00:00:00Это серьезно, без шуток. Последние несколько часов выдались тяжелыми, потому что
00:00:06произошла масштабная атака на цепочку поставок Axios. Да, того самого Axios, у которого более 80 миллионов
00:00:14скачиваний в неделю.
00:00:15Итак, первым делом.
00:00:18Чтобы вы могли проверить, затронуло ли это вас, я прикрепил ссылку на статью,
00:00:23и через секунду поделюсь подробностями. Но это важно: чтобы проверить,
00:00:27пострадали ли вы, перейдите по ссылке ниже и выполните команды, которые там указаны
00:00:32для вашей операционной системы: macOS, Linux, Windows — затронуты все.
00:00:37Вам нужно запустить эти команды, если вы под угрозой.
00:00:40И особенно если эти шаги покажут, что ваша система была взломана, вам
00:00:49нужно будет обновить секреты, сменить пароли, считать все учетные данные и API-ключи
00:00:55в вашей системе украденными. Все, что было на диске.
00:01:00Считайте пароли украденными, меняйте все, отзывайте API-ключи, это действительно важно.
00:01:07Теперь, что именно произошло?
00:01:09Axios — это, очевидно, очень популярная JavaScript-библиотека, которая используется для отправки HTTP-запросов,
00:01:17например, из React-приложения в API бэкенда.
00:01:22Как видите, она используется повсеместно, и в эту библиотеку
00:01:28был внедрен вредоносный код.
00:01:29Это не значит, что пострадали сайты, использующие эту библиотеку.
00:01:36Это значит, что скомпрометированы системы, на которых вы устанавливали эту библиотеку: ваш MacBook,
00:01:41ПК или, возможно, тот VPS, на котором вы собирали свой сайт.
00:01:50Если вы запускали npm install, bun install, npm update, bun update или что-то подобное в последние
00:01:57пару часов, есть высокая вероятность, что вы пострадали.
00:02:00Повторюсь, я поделился проверками, которые стоит выполнить, чтобы узнать свой статус.
00:02:05Как именно это произошло и что вообще такое атака на цепочку поставок?
00:02:10Кстати, я также расскажу, как защитить себя от подобных атак в будущем.
00:02:15Но сначала давайте разберемся, что именно происходит при атаке на цепочку поставок.
00:02:20Атака на цепочку поставок — это атака, целью которой является не код вашего приложения.
00:02:24Злоумышленник не пытается напрямую проникнуть в вашу систему или вашу кодовую базу.
00:02:31Вместо этого они используют тот факт, что код вашего приложения обычно имеет зависимости, которые сами
00:02:37имеют свои зависимости.
00:02:38Так образуется цепочка зависимостей, и атака направлена именно на эту цепочку.
00:02:45То есть это происходит «выше по течению» от вашего кода.
00:02:48В одну из этих зависимостей внедряется вредоносный код, и вовсе не потому,
00:02:54что разработчик библиотеки сам пытается вас атаковать.
00:02:58Вместо этого, как в данном случае, взламывается аккаунт одного из мейнтейнеров,
00:03:03и хакер использует его для внедрения вредоносного кода в какую-то библиотеку или пакет,
00:03:10который может использовать другой пакет, а ваш код затем использует этот пакет,
00:03:16содержащий вредоносную часть. Или ваше приложение напрямую подтягивает опасную зависимость.
00:03:23В любом случае, одна из ваших зависимостей внезапно оказывается с «сюрпризом».
00:03:28И в тот момент, когда вы запускаете npm install или обновление, этот пакет
00:03:36скачивается в вашу систему — тот самый зараженный пакет — и затем запускает
00:03:41вредоносный код, обычно с помощью скриптов post-install.
00:03:47Если вы не знали, в npm есть механизм скриптов.
00:03:56Мы все используем их в проектах, например, для запуска сервера разработки, сборки проекта,
00:04:01прогона тестов и тому подобного.
00:04:04И существуют специфические скрипты post-install, которые вы можете не использовать,
00:04:11когда пишете, скажем, React-приложение, но которые библиотеки часто — или нечасто —
00:04:17могут применять для запуска кода в вашей системе сразу после установки. Обычно
00:04:23не для чего-то плохого, а, например, для компиляции кода, создания бинарного файла,
00:04:31необходимого библиотеке, или подготовки системы любым способом,
00:04:36чтобы вы могли использовать только что скачанную библиотеку.
00:04:40Такова идея скрипта post-install.
00:04:42Он позволяет пакету определить код, который должен быть выполнен после установки
00:04:49через npm install, и именно это обычно эксплуатируется в таких
00:04:55атаках на цепочку поставок.
00:04:57Хакер внедряет вредоносный код в пакет в виде скрипта post-install,
00:05:04который выполняется автоматически после установки зараженного пакета.
00:05:10Обычно этот код обфусцирован, чтобы его было трудно прочитать.
00:05:14Он может быть зашифрован в base64, чтобы сканеры вредоносного кода
00:05:20могли его не заметить, или же вредоносный код может скачиваться извне.
00:05:24Так, в случае с атакой на Axios, скрипт post-install на самом деле
00:05:30не содержал вредоносный код напрямую.
00:05:32Вместо этого он связывался с сервером и скачивал код оттуда.
00:05:36Вот что здесь произошло.
00:05:37У нас есть подробный отчет о том, что именно случилось во время этой атаки.
00:05:41Вы найдете его в приложении, если захотите изучить детали, но из него мы
00:05:45узнаем, что пострадали две версии пакета Axios: 1.14.1 и 0.30.4. Они были взломаны,
00:05:57и это было сделано путем получения доступа к аккаунту одного из
00:06:02мейнтейнеров Axios. Через этот аккаунт была опубликована новая версия пакета,
00:06:08которая содержала зависимость, а та, в свою очередь, содержала скрипт post-install.
00:06:14То есть даже не сам пакет Axios содержал этот скрипт,
00:06:19а другой пакет — plaincryptojs, который был создан злоумышленником.
00:06:25Единственная цель этого пакета — иметь post-install скрипт, который скачивает и запускает
00:06:31вредоносный код.
00:06:32Таким образом, Axios был скомпрометирован путем добавления plaincryptojs в список его зависимостей.
00:06:39Это вредоносный пакет.
00:06:40Он не служит никакой другой цели, кроме скачивания вредоноса, и простого
00:06:46добавления этой зависимости в Axios было достаточно, чтобы завершить атаку.
00:06:52Этот пакет нигде не импортируется в самом исходном коде Axios.
00:06:56В нем есть только этот скрипт post-install, и всё.
00:06:59Как уже упоминалось, он способен скачивать и запускать код в macOS, Windows и Linux,
00:07:05чтобы делать что?
00:07:06Ну, красть кучу всего.
00:07:08Если ваша система затронута, то, как я говорил вначале, учетные данные, API-ключи, крипто-токены —
00:07:14весь этот «джентльменский набор» собирается и отправляется трояном, который скачивается тем самым
00:07:21скриптом post-install.
00:07:22Вот как работала эта атака.
00:07:24Похожим образом работали и подобные атаки в прошлом.
00:07:29Что еще интересно... да, кстати, эта атака началась около полуночи,
00:07:36аккурат после полуночи по UTC сегодня, несколько часов назад.
00:07:40Она длилась пару часов, и обе версии Axios, 1.14.1 и 0.30.4, были заражены
00:07:50в течение 40 минут — если быть точным, 39 минут.
00:07:53Так что это была очень хорошо организованная, спланированная атака.
00:07:56Очевидно, что создание этого дополнительного пакета произошло, кажется, за 18 часов до того,
00:08:03как началась сама атака.
00:08:04Все было очень четко спланировано.
00:08:06Странно здесь то, что у NPM есть механизм под названием «Trusted Publishing» (доверенная публикация),
00:08:14который могут использовать мейнтейнеры пакетов.
00:08:17Идея в том, что это ограничивает процесс публикации новых версий пакета
00:08:26строго определенным процессом, где вы должны собирать и публиковать новую версию
00:08:32через одного из поддерживаемых CI/CD провайдеров с определенной настройкой.
00:08:38И по задумке, даже если учетные данные вашего NPM-аккаунта будут украдены,
00:08:46в теории злоумышленник не сможет опубликовать новую версию пакета со своего компьютера,
00:08:51потому что нужно пройти через этот автоматизированный процесс.
00:08:52Конечно, можно возразить: если взломан GitHub-аккаунт мейнтейнера, то
00:08:59вредоносная версия может быть отправлена в GitHub, что запустит процесс деплоя,
00:09:06и вредоносный код опубликуется через этот самый механизм Trusted Publishing.
00:09:11Но согласно отчету по безопасности, в данном случае произошло не это.
00:09:16Потому что команда Axios использует доверенную публикацию для ветки 1.x —
00:09:21не для ветки 0.30, а именно для 1.x.
00:09:26Но в отчете сказано, что в GitHub-репозитории Axios нет никаких подозрительных коммитов или следов атаки.
00:09:33То есть не было пуша в GitHub с этой скомпрометированной версией Axios.
00:09:40Значит, процесс доверенной публикации не должен был запуститься.
00:09:44Вместо этого в отчете утверждается, что злоумышленник, должно быть, раздобыл старый
00:09:50долгоживущий классический токен доступа NPM для публикации этой вредоносной версии,
00:09:56потому что релиз существовал только в NPM, а не на GitHub.
00:10:01Возможно, это ошибка.
00:10:02Может быть, атака все же прошла через GitHub.
00:10:05Но если отчет верен, то мне не совсем понятно, как это сработало, ведь теоретически
00:10:11такой способ публикации должен быть невозможен при включенном Trusted Publishing.
00:10:15Не уверен, то ли это уязвимость в безопасности, то ли какая-то проблема со стороны NPM.
00:10:20Что какие-то существующие долгоживущие токены все еще можно использовать даже
00:10:26с включенным механизмом доверенной публикации.
00:10:27Это тот момент, в котором я не смог до конца разобраться.
00:10:32И есть ветка обсуждения, GitHub issue в репозитории Axios, где сообщили об этой атаке.
00:10:40Кстати, заметка на полях: подобных issue было создано больше, но они удалялись
00:10:45взломанным мейнтейнером, вернее, через его скомпрометированный аккаунт.
00:10:48Эта ветка выжила, и в итоге атаку удалось остановить.
00:10:52Мейнтейнеры восстановили доступ к пострадавшему аккаунту.
00:10:56И в этом обсуждении мейнтейнер пишет, что они используют доверенную
00:11:03публикацию, и непонятно, как именно это произошло.
00:11:07Там была озвучена одна теория.
00:11:09Но, насколько я понимаю, эта теория все равно требовала бы пуша
00:11:16новой вредоносной версии в GitHub, но опять же, ясности нет.
00:11:20Ясно одно: скомпрометированные версии были опубликованы, попали в NPM и,
00:11:25следовательно, скачивались в системы, где воровали данные.
00:11:29И конечно, при 80 миллионах скачиваний в неделю, за несколько часов можно нанести
00:11:35огромный ущерб.
00:11:37Очевидно, что скачивания распределены по суткам неравномерно, но это
00:11:44определенно огромное число, и можно предположить, что тысячи, если не десятки тысяч систем
00:11:51были заражены за эти несколько часов.
00:11:55Конечно, это была не первая атака на цепочку поставок.
00:11:59За последние месяцы мы видели несколько подобных случаев.
00:12:01Одна крупная атака в конце прошлого года — атака «shy hulu», когда множество пакетов
00:12:08в NPM были подменены, и там была похожая схема: внедрение вредоносного кода,
00:12:16выполнение в системах, скачавших зараженные пакеты, и последующая кража
00:12:21учетных данных и прочего.
00:12:22Так что это был один крупный инцидент.
00:12:25А всего несколько дней назад произошел аналогичный инцидент в экосистеме Python.
00:12:31Так что это не ограничивается только JavaScript: пострадал пакет lightllm.
00:12:37Очень популярный пакет, который упрощает работу с AI-провайдерами через
00:12:43один удобный интерфейс. Он тоже подвергся похожей атаке и пострадал.
00:12:49И поэтому, конечно, дело не только в JavaScript.
00:12:52Я думаю, есть пара причин, почему мы видим все больше таких атак.
00:12:57В теории подобные атаки могли случаться и, вероятно, случались
00:13:03в прошлом, но сейчас они явно становятся более частыми, и на то есть
00:13:08несколько причин.
00:13:11Одна из главных причин заключается в том, что сейчас пишется и генерируется
00:13:17больше кода, чем когда-либо прежде.
00:13:19Можно посмотреть на разные метрики.
00:13:22Например, недавно я видел график, показывающий, что количество новых репозиториев на GitHub
00:13:27находится на рекордно высоком уровне, и, конечно, это благодаря ИИ.
00:13:31Люди работают над проектами, генерируют код.
00:13:35Объем выдаваемого кода сейчас больше, чем когда-либо, и это означает, что при таком
00:13:42количестве программ и генерируемого кода поверхность атаки становится намного больше.
00:13:47Появляется больше целей.
00:13:48Становится больше людей, которые пишут код и устанавливают пакеты.
00:13:52Так что это привлекательнее, чем когда-либо.
00:13:54Не то чтобы в прошлом это было неинтересно, но сейчас количество потенциальных жертв,
00:13:59которых можно атаковать, выросло многократно.
00:14:00Это, безусловно, одна из веских причин.
00:14:03Проводить такие атаки стало просто выгоднее, но это не всё.
00:14:07Я думаю, еще одна причина также связана с ИИ: с одной стороны,
00:14:15проведение подобных атак с помощью ИИ, вероятно, стало проще, потому что
00:14:21вредоносный код, конечно, тоже можно генерировать и писать с помощью ИИ. Так что
00:14:28технические навыки, необходимые для таких атак, стали доступнее, чем раньше.
00:14:33Хотя скрипты или трояны можно было купить и в даркнете, сейчас это стало еще доступнее.
00:14:40У ИИ есть не только хорошая сторона — что больше людей могут создавать софт и превращать
00:14:46свои идеи в бизнес, — но и плохая.
00:14:50Больше людей могут творить плохие вещи с кодом благодаря ИИ, так что это одна из причин.
00:14:55Можно также поспорить, что мейнтейнеры пакетов и библиотек буквально завалены
00:15:01пулл-реквестами.
00:15:02Это еще одна большая проблема наших дней: если вы мейнтейнер опенсорс-проекта,
00:15:07вам поступает больше PR, чем когда-либо, поэтому вы можете быть не слишком внимательны
00:15:13к тому, что именно вы вливаете в проект.
00:15:14Просто уточню: в случае с Axios проблема была не в этом.
00:15:16В этой атаке явно был взломан аккаунт, но теоретически
00:15:22можно допустить, что мейнтейнеры могут принять вредоносный код или код,
00:15:29который устанавливает опасные зависимости, просто потому что они это просмотрели или
00:15:34потому что у них полностью автоматизированный процесс ревью, который этого не ловит.
00:15:38Они просто полагаются на ИИ.
00:15:40Опять же, здесь это не так, но можно представить, что в будущем хакеры будут
00:15:45внедрять вредоносный код в кодовые базы, потому что люди просто не смотрят.
00:15:51Вдобавок, когда вы используете инструменты вроде Claude Code или OpenClaude в системе для выполнения
00:15:56всевозможных задач — не только для помощи в разработке, но и для управления системой
00:16:01в целом, — конечно, для определенных задач эти инструменты могут решить
00:16:09написать какой-то скрипт и запустить код, чтобы выполнить ваш запрос, и этот
00:16:15сгенерированный код также может полагаться на зависимости вроде Axios.
00:16:20Так что поверхность атаки расширяется — это мой первый аргумент,
00:16:24но уже за пределами классической разработки. По всем этим причинам — и многим другим,
00:16:30о которых я здесь не подумал, — такие атаки становятся выгоднее, их легче проводить и
00:16:37они становятся интереснее для хакеров. Поэтому я уверен, что в будущем мы увидим их еще больше.
00:16:43Теперь, что вы можете сделать, чтобы предотвратить такие атаки и защитить себя?
00:16:47Один из важных шагов по усилению безопасности, который вы можете предпринять во всех своих проектах,
00:16:55когда вы работаете над приложениями и так далее, — это использование инструментов вроде pnpm вместо npm для
00:17:02управления зависимостями. Вы можете добавить настройку минимального возраста релиза в файл pnpm-workspace.yaml.
00:17:09В bun есть похожая функция: вы можете добавить файл bunfig.toml, если используете bun как пакетный менеджер,
00:17:15и там тоже есть настройка минимального возраста релиза. Что это дает?
00:17:21Это гарантирует, что при установке любого пакета будут устанавливаться только те версии,
00:17:27которые были выпущены не менее определенного времени назад.
00:17:34Так что если пакет был взломан пять часов назад, но у вас есть правило устанавливать только версии,
00:17:39которым как минимум три дня, вы должны быть в безопасности. Такова идея. К сожалению, в самом npm
00:17:46такой функции нет. Чтобы быть уверенным, что все понятно: мы все еще говорим о пакетах,
00:17:51которые хостятся на npm, это не проблема. Я говорю о самом инструменте управления пакетами,
00:17:56и вы, конечно, можете использовать bun или pnpm для скачивания этих пакетов из npm. И если вы
00:18:03используете их вместо стандартного npm, то сможете воспользоваться подобными настройками,
00:18:08которые просто дают вам дополнительный слой безопасности. Обычно в прошлом такие атаки
00:18:14обнаруживались в течение нескольких часов, поэтому если у вас установлен порог, скажем, в три дня,
00:18:20то большинство подобных атак к тому моменту уже будут обнаружены и прекращены. Это не дает 100%
00:18:25защиты, ведь атака может длиться и дольше, но это дает явное преимущество, и это
00:18:32определенно стоит сделать. Чтобы быть еще более защищенным, вам стоит рассмотреть
00:18:39решения вроде Doppler. Это не реклама, просто один из примеров, есть альтернативы.
00:18:44Я даже создал свою альтернативу, которой пользуюсь сам. Это сервисы или инструменты, которые
00:18:49управляют вашими секретами. Например, ваш API-ключ OpenAI: вы могли бы положить его в файл .env,
00:18:55но лучше хранить его в зашифрованном виде в сервисе вроде Doppler или с его помощью —
00:19:02на их серверах или на собственном VPS — и затем внедрять его в окружение вашего
00:19:08приложения только тогда, когда это необходимо. Таким образом, если в вашу систему попадет
00:19:13троян, который собирает все файлы .env и извлекает из них информацию,
00:19:20он не найдет там никаких секретов. В этом и идея: хранить секреты
00:19:25не в текстовых файлах в системе (а файл .env — это, по сути, просто текстовый файл),
00:19:32а в зашифрованном виде в другом месте. Это определенно стоит рассмотреть,
00:19:36и здесь есть разные решения.
00:19:40А чтобы быть еще более защищенным, вы можете вынести свою среду разработки
00:19:45со своего MacBook или ПК на внешний VPS или Mac mini,
00:19:50к которому вы подключаетесь по SSH или как-то иначе, или, возможно, использовать Docker-контейнеры. Тогда,
00:19:56если там выполнится какой-то вредоносный код, он затронет только этот Docker-контейнер
00:20:02или VPS, а не всю вашу систему. Он не сможет собрать все ваши системные пароли
00:20:07и тому подобное. Вместо этого он будет изолирован, и вы уменьшите радиус поражения. Поскольку
00:20:13такие атаки будут продолжаться — это очевидно. Я уверен, что у нас будут появляться
00:20:21все лучшие механизмы для защиты публикации пакетов и так далее, но 100% гарантии,
00:20:27что таких атак не случится, не будет никогда. И поэтому вы, как пользователь таких пакетов,
00:20:33должны защищать свою систему и иметь несколько уровней обороны, чтобы снизить шансы на
00:20:39загрузку скомпрометированной версии пакета, а если это случится — минимизировать ущерб.
00:20:45Я подробнее расскажу об этом в будущих видео, в том числе на моем втором канале,
00:20:50Academy. Будьте осторожны, проверьте, не затронула ли вас эта
00:20:55атака. И да, как я уже сказал, последние часы выдались непростыми.