regina@cryptoid.com.br

Estamos em novo endereço. Encontre-nos lá!

Faça parte desse projeto você também!

Conteúdo

O objetivo desse Blog é apresentar essa fantástica e importante tecnologia, de forma simples, para que pessoas que não dominam aspectos técnicos também possam acompanhar a evolução da adoção da Certificação Digital e o universo que gira ao seu redor:

Certificado Digital para Assinatura e Sigilo, Certificado de Atributo, Carimbo do Tempo, Documentos Eletrônicos, Processos Eletrônicos, Nota Fical Eletrônica, TV Digital, Smart Card, Token, Assinador de Documento, Gerenciador de Identidades etc..

Este Blog publica matérias e artigos extraídos da mídia que expressam a opinião dos respectivos autores e artigos escritos por mim que expressam, exclusivamente, minha opinião pessoal sem vínculo a nenhuma organização.

Matérias organizadas por data de publicação

sexta-feira, 25 de abril de 2014

Entendendo e resolvendo o problema da Vulnerabilidade #Heartbleed

A Vulnerabilidade Heartbleed é um bug severo na popular biblioteca de criptografia chamada OpenSSL. 














A falha permite roubo de informação protegida pelas criptografias nos protocolos SSL/TLS, esta que é de comum uso para segurança na internet. Os protocolos SSL/TLS fornecem comunicação segura e privacidade em conexões de internet, muito utilizados em aplicações web, email, mensageiros instantâneos (IM) e redes de comunicação privadas (VPNs).

Este bug permite que qualquer pessoa na internet seja capaz de ler uma parte da memória ram dos sistemas protegidos pelo OpenSSL. Assim comprometendo as chaves de identificação que os serviços utilizam para criptografar o tráfego, este que pode conter usuários, senhas e o conteúdo enviado pelo usuário. Isso permite que invasores que estão monitorando sua comunicação, sejam capazes de roubar suas informações que estariam criptografadas inicialmente.

Como posso identificar sites vulneráveis?


Existe uma lista com os principais sites do mundo que estão sofrendo verificações periódicas, você pode ver esta lista aqui: https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt

Também é possível testar um site específico de sua preferência por uma ferramenta chamada Heartbleed Test

Além disso você pode instalar uma extensão para o Google Chrome que irá te avisar se o site navegado está vulnerável: ChromeBleed

O que é CVE-2014-0160?


CVE-2014-0160 é a referência oficial da falha. CVE (Common Vulnerabilities and Exposures, Vulnerabilidades e Exposições públicas) é um padrão para catalogar e padronizar as vulnerabilidades de segurança da informação, a CVE é mantida pelo MITRE. Como houve uma dupla descoberta da falha, existe um outro registro de CVE , o CVE-2014-0346, este que não deve ser utilizado, pois a falha se tornou pública pelo CVE-2014-0160.

Por quê esta falha é chamada de Heartbleed?


A falha está na implementação TLS/DTLS proveniente da extensão heartbeat (RFC6520) do OpenSSL. Quando ela é explorada ela vaza informações da memória do servidor para o cliente, assim como do cliente para o servidor. Pelo fato do vazamento, bleed em inglês e o nome da extensão se chamar heartbeat, a faha foi apelidada de Heartbleed.

O que torna a falha Heartbleed única?


A falha está presente apenas em um software, este que já está corrigido nas versões mais novas, porém esta falha permitiu que uma enorme quantidade de chaves privadas de criptografia fossem expostas a internet, considerando esta exposição e a facilidade de ataque e exploração da falha de forma imperceptível, tornou esta falha extremamente séria e perigosa.

Isso é uma falha na concepção da especificação do protocolo SSL/TLS?


Não. Este é um problema de implementação, no caso, um erro de programação na popular biblioteca OpenSSL, que provê serviços de criptografia como o SSL/TLS para aplicações e serviços.

Na prática, como a negação e a reemissão dos certificados funciona?

Se você é um provedor de serviços, em algum momento você se registrou com a sua autoridade de Certificado digital ( Certificate Authority (CA)). Então você deve checar como chaves comprometidas podem ser checadas e reemitidas. Algumas CAs fazem esta reemissão de forma gratuida, outras cobram.

Eu estou afetado pela vulnerabilidade?


É provável que você seja afetado direto ou indiretamente. A OpenSSL é a mais popular biblioteca de criptografica e implementação TLS (Segurança da camada de transporte) de código aberto utilizada em encriptação de tráfico na internet. Sua rede social, o site da sua empresa, os sites comerciais, sites que você utiliza para instalar softwares ou até os sites que seu governo utiliza estão vulneráveis com o OpenSSL. Muitos serviços online usam TLS para identificar eles mesmo para você e para proteger sua privacidade e suas transações. Você pode ter soluções em rede com logins protegidos pela implementação do TLS com a vulnerabilidade. Além disso você pode ter aplicações no seu computador que poderiam expor seus dados se você estiver conectado a serviços comprometidos.

O quão a falha está difundida?


Software mais notável usando OpenSSL são os servidores web de código aberto como Apache e nginx. A combinação desses dois servidores detém aproximadamente 66% dos sites ativos na internet, veja Netcraft\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'s April 2014 Web Server Survey. Além disso o OpenSSL é utilizado para proteger por exemplo: servidores de e-mail (protocolos SMTP, POP e IMAP), servidores de bate-papo (protocolo XMPP ), rede virtual privada (SSL VPNs), soluções de rede e uma ampla variedade de aplicações ao lado do cliente. Felizmente grandes sites comerciais estão salvos pela escolha conservadora de seus equipamentos de terminais SSL/TLS e software. Ironicamente serviços menores e mais progressivos ou aqueles que atualizaram para a melhor e última criptação serão os mais afetados. Além disso o OpenSSL é muito popular em aplicações do lado do cliente e de alguma forma popular em soluções de rede que são mais atraídos em se atualizar.

Quais as versões afetadas do OpenSSL?


Relação de diferentes versões: 
OpenSSL 1.0.1 até 1.0.1f (inclusive) estão vulneráveis 
OpenSSL 1.0.1g NÃO está vulnerável 
OpenSSL ramificação 1.0.0 NÃO está vulnerável 
OpenSSL ramificação 0.9.8 NÃO está vulnerável 

A falha está incluída no OpenSSL desde dezembro de 2011, e foi amplamente difundida desde o OpenSSL versão 1.0.1 de 14 de março de 2012. A versão do OpenSSL 1.0.1g que foi liberada em 7 de abril de 2014 contém a correção da falha.

Quão difundidas são as versões vulneráveis do OpenSSL?


As versões vulneráveis estão disponívels há dois anos agora e elas foram adotas rapidamente pelos sistemas operacionais modernos. O maior fator de contribuição foi que as versões TLS 1.1 e 1.2 ficaram disponíveis com a primeira versão OpenSSL (1.0.1) vulnerável e a comunidade de segurança vem forçando a TLS 1.2 devido a ataques mais antigos contra TLS (como o BEAST).

E os Sistemas Operacionais?


Algumas distribuições de sistemas operacionais que possuem a versão com a vulnerabilidade no OpenSSL: 
Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4 
Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11 
CentOS 6.5, OpenSSL 1.0.1e-15 
Fedora 18, OpenSSL 1.0.1e-4 
OpenBSD 5.3 (OpenSSL 1.0.1c 10 maio 2012) e 5.4 (OpenSSL 1.0.1c 10 maio 2012) 
FreeBSD 10.0 - OpenSSL 1.0.1e 11 fevereiro 2013 
NetBSD 5.0.2 (OpenSSL 1.0.1e) 
OpenSUSE 12.2 (OpenSSL 1.0.1c) 

Algumas distribuições de sistemas operacionais que NÃO possuem a versão com a vulnerabilidade no OpenSSL: 

Debian Squeeze (Versão estável antiga), OpenSSL 0.9.8o-4squeeze14 
SUSE Linux Enterprise Server 
FreeBSD 8.4 - OpenSSL 0.9.8y 5 fevereiro de 2013 
FreeBSD 9.2 - OpenSSL 0.9.8y 5 fevereiro de 2013 
FreeBSD Ports - OpenSSL 1.0.1g (Em 7 de abril às 21:46:40 2014 UTC) 

Como o OpenSSL pode ser corrigido?


Mesmo que a correção pareça trivial, o time da OpenSSL está expert em resolver de maneira apropriada a falha, assim a última versão 1.0.1g ou mais novas devem ser usadas por estarem corrigidas. Se isso não for possível, desenvolvedores pode recompilar o OpenSSL sem o parâmetro do heartbeat utilizando a opção -DOPENSSL_NO_HEARTBEATS no momento da compilação.

A extensão heartbeat deve ser removida com o intuito de ajudar na deteção de serviços vulneráveis?


A recuperação dessa vulnerabilidade poderia beneficiar se a nova versão do OpenSSL corrigisse a falha como desabilitasse temporariamente o heartbeat até algumas futuras versões. Parece que a maioria se não quase todas implementações TLS que respondem a requisição heartbeat hoje são versões vulneráveis de OpenSSL. Se somente versões vulneráveis de OpenSSL continuassem a a responder ao heartbeat pelos próximos meses se tornaria mais factível alcançar proprietários de serviços vulneráveis.

É possível detectar se alguém aproveitou a falha e usou contra mim?


O abuso desta falha não deixa qualquer tipo de vestígio ou informações incomuns nos logs.

É possível que IDS/IPS possam detectar e bloquear o ataque?


Mesmo o conteúdo da requisição heartbeat seja encriptado ele tem seu próprio tipo de registro no protocolo. Isto deve possibilitar detecção de intrusos e a prevenção de sistemas (IDS/IPS) de ser treinado para detectar o uso da requisição heartbeat. Devido a criptografia diferenciar entre o uso legítimo e ataque não pode ser baseado no conteúdo da requisição, mas a invasão pode ser detectada pela comparação do tamanho da requisição pelo tamanho da resposta. Isso parece implicar que IDS/IPS pode ser programado para detectar a invasão mas não bloquear a menos que todas as requisições heatbeat sejam bloquedas juntas.

Já houveram muitos ataques?


Nós não sabemos. A comunidade de segurança deve implantar TLS/DTLS honeypots que capturam invasores e alertam sobre a tentativa de invasão.

O invasor pode acessar realmente só 64 kilobytes da memória?


Não há uma limitação de 64 kilobytes no ataque, esse limite se aplica somente a um único heartbeat. O invasor pode fazer diversas conexões durante uma sessão TLS ativa e continuar extraindo setores de 64 Kilobytes até que o conteúdo desejado seja totalmente revelado.

Este é um ataque man in the middle como ocorreu na Apple?


Não, essa vulnerabilidade não requer man in the middle (MITM). O invasor pode diretamente contatar o serviço vulnerável ou atacar qualquer usuário conectado a um serviço malicioso. Entretanto, além da ameaça direta o ladrão da chave possibilita aos invasores man in the middle personificar serviços comprometidos.

Os clientes de autenticação TLS conseguem lidar com isso?


Não, a requisição heartbeat pode ser enviada e respondida durante a etapa de pareamento do protocolo. Isso ocorre antes da autenticação do certificado do cliente.

O modo FIPS do OpenSSL consegue lidar com isso?


Não, o OpenSSL Federal Information Processing Standard (FIPS) não possui efeito algum sobre essa vulnerabilidade.

O Perfect Forward Secrecy (PFS) minimiza esta vulnerabilidade?


O uso do Perfect Forward Secrecy (PFS), o que, infelizmente, é raro mas poderoso, pode proteger comunicações antigas de descriptografia retrospectiva. Por favor, veja https://twitter.com/ivanristic/status/453280081897467905 como chaves que vazaram podem afetar este recurso.

A extensão heartbeat pode ser desabilitada durante o pareamento do protocolo TLS?


Não, o código da extensão vulnerável heartbeat é ativado independemente do resultado da etapa de negociação e pareamento. O único caminho para se proteger é fazendo a atualização para uma versão corrigida do OpenSSL ou recompilar o OpenSSL sem a extensão heartbeat.

Quem encontrou a vulnerabilidade Heartbleed?


Esta falha foi uma descoberta independente feita pelo time de engenheiros de segurança (Riku, Antti and Matti) no Codenomicon e Neel Mehta do Google Security, o qual foi o primeiro a reportar isso ao time da OpenSSL. O time da Codenomicon encontrou a vulnerabilidade heartbleed enquanto melhoravam o SafeGuard, recurso do Codenomicon\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'s Defensics, ferramenta de testes de segurança que reportou essa falha ao NCSC-FI para a coordenação de vulnerabilidade e reportou ao time OpenSSL.

O que é Defensics SafeGuard?


A SafeGuard, recurso da Codenomicon Defensics, é uma ferramenta de segurança que automaticamente testa o sistema alvo procurando fraquezas que comprometam a integridade, proteção ou privacidade. Esta é uma solução sistemática que expõe falhas em certificados de criptografia, vazamentos de privacidade ou fraquezas na autenticação que tenham exposto os usuários da internet ao ataque man in the middle e ao hacking eavesdropping. Além da falha HeartBleed o novo recurso da Defensics TLS Safeguard pode detectar por exemplo a falha de segurança no amplamente utilizado GnuTLS, aplicação de código aberto que implementa a funcionalidade SSL/TLS no \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"goto fail;\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\", falha na implementação TLS/SSL da Apple que foi corrigida em Fevereiro 2014.

Quem coordena a resposta a esta vulnerabilidade?


NCSC-FI tomou a tarefa de informar os autores do OpenSSL, softwares, sistemas operacionais e fornecedores de soluções, que foram potencialmente afetados. Entretanto, esta vulnerabilidade foi encontrada e os detalhes foram lançados de forma independente por outros, antes que este trabalho estivesse completo. Fornecedores de serviços pela internet devem notificar seus usuário onde e quando uma ação deve ser tomada.

Existe um lado bom de tudo isso?


Para aqueles provedores de serviços que foram afetados esta é uma boa hora de melhorar a segurança das chaves de criptografia utilizadas. Muitos softwares receberam updates, estes que geralmente não são atualizados. Mesmo que isso seja muito doloroso para a comunidade de segurança, nós temos certeza que a infra-estrutura de criminosos virtuais e seus segredos foram expostos também.

Onde encontrar mais informação?


Este Q&A foi publicado como sequência ao aviso da OpenSSL, desde de que sua vulnerabilidade tornou-se pública em 7 de abril de 2014. O projeto OpenSSL fez uma declaração oficial em seu site https://www.openssl.org/news/secadv_20140407.txt. NCSC-FI publicou um aviso em https://www.cert.fi/en/reports/2014/vulnerability788210.html. Fornecedores individuais de distribuições de sistemas operacionais, proprietários afetados de serviços de Internet, pacotes de software e fornecedores de soluções podem emitir seus próprios avisos.


Fonte: Via Alcyon Ferreira de Souza Junior  e  http://www.portaltic.com
http://heartbleed.com (texto original, publicado 7 de abril de 2014, ~19:00 UTC)
Renato Mendes Figueiredo | Renatomefi IT Solutions
Samuel Mendes
 https://github.com/renatomefidf/heartbleed

quinta-feira, 24 de abril de 2014

Celulares da Nokia poderão ter criptografia quântica



O servidor envia fótons através de um cabo de fibra óptica para o dispositivo menor, que pode ser incorporado em um telefone celular.[Imagem: P. Zhang et al./10.1103/PhysRevLett.112.130501]


Com informações da New Scientist - 23/04/2014

Quando tudo parecia perdido em termos de privacidade e segurança da informação, a Nokia anunciou uma solução que permite incluir nos telefones celulares o que há de mais seguro na codificação de dados: a criptografia quântica.

Engenheiros da empresa, em colaboração com pesquisadores da Universidade de Bristol, no Reino Unido, criaram o primeiro dispositivo de criptografia quântica de bolso.

O objetivo é permitir que os usuários enviem mensagens completamente seguras.

Ao menos por enquanto a conexão não poderá ser totalmente sem fios - será necessário conectar o celular a uma espécie de "cabine telefônica quântica", por meio de uma conexão de fibra óptica.

Chaves públicas

As transações seguras pela internet usam a criptografia de chave pública, que é muito boa, mas pode ser quebrada por um intruso poderoso o suficiente.

Já uma chave quântica, que não pode ser duplicada sem que se destrua a original, pode gerar códigos virtualmente inquebráveis.


Até agora, no entanto, apenas bancos e grandes empresas podem pagar pelo grande e caro equipamento necessário para isso.

Criptografia quântica portátil

Para democratizar a criptografia quântica, a equipe do professor Anthony Laing dividiu o sistema tradicional de codificação quântica em dois.

A parte volumosa ficará em um "servidor", que teria o tamanho de uma caixa de cerveja, contendo os componentes maiores, como um laser e um gerador de fótons individuais.

O servidor envia fótons através de um cabo de fibra óptica para o dispositivo menor, que pode ser incorporado em um telefone celular.

O dispositivo portátil inclui um guia de onda que altera o estado dos fótons que o atravessam, criptografando a mensagem. Em seguida, ele devolve os fótons alterados para o cabo de fibra óptica, que os leva de volta para o servidor.

A Nokia já patenteou a tecnologia, mas ainda não anunciou quando ela será transformada em um produto ou incorporada em um celular.

Já existe pelo menos um sistema de criptografia quântica portátil no mercado, embora sem tanta flexibilidade quanto um sistema incorporado em um celular.
Bibliografia:

Reference-Frame-Independent Quantum-Key-Distribution Server with a Telecom Tether for an On-Chip Client
P. Zhang, K. Aungskunsiri, E. Martín-López, J. Wabnig, M. Lobino, R. W. Nock, J. Munns, D. Bonneau, P. Jiang, H. W. Li, A. Laing, J. G. Rarity, A. O. Niskanen, M. G. Thompson, J. L. O Brien
Vol.: 112, 130501
DOI: 10.1103/PhysRevLett.112.130501
Fonte: