Publicado em: fevereiro 16, 2024
Entendendo as fugas da prisão
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 se libertar de restrições:
- Cadeia: Originalmente, o termo se referia 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 que rodam em seu sistema operacional iOS. A Apple mantém um controle rigoroso sobre o que os usuários podem e não podem fazer com seus dispositivos por meio das políticas da App Store e das medidas de segurança do sistema. Essas limitações incluem restrições à instalação de aplicativos de fontes que não sejam a App Store, à personalização da aparência e funcionalidade do dispositivo e ao acesso ao funcionamento interno do sistema operacional.
- Quebrar: Implica em escapar ou libertar-se de um confinamento. No contexto do jailbreak do iPhone, significa contornar ou burlar as restrições impostas pelo iOS da Apple. Esse processo envolve explorar vulnerabilidades no sistema iOS para obter acesso root ou privilégios administrativos, permitindo que os usuários modifiquem o dispositivo de maneiras que a Apple normalmente não permite.
Faça jailbreak em um iPhone concede ao usuário acesso total de execução e gravação. Portanto, em resumo, "jailbreak", no contexto de iPhones, significa essencialmente libertar-se das restrições e limitações impostas pelo iOS da Apple, permitindo que os usuários tenham mais controle sobre seus dispositivos e os personalizem ao seu gosto. O termo reflete a ideia de libertar seu iPhone da "prisão" metafórica das restrições da Apple, dando-lhe mais liberdade e flexibilidade com seu dispositivo.
O desejo de libertar o próprio telefone deu origem a uma "comunidade" de jailbreak composta por hackers, usuários curiosos e atores de ameaçasComo em qualquer comunidade que se preze, um grupo do Reddit (r / jailbreakA comunidade jailbreak se formou, canais do YouTube foram criados (e excluídos), e a dark web/web cinzenta facilita o compartilhamento de dicas, técnicas e procedimentos de jailbreak entre os membros da comunidade. Jailbreaks são procurados há muito tempo, e aqueles que os descobrem, executam e compartilham ganham fama ou notoriedade dentro da comunidade jailbreak.
Note 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 "quebrar" a política da Apple anule a garantia, isso não é, em si, ilegal, e muitos na comunidade de jailbreak consideram seu direito ou até mesmo obrigação participar de jailbreaks, e não necessariamente para fins maliciosos. Enquanto a comunidade de hackers, agentes de ameaças e brincalhões formou uma comunidade de jailbreak dedicada a frustrar os esforços da Apple para proteger seu sistema operacional, uma indústria lucrativa que quebra o iOS também se estabeleceu. Capacidadess como NSO, Cellebrite e Paragon oferecem técnicas sofisticadas de jailbreak mediante pagamento; e agências de aplicação da lei, bem como governos ao redor do mundo – embora relutem em admitir publicamente – quase com certeza aproveitar-se desses serviços.
No mundo da segurança da aplicaçãoNo contexto atual, o jailbreak assume uma importância desproporcional porque, sempre que um agente malicioso deseja adulterar (modificar) um aplicativo, uma das primeiras coisas que ele precisa fazer é realizar o jailbreak do telefone para garantir que o aplicativo modificado possa ser executado. Em outras palavras, embora o jailbreak não seja ilegal ou mesmo antiético, na maioria dos casos, é uma etapa necessária para usar um aplicativo que foi adulterado. Portanto, detectar telefones com jailbreak é fundamental para qualquer estratégia de segurança. endurecimento por aplicação solução.
Ao mesmo tempo, a Apple tem investido consistentemente tempo, dinheiro, esforço e engenhosidade para impedir completamente o jailbreak. Com o tempo, o jailbreak tornou-se mais complexo, 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 impedir o jailbreak é longa e repleta de histórias – essencialmente um jogo de gato e rato que impulsionou a inovação na "comunidade" de jailbreak e dentro da própria Apple.
Embora a detecção de jailbreak seja fundamental para garantir a segurança de aplicativos disponíveis publicamente, nem todos os jailbreaks são iguais; alguns nem sequer representam uma grande ameaça à segurança.
Este artigo irá 1) descrever a evolução dos jailbreaks para iPhone e 2) explicar quais tipos de jailbreak dão acesso total aos recursos do sistema no sentido original da palavra, e quais são versões menos poderosas do jailbreak tradicional.
A evolução conjunta do iOS e dos jailbreaks
Figura 1: Um grupo de jovens fugitivos da prisão na DEF CON (agosto de 2011). Crédito da foto: Dreamyshade – Obra própria, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=38871495
Os Primórdios: Explorações do BootROM
Inicialmente, o jailbreak focava principalmente no bootROM, um componente fundamental do processo de inicialização do dispositivo iOS. O bootROM é um software de baixo nível gravado permanentemente no hardware, o que torna as explorações nesse nível particularmente poderosas. 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 sem precedentes ao dispositivo, permitindo modificações permanentes que poderiam sobreviver a atualizações de software e redefinições. Essa era foi marcada por explorações famosas como limera1n e Pwnagetool, que desbloqueou iPhones em massa, permitindo instalações de firmware personalizado e modificações profundas do sistema.
A transição para o iBoot: vulnerabilidades do bootloader
À medida que a Apple reforçava o bootROM, os atacantes voltaram suas atenções para o iBoot, a próxima etapa no processo de inicialização do iOS. Explorações no bootloader, como redsn0w e Sn0wbreeze, embora menos permanentes do que as vulnerabilidades do bootROM, ainda ofereciam amplo controle sobre o dispositivo. Ao comprometer o iBoot, os atacantes podiam influenciar o kernel e o ambiente do usuário, permitindo personalização significativa e burlando as restrições do ecossistema da Apple. Essas vulnerabilidades podiam ser corrigidas por meio de atualizações de software, tornando-as um meio menos duradouro, mas ainda eficaz, de realizar jailbreak.
A Era do Kernel: Correções e Proteção
A progressão em direção à exploração de vulnerabilidades no kernel marcou uma evolução significativa nas táticas de jailbreak. Vulnerabilidades em nível de kernel, exploradas por ferramentas como... Pangu, taig e Yalu, permitia a execução de código não assinado e modificações profundas no sistema sem alterar o processo de inicialização. Essa era consolidou uma abordagem mais refinada para o 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 ao mesmo tempo uma aparência de conformidade com os protocolos de segurança do iOS.
Jailbreaks modernos: explorações precisas e específicas de processos
2015 foi um ponto de virada na história do jailbreak. A Apple, tendo efetivamente reforçado as defesas tanto do bootROM quanto do iBoot, não estava mais disposta a simplesmente reagir a várias vulnerabilidades em seu kernel com patches periódicos e partiu para o ataque contra a comunidade de jailbreak com uma série de inovações que essencialmente mantiveram a comunidade de jailbreak – bem como empresas como Cellebrite e NSO – em constante alerta.
No iOS 9 (setembro de 2015), a Apple introduziu a Proteção de Correção do Kernel (KPP), sua atualização de segurança mais crítica. A KPP refere-se a um código implementado no kernel para proteger a memória de leitura e execução e a memória somente leitura no cache do kernel. Ela faz isso realizando verificações aleatórias periodicamente.
Desde setembro de 2015, os jailbreaks foram divididos em KPPLess e KPP Bypass. KPPLess é uma técnica que mantém o KPP em execução, ou seja, burla a verificação do KPP. KPP Bypass desativa o KPP completamente. Antes do KPP, um atacante geralmente precisava ter permissão de escrita no kernel para modificar o código de segurança.
Nos chips A10, originalmente lançados com o iOS 10 em junho de 2016, a Apple introduziu o KTRR (Kernel Text Read only Region), que impede a modificação do kernel do iOS em tempo de execução. Chips mais antigos tentavam fazer isso por meio de um programa monitor carregado no EL3, mas o método era inerentemente falho, e a comunidade de jailbreak já havia descoberto maneiras de contornar o programa de monitoramento. A partir dos chips A10, a Apple efetivamente moveu as verificações de segurança para o próprio hardware, dificultando assim a vida dos jailbreakers (tanto na comunidade quanto no setor comercial).
Em junho de 2018, com o lançamento do iOS 12, a Apple introduziu o PAC (Pointer Authentication Code), sua implementação de Autenticação de Ponteiros. O PAC utiliza os bits mais significativos de um ponteiro para armazenar uma assinatura criptográfica, 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. Isso permite que o sistema ofereça garantias criptográficas robustas sobre a probabilidade de determinados ponteiros terem sido adulterados por atacantes, o que possibilita uma melhoria significativa na segurança de aplicativos.
Quando os chips A12 foram lançados no final daquele ano (setembro de 2018), a Apple introduziu a Camada de Proteção de Páginas (PPL). O objetivo da PPL é impedir que agentes maliciosos 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 no kernel. Essa é mais uma medida de mitigação de exploits que pode dificultar o encadeamento de ataques. Ela faz isso utilizando o APRR para criar um "kernel dentro do kernel" que protege as tabelas de páginas. A única maneira de o kernel modificar as tabelas de páginas é entrar na PPL chamando uma "rotina PPL", que é análoga a uma chamada de sistema do XNU para a PPL. Isso limita os pontos de entrada no código do kernel que podem modificar as tabelas de páginas apenas a essas rotinas PPL. Podemos resumir por que essa mudança no A12 foi significativa para a comunidade de jailbreak?
A comunidade de jailbreak viveu um período de relativa calma até junho de 2021, quando a Apple lançou o iOS 15. O iOS 15 causou grande alvoroço na comunidade ao introduzir o SSV, o Volume de Sistema Selado. Esse mecanismo é um recurso de segurança em nível de kernel que sela o volume com uma assinatura criptográfica conhecida apenas pela Apple, rejeitando qualquer código que tente modificar o conteúdo do sistema e, consequentemente, impedindo alterações não autorizadas antes da inicialização do iOS. Esse método forçou a comunidade de jailbreak a mudar toda a estrutura das arquiteturas de jailbreak anteriores. Desde então, os jailbreaks se dividiram em rootless e rootful.
Os jailbreaks sem root mantêm todos os arquivos e modificações fora do diretório raiz, geralmente em / var e /privado/pré-inicializaçãoOs jailbreaks com root usam bind mounts que efetivamente criam um root "falso", que então age como o root real. rootfs, mas requer uma vulnerabilidade no bootROM.
Como o jailbreak foi realizado sem modificar o código do kernel, os efeitos agora não são generalizados em todo o sistema, mas sim aplicados a cada processo individualmente. Isso significa que, em vez de fazer jailbreak no sistema operacional, agora o jailbreak é feito em cada processo.
Podemos analisar a situação da seguinte forma: na era dos jailbreaks "pré-modernos", bastava aplicar um patch no kernel para afetar todo o sistema. Agora, com tantos jailbreaks (Quimera, checkra1nAo manipular estruturas de dados do kernel em vez de corrigir diretamente o código do kernel, a manipulação ocorre por processo. Esse estado complica a detecção do jailbreak. Embora a integridade da maior parte do sistema pareça intacta, existe uma lógica implementada para determinar se um processo foi submetido a jailbreak ou não. Isso significa que, a menos que seja intencional, o processo permanece em jailbreak. Por sua vez, isso significa que, mesmo que esse tipo de jailbreak conceda acesso a recursos que a Apple não pretende que o aplicativo acesse, ele não dá acesso a todos os processos, o que é importante porque significa que o jailbreak em si não é necessariamente perigoso para todos (ou mesmo para qualquer um) dos aplicativos no telefone.
Essa nova forma de desbloqueio é tecnicamente complicada, para dizer o mínimo. Ela requer hooks em launchd onde todos os processos são invocados, os hooks execve e a inserção de todos os novos processos são executados imediatamente após a sua criação. E, infelizmente (da perspectiva da comunidade de jailbreak), toda essa criatividade técnica resulta em menos "liberdades".
Implicações para Application Security Engenheiros e DevSecOps Gerentes
Então, o que tudo isso significa para você, engenheiro de segurança de aplicações? Bem, um dos melhores mecanismos de defesa que oferecemos é o “Proteção automática de aplicativos em tempo de execução, ou RASP.O RASP permite que nossos clientes programem seus aplicativos para reagirem automaticamente quando e se as proteções forem acionadas. Alguns clientes já utilizam o RASP há algum tempo para tomar medidas quando e se o jailbreak for iniciado.
Mas se a longa história do jogo de gato e rato entre a Apple e a comunidade de jailbreak nos ensinou alguma coisa, é que nem todos os jailbreaks são iguais. Alguns exigem "conexão" com um computador, oferecendo pouco valor funcional para usuários curiosos ou qualquer pessoa além dos hackers mais determinados e acadêmicos. Existem vários tipos, como "semi-conectado", sem root e com root. Alguns podem ser considerados indistinguíveis do termo "jailbreak" devido ao seu escopo limitado, assemelhando-se mais a experimentos de hackers do que a um "produto" funcional. Embora os esforços contínuos da Apple para deter os jailbreaks tenham impulsionado a inovação na comunidade, também tornaram os jailbreaks modernos menos poderosos com o tempo. Em outras palavras, a busca implacável 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 conseguem conferir, mesmo com o aumento da habilidade técnica necessária para realizar essas pequenas façanhas.
Por esse motivo, aconselhamos que as empresas que criam aplicativos para seus clientes usem uma abordagem mais precisa do que agressiva ao reagir a sinais de jailbreak. Por exemplo, registrar a ocorrência de um jailbreak pode ser suficiente, e talvez não seja mais necessário programar uma reação específica para esse tipo de ataque. Caso seja necessário programar uma reação, considere quais outras proteções são acionadas em conjunto com o jailbreak ao desenvolver sua estratégia de Autoproteção de Aplicativos em Tempo de Execução (RASP). O jailbreak é um facilitador. É importante detectar os ataques que são possibilitados PELO jailbreak e não depender apenas da detecção do jailbreak para impedir os invasores.
Para saber mais sobre como Digital.ai Application Security Pode proteger (detectando jailbreaks, entre muitos outros truques) seus aplicativos iOS. Baixe nosso Resumo do produto.
Também recomendamos
O que a grande mídia está deixando de abordar sobre o mito
Vimos algumas histórias sobre segurança cibernética ganharem destaque na mídia tradicional…
Ataques de IA Agencial: O Agente Smith Saiu da Aposentadoria
Os defensores da evolução sem natureza continuam a testar os limites da IA…
Combater fogo com fogo: usando IA para combater IA
Os ataques a aplicativos aumentaram para 83% em janeiro de 2025, em comparação com 65% apenas em…