iOS Pentesting

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

• 구독 계획 확인하기!
• **💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

iOS 기본

iOS Basics

테스트 환경

이 페이지에서는 iOS simulator, emulators 및 jailbreaking에 대한 정보를 확인할 수 있습니다:

iOS Testing Environment

초기 분석

기본 iOS 테스트 작업

테스트 중에 여러 작업이 제안될 것입니다 (connect to the device, read/write/upload/download files, use some tools…). 따라서 이러한 작업을 수행하는 방법을 모른다면 해당 페이지를 먼저 읽기 시작하세요:

iOS Basic Testing Operations

Tip

다음 단계를 진행하려면 앱이 디바이스에 설치되어 있어야 하며 애플리케이션의 IPA 파일을 이미 확보했어야 합니다.
이 작업을 수행하는 방법은 Basic iOS Testing Operations 페이지를 읽으세요.

기본 정적 분석

흥미로운 iOS - IPA 파일 디컴파일러 몇 가지:

• https://github.com/LaurieWired/Malimite
• https://ghidra-sre.org/

IPA 파일에 대해 자동 정적 분석을 수행하려면 도구 MobSF를 사용하는 것이 권장됩니다.

바이너리에 적용된 보호 기능 식별:

• PIE (Position Independent Executable): 활성화되면 애플리케이션이 실행될 때마다 무작위 메모리 주소에 로드되어 초기 메모리 주소를 예측하기 더 어렵게 만듭니다.

otool -hv <app-binary> | grep PIE   # It should include the PIE flag

• Stack Canaries: 스택의 무결성을 검증하기 위해 함수 호출 전에 ‘canary’ 값을 스택에 배치하고 함수가 끝날 때 다시 검증합니다.

otool -I -v <app-binary> | grep stack_chk   # It should include the symbols: stack_chk_guard and stack_chk_fail

• ARC (Automatic Reference Counting): 일반적인 메모리 손상 취약점을 방지합니다.

otool -I -v <app-binary> | grep objc_release   # It should include the _objc_release symbol

• Encrypted Binary: 바이너리는 암호화되어 있어야 합니다.

otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # The cryptid should be 1

민감/취약 함수 식별

• 약한 해시 알고리즘

# On the iOS device
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"

# On linux
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"

• 불안전한 랜덤 함수

# On the iOS device
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# On linux
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"

• 불안전한 ‘Malloc’ 함수

# On the iOS device
otool -Iv <app> | grep -w "_malloc"

# On linux
grep -iER "_malloc"

• 안전하지 않거나 취약한 함수들

# On the iOS device
otool -Iv <app> | grep -w "_gets"
otool -Iv <app> | grep -w "_memcpy"
otool -Iv <app> | grep -w "_strncpy"
otool -Iv <app> | grep -w "_strlen"
otool -Iv <app> | grep -w "_vsnprintf"
otool -Iv <app> | grep -w "_sscanf"
otool -Iv <app> | grep -w "_strtok"
otool -Iv <app> | grep -w "_alloca"
otool -Iv <app> | grep -w "_sprintf"
otool -Iv <app> | grep -w "_printf"
otool -Iv <app> | grep -w "_vsprintf"

# On linux
grep -R "_gets"
grep -iER "_memcpy"
grep -iER "_strncpy"
grep -iER "_strlen"
grep -iER "_vsnprintf"
grep -iER "_sscanf"
grep -iER "_strtok"
grep -iER "_alloca"
grep -iER "_sprintf"
grep -iER "_printf"
grep -iER "_vsprintf"

일반적인 Jailbreak 탐지 방법

• 파일 시스템 검사: /Applications/Cydia.app 또는 /Library/MobileSubstrate/MobileSubstrate.dylib과 같은 일반적인 jailbreak 파일 및 디렉터리의 존재를 확인합니다.
• 샌드박스 위반: non-jailbroken devices에서 차단되어야 하는 파일 시스템의 제한 영역에 접근을 시도합니다.
• API 검사: fork() 같은 금지된 호출을 사용하거나 system()을 사용해 /bin/sh가 존재하는지 확인할 수 있는지 검사합니다.
• 프로세스 검사: Cydia, Substrate, ssh와 같은 알려진 jailbreak 관련 프로세스의 존재를 모니터링합니다.
• 커널 익스플로잇: jailbreak에 일반적으로 사용되는 커널 익스플로잇의 존재를 확인합니다.
• 환경 변수: DYLD_INSERT_LIBRARIES와 같은 jailbreak 신호를 찾습니다.
• 로드된 라이브러리 확인: 앱 프로세스에 로드된 라이브러리를 확인합니다.
• 스킴 확인: 예: canOpenURL(URL(string: “cydia://”)).

일반적인 안티-디버깅 탐지 방법

• 디버거 존재 확인: sysctl 또는 기타 방법을 사용하여 디버거가 연결되어 있는지 확인합니다.
• 안티-디버깅 API: ptrace 또는 SIGSTOP 같은 안티-디버깅 API 호출(ptrace(PT_DENY_ATTACH, 0, 0, 0) 등)을 확인합니다.
• 타이밍 검사: 특정 작업에 소요되는 시간을 측정하여 디버깅을 나타낼 수 있는 불일치를 찾습니다.
• 메모리 검사: 알려진 디버거 유물 또는 변경 사항에 대해 메모리를 검사합니다.
• 환경 변수: 디버깅 세션을 나타낼 수 있는 환경 변수를 확인합니다.
• Mach 포트: 디버거가 mach 예외 포트를 사용하고 있는지 감지합니다.

기본 동적 분석

MobSF가 수행하는 동적 분석을 확인하세요. 다양한 뷰를 탐색하고 상호작용해야 하지만 여러 클래스를 후킹하는 등의 작업을 수행하며 완료하면 보고서를 준비합니다.

설치된 앱 나열

설치된 앱의 bundle identifier를 확인하려면 frida-ps -Uai 명령을 사용하세요:

$ frida-ps -Uai
PID  Name                 Identifier
----  -------------------  -----------------------------------------
6847  Calendar             com.apple.mobilecal
6815  Mail                 com.apple.mobilemail
-  App Store            com.apple.AppStore
-  Apple Store          com.apple.store.Jolly
-  Calculator           com.apple.calculator
-  Camera               com.apple.camera
-  iGoat-Swift          OWASP.iGoat-Swift

기본 Enumeration & Hooking

앱의 구성 요소를 enumerate the components of the application하는 방법과 objection으로 hook methods and classes하는 쉬운 방법을 배우세요:

iOS Hooking With Objection

IPA 구조

The structure of an IPA file is essentially that of a zipped package. By renaming its extension to .zip, it can be decompressed to reveal its contents. Within this structure, a Bundle represents a fully packaged application ready for installation. Inside, you will find a directory named <NAME>.app, which encapsulates the application’s resources.

• Info.plist: 이 파일은 애플리케이션의 특정 구성 세부정보를 담고 있습니다.
• _CodeSignature/: 이 디렉터리에는 서명을 포함한 plist 파일이 있어 번들 내 모든 파일의 무결성을 보장합니다.
• Assets.car: 아이콘과 같은 자산 파일을 저장하는 압축 아카이브입니다.
• Frameworks/: 이 폴더는 애플리케이션의 네이티브 라이브러리를 포함하며 .dylib 또는 .framework 파일 형태일 수 있습니다.
• PlugIns/: 이 폴더에는 애플리케이션의 확장(예: .appex 파일)이 포함될 수 있지만, 항상 있는 것은 아닙니다. * Core Data: 애플리케이션의 영구 데이터를 오프라인에서 사용하도록 저장하고, 임시 데이터를 캐시하며, 단일 기기에서 undo 기능을 추가하는 데 사용됩니다. 단일 iCloud 계정의 여러 기기 간에 데이터를 동기화하려면 Core Data가 자동으로 스키마를 CloudKit 컨테이너에 미러링합니다.
• PkgInfo: PkgInfo 파일은 애플리케이션 또는 번들의 type 및 creator 코드를 지정하는 대체 방법입니다.
• en.lproj, fr.proj, Base.lproj: 특정 언어용 리소스를 포함하는 언어 팩이며, 해당 언어가 지원되지 않을 경우의 기본 리소스를 제공합니다.
• Security: _CodeSignature/ 디렉터리는 디지털 서명을 통해 번들된 모든 파일의 무결성을 검증함으로써 앱 보안에서 중요한 역할을 합니다.
• Asset Management: Assets.car 파일은 압축을 사용해 그래픽 자산을 효율적으로 관리하며, 이는 애플리케이션 성능 최적화 및 전체 크기 감소에 중요합니다.
• Frameworks and PlugIns: 이러한 디렉터리는 iOS 애플리케이션의 모듈성을 강조하며, 개발자가 재사용 가능한 코드 라이브러리(Frameworks/)를 포함하고 앱 기능을 확장(PlugIns/)할 수 있게 합니다.
• Localization: 이 구조는 여러 언어를 지원하여 특정 언어 팩용 리소스를 포함함으로써 글로벌 앱 확장을 용이하게 합니다.

Info.plist

Info.plist는 iOS 애플리케이션의 핵심 요소로, key-value 쌍 형태로 주요 구성 데이터를 캡슐화합니다. 이 파일은 애플리케이션뿐 아니라 번들된 앱 확장과 프레임워크에도 필수입니다. XML 또는 바이너리 형식으로 구조화되며, 앱 권한에서 보안 구성에 이르기까지 중요한 정보를 포함합니다. 사용 가능한 키에 대한 자세한 내용은 Apple Developer Documentation을 참조하세요.

이 파일을 더 접근하기 쉬운 형식으로 작업하려는 경우, macOS에서 기본으로 제공되는 plutil (10.2 버전 이상) 또는 Linux에서의 plistutil을 사용하여 XML로 쉽게 변환할 수 있습니다. 변환 명령은 다음과 같습니다:

• macOS의 경우:

$ plutil -convert xml1 Info.plist

• Linux용:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Info.plist 파일이 드러낼 수 있는 수많은 정보 중에서 주목할 만한 항목으로는 앱 권한 문자열 (UsageDescription), 커스텀 URL 스킴 (CFBundleURLTypes), 그리고 App Transport Security 설정 (NSAppTransportSecurity) 등이 있습니다. 이러한 항목들은 UTExportedTypeDeclarations / UTImportedTypeDeclarations 같은 내보내기/가져오기용 커스텀 문서 타입과 함께, 파일을 직접 검사하거나 간단한 grep 명령을 사용하면 쉽게 찾을 수 있습니다:

$ grep -i <keyword> Info.plist

데이터 경로

iOS 환경에서는 디렉터리가 시스템 애플리케이션과 사용자 설치 애플리케이션용으로 각각 지정되어 있습니다. 시스템 애플리케이션은 /Applications 디렉터리에 위치하고, 사용자 설치 앱은 /var/mobile/containers/Data/Application/ 아래에 배치됩니다. 이러한 애플리케이션들은 128-bit UUID라는 고유 식별자를 부여받기 때문에 디렉터리 이름이 무작위여서 수동으로 앱 폴더를 찾기 어렵습니다.

Warning

iOS에서 애플리케이션은 샌드박스되어야 하므로, 각 앱은 $HOME/Library/Containers 안에 앱의 **CFBundleIdentifier**를 폴더 이름으로 하는 폴더를 또한 갖습니다.

그러나, 두 폴더(데이터 & 컨테이너 폴더) 모두에는 두 파일을 연결하는 키 MCMetadataIdentifier가 있는 .com.apple.mobile_container_manager.metadata.plist 파일이 있습니다).

사용자 설치 앱의 설치 디렉터리 발견을 용이하게 하기 위해, objection tool은 env라는 유용한 명령을 제공합니다. 이 명령은 해당 앱에 대한 자세한 디렉터리 정보를 보여줍니다. 아래는 이 명령을 사용하는 예시입니다:

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env

Name               Path
-----------------  -------------------------------------------------------------------------------------------
BundlePath         /var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
CachesDirectory    /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library/Caches
DocumentDirectory  /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Documents
LibraryDirectory   /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library

또는 find 명령을 사용하여 /private/var/containers 내에서 앱 이름을 검색할 수 있습니다:

find /private/var/containers -name "Progname*"

예를 들어 ps 및 lsof 같은 명령을 사용하면 각각 앱의 프로세스를 식별하고 열린 파일을 나열하여 애플리케이션의 활성 디렉터리 경로에 대한 통찰을 얻을 수 있습니다:

ps -ef | grep -i <app-name>
lsof -p <pid> | grep -i "/containers" | head -n 1

번들 디렉터리:

• AppName.app
• 이전에 IPA에서 보았던 Application Bundle입니다. 필수 애플리케이션 데이터, 정적 콘텐츠 및 애플리케이션의 컴파일된 바이너리를 포함합니다.
• 이 디렉터리는 사용자에게 보이지만, 사용자는 이 디렉터리에 쓸 수 없습니다.
• 이 디렉터리의 내용은 백업되지 않습니다.
• 이 폴더의 내용은 코드 서명 검증에 사용됩니다.

데이터 디렉터리:

• Documents/
• 모든 사용자 생성 데이터를 포함합니다. 이 데이터의 생성은 애플리케이션 최종 사용자가 시작합니다.
• 사용자에게 보이며 사용자는 이 디렉터리에 쓸 수 있습니다.
• 이 디렉터리의 내용은 백업됩니다.
• 앱은 NSURLIsExcludedFromBackupKey를 설정하여 경로를 백업에서 제외할 수 있습니다.
• Library/
• 사용자별이 아닌 파일들, 예를 들어 caches, preferences, cookies, 및 property list (plist) 구성 파일을 포함합니다.
• iOS 앱은 보통 Application Support 및 Caches 하위 디렉터리를 사용하지만, 앱은 커스텀 하위 디렉터리를 생성할 수 있습니다.
• Library/Caches/
• 반영구적 캐시 파일을 포함합니다.
• 사용자에게 보이지 않으며 사용자는 이 디렉터리에 쓸 수 없습니다.
• 이 디렉터리의 내용은 백업되지 않습니다.
• OS는 앱이 실행 중이 아니고 저장 공간이 부족할 때 이 디렉터리의 파일들을 자동으로 삭제할 수 있습니다.
• Library/Application Support/
• 앱 실행에 필요한 영구적인 파일들을 포함합니다.
• 사용자에게 보이지 않으며 사용자는 쓸 수 없습니다.
• 이 디렉터리의 내용은 백업됩니다.
• 앱은 NSURLIsExcludedFromBackupKey를 설정하여 경로를 백업에서 제외할 수 있습니다.
• Library/Preferences/
• 애플리케이션이 재시작된 이후에도 지속될 수 있는 속성들을 저장하는 데 사용됩니다.
• 정보는 암호화되지 않은 상태로 애플리케이션 샌드박스 내부의 [BUNDLE_ID].plist 파일에 저장됩니다.
• NSUserDefaults를 사용해 저장된 모든 키/값 쌍은 이 파일에서 찾을 수 있습니다.
• tmp/
• 앱 실행 간에 유지될 필요가 없는 임시 파일을 쓰는 데 이 디렉터리를 사용합니다.
• 비영구적 캐시 파일을 포함합니다.
• 사용자에게 보이지 않습니다.
• 이 디렉터리의 내용은 백업되지 않습니다.
• OS는 앱이 실행 중이 아니고 저장 공간이 부족할 때 이 디렉터리의 파일들을 자동으로 삭제할 수 있습니다.

번들 디렉터리(/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app) 내부에 있는 iGoat-Swift의 Application Bundle (.app) 디렉터리를 좀 더 자세히 살펴보겠습니다:

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType      Perms  NSFileProtection    ...  Name
------------  -------  ------------------  ...  --------------------------------------
Regular           420  None                ...  rutger.html
Regular           420  None                ...  mansi.html
Regular           420  None                ...  splash.html
Regular           420  None                ...  about.html

Regular           420  None                ...  LICENSE.txt
Regular           420  None                ...  Sentinel.txt
Regular           420  None                ...  README.txt

Binary Reversing

Inside the <application-name>.app folder you will find a binary file called <application-name>. <application-name>.app 폴더 안에는 <application-name>라는 binary 파일이 있습니다. 이것이 실제로 실행되는 파일입니다. 도구 **otool**을 사용해 binary를 기본적으로 검사할 수 있습니다:

otool -Vh DVIA-v2 #Check some compilation attributes
magic  cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64    ARM64        ALL  0x00     EXECUTE    65       7112   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE

otool -L DVIA-v2 #Get third party libraries
DVIA-v2:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.1)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 274.6.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
@rpath/Bolts.framework/Bolts (compatibility version 1.0.0, current version 1.0.0)
[...]

앱이 암호화되어 있는지 확인

다음에 대한 출력이 있는지 확인하세요:

otool -l <app-binary> | grep -A 4 LC_ENCRYPTION_INFO

바이너리 디스어셈블

텍스트 섹션을 디스어셈블하세요:

otool -tV DVIA-v2
DVIA-v2:
(__TEXT,__text) section
+[DDLog initialize]:
0000000100004ab8    sub    sp, sp, #0x60
0000000100004abc    stp    x29, x30, [sp, #0x50]   ; Latency: 6
0000000100004ac0    add    x29, sp, #0x50
0000000100004ac4    sub    x8, x29, #0x10
0000000100004ac8    mov    x9, #0x0
0000000100004acc    adrp    x10, 1098 ; 0x10044e000
0000000100004ad0    add    x10, x10, #0x268

샘플 애플리케이션의 Objective-C segment을 출력하려면 다음을 사용할 수 있습니다:

otool -oV DVIA-v2
DVIA-v2:
Contents of (__DATA,__objc_classlist) section
00000001003dd5b8 0x1004423d0 _OBJC_CLASS_$_DDLog
isa        0x1004423a8 _OBJC_METACLASS_$_DDLog
superclass 0x0 _OBJC_CLASS_$_NSObject
cache      0x0 __objc_empty_cache
vtable     0x0
data       0x1003de748
flags          0x80
instanceStart  8

더 간결한 Objective-C 코드를 얻기 위해 class-dump을 사용할 수 있습니다:

class-dump some-app
//
//     Generated by class-dump 3.5 (64 bit).
//
//     class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2013 by Steve Nygard.
//

#pragma mark Named Structures

struct CGPoint {
double _field1;
double _field2;
};

struct CGRect {
struct CGPoint _field1;
struct CGSize _field2;
};

struct CGSize {
double _field1;
double _field2;
};

However, the best options to disassemble the binary are: Hopper and IDA.

데이터 저장

To learn about how iOS stores data in the device read this page:

iOS Basics

Warning

다음의 정보 저장 위치들은 애플리케이션 설치 직후, 애플리케이션의 모든 기능을 확인한 후 및 심지어 한 사용자에서 로그아웃하고 다른 사용자로 로그인한 후에도 확인되어야 합니다.
목표는 애플리케이션의 보호되지 않은 민감한 정보(비밀번호, 토큰), 현재 사용자 및 이전에 로그인했던 사용자들의 민감한 정보를 찾는 것입니다.

Plist

plist 파일은 구조화된 XML 파일로 키-값 쌍을 포함합니다. 이는 영구 데이터를 저장하는 방법이므로 때때로 이러한 파일에서 민감한 정보를 찾을 수 있습니다. 앱 설치 후 및 앱을 집중적으로 사용한 후에 이 파일들을 확인하여 새 데이터가 기록되는지 확인하는 것이 권장됩니다.

plist 파일에 데이터를 영구 저장하는 가장 일반적인 방법은 NSUserDefaults의 사용입니다. 이 plist 파일은 앱 샌드박스의 Library/Preferences/<appBundleID>.plist 안에 저장됩니다.

NSUserDefaults 클래스는 기본 시스템과 상호작용하기 위한 프로그래밍 인터페이스를 제공합니다. 기본 시스템은 애플리케이션이 사용자 설정에 따라 동작을 맞춤화할 수 있게 합니다. NSUserDefaults로 저장된 데이터는 애플리케이션 번들에서 볼 수 있습니다. 이 클래스는 plist 파일에 데이터를 저장하지만, 소량의 데이터 사용을 목적으로 합니다.

이 데이터는 더 이상 신뢰된 컴퓨터를 통해 직접 접근할 수 없지만, backup을 수행하면 접근할 수 있습니다.

objection의 ios nsuserdefaults get 명령으로 NSUserDefaults에 저장된 정보를 dump할 수 있습니다.

애플리케이션에서 사용되는 모든 plist를 찾으려면 /private/var/mobile/Containers/Data/Application/{APPID}로 접근한 다음 다음을 실행하세요:

find ./ -name "*.plist"

파일을 XML or binary (bplist) 형식에서 XML로 변환하려면 운영체제에 따라 여러 방법이 있습니다:

macOS 사용자: plutil 명령을 사용하세요. 이 명령은 macOS (10.2+)에 내장된 도구로, 이 용도로 설계되었습니다:

$ plutil -convert xml1 Info.plist

Linux 사용자의 경우: 먼저 libplist-utils를 설치한 다음, plistutil을 사용하여 파일을 변환하세요:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Within an Objection Session: 모바일 애플리케이션을 분석할 때, 특정 명령으로 plist 파일을 직접 변환할 수 있습니다:

ios plist cat /private/var/mobile/Containers/Data/Application/<Application-UUID>/Library/Preferences/com.some.package.app.plist

Core Data

Core Data는 애플리케이션의 객체 모델 계층을 관리하기 위한 프레임워크입니다. Core Data can use SQLite as its persistent store, 하지만 프레임워크 자체는 데이터베이스가 아닙니다.\
CoreData는 기본적으로 데이터를 암호화하지 않습니다. 하지만 추가 암호화 레이어를 CoreData에 적용할 수 있습니다. 자세한 내용은 GitHub Repo를 참조하세요.

애플리케이션의 SQLite Core Data 정보는 경로 /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support에서 찾을 수 있습니다.

만약 SQLite를 열어 민감한 정보에 접근할 수 있다면, 이는 구성 오류(misconfiguration)를 발견한 것입니다.

-(void)storeDetails {
AppDelegate * appDelegate = (AppDelegate *)(UIApplication.sharedApplication.delegate);

NSManagedObjectContext *context =[appDelegate managedObjectContext];

User *user = [self fetchUser];
if (user) {
return;
}
user = [NSEntityDescription insertNewObjectForEntityForName:@"User"
inManagedObjectContext:context];
user.email = CoreDataEmail;
user.password = CoreDataPassword;
NSError *error;
if (![context save:&error]) {
NSLog(@"Error in saving data: %@", [error localizedDescription]);

}else{
NSLog(@"data stored in core data");
}
}

YapDatabase

YapDatabase는 SQLite 위에 구축된 키/값 저장소입니다.
YapDatabase는 SQLite 데이터베이스이므로 이전 섹션에서 제시한 명령으로 찾을 수 있습니다.

기타 SQLite 데이터베이스

애플리케이션이 자체 SQLite 데이터베이스를 생성하는 것은 흔합니다. 이들에는 저장 민감한 데이터가 있고 암호화되지 않은 채 남겨둘 수 있습니다. 따라서 애플리케이션 디렉터리 내의 모든 데이터베이스를 확인하는 것이 항상 흥미롭습니다. 따라서 데이터가 저장된 애플리케이션 디렉터리로 이동하세요 (/private/var/mobile/Containers/Data/Application/{APPID})

find ./ -name "*.sqlite" -or -name "*.db"

Firebase Real-Time Databases

개발자는 Firebase Real-Time Databases를 통해 데이터를 저장하고 동기화할 수 있는 NoSQL 클라우드 호스팅 데이터베이스를 사용할 수 있습니다. 데이터는 JSON 형식으로 저장되며, 연결된 모든 클라이언트에 실시간으로 동기화됩니다.

You can find how to check for misconfigured Firebase databases here:

Firebase Database

Realm databases

Realm Objective-C and Realm Swift는 Apple에서 제공하지 않는 강력한 데이터 저장 대안을 제공합니다. 기본적으로 데이터를 암호화하지 않고 저장하며, 특정 구성으로 암호화를 사용할 수 있습니다.

The databases are located at: /private/var/mobile/Containers/Data/Application/{APPID}. To explore these files, one can utilize commands like:

iPhone:/private/var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents root# ls
default.realm  default.realm.lock  default.realm.management/  default.realm.note|

$ find ./ -name "*.realm*"

이 데이터베이스 파일을 보려면 Realm Studio 도구를 권장합니다.

Realm 데이터베이스 내에서 암호화를 구현하려면, 다음 코드 스니펫을 사용할 수 있습니다:

// Open the encrypted Realm file where getKey() is a method to obtain a key from the Keychain or a server
let config = Realm.Configuration(encryptionKey: getKey())
do {
let realm = try Realm(configuration: config)
// Use the Realm as normal
} catch let error as NSError {
// If the encryption key is wrong, `error` will say that it's an invalid database
fatalError("Error opening realm: \(error)")
}

Couchbase Lite 데이터베이스

Couchbase Lite 는 경량이고 임베디드된 데이터베이스 엔진으로, 문서 지향 (NoSQL) 방식을 따른다고 설명됩니다. iOS 및 macOS에 네이티브로 설계되어 데이터 동기화를 원활하게 제공합니다.

장치에서 잠재적인 Couchbase 데이터베이스를 식별하려면, 다음 디렉터리를 검사해야 합니다:

ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/

Cookies

iOS는 각 앱 폴더 안의 **Library/Cookies/cookies.binarycookies**에 앱의 cookies를 저장합니다. 그러나 개발자들은 때때로 이를 keychain에 저장하기로 결정하는데, 언급한 언급된 cookie 파일은 백업에서 접근할 수 있습니다.

cookies 파일을 검사하려면 this python script을 사용하거나 objection의 ios cookies get.
objection을 사용하여 이러한 파일을 JSON 형식으로 변환하고 데이터를 검사할 수 있습니다.

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
[
{
"domain": "highaltitudehacks.com",
"expiresDate": "2051-09-15 07:46:43 +0000",
"isHTTPOnly": "false",
"isSecure": "false",
"name": "username",
"path": "/",
"value": "admin123",
"version": "0"
}
]

캐시

기본적으로 NSURLSession은 Cache.db 데이터베이스에 HTTP requests and responses in the Cache.db와 같은 데이터를 저장합니다. 이 데이터베이스에는 토큰, 사용자명 또는 기타 민감한 정보가 캐시되어 있다면 민감한 데이터가 포함될 수 있습니다. 캐시된 정보를 찾으려면 앱의 데이터 디렉터리(/var/mobile/Containers/Data/Application/<UUID>)를 열고 /Library/Caches/<Bundle Identifier>로 이동하세요. WebKit cache is also being stored in the Cache.db 파일도 Cache.db에 저장됩니다. Objection는 sqlite connect Cache.db 명령으로 데이터베이스를 열고 상호작용할 수 있는데, 이는 normal SQLite database이기 때문입니다.

이 데이터는 요청이나 응답에 민감한 정보가 포함될 수 있으므로 이 데이터를 캐싱하지 않도록 권장합니다. 아래 목록은 이를 달성하는 다양한 방법을 보여줍니다:

1. 로그아웃 후 캐시된 응답을 제거하는 것이 권장됩니다. 이는 Apple에서 제공하는 removeAllCachedResponses 메서드로 수행할 수 있습니다. 다음과 같이 호출할 수 있습니다:

URLCache.shared.removeAllCachedResponses()

이 메서드는 Cache.db 파일에서 모든 캐시된 요청과 응답을 제거합니다.

2. 쿠키의 이점을 사용할 필요가 없다면 URLSession의 .ephemeral 구성 속성을 사용하는 것이 권장됩니다. 이는 쿠키와 캐시 저장을 비활성화합니다.

Apple documentation:

An ephemeral session configuration object is similar to a default session configuration (see default), except that the corresponding session object doesn’t store caches, credential stores, or any session-related data to disk. Instead, session-related data is stored in RAM. The only time an ephemeral session writes data to disk is when you tell it to write the contents of a URL to a file.

3. Cache Policy를 .notAllowed로 설정하여 캐시를 비활성화할 수도 있습니다. 이렇게 하면 메모리나 디스크 어느 쪽에도 Cache가 저장되지 않습니다.

스냅샷

홈 버튼을 누를 때마다 iOS는 전환을 부드럽게 하기 위해 현재 화면의 스냅샷을 찍습니다. 그러나 현재 화면에 민감한 데이터가 있는 경우, 해당 데이터는 이미지에 저장되어 (재부팅을 걸쳐 지속됩니다). 이러한 스냅샷은 홈 버튼을 두 번 탭하여 앱 간 전환할 때도 접근할 수 있는 스냅샷입니다.

iPhone이 탈옥되지 않았다면, 이러한 스크린샷을 보려면 attacker가 access를 device에 대해 unblocked 상태로 가지고 있어야 합니다. 기본적으로 마지막 스냅샷은 애플리케이션 샌드박스의 Library/Caches/Snapshots/ 또는 Library/SplashBoard/Snapshots 폴더에 저장됩니다 (trusted computers는 iOX 7.0부터 파일시스템에 접근할 수 없습니다).

이러한 동작을 방지하는 한 가지 방법은 ApplicationDidEnterBackground() 함수를 사용하여 스냅샷을 찍기 전에 빈 화면을 표시하거나 민감한 데이터를 제거하는 것입니다.

다음은 기본 스크린샷을 설정하는 샘플 수정 방법입니다.

Swift:

private var backgroundImage: UIImageView?

func applicationDidEnterBackground(_ application: UIApplication) {
let myBanner = UIImageView(image: #imageLiteral(resourceName: "overlayImage"))
myBanner.frame = UIScreen.main.bounds
backgroundImage = myBanner
window?.addSubview(myBanner)
}

func applicationWillEnterForeground(_ application: UIApplication) {
backgroundImage?.removeFromSuperview()
}

Objective-C:

@property (UIImageView *)backgroundImage;

- (void)applicationDidEnterBackground:(UIApplication *)application {
UIImageView *myBanner = [[UIImageView alloc] initWithImage:@"overlayImage.png"];
self.backgroundImage = myBanner;
self.backgroundImage.bounds = UIScreen.mainScreen.bounds;
[self.window addSubview:myBanner];
}

- (void)applicationWillEnterForeground:(UIApplication *)application {
[self.backgroundImage removeFromSuperview];
}

이 설정은 애플리케이션이 백그라운드로 전환될 때마다 배경 이미지를 overlayImage.png로 설정합니다. overlayImage.png가 항상 현재 뷰를 덮어쓰기 때문에 민감한 데이터의 leaks를 방지합니다.

Keychain

iOS keychain에 접근하고 관리하기 위해, jailbroken 장치에 적합한 Keychain-Dumper와 같은 도구들이 있습니다. 또한 Objection는 유사한 목적을 위해 ios keychain dump 명령을 제공합니다.

자격 증명 저장

NSURLCredential 클래스는 NSUserDefaults나 기타 래퍼를 우회하여 민감한 정보를 직접 keychain에 저장하기에 이상적입니다. 로그인 후 자격 증명을 저장하려면, 다음 Swift 코드를 사용합니다:

NSURLCredential *credential;
credential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistencePermanent];
[[NSURLCredentialStorage sharedCredentialStorage] setCredential:credential forProtectionSpace:self.loginProtectionSpace];

To extract these stored credentials, Objection’s command ios nsurlcredentialstorage dump is utilized.

Custom Keyboards and Keyboard Cache

iOS 8.0 이후부터 사용자는 custom keyboard extensions를 설치할 수 있으며, 이는 설정 > 일반 > 키보드 > 키보드에서 관리할 수 있다. 이러한 키보드는 기능을 확장하지만 키 입력 로그를 기록하거나 외부 서버로 데이터를 전송할 위험이 있으며, 네트워크 접근이 필요한 키보드에 대해서는 사용자에게 알림이 제공된다. 앱은 민감한 정보 입력 시 custom keyboards의 사용을 제한해야 한다.

Security Recommendations:

• 보안을 강화하기 위해 서드파티 키보드를 비활성화하는 것이 권장된다.
• 기본 iOS 키보드의 autocorrect 및 auto-suggestions 기능이 Library/Keyboard/{locale}-dynamic-text.dat 또는 /private/var/mobile/Library/Keyboard/dynamic-text.dat에 민감한 정보를 저장할 수 있음을 인지해야 한다. 이러한 캐시 파일은 정기적으로 민감한 정보가 있는지 확인해야 한다. 캐시된 데이터를 지우기 위해 설정 > 일반 > 재설정 > 키보드 사전 재설정을 통해 키보드 사전을 초기화하는 것이 권장된다.
• 네트워크 트래픽을 가로채면 custom keyboard가 원격으로 키 입력을 전송하는지 여부를 확인할 수 있다.

Preventing Text Field Caching

The UITextInputTraits protocol offers properties to manage autocorrection and secure text entry, essential for preventing sensitive information caching. For example, disabling autocorrection and enabling secure text entry can be achieved with:

textObject.autocorrectionType = UITextAutocorrectionTypeNo;
textObject.secureTextEntry = YES;

또한 개발자는 텍스트 필드(특히 비밀번호 및 PIN과 같은 민감한 정보를 입력하는 필드)가 autocorrectionType을 UITextAutocorrectionTypeNo로, secureTextEntry를 YES로 설정하여 캐싱을 비활성화하도록 해야 합니다.

UITextField *textField = [[UITextField alloc] initWithFrame:frame];
textField.autocorrectionType = UITextAutocorrectionTypeNo;

Logs

디버깅은 종종 logging을 사용합니다. 위험이 있는데, logs에 민감한 정보가 포함될 수 있습니다. 과거(iOS 6 및 이전 버전)에는 모든 앱이 logs에 접근할 수 있어서 민감한 데이터 leak 위험이 있었습니다. 이제 애플리케이션은 자신의 logs에만 접근하도록 제한됩니다.

이러한 제약에도 불구하고, 잠금 해제된 장치에 대한 물리적 접근 권한이 있는 공격자는 장치를 컴퓨터에 연결하고 logs를 읽는 것으로 이를 악용할 수 있습니다. 앱을 삭제한 후에도 logs는 디스크에 남아 있다는 점을 유의해야 합니다.

위험을 완화하려면, 앱과 철저히 상호작용하면서 모든 기능과 입력을 확인하여 민감한 정보가 의도치 않게 logged되지 않는지 확인하는 것이 좋습니다.

앱의 소스코드를 잠재적 leak에 대해 검토할 때는, 사전 정의된 및 custom logging statements를 모두 찾아보세요. 내장 함수용 키워드인 NSLog, NSAssert, NSCAssert, fprintf와, 커스텀 구현의 경우 Logging 또는 Logfile 언급을 확인하세요.

Monitoring System Logs

앱은 민감할 수 있는 다양한 정보를 log합니다. 이러한 logs를 모니터링하기 위해 다음과 같은 도구와 명령어를 사용합니다:

idevice_id --list   # To find the device ID
idevicesyslog -u <id> (| grep <app>)   # To capture the device logs

유용합니다. 추가로, Xcode는 콘솔 로그를 수집하는 방법을 제공합니다:

1. Xcode를 엽니다.
2. iOS 장치를 연결합니다.
3. Window -> Devices and Simulators로 이동합니다.
4. 장치를 선택합니다.
5. 조사 중인 문제를 재현합니다.
6. Open Console 버튼을 사용하여 새 창에서 로그를 확인합니다.

더 고급 로깅을 위해, 장치 쉘에 연결하고 socat을 사용하면 실시간 로그 모니터링을 할 수 있습니다:

iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock

로그 활동을 관찰하는 명령들이 뒤따르며, 이는 문제 진단이나 로그에서 잠재적인 data leakage를 식별하는 데 매우 유용할 수 있습니다.

백업

자동 백업 기능은 iOS에 통합되어 있어 iTunes(최대 macOS Catalina), Finder(macOS Catalina 이후) 또는 iCloud를 통해 기기 데이터 복사본을 생성할 수 있습니다. 이러한 백업은 Apple Pay 정보나 Touch ID 설정과 같은 고도로 민감한 항목을 제외한 거의 모든 기기 데이터를 포함합니다.

보안 위험

백업에 설치된 앱과 그 데이터가 포함되면 잠재적인 data leakage 문제와 백업 수정으로 인해 앱 기능이 변경될 수 있는 위험이 발생합니다. 이러한 위험을 완화하기 위해 어떤 앱의 디렉터리나 하위 디렉터리에 민감한 정보를 **평문(plaintext)**으로 저장하지 않는 것이 권장됩니다.

백업에서 파일 제외

Documents/ 및 Library/Application Support/의 파일은 기본적으로 백업됩니다. 개발자는 NSURL setResourceValue:forKey:error:와 NSURLIsExcludedFromBackupKey를 사용하여 특정 파일이나 디렉터리를 백업에서 제외할 수 있습니다. 이 방법은 민감한 데이터가 백업에 포함되는 것을 방지하는 데 매우 중요합니다.

취약점 테스트

앱의 백업 보안을 평가하려면 Finder를 사용해 백업을 생성한 다음 Apple’s official documentation의 안내를 따라 해당 백업을 찾으세요. 백업을 분석하여 앱 동작에 영향을 줄 수 있도록 변경될 수 있는 민감한 데이터나 설정을 확인합니다.

민감한 정보는 명령줄 도구나 iMazing 같은 애플리케이션을 사용해 찾을 수 있습니다. 암호화된 백업의 경우, 백업 루트의 “Manifest.plist” 파일에서 “IsEncrypted” 키를 확인해 암호화 여부를 확인할 수 있습니다.

<?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">
...
<key>Date</key>
<date>2021-03-12T17:43:33Z</date>
<key>IsEncrypted</key>
<true/>
...
</plist>

암호화된 백업을 다룰 때, DinoSec’s GitHub repo에 있는 Python 스크립트, 예를 들어 backup_tool.py와 backup_passwd.py가 유용할 수 있지만 최신 iTunes/Finder 버전과의 호환성을 위해 조정이 필요할 수 있습니다. iOSbackup tool은 암호로 보호된 백업 내 파일에 접근하는 또 다른 옵션입니다.

앱 동작 변경

백업 수정을 통해 앱 동작을 변경하는 예로는 Bither bitcoin wallet app이 있는데, 여기서는 UI lock PIN이 net.bither.plist의 pin_code 키에 저장되어 있습니다. plist에서 이 키를 제거하고 백업을 복원하면 PIN 요구가 사라져 제한 없는 접근이 가능합니다.

민감한 데이터에 대한 메모리 테스트 요약

애플리케이션 메모리에 저장된 민감한 정보를 다룰 때는 해당 데이터의 노출 시간을 최소화하는 것이 중요합니다. 메모리 내용을 조사하는 주요 방법은 두 가지로, 메모리 덤프 생성과 실시간 메모리 분석입니다. 두 방법 모두 덤프 과정이나 분석 중에 중요한 데이터를 놓칠 수 있는 등의 어려움이 있습니다.

메모리 덤프 획득 및 분석

탈옥 및 비탈옥 기기 모두에서 objection과 Fridump 같은 도구는 앱의 프로세스 메모리를 덤프할 수 있습니다. 덤프한 후에는 찾고자 하는 정보의 성격에 따라 다양한 도구를 사용해 이 데이터를 분석해야 합니다.

메모리 덤프에서 문자열을 추출하려면 strings 또는 rabin2 -zz와 같은 명령을 사용할 수 있습니다:

# Extracting strings using strings command
$ strings memory > strings.txt

# Extracting strings using rabin2
$ rabin2 -ZZ memory > strings.txt

특정 데이터 유형이나 패턴을 검색하는 것을 포함한 보다 상세한 분석을 위해, radare2는 광범위한 검색 기능을 제공합니다:

$ r2 <name_of_your_dump_file>
[0x00000000]> /?
...

런타임 메모리 분석

r2frida는 memory dump 없이도 애플리케이션의 메모리를 실시간으로 검사할 수 있는 강력한 대안입니다. 이 도구는 실행 중인 애플리케이션의 메모리에서 직접 검색 명령을 실행할 수 있게 해줍니다:

$ r2 frida://usb//<name_of_your_app>
[0x00000000]> /\ <search_command>

취약한 암호화

부적절한 키 관리 프로세스

일부 개발자는 민감한 데이터를 로컬 스토리지에 저장하고 코드 내에 hardcoded/predictable된 키로 암호화합니다. 이는 리버싱으로 인해 공격자가 기밀 정보를 추출할 수 있으므로 해서는 안 됩니다.

안전하지 않거나/또는 더 이상 권장되지 않는 알고리즘 사용

개발자는 권한 부여를 위한 deprecated algorithms을 사용하여 checks, 데이터를 store하거나 send해서는 안 됩니다. 이러한 알고리즘의 예로는 RC4, MD4, MD5, SHA1 등이 있습니다. 예를 들어 비밀번호를 저장하기 위해 hashes를 사용하는 경우, salt와 함께 brute-force에 resistant한 해시를 사용해야 합니다.

점검

주요 점검 항목은 코드 내에 hardcoded된 비밀번호/시크릿이 있는지, 또는 그것들이 predictable한지, 그리고 코드가 어떤 종류의 weak cryptography 알고리즘을 사용하고 있는지 여부를 확인하는 것입니다.

특히 objection을 사용하면 일부 crypto libraries를 자동으로 monitor할 수 있다는 점이 유용합니다:

ios monitor crypt

iOS 암호화 API 및 라이브러리에 대한 자세한 정보는 https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography를 참조하세요.

로컬 인증

로컬 인증은 특히 암호화된 방법으로 원격 엔드포인트에 대한 접근을 보호할 때 중요한 역할을 합니다. 적절하게 구현되지 않으면 로컬 인증 메커니즘은 우회될 수 있습니다.

Apple의 Local Authentication framework 및 keychain은 각각 개발자가 사용자 인증 대화상자를 제공하고 비밀 데이터를 안전하게 처리할 수 있도록 강력한 API를 제공합니다. Secure Enclave는 Touch ID의 지문 ID를 보호하며, Face ID는 생체 데이터를 노출하지 않는 안면 인식에 의존합니다.

Touch ID/Face ID를 통합하려면 개발자는 두 가지 API 선택권이 있습니다:

• LocalAuthentication.framework: 생체 데이터에 접근하지 않는 고수준 사용자 인증용.
• Security.framework: 더 낮은 수준의 keychain 서비스 접근을 위해, 생체 인증으로 비밀 데이터를 보호할 수 있음. 다양한 open-source wrappers가 keychain 접근을 단순화합니다.

Caution

하지만 LocalAuthentication.framework와 Security.framework는 주로 boolean 값을 반환하고 인증 과정에서 데이터를 전송하지 않기 때문에 우회될 수 있는 취약점이 있습니다 (자세한 내용은 Don’t touch me that way, by David Lindner et al 참조).

로컬 인증 구현

사용자에게 인증을 요청하려면 개발자는 LAContext 클래스 내의 evaluatePolicy 메서드를 사용해야 하며, 다음 중 하나를 선택합니다:

• deviceOwnerAuthentication: Touch ID 또는 기기 암호를 요구하며, 둘 다 활성화되어 있지 않으면 실패합니다.
• deviceOwnerAuthenticationWithBiometrics: Touch ID만을 요구합니다.

성공적인 인증은 **evaluatePolicy**가 반환하는 boolean 값으로 표시되며, 이는 잠재적인 보안 결함을 시사합니다.

Keychain을 사용한 로컬 인증

iOS 앱에서 로컬 인증을 구현할 때는 인증 토큰과 같은 비밀 데이터를 안전하게 저장하기 위해 keychain API를 사용합니다. 이 과정은 데이터에 기기 암호나 Touch ID 같은 생체 인증으로만 사용자가 접근할 수 있도록 보장합니다.

keychain은 SecAccessControl 속성으로 항목을 설정할 수 있는 기능을 제공하며, 이는 사용자가 Touch ID 또는 기기 암호로 성공적으로 인증할 때까지 항목에 대한 접근을 제한합니다. 이 기능은 보안을 강화하는 데 중요합니다.

아래는 Swift 및 Objective-C로 작성된 코드 예제로, 이러한 보안 기능을 활용하여 문자열을 keychain에 저장하고 불러오는 방법을 보여줍니다. 예제는 특히 Touch ID 인증을 요구하도록 접근 제어를 설정하고, 기기 암호가 구성된 경우에만 데이터를 설정된 기기에서만 접근 가능하도록 보장하는 방법을 설명합니다.

// From https://github.com/mufambisi/owasp-mstg/blob/master/Document/0x06f-Testing-Local-Authentication.md

// 1. create AccessControl object that will represent authentication settings

var error: Unmanaged<CFError>?

guard let accessControl = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
SecAccessControlCreateFlags.biometryCurrentSet,
&error) else {
// failed to create AccessControl object

return
}

// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute

var query: [String: Any] = [:]

query[kSecClass as String] = kSecClassGenericPassword
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecAttrAccount as String] = "OWASP Account" as CFString
query[kSecValueData as String] = "test_strong_password".data(using: .utf8)! as CFData
query[kSecAttrAccessControl as String] = accessControl

// 3. save item

let status = SecItemAdd(query as CFDictionary, nil)

if status == noErr {
// successfully saved
} else {
// error while saving
}

// 1. create AccessControl object that will represent authentication settings
CFErrorRef *err = nil;

SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
kSecAccessControlUserPresence,
err);

// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute
NSDictionary* query = @{
(_ _bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecAttrAccount: @"OWASP Account",
(__bridge id)kSecValueData: [@"test_strong_password" dataUsingEncoding:NSUTF8StringEncoding],
(__bridge id)kSecAttrAccessControl: (__bridge_transfer id)sacRef
};

// 3. save item
OSStatus status = SecItemAdd((__bridge CFDictionaryRef)query, nil);

if (status == noErr) {
// successfully saved
} else {
// error while saving
}

이제 keychain에서 저장된 항목을 요청할 수 있습니다. Keychain services는 사용자에게 인증 대화상자를 표시하고 적절한 fingerprint가 제공되었는지에 따라 data 또는 nil을 반환합니다.

// 1. define query
var query = [String: Any]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecReturnData as String] = kCFBooleanTrue
query[kSecAttrAccount as String] = "My Name" as CFString
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecUseOperationPrompt as String] = "Please, pass authorisation to enter this area" as CFString

// 2. get item
var queryResult: AnyObject?
let status = withUnsafeMutablePointer(to: &queryResult) {
SecItemCopyMatching(query as CFDictionary, UnsafeMutablePointer($0))
}

if status == noErr {
let password = String(data: queryResult as! Data, encoding: .utf8)!
// successfully received password
} else {
// authorization not passed
}

// 1. define query
NSDictionary *query = @{(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecReturnData: @YES,
(__bridge id)kSecAttrAccount: @"My Name1",
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecUseOperationPrompt: @"Please, pass authorisation to enter this area" };

// 2. get item
CFTypeRef queryResult = NULL;
OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, &queryResult);

if (status == noErr){
NSData* resultData = ( __bridge_transfer NSData* )queryResult;
NSString* password = [[NSString alloc] initWithData:resultData encoding:NSUTF8StringEncoding];
NSLog(@"%@", password);
} else {
NSLog(@"Something went wrong");
}

탐지

앱에서 프레임워크 사용은 앱 바이너리의 공유 동적 라이브러리 목록을 분석해 탐지할 수 있습니다. 이는 otool을 사용하여 수행할 수 있습니다:

$ otool -L <AppName>.app/<AppName>

앱에서 LocalAuthentication.framework가 사용되는 경우, 출력에는 다음의 두 줄이 모두 포함됩니다 (참고: LocalAuthentication.framework는 내부적으로 Security.framework를 사용합니다):

/System/Library/Frameworks/LocalAuthentication.framework/LocalAuthentication
/System/Library/Frameworks/Security.framework/Security

만약 Security.framework가 사용되는 경우, 두 번째 것만 표시됩니다.

Local Authentication Framework 우회

Objection

이 Objection Biometrics Bypass는 this GitHub page에 위치해 있으며, LocalAuthentication 메커니즘을 우회하기 위한 기법을 제공합니다. 이 접근법의 핵심은 Frida를 활용해 evaluatePolicy 함수를 조작하여, 실제 인증 성공 여부와 관계없이 항상 True 결과를 반환하도록 하는 것입니다. 이는 결함이 있는 생체 인증 절차를 회피할 때 특히 유용합니다.

이 우회를 활성화하려면 다음 명령을 사용합니다:

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios ui biometrics_bypass
(agent) Registering job 3mhtws9x47q. Type: ios-biometrics-disable
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # (agent) [3mhtws9x47q] Localized Reason for auth requirement: Please authenticate yourself
(agent) [3mhtws9x47q] OS authentication response: false
(agent) [3mhtws9x47q] Marking OS response as True instead
(agent) [3mhtws9x47q] Biometrics bypass hook complete

이 명령은 Objection이 evaluatePolicy 체크의 결과를 사실상 True로 변경하는 작업을 등록하는 일련의 과정을 시작합니다.

Frida

다음은 DVIA-v2 application에서의 evaluatePolicy 사용 예입니다:

+(void)authenticateWithTouchID {
LAContext *myContext = [[LAContext alloc] init];
NSError *authError = nil;
NSString *myLocalizedReasonString = @"Please authenticate yourself";

if ([myContext canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&authError]) {
[myContext evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
localizedReason:myLocalizedReasonString
reply:^(BOOL success, NSError *error) {
if (success) {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Successful" withTitle:@"Success"];
});
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Failed !" withTitle:@"Error"];
});
}
}];
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Your device doesn't support Touch ID or you haven't configured Touch ID authentication on your device" withTitle:@"Error"];
});
}
}

Local Authentication의 bypass를 달성하기 위해 Frida 스크립트를 작성한다. 이 스크립트는 evaluatePolicy 검사를 겨냥하여 그 callback을 가로채 success=1을 반환하도록 보장한다. callback의 동작을 변경함으로써 인증 검사는 사실상 bypass된다.

아래 스크립트는 evaluatePolicy 메서드의 결과를 수정하기 위해 주입된다. 이 스크립트는 callback의 결과를 항상 성공을 나타내도록 변경한다.

// from https://securitycafe.ro/2022/09/05/mobile-pentesting-101-bypassing-biometric-authentication/
if(ObjC.available) {
console.log("Injecting...");
var hook = ObjC.classes.LAContext["- evaluatePolicy:localizedReason:reply:"];
Interceptor.attach(hook.implementation, {
onEnter: function(args) {
var block = new ObjC.Block(args[4]);
const callback = block.implementation;
block.implementation = function (error, value)  {

console.log("Changing the result value to true")
const result = callback(1, null);
return result;
};
},
});
} else {
console.log("Objective-C Runtime is not available!");
}

Frida 스크립트를 주입하고 생체 인증을 bypass하려면, 다음 명령을 사용합니다:

frida -U -f com.highaltitudehacks.DVIAswiftv2 --no-pause -l fingerprint-bypass-ios.js

IPC를 통한 민감한 기능 노출

Custom URI Handlers / Deeplinks / Custom Schemes

iOS Custom URI Handlers / Deeplinks / Custom Schemes

Universal Links

iOS Universal Links

UIActivity Sharing

iOS UIActivity Sharing

UIPasteboard

iOS UIPasteboard

App Extensions

iOS App Extensions

WebViews

iOS WebViews

Serialisation and Encoding

iOS Serialisation and Encoding

네트워크 통신

암호화 없이 통신이 발생하지 않는지, 그리고 애플리케이션이 서버의 TLS certificate를 올바르게 검증하고 있는지 확인하는 것이 중요합니다.
이러한 문제를 확인하기 위해 Burp와 같은 프록시를 사용할 수 있습니다:

iOS Burp Suite Configuration

호스트명 검사

TLS certificate를 검증할 때 흔한 문제는 인증서가 trusted CA에 의해 서명되었는지만 확인하고, 인증서의 the hostname가 실제로 접속하려는 호스트명인지 확인하지 않는 것입니다.
이 문제를 Burp로 확인하려면, iPhone에서 Burp CA를 신뢰한 뒤 Burp로 다른 hostname에 대한 새로운 인증서를 생성하여 사용해 보세요. 애플리케이션이 여전히 작동하면 취약한 것입니다.

Certificate Pinning

애플리케이션이 SSL Pinning을 올바르게 사용하고 있다면, 애플리케이션은 기대한 인증서일 때만 작동합니다. 테스트 시 Burp가 자체 인증서를 제공하기 때문에 문제가 될 수 있습니다.
jailbroken 기기 내에서 이 보호를 우회하려면 애플리케이션 SSL Kill Switch를 설치하거나 Burp Mobile Assistant를 설치할 수 있습니다.

또한 objection’s ios sslpinning disable를 사용할 수도 있습니다.

기타

• /System/Library 에는 시스템 애플리케이션에서 사용하는 프레임워크들이 있습니다.
• App Store에서 사용자가 설치한 애플리케이션은 /User/Applications 내부에 위치합니다.
• /User/Library 는 사용자 레벨 애플리케이션이 저장한 데이터를 포함합니다.
• 애플리케이션 내에 저장된 노트를 읽으려면 /User/Library/Notes/notes.sqlite 에 접근할 수 있습니다.
• 설치된 애플리케이션의 폴더(/User/Applications/<APP ID>/) 내부에는 흥미로운 파일들이 있습니다:
  • iTunesArtwork: 앱에서 사용하는 아이콘
  • iTunesMetadata.plist: App Store에서 사용되는 앱 정보
  • /Library/*: 환경설정과 캐시를 포함. /Library/Cache/Snapshots/* 에는 애플리케이션이 백그라운드로 전환되기 전에 수행된 스냅샷이 있습니다.

Hot Patching/강제 업데이트

개발자는 애플리케이션을 App Store에 다시 제출하고 승인될 때까지 기다리지 않고도 원격으로 모든 설치본을 즉시 패치할 수 있습니다.
이를 위해 일반적으로 JSPatch를 사용합니다. 그러나 Siren이나 react-native-appstore-version-checker와 같은 다른 옵션도 있습니다.
이는 제3자 악성 SDK에 의해 악용될 수 있는 위험한 메커니즘이므로 자동 업데이트에 어떤 방법이 사용되는지(있다면) 확인하고 테스트하는 것이 권장됩니다. 이를 위해 이전 버전의 앱을 다운로드해 시도해볼 수 있습니다.

Third Parties

3rd party SDKs의 중요한 문제점은 그 기능들에 대한 세분화된 제어 부족입니다. 개발자는 SDK를 통합하면 잠재적 보안 취약점과 개인정보 문제를 포함한 모든 기능을 수용하거나, 아예 이점을 포기해야 하는 선택에 직면합니다. 종종 개발자는 이러한 SDK 내의 취약점을 직접 패치할 수 없습니다. 또한 SDK가 커뮤니티 내에서 신뢰를 얻으면 일부는 멀웨어를 포함하게 될 수도 있습니다.

서드파티 SDK가 제공하는 서비스는 사용자 행동 추적, 광고 표시, 사용자 경험 향상 등을 포함할 수 있습니다. 그러나 이는 개발자가 해당 라이브러리에서 실행되는 코드를 완전히 알지 못할 수 있어 개인정보 및 보안 위험을 초래합니다. 서드파티 서비스에 공유하는 정보는 필요한 것만으로 제한하고 민감한 데이터가 노출되지 않도록 하는 것이 중요합니다.

서드파티 서비스의 구현은 보통 독립 라이브러리 형태이거나 전체 SDK 형태로 제공됩니다. 사용자 개인정보를 보호하려면 이러한 서비스와 공유되는 모든 데이터는 개인 식별 정보(PII)가 노출되지 않도록 익명화되어야 합니다.

애플리케이션이 사용하는 라이브러리를 식별하려면 otool 명령을 사용할 수 있습니다. 이 도구는 애플리케이션과 해당 애플리케이션이 사용하는 각 공유 라이브러리에 대해 실행되어 추가 라이브러리를 발견하는 데 사용됩니다.

otool -L <application_path>

흥미로운 취약점 및 사례 연구

Air Keyboard Remote Input Injection

Itunesstored Bookassetd Sandbox Escape

Zero Click Messaging Image Parser Chains

참고 및 추가 자료

• https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06b-basic-security-testing#information-gathering
• iOS & Mobile App Pentesting - INE
• https://mas.owasp.org/MASTG/techniques/ios/MASTG-TECH-0057/
• https://mas.owasp.org/MASTG/techniques/ios/MASTG-TECH-0058/
• https://mas.owasp.org/MASTG/techniques/ios/MASTG-TECH-0059/
• https://mas.owasp.org/MASTG/iOS/0x06d-Testing-Data-Storage
• https://coderwall.com/p/kjb3lw/storing-password-in-keychain-the-smart-way
• https://mas.owasp.org/MASTG/tests/ios/MASVS-STORAGE/MASTG-TEST-0055/
• https://mas.owasp.org/MASTG/tests/ios/MASVS-STORAGE/MASTG-TEST-0053
• https://mas.owasp.org/MASTG/techniques/ios/MASTG-TECH-0060/
• https://mas.owasp.org/MASTG/tests/ios/MASVS-STORAGE/MASTG-TEST-0058
• https://mas.owasp.org/MASTG/tests/ios/MASVS-STORAGE/MASTG-TEST-0060
• https://mas.owasp.org/MASTG/Android/0x05f-Testing-Local-Authentication/
• https://mas.owasp.org/MASTG/tests/ios/MASVS-AUTH/MASTG-TEST-0064
• https://medium.com/securing/bypassing-your-apps-biometric-checks-on-ios-c2555c81a2dc
• https://mas.owasp.org/MASTG/tests/ios/MASVS-STORAGE/MASTG-TEST-0054
• https://github.com/ivRodriguezCA/RE-iOS-Apps/ iOS 무료 코스(https://syrion.me/blog/ios-swift-antijailbreak-bypass-frida/)
• https://www.sans.org/reading-room/whitepapers/testing/ipwn-apps-pentesting-ios-applications-34577
• https://www.slideshare.net/RyanISI/ios-appsecurityminicourse
• https://github.com/prateek147/DVIA
• https://github.com/prateek147/DVIA-v2
• https://github.com/OWASP/MSTG-Hacking-Playground%20
• OWASP iGoat https://github.com/OWASP/igoat <<< Objective-C 버전 https://github.com/OWASP/iGoat-Swift <<< Swift 버전
• https://github.com/authenticationfailure/WheresMyBrowser.iOS
• https://github.com/nabla-c0d3/ssl-kill-switch2

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

• 구독 계획 확인하기!
• **💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.