Há vulnerabilidades de software, que podem ser corrigidas com uma atualização baixada pela internet em poucos minutos, e há vulnerabilidades de hardware, gravadas em silício, que acompanham o dispositivo para o resto de sua vida útil.
A descoberta de uma falha Irreparável de Hardware que afeta sete gerações de iPhones foi a mais recente divulgada por uma equipe de pesquisa que afeta uma quantidade significativa de dispositivos Apple ainda em uso por milhões de pessoas ao redor do mundo.
Pesquisadores da Paradigm Shift publicaram um extenso relatório que detalha a falha de segurança inerente a alguns dispositivos da Apple. O problema de segurança envolve a porta USB e vários chips de silício da Apple, e é chamado de usbliter8.
Quais Dispositivos Estão Realmente Afetados
Antes de entrar nos detalhes técnicos, é fundamental entender a abrangência real desse problema, porque ela é considerável.
A vulnerabilidade usbliter8 afeta todos os dispositivos com chips A12, A13, S4 e S5. Isso inclui o iPhone XR, o iPhone XS e XS Max, o iPad Air 3, o iPad mini 5, o iPad 8, o Apple TV 4K de segunda geração, o iPhone 11, o 11 Pro e 11 Pro Max, o iPhone SE de segunda geração, o iPad 9, o Studio Display, o Apple Watch Series 4, o Series 5 e o Apple Watch SE de primeira geração. Os proprietários desses dispositivos devem ficar atentos a essa descoberta.
São, portanto, sete gerações distintas de produtos Apple, lançados entre 2018 e 2020, ainda amplamente utilizados hoje, especialmente porque a Apple historicamente mantém um ciclo de suporte de software bastante longo para seus dispositivos.
O que é o usbliter8 e Como Ele Funciona
Para entender a essência dessa vulnerabilidade, é importante primeiro localizar exatamente onde, dentro da arquitetura de um dispositivo Apple, esse problema se manifesta.
O relatório da Paradigm Shift descreve uma nova vulnerabilidade no BootROM do iPhone, descoberta e explorada pela própria equipe.
BootROM é o primeiro código que executa quando um dispositivo é ligado, antes mesmo do sistema operacional, gravado de forma permanente e imutável diretamente no chip durante a fabricação.
Por isso, qualquer falha encontrada nesse nível não pode, simplesmente, ser corrigida remotamente como aconteceria com um aplicativo ou com o próprio sistema operacional.
A vulnerabilidade se explora em torno de um bug de hardware específico da porta USB e uma falha de configuração específica no firmware do dispositivo, tornando a exploração impossível de corrigir através de atualizações tradicionais de software.
A Conexão com o Modo DFU
O ponto de entrada prático para essa exploração é um recurso bastante conhecido entre técnicos e entusiastas que trabalham com dispositivos Apple, o modo DFU, sigla para Device Firmware Update, ou Atualização de Firmware do Dispositivo. Esse modo permite restaurar completamente o software de um iPhone, iPad ou outro dispositivo Apple quando ele não consegue inicializar normalmente.
No modo DFU, você pode enviar dados específicos para o dispositivo via USB, confundindo o controlador USB e forçando-o a gravar dados na parte errada da memória, injetando código personalizado antes mesmo do iOS inicializar. Dessa forma, é possível burlar verificações de assinatura, executar software de sistema modificado, entre outras ações que normalmente seriam bloqueadas pelas camadas de segurança da Apple.
Os Novos Malwares para Mac que Miram as Chaves de Desenvolvedor
Um Bilhão de Registros Expostos: O Vazamento de Dados que colocou 39 Milhões de Brasileiros em Risco
Massiv: Trojan Bancário que usa Apps falsos de IPTV para esvaziar contas e abrir Dívidas em Bancos que Você nunca usou
108 Extensões Maliciosas do Chrome Roubam Contas do Google e do Telegram: Veja a Lista e Como se Proteger
- Ofertas na Amazon
O Detalhe Técnico Central: um Bug no Controlador USB DWC2
Para quem quer entender a raiz exata do problema, o relatório completo da Paradigm Shift descreve, com bastante precisão técnica, onde a falha realmente reside.
O controlador USB usado pela Apple em seus chips é o DWC2, da empresa Synopsys, um componente padrão na indústria, não exclusivo da Apple.
O processador de aplicativos do dispositivo configura uma transferência via DMA, sigla para Acesso Direto à Memória, alocando uma região de memória e gravando o endereço físico correspondente em um registrador específico, chamado DOEPDMA, dentro da área de memória do controlador.
O bug central foi descrito da seguinte forma pelos próprios pesquisadores. O controlador USB armazena até três pacotes de configuração consecutivos na memória.
Ao receber uma quarta transação de configuração, o endereço base do DMA é redefinido para sua posição inicial, de forma semelhante a um mecanismo de buffer circular.
Depois de gravar cada pacote recebido, o controlador incrementa o valor do registrador DOEPDMA pelo tamanho dos dados gravados, e a operação de reinicialização é implementada decrementando esse mesmo valor em 24 unidades.
O problema central surge porque o controlador também aceita pacotes menores que o tamanho padrão, embora sempre os armazene em blocos de 4 bytes.
Como o incremento do ponteiro de memória não corresponde exatamente ao valor fixo usado na operação de decremento, isso resulta em uma primitiva de underflow de buffer, em incrementos de 12 bytes, ou seja, uma forma controlada de fazer o sistema escrever dados além dos limites de memória originalmente previstos para aquele buffer.
Por que o A11 Escapa, mas o A12 e o A13 não
Um dos detalhes mais reveladores da pesquisa explica precisamente a diferença entre gerações de chip que ficam vulneráveis e a única que não fica. Até o momento, os pesquisadores confirmaram que as SecureROMs dos chips A12 e A13 são vulneráveis, enquanto a do A11 não é.
A diferença reside no fato de que o driver USB do A11 redefine manualmente o endereço de DMA para seu valor inicial após o recebimento de cada pacote, uma proteção simples que, por algum motivo, deixou de ser implementada dessa forma nos chips seguintes.
Já nos modelos A12 e A13, o componente conhecido como USB DART está configurado em modo bypass, permitindo sobrescrever livremente os dados da SRAM, a memória de acesso rápido usada nesse estágio inicial de inicialização. Em contraste, segundo o relatório, o A14 e as gerações posteriores parecem configurar o DART corretamente já no SecureROM, o que torna essa mesma vulnerabilidade inexplorável nesses chips mais recentes.
Como os Pesquisadores Obtiveram Controle Total do Dispositivo
A parte mais técnica do relatório descreve como essa primitiva inicial de corrupção de memória foi transformada em controle completo de execução de código, um processo que variou consideravelmente entre o chip A12 e o A13, justamente por conta de uma proteção de segurança adicional presente apenas no segundo.
No Chip A12 e nos Chips S4/S5
Obter o controle do registrador de programa, ou PC, no A12 foi descrito pelos pesquisadores como relativamente direto, já que o buffer de DMA do controlador USB é alocado na memória heap logo após a pilha da própria tarefa responsável pelo USB.
A abordagem mais simples envolveu sobrescrever um endereço de retorno salvo na pilha e obter controle direto do processador quando o sistema realizasse uma troca de contexto de volta para essa tarefa.
Esses chips específicos, A12 e os chips S4 e S5 usados em modelos do Apple Watch da mesma época, não utilizam uma proteção chamada PAC, sigla para Pointer Authentication Code, ou Código de Autenticação de Ponteiro, no SecureROM.
Isso permitiu aos pesquisadores executar uma técnica clássica de exploração conhecida como ROP, sigla para Return-Oriented Programming, ou Programação Orientada a Retorno, encadeando pequenos trechos de código já existentes no próprio firmware para alcançar o resultado desejado, mesmo com uma cadeia relativamente curta, de apenas alguns passos.
No Chip A13: o Desafio Adicional do PAC
As coisas não foram tão simples no SecureROM do A13, justamente devido à introdução dessa proteção PAC, que assina criptograficamente determinados ponteiros para impedir esse tipo exato de manipulação direta de endereços de retorno.
Segundo a análise dos pesquisadores, o PAC parece ser aplicado apenas aos endereços de retorno armazenados na pilha, o que, ainda assim, foi suficiente para impedir o caminho mais direto usado anteriormente no A12.
Diversas medidas de mitigação adicionais também precisaram ser contornadas ao longo do processo, incluindo verificações de soma de checagem dos metadados de memória heap e a própria assinatura dos endereços de retorno durante trocas de contexto do sistema.
Depois de várias iterações de tentativa, a equipe chegou a uma técnica de múltiplas etapas, envolvendo a sobrescrita cuidadosa de dados específicos relacionados ao componente DART, a neutralização temporária de um contador global de pânico do sistema, para evitar que o dispositivo reiniciasse durante o processo, e a manipulação cuidadosa do momento exato em que certas escritas de memória ocorrem, sincronizadas com o ciclo de vida da própria tarefa USB no sistema.
Ao final dessa sequência complexa de manipulações, os pesquisadores conseguiram sobrescrever a variável global que armazena o próprio manipulador de interrupções USB do sistema, alcançando, assim, controle total sobre o que o processador executa em seguida.
O que Acontece Depois de Obter Controle Total
Uma vez estabelecido o controle de execução, os pesquisadores ainda precisaram lidar com uma camada adicional de restrição de privilégios dentro da própria arquitetura do processador.
A partir do A12, o SecureROM opera principalmente no chamado modo EL0, o nível de privilégio mais baixo dentro da arquitetura ARM usada pelos chips da Apple, o que impede acesso direto a regiões de memória protegidas, como as tabelas da unidade de gerenciamento de memória, conhecida como MMU, e a registradores especiais de controle do processador.
Para contornar essa limitação, os pesquisadores identificaram que o próprio SecureROM ocasionalmente alterna a execução para um modo mais privilegiado, chamado EL1, através de uma instrução específica de chamada de sistema. Embora esse mecanismo não funcione como uma interface tradicional de chamadas de sistema, ele oferece, em pontos muito específicos e raros dentro da ROM, exatamente a brecha de elevação de privilégio necessária para os objetivos da pesquisa.
Reiniciando a Própria ROM com Modificações Permanentes (Até a Próxima Reinicialização)
Com controle de execução privilegiada estabelecido, a etapa final descrita pelos pesquisadores envolveu reiniciar todo o ambiente do SecureROM, mas de uma forma que preservasse as modificações já injetadas.
A forma como isso foi feito envolveu reiniciar o próprio SecureROM e deixar que ele reinicializasse tudo automaticamente, mas copiando previamente a ROM original para o final da memória SRAM, permitindo modificá-la livremente antes dessa reinicialização interna.
Como a ROM original espera ser executada a partir de seu endereço físico original, e não da posição na SRAM para onde foi copiada, os pesquisadores tiveram que configurar a própria unidade de gerenciamento de memória para mapear os endereços físicos da cópia na SRAM de volta para os endereços virtuais originais esperados pela ROM, garantindo que referências internas ao código continuassem funcionando corretamente mesmo após essa relocação.
Uma série de pequenos ajustes técnicos adicionais, descritos pelos próprios pesquisadores como uma lista de “patches”, incluiu reduzir o tamanho considerado válido da área de carregamento de dados para evitar que a própria ROM apagasse acidentalmente sua versão modificada, forçar o retorno ao modo DFU em vez de inicializar normalmente o que estivesse armazenado na memória NAND do dispositivo, modificar o número de série USB exibido pelo dispositivo para incluir um identificador específico confirmando a exploração bem-sucedida, e injetar o manipulador personalizado de requisições USB desenvolvido pela própria equipe.
O Manipulador Personalizado: o que Ele Permite Fazer
Uma vez que todo esse processo de exploração é concluído, os pesquisadores implementaram um manipulador relativamente simples de comandos, que encaminha normalmente todas as solicitações padrão do modo DFU para o código original do sistema, mas adiciona duas capacidades específicas e personalizadas.
A primeira é chamada de rebaixamento, que diminui temporariamente o modo de produção do chip, válida apenas até a próxima reinicialização do dispositivo.
A segunda é a inicialização direta de imagens do iBoot, o carregador de sistema usado em estágios posteriores de inicialização, permitindo que imagens completamente não verificadas sejam executadas, sem passar pela verificação criptográfica de assinatura que normalmente impediria a execução de software não autorizado pela Apple.
Os pesquisadores descreveram, inclusive, um obstáculo curioso encontrado durante essa fase final, ao tentar chamar a função responsável por esse salto de execução diretamente a partir do próprio manipulador personalizado, o processo simplesmente não funcionava, porque essa função coloca diversos componentes de hardware, incluindo o próprio controlador USB, em um estado de baixo consumo, o que acabava encerrando a própria tarefa USB que estava sendo usada para executar o ataque.
A solução encontrada envolveu sobrescrever o endereço de retorno da tarefa principal do sistema na pilha, e então encerrar deliberadamente a sessão USB, permitindo que a tarefa principal despertasse e retomasse a execução exatamente no ponto desejado pelos pesquisadores.
O que Permanece Seguro: o Secure Enclave
Em meio a todos esses detalhes técnicos preocupantes, há uma informação fundamental que oferece um real alívio para quem possui um dos dispositivos afetados.
Felizmente, a vulnerabilidade não afeta o Enclave de Segurança do dispositivo, onde residem os dados criptografados, como senhas e outros dados confidenciais do usuário.
O Secure Enclave Processor, conhecido pela sigla SEP, é um coprocessador isolado dentro dos chips da Apple, dedicado exclusivamente a armazenar e processar informações extremamente sensíveis, como chaves de criptografia, dados biométricos do Face ID e Touch ID, e credenciais de pagamento.
O próprio relatório da Paradigm Shift reforça esse ponto com precisão técnica. A segurança da BootROM é crítica, já que vulnerabilidades nesse nível podem comprometer a integridade de todo o dispositivo.
No entanto, o Secure Enclave Processor da Apple adiciona uma camada extra de segurança entre o atacante e os dados do usuário. Embora o usbliter8 não afete diretamente o próprio Secure Enclave, essa vulnerabilidade abre vetores de ataque mais amplos para tentar comprometer esse componente por outros meios, ainda que não diretamente através dessa falha específica.
O Pré-Requisito que Limita o Risco Real: Acesso Físico
Outro fator que reduz significativamente o risco prático dessa vulnerabilidade para o usuário médio é uma exigência fundamental para que ela possa ser explorada.
A boa notícia é que os atacantes precisam ter o dispositivo em mãos para explorar a vulnerabilidade. Diferente de falhas que podem ser exploradas remotamente através de uma rede ou da internet, o usbliter8 exige conexão física via cabo USB com o dispositivo no modo DFU, um cenário que normalmente só se aplica a situações específicas, como dispositivos roubados, perdidos, ou confiscados por terceiros que tenham acesso físico direto ao aparelho e conhecimento técnico avançado para executar todo o processo de exploração descrito no relatório.
O que a Apple Fez, e o que os Usuários Podem Fazer
Diante de uma vulnerabilidade que, por sua própria natureza, não pode ser corrigida remotamente, a pergunta natural é, o que resta fazer?
Os pesquisadores disseram que a Apple trabalhou em estreita colaboração com eles para resolver o problema, mas, no fim das contas, a solução mais eficaz para garantir a segurança dos seus dados, caso seu aparelho seja roubado, é atualizar o dispositivo para uma versão mais recente de hardware.
Curiosamente, o bug não afeta dispositivos mais antigos com o chip A11, por exemplo, reforçando que essa é uma falha específica introduzida nas gerações seguintes, e corrigida apenas a partir do A14.
O próprio relatório técnico reforça essa mesma conclusão de forma direta. Como essas vulnerabilidades residem em código imutável, os usuários afetados devem estar cientes de que a migração para hardware mais recente continua sendo a solução mais eficaz disponível.
Embora as gerações mais recentes tenham resolvido o problema subjacente, os dispositivos A12 e A13 afetados continuarão com ele pelo resto de sua vida útil, segundo a conclusão direta dos próprios pesquisadores da Paradigm Shift.
Para quem acompanha a história da exploração e do jailbreak do iPhone, essa pesquisa serve como um lembrete de que o BootROM ainda reserva surpresas de vez em quando, mesmo em chips que já têm vários anos de mercado e que, supostamente, já teriam sido exaustivamente analisados pela comunidade de segurança.
A Divulgação Responsável e a Colaboração com a Apple
Vale destacar, por fim, o processo seguido pelos próprios pesquisadores antes de tornar essa descoberta pública, um procedimento padrão e considerado ético dentro da comunidade de pesquisa em segurança da informação.
Os pesquisadores reportaram essas descobertas à equipe de Segurança de Produtos da Apple antes da publicação, e coordenaram a divulgação em conjunto com a própria empresa.
A equipe da Paradigm Shift agradeceu publicamente à equipe de Segurança de Produtos da Apple pela resposta rápida, pelo engajamento construtivo e pela cooperação durante todo o processo de divulgação, um reconhecimento que sugere que, embora a falha em si não tenha solução de software, a relação entre pesquisadores e a Apple ao longo desse processo específico transcorreu de forma colaborativa.
Segundo a própria filosofia declarada pela equipe de pesquisa, o avanço da segurança exige tanto engenharia defensiva quanto pesquisa ofensiva aprofundada, e projetos como esse ajudam a revelar as limitações práticas das mitigações de segurança já existentes, contribuindo, em última análise, para a construção de sistemas mais resilientes nas gerações futuras de hardware.
Resumo: o que Você Precisa Saber se Tiver um Desses Dispositivos
Para fechar com objetividade prática, quem possui qualquer um dos dispositivos listados no início deste artigo, da era do iPhone XR e XS até a geração do iPhone 11, deve ter em mente alguns pontos centrais.
A vulnerabilidade exige posse física do aparelho para ser explorada, não pode ser corrigida remotamente por nenhuma atualização de software futura, não compromete os dados protegidos especificamente pelo Secure Enclave, como senhas e informações de pagamento, e a única mitigação genuinamente eficaz, segundo os próprios descobridores da falha, é a substituição do hardware por um modelo mais recente, a partir da geração equipada com o chip A14.
Fonte consultada: relatório técnico completo publicado pela equipe de pesquisa da Paradigm Shift sobre a vulnerabilidade usbliter8.
