The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Подробности про второй взлом Matrix. Скомпрометированы GPG-ключи проекта

12.04.2019 19:31

Опубликованы новые подробности про взлом инфраструктуры децентрализованной платформы обмена сообщениями Matrix, о котором сообщалось утром. Проблемным звеном, через которое проникли атакующие была система непрерывной интеграции 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 серию отчётов с подробностями атаки и советами по увеличению защиты, но они были удалены. Тем не менее, в архиве отчёты сохранились. Например, взломщик сообщил, что разработчикам Matrix следовало использовать двухфакторную аутентификацию или хотя бы не использовать перенаправление SSH-агентом ("ForwardAgent yes"), тогда проникновение в инфраструктуру было бы блокировано. Эскалацию атаки также можно было остановить предоставляя разработчикам только необходимые привилегии, а не полный root-доступ на всех серверах.

Дополнительно раскритикована практика хранения ключей для создания цифровых подписей на рабочих серверах, для подобных целей следовало бы выделить отдельный изолированный хост. Ещё атакующий сообщил, что если бы разработчики Matrix регулярно проводили аудит логов и анализировали аномалии, они бы заметили следы взлома на раннем этапе (взлом CI оставался незамеченным целый месяц). Ещё одной проблемой было хранение всех файлов конфигурации в Git, что позволяло оценить настройки других хостов при взломе одного из них. Доступ по SSH к серверам инфраструктуры не был ограничен защищённой внутренней сетью, что позволяло подключиться к ним с любого внешнего адреса.

  1. Главная ссылка к новости (https://matrix.org/blog/2019/0...)
  2. OpenNews: Взлом инфраструктуры matrix.org
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: matrix
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (54) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Huff (?), 19:46, 12/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Где качнуть базу?
     
     
  • 2.22, пох (?), 22:19, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а что с ней полезного сделать-то можно? А, понял - ты свой пароль не можешь вспомнить? Да, такая же фигня :-(

     

  • 1.3, Аноним (3), 20:06, 12/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +15 +/
    Т.е. в матриксе крутили на х.ю самые обычные бестпрактисы. Молодцы, че
     
     
  • 2.4, Аноним (4), 20:14, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это какие?
     
     
  • 3.10, Аноним (10), 20:49, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +14 +/
    >самые обычные

    Они же «очевидные любому» и «всем давно известные». Диванные специалисты по ИБ такие диванные…

     
  • 2.9, пох (?), 20:47, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • –6 +/
    наоборот же ж - сплошные best practices - ci, торчащий задницей наружу, ssh-ключи (ох как я это люблю и обожаю), логи, поди, хранил за них systemd, sudo su для любой ерунды, конфиги в git вместо svn (который, в отличие от git, писали умные люди, и который умеет checkout только подветки, равно как и хоть примитивную, но fine-grained авторизацию, не позволяющую, проломив один хост, ознакомиться с конфигами другого на халяву), обновления накатываются не по факту выпуска, а когда можно и есть время разбираться, почему все сдохло
    - все ж так делают, вы чего.

    остальное - вонючее старперство и тормозит разработку.

     
     
  • 3.11, Аноним (10), 20:54, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >страх перед SSH-ключами
    >svn
    >sudo su
    >страх перед публичными сетями

    Сразу видно большого специалиста по системному администрированию двух локалхостов с LA 0.01 в сети 192.168.0.0/24.

     
     
  • 4.19, пох (?), 22:07, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да-да, вот мы видим что наадминистрировали бесстрашные "специалисты" нелокалхостов, торчащих голой жопой в интернет да еще с претензиями на особую безопасТность своего продукта.

    А вы, гражданин, к сожалению просто неуловимый джо, и нафиг никому не сдались, поэтому пока наивно думаете что что-то умеете необычное и сокровенное.

     
  • 3.27, KonstantinB (ok), 23:03, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    >, конфиги в git вместо svn

    Это ты серьезно, бро? :)

    1) Полным конфигам - с ключами и прочим - вообще нечего делать в системе контроля версий. Только шаблоны с плейсхолдерами, а сами значения берутся из

    2) На серверах, куда деплоятся эти конфиги, вообще не должно быть никаких репозиториев и доступа к нему. Деплоиться все должно с изолированного выделенного сервера. Тот, кто деплоит через git pull или svn up, должен гореть в аду.

     
     
  • 4.28, KonstantinB (ok), 23:04, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не дописал. :-)

    ..берутся из secrets database, доступа к которой нет ниоткуда, кроме выделенного сервера для деплоя.

     
     
  • 5.42, пох (?), 14:02, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а поскольку для изменения любой ерунды нужно лезть на этот сервер - ты давно уже потерял счет учеткам и паролям имеющих туда доступ.

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

     
  • 4.34, Дон Ягон (?), 04:38, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Тот, кто деплоит через git pull или svn up, должен гореть в аду.

    Горячо плюсую. Остальное, впрочем, тоже.

     
  • 4.41, пох (?), 14:00, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Полным конфигам - с ключами и прочим - вообще нечего делать в системе контроля версий

    ну действительно, зачем вам версионирование конфигов, новаяпапка2454

    > Деплоиться все должно с изолированного выделенного сервера.

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

    собственно, шматрикс - уже подeбил.

    А у меня НЕТ никакого "выделенного сервера", хакнув который или перехватив доступы допущенных, можно получить рутовый доступ ко всему, хвала ssh-agent'у и его форвардам, а так же незамутненным авторам ансимля.
    Есть svn, но он доступен частями и местами, и знание одного пароля никак не поможет получить другой, это вам не гит, это еще почти нормальные люди придумали. А любая не-svn активность на той коробке - вызовет вопросы, кто ета, и что он вообще мог там забыть - учитывая полное отсутствие поводов туда заходить.

    И, заметьте, в отличие от модных стильных молодежных - я так живу уже лет десять.

     
  • 3.66, Онанимним (?), 13:50, 16/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А что не так с использованием ssh-ключей?
     
  • 2.13, Аноним (13), 21:14, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    На самом деле в большинстве стартапов то же самое.
    Помню, как-то один прожектманагер, когда я заикнулся о том, как делать авторизацию, заявил: «Как говорил X X-ич X-ов, когда речь заходит о безопасности, работа останавливается.» Кто такой этот хрен, которого он цитировал, я так и не выяснил, да и имя сразу же забыл, но имею основания полагать, что такая точка зрения весьма распространена, и вертеть на х.ю вопросы безопасности как раз-таки входит в бестпрактисы дефективных манагеров.
     
     
  • 3.20, пох (?), 22:16, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну в целом-то не врал - работу приходится останавливать, все переделывать как надо, а не как удобно разработчикам, и их потом п-ть, чтобы после жесткого внушения что использовать для упрощения себе жизни sh скопированный в cgi/ - нехорошо, не обнаружить через час exec("/bin/sh"); уже в коде на единственноправильном язычке. Удобно уложенный в корень сайта с неприметным именем shell (по сути реальный случай - причем из тех времен, когда это действительно было можно делать, потому что менеджеры были - эффективные, без кавычек, из тех что поднимали бизнес с нуля без копейки в кармане, и хорошо понимали, чем грозит такой файлик) - а у них от этого фрустрация и опускаются руки.

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

    вот сегодня например у нас заметили что пинг запретили ;-)

     
     
  • 4.31, Аноним (31), 00:36, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > работу приходится останавливать, все переделывать как надо

    Это было начало проекта, шанс сразу сделать всё как надо, но нет.

     
     
  • 5.45, пох (?), 14:07, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "любой проект начинают как минимум двое - один из них общительный, другой умный. Первый потом обычно становится CEO, второй CTO."
    А админа они нанимают лет через пять, иногда уже после того как пару раз поломают.

    Ну и учтите еще что это в изрядной степени community проект, а такие вообще сложно удержать под контролем. Кто-нибудь рано или поздно продалбывает учетку.

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

     
  • 3.67, Сергей (??), 14:03, 16/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Проблема в том, что разработчикам надо работать, а если (например, ожегшись на молоке) назначают рулить системой какого-нибудь упоротого сисадмина, который знает только "не пущать", то начинается как раз: svn, freebsd, ещё какая-нибудь экзотика из 90-х (времён, когда у админа ещё стоял), а всего остального он не знает, и запрещает как небезопасное.

    Ответ гугла на это — концепция SRE, когда инфраструктурой рулят полуразработчики, которые не воюют с разрабами, а понимают их боль, но и не забивают и на безопасность при этом. SRE в числе самых высокооплачиваемых ребят, по последнему опросу на StackOverflow (дороже почти всех разработчиков).

     

  • 1.5, Аноним (5), 20:18, 12/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А как Jenkins мог такую дыру раскрыть? Он же на джаве, буфер там переполниться не мог, RCE почти невероятно. Как?
     
     
  • 2.7, Аноним (7), 20:35, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В любой плаг сажаешь троя и имеешь кого хочешь.
     
  • 2.12, Аноним (13), 21:06, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Какой маленький, какой наивный…
    https://jenkins.io/security/advisories/
     
     
  • 3.15, Аноним (15), 21:36, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://wp-content.bluebus.com.br/wp-content/uploads/2014/08/sarcasm-big-bang-

    // другой Аноним

     
  • 2.25, КО (?), 22:51, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тут бы помог только язык, который принципиально не позволяет читать файлы. Тогда бы файлы ключей утечь не смогли бы. Но и систему сборки на нем написать было бы трудно.
     
     
  • 3.46, пох (?), 14:08, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да ладно, для сборки не надо читать файлы, их надо писать ;-)

     

  • 1.6, Аноним (6), 20:21, 12/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    best practics
    ssh agent на сервере.
     
     
  • 2.16, Аноним (15), 21:37, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    То был форвардинг агента с админской машины на промежуточный сервер. Но от того не легче.
     
     
  • 3.21, пох (?), 22:17, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ничего что это дефолтная настройка sshd?

     
     
  • 4.30, Аноним (30), 00:08, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В том и беда. Как и всякие IdentitiesOnly.
     
  • 2.38, Аноним (38), 12:05, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот кстати да.
    ssh изкоробочный брешь сам по себе.
    Заморочишься настроить, все как надо едет но зачем когда есть прекрасный teleport и тому подобные вещи которые из коробки едут как надо.
     
     
  • 3.47, пох (?), 14:11, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    нет агента - нет проблемы.
    Ну и ключ должен быть не один на все, а индивидуальный для каждого, и с ограничением, откуда и кто может им ходить (и нет, ни разу не рут).

    Хотя сама концепция "спер ключ - получил все" - глубоко уродлива сама по себе. Интересно, когда ssh научится проверять _одновременно_ ключи и пароли? Никогда или лет через сто?

    Вангую за никогда - это ж сломает нахрен концепцию чудо-сервера-с-конфигами, с доступом ко всему, так любимую девляпсами.

     
     
  • 4.56, Твой влажный сокет (?), 20:41, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Интересно, когда ssh научится проверять _одновременно_ ключи и пароли

    А он уже давно умеет 2FA. Но дремучие админы локалхоста об этом не догадываются.
    >это ж сломает нахрен концепцию чудо-сервера-с-конфигами,

    Это сломает и концепцию одного супер-админа. Придется ведь долго-долго каждый сервер ручками настраивать и держать пароли и конфиги ко всем тысячам машин в голове. Ведь configuration management - зло и автоматизация не нужна.
    >с доступом ко всему, так любимую девляпсами.

    У "девляпсов" уже давно KMS и 2FA везде.
    >Ну и ключ должен быть не один на все, а индивидуальный для каждого, и с ограничением, откуда и кто может им ходить

    И еще для каждого сервера свой =). В итоге у нас будет
    X серверов x Y пользователей x Z источников подключения. Конечно же это нужно делать вручную ибо автоматизация зло и дыра в инфраструктуре. Можно будет сразу профиль организации поменять на "SSH key management".

     
     
  • 5.60, хотел спросить (?), 23:56, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    я не разрешаю автоматом деплоить

    только собирать и заливать на продакшен от имени не привелигированного пользователя

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

    может кто-то думает иначе, но мне так как-то спокойнее

     
  • 4.57, Анонимус2 (?), 20:46, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Интересно, когда ssh научится проверять _одновременно_ ключи и пароли? Никогда или лет через сто?

    Лет 20 как умеет, но седобородые админы не умеют

     

  • 1.8, Аноним (7), 20:40, 12/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Зато секурность.
     
  • 1.17, Аноним (17), 21:58, 12/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >Ещё одной проблемой было хранение всех файлов конфигурации в Git, что позволяло оценить настройки других хостов при взломе одного из них.

    То есть предлагалось следовать подходу security through obscurity?

     
     
  • 2.55, пох (?), 19:54, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    для закрытых от внешнего мира систем это прекрасно работает.
    Или как минимум затягивает взлом достаточно, чтобы успеть заметить проблему вовремя.

     
  • 2.59, Ан. (?), 22:23, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>Ещё одной проблемой было хранение всех файлов конфигурации в Git, что позволяло оценить настройки других хостов при взломе одного из них.
    >То есть предлагалось следовать подходу security through obscurity?

    Это конфигурации, но не токены-пароли-ключи. Насколько понял. Руками сервера сегодня уже никто не админит, всегда конфиги лежат в Гит, так и должно быть.

    К ним в инфраструктуру зайти можно из инета из кафе. Вот это чисто конкретно нарушение.

     

  • 1.23, Michael Shigorin (ok), 22:24, 12/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Добрый прохожий ещё попался...
     
     
  • 2.24, Crazy Alex (ok), 22:32, 12/04/2019 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Я бы сказал - на редкость. Дефейс и конструктивная критика вместо трояна в релизах...
     
     
  • 3.40, Аноним (40), 12:43, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И наверняка он ранее пылался им указать на недостатки. Но матриксовцы его замечания проигнорировали.
     
  • 3.48, пох (?), 14:12, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    он наверное уже в курсе, что там много не намайнишь, с полутора-то фриками пользователями.

     

  • 1.26, AnonPlus (?), 22:57, 12/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Справедливости ради, отчёты хакера удалены вместе с его аккаунтом, а не разработчиками сабжа.
     
     
  • 2.49, пох (?), 14:14, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    им достаточно было просто пожаловаться, работящие индусы все сделали за них ;-)
    Впрочем, пожаловаться мог и любой бдительный гражданин - совершенно не понимаю хакеров, выкладывающих подобное на гитхап вместо нормальных хостов.

     

  • 1.35, Kuromi (ok), 05:40, 13/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лол, и каждый раз повторяются одни и те же слова "следовало использовать двухфакторную аутентификацию". Помнится в череде "взломов" NPM - тоже самое.
     
     
  • 2.43, InuYasha (?), 14:02, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Правильно! Передайте все ключи сотовым операторам сразу! :)
     
     
  • 3.50, пох (?), 14:14, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну не ssh же ж на самом же деле патчить?

     
  • 3.51, Crazy Alex (ok), 14:36, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    TOTP или FIDO  в помощь
     
  • 3.54, Гентушник (ok), 19:07, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кроме кода по SMS есть куча других возможных факторов.
     
  • 3.68, Kuromi (ok), 17:53, 17/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Правильно! Передайте все ключи сотовым операторам сразу! :)

    U2F, FIDO\WebAuthn уже давно поддерживается в Хроме и ФФ, остальные браузеры на подходе (даже Сафари). Было бы желание.

     

  • 1.53, Аноним (53), 17:23, 13/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Спасибо за новость - узнал, что есть такой проект ... чтобы держаться подальше и другим не советовать.
     
     
  • 2.58, Андрей (??), 22:07, 13/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И от Linux впридачу.
     
  • 2.65, x3who (?), 11:08, 16/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > узнал, что есть такой проект ... чтобы держаться подальше и другим не советовать.

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

     

  • 1.61, Биарей Гиесс и Котт (?), 12:35, 14/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я не понимаю , вообще о какой безопасности в таких проектах может идти речь ??
    Всегда есть вероятность, что внутри найдется предатель, коий расскажет и о внутренней архитектуре в проекте , и отдаст пароли и проч.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    MIRhosting
    Fornex
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру