Site icon Segurança Informática

Security on Android Apps

Pedro Tavares


Segurança em Aplicações Android

O ficheiro de uma aplicação Android é chamado de Android Package (apk), e não é mais que um ficheiro Zone Information Protocol (ZIP) comprimido.

Começamos com algumas breves questões:

  • É possível descomprimir um apk?
    Sim.
  • Então, também é possível ler o código-fonte de um apk?
    Sim.
  • Os apks são reversíveis através de engenharia reversa?
    Sim.
  • Isso quer dizer que, é possível encontrar dados sensíveis como, por exemplo, palavras-passe e Application Programming Interface (API) keys, ao longo do código?
    Sim.
  • É possível construir um apk totalmente seguro — à prova de bala?


Este artigo tem o objetivo de passar alguns procedimentos de forma a que qualquer developer, ou fulano com conhecimentos básicos sobre Android, consiga auditar sua própria aplicação antes que esta seja publicada e maliciosamente explorada.

E respondendo à última questão: ”—Nim”.

 

Caça aos Dados Sensíveis

Não existe uma aplicação, sistema, infraestrutura ou até ecossistema à prova de bala e totalmente seguro. Isso deve-se a muitos fatores, p.ex., um desenho deficiente da arquitetura, bugs cometidos em sede de desenvolvimento, software desatualizado, vulnerabilidades zero-day attack, fuga de informação, entre outros. Quantos mais parâmetros são enumerados maior se torna o horizonte de ataque. Dito de uma forma mais jocosa, o objetivo da segurança da informação é então dificultar o processo de obtenção de determinado valor no seu estado mais cru. Nesse caso, qualquer fulano que tente explorar e obter informação do sistema, em vez de demorar 30 minutos vai demorar, dias, semanas, talvez anos, extingue-se o sol e o bisneto do bisneto do terceiro filho tenta alcançar o objetivo do tataravô. Confuso? É o objetivo!

O principal segredo para a segurança nasce durante o desenho da arquitetura do sistema. É necessário clarificar a arquitetura, as assunções do sistema, os intervenientes, e depois, começar o puzzle. No caso das aplicações Android existem alguns tópicos que podem e devem ser levantados logo no ínicio do desenvolvimento, p.ex:

 

Antes de avançar é importante abordar uns breves conceitos sobre a forma como uma aplicação Android opera e qual o ciclo de desenvolvimento até à geração do apk final.

 

APK e o Android

Depois do download do apk da store, a aplicação é instalada no smartphone. A forma como o sistema foi desenhado permite:

 

Dalvik Virtual Machine Vs. Java Virtual Machine

A forma como um apk é interpretado pelo sistema Android é muito semelhante à forma como uma Java Virtual Machine (JVM) interpreta um ficheiro .jar. A VM do Android chama-se Dalvik Virtual Machine (DVM).

(Existe também uma outra runtime denominada ART e que é bastante mais rápida que a DVM. Pode ser consultada mais informação aqui.)

 

Existem ferramentas de compilação como o Gradle e o Apache Ant que automatizam o processo de geração da aplicação final, o apk, no caso do Android. De notar que, foram gerados pelo caminho os ficheiros .class, que são os ficheiros com o código Java já compilado. Adicionalmente para que um apk rode numa DVM, é necessário também codificar esses ficheiros em .dex files.

O processo é um pouco mais elaborado do que aquele que foi apresentado acima (ver abaixo).

 

Os ficheiros Resources, Assets e Manifest não são sequer codificados pelo compilador Java (javac) nem pelo dx. Estes ficheiros são apenas compactados. Está a lembrar-se do ZIP e do UnZIP?

Neste ponto é importante reter o seguinte:

 

Aplicações Nativas vs. Não-Nativas

 

Nativa
De uma maneira breve, uma aplicação nativa comunica diretamente com o SO através de um API. O SO é quem gere a comunicação com os componentes de hardware.

 

Não-Nativa (Híbrida)
Uma aplicação não-nativa, por exemplo, híbrida, é uma aplicação web (por exemplo, um website) a rodar num wrapper Java Android. De uma forma ainda mais simples: — Consiste numa aplicação Android, com um web-browser, a invocar uma página HTML. É claro que existe aqui um abuso de linguagem, mas é para o leitor perceber a big picture de uma forma mais clara e leve. Para que essa página HTML concretize chamadas ao SO, é necessário, via Javascript, invocar rotinas codificadas algures no código Java.

 

Neste caso, chamadas a funções de APIs nativas são executadas através de Javascript. Ou seja, a maior parte da lógica computacional está presente nos ficheiros Javascript e que não são compilados, apenas comprimidos.

Normalmente este tipo de aplicações híbridas são desenvolvidas com recurso a ferramentas disponíveis no mercado que automatizam e aceleram o seu desenvolvimento, Cross-platform Tools (CPTs), como o Apache Cordova ou o Phonegap, e Cross-platforms to Mobile Development (CPMDs), frameworks web-based que permitem criar uma aplicação através de ponta e clique em minutos.

 

Engenharia Reversa (ER)

Podemos desenhar dois caminhos distintos antes iniciar o trabalho:

  1. Para aplicações híbridas não é necessário decompilar os ficheiros (.dex e .class), eles apenas vão conter os plugins e libs dos CPTs. É necessário fazer somente o unzip do apk porque o código está nos Assets.
  2. Para aplicações nativas é necessário percorrer todo o fluxo de Engenharia Reversa (ER).

Segue abaixo o fluxo de ER para aplicações Android.

 

 

O processo de ER de aplicações Android começa sempre da mesma forma:

 

1. Download de uma Aplicação Aleatória da Store

De forma a comprovar o que foi dito ao longo do artigo, foi descarregada uma aplicação aleatória da Play Store. Para isso, basta entrar na página da Play Store e selecionar uma aplicação para descarregar.

https://play.google.com/store/apps/details?id=ID

Através do SDK do Android, é possível puxar o apk diretamente do smartphone.

adb connect xxx.xxx.xxx.xxx:5555
adb shell pm list packages
adb pull /data/app/exemplo.app.pt.apk

 

Para os mais impacientes, podem ser usadas algumas ferramentas online, p.ex.:

https://apkpure.com


2. Unzip do apk

Em seguida segue o unzip do apk e a respetiva estrutura dos ficheiros.

unzip apk_name.apk

 

 

 

É possível observar dois ficheiros importantes:

 

3. Diretoria Assets

Em aplicações híbridas, como é o caso de apps construídas com o Apache Cordova ou Phonegap, dentro desta diretoria está a estrutura tipicamente de um website.

 

Analisando o ficheiro m_index.html é possível visualizar uma chamada a um ficheiro Javascript.

<script src="js/app.js"></script>


Analisando o ficheiroapp.js, na diretoria js, é possível encontrar dados sensíveis, secret  keys para comunicar com third party applications, como é o exemplo da Amazon Web Services, Linkedin, ou outro tipo de APIs públicas.

  linkedIn: {

            callbackUri: "https://####",

            clientId: "####rqbt###rr",

            clientSecret: "####M85####X9"

   }

 

Como uma API não pública necessita de uma API key e uma secret key para que uma comunicação entre o cliente e o servidor seja estabelecida, esses dados são guardados, preferencialmente, em ficheiros do tipo Javascript em aplicações híbridas. Como observado, isto é um problema grave de segurança, uma vez que um simples unzip do apk  fez-nos chegar aos dados sensíveis.

É muito provável que existam bots na Internet a efetuar este tipo de processos de uma forma autónoma.

 

4. Analisar o Source-code Java da Aplicação – ER

Para uma análise in-depth, é necessário seguir o processo de ER mencionado no diagrama mais acima. Para tal, é necessário usar algumas ferramentas disponíveis na Internet, p.ex., dex2jar e Java Decompiler, e efetuar os seguintes passos:

 

Depois de aberto, é possível visualizar o source-code da aplicação.

 

 

Como se trata de uma aplicação não-nativa, apenas é feita a invocação do web wrapper, tal como foi mencionado mais acima. O wrapper invoca simplesmente os resources (HTML).

Em aplicações totalmente nativas, seria possível encontrar todas as atividades da app, e procurar recursivamente por palavras-chave dentro do projeto. Dessa maneira, é viável identificar dados sensíveis.

 

Vantagens de Desvantagens de Aplicações Híbridas

As aplicações híbridas são excelente do ponto de vista da rapidez de desenvolvimento. Torna-se rápido o seu desenvolvimento porque os CPTs já fornecem um conjunto de plugins muito variados. Outra grande vantagem é que, normalmente, o desenvolvimento é cruzado, i.e., multiplataforma, Android, iOS, web, etc. E sobre tudo, o custo de desenvolvimento é muito mais barato que aplicações nativas.

Nem sempre os cuidados de segurança são os melhores. É necessário ofuscar todo o conteúdo, nomeadamente ficheiros Javascript onde vão estar guardados dados sensíveis, e sobretudo, repensar a forma como a app deve ser desenhada.

Relembrar que, o desempenho de uma aplicação híbrida não pode ser comparado ao desempenho de uma aplicação nativa, pois a aplicação não-nativa não fala diretamente com o SO.

Em suma, como vantagens podem ser enumeradas as seguintes:

 

Como desvantagens:

 

Melhorar a Segurança de Aplicações Android

A segurança de qualquer que seja o sistema deve ser pensada desde o seu início. Neste caso em específico, seja uma aplicação Android nativa ou não-nativa, o problema é exatamente o mesmo: — dados sensíveis estão codificados no código e espalhados por centenas de utilizadores.

A ofuscação é uma técnica que pode ajudar a incrementar o tempo de processamento para obter os dados sensíveis, no entanto, eles estão ali (apenas baralhados). Nesse sentido, ofuscação dificulta o processo mas não resolve o problema dos dados codificados no código.

Algumas soluções de ofuscação para aplicações Android são as seguintes:

 

É preciso pensar em outras alternativas para além da ofuscação, p.ex., o Android Key Store System, em que os dados sensíveis são guardados diretamente no processador (hardware).

É uma solução à prova de bala? Não, mas complica em muito a vida de um cracker, e obter dados deste nível de proteção é muito mais complexo do que apenas através de um simples “unzip”.

Existem também outras soluções baseadas em third parties services, como é o exemplo da AWS e do Meteor. Aqui a computação fica do lado de quem mantém o serviço e a aplicação não precisa sequer de manter registos sensíveis no client-side.

Fica em baixo um caso de uso da AWS para soluções móveis.

 

Nestes casos, a computação fica do lado do provedor de serviço (a AWS, neste exemplo em específico). A gestão de utilizadores é gerida através do serviço cognito, e as callbacks a third party applications são geridas dentro do ecossistema do provedor. Esta é uma forma elegante e segura de conceber aplicações móveis.

Tem desvantagens? Sim, a aplicação móvel distribuída por centenas de utilizadores é considerada segura (uma vez que não existem dados sensíveis partilhados do lado dos clientes) mas mantem-se “agarrada” a um provedor de serviços (o preço a pagar pela medida de segurança implementada).

Conclusão

Não existem soluções perfeitas para a segurança de um sistema ou de uma aplicação. O segredo está na forma como é conseguido fazer andar o relógio a seu favor. Como foi observado, com uma solução de ofuscação, um indivíduo ao analisar a aplicação, não iria demorar 5 minutos, mas talvez fosse demorar algumas horas até encontrar matéria sensível. Existem muitas outras maneiras que não foram discutidas neste artigo, uma vez que o objetivo principal foi demonstrar e consciencializar a importância do desenho de infraestruturas, sistemas e aplicações de forma a que estes sejam implementados com os mínimos requisitos de segurança.

Estima-se que uma grande percentagem de aplicações distribuídas na Play Store não detenham grandes mecanismos de proteção. Em Portugal, o paradigma não é muito diferente. É importante consciencializar os arquitetos de soluções da importância do uso de mecanismos de criptografia e de segurança. É importante perceber que nos últimos anos os prejuízos por fuga de informação têm sido catastróficos. Basta debruçar um olhar atento sobre um dos últimos grandes leaks do verão de 2017, Equifax.

É importante também que as empresas adotem cada vez mais uma mentalidade defensiva, porque já a partir de maio de 2018, existem procedimentos a cumprir, normas europeias que visam penalizar aquelas empresas que não o fizerem (RGPD).

Exit mobile version