Brother
Professional
- Messages
- 2,590
- Reaction score
- 483
- Points
- 83
Неправильные конфигурации непрерывной интеграции и непрерывной доставки (CI / CD), обнаруженные в платформе машинного обучения с открытым исходным кодом TensorFlow, могли быть использованы для организации атак на цепочку поставок.
Злоумышленник мог злоупотребить неправильными настройками, чтобы "провести компрометацию цепочки поставок релизов TensorFlow на GitHub и PyPI путем компрометации агентов сборки TensorFlow посредством вредоносного запроса на извлечение", - сказали преторианские исследователи Аднан Хан и Джон Ставински в отчете, опубликованном на этой неделе.
Успешное использование этих проблем могло позволить внешнему злоумышленнику загружать вредоносные версии в репозиторий GitHub, получать удаленное выполнение кода на собственном GitHub runner и даже получать токен личного доступа GitHub (PAT) для пользователя tensorflow-jenkins.
TensorFlow использует действия GitHub для автоматизации процесса сборки, тестирования и развертывания программного обеспечения. Раннеры, которые относятся к машинам, выполняющим задания в рабочем процессе GitHub Actions, могут быть либо автономными, либо размещенными на GitHub.
"Мы рекомендуем вам использовать только автономные раннеры с частными репозиториями", - отмечает GitHub в своей документации. "Это связано с тем, что форки вашего общедоступного репозитория потенциально могут запускать опасный код на вашем компьютере с автономным запуском, создавая запрос на извлечение, который выполняет код в рабочем процессе".
Иными словами, это позволяет любому участнику выполнять произвольный код на самостоятельном раннере, отправляя вредоносный запрос на извлечение.
Однако это не создает никаких проблем с безопасностью для раннеров, размещенных на GitHub, поскольку каждый раннер является эфемерным и представляет собой чистую изолированную виртуальную машину, которая уничтожается в конце выполнения задания.
Компания Praetorian заявила, что смогла идентифицировать рабочие процессы TensorFlow, которые выполнялись на автономных исполнителях, впоследствии обнаружив запросы на извлечение вилки от предыдущих участников, которые автоматически запускали соответствующие рабочие процессы CI / CD, не требуя одобрения.
Следовательно, злоумышленник, желающий троянить целевой репозиторий, может исправить опечатку или внести небольшое, но законное изменение в код, создать для него запрос на извлечение, а затем подождать, пока запрос на извлечение не будет объединен, чтобы стать участником. Затем это позволило бы им выполнять код в раннере без каких-либо предупреждающих сигналов путем создания несанкционированного запроса на извлечение.
Дальнейшее изучение журналов рабочего процесса показало, что автономный раннер был не только неэфемерным (что открыло дверь для сохранения), но также и то, что разрешения GITHUB_TOKEN, связанные с рабочим процессом, имели расширенные разрешения на запись.
"Поскольку GITHUB_TOKEN имел разрешение Contents: write, он мог загружать релизы на https://github [.]com / tensorflow / тензорный поток /releases /", - сказали исследователи. "Злоумышленник, скомпрометировавший один из этих "GITHUB_TOKEN", мог добавить свои собственные файлы в ресурсы выпуска".
Кроме того, содержимое: разрешения на запись могут быть использованы для отправки кода непосредственно в репозиторий TensorFlow путем скрытого внедрения вредоносного кода в функциональную ветвь и слияния его с основной ветвью.
Это еще не все. Субъект угрозы мог украсть AWS_PYPI_ACCOUNT_TOKEN, используемый в рабочем процессе выпуска для аутентификации в реестре индекса пакетов Python (PyPI), и загрузить вредоносный Python.whl-файл, эффективно отравляющий упаковку.
"Злоумышленник также мог использовать разрешения GITHUB_TOKEN для компрометации секрета репозитория JENKINS_TOKEN, даже если этот секрет не использовался в рабочих процессах, которые выполнялись на автономных исполнителях", - сказали исследователи.
После ответственного раскрытия 1 августа 2023 года разработчики проекта устранили недостатки с 20 декабря 2023 года, потребовав одобрения рабочих процессов, отправляемых из всех запросов на извлечение fork, и изменив разрешения GITHUB_TOKEN на " только для чтения" для рабочих процессов, которые запускались на автономных исполнителях.
"Подобные атаки CI / CD растут по мере того, как все больше организаций автоматизируют свои процессы CI / CD", - говорят исследователи.
"Компании, работающие с искусственным интеллектом / ML, особенно уязвимы, поскольку многие их рабочие процессы требуют значительных вычислительных мощностей, которые недоступны в раннерах, размещенных на GitHub, отсюда и преобладание автономных раннеров".
Раскрытие произошло после того, как оба исследователя обнаружили, что несколько общедоступных репозиториев GitHub, включая те, которые связаны с Chia Networks, Microsoft DeepSpeed и PyTorch, подвержены внедрению вредоносного кода через автономные исполнители действий на GitHub.
Злоумышленник мог злоупотребить неправильными настройками, чтобы "провести компрометацию цепочки поставок релизов TensorFlow на GitHub и PyPI путем компрометации агентов сборки TensorFlow посредством вредоносного запроса на извлечение", - сказали преторианские исследователи Аднан Хан и Джон Ставински в отчете, опубликованном на этой неделе.
Успешное использование этих проблем могло позволить внешнему злоумышленнику загружать вредоносные версии в репозиторий GitHub, получать удаленное выполнение кода на собственном GitHub runner и даже получать токен личного доступа GitHub (PAT) для пользователя tensorflow-jenkins.
TensorFlow использует действия GitHub для автоматизации процесса сборки, тестирования и развертывания программного обеспечения. Раннеры, которые относятся к машинам, выполняющим задания в рабочем процессе GitHub Actions, могут быть либо автономными, либо размещенными на GitHub.
"Мы рекомендуем вам использовать только автономные раннеры с частными репозиториями", - отмечает GitHub в своей документации. "Это связано с тем, что форки вашего общедоступного репозитория потенциально могут запускать опасный код на вашем компьютере с автономным запуском, создавая запрос на извлечение, который выполняет код в рабочем процессе".
Иными словами, это позволяет любому участнику выполнять произвольный код на самостоятельном раннере, отправляя вредоносный запрос на извлечение.
Однако это не создает никаких проблем с безопасностью для раннеров, размещенных на GitHub, поскольку каждый раннер является эфемерным и представляет собой чистую изолированную виртуальную машину, которая уничтожается в конце выполнения задания.
Компания Praetorian заявила, что смогла идентифицировать рабочие процессы TensorFlow, которые выполнялись на автономных исполнителях, впоследствии обнаружив запросы на извлечение вилки от предыдущих участников, которые автоматически запускали соответствующие рабочие процессы CI / CD, не требуя одобрения.
Следовательно, злоумышленник, желающий троянить целевой репозиторий, может исправить опечатку или внести небольшое, но законное изменение в код, создать для него запрос на извлечение, а затем подождать, пока запрос на извлечение не будет объединен, чтобы стать участником. Затем это позволило бы им выполнять код в раннере без каких-либо предупреждающих сигналов путем создания несанкционированного запроса на извлечение.
Дальнейшее изучение журналов рабочего процесса показало, что автономный раннер был не только неэфемерным (что открыло дверь для сохранения), но также и то, что разрешения GITHUB_TOKEN, связанные с рабочим процессом, имели расширенные разрешения на запись.
"Поскольку GITHUB_TOKEN имел разрешение Contents: write, он мог загружать релизы на https://github [.]com / tensorflow / тензорный поток /releases /", - сказали исследователи. "Злоумышленник, скомпрометировавший один из этих "GITHUB_TOKEN", мог добавить свои собственные файлы в ресурсы выпуска".
Кроме того, содержимое: разрешения на запись могут быть использованы для отправки кода непосредственно в репозиторий TensorFlow путем скрытого внедрения вредоносного кода в функциональную ветвь и слияния его с основной ветвью.
Это еще не все. Субъект угрозы мог украсть AWS_PYPI_ACCOUNT_TOKEN, используемый в рабочем процессе выпуска для аутентификации в реестре индекса пакетов Python (PyPI), и загрузить вредоносный Python.whl-файл, эффективно отравляющий упаковку.
"Злоумышленник также мог использовать разрешения GITHUB_TOKEN для компрометации секрета репозитория JENKINS_TOKEN, даже если этот секрет не использовался в рабочих процессах, которые выполнялись на автономных исполнителях", - сказали исследователи.
После ответственного раскрытия 1 августа 2023 года разработчики проекта устранили недостатки с 20 декабря 2023 года, потребовав одобрения рабочих процессов, отправляемых из всех запросов на извлечение fork, и изменив разрешения GITHUB_TOKEN на " только для чтения" для рабочих процессов, которые запускались на автономных исполнителях.
"Подобные атаки CI / CD растут по мере того, как все больше организаций автоматизируют свои процессы CI / CD", - говорят исследователи.
"Компании, работающие с искусственным интеллектом / ML, особенно уязвимы, поскольку многие их рабочие процессы требуют значительных вычислительных мощностей, которые недоступны в раннерах, размещенных на GitHub, отсюда и преобладание автономных раннеров".
Раскрытие произошло после того, как оба исследователя обнаружили, что несколько общедоступных репозиториев GitHub, включая те, которые связаны с Chia Networks, Microsoft DeepSpeed и PyTorch, подвержены внедрению вредоносного кода через автономные исполнители действий на GitHub.
