Опубликованы (https://matrix.org/blog/2019/04/11/security-incident/) новые подробности (https://github.com/matrix-org/matrix.org/issues/created_by/m...) про взлом инфраструктуры децентрализованной платформы обмена сообщениями Matrix, о котором сообщалось (https://www.opennet.dev/opennews/art.shtml?num=50501) утром. Проблемным звеном, через которое проникли атакующие была система непрерывной интеграции Jenkins, которая была взломана ещё 13 марта. Затем на сервере c Jenkins был перехвачен перенаправленный SSH-агентом вход одного из администраторов и 4 апреля атакующие получили доступ к другим серверам инфраструктуры.
При второй атаке сайт matrix.org был перенаправлен на другой сервер (matrixnotorg.github.io) через изменение параметров DNS, используя перехваченный при первой атаке ключ к API системы доставки контента Сloudflare. При пересборке содержимого серверов после первого взлома администраторы Matrix обновили только новые персональные ключи и упустили обновление ключа к Сloudflare.
В ходе второй атаки серверы Matrix остались нетронутыми, изменения ограничились только заменой адресов в DNS. В случае если пользователь уже сменил пароль после первой атаки, второй раз его менять не нужно. Но если пароль до сих пор не изменён, его нужно обновить как можно скорее, так как утечка базы с хэшами паролей подтверждена. В настоящий момента планируется инициировать процесс принудительного сброса пароля при следующем входе.Кроме утечки паролей также подтверждено попадание в руки атаковавших GPG-ключей, используемых для формирования цифровых подписей пакетов в Debian-репозитории Synapse и релизов Riot/Web. Ключи были защищены паролем. В настоящий момент ключи уже отозваны. Ключи были перехвачены 4 апреля, но с тех пор обновлений Synapse не выпускалось, но был релиз клиента Riot/Web 1.0.7, (предварительная проверка показала, что он не был скомпрометирован).
Атакующий разместил серию отчётов с подробностями атаки на GitHub, но они были удалены. Тем не менее, в архиве отчёты сохранились (https://archive.md/MfrjB).
URL: https://matrix.org/blog/2019/04/11/security-incident/
Новость: https://www.opennet.dev/opennews/art.shtml?num=50502
Где качнуть базу?
а что с ней полезного сделать-то можно? А, понял - ты свой пароль не можешь вспомнить? Да, такая же фигня :-(
Т.е. в матриксе крутили на х.ю самые обычные бестпрактисы. Молодцы, че
Это какие?
>самые обычныеОни же «очевидные любому» и «всем давно известные». Диванные специалисты по ИБ такие диванные…
наоборот же ж - сплошные best practices - ci, торчащий задницей наружу, ssh-ключи (ох как я это люблю и обожаю), логи, поди, хранил за них systemd, sudo su для любой ерунды, конфиги в git вместо svn (который, в отличие от git, писали умные люди, и который умеет checkout только подветки, равно как и хоть примитивную, но fine-grained авторизацию, не позволяющую, проломив один хост, ознакомиться с конфигами другого на халяву), обновления накатываются не по факту выпуска, а когда можно и есть время разбираться, почему все сдохло
- все ж так делают, вы чего.остальное - вонючее старперство и тормозит разработку.
>страх перед SSH-ключами
>svn
>sudo su
>страх перед публичными сетямиСразу видно большого специалиста по системному администрированию двух локалхостов с LA 0.01 в сети 192.168.0.0/24.
да-да, вот мы видим что наадминистрировали бесстрашные "специалисты" нелокалхостов, торчащих голой жопой в интернет да еще с претензиями на особую безопасТность своего продукта.А вы, гражданин, к сожалению просто неуловимый джо, и нафиг никому не сдались, поэтому пока наивно думаете что что-то умеете необычное и сокровенное.
>, конфиги в git вместо svnЭто ты серьезно, бро? :)
1) Полным конфигам - с ключами и прочим - вообще нечего делать в системе контроля версий. Только шаблоны с плейсхолдерами, а сами значения берутся из
2) На серверах, куда деплоятся эти конфиги, вообще не должно быть никаких репозиториев и доступа к нему. Деплоиться все должно с изолированного выделенного сервера. Тот, кто деплоит через git pull или svn up, должен гореть в аду.
Не дописал. :-)..берутся из secrets database, доступа к которой нет ниоткуда, кроме выделенного сервера для деплоя.
а поскольку для изменения любой ерунды нужно лезть на этот сервер - ты давно уже потерял счет учеткам и паролям имеющих туда доступ.Поэтому хакнуть его не представляет ни малейшей проблемы, после чего вся великая секьюрить превращается в тыкву.
> Тот, кто деплоит через git pull или svn up, должен гореть в аду.Горячо плюсую. Остальное, впрочем, тоже.
> Полным конфигам - с ключами и прочим - вообще нечего делать в системе контроля версийну действительно, зачем вам версионирование конфигов, новаяпапка2454
> Деплоиться все должно с изолированного выделенного сервера.
да-дад, паблик-ключиком с которым можно зайти куда угодно от рута. Вот так вы и победите.
собственно, шматрикс - уже подeбил.
А у меня НЕТ никакого "выделенного сервера", хакнув который или перехватив доступы допущенных, можно получить рутовый доступ ко всему, хвала ssh-agent'у и его форвардам, а так же незамутненным авторам ансимля.
Есть svn, но он доступен частями и местами, и знание одного пароля никак не поможет получить другой, это вам не гит, это еще почти нормальные люди придумали. А любая не-svn активность на той коробке - вызовет вопросы, кто ета, и что он вообще мог там забыть - учитывая полное отсутствие поводов туда заходить.И, заметьте, в отличие от модных стильных молодежных - я так живу уже лет десять.
А что не так с использованием ssh-ключей?
На самом деле в большинстве стартапов то же самое.
Помню, как-то один прожектманагер, когда я заикнулся о том, как делать авторизацию, заявил: «Как говорил X X-ич X-ов, когда речь заходит о безопасности, работа останавливается.» Кто такой этот хрен, которого он цитировал, я так и не выяснил, да и имя сразу же забыл, но имею основания полагать, что такая точка зрения весьма распространена, и вертеть на х.ю вопросы безопасности как раз-таки входит в бестпрактисы дефективных манагеров.
ну в целом-то не врал - работу приходится останавливать, все переделывать как надо, а не как удобно разработчикам, и их потом п-ть, чтобы после жесткого внушения что использовать для упрощения себе жизни sh скопированный в cgi/ - нехорошо, не обнаружить через час exec("/bin/sh"); уже в коде на единственноправильном язычке. Удобно уложенный в корень сайта с неприметным именем shell (по сути реальный случай - причем из тех времен, когда это действительно было можно делать, потому что менеджеры были - эффективные, без кавычек, из тех что поднимали бизнес с нуля без копейки в кармане, и хорошо понимали, чем грозит такой файлик) - а у них от этого фрустрация и опускаются руки.и нет, в кговавом ентер-прайсе точно такая же фигня творится, правда, там обычно, в отличие от хипста-стартапа, есть периметр безопасности, худо-бедно предотвращающий совсем уж лоховские истории типа торчания дырявого и не подлежащего апгрейду из-за миллиона плагинов, включая написанные кем-то давно уволившимся, ci в паблик.
вот сегодня например у нас заметили что пинг запретили ;-)
> работу приходится останавливать, все переделывать как надоЭто было начало проекта, шанс сразу сделать всё как надо, но нет.
"любой проект начинают как минимум двое - один из них общительный, другой умный. Первый потом обычно становится CEO, второй CTO."
А админа они нанимают лет через пять, иногда уже после того как пару раз поломают.Ну и учтите еще что это в изрядной степени community проект, а такие вообще сложно удержать под контролем. Кто-нибудь рано или поздно продалбывает учетку.
Я-то свой пароль от корпоративных серверов могу на бумажке к монитору клеить - если кто-то уже читает эту бумажку, и при этом знает, куда это набирать - тут уже все равно ловить нечего.
Но там на входе злой дядька с пистолетом, поэтому больше бояться надо казачков засланных. А у тех есть еще тыщаодин способ тот пароль спереть, даже если я его набираю из головы, трижды оглянувшись вокруг.
>Ну и учтите еще что это в изрядной степени community проект, а такие вообще сложно удержать под контролем.Особенно если разворачивать в нем системы предназначенные для кровавого энтерпрайза.
Чтобы держать под контролем ненужно сущности плодить с которыми совладать не можешь.
Проблема в том, что разработчикам надо работать, а если (например, ожегшись на молоке) назначают рулить системой какого-нибудь упоротого сисадмина, который знает только "не пущать", то начинается как раз: svn, freebsd, ещё какая-нибудь экзотика из 90-х (времён, когда у админа ещё стоял), а всего остального он не знает, и запрещает как небезопасное.Ответ гугла на это — концепция SRE, когда инфраструктурой рулят полуразработчики, которые не воюют с разрабами, а понимают их боль, но и не забивают и на безопасность при этом. SRE в числе самых высокооплачиваемых ребят, по последнему опросу на StackOverflow (дороже почти всех разработчиков).
Ну и чем svn и FreeBSD мешает работать вашим разработчикам?>Ответ гугла на это — концепция SRE, когда инфраструктурой рулят полуразработчики, которые не воюют с разрабами, а понимают их боль, но и не забивают и на безопасность при этом. SRE в числе самых высокооплачиваемых ребят, по последнему опросу на StackOverflow (дороже почти всех разработчиков).
Гугл это триллионная мегакорпорация ответ которой мало подходит остальным, и темболее среднему и малому бизнесу и уж тем более небольшому сообществу.
Вот это взрыв из прошлого, понимаю…
А как Jenkins мог такую дыру раскрыть? Он же на джаве, буфер там переполниться не мог, RCE почти невероятно. Как?
В любой плаг сажаешь троя и имеешь кого хочешь.
Какой маленький, какой наивный…
https://jenkins.io/security/advisories/
https://wp-content.bluebus.com.br/wp-content/uploads/2014/08...// другой Аноним
Тут бы помог только язык, который принципиально не позволяет читать файлы. Тогда бы файлы ключей утечь не смогли бы. Но и систему сборки на нем написать было бы трудно.
да ладно, для сборки не надо читать файлы, их надо писать ;-)
best practics
ssh agent на сервере.
То был форвардинг агента с админской машины на промежуточный сервер. Но от того не легче.
ничего что это дефолтная настройка sshd?
В том и беда. Как и всякие IdentitiesOnly.
Вот кстати да.
ssh изкоробочный брешь сам по себе.
Заморочишься настроить, все как надо едет но зачем когда есть прекрасный teleport и тому подобные вещи которые из коробки едут как надо.
нет агента - нет проблемы.
Ну и ключ должен быть не один на все, а индивидуальный для каждого, и с ограничением, откуда и кто может им ходить (и нет, ни разу не рут).Хотя сама концепция "спер ключ - получил все" - глубоко уродлива сама по себе. Интересно, когда ssh научится проверять _одновременно_ ключи и пароли? Никогда или лет через сто?
Вангую за никогда - это ж сломает нахрен концепцию чудо-сервера-с-конфигами, с доступом ко всему, так любимую девляпсами.
> Интересно, когда ssh научится проверять _одновременно_ ключи и паролиА он уже давно умеет 2FA. Но дремучие админы локалхоста об этом не догадываются.
>это ж сломает нахрен концепцию чудо-сервера-с-конфигами,Это сломает и концепцию одного супер-админа. Придется ведь долго-долго каждый сервер ручками настраивать и держать пароли и конфиги ко всем тысячам машин в голове. Ведь configuration management - зло и автоматизация не нужна.
>с доступом ко всему, так любимую девляпсами.У "девляпсов" уже давно KMS и 2FA везде.
>Ну и ключ должен быть не один на все, а индивидуальный для каждого, и с ограничением, откуда и кто может им ходитьИ еще для каждого сервера свой =). В итоге у нас будет
X серверов x Y пользователей x Z источников подключения. Конечно же это нужно делать вручную ибо автоматизация зло и дыра в инфраструктуре. Можно будет сразу профиль организации поменять на "SSH key management".
я не разрешаю автоматом деплоитьтолько собирать и заливать на продакшен от имени не привелигированного пользователя
а потом накатывать от имени рута вручную с помощью скрипта, попутно наблюдая за процессом
может кто-то думает иначе, но мне так как-то спокойнее
>Интересно, когда ssh научится проверять _одновременно_ ключи и пароли? Никогда или лет через сто?Лет 20 как умеет, но седобородые админы не умеют
Зато секурность.
>Ещё одной проблемой было хранение всех файлов конфигурации в Git, что позволяло оценить настройки других хостов при взломе одного из них.То есть предлагалось следовать подходу security through obscurity?
для закрытых от внешнего мира систем это прекрасно работает.
Или как минимум затягивает взлом достаточно, чтобы успеть заметить проблему вовремя.
>>Ещё одной проблемой было хранение всех файлов конфигурации в Git, что позволяло оценить настройки других хостов при взломе одного из них.
>То есть предлагалось следовать подходу security through obscurity?Это конфигурации, но не токены-пароли-ключи. Насколько понял. Руками сервера сегодня уже никто не админит, всегда конфиги лежат в Гит, так и должно быть.
К ним в инфраструктуру зайти можно из инета из кафе. Вот это чисто конкретно нарушение.
>всегда конфиги лежат в Гит, так и должно быть.65wat?
Ааа... а я то думал, зачем гит нужен...
Смузи-стайл воодружать систему контроля версий, вместо perl/bash скрипта и diff-а?
Добрый прохожий ещё попался...
Я бы сказал - на редкость. Дефейс и конструктивная критика вместо трояна в релизах...
И наверняка он ранее пылался им указать на недостатки. Но матриксовцы его замечания проигнорировали.
он наверное уже в курсе, что там много не намайнишь, с полутора-то фриками пользователями.
Справедливости ради, отчёты хакера удалены вместе с его аккаунтом, а не разработчиками сабжа.
им достаточно было просто пожаловаться, работящие индусы все сделали за них ;-)
Впрочем, пожаловаться мог и любой бдительный гражданин - совершенно не понимаю хакеров, выкладывающих подобное на гитхап вместо нормальных хостов.
Лол, и каждый раз повторяются одни и те же слова "следовало использовать двухфакторную аутентификацию". Помнится в череде "взломов" NPM - тоже самое.
Правильно! Передайте все ключи сотовым операторам сразу! :)
ну не ssh же ж на самом же деле патчить?
TOTP или FIDO в помощь
Кроме кода по SMS есть куча других возможных факторов.
> Правильно! Передайте все ключи сотовым операторам сразу! :)U2F, FIDO\WebAuthn уже давно поддерживается в Хроме и ФФ, остальные браузеры на подходе (даже Сафари). Было бы желание.
Спасибо за новость - узнал, что есть такой проект ... чтобы держаться подальше и другим не советовать.
И от Linux впридачу.
> узнал, что есть такой проект ... чтобы держаться подальше и другим не советовать.Как раз теперь можно ожидать, что проект, наученный добрым хакером, начнет уделять больше внимания безопасности инфраструктуры. Но вы пользуйтесь каким-нибудь проектом, которому это всё ещё предстоит. И другим советуйте.
Я не понимаю , вообще о какой безопасности в таких проектах может идти речь ??
Всегда есть вероятность, что внутри найдется предатель, коий расскажет и о внутренней архитектуре в проекте , и отдаст пароли и проч.
>Но если пароль до сих пор не изменён, его нужно обновить как можно скорее, так как утечка базы с хэшами паролей подтверждена.
>взлом инфраструктуры децентрализованной платформывзлом инфраструктуры децентрализованной платформыТак чьи пароли утекли, разработчиков?
Все утекли.