iOS Pentesting
Last updated
Last updated
Trickest का उपयोग करें ताकि आप दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित वर्कफ़्लो को आसानी से बना और स्वचालित कर सकें। आज ही एक्सेस प्राप्त करें:
इस पृष्ठ पर आप iOS सिम्युलेटर, इम्यूलेटर और जेलब्रेकिंग के बारे में जानकारी पा सकते हैं:
iOS Testing Environmentपरीक्षण के दौरान कई ऑपरेशन सुझाए जाएंगे (डिवाइस से कनेक्ट करना, फ़ाइलें पढ़ना/लिखना/अपलोड/डाउनलोड करना, कुछ उपकरणों का उपयोग करना...)। इसलिए, यदि आप इनमें से किसी भी क्रिया को करने का तरीका नहीं जानते हैं, तो कृपया पृष्ठ पढ़ना शुरू करें:
iOS Basic Testing Operationsअगले चरणों के लिए ऐप को डिवाइस पर इंस्टॉल किया जाना चाहिए और इसे पहले से ही एप्लिकेशन का IPA फ़ाइल प्राप्त कर लेना चाहिए। यह करने के लिए Basic iOS Testing Operations पृष्ठ पढ़ें।
IPA फ़ाइल पर स्वचालित स्थैतिक विश्लेषण करने के लिए MobSF उपकरण का उपयोग करने की सिफारिश की जाती है।
बाइनरी में मौजूद सुरक्षा की पहचान:
PIE (पोजीशन इंडिपेंडेंट एक्सीक्यूटेबल): जब सक्षम होता है, तो एप्लिकेशन हर बार लॉन्च होने पर एक यादृच्छिक मेमोरी पते पर लोड होता है, जिससे इसके प्रारंभिक मेमोरी पते की भविष्यवाणी करना कठिन हो जाता है।
स्टैक कैनरीज़: स्टैक की अखंडता को मान्य करने के लिए, एक 'कैनरी' मान को एक फ़ंक्शन को कॉल करने से पहले स्टैक पर रखा जाता है और फ़ंक्शन समाप्त होने पर फिर से मान्य किया जाता है।
ARC (ऑटोमैटिक रेफरेंस काउंटिंग): सामान्य मेमोरी भ्रष्टाचार दोषों को रोकने के लिए
एन्क्रिप्टेड बाइनरी: बाइनरी को एन्क्रिप्ट किया जाना चाहिए
संवेदनशील/असुरक्षित फ़ंक्शंस की पहचान
कमजोर हैशिंग एल्गोरिदम
असुरक्षित यादृच्छिक फ़ंक्शंस
असुरक्षित 'Malloc' फ़ंक्शन
असुरक्षित और कमजोर फ़ंक्शंस
MobSF द्वारा किए गए डायनामिक एनालिसिस को देखें। आपको विभिन्न दृश्य के माध्यम से नेविगेट करना होगा और उनके साथ इंटरैक्ट करना होगा, लेकिन यह अन्य चीजें करते समय कई क्लासेस को हुक करेगा और जब आप समाप्त हो जाएंगे तो एक रिपोर्ट तैयार करेगा।
स्थापित ऐप्स के बंडल पहचानकर्ता का निर्धारण करने के लिए frida-ps -Uai
कमांड का उपयोग करें:
जानें कि ऐप्लिकेशन के घटकों की गणना कैसे करें और विधियों और कक्षाओं को आसानी से कैसे हुक करें objection के साथ:
iOS Hooking With Objectionएक IPA फ़ाइल की संरचना मूल रूप से एक ज़िप पैकेज की होती है। इसके एक्सटेंशन को .zip
में बदलकर, इसे डिकंप्रेस किया जा सकता है ताकि इसके सामग्री को प्रकट किया जा सके। इस संरचना के भीतर, एक Bundle एक पूरी तरह से पैक किया गया ऐप्लिकेशन है जो इंस्टॉलेशन के लिए तैयार है। इसके अंदर, आपको <NAME>.app
नामक एक निर्देशिका मिलेगी, जो ऐप्लिकेशन के संसाधनों को संलग्न करती है।
Info.plist
: यह फ़ाइल ऐप्लिकेशन के विशिष्ट कॉन्फ़िगरेशन विवरण रखती है।
_CodeSignature/
: यह निर्देशिका एक plist फ़ाइल शामिल करती है जिसमें एक हस्ताक्षर होता है, जो बंडल में सभी फ़ाइलों की अखंडता सुनिश्चित करता है।
Assets.car
: एक संकुचित संग्रह जो आइकनों जैसी संपत्ति फ़ाइलों को संग्रहीत करता है।
Frameworks/
: यह फ़ोल्डर ऐप्लिकेशन की मूल लाइब्रेरीज़ को रखता है, जो .dylib
या .framework
फ़ाइलों के रूप में हो सकती हैं।
PlugIns/
: इसमें ऐप्लिकेशन के लिए एक्सटेंशन शामिल हो सकते हैं, जिन्हें .appex
फ़ाइलें कहा जाता है, हालांकि ये हमेशा मौजूद नहीं होते हैं। * Core Data
: इसका उपयोग आपके ऐप्लिकेशन के स्थायी डेटा को ऑफ़लाइन उपयोग के लिए, अस्थायी डेटा को कैश करने के लिए, और एकल डिवाइस पर आपके ऐप में पूर्ववत कार्यक्षमता जोड़ने के लिए किया जाता है। एक ही iCloud खाते में कई उपकरणों के बीच डेटा को समन्वयित करने के लिए, Core Data स्वचालित रूप से आपके स्कीमा को एक CloudKit कंटेनर में मिरर करता है।
PkgInfo
: PkgInfo
फ़ाइल आपके ऐप्लिकेशन या बंडल के प्रकार और निर्माता कोड निर्दिष्ट करने का एक वैकल्पिक तरीका है।
en.lproj, fr.proj, Base.lproj: ये भाषा पैक हैं जो उन विशिष्ट भाषाओं के लिए संसाधन शामिल करते हैं, और यदि कोई भाषा समर्थित नहीं है तो एक डिफ़ॉल्ट संसाधन।
Security: _CodeSignature/
निर्देशिका ऐप की सुरक्षा में एक महत्वपूर्ण भूमिका निभाती है, जो डिजिटल हस्ताक्षरों के माध्यम से सभी बंडल फ़ाइलों की अखंडता की पुष्टि करती है।
Asset Management: Assets.car
फ़ाइल ग्राफिकल संपत्तियों को कुशलतापूर्वक प्रबंधित करने के लिए संकुचन का उपयोग करती है, जो ऐप्लिकेशन के प्रदर्शन को अनुकूलित करने और इसके समग्र आकार को कम करने के लिए महत्वपूर्ण है।
Frameworks and PlugIns: ये निर्देशिकाएँ iOS ऐप्लिकेशनों की मॉड्यूलरिटी को रेखांकित करती हैं, जिससे डेवलपर्स को पुन: प्रयोज्य कोड लाइब्रेरीज़ (Frameworks/
) शामिल करने और ऐप की कार्यक्षमता को बढ़ाने (PlugIns/
) की अनुमति मिलती है।
Localization: यह संरचना कई भाषाओं का समर्थन करती है, विशिष्ट भाषा पैक के लिए संसाधन शामिल करके वैश्विक ऐप्लिकेशन पहुंच को सुविधाजनक बनाती है।
Info.plist
Info.plist iOS ऐप्लिकेशनों के लिए एक आधारशिला के रूप में कार्य करता है, जो की-वैल्यू जोड़ों के रूप में प्रमुख कॉन्फ़िगरेशन डेटा को संलग्न करता है। यह फ़ाइल न केवल ऐप्लिकेशनों के लिए बल्कि ऐप एक्सटेंशन और बंडल में शामिल फ्रेमवर्क के लिए भी आवश्यक है। यह XML या बाइनरी प्रारूप में संरचित होती है और ऐप अनुमतियों से लेकर सुरक्षा कॉन्फ़िगरेशन तक महत्वपूर्ण जानकारी रखती है। उपलब्ध कुंजियों की विस्तृत खोज के लिए, कोई Apple Developer Documentation का संदर्भ ले सकता है।
जो लोग इस फ़ाइल के साथ अधिक सुलभ प्रारूप में काम करना चाहते हैं, उनके लिए XML रूपांतरण को macOS पर plutil
का उपयोग करके आसानी से प्राप्त किया जा सकता है (संस्करण 10.2 और बाद में स्वदेशी रूप से उपलब्ध) या Linux पर plistutil
का उपयोग करके। रूपांतरण के लिए आदेश इस प्रकार हैं:
For macOS:
लिनक्स के लिए:
Info.plist फ़ाइल जो जानकारी प्रकट कर सकती है, उनमें उल्लेखनीय प्रविष्टियाँ शामिल हैं जैसे ऐप अनुमति स्ट्रिंग्स (UsageDescription
), कस्टम URL स्कीम्स (CFBundleURLTypes
), और ऐप ट्रांसपोर्ट सुरक्षा के लिए कॉन्फ़िगरेशन (NSAppTransportSecurity
)। ये प्रविष्टियाँ, अन्य जैसे निर्यातित/आयातित कस्टम दस्तावेज़ प्रकार (UTExportedTypeDeclarations
/ UTImportedTypeDeclarations
), फ़ाइल का निरीक्षण करके या एक साधारण grep
कमांड का उपयोग करके आसानी से स्थित की जा सकती हैं:
डेटा पथ
iOS वातावरण में, निर्देशिकाएँ विशेष रूप से सिस्टम अनुप्रयोगों और उपयोगकर्ता-स्थापित अनुप्रयोगों के लिए निर्धारित की गई हैं। सिस्टम अनुप्रयोग /Applications
निर्देशिका में स्थित होते हैं, जबकि उपयोगकर्ता-स्थापित ऐप्स /var/mobile/containers/Data/Application/
के अंतर्गत रखे जाते हैं। इन अनुप्रयोगों को एक अद्वितीय पहचानकर्ता दिया जाता है जिसे 128-बिट UUID कहा जाता है, जिससे किसी ऐप के फ़ोल्डर को मैन्युअल रूप से ढूंढना चुनौतीपूर्ण हो जाता है क्योंकि निर्देशिका नामों में यादृच्छिकता होती है।
चूंकि iOS में अनुप्रयोगों को सैंडबॉक्स किया जाना चाहिए, प्रत्येक ऐप के पास $HOME/Library/Containers
के अंदर एक फ़ोल्डर भी होगा जिसका नाम ऐप का CFBundleIdentifier
होगा।
हालांकि, दोनों फ़ोल्डर (डेटा और कंटेनर फ़ोल्डर) में फ़ाइल .com.apple.mobile_container_manager.metadata.plist
होती है जो दोनों फ़ाइलों को कुंजी MCMetadataIdentifier
में लिंक करती है।
उपयोगकर्ता-स्थापित ऐप के स्थापना निर्देशिका की खोज को सुविधाजनक बनाने के लिए, objection tool एक उपयोगी कमांड, env
प्रदान करता है। यह कमांड संबंधित ऐप के लिए विस्तृत निर्देशिका जानकारी प्रकट करता है। नीचे इस कमांड का उपयोग करने का एक उदाहरण दिया गया है:
वैकल्पिक रूप से, ऐप का नाम /private/var/containers
के भीतर find
कमांड का उपयोग करके खोजा जा सकता है:
कमांड जैसे ps
और lsof
का उपयोग ऐप के प्रोसेस की पहचान करने और क्रमशः खुले फ़ाइलों की सूची बनाने के लिए किया जा सकता है, जो ऐप्लिकेशन के सक्रिय निर्देशिका पथों के बारे में जानकारी प्रदान करता है:
Bundle directory:
AppName.app
यह एप्लिकेशन बंडल है जैसा कि IPA में पहले देखा गया था, इसमें आवश्यक एप्लिकेशन डेटा, स्थिर सामग्री और एप्लिकेशन का संकलित बाइनरी शामिल है।
यह निर्देशिका उपयोगकर्ताओं के लिए दृश्य है, लेकिन उपयोगकर्ता इसमें लिख नहीं सकते।
इस निर्देशिका में सामग्री बैकअप नहीं की जाती।
इस फ़ोल्डर की सामग्री का उपयोग कोड सिग्नेचर को मान्य करने के लिए किया जाता है।
Data directory:
Documents/
इसमें सभी उपयोगकर्ता-निर्मित डेटा शामिल है। एप्लिकेशन अंत उपयोगकर्ता इस डेटा के निर्माण की शुरुआत करता है।
उपयोगकर्ताओं के लिए दृश्य है और उपयोगकर्ता इसमें लिख सकते हैं।
इस निर्देशिका में सामग्री बैकअप की जाती है।
एप्लिकेशन NSURLIsExcludedFromBackupKey
सेट करके पथों को अक्षम कर सकता है।
Library/
इसमें सभी फाइलें जो उपयोगकर्ता-विशिष्ट नहीं हैं, जैसे कि कैश, प्रेफरेंस, कुकीज़, और प्रॉपर्टी लिस्ट (plist) कॉन्फ़िगरेशन फ़ाइलें शामिल हैं।
iOS ऐप्स आमतौर पर Application Support
और Caches
उपनिर्देशिकाओं का उपयोग करते हैं, लेकिन ऐप कस्टम उपनिर्देशिकाएँ बना सकता है।
Library/Caches/
इसमें सेमी-स्थायी कैश की गई फ़ाइलें शामिल हैं।
उपयोगकर्ताओं के लिए अदृश्य है और उपयोगकर्ता इसमें लिख नहीं सकते।
इस निर्देशिका में सामग्री बैकअप नहीं की जाती।
जब ऐप चल नहीं रहा होता है और स्टोरेज स्पेस कम होता है, तो OS स्वचालित रूप से इस निर्देशिका की फ़ाइलों को हटा सकता है।
Library/Application Support/
इसमें ऐप चलाने के लिए आवश्यक स्थायी फाइलें शामिल हैं।
उपयोगकर्ताओं के लिए अदृश्य है और उपयोगकर्ता इसमें लिख नहीं सकते।
इस निर्देशिका में सामग्री बैकअप की जाती है।
ऐप NSURLIsExcludedFromBackupKey
सेट करके पथों को अक्षम कर सकता है।
Library/Preferences/
इसका उपयोग उन प्रॉपर्टीज को स्टोर करने के लिए किया जाता है जो ऐप्लिकेशन के पुनरारंभ होने के बाद भी बनी रह सकती हैं।
जानकारी, बिना एन्क्रिप्ट किए, एप्लिकेशन सैंडबॉक्स के अंदर एक plist फ़ाइल में [BUNDLE_ID].plist के रूप में सहेजी जाती है।
NSUserDefaults
का उपयोग करके संग्रहीत सभी कुंजी/मान जोड़े इस फ़ाइल में पाए जा सकते हैं।
tmp/
इस निर्देशिका का उपयोग अस्थायी फ़ाइलें लिखने के लिए करें जिन्हें ऐप लॉन्च के बीच में बने रहने की आवश्यकता नहीं है।
इसमें गैर-स्थायी कैश की गई फ़ाइलें शामिल हैं।
उपयोगकर्ताओं के लिए अदृश्य है।
इस निर्देशिका में सामग्री का बैकअप नहीं लिया जाता है।
जब ऐप चल नहीं रहा होता है और स्टोरेज स्पेस कम होता है, तो OS स्वचालित रूप से इस निर्देशिका की फ़ाइलों को हटा सकता है।
आइए iGoat-Swift के एप्लिकेशन बंडल (.app) निर्देशिका पर करीब से नज़र डालते हैं जो बंडल निर्देशिका के अंदर है (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
):
<application-name>.app
फ़ोल्डर के अंदर आपको एक बाइनरी फ़ाइल मिलेगी जिसे <application-name>
कहा जाता है। यह वह फ़ाइल है जो executed की जाएगी। आप टूल otool
के साथ बाइनरी का एक बुनियादी निरीक्षण कर सकते हैं:
ऐप एन्क्रिप्टेड है या नहीं जांचें
देखें कि क्या इसके लिए कोई आउटपुट है:
बाइनरी को डिसएसेंबल करना
टेक्स्ट सेक्शन को डिसएसेंबल करें:
नमूना एप्लिकेशन के Objective-C खंड को प्रिंट करने के लिए आप उपयोग कर सकते हैं:
एक अधिक संक्षिप्त Objective-C कोड प्राप्त करने के लिए आप class-dump का उपयोग कर सकते हैं:
हालांकि, बाइनरी को डिसअस्सेम्बल करने के लिए सबसे अच्छे विकल्प हैं: Hopper और IDA.
Trickest का उपयोग करें ताकि आप आसानी से वर्कफ़्लो बना सकें और स्वचालित कर सकें जो दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित हैं। आज ही एक्सेस प्राप्त करें:
यह जानने के लिए कि iOS डिवाइस में डेटा कैसे संग्रहित करता है, इस पृष्ठ को पढ़ें:
iOS Basicsजानकारी संग्रहित करने के लिए निम्नलिखित स्थानों की जांच ऐप्लिकेशन इंस्टॉल करने के तुरंत बाद, ऐप्लिकेशन की सभी कार्यक्षमताओं की जांच करने के बाद और यहां तक कि एक उपयोगकर्ता से लॉगआउट करने और दूसरे में लॉगिन करने के बाद की जानी चाहिए। लक्ष्य है अनसुरक्षित संवेदनशील जानकारी खोजना (पासवर्ड, टोकन), वर्तमान उपयोगकर्ता और पूर्व में लॉगिन किए गए उपयोगकर्ताओं की।
plist फ़ाइलें संरचित XML फ़ाइलें हैं जो की-मान जोड़े रखती हैं। यह स्थायी डेटा संग्रहित करने का एक तरीका है, इसलिए कभी-कभी आप इन फ़ाइलों में संवेदनशील जानकारी पा सकते हैं। ऐप इंस्टॉल करने के बाद और इसका गहन उपयोग करने के बाद इन फ़ाइलों की जांच करने की सिफारिश की जाती है कि क्या नया डेटा लिखा गया है।
plist फ़ाइलों में डेटा को स्थायी रूप से रखने का सबसे सामान्य तरीका NSUserDefaults का उपयोग करना है। यह plist फ़ाइल ऐप सैंडबॉक्स के अंदर Library/Preferences/<appBundleID>.plist
में सहेजी जाती है।
NSUserDefaults
क्लास डिफ़ॉल्ट सिस्टम के साथ इंटरैक्ट करने के लिए एक प्रोग्रामेटिक इंटरफ़ेस प्रदान करती है। डिफ़ॉल्ट सिस्टम एक एप्लिकेशन को उपयोगकर्ता प्राथमिकताओं के अनुसार अपने व्यवहार को अनुकूलित करने की अनुमति देता है। NSUserDefaults
द्वारा सहेजा गया डेटा एप्लिकेशन बंडल में देखा जा सकता है। यह क्लास डेटा को plist फ़ाइल में संग्रहित करती है, लेकिन इसका उपयोग छोटे मात्रा में डेटा के साथ किया जाना चाहिए।
इस डेटा को सीधे एक विश्वसनीय कंप्यूटर के माध्यम से लंबे समय तक एक्सेस नहीं किया जा सकता है, लेकिन इसे बैकअप करके एक्सेस किया जा सकता है।
आप NSUserDefaults
का उपयोग करके सहेजी गई जानकारी को objection के ios nsuserdefaults get
का उपयोग करके डंप कर सकते हैं।
आप ऐप द्वारा उपयोग की जाने वाली सभी plist फ़ाइलों को खोजने के लिए /private/var/mobile/Containers/Data/Application/{APPID}
पर जा सकते हैं और चलाएं:
फाइलों को XML या बाइनरी (bplist) प्रारूप से XML में परिवर्तित करने के लिए, आपके ऑपरेटिंग सिस्टम के आधार पर विभिन्न विधियाँ उपलब्ध हैं:
macOS उपयोगकर्ताओं के लिए: plutil
कमांड का उपयोग करें। यह macOS (10.2+) में एक अंतर्निहित उपकरण है, जिसे इस उद्देश्य के लिए डिज़ाइन किया गया है:
Linux उपयोगकर्ताओं के लिए: पहले libplist-utils
स्थापित करें, फिर अपने फ़ाइल को परिवर्तित करने के लिए plistutil
का उपयोग करें:
Within an Objection Session: मोबाइल अनुप्रयोगों का विश्लेषण करने के लिए, एक विशिष्ट कमांड आपको plist फ़ाइलों को सीधे परिवर्तित करने की अनुमति देता है:
Core Data
आपके एप्लिकेशन में ऑब्जेक्ट्स के मॉडल लेयर को प्रबंधित करने के लिए एक ढांचा है। Core Data अपने स्थायी स्टोर के रूप में SQLite का उपयोग कर सकता है, लेकिन ढांचा स्वयं एक डेटाबेस नहीं है।
CoreData डिफ़ॉल्ट रूप से अपने डेटा को एन्क्रिप्ट नहीं करता है। हालाँकि, CoreData में एक अतिरिक्त एन्क्रिप्शन लेयर जोड़ी जा सकती है। अधिक विवरण के लिए GitHub Repo देखें।
आप किसी एप्लिकेशन की SQLite Core Data जानकारी को पथ /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support
में पा सकते हैं।
यदि आप SQLite खोल सकते हैं और संवेदनशील जानकारी तक पहुँच सकते हैं, तो आपने एक गलत कॉन्फ़िगरेशन पाया है।
YapDatabase एक की/मान भंडार है जो SQLite के ऊपर बनाया गया है। चूंकि Yap डेटाबेस sqlite डेटाबेस हैं, आप उन्हें पिछले अनुभाग में दिए गए कमांड का उपयोग करके ढूंढ सकते हैं।
ऐप्लिकेशन के लिए अपना खुद का sqlite डेटाबेस बनाना सामान्य है। वे संवेदनशील डेटा को उन पर स्टोर कर सकते हैं और इसे एन्क्रिप्ट नहीं कर सकते। इसलिए, हमेशा ऐप्लिकेशन की निर्देशिका के अंदर हर डेटाबेस की जांच करना दिलचस्प होता है। इसलिए उस ऐप्लिकेशन की निर्देशिका पर जाएं जहां डेटा सहेजा गया है (/private/var/mobile/Containers/Data/Application/{APPID}
)
डेवलपर्स को डेटा स्टोर और सिंक करने की अनुमति मिलती है NoSQL क्लाउड-होस्टेड डेटाबेस के माध्यम से Firebase Real-Time Databases। JSON प्रारूप में स्टोर किया गया डेटा सभी जुड़े हुए क्लाइंट्स के साथ वास्तविक समय में समन्वयित होता है।
आप यहाँ गलत कॉन्फ़िगर किए गए Firebase डेटाबेस की जांच करने के लिए देख सकते हैं:
Firebase DatabaseRealm Objective-C और Realm Swift डेटा स्टोरेज के लिए एक शक्तिशाली विकल्प प्रदान करते हैं, जो Apple द्वारा प्रदान नहीं किया गया है। डिफ़ॉल्ट रूप से, वे डेटा को अनएन्क्रिप्टेड स्टोर करते हैं, विशेष कॉन्फ़िगरेशन के माध्यम से एन्क्रिप्शन उपलब्ध है।
डेटाबेस निम्नलिखित स्थान पर स्थित हैं: /private/var/mobile/Containers/Data/Application/{APPID}
। इन फ़ाइलों का अन्वेषण करने के लिए, कोई कमांड का उपयोग कर सकता है:
इन डेटाबेस फ़ाइलों को देखने के लिए, Realm Studio उपकरण की सिफारिश की जाती है।
एक Realm डेटाबेस के भीतर एन्क्रिप्शन लागू करने के लिए, निम्नलिखित कोड स्निपेट का उपयोग किया जा सकता है:
Couchbase Lite को एक हल्का और एंबेडेड डेटाबेस इंजन के रूप में वर्णित किया गया है जो डॉक्यूमेंट-ओरिएंटेड (NoSQL) दृष्टिकोण का पालन करता है। इसे iOS और macOS के लिए मूल रूप से डिज़ाइन किया गया है, यह डेटा को सहजता से सिंक करने की क्षमता प्रदान करता है।
डिवाइस पर संभावित Couchbase डेटाबेस की पहचान करने के लिए, निम्नलिखित निर्देशिका की जांच की जानी चाहिए:
iOS ऐप्स के कुकीज़ को प्रत्येक ऐप्स के फ़ोल्डर के अंदर Library/Cookies/cookies.binarycookies
में स्टोर करता है। हालाँकि, डेवलपर्स कभी-कभी उन्हें कीचेन में सहेजने का निर्णय लेते हैं क्योंकि उल्लेखित कुकी फ़ाइल को बैकअप में एक्सेस किया जा सकता है।
कुकी फ़ाइल की जांच करने के लिए आप इस पायथन स्क्रिप्ट का उपयोग कर सकते हैं या objection के ios cookies get
का उपयोग कर सकते हैं।
आप इन फ़ाइलों को JSON प्रारूप में परिवर्तित करने और डेटा की जांच करने के लिए objection का भी उपयोग कर सकते हैं।
डिफ़ॉल्ट रूप से NSURLSession डेटा को स्टोर करता है, जैसे कि HTTP अनुरोध और प्रतिक्रियाएँ Cache.db डेटाबेस में। इस डेटाबेस में संवेदनशील डेटा हो सकता है, यदि टोकन, उपयोगकर्ता नाम या कोई अन्य संवेदनशील जानकारी कैश की गई है। कैश की गई जानकारी खोजने के लिए ऐप के डेटा निर्देशिका को खोलें (/var/mobile/Containers/Data/Application/<UUID>
) और /Library/Caches/<Bundle Identifier>
पर जाएँ। WebKit कैश भी Cache.db फ़ाइल में स्टोर किया जा रहा है। Objection इस डेटाबेस को sqlite connect Cache.db
कमांड के साथ खोल सकता है और इसके साथ इंटरैक्ट कर सकता है, क्योंकि यह एक सामान्य SQLite डेटाबेस है।
यह सिफारिश की जाती है कि इस डेटा को कैशिंग बंद कर दिया जाए, क्योंकि इसमें अनुरोध या प्रतिक्रिया में संवेदनशील जानकारी हो सकती है। नीचे दी गई सूची विभिन्न तरीकों को दिखाती है:
साइन आउट करने के बाद कैश की गई प्रतिक्रियाएँ हटाने की सिफारिश की जाती है। यह Apple द्वारा प्रदान की गई विधि removeAllCachedResponses
के साथ किया जा सकता है। आप इस विधि को इस प्रकार कॉल कर सकते हैं:
URLCache.shared.removeAllCachedResponses()
यह विधि Cache.db फ़ाइल से सभी कैश किए गए अनुरोधों और प्रतिक्रियाओं को हटा देगी। 2. यदि आपको कुकीज़ के लाभ का उपयोग करने की आवश्यकता नहीं है, तो URLSession की .ephemeral कॉन्फ़िगरेशन प्रॉपर्टी का उपयोग करने की सिफारिश की जाती है, जो कुकीज़ और कैश को सहेजने को बंद कर देगी।
An ephemeral session configuration object is similar to a default session configuration (see default), except that the corresponding session object doesn’t store caches, credential stores, or any session-related data to disk. Instead, session-related data is stored in RAM. The only time an ephemeral session writes data to disk is when you tell it to write the contents of a URL to a file.
3. कैश को .notAllowed पर सेट करके भी बंद किया जा सकता है। यह किसी भी तरीके से कैश को स्टोर करने को बंद कर देगा, चाहे वह मेमोरी में हो या डिस्क पर।
जब भी आप होम बटन दबाते हैं, iOS वर्तमान स्क्रीन का एक स्नैपशॉट लेता है ताकि एप्लिकेशन में संक्रमण को बहुत सुचारू तरीके से किया जा सके। हालाँकि, यदि वर्तमान स्क्रीन में संवेदनशील डेटा मौजूद है, तो यह छवि में सहेजा जाएगा (जो रीबूट के दौरान स्थायी रहता है)। ये स्नैपशॉट हैं जिन तक आप ऐप्स के बीच स्विच करने के लिए होम स्क्रीन पर डबल टैप करके भी पहुँच सकते हैं।
जब तक iPhone जेलब्रोकन नहीं है, हमलावर को इन स्क्रीनशॉट्स को देखने के लिए डिवाइस अनब्लॉक करने की एक्सेस होनी चाहिए। डिफ़ॉल्ट रूप से अंतिम स्नैपशॉट ऐप के सैंडबॉक्स में Library/Caches/Snapshots/
या Library/SplashBoard/Snapshots
फ़ोल्डर में स्टोर किया जाता है (विश्वसनीय कंप्यूटर iOX 7.0 से फ़ाइल सिस्टम तक पहुँच नहीं सकते)।
इस बुरे व्यवहार को रोकने का एक तरीका यह है कि स्नैपशॉट लेने से पहले एक खाली स्क्रीन डालें या संवेदनशील डेटा को हटा दें, ApplicationDidEnterBackground()
फ़ंक्शन का उपयोग करके।
नीचे एक नमूना सुधार विधि है जो एक डिफ़ॉल्ट स्क्रीनशॉट सेट करेगी।
Swift:
उद्देश्य-सी:
यह बैकग्राउंड इमेज को overlayImage.png
पर सेट करता है जब भी एप्लिकेशन बैकग्राउंड में जाता है। यह संवेदनशील डेटा लीक को रोकता है क्योंकि overlayImage.png
हमेशा वर्तमान दृश्य को ओवरराइड करेगा।
iOS की कीचेन तक पहुँचने और प्रबंधित करने के लिए, Keychain-Dumper जैसे उपकरण उपलब्ध हैं, जो जेलब्रोकन उपकरणों के लिए उपयुक्त हैं। इसके अतिरिक्त, Objection समान उद्देश्यों के लिए ios keychain dump
कमांड प्रदान करता है।
NSURLCredential क्लास संवेदनशील जानकारी को सीधे कीचेन में सहेजने के लिए आदर्श है, NSUserDefaults या अन्य रैपर की आवश्यकता को बायपास करते हुए। लॉगिन के बाद क्रेडेंशियल्स को स्टोर करने के लिए, निम्नलिखित स्विफ्ट कोड का उपयोग किया जाता है:
To extract these stored credentials, Objection's command ios nsurlcredentialstorage dump
is utilized.
iOS 8.0 से, उपयोगकर्ता कस्टम कीबोर्ड एक्सटेंशन स्थापित कर सकते हैं, जिन्हें Settings > General > Keyboard > Keyboards के तहत प्रबंधित किया जा सकता है। जबकि ये कीबोर्ड विस्तारित कार्यक्षमता प्रदान करते हैं, वे कीस्ट्रोक लॉगिंग और डेटा को बाहरी सर्वरों पर भेजने का जोखिम उठाते हैं, हालांकि उपयोगकर्ताओं को नेटवर्क एक्सेस की आवश्यकता वाले कीबोर्ड के बारे में सूचित किया जाता है। ऐप्स को संवेदनशील जानकारी के लिए कस्टम कीबोर्ड के उपयोग को प्रतिबंधित करना चाहिए।
सुरक्षा सिफारिशें:
सुरक्षा बढ़ाने के लिए तीसरे पक्ष के कीबोर्ड को बंद करने की सलाह दी जाती है।
डिफ़ॉल्ट iOS कीबोर्ड की ऑटोकरेक्ट और ऑटो-सजेशन सुविधाओं के बारे में जागरूक रहें, जो संवेदनशील जानकारी को Library/Keyboard/{locale}-dynamic-text.dat
या /private/var/mobile/Library/Keyboard/dynamic-text.dat
में कैश फ़ाइलों में संग्रहीत कर सकती हैं। इन कैश फ़ाइलों की नियमित रूप से जांच की जानी चाहिए। कैश डेटा को साफ़ करने के लिए Settings > General > Reset > Reset Keyboard Dictionary के माध्यम से कीबोर्ड शब्दकोश को रीसेट करने की सिफारिश की जाती है।
नेटवर्क ट्रैफ़िक को इंटरसेप्ट करना यह प्रकट कर सकता है कि क्या एक कस्टम कीबोर्ड दूरस्थ रूप से कीस्ट्रोक्स को भेज रहा है।
UITextInputTraits प्रोटोकॉल ऑटोकरेक्शन और सुरक्षित टेक्स्ट एंट्री को प्रबंधित करने के लिए गुण प्रदान करता है, जो संवेदनशील जानकारी कैशिंग को रोकने के लिए आवश्यक है। उदाहरण के लिए, ऑटोकरेक्शन को बंद करना और सुरक्षित टेक्स्ट एंट्री को सक्षम करना निम्नलिखित के साथ किया जा सकता है:
इसके अतिरिक्त, डेवलपर्स को यह सुनिश्चित करना चाहिए कि टेक्स्ट फ़ील्ड, विशेष रूप से संवेदनशील जानकारी जैसे पासवर्ड और पिन दर्ज करने के लिए, कैशिंग को अक्षम करें autocorrectionType
को UITextAutocorrectionTypeNo
और secureTextEntry
को YES
सेट करके।
कोड को डिबग करना अक्सर logging के उपयोग को शामिल करता है। इसमें एक जोखिम होता है क्योंकि logs में संवेदनशील जानकारी हो सकती है। पहले, iOS 6 और इससे पहले के संस्करणों में, logs सभी ऐप्स के लिए सुलभ थे, जिससे संवेदनशील डेटा लीक होने का जोखिम था। अब, एप्लिकेशन केवल अपने logs तक पहुँचने के लिए प्रतिबंधित हैं।
इन प्रतिबंधों के बावजूद, एक हमलावर जिसे अनलॉक किए गए डिवाइस तक भौतिक पहुँच है अभी भी इसे एक कंप्यूटर से डिवाइस को कनेक्ट करके और logs को पढ़कर भुनाने में सक्षम हो सकता है। यह ध्यान रखना महत्वपूर्ण है कि logs ऐप के अनइंस्टॉलेशन के बाद भी डिस्क पर बने रहते हैं।
जोखिमों को कम करने के लिए, यह सलाह दी जाती है कि ऐप के साथ पूरी तरह से इंटरैक्ट करें, इसके सभी कार्यात्मकताओं और इनपुट्स का अन्वेषण करें ताकि यह सुनिश्चित हो सके कि कोई संवेदनशील जानकारी अनजाने में लॉग नहीं की जा रही है।
जब संभावित लीक के लिए ऐप के स्रोत कोड की समीक्षा करें, तो predefined और custom logging statements दोनों के लिए NSLog
, NSAssert
, NSCAssert
, fprintf
जैसे कीवर्ड का उपयोग करें, और किसी भी कस्टम कार्यान्वयन के लिए Logging
या Logfile
का उल्लेख करें।
ऐप्स विभिन्न प्रकार की जानकारी लॉग करते हैं जो संवेदनशील हो सकती है। इन लॉग्स की निगरानी करने के लिए, उपकरण और कमांड जैसे:
उपयोगी हैं। इसके अतिरिक्त, Xcode कंसोल लॉग एकत्र करने का एक तरीका प्रदान करता है:
Xcode खोलें।
iOS डिवाइस कनेक्ट करें।
Window -> Devices and Simulators पर जाएं।
अपने डिवाइस का चयन करें।
उस समस्या को ट्रिगर करें जिसे आप जांच रहे हैं।
नए विंडो में लॉग देखने के लिए Open Console बटन का उपयोग करें।
अधिक उन्नत लॉगिंग के लिए, डिवाइस शेल से कनेक्ट करना और socat का उपयोग करना वास्तविक समय में लॉग मॉनिटरिंग प्रदान कर सकता है:
लॉग गतिविधियों को देखने के लिए आदेशों के बाद, जो समस्याओं का निदान करने या लॉग में संभावित डेटा लीक की पहचान करने के लिए अमूल्य हो सकते हैं।
Trickest का उपयोग करें ताकि आप दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित वर्कफ़्लो को आसानी से बना और स्वचालित कर सकें। आज ही एक्सेस प्राप्त करें:
ऑटो-बैकअप सुविधाएँ iOS में एकीकृत हैं, जो iTunes (macOS Catalina तक), Finder (macOS Catalina के बाद) या iCloud के माध्यम से डिवाइस डेटा की प्रतियों को बनाने की सुविधा प्रदान करती हैं। ये बैकअप लगभग सभी डिवाइस डेटा को शामिल करते हैं, अत्यधिक संवेदनशील तत्वों जैसे Apple Pay विवरण और Touch ID कॉन्फ़िगरेशन को छोड़कर।
स्थापित ऐप्स और उनके डेटा का बैकअप में शामिल होना संभावित डेटा लीक और बैकअप संशोधनों के कारण ऐप कार्यक्षमता में परिवर्तन का जोखिम उठाता है। इन जोखिमों को कम करने के लिए सलाह दी जाती है कि किसी भी ऐप के निर्देशिका या उसके उपनिर्देशिकाओं में संवेदनशील जानकारी को स्पष्ट पाठ में न रखें।
Documents/
और Library/Application Support/
में फ़ाइलें डिफ़ॉल्ट रूप से बैकअप की जाती हैं। डेवलपर्स NSURL setResourceValue:forKey:error:
का उपयोग करके NSURLIsExcludedFromBackupKey
के साथ विशिष्ट फ़ाइलों या निर्देशिकाओं को बैकअप से बाहर कर सकते हैं। यह प्रथा संवेदनशील डेटा को बैकअप में शामिल होने से बचाने के लिए महत्वपूर्ण है।
किसी ऐप की बैकअप सुरक्षा का आकलन करने के लिए, पहले एक बैकअप बनाएं जो Finder का उपयोग करके किया गया हो, फिर इसे Apple के आधिकारिक दस्तावेज़ से मार्गदर्शन प्राप्त करके खोजें। संवेदनशील डेटा या कॉन्फ़िगरेशन का विश्लेषण करें जो ऐप के व्यवहार को प्रभावित करने के लिए बदला जा सकता है।
संवेदनशील जानकारी को कमांड-लाइन उपकरणों या iMazing जैसे अनुप्रयोगों का उपयोग करके खोजा जा सकता है। एन्क्रिप्टेड बैकअप के लिए, एन्क्रिप्शन की उपस्थिति की पुष्टि "Manifest.plist" फ़ाइल में "IsEncrypted" कुंजी की जांच करके की जा सकती है जो बैकअप की जड़ में होती है।
For dealing with encrypted backups, Python scripts available in DinoSec's GitHub repo, like backup_tool.py and backup_passwd.py, may be useful, albeit potentially requiring adjustments for compatibility with the latest iTunes/Finder versions. The iOSbackup tool is another option for accessing files within password-protected backups.
एक उदाहरण ऐप व्यवहार को बैकअप संशोधनों के माध्यम से बदलने का Bither bitcoin wallet app में प्रदर्शित किया गया है, जहां UI लॉक PIN net.bither.plist
में pin_code कुंजी के तहत संग्रहीत होता है। plist से इस कुंजी को हटाने और बैकअप को पुनर्स्थापित करने से PIN आवश्यकता हटा दी जाती है, जिससे बिना किसी प्रतिबंध के पहुंच मिलती है।
जब किसी एप्लिकेशन की मेमोरी में संग्रहीत संवेदनशील जानकारी से निपटते हैं, तो इस डेटा के एक्सपोजर समय को सीमित करना महत्वपूर्ण है। मेमोरी सामग्री की जांच करने के लिए दो प्रमुख दृष्टिकोण हैं: मेमोरी डंप बनाना और वास्तविक समय में मेमोरी का विश्लेषण करना। दोनों विधियों में उनकी चुनौतियाँ होती हैं, जिसमें डंप प्रक्रिया या विश्लेषण के दौरान महत्वपूर्ण डेटा को चूकने की संभावना शामिल है।
For both jailbroken and non-jailbroken devices, tools like objection and Fridump allow for the dumping of an app's process memory. Once dumped, analyzing this data requires various tools, depending on the nature of the information you're searching for.
To extract strings from a memory dump, commands such as strings
or rabin2 -zz
can be used:
विशिष्ट डेटा प्रकारों या पैटर्न की खोज सहित अधिक विस्तृत विश्लेषण के लिए, radare2 व्यापक खोज क्षमताएँ प्रदान करता है:
r2frida एक शक्तिशाली विकल्प प्रदान करता है जो बिना मेमोरी डंप की आवश्यकता के वास्तविक समय में एक ऐप की मेमोरी का निरीक्षण करने के लिए है। यह उपकरण चल रहे ऐप्लिकेशन की मेमोरी पर सीधे खोज आदेशों को निष्पादित करने की अनुमति देता है:
कुछ डेवलपर्स संवेदनशील डेटा को स्थानीय स्टोरेज में सहेजते हैं और इसे कोड में हार्डकोडेड/पूर्वानुमानित कुंजी के साथ एन्क्रिप्ट करते हैं। ऐसा नहीं करना चाहिए क्योंकि कुछ रिवर्सिंग हमलावरों को गोपनीय जानकारी निकालने की अनुमति दे सकती है।
डेवलपर्स को deprecated algorithms का उपयोग checks करने, store करने या send करने के लिए नहीं करना चाहिए। इनमें से कुछ एल्गोरिदम हैं: RC4, MD4, MD5, SHA1... यदि hashes का उपयोग पासवर्ड को स्टोर करने के लिए किया जाता है, तो नमक के साथ hashes ब्रूट-फोर्स resistant का उपयोग किया जाना चाहिए।
मुख्य जांच करने के लिए यह है कि क्या आप कोड में hardcoded पासवर्ड/गुप्त जानकारी खोज सकते हैं, या क्या वे predictable हैं, और क्या कोड किसी प्रकार के weak cryptography एल्गोरिदम का उपयोग कर रहा है।
यह जानना दिलचस्प है कि आप objection का उपयोग करके कुछ crypto libraries को स्वचालित रूप से monitor कर सकते हैं:
For अधिक जानकारी about iOS cryptographic APIs and libraries access https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography
स्थानीय प्रमाणीकरण एक महत्वपूर्ण भूमिका निभाता है, विशेष रूप से जब यह दूरस्थ एंडपॉइंट पर क्रिप्टोग्राफिक विधियों के माध्यम से पहुंच की सुरक्षा की बात आती है। यहाँ का सार यह है कि उचित कार्यान्वयन के बिना, स्थानीय प्रमाणीकरण तंत्र को दरकिनार किया जा सकता है।
Apple का स्थानीय प्रमाणीकरण ढांचा और कीचेन उपयोगकर्ता प्रमाणीकरण संवादों को सुविधाजनक बनाने और गुप्त डेटा को सुरक्षित रूप से संभालने के लिए मजबूत APIs प्रदान करते हैं। Secure Enclave Touch ID के लिए फिंगरप्रिंट ID को सुरक्षित करता है, जबकि Face ID चेहरे की पहचान पर निर्भर करता है बिना बायोमेट्रिक डेटा से समझौता किए।
Touch ID/Face ID को एकीकृत करने के लिए, डेवलपर्स के पास दो API विकल्प हैं:
LocalAuthentication.framework
उच्च-स्तरीय उपयोगकर्ता प्रमाणीकरण के लिए बायोमेट्रिक डेटा तक पहुंच के बिना।
Security.framework
निचले स्तर की कीचेन सेवाओं तक पहुंच के लिए, बायोमेट्रिक प्रमाणीकरण के साथ गुप्त डेटा को सुरक्षित करना। विभिन्न ओपन-सोर्स रैपर कीचेन तक पहुंच को सरल बनाते हैं।
हालांकि, दोनों LocalAuthentication.framework
और Security.framework
कमजोरियों को प्रस्तुत करते हैं, क्योंकि वे मुख्य रूप से बूलियन मान लौटाते हैं बिना प्रमाणीकरण प्रक्रियाओं के लिए डेटा को प्रसारित किए, जिससे उन्हें दरकिनार करने के लिए संवेदनशील बनाते हैं (देखें Don't touch me that way, by David Lindner et al).
उपयोगकर्ताओं से प्रमाणीकरण के लिए प्रेरित करने के लिए, डेवलपर्स को LAContext
वर्ग के भीतर evaluatePolicy
विधि का उपयोग करना चाहिए, निम्नलिखित में से चुनते हुए:
deviceOwnerAuthentication
: Touch ID या डिवाइस पासकोड के लिए प्रेरित करता है, यदि कोई भी सक्षम नहीं है तो विफल होता है।
deviceOwnerAuthenticationWithBiometrics
: विशेष रूप से Touch ID के लिए प्रेरित करता है।
सफल प्रमाणीकरण evaluatePolicy
से बूलियन लौटाने वाले मान द्वारा संकेतित होता है, जो एक संभावित सुरक्षा दोष को उजागर करता है।
iOS ऐप्स में स्थानीय प्रमाणीकरण को लागू करने में कीचेन APIs का उपयोग करना शामिल है ताकि प्रमाणीकरण टोकन जैसे गुप्त डेटा को सुरक्षित रूप से संग्रहीत किया जा सके। यह प्रक्रिया सुनिश्चित करती है कि डेटा केवल उपयोगकर्ता द्वारा, उनके डिवाइस पासकोड या बायोमेट्रिक प्रमाणीकरण जैसे Touch ID का उपयोग करके ही एक्सेस किया जा सके।
कीचेन SecAccessControl
विशेषता के साथ आइटम सेट करने की क्षमता प्रदान करता है, जो उपयोगकर्ता द्वारा Touch ID या डिवाइस पासकोड के माध्यम से सफल प्रमाणीकरण होने तक आइटम तक पहुंच को प्रतिबंधित करता है। यह सुविधा सुरक्षा बढ़ाने के लिए महत्वपूर्ण है।
नीचे Swift और Objective-C में कोड उदाहरण दिए गए हैं जो दिखाते हैं कि कैसे कीचेन में एक स्ट्रिंग को सहेजना और पुनः प्राप्त करना है, इन सुरक्षा सुविधाओं का लाभ उठाते हुए। उदाहरण विशेष रूप से दिखाते हैं कि कैसे एक्सेस नियंत्रण स्थापित किया जाए ताकि Touch ID प्रमाणीकरण की आवश्यकता हो और सुनिश्चित करें कि डेटा केवल उसी डिवाइस पर उपलब्ध हो जिस पर इसे सेट किया गया था, इस शर्त के तहत कि एक डिवाइस पासकोड कॉन्फ़िगर किया गया है।
अब हम कीचेन से सहेजे गए आइटम को अनुरोध कर सकते हैं। कीचेन सेवाएँ उपयोगकर्ता को प्रमाणीकरण संवाद प्रस्तुत करेंगी और उपयुक्त फिंगरप्रिंट प्रदान किया गया या नहीं, इसके आधार पर डेटा या निल लौटाएँगी।
किसी ऐप में फ्रेमवर्क के उपयोग का पता ऐप बाइनरी की साझा डायनामिक लाइब्रेरी की सूची का विश्लेषण करके लगाया जा सकता है। यह otool
का उपयोग करके किया जा सकता है:
यदि किसी ऐप में LocalAuthentication.framework
का उपयोग किया गया है, तो आउटपुट में निम्नलिखित दोनों पंक्तियाँ शामिल होंगी (याद रखें कि LocalAuthentication.framework
के पीछे Security.framework
का उपयोग होता है):
यदि Security.framework
का उपयोग किया गया है, तो केवल दूसरा ही दिखाया जाएगा।
Objection Biometrics Bypass के माध्यम से, जो इस GitHub पृष्ठ पर स्थित है, LocalAuthentication तंत्र को पार करने के लिए एक तकनीक उपलब्ध है। इस दृष्टिकोण का मूल उद्देश्य Frida का उपयोग करके evaluatePolicy
फ़ंक्शन में हेरफेर करना है, यह सुनिश्चित करते हुए कि यह लगातार True
परिणाम देता है, वास्तविक प्रमाणीकरण सफलता की परवाह किए बिना। यह दोषपूर्ण बायोमेट्रिक प्रमाणीकरण प्रक्रियाओं को दरकिनार करने के लिए विशेष रूप से उपयोगी है।
इस बाईपास को सक्रिय करने के लिए, निम्नलिखित कमांड का उपयोग किया जाता है:
यह कमांड एक अनुक्रम शुरू करता है जहाँ Objection एक कार्य पंजीकृत करता है जो प्रभावी रूप से evaluatePolicy
जांच के परिणाम को True
में बदल देता है।
evaluatePolicy
के उपयोग का एक उदाहरण DVIA-v2 एप्लिकेशन से:
स्थानीय प्रमाणीकरण के bypass को प्राप्त करने के लिए, एक Frida स्क्रिप्ट लिखी गई है। यह स्क्रिप्ट evaluatePolicy जांच को लक्षित करती है, इसके कॉलबैक को इंटरसेप्ट करते हुए यह सुनिश्चित करती है कि यह success=1 लौटाए। कॉलबैक के व्यवहार को बदलकर, प्रमाणीकरण जांच को प्रभावी रूप से बायपास किया जाता है।
नीचे दी गई स्क्रिप्ट evaluatePolicy विधि के परिणाम को संशोधित करने के लिए इंजेक्ट की जाती है। यह हमेशा सफलता को इंगित करने के लिए कॉलबैक के परिणाम को बदलती है।
Frida स्क्रिप्ट को इंजेक्ट करने और बायोमेट्रिक प्रमाणीकरण को बायपास करने के लिए, निम्नलिखित कमांड का उपयोग किया जाता है:
यह महत्वपूर्ण है कि यह जांचें कि कोई संचार बिना एन्क्रिप्शन के नहीं हो रहा है और यह भी कि एप्लिकेशन सर्वर के TLS प्रमाणपत्र को सही तरीके से मान्य कर रहा है। इन प्रकार के मुद्दों की जांच करने के लिए आप Burp जैसे प्रॉक्सी का उपयोग कर सकते हैं:
iOS Burp Suite ConfigurationTLS प्रमाणपत्र को मान्य करने में एक सामान्य समस्या यह है कि यह जांचना कि प्रमाणपत्र को विश्वसनीय CA द्वारा हस्ताक्षरित किया गया था, लेकिन यह नहीं जांचना कि प्रमाणपत्र का होस्टनेम वह होस्टनेम है जिसे एक्सेस किया जा रहा है। इस मुद्दे की जांच करने के लिए Burp का उपयोग करते समय, iPhone में Burp CA को विश्वसनीय बनाने के बाद, आप एक अलग होस्टनेम के लिए Burp के साथ एक नया प्रमाणपत्र बना सकते हैं और इसका उपयोग कर सकते हैं। यदि एप्लिकेशन अभी भी काम करता है, तो कुछ न कुछ कमजोर है।
यदि एक एप्लिकेशन सही तरीके से SSL पिनिंग का उपयोग कर रहा है, तो एप्लिकेशन केवल तभी काम करेगा जब प्रमाणपत्र वही हो जो अपेक्षित हो। जब एक एप्लिकेशन का परीक्षण करते समय यह एक समस्या हो सकती है क्योंकि Burp अपना प्रमाणपत्र प्रदान करेगा। इस सुरक्षा को बायपास करने के लिए एक जेलब्रोकन डिवाइस के अंदर, आप SSL Kill Switch एप्लिकेशन स्थापित कर सकते हैं या Burp Mobile Assistant स्थापित कर सकते हैं।
आप objection's ios sslpinning disable
का भी उपयोग कर सकते हैं।
/System/Library
में आप फोन में सिस्टम एप्लिकेशनों द्वारा उपयोग किए जाने वाले फ्रेमवर्क पा सकते हैं।
App Store से उपयोगकर्ता द्वारा स्थापित एप्लिकेशन /User/Applications
के अंदर स्थित होते हैं।
और /User/Library
में उपयोगकर्ता स्तर के एप्लिकेशनों द्वारा सहेजे गए डेटा होते हैं।
आप /User/Library/Notes/notes.sqlite
तक पहुँच सकते हैं ताकि एप्लिकेशन के अंदर सहेजे गए नोट्स को पढ़ सकें।
एक स्थापित एप्लिकेशन के फ़ोल्डर के अंदर (/User/Applications/<APP ID>/
) आप कुछ दिलचस्प फ़ाइलें पा सकते हैं:
iTunesArtwork
: ऐप द्वारा उपयोग किया जाने वाला आइकन
iTunesMetadata.plist
: App Store में उपयोग किए जाने वाले ऐप की जानकारी
/Library/*
: प्राथमिकताएँ और कैश शामिल हैं। /Library/Cache/Snapshots/*
में आप एप्लिकेशन को बैकग्राउंड में भेजने से पहले किए गए स्नैपशॉट को पा सकते हैं।
डेवलपर्स अपने ऐप के सभी इंस्टॉलेशन को तुरंत पैच कर सकते हैं बिना एप्लिकेशन को App Store में फिर से सबमिट किए और इसके स्वीकृत होने की प्रतीक्षा किए। इसके लिए आमतौर पर JSPatch** का उपयोग किया जाता है।** लेकिन अन्य विकल्प भी हैं जैसे Siren और react-native-appstore-version-checker। यह एक खतरनाक तंत्र है जिसे दुर्भावनापूर्ण तृतीय पक्ष SDK द्वारा दुरुपयोग किया जा सकता है, इसलिए यह अनुशंसा की जाती है कि स्वचालित अपडेटिंग के लिए कौन सा तरीका उपयोग किया जा रहा है (यदि कोई हो) की जांच करें और इसका परीक्षण करें। आप इस उद्देश्य के लिए ऐप का एक पिछला संस्करण डाउनलोड करने का प्रयास कर सकते हैं।
3rd पार्टी SDKs के साथ एक महत्वपूर्ण चुनौती उनके कार्यात्मकताओं पर सूक्ष्म नियंत्रण की कमी है। डेवलपर्स के पास एक विकल्प होता है: या तो SDK को एकीकृत करें और इसकी सभी सुविधाओं को स्वीकार करें, जिसमें संभावित सुरक्षा कमजोरियाँ और गोपनीयता संबंधी चिंताएँ शामिल हैं, या इसके लाभों को पूरी तरह से छोड़ दें। अक्सर, डेवलपर्स इन SDKs के भीतर कमजोरियों को स्वयं पैच करने में असमर्थ होते हैं। इसके अलावा, जैसे-जैसे SDKs समुदाय में विश्वास प्राप्त करते हैं, कुछ में मैलवेयर शामिल हो सकता है।
तीसरे पक्ष के SDKs द्वारा प्रदान की जाने वाली सेवाओं में उपयोगकर्ता व्यवहार ट्रैकिंग, विज्ञापन प्रदर्शन, या उपयोगकर्ता अनुभव में सुधार शामिल हो सकते हैं। हालाँकि, यह एक जोखिम प्रस्तुत करता है क्योंकि डेवलपर्स इन लाइब्रेरी द्वारा निष्पादित कोड के बारे में पूरी तरह से अवगत नहीं हो सकते हैं, जिससे संभावित गोपनीयता और सुरक्षा जोखिम हो सकते हैं। यह महत्वपूर्ण है कि तीसरे पक्ष की सेवाओं के साथ साझा की गई जानकारी को आवश्यकतानुसार सीमित किया जाए और यह सुनिश्चित किया जाए कि कोई संवेदनशील डेटा उजागर न हो।
तीसरे पक्ष की सेवाओं का कार्यान्वयन आमतौर पर दो रूपों में आता है: एक स्वतंत्र पुस्तकालय या एक पूर्ण SDK। उपयोगकर्ता की गोपनीयता की रक्षा के लिए, इन सेवाओं के साथ साझा किए गए किसी भी डेटा को गुमनाम किया जाना चाहिए ताकि व्यक्तिगत पहचान योग्य जानकारी (PII) का खुलासा न हो।
एक एप्लिकेशन द्वारा उपयोग की जाने वाली लाइब्रेरी की पहचान करने के लिए, otool
कमांड का उपयोग किया जा सकता है। इस उपकरण को एप्लिकेशन और इसके द्वारा उपयोग की जाने वाली प्रत्येक साझा लाइब्रेरी के खिलाफ चलाया जाना चाहिए ताकि अतिरिक्त लाइब्रेरी का पता लगाया जा सके।
OWASP iGoat https://github.com/OWASP/igoat <<< Objective-C संस्करण https://github.com/OWASP/iGoat-Swift <<< Swift संस्करण
Trickest का उपयोग करें ताकि आप आसानी से वर्कफ़्लो बना और स्वचालित कर सकें जो दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित हैं। आज ही एक्सेस प्राप्त करें:
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)