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'sı 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ü ve $PATH'inizde bulunması gerekir (yani adb'yi komut satırından ç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 değişkeninize eklemeyi unutmayın.
• aapt, dağıtımınızın paket yöneticisi aracılığıyla da yüklenebilir.

Not: ADB ve AAPT'yi ayarlama konusunda yardıma ihtiyacınız varsa CTS kılavuzuna göz atın.

Dikkat: STS, yalnızca 64 bit Linux makineleri resmi olarak destekler. STS SDK'sı ile yazılan testler Windows veya macOS'te Android Studio ile derlenebilir ancak bu testlerin bu platformlarda çalışmasını sağlamak kolay değildir ve bu dokümanın 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'i kullanmaya başlama

Arşivi çıkardıktan sonra, Gradle projesinin kökündeki local.properties dosyasında sdk.dir mülkünü ayarlayın ve ardından iskelet testi 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. Test, cihazın güvenlik açığı olup olmadığını belirleyemediğinde bir ASSUMPTION_FAILURE döndürür (örneğin, Assert yerine Assume kullanılarak).

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

1. sts-test alt dizinindeki adb aracılığıyla cihazla etkileşime geçen ana makine tarafında bir 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, test-app alt dizinindedir.

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

• Doğal kavram kanıtlama:

  1. Ana makine tarafı test, cihaza yerel bir yürütülebilir dosya gönderip başlatır.
  2. Yerel program kilitleniyor veya belirli bir çıkış kodu döndürüyor.
  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.

• Enstrümantasyonlu test uygulaması:

  1. Ana makine tarafı test, bir uygulama veya hizmetten oluşan bir APK'yı cihaza gönderir.
  2. Ana makine tarafı test, APK ile birlikte paketlenen cihaz tarafı JUnit testlerini runDeviceTest() üzerinden 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ındaki JUnit testlerinin başarısı veya başarısızlığı, ana makine tarafındaki teste döndürülür. Bu test, testin geçip geçmediğini belirlemek için kullanılabilir.

Bu iki kalıbın birlikte kullanılması (örneğin, cihaz tarafı 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ıtı saldırım için test uygulamasına veya yerel yürütülebilir dosyaya gerek yok

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

Testiniz cihaz üzerinde bir uygulama/hizmet 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ıtı saldırım ikinci bir uygulama/hizmet içeriyor

Öncelikle, ikinci uygulamanız/hizmetiniz için projenize yeni bir modül ekleyin ve bu modülü diğer APK'lar gibi yazın.

Ardından, bu dizinin kökündeki build.gradle dosyasını düzenleyin ve copyArtifacts, assembleStsARM ve assembleStsx86'daki talimatları uygulayarak 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 ile 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 dizinindeki build dizininde yeni bir codesubmission.zip dosyası oluşturulmalıdır. Bu dosyayı, Android Güvenlik Açıklarını Bildirenler İçin Ödül Programı'na gönderiminizle birlikte yükleyin.