PplWare Mobile

Heartbleed: Saiba o que é esta vulnerabilidade e como o afecta!

                                    
                                

Este artigo tem mais de um ano


Autor: Pedro Simões


  1. Abílio says:

    Quem precisa da NSA?

  2. Antonio says:

    Eu gostava era de saber fazer um ddos

    • Para? Que ganhavas com isso?

      • Antonio says:

        simples….Para testar a capacidade dos meus serviços

        • Jorge Silva says:

          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

        • eleck says:

          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

    • Pedro Simões says:

      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.

  3. Pedro Pinho says:

    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

  4. Rui says:

    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,

  5. Luís Nabais says:

    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

    • Carlos says:

      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.

      • Nelson says:

        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.

        • Carlos says:

          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.

      • lmx says:

        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…

    • Carlos says:

      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.

    • Dlencastre says:

      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…

      • Carlos says:

        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)

      • lmx says:

        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…

    • Carlos says:

      “Numa escala de 1 a 10, isto é um 11”
      Bruce Schneier

      (não preciso dizer quem ele é, ou preciso?)

  6. Dlencastre says:

    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…

  7. Carlos says:

    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… 🙁

    • lmx says:

      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…

      • Carlos says:

        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.

        • Nunes says:

          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!

          • Carlos says:

            É, 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…

          • Nunes says:

            @ 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.

        • lmx says:

          “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..”

Deixe um comentário

O seu endereço de email não será publicado.

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

Aviso: Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. A administração deste site reserva-se, desde já, no direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.