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 março de 2021

Feliz Primavera a todos os nossos leitores! Bem-vindo a esta edição de março do SSL.com Security Roundup, na qual olhamos para outro mês passado em 2021. Especificamente, estamos olhando para o mês passado em segurança digital e coletamos o que consideramos ser o mais interessante coisas nesse reino, para você, abaixo.

eSigner oferece aos clientes SSL.com uma plataforma unificada e interface do usuário para documentos em nuvem e assinatura de código. Saiba mais sobre o eSigner.eSigner

IETF descontinua TLS 1.0 e 1.1

Já sabemos há algum tempo que TLS as versões 1.0 e 1.1 não são seguras. A Internet Engineering Task Force (IETF) acaba de torná-lo oficial com RFC 8996, que formalmente desativa esses obsoletos TLS versões.

Do resumo:

Este documento descontinua formalmente o Transport Layer Security (TLS) versões 1.0 (RFC 2246) e 1.1 (RFC 4346) Conseqüentemente, esses documentos foram movidos para o status Histórico. Essas versões não têm suporte para algoritmos e mecanismos criptográficos atuais e recomendados, e vários perfis governamentais e industriais de aplicativos que usam TLS agora mande evitar esses velhos TLS versões. TLS a versão 1.2 tornou-se a versão recomendada para os protocolos IETF em 2008 (posteriormente tornou-se obsoleto por TLS versão 1.3 em 2018), fornecendo tempo suficiente para a transição de versões anteriores. A remoção do suporte para versões mais antigas das implementações reduz a superfície de ataque, reduz a oportunidade de configuração incorreta e simplifica a biblioteca e a manutenção do produto.

Takeway de SSL.com: Desativar versões precoces e inseguras de SSL e TLS é um importante melhores práticas para segurança na Internet. Se você não tem certeza se TLS 1.0 e 1.1 ainda estão ativados em seus servidores, agora é um ótimo momento para verificar e atualizar suas configurações, se necessário. Confira esses recursos em SSL.com para obter mais informações:

O Chrome 90 será padronizado para HTTPS

A partir da versão 90, a barra de endereço do Chrome usará HTTPS como protocolo padrão. Isso significa que os URLs inseridos sem o prefixo, como a maioria dos usuários tendem a fazer, ficarão mais seguros https:// em vez de http://, que era o padrão do Chrome até este ponto. O switch tem implicações de segurança óbvias - HTTPS é mais seguro e evita a interceptação e espionagem criptografando o tráfego. A mudança pelo Chrome também oferece um aumento no desempenho, pois elimina a necessidade de redirecionamento do padrão anterior para o protocolo mais amplamente usado. Como relatado por do Blog do Chromium:

Além de ser uma melhoria clara de segurança e privacidade, essa mudança melhora a velocidade de carregamento inicial de sites que suportam HTTPS, uma vez que o Chrome se conectará diretamente ao endpoint HTTPS sem precisar ser redirecionado de http: // para https: //. Para sites que ainda não oferecem suporte a HTTPS, o Chrome voltará ao HTTP quando a tentativa de HTTPS falhar (incluindo quando houver erros de certificado, como incompatibilidade de nome ou certificado autoassinado não confiável, ou erros de conexão, como falha de resolução de DNS) .

Inicialmente, a mudança será implementada no Chrome Desktop e no Chrome para Android. Uma mudança para o Chrome no iOS seguirá.

Takeaway de SSL.com: Com a maioria dos sites agora habilitados para HTTPS, essa mudança no Chrome aumentará a segurança e a velocidade para os usuários. Obviamente, nós co-assinamos qualquer movimento que tenha esses objetivos em mente.

Verkada Hack expõe 150,000 câmeras de segurança

Em um início bastante desfavorável, uma startup do Vale do Silício conhecida como Verkada sofreu uma violação de segurança maciça. Os hackers assumiram o controle de mais de 150,000 câmeras localizadas em locais como prisões, delegacias de polícia, fábricas da Tesla, hospitais, academias e até mesmo nos escritórios da própria empresa. Por que essas câmeras estavam em locais tão sensíveis? Bem, porque a Verkada, infelizmente, é uma empresa de segurança. De acordo com um extenso relatório by Bloomberg's William Turton, os hackers conseguiram acesso através de um nome de usuário e senha encontrados online para uma conta de “Super Admin”, permitindo o acesso às câmeras de todos os clientes da empresa.

Esse acesso permitiu que os invasores vissem os quartos do hospital, entrevistas de testemunhas entre a polícia e suspeitos de crimes e ver quem havia usado o cartão de controle de acesso em um hospital de Tempe. Quanto à motivação por trás do hack, Bloomberg relatórios:

A violação de dados foi realizada por um coletivo internacional de hackers e pretendia mostrar a difusão da vigilância por vídeo e a facilidade com que os sistemas podem ser violados, disse Tillie Kottmann, um dos hackers que reivindicou o crédito pela violação de San Mateo, na Califórnia. Verkada. Kottmann, que usa os pronomes eles / eles, anteriormente reivindicou o crédito pelo hacking da fabricante de chips Intel Corp. e a montadora Nissan Motor Co. Kottmann disse que seus motivos para hackear são "muita curiosidade, luta pela liberdade de informação e contra a propriedade intelectual, uma grande dose de anti-capitalismo, uma pitada de anarquismo - e também é muito divertido não fazer isso. ”

O hack “expõe quão amplamente estamos sendo vigiados e quão pouco cuidado é colocado em pelo menos proteger as plataformas usadas para fazer isso, buscando nada além do lucro”, disse Kottmann.

Após o incidente, Verkada desativou todas as contas de administrador interno e iniciou uma investigação.

Takeaway de SSL.com: Evitando a crítica geral da vida em uma sociedade de vigilância, vamos nos concentrar na lição de bom senso aqui. Não exponha as credenciais de login na Internet, mas considere opções mais seguras, como autenticação baseada em certificado demasiado.

Principais falhas de segurança encontradas no software Netop Vision

Uma notícia assustadora para os pais que estão tentando aprender o restante do aprendizado em casa, as principais vulnerabilidades de segurança foram encontradas no Netop Vision - um software de aprendizado virtual popular usado por cerca de 3 milhões de professores e alunos. O Netop permite o aprendizado em casa servindo como um sistema de monitoramento de alunos que permite que os professores trabalhem remotamente nos computadores de seus alunos e é usado principalmente para gerenciar laboratórios de informática ou salas de aula nas escolas. Porém, por causa da Covid, os alunos levaram os computadores domésticos com o software para ensino a distância, aumentando seu alcance e vulnerabilidade.

Pesquisadores da McAfee anunciaram que encontraram quatro falhas críticas no software de gerenciamento de sala de aula. As falhas podem permitir que invasores assumam o controle de computadores, roubem credenciais ou instalem ransomware. De forma preocupante, os problemas de segurança também podem permitir que os hackers se façam passar por professores e observem os alunos.

Benjamin Freed em EdScoopName relatado sobre o problema em março:

Membros do Grupo de Pesquisa Avançada de Ameaças da McAfee testaram o programa Netop criando uma sala de aula virtual simulada, com um computador atuando como estação do professor e três dispositivos de alunos. Uma das primeiras coisas que os pesquisadores notaram foi que os perfis de usuário de professor e aluno apresentavam diferentes níveis de permissão. Eles também perceberam rapidamente que todo o tráfego de rede entre o professor e os alunos estava sendo enviado em pacotes não criptografados - incluindo capturas de tela das telas dos alunos sendo enviadas para o professor - sem a opção de ativar a criptografia.

“Com essas informações, a equipe conseguiu se disfarçar de professor, modificando seu código”, escreveram os pesquisadores da McAfee.

Depois de saber sobre o ataque, a empresa agiu rapidamente para corrigir a maioria dos problemas. No entanto, o software continua a usar conexões não criptografadas, o que é um risco contínuo.

Takeaway de SSL.com: Este é um bom lembrete de que qualquer software usado para aprendizado remoto (ou qualquer outra coisa remota, na verdade) deve usar criptografia de rede para evitar espionagem ou coisa pior.

 

 

Inscreva-se no boletim informativo de SSL.com

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