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 executaradb
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.
- 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
- 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:
- Um teste Tradefed do lado do host que interage com o dispositivo por meio do adb, no
Subdiretório
sts-test
. - Um ataque de prova de conceito nativo opcional que é enviado
pelo
adb push
e executada pelo teste do lado do host no Subdiretórionative-poc
. - 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óriotest-app
.
Um fluxo de teste STS típico geralmente segue um destes dois padrões:
Prova de conceito nativa:
- O teste no lado do host envia e inicia um executável nativo no dispositivo.
- O programa nativo falha ou retorna um código de saída específico.
- 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:
- O teste no lado do host envia um APK que consiste em um app ou serviço para o dispositivo.
- O teste do lado do host inicia os testes JUnit do lado do dispositivo que são agrupados.
com o APK pela
runDeviceTest()
- 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.
- 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.