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 का समर्थन करें

सदस्यता योजनाओं की जांच करें!

हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**

हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।

परीक्षण वातावरण

इस पृष्ठ पर आप iOS simulator, emulators और jailbreaking: के बारे में जानकारी पा सकते हैं:

iOS Testing Environment

परीक्षण के दौरान कई संचालन सुझाए जाएंगे (डिवाइस से कनेक्ट करना, फाइलें पढ़ना/लिखना/अपलोड/डाउनलोड करना, कुछ tools का उपयोग करना…). इसलिए, यदि आप इनमें से किसी भी क्रिया को कैसे करना है नहीं जानते तो कृपया पृष्ठ पढ़ना शुरू करें:

iOS Basic Testing Operations

Tip

निम्नलिखित चरणों के लिए ऐप डिवाइस में इंस्टॉल होना चाहिए और ऐप का IPA file पहले से प्राप्त हो चुका होना चाहिए.
Read the Basic iOS Testing Operations page to learn how to do this.

बुनियादी Static Analysis

कुछ दिलचस्प iOS - IPA फाइल decompilers:

IPA फ़ाइल पर automatic Static Analysis करने के लिए MobSF टूल का उपयोग करने की सलाह दी जाती है।

बाइनरी में मौजूद protections की पहचान:

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

सेंसिटिव/इनसेक्योर Functions की पहचान

Weak Hashing Algorithms

# 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"

Insecure Random Functions

# 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"

Insecure ‘Malloc’ Function

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

# On linux
grep -iER "_malloc"

Insecure and Vulnerable Functions

# 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 detection विधियाँ

File System Checks: सामान्य jailbreak फ़ाइलों और डायरेक्टरीज़ की उपस्थिति खोजें, जैसे /Applications/Cydia.app या /Library/MobileSubstrate/MobileSubstrate.dylib.
Sandbox Violations: फ़ाइल सिस्टम के प्रतिबंधित क्षेत्रों तक पहुँचने का प्रयास करें, जो non-jailbroken डिवाइस पर ब्लॉक होना चाहिए।
API Checks: जांचें कि क्या forbidden calls जैसे fork() का उपयोग कर child process बनाया जा सकता है या system() से यह देखा जा सकता है कि /bin/sh मौजूद है या नहीं।
Process Checks: ज्ञात jailbreak-संबंधित प्रोसेस की उपस्थिति की निगरानी करें, जैसे Cydia, Substrate, या ssh.
Kernel Exploits: उन kernel exploits की उपस्थिति की जांच करें जो आमतौर पर jailbreaks में उपयोग होते हैं।
Environment Variables: jailbreak के संकेतों के लिए environment variables निरीक्षण करें, जैसे DYLD_INSERT_LIBRARIES.
Libraries Check: उन libs की जाँच करें जो app process में लोड हैं।
Check schemes: जैसे canOpenURL(URL(string: "cydia://")).

सामान्य Anti-Debugging detection विधियाँ

Check for Debugger Presence: sysctl या अन्य तरीकों का उपयोग करके जांचें कि क्या कोई debugger जुड़ा है।
Anti-Debugging APIs: anti-debugging APIs जैसे ptrace या SIGSTOP के कॉल्स की तलाश करें, जैसे ptrace(PT_DENY_ATTACH, 0, 0, 0).
Timing Checks: कुछ ऑपरेशनों के लिए लगे समय को मापें और debugging का संकेत दे सकने वाली असमानताओं की तलाश करें।
Memory Checks: ज्ञात debugger artifacts या संशोधनों के लिए मेमोरी का निरीक्षण करें।
Environment Variables: ऐसे environment variables की जाँच करें जो debugging सत्र का संकेत दे सकते हैं।
Mach Ports: पता करें कि क्या mach exception ports debuggers द्वारा उपयोग किए जा रहे हैं।

बुनियादी Dynamic Analysis

MobSF द्वारा किए जाने वाले dynamic analysis को देखें। आपको विभिन्न views के माध्यम से नेविगेट करना होगा और उनके साथ इंटरैक्ट करना होगा क्योंकि यह कई क्लासेस को hook करेगा और अन्य काम करते हुए एक रिपोर्ट तैयार करेगा जब आप समाप्त कर लेंगे।

Installed Apps की सूची बनाना

इंस्टॉल्ड ऐप्स के 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

Basic Enumeration & Hooking

जानें कि कैसे आप enumerate the components of the application कर सकते हैं और कैसे आसानी से hook methods and classes objection के साथ कर सकते हैं:

iOS Hooking With Objection

IPA Structure

एक IPA file की संरचना मौलिक रूप से एक zipped package जैसी होती है। इसके extension को .zip में बदलकर, इसे decompressed करके इसकी सामग्री देखी जा सकती है। इस संरचना के अंदर, एक Bundle एक पूरी तरह पैक किया हुआ एप्लिकेशन दर्शाता है जो इंस्टॉलेशन के लिए तैयार होता है। अंदर, आपको <NAME>.app नामक एक डायरेक्टरी मिलेगी, जो एप्लिकेशन के संसाधनों को समाहित करती है।

Info.plist: यह फ़ाइल एप्लिकेशन के विशिष्ट कॉन्फ़िगरेशन विवरण रखती है।
_CodeSignature/: यह डायरेक्टरी एक plist फ़ाइल शामिल करती है जिसमें एक signature होता है, जो bundle में सभी फ़ाइलों की integrity सुनिश्चित करता है।
Assets.car: एक compressed archive जो icons जैसे asset फ़ाइलें स्टोर करता है।
Frameworks/: यह फ़ोल्डर एप्लिकेशन की native libraries रखता है, जो .dylib या .framework फ़ाइलों के रूप में हो सकती हैं।
PlugIns/: यह एप्लिकेशन के extensions शामिल कर सकता है, जिन्हें .appex फ़ाइलें कहा जाता है, हालांकि ये हमेशा मौजूद नहीं होते। * Core Data: यह आपके एप्लिकेशन के स्थायी डेटा को ऑफ़लाइन उपयोग के लिए सेव करने, अस्थायी डेटा को cache करने, और एक डिवाइस पर undo functionality जोड़ने के लिए प्रयोग किया जाता है। एक ही iCloud खाते के भीतर कई डिवाइसों पर डेटा sync करने के लिए, Core Data स्वचालित रूप से आपके schema को एक CloudKit container में mirror कर देता है।
PkgInfo: PkgInfo फ़ाइल आपके एप्लिकेशन या bundle के type और creator codes निर्दिष्ट करने का एक वैकल्पिक तरीका है।
en.lproj, fr.proj, Base.lproj: ये भाषा पैक हैं जो उन विशेष भाषाओं के संसाधन को contain करते हैं, और एक default resource प्रदान करते हैं जब कोई भाषा समर्थित नहीं होती।
Security: _CodeSignature/ डायरेक्टरी ऐप की सुरक्षा में महत्वपूर्ण भूमिका निभाती है, डिजिटल signatures के माध्यम से सभी bundled फ़ाइलों की integrity की पुष्टि करके।
Asset Management: Assets.car फ़ाइल compression का उपयोग करके graphical assets को कुशलतापूर्वक प्रबंधित करती है, जो application performance optimize करने और इसके कुल आकार को घटाने के लिए महत्वपूर्ण है।
Frameworks and PlugIns: ये डायरेक्टरियाँ iOS एप्लिकेशन की modularity को दर्शाती हैं, जिससे developers reusable code libraries (Frameworks/) शामिल कर सकते हैं और app functionality (PlugIns/) बढ़ा सकते हैं।
Localization: यह संरचना कई भाषाओं का समर्थन करती है, जिससे विशिष्ट भाषा पैक्स के संसाधन शामिल करने द्वारा वैश्विक पहुँच सहूलियत होती है।

Info.plist

Info.plist iOS applications के लिए एक cornerstone के रूप में कार्य करता है, महत्वपूर्ण कॉन्फ़िगरेशन डेटा को key-value जोड़ों के रूप में समाहित करता है। यह फ़ाइल केवल applications के लिए ही नहीं बल्कि app extensions और frameworks के लिए भी आवश्यक है जो bundle में शामिल होते हैं। यह XML या binary फॉर्मैट में संरचित होता है और app permissions से लेकर security configurations तक महत्वपूर्ण जानकारी रखता है। उपलब्ध keys के विस्तृत विवरण के लिए Apple Developer Documentation देखें।

जो लोग इस फ़ाइल के साथ अधिक सुलभ फ़ॉर्मैट में काम करना चाहते हैं, वे XML conversion आसानी से macOS पर plutil (versions 10.2 और बाद में नॅटिव रूप से उपलब्ध) या Linux पर plistutil का उपयोग करके कर सकते हैं। Conversion के लिए कमांड निम्न हैं:

For 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

Data Paths

iOS वातावरण में, डायरेक्टरी विशेष रूप से system applications और user-installed applications के लिए निर्धारित होती हैं। सिस्टम एप्लिकेशन /Applications डायरेक्टरी में रहती हैं, जबकि यूजर-इंस्टॉल्ड ऐप्स /var/mobile/containers/Data/Application/ के अंतर्गत रखे जाते हैं। इन एप्लिकेशनों को एक अनूठा पहचानकर्ता दिया जाता है जिसे 128-bit UUID कहा जाता है, जिससे डायरेक्टरी नामों के रैंडम होने के कारण किसी ऐप के फोल्डर को मैन्युअली ढूँढना कठिन हो जाता है।

Warning

As applications in iOS must be sandboxed, each app will have also a folder inside $HOME/Library/Containers with app’s CFBundleIdentifier as the folder name.

However, both folders (data & container folders) have the file .com.apple.mobile_container_manager.metadata.plist that links both files in the key MCMetadataIdentifier).

यूजर-इंस्टॉल्ड ऐप की इंस्टॉलेशन डायरेक्टरी को खोजने को आसान बनाने के लिए, 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

इसके अलावा, ऐप का नाम /private/var/containers के भीतर find कमांड का उपयोग करके खोजा जा सकता है:

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 के समान है, इसमें आवश्यक एप्लिकेशन डेटा, स्थैतिक सामग्री और एप्लिकेशन का संकलित बाइनरी शामिल होता है।
यह डायरेक्टरी उपयोगकर्ताओं को दिखाई देती है, लेकिन उपयोगकर्ता इसमें लिख नहीं सकते।
इस डायरेक्टरी की सामग्री बैकअप नहीं की जाती।
इस फ़ोल्डर की सामग्री का उपयोग code signature को validate करने के लिए किया जाता है।

डेटा निर्देशिका:

Documents/
इसमें सभी उपयोगकर्ता-जनित डेटा होता है। एप्लिकेशन का end user इस डेटा के निर्माण की पहल करता है।
उपयोगकर्ताओं के लिए दिखाई देता है और उपयोगकर्ता इसमें लिख सकते हैं।
इस डायरेक्टरी की सामग्री बैकअप की जाती है।
ऐप पथों को NSURLIsExcludedFromBackupKey सेट करके अक्षम कर सकता है।
Library/
इसमें सभी ऐसी फ़ाइलें होती हैं जो user-specific नहीं हैं, जैसे caches, preferences, cookies, और property list (plist) configuration files।
iOS apps आम तौर पर Application Support और Caches सबडायरेक्टरी का उपयोग करते हैं, लेकिन ऐप कस्टम सबडायरेक्टरी बना सकता है।
Library/Caches/
इसमें अर्ध-स्थायी कैश की गई फ़ाइलें होती हैं।
उपयोगकर्ताओं के लिए अदृश्य और उपयोगकर्ता इसमें लिख नहीं सकते।
इस डायरेक्टरी की सामग्री बैकअप नहीं की जाती।
जब ऐप चल नहीं रहा होता और स्टोरेज कम हो, तो OS स्वचालित रूप से इस डायरेक्टरी की फाइलें हटा सकता है।
Library/Application Support/
इसमें ऐप चलाने के लिए आवश्यक स्थायी फ़ाइलें होती हैं।
अदृश्य के उपयोगकर्ताओं और उपयोगकर्ता इसमें लिख नहीं सकते।
इस डायरेक्टरी की सामग्री बैकअप की जाती है।
ऐप पथों को NSURLIsExcludedFromBackupKey सेट करके अक्षम कर सकता है।
Library/Preferences/
उन प्रॉपर्टीज़ को संग्रहीत करने के लिए उपयोग किया जाता है जो application के restart होने के बाद भी बनी रह सकती हैं।
जानकारी application sandbox के अंदर unencrypted रूप में [BUNDLE_ID].plist नामक एक plist फ़ाइल में सहेजी जाती है।
NSUserDefaults का उपयोग करके संग्रहीत सभी key/value जोड़े इस फ़ाइल में पाए जा सकते हैं।
tmp/
इस डायरेक्टरी का उपयोग ऐसे अस्थायी फ़ाइलों को लिखने के लिए करें जिन्हें ऐप लॉन्च्स के बीच स्थायी रहने की आवश्यकता नहीं है।
गैर-स्थायी कैश्ड फ़ाइलें होती हैं।
उपयोगकर्ताओं के लिए अदृश्य।
इस डायरेक्टरी की सामग्री बैकअप नहीं की जाती।
जब ऐप चल नहीं रहा होता और स्टोरेज कम हो, तो OS स्वचालित रूप से इस डायरेक्टरी की फाइलें हटा सकता है।

चलिये Bundle निर्देशिका के अंदर iGoat-Swift के Application Bundle (.app) डायरेक्टरी (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.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

<application-name>.app फ़ोल्डर के अंदर आपको <application-name> नाम की एक binary फ़ाइल मिलेगी। यह वही फ़ाइल है जिसे निष्पादित किया जाएगा। आप इस binary का बुनियादी निरीक्षण टूल otool के साथ कर सकते हैं:

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)
[...]

जाँचें कि app encrypted है

देखें कि इसके लिए कोई output है या नहीं:

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

बाइनरी को डिसअसेंबल करना

text section को डिसअसेंबल करें:

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 खंड को प्रिंट करने के लिए आप उपयोग कर सकते हैं:

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 code प्राप्त करने के लिए आप 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;
};

हालाँकि, बाइनरी को disassemble करने के लिए सबसे अच्छे विकल्प हैं: Hopper और IDA.

डेटा स्टोरेज

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

iOS Basics

Warning

The following places to store information should be checked right after installing the application, after checking all the functionalities of the application and even after login out from one user and login into a different one.
The goal is to find unprotected sensitive information of the application (passwords, tokens), of the current user and of previously logged users.

Plist

plist files are structured XML files that contains key-value pairs. It’s a way to store persistent data, so sometimes you may find sensitive information in these files. It’s recommended to check these files after installing the app and after using intensively it to see if new data is written.

The most common way to persist data in plist files is through the usage of NSUserDefaults. This plist file is saved inside the app sandbox in Library/Preferences/<appBundleID>.plist

The NSUserDefaults class provides a programmatic interface for interacting with the default system. The default system allows an application to customize its behaviour according to user preferences. Data saved by NSUserDefaults can be viewed in the application bundle. This class stores data in a plist file, but it’s meant to be used with small amounts of data.

This data cannot be longer accessed directly via a trusted computer, but can be accessed performing a backup.

You can dump the information saved using NSUserDefaults using objection’s ios nsuserdefaults get

To find all the plist of used by the application you can access to /private/var/mobile/Containers/Data/Application/{APPID} and run:

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

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 अपने डेटा को डिफ़ॉल्ट रूप से encrypt नहीं करता है। हालांकि, CoreData में एक अतिरिक्त encryption layer जोड़ी जा सकती है। अधिक जानकारी के लिए GitHub Repo देखें।

You can find the SQLite Core Data information of an application in the path /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support

यदि आप SQLite खोलकर संवेदनशील जानकारी तक पहुँच पा रहे हैं, तो आपने एक गलत कॉन्फ़िगरेशन पाया है।

-(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 के ऊपर बना एक key/value स्टोर है.
चूंकि Yap डेटाबेस sqlite डेटाबेस हैं, आप उन्हें पिछले सेक्शन में दिए गए कमांड का उपयोग करके पा सकते हैं।

अन्य SQLite डेटाबेस

यह सामान्य है कि applications अपना खुद का sqlite database बनाती हैं। वे उनमें संग्रहित संवेदनशील डेटा रख सकती हैं और उसे बिना एन्क्रिप्ट किए छोड़ सकती हैं। इसलिए, एप्लिकेशन डायरेक्टरी के अंदर हर database की जाँच करना हमेशा दिलचस्प होता है। इसलिए उस application directory में जाएँ जहाँ डेटा सेव होता है (/private/var/mobile/Containers/Data/Application/{APPID})

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

Firebase Real-Time Databases

डेवलपर्स Firebase Real-Time Databases के माध्यम से डेटा को स्टोर और सिंक करने में सक्षम होते हैं, जो एक NoSQL cloud-hosted database में होस्ट किया जाता है। JSON प्रारूप में संग्रहीत, डेटा रीयल-टाइम में सभी कनेक्टेड क्लाइंट्स के साथ सिंक्रोनाइज़ हो जाता है।

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

Firebase Database

Realm databases

Realm Objective-C और 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 डेटाबेस में encryption लागू करने के लिए, निम्नलिखित code snippet का उपयोग किया जा सकता है:

// 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 Databases

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 file बैकअप्स में एक्सेस की जा सकती है।

cookies file की जाँच करने के लिए आप 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"
}
]

Cache

डिफ़ॉल्ट रूप से NSURLSession डेटा संग्रहीत करता है, जैसे कि HTTP requests and responses in the Cache.db database. यह database संवेदनशील डेटा रख सकता है, अगर tokens, usernames या कोई अन्य संवेदनशील जानकारी cached हो गई हो। कैश्ड जानकारी खोजने के लिए ऐप की data directory खोलें (/var/mobile/Containers/Data/Application/<UUID>) और /Library/Caches/<Bundle Identifier> पर जाएँ। WebKit cache is also being stored in the Cache.db file। Objection इस database को खोलकर interact कर सकता है कमांड sqlite connect Cache.db से, क्योंकि यह एक normal SQLite database है।

यह सलाह दी जाती है कि इन डेटा का Caching अक्षम करें, क्योंकि request या response में संवेदनशील जानकारी हो सकती है। नीचे दी गई सूची अलग-अलग तरीकों को बताती है जिनसे यह हासिल किया जा सकता है:

लॉगआउट के बाद Cached responses हटाना अनुशंसित है। यह Apple द्वारा प्रदान किए गए method removeAllCachedResponses से किया जा सकता है। आप इस method को निम्नानुसार कॉल कर सकते हैं:

URLCache.shared.removeAllCachedResponses()

यह method Cache.db फाइल से सभी cached requests और responses हटा देगा।

यदि आपको cookies के फायदे इस्तेमाल करने की आवश्यकता नहीं है तो यह अनुशंसित होगा कि आप URLSession की .ephemeral configuration property का उपयोग करें, जो cookies और Caches को सेव करना अक्षम कर देगी।

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.

Cache को Cache Policy को .notAllowed पर सेट करके भी अक्षम किया जा सकता है। यह किसी भी रूप में Cache को स्टोर करने को अक्षम कर देगा, चाहे memory में हो या disk पर।

Snapshots

जब भी आप home button दबाते हैं, iOS वर्तमान स्क्रीन का एक snapshot लेता है ताकि application के बीच transition अधिक smooth हो सके। हालाँकि, यदि वर्तमान स्क्रीन में संवेदनशील डेटा मौजूद है, तो वह उस image में सहेजा जाएगा (जो reboots के बाद भी persist करता है)। ये वही snapshots हैं जिन्हें आप apps के बीच switch करने के लिए home button को double tap करके भी access कर सकते हैं।

जब तक iPhone jailbroken न हो, attacker को इन screenshots देखने के लिए device का access unblocked होना चाहिए। डिफ़ॉल्ट रूप से आख़िरी snapshot application’s sandbox में Library/Caches/Snapshots/ या Library/SplashBoard/Snapshots फ़ोल्डर में स्टोर होता है (trusted computers iOX 7.0 से फाइल सिस्टम को access नहीं कर पाते)।

इस बर्ताव को रोकने का एक तरीका यह है कि snapshot लेने से पहले एक blank स्क्रीन दिखाया जाए या संवेदनशील डेटा हटा दिया जाए, ApplicationDidEnterBackground() function का उपयोग करके।

निम्न एक sample remediation method है जो एक default screenshot सेट करेगा।

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 पर सेट कर देता है। यह sensitive data leaks को रोकता है क्योंकि overlayImage.png हमेशा वर्तमान व्यू को ओवरराइड कर देगा।

Keychain

iOS keychain को एक्सेस और मैनेज करने के लिए, Keychain-Dumper जैसे टूल उपलब्ध हैं, जो jailbroken devices के लिए उपयुक्त हैं। इसके अलावा, Objection समान उद्देश्यों के लिए ios keychain dump कमांड प्रदान करता है।

स्टोरिंग क्रेडेंशियल्स

NSURLCredential क्लास सीधे keychain में संवेदनशील जानकारी सेव करने के लिए आदर्श है, जिससे NSUserDefaults या अन्य wrappers की आवश्यकता बायपास हो जाती है। लॉगिन के बाद क्रेडेंशियल्स स्टोर करने के लिए, निम्न Swift कोड उपयोग किया जाता है:

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

इन संग्रहीत क्रेडेंशियल्स को निकालने के लिए, Objection का command ios nsurlcredentialstorage dump उपयोग किया जाता है।

कस्टम कीबोर्ड और कीबोर्ड कैश

iOS 8.0 से आगे, उपयोगकर्ता custom keyboard extensions इंस्टॉल कर सकते हैं, जिन्हें Settings > General > Keyboard > Keyboards के तहत मैनेज किया जा सकता है। ये कीबोर्ड विस्तारित फ़ंक्शनलिटी प्रदान करते हैं, लेकिन ये keystroke logging और डेटा को बाहरी सर्वरों पर भेजने के जोखिम पैदा कर सकते हैं; हालांकि उपयोगकर्ताओं को उन keyboards के बारे में सूचित किया जाता है जिन्हें network access की आवश्यकता होती है। Apps custom keyboards के उपयोग को sensitive information एंट्री के लिए सीमित कर सकते हैं — और करना चाहिए।

सुरक्षा सुझाव:

बेहतर सुरक्षा के लिए third-party keyboards को disable करने की सलाह दी जाती है।
default iOS keyboard के autocorrect और auto-suggestions फीचर्स के बारे में सतर्क रहें, जो संवेदनशील जानकारी को cache फ़ाइलों में स्टोर कर सकते हैं, ये फ़ाइलें Library/Keyboard/{locale}-dynamic-text.dat या /private/var/mobile/Library/Keyboard/dynamic-text.dat पर स्थित होती हैं। इन cache फ़ाइलों को नियमित रूप से sensitive data के लिए चेक किया जाना चाहिए। Cached डेटा को साफ़ करने के लिए Settings > General > Reset > Reset Keyboard Dictionary के माध्यम से keyboard dictionary को reset करने की सलाह दी जाती है।
Network traffic को intercept करने से पता चल सकता है कि क्या कोई custom keyboard keystrokes remotely भेज रहा है।

टेक्स्ट फील्ड कैशिंग रोकना

The UITextInputTraits protocol ऑटोकरेक्शन और secure text entry को मैनेज करने के लिए properties प्रदान करता है, जो sensitive information के caching को रोकने के लिए आवश्यक हैं। उदाहरण के लिए, autocorrection को disable करना और secure text entry को enable करना निम्नानुसार किया जा सकता है:

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

इसके अतिरिक्त, डेवलपर्स को यह सुनिश्चित करना चाहिए कि टेक्स्ट फ़ील्ड्स — विशेषकर वे जिनमें संवेदनशील जानकारी जैसे passwords और PINs दर्ज की जाती है — कैशिंग अक्षम हों, इसके लिए autocorrectionType को UITextAutocorrectionTypeNo और secureTextEntry को YES पर सेट करें।

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

Logs

कोड डिबग करने में अक्सर logging का उपयोग होता है। यह जोखिम है क्योंकि logs में संवेदनशील जानकारी हो सकती है। पहले, iOS 6 और उससे पुराने वर्ज़न में, logs सभी apps के लिए उपलब्ध थे, जिससे sensitive data का leak होने का जोखिम था। अब, applications केवल अपने logs तक ही पहुंच सकते हैं।

इन प्रतिबंधों के बावजूद, एक attacker with physical access अनलॉक्ड डिवाइस को कंप्यूटर से कनेक्ट करके और reading the logs करके इसका फायदा उठा सकता है। ध्यान दें कि logs ऐप की अनइंस्टॉलेशन के बाद भी डिस्क पर बने रहते हैं।

जोखिम कम करने के लिए, सलाह दी जाती है कि आप thoroughly interact with the app, इसकी सभी कार्यक्षमताओं और इनपुट्स का परीक्षण करके यह सुनिश्चित करें कि कोई संवेदनशील जानकारी अनजाने में log तो नहीं हो रही है।

जब आप ऐप के source code की समीक्षा कर रहे हों संभावित leaks के लिए, तो दोनों predefined और custom logging statements की तलाश करें — built-in फ़ंक्शन्स के लिए NSLog, NSAssert, NSCAssert, fprintf जैसे keywords, और custom implementations के लिए Logging या Logfile का जिक्र।

Monitoring System Logs

Apps कई तरह की जानकारी log करते हैं जो संवेदनशील हो सकती है। इन logs की monitoring के लिए, निम्न tools और commands जैसे:

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

उपयोगी होते हैं। इसके अतिरिक्त, Xcode कंसोल लॉग एकत्र करने का तरीका प्रदान करता है:

Xcode खोलें.
iOS डिवाइस कनेक्ट करें.
Window -> Devices and Simulators पर जाएँ.
अपने डिवाइस का चयन करें.
आप जो समस्या जांच रहे हैं, उसे ट्रिगर करें.
लॉग एक नई विंडो में देखने के लिए Open Console बटन का उपयोग करें.

अधिक उन्नत लॉगिंग के लिए, device shell से कनेक्ट करना और socat का उपयोग रियल-टाइम लॉग मॉनिटरिंग प्रदान कर सकता है:

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

लॉग गतिविधियों का अवलोकन करने के लिए दिए गए कमांड्स का पालन करें, जो समस्याओं का निदान करने या लॉग में संभावित डेटा leak की पहचान करने के लिए अमूल्य हो सकते हैं।

Backups

Auto-backup features iOS में एकीकृत हैं, जो iTunes (up to macOS Catalina), Finder (from macOS Catalina onward), या iCloud के माध्यम से डिवाइस डेटा की प्रतियाँ बनाने में मदद करते हैं। ये बैकअप लगभग सभी डिवाइस डेटा को शामिल करते हैं, सिवाय उन अत्यधिक संवेदनशील तत्वों के जैसे Apple Pay विवरण और Touch ID कॉन्फ़िगरेशन।

Security Risks

बैकअप में installed apps and their data का शामिल होना संभावित data leak और इस जोखिम को बढ़ाता है कि backup modifications could alter app functionality। इन जोखिमों को कम करने के लिए सलाह दी जाती है कि किसी भी ऐप के डिरेक्टरी या उसकी सबडिरेक्टरी में संवेदनशील जानकारी को plaintext में स्टोर न करें।

Excluding Files from Backups

Files in Documents/ and Library/Application Support/ डिफ़ॉल्ट रूप से बैकअप की जाती हैं। Developers विशिष्ट फाइलों या डायरेक्टरीज़ को बैकअप से exclude करने के लिए NSURL setResourceValue:forKey:error: के साथ NSURLIsExcludedFromBackupKey का उपयोग कर सकते हैं। यह अभ्यास संवेदनशील डेटा को बैकअप में शामिल होने से बचाने के लिए महत्वपूर्ण है।

Testing for Vulnerabilities

किसी ऐप की बैकअप सुरक्षा का आकलन करने के लिए, पहले Finder का उपयोग करके creating a backup करें, फिर उसे ढूँढने के लिए Apple’s official documentation में दिए निर्देशों का पालन करें। बैकअप का विश्लेषण करें कि क्या संवेदनशील डेटा या कॉन्फ़िगरेशन मौजूद हैं जिन्हें बदलकर ऐप के व्यवहार को प्रभावित किया जा सकता है।

संवेदनशील जानकारी command-line tools या iMazing जैसे applications का उपयोग करके खोजी जा सकती है। एन्क्रिप्टेड बैकअप के लिए, एन्क्रिप्शन की उपस्थिति को बैकअप की रूट में मौजूद “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 scripts, जैसे backup_tool.py और backup_passwd.py, उपयोगी हो सकते हैं, हालांकि उन्हें नवीनतम iTunes/Finder संस्करणों के साथ संगतता के लिए समायोजन की आवश्यकता पड़ सकती है। iOSbackup tool पासवर्ड-प्रोटेक्टेड बैकअप्स के भीतर फ़ाइलों तक पहुँचने का एक और विकल्प है।

ऐप व्यवहार बदलना

बैकअप संशोधनों के जरिए ऐप व्यवहार बदलने का एक उदाहरण Bither bitcoin wallet app में दिखाया गया है, जहाँ UI lock PIN net.bither.plist में pin_code key के अंतर्गत संग्रहीत होता है। इस key को plist से हटाकर और बैकअप को पुनर्स्थापित करके PIN आवश्यकता हटा दी जाती है, जिससे unrestricted access मिल जाता है।

संवेदनशील डेटा के लिए मेमोरी परीक्षण का सारांश

जब किसी एप्लिकेशन की मेमोरी में संग्रहीत संवेदनशील जानकारी से निपटा जा रहा हो, तो इस डेटा के exposure समय को सीमित करना महत्वपूर्ण है। मेमोरी सामग्री की जाँच के दो मुख्य तरीके हैं: मेमोरी डंप बनाना और रीयल टाइम में मेमोरी का विश्लेषण। दोनों तरीकों में चुनौतियाँ हैं, जैसे कि डंप प्रक्रिया या विश्लेषण के दौरान महत्वपूर्ण डेटा छूट सकता है।

मेमोरी डंप प्राप्त करना और उसका विश्लेषण

jailbroken और non-jailbroken डिवाइस दोनों के लिए, objection और Fridump जैसे tools किसी ऐप की process memory को dump करने की अनुमति देते हैं। एक बार dump हो जाने पर, इस डेटा का विश्लेषण करने के लिए विभिन्न tools की आवश्यकता होती है, जो कि आप जिस प्रकार की जानकारी खोज रहे हैं उस पर निर्भर करता है।

मेमोरी डंप से strings निकालने के लिए, 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]> /?
...

Runtime Memory Analysis

r2frida एक शक्तिशाली विकल्प प्रदान करता है जो किसी ऐप की मेमोरी का वास्तविक समय में निरीक्षण करने की अनुमति देता है, बिना memory dump की आवश्यकता के। यह टूल चल रही एप्लिकेशन की मेमोरी पर सीधे खोज कमांड्स चलाने में सक्षम बनाता है:

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

क्रिप्टोग्राफी में कमजोरियाँ

कमजोर कुंजी प्रबंधन प्रक्रियाएँ

कुछ डेवलपर्स संवेदनशील डेटा को लोकल स्टोरेज में सेव करते हैं और इसे कोड में हार्डकोडेड/पूर्वानुमेय कुंजी से encrypt कर देते हैं। यह नहीं किया जाना चाहिए क्योंकि कुछ reversing से हमलावरों को गोपनीय जानकारी निकालने की अनुमति मिल सकती है।

असुरक्षित और/या डिप्रीकेटेड एल्गोरिदम का उपयोग

डेवलपर्स को डिप्रीकेटेड एल्गोरिदम का उपयोग प्राधिकरण जांच, डेटा संग्रहित करने या भेजने के लिए नहीं करना चाहिए। इनमें से कुछ एल्गोरिदम हैं: RC4, MD4, MD5, SHA1… उदाहरण के लिए यदि पासवर्ड स्टोर करने के लिए hashes का उपयोग किया जाता है, तो salt के साथ brute-force प्रतिरोधी hashes का उपयोग किया जाना चाहिए।

जाँच

मुख्य जाँचें यह पता लगाना है कि क्या आप कोड में हार्डकोडेड पासवर्ड/सीक्रेट्स ढूंढ सकते हैं, या क्या वे पूर्वानुमेय हैं, और क्या कोड किसी प्रकार की कमज़ोर क्रिप्टोग्राफी एल्गोरिदम का उपयोग कर रहा है।

यह जानना दिलचस्प है कि आप monitor कर सकते हैं कुछ crypto libraries को ऑटोमेटिक रूप से objection का उपयोग करके:

ios monitor crypt

iOS cryptographic APIs और libraries के बारे में अधिक जानकारी के लिए देखें https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography

स्थानीय प्रमाणीकरण

स्थानीय प्रमाणीकरण महत्वपूर्ण भूमिका निभाता है, खासकर जब यह क्रिप्टोग्राफिक तरीकों के माध्यम से दूरस्थ एंडपॉइंट पर पहुँच की सुरक्षा से संबंधित हो। निहितार्थ यह है कि सही तरीके से लागू न होने पर स्थानीय प्रमाणीकरण तंत्र को बायपास किया जा सकता है।

Apple का Local Authentication framework और keychain क्रमशः उपयोगकर्ता प्रमाणीकरण डायलॉग सक्षम करने और गुप्त डेटा को सुरक्षित रूप से संभालने के लिए डेवलपर्स को मजबूत APIs प्रदान करते हैं। Secure Enclave Touch ID के लिए fingerprint ID को सुरक्षित करता है, जबकि Face ID चेहरे की पहचान पर निर्भर करता है और बायोमेट्रिक डेटा की सुरक्षा को प्रभावित नहीं करता।

Touch ID/Face ID को एकीकृत करने के लिए, डेवलपर्स के पास दो API विकल्प होते हैं:

LocalAuthentication.framework: high-level user authentication के लिए, बिना biometric data तक पहुँच के।
Security.framework: lower-level keychain services तक पहुँच के लिए, गुप्त डेटा को biometric authentication के साथ सुरक्षित करने के लिए। विभिन्न open-source wrappers keychain access को सरल बनाते हैं।

Caution

हालांकि, LocalAuthentication.framework और Security.framework दोनों में कमजोरियाँ हैं, क्योंकि वे मुख्य रूप से boolean मान लौटाते हैं बिना authentication प्रक्रियाओं के लिए डेटा ट्रांसमिट किए, जिससे वे बायपास के प्रति संवेदनशील हो जाते हैं (संदर्भ के लिए देखें Don’t touch me that way, by David Lindner et al).

स्थानीय प्रमाणीकरण लागू करना

उपयोगकर्ताओं से प्रमाणीकरण के लिए संकेत करने हेतु, डेवलपर्स को LAContext क्लास में मौजूद evaluatePolicy मेथड का उपयोग करना चाहिए, निम्न में से चयन करते हुए:

deviceOwnerAuthentication: Touch ID या device passcode के लिए संकेत करता है; अगर दोनों में से कोई सक्षम नहीं है तो विफल हो जाएगा।
deviceOwnerAuthenticationWithBiometrics: केवल Touch ID के लिए संकेत करता है।

सफल प्रमाणीकरण evaluatePolicy द्वारा लौटाए गए boolean मान से सूचित होता है, जो एक संभावित सुरक्षा दोष को दर्शाता है।

Keychain का उपयोग करके स्थानीय प्रमाणीकरण

iOS ऐप्स में स्थानीय प्रमाणीकरण को लागू करने में keychain APIs का उपयोग शामिल है ताकि authentication tokens जैसे गुप्त डेटा को सुरक्षित रूप से संग्रहीत किया जा सके। यह प्रक्रिया सुनिश्चित करती है कि डेटा केवल उपयोगकर्ता द्वारा ही एक्सेस किया जा सके, उनके device passcode या Touch ID जैसे biometric authentication का उपयोग करके।

keychain SecAccessControl attribute के साथ आइटम सेट करने की क्षमता प्रदान करता है, जो उस आइटम तक पहुँच को तब तक सीमित करता है जब तक उपयोगकर्ता Touch ID या device passcode के माध्यम से सफलतापूर्वक प्रमाणीकरण न कर ले। यह फीचर सुरक्षा बढ़ाने के लिए महत्वपूर्ण है।

नीचे Swift और Objective-C में कोड उदाहरण दिए गए हैं जो दिखाते हैं कि इन सुरक्षा सुविधाओं का उपयोग करके keychain में एक string को कैसे सेव और retrieve किया जाए। उदाहरण विशेष रूप से दिखाते हैं कि कैसे access control सेट किया जाए ताकि Touch ID प्रमाणीकरण आवश्यक हो और यह सुनिश्चित किया जा सके कि डेटा केवल उसी डिवाइस पर सुलभ हो जिस पर इसे सेट किया गया था, बशर्ते कि device passcode कॉन्फ़िगर किया गया हो।

// 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 उपयोगकर्ता को authentication dialog प्रस्तुत करेंगे और उपयुक्त 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");
}

पता लगाना

किसी app में frameworks के उपयोग का पता app binary की shared dynamic libraries की सूची का विश्लेषण करके भी लगाया जा सकता है। यह 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 का उपयोग किया गया है, तो केवल दूसरा दिखाया जाएगा।

लोकल ऑथेंटिकेशन फ्रेमवर्क Bypass

Objection

Objection Biometrics Bypass, located at this GitHub page, के माध्यम से LocalAuthentication mechanism को बायपास करने की एक तकनीक उपलब्ध है। इस तरीके का मूल Frida का उपयोग करके evaluatePolicy function को manipulate करना है, जिससे यह वास्तविक authentication सफलता की परवाह किए बिना लगातार True परिणाम देता है। यह विशेष रूप से flawed biometric authentication प्रक्रियाओं को circumvent करने में उपयोगी है।

इस bypass को सक्रिय करने के लिए, निम्नलिखित कमांड का उपयोग किया जाता है:

...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

यह command एक अनुक्रम शुरू करता है जहाँ Objection एक task रजिस्टर करता है जो प्रभावी रूप से evaluatePolicy चेक के परिणाम को True में बदल देता है।

Frida

evaluatePolicy के उपयोग का एक उदाहरण DVIA-v2 application:

+(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 script लिखा गया है। यह script evaluatePolicy चेक को लक्षित करता है और उसके callback को intercept करके यह सुनिश्चित करता है कि वह success=1 लौटाए। callback के व्यवहार को बदलकर authentication चेक प्रभावी रूप से bypass कर दिया जाता है।

नीचे दिया गया script inject किया जाता है ताकि evaluatePolicy method के परिणाम को modify किया जा सके। यह callback के परिणाम को हमेशा success दर्शाने के लिए बदल देता है।

// 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 script को इंजेक्ट करने और बायोमेट्रिक प्रमाणीकरण को bypass करने के लिए, निम्नलिखित कमांड का उपयोग किया जाता है:

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

IPC के माध्यम से संवेदनशील कार्यक्षमता का एक्सपोज़र

नेटवर्क संचार

यह सुनिश्चित करना महत्वपूर्ण है कि कोई संचार बिना एन्क्रिप्शन के नहीं हो रहा है और साथ ही ऐपlication सर्वर के TLS certificate को सही तरीके से वैलिडेट कर रही है।
ऐसे मुद्दों की जाँच के लिए आप Burp जैसे प्रॉक्सी का उपयोग कर सकते हैं:

iOS Burp Suite Configuration

Hostname चेक

TLS certificate को validate करते समय एक सामान्य समस्या यह है कि certificate को एक trusted CA द्वारा sign किया गया है या नहीं यह देखा जाता है, लेकिन यह नहीं देखा जाता कि certificate का hostname वही hostname है जिसे access किया जा रहा है।
इस मुद्दे की जाँच के लिए Burp का उपयोग करते समय, iPhone में Burp CA को trust करने के बाद, आप Burp के साथ किसी अलग hostname के लिए नया certificate create कर के उसे इस्तेमाल कर सकते हैं। अगर application फिर भी काम करती है, तो यह vulnerable है।

Certificate Pinning

अगर कोई application सही तरीके से SSL Pinning का उपयोग कर रही है, तो application केवल तभी काम करेगी जब certificate वही होगा जिसकी उम्मीद है। जब किसी application का परीक्षण किया जा रहा हो तो यह समस्या हो सकती है क्योंकि Burp अपना certificate serve करेगा।
इस सुरक्षा को jailbroken डिवाइस के अंदर बायपास करने के लिए, आप एप्लिकेशन SSL Kill Switch इंस्टॉल कर सकते हैं या Burp Mobile Assistant इंस्टॉल कर सकते हैं।

आप objection’s ios sslpinning disable भी उपयोग कर सकते हैं

विविध

/System/Library में आप system applications के लिए फोन में इंस्टॉल किए गए frameworks पा सकते हैं
App Store से user द्वारा इंस्टॉल किए गए applications /User/Applications के अंदर होते हैं
और /User/Library में user-level applications द्वारा सेव किया गया डेटा होता है
आप /User/Library/Notes/notes.sqlite को एक्सेस कर सकते हैं ताकि application में सेव नोट्स पढ़ सकें।
इंस्टॉल किए गए application के फ़ोल्डर (/User/Applications/<APP ID>/) के अंदर आप कुछ दिलचस्प फाइलें पा सकते हैं:
iTunesArtwork: ऐप द्वारा उपयोग किया गया आइकन
iTunesMetadata.plist: App Store में उपयोग होने वाली ऐप की जानकारी
/Library/*: इसमें preferences और cache होते हैं। /Library/Cache/Snapshots/* में आप वह snapshot पा सकते हैं जो application को background भेजने से पहले लिया गया था।

Hot Patching/Enforced Updateing

डेवलपर्स बिना application को App store पर फिर से सबमिट किए और approval का इंतज़ार किए हुए, अपने ऐप की सभी इंस्टॉलेशंस को दूर से तुरंत patch कर सकते हैं।
इसके लिए आमतौर पर JSPatch का उपयोग किया जाता है। लेकिन अन्य विकल्प भी हैं जैसे Siren और react-native-appstore-version-checker.
यह एक खतरनाक मेकैनिज्म है जिसे malicious third party SDKs द्वारा दुरुपयोग किया जा सकता है, इसलिए यह सिफारिश की जाती है कि यह जाँचा जाए कि अपने आप अपडेट करने के लिए कौन सा method उपयोग किया जा रहा है (यदि कोई हो) और उसे टेस्ट करें। इस उद्देश्य के लिए आप ऐप का पिछला संस्करण डाउनलोड करने की कोशिश कर सकते हैं।

Third Parties

3rd party SDKs के साथ एक महत्वपूर्ण चुनौती उनकी कार्यक्षमता पर सूक्ष्म नियंत्रण की कमी है। डेवलपर्स के सामने विकल्प होता है: या तो SDK को इंटीग्रेट करें और इसके सभी फीचर्स स्वीकार करें — जिसमें संभावित security vulnerabilities और privacy चिंताएँ शामिल हो सकती हैं — या इसके लाभों को पूरी तरह छोड़ दें। अक्सर, डेवलपर्स स्वयं इन SDKs में vulnerabilities को patch करने में सक्षम नहीं होते। इसके अलावा, जैसे-जैसे SDKs समुदाय में विश्वास प्राप्त करते हैं, कुछ में malware भी शामिल हो सकता है।

third-party SDKs द्वारा प्रदान की जाने वाली सेवाओं में user behavior tracking, advertisement displays, या user experience enhancements शामिल हो सकते हैं। हालांकि, इससे जोखिम उत्पन्न होता है क्योंकि डेवलपर्स उन लाइब्रेरीज़ द्वारा execute किए जाने वाले कोड के बारे में पूरी तरह से अवगत नहीं हो सकते, जिससे संभावित privacy और security जोखिम पैदा होते हैं। यह आवश्यक है कि third-party services के साथ साझा की जाने वाली जानकारी को केवल आवश्यक तक सीमित रखा जाए और सुनिश्चित किया जाए कि कोई संवेदनशील डेटा एक्सपोज़ न हो।

third-party services का इम्प्लीमेंटेशन आम तौर पर दो रूपों में आता है: एक standalone library या एक full SDK। उपयोगकर्ता की गोपनीयता की रक्षा के लिए, इन सेवाओं के साथ साझा किया जाने वाला कोई भी डेटा गुमनाम किया जाना चाहिए ताकि Personal Identifiable Information (PII) का खुलासा न हो।

किसी application द्वारा उपयोग की जाने वाली लाइब्रेरीज़ पहचानने के लिए, otool कमांड का उपयोग किया जा सकता है। इस टूल को application और प्रत्येक shared library पर चलाना चाहिए ताकि अतिरिक्त लाइब्रेरीज़ का पता चल सके।

otool -L <application_path>

दिलचस्प Vulnerabilities & Case Studies

Air Keyboard Remote Input Injection

Itunesstored Bookassetd Sandbox Escape

Zero Click Messaging Image Parser Chains

संदर्भ और अधिक संसाधन

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 का समर्थन करें

सदस्यता योजनाओं की जांच करें!

हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**

हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।