Vulnerabilidades em aplicativos confiáveis da Xiaomi permitiam rebaixamento de componentes, corrupção de memória e risco de falsificação de pacotes de pagamento protegidos pelo Tencent Soter.
| Componente | Aplicativos confiáveis da Xiaomi executados no Beanpod TEE em dispositivos MediaTek, incluindo thhadmin e o aplicativo Soter usado para operações do Tencent Soter. |
| Vetor | Rebaixamento de aplicativos confiáveis sem controle de versão e invocação de interfaces TEE a partir de contexto Android com permissão, como usuários privilegiados autorizados pelo SELinux. |
| Impacto | Possível bypass de correções, desativação do sistema de pagamento, vazamento de chaves protegidas, execução de código no contexto do aplicativo confiável e falsificação condicionada de pacotes de pagamento. |
| Prioridade | Validar atualizações de firmware e componentes TEE, impedir rebaixamento de aplicativos confiáveis, revisar acessos ao dispositivo TEE e monitorar falhas anômalas relacionadas ao Soter. |
| Versões | O teste citado usou Xiaomi Redmi Note 9T 5G com MIUI Global 12[.]5[.]6[.]0 e rebaixamento de thhadmin extraído de MIUI Global 10[.]4[.]1[.]0. |
| Artefatos | Aplicativos confiáveis armazenados em /vendor/thh/ta, biblioteca cliente /vendor/lib/libTEECommon.so e aplicativo Soter identificado pelo arquivo d78d338b1ac349e09f65f4efe179739d.ta. |
A pesquisa analisou a implementação de aplicativos confiáveis da Xiaomi em smartphones baseados em chips MediaTek, com foco no ambiente de execução confiável usado para proteger operações sensíveis. O alvo principal foi a camada TEE que armazena e processa material criptográfico relacionado a pagamentos móveis, autenticação biométrica e validação de transações. O modelo de segurança esperado é que o mundo confiável permaneça isolado mesmo quando o Android esteja comprometido, mas a análise mostrou que componentes escritos e integrados pelo fabricante do dispositivo também precisam de validação rigorosa, porque erros nessa camada podem comprometer garantias que normalmente são atribuídas ao hardware.
O cenário técnico envolve dispositivos Xiaomi com Beanpod TEE, aplicativos confiáveis armazenados em /vendor/thh/ta e integração com o Tencent Soter, plataforma usada para assinar e validar pacotes de pagamento. O fluxo de pagamento depende de chaves assimétricas mantidas dentro do TEE, incluindo chave do dispositivo, chave da aplicação e chave de negócio. Quando esse encadeamento funciona corretamente, o servidor consegue verificar que uma transação foi originada de uma aplicação específica, em um dispositivo específico, após aprovação do usuário. As falhas descritas quebram partes importantes desse pressuposto ao permitir rebaixamento de componentes, corrupção de memória e acesso indevido a dados internos do aplicativo confiável.
O impacto não se limita a uma falha de aplicativo Android comum. A superfície analisada fica no limite entre o sistema operacional móvel e o ambiente confiável, onde ficam chaves privadas e funções de assinatura. O material analisado indica que as vulnerabilidades poderiam permitir falsificação de pacotes de pagamento ou desativação do sistema de pagamento a partir de uma aplicação Android sem privilégios diretos, desde que o invasor consiga alcançar um contexto autorizado a conversar com o dispositivo TEE. Também foi descrita a possibilidade de vazamento de chaves e execução de código dentro do aplicativo confiável, o que eleva a prioridade de correção para fabricantes, equipes de engenharia de dispositivos e equipes que dependem de atestação local para pagamentos.
Em dispositivos Xiaomi com MediaTek, os aplicativos confiáveis podem ser assinados e embutidos pelo fabricante do aparelho. A análise observou que o formato desses aplicativos não incluía um campo de controle de versão capaz de impedir rebaixamento. Com isso, uma versão antiga e ainda assinada poderia substituir uma versão nova no dispositivo e ser aceita pelo TEE. No teste descrito, o aplicativo confiável thhadmin, responsável por funções de gerenciamento de segurança, foi substituído em um Xiaomi Redmi Note 9T 5G com MIUI Global 12[.]5[.]6[.]0 por uma versão extraída de outro aparelho com MIUI Global 10[.]4[.]1[.]0. O componente antigo foi carregado com sucesso, apesar de apresentar diferenças relevantes de código.
Esse rebaixamento é importante porque transforma uma correção anterior em uma defesa frágil: se o TEE aceita código antigo apenas porque a assinatura continua válida, vulnerabilidades já corrigidas podem voltar a ficar exploráveis. A condição técnica central não é a ausência de assinatura, mas a ausência de uma política de versão monotônica para aplicativos confiáveis. Para equipes de segurança, isso significa que a verificação de integridade precisa cobrir não apenas autenticidade criptográfica, mas também versão mínima permitida, origem do binário e coerência entre firmware, sistema operacional e componentes do ambiente confiável.
A comunicação entre Android e TEE segue a API cliente da GlobalPlatform, implementada na biblioteca /vendor/lib/libTEECommon.so. O acesso direto aos aplicativos confiáveis não é concedido a qualquer aplicação Android: a política SELinux restringe o objeto teei_client_device a usuários privilegiados, como contextos associados a mídia e DRM. Ainda assim, o contexto técnico descreve que vulnerabilidades anteriores no decodificador ALAC poderiam permitir que uma aplicação sem privilégio executasse código sob o usuário mediacodec, criando uma ponte para invocar aplicativos confiáveis. A cadeia, portanto, depende de uma combinação de falha no lado Android com interfaces sensíveis expostas ao contexto privilegiado.
Dentro dos aplicativos confiáveis, a função TA_InvokeCommandEntryPoint processa identificadores de comando e buffers enviados pelo lado Android. Esse ponto foi tratado como uma superfície adequada para fuzzing, porque concentra parsing, validação de parâmetros e manipulação de memória. A análise encontrou problemas no thhadmin que poderiam levar a vazamento de chaves armazenadas ou execução de código no contexto do aplicativo confiável. O detalhe defensivo relevante é que entradas malformadas conseguiam atingir corrupção de heap, indicando validação insuficiente de tamanhos, tipos e regiões de memória antes do processamento dentro do TEE.
No fluxo do Tencent Soter, o aplicativo confiável identificado como d78d338b1ac349e09f65f4efe179739d.ta armazena e opera chaves usadas para autenticação de transações. O comando initSigh, associado ao identificador 0x100C, inicia uma sessão de assinatura recebendo o alias da AuthKey e uma string de desafio. A vulnerabilidade descrita ocorre porque alias e desafio são concatenados em um buffer de tamanho fixo sem checagem adequada de limites. Entradas maiores que o esperado podem sobrescrever dados adjacentes no heap. O contexto também indica que os aplicativos confiáveis da Xiaomi não tinham ASLR, o que reduz a aleatoriedade disponível para dificultar exploração de corrupção de memória.
Além da corrupção de heap, foi descrita uma vulnerabilidade de leitura arbitrária em uma versão antiga do aplicativo Soter, justamente o tipo de falha que se torna mais grave quando combinada com rebaixamento. O problema conceitual envolve parâmetros passados via TEEC_Operation: se o chamador informa um tipo de parâmetro diferente do que o aplicativo confiável espera, e o aplicativo não valida corretamente paramTypes nem usa TEE_CheckMemoryAccessRights, um valor numérico pode ser interpretado como endereço virtual. Em termos defensivos, essa classe de bug expõe a necessidade de validação explícita de tipo, tamanho e permissão de acesso em cada comando exposto por um aplicativo confiável.
A superfície técnica envolve smartphones Xiaomi baseados em MediaTek que usam Beanpod TEE ou implementações associadas de aplicativos confiáveis integrados pelo fabricante. O material analisado cita especificamente o Xiaomi Redmi Note 9T 5G com MIUI Global 12[.]5[.]6[.]0 como dispositivo de teste e menciona comparação com componentes extraídos de MIUI Global 10[.]4[.]1[.]0. Também são citados outros modelos usados para comparação de campos de formato, como Xiaomi T11 e Xiaomi Note 8 Pro, mas o contexto não fornece uma matriz completa de versões vulneráveis. Assim, a exposição deve ser tratada como condicionada aos dispositivos que compartilham a mesma implementação e aceitam os mesmos aplicativos confiáveis sem proteção contra rebaixamento.
O ponto mais sensível é a dependência de pagamentos móveis em chaves privadas mantidas pelo TEE. No Tencent Soter, a chave privada ATTK é gerada no TEE antes de o aparelho sair de fábrica; a chave ASK é gerada para uma aplicação; e a AuthKey é usada em cenários de negócio, como pagamento ou login. A assinatura de dados de transação ocorre após autenticação por impressão digital, usando desafio do servidor, identificador biométrico, informações do dispositivo e dados de pagamento. Se uma chave privada vinculada a esse fluxo for extraída ou usada indevidamente, o servidor pode receber pacotes que parecem ter sido aprovados por um dispositivo legítimo.
A exposição operacional também depende das permissões locais. Uma aplicação Android comum não tem autorização direta para conversar com aplicativos confiáveis da Xiaomi. Porém, a presença de contextos privilegiados autorizados pelo SELinux cria uma superfície de encadeamento: uma falha em componente que execute sob um desses usuários pode transformar uma aplicação inicialmente sem privilégio em chamadora efetiva da interface TEE. Esse detalhe é importante para triagem de risco, porque a vulnerabilidade não precisa começar dentro do TEE; ela pode depender de uma etapa anterior no Android, seguida por abuso de uma API interna sensível.
- Dispositivos Xiaomi com chips MediaTek e Beanpod TEE, quando usam aplicativos confiáveis compatíveis com o formato analisado.
- Aplicativos confiáveis em
/vendor/thh/ta, incluindothhadmine o componente Soter usado para operações de chave e assinatura. - Fluxos de pagamento que dependem de Tencent Soter, AuthKey, ASK e ATTK para validação de pacotes de transação.
- Contextos Android privilegiados com permissão SELinux para acessar
teei_client_device, especialmente quando combinados com falhas em componentes de mídia ou DRM.
A detecção deve começar pela integridade dos componentes confiáveis. Em uma frota gerenciada, equipes de mobilidade e segurança podem comparar versões, hashes internos controlados pelo inventário corporativo e origem dos arquivos em /vendor/thh/ta, procurando divergências entre firmware instalado, versão MIUI reportada e binários confiáveis esperados para aquele pacote. Como o problema descrito aceita rebaixamento de aplicativo assinado, uma assinatura válida não deve ser tratada como único critério de confiança. O sinal de interesse é a presença de um componente antigo em um sistema que deveria conter uma versão mais recente.
No lado do sistema operacional, falhas do aplicativo Soter podem aparecer como registros de crash parcialmente cifrados no log do núcleo Android. Um evento isolado pode ser ruído, mas repetição associada a chamadas de assinatura, geração de chaves ou autenticação de pagamento merece análise. Também é relevante correlacionar crash de TEE com atividade recente de processos privilegiados, especialmente mediacodec, DRM e outros contextos autorizados a acessar a interface TEE. A defesa deve procurar sequências em que uma aplicação de terceiro aciona processamento de mídia ou outro componente vulnerável e, logo depois, ocorre interação incomum com serviços de pagamento ou aplicativos confiáveis.
Para equipes de fraude e backend de pagamento, a telemetria não deve ficar restrita ao aparelho. Como o Soter é usado para validar pacotes assinados, eventos anômalos no servidor podem revelar abuso mesmo quando o endpoint não fornece todos os detalhes. Indicadores úteis incluem geração inesperada de novas chaves de aplicação ou negócio para o mesmo dispositivo, mudanças de padrão em alias de AuthKey, aumento de falhas de validação, assinaturas válidas em contexto de sessão inconsistente e transações que passam por validação criptográfica, mas apresentam divergências de dispositivo, aplicação, usuário ou desafio.
A análise de memória e de exploração não deve ser transformada em reprodução ofensiva no ambiente de produção. O trabalho defensivo suficiente é verificar se os comandos expostos por aplicativos confiáveis validam paramTypes, tamanhos de buffers e permissões de acesso antes de processar dados fornecidos pelo lado Android. Em engenharia de produto, fuzzing controlado de TA_InvokeCommandEntryPoint pode ser usado em laboratório para encontrar classes semelhantes de falhas. Em operação, a prioridade é observar sintomas: rebaixamento, crashes, chamadas fora do perfil esperado e discrepâncias entre assinatura, sessão e contexto de autorização.
- Binários confiáveis antigos em
/vendor/thh/tapresentes em firmware que deveria conter componentes mais novos. - Crash recorrente do aplicativo Soter ou de aplicativos confiáveis durante operações de assinatura, chave ou autenticação biométrica.
- Acesso anômalo ao
teei_client_devicepor contextos Android privilegiados após atividade de mídia, DRM ou processamento de conteúdo fornecido por aplicativo de terceiro. - Geração inesperada de ASK ou AuthKey, alias fora do padrão esperado e validações de transação com inconsistência entre desafio, dispositivo e sessão.
- Diferenças entre versão MIUI reportada, pacote de firmware instalado e versão efetiva dos aplicativos confiáveis carregados pelo TEE.
A mitigação principal é impedir que aplicativos confiáveis antigos sejam aceitos pelo TEE. Isso exige controle de versão no formato ou na política de carregamento, com rejeição de componentes abaixo de uma versão mínima segura. Assinatura criptográfica continua necessária, mas não é suficiente quando o mesmo ecossistema permite carregar binários legitimamente assinados e vulneráveis. Fabricantes devem vincular aplicativos confiáveis ao nível de firmware esperado, registrar versão interna verificável e garantir que atualizações de segurança não possam ser revertidas por substituição local de arquivos.
No código dos aplicativos confiáveis, cada comando exposto precisa validar tipos, tamanhos e direitos de acesso antes de tocar em buffers enviados pelo lado Android. Funções como TEE_CheckMemoryAccessRights devem ser usadas de forma consistente, e campos como paramTypes não podem ser tratados como detalhe opcional. O handler de inicialização de assinatura do Soter ilustra uma falha clássica: concatenar dados controlados pelo chamador em buffer fixo sem checagem de tamanho. A correção técnica deve incluir limites explícitos para alias, desafio e identificadores de sessão, além de tratamento seguro de erro quando o formato recebido exceder o esperado.
Também é necessário reduzir a exposição da ponte Android para TEE. A política SELinux deve manter o acesso ao dispositivo TEE limitado ao menor conjunto possível de contextos, com revisão especial para usuários que processam entrada não confiável, como mídia. Quando um componente privilegiado precisa interagir com TEE, a chamada deve ser mediada por validações de origem, finalidade e formato. Em ambientes corporativos, dispositivos usados para pagamentos ou autenticação forte devem receber atualizações de firmware de forma prioritária e ser removidos de fluxos sensíveis quando não for possível confirmar a versão dos componentes confiáveis.
Para organizações que integram Tencent Soter ou dependem de verificação de pacotes assinados por TEE, a resposta precisa combinar correção de endpoint com controles no servidor. A validação criptográfica deve ser acompanhada por análise de sessão, reputação do dispositivo, coerência do desafio, histórico de chaves e sinais de risco. Caso exista suspeita de rebaixamento ou vazamento de chave, a rotação de chaves de aplicação e negócio deve ser considerada conforme o desenho do serviço, junto com invalidação de sessões e revisão de transações recentes. A medida exata depende da integração, mas a decisão não deve assumir que uma assinatura válida prova integridade plena do dispositivo.
A validação pós-correção deve confirmar três pontos: aplicativos confiáveis antigos não carregam mais, comandos rejeitam parâmetros com tipo ou tamanho inesperado e crashes relacionados ao Soter deixam de ocorrer sob testes de robustez. Em desenvolvimento, fuzzing de interfaces TEE deve fazer parte do ciclo de segurança dos aplicativos confiáveis, não apenas de componentes Android. Em operação, inventário de firmware, telemetria de crash, registros de pagamentos e alertas de integridade devem ser correlacionados para detectar sinais de regressão ou tentativa de abuso em dispositivos que continuam expostos.
- Aplicar atualizações de firmware e componentes TEE fornecidas pelo fabricante para dispositivos Xiaomi MediaTek afetados.
- Bloquear rebaixamento de aplicativos confiáveis por meio de controle de versão e política de carregamento com versão mínima segura.
- Revisar validação de
paramTypes, tamanhos de buffers e permissões de memória em todos os comandos dos aplicativos confiáveis. - Auditar permissões SELinux para
teei_client_devicee reduzir a exposição de contextos que processam entrada não confiável. - Correlacionar eventos de pagamento, geração de chaves, crashes de TEE e inconsistências de sessão antes de confiar apenas na validade criptográfica de pacotes assinados.
0 Comentários