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

Pakiet Security Test Suite Trade Federation (sts-tradefed) opiera się na platformie testowej Android Trade Federation i przeprowadza testy poprawek zabezpieczeń wszystkich urządzeń z Androidem, które nie są objęte pakietem Compatibility Test Suite. Testy te służą wyłącznie do sprawdzania poprawek, które są powiązane (lub będą powiązane) z typowymi lukami w zabezpieczeniach (CVE).

Pakiet SDK umożliwia programowanie testów STS poza drzewem źródłowym Androida przy użyciu Android Studio lub standardowego pakietu SDK do Androida. Zawiera wszystkie narzędzia potrzebne do kompilacji i przeprowadzania testu STS.

Pobierz najnowszy pakiet SDK STS

Wymagania wstępne

  • 64-bitowy komputer z systemem Linux.
  • Android Studio (można je też zainstalować za pomocą menedżera pakietów dystrybucji).
  • Narzędzia platformy Androida (adb, fastboot) muszą być zainstalowane i znajdujące się w systemie $PATH (tj. adb powinno być możliwe uruchomienie z poziomu wiersza poleceń). Narzędzia platformy najłatwiej zainstalować za pomocą menedżera pakietów Twojej dystrybucji.
    • Jeśli zamiast samodzielnych narzędzi platformy używasz menedżera pakietu SDK w Android Studio, pamiętaj, aby dodać katalog platform-tools pakietu SDK do zmiennej $PATH.
  • aapt, który można też zainstalować za pomocą menedżera pakietów dystrybucji.

Pierwsze kroki z Android Studio

Po rozpakowaniu archiwum otwórz katalog w Android Studio jako istniejący projekt. Uruchom kompilację docelową assembleSTSARM lub assembleSTSx86, aby skompilować test szkieletu, w zależności od architektury docelowego urządzenia z Androidem. Uruchom ustawienie runSTS, aby przeprowadzić test szkieletu na połączonym urządzeniu (ADB musi być autoryzowany).

Pierwsze kroki z Gradle

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

  1. Test Tradefed po stronie hosta, który wchodzi w interakcję z urządzeniem za pomocą narzędzia 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 zainstalowany na urządzeniu za pomocą adb install i uruchamiany w ramach testu po stronie hosta. Aplikacja lub usługa może też zawierać własny zestaw stwierdzeń JUnit, który jest przekazywany do programu wykonawczego po stronie hosta. Znajduje się on w podkatalogu test-app.

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

  • Model natywny:

    1. Test po stronie hosta przesyła i uruchamia natywny plik wykonywalny na urządzeniu.
    2. Program natywny ulega awarii lub zwraca określony kod wyjścia.
    3. Test po stronie hosta sprawdza awarie, analizuje zapis logcat z tyłu lub szuka konkretnego kodu wyjścia, aby ustalić, czy atak się udał.

  • Zintegrowana aplikacja testowa:

    1. Test po stronie hosta przesyła plik APK zawierający aplikację lub usługę na urządzenie.
    2. Test po stronie hosta uruchamia testy JUnit po stronie urządzenia, które są dołączone do pliku APK za pomocą interfejsu runDeviceTest()
    3. Testy JUnit po stronie urządzenia klikają przyciski i obserwują aplikację za pomocą UIAutomator lub w inny sposób uzyskują dostęp do systemu Androida w sposób, który ujawnia luki w zabezpieczeniach.
    4. Wynik testów JUnit na urządzeniu jest zwracany do testu na hoście, co pozwala określić, czy test się powiódł.

Możliwe jest też połączenie obu tych wzorów (np. uruchamianie natywnego programu w połączeniu z testami na urządzeniu). Dostępne są też inne frameworki pomiarowe, np. frida-inject. Szczegółowe informacje znajdziesz w dokumentach referencyjnych Security Test Suite i Tradefed.

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

Większość testów nie wymaga aplikacji na urządzeniu ani natywnego pliku wykonywalnego.

Jeśli test nie wymaga korzystania z aplikacji lub usługi na urządzeniu, po prostu usuń podkatalog test-app. Podobnie, jeśli w teście nie jest używany natywny plik wykonywalny, usuń podkatalog native-poc, a następnie zsynchronizuj projekt za pomocą Gradle. Projekt jest skonfigurowany tak, aby automatycznie pomijać kompilowanie tych modułów, gdy ich nie ma.

Mój atak typu proof-of-concept wykorzystuje drugą aplikację lub usługę

Najpierw dodaj do projektu nowy moduł dla drugiej aplikacji/usługi i zapisz się w taki sam sposób jak w przypadku każdego innego pliku APK.

Następnie w katalogu głównym katalogu otwórz plik build.gradle i dodaj moduł, postępując zgodnie z instrukcjami podanymi w artykułach copyArtifacts, assembleStsARM i assembleStsx86. Dzięki temu skompilowany plik APK zostanie skopiowany do katalogu wyjściowego STS i będzie mógł zainstalować/wywołać nową aplikację z testu.

Na koniec zsynchronizuj projekt za pomocą Gradle.

Przesyłanie testu STS

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