Android Security AutoRepro

Wtyczka Gradle AutoRepro jest oparta na platformie testowej Android Trade Federation i służy do testowania wszystkich urządzeń z Androidem pod kątem poprawek zabezpieczeń w odniesieniu do luk w zabezpieczeniach opisanych w biuletynie bezpieczeństwa Androida. Te testy są przeznaczone wyłącznie dla poprawek, które są lub będą powiązane z typem luki w zabezpieczeniach (CVE).

Wtyczka umożliwia tworzenie testów Tradefed poza drzewem źródłowym Androida za pomocą Android Studio lub standardowego pakietu Android SDK. Zawiera wszystkie narzędzia potrzebne do tworzenia i uruchamiania testu Tradefed.

Służy on głównie do przesyłania automatycznie odtwarzalnych dowodów koncepcji w ramach Programu nagród za wykrywanie luk w zabezpieczeniach Androida.

Pobierz przykład AutoRepro

Wymagania wstępne

Instrukcje dotyczą 64-bitowego komputera z systemem Linux.

  • Android Studio Ladybug lub nowsze – można też zainstalować za pomocą menedżera pakietów dystrybucji.
  • Narzędzia platformy Android SDK (adb, fastboot) – muszą być zainstalowane i znajdować się w $PATH (czyli musisz mieć możliwość uruchomienia adb z wiersza poleceń). Najprostszym sposobem zainstalowania narzędzi platformy jest użycie menedżera pakietów dystrybucji.
    • Jeśli zamiast samodzielnych narzędzi platformy używasz menedżera SDK w Android Studio, pamiętaj, aby dodać katalog platform-tools pakietu SDK do $PATH na potrzeby programowania w wierszu poleceń.
  • AAPT2 – Można ją też zainstalować za pomocą menedżera pakietów dystrybucji.
  • Java JDK 21 lub nowsza – zgodna z pakietem Android SDK i Gradle.

Pierwsze kroki z Androidem Studio

Po wyodrębnieniu przykładu lub szablonu otwórz katalog w Android Studio jako istniejący projekt i poczekaj na zakończenie synchronizacji Gradle. Istnieje kilka wstępnie skonfigurowanych konfiguracji uruchamiania Androida Studio.

Zadania Gradle:

  • assembleSubmissionSources – przygotuj pliki źródłowe do przesłania w formacie ZIP.
  • assembleSubmissionZip – Przygotuj plik ZIP do przesłania.
  • copyInvocationResultsToSubmission – skopiuj wyniki z poprzednich wywołań Tradefed do katalogu źródeł przesyłania AutoRepro, aby ułatwić proces weryfikacji. Pamiętaj, że zawiera on logi zarówno z hosta, jak i z urządzenia. Sprawdź zawartość przed uruchomieniem lub po uruchomieniu.

Wywołanie AutoRepro w konfiguracjach uruchamiania Androida Studio:

  • autorepro_nonroot_arm64
  • autorepro_nonroot_x86_64
  • autorepro_root_arm64
  • autorepro_root_x86_64

Konfiguracje programu uruchamiającego mają postać autorepro_{device_root}_{device_arch}. Zwykle lepiej jest używać konta bez uprawnień roota, ponieważ luki w zabezpieczeniach wymagające uprawnień roota są mniej poważne. Jednak użycie uprawnień roota do przeprowadzenia konfiguracji lub czyszczenia może być dopuszczalne, o ile jest to wyraźnie udokumentowane i ogólnie akceptowane jako prawidłowy stan bez uprawnień roota. Na przykład dopuszczalne jest użycie roota do fałszywego wysyłania wiadomości tekstowych na urządzenie, aby uniknąć konieczności używania drugiego urządzenia i wielu kart SIM.

Spowoduje to uruchomienie Tradefed na potrzeby testu. Tradefed czeka na podłączenie prawidłowego urządzenia, więc upewnij się, że jest ono podłączone, a debugowanie ADB jest autoryzowane.

Pisanie testu AutoRepro

Test AutoRepro składa się z 3 części i ma 3 odpowiednie wtyczki Gradle:

  1. Wtyczka Gradle id("com.android.security.autorepro.javahosttest") Pojedynczy test Tradefed po stronie hosta, który wchodzi w interakcję z urządzeniem za pomocą ADB. W przykładzie użyto go w katalogu submission/hostTest/.
  2. Wtyczka Gradle id("com.android.security.autorepro.apptest") Plik APK aplikacji lub usługi, który jest instalowany na urządzeniu za pomocą adb install i uruchamiany przez test po stronie hosta. Aplikacja lub usługa może też zawierać własny zestaw asercji JUnit, które są zgłaszane do narzędzia uruchamiającego po stronie hosta. W przykładzie użyto go w submission/appTest/ i katalogu.
  3. Wtyczka Gradle id("com.android.security.autorepro.ndktest") Opcjonalny atak oparty na NDK, który jest przesyłany na urządzenie przez adb push i wykonywany przez test po stronie hosta. W przykładzie użyto go w katalogu submission/ndkTest/.

Typowy przepływ testu AutoRepro zwykle przebiega według jednego z 2 wzorców:

  • Aplikacja testowa z instrumentacją:

    1. Test po stronie hosta przesyła na urządzenie plik APK zawierający aplikację lub usługę z instrumentacją.
    2. Test po stronie hosta uruchamia testy JUnit po stronie urządzenia, które są dołączone do pliku APK za pomocą runDeviceTest().
    3. Testy JUnit po stronie urządzenia klikają przyciski i obserwują aplikację za pomocą UIAutomatora lub w inny sposób uzyskują dostęp do interfejsów API Androida, co ujawnia luki w zabezpieczeniach.
    4. Informacja o powodzeniu lub niepowodzeniu testów JUnit po stronie urządzenia jest przekazywana do testu po stronie hosta, który może służyć do określenia, czy test został zaliczony. Komunikat o błędzie powinien zawierać szczegółowe informacje o tym, dlaczego asercja się nie powiodła, oraz wszelkie konkretne obiekty, wartości, wyjątki, ślady stosu lub inne artefakty jako dowód podatności na zagrożenia.

  • Model koncepcyjny NDK:

    1. Test po stronie hosta przesyła i uruchamia na urządzeniu plik wykonywalny Linuksa.
    2. Program natywny ulegnie awarii lub zwróci określony kod zakończenia.
    3. Test po stronie hosta sprawdza awarie, analizuje ślad wsteczny logcat lub szuka określonego kodu zakończenia, aby ustalić, czy atak się powiódł. Komunikat o błędzie powinien zawierać szczegółowe informacje o tym, dlaczego test się nie powiódł, oraz konkretne struktury, wartości, ślady stosu i inne artefakty jako dowód podatności na zagrożenia.

Możliwe jest też połączenie tych 2 wzorców (np. uruchomienie programu natywnego w połączeniu z testami na urządzeniu). Dostępne są też inne platformy do instrumentacji, np. frida-inject. Szczegółowe informacje znajdziesz w dokumentacji referencyjnej pakietu testów bezpieczeństwa i dokumentacji referencyjnej Tradefed.

Mój dowód koncepcji ataku nie wymaga aplikacji testowej ani natywnego pliku wykonywalnego

Większość testów nie będzie wymagać aplikacji po stronie urządzenia ani natywnego pliku wykonywalnego.

Jeśli test nie wymaga użycia funkcji, usuń niepotrzebne katalogi podprojektów Gradle.

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

Dodaj dowolną liczbę podprojektów Gradle z wtyczkami AutoRepro.

Przesyłanie testu AutoRepro

Aby dołączyć wyniki testu z urządzenia do zgłoszenia:

  • Opcjonalnie uruchom zadanie Gradle clean, aby usunąć stare przebiegi testów.
  • Uruchom odpowiednią konfigurację AutoRepro, aby wywołać Tradefed dla testu i zebrać logi oraz wyniki.
  • Uruchom zadanie copyInvocationResultsToSubmission, aby skopiować logi i wyniki do katalogu źródeł zgłoszeń.

Uruchom polecenie assembleSubmissionZip, aby utworzyć plik submission/build/autorepro-submission.zip. Prześlij ten plik wraz ze zgłoszeniem w ramach Programu wykrywania luk w zabezpieczeniach Androida. Upewnij się, że załącznik pasuje do wzorca *autorepro-submission*.zip i że został przesłany wraz z pierwszym raportem. Przesłanie zgłoszenia z opóźnieniem wpłynie na naszą możliwość prawidłowego sprawdzenia raportu.