1. 개요

 피싱 앱을 통한 신종 보이스 피싱 등 모바일 앱을 대상으로 하는 공격이 있다. 앱 개발사는 공격자로부터의 해킹을 예방하기 위해 앱 배포 전 백신, 플랫폼 해킹 탐지, 역공학 방지, 앱 위변조 여부를 확인한다. 이러한 대처에도 불구하고 블랙 해커들로 인해 동일한 사고가 발생하고 있다. 현존하는 iOS 보안 기술 동향들을 연구 및 기술하고 보안 솔루션에 우회 기술을 적용해보아 앞으로의 보안 기술 발전에 조금이나마 도움이 되고자 한다.

2. iOS 앱 보안 기술

 공격자들이 피해자들에게 위변조된 앱을 배포하기 위해서, OS 위변조 탐지(=플랫폼 해킹 탐지)와 앱 위변조 탐지 우회가 필수적이다. third-party APP 설치를 위해서는, 순정단말이 아닌 OS가 변조된 jailbreak device이어야만 한다. 주요 로직(ex. ID, PWD 전송, 계좌 송금 등) 변조를 위해서는 앱을 위변조하여 실행해야 한다. 그러나 개요에서 설명하였듯이, 보안 모듈로 인해 jailbreak device, 앱 위변조는 탐지되므로 앱 이용이 불가하다. 배포되어 악의적인 수행을 하는 APP들은 현존하는 OS 위변조 탐지, 앱 위변조 탐지 기술들을 우회하도록 위변조됐다. 그렇기에 이 두 가지 보안 기술을 중점으로 살펴봤다.

1) OS 위변조 탐지 

- File/Directory 존재 여부 확인
iOS는 앱을 통한 시스템 변조 가능성을 배제하기 위해, 각 앱마다 sandbox라는 앱 접근 가능 영역이 존재한다. 하지만 시스템 앱은 system partition에 설치되며 sandbox 제한이 없다. 그러므로 공격자들은 공격 도구, Cydia와 같은 Tweak관련 파일들을 root partition(=system partition) 하위 경로에 저장한다. system partition 검사를 통해 탈옥 관련 파일 리스트를 추출한 후 경로 검사를 통해 jailbreak 탐지가 가능하다.

- File/Directory 접근 권한 확인/변조
jailbreak 도구 실행 시, 접근 권한이 변경되는 file/directory가 존재한다. 단말기에서 각 앱들의 sandbox 영역 외 File/Directory 권한 확인 가능, 파일 권한값 획득 여부 검사를 통해서 탈옥을 검증한다. 

- File 작성, 수정 및 제거 시도 
jailbreak 툴들은 설치한 thirdparty-app의 sandbox를 무력화시키기도 한다. 그러므로 탈옥단말기에서는 sandbox 외 시스템 File, directory 접근 가능하다. 각 앱들의 sandbox 영역 외 File/Directory 경로 접근 및 읽기, 쓰기, 제거, 작업 디렉터리 경로 변경 등을 시도하여 탈옥 탐지가 가능하다. 주로 /tmp 하위 폴더 내 작업 시도한다.

- 동적 라이브러리 확인
프로세스에 로딩된 라이브러리 중 탈옥환경에서 실행 가능한 후킹 도구, tweak 관련 모듈명(ex, Substrate, TweakInject, cycript, SBInject, pspawn, rocketbootstrap, colorpicker, CS, bfdecrypt 등) 검사를 통해 jailbreak을 탐지한다.

- fork 시도
sandbox로 인해 순정 단말기 내 앱 프로세스는 fork() 이용이 불가하나, sandbox 제한 없는 탈옥단말기에서는 가능하다. jailbreak 단말기에서 fork() 실행 후, 결과 값 확인을 통한 정상 실행 여부 검사한다.

- Schema 확인 
Android와 마찬가지로 iOS도 custom URL을 지원한다. 탈옥 관련 앱들(Cydia, Sileo, zbra, undecimus, iFile 등) 존재 여부 파악을 위해, URL Schema를 이용하여 앱 실행 여부를 확인한다. 

- Shell 실행
system()은 SHELL_PATH로 /bin/sh를 이용하나, 순정디바이스에서는 /bin/sh 접근이 불가하다. system()는 쉘 이용 불가 시, 0을 반환한다. 탈옥단말기에서는 /bin/sh에 접근이 가능하므로, system() 정상 실행이 가능하다. 

- Binding Port 확인
탈옥환경에서 hooking 도구인 Frida를 이용하여 실행 파일 분석이 가능하다. Frida는 27042 port를 default로 이용한다. socket 생성 후, connect()를 이용하여 frida default port open 여부를 확인한다.

- symbolic link 확인
iOS에는 크게 2개의 영역이 존재한다. 하나는 용량이 적은 read-only system 영역이고, 다른 하나는 data 영역이다. jailbreak 툴들은 공간이 작은 system 영역 대신 data 영역에 thirdparty software를 저장하고, symbolic link를 통해 연결해놓는다. 파일, 폴더의 symbolic link를 확인한다. 

2) 앱 위변조 탐지 

- Binary File 기반 hash 검증
Mac에서 제공하는 API를 이용하여 앱 실행 파일 경로 획득, 파일 접근이 가능하다. 이후 파일  해쉬 생성을 통해 위변조 검증이 가능하다.

- Memory 기반 hash 검증
메모리상에서 실행 모듈 base 주소 획득 후 접근하여 data(실행 파일 전체, Code section, File signature 등) Hash, 암호화를 통해 검증할 수 있다. 주로 코드 섹션 __TEXT 세그먼트의 __text 섹션의 해시를 검증한다.

3. 우회 기법

1) Mach-O Load Commands

iOS 애플리케이션의 바이너리는 Mach-O구조로 이루어진다. Mach-O는Header, Load Commands, Data로 이루어져 있다. Load Commands는 다수의 Command를 포함하며 동적 라이브러리는 Command영역에 정의한다. 동적 라이브러리는 iOS운영체제에 존재하는 기본 라이브러리와 애플리케이션 개발자가 삽입한 동적 라이브러리가 포함된다. 다수의 동적 라이브러리가 정의된 경우 Command 순서대로 라이브러리가 로드된다.

공격자는 애플리케이션 바이너리의 Load Commands를 조작하여 악의적인 동적 라이브러리 삽입이 가능하다. 공격자의 동적 라이브러리가 첫 번째로 정의된 경우, 애플리케이션의 바이너리 코드와 기타 보안 모듈의 동적 라이브러리보다 먼저 호출된다. 보안 모듈보다 먼저 호출된 동적 라이브러리는 메모리 조작을 통해 보안 모듈을 손쉽게 무력화한다. 

2) DYLD_INSERT_LIBRARIES

순정단말기에서는 앱을 리패키징하여 메모리 접근할 수 있으나, 최고(root) 권한 이용 가능한 device에서는 시스템 환경변수를 통한 라이브러리 삽입이 가능하다. 그러므로 탈옥환경에서는 앱 위변조 우회하지 않은 상태에서 로직 변조가 가능하다. 

3) 메모리 해킹

공격자의 동적 라이브러리는 애플리케이션의 메모리에 자유롭게 접근한다. 보안 모듈의 디버깅 방지 기능은 타 프로세스에서의 접근을 방지하므로 동적 라이브러리 삽입을 통한 메모리 접근은 디버깅 방지 기능에 영향을 받지 않는다. 함수 후킹을 위해서 함수 시작 부분의 명령어나 주소 테이블 내 주소를 변조할 수있다. Frida를 이용하여 API 인라인 후킹을 구현한 코드는 다음과 같다.

#대상 프로세스 attach session = host.attach(TARGE_PID) #스크립트 로드 script.session.create_script(''' Interceptor.attach(     Module.findExportByName(null,"fopen"),{ //fopen 함수를 찾는다.        onEnter: function(args){            if(args[0].isNull())return;            var path=args[0].readUtf8String();  //현재 fopen 함수의 인자를 출력한다.            console.log("[+] fopen "+path);     //인자로 전달된 원본파일명            if(path.match("TARGET_PATH")){               console.log(" --> Change It!!");               args[0].writeUtf8String("CHANGED_PATH"); //후킹하여 변조하는 인자            }         }     }); ''') script.on('message',on_message) script.load()

4) 메소드 스위즐링

Objective-C는 클래스의 메소드를 호출할 때, 함수 주소에 의한 호출이 아닌 객체에 메시지를 전송하여 메소드를 호출한다. 메시지를 받은 객체는 dispatch table에서 각 메시지에 해당하는 메소드를 호출한다. Objective-C의 메소드 호출 방식으로 인해 메소드 교체가 가능하다. iOS는 특정 메소드의 구현을 변경하는API를 제공한다.

공격자의 동적 라이브러리는 애플리케이션의 클래스와 메소드에 자유롭게 접근 가능하다.

method_exchangeImplementations API를 이용하여 메소드 스위즐링을 구현한 코드는 다음과 같다.

#include <objc/runtime.h> #include <objc/message.h> … // 스위즐링 대상 클래스와 메소드를 가져온다 Class clsTarget = objc_getClass(“TARGET_CLASS_NAME”); Method methodOrg = class_getInstanceMethod(clsTarget, @selector(TARGET_SELECTOR));   // 스위즐링 대상 클래스에 공격자의 메소드를 삽입한다 class_addMethod(clsTarget, @selector(MY_SELECTOR));   // 스위즐링 대상 클래스에 존재하는 메소드와 삽입한 메소드를 교체(스위즐링)한다 Method methodNew = class_getInstanceMethod(clsTarget, @selector(MY_SELECTOR)); method_exchangeImplementations(methodOrg, methodNew);

4. 대응 방안

 본 게시글에서 앱 보안 기술과 더불어 우회 기법을 소개하였다. 공격자로부터 앱을 보호하기 위해 다양한 보안 기술을 탑재한 보안 솔루션들이 존재한다. 국내 iOS 앱 보안 솔루션 총 5개에 본 게시글에서 소개하는 우회 기법을 적용한 결과, AppSuit를 제외한 타 솔루션들의 탈옥 탐지와 위변조 탐지 로직 무력화가 가능하였다. 소개한 기법을 이용하여 보안 솔루션들이 무력화되므로 안전한 iOS 앱 보안을 위해 전문적인 보안 솔루션 적용을 권고한다.