Resumo de segurança de setembro de 2020

Bem-vindo à edição de setembro do Security Roundup mensal da SSL.com! Hoje vamos falar sobre:

• Novo SSL.com newsletter
• Mudanças no Fórum CA / B Diretrizes EV SSL
• Planos da Rússia para protocolos de proibição que escondem o destino do tráfego da internet
• A Ataque de guaxinim on TLS versões 1.2 e anteriores
• Inseguro Internet of Things (IoT) práticas
  

Anunciando o boletim informativo SSL.com!

SSL.com tem o orgulho de anunciar nosso novo boletim informativo mensal por e-mail! Todos os meses enviaremos notícias e informações sobre segurança na Internet, PKIe certificados digitais, junto com informações sobre novos produtos e serviços oferecidos por SSL.com. Para se inscrever, basta preencher o formulário abaixo. (Você pode cancelar a inscrição facilmente a qualquer momento clicando no desinscrever link em cada e-mail que enviamos.):

Votação do Fórum CA / B SC30: Mudanças nas Diretrizes de Certificado EV SSL

Em notícias de interesse para SSL.com's SSL EV clientes, a versão atual (1.7.3) do CA / Fórum do navegador Diretrizes de certificado EV SSL, que entrou em vigor em 20 de agosto de 2020, tem alguns novos requisitos. Especificamente, conforme descrito no Fórum CA / B Cédula SC30, as autoridades de certificação (CAs), como SSL.com, devem agora publicar a lista de agências de registro e incorporação que usam ao validar solicitações de certificado EV SSL. (A mudança está alinhada com um objetivo maior de tornar as fontes de validação EV consistentes entre os CAs.)

Como resultado, SSL.com publicará uma lista das fontes de informação que usamos ao validar empresas e outras organizações para certificados EV. Quando não conseguirmos localizar a organização de um candidato em nossa lista atual de fontes, tentaremos localizar outra fonte de informações viável e adicioná-la à nossa lista publicada antes de validar o pedido e emitir o certificado.

Rússia planeja banir protocolos que ocultam o destino do tráfego

Esta história pode parecer familiar, se você se mantiver atualizado com as notícias de segurança digital. Na verdade, no mês passado nós relatamos em uma história de que o "Grande Firewall" da China agora está bloqueando o tráfego HTTPS que usa TLS 1.3 e ENSI (Encrypted Server Name Indication) em um esforço para tornar mais fácil para os censores chineses verem quais sites os cidadãos estão tentando visitar e controlar o acesso a tais sites.

Este mês, um relatório de Catalin Cimpanu in ZDNet explicou que a Rússia agora está procurando proibir o uso de alguns protocolos com uma atualização das leis de tecnologia que “tornariam ilegal o uso de protocolos de criptografia que ocultam totalmente o destino do tráfego”. Conforme observado no artigo, esses protocolos incluiriam TLS 1.3, DoH, DoT e ESNI. O raciocínio é, naturalmente, muito parecido com o raciocínio por trás da proibição da China - os protocolos impedem a vigilância e o alcance da censura pelo Estado. Do artigo:

A Rússia não usa um sistema nacional de firewall, mas o regime de Moscou depende de um sistema chamado SORM que permite à aplicação da lei interceptar o tráfego da Internet para fins de aplicação da lei direto na fonte, nos centros de dados de telecomunicações.
Além disso, o ministério de telecomunicações da Rússia, o Roskomnadzor, tem executado um firewall nacional de fato por meio de seu poder regulatório sobre os ISPs locais. Na última década, Roskomnadzor baniu sites que considerava perigosos e pediu aos ISPs para filtrar seu tráfego e bloquear o acesso aos respectivos sites.
Com o TLS 1.3, DoH, DoT e ESNI ganhando adoção, todas as ferramentas atuais de vigilância e censura da Rússia se tornarão inúteis, pois dependem do acesso aos identificadores de site que vazam do tráfego criptografado da web.

A lei está atualmente sendo considerada, aguardando feedback do público, e retornará para votação no início de outubro. ZDNet observa que, dado o clima, “é quase certo que a emenda será aprovada”.

Novo TLS Ataque: Guaxinim

Nós já temos um blog sobre o "Ataque de guaxinim", mas vale a pena mencionar novamente, pois o ataque pode permitir que terceiros violem SSL /TLS criptografia para ler a comunicação destinada a ser mantida segura. Conforme explicado em um publicado recentemente trabalho acadêmico, o ataque explora uma vulnerabilidade de tempo em TLS versões 1.2 e anteriores e podem descriptografar comunicações que incluem nomes de usuário, senhas, dados de cartão de crédito e outras informações confidenciais. De nossa postagem no início deste mês:

Embora pareça assustador, tenha em mente que esse ataque só pode ocorrer em circunstâncias muito específicas e raras: o servidor deve reutilizar as chaves públicas Diffie-Hellman no aperto de mão (já considerada uma prática ruim), e o invasor deve ser capaz de fazer medições de tempo precisas. Além disso, o navegador deve oferecer suporte aos pacotes de criptografia vulneráveis ​​(em junho de 2020, todos os principais navegadores os abandonaram).

A Internet das Coisas (Vulneráveis), Coffee Maker Edition

Embora a história acima não fosse sobre ataques de guaxinins, essa história é realmente sobre cafeteiras. Para ser mais preciso, o artigo de Dan Goodin em Ars Technica é sobre como uma cafeteira foi transformada em uma "máquina de resgate" explorando fraquezas comuns nos dispositivos da Internet das Coisas (IoT).

Basicamente, os (pobremente nomeados) iKettle dos produtos Smarter têm sido um alvo para aqueles que procuram ilustrar os perigos de dispositivos facilmente hackeados. Desde 2015, versões da chaleira foram confiscados remotamente por meio de engenharia reversa. Embora a empresa tenha lançado uma nova versão do pote desde então, os antigos ainda estão em uso e, cara, eles são vulneráveis ​​ao que as notas do artigo são ataques "fora da caixa". Recentemente, um programador chamado Martin Hron decidiu testar os limites de como uma violação de segurança em uma cafeteira poderia parecer, na pior das hipóteses:

Quando Hron conectou pela primeira vez sua cafeteira Smarter, ele descobriu que ela agia imediatamente como um ponto de acesso Wi-Fi que usava uma conexão não segura para se comunicar com um aplicativo de smartphone. O aplicativo, por sua vez, é utilizado para configurar o aparelho e, caso o usuário queira, conectá-lo a uma rede Wi-Fi doméstica. Sem criptografia, o pesquisador não teve problemas em aprender como o telefone controlava a cafeteira e, como também não havia autenticação, como um aplicativo de telefone desonesto poderia fazer a mesma coisa.
Essa capacidade ainda deixava Hron com apenas um pequeno menu de comandos, nenhum deles especialmente prejudicial. Então, ele examinou o mecanismo que a cafeteira usava para receber atualizações de firmware. Acontece que eles foram recebidos do telefone com - você adivinhou - sem criptografia, sem autenticação e sem assinatura de código.

Há uma extensa postagem no blog sobre o hack da cafeteira chamada “O cheiro fresco do café resgatado. ” Há também um vídeo divertido demonstrando o caos que resultou da exploração das vulnerabilidades da máquina de café. Embora seja improvável que um ataque como este chegue à cozinha de alguém em breve, é um bom lembrete de que "inteligente" significa mais do que "conveniente".