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

Security Test Suite Trade Federation (sts-tradefed) est construit sur le faisceau de tests 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) à un Common Vulnerabilities and Exposures (CVE).

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

Obtenez le dernier SDK STS

Conditions préalables

  • 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 (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 paquets de votre distribution.

Commencez à utiliser 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 build assembleSTSARM ou assembleSTSx86 pour créer le test squelette, 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 test squelette. 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

Écrire un test STS

Un test STS comprend 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 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é au programme d'exécution côté hôte. C'est 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 plantages, 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 envoie 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 appuie sur les boutons et surveillent l'application à l'aide d'UIAutomator, ou accèdent au système Android de manière à révéler des vulnérabilités de sécurité.
    4. La réussite 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, exécution d'un programme natif en conjonction avec des tests côté appareil) est également possible. Certains 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 ne nécessite pas d'application de test et/ou d'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/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 Gradle 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 dans copyArtifacts , assembleStsARM et assembleStsx86 . Cela garantira que l'APK compilé est copié dans le répertoire de sortie de STS et permettra l'installation/l'appel de la nouvelle application à partir du test.

Enfin, synchronisez Gradle 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 Android Vulnerability Reward.