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

A Security Test Suite Trade Federation (sts-tradefed) é baseada na Android Trade Federation (link em inglês) arcabouço de testes para verificar a segurança de todos os dispositivos Android testes de patch que não se enquadrem no Teste de Compatibilidade do Android. Esses testes são exclusivamente para correções associadas (ou que serão associadas) a uma 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 padrão do Android. Ela inclui todos os utilitários necessárias 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 distribuição.
  • Ferramentas da Plataforma Android (adb, fastboot) precisam ser instalados e estar no $PATH (ou seja, você deve 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 uma plataforma independente não se esqueça de adicionar 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 em um projeto que já existe. Execute o destino de build assembleSTSARM ou assembleSTSx86 para criar o esqueleto de teste, dependendo da arquitetura do Android de destino. dispositivo. Execute o destino de build runSTS para executar o teste de estrutura nos dispositivos conectados dispositivo (o adb precisa ser autorizado).

Começar a usar o Gradle

Depois de extrair o arquivo, defina a propriedade sdk.dir na local.properties na raiz do projeto do Gradle e execute o assembleSTSARM Tarefa do Gradle para criar o teste de estrutura. Depois que o build é concluído, o teste pode ser executado navegando (cd) até 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 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 pelo adb push e executada pelo teste do lado do host no Subdiretório native-poc.
  3. Um APK de serviço ou app opcional instalado no dispositivo por meio do adb install e também iniciados pelo teste do lado do host. O app ou serviço também pode conter seu próprio conjunto de declarações JUnit relatadas ao no 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 no lado do host verifica se há falhas, analisa o backtrace do logcat, ou procura o código de saída específico para determinar se o ataque bem-sucedido.

  • App de teste instrumentado:

    1. O teste no lado 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 agrupados. com o APK pela runDeviceTest()
    3. Os testes JUnit no lado do dispositivo tocam em botões e observam o aplicativo usando UIAutomator ou acessa o sistema Android de formas que e revelar vulnerabilidades de segurança.
    4. O êxito ou a falha dos testes JUnit no lado do dispositivo são retornados para o teste no lado do host, que pode ser usado para determinar se o teste foi aprovado ou não.

Uma combinação dos dois padrões (por exemplo, a execução de um programa nativo em junto com testes do lado do dispositivo) também é possível. Alguma outra instrumentação frameworks, como frida-inject, também estão disponíveis. Para mais detalhes, consulte a 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 do lado do dispositivo e de um executável nativo.

Se o teste não envolver o uso de um app/serviço no dispositivo, basta excluir subdiretório test-app. Da mesma forma, se o teste não usar um 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 existem.

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 grave como 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 garante que o APK compilado seja copiado para a 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, deve ser criado em build na raiz do projeto. Faça upload desse arquivo com sua inscrição no Programa de recompensa para descobertas de vulnerabilidades do Android.