новые sobre o hackeamento da infraestrutura da plataforma descentralizada de mensagens Matrix, sobre a qual pela manhã. O link problemático através do qual os invasores penetraram foi o sistema de integração contínua Jenkins, que foi hackeado em 13 de março. Em seguida, no servidor Jenkins, o login de um dos administradores, redirecionado por um agente SSH, foi interceptado e, no dia 4 de abril, os invasores obtiveram acesso a outros servidores da infraestrutura.
Durante o segundo ataque, o site matrix.org foi redirecionado para outro servidor (matrixnotorg.github.io) alterando os parâmetros DNS, usando a chave da API do sistema de entrega de conteúdo Cloudflare interceptada durante o primeiro ataque. Ao reconstruir o conteúdo dos servidores após o primeiro hack, os administradores do Matrix atualizaram apenas novas chaves pessoais e deixaram de atualizar a chave para Cloudflare.
Durante o segundo ataque, os servidores Matrix permaneceram intactos; as mudanças limitaram-se apenas à substituição de endereços no DNS. Caso o usuário já tenha alterado a senha após o primeiro ataque, não há necessidade de alterá-la uma segunda vez. Mas caso a senha ainda não tenha sido alterada, ela precisa ser atualizada o mais rápido possível, já que foi confirmado o vazamento do banco de dados com hashes de senhas. O plano atual é iniciar um processo de redefinição forçada de senha na próxima vez que você fizer login.
Além do vazamento de senhas, também foi confirmado que chaves GPG usadas para gerar assinaturas digitais para pacotes no repositório Debian Synapse e versões Riot/Web caíram nas mãos dos invasores. As chaves eram protegidas por senha. As chaves já foram revogadas neste momento. As chaves foram interceptadas em 4 de abril, desde então nenhuma atualização do Synapse foi lançada, mas o cliente Riot/Web 1.0.7 foi lançado (uma verificação preliminar mostrou que não foi comprometido).
O invasor postou uma série de relatórios no GitHub com detalhes do ataque e dicas para aumentar a proteção, mas foram excluídos. No entanto, os relatórios arquivados .
Por exemplo, o invasor relatou que os desenvolvedores do Matrix deveriam autenticação de dois fatores ou pelo menos não usar o redirecionamento de agente SSH (“ForwardAgent sim”), a penetração na infraestrutura seria bloqueada. A escalada do ataque também poderia ser interrompida dando aos desenvolvedores apenas os privilégios necessários, em vez de em todos os servidores.
Além disso, a prática de armazenar chaves para a criação de assinaturas digitais em servidores de produção foi criticada; um host isolado separado deveria ser alocado para tais fins. Ainda atacando , que se os desenvolvedores do Matrix tivessem auditado regularmente os logs e analisado anomalias, eles teriam notado vestígios de um hack logo no início (o hack do CI passou despercebido por um mês). Outro problema armazenar todos os arquivos de configuração no Git, o que possibilitou avaliar as configurações de outros hosts caso um deles fosse hackeado. Acesso via SSH a servidores de infraestrutura limitado a uma rede interna segura, que permitia conectar-se a eles a partir de qualquer endereço externo.
Fonteopennet.ru
[: En]новые sobre o hackeamento da infraestrutura da plataforma descentralizada de mensagens Matrix, sobre a qual pela manhã. O link problemático através do qual os invasores penetraram foi o sistema de integração contínua Jenkins, que foi hackeado em 13 de março. Em seguida, no servidor Jenkins, o login de um dos administradores, redirecionado por um agente SSH, foi interceptado e, no dia 4 de abril, os invasores obtiveram acesso a outros servidores da infraestrutura.
Durante o segundo ataque, o site matrix.org foi redirecionado para outro servidor (matrixnotorg.github.io) alterando os parâmetros DNS, usando a chave da API do sistema de entrega de conteúdo Cloudflare interceptada durante o primeiro ataque. Ao reconstruir o conteúdo dos servidores após o primeiro hack, os administradores do Matrix atualizaram apenas novas chaves pessoais e deixaram de atualizar a chave para Cloudflare.
Durante o segundo ataque, os servidores Matrix permaneceram intactos; as mudanças limitaram-se apenas à substituição de endereços no DNS. Caso o usuário já tenha alterado a senha após o primeiro ataque, não há necessidade de alterá-la uma segunda vez. Mas caso a senha ainda não tenha sido alterada, ela precisa ser atualizada o mais rápido possível, já que foi confirmado o vazamento do banco de dados com hashes de senhas. O plano atual é iniciar um processo de redefinição forçada de senha na próxima vez que você fizer login.
Além do vazamento de senhas, também foi confirmado que chaves GPG usadas para gerar assinaturas digitais para pacotes no repositório Debian Synapse e versões Riot/Web caíram nas mãos dos invasores. As chaves eram protegidas por senha. As chaves já foram revogadas neste momento. As chaves foram interceptadas em 4 de abril, desde então nenhuma atualização do Synapse foi lançada, mas o cliente Riot/Web 1.0.7 foi lançado (uma verificação preliminar mostrou que não foi comprometido).
O invasor postou uma série de relatórios no GitHub com detalhes do ataque e dicas para aumentar a proteção, mas foram excluídos. No entanto, os relatórios arquivados .
Por exemplo, o invasor relatou que os desenvolvedores do Matrix deveriam autenticação de dois fatores ou pelo menos não usar o redirecionamento de agente SSH (“ForwardAgent sim”), a penetração na infraestrutura seria bloqueada. A escalada do ataque também poderia ser interrompida dando aos desenvolvedores apenas os privilégios necessários, em vez de em todos os servidores.
Além disso, a prática de armazenar chaves para a criação de assinaturas digitais em servidores de produção foi criticada; um host isolado separado deveria ser alocado para tais fins. Ainda atacando , que se os desenvolvedores do Matrix tivessem auditado regularmente os logs e analisado anomalias, eles teriam notado vestígios de um hack logo no início (o hack do CI passou despercebido por um mês). Outro problema armazenar todos os arquivos de configuração no Git, o que possibilitou avaliar as configurações de outros hosts caso um deles fosse hackeado. Acesso via SSH a servidores de infraestrutura limitado a uma rede interna segura, que permitia conectar-se a eles a partir de qualquer endereço externo.
Fonte: opennet.ru
[:]