Автовоспроизведение безопасности Android

Плагин AutoRepro Gradle создан на основе тестовой среды Android Trade Federation и предназначен для проверки всех устройств Android на наличие уязвимостей, описанных в бюллетене безопасности Android . Эти тесты предназначены исключительно для исправлений, связанных или которые будут связаны с распространенными уязвимостями и угрозами (CVE).

Этот плагин позволяет разрабатывать тесты Tradefed вне исходного кода Android, используя Android Studio или стандартный Android SDK. Он включает в себя все необходимые утилиты для сборки и запуска тестов Tradefed.

В основном он используется для автоматической отправки воспроизводимых прототипов в рамках программы вознаграждения за обнаружение уязвимостей в Android .

Прямая загрузка Пример

Просмотрите примеры и шаблоны AutoRepro

Предварительные требования

Инструкции предназначены для 64-битного ПК под управлением Linux.

  • Android Studio Ladybug или более поздняя версия — также может быть установлена ​​через менеджер пакетов вашего дистрибутива.
  • Инструменты платформы Android SDK ( adb , fastboot ) — необходимо установить и добавить в переменную $PATH (то есть, вы должны иметь возможность запускать adb из командной строки). Самый простой способ установить инструменты платформы — использовать менеджер пакетов вашего дистрибутива.
    • Если вы используете менеджер SDK Android Studio вместо отдельных инструментов платформы, не забудьте добавить каталог platform-tools из SDK в переменную $PATH для разработки из командной строки.
  • AAPT2 . — Также может быть установлен с помощью менеджера пакетов вашего дистрибутива.
  • Java JDK 21 или более поздняя версия — совместима с Android SDK и Gradle.

Начните использовать Android Studio

После извлечения примера или шаблона откройте каталог в Android Studio как существующий проект и дождитесь завершения синхронизации Gradle. В Android Studio доступно несколько предварительно настроенных конфигураций запуска.

Задачи Gradle:

  • assembleSubmissionSources - Собирает исходные файлы для архива с результатами обработки.
  • assembleSubmissionZip - Собирает архив с файлом для загрузки.
  • copyInvocationResultsToSubmission — Копирует результаты предыдущих вызовов Tradefed в каталог исходных файлов для автоматической проверки, чтобы упростить процесс анализа. Обратите внимание, что он содержит журналы как с хоста, так и с устройства; проверьте содержимое до или после выполнения этой операции.

Настройки запуска Android Studio для вызова функции AutoRepro:

  • autorepro_nonroot_arm64
  • autorepro_nonroot_x86_64
  • autorepro_root_arm64
  • autorepro_root_x86_64

Настройки лаунчера имеют вид autorepro_{device_root}_{device_arch} . Как правило, предпочтительнее использовать версию без root-прав, поскольку уязвимости, требующие root-доступа, менее серьезны. Однако использование root-прав для выполнения настройки или очистки может быть допустимо, если это четко задокументировано и общепринято как допустимое состояние без root-прав. Например, допустимо использовать root-права для имитации отправки текстовых сообщений на устройство, чтобы избежать необходимости использования второго устройства и нескольких SIM-карт.

Эти действия запустят Tradefed для вашего тестирования. Tradefed ожидает подключения действительного устройства, поэтому убедитесь, что оно подключено и разрешена отладка ADB.

Интеграция с агентами кодирования

Пример и шаблоны предоставляют контекстный файл AGENTS.md , совместимый с Gemini в Android Studio, Gemini CLI и другими агентами для разработки кода. Он содержит информацию о структуре отправки заданий и инструкции по использованию AutoRepro. Вы можете использовать его для:

  • Автоматически запустите AutoRepro для вашего устройства.
  • Проведите проверку кода существующей заявки на предмет изменений, которые могут ускорить принятие вашего отчета.
  • Помогите структурировать новый прототип, используя информацию об уязвимости.

Напишите тест AutoRepro.

Тест AutoRepro состоит из трех частей и трех соответствующих плагинов Gradle:

  1. Плагин Gradle id("com.android.security.autorepro.javahosttest") это единственный тест Tradefed на стороне хоста, взаимодействующий с устройством через ADB. В примере он используется в каталоге submission/hostTest/ .
  2. id("com.android.security.autorepro.apptest") это APK-файл приложения или сервиса, который устанавливается на устройство с помощью adb install и запускается тестом на стороне хоста. Приложение или сервис также может содержать собственный набор утверждений JUnit, которые передаются исполнителю на стороне хоста. В примере он используется в каталоге submission/appTest/ и .
  3. Плагин Gradle id("com.android.security.autorepro.ndktest") — необязательный прототип атаки на основе NDK, который устанавливается на устройство через adb push и выполняется тестом на стороне хоста. В примере он используется в каталоге submission/ndkTest/ .

Типичный алгоритм автоматического воспроизведения ошибок обычно следует одному из двух сценариев:

  • Приложение для инструментального тестирования:

    1. Тестирование на стороне хоста загружает на устройство APK-файл, содержащий инструментированное приложение или сервис.
    2. Тест на стороне хоста запускает тесты JUnit на стороне устройства, которые входят в состав APK-файла и запускаются с помощью функции runDeviceTest() .
    3. Тесты JUnit на стороне устройства отслеживают нажатия кнопок и наблюдают за работой приложения с помощью UIAutomator, или иным образом обращаются к API Android, выявляя уязвимости безопасности.
    4. Результаты успешного или неудачного выполнения тестов JUnit на стороне устройства возвращаются в тест на стороне хоста, который может быть использован для определения того, пройден ли тест или нет. Сообщение об ошибке должно содержать подробную информацию о причинах сбоя утверждения, а также любые конкретные объекты, значения, исключения, трассировки стека или другие артефакты, подтверждающие уязвимость.

  • NDK-прототип:

    1. Тест на стороне хоста запускает исполняемый файл Linux на устройстве.
    2. Встроенная программа завершается с ошибкой или возвращает определенный код завершения.
    3. Тест на стороне хоста проверяет наличие сбоев, анализирует трассировку стека logcat или ищет конкретный код завершения, чтобы определить, была ли атака успешной. Сообщение об ошибке должно содержать подробную информацию о причинах сбоя проверки, а также любые конкретные структуры, значения, трассировки стека или другие артефакты, подтверждающие уязвимость.

Также возможно сочетание двух подходов (например, запуск нативной программы совместно с тестами на стороне устройства). Доступны и другие фреймворки для инструментирования, такие как frida-inject . Более подробную информацию см. в справочной документации Security Test Suite и справочной документации Tradefed .

Структурирование возможности подтверждения концепции

Качественный PoC должен не просто выявлять ошибку, но и предоставлять проверяемые доказательства того, что была нарушена граница безопасности. Для достижения этой цели PoC могут следовать определенной трехэтапной схеме «провал-затем-успех»:

  1. Подготовка: Подготовьте устройство, установив необходимые приложения, загрузив файлы и убедившись, что устройство находится в требуемом состоянии непосредственно перед эксплойтом. (Использование root-прав для настройки разрешено, если это оправдано и соответствует реальному состоянию конечного пользователя).
  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);
    }
}

Для демонстрации моей концепции атаки не требуется тестовое приложение или исполняемый файл.

Для большинства тестов не потребуется одновременно и приложение для устройства, и исполняемый файл.

Если ваш тест не предполагает использования какой-либо функции, удалите ненужные подкаталоги Gradle.

В качестве экспериментального варианта атаки я использую второе приложение или сервис.

Добавьте столько подпроектов Gradle с плагинами AutoRepro, сколько вам нужно.

Отправьте тест AutoRepro

Чтобы включить результаты тестирования вашего устройства в заявку:

  • При желании можно запустить задачу clean Gradle, чтобы удалить все старые результаты выполнения тестов.
  • Запустите соответствующую конфигурацию AutoRepro, чтобы использовать Tradefed для тестирования и собрать журналы и результаты.
  • Запустите задачу copyInvocationResultsToSubmission , чтобы скопировать журналы и результаты в каталог источников отправки.

Запустите assembleSubmissionZip , чтобы создать файл submission/build/autorepro-submission.zip . Загрузите этот файл вместе с вашим отчетом в программу вознаграждения за обнаружение уязвимостей Android. Убедитесь, что вложение соответствует шаблону *autorepro-submission*.zip и загружено вместе с первоначальным отчетом. Загрузка отчетов с опозданием повлияет на нашу возможность должным образом рассмотреть ваш отчет.