[1탄] 취약점 점검 전 알아야 할 iOS 파일 시스템과 보안 아키텍처

작성자: 보안왕 김보안

들어가며

모바일 앱 취약점 점검을 위해선 최소한 루팅, 탈옥, 후킹과 같은 기본적인 점검 Skill이 필요합니다.
기본적인 Skill 이전에 점검 대상에 대한 이해를 먼저 다져놓으면 이후 다룰 실무적인 내용을 이해하는데에 더 도움이 될 것이라고 생각합니다. 저 또한 다짜고짜 탈옥, Frida 후킹 이런 실무적인 기술만 공부했었습니다.
 
진단원으로서 취약점을 도출해내면 대부분은 개발자가 취약점에 대한 조치를 수행합니다. 취약점에 대한 조치 가이드를 제공하고 조치를 맡은 개발자와 커뮤니케이션을 위해 그들과 눈높이를 맞출 필요가 있습니다. 그러기 위해선 취약점 점검 Skill 뿐 아니라 대상 환경에 대한 최소한의 이해가 필요하다고 생각했습니다.
 
이번 포스팅에서는 iOS 파일 시스템의 구조부터 샌드박스, 데이터 보호(Data Protection) 메커니즘, 그리고 키체인(Keychain)의 원리까지, 알고 넘어가야할 iOS 보안 아키텍처의 핵심을 정리해 보겠습니다.

 

목표 : 앱의 로컬 데이터가 어디에 저장되는지, 시스템이 데이터를 어떻게 보호하는지 파악하여 정확한 공격 벡터를 찾을 수 있다.

iOS 파일 시스템

• /Applications: 기기에 설치된 모든 기본(Native) 애플리케이션이 포함됩니다. (예: /Applications/Calculator.app)
• /var/containers/Bundle/application/[uuid]: 설치된 앱의 애플리케이션 번들(실행 파일 및 리소스)이 포함됩니다.
• /var/mobile/Containers/Data/Application/[uuid]: 설치된 애플리케이션의 데이터가 저장되는 곳입니다.
• /System: 핵심 시스템 파일 및 라이브러리가 포함됩니다.
• /Library: 시스템 전반에서 사용되는 리소스와 설정 파일이 포함됩니다.
• /User: 사용자 고유의 데이터와 설정이 포함됩니다.
• /Development: "개발용으로 사용(Use for development)" 버튼을 누르기 전까지는 비어 있습니다.
• /dev: 디바이스 파일들이 포함됩니다.
• /Core: OS 코어 덤프(Core Dumps) 파일이 포함됩니다.
• /private/var/mobile/Library/Logs/CrashReporter/<appname-date>*: 특정 애플리케이션의 크래시 로그(Crash logs)가 포함됩니다.
• 그 외 Unix 시스템의 기본적인 디렉터리들이 존재합니다.

권한 분리 및 샌드박스

iOS는 애플리케이션과 시스템 프로세스 사이 명확한 권한 분리가 존재합니다. 일반 애플리케이션은 mobile 사용자 권한으로 실행되고, 시스템 프로세스는 root 권한으로 동작합니다.
여기 샌드박스(Sandbox) 개념이 추가됩니다. 권한 분리를 통해 모든 애플리케이션은 mobile 권한으로 동작하지만 동일한 mobile 권한을 가지고 있더라도 샌드박스 정책으로 인해 특정 앱이 다른 앱의 데이터 영역에 접근하는 것은 불가합니다.

iOS 애플리케이션 샌드박스 격리 구조도

애플리케이션은 각 앱이 고유한 디렉터리 (private/var/mobile/Applications/{random ID})를 부여받아 해당 디렉터리 안에서만 실행됩니다. 그래서 우리가 앱을 사용할 때 앱에서 사진, 주소록, 문자메시지 등 보호된 자원에 대한 접근이 필요할 경우 시스템은 사용자의 명시적인 권한 허용을 팝업을 통해 확인받는 것입니다.

데이터 보호

iOS는 디바이스를 분실하거나 도난당했을 때 데이터를 보호하기 위해 데이터 보호 메커니즘이 적용됩니다.

iOS 데이터 보호 파일 암호화 흐름도

하드웨어 암호화 전용 프로세서 SEP(Secure Enclave Processor)를 기반으로 데이터 보호가 적용됩니다.
기기에서 파일이 생성되면 해당 파일은 고유한 256비트 AES 키로 암호화되며, 이 키는 시스템에서 관리하는 클래스 키(Class Key)로 다시 암호화되어 저장됩니다.
iOS에선 파일을 보안 수준에 따라 4가지로 분류합니다.
개발자는 FileDP와 같은 도구를 사용하여 아이폰 내 파일들의 데이터 보호 클래스를 확인할 수 있습니다.

• Complete Protection (NSFileProtectionComplete): 가장 안전한 보안 수준으로 기기가 잠금 해제된 상태에서만 접근 가능합니다.
• Protected Unless Open: 기기가 잠겨도, 이미 열려 있던 파일은 계속 접근 가능합니다.
• Protected Until First User Authentication: iOS 7 이후 기본 적용되었습니다. 부팅 후 최초 1회 잠금 해제 이후부터는 쭉 접근 가능합니다.
• No Protection: 기기 고유 키로만 보호되며 언제든 접근 가능합니다.

키체인

사용자의 비밀번호, 인증 토큰, 생체인증 정보 등 민감한 데이터는 키체인(Keychain)이라는 암호화 컨테이너에 저장됩니다.

iOS 키체인 저장 구조도

키체인은 기기 고유 칩셋에서만 알 수 있는 UID와 사용자 비밀번호(Passcode)를 결합한 값으로 암호화됩니다. 따라서 일반적인 경우엔 암호화된 기기가 아닌 다른 기기에선 복호화가 불가능합니다.
여기서 왜 일반적인 경우로 한정하였냐면, 탈옥(Jailbreak)된 기기에선 이러한 보호 로직이 무력화되어 내부 값을 덤프할 수 있습니다.
일반 앱 데이터는 앱을 삭제하면 함께 지워지지만, 키체인에 저장된 데이터는 앱을 삭제해도 기기에 영구적으로 남습니다. 이는 만약 기기를 초기화하지 않고 중고 거래 시 이전 사용자의 계정 정보나 토큰이 새로운 사용자에게 그대로 노출될 수 있는 부분입니다.

앱 권한 및 엔타이틀먼트

마지막으로, 대상 앱이 샌드박스를 넘어 어떤 시스템 자원과 상호작용하는지 살펴보는 내용입니다.
Info.plist: 앱이 사용자에게 권한(카메라, 위치 등)을 요청할 때 띄우는 목적 설명 문구(Purpose Strings)들이 정의되어 있습니다.
Entitlements: 앱이 런타임에 키체인 그룹을 공유하거나, 특정 데이터 보호 API를 사용하는 등 특수한 시스템 권한을 얻기 위해 선언하는 키-값(Key-Value) 설정입니다.
진단 전 .ipa 파일을 풀어 이 설정들을 먼저 분석하면, 해당 앱이 디바이스 내에서 어떤 동작을 수행하는지 그 '공격 표면(Attack Surface)'을 빠르게 파악할 수 있습니다.

1. IPA 압축 해제. 2. Payload/.app/ 내에서 Info.plist 파일 찾기.

Info.plist는 일반적으로 아래와 같은 형태를 보입니다.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>CFBundleIdentifier</key>
    <string>com.boan.ios.app</string>

    <key>NSAppTransportSecurity</key>
    <dict>
        <key>NSAllowsArbitraryLoads</key>
        <true/>
    </dict>

    <key>CFBundleURLTypes</key>
    <array>
        <dict>
            <key>CFBundleURLSchemes</key>
            <array>
                <string>mysecureapp</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

• CFBundleIdentifier (앱 식별자): 앱을 고유하게 구분하는 ID로, 이후 Frida 등을 이용한 동적 분석 시 타겟 앱을 정확히 지정하기 위해 가장 먼저 확인하는 값입니다.
• NSAllowsArbitraryLoads (평문 통신 허용): 애플의 기본 통신 보안(HTTPS 강제)을 무력화하고 평문(HTTP) 통신을 허용하는 설정으로, 패킷 스니핑 및 중간자 공격(MITM)이 가능할 확률이 높습니다.
• CFBundleURLSchemes (커스텀 URL 스킴): 외부에서 앱을 실행할 수 있도록 열어둔 '딥링크' 주소로, 전달되는 입력값을 제대로 검증하지 않으면 공격자가 악의적인 기능을 강제로 실행시킬 수 있습니다.

마치며

오늘 살펴본 파일 시스템 경로, 샌드박스 메커니즘, 데이터 보호 클래스, 그리고 키체인의 특성을 머릿속에 담아두신다면, 이후 진행될 실무 진단과 조치 가이드 작성 시 훨씬 더 넓은 시야를 가질 수 있을 것입니다.
내가 대상으로 하는 환경을 깊게 이해하고 점검을 수행하면 더욱 나은 점검 결과물을 만들어낼 수 있을 것이라고 생각합니다.
감사합니다.