Как стать автором
Обновить

Комментарии 67

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

Кто-то использует Github как архив, и актуальная локальная копия может быть далеко не у всех и не для всего.

Тогда они получили ценный урок.
Тоже не понял этот момент. Может репозиторий при этом настроен как деплой и сервисы связанные поломались?

Правда, чтобы это стало проблемой, нужно как минимум отобрать доступ у автора, а тот должна восстановить поддержка сервиса.
Там еще утечка упоминается, для приватных может быть критично… Но какой процент будет у пересечения множества приватных проектов и слабых паролей? Так что да, странно.
Он не удалить угрожает, а will make your code public or use them otherwise
НЛО прилетело и опубликовало эту надпись здесь
Нет, угрожает что сделает приватные репы публичными. Еще предстоит выяснить имеется ли у него к ним доступ, но как говорится чем черт не шутит :/
Для гита эта угроза (конечно, только для приватных реп) гораздо страшнее чем удаление, так-что git push -f с любой машины где есть копия репы и все данные опять на месте.

недавно работал, есть практика сваливать самый условно-полезный или просто интересный код в публичные репозитории с целью не потерять его со временем.

Я мало знаком с системами контроля версий, но думал, что они хранят все изменения и можно откатиться в любой момент на любую версию. Как можно полностью всё удалить?

Удалить сам репозиторий кода, исходники и папочку .git с сервера.

И все репозитории на машинах всех разработчиков, кто клонировал этот репозиторий.

У пары моих проектов они безусловно есть где-то на моих машинах, но мне проще выкачать из гита их, если понадобятся, а не искать на устройствах. Возможно у некоторых проектов из этого списка такая же история.

Еще не стоит забывать про фактор срочности.


Если на ком-то из разработчиков лежит ответственность, в особенности, если репозиторий еще и с CI/CD, автоматически развертывающим ветки, мышление может значительно атрофироваться под действием воображения, искусно растрачивающем ресурсы на пребор каждого из предметов, которые изрядно раззадоренный выходными босс мог бы засунуть "туда" с примерным анализом ущерба проникновения.


Полагаю, 570$ не самая большая цена, которую можно заплатить в подобной ситуации.

Полагаю, 570$ не самая большая цена, которую можно заплатить в подобной ситуации.

Давайте я украду у Вас что-нибудь ценное, затребую выкуп, а Ваше возмущение буду парировать фразой «что это не слишком большая цена в такой ситуации...»? Нравится?
1) Удалить все ветки и теги.

2) Установить master в новый коммит с этим сообщением.

Фактически, все объекты останутся в репозитории, но их восстановление может оказаться тем еще геморроем.

В локальной репе разраба по рефлогу откатиться можно после случайного гит пулл/фетч, а потом уже git push -f по всем бранчам и тегам

В локальной репе разраба

Если она есть, то все очень просто, да. А если вдруг нет?

А как они коммитили в эти репы, не имея локальной копии? Странная ситуация, либо репы древние/неактивные (последний коммит был год назад, например)

А как они коммитили в эти репы, не имея локальной копии?

Такая ситуация не исключена.

В GL можно коммитить прямо через веб-интерфейс
НЛО прилетело и опубликовало эту надпись здесь
Рефлог же есть. И на github тоже есть. Как-то так:
curl -u api.github.com/repos:owner/:repo/events
И с ним тоже можно колдовать и по нему восстанавливаться. Чтобы почистить нужно «housekeeping» (или как он там называется) выполнить, который тоже далеко не сразу после выполняется и не всё чистит (чтобы сам себе злой Буратино не мог всё легко поехрить).

Рефлог он локальный. Вы не можете выкачать с гитхаба коммит, на который не ссылается ни одна голова в репозитории.

Я именно про рефлог сервера гитхаба. И коммиты без ссылок доступны по ссылкам вида (например):


https://api.github.com/repos/<user>/<repo>/git/commits/<hash>

Восстановление репозитория гитхаба после грандиозного факапа с push --force весьма популярная беда и хорошо гуглится.

Но вы не можете выкачать по ssh эти коммиты. Только через api

Можно переписать историю если есть ключ с правами на запись, гитхаб никак не защищает от push --force, а вот гитлаб должен защитить master. Ну а имея пароль можно делать все что угодно.

История про тех кто не делает бэкапы, можно же элементарно репы на впс пуллить.

Защиту мастера можно отключить, иначе разработка превратится в ад, что коммиты в мастере не подправить. Надо редко, но когда надо, приходится убирать защиты.

Всё же такие ситуации — исключительные и стоит возвращать защиту ветки обратно после всех проведенных действий.

Да, конечно. Защита от случайных катастрофическмх действий должна быть, главное, чтобы кнопку отключения, если что, не убирали вовсе.

Рефлог и доступ к старым комитам на сервере тоже есть.
как?
Есть вариант с откатом, например, до самого первого комита
Насколько я понимаю, восстановить последущие уже нельзя никак, потому что их просто нет в истории комитов
git reset --hard <хэш>
git push -f origin <ветка>
Но и восстанавливается история точно так же…

Можно "форспушнуть", у приличных людей такая практика считается моветоном, Линус Торвальдс за такое сечёт розгами ярко-выраженного социального неодобрения.

Хм… эт что получается.
Гитхаб не делает бэкапы для восстановления данных в случае каких-либо «непредвиденных» ситуаций?
В Гитхаб нет «защиты» от банального брутфорса?

Как-то все слишком просто.
А что, на сервисе, в котором за секунду обрабатываются сотни запросов на изменения, можно иметь бэкап, актуальный на момент взлома?
Можно, никто ж не запрещает.
Коммент на Хабре оставить, очевидно же)
например: habr.com/ru/post/140031

или в гугл: DFS, NFS и т.п.
Это не бэкап.
Ну не на момент взлома, но, как я понимаю, больше всех пострадали как раз неактивные репозитории, кода которых нет на машинах разработчиков ввиду давности разработки. А для них что вчерашний, что прошлого месяца бэкап вполне сойдет. Я бы на месте гитхаба просто повесил всем кнопку «поднять из бэкапа» и предупреждение, за какую дату бэкап.
Это если есть возможность вытащить из общего бэкапа пользовательский. А так его задача (если его делает администрация сервиса) — обеспечить быстрое и удобное аварийное восстановление сервиса в целом, а не данных конкретного пользователя.
Насколько я знаю, на GitHub отключен git gc и они никогда не чистят reflog, так что история всех репозиториев полностью сохраняется. Если что-то было запушено, то оно остаётся на серверах GitHub. Так что у них есть техническая возможность восстановить любую ветку.

Будут ли они это делать — для людей, которые не платят им денег — другой вопрос. Но написать в службу поддержки и попробовать можно.
Чистят, но очень редко, неглубоко и только для больших репозиториев. Там даже пипка, помнится, где-то была, на случай, если ты с бодуна закомитил 100500 гигабайт, а потом опомнился. Но пипка мудра и чистит только явные косяки и ОЧЕНЬ большие комиты.
Взломщик удалил код из тысяч 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/

Интересно, откуда ей знать, какие пароли у пользователей?

А кто мешает, даже если пароли соленые, запустить брут на перебор хешей на серверах ГХ на аккаунты, которые пострадали, и хозяева обратились, чтобы проверить гипотезу о слабости паролей?
К тому же, еще возможен вариант, что по логу видели, что ко всем пострадавшим аккаунтам была попытка брута. В таком случае тоже очевидно, что пароли были слабые.
вапрос — нафига хранить свой, радной, ламповый код — где-то, контроль над чем не имеешь? ну много разрабов — ок — челы схалявили на свою базу — а тут так сразу и прикрылось…
а где хранить? У меня хард ssd не резиновый
Блин, это же распределенная система, да где угодно и сколько угодно копий своего добра)

Читал в свое время эту историю, насколько я помню, "взломщик" в конце концов вышел на связь, изложенная им версия взлома такая — люди тем или иным образом выкладывали свой .git/config с паролями в htdocs.

То есть это как на банковской карте ПИН-код фломастером написать? Понятно…
Кроме того, эти разработчики удаляли токены доступа для приложений, которые не использовались в течение длительного времени.

В чем опасность? Может имелось ввиду, что наоборот НЕ удаляли токены?
Тоже не понял. Видимо автор слишком торопился поелиться новостью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости

Истории