Heartbleed: Saiba o que é esta vulnerabilidade e como o afecta!
O mundo da segurança da Internet foi abalado ontem com a descoberta de uma vulnerabilidade grave no OpenSSL, o Heartbleed, que permite que qualquer atacante consiga descobrir informações que deveriam estar seguras e não acessíveis.
Mas apesar da importância deste problema e do seu impacto, poucos podem ter tomado real consciência do que realmente significa para os utilizadores da Internet e para os sites que a compõem.
Para o utilizador comum o Heartbleed pode não ter a importância e o impacto que teve para a comunidade e para os gestores de sistemas espalhado pela Internet.
Esta é uma falha muito grave e que se devidamente explorada pode levar a que muita informação seja transmitida para os atacantes, revelando desde passwords a chaves de cifra, dando depois acesso em claro à informação que foi transmitida entre o servidor e os seus clientes, de forma cifrada.
A sua aplicação e execução é relativamente simples de fazer e os servidores afectados, tipicamente os que têm ainda instalada uma das versões do OpenSSL com problemas, podem nem se aperceber que estão a disponibilizar informação de forma indevida e que nem deveria ser propagada.
Este bug existe já há 2 anos e até agora não se conhece ainda o impacto que está a ter, sendo apenas conhecido que muitos dos principais sites da Internet estiveram expostos durante muito tempo.
Mas para que o utilizador comum tenha noção deste problema e do seu impacto, Zulfikar Ramzan, CTO da empresa Elastica especializada em segurança da Cloud, criou um vídeo que de forma muito simples e prática explica a forma como este bug acontece e quais as implicações de segurança que acarreta.
Como podem ver no vídeo apresentado, este é um problema grave e que afecta provavelmente muitos sites da Internet, não apenas de grandes empresas mas também de sites menores.
A solução é simples e passa pela actualização do SSL para uma versão que não tenha este bug, nomeadamente a 10.0.1f.
Este é apenas mais um bug de segurança associado às comunicações seguras. Depois da Apple no inicio deste ano, tanto no iOS como no OSX, muitos mais surgiram com outros sistemas a serem afectados.
Recordamos que devem realizar imediatamente a actualização dos vossos servidores para uma versão não afectada pelo bug, sob pena de estarem expostos ao problema.
Se ficaram interessados sobre o Heartbleed e querem saber mais sobre este problema que afecta a maioria da Internet, podem fazê-lo no site criado para a sua divulgação.
Homepage: Heartbleed
Este artigo tem mais de um ano
Proponha uma correção, faça uma sugestão
Loading ...
Quem precisa da NSA?
Já a NSA está 2 passos à frente deste Hearthbleed eheh
Eu gostava era de saber fazer um ddos
Para? Que ganhavas com isso?
simples….Para testar a capacidade dos meus serviços
Regra de informatica, prepara-te para o pior que pode acontecer.
Se os servidores forem a baixo (pq eles vao a baixo), que tipo de degradacao de servico tens implementado para tentar que o teu servidor seja utilizavel?
http://blog.codinghorror.com/working-with-the-chaos-monkey/
Isto e o que a netflix faz para testar os servidores deles…devias comecar por ai.
Para rebentares um servidor basta encontrares um administrador de sistemas que nao sabe o que faz e tem um servidor NTP mal configurado. Ha um pacote UDP em especifico que faz com que o servidor multiplique em N (muitas) de vezes o tamanho do teu pedido e envia-o para o destinatario.
J
um ddos não é mais que um dos só que com varias maquinas e sincronizadas. um dos é tu mandares varios pedidos (requests) de pagina ou de outro serviço ao servidor alvo, e o dos acontece quando tu mandas tantos pedidos ao servidor que este não consegue responder a todos e por esse motivo “estoura”, fica entupido. Fazer um dos rapido é simples fazes um programita na linguagem que quiseres em que este fazer requests http de uma pagina qualquer e pronto, agora o teu upload tem que ser grande para conseguires ultrapassar com os pedidos que mandas a capacidade de resposta do servidor
eu posso ensinar
vai ao site:
http://goo.gl/tgmXMJ
faz o download e depois colocas um D antes do DOS
E bum faz-se um DDOS.
é fácil e aconselho a fazer primeiro no teu PC para testar.
tens também a possibilidade de fazer um DDOS 1.1 ou um DDOS 2.0
Agora a sério deixa de pensar nisso.
Só uma pergunta: porque é que eu vejo 5 seg de video depois publicidade e depois video outra vez?
Antes dava para clicar na publicidade e o video começava logo a correr, agora não.
Sou só eu, ou agora temos que ver mesmo a publicadade toda, depois de 5seg de video?
Abraço
Boas tardes,
Aqui na noticia está “A solução é simples e passa pela actualização do SSL para uma versão que não tenha este bug, nomeadamente a 10.0.1f.”
Mas essa versão é uma das vulneráveis, segundo http://heartbleed.com/
A solução passa pela instalação da versão 1.0.1g, “Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.”
Cumprimentos,
Antes que todos entrem em pânico, leiam melhor o artigo, já há packages para quase todas as distribuições com as correcções.
Podem ler mais neste artigo: http://www.muktware.com/2014/04/heartbleed-serious-openssl-bug-patched-linux-distros/25273
E vais tu instala-los nos literalmente milhões de servidores afetados? E nos serviços em que *não* pode haver interrupções? E nos casos em que, sabe-se lá porquê, alguma coisa vai deixar de funcionar depois da atualização.
Nos servidores que “não” podem haver interrupções?
Que é que tem?
Sempre que tens essa exigência, tens uma máquina ao lado que faz tudo o que faz a primeira, atualizas uma máquina e depois atualizada a segunda, depois a terceira, etc…
Pensavas que era só um computador 😉
Mesmo que fosse, não havia problema em manter o serviço, normalmente para esses casos, utilizam-se máquinas virtuais.
Num mundo perfeito isso seria verdade, mas o que não falta por aí é empresas que têm servidores críticos que muitas vezes nem backups têm…
Para não ir mais longe, onde eu trabalho agora, numa grande seguradora, o “servidor” de várias aplicações críticas para o negócio é um PC desktop que está na mesa ao lado da minha.
Felizmente tem o Windows Server 2008R2 e o IIS 7.5 por isso desta escapou.
vais ter que ter uma maquina em standby como o nelson referiu, para que quando aconteça qualquer anomalia, ligares a nova maquina…desligares a outra, depois de verificares que não existem mais requests, a serem processados nessa maquina…
no entanto é ou pode ser chato…porque imagina que o servidor afectado serviu uma maquina com cokie de sessão, o que vai fazer com que todos os requests dessa sessão sejam pedidos aquele servidor :S
tem que ser bem feito, não é tão trivial assim…mas claro, depende do serviço..se for uma coisa critica, tem que ser bem feito, não pode ser em cima do joelho
Se o serviço não for problemático…então basta o que disse acima…
As sessões que não funcionarem…a pessoa ao atualizar a página já resolve o problema…
E ainda… Vais garantir que ninguém roubou as chaves privadas dos certificados de todos os sites de todos os bancos do mundo que usam versões vulneráveis do opensssl?
Vais tu substituir todos os certificados, pelo sim pelo não?
Isto é um bug de consequências gigantescas, tentar menorizá-lo dizendo que “ah e tal mas já há uma atualização” é no mínimo perigoso.
as chaves teem que ser novas…grande jogada para os certificadores 😉
O problema não está no tardar de resposta. O problema está na identificação do problema e na verificação dos danos, na implementação em sistemas de alto desempenho e maquinas redundantes e os respectivos testes. Eu não acredito em soluções imediatas, ou seja, se já saiu a correcção das duas uma: Ou já conheciam o bug ou é algo feito em cima do joelho.
Agora é que isto vai dar que falar. Neste momento há milhares de crackers a tentar qualquer coisa para ver como funciona e como se evolui…
nops, a solução é simples, validar o tamanho do buffer de entrada. é coisa que se faz nuns 5 minutos…
a questão mais grave de fundo é como é que ainda andamos a sofrer com bugs de overflows de buffers em 2014.
e porque é que o openssl não usa as funções nativas do libc que não deixariam passar o erro (o openssl crashava, o que seria um mal menor, pelo menos até alguém descobrir como executar código depois do buffer overflow. mas isso é mais complicado)
a resposta é muito tardia…o bug foi detectado em 2012…estamos em 2014 :S
Não era é pelos vistos uma coisa simples de resolver…ou ninguém se apercebeu da coisa…
“Numa escala de 1 a 10, isto é um 11”
Bruce Schneier
(não preciso dizer quem ele é, ou preciso?)
No mínimo este facto de de x em x segundo fazer o request e obter os dados da memoria do OpenSSL é assustador.
impressionante como se descobrem estas coisas…
para validar se o site é seguro:
https://lastpass.com/heartbleed/
felizmente o meu banco, a CGD, usa servidores Windows para os sites, menos uma coisa com que me tenho de preocupar.
só fica a faltar tudo o resto… 🙁
mas…isto nada tem a ver com o sistema operativo…mas sim com o sistema de encriptação…que funciona em todos os SO’s :S
GNUTLS…
Bom, o Windows não utiliza nem o GnuTLS nem o OpenSSL, por isso está imune aos problemas de ambos.
Já o OS X, o iOS, as várias distros do Linux e as várias variantes do BSD usam ou um ou o outro ou ambos, por isso se não forem atualizados estão vulneráveis aos problemas de ambos, com azar dos dois ao mesmo tempo.
O iOS não tem qualquer vestígio do OpenSSL, e o OSX não usa OpenSSL para estas comunicações, usa a mesma biblioteca do iOS para o protocolo. Há uma versão do OpenSSL no OS X só para manter compatibilidade com aplicações BSD, mas mesmo essa versão não é afectada por este bug!
É, mas eu não disse que usa o OpenSSL, ou disse.
Acho que toda a gente sabe que o iOS e o OS X usam o GnuTLS, que é o responsável por aquele bugezito em que ambos aceitavam tudo o que era certificado “à confiança”.
E bom, tirando a Apple, quem mais usa o OS X em servidores? Nem o John “Daring Fireball” Gruber usa…
@ Carlos
Tb não usam o GnuTLS – provavelmente nem a licença seria compatível! Usa o Secure Transport, feito pela Apple, tb open source.
Este bug não afecta só os servidores, embora sejam os servidores que ficam mais vulneráveis e os mais preocupantes. Dado que foste tu a mencionar o iOS pensei até que saberias isso!
Quanto a usar o OS X como servidor, na verdade é bastante usado como servidor local para administrar serviços a outros Macs.
“Bom, o Windows não utiliza nem o GnuTLS nem o OpenSSL, por isso está imune aos problemas de ambos.”
Se usares um nginx, apache, etc no windows…estás a usar openssl…ou gnutls…por isso afecta da mesma forma…o openssl não existe apenas no linux…e derivados do unix…
Tu estás a ver a coisa pelo lado do cliente…no windows salvo erro chrome e firefox usam nss salvo erro, mas existe muito software no windows a correr openssl…
Até o próprio office da Ms tem suporte para se poder utilizar openssl..nos locais que seja necessário…está tão vulnerável como os outros…
Não há almoços grátis nestas coisas…comem todos pela mesma medida :S
e ja nem vamos falar das extensões AES que existem nos procs actuais e que se desconfia terem trojans da NSA…porque se formos por ai…bom “é a loucura total..”