iOS Basics

Support HackTricks

권한 분리 및 샌드박스

iOS에서는 사용자 접근 가능한 애플리케이션과 시스템의 핵심 프로세스 간에 권한의 구분이 존재합니다. 애플리케이션은 mobile 사용자 신원 아래에서 실행되며, 중요한 시스템 프로세스는 **root**로 작동합니다. 이 분리는 애플리케이션이 수행할 수 있는 작업에 엄격한 제한을 부과하는 샌드박스 메커니즘에 의해 강화됩니다. 예를 들어, 애플리케이션이 동일한 사용자 신원을 공유하더라도 서로의 데이터에 접근하거나 수정하는 것은 금지됩니다.

애플리케이션은 특정 디렉토리(private/var/mobile/Applications/{random ID})에 설치되며, SMS 및 전화 통화와 같은 특정 시스템 영역 및 기능에 대한 제한된 읽기 접근 권한을 가집니다. 보호된 영역에 대한 접근은 사용자 권한 요청 팝업을 트리거합니다.

데이터 보호

iOS는 개발자에게 데이터 보호 API를 제공합니다. 이는 암호화 작업 및 키 관리를 위한 전용 코프로세서인 Secure Enclave Processor (SEP) 위에 구축되어 있습니다. SEP는 장치 UID라는 고유한 장치 전용 키를 통해 데이터 보호 무결성을 보장합니다.

파일 생성 시, 고유한 256비트 AES 암호화 키가 생성되어 파일의 내용을 암호화합니다. 이 암호화 키는 클래스 ID와 함께 클래스 키를 사용하여 암호화되고 파일의 메타데이터에 저장됩니다. 파일을 복호화하려면 시스템의 키를 사용하여 메타데이터에 접근하고, 클래스 ID로 클래스 키를 검색한 후 파일의 고유한 암호화 키를 복호화합니다.

iOS는 데이터 보안을 위해 네 가지 보호 클래스를 정의하며, 이는 데이터에 접근할 수 있는 시기와 방법을 결정합니다:

  • 완전 보호 (NSFileProtectionComplete): 사용자의 비밀번호로 장치가 잠금 해제될 때까지 데이터에 접근할 수 없습니다.

  • 열리지 않는 한 보호됨 (NSFileProtectionCompleteUnlessOpen): 장치가 잠금 상태일 때도 파일이 열려 있었던 경우 파일 접근을 허용합니다.

  • 첫 사용자 인증 전까지 보호됨 (NSFileProtectionCompleteUntilFirstUserAuthentication): 부팅 후 첫 사용자 잠금 해제 이후 데이터에 접근할 수 있으며, 장치가 다시 잠금 상태가 되어도 접근이 가능합니다.

  • 보호 없음 (NSFileProtectionNone): 데이터는 장치 UID로만 보호되며, 빠른 원격 데이터 삭제를 용이하게 합니다.

NSFileProtectionNone을 제외한 모든 클래스의 암호화는 장치 UID와 사용자의 비밀번호에서 파생된 키를 포함하여, 올바른 비밀번호가 있는 장치에서만 복호화가 가능하도록 보장합니다. iOS 7 이후 기본 보호 클래스는 "첫 사용자 인증 전까지 보호됨"입니다.

개발자는 iPhone의 파일 데이터 보호 클래스를 검사하기 위한 도구인 FileDP를 사용할 수 있습니다.

# Example code to use FileDP for checking file protection class
# Note: Ensure your device is jailbroken and has Python installed to use FileDP.
# Installation and usage of FileDP:
git clone https://github.com/abjurato/FileDp-Source
cd FileDp-Source
python filedp.py /path/to/check

키체인

iOS에서 키체인민감한 정보를 저장하기 위한 안전한 암호화된 컨테이너 역할을 하며, 이를 저장한 애플리케이션이나 명시적으로 권한을 부여받은 애플리케이션만 접근할 수 있습니다. 이 암호화는 iOS에 의해 생성된 고유한 비밀번호로 강화되며, 이 비밀번호 자체는 AES로 암호화됩니다. 이 암호화 과정은 PBKDF2 함수를 활용하여 사용자의 패스코드와 장치의 UID에서 파생된 솔트를 결합합니다. 이 UID는 오직 보안 엔클레이브 칩셋만 접근할 수 있는 구성 요소입니다. 따라서 사용자의 패스코드가 알려져 있더라도, 키체인 내용은 원래 암호화된 장치 외의 다른 장치에서는 접근할 수 없습니다.

키체인 데이터에 대한 관리 및 접근Keychain-access-groupsapplication-identifier와 같은 특정 앱 권한에 따라 securityd 데몬에 의해 처리됩니다.

키체인 API 작업

키체인 API는 Apple의 키체인 서비스 문서에서 자세히 설명되어 있으며, 안전한 저장 관리에 필요한 필수 기능을 제공합니다:

  • SecItemAdd: 키체인에 새 항목을 추가합니다.

  • SecItemUpdate: 키체인에 있는 기존 항목을 업데이트합니다.

  • SecItemCopyMatching: 키체인에서 항목을 검색합니다.

  • SecItemDelete: 키체인에서 항목을 제거합니다.

키체인 비밀번호를 무차별 대입하는 것은 암호화된 키를 직접 공격하거나 장치 자체에서 패스코드를 추측하려고 시도하는 것을 포함하며, 실패한 시도 간의 지연을 강제하는 보안 엔클레이브에 의해 크게 방해받습니다.

키체인 항목 데이터 보호 구성

키체인 항목의 데이터 보호 수준은 항목 생성 또는 업데이트 시 kSecAttrAccessible 속성을 사용하여 설정됩니다. 이러한 수준은 Apple에서 지정한 대로 키체인 항목에 접근할 수 있는 시기와 방법을 결정합니다:

  • kSecAttrAccessibleAlways: 장치 잠금 상태와 관계없이 언제든지 접근 가능.

  • kSecAttrAccessibleAlwaysThisDeviceOnly: 항상 접근 가능하지만 백업에 포함되지 않음.

  • kSecAttrAccessibleAfterFirstUnlock: 재시작 후 첫 잠금 해제 후 접근 가능.

  • kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly: 위와 동일하지만 새로운 장치로 전송할 수 없음.

  • kSecAttrAccessibleWhenUnlocked: 장치가 잠금 해제된 경우에만 접근 가능.

  • kSecAttrAccessibleWhenUnlockedThisDeviceOnly: 잠금 해제 시 접근 가능, 백업에 포함되지 않음.

  • kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly: 장치 패스코드가 필요하며, 백업에 포함되지 않음.

**AccessControlFlags**는 생체 인식 인증 또는 패스코드 사용을 허용하여 접근 방법을 더욱 세분화합니다.

탈옥 장치 경고

탈옥된 장치에서는 키체인의 보호가 손상되어 상당한 보안 위험을 초래합니다.

키체인 데이터의 지속성

앱이 삭제될 때 삭제되는 앱 전용 데이터와 달리, 키체인 데이터는 장치에 지속적으로 남아 있습니다. 이 특성으로 인해 중고 장치의 새로운 소유자가 앱을 재설치함으로써 이전 소유자의 애플리케이션 데이터에 접근할 수 있습니다. 개발자는 이 위험을 완화하기 위해 앱 설치 시 또는 로그아웃 시 키체인 데이터를 사전적으로 지우는 것이 좋습니다. 다음은 첫 앱 실행 시 키체인 데이터를 지우는 방법을 보여주는 Swift 코드 예제입니다:

let userDefaults = UserDefaults.standard

if userDefaults.bool(forKey: "hasRunBefore") == false {
// Remove Keychain items here

// Update the flag indicator
userDefaults.set(true, forKey: "hasRunBefore")
userDefaults.synchronize() // Forces the app to update UserDefaults
}

앱 기능

앱 개발 분야에서 샌드박싱은 보안을 강화하는 데 중요한 역할을 합니다. 이 과정은 각 앱이 고유한 홈 디렉토리 내에서 작동하도록 보장하여 시스템 파일이나 다른 앱의 데이터에 접근하는 것을 방지합니다. 이러한 제한 사항의 시행은 신뢰할 수 있는 BSD (MAC) 강제 접근 제어 프레임워크의 일환인 샌드박스 정책을 통해 이루어집니다.

개발자는 데이터 보호 또는 키체인 공유와 같은 특정 기능 또는 권한을 앱에 구성할 수 있습니다. 이러한 권한은 앱이 설치된 직후에 적용됩니다. 그럼에도 불구하고 특정 보호된 리소스에 접근하기 위해서는 앱이 첫 시도 시 사용자로부터 명시적인 동의를 받아야 합니다. 이는 사용자에게 권한 요청 알림에서 제공되는 목적 문자열 또는 _사용 설명 문자열_을 통해 이루어집니다.

소스 코드에 접근할 수 있는 경우, Info.plist 파일에 포함된 권한을 확인하는 방법은 다음과 같습니다:

  1. Xcode에서 프로젝트를 엽니다.

  2. Info.plist 파일을 찾고 엽니다.

  3. "Privacy -"로 접두사가 붙은 키를 검색하며, 명확성을 위해 원시 키/값을 볼 수 있는 옵션을 선택합니다.

IPA 파일을 다룰 때는 다음 단계를 따를 수 있습니다:

  1. IPA 파일의 압축을 풉니다.

  2. Payload/<앱이름>.app/ 내에서 Info.plist 파일을 찾습니다.

  3. 필요에 따라 파일을 XML 형식으로 변환하여 더 쉽게 검사합니다.

예를 들어, Info.plist 파일의 목적 문자열은 다음과 같이 보일 수 있습니다:

<plist version="1.0">
<dict>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Your location is used to provide turn-by-turn directions to your destination.</string>

Device Capabilities

앱의 Info.plist 파일은 장치 기능을 지정하여 App Store가 장치 호환성을 위해 앱을 필터링하는 데 도움을 줍니다. 이는 UIRequiredDeviceCapabilities 키 아래에 정의됩니다. 예를 들어:

<key>UIRequiredDeviceCapabilities</key>
<array>
<string>armv7</string>
</array>

이 예시는 앱이 armv7 명령어 집합과 호환된다는 것을 나타냅니다. 개발자는 NFC를 지원하는 장치에서만 앱을 사용할 수 있도록 보장하기 위해 nfc와 같은 기능을 지정할 수도 있습니다.

권한

권한은 iOS 앱 개발의 또 다른 중요한 측면으로, 앱이 런타임 검사 이상의 특정 작업을 수행할 수 있는 권한을 부여하는 키-값 쌍으로 작용합니다. 예를 들어, 앱에서 데이터 보호를 활성화하려면 Xcode 프로젝트에 특정 권한을 추가해야 하며, 이는 앱의 권한 파일이나 IPA의 내장 모바일 프로비전 파일에 반영됩니다.

References

Support HackTricks

Last updated