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

Android 사이트 참고

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

Security Test Suite Trade Federation(sts-tradefed)은 호환성 테스트 도구 모음에 속하지 않는 보안 패치 테스트를 위해 모든 Android 장치를 테스트하기 위해 Android Trade Federation 테스트 도구 위에 구축되었습니다. 이러한 테스트는 CVE(Common Vulnerabilities and Exposures)와 연결된(또는 연결될) 수정 프로그램에만 적용됩니다.

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

전제 조건

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

참고: ADB 및 AAPT 설정에 도움이 필요한 경우 CTS 가이드 를 참조하세요.

주의: STS는 공식적으로 64비트 Linux 시스템만 지원합니다. STS SDK로 작성된 테스트는 Windows 또는 MacOS에서 Android Studio로 빌드할 수 있지만 해당 플랫폼에서 실행하는 것은 쉽지 않으며 이 문서의 범위를 벗어납니다.

Android Studio 사용 시작하기

아카이브를 추출한 후 Android Studio에서 기존 프로젝트로 디렉터리를 엽니다. 대상 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 테스트에는 세 부분이 있습니다.

sts-test 하위 디렉터리에서 adb를 통해 기기와 상호작용하는 호스트 측 Tradefed 테스트입니다.
선택적 기본 개념 증명 공격은 adb push 를 통해 장치에 푸시되고 native-poc 하위 디렉터리의 호스트 측 테스트에 의해 실행됩니다.
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 와 같은 일부 다른 계측 프레임워크도 사용할 수 있습니다. 자세한 내용은 Security Test Suite 참조 문서 및 Tradefed 참조 문서 를 참조하세요.

내 개념 증명 공격에는 테스트 앱 및/또는 기본 실행 파일이 필요하지 않습니다.

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

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

내 개념 증명 공격에는 두 번째 앱/서비스가 포함됩니다.

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

다음으로 이 디렉터리의 루트에서 build.gradle 을 편집하고 copyArtifacts , assembleStsARM 및 assembleStsx86 의 지침에 따라 모듈을 추가합니다. 이렇게 하면 컴파일된 APK가 STS의 출력 디렉터리에 복사되고 테스트에서 새 앱을 설치/호출할 수 있습니다.

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

STS 테스트 제출

zipForSubmission 작업을 실행합니다(Android Studio 또는 명령줄의 Gradle 사용). 새 파일 codesubmission.zip 은 프로젝트 루트의 build 디렉터리에 생성되어야 합니다. Android Vulnerability Reward Program에 대한 제출과 함께 해당 파일을 업로드합니다.