[TÓPICO DEDICADO] O papo é Programação/Desenvolvimento e áreas de TI afins

[House.Cybersec]

Nos últimos dias tem ocorrido DEZENAS de ataques em sucedidos com ransomware. Todo tamanho de empresa, desde um da área de saúde da Escócia (18bi de dolares que ganharam em 2021), até uma Japonesa da area de produção (3bi de dólares) e outras bem menores.

 

[Alberth-OC]

 

[The_Ancient_Machine]

Meu Arch estava com essa versão instalada, apareceu uma atualização ontem para a 5.6.2. Só é ruim ainda usarem o mesmo repositório git, pois ele pode estar comprometido. O Github trancou o repositório.

GitHub - tukaani-project/xz: XZ Utils

XZ Utils. Contribute to tukaani-project/xz development by creating an account on GitHub.

github.com

O openssh não usa diretamente o liblzma (que usa o xz). No entanto, o Debian e várias outras distribuições configuram o openssh para suportar a notificação do SystemD, e o libSystemD depende do lzma.
Arch não vincula diretamente o openssh ao liblzma e, portanto, esse vetor de ataque não é possível.

Quem está em risco e foi anunciado é quem usa Fedora 40, Debian Sid, Kali Linux e OpenSuse Tumbleweed.

O backdoor só se ativava nas condições de estar em distros RPM ou DEB, utilizando SystemD e com o SSH ativado.

O problema maior é que o desenvolvedor que injetou esse backdoor, estava no projeto há 2 anos. O nome e sobrenome do desenvolvedor dão a entender que o cara é chinês (mas obviamente é fake). Foi algo bem sofisticado, um outro desenvolvedor descobriu meio que por acaso, ao perceber um uso estranho de CPU em sua instalação Debian.

oss-security - backdoor in upstream xz/liblzma leading to ssh server compromise

Backdoor in upstream xz/liblzma leading to SSH server compromise | Hacker News

news.ycombinator.com

 

[igormp]

Meu Arch estava com essa versão instalada, apareceu uma atualização ontem para a 5.6.2. Só é ruim ainda usarem o mesmo repositório git, pois ele pode estar comprometido. O Github trancou o repositório.

GitHub - tukaani-project/xz: XZ Utils

XZ Utils. Contribute to tukaani-project/xz development by creating an account on GitHub.

github.com

O openssh não usa diretamente o liblzma (que usa o xz). No entanto, o Debian e várias outras distribuições configuram o openssh para suportar a notificação do SystemD, e o libSystemD depende do lzma.
Arch não vincula diretamente o openssh ao liblzma e, portanto, esse vetor de ataque não é possível.

Quem está em risco e foi anunciado é quem usa Fedora 40, Debian Sid, Kali Linux e OpenSuse Tumbleweed.

O backdoor só se ativava nas condições de estar em distros RPM ou DEB, utilizando SystemD e com o SSH ativado.

O problema maior é que o desenvolvedor que injetou esse backdoor, estava no projeto há 2 anos e até se encontrou com outros desenvolvedores. O nome e sobrenome do desenvolvedor dá a entender que o cara é chinês (estão evitando falar disso para não gerar um problema diplomático). Foi algo bem sofisticado, um outro desenvolvedor descobriu meio que por acaso, ao perceber um uso estranho de CPU em sua instalação Debian.

oss-security - backdoor in upstream xz/liblzma leading to ssh server compromise

Backdoor in upstream xz/liblzma leading to SSH server compromise | Hacker News

news.ycombinator.com

Fedora 40 não, só o rawhide.

 

[The_Ancient_Machine]

Fedora 40 não, só o rawhide.

Red Hat recomendou fazer downgrade mesmo assim:

At this time the Fedora Linux 40 builds have not been shown to be compromised. We believe the malicious code injection did not take effect in these builds. However, Fedora Linux 40 users should still downgrade to a 5.4 build to be safe. An update that reverts xz to 5.4.x has recently been published and is becoming available to Fedora Linux 40 users through the normal update system.

Urgent security alert for Fedora 41 and Fedora Rawhide users

Red Hat Information Risk and Security and Red Hat Product Security learned that the latest versions of the “xz” tools and libraries contain malicious code that appears to be intended to allow unauthorized access.

www.redhat.com

--- Post duplo é unido automaticamente: 30/03/2024 ---

Histórico até o momento:

Everything I know about the XZ backdoor

Please note: This is being updated in real-time. The intent is to make sense of lots of simultaneous discoveries

boehs.org

Breve análise do backdoor:

 

[igormp]

Red Hat recomendou fazer downgrade mesmo assim

Recomendação é diferente de estar em risco. Únicos afetados foram Kali, rawhide e Debian unstable até o momento, e é algo praticamente irrelevante pq seria muita idiotice ter um sistema dessas com ssh exposto pra Internet pra começo de história, então na prática o risco é quase nulo pq esse backdoor foi descoberto a tempo.

 

[The_Ancient_Machine]

Recomendação é diferente de estar em risco. Únicos afetados foram Kali, rawhide e Debian unstable até o momento, e é algo praticamente irrelevante pq seria muita idiotice ter um sistema dessas com ssh exposto pra Internet pra começo de história, então na prática o risco é quase nulo pq esse backdoor foi descoberto a tempo.

O Fedora 40 possui ambos os arquivos, mas parece que o malware não se ativa nele. Só que essa é uma história ainda em desenvolvimento. As versões 5.6.0 e 5.6.1 foram onde o malware foi descoberto, mas o desenvolvedor estava no projeto há 2 anos, ainda estão auditando as versões antigas.

Ele afetar o SSH é apenas a ponta do iceberg, não se sabe ainda se há outros backdoors em outros serviços. A Red Hat classificou esse CVE com nota 10, que é o máximo.

cve-details

E para dar mais dor de cabeça, esse mesmo desenvolvedor tem mais de 750 commits no XZ e também participava de outros projetos open source. Muita história ainda vai rolar.

O malware foi descoberto por acaso, porque o código dele tem um bug, que derrubava a performance da conexão SSH, o que chamou a atenção de um desenvolvedor da Microsoft enquanto ele testava umas coisas no Debian Sid. Sem isso, provavelmente passaria ileso, tendo em vista que essas versões são de janeiro de 2024.

O Debian discute voltar para a versão 5.3.1 que é a última anterior a entrada do "Jia Tan". O problema é que isso poderá quebrar vários pacotes, então ainda estão verificando essa possibilidade.

#1068024 - revert to version that does not contain changes by bad actor - Debian Bug report logs

bugs.debian.org

 

[House.Cybersec]

Teve um backdoor no xz que aparentemente gerava uma falha de segurança no sshd:

oss-security - backdoor in upstream xz/liblzma leading to ssh server compromise

Everything I know about the XZ backdoor

Please note: This is being updated in real-time. The intent is to make sense of lots of simultaneous discoveries

boehs.org

Risco praticamente 0 pq não teve tempo de propagar nem chegar em alguma release final de distros, mas parece ter sido algo bem elaborado e planejado há anos.

O maior risco era no caso do usuário do Kali que fez o update entre 26 e 29 de março, ai pegou uma release com a falha.

Ou, usuários de outras distros que por azar pegou também essa versão vulnerável.

Mas era bem simples de mitigar, postei até um script que vc executa, informa a versão e caso fosse uma versão vulneravel faria o downgrade.

--- Post duplo é unido automaticamente: 01/04/2024 ---

Recomendação é diferente de estar em risco. Únicos afetados foram Kali, rawhide e Debian unstable até o momento, e é algo praticamente irrelevante pq seria muita idiotice ter um sistema dessas com ssh exposto pra Internet pra começo de história, então na prática o risco é quase nulo pq esse backdoor foi descoberto a tempo.

Ter SSH exposto é pedir demais ...

No mínimo acesso liberado para um IP de segurança (acesso restrito) e se possível, adicionar um MFA ...

 

[Andromeda's Ryder]

O backdoor só se ativava nas condições de estar em distros RPM ou DEB, utilizando SystemD e com o SSH ativado.

O problema maior é que o desenvolvedor que injetou esse backdoor, estava no projeto há 2 anos. O nome e sobrenome do desenvolvedor dão a entender que o cara é chinês (mas obviamente é fake). Foi algo bem sofisticado, um outro desenvolvedor descobriu meio que por acaso, ao perceber um uso estranho de CPU em sua instalação Debian.

oss-security - backdoor in upstream xz/liblzma leading to ssh server compromise

Backdoor in upstream xz/liblzma leading to SSH server compromise | Hacker News

news.ycombinator.com

Esse tipo de coisa vai continuar a acontecer infelizmente

 

[The_Ancient_Machine]

Esse tipo de coisa vai continuar a acontecer infelizmente

Sim, pois ao mesmo tempo que temos vários projetos onde um cara só cuida de uma peça vital na infraestrutura global, também tem o fator de estarmos em uma nova guerra fria, vários atores pagos por estados vão atacar o outro pelo "ciberespaço", para causar algum dano.

Já descobriram que o Jia Tan teve commits em outros projetos como libarchive, STest, Seatest. Ele fez fork e estava trabalhando no wasmtime, squashfs-tools, zstd, lz4, ZipArchive.
E é uma dev, imagina quantos outros não estão por aí.

 

[Andromeda's Ryder]

Sim, pois ao mesmo tempo que temos vários projetos onde um cara só cuida de uma peça vital na infraestrutura global, também tem o fator de estarmos em uma nova guerra fria, vários atores pagos por estados vão atacar o outro pelo "ciberespaço", para causar algum dano.

Já descobriram que o Jia Tan teve commits em outros projetos como libarchive, STest, Seatest. Ele fez fork e estava trabalhando no wasmtime, squashfs-tools, zstd, lz4, ZipArchive.
E é uma dev, imagina quantos outros não estão por aí.

Pois é, guerra fria é a palavra chave e não há como saber quem é quem e quantas vulnerabilidades foram criadas e ainda não foram identificadas, é impossível controlar/revisar tudo, e aí ficam à mercê.

 

[House.Cybersec]

Nossa ... é mais fácil hackear do que reportar uma falha ...

Estou atualizando meu setup de bug bounty, e com isso, uso sites de faculdades para realizar recon e caso encontre alguma falha eu reporto (ou pelo menos tento). Achei um endpoint exposto com vários arquivos livres pra fazer download (até arquivos com dados de pacientes) de uma faculdade MUITO grande, já mandei e-mail, já liguei pra tentar reportar e até agora NADA de ser atendido O_O.

 

[Andromeda's Ryder]

Nossa ... é mais fácil hackear do que reportar uma falha ...

Estou atualizando meu setup de bug bounty, e com isso, uso sites de faculdades para realizar recon e caso encontre alguma falha eu reporto (ou pelo menos tento). Achei um endpoint exposto com vários arquivos livres pra fazer download (até arquivos com dados de pacientes) de uma faculdade MUITO grande, já mandei e-mail, já liguei pra tentar reportar e até agora NADA de ser atendido O_O.

infelizmente as empresas só se mexem se causar algum dano financeiro, e olha lá, ainda mais no Brasil, esse povo merece se ferrar muito.

 

[manotroll]

não daria pra apenas remover as linhas que geram a falha do ssh e pronto ?
ou se fizer isso ta quebrando tudo ?
hoje acho que nei precisa ter o ip exposto ja que ipv4 praticamente ninguem tem
mais ipv6 todos temos
o que e MFA ?

 

[igormp]

não daria pra apenas remover as linhas que geram a falha do ssh e pronto ?

A falha não foi no ssh, mas sim, revertendo isso do build já elimina a falha. O problema era que as linhas conseguiram ser introduzidas em primeiro lugar, e chegaram a entrar em alguns sistemas.

hoje acho que nei precisa ter o ip exposto ja que ipv4 praticamente ninguem tem

Muita gente tem ipv4. Mas sim, precisa dele exposto pra internet, oq reduz bastante o vetor de ataque.

mais ipv6 todos temos

Nem todos.

o que e MFA ?

Multi factor authentication, aquela paradinha de pedir um código extra depois de colocar a senha.

 

[manotroll]

A falha não foi no ssh, mas sim, revertendo isso do build já elimina a falha. O problema era que as linhas conseguiram ser introduzidas em primeiro lugar, e chegaram a entrar em alguns sistemas.

Muita gente tem ipv4. Mas sim, precisa dele exposto pra internet, oq reduz bastante o vetor de ataque.

Nem todos.

Multi factor authentication, aquela paradinha de pedir um código extra depois de colocar a senha.

mais ipv6 e so ligar pro provedor que eles ligam ja que estamos no cgnat faz muito tempo que não vejo um ipv4 valido e aqui no provedor acho que nei pagando
MFA no ssh seria além da senha o arquivo com o certificado ou teria como fazer senha e + alguma outra coisa ?
mais como o cara ja estava contribuindo tem 2 anos teria outras vi que a galera ta revisando

 

[igormp]

mais ipv6 e so ligar pro provedor que eles ligam ja que estamos no cgnat faz muito tempo que não vejo um ipv4 valido e aqui no provedor acho que nei pagando

Aqui tenho IPV4 válido em ambos os meus links residenciais, sem CGNAT (Tim fibra e Vivo fibra).

MFA no ssh seria além da senha o arquivo com o certificado ou teria como fazer senha e + alguma outra coisa ?

Onde foi mencionado MFA no ssh? No caso dessa falha isso seria inútil.

 

[House.Cybersec]

Aqui tenho IPV4 válido em ambos os meus links residenciais, sem CGNAT (Tim fibra e Vivo fibra).

Onde foi mencionado MFA no ssh? No caso dessa falha isso seria inútil.

Eu que mencionei, mas não para esse caso. Apenas citei que quem trabalha com SSH (ou RDP) exposto está errado. E se possível, mesmo sem estar exposto seria interessante adicionar um MFA para acesso.

 

[manotroll]

Eu que mencionei, mas não para esse caso. Apenas citei que quem trabalha com SSH (ou RDP) exposto está errado. E se possível, mesmo sem estar exposto seria interessante adicionar um MFA para acesso.

e como seria ?
afinal usar um no-ip pra acessar ele diretamente passando do cgnat seria deixar ele exposto correto ?
ou eu teria que colocar uma senha no no-ip por exemplo pra ai sim conseguir enxergar a rede pra poder conectar no ssh ?

 

[House.Cybersec]

e como seria ?
afinal usar um no-ip pra acessar ele diretamente passando do cgnat seria deixar ele exposto correto ?
ou eu teria que colocar uma senha no no-ip por exemplo pra ai sim conseguir enxergar a rede pra poder conectar no ssh ?

1: Se você é um usuário casual:
- A: Bloqueie o RDP no Firewall do Windows, já é uma medida simples e que ajuda na segurança.
- B: Bloqueie o SSH no Firewall do Linux, pode ser UFW ou Iptables, simples e prático.
- C: Se precisa ter acesso externo, crie uma vpn na AWS (um ano grátis em uma VM t2.small) e libera no firewall o acesso somente para esse IP.

2: Se for um Analista de Infra ou Cybersec, faz o mesmo que citei no passo C. Geralmente empresas possuem IPs Fixo, e caso a empresa que trabalhe não possua, use a estratégia de criar uma VPN e libere acesso somente por ela. Crie uma política de rotacionar as chaves de acesso e adicione MFA ao SSH (é grátis), RDP tem seu preço (mas é barato, até).

 

[Andromeda's Ryder]

1: Se você é um usuário casual:
- A: Bloqueie o RDP no Firewall do Windows, já é uma medida simples e que ajuda na segurança.
- B: Bloqueie o SSH no Firewall do Linux, pode ser UFW ou Iptables, simples e prático.
- C: Se precisa ter acesso externo, crie uma vpn na AWS (um ano grátis em uma VM t2.small) e libera no firewall o acesso somente para esse IP.

2: Se for um Analista de Infra ou Cybersec, faz o mesmo que citei no passo C. Geralmente empresas possuem IPs Fixo, e caso a empresa que trabalhe não possua, use a estratégia de criar uma VPN e libere acesso somente por ela. Crie uma política de rotacionar as chaves de acesso e adicione MFA ao SSH (é grátis), RDP tem seu preço (mas é barato, até).

fazer uso de forma errada tem um monte, pode contar nos dedos quantos profissionais vão se mexer pra fazer algo, só quando a água bate na buzanfa o povo se mexe.

--- Post duplo é unido automaticamente: 04/04/2024 ---

de resto, só digo isso:

windows

 

[Termal]

Acabei de saber que quem trabalhar nos EUA pode declarar gasto com twitter no IR. Isso existe no Brasil?

 

[TuxSenpai]

1: Se você é um usuário casual:
- A: Bloqueie o RDP no Firewall do Windows, já é uma medida simples e que ajuda na segurança.
- B: Bloqueie o SSH no Firewall do Linux, pode ser UFW ou Iptables, simples e prático.
- C: Se precisa ter acesso externo, crie uma vpn na AWS (um ano grátis em uma VM t2.small) e libera no firewall o acesso somente para esse IP.

2: Se for um Analista de Infra ou Cybersec, faz o mesmo que citei no passo C. Geralmente empresas possuem IPs Fixo, e caso a empresa que trabalhe não possua, use a estratégia de criar uma VPN e libere acesso somente por ela. Crie uma política de rotacionar as chaves de acesso e adicione MFA ao SSH (é grátis), RDP tem seu preço (mas é barato, até).

Usar o AWS para fazer uma VPN dá realmente certo?
Pergunto, pois como é uma coisa que não vai tá fisicamente, mas sim, com terceiros, até que ponto se torna seguro?

Essa falha no XZ é uma das milhares que devem existir, tipo, aquele monte de plugins do phython que tem ai a rodo, empacotamentos de terceiros, appsimages, flatpacks e etc, que tem ai aos montes. Fora inúmeros programas de devs que não disponibilizam nenhuma documentação.
O pessoal do Debian & cia já fizeram downgrade. O cara foi esperto, fico imaginando se ele pegasse uma libc6 por exemplo, o estrago que iria ser.
E lembrando, se não usam o serviço, desabilitem o mesmo, é uma a coisa a menos para se preocuparem.

Link para eu lembrar de ver depois:

https://www.cisoadvisor.com.br/distribuicoes-linux-sao-afetadas-por-backdoor-no-xz-utils/

 

[igormp]

Usar o AWS para fazer uma VPN dá realmente certo?
Pergunto, pois como é uma coisa que não vai tá fisicamente, mas sim, com terceiros, até que ponto se torna seguro?

Eu tenho uma vpn no gcp, e tinha uma na Oracle (até fazer caca e perder a máquina), nunca tive dor de cabeça, mas uso mais quando quero acessar algum conteúdo dos US mesmo, e não por segurança ou outra coisa.

 

[House.Cybersec]

Usar o AWS para fazer uma VPN dá realmente certo?
Pergunto, pois como é uma coisa que não vai tá fisicamente, mas sim, com terceiros, até que ponto se torna seguro?

Essa falha no XZ é uma das milhares que devem existir, tipo, aquele monte de plugins do phython que tem ai a rodo, empacotamentos de terceiros, appsimages, flatpacks e etc, que tem ai aos montes. Fora inúmeros programas de devs que não disponibilizam nenhuma documentação.
O pessoal do Debian & cia já fizeram downgrade. O cara foi esperto, fico imaginando se ele pegasse uma libc6 por exemplo, o estrago que iria ser.
E lembrando, se não usam o serviço, desabilitem o mesmo, é uma a coisa a menos para se preocuparem.

Link para eu lembrar de ver depois:

https://www.cisoadvisor.com.br/distribuicoes-linux-sao-afetadas-por-backdoor-no-xz-utils/

AWS, assim como Azure e GCP (para citar os três maiores) seguem padrões e frameworks de Segurança bem sólidos.

Pode ficar tranquilo em relação a isso. É muito mais seguro seus dados trafegando em uma VPN criada por exemplo com a OpenVPN lá na AWS, que com vários serviços que são vendidos por aí.

Detalhe: Muitos serviços de VPN e proxy que são vendidos usam justamente a infraestrutura de uma das três que citei.