Android Security AutoRepro

ปลั๊กอิน AutoRepro Gradle สร้างขึ้นบนชุดทดสอบของ Android Trade Federation เพื่อทดสอบอุปกรณ์ Android ทั้งหมดสำหรับการทดสอบแพตช์ความปลอดภัยเทียบกับช่องโหว่ในกระดานข่าวความปลอดภัยของ Android การทดสอบเหล่านี้มีไว้สำหรับการแก้ไขที่เชื่อมโยงหรือจะเชื่อมโยง กับ Common Vulnerabilities and Exposures (CVE) โดยเฉพาะ

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

โดยส่วนใหญ่จะใช้เพื่อส่งหลักฐานแนวคิดที่ทำซ้ำได้โดยอัตโนมัติสำหรับโปรแกรมให้รางวัลด้านช่องโหว่ของ Android

ตัวอย่างการทำซ้ำอัตโนมัติของการดาวน์โหลดโดยตรง

เรียกดูตัวอย่างและเทมเพลต AutoRepro

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

วิธีการนี้มีไว้สำหรับพีซี Linux 64 บิต

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

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

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

งาน Gradle

  • assembleSubmissionSources - รวบรวมไฟล์ต้นฉบับสำหรับการส่ง zip
  • assembleSubmissionZip - รวบรวมไฟล์ ZIP ที่ส่งเพื่ออัปโหลด
  • copyInvocationResultsToSubmission - คัดลอกผลลัพธ์จากการเรียกใช้ Tradefed ก่อนหน้าลงในไดเรกทอรีแหล่งที่มาของการส่ง AutoRepro เพื่อช่วยในกระบวนการตรวจสอบ โปรดทราบว่าไฟล์นี้มีบันทึกจากทั้งโฮสต์และอุปกรณ์ โปรดตรวจสอบเนื้อหาก่อนหรือหลังเรียกใช้

การเรียกใช้ AutoRepro ในการกำหนดค่าการเรียกใช้ Android Studio

  • autorepro_nonroot_arm64
  • autorepro_nonroot_x86_64
  • autorepro_root_arm64
  • autorepro_root_x86_64

การกำหนดค่า Launcher อยู่ในรูปแบบ autorepro_{device_root}_{device_arch} โดยทั่วไปแล้วควรใช้ แบบไม่รูทเนื่องจากช่องโหว่ที่ต้องใช้รูทมีความรุนแรงน้อยกว่า อย่างไรก็ตาม การใช้ รูทเพื่อทำการตั้งค่าหรือล้างข้อมูลอาจเป็นที่ยอมรับได้ตราบใดที่มีการ บันทึกไว้อย่างชัดเจนและโดยทั่วไปถือว่าเป็นสถานะที่ไม่ใช่รูทที่ถูกต้อง เช่น คุณสามารถใช้รูทเพื่อจำลองการส่งข้อความไปยังอุปกรณ์เพื่อหลีกเลี่ยงการต้องใช้อุปกรณ์เครื่องที่ 2 และซิมการ์ดหลายอัน

ซึ่งจะเปิดใช้ Tradefed สำหรับการทดสอบ Tradefed จะรอให้อุปกรณ์ที่ถูกต้องเชื่อมต่อ ดังนั้นโปรดตรวจสอบว่าได้เชื่อมต่ออุปกรณ์และอนุญาตการแก้ไขข้อบกพร่อง ADB แล้ว

การผสานรวมกับเอเจนต์การเขียนโค้ด

ตัวอย่างและเทมเพลตมีAGENTS.mdไฟล์บริบทที่ใช้ได้กับ Gemini ใน Android Studio, Gemini CLI และเอเจนต์การเขียนโค้ดอื่นๆ โดยมีเนื้อหา พร้อมความคิดเห็นเกี่ยวกับการจัดโครงสร้างการส่งและวิธีการใช้ AutoRepro คุณ สามารถใช้สิ่งนี้เพื่อทำสิ่งต่อไปนี้

  • เรียกใช้ AutoRepro สำหรับอุปกรณ์โดยอัตโนมัติ
  • ตรวจสอบโค้ดของการส่งที่มีอยู่เพื่อหาการเปลี่ยนแปลงที่จะช่วยให้รายงานได้รับการยอมรับเร็วขึ้น
  • ช่วยสร้าง PoC ใหม่โดยอิงตามข้อมูลช่องโหว่

เขียนการทดสอบ AutoRepro

การทดสอบ AutoRepro มี 3 ส่วน และมีปลั๊กอิน Gradle ที่เกี่ยวข้อง 3 รายการ ดังนี้

  1. ปลั๊กอิน Gradle id("com.android.security.autorepro.javahosttest") การทดสอบ Tradefed ด้านเดียว ของโฮสต์ที่โต้ตอบกับอุปกรณ์ผ่าน ADB ตัวอย่างใช้ในไดเรกทอรี submission/hostTest/
  2. ปลั๊กอิน Gradle id("com.android.security.autorepro.apptest") APK ของแอปหรือบริการที่ติดตั้งในอุปกรณ์ผ่าน adb install และ เปิดโดยการทดสอบฝั่งโฮสต์ แอปหรือบริการยังอาจมีชุดการยืนยัน JUnit ของตัวเองซึ่งจะรายงานไปยังโปรแกรมเรียกใช้ฝั่งโฮสต์ด้วย ตัวอย่างใช้ใน submission/appTest/ และไดเรกทอรี
  3. ปลั๊กอิน Gradle id("com.android.security.autorepro.ndktest") การโจมตีแบบ Proof-of-Concept ที่อิงตาม NDK ซึ่งไม่บังคับ ซึ่งพุชไปยังอุปกรณ์ผ่าน adb push และดำเนินการโดยการทดสอบฝั่งโฮสต์ ตัวอย่างนี้ใช้ในไดเรกทอรี submission/ndkTest/

โดยปกติแล้วโฟลว์การทดสอบ AutoRepro จะเป็นไปตามรูปแบบใดรูปแบบหนึ่งต่อไปนี้

  • แอปทดสอบแบบมีเครื่องควบคุม:

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

  • การพิสูจน์แนวคิด NDK:

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

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

การจัดโครงสร้างความสามารถในการพิสูจน์แนวคิด

PoC คุณภาพสูงต้องทำได้มากกว่าการเรียกข้อบกพร่อง แต่ควรแสดงหลักฐานที่ตรวจสอบได้ ว่ามีการข้ามขอบเขตด้านความปลอดภัย เพื่อให้บรรลุเป้าหมายนี้ PoC สามารถ ทำตามรูปแบบ "ล้มเหลวแล้วจึงสำเร็จ" 3 ขั้นตอนที่เฉพาะเจาะจงได้ดังนี้

  1. การตั้งค่า: เตรียมอุปกรณ์โดยการติดตั้งแอปที่จำเป็น พุชไฟล์ และตรวจสอบว่าอุปกรณ์อยู่ในสถานะที่เฉพาะเจาะจงตามที่จำเป็นก่อนที่จะ ใช้ช่องโหว่ (อนุญาตให้ใช้รูทสำหรับการกำหนดค่าหากมีเหตุผลอันสมควรและ เป็นตัวแทนของสถานะผู้ใช้ปลายทางที่สมจริง)
  2. พิสูจน์ขอบเขต: ก่อนที่จะทริกเกอร์ช่องโหว่ ให้ลองดำเนินการเป้าหมายและยืนยันว่าการดำเนินการล้มเหลว เช่น หากช่องโหว่ทำให้สามารถ อ่านไฟล์ที่ป้องกันได้ คุณต้องพยายามอ่านไฟล์นั้นก่อนและยืนยันว่าได้รับข้อผิดพลาด "ไม่อนุญาต"
  3. ทริกเกอร์และยืนยัน: ทริกเกอร์ช่องโหว่ แล้วทำซ้ำการดำเนินการจากขั้นตอนที่ 2 ทันที ตอนนี้การดำเนินการนี้ควรสำเร็จในอุปกรณ์ที่มีช่องโหว่ หากต้องการ ยืนยันข้อความนี้ คุณต้องใช้การยืนยันที่ล้มเหลวในอุปกรณ์ที่มีช่องโหว่โดยมี ข้อความที่ขึ้นต้นด้วยคำนำหน้าที่ตรงกันทุกประการ AUTOREPRO_VULNERABILITY_PROVEN: ข้อความนี้ต้องมีคำอธิบายโดยย่อเกี่ยวกับช่องโหว่และอาร์ติแฟกต์ที่จับได้ (เช่น ข้อมูลที่รั่วไหลหรือสถานะที่ไม่คาดคิด) เพื่อพิสูจน์ให้เห็นอย่างชัดเจนว่าการหาช่องโหว่สำเร็จ

ตัวอย่าง

@Test
public void testPoc() throws Exception {
    // 1. Setup: Prepare the device.
    setup();

    // 2. Prove the Boundary: Assert the resource is protected BEFORE the exploit.
    // This passes on all devices (safe or vulnerable) before the trigger runs.
    assertDeviceIsSecure();

    // 3. Trigger & Verify: Execute the exploit logic, then immediately repeat
    // the action from Step 2. On a vulnerable device, this action should now
    // succeed, causing assertDeviceIsSecure() to fail with an
    // AUTOREPRO_VULNERABILITY_PROVEN message.
    triggerExploit();
    assertDeviceIsSecure();
}

private void assertDeviceIsSecure() {
    try {
        String content = readProtectedFile();

        // Where possible, put the content in the assertion message.
        // Start the assertion message with "AUTOREPRO_VULNERABILITY_PROVEN:".
        Assert.fail("AUTOREPRO_VULNERABILITY_PROVEN: Successfully read protected file. Content: '" + content + "'");
    } catch (ThisVulnSpecificException e) {
        Log.i(TAG, "protected against reading protected file", e);
    }
}

การโจมตีแบบ Proof-of-Concept ของฉันไม่จำเป็นต้องมีแอปทดสอบหรือไฟล์ที่เรียกใช้งานได้

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

หากการทดสอบไม่ได้เกี่ยวข้องกับการใช้ฟีเจอร์ ให้ลบไดเรกทอรีย่อย gradle ที่ไม่จำเป็นออก

การโจมตีแบบ Proof-of-Concept ของฉันเกี่ยวข้องกับแอปหรือบริการที่ 2

เพิ่มโปรเจ็กต์ย่อย Gradle ที่มีปลั๊กอิน AutoRepro ได้มากเท่าที่ต้องการ

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

หากต้องการรวมผลการทดสอบจากอุปกรณ์เป็นส่วนหนึ่งของการส่ง ให้ทำดังนี้

  • หรือจะเรียกใช้ทาสก์ Gradle clean เพื่อลบการทดสอบเก่าก็ได้
  • เรียกใช้การกำหนดค่าการเรียกใช้ AutoRepro ที่เหมาะสมเพื่อเรียกใช้ Tradefed สำหรับ การทดสอบของคุณ และรวบรวมบันทึกและผลลัพธ์
  • เรียกใช้copyInvocationResultsToSubmissionเพื่อคัดลอกบันทึกและ ผลลัพธ์ไปยังไดเรกทอรีแหล่งที่มาของการส่ง

เรียกใช้ assembleSubmissionZip เพื่อสร้างไฟล์ submission/build/autorepro-submission.zip อัปโหลดไฟล์ดังกล่าวพร้อมกับ การส่งของคุณไปยังโปรแกรมสะสมคะแนนสำหรับช่องโหว่ของ Android ตรวจสอบว่าไฟล์แนบตรงกับรูปแบบ *autorepro-submission*.zip และอัปโหลดพร้อมกับรายงานเริ่มต้น การอัปโหลดข้อมูลที่ส่งล่าช้าจะส่งผลต่อความสามารถของเราในการตรวจสอบรายงานของคุณอย่างเหมาะสม