Zestaw programistyczny Android Security Test Suite (STS SDK)

Security Test Suite Trade Federation (sts-tradefed) jest zbudowany na szczycie zestawu testowego Android Trade Federation do testowania wszystkich urządzeń z Androidem pod kątem testów poprawek zabezpieczeń, które nie mieszczą się w pakiecie testów zgodności. Testy te dotyczą wyłącznie poprawek, które są (lub będą powiązane) z typowymi lukami w zabezpieczeniach i zagrożeniami (CVE).

Zestaw SDK umożliwia opracowywanie testów STS poza drzewem źródłowym systemu Android 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 STS SDK

Wymagania 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ś być w stanie uruchomić adb z wiersza poleceń). Najprostszym sposobem na zainstalowanie 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 swojego $PATH.
  • aapt , który można również zainstalować za pomocą menedżera pakietów dystrybucji.

Rozpocznij korzystanie z Android Studio

Po rozpakowaniu archiwum otwórz katalog w Android Studio jako istniejący projekt. Uruchom obiekt docelowy kompilacji assembleSTSARM lub assembleSTSx86 , aby skompilować test szkieletowy, 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 mieć autoryzację).

Rozpocznij korzystanie 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 szkieletowy. 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 przez adb, w podkatalogu sts-test .
  2. Opcjonalny natywny atak typu „proof-of-concept”, który jest przekazywany 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, który jest instalowany na urządzeniu przez adb install i uruchamiany przez test po stronie hosta. Aplikacja lub usługa może również zawierać własny zestaw potwierdzeń JUnit, który jest zgłaszany do modułu uruchamiającego po stronie hosta. Znajduje się w podkatalogu test-app .

Typowy przebieg testu STS jest zwykle zgodny z jednym z dwóch wzorców:

  • Natywna weryfikacja koncepcji:

    1. Test po stronie hosta wypycha i uruchamia natywny plik wykonywalny na urządzeniu.
    2. Natywny program ulega awarii lub zwraca określony kod wyjścia.
    3. Test po stronie hosta sprawdza awarie, sprawdza wsteczny ślad 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 pakiet APK składający się z aplikacji lub usługi na urządzenie.
    2. Test po stronie hosta uruchamia testy JUnit po stronie urządzenia, które są dołączone do pakietu APK za pomocą runDeviceTest()
    3. JUnit po stronie urządzenia testuje przyciski i obserwuje aplikację za pomocą UIAutomator lub w inny sposób uzyskuje dostęp do systemu Android w sposób, który ujawnia luki w zabezpieczeniach.
    4. Powodzenie lub niepowodzenie testów JUnit po stronie urządzenia jest zwracane do testu po stronie hosta, którego można użyć do określenia, czy test zakończył się pomyślnie, czy nie.

Możliwe jest również połączenie tych dwóch wzorców (np. uruchomienie programu natywnego w połączeniu z testami po stronie urządzenia). Dostępne są również inne frameworki oprzyrządowania, takie jak frida-inject . Aby uzyskać szczegółowe informacje, zapoznaj się z dokumentacją referencyjną pakietu Security Test Suite i dokumentacją referencyjną Tradefed .

Mój atak typu „proof-of-concept” 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 Twój test nie obejmuje korzystania z aplikacji/usługi na urządzeniu, po prostu usuń podkatalog test-app . Podobnie, jeśli twój test nie używa natywnego pliku wykonywalnego, usuń podkatalog native-poc a następnie zsynchronizuj projekt Gradle. Projekt jest skonfigurowany tak, aby automatycznie pomijał budowanie tych modułów, gdy nie istnieją.

Mój atak polegający na weryfikacji koncepcji obejmuje drugą aplikację/usługę

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

Następnie edytuj build.gradle w katalogu głównym tego katalogu i dodaj swój moduł, postępując zgodnie z instrukcjami w copyArtifacts , assembleStsARM i assembleStsx86 . Zapewni to skopiowanie skompilowanego pliku APK 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ń). Nowy plik, codesubmission.zip , powinien zostać utworzony w katalogu build w katalogu głównym projektu. Prześlij ten plik wraz ze zgłoszeniem do programu nagród za luki w zabezpieczeniach Androida.