Security Test Suite Trade Federation (sts-tradefed) สร้างขึ้นจากชุดทดสอบ Android Trade Federation เพื่อทดสอบอุปกรณ์ Android ทั้งหมดสำหรับการทดสอบแพตช์ความปลอดภัยที่ไม่รวมอยู่ในชุดทดสอบความเข้ากันได้ การทดสอบเหล่านี้มีไว้สำหรับการแก้ไขที่เกี่ยวข้อง (หรือจะเชื่อมโยง) กับช่องโหว่และความเสี่ยงทั่วไป (CVE) เท่านั้น
SDK อนุญาตให้พัฒนาการทดสอบ STS ภายนอกแผนผังต้นทางของ Android โดยใช้ Android Studio หรือ Android SDK มาตรฐาน ประกอบด้วยยูทิลิตี้ทั้งหมดที่จำเป็นในการสร้างและรันการทดสอบ STS
ข้อกำหนดเบื้องต้น
- พีซีลินุกซ์ 64 บิต
- Android Studio (สามารถติดตั้งได้จากตัวจัดการแพ็คเกจของ distro ของคุณ
- จำเป็นต้องติดตั้ง เครื่องมือแพลตฟอร์ม Android (
adb
,fastboot
) และอยู่ใน$PATH
ของคุณ (เช่น คุณควรจะสามารถเรียกใช้adb
จากบรรทัดคำสั่งได้) วิธีที่ง่ายที่สุดในการติดตั้งเครื่องมือแพลตฟอร์มคือผ่านตัวจัดการแพ็คเกจของ distro- หากใช้ตัวจัดการ SDK ของ Android Studio แทนเครื่องมือแพลตฟอร์มแบบสแตนด์อโลน อย่าลืมเพิ่มไดเรกทอรี
platform-tools
ของ SDK ลงใน $PATH ของคุณ
- หากใช้ตัวจัดการ SDK ของ Android Studio แทนเครื่องมือแพลตฟอร์มแบบสแตนด์อโลน อย่าลืมเพิ่มไดเรกทอรี
- 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 มีสามส่วน:
- การทดสอบ Tradefed ฝั่งโฮสต์ที่โต้ตอบกับอุปกรณ์ผ่าน adb ในไดเรกทอรีย่อย
sts-test
- การโจมตีแบบ Proof-of-Concept แบบเนทิฟที่เป็นทางเลือกซึ่งส่งไปยังอุปกรณ์ผ่าน
adb push
และดำเนินการโดยการทดสอบฝั่งโฮสต์ในไดเร็กทอรีnative-poc
- APK ของแอปหรือบริการเสริมที่ติดตั้งลงในอุปกรณ์ผ่าน
adb install
และเปิดใช้งานโดยการทดสอบฝั่งโฮสต์ด้วย แอพหรือบริการยังสามารถมีชุดการยืนยัน JUnit ของตัวเองที่รายงานไปยังนักวิ่งฝั่งโฮสต์ ซึ่งอยู่ในไดเรกทอรีย่อยtest-app
ขั้นตอนการทดสอบ STS ทั่วไปมักจะเป็นไปตามหนึ่งในสองรูปแบบ:
การพิสูจน์แนวคิดดั้งเดิม:
- การทดสอบฝั่งโฮสต์จะพุชและเรียกใช้ไฟล์ปฏิบัติการดั้งเดิมบนอุปกรณ์
- โปรแกรมเนทีฟขัดข้องหรือส่งคืนรหัสทางออกเฉพาะ
- การทดสอบฝั่งโฮสต์จะตรวจหาข้อขัดข้อง ดูที่ logcat backtrace หรือค้นหาโค้ดทางออกเฉพาะเพื่อพิจารณาว่าการโจมตีสำเร็จหรือไม่
แอปทดสอบแบบมีเครื่องมือ:
- การทดสอบฝั่งโฮสต์จะพุช APK ที่ประกอบด้วยแอปหรือบริการไปยังอุปกรณ์
- การทดสอบฝั่งโฮสต์จะเริ่มต้นการทดสอบ JUnit ฝั่งอุปกรณ์ที่มาพร้อมกับ APK ผ่าน
runDeviceTest()
- JUnit ฝั่งอุปกรณ์จะทดสอบการแตะปุ่มและดูแอปโดยใช้ UIAutomator หรือเข้าถึงระบบ Android ในลักษณะที่เปิดเผยช่องโหว่ด้านความปลอดภัย
- ความสำเร็จหรือความล้มเหลวของการทดสอบ 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