На днях стало известно о том, что сотни разработчиков пострадали от действий неизвестного взломщика. Злоумышленник каким-то образом получил доступ к репозиториям пользователей хостинг-сервисов Git (GitHub, Bitbucker, GitLab), удалил хранящийся там код и теперь требует деньги за восстановление данных.
Пока что способ, который применялся злоумышленником для взлома репозиториев остается неизвестным. Вместо удаленных данных злоумышленник оставляет сообщение с требованием выплаты выкупа в размере 0,1 биткоина ($570 по текущему курсу). В сообщении говорится о том, что код сохранен и находится на подконтрольном взломщику сервере. Данные пострадавших разработчиков будут окончательно удалены в том случае, если выкуп не будет получен в течение 10 дней.
Насколько можно понять, пострадавшие уже начали выплачивать требуемую сумму. Ресурс BitcoinAbuse.com, занимающийся анализом определенных биткоин-адресов, за последние 24 часа для указанного злоумышленником биткоин-кошелька было зафиксировано несколько десятков транзакций.
Некоторые пользователи, пострадавшие в результате атаки, заявили, что их пароль к учетной записи был не слишком надежным. Кроме того, эти разработчики удаляли токены доступа для приложений, которые не использовались в течение длительного времени. Возможно, киберпреступник просканировал сеть с целью выявления файлов конфигурации Git. Данные файлов помогли злоумышленнику добиться поставленной цели.
Ситуацию уже успели прокомментировать представители GitLab. Директор по безопасности хостинга Кэти Ванг заявила, что расследование проблемы продолжается уже больше суток. Так, пользователей сервиса, которые пострадали в результате действий злоумышленника предупредили о проблеме. Ванг подтвердила слова пострадавших, рассказав о том, что они использовали недостаточно надежные пароли.
В качестве рекомендации пользователям предложили использовать менеджеры паролей, а также двухфакторную идентификацию, что помогает предотвратить возникновение подобных проблем в будущем.
GitHub блокирует некоторые учетные записи до выяснения обстоятельств. «GitHub заморозил мой аккаунт на время расследования, надеюсь, я смогу получить свою учетную запись обратно уже сегодня», — заявил один из пользователей сервиса.
Пострадавшие пользователи обсуждают происшествие здесь, а возможное решение предлагается на StackExchange.
Стоит отметить, что злоумышленник не удаляет весь код, как оказалось, он меняет заголовки Git-коммитов. Это означает возможность восстановления кода пострадавшими, правда, не в 100% случаев.
Комментарии (66)
Geograph
05.05.2019 13:26+1Я мало знаком с системами контроля версий, но думал, что они хранят все изменения и можно откатиться в любой момент на любую версию. Как можно полностью всё удалить?
tmin10
05.05.2019 13:27+1Удалить сам репозиторий кода, исходники и папочку .git с сервера.
keydon2
05.05.2019 13:37+1И все репозитории на машинах всех разработчиков, кто клонировал этот репозиторий.
tmin10
05.05.2019 17:07У пары моих проектов они безусловно есть где-то на моих машинах, но мне проще выкачать из гита их, если понадобятся, а не искать на устройствах. Возможно у некоторых проектов из этого списка такая же история.
Lexicon
06.05.2019 05:08Еще не стоит забывать про фактор срочности.
Если на ком-то из разработчиков лежит ответственность, в особенности, если репозиторий еще и с CI/CD, автоматически развертывающим ветки, мышление может значительно атрофироваться под действием воображения, искусно растрачивающем ресурсы на пребор каждого из предметов, которые изрядно раззадоренный выходными босс мог бы засунуть "туда" с примерным анализом ущерба проникновения.
Полагаю, 570$ не самая большая цена, которую можно заплатить в подобной ситуации.
maisvendoo
06.05.2019 07:10Полагаю, 570$ не самая большая цена, которую можно заплатить в подобной ситуации.
Давайте я украду у Вас что-нибудь ценное, затребую выкуп, а Ваше возмущение буду парировать фразой «что это не слишком большая цена в такой ситуации...»? Нравится?
tyderh
05.05.2019 13:551) Удалить все ветки и теги.
2) Установить master в новый коммит с этим сообщением.
Фактически, все объекты останутся в репозитории, но их восстановление может оказаться тем еще геморроем.
F0iL
05.05.2019 14:08git push --force, например.
восстановить можно будет, но только имея доступ к ФС где лежала репа и если не делали git gc, да и то очень хлопотно.Sap_ru
05.05.2019 18:11Рефлог же есть. И на github тоже есть. Как-то так:
curl -u api.github.com/repos:owner/:repo/events
И с ним тоже можно колдовать и по нему восстанавливаться. Чтобы почистить нужно «housekeeping» (или как он там называется) выполнить, который тоже далеко не сразу после выполняется и не всё чистит (чтобы сам себе злой Буратино не мог всё легко поехрить).
fshp
05.05.2019 19:06+1Рефлог он локальный. Вы не можете выкачать с гитхаба коммит, на который не ссылается ни одна голова в репозитории.
Sap_ru
05.05.2019 20:28Я именно про рефлог сервера гитхаба. И коммиты без ссылок доступны по ссылкам вида (например):
https://api.github.com/repos/<user>/<repo>/git/commits/<hash>
Восстановление репозитория гитхаба после грандиозного факапа с push --force весьма популярная беда и хорошо гуглится.
Barnaby
05.05.2019 14:19Можно переписать историю если есть ключ с правами на запись, гитхаб никак не защищает от push --force, а вот гитлаб должен защитить master. Ну а имея пароль можно делать все что угодно.
История про тех кто не делает бэкапы, можно же элементарно репы на впс пуллить.tmin10
05.05.2019 17:08Защиту мастера можно отключить, иначе разработка превратится в ад, что коммиты в мастере не подправить. Надо редко, но когда надо, приходится убирать защиты.
androidovshchik
06.05.2019 05:55Есть вариант с откатом, например, до самого первого комита
Насколько я понимаю, восстановить последущие уже нельзя никак, потому что их просто нет в истории комитов
git reset --hard <хэш>
git push -f origin <ветка>
unclechu
08.05.2019 02:23Можно "форспушнуть", у приличных людей такая практика считается моветоном, Линус Торвальдс за такое сечёт розгами ярко-выраженного социального неодобрения.
orion76
05.05.2019 13:57Хм… эт что получается.
Гитхаб не делает бэкапы для восстановления данных в случае каких-либо «непредвиденных» ситуаций?
В Гитхаб нет «защиты» от банального брутфорса?
Как-то все слишком просто.lubezniy
05.05.2019 14:04А что, на сервисе, в котором за секунду обрабатываются сотни запросов на изменения, можно иметь бэкап, актуальный на момент взлома?
orion76
05.05.2019 14:13Можно, никто ж не запрещает.
lubezniy
05.05.2019 17:37Запрещать не запрещает, а сделать его как?
Stas911
06.05.2019 04:50Ну не на момент взлома, но, как я понимаю, больше всех пострадали как раз неактивные репозитории, кода которых нет на машинах разработчиков ввиду давности разработки. А для них что вчерашний, что прошлого месяца бэкап вполне сойдет. Я бы на месте гитхаба просто повесил всем кнопку «поднять из бэкапа» и предупреждение, за какую дату бэкап.
lubezniy
06.05.2019 07:26Это если есть возможность вытащить из общего бэкапа пользовательский. А так его задача (если его делает администрация сервиса) — обеспечить быстрое и удобное аварийное восстановление сервиса в целом, а не данных конкретного пользователя.
ilammy
05.05.2019 14:24Насколько я знаю, на GitHub отключен git gc и они никогда не чистят reflog, так что история всех репозиториев полностью сохраняется. Если что-то было запушено, то оно остаётся на серверах GitHub. Так что у них есть техническая возможность восстановить любую ветку.
Будут ли они это делать — для людей, которые не платят им денег — другой вопрос. Но написать в службу поддержки и попробовать можно.Sap_ru
05.05.2019 18:15Чистят, но очень редко, неглубоко и только для больших репозиториев. Там даже пипка, помнится, где-то была, на случай, если ты с бодуна закомитил 100500 гигабайт, а потом опомнился. Но пипка мудра и чистит только явные косяки и ОЧЕНЬ большие комиты.
apapacy
05.05.2019 14:51Какой бы ни был слабый пароль. Если есть простой подсчет неудачных попыток с последующей блокировкой то перебрать даже все двухбуквеннып пароли не получится. Это ж кто-то брутфорсил месяцами репы со скоростью сотниизапросовивсекунду и это не было выявлено.
Второй вариант это как-то получили доступ к хэшам паролей.
Ну или тоже самое плюс слив информацииAlexey2005
05.05.2019 15:17Ну в принципе можно перебирать не пароли, а аккаунты. Взять штуки три самых распространённых паролей и пробовать ими все репы подряд. На каждый реп будет приходиться не более трёх попыток, но при достаточном количестве репов хотя бы несколько сломается.
fshp
05.05.2019 19:10Извините, но этот пароль уже используется пользователем Alexey2005. Придумайте другой пароль.
SergeiMinaev
05.05.2019 16:17+2Ванг подтвердила слова пострадавших, рассказав о том, что они использовали недостаточно надежные пароли.
Интересно, откуда ей знать, какие пароли у пользователей? Лично спрашивала или?Cerberuser
05.05.2019 17:04По ссылке на StackExchange из статьи есть одно предположение:
It happened because .git/config includes the remote URLs and people added username:password in it
Понятно, что в реальных условиях такого быть не должно, но если всё же произошло — собственно, вот она, возможность (для владельцев сервера, разумеется).mayorovp
05.05.2019 17:55А откуда им знать что у людей в .git/config лежит? Этот же файл никуда не передается…
DerRotBaron
05.05.2019 20:39+1Если лежит на плохо настроенном http-сервере, то ещё как передаётся.
Например, так: https://habr.com/ru/post/422725/
algotrader2013
05.05.2019 18:34Интересно, откуда ей знать, какие пароли у пользователей?
А кто мешает, даже если пароли соленые, запустить брут на перебор хешей на серверах ГХ на аккаунты, которые пострадали, и хозяева обратились, чтобы проверить гипотезу о слабости паролей?
К тому же, еще возможен вариант, что по логу видели, что ко всем пострадавшим аккаунтам была попытка брута. В таком случае тоже очевидно, что пароли были слабые.
dimitry78
05.05.2019 18:55вапрос — нафига хранить свой, радной, ламповый код — где-то, контроль над чем не имеешь? ну много разрабов — ок — челы схалявили на свою базу — а тут так сразу и прикрылось…
androidovshchik
06.05.2019 06:13Блин, это же распределенная система, да где угодно и сколько угодно копий своего добра)
KanuTaH
05.05.2019 20:20Читал в свое время эту историю, насколько я помню, "взломщик" в конце концов вышел на связь, изложенная им версия взлома такая — люди тем или иным образом выкладывали свой .git/config с паролями в htdocs.
GLeBaTi
06.05.2019 13:24Кроме того, эти разработчики удаляли токены доступа для приложений, которые не использовались в течение длительного времени.
В чем опасность? Может имелось ввиду, что наоборот НЕ удаляли токены?
Sirion
Лол. Возможно, я чего-то не понимаю, но… Взломщик удалил код из отдельных репозиториев распределённой системы контроля версий и чего-то там требует? В то время как у каждого, кто с этими репозиториями недавно работал, должна быть полноценная свежая копия?
KvanTTT
Кто-то использует Github как архив, и актуальная локальная копия может быть далеко не у всех и не для всего.
Sirion
Тогда они получили ценный урок.
MonkAlex
Тоже не понял этот момент. Может репозиторий при этом настроен как деплой и сервисы связанные поломались?
Правда, чтобы это стало проблемой, нужно как минимум отобрать доступ у автора, а тот должна восстановить поддержка сервиса.
olekl
Там еще утечка упоминается, для приватных может быть критично… Но какой процент будет у пересечения множества приватных проектов и слабых паролей? Так что да, странно.
AlexMoskvichev
Он не удалить угрожает, а will make your code public or use them otherwise
sumanai
Он сделает публичный код ещё публичнее?
Хотя владельцы приватных репозиториев будут не рады.
Acuna
Нет, угрожает что сделает приватные репы публичными. Еще предстоит выяснить имеется ли у него к ним доступ, но как говорится чем черт не шутит :/
playnet
Для гита эта угроза (конечно, только для приватных реп) гораздо страшнее чем удаление, так-что git push -f с любой машины где есть копия репы и все данные опять на месте.
unclechu
недавно работал, есть практика сваливать самый условно-полезный или просто интересный код в публичные репозитории с целью не потерять его со временем.