A proteção de aplicativos contra ataques cibernéticos se torna cada vez mais uma necessidade crítica, à medida que as arquiteturas consideradas “modernas” migram funções que tradicionalmente eram executadas na lógica do software (e portanto, no back-end) para o lado do cliente (no front-end). Entretanto, é preciso tomar o devido cuidado com a proteção dos aplicativos contra ameaças cibernéticas, para evitar transformar uma tendência promissora de design de software em falhas graves de segurança.

Segundo o “Market Guide for In-App Protection”¹ publicado em 2019 pelo Gartner Group, pelo menos 50% dos ataques bem-sucedidos contra aplicativos móveis até 2022 poderia ser impedidos se fosse usada proteção específica para aplicativos.

A proteção In-App

As tecnologias In-App (no aplicativo) protegem os aplicativos de dentro para fora, ou seja, sem exigir a instalação de componentes externos no dispositivo em que o aplicativo é executado. Dessa forma, a proteção In-App é particularmente adequada para aplicativos de alto valor ou para aplicativos que sejam executados em dispositivos não controlados pela empresa (em celulares e tablets de clientes, por exemplo) ou em ambientes operacionais considerados não confiáveis.

Isso significa que a proteção In-App tem como objetivo principal proteger os usuários destas aplicações. Os casos de uso geralmente envolvem aplicativos voltados para o consumidor, código JavaScript no front-end e aplicativos móveis.

A proteção In-App pode ser implementada em qualquer aplicativo, em qualquer plataforma e, na maioria dos casos, a empresa precisa ter acesso ao código e permissão para modificá-lo. As soluções com tecnologia mais avançada também incluem um conjunto de proteções essenciais que podem ser aplicadas pós-desenvolvimento, sem intervenção do desenvolvedor e modificação do código.

Embora a proteção a aplicativos às vezes seja implementada em back-ends na forma de soluções RASP (Runtime Application Self-Protection), não abordaremos esses casos de uso neste artigo, pois não se concentram na proteção do front-end.

Os recursos de proteção no aplicativo podem ser introduzidos durante o desenvolvimento do aplicativo ou após a codificação. Algumas soluções no mercado fornecem bibliotecas na forma de SDKs para serem integradas diretamente no código-fonte, algumas aproveitam as possibilidades do código nativo e outras injetam sua funcionalidade diretamente em um aplicativo sem exigir modificações ou posse do código-fonte. Embora essa última abordagem forneça maior flexibilidade, ela também depende da linguagem de programação e da estrutura utilizada. Por exemplo, aplicativos Java e .NET acomodam a injeção binária muito mais facilmente do que tecnologias que produzem código nativo.

Tendências do mercado

As organizações mostram interesse crescente na proteção In-App para seus aplicativos móveis. Isso não surpreende, pois as transações originadas de aplicativos móveis cresceram mais de 600% nos últimos três anos e os ataques a estes aplicativos representam quase 2% de todas as transações.²

Além de ser recomendada para aplicativos móveis e SPA (Single Page Application), a proteção In-App também é adequada para proteger softwares em execução em dispositivos conectados (IoT). Assim como os aplicativos móveis e aplicativos SPA, os dispositivos conectados também movem parte da lógica do software do back-end para ser executada no front-end, em ambientes desprotegidos e não confiáveis.

Essa tendência será cada vez maior com a disseminação da computação de borda (edge computing), computação imersiva, realidade mista e realidade aumentada. Por exemplo, a computação imersiva, por definição, aproveita os sensores presentes localmente no dispositivo e, portanto, requer lógica de software no front-end.

Ao contrário dos gateways de Web Application Firewall (WAF) e de API, a proteção In-App é incorporada ao próprio aplicativo, na maioria dos casos exigindo mais o envolvimento da equipe de desenvolvimento, que às vezes é menos sensível às implicações de segurança de seu software e dedica mais atenção à implantação de novas funcionalidades e ao desempenho dos aplicativos, mas não tem muito envolvimento com as equipes de segurança e de prevenção à fraudes.

A proteção In-App abrange recursos que atuam durante as fases de prevenção e detecção. Vamos explorar melhor esses tópicos abaixo:

Prevenção: funcionalidades de proteção

Os recursos de prevenção também são chamados de blindagem de código (application hardening). Eles podem ser considerados medidas passivas e dissuasivas, que aumentam o nível de esforço necessário para que o invasor realize um ataque. Além de outras técnicas, os recursos de prevenção consistem principalmente de ofuscação de código e white-boxing:

Ofuscação de código: A ofuscação embaralha o código e torna mais difícil para um invasor fazer engenharia reversa para saber como o aplicativo funciona. Um aplicativo que é mais difícil de ler também é mais difícil de atacar, e é mais difícil roubar sua propriedade intelectual ou reempacotar o aplicativo. Existem várias técnicas aplicadas para ofuscar o código. Os componentes e identificadores de software (como o nome de uma classe ou método) podem ser renomeados, um código falso que nunca é usado (por exemplo, uma instrução condicional para uma condição que nunca é verificada) pode ser adicionado e sequências de caracteres podem ser criptografadas. O código também pode ser recompilado e executado em um intérprete ou máquina virtual. Reflexão e empacotamento são outras duas técnicas frequentemente usadas.

White-boxing ou criptografia white-box: Outra técnica importante de prevenção é a white-boxing, que é o conjunto de técnicas usadas para ocultar e proteger dados confidenciais de aplicativos (normalmente chaves de criptografia) armazenados em um dispositivo. Na sua forma mais básica, o white-boxing usa técnicas semelhantes à ofuscação para ocultar dados, mas também pode combinar a funcionalidade anti-adulteração. É uma alternativa ao uso dos recursos nativos das plataformas mais modernas, como o Keychain do Apple iOS ou o Credential Manager do Microsoft Windows 10. Pode ser particularmente útil quando a empresa deseja permitir que seu aplicativo seja executado em dispositivos jailbroken, que não podem se beneficiar da proteção Keychain do iOS. A lógica por trás do white-boxing é que o invasor vê o local padrão para credenciais em um dispositivo como o primeiro local para tentar atacar. Portanto, mover as credenciais para outro lugar evita esses ataques, apesar de todas as defesas que os armazenamentos de credenciais têm nos dispositivos.

Pinagem de certificado (certificate Pinning): Em vez de aceitar qualquer certificado de um tipo específico de autoridade de certificação, a fixação permite que as partes envolvidas no processo de autenticação identifiquem mutuamente determinados certificados e somente esses certificados serão aceitos. Se um invasor falsificar um certificado, mesmo que seja proveniente de uma autoridade de certificação legítima, a outra parte o rejeitará, evitando um ataque do tipo man-in-the-middle.

Criptografia de recursos: A criptografia de recursos de vários componentes, como classes ou cadeias, também pode ser usada para impedir ataques.

Expiração automática: Delimita o período de tempo após o qual o aplicativo interromperá a operação, enquanto a conexão de domínio limita a operação do aplicativo a um domínio específico.

Teclado stand-alone: Alguns produtos também fornecerão um teclado específico para o aplicativo, para impedir tentativas de registro de chaves.

Polimorfismo: Essa é outra técnica que está emergindo nesse mercado, onde o código pode ser alterado durante uma tentativa de engenharia reversa, para adicionar dificuldade à tentativa.

Remoção de dados de teste e técnicas não seguras: Inclui a combinação de métodos, uma técnica de programação legítima que pode, no entanto, ser explorada por um invasor.

Detecção: Recursos anti-adulteração

Os recursos de detecção se concentram no reconhecimento do ambiente no qualo aplicativo está sendo executado (por exemplo, o dispositivo ou o servidor) para determinar se esse ambiente pode ser confiável. Os recursos incluem:

Detecção de depuração e de emulação: Esses são recursos comuns nos In-Apps, pois ferramentas de depuração (debuggers) e ambientes virtuais são amplamente usados em tentativas de engenharia reversa.

Detecção de escalonamento de privilégios: Este é um controle usado com frequência. Em plataformas móveis, isso pode ser traduzido em detecção de jailbreak ou de root.

Verificações de integridade: É possível detectar se um aplicativo ou uma configuração de dispositivo foi alterado. As verificações de integridade podem envolver uma variedade de verificações, como uma soma de verificação (checksum) de todo o aplicativo ou uma verificação do inventário de bibliotecas e chamadas incluídas no aplicativo.

Impressão digital (fingerprinting): Coleta informações sobre o dispositivo. As informações podem ser usadas para identificar um dispositivo específico, o que permite que o aplicativo se autobloqueie para ser executado apenas nesse dispositivo específico (ou seja, conexão de dispositivo).

Detecção de malware: Analisa os outros aplicativos instalados no dispositivo, em plataformas de sistemas operacionais onde isso é permitido, bem como analisa o comportamento mais amplo do dispositivo e pode identificar um malware presente no ambiente.

Outras funcionalidades para proteção de aplicativos

Outros recursos também podem ser encontrados nos In-Apps, como:

Tecnologias anti-bot são usadas para identificar e bloquear bots maliciosos com base no comportamento (por exemplo, geolocalização, reputação do endereço IP, comportamento biométrico).

Proteção contra clickjacking inclui vários métodos, como CSP, SRI, detecção de injeção de script e outros métodos.

Autoproteção de aplicativo de tempo de execução (Runtime Application Self-Protection ou RASP) é uma tecnologia de segurança adicionada ao ambiente de tempo de execução de um aplicativo por meio de instrumentação de código. Ele monitora comportamentos, controla a execução do aplicativo, detecta e evita ataques em tempo real.

Autenticação multifator / Out of Band (OOB) fornece proteção contra controle de conta, spray de senha (password spraying), phishing e ataques similares, verificando se o usuário possui um fator adicional de autenticação (como um dispositivo, token, número de telefone, mensagem SMS, etc.).

Análise de risco coleta a chamada “telemetria de ataque” registrada pelo aplicativo, para processar em um sistema de back-end e decidir como reagir a um determinado nível de risco. Idealmente, a solução fornecerá seu próprio mecanismo de avaliação de risco, mas é comum a integração com soluções SIEM (Security Information and Event Management) e ferramentas de detecção de fraude on-line.

Como proteger os aplicativos móveis da sua empresa

A Leadcomm é parceira da Arxan, um fornecedor de soluções completas de proteção In-App, voltada a aplicativos móveis, da Web, híbridos, de desktop ou de servidor, de engenharia reversa, violação de código, manipulação de API e clonagem. Impede o roubo de propriedade intelectual, credenciais, dados confidenciais e revelação de ativos críticos de infraestrutura, como APIs, URLs de banco de dados e chaves privadas usadas para desenvolver ataques subsequentes.

O portfólio de produtos da Arxan inclui soluções para proteção de aplicativos, análise de ameaças, criptografia white-box e gerenciamento de aplicativos (anteriormente conhecido como Apperian).

A solução inclui um conjunto de proteções essenciais que podem ser aplicadas pós-desenvolvimento, sem intervenção do desenvolvedor e modificação do código. Os recursos de gerenciamento de aplicativos móveis permitem a distribuição segura de aplicativos para dispositivos gerenciados e não gerenciados.

Conheça mais sobre o Arxan clicando aqui.

Está na hora de levar a sério a segurança dos seus Apps.

Fontes:
¹“Market Guide for In-App Protection”, Gartner, 2019.

²“Q2 2018 Cybercrime Report,” ThreatMetrix.