Обычный программист что-то гуглил в гугле и попал на репозиторий с вредоносным кодом и решил выяснить, сколько еще таких зараженных репозиториев, которые легко гуглятся.
3 августа Stephen Lacy написал в твиттере, что «обнаружил широкомасштабную атаку на 35 000 репозиториев GitHub», на проекты crypto, golang, python, js, bash, docker, k8s, а так же скрипты npm, образы докеров и установочные документы. (Позже он уточнил, что не «35 000 репозиториев», а 35 000 «code hits»)
Вскоре после его твита либо GitHub, либо злоумышленник удалил большинство общедоступных форков, а еще пару часов спустя появляется твит от только что созданной учетной записи пользователя @Pl0xP, где он утверждает, что он стоит за атакой, и это часть аудита за вознаграждение — bug bounty.
Большинство коммитов кажутся безобидными, с такими сообщениями, как «поднять версию до 0.3.11».
Некоторые из этих repo histories включают коммиты от первоначального автора, но коммит не проверен GPG: github.com/redhat-openshift-ecosystem/operator-bundle-validate-container/commits?author=samvarankashyap
Некоторые из этих репозиториев были «заархивированы», например, этот в 2019 году.
github.com/Logicalis/asn1/commit/9962b33c959eb0e62f60280a7f65552365ff31cc
Некоторые из них замаскированы под законно выглядящие пулл-реквесты, но репозиторий не получил никаких PR, Каждый файл go в этом репозитории был заражен.
Stephen Lacy обнаружил эксплойт, когда просматривал проект, который нашел в поиске Google. Он рекомендует не устанавливать случайные packages из Интернета, и призывает подписывать коммиты GPG.
Эта атака, возможно, направлена на пользователей, которые вводят в search-engines-related code snippets и попадают в эти вредоносные репозитории GitHub.
Вот возможный сценарий атаки:
- Злоумышленник форкает репозиторий GitHub
- Злоумышленник изменяет последний исходный коммит и добавляет вредоносный код, используя исходный идентификатор коммиттера.
- Вредоносная начинка отправляет конфиденциальные переменные среды в инфраструктуру злоумышленника, а затем ожидает команды от злоумышленника для выполнения на машине.
Похоже, что злоумышленник изменял самый последний коммит и модифицировал его с помощью вредоносного кода. Возможно, он планировал внедрить этот код в исходный форкнутый проект.
Внося или фиксируя изменения правильным образом, злоумышленники могут выдать себя за другого пользователя GitHub и создать впечатление, что коммит исходит от них. Это делается путем локального изменения определенных переменных среды для получения имени пользователя и адреса электронной почты пользователя, за которого злоумышленник хотел бы выдать себя.
Скриншот одного из зараженных коммитов. Обратите внимание, что подпись коммита не проверена
Зараженные Golang файлы
Похоже, что злоумышленник запустил программу, чтобы «исправить» каждый из файлов «.go» клонированного проекта с помощью функции инициализации, таким образом получив возможность эксфильтрации переменных среды и выполнения кода на машине жертвы. Этот вредоносный код не будет работать, если переменная среды «e452d6ab=1» определена:
Зараженные NPM файлы
Похоже, злоумышленник запустил программу для «исправления» каждого из файлов «package.json» клонированного проекта с оператором «postinstall», имея логику для эксфильтрации переменных среды и выполнения кода на машине жертвы:
Зараженные YAML файлы
Файлы YAML, конфигурация инфраструктуры и контейнеры были изменены с помощью дополнительных шагов для выполнения команды curl для эксфильтрации всех переменных среды в настраиваемую службу:
Заявлению о том, что это «аудит» противоречат два момента:
- Код отфильтровал важные переменные среды. Допустим, вы делаете POC, и отправки имени вашего компьютера более чем достаточно.
- После эксфильтрации данных сервер отправлял команды для выполнения на машине жертвы.
Tane Piper написал, что 5 лет назад он сообщил почти о том же эксплойте в @npmjs, но никто не воспринял это всерьез.
Sven Slootweg прокомментировал: «На самом деле это не столько «эксплойт в npm», сколько более фундаментальная проблема с контролем доступа в операционных системах текущего поколения. Удаление постустановочных скриптов на самом деле ничего не решит — вместо этого вы просто вставите свой вредоносный код куда-нибудь в код пакета.»
Выводы
GitHub как вектор атаки в эпоху автоматизированных конвейеров ci/cd невероятно недооценен.
Данная атака нацелена на наивных разработчиков, так что будьте внимательны, когда гуглите куски кода. А если это все же было дело рук белого хакера, то уж очень потенциально вредоносные методы он выбрал.
PS
Не важно насколько криво я написал пост, важно сколько пользы для сообщества написали вы в комментариях.
Комментарии (50)
vindy123
04.08.2022 06:50+34Статья - какой-то лютый бессмысленный речекряк, абсолютно ничего не объясняющий.
bogomolovvm
04.08.2022 07:50+17Он рекомендует не устанавливать случайные packages из Интернета, и призывает подписывать коммиты GPG.,
Смотря какой fabric, смотря откуда приходит fabric
andreishe
04.08.2022 08:01+24Как сказали на реддите под этой новостью:
Person uploads malware into their own project that wasn't used by anyone. Panic ensues.
Офигенная атака, да.
d2d8
04.08.2022 08:42+15На самом деле вектор атаки тут есть. Если форкать давно не обновляемые репозитории, лупить туда псевдоапдейты в которых якобы что-то пофикшено или указан переход на современные библиотеки то вполне себе вменяемый человек может такие форки попытаться использовать. А если там кроме вредоноса действительно что-то нужное исправлено/добавлено то и оставить в рабочем проекте.
baldr
04.08.2022 08:51+2Проблема в том, что можно делать коммиты под чужим именем. Вы делаете коммит от кого-то знакомого мейнтейнеру проекта, надеясь что он не будет внимательно все проверять и смержит. Можно использовать подпись, но все ли так делают?
HappyGroundhog
04.08.2022 08:52+17В телеграмм канале «SecAtor» (чтобы соблюсти авторские права на текст)
было гораздо более понятное объяснение произошедшего.Разработчик Стивен Лейси обнаружил [1, 2] широко распространенную атаку вредоносного ПО на GitHub, затронувшую около 35 000 репозиториев программного обеспечения.
Речь идет о клонировании тысяч репозиториев GitHub в рамках нацеливания на ничего не подозревающих разработчиков. Тысячи проектов являются форками известных проектов, таких как crypto, golang, python, js, bash, docker, k8s и др., правда с начинкой в виде бэкдоров.
В анализа одного из них с открытым исходным кодом инженер заметил следующий URL-адрес в коде hxxp://ovz1.j19544519.pr46m.vps.myjino[.]ru.
При поиске GitHub по этому URL-адресу было найдено более 35 000 результатов, отображающих файлы с вредоносным URL-адресом. При этом более 13 000 результатов поиска соответствовали одному репозиторию под названием redhat-operator-ecosystem, который был оперативно удален с GitHub.
Разработчик Джеймс Такер указал, что клонированные репозитории, содержащие вредоносный URL-адрес, не только извлекают переменные среды пользователя, но и дополнительно содержат однострочный бэкдор.
Эксфильтрация переменных среды сама по себе может предоставить злоумышленникам ключи API, токены, учетные данные Amazon AWS и криптографические ключи, где это применимо.
Подавляющее большинство клонированных репозиториев были изменены с помощью вредоносного кода в течение последнего месяца. Тем не менее, были и репозитории с вредоносными коммитами, датированными еще 2015 годом.
GitHub удалил вредоносные клоны со своей платформы после получения отчета инженера. Тем не менее ресерчер Флориан Рот предоставил правила Sigma для обнаружения вредоносного кода в среде.
Разработчикам следует не забывать использовать ПО исключительно из официальных репозиториев и внимательно отслеживать потенциальные опечатки или разветвления репозитория, которые могут казаться идентичными исходному проекту, но скрывать вредоносное ПО.baldr
04.08.2022 09:17+1Я давно уже считаю что использовать переменные окружения в наше время неудобно и небезопасно. Просто положив ваши пароли-секреты в отдельный файлик вне папки с кодом, вы уже значительно усложните задачу по их поиску. Конечно, это тоже не очень способ, но хоть с чего-то надо начать..
Прочитать переменные окружения и отправить POST-запрос с ними сейчас, теоретически, можно сравнительно маленьким куском кода, замаскированным под регексп.
SergeyMax
04.08.2022 09:37-7Просто положив ваши пароли-секреты в отдельный файлик вне папки с кодом
Вы только что начали лечить понос затыканием жопы)
baldr
04.08.2022 09:55+7Сэр, вот вы пришли в комментарии, нагрубили пошлым комментарием неизвестному вам человеку, по сути не предложили ничего умного. Это хорошо?
Я, тем не менее, с удовольствием узнаю вашу точку зрения - как бы вы предложили решить такую проблему?
Большая часть проектов на гитхабе - это небольшие библиотеки или скрипты. Им нет необходимости городить сложные энвароменты с, например, Vault или другими хранилищами секретов, но им нужны, например, ключи для AWS.. Вроде бы сейчас уже меньше стало хардкода паролей в коде, но переменные окружения до сих пор считаются нормальной практикой, несмотря на кучу уязвимостей с ними.
Если вставить в практически произвольное место проекта на, скажем, питоне, однострочник с отправкой переменных окружения на какой-то левый адрес, то есть шанс, что никто и не заметит. И это довольно просто сделать для тысяч проектов (как и было продемонстрировано). Если же ваши пароли лежат в отдельном файле, то его еще надо найти (атака уже адресная), а для проекта прочитать файл не сложнее работы с окружением.
Я понимаю все минусы хранения в файлах, конечно же. Но - я здесь сравниваю только с переменными окружения.
SergeyMax
04.08.2022 10:05+6Я, тем не менее, с удовольствием узнаю вашу точку зрения - как бы вы предложили решить такую проблему?
Как бы совершенно очевидно, что если ваша пропатченая библиотека или скрипт используют логин и пароль, то куда бы вы его не прятали, в переменную окружения ли, в командную строку, или в не менее секретный файлик — в любом из этих случаев ваш драгоценный пароль утечёт, а дырявая библиотека откроет на вашей машине дупло таких размеров, что вы замучаетесь потом всё это вычищать. Поэтому совершенно очевидно, что решать проблему нужно не затыканием жопы (читай: перекладыванием пароля из одного места в другое), а неиспользованием левых репозиториев, незапуском мутного вареза на машине, и вообще мытьём рук перед едой.
kahi4
04.08.2022 10:36+5Это просто немыслимо. Webpack стандарт в мире разработки фронтэнда. Фактически, в веб-разработке практически на любом своременном стеке (даже на F#) он к вам доедет. У него самого больше сотни зависимостей (включая дев), у каждой из которых от 10 до 30 своих зависимостей, если покопаться, можно выйти на https://www.npmjs.com/package/xo (кто об это вообще слышал) -> execa -> c8 -> standard -> standard-engine -> installed check -> npm-run-all2 у которого есть pretest скрипт, который что-то делает. Проверить эту всю кротовую нору фактически нереально, поэтому нужно предпринимать более сложные шаги, на подобие сборки в докере без доступа к окружению.
SergeyMax
04.08.2022 10:52+3а подобие сборки в докере без доступа к окружению
Ну собрали без доступа к окружению, и дальше что? Ваша дырявая прога будет слушать дефолтный порт, и при приёме магического пакета будет выполнять команду drop database (или create user, если хотите). Даже если у вас вообще нет никакого доступа ни к какому окружению (допустим, это статический сайт), то всё равно остаётся возможность отгрузить клиентам веб-майнер, или ещё какую-нибудь хрень.
Просто сейчас линуксоиды столкнулись с тем, с чем столкнулась винда 30 лет назад: разработка вирусни под линукс внезапно стала выгодной.
kahi4
04.08.2022 11:23С одной стороны да, с другой - это же просто минимизация рисков. Ну вот взять веб-звонки. Мы в данный момент не можем потянуть написать это с нуля, вынуждены пользоваться чем-то. Да и вебпак нужен тоже. Ничего не ставить - так себе бизнес модель. Более того, шансов что самописный код будет иметь уязвиосмость больше чем шансы зловредна у пакета, который скачивают 40 млн раз в неделю (окей, что его никто не заметит с этими вашими сонар кубами и прочим).
Но минимизировать все равно можно. Конкретно с фронтэнжом собирая в «чистом» докере мы не даем доступов ни к чему во время сборки. Чтото может просочиться в бандл, но мы постоянно толпой просматриваем все запросы которые делает наш фронтэнд и куда он их делает, более того у нас есть service worker который протестирует все запросы и поддельный будет обнаружен быстро (впрочем, это особенности именно нашего продукта, в котором нам нельзя делать 3rd party requests вообще. У части клиентов стоит строгий whitelist например). Да, теоретически он может «спать» неделями, годами, но опять же - риск менеджмент он такой.
С бэкэндом, конечно же, сложнее. Но тоже решается зеркалом и доступами куда ему можно ходить.
kahi4
04.08.2022 11:28+2К слову, с тем что перекладывание паролей из одного места в другое слабо решает проблему, я все же соглашусь. Это довольно распространенная практика и все используют одни и те же пакеты для Парсинга конфигов, так что толку то. Да и можно внедрить вредонос непосредственно в драйвер базы данных (рефлексией или какой еще магией вам позволяет это сделать язык) и удачи.
SergeyMax
04.08.2022 11:37-1шансов что самописный код будет иметь уязвиосмость больше чем шансы зловредна у пакета, который скачивают 40 млн раз в неделю
Это без сомнения именно так. Но в статье речь о другом: о том, что вы случайно вместо одного пакета включаете другой, со скачиванием 10 раз в неделю, в котором шанс нахождения зловреда на порядки выше. Просто потому, что вам пытаются показать, что этот пакет новее, или лучше поддерживается.
SergeyMax
04.08.2022 11:01Проверить эту всю кротовую нору фактически нереально
Речь идёт не о том, чтобы лично вы проверяли эту кротовую нору, а о том, чтобы вы как минимум не воткнули в свой проект левый форк вместо оригинального репозитория. Потому что тема сейчас определённо поедет.
kahi4
04.08.2022 11:24Мой пример был о том, что в ноде вы не воткнули, но как вы определите что какой-то из дочек дочек дочек не воткнул?
SergeyMax
04.08.2022 11:32-1но как вы определите что какой-то из дочек дочек дочек не воткнул?
Это же не я определяю, а мейнтейнеры пакетов. Но целевая аудитория этой конкретной атаки с фейковыми форками не они, а обычные ололо-веб-программисты.
faultedChip
04.08.2022 13:00С чего вы взяли что разработчик "какой-то из дочек дочек дочек" не может быть так обманут? Там зачастую точно такие же ололо-веб-программисты (ох уж этот элитизм...)
SergeyMax
04.08.2022 13:17-1С чего вы взяли что разработчик "какой-то из дочек дочек дочек" не может быть так обманут?
Как минимум с того, что его код популярен, и проверен множеством использований (и элитизм тут ни при чём).
dravor
04.08.2022 16:04+2Как минимум с того, что его код популярен, и проверен множеством использований (и элитизм тут ни при чём).
В это предлагается просто исступленно верить, потому как после этой фразы принято кивать с умным видом и расходиться. Кто те полчища мэйнтейнеров, которые проверяют каждый пакет во всех тысячах зависимостей обычно уже не обсуждается.
faultedChip
04.08.2022 17:28+2Я думал эта байка опенсорса рассыпалась после целой череды уязвимостей, которые годами висели ненайденными. Чего стоит только последняя пачка уязвимостей в Самбе.
и элитизм тут ни при чём
Я и не говорю что он оправдан.
SergeyMax
04.08.2022 20:16-1Уязвимости есть всегда и везде, и этот факт не является поводом действовать по принципу "сгорел сарай - гори и хата", и хватать первую попавшуюся позавчера созданную репу вместо существующей уже пару лет. Извините за банальность.
faultedChip
04.08.2022 20:32Извините за банальность.
Извиняю, но скажите как эта банальность относится к теме обсуждения? Речь ведь шла о зависимостях в зависимостя.
TheRikipm
04.08.2022 20:09-1Если вставить в практически произвольное место проекта на, скажем, питоне, однострочник с отправкой переменных окружения на какой-то левый адрес, то есть шанс, что никто и не заметит.
Если вставить в практически произвольное место проекта на, скажем, питоне, однострочник с отправкой файла с паролями на какой-то левый адрес, то шанс что никто его не заметит тоже есть.
Если практика хранения паролей в отдельном файле станет распостраннённой и вирусы будут красть файлы, а не переменные окружения, то вы будете реккомендовать вынести пароли из файла в какое-то другое место? Например, в переменные окружения?)
baldr
04.08.2022 20:21Я, например, буду рекомендовать, например, прочитать настройки из этого файла и удалить, чтобы больше к нему не имел доступа никто из этого контейнера. Их все еще можно будет получить из памяти, из этого же файла до его удаления, но это уже, опять же, адресная атака на конкретно это приложение, здесь можно много всего придумать.
Переменные окружения часто наследуют даже дочерние процессы, запущенные из основного, а сервисы в контейнерах до сих пор запускаются из-под root, так что, опять же - с ними проблема стоит острее.
TheRikipm
04.08.2022 20:32Я, например, буду рекомендовать, например, прочитать настройки из этого файла и удалить, чтобы больше к нему не имел доступа никто из этого контейнера.
Ну т.е. вы будете хранить пароли не в файле, а в памяти? И однострочнику на пайтоне ничего не помешает прочитать их из памяти и отправить на удалённый сервер?
Их все еще можно будет получить из памяти, из этого же файла до его удаления, но это уже, опять же, адресная атака на конкретно это приложение
Если описанная вами практика станет популярна, то зловреды будут сразу искать пароли в памяти и подобная атака перестанет быть адресной.
Система безопасности которая опирается на экзотичное место хранения паролей - это security through obscurity в чистом виде. Вы с таким-же успехом можете поменять местами имена переменных окружения: например назвать переменную с паролем для базы данных "REDIS_HOST", а переменную с паролем для редиса "MAIL_USERNAME". Я уверен, атакующий будет в замешательстве.baldr
04.08.2022 20:44+1Мне очень нравится как вы предлагаете способы решения проблем. Ой, а вы же не предлагаете! Критиковать очень просто, да.
Давайте я еще раз зачем-то для вас повторю то что я уже в этом же треде писал: я понимаю все эти проблемы с файлами. Если захотят взломать конкретно мое приложение - никого не остановят ни хранение паролей в памяти, ни их шифрование, ни другие способы. Особенно если проект лежит в открытом репозитории.
Вот смотрите - было показано что для 35000 файлов из разных репозиториев можно автоматически вставить отправку переменных окружения. В переменные окружения сейчас лепят практически все секреты и они там живут весь срок работы сервиса, причем прочитать их могут даже соседние процессы.
Принимая во внимание все то что в этих комментариях тут уже писали - у вас есть предложения по теме?
TheRikipm
04.08.2022 20:57Если вы сами понимаете все эти проблемы то зачем предлагаете подобные способы "защиты"? Вы можете жонглировать паролями хоть каждую секунду - переносить их из окружения в файлы, из файлов в БД, из БД в память и т.д - если код зловреда имеет те-же полномочия что и основной код - то он может прочитать пароли оттуда-же откуда его читает основной код.
На этом уровне проблема защиты принципиально не решаема, нужно исправлять проблему с зловредными библиотеками.
Мне очень нравится как вы предлагаете способы решения проблем. Ой, а вы же не предлагаете! Критиковать очень просто, да.
Если вы адепт логики "Критикуешь - предлагай", то рекомендую вам отвыкать от неё. Мне не обязательно знать решение проблемы что-бы понять что ваше решение ничего не даёт.
- Коллеги, нам нужно придумать лекарство от рака. У кого-нибудь есть предложения?
- А давайте вколим пациенту три литра физраствора и заставим его танцевать джангу!
- Что за бред? Как это поможет пациенту?
- Критиковать всегда просто, а вы попробуйте сами что-нибудь предложить.baldr
05.08.2022 19:21Ок, вот вам более понятный пример.
Допустим, вам стало известно что в моем проекте используется библиотека, к которой у вас есть доступ. Пусть это будет что-то простое - например, дополнительные математические функции для статистики. Вы можете поменять какую-то часть кода на свою и если изменения небольшие - есть шанс что они проскочат формальную инспекцию и попадут в проект.
Вы не знаете про мой проект ничего - ни как используются ваши функции, ни как организован проект, ни права процесса. Вам нужно утащить все возможные пароли и секреты, хотя бы один - что вы сможете придумать? Язык - на ваш выбор из Python/Javascript/PHP. Мне не нужен код - просто идеи.
Мне не обязательно знать решение проблемы что-бы понять что ваше решение ничего не даёт.
Самый очевидный и простой вариант - получить и отправить переменные окружения. Если их нет - что тогда?
p07a1330
04.08.2022 21:18Тянуть их с локального сервера, желательно - не имеющего доступа в большой интернет и с доступом только по белому листу.
Грубо говоря, у нас есть сервер с бизнес логикой, который должен работать с конфиденциальными данными. Мы поднимаем рядом с ним (можно даже в той же машине, просто докером) еще 1 сервер, который принимает запросы ТОЛЬКО от сетки 192.168... (или даже только с локалхоста) и отдает статичный JSON.
Сломайте)
Как вариант экзотики - сервер можно сделать SFTP и на каком-нибудь нестандартном порту.
Barnaby
04.08.2022 09:56+1И как это будет с ci/cd работать?
baldr
04.08.2022 10:10Плохо будет работать. И проблема известна, но все что рекомендуют - "проверяйте коммиты", что, на мой взгляд, довольно плохой совет сам по себе.
iig
04.08.2022 10:31В CI/CD есть своя уличная магия для паролей/ключей/секретов. Надо её использовать.
baldr
04.08.2022 10:38+2Это вы про вот это вот?
Filetype variables:* Consist of a key, value and file.
* Are made available in jobs as environment variables
То есть пароль для Google Apps, нужный только маленькой части приложения, становится доступен сразу всем другим частям, в том числе и левым библиотекам, подгруженным по зависимостям. И, вспоминая node.js dependency hell, например, я не представляю как можно простым ревью кода что-то тут предотвратить.
iig
04.08.2022 13:30Да, эта магия помогает не сохранять пароли в исходниках. От выполнения недоверенного кода - разве что для каждого модуля отдельная песочница и строго определенные интерфейсы взаимодействия - но кто так делает?
Yuribtr
04.08.2022 10:35+9Может это атака на Copilot и им подобные системы? Когда ослабнет контроль за репозиториями-донорами, такой код вполне может попасть в какой нибудь рабочий проект.
TheSima
04.08.2022 12:57+5Так же это возможно атака тот самый ИИ который обучается на коде из github, он увидит что этот код много где вставляется и тоже начнёт вставлять его в свой код, удобно)
Max_JK
04.08.2022 12:31Вижу слова и предложения но в осмысленную последовательность они не складываются, слишком сложно читать. Если бы я не знал про эту атаку раннее то думаю вообще бы ничего не понял. Можно писать как-то проще как раз для наивных разработчиков которые не разбираются в этой теме и терминах?
magic2k
05.08.2022 04:22+4Текст адверсариал атак! Емердженси выход! not rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ
Еще и в теги го поставили, на основании того, что там про голанг и packages упоминание :)
rinat_crone
Как нормальный человек должен вообще ваш опус читать?
Имя логику, а заодно, по ходу, переводчика и весь русский язык.
Так отфильтровал или всё же нет?
коммит вообще не подписан подписью.
Действительно, удалял на днях постустановочный скрипт и, внезапно, вставил вредоносный код внутрь пакета. Боги, что за чушь тут написана?
даже magic gooddy лучше бы справился
Кого, простите, злоумышленник хочет выдать за другого? Получаемое имя пользователя?
Вы вроде пытались важную информацию донести своей статьёй но где-то по пути что-то явно пошло не так. Это как если бы айтишники статьи по медицине писали, ей богу — было бы не менее смешно и столь же удручающе читалось, какая бы полезная (и не важно, насколько баянистая, ага) там информация не была выложена.
Timeweb, если вы считаете ЭТО хорошей рекламой своему сервису на IT–ресурсе, то у меня для вас плохие новости.
AndreyDmitriev
Я вообще нифига не понял. Похоже суть в том, что злоумышленник форкает популярный репозиторий, добавляет вредоносный код, коммитит его (в своём же форке) как бы от имени владельца оригинального репозитория, юный программист, возжелавший исходников, натыкается на форк, копирует код себе, не глядя запускает и приехали. Если так, то это всё равно что по ссылкам в фишинговом письме щёлкать, и такому юзеру и так пофиг от кого там последние коммиты и подписаны они или нет. А коммитить, используя чужой идентификатор, вроде и раньше можно было и где-то было обсуждение - является ли это вообще угрозой или нет.
faultedChip
Ну в целом так: в гитхабе же не только крупные и поддерживаемые проекты, хватает небольших полезных проектов, которые давно заброшены маинтейнерами - и у многих куча форков с исправлениями под современные реалии. И десяток вредоносных форков среди таких будет совершенно не заметен.
А про подпись коммитов я лично в первый раз слышу - в руководствах по использованию гита на него не натыкался.
AndreyDmitriev
Ну тут надо быть очень внимательным, да.
Про коммит от имени чужого пользователя я по-моему видел что-то на хабре, но не могу найти. Вроде там только email пользователя надо знать и больше ничего.
Сам гитхаб вот что пишет:
Why are my commits linked to the wrong user?
Ну а про подпись вот навскидку:
Git Tools - Signing Your Work
d583605
Возможно вот https://habr.com/ru/post/515550/
Artarik
не все так однозначно. Как быть с проектами которые разработчик забросил, а их подхватил кто-то другой, например? изучать полностью 2 ветки и пытаться понять вредоносный код это или полезный?