iPOG: falha crítica no macOS permite coleta de senhas em plain text

macos-high-sierra

O macOS High Sierra mal chegou e já foi descoberta uma falha gravíssima no sistema: uma vulnerabilidade 0-day (que afeta também as versões Sierra e El Capitan) revelada pelo profissional de segurança Patrick Wardle, um ex-NSA que hoje trabalha para a Synack permite que programas maliciosos coletem dados extremamente sensíveis dos usuários, de senhas a números de cartões de crédito.

E o pior: em plain text.

O processo é simples e ardiloso: o macOS utiliza um sistema de gerenciamento de senhas chamado Keychain (ou “Chaveiro”) que guarda uma série de informações consideradas sensíveis, bem como chaves criptográficas e números de cartões de crédito, além de informações de login de apps e serviços. É uma prática normal para manter tais dados a salvo, desde que o sistema em si seja seguro o bastante para evitar intrusões. Coisas como criptografia, quando aplicadas aos dados também são uma boa pedida.

Só que não é bem o que acontece. Wardle descobriu que um app remoto é capaz de acessar o Keychain com certa facilidade e coletar os dados dos usuários, mas o problema maior reside no fato de que não é preciso um grande esforço para isso: programas não-autenticados pela Apple, instalados de forma forçada pelo usuário (por padrão o macOS bloqueia tais apps, mas não é difícil contornar as restrições do SO) ou mesmo versões legítimas que tenham sido comprometidas (antes que pergunte sim, o CCleaner também é compatível com o sistema da maçã) poderiam em tese ser capazes de realizar o ataque. Isso posto, conseguir uma licença junto à Apple só demanda o pagamento de US$ 99 por ano e nem é algo tão difícil assim de um desenvolvedor mal intencionado conseguir.

Wardle revelou que os testes foram bem sucedidos não só no macOS High Sierra, mas também nas versões Sierra e OS X El Capitan; isso significa que boa parte dos Macs ativos hoje estão vulneráveis a ataques do tipo. Porém o mais inacreditável é que Wardle conseguiu coletar todas as informações do Keychain em plain text. Não houve nenhum tipo de resistência, uma criptografia protegendo as informações, nada.

O vídeo abaixo mostra o ataque em curso:


Steal y0 (macOS) Keychain from patrick wardle

Wardle informa que notificou a Apple no último dia 7, semanas antes do High Sierra ser lançado e só pretende revelar como chegou à vulnerabilidade assim que a maçã corrigir a falha, algo que ainda não foi feito. Em nota, um porta-voz da Apple disse apenas que “o macOS é seguro por padrão” e que o sistema avisa o usuário para não instalar qualquer coisa no sistema (dando a entender que Wardle teria forçado a barra, quando é o que profissionais de segurança costumam fazer). Ele só não explicou por que diabos o SO armazena senhas em plain text.

Sejamos sinceros aqui: é óbvio que boas práticas por parte do usuário e/ou administradores de rede (em caso de máquinas corporativas) é imperativo para evitar a instalação de aplicativos suspeitos nos Macs, mas a Apple também não fez sua parte: a facilidade com que os atacantes podem extrair informações extremamente sensíveis do Keychain, ainda mais em plain text é imperdoável, é um POG digno da quizumba que era o app do Starbucks. É uma demonstração cabal de preguiça por parte dos desenvolvedores da maçã, provavelmente por acreditarem na baboseira “o macOS é o sistema mais seguro que existe”.

Não custa nada lembrar: não existe sistema 100% seguro. Seja por brechas no código, malícia ou mera ingenuidade sempre haverão falhas e os hackers, tal qual a Cosa Nostra não perdoam. É importante que o usuário saiba que não deve instalar qualquer coisa no macOS, Windows ou Linux mas também é obrigação das empresas ao menos fazerem o dever de casa.

Fonte: Extreme Tech.

Relacionados: , , , , , , , , , , , ,

Autor: Ronaldo Gogoni

Um cara normal até segunda ordem. Além do MeioBit dou meus pitacos eventuais como podcaster do #Scicast, no Portal Deviante.

Compartilhar
  • O Gogoni ensinando a Apple a fazer software corretamente. Achar que seja preguiça, POG, etc é simplificar demais, pois não estamos falando de uma startup. Podem haver motivos mais complexos para ser assim. Vamos ver.

    • ffcalan

      Poder até pode, mas é difícil de acreditar. Visto já vimos empresas de grande porte fazerem cagadas no mesmo nível, e até maior. Vide Sony.

      • O forte da Sony não é software ou segurança, e sim hardware. Diferente da Apple que prima por softwares de primeira linha e faz isso por 30 anos.

        • ffcalan

          Isso não faz nenhum sentido. Do que adianta um ótimo hardware se o software é um lixo e vice-versa?

    • Nenhum, NENHUM motivo justifica guardar senhas em plain text. Isso é o básico do básico em Segurança da Informação.

      • E por que a grande Apple pisaria na bola com isso? Preguiça? A Apple preguiçosa? Me parece uma explicação muito superficial.

        • Diogo

          Porque a culpa “é do usuário”… Sim, é uma explicação superficial, que o próprio Jobs já deu uma vez.

          • Mas eu não falei isso.

          • Diogo

            Mas eu falei. Entenda: a Apple às vezes tem o hábito de fazer tal coisa (ou deixar de fazer) não pra agradar o usuário ou pra cumprir algum requisito de segurança ou usabilidade, e sim porque aquilo foi feito “pra isso” (e depois coloca a culpa no usuário que não sabe usar direito).

        • Dou uma e se for bom dou mais

          Sim, preguiça. Freebsd que é o backend do OS da Apple e o Linux fazem criptografia da keychain e descriptografam em memória protegida não liberando assim dados em plain. Se eles DESLIGARAM isso (porque vem por padrão) foi por preguiça de fazer como nos dois de colocar um pedido de senha de criptografia no primeiro uso da sessão.

      • Luiz Rodrigo Martins Barbosa

        O Keychain é criptografado. Mas eventualmente você precisa fazer o “unlock do Keychain” pra pode usar as chaves que estão lá. Apps fazem isso o tempo todo, o Safari faz isso, afinal a senha precisa ser colocada no campo.

        A falha que ele descobriu deve ser uma elevação de privilégio indevido que permite fazer o unlock do Keychain inteiro.

        • Dou uma e se for bom dou mais

          No linux isso é feito em memória protegida portanto o unlock não permitira acesso em plain text, porque no da apple que usa freebsd (que é mais fresco que linux) isso tem que ser complicado.

          • Wallacy

            Mesmo em memoria protegida a chave é a mesma. Se ele obteve a chave já era.

          • Dou uma e se for bom dou mais

            Claro, porque afinal de contas você consegue ler memória protegida… A única coisa que você conseguiria era ler uma senha digitada e não o arquivo e a senha digitada poderia ser qualquer coisa desde comentário inútil até uma carta para a mãe morta.

      • Vinicius Teixeira Coelho

        O motivo de guardar em plain text nesse caso é bem justificado. As informações gravadas no keychain ou em qualquer outro software que é um repositório para as suas senhas tem a senha em plain text. O repositório tem que ser criptografado, mas no momento que você entra com sua chave para descriptografar o repositório a senha por exemplo do seu e-mail que esta no software vai aparecer em plain text, ou como você faria para copiar a senha e colocar no site que você quer acessar? Qualquer entrada de senha é feita em plain text, lá no bando de dados do serviço que você esta tentando acessar ai sim deve ser um hash da senha, mas não é esse o caso do keychain.

        • Dou uma e se for bom dou mais

          Só que no linux a keychain é criptografada e não tem problema nenhum, digita a senha da keychain no primeiro uso da seção e bom divertimento, porque no da apple pode ser diferente?

          • Wallacy

            Mas a Keychain é criptografada, com a senha do usuário. O problema ai é ele ter conseguido esse acesso.

          • Dou uma e se for bom dou mais

            Só que tem a contrachave do sistema que só permite acesso ao dado pedido e não ao arquivo.

          • Wallacy

            E quem disse que ele obteve o arquivo? O vídeo e o post original é claro. Ele da um print na plist com os dados brutos (que é request), que tem os dados criptografados, logo após ele da um print com os dados descriptografados, que é o output do app dele.

            Da pra fazer isso via apple script, basta obter a lista de entradas na keychain (publico), pedir key por key e inserir a chave do usuario, que foi o que ele obteve.

            O misterio aqui é como ele obteve a chave do usuario.

    • Cãopetente em obras

      Não é o Gogoni ensinando a Apple. Ele simplesmente noticiou o absurdo. Um pesquisador descobriu uma falha no MacOs e a maçã disse que o sistema é seguro, somente isso, não notificando o pesquisador se essa falha será consertada, não divulgando a causa do problema e dando a entender que a culpa é do pesquisador (que cumpriu a sua missão de descobrir falhas, já que isso torna os sistemas seguros) que simplesmente poderia não ter notificado a Apple ou a sua base de usuários, já que o mesmo não possui essa obrigação.

  • Todo sistema é vulnerável, menos a urna eletrônica. hahaha

    • Kleber Leal

      É claro que a urna não é inviolável, mas pra quê se arriscar montando uma megaoperação hacker e correr o risco de ter a chapa caçada? Eleitor brasileiro entrega o voto estupidamente, não é necessário adulterar urnas.

      A América Latina é um celeiro do populismo. Brasil não é diferente. É infinitamente mais fácil angariar votos com as mesmas promessas insossas e genéricas no horário eleitoral – as famigeradas saúde, educação e segurança. Dar alguma coisa também funciona. Nós adoramos os presentinhos que o papai Estado dá.

      Some-se a isso tudo a obrigatoriedade do voto e pronto. Nem é preciso encostar nas urnas.

      • Dou uma e se for bom dou mais

        “Eleitor brasileiro entrega o voto estupidamente, não é necessário adulterar urnas.”
        E com isso salva-se uma alma! (ou não se você é ateu, dai você vai pro inferno de qualquer jeito aeuhauahauhaeuhae).

  • Pelo que entendi, o grande problema foi o dev conseguir acesso ao conteúdo do keychain sem a senha da conta do usuário. É apenas esta senha que proteje, localmente, o keychain.
    Fica a dúvida se QUALQUER app que precisa desta senha pra rodar pode acessar o keychain na surdina.
    Quanto a armazenar em plain text, acho que é como o pessoal aí falou. Na ponta server é inaceitável, na ponta client tem que estar em plain text em algum lugar, ou o usuário não consegue acessar, copiar, ver etc. Faz sentido?

    • Dou uma e se for bom dou mais

      Não, o linux usa o mesmo sistema e a keychain só fica em plain text se o usuário resolver não colocar senha na keychain (que é separada da senha de login, o que melhroa a segurança).

    • Rodrigo M

      O problema é que se é acessado sem a chave do usuário o dado ou está guardado sem criptografia ou está criptografado com alguma chave interna (que pode ser descoberta anyway).

  • Dou uma e se for bom dou mais

    Tem o mesmo chaveiro no linux… até o xubuntu core ou lxde minimal vem com esse chaveiro. Plain text fica apenas quando o usuário decide não colocar uma senha (que é pedida apenas uma vez no primeiro uso da sessão).
    Agora… no mac… que usa o primo metido a besta do linux (freebsd) como retaguarda e os caras ainda conseguem fazer essa mercadoria. Dai vem dizer que o usuário é que é tóxico.

    • Cãopetente em obras

      É uma feature. Seus usuários que não sabem utilizar o sistema da forma correta, de forma mágica™.

    • Wallacy

      Sim, no Linux o store fica em Plain Text quando o não se adiciona senha na sessão.

      Porem o OSX não é FreeBSD. Ele apenas usa diversos recursos do FreeBSD, como outros sistemas.

      O FreeBSD tem um kernel monolítico com módulos dinâmicos, enquanto o Darwin (OSX) usa kernel híbrido via sistemas de mensagem. O FreeBSD trouxe a parte BSD/POSIX ao kernel XNU, porém boa parte do Darwin (XNU) é composta pelo Kernel Mach. A parte de segurança e qualquer coisa que não seja a a parte posix compilance não faz parte.

      São bem diferentes no fim do dia, no fim prefiro tudo é *unix-like* em algum nível.

      • Dou uma e se for bom dou mais

        COMO EU DISSE FREEBSD COMO RETAGUARDA e não que o OSX é freebsd, portanto o OSX pode muito bem HERDAR RECURSOS que no freebsd é padrão.

        • Wallacy

          Calm down buddy! Nesse recinto aqui Caps não são muito bem aceitos, muito menos necessário.

          E dizer: “linux (freebsd) como retaguarda” não tem significado algum sem contexto! Como eu disse, a unica parte FreeBSD do Darwin é os módulos posix. E isso não tem nada haver com implementações de alto nivel de segurança como é o caso da Keychain.

          “Poder herdar” recursos qualquer um pode, até o Windows pode herdar o método de segurança da Keychain, já que isso nada tem haver com a implementação posix do kernel.

          Fun Fact: Windows se tornou posix antes do Linux.

          • Dou uma e se for bom dou mais

            NOSSSA AQUI NÃO SE ACEITA CAPS. QUE PENINHA DO FLOQUINHO QUE NÃO SABE LER E RECLAMA QUANDO FRISAM O TEXTO PRA VER SE ELE CONSEGUE.

          • Wallacy

            Você é novo aqui não é? Pelo visto por pouco tempo.

          • Dou uma e se for bom dou mais

            MIMIMIMI ELE TÁ USANDO MAISUCULAS E EU NÃO AGUENTO MIMIMIMIMI

          • tuneman

            Camarada, não perca tempo com esse ignorante.

  • Que bola fora vergonhoso hein devs do Mac!
    Não existe sistema seguro, mas aposto que se fosse o Windows os fanboys iriam zoar né?

  • Esr Da Silva Esr

    Matéria errada, Apple não tem falhas, com certeza é uma característica.

    • Firmo

      Concordo, Apple é perfeita, devem estar loucos ou entendendo errado…

  • Wallacy

    Não sei se o Gogoni já usou o OSX, ou outros aqui que estão comentando, mas a Keychain não é armazenada em PlainText, basta ir no db da Keychain e verá que ela é criptografada. O que o camarada fez foi obter o acesso a chave, que é a senha do usuário local, isso sim é o grande problema.

    Teste simples: Entre na Keychain, encontre um registro, peça pra ver a senha… Ele vai pedir a senha do usuário. Idem pro Windows e pro Linux.

    Problema. O diabo do sistema deixou o cara autenticar com a senha do usuário em background!

    • Dou uma e se for bom dou mais

      ERRRROOOOOUUUU, no linux e no windows tudo isso é feito em memória protegida e ainda por cima não é decriptografado todo o arquivo, apenas o que for pedido (senha armazenada de um site por exemplo). Sendo assim o malware só conseguiria todos os dados SE E APENAS SE ele soubesse todos os sites armazenados na keychain. Portanto não é chegar na senha e decriptografar (uma vez que tem a contrachave) e assim obter um plain text nos outros (se bem que não sei direito quanto ao windows uma vez que ele não tem chaveiro público, precisa de programas externos para isso).

      • Wallacy

        Bebeu? De onde você tirou que ele obteve todo o arquivo fazendo o request para uma key especifica? Descriptografar todas as entradas usando a master key é diferente de obter a base.

        Veja que ele obtêm os dados do usuario local (obvio, pois ele só tem acesso ao que foi feito load em user space), e cada chave da keychain no campo blob já aparece em full utf8. Claramente descriptografado, já que por padrão você ir lá agora e imprimir esses dados vai ver que existe criptografias nesses campos.

        Fora que seu comentario de memoria protegida não faz sentido, o mesmo acontece no OSX e não tem relação com o exploit. Obter todas as entradas da keychain é a coisa mais simples de todas, em todos os três sistemas, por regra isso é publico.

        Obter a chave é o grande problema, na verdade, é muito mais serio que o problema da keychain isolado. O arquivo keychain-db é um velho conhecido de todos, pedir suas entradas sempre foi trivial, obter os blobs já em utf8 que não. Até então.

        • Dou uma e se for bom dou mais

          Cara vai tomar onde o sol não bate e vai aprender a ler, não vou perder meu tempo com textão sendo que você nem prestou atenção que estou falando de linux e não do FagOS.

      • Wallacy

        Só como referencia, esse é o método padrão (via API a mesma coisa).

        sh “security list-keychains -s ~/Library/Keychains/iosbuilds.keychain-db”
        sh “security unlock-keychain -p ${env.KEYCHAIN_PASSWORD} /Users/iosbuilds/Library/Keychains/iosbuilds.keychain-db”

        O arquivo keychain-db sempre foi de fácil acesso, listar suas entradas também. Você pode pedir entrada por entrada, ou pedir todas as entradas (via API só tem como fazer uma por uma), a questão toda é o unlock sem chave.

        • Dou uma e se for bom dou mais

          Onde isso? Porque no linux não tem ~/Library e nem /Users novamente ERRRRRRRRRRROOOOOOUUUUUU

          • Wallacy

            Estou falando do OSX… Esse é o método padrão.

          • Dou uma e se for bom dou mais

            E eu estou falando de linux meu caro, foda-se o FagOS.

    • Daniel Tiecher

      Que bom que tem gente que entendo do que está escrevendo aqui. Novamente vejo um artigo de caráter técnico sendo mal escrita pelo Gogoni. Eu sei que o Meiobit é um blog e por isso junto da notícia nós temos também a opinião do autor, porém pelo texto dá pra entender que o Gogoni não entende como o Keychain funciona ou mesmo o que esta vulnerabilidade está fazendo (até porque o como até então não é de conhecimento público), porém mesmo assim resolver dar pitaco sobre como a Apple deveria ou não ter implementado essa funcionalidade, exige ao menos um profundo conhecimento sobre o assunto, do contrário é só um monte de falácias mascaradas de conhecimento.

      • Wallacy

        O post de origin, o tal “hacker” também deixa tudo meio opaco. Nesse caso podemos culpar a fonte.

        • Daniel Tiecher

          De fato, mas daí pular pra dizer que a Apple simplesmente armazenas as senhas em texto plano na base do Keychain, sem antes entender como ele funciona é complicado.

  • Fabiano Novaes Ferreira

    como assim falha na apple? inaceitável

Aproveite nossos cupons de desconto:

Cupom de desconto Locaweb, Cupom de desconto HP, Cupom de desconto Descomplica, Cupom de desconto Nuuvem, Cupom de desconto CVC, Cupom de desconto Asus, Cupom de desconto World Tennis