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

La fédération des outils de test de sécurité (sts-tradefed) s'appuie sur Android Trade Fédération Harnais de test pour évaluer la sécurité de tous les appareils Android qui ne relèvent pas de la suite de tests de compatibilité. Ces tests sont exclusivement pour les correctifs qui sont (ou seront associés) à un 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 qui sont nécessaires pour construire et exécuter un test STS.

<ph type="x-smartling-placeholder"></ph> Obtenir le dernier SDK STS

Prérequis

  • PC Linux 64 bits.
  • Android Studio (peut également être installé du gestionnaire de packages de votre distribution.
  • Outils de la plate-forme Android (adb, fastboot) doit être installé et se trouver dans votre $PATH (par exemple, vous devrait pouvoir exécuter adb à partir de la ligne de commande). Le moyen le plus simple installer les outils de la plateforme via le gestionnaire de packages de votre distribution.
    • Si vous utilisez le SDK Manager d'Android Studio au lieu de la plate-forme autonome 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 compilation assembleSTSARM ou assembleSTSx86 pour créer le squelette de test, en fonction de l'architecture de l'appareil Android cible appareil. Exécutez la cible de compilation runSTS pour exécuter le test squelette sur l'instance connectée (ADB doit être autorisé).

Premiers pas avec Gradle

Après avoir extrait l'archive, définissez la propriété sdk.dir dans local.properties à la racine du projet Gradle, puis exécutez la Tâche Gradle assembleSTSARM pour créer le test squelette. Une fois la compilation terminé, vous pouvez exécuter le test en accédant (cd) à build/android-sts/tools et exécuter 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. Une attaque de démonstration de faisabilité native facultative qui est poussée sur appareil via adb push et exécutée par le test côté hôte dans la 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 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 le 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 trace arrière logcat, ou recherche le code de sortie spécifique pour déterminer si l'attaque réussi.

  • Application de test d'instrumentation:

    1. Le test côté hôte transfère un APK constitué d'une application ou d'un service vers l'appareil.
    2. Le test côté hôte lance les tests JUnit côté appareil regroupés avec l'APK jusqu'à runDeviceTest()
    3. Le test JUnit côté appareil appuie sur les boutons et regarde l'application en utilisant UIAutomator, ou accède au système Android d'une manière qui révéler les failles de sécurité.
    4. La réussite ou l'échec des tests JUnit côté appareil est renvoyé à le 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 dans avec des tests côté appareil) est également possible. Autre instrumentation frameworks, tels que frida-inject, sont également disponibles. Pour en savoir plus, consultez les documentation de référence de la suite Security Test Suite et Documents de référence transférés.

Mon attaque de démonstration de faisabilité 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 ou d'un service sur l'appareil, il vous suffit de le supprimer le sous-répertoire test-app. De même, si votre test n'utilise pas de code natif exécutable, supprimez le sous-répertoire native-poc, puis synchronisez le projet avec Gradle. Le projet est configuré de manière à ignorer automatiquement la création de ces modules lorsqu'ils n'existent pas.

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

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

Ensuite, modifiez build.gradle à la racine de ce répertoire et ajoutez votre module. en suivant les instructions fournies dans copyArtifacts, assembleStsARM et assembleStsx86 Cela permettra de s'assurer que l'APK compilé est copié dans la sortie STS et permet d'installer et d'appeler la nouvelle application lors du test.

Enfin, synchronisez le projet avec Gradle.

Envoyer le test STS

Exécuter la tâche zipForSubmission (avec Android Studio ou avec Gradle sur le ligne de commande). Un fichier (codesubmission.zip) doit être créé dans build. à la racine du projet. Importez-le avec votre au programme de récompense pour la découverte de failles d'Android.