Android Security AutoRepro

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Wtyczka AutoRepro Gradle została opracowana na podstawie zestawu testów Android Trade Federation i służy do testowania wszystkich urządzeń z Androidem pod kątem łatek zabezpieczeń w odniesieniu do podatności w komunikatach o błędach dotyczących zabezpieczeń Androida. Te testy są przeznaczone wyłącznie do poprawek, które są powiązane lub zostaną powiązane z typowymi lukami 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.

Jest ona używana głównie do przesyłania automatycznie powtarzalnych dowodów koncepcji w ramach Programu nagród za luki w zabezpieczeniach Androida.

Pobierz przykładowy plik AutoRepro download

Wymagania wstępne

Instrukcje dotyczą 64-bitowego komputera z systemem Linux.

• Android Studio Ladybug lub nowsza wersja – można je też zainstalować za pomocą menedżera pakietów dystrybucji.
• Narzędzia platformy pakietu SDK Androida (adb, fastboot) – muszą być zainstalowane i znajdować się w folderze $PATH (czyli musisz mieć możliwość uruchomienia polecenia adb z poziomu 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 pakietu SDK w Android Studio, pamiętaj, aby dodać katalog platform-tools pakietu SDK do katalogu $PATH na potrzeby programowania w linii poleceń.
• AAPT2. – Można je też zainstalować za pomocą menedżera pakietów dystrybucji.
• Java JDK 21 lub nowsza – zgodna z pakietem Android SDK i Gradle.

Pierwsze kroki z Android Studio

Po wypakowaniu przykładu lub szablonu otwórz katalog w Android Studio jako istniejący projekt i zaczekaj, aż Gradle zakończy synchronizację. Dostępnych jest kilka wstępnie skonfigurowanych konfiguracji uruchomienia Android Studio.

Zadania Gradle:

• assembleSubmissionSources – zmontuj pliki źródłowe do przesłania w pliku ZIP.
• assembleSubmissionZip – zmontuj plik ZIP z przesyłanymi danymi.
• copyInvocationResultsToSubmission – skopiuj wyniki z poprzednich wywołań Tradefed do katalogu źródeł przesyłanych do AutoRepro, aby ułatwić proces sprawdzania. Pamiętaj, że zawiera on dzienniki zarówno hosta, jak i urządzenia. Przejrzyj je przed uruchomieniem tego polecenia lub po jego uruchomieniu.

Konfiguracje uruchamiania Android Studio w AutoRepro:

• autorepro_nonroot_arm64
• autorepro_nonroot_x86_64
• autorepro_root_arm64
• autorepro_root_x86_64

Konfiguracje menu z aplikacjami mają postać autorepro_{device_root}_{device_arch}. Zwykle zaleca się używanie nierootowych uprawnień, ponieważ luki wymagające uprawnień root są mniej poważne. Używanie uprawnień root do konfigurowania lub czyszczenia jest jednak dopuszczalne, o ile jest wyraźnie udokumentowane i ogólnoprzyjęte jako prawidłowy stan bez uprawnień root. Dopuszczalne jest na przykład użycie uprawnień roota do fałszywego wysyłania SMS-ów na urządzenie, aby uniknąć konieczności korzystania z drugiego urządzenia i wielu kart SIM.

Te opcje otworzą Tradefed na potrzeby testu. Tradefed czeka na połączenie z odpowiednim urządzeniem, więc upewnij się, że jest ono połączone i że debugowanie ADB jest autoryzowane.

Pisanie testu automatycznego odtwarzania

Test AutoRepro składa się z 3 części i 3 odpowiednich wtyczek Gradle:

1. Wtyczka Gradle id("com.android.security.autorepro.javahosttest") Jednorazowy test Tradefed po stronie hosta, który współpracuje z urządzeniem za pomocą ADB. Przykład używa go w katalogu submission/hostTest/.
2. Wtyczka Gradle id("com.android.security.autorepro.apptest") Plik APK aplikacji lub usługi zainstalowany na urządzeniu za pomocą adb install i uruchamiany przez test po stronie hosta. Aplikacja lub usługa może też zawierać własny zbiór stwierdzeń JUnit, który jest przekazywany do narzędzia do wykonywania testów po stronie hosta. W tym przykładzie jest on używany w katalogu submission/appTest/.
3. Wtyczka Gradle id("com.android.security.autorepro.ndktest") Opcjonalny atak proof-of-concept oparty na NDKu, który jest przesyłany na urządzenie za pomocą adb push i uruchamiany przez test po stronie hosta. W przykładzie jest on używany w katalogu submission/ndkTest/.

Typowy proces testowania automatycznego odtwarzania zwykle przebiega według jednego z tych schematów:

• Instrumentowana aplikacja testowa:

  1. Test po stronie hosta przesyła na urządzenie plik APK zawierający instrumentowaną aplikację lub usługę.
  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ą UIAutomator lub w inny sposób uzyskują dostęp do interfejsów API Androida w sposób, który ujawnia luki w zabezpieczeniach.
  4. Wynik testów JUnit na urządzeniu jest zwracany do testu po stronie hosta, co pozwala określić, czy test się powiódł. Komunikat o błędzie powinien zawierać szczegółowe informacje o przyczynie, dla której założenie nie zostało spełnione, oraz konkretne obiekty, wartości, wyjątki, informacje o łańcuchu wywołań lub inne artefakty potwierdzające podatność na atak.

• Model koncepcyjny NDK:

  1. Test po stronie hosta przesyła i uruchamia plik wykonywalny Linuksa na urządzeniu.
  2. Program natywny ulega awarii lub zwraca określony kod zakończenia.
  3. Test po stronie hosta sprawdza, czy doszło do awarii, analizuje ścieżkę śledzenia logcat lub szuka określonego kodu zakończenia, aby określić, czy atak się powiódł. Komunikat o błędzie powinien zawierać szczegółowe informacje o tym, dlaczego założenie nie zostało spełnione, oraz informacje o konkretnych strukturach, wartościach, ścieżkach wywołania lub innych artefaktach, które stanowią dowód na podatność.

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.

W przypadku ataku proof-of-concept nie trzeba uruchamiać testowej aplikacji 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 funkcji, usuń niepotrzebne katalogi podprojektów Gradle.

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

Dodaj dowolną liczbę projektów podrzędnych Gradle z wtyczkami AutoRepro.

Przesyłanie testu automatycznego powielania

Aby dołączyć wyniki testów z urządzenia jako część przesyłanych danych:

• Opcjonalnie uruchom zadanie Gradle clean, aby usunąć wszystkie stare testy.
• Uruchom odpowiednią konfigurację AutoRepro, aby wywołać narzędzie Tradefed w ramach testu i zebrać dzienniki oraz wyniki.
• Uruchom zadanie copyInvocationResultsToSubmission, aby skopiować logi i wyniki do katalogu źródeł przesyłania.

Uruchom assembleSubmissionZip, aby utworzyć plik submission/build/autorepro-submission.zip. Prześlij ten plik wraz z informacjami do programu lojalnościowego dotyczącego luk w zabezpieczeniach w Androidzie. Upewnij się, że załącznik jest zgodny ze wzorcem *autorepro-submission*.zip i został przesłany wraz z pierwotnym raportem. Przesyłanie zgłoszeń z opóźnieniem może utrudnić nam dokładne sprawdzenie Twojego zgłoszenia.