Comments 16
Интересно, кто минус за статью поставил? Автор одного из описанных репозиториев?
какой бюрократический ад менеджерам нужно пройти
Менеджеры минимизируют свои усилия и, особенно, личную инициативу. У них нет повода проходить бюрократический ад, пока с них этого не требуют.
Автор предлагает автоматически удалять любой репозиторий который попал под общую регулярку аля "download now"?
В статье был пример, как с помощью регулярки и обычного поиска на сайте гитхаба любой человек может найти репозитории, которые с большой вероятностью распространяют троян. А это значит, что команда безопасности гитхаба, с их ресурсами и возможностями, тоже могла это сделать.
Автоматизировать можно не только поиск, но и проверку файлов на вирусы. И после проверок скрипт мог бы составлять список репозиториев для последующей ручной проверки человеком, который примет окончательное решение об удалении репозитория.
"download now" был первой строкой поиска, под который попадало много легитимных репозиториев, о чём в статье и было указано. Я и подумать не мог, что после прочтения у вас появится мнение, что по этой строке поиска нужно автоматически удалять любой репозиторий.
Ну как минимум проблема в следующем: добавишь поиск по regex - злоумышленники лишь подстроятся под это, нужно будет новое изменение вводить. Если так накидывать regex'ы то быстро наберется какой-то снежный ком разных проверок, которые рано или поздно ударят по нормальным репозиториям.
Я не говорю, что над этим не нужно работать, но решение проблемы чуть более комплексное, чем просто раз прогнать базу.
Если злоумышленники подстраиваются, то это проблема. Но кажется написать регулярку, которая ищет zip архивы или исполняемые файлы в readme, можно было давно. Всё зависит от желания менеджеров гитхаба и вычислительных ресурсов.
Можно предположить, что за 18 лет существования гитхаба у них не возникло такой бизнес задачи.
Но в схеме, о которой написано в этой статье, злоумышленники не подстраиваются. Они используют одинаковую схему уже 2 года и продолжают её использовать. В каждом из этих репозиториев также есть последний коммит, который называется "Update README.md". Я написал скрипт, который нашёл 10К таких репозиториев.
Паттерн поиска оказался настолько точным, что команда гитхаба удалила все эти репозитории. Вопрос в том, почему они больше ничего не сделали. Почему они не запустили скрипт, не написали свой скрипт, не провели анализ репозиториев вручную.
Так вроде в этом и смысл любой защиты? Заставить подстраиваться так долго, чтобы злоумышленник (по крайней мере большая часть из них) - сочли это неразумной тратой времени.
Наткнулся на статью и появился такой вопрос от новичка в этой сфере, так как я недавно начал пользоваться гитом. Есть ли какие-либо универсальные способы проверки репозитория на подозрительные файлы? Кроме скачивания исходного кода и загрузки его на VirusTotal, конечно.
Универсальные способы известны и авторам троянов.
Скачай репу и повелевай LLM агенту проверить. Для этого специально сконфигурируй агента, у которого права только на чтение и только внутри репы.
Универсальнее способа нет и не будет. Раньше LLM станет достойным антивирусом, чем напишут надёжный антивирус для Linux.
Есть ли какие-либо универсальные способы проверки репозитория на подозрительные файлы? Кроме скачивания исходного кода и загрузки его на VirusTotal, конечно.
Вы же сами и указали универсальный способ.
Всё что нужно - показывать дату и результат проверки архива на virustotal прямо на странице github. А там уж пусть человек принимает решение - хочет он это скачать или нет.
Очень скромные и прилежные мошенники, звёзды не накручены, репозиторий внешне выглядит адекватно, ридми опрятный. Я уже привык видеть тонны одинаковых "FC26 Mod Manager" с сотнями звёзд и единственным файлом с кодом main.py или manager.py, внутри которого сиротливая строчка print('супер тест репозитория') (да, у большинства одна и та же структура и одна и та же несчастная строка кода). Кстати, у последних больше шансов улизнуть от проверок сторонними антивирус решениями - ссылка на скачивание обычно ведёт на контент соседнего репозитория, а скан текущего ничего не даст, это ведь просто тест репозитория.
Репозитории выглядят адекватно, потому что они копируют всю историю коммитов из чужих репозиториев. При этом сохраняется даже список контрибьюторов. Также они каждые несколько часов отправляют коммит с единственным изменением в readme файле. Таким образом эти репозитории всегда показываются сверху в результатах поиска, потому что обновлялись недавно.
Чем вообще занимается служба безопасности GitHub?