Kit de développement de la suite de tests de sécurité Android (STS SDK)

Security Test Suite Trade Federation (sts-tradefed) est construit sur le harnais de test Android Trade Federation pour tester tous les appareils Android pour les tests de correctifs de sécurité qui ne relèvent pas de la suite de tests de compatibilité. Ces tests concernent exclusivement les correctifs qui sont associés (ou seront associés) à des vulnérabilités et expositions communes (CVE).

Le SDK permet le développement de tests STS en dehors de l'arborescence source Android à l'aide d'Android Studio ou du SDK Android standard. Il inclut tous les utilitaires nécessaires pour créer et exécuter un test STS.

Obtenir le dernier SDK STS

Conditions préalables

  • Ordinateur Linux 64 bits.
  • Android Studio (peut également être installé à partir du gestionnaire de packages de votre distribution.
  • Les outils de la plate-forme Android ( adb , fastboot ) doivent être installés et se trouver dans votre $PATH (c'est-à-dire que vous devriez pouvoir exécuter adb à partir de la ligne de commande). Le moyen le plus simple d'installer les outils de la plate-forme consiste à utiliser le gestionnaire de packages de votre distribution.
    • Si vous utilisez le gestionnaire de SDK d'Android Studio au lieu d'outils de plate-forme autonomes, n'oubliez pas d'ajouter le répertoire platform-tools du SDK à votre $PATH.
  • aapt , qui peut également être installé via le gestionnaire de packages de votre distribution.

Premiers pas avec Android Studio

Après avoir extrait l'archive, ouvrez le répertoire dans Android Studio en tant que projet existant. Exécutez la cible de génération assembleSTSARM ou assembleSTSx86 pour créer le squelette de test, en fonction de l'architecture de l'appareil Android cible. Exécutez la cible de build runSTS pour exécuter le test squelette sur l'appareil connecté (ADB doit être autorisé).

Commencez à utiliser Gradle

Après avoir extrait l'archive, définissez la propriété sdk.dir dans le fichier local.properties à la racine du projet Gradle, puis exécutez la tâche assembleSTSARM Gradle pour créer le squelette de test. Une fois la construction terminée, le test peut être exécuté en naviguant ( cd ) dans build/android-sts/tools et en exécutant le 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

Rédiger un test STS

Un test STS comporte trois parties :

  1. Un test Tradefed côté hôte qui interagit avec l'appareil via adb, dans le sous-répertoire sts-test .
  2. Une attaque de preuve de concept native facultative qui est poussée sur l'appareil via adb push et exécutée par le test côté hôte dans le sous-répertoire native-poc .
  3. Une application ou un service APK facultatif qui est installé sur l'appareil via adb install et également lancé par le test côté hôte. L'application ou le service peut également contenir son propre ensemble d'assertions JUnit qui est signalé à l'exécuteur côté hôte. Ceci se trouve dans le sous-répertoire test-app .

Un flux de test STS typique suit généralement l'un des deux modèles suivants :

  • Preuve de concept native :

    1. Le test côté hôte pousse et lance un exécutable natif sur l'appareil.
    2. Le programme natif plante ou renvoie un code de sortie spécifique.
    3. Le test côté hôte vérifie les pannes, examine la trace du logcat ou recherche le code de sortie spécifique pour déterminer si l'attaque a réussi.

  • Application de test instrumentée :

    1. Le test côté hôte pousse un APK composé d'une application ou d'un service sur l'appareil.
    2. Le test côté hôte démarre les tests JUnit côté appareil qui sont fournis avec l'APK via runDeviceTest()
    3. Les tests JUnit côté appareil appuient sur les boutons et surveillent l'application à l'aide d'UIAutomator, ou accèdent au système Android d'une manière qui révèle des vulnérabilités de sécurité.
    4. Le succès ou l'échec des tests JUnit côté périphérique est renvoyé au test côté hôte, qui peut être utilisé pour déterminer si le test a réussi ou non.

Une combinaison des deux modèles (par exemple, l'exécution d'un programme natif en conjonction avec des tests côté appareil) est également possible. D'autres frameworks d'instrumentation, tels que frida-inject , sont également disponibles. Pour plus de détails, consultez les documents de référence Security Test Suite et les documents de référence Tradefed .

Mon attaque de preuve de concept n'a pas besoin d'une application de test et/ou d'un exécutable natif

La plupart des tests n'auront pas besoin à la fois d'une application côté appareil et d'un exécutable natif.

Si votre test n'implique pas l'utilisation d'une application/service sur l'appareil, supprimez simplement le sous-répertoire test-app . De même, si votre test n'utilise pas d'exécutable natif, supprimez le sous-répertoire native-poc puis Gradle-synchronisez le projet. Le projet est configuré pour ignorer automatiquement la construction de ces modules lorsqu'ils n'existent pas.

Mon attaque de preuve de concept implique une deuxième application/service

Tout d'abord, ajoutez un nouveau module à votre projet pour votre deuxième application/service et écrivez-le comme vous le feriez pour n'importe quel autre APK.

Ensuite, modifiez build.gradle à la racine de ce répertoire et ajoutez votre module en suivant les instructions de copyArtifacts , assembleStsARM et assembleStsx86 . Cela garantira que l'APK compilé est copié dans le répertoire de sortie de STS et permet l'installation/l'appel de la nouvelle application à partir du test.

Enfin, Gradle-synchronisez le projet.

Soumettre le test STS

Exécutez la tâche zipForSubmission (soit avec Android Studio, soit avec Gradle sur la ligne de commande). Un nouveau fichier, codesubmission.zip , doit être créé dans le répertoire build à la racine du projet. Téléchargez ce fichier avec votre soumission au programme de récompense de vulnérabilité Android.