PplWare Mobile

Ultima hora: Ubuntu Forums da Canonical atacado !!!

                                    
                                

Este artigo tem mais de um ano


Autor: Pedro Pinto


  1. ADk says:

    Uso distro linux, obviamente ninguem está livre, mas ubuntu ou derivados é algo que nunca ficou instalado mais de 3 dias nas minhas maquinas.

  2. Eduardo Oliveira says:

    A questão que se pões é as hash’s tinham sal?
    Se sim esse sal foi visto?

    • pixar says:

      Não fazemos ideia como as passes eram guardadas. Mas se usaram o método de encriptação das passes dos utilizadores Linux, o sal estão lá junto das passes para quem quiser ver.

    • pixar says:

      Bem, pelo que é dito no site referido pelo Kunh4, tem sal que chegue.

      “You can stop worrying about your passwords. Yes, they were encrypted. Encrypted with the default vBulletin hashing algorithm (md5(md5($pass).$salt). Whilst it may not be the strongest, when you’re dealing with 1.8m users it would take a very long time to get anywhere with the hashes. You don’t have to worry about a DB leak. That isn’t how I like to do things.”

      Quase de certeza que este está visivel.

      • MD5?
        Quem é que ainda usa MD5 para encriptar passwords?
        O algoritmo tem vários erros e uma coisa que nunca deveria acontecer, colisão de hashs.

        Apesar do SHA1 também ter vários erros comprovados, é mais seguro que o MD5, principalmente se usarem o SHA256 ou superior.

        • pixar says:

          Pois, o MD5 tem alguns problemas como referiste.
          Claro que para passwords de registos pouco importantes em sites, serve.
          Para utilizadores de SO, isso podia ser uma desgraça.

        • Colisão de hash é inevitável, uma vez que o número de chaves é limitado (no MD5 é 2^128 chaves). O problema das colisões nos algoritmos de hash é quando essas colisões se conseguem provocar, ou seja, quando se consegue gerar a mesma chave com outro texto de entrada. O algoritmo MD5 é vulnerável a esse tipo de problema (e por isso não devia ser usado!). Desta forma, com a lista de chaves em MD5 (e supondo que se tem o texto de salt) seria possível a um atacante entrar com a conta de qualquer utilizador, mesmo não conhecendo a sua senha de acesso — basta encontrar uma que resulte na mesma chave MD5. Neste caso específico esse problema não existe, dado que o login foi desligado.

          De notar que a hipótese de conseguir descobrir a senha de acesso a partir da chave MD5, mesmo conhecendo o texto de salt, é bastante remota, a não ser para senhas comuns (nomes, datas de aniversário, etc.), o que torna difícil usar a lista conseguida com este ataque para acesso a outros serviços. De qualquer forma, foi correcta a atitude de alertar os utilizadores para alterarem as senhas idênticas noutros serviços: em segurança, mais vale prevenir que remediar. Aliás, toda a actuação da Canonical neste caso me parece, até agora, exemplar, desactivando o site logo que tiveram conhecimento do ataque (5 minutos depois do defacement) e alertando os utilizadores para o acontecido, quais os perigos a que estão expostos e quais as acções a tomar. Veremos se continuam assim no desenrolar da história.

    • NT says:

      Pode ter sal, pimenta, coentros… Uma salada.
      Mas hoje em dia não se trata de saber se a password pode ser quebrada mas sim quanto tempo isso demora. Portanto está na hora de mudar de password (PRINCIPALMENTE se usarem mesma passaword para tudo e mais alguma coisa).
      O que o ‘sal’ vai evitar é o seguinte (tentar explicar) Dois utilizadores, UserA e UserB e ambos utilizam a mesma password ‘chave’ ora se não houvesse sal a hash podia ser HDF3812343 (exemplo…) e era igual para os dois, ora ao se adicionar o sal, embora tenham a mesma password as hash’s são diferentes o que obriga a quem esteja a quebrar as passwords irá ter mais trabalho pois terá que quebrar uma a uma.

      Já agora façam um favor a vós mesmos, usem algo como o lastpass ou keypass e gerem password diferentes para cada site (e se for possível meterem passwords com mais de 12 digitos)

  3. Ru1Sous4 says:

    Qt ao deface ainda é naquela, agora o roubo do username/mail e passwords é preocupante :\

  4. KuNh4 says:

    Encontrei este tweet possivelmente feito pelo autor que fez esse ataque.
    Tweet: http://www.twitlonger.com/show/n_1rlft0d
    Link do twitter: https://twitter.com/Sputn1k_

  5. k says:

    Não estou muito preocupado. Este sujeito parece estar a fazer isto mais como forma de alerta do que por fins maliciosos. Mesmo pelos outros tweets dele.

    De certeza que a segurança ira ser reforçada por causa disto. No final é capaz de ter sido mais positivo que negativo.

  6. Carlos says:

    “Todos nós sabemos que não existe segurança informática perfeita!”

    É verdade.
    Mas não deixa de ser curioso que seja quem se gaba da segurança que seja vítima de falhas de segurança.

    Ou então foi em solidariedade com a Apple. Não devem ter querido que se sentissem sozinhos depois de uma “manutenção prolongada” ter deixado vários sites e fóruns da Apple fora do ar mais de 30 horas… Também não deixa de ser curioso isso não ter sido notícia.

  7. Tavares says:

    “De certeza que a segurança ira ser reforçada por causa disto. No final é capaz de ter sido mais positivo que negativo”.Isso é o que se poderá dizer em relação à “invasão” de qualquer outro site…ou esse raciocínio apenas é válido quando aparecem “buracos” no Linux??

    • k says:

      Deixa os favoritismos em casa, não leste nada do que eu disse que pudesse ser alusivo a alguma especificidade de sistema sistema em relação a outro. Se leres os tweets do gajo que fez isso, vais perceber que ele nao parece mal intencionado. E como ele próprio diz, é preferível ser ele a faze lo do que um grupo bem pior. Nesse sentido, se fosse conta mim, eu preferia que fosse um sujeito que o fizesse como brincadeira ou como prova de conceito onde o deface é feito apenas para provar possível do que para fins realmente maliciosos. Desta maneira de certeza que a empresa atacada vai tentar melhorar a segurança actual. Tem que o fazer. Com a vantagem acrescida que se a falha explorada for em software canonical ira também ser corrigida nas futuras distribuições o que será benéfico para todos os users.
      Custa perceber isso?

      • tavares says:

        Li perfeitamente o que teu comentário e os tweets do “dito cujo”.O que não estou é convencido da “bondade” dos mesmos,como pareces estar.Se “ele” pretendesse apenas a resolução do problema,teria comunicado o que “descobriu” á Cononical para “reparação” em vez de o publicar e “alertar” quem se quiser aproveitar da falha.Quanto a favoritismos acerca de produtos ou marcas,para mim não serve nem enfio a “carapuça”. Apenas sou fanboy das minhas filhas,e…mesmo com elas nem sempre estou de acordo!!

  8. honey says:

    o facebook é a solução, seguro

  9. sakura says:

    Canonical 6 anos linux + de 20 …….

    Canonical noobys….. pls

  10. Benchmark do iPhone 5 says:

    Para quem não souber, Saurik é o patrão do Cydia para iOS com jailbreak.

    Há tempos deu-lhe para criar também tweaks para Android. O pplware fez um post sobre o Cydia Substract que pôs no Google Play.

    Agora apresentou um fix, manual, para o Android Master Key (a vulnerabilidade descoberta pela Bluebox Security e que afecta Androids às carradas).

    http://www.idownloadblog.com/2013/07/21/saurik-posts-android-exploit/

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.