Pakiet dla programistów Android Security Test Suite (STS SDK)

Federacja Handlu Security Test Suite (sts-tradefed) jest zbudowana Federacja Android Trade za pomocą jarzma testowego do testowania bezpieczeństwa wszystkich urządzeń z Androidem testów poprawek, które nie należą do pakietu Compatibility Test Suite. Te testy są wyłącznie w przypadku poprawek, które są powiązane (lub będą powiązane) z Typowe luki w zabezpieczeniach (CVE).

Pakiet SDK umożliwia programowanie testów STS poza drzewem źródłowym Androida za pomocą Android Studio lub standardowego pakietu Android SDK. Obejmuje wszystkie media niezbędnych do utworzenia i przeprowadzenia testu STS.

Pobierz najnowszy pakiet SDK STS

Wymagania wstępne

  • 64-bitowy komputer z systemem Linux.
  • Android Studio (można też zainstalować) w menedżerze pakietów tej dystrybucji.
  • Narzędzia platformy Androida (adb, fastboot) muszą być zainstalowane w Twoim urządzeniu $PATH (tzn. powinno być możliwe uruchamianie adb z wiersza poleceń). Najprostszy sposób narzędzia platformy można zainstalować za pomocą menedżera pakietów w swojej dystrybucji.
    • Jeśli używasz Menedżera pakietów SDK w Android Studio zamiast samodzielnej platformy narzędzi, pamiętaj o dodaniu katalogu platform-tools pakietu SDK do ścieżki $PATH.
  • aapt, który można też zainstalować za pomocą menedżera pakietów Twojej dystrybucji.
.

Pierwsze kroki z Android Studio

Po rozpakowaniu archiwum otwórz katalog w Android Studio jako plik istniejącego projektu. Uruchom cel kompilacji assembleSTSARM lub assembleSTSx86, aby w zależności od architektury docelowego Androida urządzenia. Uruchom cel kompilacji runSTS, aby uruchomić test szkieletowy na połączonym urządzenia (ADB musi być autoryzowane).

Pierwsze kroki z Gradle

Po rozpakowaniu archiwum ustaw właściwość sdk.dir w parametrze local.properties w katalogu głównym projektu Gradle, a następnie uruchom assembleSTSARM Zadanie Gradle, które pozwala utworzyć test szkieletowy. Po utworzeniu Gdy skończysz, test możesz uruchomić, przechodząc do witryny (cd) build/android-sts/tools i uruchamiam kod 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

Pisanie testu STS

Test STS składa się z 3 etapów:

  1. Test Tradefed po stronie hosta, który wchodzi w interakcję z urządzeniem za pomocą narzędzia adb, Podkatalog sts-test.
  2. Opcjonalny natywny atak demonstracyjny na model koncepcyjny urządzenia za pomocą usługi adb push i wykonane w ramach testu po stronie hosta native-poc.
  3. Opcjonalny plik APK aplikacji lub usługi zainstalowany na urządzeniu za pomocą adb install, a także uruchomiono w ramach testu po stronie hosta. Aplikacja lub usługa może też zawierać własny zestaw asercji JUnit zgłaszanych do po stronie hosta. Ten element znajduje się w podkatalogu test-app.

Typowy przebieg testu STS odbywa się zwykle zgodnie z jednym z 2 wzorców:

  • Model natywny:

    1. Test po stronie hosta przekazuje i uruchamia natywny plik wykonywalny urządzenia.
    2. Program natywny ulega awarii lub zwraca określony kod wyjścia.
    3. Test po stronie hosta przeprowadza testy pod kątem awarii, analizuje zapis logcat z backendem, lub szuka konkretnego kodu wyjścia, aby określić, czy atak udało się.

  • Zintegrowana aplikacja testowa:

    1. Test po stronie hosta przekazuje do aplikacji plik APK zawierający aplikację lub usługę urządzenia.
    2. Test po stronie hosta rozpoczyna pakiet testów JUnit po stronie urządzenia. z pakietem APK w runDeviceTest()
    3. JUnit po stronie urządzenia testuje dotykanie przycisków i sprawdzanie aplikacji za pomocą UIAutomator ani w inny sposób uzyskuje dostęp do systemu Android w sposób, i ujawnić luki w zabezpieczeniach.
    4. Powodzenie lub niepowodzenie testów JUnit po stronie urządzenia jest zwracany do test po stronie hosta, który może służyć do ustalenia, czy test zaliczył się lub nie.

kombinacji 2 wzorców (na przykład uruchomienie programu natywnego w w połączeniu z testami po stronie urządzenia). Inne narzędzia dostępne są również platformy, takie jak frida-inject. Więcej informacji: Dokumentacja pakietu Security Test Suite oraz Przekształcone dokumenty referencyjne.

Mój atak typu „dowód koncepcyjny” nie wymaga aplikacji testowej ani natywnego pliku wykonywalnego

Większość testów nie wymaga zarówno aplikacji po stronie urządzenia, jak i natywnego pliku wykonywalnego.

Jeśli test nie obejmuje użycia aplikacji/usługi na urządzeniu, usuń do podkatalogu test-app. Podobnie, jeśli test nie korzysta z tagu natywnego plik wykonywalny, usuń podkatalog native-poc, a następnie zsynchronizuj projekt za pomocą Gradle. Projekt jest skonfigurowany tak, aby automatycznie pomijać tworzenie tych modułów, gdy nie istnieją.

Mój atak typu „dowód koncepcyjny” obejmuje drugą aplikację/usługę

Najpierw dodaj do projektu nowy moduł dla drugiej aplikacji/usługi i zapisz tak jak każdy inny plik APK.

Następnie edytuj build.gradle w katalogu głównym tego katalogu i dodaj moduł wykonując instrukcje podane w dokumentach copyArtifacts, assembleStsARM i assembleStsx86 Dzięki temu skompilowany plik APK zostanie skopiowany do danych wyjściowych i umożliwia instalowanie/wywołanie nowej aplikacji z testu.

Na koniec Gradle zsynchronizuj projekt.

Przesyłanie testu STS

Uruchom zadanie zipForSubmission (przy użyciu Android Studio lub Gradle na wiersza poleceń). Nowy plik codesubmission.zip należy utworzyć w lokalizacji build w katalogu głównym projektu. Prześlij ten plik razem z do programu wyszukiwania luk w zabezpieczeniach Androida.