Android 보안 테스트 모음 개발 키트(STS SDK)

보안 테스트 모음 Trade Federation(sts-tradefed)은 Android Trade Federation 테스트 하네스를 기반으로 빌드되어 호환성 테스트 모음에 포함되지 않는 보안 패치 테스트를 위해 모든 Android 기기를 테스트합니다. 이러한 테스트는 일반적인 취약점 및 노출(CVE)과 연결되거나 연결될 예정인 수정사항에만 독점적으로 사용됩니다.

이 SDK를 사용하면 Android 스튜디오 또는 표준 Android SDK를 사용하여 Android 소스 트리 외부에서 STS 테스트를 개발할 수 있습니다. 여기에는 STS 테스트를 빌드하고 실행하는 데 필요한 모든 유틸리티가 포함되어 있습니다.

최신 STS SDK 가져오기

기본 요건

  • 64비트 Linux PC
  • Android 스튜디오(distro의 패키지 관리자에서도 설치할 수 있음)
  • Android 플랫폼 도구(adb ,fastboot)를 $PATH에 설치해야 합니다(즉, 명령줄에서 adb를 실행해야 합니다). 플랫폼 도구를 설치하는 가장 쉬운 방법은 distro의 패키지 관리자를 사용하는 것입니다.
    • 독립형 플랫폼 도구 대신 Android 스튜디오의 SDK Manager를 사용하는 경우 $PATH에 SDK의 platform-tools 디렉터리를 추가해야 합니다.
  • aapt는 distro의 패키지 관리자를 통해서도 설치할 수 있습니다.

Android 스튜디오를 사용하여 시작하기

보관 파일을 추출한 후 Android 스튜디오에서 디렉터리를 기존 프로젝트로 엽니다. 타겟 Android 기기의 아키텍처에 따라 assembleSTSARM 또는 assembleSTSx86 빌드 타겟을 실행하여 스켈레톤 테스트를 빌드합니다. runSTS 빌드 타겟을 실행하여 연결된 기기에서 스켈레톤 테스트를 실행합니다(ADB 승인 필요).

Gradle을 사용하여 시작하기

보관 파일을 추출한 후 Gradle 프로젝트의 루트에 있는 local.properties 파일에 sdk.dir 속성을 설정하고 assembleSTSARM Gradle 작업을 실행하여 스켈레톤 테스트를 빌드합니다. 빌드가 완료되면 build/android-sts/tools로 이동하고(cd 사용) 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 테스트에는 다음과 같은 세 가지 부분이 있습니다.

  1. sts-test 하위 디렉터리에서 adb를 통해 기기와 상호작용하는 호스트 측 Tradefed 테스트
  2. adb push를 통해 기기로 푸시되고 native-poc 하위 디렉터리의 호스트 측 테스트에 의해 실행되는 네이티브 개념 증명 공격(선택사항)
  3. adb install을 통해 기기에 설치되고 호스트 측 테스트로도 실행되는 선택적 앱 또는 서비스 APK. 앱 또는 서비스는 호스트 측 실행기에 보고되는 자체 JUnit 어설션 세트도 포함할 수 있습니다. test-app 하위 디렉터리에 있습니다.

일반적인 STS 테스트 흐름은 대부분 다음 두 가지 패턴 중 하나를 따릅니다.

  • 네이티브 개념 증명:

    1. 호스트 측 테스트는 기기에서 네이티브 실행 파일을 푸시하고 실행합니다.
    2. 네이티브 프로그램이 다운되거나 특정 종료 코드를 반환합니다.
    3. 호스트 측 테스트가 비정상 종료를 확인하거나, Logcat 백트레이스를 살펴보거나, 특정 종료 코드를 찾아 공격이 성공했는지 확인합니다.

  • 계측 테스트 앱:

    1. 호스트 측 테스트는 앱 또는 서비스로 구성된 APK를 기기에 푸시합니다.
    2. 호스트 측 테스트는 runDeviceTest()를 통해 APK와 함께 번들로 제공되는 기기 측 JUnit 테스트를 시작합니다.
    3. 기기 측 JUnit 테스트는 UIAutomator를 사용하여 버튼을 탭하고 앱을 보거나 보안 취약점을 드러내는 방식으로 Android 시스템에 액세스합니다.
    4. 기기 측 JUnit 테스트의 성공 또는 실패는 호스트 측 테스트에 반환되며 이는 테스트를 통과했는지 확인하는 데 사용할 수 있습니다.

두 패턴의 조합(예: 기기 측 테스트와 함께 네이티브 프로그램을 실행)도 가능합니다. frida-inject와 같은 다른 계측 프레임워크도 사용할 수 있습니다. 자세한 내용은 보안 테스트 모음 참조 문서 및 Tradefed 참조 문서를 확인하세요.

개념 증명 공격에 테스트 앱 또는 네이티브 실행 파일이 필요하지 않음

대부분의 테스트에는 기기 측 앱과 네이티브 실행 파일이 모두 필요하지는 않습니다.

테스트에 기기 내 앱/서비스가 필요하지 않은 경우 test-app 하위 디렉터리를 삭제합니다. 마찬가지로 테스트에서 네이티브 실행 파일을 사용하지 않는 경우 native-poc 하위 디렉터리를 삭제하고 프로젝트에서 Gradle 동기화를 진행합니다. 모듈이 존재하지 않는 경우 이러한 모듈 빌드를 자동으로 건너뛰도록 프로젝트가 설정됩니다.

개념 증명 공격에 두 번째 앱/서비스가 사용됨

먼저 두 번째 앱/서비스를 위해 프로젝트에 새 모듈을 추가하고 다른 APK와 마찬가지로 작성합니다.

그런 다음 이 디렉터리의 루트에서 build.gradle을 수정하고 copyArtifacts, assembleStsARM, assembleStsx86의 안내에 따라 모듈을 추가합니다. 이렇게 하면 컴파일된 APK가 STS의 출력 디렉터리에 복사되고 테스트에서 새 앱 설치/호출이 가능해집니다.

마지막으로 프로젝트에서 Gradle 동기화를 진행합니다.

STS 테스트 제출

명령줄에서 Android 스튜디오 또는 Gradle을 사용하여 zipForSubmission 작업을 실행합니다. 프로젝트 루트의 build 디렉터리에 새 파일 codesubmission.zip이 생성됩니다. Android 취약점 리워드 프로그램에 제출하는 동시에 이 파일을 업로드합니다.