Histórico de patches da Apple

Este ano, a1exdandy e eu conversamos nas conferências VolgaCTF e KazHackStan com uma palestra sobre os programas Patch Diffing escritos no Objective-C, e como usá-lo para pesquisar e encontrar vulnerabilidades de 0 e 1 dia nos produtos da Apple. Você pode assistir ao vídeo da apresentação aqui e, para ler o artigo, seja bem-vindo ao gato.

Difusão binária é o processo de comparar dois arquivos executáveis ​​para encontrar semelhanças e diferenças entre eles. A correção de patches é um caso especial da correção de binários quando um arquivo com vulnerabilidade é comparado com um arquivo fixo (arquivo com um patch). Assim, você pode descobrir quais correções o desenvolvedor fez e entender qual era a vulnerabilidade.

Alguns anos atrás (em 2013), foi publicado um artigo sobre os programas Patch Diffing for Windows, aos quais também tínhamos uma mão. Recomendamos que você se familiarize com ele, se estiver interessado neste tópico em conexão com o sistema operacional Windows. No mesmo artigo, falaremos sobre a análise de programas para o Apple OS.

Como a difusão binária e a difusão de patches podem ser úteis?

A principal tarefa da difusão binária é rastrear quais alterações foram feitas no aplicativo. Para fazer isso, você precisa pegar a versão antiga e compará-la com a nova para ver quais alterações o desenvolvedor adicionou e como elas são implementadas.

Vejamos situações em que isso pode ser útil:

• Análise do desenvolvimento do programa : Comparando as versões novas e antigas, é possível entender como o aplicativo está se desenvolvendo, quais novas funcionalidades são adicionadas, quais são removidas e quais alterações o código existente foi submetido.
• Importando o conhecimento existente : em programas que não usam informações simbólicas, os engenheiros reversos precisam gastar muito mais tempo estudando a lógica e procurando vulnerabilidades. Mas acontece que em alguma versão do software, os desenvolvedores acidentalmente ou deliberadamente deixam informações simbólicas. Esta informação pode ser portada de lá para a versão do software que você precisa. Por exemplo , os funcionários do Google Project Zero que usam Biff Diffing conseguiram obter caracteres para as versões mais recentes do Adobe Reader para Windows, de versões mais antigas para outros sistemas operacionais, o que os ajudou a encontrar vulnerabilidades;
• Treinamento em software real : em nossa opinião, o Patch Diffing é uma ótima maneira de passar sem problemas do estudo de pequenos problemas de CTF para a pesquisa de software real. Explorando o patch, você pode observar a vulnerabilidade real em um grande produto de software com todos os seus recursos (embora tenha certeza de que a vulnerabilidade está presente no código). Ao explorar erros em um produto, você pode gradualmente avançar para encontrar as mesmas vulnerabilidades. Como bônus, você pode tentar escrever explorações para eles;
• Criando explorações de 1 dia : Quando um desenvolvedor já lançou um patch, você pode analisá-lo rapidamente, escrever uma exploração para esta vulnerabilidade e obter uma exploração de 1 dia. Ao mesmo tempo, existe o chamado Patch Gapping - o tempo entre o lançamento do patch e sua instalação direta pelos clientes. Durante esse período, uma exploração de 1 dia pode funcionar com êxito e beneficiar seu autor (instalar atualizações em tempo hábil!) Até que todos instalem o patch lançado pelos desenvolvedores. Há situações em que uma vulnerabilidade é corrigida em uma biblioteca, mas os programas ainda usam uma versão desatualizada da biblioteca. Aqui estão alguns exemplos interessantes de Patch Gapping for Chrome e WebKit ;
• Pesquise vulnerabilidades de 0 dia : não importa o quão estranho possa parecer, mas analisando as correções, você pode encontrar vulnerabilidades anteriormente desconhecidas (vulnerabilidades de 0 dia). Os desenvolvedores também estão enganados e, portanto, no processo de criação de um patch, a vulnerabilidade pode não estar fechada corretamente. Assim, analisando um patch, você pode encontrar uma maneira de contorná-lo. Por exemplo, os desenvolvedores do Apache Struts corrigiram uma vulnerabilidade cinco vezes, mas o patch funcionou apenas em sua sexta versão! Além disso, muitas vezes um desenvolvedor, cumprindo claramente a tarefa definida para corrigir uma certa vulnerabilidade, pode não perceber o que está acontecendo nas seções vizinhas do código. Pode haver exatamente a mesma vulnerabilidade nas proximidades e, em caso de detecção, será de 0 dias. É importante estudar o padrão de um erro de desenvolvedor detectado e tentar encontrar algo semelhante no mesmo programa. Se o desenvolvedor cometeu um erro em um lugar, a probabilidade de repetir o mesmo erro em outro lugar é alta.

Existe um mito de que ocultar informações sobre patches de vulnerabilidade aumenta a segurança. No entanto, os invasores, por via de regra, já desenvolveram infraestrutura para analisar patches, para encontrar rapidamente os dados nos quais estão interessados. Ocultar vulnerabilidades complica o trabalho dos responsáveis ​​pela proteção do sistema, porque, sem acesso total às informações, é impossível entender a importância desse patch para a empresa. Sobre esta questão, é altamente recomendável que você leia o artigo "Rashomon of disclosure" do pesquisador Halvar Flake, onde a situação é vista sob diferentes ângulos.

Nem sempre as vulnerabilidades descobertas são ocultadas intencionalmente. Os desenvolvedores podem não atribuir importância especial a algumas das deficiências de seus produtos e corrigi-las sem publicidade, como um bug comum.

Temos certeza de que não são todas as situações em que você pode usar difusão binária e difusão de patches e, nos comentários, pode escrever seus próprios scripts.

Toolkit

A partir da teoria, passamos a praticar gradualmente. Naturalmente, fazer Diffing binário manualmente é uma tarefa louca. Um extenso kit de ferramentas foi desenvolvido há muito tempo, consistindo em programas e plug-ins independentes para analisadores binários populares: Diaphora, BinDiff, DarunGrim, YaDiff, rizzo, Realyze, Turbodiff, patchdiff2, revanche e outros.

Interface BinDiff.

Interface Diaphora

Na prática, usamos principalmente apenas os dois primeiros (eles são apresentados nas capturas de tela acima). Infelizmente, a maioria das ferramentas atuais não é animadora com a qualidade do trabalho ou é completamente abandonada. Agora, existem novas ferramentas usando o ML, mas sua qualidade deixa muito a desejar, embora tenham idéias interessantes para comparar arquivos binários de diferentes arquiteturas.

Eu também gostaria de observar separadamente as ferramentas recentemente exibidas para comparar o código-fonte aberto em arquivos binários: Pigaios e Karta. Esta é uma direção muito interessante e útil. Eles coletam métricas do código-fonte e as usam para comparar funções em arquivos binários. Isso é muito útil na ausência de caracteres e vinculação estática. A tarefa dessas ferramentas é mapear funções em um arquivo para funções em outro.

Comparação de correções para sistemas operacionais Apple

Como regra, os aplicativos para o Apple OS gravam no Objective-C. Esta é uma extensão orientada a objetos para C, baseada em paradigmas da linguagem Smalltalk com seu próprio tempo de execução.

Se abrirmos o programa Objective-C em algum analisador binário (no nosso caso, é um IDA), veremos algo assim: as funções em C / C ++ terão nomes abstratos e as funções em Objective-C serão chamadas muito bem. (Diremos imediatamente que não consideramos situações com ofuscação de código - essa é uma história separada.) Isso facilita a engenharia reversa: é fácil ver qual objeto é chamado, qual método é usado e quais argumentos ele possui. Além disso, essas informações simbólicas simplificam bastante o trabalho com ferramentas para comparar arquivos binários. Ele permite que você rapidamente e com um número mínimo de erros mapeie funções.

Quando não há símbolos, as ferramentas precisam usar algoritmos internos para análise, heurística etc. Naturalmente, eles nem sempre funcionam corretamente.

Casos de uso em que a correção de patches foi muito útil

Provavelmente, esta apresentação (no formato de 45 minutos) e este artigo não teriam nascido se recentemente, a Apple não tivesse surpreendido a comunidade mundial de pesquisas várias vezes. Vamos olhar para esses casos.

Caso 1: CVE-2019-8606

Em maio de 2019, foi lançado o iOS 12.3 para iPhone, onde a vulnerabilidade com a qual era possível instalar o jailbreak foi corrigida. Em julho daquele ano, a Apple lançou a versão 12.4, onde o jailbreak voltou a funcionar: os funcionários removeram acidentalmente o adesivo protetor. A versão corrigida foi lançada apenas após um mês: todo esse tempo, qualquer dispositivo da versão mais recente poderia ser facilmente sujeito a operações de jailbreak. Tudo isso foi descoberto graças ao patch diffing.

Caso 2: CVE-2019-7278 e CVE-2019-7286

A experiência pessoal com Patch difere na conferência Hack in the Box em seu relatório Recriando um jailbreak do iOS de 0 dia com os patches de segurança da Apple foi descrito pelo pesquisador de segurança Stefan Esser. Ele falou sobre o CVE-2019-7278 e o CVE-2019-7286 - eles são notáveis ​​pelos que foram descobertos graças ao Grupo de Análise de Ameaças do Google durante o uso real por invasores (ITW, na natureza). A Apple recebeu informações sobre eles, mas nem eles nem os caras do Google revelaram detalhes técnicos. Então Stefan se perguntou o que os atacantes estavam usando. É altamente recomendável que você leia o relatório, pois ele também fala sobre o processo de comparação de componentes do kernel e do espaço do usuário.
Fato interessante: um ou dois dias antes do discurso de Stefan, o Projeto Zero Ian Beer publicou uma série de artigos "Um mergulho profundo nas cadeias de exploração iOS encontradas na natureza" , o que confundiu um pouco os mapas para o pesquisador;)

Caso 3: checkm8

Os dispositivos Apple usam dois gerenciadores de inicialização: Bootrom e Iboot. O primeiro começa a funcionar assim que o dispositivo é ligado. Está na memória somente leitura e não pode ser atualizado. O Iboot é um carregador de inicialização de segundo nível que aprimora a autenticação executada na cadeia de inicialização.
A peculiaridade dos carregadores é que eles compartilham o código. No início do ano passado, os especialistas compararam as atualizações do Iboot e descobriram que a Apple corrigia uma vulnerabilidade na pilha USB. Sabendo que o mesmo código é usado na parte não atualizada do Bootrom, eles perceberam que essa vulnerabilidade também existe. Em seguida, o desenvolvimento da exploração checkm8 começou. Agora, todos os dispositivos baseados em chips de A5 a A11 (do iPhone 4s ao iPhone X) estão completamente vulneráveis ​​e é possível executar seu próprio código neles. Ao mesmo tempo, em dispositivos das versões XR e 11, essa vulnerabilidade já está fechada e não houve relatos disso da Apple.
Assim, sabendo onde foi corrigido e como o código é dividido, você pode encontrar algumas coisas muito legais!

Nossa história: CVE-2019-8574

Em maio, a Apple lançou uma nova atualização para seus dispositivos. Examinamos a lista de vulnerabilidades corrigidas e encontramos o utilitário sysdiagnose. Este programa coleta informações de diagnóstico de várias fontes e as transfere para o usuário na forma de um arquivo para análises adicionais, suporte ou um centro de serviço. Parecia que era impossível influenciar a maneira como ela coleta informações. A descrição do patch afirmou que a vulnerabilidade poderia ser usada para aumentar privilégios e é um erro de corrupção de memória, o que nos intrigou ainda mais. E o próprio autor da descoberta não publicou nenhuma descrição de si mesmo ...

Você pode chamar sysdiagnose no macOS pressionando Ctrl + Option + Shift +., Ou usando o comando sudo sysdiagnose. Nos dispositivos iOS, é necessário manter pressionada a tecla liga / desliga e as teclas de volume para cima e para baixo.

Patch Diffing Apple na prática

Se você deseja corrigir os dispositivos Apple com diferenças, é necessário obter duas versões da atualização (antiga e nova). No macOS, você pode analisar arquivos no Catálogo de Atualização de Software. Esse método nem sempre ajuda, pois a Apple remove algumas atualizações. As atualizações também podem ser encontradas no diretório / Library / Updates. Você pode encontrar o firmware para dispositivos iOS no site ipsw.me.
Para o macOS, você precisa extrair arquivos executáveis, arquivos de biblioteca, estruturas e o kernel usando o utilitário Suspicious Package.
Para dispositivos iOS, as coisas são um pouco mais complicadas. A atualização em si é um arquivo ZIP. Neste arquivo, você precisa encontrar o arquivo kernelcache: inside é o kernel e sua extensão. No entanto, antes da análise, você precisa converter o arquivo para o formato Mach-O. Isso pode ser feito usando os utilitários img4tool, joker, jtool2 e outros.
O firmware do componente terrestre do usuário pode ser encontrado na maior imagem DMG: contém o sistema raiz e os arquivos executáveis. No entanto, se você olhar para bibliotecas e estruturas compartilhadas, elas não estarão lá. O fato é que, para otimizar o espaço, eles são colocados em dyld_shared_cache. Este arquivo contém todas as bibliotecas do iPhone e ocupa mais de 1 gigabyte, o que complica sua análise. Se você precisar baixar uma parte separada do arquivo ipsw, use o utilitário ipsw ( https://github.com/blacktop/ipsw ).

Patchdifting CVE-2019-8574

Para estudar o patch CVE-2019-8574, obtemos um arquivo da Library / Updates e extraímos dois arquivos executáveis ​​de diagnóstico por sysdia (antigos e novos) usando o Pacote Suspeito e, em seguida, procuramos atualizações nos utilitários para comparar códigos binários, por exemplo, Diaphora ou BinDiff (eles são muito melhor que o editor hexadecimal).

Como o patch funciona

Para a arquitetura x86_64, encontramos apenas uma função alterada. Há mais mudanças no ARM, mas são insignificantes.

O problema estava no método [SDTask start]: ele adicionou uma nova verificação. Na figura, você pode ver como é chamada uma chamada para alguma função isAppleInternal e a presença da substring / usr / local em algum caminho é verificada.

Como afirmado anteriormente, o sysdiagnose coleta informações de várias fontes. As fontes podem ser arquivos (por exemplo, um log de eventos) ou a saída de alguns comandos de informações (por exemplo, listando processos ou threads usando ps) - essas tarefas são armazenadas no sysdiagnose como objetos SDTask. O método [SDTask start] inicia a execução das tarefas. Na figura abaixo, você pode ver o código no qual todas as tarefas são formadas. Todos os caminhos dos arquivos executáveis ​​e seus argumentos são gravados diretamente no programa e existem tarefas de vários diretórios, incluindo / usr / local.

Portanto, antes de instalar o patch, qualquer tarefa pode ser executada independentemente de onde o arquivo executável está localizado. Após a instalação do patch, é chamada a função isAppleInternal, que verifica se o dispositivo é um dispositivo de teste interno da Apple. Se este for um dispositivo interno, a tarefa será executada de maneira padrão e, se for do lado do cliente, a presença da substring / usr / local / no caminho do arquivo executável da tarefa será verificada. Se uma substring for encontrada, a tarefa não será concluída.

Lembre-se de que, na descrição da vulnerabilidade, foi dito que se trata de um erro de corrupção de memória, mas no patch não notamos nada parecido ... Em nossa opinião, essa é uma vulnerabilidade lógica bem e estavelmente explorada.

Como explorá-lo

Para explorar a vulnerabilidade, você deve executar as seguintes etapas:
Crie qualquer arquivo executável (script binário ou shell) que o sysdiagnose seja iniciado a partir de / usr / local / bin e coloque nossa carga útil lá. A lista de arquivos válidos é fornecida abaixo. É importante que o gerenciador de pacotes brew esteja instalado no sistema: permite ao usuário criar arquivos em / usr / local / sem elevar privilégios.

É necessário chamar sysdiagnose. Ao mesmo tempo, nossa carga útil será executada com direitos de usuário root e sua saída será colocada no arquivo que sysdiagnosticar formulários. Assim, obtemos escalação de privilégios. No entanto, a execução do sysdiagnose exige privilégios elevados. Mas, como mencionado acima, o sysdiagnose também pode ser iniciado usando o atalho de teclado, e isso funciona mesmo na tela de bloqueio do macOS.
Essa vulnerabilidade pode ser usada para criar vários programas maliciosos.

/usr/local/bin/airplayutil /usr/local/bin/amstool /usr/local/bin/apsclient /usr/local/bin/audioDeviceDump /usr/local/bin/cdcontexttool /usr/local/bin/cddebug /usr/local/bin/cdknowledgetool /usr/local/bin/dastool /usr/local/bin/idstool /usr/local/bin/imtool /usr/local/bin/keystorectl /usr/local/bin/pmtool /usr/local/bin/xcpm /usr/local/efi/bin/efi-perf 

Curiosamente, outras vulnerabilidades podem estar associadas ao gerenciador de pacotes de distribuição, ou melhor, à capacidade de gravar em / usr / local / sem privilégios.

Conclusão

Com este estudo, gostaríamos de mostrar a importância e a criticidade da correção de patches não apenas para invasores, mas também para aumentar a segurança dos produtos de software. Infelizmente, o patch não pode apenas fechar a vulnerabilidade, mas também jogar nas mãos do atacante.

No entanto, essa abordagem permite não apenas estudar vulnerabilidades conhecidas, mas também procurar novas como elas. Portanto, acreditamos que a correção de patches é essencial para todo pesquisador.