A acessibilidade é essencial para os utilizadores; o risco surge da concessão injustificada de acesso e do seu abuso.
O malware nem sempre precisa de quebrar a encriptação das mensagens. Se obtiver acesso aos dados que o dispositivo processa para apresentação ou introdução, poderá ver o conteúdo antes da encriptação ou depois da desencriptação. O abuso da acessibilidade e as janelas de sobreposição são dois exemplos, mas os seus mecanismos não são iguais.
Além disso, nem todas as aplicações com acessibilidade ou uma janela flutuante são malware. Os leitores de ecrã e as ferramentas de apoio são essenciais para muitos utilizadores. O objetivo é conceder acesso de forma consciente e reduzir o abuso, não eliminar a acessibilidade.
Três ameaças que não devemos confundir
| Método | O que faz o atacante? | O que não se deve presumir? |
|---|---|---|
| Janela ou formulário falso | Leva o utilizador a introduzir informações numa interface semelhante à aplicação verdadeira | Nem todas as sobreposições leem automaticamente o texto da janela subjacente |
| Roubo de cliques ou tapjacking | Engana o utilizador para que toque noutro controlo | Uma camada transparente não significa que todas as teclas sejam registadas |
| Abuso de um serviço de acessibilidade | Usa as capacidades permitidas do serviço para observar ou executar ações | O acesso a todas as vistas não é igual em todas as versões |
O guia oficial de tapjacking distingue a ocultação total e parcial da interface. O tipo de janela, a versão do Android e as definições da aplicação influenciam o resultado.
Como pode a acessibilidade chegar a dados sensíveis?
Um serviço de acessibilidade pode, dentro das suas capacidades, receber informações da interface ou executar uma ação em nome do utilizador. Um serviço malicioso pode abusar dessa mesma possibilidade. Por isso, ativá-lo para uma aplicação sem uma razão clara não é uma decisão insignificante.
Contudo, afirmar que “qualquer serviço pode ler todo o texto de qualquer aplicação” é demasiado absoluto. Importam a estrutura das vistas, a forma como os dados são disponibilizados e as limitações do sistema operativo. O Android dispõe de funcionalidades como accessibilityDataSensitive para vistas sensíveis; a sua utilização e comportamento devem ser testados na versão de destino. Veja a explicação da Google sobre a proteção de dados contra serviços maliciosos.
O que faz e não faz FLAG_SECURE?
FLAG_SECURE serve para limitar capturas de ecrã e a apresentação de conteúdo em saídas não seguras. Esta opção, por si só, não controla o contrato de acessibilidade, formulários falsos ou todas as formas de extração de texto. Fotografar o ecrã com outro dispositivo é também uma questão distinta.
O Android disponibiliza outras ferramentas, como HIDE_OVERLAY_WINDOWS, para reduzir as janelas de sobreposição. Nenhuma deve ser apresentada como um “botão antiespionagem” sem verificar a compatibilidade, as limitações de versão e o impacto nos utilizadores com necessidades de acessibilidade. Veja o guia de proteção de atividades sensíveis.
Lista de verificação do utilizador para rever acessos
- Nas definições do dispositivo, reveja separadamente as aplicações com acessibilidade, apresentação sobre outras aplicações e acesso às notificações. Os nomes dos caminhos variam consoante o fabricante e a versão.
- Para cada caso, pergunte que funcionalidade concreta precisa desse acesso. O acesso de um leitor de ecrã de confiança não equivale ao de uma aplicação de lanterna desconhecida.
- Considere um pedido urgente para ativar acesso após instalar um ficheiro desconhecido como um sinal de que é necessário investigar melhor; um simples pedido de permissão não prova que se trata de malware.
- Se o aspeto da página de início de sessão for suspeito, não introduza informações sensíveis. Abra a aplicação pelo seu caminho habitual e verifique o endereço ou a origem da instalação.
- Depois de revogar acesso desnecessário, teste o funcionamento das ferramentas de apoio de que precisa. A segurança não deve tornar o dispositivo inutilizável para o seu proprietário.
Se suspeitar que a sua palavra-passe ou sessão já foi exposta, revogar a permissão não basta. A partir de um dispositivo de confiança, verifique as sessões ativas e os métodos de recuperação da conta e altere as palavras-passe em risco.
O que deve o programador testar?
Avalie separadamente os ecrãs de início de sessão, confirmação de operações e apresentação de informações sensíveis. Teste os toques em controlos ocultados e a sobreposição parcial; testar apenas capturas de ecrã não basta. Depois, verifique o mesmo percurso com um leitor de ecrã e ferramentas de apoio reais, para que a defesa de segurança não impeça o acesso legítimo.
No relatório de teste, registe as versões do Android e da aplicação, o tipo de serviço, as permissões e os dados que estavam efetivamente visíveis. Um teste limitado não permite tirar conclusões sobre todos os dispositivos.
A fronteira da encriptação das mensagens
O modelo de ameaças da Livara exclui dispositivos infetados ou desbloqueados da garantia de proteção do conteúdo. Assim, o nome do algoritmo ou o caráter pós-quântico da troca de chaves não constitui uma defesa contra todos os abusos da interface. Considere a proteção do percurso da mensagem, a integridade do dispositivo e o controlo das permissões como três verificações separadas.
