{"id":19075,"date":"2021-11-05T13:30:19","date_gmt":"2021-11-05T16:30:19","guid":{"rendered":"https:\/\/www.ethicalhacker.com.br\/site\/?p=19075"},"modified":"2021-11-05T13:30:21","modified_gmt":"2021-11-05T16:30:21","slug":"a-microsoft-encontra-uma-nova-vulnerabilidade-do-macos-shrootless-que-pode-contornar-a-protecao-de-integridade-do-sistema","status":"publish","type":"post","link":"https:\/\/www.ethicalhacker.com.br\/site\/2021\/11\/basico\/a-microsoft-encontra-uma-nova-vulnerabilidade-do-macos-shrootless-que-pode-contornar-a-protecao-de-integridade-do-sistema\/","title":{"rendered":"A Microsoft encontra uma nova vulnerabilidade do macOS, Shrootless, que pode contornar a prote\u00e7\u00e3o de integridade do sistema"},"content":{"rendered":"\n

A Microsoft descobriu uma vulnerabilidade que pode permitir que um invasor ignore a <\/span>prote\u00e7\u00e3o de integridade do sistema (SIP) no macOS e execute opera\u00e7\u00f5es arbitr\u00e1rias em um dispositivo. Tamb\u00e9m encontramos uma t\u00e9cnica semelhante que pode permitir que um invasor eleve seus privil\u00e9gios para fazer root em um dispositivo afetado.<\/p>\n

\u00a0<\/p>\n

Compartilhamos essas descobertas com a Apple por meio do Coordinated Vulnerability Disclosure (CVD) por meio do Microsoft Security Vulnerability Research (MSVR). Uma corre\u00e7\u00e3o para esta vulnerabilidade, agora identificada como CVE-2021-30892 , foi inclu\u00edda nas atualiza\u00e7\u00f5es de seguran\u00e7a lan\u00e7adas pela Apple em 26 de outubro de 2021.<\/p>\n

\u00a0<\/p>\n

SIP \u00e9 uma tecnologia de seguran\u00e7a no macOS que restringe um usu\u00e1rio root de realizar opera\u00e7\u00f5es que podem comprometer a integridade do sistema. Descobrimos a vulnerabilidade ao avaliar os processos autorizados a contornar as prote\u00e7\u00f5es SIP. Descobrimos que a vulnerabilidade est\u00e1 nos pacotes assinados pela Apple com scripts de p\u00f3s-instala\u00e7\u00e3o que s\u00e3o instalados. Um agente malicioso pode criar um arquivo especialmente criado que sequestra o processo de instala\u00e7\u00e3o. Depois de contornar as restri\u00e7\u00f5es do SIP, o invasor pode instalar um driver de kernel malicioso (rootkit), sobrescrever arquivos de sistema ou instalar malware persistente e indetect\u00e1vel, entre outros.<\/p>\n

\u00a0<\/p>\n

Esta vulnerabilidade no n\u00edvel do sistema operacional e outras que inevitavelmente ser\u00e3o descobertas aumentam o n\u00famero crescente de vetores de ataque poss\u00edveis para os invasores explorarem. \u00c0 medida que as redes se tornam cada vez mais heterog\u00eaneas, o n\u00famero de amea\u00e7as que tentam comprometer dispositivos n\u00e3o Windows tamb\u00e9m aumenta. O Microsoft Defender for Endpoint no Mac permite que as organiza\u00e7\u00f5es obtenham visibilidade e detectem amea\u00e7as em dispositivos macOS. Essa visibilidade se acumula no Microsoft Defender for Endpoint , que fornece \u00e0s organiza\u00e7\u00f5es um \u201cpainel de vidro \u00fanico\u201d onde podem detectar, gerenciar, responder e corrigir vulnerabilidades e amea\u00e7as em diferentes plataformas.<\/p>\n

\u00a0<\/p>\n

Nesta postagem do blog, compartilharemos algumas informa\u00e7\u00f5es sobre o SIP, examinaremos os tipos comuns de desvios SIP divulgados anteriormente e apresentaremos os \u00fanicos que descobrimos.<\/p>\n

\u00a0<\/p>\n

Vis\u00e3o geral do SIP<\/strong> <\/span><\/h2>\n

Apresentado pela primeira vez pela Apple no macOS Yosemite, SIP tamb\u00e9m conhecido como \u201csem raiz\u201d essencialmente bloqueia o sistema desde a raiz, aproveitando a sandbox da Apple para proteger toda a plataforma. Internamente, \u00e9 controlado pelas seguintes vari\u00e1veis \u200b\u200bNVRAM:<\/p>\n

\u00a0<\/p>\n

    \n
  • csr-active-config: <\/strong>bitmask de prote\u00e7\u00f5es habilitadas <\/span><\/li>\n
  • csr-data: <\/strong>armazena a configura\u00e7\u00e3o do netboot <\/span><\/li>\n<\/ul>\n

    \u00a0<\/p>\n

    Essas vari\u00e1veis \u200b\u200bn\u00e3o podem ser modificadas legitimamente no modo de n\u00e3o recupera\u00e7\u00e3o. Portanto, a \u00fanica maneira leg\u00edtima de desabilitar o SIP \u00e9 inicializando no modo de recupera\u00e7\u00e3o e desligando o SIP. A desativa\u00e7\u00e3o do SIP \u00e9 feita usando a ativa\u00e7\u00e3o interna da ferramenta\u00a0 csrutil<\/em>, que tamb\u00e9m pode exibir o status do SIP:<\/p>\n

    \u00a0<\/p>\n

    \"Captura<\/p>\n

    Figura 1: csrutil mostrando o status do SIP. Observe que o SIP n\u00e3o pode ser desativado no sistema operacional sem recupera\u00e7\u00e3o. <\/em><\/p>\n

    \u00a0<\/p>\n

    A csr-active-config <\/em>vari\u00e1vel bitmask NVRAM descreve as diferentes prote\u00e7\u00f5es que o SIP oferece. Embora n\u00e3o seja uma lista exaustiva, abaixo est\u00e3o algumas men\u00e7\u00f5es honrosas; o resto pode ser examinado livremente no do c\u00f3digo-fonte XNU :<\/p>\n

    \u00a0<\/p>\n\n\n\n\n\n\n\n\n
    bit csr-active-config NVRAM <\/strong><\/td>\nDescri\u00e7\u00e3o <\/strong><\/td>\n<\/tr>\n
    CSR_ALLOW_UNTRUSTED_KEXTS <\/strong><\/td>\nControla o carregamento de extens\u00f5es de kernel n\u00e3o confi\u00e1veis<\/td>\n<\/tr>\n
    CSR_ALLOW_UNRESTRICTED_FS <\/strong><\/td>\nControla o acesso de grava\u00e7\u00e3o a locais restritos do sistema de arquivos<\/td>\n<\/tr>\n
    CSR_ALLOW_TASK_FOR_PID <\/strong><\/td>\nControla se permite obter uma porta de tarefa para processos Apple (ou seja, invocar a task_for_pid <\/em>API )<\/td>\n<\/tr>\n
    CSR_ALLOW_UNRESTRICTED_NVRAM <\/strong><\/td>\nControla o acesso irrestrito ao NVRAM<\/td>\n<\/tr>\n
    CSR_ALLOW_KERNEL_DEBUGGER <\/strong><\/td>\nControla se permite a depura\u00e7\u00e3o do kernel<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    \u00a0<\/p>\n

    O comprometimento de qualquer uma dessas prote\u00e7\u00f5es pode permitir que os invasores ignorem o SIP completamente. Alguns cen\u00e1rios incluem o seguinte:<\/p>\n

      \n
    • Carregar extens\u00f5es de kernel n\u00e3o confi\u00e1veis \u200b\u200bpode comprometer o kernel e permitir que essas extens\u00f5es executem opera\u00e7\u00f5es sem qualquer verifica\u00e7\u00e3o<\/span><\/span><\/li>\n<\/ul>\n

      \u00a0<\/h3>\n

      Restri\u00e7\u00f5es do sistema de arquivos<\/strong> <\/span><\/h3>\n
        \n
      • Ignorar as verifica\u00e7\u00f5es do sistema de arquivos pode permitir que uma extens\u00e3o do kernel imponha o SIP a si mesmo completamente <\/span><\/li>\n
      • Modificar livremente a NVRAM pode controlar o pr\u00f3prio SIP <\/span><\/li>\n<\/ul>\n

        \u00a0<\/p>\n

        Restri\u00e7\u00f5es do sistema de arquivos<\/strong> <\/span><\/h3>\n

        Ao longo dos anos, a Apple fortaleceu o SIP contra ataques, melhorando as restri\u00e7\u00f5es. Uma das restri\u00e7\u00f5es SIP mais not\u00e1veis \u200b\u200b\u00e9 a restri\u00e7\u00e3o do sistema de arquivos. Isso \u00e9 especialmente importante para equipes vermelhas e agentes mal-intencionados, j\u00e1 que a quantidade de danos que algu\u00e9m pode causar aos componentes cr\u00edticos de um dispositivo se baseia diretamente em sua capacidade de gravar dados irrestritos no disco.<\/p>\n

        \u00a0<\/p>\n

        O arquivo \/System\/Library\/Sandbox\/rootless.conf <\/em>geralmente controla quais arquivos s\u00e3o protegidos por SIP. Embora o referido arquivo tamb\u00e9m seja protegido por SIP, pode-se execut\u00e1-lo usando ls <\/em>com o -O <\/em>sinalizador para listar quais arquivos est\u00e3o protegidos de forma semelhante. Os arquivos protegidos por SIP possuem o marcador \u201crestrito\u201d.<\/p>\n

        \u00a0<\/p>\n

        \"Captura<\/p>\n

        Figura 2: Listagem \/usr com a op\u00e7\u00e3o -O. \/usr\/local n\u00e3o \u00e9 protegido por SIP, mas \/usr\/sbin \u00e9. <\/em><\/p>\n

        \u00a0<\/p>\n

        Os arquivos com o atributo estendido com.apple.rootless <\/em>s\u00e3o igualmente protegidos por SIP. Obviamente, n\u00e3o h\u00e1 como adicionar esse atributo estendido a um arquivo de maneira leg\u00edtima. Caso contr\u00e1rio, o malware pode usar o SIP para sua pr\u00f3pria prote\u00e7\u00e3o. As restri\u00e7\u00f5es do sistema de arquivos s\u00e3o uma \u00f3tima maneira de restringir invasores. Por exemplo, muitos do \/System <\/em>diret\u00f3rio e seus subdiret\u00f3rios s\u00e3o protegidos por SIP.<\/p>\n

        \u00a0<\/p>\n

        \"Captura<\/p>\n

        Figura 3: SIP bloqueando um registro malicioso do LaunchDaemon que \u00e9 freq\u00fcentemente usado para persist\u00eancia. <\/em><\/p>\n

        \u00a0<\/h3>\n

        Direitos sem raiz<\/strong><\/h3>\n

        Como as restri\u00e7\u00f5es do sistema de arquivos s\u00e3o t\u00e3o poderosas, a Apple deve considerar alguns casos excepcionais. Por exemplo, as atualiza\u00e7\u00f5es do sistema requerem acesso irrestrito a diret\u00f3rios protegidos por SIP. Portanto, a Apple introduziu um conjunto espec\u00edfico de direitos que ignoram as verifica\u00e7\u00f5es SIP por design. Esses direitos s\u00e3o ajustados para verifica\u00e7\u00f5es SIP espec\u00edficas e apenas a Apple pode atribu\u00ed-los. Ent\u00e3o, naturalmente, a Apple apenas atribui esses direitos aos seus processos.<\/p>\n

        \u00a0<\/p>\n

        Em nossa pesquisa, nos concentramos em dois direitos poderosos, que tamb\u00e9m foram alvos de ca\u00e7adores de vulnerabilidade:<\/p>\n

        \u00a0<\/p>\n\n\n\n\n\n
        Direito <\/strong><\/td>\nDescri\u00e7\u00e3o <\/strong><\/td>\n<\/tr>\n
        com.apple.rootless.install <\/strong><\/td>\nIgnora completamente as verifica\u00e7\u00f5es do sistema de arquivos SIP<\/td>\n<\/tr>\n
        com.apple.rootless.install.inheritable <\/strong><\/td>\nHerda com.apple.rootless.install <\/em>para processos filho<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

        \u00a0<\/p>\n

        \"Captura<\/p>\n

        Figura 4: Um exemplo de processo intitulado \u201ccom.apple.rootless.install\u201d <\/em><\/p>\n

        \u00a0<\/p>\n

        Um r\u00e1pido resumo de not\u00e1veis \u200b\u200bdesvios SIP<\/strong><\/h2>\n

        Antes de nossa descoberta, havia v\u00e1rias vulnerabilidades de desvio SIP interessantes j\u00e1 relatadas no passado. Nesta se\u00e7\u00e3o, categorizamos essas vulnerabilidades em v\u00e1rias classes e fornecemos um exemplo para cada uma. Observe que esta n\u00e3o \u00e9 uma lista completa; por exemplo, exclu\u00edmos vulnerabilidades envolvendo o pr\u00f3prio kernel porque o SIP protege apenas a \u00e1rea do usu\u00e1rio.<\/p>\n

        \u00a0<\/p>\n

        Abuso de bibliotecas din\u00e2micas<\/strong><\/h3>\n

        Anteriormente, os processos autorizados ainda podiam carregar bibliotecas din\u00e2micas arbitr\u00e1rias. Um exemplo foi apresentado em 2016 , onde libBaseIA.dylib <\/em>, que \u00e9 local para o aplicativo, foi usado por um bin\u00e1rio autorizado e pode estar infectado com c\u00f3digo malicioso. Nesse ponto, o desvio SIP pode ser completamente implementado no dylib malicioso.<\/p>\n

        \u00a0<\/p>\n

        Montagem<\/strong><\/h3>\n

        Em uma atualiza\u00e7\u00e3o de seguran\u00e7a para OSX 10.11.2, a Apple corrigiu um bug de seguran\u00e7a que tamb\u00e9m foi abusado pelo malware MacDefender. A referida vulnerabilidade pode permitir que um arquivo .dmg malicioso seja montado (usando hdiutil) em uma pasta protegida por SIP, ignorando completamente as restri\u00e7\u00f5es do sistema de arquivos SIP.<\/p>\n

        \u00a0<\/p>\n

        Abuso de direitos<\/strong><\/h3>\n

        Os processos autorizados tamb\u00e9m t\u00eam sido fontes de contornos de seguran\u00e7a. Um exemplo not\u00e1vel \u00e9 um bypass que usou o intitulado fsck_cs <\/em>utilit\u00e1rio . O bypass explorou o fato de que fsck_cs <\/em>seguiria links simb\u00f3licos e tentaria consertar o sistema de arquivos apresentado a ele.<\/p>\n

        \u00a0<\/p>\n

        Portanto, um invasor pode criar um apontar uma liga\u00e7\u00e3o simb\u00f3lica de \/dev\/diskX <\/em>para \/System\/Library\/Extensions\/AppleKextExcludeList.kext\/Contents\/Info.plist <\/em>e invocar fsck_cs sobre o primeiro. \u00c0 medida que o Info.plist <\/em>arquivo \u00e9 corrompido, o sistema operacional n\u00e3o pode mais controlar as exclus\u00f5es de extens\u00e3o do kernel, ignorando o SIP.<\/p>\n

        \u00a0<\/p>\n

        A vulnerabilidade ‘Shrootless’<\/strong><\/h2>\n

        Ao avaliar os processos do macOS com direito a ignorar as prote\u00e7\u00f5es SIP, encontramos o daemon system_installd <\/em>, que tem o poderoso com.apple.rootless.install.inheritable como autoriza\u00e7\u00e3o<\/em>. Com esta autoriza\u00e7\u00e3o, qualquer processo filho de system_installd <\/em>seria capaz de ignorar as restri\u00e7\u00f5es do sistema de arquivos SIP por completo.<\/p>\n

        \u00a0<\/p>\n

        \"Captura<\/p>\n

        Figura 5: direitos system_installd. Observe o \u201ccom.apple.rootless.install.inheritable\u201d <\/em><\/p>\n

        \u00a0<\/p>\n

        Como o Microsoft Defender for Endpoint tem um componente p\u00f3s-viola\u00e7\u00e3o, decidimos examinar todos os processos filho de system_installd <\/em>. Para nossa surpresa, vimos alguns casos que poderiam permitir que invasores abusassem de sua funcionalidade e contornassem o SIP.<\/p>\n

        \u00a0<\/p>\n

        Por exemplo, ao instalar um pacote assinado pela Apple (arquivo .pkg), o referido pacote invoca o system_installd <\/em>, que ent\u00e3o se encarrega de instalar o anterior. Se o pacote contiver scripts de p\u00f3s-instala\u00e7\u00e3o, system_installd os <\/em>executar\u00e1 invocando um shell padr\u00e3o, que \u00e9 zsh <\/em>no macOS. Curiosamente, quando o zsh \u00e9 <\/em>iniciado, ele procura o arquivo \/etc\/ zshenv <\/em>e se encontrado executa comandos desse arquivo automaticamente, mesmo no modo n\u00e3o interativo.<\/p>\n

        \u00a0<\/p>\n

        Portanto, para que os invasores executem opera\u00e7\u00f5es arbitr\u00e1rias no dispositivo, um caminho totalmente confi\u00e1vel que eles poderiam seguir seria criar um arquivo malicioso em \u00a0 \/etc\/zshenv\u00a0<\/em> e esperar que o system_installd <\/em>invoque o zsh <\/em>.<\/p>\n

        \u00a0<\/p>\n

        Para criar um exploit de prova de conceito (POC) totalmente funcional, implementamos o seguinte algoritmo:<\/p>\n

        \u00a0<\/p>\n

          \n
        1. Baixe um pacote assinado pela Apple (usando wget <\/em>) que \u00e9 conhecido por ter um script de p\u00f3s-instala\u00e7\u00e3;<\/span><\/li>\n
        2. Instale um \/etc\/zshenv malicioso <\/em>que verifique seu processo pai; se for um system_installd, ent\u00e3o ele gravaria\u00a0<\/em> em locais restritos; <\/span><\/li>\n
        3. Invocar o instalador <\/em>utilit\u00e1rio para instalar o pacot.<\/span><\/li>\n<\/ol>\n

          \u00a0<\/p>\n

          Conforme visto na Figura 6 abaixo, o exploit POC foi capaz de substituir a lista de exclus\u00e3o de extens\u00e3o do kernel:<\/p>\n

          \u00a0<\/p>\n

          \"Captura<\/p>\n

          Figura 6: Nosso exploit POC substituindo a lista de exclus\u00e3o de extens\u00e3o do kernel com dados arbitr\u00e1rios <\/em><\/p>\n

          \u00a0<\/p>\n

          zshenv <\/em>como t\u00e9cnica de ataque<\/strong><\/h3>\n

          Durante nossa pesquisa, tamb\u00e9m descobrimos que zshenv <\/em>tamb\u00e9m pode ser usado como uma t\u00e9cnica de ataque geral, al\u00e9m de ser usado para um desvio SIP. Descobrimos que em \/etc\/zshenv <\/em>tem um equivalente para cada perfil de usu\u00e1rio em ~ \/ .zshenv <\/em>, que tem a mesma fun\u00e7\u00e3o e comportamento, mas n\u00e3o requer permiss\u00f5es de root para gravar.<\/p>\n

          \u00a0<\/p>\n

          Geralmente, zshenv <\/em>pode ser usado da seguinte forma:<\/p>\n