Windows XP, 2003 이하의 운영체제의 경우 처음으로 로그인하는 사용자의 user-mode 애플리케이션과 함께 서비스들이 모두 세션 0에서 실행되었다. 그 중에는 상승된 권한으로 실행되는 서비스들도 존재하였고 이 서비스들은 권한 상승을 노리는 공격자들의 타겟이 되었다.
이러한 문제를 해결하고자,그리고 세션 0에서 실행되는 서비스들은 상호작용 대상에서 제외시켰다. 이로 인해 더이상 서비스들은 다른 세션에서 실행되는 사용자 애플리케이션과 상호작용 할 수 없게 되었으며, 동시에 사용자 애플리케이션에 포함된 악성 코드로부터 보호되었다. 모든 서비스들과 user-mode 드라이버들은 세션 0에서 실행되도록 분리시키고, 사용자 세션은 세션 1 이후의 세션에서 실행되도록 하였다.
적용 대상
Windows Kernel 6 이상이 탑재되는 Windows 7 이후 운영체제부터 적용
영향
Session 0에서 실행되는 서비스가 UI와 같은 상호작용 기능을 수행할 경우, 서비스는 사용자의 Windows 세션과 다른 세션에서 독립적으로 실행되고 있기 때문에 정상적으로 서비스의 동작을 확인할 수 없다.
Window 메세지 기능을 이용하여 서비스와 애플리케이션 간의 통신을 수행하는 경우, 서비스와 애플리케이션이 서로 다른 메세지 큐를 갖게 되어 정상적으로 메세지 전달이 안된다.
Mitigation
Windows Vista에 내장된 mitigation을 사용할 경우, 특수 desktop 내에서 세션 0과 사용자 간의 상호작용 가능
Windows XP compatibility mode를 사용할 경우, 전역으로 생성된 오브젝트를 이용해 세션 0에서 실행되는 서비스와 사용자 애플리케이션 간의 작업 수행
해결 방안
Client - Server 모델을 적용하여 RPC나 명명된 파이프를 사용해서 서비스와 애플리케이션 간 통신하기
CreateProcessAsUser API를 사용하여 사용자의 세션에서 프로세스를 생성하고 상호작용 하기
간단한 메세지 박스의 경우 WTSSendMessage API를 사용하여 사용자 세션에 알림 전달하기
오브젝트에 명시적으로 Local\이나 Global\ 네임스페이스를 적용하여 서비스에서 사용할 수 있도록 하기
MSDN에서는 프로세스를 간단히 말해 “실행 중인 프로그램”으로 정의하고 있다. 하나의 프로세스는 하나 이상의 스레드(thread)를 갖는데, 이 중 첫 번째로 실행된 스레드를 primary 스레드라고 부른다. 프로세스의 주소 공간에 저장된 코드가 실제로 실행되기 위해서는 이를 실행하기 위한 스레드가 필요하다. 따라서 프로세스가 실행되면 주 스레드가 생성되고, 프로세스 내 모든 스레드가 종료될 경우 프로세스도 종료된다.
Process 구성 요소
프로세스는 크게 두 개의 컴포넌트로 구성된다.
프로세스 커널 오브젝트
사용할 코드와 데이터를 수용하기 위한 주소 공간
프로세스 커널 오브젝트는 프로세스 자체가 아니다. 프로세스를 관리하기 위한 목적으로 운영체제에서 사용되는 커널 오브젝트이며, 프로세스에 대한 통계 정보를 가지는 메모리 블록이다. 따라서 프로세스 생성과 종료 과정 시 가장 처음으로 생성되고, 가장 마지막으로 삭제된다.
각 프로세스는 프로세스 별 주소 공간을 가진다. 이 주소 공간에는 프로세스의 실행에 필요한 코드와 데이터가 저장될 공간이 있으며, 실행에 사용되는 Thread Stack이나 Heap 할당을 위한 메모리 공간도 포함된다.
Process 생성 과정
프로세스 생성 시 CreateProcess API를 이용하여 새로운 프로세스를 생성할 수 있다.
BOOL CreateProcess(
[in, optional] LPCTSTR lpApplicationName,
[in, out, optional] LPTSTR lpCommandLine,
[in, optional] LPSECURITY_ATTRIBUTES lpProcessAttributes,
[in, optional] LPSECURITY_ATTRIBUTES lpThreadAttributes,
[in] BOOL bInheritHandles,
[in] DWORD dwCreationFlags,
[in, optional] LPVOID lpEnvironment,
[in, optional] LPCTSTR lpCurrentDirectory,
[in] LPSTARTUPINFOT lpStartupInfo,
[out] LPPROCESS_INFORMATION lpProcessInformation
);
// T는 사용되는 문자 타입에 따라 None(ANSI)나 W(Unicode)가 될 수 있다.
이 API는 다음의 과정으로 Process를 생성한다.
프로세스 커널 오브젝트 생성
새 프로세스를 위한 가상 주소 공간 생성
생성된 가상 주소 공간에 실행 파일 코드와 데이터, 사용되는 DLL 파일 로드
새 프로세스의 primary 스레드에 대한 스레드 커널 오브젝트 생성
primary 스레드에 의해 C/C++ 런타임 시작 함수 실행
여기서 5번 단계를 거쳐 실행된 C/C++ 런타임 시작 함수는 다음의 작업을 수행한다.
C/C++ 런타임 라이브러리 초기화: 전역변수와 Heap 초기화
코드 상에서 선언된 전역 오브젝트, static 클래스 오브젝트 생성자 호출
이렇게 초기화 과정을 모두 완료하고 난 후 애플리케이션의 진입점 함수를 호출해 본 프로그램을 시작한다.
참고. Linker와 Loader
Linker와 Loader는 운영체제의 구성 요소로 프로그램을 개발하고 실행할 때 사용되는 요소이다. Linker는 프로그램 개발 시 컴파일 단계에서 생성된 여러 오브젝트 파일과 라이브러리 파일들을 하나의 실행 파일로 결합하기 위해 사용된다. Loader는 실행 파일의 코드와 데이터 등을 프로세스의 가상 주소 공간에 로드하기 위해 사용된다.
앞서 언급된 프로세스 생성 과정 중 Linker와 Loader가 기여하는 파트는 다음과 같다.
Linker는 프로세스 생성 과정 중 5번 단계에 사용되는 C/C++ 런타임 시작 함수를 결정한다. 이 때 결정의 기준이 되는 정보가 개발된 프로그램에 대한 Subsystem 링커 스위치이다. 이 링커 스위치는 실행 파일의 형태에 따른 필요 서브시스템 정보를 가지는데, CUI 프로그램일 경우 /SUBSYSTEM:CONSOLE 링커 스위치를 가지고 GUI 프로그램일 경우 /SUBSYSTEM:WINDOWS 링커 스위치를 가진다.
프로그램 빌드 단계에서 Linker는 이 서브시스템 정보를 확인한 후 CONSOLE 링커 스위치가 설정된 경우 프로그램 내 구현된 main이나 wmain 함수를 찾고, 이 함수가 존재하는 경우 mainCRTStartup이나 wmainCRTStartup 함수를 런타임 시작 함수로 설정한다. 만일 서브시스템 정보가 WINDOWS 링커 스위치로 설정된 경우 프로그램 내 WinMain이나 wWinMain 함수가 구현되었는지 확인하고, WinMainCRTStartup이나 wWinMainCRTStartup 함수를 런타임 시작 함수로 설정한다. 이렇게 설정된 런타임 시작 함수가 프로세스 생성 단계 5번에서 실행된다.
Loader는 3번 단계를 수행하는데 핵심적인 역할을 하며, 5번 단계에서 C/C++ 런타임 시작 함수가 실행되기 전 프로그램 실행에 필요한 환경을 구성하는 역할을 한다.
이 때에도 마찬가지로 프로그램의 서브시스템 정보를 확인한다. Windows의 PE 파일 헤더의 필드 중 subsystem 정보를 얻을 수 있는데, 이를 이용하여 실행에 필요한 서브시스템 정보를 얻을 수 있다. 그리하여 서브시스템 정보가 CONSOLE일 경우 프로그램 실행 전에 콘솔 윈도우를 생성하거나 기존에 열려있던 콘솔 윈도우를 사용하여 실행에 필요한 환경을 구성한다. 서브시스템 정보가 WINDOWS라면 곧바로 애플리케이션을 로드한다.
Process 종료 과정
프로세스는 여러 요인에 의해 종료될 수 있다. 정상적으로 프로그램이 시작하고 끝나면서 종료되는 경우도 있겠지만, 프로그램 내에서 호출된 ExitProcess 함수에 의해 종료될 수도 있고 다른 프로세스에서 호출된 TerminateProcess 함수에 의해서도 종료될 수 있다. 이 중 프로그램의 진입점 함수가 반환되면서 프로그램이 graceful 종료되는 상황에 대해 설명한다.
프로세스의 실행 과정을 보면 프로세스가 생성된 후 런타임 시작 함수가 호출되고, 런타임 시작 함수의 실행 과정에서 프로그램의 진입점 함수가 호출되며 프로그램이 실행되는 것을 알 수 있다. 그렇기에 함수의 실행 과정을 고려했을 때 진입점 함수가 반환 된 뒤 프로그램의 제어가 다시 런타임 시작 함수로 돌아올 것임을 알 수 있다. 그렇기에 진입점 함수가 반환 된 후 런타임 시작 함수로 제어가 돌아간 이후 단계부터 정리하였다.
진입점 함수가 반환되면 진입점 함수의 반환값을 인자로 갖는 C/C++ 런타임 라이브러리의 exit 함수를 호출한다. exit 함수는 다음의 작업을 수행한다.
_onexit 함수를 통해 프로그램 종료 시 호출되도록 등록해둔 루틴 수행
모든 전역 클래스 오브젝트와 static C++ 클래스 오브젝트의 파괴자 호출
진입점 함수의 반환값(종료 코드)을 인자로 갖는 ExitProcess 함수 호출
마지막 과정인 ExitProcess 함수를 호출하고 나면 운영체제에 의해 프로세스가 종료된다.
프로세스가 종료된 뒤에는 다음의 작업이 수행된다.
프로세스 내에 남아있는 스레드 종료
프로세스에 의해 할당되었던 모든 사용자 오브젝트와 GDI 오브젝트 삭제
프로세스에서 사용된 모든 커널 오브젝트에 대한 사용 카운트 1 감소
프로세스의 종료 코드를 STILL_ALIVE에서 반환된 종료 코드로 변경
프로세스 커널 오브젝트의 상태를 시그널 상태로 변경
프로세스 커널 오브젝트의 사용 카운트 1 감소
여기서 6번 단계 이후 프로세스 커널 오브젝트의 사용 카운트가 0이 되어야 프로세스의 커널 오브젝트까지 삭제되면서 프로세스의 모든 정보가 온전히 파괴된다. 만약 여전히 다른 프로세스에서 해당 프로세스의 정보를 이용하고자 프로세스 커널 오브젝트에 대한 핸들을 사용 중이라면 사용 카운트가 0이 되지 않아 곧바로 파괴되지 않을 것이다.
커널 오브젝트는 커널에 의해 할당된 메모리 블록으로, 커널에 의해서만 접근 가능한 객체이다. 이를 이용하여 시스템에서 사용되는 여러 자원들을 효과적으로 관리할 수 있다.
커널 오브젝트는 파일 오브젝트, Mutex 오브젝트, Process 오브젝트 등 여러 종류의 형태로 존재한다. 각 오브젝트는 보안과 안정성을 위해 커널에 의해서만 접근 가능하며, 이를 생성 및 조작하기 위해서는 Windows에서 제공하는 API를 이용해야 한다.
각 커널 오브젝트는 형태에 따라 서로 다른 정보를 가진다. 그럼에도 불구하고 다음의 두 정보는 커널 오브젝트 마다 공통적으로 사용된다.
1. 사용 카운트
: 해당 커널 오브젝트를 사용 중인 프로세스의 수. 0 이상의 정수값을 갖는다.
커널 오브젝트를 최초 생성할 경우 사용 카운트값으로 1을 갖는다.
커널 오브젝트를 사용하는 프로세스의 수가 증가할 때마다 사용 카운트값이 1씩 증가한다.
커널 오브젝트의 사용을 종료(프로세스의 종료 또는 CloseHandle(hObj) 호출)할 때마다 사용 카운트 값이 1씩 감소한다.
커널 오브젝트의 사용 카운트값이 0이 되면 해당 오브젝트가 삭제된다. (해당 커널 오브젝트에 대한 사용이 모두 종료되어야 삭제된다.)
2. 보안 디스크립터(SECURITY_ATTRIBUTES 구조체)
: 커널 오브젝트에 대한 소유자, 접근 권한에 대한 정보
커널 오브젝트와 유저 오브젝트/GDI 오브젝트를 구분하는 팁으로, 오브젝트 생성 API에 보안 특성을 지정하는 매개변수가 존재하는지를 확인하는 방법이 있다고 한다.
Handle & Process Handle Table
Windows API를 이용해 커널 오브젝트를 생성하는 데 성공하면 커널 오브젝트를 조작하는 데 사용 가능한 핸들(handle) 값을 얻을 수 있다. 이 핸들값을 다른 Windows API 매개변수로 전달하여 커널 오브젝트를 사용할 수 있다.
생성된 커널 오브젝트에 대한 핸들값은 각 프로세스마다 고유하다. 각 프로세스는 자신만의 독립된 프로세스 핸들 테이블을 갖기 때문에, 프로세스 내에서 생성된 핸들값은 해당 프로세스 내에서 생성된 모든 스레드에서 사용 가능하지만 다른 프로세스에서는 사용할 수 없다. 다음은 프로세스 핸들 테이블의 구조이다.
Process Handle Table
커널 오브젝트에 대한 핸들값은 프로세스 핸들 테이블에 매핑된 인덱스값과도 관련이 있는데, 가령 프로세스 A에서 프로세스 핸들 테이블 내 인덱스 2번을 가리키는 핸들값을 프로세스 B에서 동일하게 사용할 경우 프로세스 B의 프로세스 핸들 테이블 내 인덱스 2번에 다른 타입의 커널 오브젝트가 참조되어 있으면 잘못된 오브젝트를 참조하게 된다.
How to share Handles
앞서 설명한 바와 같이 두 프로세스 간 커널 오브젝트를 공유해야 할 경우 단순히 핸들값을 공유하는 방법은 옳지 않다. 그렇기에 이후 내용에서 서로 다른 두 프로세스 간에 커널 오브젝트를 공유하기 위한 방안을 정리하였다.
1. Kernel Object Handle 상속
이 방법은 커널 오브젝트를 공유하고자 하는 두 프로세스가 Parent - Child 관계일 경우 사용 가능하다. 이 방법은 크게 다음과 같은 단계로 진행된다.
Parent process에서 상속하고자 하는 핸들 설정: 핸들 생성 또는 핸들 속성 변경 시
Child process 생성 시 child process에게 핸들을 상속할 것인지 유무 설정
위 두 단계를 거치고 나면 Parent process의 process handle table 내 상속된 핸들에 대한 레코드가 새로 생성된 Child process의 process handle table 내 동일한 인덱스로 복사된다.
이러한 메커니즘으로 인해 핸들 상속 후 Parent process에서 대상 커널 오브젝트에 대해 사용 중이던 핸들의 사용을 종료하더라도, Child process의 process handle table 내에 커널 오브젝트에 대한 정보가 남아있으므로 Child process에서 상속된 핸들을 통해 여전히 커널 오브젝트에 접근할 수 있다. 또한 상속을 통해 대상 커널 오브젝트를 사용하는 프로세스의 수가 1 증가하였으므로 대상 커널 오브젝트의 사용 카운트값도 1 증가하게 된다.
2. Kernel Object의 이름 이용
이 방법은 커널 오브젝트 생성 시 고유한 이름을 부여하여, 다른 프로세스에서 커널 오브젝트의 이름을 이용해 대상 오브젝트에 대한 핸들을 얻는 방식이다. 이 방식이 가능한 이유는 커널에 의해 할당된 커널 오브젝트들은 타입에 상관없이 동일한 네임스페이스를 공유하기 때문에 서로 다른 프로세스라 하더라도 공유 중인 네임스페이스 내 정의된 커널 오브젝트의 이름을 이용하여 공유할 수 있다. 따라서 하나의 네임스페이스 내에서 명명되는 커널 오브젝트들은 고유한 이름을 가져야 하며, 다른 타입의 커널 오브젝트라 하더라도 서로 다른 이름을 가져야 한다.
만일 명명하고자 하는 커널 오브젝트의 이름이 이미 네임스페이스 내에서 사용 중인 경우 커널 오브젝트의 생성은 실패할 것이다. 이러한 메커니즘을 악용하면, 공유 중인 네임스페이스를 통해 공격 대상 프로세스에서 사용할 커널 오브젝트의 이름을 수집한 후 미리 해당 이름을 갖는 커널 오브젝트를 생성하여 공격 대상 프로세스의 정상 구동을 방해하는 공격(DoS 공격의 일종)에 취약해진다.
따라서 이를 막고자 Private 네임스페이스를 사용하여, 다른 프로세스에서 사용 중인 이름과 충돌되거나 사용되는 이름이 탈취되는 것으로부터 안전해질 수 있다. 이 때 Boundary descriptor를 함께 사용하여 private 네임스페이스에 대한 접근 권한을 설정하는 것으로 private 네임스페이스 자체에 대한 보안을 강화할 수 있다.
추가로, 터미널 서비스를 사용하는 경우에는 모든 클라이언트 세션으로부터 접근 가능한 Global 네임스페이스가 있고, 각 클라이언트 세션별 고유 네임스페이스(Local)가 존재한다. 기본적으로 터미널 서비스에서 사용되는 커널 오브젝트는 Global 네임스페이스 내 명명되고, 각 터미널 서비스 내 애플리케이션에서 사용되는 커널 오브젝트는 Local 네임스페이스에 명명된다. 그렇기 때문에 서로 다른 클라이언트 세션에서 동일한 애플리케이션을 실행하여도 충돌이 발생하지 않을 수 있다.
3. Kernel Object Handle 복사
이 방법은 source process의 process handle table 내에 기록된 커널 오브젝트에 대한 참조를 target process의 process handle table로 복사하는 것이다. 이를 위해 DuplicateHandle API를 사용하면 간편하게 복사할 수 있다.
이 함수를 호출하면 공유하고자 하는 target process에서 사용 가능한 커널 오브젝트의 핸들값을 얻을 수 있다. 만일 source process에서 위 함수를 사용하여 target process를 위한 핸들값을 구했다면 IPC와 같은 프로세스 간 통신 방법으로 target process에 핸들값을 전달하여 커널 오브젝트를 사용하도록 할 수 있다.
Frida는 Dynamic Binary Instrumentation(DBI) 프레임워크이며, Windows, mac OS, iOS, Android 애플리케이션을 동적으로 분석할 수 있게 해주는 도구이다. Frida는 함수를 후킹하여 해당 함수의 동작을 분석하거나, 다른 동작을 수행하도록 코드를 덮는 등의 작업을 할 수 있게 해준다. Frida는 크게 두 가지 구성 요소로 이루어진다. 안드로이드 기기 내에 설치 후 열어두어야하는 Frida Server와, Local host에 설치하여 후킹 코드를 전달하고 후킹 결과를 확인할 수 있도록 하기 위한 Frida 클라이언트로 구성된다.
이번 샘플로 사용한 악성 앱의 경우 MobSF와 같은 악성 애플리케이션 분석 프로그램으로 분석할 경우 악성 행위가 제대로 탐지되지 않는 특징을 가진다. multidex 애플리케이션의 특징을 이용하여 악성 코드를 별도의 파일로 분리하고 암호화 시켜두었기 때문이다.
그 후 암호화되지 않은 classes.dex 파일을 이용하여 애플리케이션을 실행하고, 실행된 dex를 이용하여 암호화된 dex 파일의 내용을 복호화해 실행한다. 복호화된 dex 파일을 분석할 경우 곧바로 확인할 수 있겠지만 이러한 특징을 가지고 있기 때문에 복호화된 dex 파일의 내용을 획득하지 못하면 실제로 어떤 악성 행위를 행하는지 파악하기 어렵다.
그렇다면 이를 해결하기 위해 실제 모바일 기기에 설치 후 행위 기반의 동적 분석을 진행하면 되지 않느냐라고 말할 수 있다. 그러나 이 샘플을 기기에서 실행할 경우 Root 탐지, Emulator 탐지, ADB 탐지 등 다양한 탐지 메커니즘에 의해 곧바로 프로그램이 종료된다. 그렇기에 동적 분석을 위해서는 이러한 탐지 메커니즘을 우회하는 작업을 선행해야만 한다.
2. Frida
탐지 메커니즘을 우회하기 위해 유명한 동적 분석 도구인 Frida를 사용할 것이다. 이를 사용하면 코드 내 특정 함수를 원하는 대로 변경하여 실행 흐름을 조작할 수 있다. 도구의 이러한 특징을 이용하여, 프로그램 내에서 동적 분석 탐지를 위해 사용되는 코드를 확인하고 실행 흐름에 영향을 미치는 핵심 코드를 조작한다면 프로그램이 종료되지 않도록 만들 수 있다.
샘플 APK는 안드로이드 환경에서 실행되는 애플리케이션이기 때문에 Frida에서 제공하는 Java 관련 API을 주로 사용할 것이다. 그 중 Java.use()를 사용하면 현재 로딩된 클래스의 wrapper를 얻을 수 있어 매우 손쉬운 후킹이 가능하다. 여기서 로딩된 클래스에만 접근할 수 있다는 부분이 핵심인데, 이번 샘플의 경우 앱이 실행된 후 복호화 작업이 끝나야 앱의 구성 요소가 로드되기 때문에 처음부터 앱의 구성 요소에 접근할 수 없다. 현재 초점을 두고 있는 탐지 메커니즘 역시 이 암호화된 dex 파일 내에 위치해있다. 따라서 어느 시점에 복호화 작업이 끝나는 지를 파악하여 이 시점을 먼저 가로챈 다음, 후킹하고자 하는 탐지 메커니즘에 접근하는 방식을 사용할 것이다.-> 보고서 작성 당시 이렇게 생각하고 3번의 과정을 분석하였는데, 막상 분석하고 난 후 frida 스크립트를 작성하려고 하니 jadx 상에서 보이는 클래스나 메서드의 이름이 jadx에서 임의로 붙여둔 이름이라 이를 명확히 가리켜 해당되는 wrapper를 가져올 수 없었다. 따라서 범용적으로 사용되는 Java나 android 라이브러리가 detection code에서 사용되는 시점을 후킹하여 원하는 작업을 하도록 하였다. (이 부분에 대한 분석은 이어지는 4번에서 확인할 수 있다.)
3. Detailed Analysis: Decryption Process
프로그램이 시작되는 파일을 찾기 위해 AndroidManifest.xml 파일을 확인하면, application 태그의 name 속성으로 com.lzsEsq.dykSgp.jhvqZx.pupsPVlBod라는 이름의 클래스가 적혀있는 것을 확인할 수 있다.
이를 통해 com.lzsEsq.dykSgp.jhvqZx.pupsPVlBod 클래스부터 분석을 시작하면 될 것이라는 것을 알 수 있다. 이 파일에서 한 가지 더 확인할 수 있는 부분은 entry 클래스가 속한 패키지명은 com.lzsEsq.dykSgp.jhvqZx 인데, AndroidManifest.xml 파일에 기록된 패키지명은 com.ldjSxw.heBbQd 로 차이를 보인다는 것이다.
암호화되어있지 않은 classes.dex의 소스 코드는 jadx를 이용하여 곧바로 확인할 수 있다. 파일 내용을 확인하면 앞서 AndroidManifest.xml 파일에서 보았던 entry 클래스 pupsPVlBod를 찾을 수 있다.
이 클래스는 메세지 수신을 위한 handler를 가진다.
본격적인 분석 시작을 위해 이 클래스의 onCreate 메서드를 확인하였다.
onCreate 메서드에서는 3개의 서로 다른 함수를 호출한다. 분석 결과, 이 중 첫 번째로 호출되는 함수 m19a가 주된 실행을 담당하였다.
m19a 함수는 base context와 com.ldjSxw.heBbQd.MainApplication 클래스에 대한 인스턴스를 인자로 하는 attach 메서드를 호출한다. 이로 인해 본 클래스 내에 정의된 attachBaseContext메서드가 호출된다. 그리고 이 attachBaseContext 메서드에서 대부분의 작업이 진행된다.
attachBaseContext 메서드는 크게 다음과 같은 작업을 수행한다.
복호화된 파일이 저장될 폴더 초기화
암호화된 파일 복호화
신규 폴더로 apk 파일 복사
이 과정에서 신규로 저장될 파일들은 com.ldjSxw.heBbQd.MainApplication_{appVersion}/app 폴더에 위치하게 될 것임을 알 수 있으며, 실제 디바이스 내에서 확인했을 때에도 /data/data/com.ldjSxw.heBbQd.MainApplication_null/app 폴더 내에 위치하였다.
위 과정에서 dexDir 경로가 존재하지 않을 경우 m9k 함수를 실행시키는데, 이 과정에서 암호화된 dex 파일에 대한 복호화 과정을 확인할 수 있다.
m9k 함수에서 주로 수행하는 작업은 다음과 같다.
새롭게 애플리케이션 파일이 위치할 경로 내에 있는 폴더 및 파일들을 모두 삭제한다. 프로그램이 실행될 때 실제로 사용될 경로이기 때문에 다른 파일의 간섭을 최소화하기 위한 조치로 보인다.
인증서 관련 파일을 제외한 나머지 파일들 중, classes.dex 파일이 아닌 dex 파일을 복호화하여 신규 위치에 저장한다. (m10j method)
classes.dex 파일과 인증서 관련 파일이 아닌 나머지 파일을 신규 위치에 저장한다.
여기서 복호화에 사용되는 m10j 메서드를 따라가면, pupsPVlBod클래스와 함께 존재하던 ymcBssEDD클래스의 decrypt메서드가 사용되는 것을 확인할 수 있다.
decrypt 함수의 세부 구조는 libset.so 파일에 native 라이브러리로 구현되어 있어 별도의 분석이 필요하다. 이 라이브러리를 분석할 경우 복호화 키를 얻을 수 있는데, 이 부분은 2.3.1 파트에서 다뤘기 때문에 넘어간다.
이러한 일련의 과정으로 암호화된 dex 파일을 복호화하고 apk 파일 내 나머지 파일들을 신규 위치로 이동하여 실행할 준비를 마치게 된다.
다시 m19a 메서드로 돌아오면, 앞서 정리한 과정을 수행하고 기타 Field의 값을 획득한 후 마지막에 f1302m으로 빈 메시지를 전송한다. f1302m은 분석 초기에 확인하고 넘어갔던 메세지 수신 handler이다.
f1302m으로 메시지를 전송하면 정의해둔 handleMessage메서드가 실행된다. 이 코드에서는 handleMessage 메서드를 다음과 같이 정의하여 메세지를 수신할 경우 f1304o의 onCreate메서드가 호출되도록 하였다. f1304o은 m19a 메서드의 초반에서 정의한 대로 com.ldjSxw.heBbQd.MainApplication의 클래스 인스턴스를 가진다. 결과적으로 m19a 메서드에서 메세지를 보내는 행위는 com.ldjSxw.heBbQd.MainApplication 클래스가 실행되게 만드는 결과를 낳는다.
앞서 AndroidManifest.xml 파일을 확인하며 entry 클래스의 패키지명과 본 apk 파일의 패키지명이 달랐던 것을 기억하는가? 그 때 확인하였던 apk 파일의 패키지명은 메세지를 보내 실행되도록 만드는 클래스의 패키지명과 일치하며, 이러한 점들을 미루어 생각했을때 본격적으로 앱의 구성 요소가 로드될 것임을 짐작할 수 있다. 따라서 MainApplication으로 메세지를 보내는 sendEmptyMessage 함수가 호출되는 시점이 dex 파일의 복호화가 완료된 지점일 것이다.
4. Detailed Analysis: Detection Process
AndroidManifest.xml 파일 내 기재된 바에 의하면 샘플 APK는 IntroActivity에서 시작한다.
이 IntroActivity는 BaseActivity를 상속받는데, 이러한 이유로 프로그램이 시작하면 BaseActivity의 onCreate 메서드가 실행되고, 그 후에 IntroActivity의 onCreate 메서드가 실행된다.
아래는 BaseActivity의 onCreate 메서드이다. 이 메서드는 실행되자마자 m47k 메서드를 실행하고 그 결과값에 따라 프로그램을 종료시킨다. 종료 시 반환하는 문자열로 Rooted가 사용되는 것을 통해 루트 탐지 부분일 것으로 생각할 수 있다. 실제로 앱을 에뮬레이터 상에서 실행하였을 때 루트 상태의 에뮬레이터를 사용할 경우 곧바로 종료된다.
이에 따라 탐지 우회 방안을 찾기 위해 m47k 메서드에서 사용되는 각 함수를 하나씩 분석하였다.
Locale Detection: 시스템 언어 설정을 확인하여 한국어를 사용하는 기기에서만 앱이 실행되도록 하는 코드이다. 이를 통해 한국어 사용자를 대상으로 악성 행위를 수행하도록 하고 있음을 알 수 있다.
Root Detection: 다음의 두 함수를 이용하여 루팅된 기기에서 실행되고 있는지 확인한다. 이를 위해 루팅된 기기에서 주로 발견되는 Build Tag 내 test-keys 키워드가 포함되어있거나, Superuser.apk 패키지가 설치되었는지 여부를 확인하고 있다.
Emulator Detection: 에뮬레이터 상에서 앱이 실행되고 있는지를 확인하기 위해 앱이 실행중인 기기 내 /proc/tty/drivers 파일 내용을 확인한다. 그 중에서도 QEMU 기반의 Android 가상 환경에서 사용되는 goldfish kernel을 사용하는 에뮬레이터를 대상으로 탐지하고 있다.
ADB Detection: Android의 Secure system setting 내 속성 중 adb_enabled 속성값을 확인하여 adb 사용중인지에 대해 확인한다.
VPN Detection: 에뮬레이터에서 사용 중인 네트워크 인터페이스 중 tun0이나 ppp0과 같은 VPN에서 주로 사용되는 인터페이스명이 존재하는지 확인한다.
HTTP Proxy Detection: Proxy를 사용할 경우 http.proxyHost와 http.proxyPort 속성에 각각 proxy 설정값이 부여된다. 그렇기 때문에 이 값이 설정되었는지 여부를 이용하여 proxy 사용 여부를 확인한다.
5. Detection Bypass
앞서 확인한 각 탐지 메커니즘에 대해 다음과 같은 Frida 스크립트를 작성하였다. Frida에서 API로 지원하는 언어 중 Javascript를 사용하였으며, 후킹하고자 하는 대상인 Android 앱이 Java를 기반으로 작성된 프로그램이기 때문에 Frida API 중 Java Instrumentation을 주로 사용하였다.
스크립트 작성 시 decompile 특성 상, 프로그램 작성자에 의해 명명된 함수의 원본 함수명을 찾는데 어려움이 있다. 따라서 주로 android나 java 라이브러리에 정의된 함수의 이름을 이용하여 이를 후킹하는 방식을 사용하였다.
Locale Detection: getLanguage 함수는 String 타입으로 현재 시스템에 설정된 언어를 반환한다. 그렇기 때문에 이를 hooking하여 어떤 시스템에서도 한글 설정이 되어 있는 것과 같이 인식하도록 반환값을 “ko”로 고정되게 만들었다.
Root Detection 1: java 라이브러리 method인 contains의 반환값을 hooking하여 탐지하고자 하는 값이 포함되지 않은 것으로 처리되도록 하였다. 이 때 루트 탐지에 사용된 값이 test-keys이므로, 이 값으로 비교할 경우에만 우회 코드가 동작하도록 하기 위한 조건을 함께 설정하였다.
Root Detection 2: Superuser.apk 가 존재하는지를 검사하기 위해 File 클래스의 생성자를 이용하여 검사할 경로의 파일을 불러온다. 이를 특징으로 삼아, /system/app/Superuser.apk 경로를 File 생성자의 인자로 넘기며 호출하는 순간을 hooking하였다. 여기서는 탐지할 경로를 없을 만한 파일의 경로로 설정하여, File 클래스가 존재하지 않는 파일의 경로를 조사하도록 하였다.
Emulator Detection: indexOf method 사용 중 비교 대상 문자열로 goldfish를 사용하는 경우에만 해당 문자열이 포함되지 않았음을 나타내는 결과인 -1을 반환하도록 하였다.
ADB Detection: Settings.Secure 클래스 내 getInt 메서드를 사용하여 adb_enabled 속성값을 조회하는 경우는 탐지를 위한 과정 중 사용하는 경우가 유일할 것으로 생각되어, adb_enabled 속성값 조회 시 항상 0을 반환값으로 가지도록 하였다.
VPN Detection: tun0과 ppp0 문자열과 비교하는 경우가 흔히 존재하지 않을 것으로 생각되어, 이를 다른 문자열과 비교하기 위해 equals 메서드의 인자로 사용하는 경우를 후킹하여 일치하지 않음을 나타내는 false를 반환값으로 가지도록 하였다.
Proxy Detection: System.getProperty 메서드를 이용해 http.proxyHost나 http.proxyPort 속성값을 조회하는 경우를 후킹하여 두 경우에 대해 null을 반환값으로 가지도록 하였다. 이를 통해 실제 proxy를 사용중이더라도 정상적인 속성값을 조회하지 못해 proxy가 사용중인지 알 수 없도록 하였다.
