The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Анализ подверженности репозиториев на GitHub атаке RepoJacking

24.06.2023 10:48

Исследователи из компании Aqua Security проанализировали применимость атаки RepoJacking к репозиториям на GitHub. Суть проблемы в том, что после удаления или переименования проектов на GitHub, в сторонних репозиториях могут остаться ссылки на уже несуществующие имена, например, в документации, скриптах и инструкциях по установке из README-файлов. Атакующий может зарегистрировать на GitHub имя пользователя, повторяющее ранее существовавшее имя, разместить в репозитории с повторяющимся именем вредоносное ПО и ожидать, что кто-то загрузит его, пользуясь неисправленными руководствами или старым кодом, загружающим зависимости по старым ссылкам.

Например, в прошлом году подобным образом был получен контроль над PHP-библиотекой phpass. В GitHub имеется защита от повторной регистрации удалённых проектов, но её удалось обойти через создание репозитория с тем же именем в произвольной учётной записи, после чего переименовать эту учётную запись в целевую. Например, если нужно зарегистрировать репозиторий user/rep, где учётная запись user удалена, GitHub даст создать повторно пользователя "user", но не позволит создать репозиторий "rep". Обойти это ограничение можно создав репозиторий "rep" в учётной записи другого пользователя (например, "user1"), после чего переименовать этого пользователя в "user".

GitHub теперь пытается противостоять подобным манипуляциям, но по данным Aqua Security, не все обходные пути блокируются и защита распространяется только на самые популярные проекты, до переименования насчитывавшие более 100 клонов. При этом защита не захватывает проекты, ставшие популярными после переименования. Также не учитывается, что популярный проект может использовать в качестве зависимости менее популярный репозиторий, который раньше был переименован и на который не распространяется защита (атака может быть совершена через подмену зависимости). После переименования GitHub автоматические перенаправляет старые ссылки на новый репозиторий, но это перенаправление действует только до регистрации пользователя с тем же именем, из-за чего в коде часто забывают поправить ссылки на новое имя.

В ходе исследования Aqua Security была изучена выборка из 1.25 млн репозиториев, что соответствует примерно 0.4% от общего числа репозиториев на GitHub. Список был получен на основе анализа лога изменений за случайный месяц (июнь 2019). Подверженность атаке RepoJacking выявлена в 36983 репозиториях (2.95%). Экстраполировав полученные результаты на все репозитории GitHub сделан вывод, что потенциально атака RepoJacking может затрагивать более 8 млн репозиториев.

В качестве примера рассмотрены RepoJacking-уязвимости в репозиториях Google (google/mathsteps) и Lyft (yesgraph-Dominus_DEPRECATED). В репозитории Google старое имя репозитория ("socraticorg/mathsteps") упоминалось в официальной инструкции по установке, а в репозитории Lyft присутствовал установочный скрипт, загружающий ZIP-архив из переименованного репозитория ("YesGraph/Dominus"). Для совершения атаки злоумышленник мог зарегистрировать пользователей "socraticorg" и "YesGraph", после чего разместить в них репозитории "mathsteps" и "Dominus".

Исследователями также проведена экспериментальная атака, показывающая работоспособность метода. В нескольких переменованных репозиториях были организован сбор информации об IP-адресах, загрузивших размещённые в репозитории артефакты. В итоге загрузки подменённых данных были зафиксированы в сетях нескольких крупных компаний.

  1. Главная ссылка к новости (https://blog.aquasec.com/githu...)
  2. OpenNews: Выявлена подстановка вредоносной зависимости в ночные сборки PyTorch
  3. OpenNews: Атака на NPM, позволяющая определить наличие пакетов в приватных репозиториях
  4. OpenNews: Уязвимости в сканерах безопасности образов Docker-контейнеров
  5. OpenNews: Атака на зависимости позволила выполнить код на серверах PayPal, Micrоsoft, Apple, Netflix, Uber и ещё 30 компаний
  6. OpenNews: Атака на проекты через регистрацию GitHub-репозитория с тем же именем
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/59339-github
Ключевые слова: github, attack
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (19) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.6, Анониссимус (?), 13:17, 24/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Держать исходники на блокчейне -- было бы самым надёжным решением. Держать в облачном сервисе -- самое ненадёжное.

    Есть ещё компромиссный вариант: держать на своём сервере. Вот что мешало например гуглу хранить свою либу на своём сервере? Но нет же, всем гетхапчик подавай.

     
     
  • 2.8, Всем Анонимам Аноним (?), 13:54, 24/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Блокчейн ничем не лучше просто проверки контрольной суммы. Но это только для конкретной версии.
    Если нужна последняя версия, то тогда блокчейн не спасет в случае кражи ключей. Более того, будет куча исходников, которые навечно будут туда ссылаться. Поэтому этот вирус будут получать и через 50 лет.

    Нет простых и идеальных решений.

     
     
  • 3.14, Аноним (14), 17:58, 24/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Блокчейн ничем не лучше просто проверки контрольной суммы.

    Лучше.
    Чтобы добавить блок, нужно заплатить. Т.е. чтобы создать repojacking надо заплатить хотя бы минимальную комиссию за каждый репозиторий (а скорее всего существенно больше, зависит от реализации), что резко сужает круг репозиториев, которые имеет смысл реподжектить.
    Во-вторых в биткойне (а остальные блокчейны не нужны) ещё и по адресу можно определять владельца. Т.е. это не только контрольная сумма, но и подпись. Владеешь кошельком - значит владеешь репозиторием (что все же лучше по безопасности чем емейл/пароль на гитлабе). Есть даже аутентификации на lightining (LNURL-auth).

    > Более того, будет куча исходников, которые навечно будут туда ссылаться. Поэтому этот вирус будут получать и через 50 лет.

    Но и полезный софт тоже будет доступен через 50 лет. Кроме того пользователи легко смогут отфильтровать проекты по времени.

    > Нет простых и идеальных решений.

    Абсолютно верно! В наше время любят про это забывать.

     
     
  • 4.16, КО (?), 18:39, 24/06/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Все эти ваши смузидвижения можно произвести и без блокчейна и по мощности пук будет примерно такой же.
     
     
  • 5.28, Аноним (28), 04:59, 26/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Все эти ваши смузидвижения можно произвести и без блокчейна и по мощности
    > пук будет примерно такой же.

    Можно. Но вся централизация упирается в бесконечное количество всяких *джекингов, фишингов, атак на владельца, злоупотреблений и пр. Ну а с децентрализацией предлагайте, попробую рассказать почему этот способ хуже (ну или позорно посыплю голову пеплом если предложите что-то стоящее).

     
  • 4.26, Бывалый смузихлёб (?), 10:17, 25/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    чтобы взымать плату блокчейн не обязателен
    ну а второй аргумент - по сути, можно просто сделать доступ по ИД репы без возможности его менять
     
     
  • 5.27, Аноним (28), 04:52, 26/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > чтобы взымать плату блокчейн не обязателен
    > ну а второй аргумент - по сути, можно просто сделать доступ по
    > ИД репы без возможности его менять

    Можно, но если это централизация, то привет проблемы гитхаба (собственно имя это ид, а то что его можно менять это бага, то что ид станет цифровым, не избавит от багов, не говоря уже о других проблемах, на мой взгляд более весомых).
    Если это децентрализация, то нужны методы борьбы с фейками. В биткойне уже это есть (собственно он изначально и вырос из антиспамера для почты).

     
  • 3.19, Анониссимус (?), 20:40, 24/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Блокчейн ничем не лучше просто проверки контрольной суммы. Но это только для
    > конкретной версии.
    > Если нужна последняя версия, то тогда блокчейн не спасет в случае кражи
    > ключей. Более того, будет куча исходников, которые навечно будут туда ссылаться.
    > Поэтому этот вирус будут получать и через 50 лет.
    > Нет простых и идеальных решений.

    У блокчейна есть одна важная особенность: защита от подделки истории. Если туда что-то записано, изменить это нельзя (если это сильный блокчейн). Поэтому, теоретически, разные библиотеки и пр. можно было бы аудировать и конкретные версии записывать в блокчейн (или хеш просто). Тогда эта конкретная версия ПО была бы защищена и от потенциальных взломщиков, и даже от самого автора софта.

     
  • 2.9, Аноним (-), 13:55, 24/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Деньги.
    Вы не против организовать нам всем халявный аналог гитхаба, раз уж так хорошо разбираетесь в надежности и что кому мешает?
     
     
  • 3.15, Аноним (14), 18:00, 24/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Так есть же, но вы же сами им не пользуетесь. Поколение рабов хочет жить по-царски, но боится ломать цепи.
     
     
  • 4.21, Аноним (21), 22:30, 24/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если ты сейчас не про хостинг кода pashev.ru, то больше не разговаривай со мной никогда.
     
  • 4.22, Аноним (22), 23:37, 24/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >рабы хотят вкалывать бесплатно, делая свои никому кроме них не нужные хобби-проекты, но при этом чтобы их хобби оплачивал кто-то другой

    пофиксил.

     
  • 2.20, Amonim (?), 21:26, 24/06/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В git целостность истории обеспечивается на основе дерева хешей. Чем это не блокчейн? В основе те же принцыпы и технологии.
     
     
  • 3.23, Анониссимус (?), 01:08, 25/06/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Отличие в том, что в гите можно перестроить это дерево хешей, и никто этого может и не заметить. А в блокчейне это невозможно, если только не завладеешь контролем над всей сетью.
     
     
  • 4.30, Аноним (30), 22:29, 03/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Отличие в том, что в гите можно перестроить это дерево хешей, и никто этого может и не заметить.

    Чё правда?

     
     
  • 5.31, Анониссимус (?), 01:35, 04/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> Отличие в том, что в гите можно перестроить это дерево хешей, и никто этого может и не заметить.
    > Чё правда?

    Я в устройстве гита глубоко не разбираюсь. Но есть вполне понятные соображения. Репозиторий чаще всего хранится на одном главном хосте (хоть система и является распределённой). С этого же главного хоста потом и скачиваются исходники. И если тот, кто управляет главным репозиторием (или тот, кто захватил контроль) внедрит какой-нибудь вредонос в исходники; то те, кто делает 'git clone' (пользователи, мейнтейнеры, скрипты -- не важно) ничего не заметят. Потому что почти никто не будет сверять хеши. Да и с чем сверять? Где хранится хеш от "правильной", не подменённой версии ПО? Такую проблему может решить только хранилище, в котором историю действительно невозможно переписать задним числом. И насколько я знаю, единственной такой технологией является блокчейн.

     

  • 1.7, Аноним (-), 13:53, 24/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хотелось бы детализации на основе ЯП, а то я подозреваю, что уязвимость сильно завязана на лефтпады.
     
     
  • 2.24, Аноним (24), 07:19, 25/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Может на всеми любимый тут go
     

  • 1.29, Аноним (29), 10:15, 27/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Потому что гит это горбуха идеологически. Вот и страдайте. А нормальные люди пользовались и будут пользоваться централизованными, платными сервисами.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру