Questão Como usar a Internet enquanto o Heartbleed está sendo consertado?


Existem muitos sites que não são atualmente vulneráveis, mas não tenho idéia se eles estavam vulnerável há alguns dias.

Por exemplo:

  • twitter.com: Não está vulnerável no momento, mas o certificado é de quarta-feira, 5 de março 00:00:00 UTC 2014
  • google.com.br: não está vulnerável no momento, mas o certificado é de quarta-feira 12 de março 09:53:40 UTC de 2014
  • bankofamerica.com: Não está vulnerável no momento, mas o certificado é de qui Dez 05 00:00:00 UTC 2013

O que eu faço? Não usá-los até que eles reeditarem? Como sei que eles reemitem o certificado com chaves novas? Parece que eu nem deveria fazer login nesses sites para alterar minha senha porque não há como saber que eles são o verdadeiro site.


119


origem


Duplicação possível de O que os usuários finais devem fazer sobre o Heartbleed?em security.stackexchange.com - Philipp


Respostas:


Atualizações 2014-04-11

A Cloudflare configurou um desafio para verificar se a extração de chave privada era de fato possível. Foi feito com cerca de 100 mil pedidos, e verifica os medos. Não é mais teórico, mas provado. Você pode ir Aqui para ler sobre isso.

Além disso, Bloomberg relatou que o NSA tenho conhecimento sobre esta façanha para pelo menos dois anos. Isso faz sentido, pois a NSA tem os recursos para contratar analistas cujo único trabalho é encontrar explorações em software como este. Agora que sabemos que o governo dos EUA vem explorando-o por tanto tempo, a probabilidade de que outros estados o tenham conhecido e explorado é significativa.


TL; DR Fique atento aos anúncios das organizações sobre o status de seus sistemas, altere TODOS das suas senhas e observe as atividades fraudulentas / suspeitas em contas importantes, como bancos ou outros sistemas financeiros.

Para entender por que a situação é tão perigosa, primeiro precisamos entender o que esse ataque realmente faz. O CVE-2014-0160, AKA Heartbleed, é um bug overread buffer que permite que um invasor consiga até 64 kB de memória de um servidor executando uma versão vulnerável do OpenSSL.

Isso parece muito ruim. Como isto funciona na pratica

Você está certo, é uma falha séria, mas voltaremos a isso um pouco mais tarde. Agora vamos falar sobre por que a exploração funciona. Segurança da Camada de Transporte (TLS) é usado para proteger informações por muitos aplicativos, incluindo HTTP (HTTPS) ou para proteger SMTP se ativado por exemplo. No RFC 5246, que define os padrões para o TLS, existe uma função conhecida como heartbeat. O cliente e o servidor enviam alguns dados para manter a conexão ativa para que possa ser usada posteriormente. Agora, na prática, o cliente enviará alguns dados e o servidor apenas enviará de volta, e tudo estará ótimo. No entanto, nas versões afetadas do OpenSSL, não há verificação para ver se o cliente realmente enviou a quantidade de dados que ele disse ter feito. Então, se eu enviar 1 byte e dizer ao servidor que eu realmente enviei 64 kB, ele vai me enviar de volta 64 kB. De onde vêm esses outros bytes? Essa é a chave para o problema aí mesmo. O OpenSSL vai lhe enviar de volta 64 kB - 1 bytes de memória que o processo tem acesso e que você originalmente não enviou, dependendo de onde seu 1 byte está armazenado. Esses bytes extras da memória são o problema, pois podem conter informações valiosas, como material de chave privada¹ e informações que o servidor está descriptografando para usar. Exemplos disso seriam: senhas, informações de cartão de crédito e / ou PINs.

ESTÁ BEM. O que isso significa para segurança da informação? Se você entender como funciona a criptografia assimétrica, já sabe que isso é sério, já que a divulgação processa a criptografia apenas como ofuscação. Isso significa que, embora os servidores possam estar com patches e não estejam mais vazando memória, as sessões ainda podem estar inseguras. É possível que isso tenha sido explorado antes que fosse conhecido publicamente ou enquanto o patch estava ocorrendo, mas atualmente não há um método comprovado para mostrar que ocorreu um ataque. É possível que regras para IDSs pode se tornar disponível, mas a partir de agora esse não é o caso.  As regras do IDS foram liberadas. Isso por si só é extremamente perigoso, porque os operadores não sabem se suas chaves ainda estão seguras.

Somos forçados a presumir que as chaves vazaram, o que significa que é possível que tudo que você enviar através da rede possa ser descriptografado por terceiros. A única maneira de atenuar isso é regenerando chaves e obtendo novos certificados emitidos enquanto os antigos são revogados. Infelizmente, isso leva tempo como o CAs sem dúvida estão sendo inundados com esses pedidos agora. Ainda assim, isso deixa a possibilidade de ataque man-in-the-middleou outras oportunidades de phishing.

Quando será seguro? Saber quando será seguro é uma questão difícil. Algumas coisas que eu gostaria de sugerir são anúncios públicos explicando que o bug foi corrigido em seus ambientes ou que nunca foram vulneráveis, porque nunca usaram as versões afetadas. Quando eles anunciaram que tinham atualizado para uma nova versão do OpenSSL, eu garantiria que eles estivessem usando um novo certificado assinado depois de a data de lançamento público da exploração que era 2014-04-07.

** Observe que o tráfego anteriormente gravado pode ser descriptografado se a chave privada tiver vazado posteriormente.

O que posso fazer como usuário para me proteger?

Nos próximos dias, se você puder evitar o uso de sites críticos, como bancos on-line ou acesso a prontuários on-line, sugiro que o faça. Se você deve fazê-lo, entenda que sua sessão está potencialmente em risco e esteja preparada para aceitar as conseqüências disso. Além disso, depois que as organizações anunciam que não estão mais vulneráveis, você deve Mude sua senha; usar um gerenciador de senhas pode ajudar. Você também deve se preparar para alterar ou monitorar qualquer outra informação usada, como dados bancários ou números de cartão de crédito.

Aviso especial para ativistas

Qualquer coisa que usa o OpenSSL pode ser afetado, incluindo Tor. É possível que os governos tenham conseguido usar essa falha desde sua inclusão nas versões do OpenSSL há mais de dois anos, pois teriam os vastos recursos necessários para procurar explorações como essa e, como tal, você deve estar preparado para que as informações possam não seja mais privado.

** Observe que o tráfego anteriormente gravado pode ser descriptografado se a chave privada tiver vazado posteriormente, a menos que segurança avançada perfeita (PFS) foi implementado.

There- Houve alegações de que é provável que as chaves privadas não estivessem na memória, mas ao mesmo tempo houve alegações de extração de chaves bem-sucedida.  Neste ponto, é incerto qual lado está correto.


201



Este é de longe o texto mais informativo que eu li sobre este novo ataque Heartbleed (todos os outros artigos / blogs / posts de notícias continham apenas pedaços de informação). Bom trabalho :) . - Radu Murzea
Como podemos saber que novos certificados são gerados usando uma nova chave?
Note that previously recorded traffic may be decrypted if the private key was later leaked.   Não se o servidor estava usando uma cifra com sigilo de encaminhamento. - Wes
@Wes Você está certo de que o PFS provavelmente manteria o tráfego seguro. Eu estava tentando andar uma linha fina de explicar a situação sem confundir as pessoas. Infelizmente, o PFS não foi amplamente implantado. - Jacob
Resumindo what is heartbleed bug  xkcd.com/1354 - GoodSp33d


O risco apresentado por esta vulnerabilidade está sendo superado. Eu digo isso porque há ZERO evidência de que esta vulnerabilidade foi conhecida ou explorada antes de sua publicação pelos pesquisadores dois dias atrás.

Deixe-me ser claro, é urgente que sites vulneráveis, particularmente aqueles que transacionam dados sensíveis através da Internet, sejam corrigidos. É igualmente urgente que as assinaturas do ataque sejam carregadas nas ferramentas de proteção contra malware e IDS. Dentro da TI, devemos responder a essa vulnerabilidade com a mais alta prioridade.

Dito isto, não sinto que o nível de risco associado a esta vulnerabilidade pela imprensa pública seja justificado.

O que os indivíduos devem fazer para se proteger?  Não use sites que estão executando versões vulneráveis ​​do OpenSSL.

Até e a menos que haja evidência de que esta vulnerabilidade foi explorada, qualquer ação adicional é inútil e motivada por nada mais do que FUD. Você discorda? Considere as muitas vulnerabilidades lançadas a cada mês ou trimestre permitir a execução de código arbitrário. Aqueles que dão privilégios de root ou de nível de sistema ao invasor ou onde o invasor pode obtê-los subseqüentemente por meio do escalonamento de privilégios apresentam tanto ou mais risco à segurança de todos os dados manipulados pelos sistemas vulneráveis ​​como esta vulnerabilidade apresenta.

Em muitos casos, essas vulnerabilidades são descobertas pelo fornecedor de software ou pelos pesquisadores que informam o fornecedor. O fornecedor produz um patch e o libera para o mercado sem a publicação dos detalhes da vulnerabilidade. Em alguns casos, os detalhes são publicados e as explorações são publicadas pela comunidade de segurança para uso em ferramentas de teste. Nós não reagimos a essas muitas vulnerabilidades dizendo "Todos os nossos segredos PODEM ter sido expostos!"

Se há evidências de exploração, devemos reagir adequadamente a isso. Vejo grande risco na reação exagerada dos pesquisadores que anunciaram essa vulnerabilidade e na imprensa que amplificaram a conversa solta dos pesquisadores. Eles estão chorando lobo.

- El viejo


14



Esta resposta deve ser votada mais IMO. tem muito de vulnerabilidades publicadas todos os meses que permitiriam que as pessoas roubassem as chaves privadas dos servidores, e não é feito muito barulho sobre elas. Este é mais grave do que a média por causa da onipresença do OpenSSL, mas ainda está sendo superestimada. - alastair
"Até e a menos que haja evidência de que esta vulnerabilidade foi explorada" "Se houver evidência de exploração, devemos reagir apropriadamente." Você fala muito sobre evidências de exploração. No entanto, uma das coisas assustadoras sobre o bug Heartbleed é que exploração bem sucedida é indetectável após o facto (a menos que você esteja armazenando a mensagem de pulsação entrante toda a cada vez, perpetuamente, e mesmo assim não é garantido que a exploração bem-sucedida tenha levado a uma quebra de segurança). Como você propõe que nós estabeleçamos depois da evidência factual da exploração bem sucedida do bug? - Michael Kjörling
-1 porque esse autor não entende realmente a natureza dos ataques que eu não acho. Por um lado, os invasores que tinham esse tipo de acesso trabalhariam muito duro para mantê-lo em segredo e para não permitir que a intrusão aparecesse. Um bug desse tipo que reduz a segurança de cerca de metade do tráfego seguro na Internet não é lobo que chora. É uma questão muito séria, eu acho. - Eliptical View
Eu considero Bruce Schneier da mais alta consideração quando se trata de segurança de TI. Citar seu post no blog sobre a vulnerabilidade do Heartbleed: "Catastrófico" é a palavra certa. Na escala de 1 a 10, este é um 11. Só isso já é o suficiente para eu discordar fortemente da sua minimização do problema. - abstrask
Esta postagem deve ser desatualizada. O problema não está sendo ignorado, é uma falha catastrófica do OpenSSL, além do que, mesmo que não tenha sido usado até que seja anunciado publicamente, os jogadores ruins terão seus sites definitivamente comprometidos com ele posteriormente. Também é altamente provável que a NSA soubesse disso (mas isso não pode ser provado). Existem teorias convincentes apontando para este ser um compromisso deliberado, embora o autor nega. - davidgo


Nem todo site usa bibliotecas OpenSSL para HTTPS (também há GnuTLS e PolarSSL, por exemplo), e nem todas as versões do OpenSSL eram vulneráveis ​​(versões antigas não eram). Isso significa que há uma boa chance de os sites que você mencionou não alterarem os certificados porque não precisavam. Basta olhar para as datas em que os certificados foram emitidos não lhe diz o suficiente.

Existem várias ferramentas e sites que podem ajudá-lo a verificar se um site é vulnerável, por exemplo:  - http://filippo.io/Heartbleed- https://gist.github.com/mitsuhiko/10130454- https://www.ssllabs.com/ssltest/ 

Infelizmente, como você já afirmou, isso não diz se eles estavam. Receio que a questão chave aqui seja a confiança: não há maneira objetiva de verificar quais bibliotecas SSL elas usam e usam sem informações privilegiadas. Você tem que esperar que eles fizeram o que precisam fazer (porque é a coisa certa, ou até porque eles temem a humilhação pública) e se eles o fizeram, você pode apenas esperar que eles estejam abertos sobre isso.

É claro, você pode sempre perguntar a esses sites se eles foram afetados. Já vi diversos sites publicando declarações públicas sobre isso. Perguntar publicamente usando mídias sociais como o Twitter ou o Facebook geralmente funciona.

Portanto, o melhor conselho que posso dar é um conselho geral: tenha cuidado com o que você deixa para trás na internet e em quais sites você confia com suas informações pessoais.


5



aguarda o inevitável bug PolarSSL para aparecer (isto é próximo na lista ...) - strugee


Em relação às chaves privadas expostas, vale acrescentar que, embora alguém possa descriptografar dados em uma sessão criptografada, porque eles agora têm a chave privada, eles ainda precisarão se estabelecer como homem no meio da sessão. Nem todo mundo na Internet pode fazer isso.

Meu entendimento é que eles ainda precisarão estar interceptando o tráfego, seja na LAN local e ARP spoofing ou ser capaz de seqüestrar / redirecionar o tráfego anunciando rotas falsas para roteadores da Internet. Esse tipo de ataque sempre foi possível mesmo sem essa vulnerabilidade.


1



Não necessariamente verdade com o Heartbleed. O bug existe porque os dados (supostamente criptografados) podem ser expostos acessando a RAM. Portanto, eles não precisam interceptar / farejar o tráfego para explorar essa vulnerabilidade. No entanto, precisaria haver algum software malicioso instalado no servidor ou no cliente e também precisaria de acesso adequado para acessar a RAM. - ub3rst4r
Não tão. Ele pode ser comprometido por um ataque Man-In-The-Middle também. Além disso, o despejo de memória não afeta apenas essa sessão, é possível (dependendo do conteúdo do bloco de memória) ver nomes de usuário e senhas não criptografados de outros usuários, além de chaves privadas para facilitar a decodificação de todo o tráfego [via ataque MITM] - davidgo
Eu acho que deveria ter sido um pouco mais claro que eu estava principalmente referindo-se ao uso das chaves comprometidas depois que o servidor é corrigido. - PeterJ


Você pode inserir o URL de um site em Verificador Heartbleed LastPass e ele informará se o site foi ou ainda está vulnerável e quando seu certificado foi atualizado.

Há também uma extensão do Chrome chamada Chromebleed que avisará se você estiver visitando um site afetado pelo Heartbleed.

Mashable.com tem uma lista de sites bem conhecidos, se eles foram afetados e se você deve alterar sua senha. Curiosamente, nenhum dos sites da lista de Bancos e Corretoras foi impactado.


0





Eu também visitaria o seguinte site:

https://www.ivpn.net/blog/heartbleed-passwords-change

Eles têm uma lista de sites populares que foram afetados e quando e onde você deve alterar suas senhas


0





No geral, eu diria que não deixe a paranóia chegar até você. Realisticamente, apenas ser capaz de descriptografar o tráfego e obter sua senha não é o mesmo que ter feito isso.

Se você usar autenticação de dois fatores (e você deve) em sites como o Twitter, Facebook, Gmail e seu banco, então você não deve estar muito preocupado, e mesmo se você não estiver, provavelmente você está bem como está.

Se você sentir a necessidade de alterar todas as suas senhas, terá que ir em frente e fazê-lo onde achar necessário. Isso é tudo que existe para isso, realmente.


-1



a autenticação de dois fatores não impedirá que uma parte mal-intencionada faça qualquer coisa que seja possível em torno dessa exploração. Não tenho certeza do motivo pelo qual você mencionou. Ganhar acesso a suas contas sociais não é realmente a preocupação de alguém que possa aproveitar essa exploração no OpenSSL de qualquer maneira. - Ramhound
@ramhound Eu mencionei nos comentários antes dos comentários serem removidos, dois fatores ajudam porque, uma vez que um site tenha um novo certificado emitido, qualquer senha que um invasor possa ter não é mais útil. Como não faz sentido alterar uma senha até que um novo certificado seja emitido (e os servidores consertados), o que você ganha é a reconfiguração instantânea da conta de possíveis vazamentos de credenciais que podem ter ocorrido enquanto o invasor tinha a chave privada. Além disso, o Twitter e o Facebook são importantes, pois podem ser usados ​​como logon único para muitos outros sites (incluindo esse aqui eu acredito?) - Sirex
A senha ainda é útil porque as pessoas usam a mesma senha, sim, até pessoas que usam autenticação de dois fatores. Contanto que o invasor consiga basicamente descarregar os dados da sessão, eles podem executar um ataque MiTM contra você. - Ramhound
Sim, mas a reutilização de senhas é realmente uma falha separada. Meu ponto foi dois fatores ajuda a mitigar a gravidade e a longevidade do resultado, mas sim, isso não ajudará com o bug real sendo explorado. - Sirex
@Sirex Tanto quanto eu posso dizer que nenhum site que eu logar usando autenticação de dois fatores invalidou os cookies na minha máquina. Isto é, obviamente, um fracasso da parte deles, mas meu ponto é, no momento em que a autenticação de dois fatores não é um salvador. Um invasor pode facilmente interceptar os cookies e usá-los em seus próprios pedidos. Além disso, como não há como saber se alguém explorou esse bug (mesmo para os administradores do sistema), a única premissa segura é que ele foi explorado. Eu sei, por exemplo, que o chase.com ainda estava vulnerável até a manhã de quarta-feira. É improvável que os atacantes tenham perdido essa. - CrazyCasta