[iOS App 진단] 12강 - 탈옥 탐지 우회(실습4)

가. 탈옥(Jailbreak) 이란?

- iOS의 샌드박스 제한을 풀어 서명되지 않은 코드를 모바일 디바이스에서 실행되게 하도록 하는 것을 말함.

- 탈옥된 기기에서의 사용자는 최고 권한을 얻기 때문에 앱(App)을 분해하여 정밀분석할 수 있고, 분석한 내용을 토대로 보안기능을 우회할 수 있음.
- 보안기능이 우회될 경우 모바일 디바이스에 저장된 사용자 개인정보뿐만 아니라 시스템 접근 권한까지 획득할 수도 있음.

 

나. 대응방법

아래의 글을 참고하여 탈옥된 디바이스에서 앱이 실행되지않게 하고, 탈옥 탐지기능을 우회할 수 없도록 디버깅을 방지하는 기능을 적용한다.

[Mobile App 취약점 진단/iOS App 진단] - [iOS App 진단] 12강 - 탈옥 탐지 우회(이론 및 대응방법)

[iOS App 진단] 12강 - 탈옥 탐지 우회(이론 및 대응방법)

 

다. DVIA-v2 앱을 통한 실습

1. 분석 대상 앱 실행

- 탈옥탐지 우회 실습을 위해 DVIA-v2 앱을 실행한다.

 

※ DVIA-v2 어플이 설치되어있지 않은 사람은 아래의 글을 참고하여 앱을 설치하길 바란다.

2022.07.01 - [Mobile App 취약점 진단/iOS App 진단] - [iOS App 진단] 04강 - 진단 대상 설치

[iOS App 진단] 04강 - 진단 대상 설치

 

- 메인메뉴 좌측 상단 메뉴 클릭 → Jailbreak Detection 클릭 → Jailbreak Test 4 클릭

- 현재 탈옥된 기기를 사용하고 있다는 "Device is Jailbroken, Exiting !" 메시지가 출력되며 앱이 강제 종료된다.

- 본글에서는 탈옥된 기기를 사용하더라도 위 메시지가 출력되지 않고 강제종료되지 않도록 탈옥탐지 기능을 우회해 볼 것이다.

 

2. 바이너리 파일 추출

- 바이너리 파일을 변조하기 위해서는 앱내부에 존재하는 바이너리 파일을 추출해내야 한다.

- 3uTools Files에서 Applications(User) 클릭 또는 탐색창에 /var/Containers/Bundle/Application 입력한다.

- 분석 대상 앱 이름과 동일한 폴더를 더블클릭한다.

 

- Size 클릭하여 파일을 크기순으로 정렬한다.

- 폴더를 제외하고 크기가 제일 큰 파일이 바이너리 파일이다.

 

-  바이너리 파일을 우클릭한뒤 Export 버튼을 눌러 PC로 추출한다.

 

3. ASLR 적용여부 확인

- 바이너리 파일을 분석하기 위해서는 ASLR이 적용되어 있지는 확인하여야 한다.

* ASLR(Address Space Layout Randomization, 주소 공간 배열 무작위화) : 메모리 손상 취약점 공격을 방지하기 위한 기술로, 프로그램이 실행될 때마다 메모리주소가 랜덤으로 변경된다.

- 아래의 글을 참고하여 앱에 ASLR이 적용되어 있는지 확인한다.

2023.10.03 - [Mobile App 취약점 진단/iOS App 진단] - 바이너리 ASLR 적용유무 확인방법 - otool

바이너리 ASLR 적용유무 확인방법 - otool

- 확인결과 DVIA-v2 바이너리 파일에는 ASLR이 적용되어 있는 것을 알 수 있다.

 

4. 바이너리 파일 분석

- 아래의 과정을 따라하여 추출한 바이너리 파일을 기드라(Ghidra)를 통해 분석한다.

※ 기드라가 설치되어 있지 않은 사람은 아래의 글을 참고하여 설치하길 바란다.

2022.06.28 - [Mobile App 취약점 진단/iOS App 진단] - [iOS App 진단] 03강 - 진단 도구 설치

[iOS App 진단] 03강 - 진단 도구 설치

 

- File 클릭 → New Project 클릭 → Non-Shared Project 선택 → Next 클릭

 

- Project Directory 경로지정 → Project Name 입력 → Finish 클릭 → File 클릭 → Import File 클릭

* Project Directory : 프로젝트 저장 경로.

* Project Name : 프로젝트 이름.

 

- 위에서 추출한 바이너리 파일 선택 → Select File To Import 버튼 클릭

 

- 설정내용을 아무것도 건드리지 않고 OK 버튼 클릭

 

- 추가된 바이너리 파일(DVIA-v2)을 더블클릭 → Yes 버튼 클릭

 

- 설정내용을 아무것도 건드리지 않고 Analyze 버튼 클릭 → 분석이 종료될때까지 대기(우측 하단에 진행률이 표시됨).

※ 분석이 종료되면 알림 창이 발생한다. 분석이 완료되지 않으면 결과가 달라질 수 있으므로 완료될 때까지 기다린다.

 

- Search 클릭 → For Strings 클릭

 

- 'Jailbreak Test 4' 클릭 시 발생했던 오류문구를 Filter에 입력 → 검색결과 중에서 분석하고자 하는 행(아이템)을 더블클릭

 

- 검색창을 최소화하거나 닫으면 메인창의 커서가 위에서 더블클릭한 문구가 위치한 곳으로 이동되어 있다.

- 음영표시된 칸의 우측 "XREF[1]:     __T07DVIA_v232JailbreakDetection..."을 더블클릭한다.

 

- 더블클릭 시 음영표시된 칸을 선택 → Window 클릭 → Function Graph 클릭

 

- 노란색으로 표시되면서 확대/축소를 반복하는 곳을 마우스 휠을 이용하여 확대한다.

- 내용을 분석해 보면 레지스터 w8의 값이 0x0일 때와 아닐 때의 결과가 달라진다는 것을 알 수 있다.

* 100193b70 : 문구를 보았을 때 탈옥되지 않은 기기일 때 실행되는 로직인걸 알 수 있음.

* 1001936e8 : 문구를 보았을때 탈옥된 기기를 사용할 때 실행되는 로직인걸 알 수 있음.

* tbz(Test bit and Branch if Zero) : 테스트 비트의 값을 0과 비교하여 결과에 따라 다른 오프셋의 레이블로 분기함.

 

5. 바이너리 파일 변조

- 현재 로직을 분석해 보면 w8 레지스터 값이 0x0일 때 100193b70 오프셋(offset)으로 이동되도록 되어져 있다는 것을 알 수 있다.

- 100193b70 오프셋은 탈옥이 탐지되지 않았을 때의 로직이므로, 'Jailbreak Test 4' 클릭 시 w8 값으로 0x0 이외의 값이 입력되어 탈옥이 탐지되었을 때의 로직이 실행되었다고 추측할 수 있다.

- 'Jailbreak Test 4' 클릭 시 레지스터 w8에 입력되는 값을 0x0으로 변조하여 탈옥이 탐지되지 않았을 때의 로직이 실행되어 탈옥탐지 기능을 우회할 수 있게 해보겠다.

//이해하기 쉽게 현재 구성을 C언어로 작성하면 아래와 같다.
if (w8 == 0) {
	탈옥이 탐지되지 않았을 때의 로직 실행
}
else {
	탈옥이 탐지되었을 때의 로직 실행
}Copy

 

- 분기점이 되는 곳의 오프셋을 알기 위해 아래와 같이 적색박스로 되어 있는 곳을 클릭한다(더블클릭 X).

 

- Function Graph 창을 최소화하거나 닫으면 메인창의 커서가 위에서 클릭한 분기점의 위치로 변경되어 있을 것이다.

- 음영표시된 칸의 오프셋을 기억하도록 한다.

* 분기점의 오프셋 : 1001936e4

 

- w8의 값을 변조하기 위해서는 탈옥된 기기에 프리다 서버, PC에 프리다 클라이언트가 설치되어 있어야 한다.

- 아래의 글을 참고하여 프리다(Frida) 서버와 클라이언트를 설치하도록 한다.

2022.06.28 - [Mobile App 취약점 진단/iOS App 진단] - [iOS App 진단] 03강 - 진단 도구 설치

[iOS App 진단] 03강 - 진단 도구 설치

 

- PC의 프리다 클라이언트를 이용하여 탈옥탐지 기능을 우회하고자 하는 앱의 이름을 알아낸다.

- 명령어 : frida-ps -Ua

* 앱의 이름 : DVIA-v2

frida-ps -Ua

 

- 위에서 확인한 정보를 바탕으로 아래의 자바스크립트 코드를 PC에서 작성한다.

- 파일 명 : hagsig_jailbreak1.js

* 메모장에 아래의 코드를 입력한 뒤 확장자명을 .js로 저장하면 자바스크립트 파일이 만들어진다.

var realbase_address = Module.findBaseAddress('DVIA-v2') //DVIA-v2 바이너리가 실행되어 메모리에 올라갔을때 할당된 주소를 realbase_address에 저장
console.log('realbase address : ' + realbase_address) //realbase_address에 저장된 주소를 화면에 출력

var jailbreak_address = realbase_address.add('0x1936e4') //realbase_address에 분기점 오프셋을 더하면 실제 분기점 메모리 주소가 jailbreak_address에 저장됨
console.log('jailbreak address : ' + jailbreak_address) //jailbreak_address에 저장된 주소를 화면에 출력

Interceptor.attach(jailbreak_address, { //jailbreak_address에서 호출되는 값을 가로채기 위해 준비
	onEnter: function(args){ //호출되는 레지스터 값을 받아옴
		console.log(JSON.stringify(this.context)) //받아온 레지스터 값을 JSON 형태로 화면에 출력
	}
})

※ 위 코드를 좀 더 자세히 공부하고 싶다면 아래의 게시글을 참고하여 프리다 문법을 공부하도록 하자.

2023.10.03 - [Mobile App 취약점 진단/iOS App 진단] - 프리다(Frida) 문법 정리

프리다(Frida) 문법 정리

 

- PC의 프리다 클라이언트를 이용하여 작성한 코드를 실행한다.

- 명령어 : frida -U -l [코드경로] [앱이름]

frida -U -l hagsig_jailbreak1.js DVIA-v2

- ASLR이 적용되어 있으므로, realbase address와 jailbreak address는 실행할 때마다 값이 달라진다.

 

- 위 화면에서 'Jailbreak Test 4'를 클릭하면 아래와 같이 많은 레지스터 값이 출력된다.

- 레지스터 x8의 값으로 0x1이 입력되어 탈옥된 기기라는 "Device is Jailbroken, Exiting !" 메시지가 출력되는 것을 확인할 수 있다.

* 레지스터 x8이 위에서 본 레지스터 w8이다.

 

- 레지스터 x8의 값을 0x0으로 바꾸어주면 탈옥되지 않았을 때의 로직이 실행될 것 같다.

- 위에서 작성한 코드에 레지스터 x8의 값을 0x0으로 변조해 주는 코드를 추가하여 실행한다.

var realbase_address = Module.findBaseAddress('DVIA-v2')
console.log('realbase address : ' + realbase_address + '\r\n')

var jailbreak_address = realbase_address.add('0x1936e4')
console.log('jailbreak address : ' + jailbreak_address + '\r\n')

Interceptor.attach(jailbreak_address, {
	onEnter: function(args){
		console.log('as is : ' + JSON.stringify(this.context) + '\r\n')
		this.context.x8 = 0x0 //x8의 값을 0x0으로 변조
		console.log('to be : ' + JSON.stringify(this.context) + '\r\n') //변조된 결과 출력
	}
})

 

- 레지스터 x8의 값을 변조하는 코드를 삽입한 자바스크립트 파일을 실행한 뒤 'Jailbreak Test 4'를 클릭한다.

- "Device is Not Jailbroken"이라는 메시지가 출력되며, 앱이 강제종료되지 않도록 탈옥탐지 기능을 우회한 것을 확인할 수 있다.

 

※ 프리다가 아닌 기드라로 레지스터 x0값을 변경하는 방법을 공부하고 싶다면 아래의 글을 참고하자.

2023.09.10 - [Mobile App 취약점 진단/iOS App 진단] - [iOS App 진단] 11강 - 어플리케이션 패칭(앱 위·변조) 실습 2

[iOS App 진단] 11강 - 어플리케이션 패칭(앱 위·변조) 실습 2