Android Security AutoRepro

Trình bổ trợ AutoRepro Gradle được xây dựng dựa trên bộ kiểm thử Android Trade Federation để kiểm thử tất cả các thiết bị Android nhằm kiểm thử bản vá bảo mật đối với các lỗ hổng trong Bản tin bảo mật của Android. Các kiểm thử này chỉ dành cho những bản sửa lỗi được liên kết hoặc sẽ được liên kết với một Lỗ hổng và vấn đề rò rỉ phổ biến (CVE).

Trình bổ trợ này cho phép phát triển các kiểm thử Tradefed bên ngoài cây nguồn Android bằng Android Studio hoặc Android SDK tiêu chuẩn. Thư viện này bao gồm tất cả các tiện ích cần thiết để tạo và chạy một kiểm thử Tradefed.

Công cụ này chủ yếu được dùng để gửi các bằng chứng về khái niệm có thể tái tạo tự động cho Chương trình phần thưởng cho lỗ hổng bảo mật của Android.

Ví dụ về tính năng Tải xuống trực tiếp AutoRepro

Duyệt xem Ví dụ và mẫu AutoRepro

Điều kiện tiên quyết

Hướng dẫn này dành cho máy tính Linux 64 bit.

  • Android Studio Ladybug trở lên – Bạn cũng có thể cài đặt từ trình quản lý gói của bản phân phối.
  • Công cụ nền tảng SDK Android (adb, fastboot) – Cần được cài đặt và có trong $PATH (Tức là bạn có thể chạy adb từ dòng lệnh). Cách dễ nhất để cài đặt các công cụ nền tảng là sử dụng trình quản lý gói của bản phân phối.
    • Nếu sử dụng trình quản lý SDK của Android Studio thay vì các công cụ nền tảng độc lập, hãy nhớ thêm thư mục platform-tools của SDK vào $PATH để phát triển bằng dòng lệnh.
  • AAPT2. – Cũng có thể được cài đặt bằng trình quản lý gói của bản phân phối.
  • Java JDK 21 trở lên – tương thích với Android SDK và Gradle.

Bắt đầu sử dụng Android Studio

Sau khi trích xuất ví dụ hoặc mẫu, hãy mở thư mục trong Android Studio dưới dạng một dự án hiện có và chờ quá trình đồng bộ hoá Gradle hoàn tất. Có một số cấu hình chạy Android Studio được định cấu hình sẵn.

Tác vụ Gradle:

  • assembleSubmissionSources – Tập hợp các tệp nguồn cho tệp zip cần gửi.
  • assembleSubmissionZip – Tập hợp tệp zip để tải lên.
  • copyInvocationResultsToSubmission – Sao chép kết quả từ các lệnh gọi Tradefed trước đó vào thư mục nguồn gửi AutoRepro để hỗ trợ quy trình xem xét. Xin lưu ý rằng thông tin này chứa nhật ký của cả máy chủ lưu trữ và thiết bị; hãy xem nội dung trước hoặc sau khi chạy thông tin này.

Cấu hình chạy AutoRepro invocation Android Studio:

  • autorepro_nonroot_arm64
  • autorepro_nonroot_x86_64
  • autorepro_root_arm64
  • autorepro_root_x86_64

Cấu hình trình chạy có dạng autorepro_{device_root}_{device_arch}. Bạn nên sử dụng nonroot vì các lỗ hổng bảo mật yêu cầu quyền truy cập root ít nghiêm trọng hơn. Tuy nhiên, bạn có thể sử dụng quyền truy cập của người dùng root để thiết lập hoặc dọn dẹp, miễn là bạn ghi lại rõ ràng và được chấp nhận rộng rãi là trạng thái không phải root hợp lệ. Ví dụ: bạn có thể dùng quyền truy cập vào hệ thống để giả mạo việc gửi tin nhắn văn bản đến thiết bị nhằm tránh phải dùng thiết bị thứ hai và nhiều thẻ SIM.

Các lệnh này sẽ khởi chạy Tradefed cho kiểm thử của bạn. Tradefed chờ một thiết bị hợp lệ được kết nối, vì vậy, hãy đảm bảo rằng một thiết bị đã được kết nối và được phép gỡ lỗi ADB.

Tích hợp với các tác nhân lập trình

Ví dụ và mẫu này cung cấp một tệp ngữ cảnh AGENTS.md tương thích với Gemini trong Android Studio, Gemini CLI và các tác nhân lập trình khác. Nội dung này có ý kiến về cấu trúc của bản gửi và hướng dẫn về cách sử dụng AutoRepro. Bạn có thể dùng tính năng này để:

  • Tự động chạy AutoRepro cho thiết bị
  • Xem xét mã của một bản gửi hiện có để tìm những thay đổi có thể giúp báo cáo của bạn được chấp nhận nhanh hơn
  • Giúp cấu trúc một PoC mới dựa trên thông tin về lỗ hổng

Viết một bài kiểm thử AutoRepro

Có 3 phần trong một bài kiểm thử AutoRepro và 3 trình bổ trợ Gradle tương ứng:

  1. Trình bổ trợ Gradle id("com.android.security.autorepro.javahosttest") Kiểm thử Tradefed một phía duy nhất tương tác với thiết bị thông qua ADB. Ví dụ này sử dụng tham số này trong thư mục submission/hostTest/.
  2. Trình bổ trợ Gradle id("com.android.security.autorepro.apptest") Một tệp APK ứng dụng hoặc dịch vụ được cài đặt vào thiết bị thông qua adb install và được kiểm thử phía máy chủ lưu trữ khởi chạy. Ứng dụng hoặc dịch vụ cũng có thể chứa bộ khẳng định JUnit riêng được báo cáo cho trình chạy phía máy chủ. Ví dụ này sử dụng nó trong submission/appTest/ và thư mục.
  3. Trình bổ trợ Gradle id("com.android.security.autorepro.ndktest") Một cuộc tấn công dựa trên NDK không bắt buộc được đẩy vào thiết bị thông qua adb push và được thực thi bằng kiểm thử phía máy chủ lưu trữ. Ví dụ này sử dụng nó trong thư mục submission/ndkTest/.

Quy trình kiểm thử AutoRepro điển hình thường tuân theo một trong hai mẫu sau:

  • Ứng dụng kiểm thử đo lường:

    1. Thử nghiệm phía máy chủ đẩy một APK bao gồm một ứng dụng hoặc dịch vụ được đo lường vào thiết bị.
    2. Thử nghiệm phía máy chủ bắt đầu các thử nghiệm JUnit phía thiết bị được đi kèm với APK thông qua runDeviceTest().
    3. Các kiểm thử JUnit phía thiết bị sẽ nhấn vào các nút và theo dõi ứng dụng bằng UIAutomator, hoặc truy cập vào các API Android theo cách để lộ các lỗ hổng bảo mật.
    4. Kết quả thành công hay thất bại của các kiểm thử JUnit phía thiết bị sẽ được trả về cho kiểm thử phía máy chủ lưu trữ. Bạn có thể dùng kết quả này để xác định xem kiểm thử có đạt hay không. Thông báo lỗi phải chứa thông tin chi tiết về lý do khiến câu khẳng định không thành công và mọi đối tượng, giá trị, ngoại lệ, dấu vết ngăn xếp hoặc các cấu phần phần mềm cụ thể khác làm bằng chứng về lỗ hổng bảo mật.

  • Bằng chứng về tính khả thi của NDK:

    1. Thử nghiệm phía máy chủ sẽ đẩy và khởi chạy một tệp thực thi Linux trên thiết bị.
    2. Chương trình gốc gặp sự cố hoặc trả về một mã thoát cụ thể.
    3. Thử nghiệm phía máy chủ kiểm tra các sự cố, xem xét dấu vết ngăn xếp logcat hoặc tìm mã thoát cụ thể để xác định xem cuộc tấn công có thành công hay không. Thông báo lỗi phải chứa thông tin chi tiết về lý do khiến câu khẳng định không thành công và mọi cấu trúc, giá trị, dấu vết ngăn xếp hoặc các cấu phần phần mềm cụ thể khác làm bằng chứng về lỗ hổng.

Bạn cũng có thể kết hợp hai mẫu này (ví dụ: chạy một chương trình gốc cùng với các kiểm thử phía thiết bị). Một số khung đo lường khác, chẳng hạn như frida-inject, cũng có sẵn. Để biết thông tin chi tiết, hãy xem tài liệu tham khảo về Bộ kiểm thử bảo mật và tài liệu tham khảo về Tradefed.

Cấu trúc chứng minh tính khả thi của khái niệm

PoC chất lượng cao phải làm được nhiều việc hơn là chỉ kích hoạt một lỗi; PoC đó phải cung cấp bằng chứng có thể xác minh rằng một ranh giới bảo mật đã bị vượt qua. Để đạt được điều này, PoC có thể tuân theo một mẫu "thất bại rồi thành công" gồm 3 bước cụ thể:

  1. Thiết lập: Chuẩn bị thiết bị bằng cách cài đặt các ứng dụng cần thiết, truyền tệp và đảm bảo thiết bị ở trạng thái cụ thể cần thiết ngay trước khi khai thác. (Bạn được phép sử dụng quyền truy cập ở cấp gốc để định cấu hình nếu có lý do chính đáng và thể hiện trạng thái thực tế của người dùng cuối).
  2. Chứng minh ranh giới: Trước khi kích hoạt lỗ hổng, hãy thử hành động mục tiêu và khẳng định rằng hành động đó không thành công. Ví dụ: nếu lỗ hổng cho phép đọc một tệp được bảo vệ, trước tiên, bạn phải cố gắng đọc tệp đó và xác nhận rằng bạn nhận được lỗi "Quyền bị từ chối".
  3. Kích hoạt và xác minh: Kích hoạt lỗ hổng, sau đó lặp lại ngay hành động ở Bước 2. Trên một thiết bị dễ bị tấn công, thao tác này hiện sẽ thành công. Để xác minh điều này, bạn phải sử dụng một câu khẳng định không thành công trên một thiết bị dễ bị tấn công bằng một thông báo bắt đầu bằng tiền tố chính xác AUTOREPRO_VULNERABILITY_PROVEN:. Thông báo này phải có nội dung mô tả ngắn gọn về lỗ hổng và mọi hiện vật thu thập được (chẳng hạn như dữ liệu bị rò rỉ hoặc trạng thái không mong muốn) để chứng minh một cách chắc chắn rằng việc khai thác đã thành công.

Ví dụ:

@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);
    }
}

Cuộc tấn công chứng minh khái niệm của tôi không cần ứng dụng kiểm thử hoặc tệp thực thi gốc

Hầu hết các bài kiểm thử sẽ không cần cả ứng dụng phía thiết bị và tệp thực thi gốc.

Nếu kiểm thử của bạn không liên quan đến việc sử dụng một tính năng, hãy xoá các thư mục dự án con gradle không cần thiết.

Cuộc tấn công chứng minh khái niệm của tôi liên quan đến một ứng dụng hoặc dịch vụ thứ hai

Thêm bao nhiêu dự án con Gradle tuỳ ý bằng các trình bổ trợ AutoRepro.

Gửi bài kiểm thử AutoRepro

Cách đưa kết quả kiểm thử từ thiết bị của bạn vào nội dung gửi:

  • Bạn có thể chạy tác vụ clean của Gradle để xoá mọi lượt chạy kiểm thử cũ.
  • Chạy cấu hình chạy AutoRepro thích hợp để gọi Tradefed cho kiểm thử của bạn và thu thập nhật ký cũng như kết quả.
  • Chạy tác vụ copyInvocationResultsToSubmission để sao chép nhật ký và kết quả vào thư mục nguồn gửi.

Chạy assembleSubmissionZip để tạo tệp submission/build/autorepro-submission.zip. Tải tệp đó lên cùng với nội dung bạn gửi cho Chương trình phần thưởng phát hiện lỗ hổng bảo mật của Android. Đảm bảo rằng tệp đính kèm khớp với mẫu *autorepro-submission*.zip và được tải lên cùng với báo cáo ban đầu. Việc tải nội dung lên muộn sẽ ảnh hưởng đến khả năng xem xét báo cáo của bạn một cách thích hợp.