en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Resumo de segurança de dezembro de 2020

SSL.com deseja a todos os nossos clientes e visitantes uma temporada de férias feliz, segura e saudável e um próspero 2021! Esperamos que o novo ano seja um pouco menos, humm ... interessante de 2020 tem sido em alguns aspectos, mas temos certeza de que não passará um mês sem notícias importantes do mundo da segurança de rede, certificados digitais e PKI.

Vulnerabilidade OpenSSL DoS

Abordamos esse problema em um blog no início deste mês, mas vale a pena repetir. Uma vulnerabilidade de alta gravidade em OpenSSL foi descoberto que afeta todas as versões do OpenSSL 1.0.2 e 1.1.1 anteriores a 1.1.1i. Esta vulnerabilidade pode ser explorada para criar um ataque de negação de serviço (DoS). OpenSSL 1.1.1i, lançado em 8 de dezembro de 2020, inclui uma correção.

Os usuários do OpenSSL devem atualizar suas instalações o mais rápido possível. Existem dois caminhos para aplicar a correção:

  • Usuários de OpenSSL 1.1.1 e usuários 1.0.2 sem suporte devem atualizar para 1.1.1i.
  • Os clientes de suporte premium do OpenSSL 1.0.2 devem atualizar para 1.0.2x.

O OpenSSL está instalado atualmente na maioria dos servidores da web HTTPS. Você pode ler mais sobre a vulnerabilidade em SSL.com's blog, e no projeto OpenSSL's Aviso de Segurança.

Conclusão de SSL.com: Se você é um usuário OpenSSL e ainda não fez isso, leia o OpenSSL's consultivo sobre a vulnerabilidade e atualize sua instalação o mais rápido possível.

Cloudflare defende novos protocolos de privacidade

Tim Anderson relatado em The Register que Cloudflare está "pressionando para a adoção de novos protocolos de internet que diz permitir uma 'internet que respeita a privacidade'". Esses protocolos incluem privacidade aprimorada DNS sobre HTTPS (DoH), criptografia adicional para o TLS aperto de mãoe melhorias de segurança para o manuseio de senhas de usuários.

Esquecido DoH

DNS sobre HTTPS (DoH) aborda um elo fraco na privacidade da Internet criptografando consultas e respostas DNS, que têm sido enviadas historicamente como texto simples. DoH alheio (ODoH)  leva a proteção da privacidade do DNS um passo adiante, evitando que os servidores DoH saibam o endereço IP do cliente:

A essência do ODoH é que ele introduz um proxy de rede entre o cliente e o servidor DoH. O proxy não tem visibilidade da consulta DNS, que só pode ser lida pelo servidor DoH. O servidor não tem conhecimento do endereço IP do cliente. A consulta é privada, desde que o proxy e o servidor não entrem em conluio.

Cloudflare já declarou suporte para ODoH, que foi desenvolvido por engenheiros da Cloudflare, Apple e Fastly. Você pode aprender mais verificando seu papel em arxiv.org.

Hello do cliente criptografado (ECH)

Hello do cliente criptografado (ECH) oferece criptografia de handshake aprimorada em TLS, indo além SNI criptografado (ESNI), que protege apenas a Indicação do Nome do Servidor (SNI) no TLS aperto de mão. Christopher Patton, engenheiro de pesquisa da Cloudflare escreve,

Embora o ESNI tenha dado um passo significativo à frente, ele ficou aquém de nosso objetivo de alcançar a criptografia de handshake total. Além de ser incompleto - protege apenas SNI - é vulnerável a um punhado de ataques sofisticados, que, embora difícil de realizar, apontam para fraquezas teóricas no design do protocolo que precisam ser abordadas.
...
Em última análise, o objetivo da ECH é garantir que TLS as conexões feitas a servidores de origem diferentes por trás do mesmo provedor de serviços ECH são indistinguíveis umas das outras.

Sem surpresa, visto que ECH “só faz sentido ao lado do DoH e no contexto de uma CDN (rede de distribuição de conteúdo)”, a Cloudflare “se vê como um provável provedor de ECH”. Você pode ler mais sobre ECH no IETF's projecto de proposta.

Senhas OPAQUE

Senhas OPAQUE - “algum tipo de trocadilho com Função Pseudo-Random Oblivious (OPRF) combinada com Troca de Chave Autenticada por Senha (PAKE)” - é um mecanismo para evitar completamente a transferência da senha de um usuário para um servidor. O OPAQUE consegue isso “fazendo com que o servidor e o cliente calculem em conjunto um hash salgado para comparar usando um segundo sal intermediário. Isso garante que o servidor não descubra a senha do usuário durante a autenticação e que o usuário não descubra o sal secreto do servidor. ”

Você pode descobrir muito mais sobre as senhas OPAQUE em Neste artigo [Link do PDF] por pesquisadores da Universidade da Califórnia, Irvine e IBM, e pela engenheira da Cloudflare Tatiana Bradley blog.

Conclusão de SSL.com: Estamos sempre animados para aprender sobre novos protocolos de segurança de rede, especialmente no que se refere a PKI e certificados digitais. Traremos mais informações sobre esses e outros avanços de segurança e privacidade à medida que aparecem e são implementados.

Vazamento de credenciais de FTP possivelmente vinculadas ao ataque SolarWinds

A menos que você tenha passado as últimas semanas em uma cabine remota e fora da rede (não é uma má ideia agora que pensamos nisso), você provavelmente já ouviu bastante sobre o ataque à cadeia de abastecimento que comprometeu o software de monitoramento de TI Orion da SolarWinds e muitos de seus usuários no governo e na indústria. Ravie Lakshmanan em 16 de dezembro história no Hacker News discute como os invasores “provavelmente conseguiram comprometer a construção do software e a infraestrutura de assinatura de código da plataforma SolarWinds Orion já em outubro de 2019 para entregar o backdoor malicioso por meio de seu processo de lançamento de software”.

A ideia… era comprometer o sistema de construção, injetar silenciosamente seu próprio código no código-fonte do software, esperar a empresa compilar, assinar pacotes e, por último, verificar se suas modificações aparecem nas atualizações recém-lançadas conforme o esperado.

O cronograma de outubro de 2019 se alinha ao do pesquisador de segurança Vinoth Kumer descoberta, em novembro de 2019, de um repositório GitHub público vazando credenciais de FTP de texto simples para o servidor de atualização do Solarwinds - e que esse servidor estava acessível com a senha “solarwinds123.” O repo em questão estava aberto ao público “desde 17 de junho de 2018”, dando aos possíveis invasores tempo suficiente para descobrir e explorar as credenciais vazadas.

Claro, não ajudou o fato de a SolarWinds também aconselhar os usuários a desabilitar as medidas de segurança:

Para piorar as coisas, o código malicioso adicionado a uma atualização do software Orion pode ter passado despercebido pelo software antivírus e outras ferramentas de segurança em sistemas direcionados devido ao próprio SolarWinds assessoria de suporte, que afirma que seus produtos podem não funcionar corretamente, a menos que seus diretórios de arquivos sejam isentos de varreduras antivírus e restrições de objeto de política de grupo (GPO).

Conclusão de SSL.com: Assinatura de código é uma etapa importante, até mesmo obrigatória, para manter a confiança ao distribuir software aos clientes, mas depende de um ambiente seguro para ter sucesso. Proteger servidores cruciais com senhas fracas e fáceis de adivinhar e / ou expor inadvertidamente credenciais de texto simples ao público deixa uma porta aberta para ataques que exploram seu sistema de compilação para liberar software assinado, porém com Trojan.

Inscreva-se no boletim informativo de SSL.com

Não perca novos artigos e atualizações de SSL.com