Zestaw deweloperski pakietu testów zabezpieczeń systemu Android (STS SDK)

Security Test Suite Trade Federation (sts-tradefed) opiera się na wiązce testowej Android Trade Federation i umożliwia testowanie wszystkich urządzeń z systemem Android pod kątem testów poprawek zabezpieczeń, które nie wchodzą w zakres pakietu testów zgodności. Testy te dotyczą wyłącznie poprawek, które są powiązane (lub będą powiązane) z typowymi lukami i zagrożeniami (CVE).

SDK umożliwia tworzenie testów STS poza drzewem źródłowym Androida przy użyciu Android Studio lub standardowego zestawu SDK systemu Android. Zawiera wszystkie narzędzia potrzebne do zbudowania i uruchomienia testu STS.

Pobierz najnowszy pakiet SDK STS

Warunki wstępne

  • 64-bitowy komputer z systemem Linux.
  • Android Studio (można również zainstalować z menedżera pakietów Twojej dystrybucji.
  • Narzędzia platformy Android ( adb , fastboot ) muszą być zainstalowane i znajdować się w $PATH (tzn. powinieneś móc uruchomić adb z wiersza poleceń). Najłatwiejszym sposobem zainstalowania narzędzi platformy jest skorzystanie z menedżera pakietów Twojej dystrybucji.
    • Jeśli używasz menedżera SDK Android Studio zamiast samodzielnych narzędzi platformy, pamiętaj o dodaniu katalogu platform-tools SDK do $PATH.
  • aapt , który można również zainstalować za pomocą menedżera pakietów Twojej dystrybucji.

Zacznij korzystać z Android Studio

Po rozpakowaniu archiwum otwórz katalog w Android Studio jako istniejący projekt. Uruchom cel kompilacji assembleSTSARM lub assembleSTSx86 , aby zbudować test szkieletu, w zależności od architektury docelowego urządzenia z systemem Android. Uruchom cel kompilacji runSTS , aby uruchomić test szkieletu na podłączonym urządzeniu (ADB musi być autoryzowany).

Zacznij korzystać z Gradle

Po rozpakowaniu archiwum ustaw właściwość sdk.dir w pliku local.properties w katalogu głównym projektu Gradle, a następnie uruchom zadanie assembleSTSARM Gradle, aby zbudować test szkieletu. Po zakończeniu kompilacji test można uruchomić, przechodząc ( cd ) do build/android-sts/tools i wykonując opakowanie 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

Napisz test STS

Test STS składa się z trzech części:

  1. Test Tradefed po stronie hosta, który wchodzi w interakcję z urządzeniem poprzez adb w podkatalogu sts-test .
  2. Opcjonalny natywny atak typu proof-of-concept, który jest przesyłany na urządzenie za pomocą adb push i wykonywany przez test po stronie hosta w podkatalogu native-poc .
  3. Opcjonalny plik APK aplikacji lub usługi instalowany na urządzeniu poprzez adb install , a także uruchamiany przez test po stronie hosta. Aplikacja lub usługa może również zawierać własny zestaw potwierdzeń JUnit, który jest raportowany do modułu uruchamiającego po stronie hosta. Znajduje się on w podkatalogu test-app .

Typowy przebieg testu STS zwykle przebiega według jednego z dwóch wzorców:

  • Natywny dowód koncepcji:

    1. Test po stronie hosta wypycha i uruchamia natywny plik wykonywalny na urządzeniu.
    2. Program natywny ulega awarii lub zwraca określony kod zakończenia.
    3. Test po stronie hosta sprawdza, czy nie występują awarie, śledzi logcat lub szuka określonego kodu wyjścia, aby określić, czy atak się powiódł.
  • Oprzyrządowana aplikacja testowa:

    1. Test po stronie hosta wypycha na urządzenie plik APK składający się z aplikacji lub usługi.
    2. Test po stronie hosta rozpoczyna testy JUnit po stronie urządzenia, które są dołączone do pakietu APK za pomocą runDeviceTest()
    3. JUnit po stronie urządzenia testuje dotknięcie przycisków i ogląda aplikację za pomocą UIAutomator lub w inny sposób uzyskuje dostęp do systemu Android w sposób ujawniający luki w zabezpieczeniach.
    4. Sukces lub niepowodzenie testów JUnit po stronie urządzenia jest zwracany do testu po stronie hosta, który może zostać wykorzystany do ustalenia, czy test zakończył się pomyślnie, czy nie.

Możliwa jest również kombinacja tych dwóch wzorców (na przykład uruchomienie programu natywnego w połączeniu z testami po stronie urządzenia). Dostępne są również inne struktury instrumentacji, takie jak frida-inject . Aby uzyskać szczegółowe informacje, zobacz dokumentację referencyjną pakietu Security Test Suite i dokumentację referencyjną Tradefed .

Mój atak potwierdzający koncepcję nie wymaga aplikacji testowej i/lub natywnego pliku wykonywalnego

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

Jeśli test nie wymaga użycia aplikacji/usługi na urządzeniu, po prostu usuń podkatalog test-app . Podobnie, jeśli Twój test nie korzysta z natywnego pliku wykonywalnego, usuń podkatalog native-poc a następnie zsynchronizuj projekt metodą Gradle. Projekt jest skonfigurowany tak, aby automatycznie pomijał budowanie tych modułów, jeśli nie istnieją.

Mój atak weryfikujący koncepcję obejmuje drugą aplikację/usługę

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

Następnie edytuj build.gradle w katalogu głównym tego katalogu i dodaj moduł, postępując zgodnie z instrukcjami zawartymi w copyArtifacts , assembleStsARM i assembleStsx86 . Dzięki temu skompilowany plik APK zostanie skopiowany do katalogu wyjściowego STS i umożliwi instalację/wywołanie nowej aplikacji z testu.

Na koniec zsynchronizuj projekt Gradle.

Przesyłanie testu STS

Uruchom zadanie zipForSubmission (w Android Studio lub Gradle w wierszu poleceń). Należy utworzyć nowy plik codesubmission.zip w katalogu build w katalogu głównym projektu. Prześlij ten plik wraz ze zgłoszeniem do programu nagród za luki w zabezpieczeniach systemu Android.