ชุดพัฒนาชุดทดสอบความปลอดภัยของ 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 ล่าสุด

ข้อกำหนดเบื้องต้น

  • พีซีลินุกซ์ 64 บิต
  • Android Studio (สามารถติดตั้งได้จากตัวจัดการแพ็คเกจของ distro ของคุณ
  • จำเป็นต้องติดตั้ง เครื่องมือแพลตฟอร์ม 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 และดำเนินการ wrapper sts-tradefed

$ 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 มีสามส่วน:

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

ขั้นตอนการทดสอบ STS ทั่วไปมักจะเป็นไปตามหนึ่งในสองรูปแบบ:

  • การพิสูจน์แนวคิดดั้งเดิม:

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

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

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

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

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

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

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

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

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

ในที่สุด Gradle-sync โครงการ

ส่งแบบทดสอบ STS

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