Комментарии 67
Лол. Возможно, я чего-то не понимаю, но… Взломщик удалил код из отдельных репозиториев распределённой системы контроля версий и чего-то там требует? В то время как у каждого, кто с этими репозиториями недавно работал, должна быть полноценная свежая копия?
Кто-то использует Github как архив, и актуальная локальная копия может быть далеко не у всех и не для всего.
Тоже не понял этот момент. Может репозиторий при этом настроен как деплой и сервисы связанные поломались?
Правда, чтобы это стало проблемой, нужно как минимум отобрать доступ у автора, а тот должна восстановить поддержка сервиса.
Правда, чтобы это стало проблемой, нужно как минимум отобрать доступ у автора, а тот должна восстановить поддержка сервиса.
Там еще утечка упоминается, для приватных может быть критично… Но какой процент будет у пересечения множества приватных проектов и слабых паролей? Так что да, странно.
Он не удалить угрожает, а will make your code public or use them otherwise
Для гита эта угроза (конечно, только для приватных реп) гораздо страшнее чем удаление, так-что git push -f с любой машины где есть копия репы и все данные опять на месте.
недавно работал, есть практика сваливать самый условно-полезный или просто интересный код в публичные репозитории с целью не потерять его со временем.
Удалить сам репозиторий кода, исходники и папочку .git с сервера.
И все репозитории на машинах всех разработчиков, кто клонировал этот репозиторий.
У пары моих проектов они безусловно есть где-то на моих машинах, но мне проще выкачать из гита их, если понадобятся, а не искать на устройствах. Возможно у некоторых проектов из этого списка такая же история.
Еще не стоит забывать про фактор срочности.
Если на ком-то из разработчиков лежит ответственность, в особенности, если репозиторий еще и с CI/CD, автоматически развертывающим ветки, мышление может значительно атрофироваться под действием воображения, искусно растрачивающем ресурсы на пребор каждого из предметов, которые изрядно раззадоренный выходными босс мог бы засунуть "туда" с примерным анализом ущерба проникновения.
Полагаю, 570$ не самая большая цена, которую можно заплатить в подобной ситуации.
1) Удалить все ветки и теги.
2) Установить master в новый коммит с этим сообщением.
Фактически, все объекты останутся в репозитории, но их восстановление может оказаться тем еще геморроем.
2) Установить master в новый коммит с этим сообщением.
Фактически, все объекты останутся в репозитории, но их восстановление может оказаться тем еще геморроем.
Рефлог же есть. И на github тоже есть. Как-то так:
curl -u api.github.com/repos:owner/:repo/events
И с ним тоже можно колдовать и по нему восстанавливаться. Чтобы почистить нужно «housekeeping» (или как он там называется) выполнить, который тоже далеко не сразу после выполняется и не всё чистит (чтобы сам себе злой Буратино не мог всё легко поехрить).
curl -u api.github.com/repos:owner/:repo/events
И с ним тоже можно колдовать и по нему восстанавливаться. Чтобы почистить нужно «housekeeping» (или как он там называется) выполнить, который тоже далеко не сразу после выполняется и не всё чистит (чтобы сам себе злой Буратино не мог всё легко поехрить).
Рефлог он локальный. Вы не можете выкачать с гитхаба коммит, на который не ссылается ни одна голова в репозитории.
Я именно про рефлог сервера гитхаба. И коммиты без ссылок доступны по ссылкам вида (например):
https://api.github.com/repos/<user>/<repo>/git/commits/<hash>Восстановление репозитория гитхаба после грандиозного факапа с push --force весьма популярная беда и хорошо гуглится.
Можно переписать историю если есть ключ с правами на запись, гитхаб никак не защищает от push --force, а вот гитлаб должен защитить master. Ну а имея пароль можно делать все что угодно.
История про тех кто не делает бэкапы, можно же элементарно репы на впс пуллить.
История про тех кто не делает бэкапы, можно же элементарно репы на впс пуллить.
Есть вариант с откатом, например, до самого первого комита
Насколько я понимаю, восстановить последущие уже нельзя никак, потому что их просто нет в истории комитов
git reset --hard <хэш>
git push -f origin <ветка>
Насколько я понимаю, восстановить последущие уже нельзя никак, потому что их просто нет в истории комитов
git reset --hard <хэш>
git push -f origin <ветка>
Можно "форспушнуть", у приличных людей такая практика считается моветоном, Линус Торвальдс за такое сечёт розгами ярко-выраженного социального неодобрения.
Хм… эт что получается.
Гитхаб не делает бэкапы для восстановления данных в случае каких-либо «непредвиденных» ситуаций?
В Гитхаб нет «защиты» от банального брутфорса?
Как-то все слишком просто.
Гитхаб не делает бэкапы для восстановления данных в случае каких-либо «непредвиденных» ситуаций?
В Гитхаб нет «защиты» от банального брутфорса?
Как-то все слишком просто.
А что, на сервисе, в котором за секунду обрабатываются сотни запросов на изменения, можно иметь бэкап, актуальный на момент взлома?
Можно, никто ж не запрещает.
Ну не на момент взлома, но, как я понимаю, больше всех пострадали как раз неактивные репозитории, кода которых нет на машинах разработчиков ввиду давности разработки. А для них что вчерашний, что прошлого месяца бэкап вполне сойдет. Я бы на месте гитхаба просто повесил всем кнопку «поднять из бэкапа» и предупреждение, за какую дату бэкап.
Насколько я знаю, на GitHub отключен git gc и они никогда не чистят reflog, так что история всех репозиториев полностью сохраняется. Если что-то было запушено, то оно остаётся на серверах GitHub. Так что у них есть техническая возможность восстановить любую ветку.
Будут ли они это делать — для людей, которые не платят им денег — другой вопрос. Но написать в службу поддержки и попробовать можно.
Будут ли они это делать — для людей, которые не платят им денег — другой вопрос. Но написать в службу поддержки и попробовать можно.
Взломщик удалил код из тысяч Git-репозиториев.
Откуда такие цифры?
A GitHub search reveals that at least 392 GitHub repositories have been ransomed, so far.
Ванг подтвердила слова пострадавших, рассказав о том, что они использовали недостаточно надежные пароли.
Это она по хешу паролей определила? Или хранят plain?
Какой бы ни был слабый пароль. Если есть простой подсчет неудачных попыток с последующей блокировкой то перебрать даже все двухбуквеннып пароли не получится. Это ж кто-то брутфорсил месяцами репы со скоростью сотниизапросовивсекунду и это не было выявлено.
Второй вариант это как-то получили доступ к хэшам паролей.
Ну или тоже самое плюс слив информации
Второй вариант это как-то получили доступ к хэшам паролей.
Ну или тоже самое плюс слив информации
Ну в принципе можно перебирать не пароли, а аккаунты. Взять штуки три самых распространённых паролей и пробовать ими все репы подряд. На каждый реп будет приходиться не более трёх попыток, но при достаточном количестве репов хотя бы несколько сломается.
Извините, но этот пароль уже используется пользователем Alexey2005. Придумайте другой пароль.
Ванг подтвердила слова пострадавших, рассказав о том, что они использовали недостаточно надежные пароли.
Интересно, откуда ей знать, какие пароли у пользователей? Лично спрашивала или?
По ссылке на StackExchange из статьи есть одно предположение:
Понятно, что в реальных условиях такого быть не должно, но если всё же произошло — собственно, вот она, возможность (для владельцев сервера, разумеется).
It happened because .git/config includes the remote URLs and people added username:password in it
Понятно, что в реальных условиях такого быть не должно, но если всё же произошло — собственно, вот она, возможность (для владельцев сервера, разумеется).
А откуда им знать что у людей в .git/config лежит? Этот же файл никуда не передается…
Если лежит на плохо настроенном http-сервере, то ещё как передаётся.
Например, так: https://habr.com/ru/post/422725/
Интересно, откуда ей знать, какие пароли у пользователей?
А кто мешает, даже если пароли соленые, запустить брут на перебор хешей на серверах ГХ на аккаунты, которые пострадали, и хозяева обратились, чтобы проверить гипотезу о слабости паролей?
К тому же, еще возможен вариант, что по логу видели, что ко всем пострадавшим аккаунтам была попытка брута. В таком случае тоже очевидно, что пароли были слабые.
вапрос — нафига хранить свой, радной, ламповый код — где-то, контроль над чем не имеешь? ну много разрабов — ок — челы схалявили на свою базу — а тут так сразу и прикрылось…
Читал в свое время эту историю, насколько я помню, "взломщик" в конце концов вышел на связь, изложенная им версия взлома такая — люди тем или иным образом выкладывали свой .git/config с паролями в htdocs.
Кроме того, эти разработчики удаляли токены доступа для приложений, которые не использовались в течение длительного времени.
В чем опасность? Может имелось ввиду, что наоборот НЕ удаляли токены?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Взломщик удалил код из сотен Git-репозиториев. За восстановление он требует 0,1 биткоина