ชุดพัฒนาซอฟต์แวร์สำหรับทดสอบความปลอดภัยของ Android (STS SDK)

Security Test Suite Trade Federation (sts-tradefed) สร้างขึ้นจากแพ็กเกจทดสอบของ Android Trade Federation เพื่อทดสอบอุปกรณ์ Android ทั้งหมดสำหรับการทดสอบแพตช์ความปลอดภัยที่ไม่ได้อยู่ในชุดเครื่องมือทดสอบความเข้ากันได้ การทดสอบเหล่านี้มีไว้เพื่อการแก้ไขที่มีความสัมพันธ์ (หรือจะเชื่อมโยง) กับช่องโหว่และจำนวนผู้ที่เห็นทั่วไป (CVE) เท่านั้น

SDK อนุญาตให้พัฒนาการทดสอบ STS นอกโครงสร้างแหล่งที่มาของ Android โดยใช้ Android Studio หรือ Android SDK มาตรฐาน ซึ่งรวมถึงยูทิลิตีทั้งหมดที่จําเป็นต่อการสร้างและเรียกใช้การทดสอบ STS

รับ STS SDK ล่าสุด

สิ่งที่ต้องมีก่อน

  • คอมพิวเตอร์ Linux 64 บิต
  • Android Studio (ติดตั้งได้จากเครื่องมือจัดการแพ็กเกจของดิสโทรด้วย)
  • เครื่องมือแพลตฟอร์ม Android (adb, fastboot) ต้องติดตั้งและอยู่ใน $PATH (กล่าวคือ คุณควรเรียกใช้ adb จากบรรทัดคำสั่งได้) วิธีที่ง่ายที่สุดในการติดตั้งเครื่องมือแพลตฟอร์มคือการติดตั้งผ่านตัวจัดการแพ็กเกจของ Distro
    • หากใช้เครื่องมือจัดการ SDK ของ Android Studio แทนเครื่องมือแพลตฟอร์มแบบสแตนด์อโลน อย่าลืมเพิ่มไดเรกทอรี platform-tools ของ SDK ลงใน $PATH
  • aapt ซึ่งติดตั้งผ่านตัวจัดการแพ็กเกจของ Distro ได้

เริ่มต้นใช้งาน Android Studio

หลังจากแตกไฟล์แล้ว ให้เปิดไดเรกทอรีใน Android Studio เป็นโปรเจ็กต์ที่มีอยู่ เรียกใช้เป้าหมายบิลด์ assembleSTSARM หรือ assembleSTSx86 เพื่อสร้างการทดสอบโครงกระดูก ทั้งนี้ขึ้นอยู่กับสถาปัตยกรรมของอุปกรณ์ Android เป้าหมาย เรียกใช้เป้าหมายบิลด์ runSTS เพื่อทำการทดสอบโครงกระดูกในอุปกรณ์ที่เชื่อมต่อ (ต้องให้สิทธิ์ ADB)

เริ่มต้นใช้งาน Gradle

หลังจากแตกไฟล์แล้ว ให้ตั้งค่าพร็อพเพอร์ตี้ sdk.dir ในไฟล์ local.properties ที่รูทของโปรเจ็กต์ Gradle จากนั้นเรียกใช้งาน assembleSTSARM Gradle เพื่อสร้างการทดสอบโครงร่าง หลังจากบิลด์เสร็จแล้ว คุณจะเรียกใช้การทดสอบได้โดยไปที่ (cd) build/android-sts/tools แล้วเรียกใช้ sts-tradefed wrapper

$ 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

การทดสอบ STS แบ่งออกเป็น 3 ส่วน ได้แก่

  1. การทดสอบ Tradefed ฝั่งโฮสต์ที่โต้ตอบกับอุปกรณ์ผ่าน adb ในไดเรกทอรีย่อย sts-test
  2. การโจมตีแบบพิสูจน์แนวคิดที่มีอยู่แล้ว (ไม่บังคับ) ซึ่งพุชเข้าไปในอุปกรณ์ผ่าน adb push และดำเนินการโดยการทดสอบฝั่งโฮสต์ในไดเรกทอรีย่อย native-poc
  3. APK ของแอปหรือบริการที่ไม่บังคับซึ่งติดตั้งในอุปกรณ์ผ่าน adb install และเปิดตัวโดยการทดสอบฝั่งโฮสต์ด้วย แอปหรือบริการยังอาจมีชุดการยืนยัน JUnit ของตัวเองที่รายงานไปยังโปรแกรมรันไทม์ฝั่งโฮสต์ได้ด้วย ซึ่งอยู่ในไดเรกทอรีย่อย test-app

โดยปกติแล้วขั้นตอนการทดสอบ STS ทั่วไปจะเป็นไปตาม 1 ใน 2 รูปแบบต่อไปนี้

  • การพิสูจน์แนวคิดแบบเนทีฟ

    1. การทดสอบฝั่งโฮสต์จะพุชและเปิดใช้ไฟล์ปฏิบัติการที่มาพร้อมเครื่องในอุปกรณ์
    2. โปรแกรมเนทีฟขัดข้องหรือส่งคืนโค้ดสำหรับออกที่เฉพาะเจาะจง
    3. การทดสอบฝั่งโฮสต์จะตรวจหาข้อขัดข้อง ดู Logcat Backtrace หรือมองหาโค้ดการออกที่เจาะจงเพื่อพิจารณาว่าการโจมตีสำเร็จหรือไม่

  • แอปทดสอบที่มีการวัดคุม:

    1. การทดสอบฝั่งโฮสต์จะพุช APK ที่ประกอบด้วยแอปหรือบริการไปยังอุปกรณ์
    2. การทดสอบฝั่งโฮสต์จะเริ่มต้นการทดสอบ JUnit ฝั่งอุปกรณ์ที่รวมอยู่ใน APK ผ่าน runDeviceTest()
    3. JUnit ทดสอบแตะปุ่มและดูแอปโดยใช้ UIAutomator หรือเข้าถึงระบบ Android ในลักษณะที่เปิดเผยช่องโหว่ด้านความปลอดภัย
    4. ระบบจะแสดงผลลัพธ์ของการทดสอบ JUnit ฝั่งอุปกรณ์ที่สำเร็จหรือไม่สำเร็จไปยังการทดสอบฝั่งโฮสต์ ซึ่งสามารถใช้เพื่อระบุว่าการทดสอบผ่านหรือไม่

นอกจากนี้ คุณยังใช้ทั้ง 2 รูปแบบร่วมกันได้ (เช่น การเรียกใช้โปรแกรมเนทีฟร่วมกับการทดสอบฝั่งอุปกรณ์) เฟรมเวิร์กการวัดคุมอื่นๆ เช่น frida-inject ก็มีให้ใช้งานเช่นกัน โปรดดูรายละเอียดที่หัวข้อเอกสารอ้างอิงชุดทดสอบความปลอดภัยและหัวข้อเอกสารอ้างอิง Tradefed

การโจมตีแบบพิสูจน์แนวคิดของฉันไม่จำเป็นต้องใช้แอปทดสอบหรือไฟล์ปฏิบัติการในเครื่อง

การทดสอบส่วนใหญ่ไม่จำเป็นต้องใช้ทั้งแอปฝั่งเซิร์ฟเวอร์และไฟล์ปฏิบัติการในเครื่อง

หากการทดสอบไม่ได้เกี่ยวข้องกับการใช้แอป/บริการในอุปกรณ์ ให้ลบไดเรกทอรีย่อย test-app ในทำนองเดียวกัน หากการทดสอบไม่ได้ใช้ไฟล์ปฏิบัติการแบบเนทีฟ ให้ลบไดเรกทอรีย่อย native-poc จากนั้น Gradle ซิงค์โปรเจ็กต์ ระบบจะตั้งค่าโปรเจ็กต์ให้ข้ามการสร้างโมดูลเหล่านั้นโดยอัตโนมัติเมื่อไม่มีโมดูลดังกล่าว

การโจมตีเพื่อพิสูจน์แนวคิดของฉันเกี่ยวข้องกับแอป/บริการที่ 2

ก่อนอื่น ให้เพิ่มโมดูลใหม่ลงในโปรเจ็กต์สำหรับแอป/บริการที่ 2 แล้วเขียนแอปนั้นเหมือนกับที่คุณเขียน APK อื่นๆ

ถัดไป ให้แก้ไข build.gradle ที่รูทของไดเรกทอรีนี้ แล้วเพิ่มโมดูลโดยทำตามวิธีการใน copyArtifacts, assembleStsARM และ assembleStsx86 วิธีนี้ช่วยให้มั่นใจว่าระบบจะคัดลอก APK ที่คอมไพล์ไปยังไดเรกทอรีเอาต์พุตของ STS และเปิดใช้การติดตั้ง/การเรียกใช้แอปใหม่จากการทดสอบ

สุดท้าย Gradle ซิงค์โปรเจ็กต์

ส่งการทดสอบ STS

เรียกใช้งาน zipForSubmission (ด้วย Android Studio หรือ Gradle ในบรรทัดคำสั่ง) คุณควรสร้างไฟล์ใหม่ codesubmission.zip ในไดเรกทอรี build ที่รูทของโปรเจ็กต์ อัปโหลดไฟล์ไปพร้อมกับการส่ง ไปยังโปรแกรมสะสมคะแนนช่องโหว่ของ Android