Compreendendo os jailbreaks

Quando se trata de iPhones, o termo “jailbreak” (cunhado com a primeira versão do iOS antes mesmo de ser chamado de “iOS”) combina tecnologia e o conceito de libertação de restrições:

1. Cadeia: Refere-se originalmente a uma prisão ou confinamento metafórico. No contexto dos iPhones, representa as restrições e limitações impostas pela Apple aos aplicativos de terceiros executados em seu sistema operacional iOS. A Apple mantém controle estrito sobre o que os usuários podem ou não fazer com seus dispositivos por meio das políticas da App Store e medidas de segurança do sistema. Essas limitações incluem restrições à instalação de aplicativos de outras fontes que não a App Store, à personalização da aparência e funcionalidade do dispositivo e ao acesso ao funcionamento interno do sistema operacional.
2. Quebrar: Implica escapar ou libertar-se do confinamento. No contexto do jailbreak do iPhone, significa contornar ou contornar as restrições definidas pelo iOS da Apple. Este processo envolve a exploração de vulnerabilidades no sistema iOS para obter acesso root ou privilégios administrativos, permitindo aos usuários modificar o dispositivo de maneiras que a Apple normalmente não permite.

O jailbreak de um iPhone dá ao usuário final acesso total de execução e gravação. Então, juntando tudo isso, “jailbreak” no contexto dos iPhones significa essencialmente libertar-se das restrições e limitações impostas pelo iOS da Apple, permitindo aos usuários obter mais controle sobre seus dispositivos e personalizá-los ao seu gosto. O termo reflete a ideia de libertar o seu iPhone da “prisão” metafórica das restrições da Apple, dando-lhe mais liberdade e flexibilidade com o seu dispositivo.

O desejo de liberar o telefone deu origem a uma “comunidade” de Jailbreak composta por hackers, usuários curiosos e atores de ameaças. Como acontece com qualquer comunidade que se preze, um grupo Reddit (r / jailbreak) foi formado, canais do YouTube foram criados (e eliminados) e a web escura/cinza apoia o compartilhamento de dicas, técnicas e procedimentos de jailbreak entre os membros da comunidade. Os jailbreaks são procurados há muito tempo, e aqueles que descobrem, executam e compartilham jailbreaks ganham fama ou notoriedade na comunidade de jailbreak.

Observe que o jailbreak pode anular garantias e ter implicações legais, portanto, não é algo que a Apple apoie ou incentive oficialmente. Observe também que, embora “libertar-se” da política da Apple anule a garantia da Apple, não é, por si só, ilegal, e muitos na comunidade de jailbreak consideram seu direito ou mesmo obrigação participar de jailbreaks, e não necessariamente para fins maliciosos. propósitos. Embora a comunidade de hackers, atores de ameaças e brincalhões alegres tenha formado vagamente uma comunidade de jailbreak de base dedicada a frustrar os esforços da Apple para bloquear seu sistema operacional, uma indústria com fins lucrativos que quebra o iOS também criou raízes. Capacidadess como NSO, Cellebrite e Paragon oferecem técnicas sofisticadas de jailbreak mediante o pagamento de uma taxa; e agências de aplicação da lei, bem como governos em todo o mundo – embora detestem admitir isso publicamente – quase com certeza recorrer a estes serviços.

No mundo da application security, os jailbreaks assumem uma importância descomunal porque sempre que um agente de ameaça deseja adulterar (modificar) um aplicativo, uma das primeiras coisas que ele deve fazer é desbloquear um telefone para garantir que o aplicativo modificado possa ser executado. Em outras palavras, embora o jailbreak de um telefone não seja ilegal ou mesmo antiético, o jailbreak é, na maioria dos casos, uma etapa necessária para realmente usar um aplicativo que foi adulterado. Portanto, detectar telefones desbloqueados é parte integrante de qualquer endurecimento de aplicação solução.

Ao mesmo tempo, a Apple investiu consistentemente tempo, dinheiro, esforço e engenhosidade na prevenção total de jailbreaks. Com o tempo, os jailbreaks tornaram-se mais complicados, muitas vezes exigindo múltiplas explorações para desbloquear totalmente o dispositivo devido às melhorias de segurança da Apple. A evolução dos esforços da Apple para evitar jailbreaks é longa e célebre – essencialmente um jogo de gato e rato que estimulou a inovação na “comunidade” de jailbreak e dentro da própria Apple.

Embora a detecção de jailbreak seja essencial para garantir a segurança dos aplicativos disponíveis publicamente, nem todos os jailbreaks são criados iguais; alguns jailbreaks nem representam uma grande ameaça à segurança.

Esta postagem irá 1) descrever a evolução dos jailbreaks do iPhone e 2) elaborar quais tipos de jailbreak dão acesso total aos recursos do sistema no sentido original da palavra e quais são primos menos poderosos do jailbreak tradicional.

A evolução conjunta do iOS e dos Jailbreaks

Os primeiros dias: explorações do BootROM

No início, o jailbreak se concentrava principalmente no bootROM, um componente fundamental do processo de inicialização do dispositivo iOS. O bootROM é um software de baixo nível permanentemente gravado no hardware, tornando as explorações nesse nível particularmente poderosas. Os ataques ao bootROM afetam toda a cadeia de confiança: o bootloader, o kernel e, eventualmente, o ambiente do usuário. Uma exploração bem-sucedida do bootROM poderia conceder acesso incomparável ao dispositivo, permitindo modificações permanentes que poderiam sobreviver a atualizações e redefinições de software. Esta época foi marcada por façanhas famosas como limera1n e Pwnagetool, que desbloqueou iPhones em massa, permitindo instalações de firmware personalizadas e modificações profundas no sistema.

A mudança para o iBoot: vulnerabilidades do bootloader

À medida que a Apple fortaleceu o bootROM, os invasores voltaram sua atenção para o iBoot, o próximo estágio no processo de inicialização do iOS. Exploits no bootloader, como redsn0w e Sn0wbreeze, embora menos permanentes que as vulnerabilidades do bootROM, ainda oferecem amplo controle sobre o dispositivo. Ao comprometer o iBoot, os invasores podem influenciar o kernel e o ambiente do usuário, permitindo uma personalização significativa e contornando as restrições do ecossistema da Apple. Essas vulnerabilidades podiam ser corrigidas por meio de atualizações de software, tornando-as um meio de jailbreak menos durável, mas ainda eficaz.

A Era do Kernel: Patches e Proteção

A progressão em direção às explorações do kernel marcou uma evolução significativa nas táticas de jailbreak. Vulnerabilidades no nível do kernel, exploradas por ferramentas como Pangu, taig e Yalu, permitiu a execução de código não assinado e modificações profundas no sistema sem alterar o processo de inicialização. Esta era consolidou uma abordagem mais refinada ao jailbreak, com foco na flexibilidade operacional dentro da arquitetura de segurança da Apple. Jailbreaks como Electra e Unc0ver exemplificou ainda mais essa estratégia, navegando pelas defesas da Apple para modificar o sistema, mantendo uma aparência de conformidade com os protocolos de segurança do iOS.

Jailbreaks modernos: explorações de precisão e específicas de processos

2015 foi um ponto de inflexão na história dos jailbreaks. A Apple, tendo efetivamente reforçado as defesas do bootROM e do iBoot, não estava mais disposta a simplesmente reagir a várias explorações em seu kernel com patches periódicos e partiu para a ofensiva contra a comunidade jailbreak com uma série de inovações que essencialmente mantiveram o jailbreak comunidade – bem como empresas como Cellebrite e NSO – em seus calcanhares.

No iOS 9 (setembro de 2015), a Apple introduziu o Kernel Patch Protection (KPP), sua atualização de segurança mais crítica. KPP refere-se ao código implementado no kernel para proteger a memória de leitura, execução e somente leitura no kernelcache. Isso é feito por meio de verificações aleatórias de vez em quando.

Desde setembro de 2015, os jailbreaks foram divididos em KPPLess e KPP Bypass. KPPLess é uma técnica em que o KPP ainda está em execução – isso significa evitar a verificação do KPP. KPP Bypass desativa completamente o KPP. Antes do KPP, um invasor precisava principalmente ter capacidade de gravação no kernel para corrigir o código de segurança.

Nos chips A10, originalmente fornecidos com iOS 10 em junho de 2016, a Apple introduziu KTRR, Kernel Text Read only Region, que evita a modificação do kernel do iOS em tempo de execução. Chips mais antigos tentaram fazer isso por meio de um programa de monitoramento carregado no EL3, mas o método era inerentemente falho, e a comunidade Jailbreak já havia descoberto maneiras de contornar o programa de monitoramento. Começando com os chips A10, a Apple efetivamente transferiu as verificações de segurança para o próprio hardware, dificultando assim a vida dos Jailbreakers (tanto na comunidade quanto no setor com fins lucrativos).

Em junho de 2018, com o release do iOS 12, a Apple introduziu o PAC (Pointer Authentication Code), sua implementação de Pointer Authentication. O PAC utiliza os bits superiores de um ponteiro para armazenar uma assinatura criptográfica, essencialmente aumentando a segurança ao verificar os valores do ponteiro e o contexto adicional. Instruções especiais foram introduzidas para adicionar um código de autenticação a um ponteiro, verificar o PAC de um ponteiro autenticado e restaurar o valor original do ponteiro. Isto dá ao sistema uma maneira de fazer garantias criptograficamente fortes sobre a probabilidade de certos ponteiros terem sido adulterados por invasores, o que oferece a possibilidade de melhorar bastante application security.

Quando os chips A12 foram lançados no final daquele ano (setembro de 2018), a Apple introduziu o Page Protection Layer (PPL). O objetivo do PPL é evitar que os agentes de ameaças modifiquem o código executável de um processo ou suas tabelas de páginas, mesmo após obterem privilégios de leitura/gravação/execução do kernel. Esta é outra mitigação de exploração que pode tornar mais difícil encadear ataques. Isso é feito aproveitando o APRR para criar um “kernel dentro do kernel” que protege as tabelas de páginas. A única maneira de o kernel modificar tabelas de páginas é entrar no PPL chamando uma “rotina PPL”, que é análoga a um syscall de XNU para PPL. Isso limita os pontos de entrada no código do kernel que podem modificar tabelas de páginas apenas para essas rotinas PPL. Podemos resumir por que essa mudança no A12 foi significativa para a comunidade do jailbreak?

A comunidade jailbreak teve um período de relativa calma até junho de 2021, quando a Apple lançou o iOS15. O iOS15 deu entusiasmo à comunidade do jailbreak ao apresentar o SSV, o Sealed System Volume. Este mecanismo é um recurso de segurança em nível de kernel que sela o volume com uma assinatura criptográfica conhecida apenas pela Apple, que rejeita qualquer código que tente modificar o conteúdo do sistema, o que impedirá quaisquer alterações não autorizadas feitas antes da inicialização do iOS. Este método forçou a comunidade de jailbreak a mudar toda a estrutura das arquiteturas de jailbreak anteriores. Desde então, os jailbreaks foram divididos em sem raízes e com raízes.

Os jailbreaks sem root mantêm todos os arquivos e modificações fora do root, geralmente em / var e /privado/pré-inicialização. Os jailbreaks rootful usam montagens de ligação que efetivamente criam uma raiz “falsa”, que então age como a real rootfs, mas requer uma exploração bootROM.

Como o jailbreak foi alcançado sem corrigir o código do kernel, os efeitos agora não abrangem todo o sistema, mas mais por processo. Isso significa que, em vez de fazer o jailbreak do sistema operacional, o jailbreak agora é feito por processo.

Podemos ver desta forma – na era dos jailbreaks “pré-modernos”, bastava corrigir o kernel, o que fazia com que todo o sistema fosse afetado. Agora, onde muitos jailbreaks (Quimera, checkra1n) estão adulterando as estruturas de dados do kernel em vez de corrigir diretamente o código do kernel, a adulteração está acontecendo por processo. Este estado complica a detecção do jailbreak. Embora a maior parte da integridade do sistema pareça intacta, a lógica é implementada para determinar se um processo foi desbloqueado ou não. Ou seja, a menos que seja pretendido, o processo permanece preso. Isso, por sua vez, significa que mesmo que esse tipo de jailbreak conceda acesso a recursos aos quais a Apple não pretende que o aplicativo tenha acesso, ele não dá acesso a todos os processos, o que é importante porque significa que o próprio jailbreak é não necessariamente perigoso para todos (ou mesmo algum) dos aplicativos do telefone.

Esta nova forma de jailbreak é tecnicamente complicada, para dizer o mínimo. Requer ganchos em launchd onde todos os processos estão sendo invocados, ganchos de execução e inserção de todos os novos jailbreaks de processos imediatamente após a criação do processo. E, infelizmente (da perspectiva da comunidade jailbreak), toda essa criatividade técnica leva a menos “liberdades”.

Implicações para Application Security Engenheiros e DevSecOps Gerentes

Então, o que tudo isso significa para você, o application security engenheiro? Bem, um dos melhores mecanismos de defesa que fornecemos para você é “Autoproteção de aplicativo em tempo de execução” ou RASP. O RASP permite que nossos clientes programem seus aplicativos para reagir automaticamente quando e se guardas e proteções forem acionadas. Alguns clientes usam o RASP há muito tempo para agir quando e se os jailbreaks forem acionados.

Mas se a extensa história do jogo de gato e rato entre a Apple e a comunidade Jailbreak nos ensinou alguma coisa, é que nem todos os jailbreaks são criados iguais. Alguns exigem “tethering” a um computador, oferecendo pouco valor funcional para usuários curiosos ou qualquer pessoa além dos mais determinados agentes de ameaças e acadêmicos. Existem vários tipos, como “semi-amarrado”, sem raiz e “com raiz”. Alguns provavelmente não são dignos do apelido de “jailbreak” devido ao seu escopo limitado, parecendo mais experimentos de hackers do que um “produto” funcional. Embora os esforços contínuos da Apple para impedir os jailbreaks tenham forçado a inovação na comunidade do jailbreak, eles também tornaram os jailbreaks modernos menos poderosos ao longo do tempo. Em outras palavras, a busca incessante da Apple para encurralar a comunidade de jailbreak fez com que o termo “jailbreak” parecesse quase grandioso demais para se referir às vantagens que esses hacks estão conseguindo conferir, mesmo que a perspicácia técnica necessária para realizar esses pequenos feitos tenha crescido.

Por esse motivo, orientamos que as empresas que criam aplicativos para seus clientes apliquem um bisturi, em vez de um martelo, para reagir aos sinais de jailbreak. Por exemplo, apenas registrar que ocorreu um jailbreak pode ser suficiente e pode não ser mais necessário programar uma reação exclusivamente a um jailbreak. Se você achar necessário programar uma reação, considere quais outras proteções são acionadas em combinação com o jailbreak ao planejar sua estratégia de Autoproteção de Aplicativo em Tempo de Execução (RASP). O jailbreak é um facilitador. É importante detectar os ataques habilitados pelo jailbreak e não confiar apenas na detecção do jailbreak para impedir os invasores.

 

Para ler mais sobre como Digital.ai Application Security pode proteger (detectando jailbreaks entre muitos outros truques) seus aplicativos iOS, baixe nosso Resumo do produto.