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

A Security Test Suite Trade Federation (sts-tradefed) foi criada com base no equipamento de teste da Android Trade Federation para testar todos os dispositivos Android em busca de 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. Inclui todos os utilitários necessários para construir e executar um teste STS.

Obtenha o SDK STS mais recente

Pré-requisitos

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

Comece a usar o Android Studio

Após 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 esqueleto, dependendo da arquitetura do dispositivo Android de destino. Execute o destino de construção runSTS para executar o teste de esqueleto no dispositivo conectado (o 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 assembleSTSARM Gradle para construir o teste de esqueleto. 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 ao dispositivo por meio adb push e executado pelo teste do lado do host no subdiretório native-poc .
  3. Um APK de aplicativo ou serviço opcional 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 de dois padrões:

  • Prova de conceito nativa:

    1. O teste do lado 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, analisa o backtrace do logcat 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 acompanham o APK por meio de runDeviceTest()
    3. O JUnit do lado do dispositivo testa toques em botões e observa o aplicativo usando o UIAutomator ou acessa 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 Gradle. O projeto está configurado para ignorar 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 deste 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 aplicativo a partir do teste.

Por fim, sincronize o projeto com 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. Faça upload desse arquivo junto com seu envio para o Programa de recompensa por vulnerabilidade do Android.