Android e AccessibilityService: Protegendo Telas Sensíveis contra Leitura de Interface

Ao discutir a proteção de telas sensíveis no Android, geralmente se pensa em mecanismos de exibição de imagem protegida. Na prática, o desenvolvedor geralmente se depara com WindowManager.LayoutParams.FLAG_SECURE e ferramentas semelhantes da plataforma, que proíbem a criação de capturas de tela normais, restringem a saída da janela para telas externas não seguras e, em uma série de cenários, dificultam a captura do conteúdo da tela por meio de ferramentas do sistema. Para superfícies separadas, uma proteção semelhante pode ser aplicada no nível SurfaceView. Essa camada é importante para telas que exibem dados de pagamento, códigos únicos, informações pessoais e outras informações confidenciais.

No entanto, as capacidades de saída protegida não devem ser superestimadas. Elas reduzem o risco de vazamento da imagem da tela como uma representação visual, mas por si só não resolvem o problema de ler uma interface estruturada por meio de ferramentas especiais. Em outras palavras, a proteção da imagem e a proteção da semântica da interface pertencem a níveis diferentes. A primeira impede a captura do conteúdo da tela como uma imagem, enquanto a segunda deve impedir a transferência de texto, descrições, estados e a árvore de elementos para um consumidor externo.

No Android, existe um mecanismo de sistema especial chamado AccessibilityService. Ele é necessário para que alguns aplicativos possam ajudar o usuário a interagir com outros: anunciar o conteúdo da tela, simplificar a navegação, oferecer suporte à entrada alternativa e tornar a interface mais acessível para pessoas com deficiência. Para essa ajuda, o sistema não precisa apenas "ver a imagem" na tela. O AccessibilityService recebe acesso mais profundo à interface: pode descobrir quais janelas estão abertas, quais elementos estão localizados nelas, qual é o texto, a descrição, o estado e quais ações o usuário está executando. É aqui que o problema de segurança surge. O mecanismo, concebido como uma ferramenta de acessibilidade, quando usado incorretamente, se transforma em uma maneira conveniente de observar as ações do usuário e ler o conteúdo da interface. Na verdade, um aplicativo com esse acesso recebe não uma captura de tela, mas sua representação estruturada. Se o aplicativo obtiver acesso à acessibilidade, ele pode: ler o conteúdo da interface; rastrear a mudança de telas; ver a entrada e as ações do usuário; clicar em botões e executar gestos em nome do usuário; interferir na remoção de si mesmo e conduzir a vítima pelas telas de configurações necessárias. Por causa disso, a acessibilidade tem sido usada por malware móvel por muitos anos, principalmente RATs (Remote Access Trojan), como um conveniente "painel de controle" do dispositivo. Isso é especialmente comum em trojans bancários: por meio desse acesso, eles leem a interface de aplicativos bancários, interceptam códigos, impõem ações e ocultam sua atividade.

A obtenção de acesso ao AccessibilityService geralmente envolve engenharia social. O usuário é mostrado que, para o "funcionamento correto" do aplicativo, é necessário conceder permissões adicionais. Em seguida, ele é literalmente levado à tela desejada: dicas, sobreposições, explicações falsas, às vezes pressão no espírito de "sem isso, o aplicativo não funcionará". Ou seja, a principal barreira aqui não é técnica, mas comportamental. O usuário é persuadido a ativar um recurso perigoso. Na prática, obter acesso ao AccessibilityService dá ao aplicativo malicioso não um, mas vários canais de observação da interface. Primeiro, o serviço recebe eventos da interface do usuário: informações sobre a mudança de janelas, alteração de texto em campos, foco em movimento, aparecimento de novas atividades e outras ações significativas. Isso já é suficiente para reconstruir o cenário de trabalho do usuário quase em tempo real: determinar qual aplicativo está aberto, em qual tela a vítima está e em que momento a entrada de dados confidenciais começa. Em segundo lugar, ao acessar o conteúdo da janela, o serviço pode ler a árvore de elementos da interface. Nessa representação, o invasor se torna capaz de valores de texto, contentDescription, estrutura da tela e, em alguns casos, IDs de elementos. Como resultado, o atacante recebe não apenas uma imagem da tela, mas um modelo semântico bastante preciso da interface, adequado para análise automatizada e navegação. É a combinação do canal de eventos e da árvore de elementos que torna o AccessibilityService particularmente perigoso: ele permite não apenas extrair dados, mas também sincronizar a lógica maliciosa com as ações atuais do usuário, o que cria uma base técnica para suporte remoto de uma sessão bancária, fraude no dispositivo e cenários mais complexos de controle oculto do dispositivo.

As ameaças modernas baseadas no abuso do AccessibilityService são consideradas em detalhes em análises analíticas e em análises de famílias específicas de malware móvel. Em materiais em russo, a ESET mostrou que o uso do serviço de acessibilidade há muito se tornou uma técnica estável de malware Android para obter controle aprimorado sobre o dispositivo e contornar os cenários padrão do usuário para ativar permissões perigosas (ESET / BankBot, ESET / DoubleLocker). Nas publicações do Group-IB / F6, esse problema já é considerado no nível da exploração prática: malware por meio do AccessibilityService rastreia as alterações nos elementos da tela, imita as ações do usuário, interfere na abertura das configurações de proteção e acompanha o cenário fraudulento até a conclusão da operação (F6 / Gustuff, F6 / Fanta, F6 / Godfather). Além disso, nas análises em russo do Laboratório Kaspersky e Securelist, é enfatizado que os invasores usam sistematicamente o acesso à acessibilidade para aumentar o controle sobre o dispositivo infectado, interceptar as ações do usuário e combater os mecanismos de proteção integrados do Android (Kaspersky / Habr, Securelist).

Para demonstrar a ideia, não é necessário escrever um aplicativo separado. Parte do efeito pode ser mostrado por meio de ADB e UI Automator. As ferramentas desta classe podem trabalhar com a hierarquia da janela fora do processo do aplicativo testado e permitem obter uma representação XML da interface do usuário atual, na qual os atributos de texto, resource-id, contentDescription, classes e limites dos elementos são visíveis. Ao mesmo tempo, é importante definir cuidadosamente os limites do método aqui. ADB e UI Automator são ferramentas de pesquisa e teste, e não um modelo preciso de malware. Eles exigem depuração ou um ambiente de teste habilitado e não reproduzem todo o ciclo de vida do abuso do AccessibilityService. No entanto, para demonstrar o vazamento da árvore de elementos, eles são suficientes: o comando adb exec-out uiautomator dump /dev/tty > view.xml permite obter um dump da hierarquia da janela atual e, em seguida, comparar visualmente com o resultado após ativar a proteção.

A proteção contra a leitura da tela por meio da acessibilidade no Android não é resolvida por uma única configuração. Na prática, este é um conjunto de medidas separadas, e cada uma fecha seu próprio canal de vazamento ou controle. A proteção envolve várias etapas, incluindo a remoção de partes sensíveis da árvore de acessibilidade, a limpeza de dados que podem vazar, a marcação de dados confidenciais no nível do sistema, o bloqueio de canais secundários de saída da tela, o bloqueio de ataques de sobreposição e tapjacking, e o uso de semântica no Compose. Para implementar essas proteções, os desenvolvedores podem usar uma biblioteca chamada secure-ui, que simplifica o processo, fornecendo uma abordagem em camadas para proteger telas sensíveis.

Em resumo, a acessibilidade é crucial para pessoas com deficiência, mas a segurança dos usuários também é essencial. Os desenvolvedores devem proteger dados confidenciais contra aplicativos potencialmente fraudulentos, implementando medidas de segurança como as descritas neste artigo.