Подробности за втория хак на Matrix. GPG ключовете на проекта са компрометирани

[: ru]

Публикувано новые детайлите за хакването на инфраструктурата на децентрализираната платформа за съобщения Matrix, за която съобщава сутринта. Проблемната връзка, през която нападателите са проникнали, е системата за непрекъсната интеграция Jenkins, която беше хакната на 13 март. След това на сървъра на Jenkins влизането на един от администраторите, пренасочено от SSH агент, беше прихванато и на 4 април нападателите получиха достъп до други инфраструктурни сървъри.

По време на втората атака уебсайтът matrix.org беше пренасочен към друг сървър (matrixnotorg.github.io) чрез промяна на DNS параметрите, използвайки ключа към API на системата за доставка на съдържание Cloudflare, прихванат по време на първата атака. При възстановяването на съдържанието на сървърите след първото хакване, администраторите на Matrix актуализираха само нови лични ключове и пропуснаха да актуализират ключа към Cloudflare.

По време на втората атака сървърите на Matrix останаха недокоснати; промените бяха ограничени само до подмяна на адреси в DNS. Ако потребителят вече е променил паролата след първата атака, няма нужда да я променя втори път. Но ако паролата все още не е променена, тя трябва да бъде актуализирана възможно най-скоро, тъй като изтичането на базата данни с хешове на пароли е потвърдено. Настоящият план е да инициирате процес на принудително нулиране на паролата следващия път, когато влезете.

В допълнение към изтичането на пароли, също така беше потвърдено, че GPG ключовете, използвани за генериране на цифрови подписи за пакети в хранилището на Debian Synapse и изданията на Riot/Web, са попаднали в ръцете на нападателите. Ключовете бяха защитени с парола. В момента ключовете вече са анулирани. Ключовете бяха прихванати на 4 април, оттогава не са пускани актуализации на Synapse, но беше пуснат клиентът Riot/Web 1.0.7 (предварителната проверка показа, че не е компрометиран).

Нападателят публикува поредица от доклади в GitHub с подробности за атаката и съвети за повишаване на защитата, но те бяха изтрити. Въпреки това архивираните отчети запазен.
Например, нападателят съобщи, че разработчиците на Matrix трябва да се използва двуфакторно удостоверяване или поне неизползване на пренасочване на SSH агент („ForwardAgent да“), тогава проникването в инфраструктурата ще бъде блокирано. Ескалацията на атаката също може да бъде спряна чрез даване на разработчиците само на необходимите привилегии, а не пълен root достъп на всички сървъри.

Освен това беше критикувана практиката за съхраняване на ключове за създаване на цифрови подписи на производствени сървъри; за тези цели трябва да се разпредели отделен изолиран хост. Все още атакува сообщил, че ако разработчиците на Matrix редовно одитираха регистрационни файлове и анализираха аномалии, те щяха да забележат следи от хак рано (CI хакът остана неоткрит в продължение на месец). Друг проблем беше съхраняване на всички конфигурационни файлове в Git, което дава възможност да се оценят настройките на други хостове, ако някой от тях е бил хакнат. Достъп чрез SSH до инфраструктурни сървъри не беше ограничени до защитена вътрешна мрежа, което прави възможно свързването с тях от всеки външен адрес.

източникopennet.ru

[EN]

Публикувано новые детайлите за хакването на инфраструктурата на децентрализираната платформа за съобщения Matrix, за която съобщава сутринта. Проблемната връзка, през която нападателите са проникнали, е системата за непрекъсната интеграция Jenkins, която беше хакната на 13 март. След това на сървъра на Jenkins влизането на един от администраторите, пренасочено от SSH агент, беше прихванато и на 4 април нападателите получиха достъп до други инфраструктурни сървъри.

По време на втората атака уебсайтът matrix.org беше пренасочен към друг сървър (matrixnotorg.github.io) чрез промяна на DNS параметрите, използвайки ключа към API на системата за доставка на съдържание Cloudflare, прихванат по време на първата атака. При възстановяването на съдържанието на сървърите след първото хакване, администраторите на Matrix актуализираха само нови лични ключове и пропуснаха да актуализират ключа към Cloudflare.

По време на втората атака сървърите на Matrix останаха недокоснати; промените бяха ограничени само до подмяна на адреси в DNS. Ако потребителят вече е променил паролата след първата атака, няма нужда да я променя втори път. Но ако паролата все още не е променена, тя трябва да бъде актуализирана възможно най-скоро, тъй като изтичането на базата данни с хешове на пароли е потвърдено. Настоящият план е да инициирате процес на принудително нулиране на паролата следващия път, когато влезете.

В допълнение към изтичането на пароли, също така беше потвърдено, че GPG ключовете, използвани за генериране на цифрови подписи за пакети в хранилището на Debian Synapse и изданията на Riot/Web, са попаднали в ръцете на нападателите. Ключовете бяха защитени с парола. В момента ключовете вече са анулирани. Ключовете бяха прихванати на 4 април, оттогава не са пускани актуализации на Synapse, но беше пуснат клиентът Riot/Web 1.0.7 (предварителната проверка показа, че не е компрометиран).

Нападателят публикува поредица от доклади в GitHub с подробности за атаката и съвети за повишаване на защитата, но те бяха изтрити. Въпреки това архивираните отчети запазен.
Например, нападателят съобщи, че разработчиците на Matrix трябва да се използва двуфакторно удостоверяване или поне неизползване на пренасочване на SSH агент („ForwardAgent да“), тогава проникването в инфраструктурата ще бъде блокирано. Ескалацията на атаката също може да бъде спряна чрез даване на разработчиците само на необходимите привилегии, а не пълен root достъп на всички сървъри.

Освен това беше критикувана практиката за съхраняване на ключове за създаване на цифрови подписи на производствени сървъри; за тези цели трябва да се разпредели отделен изолиран хост. Все още атакува сообщил, че ако разработчиците на Matrix редовно одитираха регистрационни файлове и анализираха аномалии, те щяха да забележат следи от хак рано (CI хакът остана неоткрит в продължение на месец). Друг проблем беше съхраняване на всички конфигурационни файлове в Git, което дава възможност да се оценят настройките на други хостове, ако някой от тях е бил хакнат. Достъп чрез SSH до инфраструктурни сървъри не беше ограничени до защитена вътрешна мрежа, което прави възможно свързването с тях от всеки външен адрес.

Източник: opennet.ru

[:]

Добавяне на нов коментар