ชุดพัฒนาซอฟต์แวร์สำหรับทดสอบความปลอดภัยของ 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 PC 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 ประกอบด้วย 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 ได้ด้วย โปรดดูรายละเอียดที่ เอกสารอ้างอิงชุดทดสอบความปลอดภัย และ เอกสารอ้างอิงที่มีการเทรด

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

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

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

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

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

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

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

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

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