Telefónica Tech Boletim semanal de Cibersegurança 29 Abril – 5 Maio Vulnerabilidade crítica nos firewalls Zyxel O fabricante de equipamentos de rede Zyxel lançou patches de segurança para uma vulnerabilidade crítica que afeta seus firewalls. A vulnerabilidade, que foi descoberta e relatada...
Telefónica Tech Boletim semanal de Cibersegurança 15 – 21 Abril Google corrige duas novas vulnerabilidades de 0-day exploradas ativamente O Google emitiu novos avisos de segurança sobre a identificação de vulnerabilidades de 0-day que afeta o navegador Chrome que está...
OpenPGP: Procurando desesperadamente por KristianSergio de los Santos 15 julio, 2020 Há um ano, o OpenPGP teve um problema de vandalismo em seus principais servidores. O sistema estava morrendo e precisava de uma mudança que não fosse trivial sem trair princípios baseados na Internet dos anos 90 e que são ingênuos aos olhos de hoje. Recentemente, uma anedota simples revela novamente sérias deficiências, um anacronismo inadequado nas redes de hoje. Uma vontade inabalável, mas incapaz de se adaptar aos novos tempos, que continua procurando desesperadamente por Kristian. O que aconteceu? Os servidores principais (SKS) são básicos na infraestrutura do OpenPGP. Eles garantem que podemos localizar as chaves públicas das pessoas. Eles lhes permitem ingressar no sistema, nunca se perder e replicar para oferecer disponibilidade. Para interagir com eles, o protocolo OpenPGP HTTP Keyserver ou HKP é usado. Através da porta 11371, você pode fazer upload e procurar chaves. Os funcionários públicos nunca funcionaram muito bem e têm muitas deficiências. Para testá-lo, basta conectar-se a qualquer sistema de chaves (como https://pgp.mit.edu) e procurar por chaves. Após vários erros no servidor (e adaptando o olho à estética dos anos 90), talvez você tenha a resposta. O mesmo acontece com https://keys.gnupg.net, https://pgp.key-server.io ou qualquer outro. Servidores não confiáveis e com pouca manutenção são a base da criptografia pública. HKP sobre TLS é chamado HKPS. O servidor hkps.pool.sks-keyservers.net é responsável pelo pool de servidores HKPS, o guarda-chuva, e possui «pedidos» do ponto de vista do DNS para se conhecerem e coordenarem. Para pertencer ao pool , os servidores devem ser validados e certificados por sua própria CA que permita a comunicação criptografada. Essa CA foi mantida por uma única pessoa manualmente por mais de 10 anos: Kristian Fiskerstrand. Todd Fleisher, que gerencia um desses servidores, expirou o certificado que lhe permitia se comunicar com a central e permanecer no pool e, portanto, coordenado com os outros servidores. Ele procurou Kristian «desesperadamente» por um mês. O tempo estava correndo contra ele. Ele não dava sinais de vida nem pelo correio nem pelas redes sociais. Eventualmente, o certificado expirou e ele teve que fazer check-out em Let’s Encrypt para manter as comunicações criptografadas, sabendo que o pool hkps.pool.sks-keyservers.net não confiava nele, mas pelo menos lhe permitiu continuar operando sem sincronizar . Em pouco tempo, Kristian respondeu: Sem muita explicação, ela estivera em outros assuntos no mês passado. Ele renovou o certificado. Se demorasse mais tempo, o restante dos servidores expiraria e o pool os ignoraria. Por que isso aconteceu? Porque um ponto crítico centralizado (que permite o uso descentralizado do OpenPGP) está nas mãos de uma única pessoa que o mantém voluntariamente. Algo de outra década (que nem sequer é a última) propenso a erros, erros e dependente de boas vontades. Romântico, mas impraticável. Adoramos software livre, mas não devemos esquecer que ele também requer financiamento, para que não apenas uma pessoa, mas uma equipe possa dedicar o tempo correspondente. Porque estamos falando de um sistema de criptografia gratuito e gratuito, cujo avô era o banner cypherpunk dos anos 90 e pelo qual Phil Zimmerman lutou. Lembre-se que até 2000 a exportação de criptografia para fora dos Estados Unidos era muito limitada. Este não é o único problema do OpenPGP. O Thunderbird, um clássico que passou por todos os tipos de problemas (a Mozilla queria se livrar dele por um tempo para concentrar seus esforços no Firefox) deu boas notícias. Em outubro de 2019, a Mozilla anunciou que queria adicionar suporte nativo ao OpenPGP ao seu cliente de email Thunderbird . Isso envolveu dispensar sua extensão Enigmail, a rainha do gerenciamento de S / MIME e OpenPGP pelo correio. Esse fato trouxe à luz algumas realidades no mundo do software que, no campo do código aberto e gratuito, talvez sejam mais surpreendentes devido às expectativas geradas. O Enigmail funciona quase como um milagre. Isso significa que a interface do Enigmail usa chamadas para linhas de comando e coleta o resultado redesenhado no Thunderbird, com todos os problemas que isso pode acarretar . Certamente não é a situação ideal, mas esse é o caso há muitos anos e nada melhor surgiu. Enigmail é um projeto de poucas pessoas em seu tempo livre que vive de doações. Eles o apoiam há mais de 15 anos e, quando sabem que terão que matá-lo, até se oferecem para ajudar a equipe de desenvolvimento do Thunderbird a alcançar a integração. Ainda assim, o Thunderbird teve que enfrentar problemas de licenciamento para incorporar nativamente a criptografia em seu cliente , mas havia uma condição: se o esforço fizesse a Mozilla perder o foco no Firefox, não valeria a pena. Mas parece que está quase integrado. Podemos ver esta mensagem nas últimas versões do Thunderbird: Isso basicamente significa que eles não conseguiram combinar os dois sistemas por um tempo, nem o Enigmail nem o novo sistema integrado estão indo bem nas versões mais recentes. Você não lhes deu tempo. Portanto, é hora de escolher uma versão desatualizada do Thunderbird, se você quiser usar o OpenPGP com o Enigmail por um período. O que mais vai acontecer? Um sistema crítico não pode ser sustentado por boa vontade. É necessária uma massa crítica de uso (além da promoção), investimento (e não apenas doações), colaborações (além das boas palavras), infraestrutura e pessoas. Especialmente pessoas. Você não pode literalmente confiar em um técnico para uma parte crítica do sistema, porque ele coloca toda a sua funcionalidade em jogo. O software livre não pode estar desesperadamente procurando Kristian. Vá para a nuvem com confiança suportada pela ElevenPaths e Check PointAmeaças cibernéticas durante o COVID-19, uma investigação da Telco Security Alliance
Telefónica Tech Boletim semanal de Cibersegurança 11 – 17 Fevereiro Apple corrige 0-day explorado ativamente A Apple emitiu vários avisos de segurança para corrigir uma vulnerabilidade de 0-day explorada ativamente. A falha de segurança, listada como CVE-2023-23529, é uma confusão...
Telefónica Tech Boletim semanal de Cibersegurança 4 – 10 Fevereiro Vulnerabilidade crítica no Atlassian Jira A Atlassian emitiu um comunicado de segurança no qual lança correções para resolver uma vulnerabilidade crítica no Jira Service Management Server e no Data Center. De...
Telefónica Tech Boletim semanal de Cibersegurança 27 Janeiro – 3 Fevereiro LockBit Green: nova variante LockBit Pesquisadores da vx-underground detectaram recentemente que uma nova variante de ransomware, chamada LockBit Green, está sendo usada pelos manipuladores de ransomware LockBit. Esta nova variante seria...
Telefónica Tech Boletim semanal de Cibersegurança 21 – 27 Janeiro Killnet visando vítimas na Espanha Esta semana, o grupo hacktivista Killnet anunciou uma campanha de ataques contra a Alemanha, levando a ataques de Negação de Serviço Distribuído (DDoS) que tornaram...
Telefónica Tech Boletim semanal de Cibersegurança 14 – 20 Janeiro Vulnerabilidades críticas nos roteadores Netcomm e TP-Link Várias vulnerabilidades foram descobertas nos roteadores Netcomm e TP-Link. Por um lado, as falhas, identificadas como CVE-2022-4873 e CVE-2022-4874, são um caso de estouro de...
Telefónica Tech Boletim semanal de Cibersegurança 31 Dezembro – 6 Janeiro Cadeia de dependência do PyTorch é violada O PyTorch, uma popular estrutura de aprendizado de máquina de código aberto, alertou os usuários que instalaram o PyTorch todas as noites entre...