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

A Security Test Suite Trade Federation (sts-tradefed) é construída sobre o arnês de teste Android Trade Federation para testar todos os dispositivos Android para testes de patch de segurança que não se enquadram no Compatibility Test Suite. Esses testes são exclusivamente para correções associadas (ou serão associadas) a Vulnerabilidades e Exposições Comuns (CVE).

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

Obtenha o SDK STS mais recente

Pré-requisitos

  • PC Linux de 64 bits.
  • Android Studio (também pode ser instalado a partir do gerenciador de pacotes da sua distro.
  • As ferramentas da plataforma Android ( adb , fastboot ) precisam ser instaladas e estar em seu $PATH (ou seja, você deve ser capaz de executar adb a partir da linha de comando). A maneira mais fácil de instalar as ferramentas da plataforma é por meio do gerenciador de pacotes da sua distro.
    • Se estiver usando o gerenciador de SDK do Android Studio em vez de ferramentas de plataforma independentes, lembre-se de adicionar o diretório platform-tools do SDK ao seu $PATH.
  • aapt , que também pode ser instalado através do gerenciador de pacotes da sua distro.

Comece 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 compilação assembleSTSARM ou assembleSTSx86 para criar o teste de estrutura, dependendo da arquitetura do dispositivo Android de destino. Execute o destino de compilação runSTS para executar o teste de esqueleto no dispositivo conectado (ADB deve ser autorizado).

Comece a usar o Gradle

Depois de extrair o arquivo, defina a propriedade sdk.dir no arquivo local.properties na raiz do projeto Gradle e, em seguida, execute a tarefa Gradle assembleSTSARM para criar o teste básico. Após a conclusão da compilação, o teste pode ser executado navegando ( cd ) em 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

Escreva um teste STS

Existem três partes em um teste STS:

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

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

  • Prova de conceito nativa:

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

    1. O teste do lado do host envia um APK que consiste em um aplicativo 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 meio de runDeviceTest()
    3. Os testes JUnit do lado do dispositivo tocam botões e observam o aplicativo usando UIAutomator ou, de outra forma, acessam o sistema Android de maneiras que revelam vulnerabilidades de segurança.
    4. O sucesso ou falha dos testes JUnit do lado do dispositivo é retornado ao teste do 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, execução de um programa nativo em conjunto com testes do lado do dispositivo) também é possível. Algumas outras estruturas de instrumentação, como frida-inject , também estão disponíveis. Para obter detalhes, consulte os documentos de referência do Security Test Suite e os documentos de referência do Tradefed .

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

A maioria dos testes não precisará de um aplicativo do lado do dispositivo e de um executável nativo.

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

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

Primeiro, adicione um novo módulo ao seu projeto para seu segundo aplicativo/serviço e escreva-o 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 permitirá a instalação/chamada do novo formulário de teste do aplicativo.

Por fim, sincronize o projeto com o Gradle.

Enviando o teste STS

Execute a tarefa zipForSubmission (com Android Studio ou com Gradle na linha de comando). Um novo arquivo, codesubmission.zip , deve ser criado no diretório build na raiz do projeto. Carregue esse arquivo junto com seu envio para o Programa de Recompensa de Vulnerabilidade do Android.