Android Güvenlik Test Paketi geliştirme kiti (STS SDK'sı)

Security Test Suite Trade Federation (sts-tradefed), tüm Android cihazları Compatibility Test Suite'e dahil olmayan güvenlik yaması testleri açısından test etmek için Android Trade Federation test donanımının üzerine inşa edilmiştir. Bu testler, yalnızca Common Vulnerabilities and Exposures (CVE) ile ilişkilendirilmiş (veya ilişkilendirilecek) düzeltmeler içindir.

SDK, Android Studio veya standart Android SDK kullanılarak Android kaynak ağacının dışında STS testlerinin geliştirilmesine olanak tanır. STS testi oluşturmak ve çalıştırmak için gereken tüm yardımcı programları içerir.

En Son STS SDK'sını Edinin

Ön koşullar

• 64 bit Linux PC.
• Android Studio (distronuzun paket yöneticisinden de yüklenebilir.
• Android platform araçlarının (adb, fastboot) yüklü olması ve $PATH içinde olması gerekir (yani komut satırından adb çalıştırabilmeniz gerekir). Platform araçlarını yüklemenin en kolay yolu dağıtımınızın paket yöneticisini kullanmaktır.
  • Bağımsız platform araçları yerine Android Studio'nun SDK yöneticisini kullanıyorsanız SDK'nın platform-tools dizinini $PATH dosyanıza eklemeyi unutmayın.
• aapt. Bu paket, distro'nuzun paket yöneticisi aracılığıyla da yüklenebilir.

Not: ADB ve AAPT kurulumu konusunda yardıma ihtiyacınız varsa CTS kılavuzuna bakın.

Dikkat: STS resmi olarak yalnızca 64 bit Linux makinelerini destekler. STS SDK ile yazılan testler Windows veya MacOS'te Android Studio ile derlenebilir ancak söz konusu platformlarda çalıştırılmasını sağlamak çok önemli değildir ve bu belgenin kapsamı dışındadır.

Android Studio'yu kullanmaya başlama

Arşivi çıkardıktan sonra dizini Android Studio'da mevcut bir proje olarak açın. Hedef Android cihazın mimarisine bağlı olarak iskelet testi oluşturmak için assembleSTSARM veya assembleSTSx86 derleme hedefini çalıştırın. İskelet testini bağlı cihazda çalıştırmak için runSTS derleme hedefini çalıştırın (ADB yetkili olmalıdır).

Gradle'ı kullanmaya başlayın

Arşivi çıkardıktan sonra local.properties dosyasında sdk.dir özelliğini Gradle projesinin kök düzeyinde ayarlayın ve ardından iskelet testini oluşturmak için assembleSTSARM Gradle görevini çalıştırın. Derleme tamamlandıktan sonra build/android-sts/tools'a gidip (cd) sts-tradefed sarmalayıcısını çalıştırarak testi çalıştırabilirsiniz.

$ echo 'sdk.dir=/home/<myusername>/Android/Sdk' > local.properties
$ ./gradlew assembleSTSARM
$ cd build/android-sts/tools
$ ./sts-tradefed run sts-dynamic-develop -m hostsidetest

STS testi yazma

Not: STS testi, cihazın güvenlik açığı olmadığında geçer, cihazın güvenlik açığı olduğunda veya başka bir deyişle saldırı başarılı olduğunda başarısız olur. Cihazın güvenlik açığı olup olmadığını belirleyemediğinde test bir ASSUMPTION_FAILURE döndürmelidir (örneğin, Assert yerine Assume kullanılarak).

STS testi üç bölümden oluşur:

1. sts-test alt dizininde, adb aracılığıyla cihazla etkileşime giren ana makine taraflı Tradefed testi.
2. adb push aracılığıyla cihaza gönderilen ve native-poc alt dizinindeki ana makine tarafı test tarafından yürütülen isteğe bağlı yerel bir kavram kanıtı saldırısı.
3. adb install aracılığıyla cihaza yüklenen ve ana makine tarafı test tarafından da başlatılan isteğe bağlı bir uygulama veya hizmet APK'sı. Uygulama veya hizmet, ana makine tarafı çalıştırıcıya bildirilen kendi JUnit onayları grubunu da içerebilir. Bu dosya test-app alt dizinindedir.

Tipik bir STS test akışı genellikle iki kalıptan birini izler:

• Doğal kavram kanıtlama:

  1. Ana makine tarafı testi, cihazda yürütülebilir bir yerel dosyayı aktarır ve başlatır.
  2. Yerel program çöker veya belirli bir çıkış kodu döndürür.
  3. Ana makine tarafındaki test, saldırının başarılı olup olmadığını belirlemek için kilitlenmeleri kontrol eder, logcat geri izlemesine bakar veya belirli çıkış kodunu arar.

• Araçlı test uygulaması:

  1. Ana makine tarafı testi, uygulama veya hizmetten oluşan bir APK'yı cihaza aktarır.
  2. Ana makine tarafı testi, runDeviceTest() üzerinden APK ile birlikte gelen cihaz tarafı JUnit testlerini başlatır
  3. Cihaz tarafındaki JUnit testleri, düğmelere dokunur ve UIAutomator'u kullanarak uygulamayı izler ya da güvenlik açıklarını ortaya çıkaracak şekilde Android sistemine başka bir şekilde erişir.
  4. Cihaz tarafı JUnit testlerinin başarılı veya başarısız olması, ana makine tarafı testine döndürülür. Bu test, testin başarılı olup olmadığını belirlemek için kullanılabilir.

İki kalıbın bir kombinasyonu (ör. cihaz taraflı testlerle birlikte yerel bir programın çalıştırılması) da mümkündür. frida-inject gibi başka araç çerçeveleri de vardır. Ayrıntılar için Security Test Suite referans dokümanlarını ve Tradefed referans dokümanlarını inceleyin.

Kavram kanıtlama saldırım için test uygulaması veya yürütülebilir yerel uygulama gerekmiyor.

Çoğu test için hem cihaz tarafı uygulamaya hem de yerel bir yürütülebilir dosyaya gerek yoktur.

Testiniz cihaz üzerinde bir uygulamanın/hizmetin kullanımını içermiyorsa test-app alt dizinini silmeniz yeterlidir. Benzer şekilde, testiniz yerel bir yürütülebilir dosya kullanmıyorsa native-poc alt dizinini silin ve ardından projeyi Gradle ile senkronize edin. Proje, bu modüller mevcut olmadığında derlemeyi otomatik olarak atlayacak şekilde ayarlanmıştır.

Kavram kanıtlama saldırım ikinci bir uygulama/hizmet içeriyor

İlk olarak, ikinci uygulamanız/hizmetiniz için projenize yeni bir Modül ekleyin ve diğer APK'larda olduğu gibi bunu yazın.

Daha sonra, bu dizinin kök dizininde build.gradle öğesini düzenleyin ve copyArtifacts, assembleStsARM ve assembleStsx86 alanlarındaki talimatları izleyerek modülünüzü ekleyin. Bu işlem, derlenen APK'nın STS'nin çıkış dizinine kopyalanmasını ve testten yeni uygulamanın yüklenmesini/çağrısını sağlar.

Son olarak, projeyi Gradle senkronize edin.

STS testini gönderme

zipForSubmission görevini çalıştırın (Android Studio ile veya komut satırında Gradle ile). Projenin kök kısmındaki build dizininde codesubmission.zip adlı yeni bir dosya oluşturulmalıdır. Android Güvenlik Açığı Ödül Programı'na gönderiminizle birlikte bu dosyayı da yükleyin.