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

La fédération commerciale de la suite de tests de sécurité (sts-tradefed) s'appuie sur le harnais de test d'Android Trade Fédération pour tester tous les appareils Android afin de détecter les tests des correctifs de sécurité qui ne font pas partie de la suite de tests de compatibilité. Ces tests sont réservés aux correctifs associés (ou qui seront associés) à une faille et exposition courante (CVE, Common Vulnerabilities and Exposures).

Le SDK permet de développer des 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 à la création et à l'exécution d'un test STS.

Obtenir le dernier SDK STS

Prérequis

  • PC 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 (par exemple, 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 paquets de votre distribution.
    • Si vous utilisez le SDK Manager d'Android Studio au lieu des 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 paquets 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 compilation assembleSTSARM ou assembleSTSx86 pour compiler le test de squelette, en fonction de l'architecture de l'appareil Android cible. Exécutez la cible de compilation runSTS pour exécuter le test squelette sur l'appareil connecté (ADB doit être autorisé).

Premiers pas avec 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 Gradle assembleSTSARM pour créer le test de squelette. Une fois la compilation terminée, vous pouvez exécuter le test en accédant (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

Écrire un test STS

Un test STS se compose de 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. Attaque de démonstration de faisabilité native facultative qui est transmise à l'appareil via adb push et exécutée par le test côté hôte dans le sous-répertoire native-poc.
  3. Un APK d'application ou de service facultatif 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. Il se trouve dans le sous-répertoire test-app.

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

  • Démonstration de faisabilité native :

    1. Le test côté hôte transfère 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 recherche les plantages, examine la rétrocontamination logcat ou recherche le code de sortie spécifique pour déterminer si l'attaque a réussi.

  • Application de test d'instrumentation:

    1. Le test côté hôte transfère un APK composé d'une application ou d'un service sur l'appareil.
    2. Le test côté hôte lance les tests JUnit côté appareil qui sont fournis avec l'APK via runDeviceTest().
    3. JUnit côté appareil teste les boutons d'appui et surveille l'application à l'aide d'UIAutomator, ou accède au système Android de manière à révéler des failles de sécurité.
    4. La réussite ou l'échec des tests JUnit côté appareil est renvoyé au test côté hôte, qui peut être utilisé pour déterminer si le test a réussi ou non.

Il est également possible de combiner les deux modèles (par exemple, l'exécution d'un programme natif conjointement avec des tests côté appareil). D'autres frameworks d'instrumentation, tels que frida-inject, sont également disponibles. Pour en savoir plus, consultez la documentation de référence de la suite Security Test Suite et la documentation de référence sur les données transférables.

Mon attaque de preuve de concept ne nécessite pas d'application de test ni d'exécutable natif

La plupart des tests ne nécessitent pas à la fois une application côté appareil et un exécutable natif.

Si votre test n'implique pas l'utilisation d'une application/d'un 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 synchronisez le projet avec Gradle. Le projet est configuré pour ignorer automatiquement la compilation de ces modules lorsqu'ils n'existent pas.

Mon attaque de démonstration de faisabilité implique une deuxième application/un deuxième service

Commencez par ajouter un nouveau module à votre projet pour votre deuxième application/service, puis é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 dans copyArtifacts, assembleStsARM et assembleStsx86. Cela garantit que l'APK compilé est copié dans le répertoire de sortie de STS et permet d'installer/d'appeler la nouvelle application à partir du test.

Enfin, synchronisez le projet avec Gradle.

Envoyer le test STS

Exécutez la tâche zipForSubmission (avec Android Studio ou avec Gradle sur la ligne de commande). Un nouveau fichier, codesubmission.zip, doit être créé dans le répertoire build à la racine du projet. Importez ce fichier avec votre envoi au programme de récompenses pour la détection de failles Android.