Kit de desenvolvimento do pacote de testes de segurança do Android (SDK do STS)

O Security Test Suite Trade Federation (sts-tradefed) é criado com base no arcabouço de testes da Trade Federation do Android para testar todos os dispositivos Android em busca de patches de segurança que não se enquadram no conjunto de teste de compatibilidade. Esses testes são exclusivamente para correções associadas (ou que serão associadas) a vulnerabilidades e exposições comuns (CVE, na sigla em inglês).

O SDK permite o desenvolvimento de testes STS fora da árvore de origem do Android usando o Android Studio ou o SDK Android padrão. Ela inclui todos os utilitários necessários para criar e executar um teste STS.

Instalar o SDK do STS mais recente

Pré-requisitos

  • PC Linux de 64 bits.
  • Android Studio (também pode ser instalado no gerenciador de pacotes da sua distro.
  • As ferramentas da plataforma Android (adb, fastboot) precisam ser instaladas e estar no $PATH. Ou seja, você precisa conseguir executar adb na linha de comando. A maneira mais fácil de instalar as ferramentas da plataforma é pelo gerenciador de pacotes da sua distribuição.
    • Se você estiver usando o SDK Manager do Android Studio em vez de ferramentas de plataforma independentes, adicione o diretório platform-tools do SDK ao $PATH.
  • aapt, que também pode ser instalado pelo gerenciador de pacotes da sua distribuição.

Começar a usar o Android Studio

Depois de extrair o arquivo, abra o diretório no Android Studio como um projeto existente. Execute o destino de build assembleSTSARM ou assembleSTSx86 para criar o teste de esqueleto, dependendo da arquitetura do dispositivo Android de destino. Execute o destino de build runSTS para executar o teste de esqueleto no dispositivo conectado (o ADB precisa ser autorizado).

Começar a usar o Gradle

Depois de extrair o arquivo, defina a propriedade sdk.dir no arquivo local.properties na raiz do projeto do Gradle e execute a tarefa assembleSTSARM do Gradle para criar o teste esqueleto. Depois que o build for concluído, o teste poderá ser executado navegando (cd) para build/android-sts/tools e executando o wrapper sts-tradefed.

$ echo 'sdk.dir=/home/<myusername>/Android/Sdk' > local.properties
$ ./gradlew assembleSTSARM
$ cd build/android-sts/tools
$ ./sts-tradefed run sts-dynamic-develop -m hostsidetest

Criar um teste STS

Um teste de STS tem três partes:

  1. Um teste Tradefed do lado do host que interage com o dispositivo por meio do adb, no subdiretório sts-test.
  2. Um ataque de prova de conceito nativo opcional que é enviado ao dispositivo por adb push e executado pelo teste do lado do host no subdiretório native-poc.
  3. Um APK de app ou serviço opcional que é instalado no dispositivo por meio de adb install e também iniciado pelo teste do lado do host. O app ou serviço também pode conter o próprio conjunto de declarações do JUnit informado ao executor do lado do host. Ele está no subdiretório test-app.

Um fluxo de teste STS típico geralmente segue um destes dois padrões:

  • Prova de conceito nativa:

    1. O teste no lado do host envia e inicia um executável nativo no dispositivo.
    2. O programa nativo falha ou retorna um código de saída específico.
    3. O teste do host verifica falhas, analisa o backtrace do logcat ou procura o código de saída específico para determinar se o ataque foi bem-sucedido.

  • App de teste instrumentado:

    1. O teste do host envia um APK que consiste em um app ou serviço para o dispositivo.
    2. O teste do lado do host inicia os testes JUnit do lado do dispositivo que são empacotados com o APK por runDeviceTest().
    3. Os testes JUnit no lado do dispositivo tocam em botões e observam o app usando o UIAutomator ou acessa o sistema Android de maneiras que revelam vulnerabilidades de segurança.
    4. O sucesso ou a falha dos testes JUnit do dispositivo são retornados ao teste do host, que pode ser usado para determinar se o teste foi bem-sucedido ou não.

Uma combinação dos dois padrões (por exemplo, a execução de um programa nativo com testes no lado do dispositivo) também é possível. Alguns outros frameworks de instrumentação, como frida-inject, também estão disponíveis. Para mais detalhes, consulte os documentos de referência do pacote de testes de segurança e os documentos de referência do Tradefed.

Meu ataque de prova de conceito não precisa de um app de teste ou um executável nativo

A maioria dos testes não precisa de um app no dispositivo e de um executável nativo.

Se o teste não envolver o uso de um app/serviço no dispositivo, basta excluir o subdiretório test-app. Da mesma forma, se o teste não usar um executável nativo, exclua o subdiretório native-poc e sincronize o projeto com o Gradle. O projeto é configurado para pular automaticamente a criação desses módulos quando eles não existirem.

Meu ataque de prova de conceito envolve um segundo app/serviço

Primeiro, adicione um novo módulo ao projeto para o segundo app/serviço e escreva como faria com qualquer outro APK.

Em seguida, edite build.gradle na raiz desse diretório e adicione seu módulo seguindo as instruções em copyArtifacts, assembleStsARM e assembleStsx86. Isso garantirá que o APK compilado seja copiado para o diretório de saída do STS e permite a instalação/chamada do novo app do teste.

Por fim, sincronize o projeto com o Gradle.

Enviar o teste STS

Execute a tarefa zipForSubmission com o Android Studio ou o Gradle na linha de comando. Um novo arquivo, codesubmission.zip, precisa ser criado no diretório build na raiz do projeto. Faça o upload desse arquivo junto com seu envio para o Programa de recompensa para descobertas de vulnerabilidades do Android.