{"id":32603,"date":"2019-10-31T21:47:55","date_gmt":"2019-10-31T18:47:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya\/"},"modified":"2019-10-31T21:47:55","modified_gmt":"2019-10-31T18:47:55","slug":"potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","title":{"rendered":"Ataques potenciais ao HTTPS e como se proteger deles","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Metade dos sites usa HTTPS<\/a><\/noindex>, e esse n\u00famero continua a crescer. O protocolo reduz o risco de intercepta\u00e7\u00e3o de tr\u00e1fego, mas n\u00e3o elimina as tentativas de ataques. Sobre alguns deles \u2014 POODLE, BEAST, DROWN e outros \u2014 e as formas de prote\u00e7\u00e3o, falaremos no nosso material.<\/p>\n

\"Ataques <\/a><\/noindex><\/a><\/noindex>
\n\/ Flickr \/ Sven Graeme<\/a><\/noindex> \/ CC BY-SA<\/i><\/p>\n

POODLE<\/h2>\n

\nA primeira men\u00e7\u00e3o ao ataque POODLE<\/a><\/noindex> foi em 2014. A vulnerabilidade no protocolo SSL 3.0 foi descoberta pelo especialista em seguran\u00e7a da informa\u00e7\u00e3o Bodo M\u00f6ller e seus colegas do Google.<\/p>\n

A ess\u00eancia do ataque \u00e9 a seguinte: um hacker for\u00e7a o cliente a estabelecer uma conex\u00e3o via SSL 3.0 emulando quedas de conex\u00e3o. Em seguida, ele procura mensagens marcadoras especiais no tr\u00e1fego cifrado em CBC<\/a><\/noindex>-modo. Com uma s\u00e9rie de requisi\u00e7\u00f5es falsas, o criminoso obt\u00e9m a capacidade de reconstruir o conte\u00fado das informa\u00e7\u00f5es que lhe interessam, como cookies.<\/p>\n

SSL 3.0 \u00e9 um protocolo desatualizado. Mas a quest\u00e3o de sua seguran\u00e7a ainda \u00e9 relevante. Os clientes o utilizam para evitar problemas de compatibilidade com servidores. Segundo alguns dados, quase 7% dos 100 mil sites mais populares ainda suportam SSL 3.0<\/a><\/noindex>. Al\u00e9m disso existem<\/a><\/noindex> modifica\u00e7\u00f5es do POODLE, cujo alvo s\u00e3o os mais modernos TLS 1.0 e TLS 1.1. Neste ano ganhou<\/a><\/noindex> novos ataques Zombie POODLE e GOLDENDOODLE, que contornam a prote\u00e7\u00e3o do TLS 1.2 (eles ainda est\u00e3o relacionados \u00e0 criptografia CBC).<\/p>\n

Como se proteger.<\/b> No caso do POODLE original, \u00e9 necess\u00e1rio desativar o suporte ao SSL 3.0. No entanto, isso pode causar problemas de compatibilidade. Uma solu\u00e7\u00e3o alternativa pode ser o mecanismo TLS_FALLBACK_SCSV \u2014 ele garante que a troca de dados via SSL 3.0 ocorrer\u00e1 apenas com sistemas antigos. Os criminosos n\u00e3o poder\u00e3o mais iniciar o downgrade do protocolo. A forma de prote\u00e7\u00e3o contra Zombie POODLE e GOLDENDOODLE \u00e9 desativar o suporte a CBC em aplicativos baseados em TLS 1.2. Uma solu\u00e7\u00e3o radical ser\u00e1 a migra\u00e7\u00e3o para o TLS 1.3 \u2014 na nova vers\u00e3o do protocolo, n\u00e3o \u00e9 utilizada a criptografia CBC. Em seu lugar, s\u00e3o aplicados m\u00e9todos mais seguros, como AES e ChaCha20.<\/p>\n

BEAST<\/h2>\n

\nUm dos primeiros ataques ao SSL e TLS 1.0, descoberto em 2011. Assim como o POODLE, o BEAST usa<\/a><\/noindex> Carater\u00edsticas da criptografia CBC. Os invasores inserem um agente JavaScript ou um applet Java na m\u00e1quina do cliente, que substitui mensagens durante a transmiss\u00e3o de dados via TLS ou SSL. Como os invasores conhecem o conte\u00fado dos pacotes 'falsificados', eles podem usar isso para decifrar o vetor de inicializa\u00e7\u00e3o e ler as outras mensagens ao servidor, como cookies de autentica\u00e7\u00e3o.<\/p>\n

Atualmente, as vulnerabilidades BEAST ainda afetam uma s\u00e9rie de ferramentas de rede<\/a><\/noindex>: servidores proxy e aplicativos de prote\u00e7\u00e3o de gateways de internet locais.<\/p>\n

Como se proteger.<\/b> O atacante precisa enviar requisi\u00e7\u00f5es regularmente para decifrar os dados. No VMware recomendam<\/a><\/noindex> reduza a dura\u00e7\u00e3o do SSLSessionCacheTimeout \u2014 de cinco minutos (recomenda\u00e7\u00e3o padr\u00e3o) para 30 segundos. Essa abordagem complicar\u00e1 a implementa\u00e7\u00e3o dos planos dos invasores, embora tenha algum efeito negativo na performance. Al\u00e9m disso, \u00e9 importante entender que em breve a vulnerabilidade BEAST pode se tornar obsoleta por conta pr\u00f3pria \u2014 a partir de 2020, os principais navegadores cessam<\/a><\/noindex> o suporte ao TLS 1.0 e 1.1. De qualquer forma, menos de 1,5% de todos os usu\u00e1rios de navegadores ainda utilizam esses protocolos.<\/p>\n

DROWN<\/h2>\n

\n\u00c9 um ataque cross-protocol que explora falhas na implementa\u00e7\u00e3o do SSLv2 com chaves RSA de 40 bits. O invasor escuta centenas de conex\u00f5es TLS do alvo e envia pacotes especiais ao servidor com SSLv2, que usa a mesma chave privada. Usando o ataque Bleichenbacher<\/a><\/noindex>, um hacker pode decifrar uma dessas aproximadamente mil sess\u00f5es TLS do cliente.<\/p>\n

O DROWN foi conhecido pela primeira vez em 2016 \u2014 e, na \u00e9poca, afetou um ter\u00e7o dos servidores<\/a><\/noindex> no mundo. Hoje, ainda \u00e9 relevante. De 150 mil sites mais populares, 2% ainda suportam<\/a><\/noindex> SSLv2 e mecanismos de criptografia vulner\u00e1veis.<\/p>\n

Como se proteger.<\/b> \u00c9 necess\u00e1rio aplicar patches fornecidos pelos desenvolvedores de bibliotecas criptogr\u00e1ficas, desativando o suporte ao SSLv2. Por exemplo, duas dessas corre\u00e7\u00f5es foram apresentadas para o OpenSSL (em 2016, eram as atualiza\u00e7\u00f5es<\/a><\/noindex> 1.0.1s e 1.0.2g). Atualiza\u00e7\u00f5es e instru\u00e7\u00f5es para desativar o protocolo vulner\u00e1vel tamb\u00e9m foram publicadas na Red Hat<\/a><\/noindex>, Apache<\/a><\/noindex>, Debian<\/a><\/noindex>.<\/p>\n

\"Um recurso pode ser vulner\u00e1vel ao DROWN se suas chaves forem usadas por um servidor externo com SSLv2, como um servidor de correio,\" observa o chefe do departamento de desenvolvimento do provedor de IaaS 1cloud.ru<\/a><\/noindex> Sergey Belkin. \u2014 Essa situa\u00e7\u00e3o ocorre quando v\u00e1rios servidores usam um certificado SSL comum. Nesse caso, \u00e9 necess\u00e1rio desativar o suporte SSLv2 em todas as m\u00e1quinas.<\/i><\/p><\/blockquote>\n

\nPara verificar se \u00e9 necess\u00e1rio atualizar seu sistema, voc\u00ea pode usar uma ferramenta<\/a><\/noindex> \u2014 desenvolvida por especialistas em seguran\u00e7a da informa\u00e7\u00e3o que descobriram o DROWN. Mais sobre as recomenda\u00e7\u00f5es relacionadas \u00e0 prote\u00e7\u00e3o contra esse tipo de ataque pode ser lido no post no site OpenSSL.<\/a><\/noindex>.<\/p>\n

Heartbleed<\/h2>\n

\nUma das maiores vulnerabilidades em software \u2014 Heartbleed<\/a><\/noindex>. Foi descoberta em 2014 na biblioteca OpenSSL. No momento do an\u00fancio do erro, o n\u00famero de sites vulner\u00e1veis era estimado em meio milh\u00e3o<\/a><\/noindex> \u2014 cerca de 17% dos recursos protegidos na rede.<\/p>\n

O ataque \u00e9 realizado atrav\u00e9s de um pequeno m\u00f3dulo de extens\u00e3o TLS chamado Heartbeat. O protocolo TLS exige que os dados sejam transmitidos continuamente. Em caso de inatividade prolongada, a conex\u00e3o \u00e9 interrompida e precisa ser restabelecida. Para lidar com o problema, servidores e clientes 'ruidosamente' artificialmente o canal (RFC 6520, p. 5<\/a><\/noindex>), transmitindo pacotes de comprimento aleat\u00f3rio. Se o pacote fosse maior que o pacote original, as vers\u00f5es vulner\u00e1veis do OpenSSL liam a mem\u00f3ria al\u00e9m do buffer atribu\u00eddo. Nesta \u00e1rea poderiam estar quaisquer dados, incluindo chaves de criptografia e informa\u00e7\u00f5es sobre outras conex\u00f5es.<\/p>\n

A vulnerabilidade estava presente em todas as vers\u00f5es da biblioteca entre 1.0.1 e 1.0.1f, inclusive, e em v\u00e1rias distribui\u00e7\u00f5es de sistemas operacionais \u2014 Ubuntu at\u00e9 12.04.4, CentOS ap\u00f3s 6.5, OpenBSD 5.3 e outros. Uma lista completa est\u00e1 dispon\u00edvel no site dedicado ao Heartbleed.<\/a><\/noindex>. Embora patches contra essa vulnerabilidade tenham sido lan\u00e7ados praticamente imediatamente ap\u00f3s sua descoberta, o problema ainda persiste. Em 2017, quase 200 mil sites<\/a><\/noindex>, ainda estavam vulner\u00e1veis ao Heartbleed.<\/p>\n

Como se proteger.<\/b> \u00c9 necess\u00e1rio atualizar o OpenSSL<\/a><\/noindex> para a vers\u00e3o 1.0.1g ou superior. Tamb\u00e9m \u00e9 poss\u00edvel desativar as solicita\u00e7\u00f5es de Heartbeat manualmente usando a op\u00e7\u00e3o DOPENSSL_NO_HEARTBEATS. Ap\u00f3s a atualiza\u00e7\u00e3o, os especialistas em seguran\u00e7a da informa\u00e7\u00e3o recomendam<\/a><\/noindex> devem reemitir os certificados SSL. A substitui\u00e7\u00e3o \u00e9 necess\u00e1ria caso os dados sobre as chaves de criptografia tenham sido comprometidos.<\/p>\n

Substitui\u00e7\u00e3o de certificado<\/h2>\n

\nUm n\u00f3 gerenciado \u00e9 estabelecido entre o usu\u00e1rio e o servidor com um certificado SSL leg\u00edtimo, interceptando ativamente o tr\u00e1fego. Esse n\u00f3 se apresenta como um servidor leg\u00edtimo, apresentando um certificado v\u00e1lido, permitindo a realiza\u00e7\u00e3o de um ataque MITM.<\/p>\n

De acordo com pesquisa<\/a><\/noindex> De acordo com especialistas da Mozilla, Google e v\u00e1rias universidades, cerca de 11% das conex\u00f5es protegidas na rede s\u00e3o 'ouvidas'. Isso \u00e9 resultado da instala\u00e7\u00e3o de certificados raiz suspeitos nos computadores dos usu\u00e1rios.<\/p>\n

Como se proteger.<\/b> Usar os servi\u00e7os de provedores SSL confi\u00e1veis<\/a><\/noindex>. Voc\u00ea pode verificar a 'qualidade' dos certificados por meio do servi\u00e7o Certificate Transparency<\/a><\/noindex> (CT). Provedores de nuvem tamb\u00e9m podem ajudar na detec\u00e7\u00e3o de 'escuta' \u2014 hoje, algumas grandes empresas j\u00e1 oferecem ferramentas especializadas para monitoramento de conex\u00f5es via TLS.<\/p>\n

Outra forma de prote\u00e7\u00e3o ser\u00e1 o novo especifica\u00e7\u00e3o<\/a><\/noindex> ACME, que automatiza a obten\u00e7\u00e3o de certificados SSL. Ao mesmo tempo, ele adicionar\u00e1 mecanismos adicionais para verificar a propriedade do site. Saiba mais sobre ele em um dos nossos materiais anteriores<\/a><\/noindex>.<\/p>\n

\"Ataques
\n\/ Flickr \/ Yuri Samoilov<\/a><\/noindex> \/ CC BY<\/i><\/p>\n

Perspectivas do HTTPS<\/h2>\n

\nApesar de v\u00e1rias vulnerabilidades, gigantes da TI e especialistas em seguran\u00e7a cibern\u00e9tica acreditam no futuro do protocolo. Pelo uso ativo do HTTPS \u00e9<\/a><\/noindex> o criador da WWW, Tim Berners-Lee. Segundo ele, ao longo do tempo, o TLS se tornar\u00e1 mais seguro, o que aumentar\u00e1 significativamente a seguran\u00e7a das conex\u00f5es. Berners-Lee at\u00e9 sugeriu que no futuro surgir\u00e3o<\/a><\/noindex> certificados de cliente para autentica\u00e7\u00e3o de identidade. Eles ajudar\u00e3o a melhorar a prote\u00e7\u00e3o dos servidores contra invasores.<\/p>\n

O desenvolvimento da tecnologia SSL\/TLS tamb\u00e9m est\u00e1 previsto com o uso de aprendizado de m\u00e1quina \u2014 algoritmos inteligentes ser\u00e3o respons\u00e1veis pela filtragem do tr\u00e1fego malicioso. Em conex\u00f5es HTTPS, os administradores n\u00e3o t\u00eam como saber o conte\u00fado das mensagens criptografadas \u2014 incluindo detectar solicita\u00e7\u00f5es de malware. J\u00e1 hoje, redes neurais podem filtrar pacotes potencialmente perigosos com uma precis\u00e3o de 90%. (slide 23 da apresenta\u00e7\u00e3o<\/a><\/noindex>).<\/p>\n

Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/h2>\n

\nAtaques ao HTTPS est\u00e3o, em sua maioria, relacionados n\u00e3o a problemas no pr\u00f3prio protocolo, mas ao suporte de mecanismos de criptografia desatualizados. A ind\u00fastria de TI come\u00e7a a abandonar gradualmente os protocolos de gera\u00e7\u00e3o anterior e oferece novas ferramentas para encontrar vulnerabilidades. No futuro, essas ferramentas se tornar\u00e3o cada vez mais inteligentes.<\/p>\n

Links adicionais sobre o tema:<\/h5>\n

<\/p>\n