PplWare Mobile

Engenheiro evitou, sem querer, possível grande ataque informático…

                                    
                                

Autor: Pedro Pinto


  1. Rodrigo says:

    Deve ter dedinho da NSA ou Unit 8200.

    • darth says:

      e porque assumes que sao americanos ou israelistas logo? ate parece que russia e china nao teriam interesse tambem

      • Fred says:

        E porque assumes que só a Russia ou a China teriam interesse no backdoor.
        A partir da informação veículada pela C.S. é estatísticamente mais provável vir dos USA ou Israel.
        E ao contrário de @Zé Fonseca A. considero que esta é uma demonstração das vantagens do open source e free software. Permitiu topar logo a causa!

    • não é relevante says:

      Tem mãos de filandeses, de Taiwan, etc..

      Tem ligação a unidades de crime organizado muito poderosas na ucrânia e fora dela, como o grupo c14, que é um grupo de fachada para …14 = I-A, c14 = cia, e este grupo é gerido a um alto nivel por israel…pronto pronto..judeus ucranianos, esta melhor assim?

      A microsoft está involvida, e muito provavelmente a NSA, até porque as tecnicas usadas são de tal forma avançadas que foram até a genese do algoritmo criptografico RSA…

      Eu já ha uns 6 meses que estou a investigar este e uma ramificação deste, relacionada com ataques a browsers, pois eu proprio já notei que era atacada em maio de 2023, de forma massiva, a reinstalação de SO não resolvia, reinstalei tudo, firmware, routers, etc..nada resolve.

      Como não confio nem em Russos, nem Chineses nem Americanos, e muito menos Alemães(de onde tenho sufrido cerca de 20% dos ataques que me fazem), nunca falei deste tema abertamente..

      Mas em suma, tenham cuidado com a quantidade de cpu usada pelo browser, eu sei eu sei, é muito dificil de testar, a forma mais basica de deitar o olho é fechar todas as tabs, deixar o browser aberto, e verificar o consumo de cpu..

      Também é muito importante deitar o olho constantemente á quantidade de sockets que estão abertos na máquina, é muito importante, e ao fazerem isso, vão perceber que a loucura que estamos a passar, é enorme!!!

      • Mike says:

        Gostava de perceber essa de sofrer 20% dos ataques de alemães… a Alemanha tem Datacenters e se sofre ataques de um IP de um Datacenter alemão, não quer propriamente dizer que o ataque é feito por alemães…
        E já agora, quem descobriu a falha (Andres Freund) é alemão… 😉

  2. Zé Fonseca A. says:

    Este CVE foi um mote à confiança no open source e na sua comunidade. Mais uns meses e tinha sido giro de ver.
    Para os que consideram código aberto mais seguro por estar em código aberto esta foi uma chapada de luva branca

    • Paulo Rodrigues says:

      +1

    • Elektro says:

      Open Source tem as suas vantagens e desvantagens. Mas a maior vantagem é exatamente a que está na notícia, alguém que não está diretamente associado ao desenvolvimento da biblioteca xz pôde analisar o repositório e identificar uma falha de segurança, se não fosse uma falha de segurança teria sido uma sugestão para otimização do código.

      Quantas falhas andarão por aí relacionados a código closed source que só teremos conhecimento depois dos estragos estarem feitos ? Até porque essas falhas (em closed source) são vendidas por quem as descobre para quem ter interesse das utilizar. Isto porque os bountys das empresas proprietárias são uma miséria.

      Tens o exemplo da malta que faz rips dos filmes nas plataformas: Netflix, Prime, HBO… usam uma falha do Widevine (DRM da Google) que não é publica para o fazer.

      • André R. says:

        Leste bem? Ele só detetou porque estranhou o lag em SSH “[…] a backdoor foi descoberta, pois Andres Freund debruçou-se a investigar o porquê das ligações por SSH passarem a ter o dobro de latência.[…]”.
        Se não fosse isso ele nem dava conta. Ele não foi verificar o código por iniciativa própria só porque não tinha nada pra fazer.

        • Elektro says:

          Tens toda a razão, abrir ticket para uma empresa de forma a obter uma resposta “Your feedback has been received.” é muito melhor!

    • André R. says:

      Não sabes o que escreves…

    • moinho de vento says:

      Oi?
      Portanto, ter um código aberto, em que até os logs de tudo estão acessíveis, no caso git, em que se sabe todo o fluxo feito para camuflar o “Backdoor”, por quem foi feito, e só não se preveniu isto porque, por exemplo, desativaram o fuzzing de teste à função que continha o código adulterado…
      Quer dizer, se isto fosse numa empresa em que ninguém tem acesso a esta informação, e mais, que a empresa nem deu pela falha, isso, sim, é segurança.
      Portanto, um funcionário adiciona uma função, que pode sempre dizer que tinha uma excelente intenção, só não previa que iria ser usada como “backdoor”, isso, sim, seria segurança.

    • Pedro Cunha says:

      Zé Fonseca, este CVE nunca seria um CVE se o código não fosse aberto.
      Em que medida seria útil o código ser fechado neste caso?

    • Manuel da Rocha says:

      A tal função foi encontrada em 87330733 milhões!!! de versões de Linux, a mais antiga foi publicada em Novembro de 2018 (ainda andam a ver em versões mais antigas que usavam outra função, na mesma biblioteca). Muitos milhões de utilizadores vão ter de actualizar as suas versões, assim como triliões de programadores terão de rever as suas distros, a ver se retiraram aquelas funções ou se ainda lá estão.

    • GNUUUUU! says:

      Open-source pode não ser exatamente sinónimo de segurança, mas de transparência é certamente. Penso que a segurança está mais associada à comunidade e na forma como essa está estruturada, havendo mais transparência (tanto no código como nos processos de desenvolvimento) há menos espaço para pessoas mal intencionadas conseguirem fazer ataques deste tipo. Já em closed-source é o contrário, zero transparência e potêncialmente as mesmas vulnerabilidades. Eu sei qual prefiro.

      • Croft Lara says:

        Justifica com o que quiseres, mas demonstra que mesmo com a “transparência” ninguém deu por ela até este indivíduo… Até se tivesse sido colocada lá para ver quanto tempo descobriam, demonstrou que andaram todos a dormir. Só como estudo de caso já demonstrou muito.

        • Pedro Cunha says:

          Demonstrou que a transparência de pouco serve se alguém mal intencionado e com um plano a longo prazo se infiltrar na equipa de desenvolvimento de uma peça de software de baixo nível quando essa equipa é muito pequena.

          Portanto, não é a transparência que está mal. Está mal haver apenas um programador a trabalhar nas xz-utils — foi por isso que foi admitido como colaborador o Jia Tan. Provavelmente falta aqui definir planos para assegurar a manutenção adequada de peças de software tão centrais (eventualmente adoptá-las na Linux Foundation, etc).

          Mas não podemos esquecer: o nível de sofisticação deste ataque era muito alto. Não se tratava apenas de inspeccionar commits para perceber que havia um problema. Há várias análises sobre o assunto feitas por pessoas da área; vale a pena ler.

        • libre says:

          quando são falhas, backdoors ou outra coisa qualquer manhosa que acontece em closed source também estava tudo a dormir não é

  3. Figueiredo says:

    Algo não bate certo nesta história.

    • says:

      Pois não. Para as alterações maliciosos terem entrado é porque alguém as aprovou. É muito fácil de saber quem as meteu e quem aprovou. Agora se só estão preocupados em saber a qual grupo de “hackers” culpar isso já é outra história. Mas uma ferramenta tão importante assim devia estar melhor vigiada…

      • Pedro Cunha says:

        As alterações maliciosas entraram porque o alegado culpado foi admitido como colaborador no repositório xz-utils, em parte por burn-out e incapacidade do autor original em responder a solicitações e alguma insistência dos utilizadores (alguns dos quais eram contas fictícias para forçar a admissão do tal colaborador, Jia Tan).

        Relativamente às alterações propriamente ditas, ainda existe o problema de que muitas delas isoladamente não levantam grandes suspeitas; aliás, o problema surge com ficheiros que não estão presentes no repositório mas sim nas tarballs disponibilizadas nas Releases (e as alterações de código até então feitas silenciosamente foram construindo caminho para fazer uso desses ficheiros com código malicioso obfuscado).

        Quanto à necessidade de vigilância de uma ferramenta tão importante: é um dos problemas do código aberto — muita gente acha que é gratuito e poucos pensam nas consequências da incapacidade dos programadores para fazer a manutenção desses projectos. Talvez este incidente traga alguma atenção a esse problema.
        Coitado do autor original nesta fase. Não tinha tempo antes, e agora ainda tem mais pressão em cima de si (apenas uma pessoa) para reverter o código problemático.

  4. Nirelle says:

    O Mint e o Ubuntu escapam quase sempre a estas falhas LOL!!
    Mas ficamos a saber que a Microsoft também usa Linux nos servidores 🙂

    • Zé Fonseca A. says:

      Claramente nunca viste uma subscrição azure na vida..

      • Nirelle says:

        Claramente nunca leste o texto…
        “Recentemente foi descoberta uma backdoor na biblioteca xz para Linux. Tal como referimos aqui, a backdoor foi descoberta, pois Andres Freund debruçou-se a investigar o porquê das ligações por SSH passarem a ter o dobro de latência.”

  5. ze says:

    Andam sempre a atirar a culpa para a china e rússia escondendo o verdadeiro culpado: o dark state dos EUA! Ou como a imprensa ocidental está toda manipulada por eles… Só os tapados que ainda não abriram os olhos é que continuam a ser enganados….

    • Tristan III says:

      É justamente o oposto: você foi enganado pelos media enviesados pró-Moscovo e pró-Pequim para acusar os EUA e o Ocidente de tudo.

      E agora, hã?

  6. Santos says:

    Não sei porquê, mas esse backdoor deve ter sido criado pela própria MS ou alguma “companhia”…

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.