iOS Pentesting
Last updated
Last updated
Dünyanın en gelişmiş topluluk araçlarıyla desteklenen iş akışlarını kolayca oluşturmak ve otomatikleştirmek için Trickest kullanın. Bugün Erişim Alın:
Bu sayfada iOS simülatörü, emülatörler ve jailbreaking hakkında bilgi bulabilirsiniz:
iOS Testing EnvironmentTest sırasında birçok işlem önerilecektir (cihaza bağlanma, dosyaları okuma/yazma/yükleme/indirme, bazı araçları kullanma...). Bu nedenle, bu eylemlerden herhangi birini nasıl gerçekleştireceğinizi bilmiyorsanız, lütfen sayfayı okumaya başlayın:
iOS Basic Testing OperationsAşağıdaki adımlar için uygulama cihazda kurulu olmalıdır ve uygulamanın IPA dosyasını zaten almış olmalıdır. Bunu nasıl yapacağınızı öğrenmek için Temel iOS Test İşlemleri sayfasını okuyun.
IPA dosyasına otomatik Statik Analiz gerçekleştirmek için MobSF aracını kullanmanız önerilir.
İkili dosyada mevcut olan korumaların tanımlanması:
PIE (Position Independent Executable): Etkinleştirildiğinde, uygulama her başlatıldığında rastgele bir bellek adresine yüklenir, bu da başlangıç bellek adresini tahmin etmeyi zorlaştırır.
Stack Canaries: Yığın bütünlüğünü doğrulamak için, bir işlev çağrılmadan önce yığında bir ‘canary’ değeri yerleştirilir ve işlev sona erdiğinde tekrar doğrulanır.
ARC (Automatic Reference Counting): Yaygın bellek bozulma hatalarını önlemek için
Şifreli İkili: İkili dosya şifrelenmiş olmalıdır
Hassas/Güvensiz Fonksiyonların Tanımlanması
Zayıf Hashing Algoritmaları
Güvensiz Rastgele Fonksiyonlar
Güvensiz ‘Malloc’ Fonksiyonu
Güvensiz ve Açık Fonksiyonlar
MobSF tarafından gerçekleştirilen dinamik analizi kontrol edin. Farklı görünümler arasında gezinmeniz ve onlarla etkileşimde bulunmanız gerekecek, ancak diğer şeyleri yaparken birçok sınıfı bağlayacak ve işiniz bittiğinde bir rapor hazırlayacaktır.
Yüklenen uygulamaların bundle identifier'ını belirlemek için frida-ps -Uai
komutunu kullanın:
Uygulamanın bileşenlerini listelemeyi ve objection ile yöntemleri ve sınıfları kolayca hook etmeyi öğrenin:
iOS Hooking With ObjectionBir IPA dosyasının yapısı esasen bir ziplenmiş paket yapısıdır. Uzantısını .zip
olarak yeniden adlandırarak, içeriğini açabilirsiniz. Bu yapı içinde, bir Bundle, kurulum için hazır tamamen paketlenmiş bir uygulamayı temsil eder. İçinde, uygulamanın kaynaklarını kapsayan <NAME>.app
adında bir dizin bulacaksınız.
Info.plist
: Bu dosya, uygulamanın belirli yapılandırma ayrıntılarını tutar.
_CodeSignature/
: Bu dizin, bundle içindeki tüm dosyaların bütünlüğünü sağlamak için bir imza içeren bir plist dosyası içerir.
Assets.car
: İkonlar gibi varlık dosyalarını depolayan sıkıştırılmış bir arşivdir.
Frameworks/
: Bu klasör, .dylib
veya .framework
dosyaları şeklinde olabilen uygulamanın yerel kütüphanelerini barındırır.
PlugIns/
: Bu, uygulamaya eklemeler içerebilir, bunlar .appex
dosyaları olarak bilinir, ancak her zaman mevcut olmayabilir. * Core Data
: Uygulamanızın kalıcı verilerini çevrimdışı kullanım için kaydetmek, geçici verileri önbelleğe almak ve uygulamanıza tek bir cihazda geri alma işlevselliği eklemek için kullanılır. Bir iCloud hesabında birden fazla cihaz arasında veri senkronize etmek için, Core Data otomatik olarak şemanızı bir CloudKit konteynerine yansıtır.
PkgInfo
: PkgInfo
dosyası, uygulamanızın veya bundle'ınızın türünü ve yaratıcısını belirtmenin alternatif bir yoludur.
en.lproj, fr.proj, Base.lproj: Bu, belirli diller için kaynakları içeren dil paketleridir ve bir dil desteklenmediğinde varsayılan bir kaynak içerir.
Güvenlik: _CodeSignature/
dizini, dijital imzalar aracılığıyla tüm paketlenmiş dosyaların bütünlüğünü doğrulayarak uygulamanın güvenliğinde kritik bir rol oynar.
Varlık Yönetimi: Assets.car
dosyası, grafik varlıkları verimli bir şekilde yönetmek için sıkıştırma kullanır, bu da uygulama performansını optimize etmek ve genel boyutunu azaltmak için önemlidir.
Frameworks ve PlugIns: Bu dizinler, iOS uygulamalarının modülerliğini vurgular, geliştiricilerin yeniden kullanılabilir kod kütüphanelerini (Frameworks/
) dahil etmelerine ve uygulama işlevselliğini genişletmelerine olanak tanır.
Yerelleştirme: Yapı, belirli dil paketleri için kaynaklar ekleyerek küresel uygulama erişimini kolaylaştıran birden fazla dili destekler.
Info.plist
Info.plist, iOS uygulamaları için bir köşe taşı olarak hizmet eder ve anahtar-değer çiftleri şeklinde ana yapılandırma verilerini kapsar. Bu dosya, yalnızca uygulamalar için değil, aynı zamanda içinde paketlenmiş uygulama uzantıları ve frameworkler için de gereklidir. XML veya ikili formatta yapılandırılmıştır ve uygulama izinlerinden güvenlik yapılandırmalarına kadar kritik bilgileri tutar. Mevcut anahtarların detaylı bir keşfi için Apple Developer Documentation adresine başvurabilirsiniz.
Bu dosya ile daha erişilebilir bir formatta çalışmak isteyenler için, XML dönüşümü macOS'ta (10.2 ve sonraki sürümlerde yerel olarak mevcut) plutil
kullanılarak veya Linux'ta plistutil
ile zahmetsizce gerçekleştirilebilir. Dönüşüm için komutlar aşağıdaki gibidir:
macOS için:
Linux için:
Info.plist dosyasının ifşa edebileceği çok sayıda bilgi arasında, dikkat çekici girdiler uygulama izin dizeleri (UsageDescription
), özel URL şemaları (CFBundleURLTypes
) ve Uygulama Taşıma Güvenliği için yapılandırmalar (NSAppTransportSecurity
) bulunmaktadır. Bu girdiler, dışa aktarılan/içe aktarılan özel belge türleri (UTExportedTypeDeclarations
/ UTImportedTypeDeclarations
) gibi diğerleriyle birlikte, dosyayı inceleyerek veya basit bir grep
komutu kullanarak kolayca bulunabilir:
Veri Yolları
iOS ortamında, dizinler sistem uygulamaları ve kullanıcı tarafından yüklenen uygulamalar için özel olarak belirlenmiştir. Sistem uygulamaları /Applications
dizininde bulunurken, kullanıcı tarafından yüklenen uygulamalar /var/mobile/containers/Data/Application/
altında yer alır. Bu uygulamalar, dizin adlarının rastgeleliği nedeniyle bir uygulamanın klasörünü manuel olarak bulmayı zorlaştıran 128-bit UUID olarak bilinen benzersiz bir tanımlayıcıya sahiptir.
iOS'taki uygulamalar sandbox'lanmış olması gerektiğinden, her uygulamanın $HOME/Library/Containers
içinde uygulamanın CFBundleIdentifier
olarak adlandırılan bir klasörü de olacaktır.
Ancak, her iki klasör (veri ve konteyner klasörleri) .com.apple.mobile_container_manager.metadata.plist
dosyasını içerir ve bu dosya, MCMetadataIdentifier
anahtarında her iki dosyayı bağlar.
Kullanıcı tarafından yüklenen bir uygulamanın kurulum dizinini keşfetmeyi kolaylaştırmak için, objection aracı faydalı bir komut sağlar, env
. Bu komut, söz konusu uygulama için ayrıntılı dizin bilgilerini ortaya çıkarır. Aşağıda bu komutun nasıl kullanılacağına dair bir örnek bulunmaktadır:
Alternatif olarak, uygulama adı /private/var/containers
içinde find
komutunu kullanarak aranabilir:
ps
ve lsof
gibi komutlar, uygulamanın işlemini tanımlamak ve sırasıyla açık dosyaları listelemek için de kullanılabilir, bu da uygulamanın aktif dizin yolları hakkında bilgiler sağlar:
Bundle dizini:
AppName.app
Bu, IPA'da daha önce görülen Uygulama Paketi olup, temel uygulama verilerini, statik içeriği ve uygulamanın derlenmiş ikili dosyasını içerir.
Bu dizin kullanıcılara görünür, ancak kullanıcılar buna yazamaz.
Bu dizindeki içerik yedeklenmez.
Bu klasörün içeriği kod imzasını doğrulamak için kullanılır.
Veri dizini:
Documents/
Kullanıcı tarafından oluşturulan tüm verileri içerir. Uygulama son kullanıcısı bu verilerin oluşturulmasını başlatır.
Kullanıcılara görünür ve kullanıcılar buna yazabilir.
Bu dizindeki içerik yedeklenir.
Uygulama, NSURLIsExcludedFromBackupKey
ayarını kullanarak yolları devre dışı bırakabilir.
Library/
Kullanıcıya özel olmayan tüm dosyaları içerir, örneğin önbellekler, tercihler, çerezler ve özellik listesi (plist) yapılandırma dosyaları.
iOS uygulamaları genellikle Application Support
ve Caches
alt dizinlerini kullanır, ancak uygulama özel alt dizinler oluşturabilir.
Library/Caches/
Yarı kalıcı önbellek dosyalarını içerir.
Kullanıcılara görünmez ve kullanıcılar buna yazamaz.
Bu dizindeki içerik yedeklenmez.
OS, uygulama çalışmadığında ve depolama alanı azaldığında bu dizinin dosyalarını otomatik olarak silebilir.
Library/Application Support/
Uygulamanın çalışması için gerekli kalıcı dosyaları içerir.
Kullanıcılara görünmez ve kullanıcılar buna yazamaz.
Bu dizindeki içerik yedeklenir.
Uygulama, NSURLIsExcludedFromBackupKey
ayarını kullanarak yolları devre dışı bırakabilir.
Library/Preferences/
Uygulama yeniden başlatılsa bile kalıcı olabilen özellikleri saklamak için kullanılır.
Bilgiler, şifrelenmemiş olarak, uygulama kumanda alanında [BUNDLE_ID].plist adlı bir plist dosyasında saklanır.
NSUserDefaults
kullanılarak saklanan tüm anahtar/değer çiftleri bu dosyada bulunabilir.
tmp/
Uygulama başlatmaları arasında kalıcı olması gerekmeyen geçici dosyalar yazmak için bu dizini kullanın.
Kalıcı olmayan önbellek dosyalarını içerir.
Kullanıcılara görünmez.
Bu dizindeki içerik yedeklenmez.
OS, uygulama çalışmadığında ve depolama alanı azaldığında bu dizinin dosyalarını otomatik olarak silebilir.
Bundle dizinindeki iGoat-Swift'in Uygulama Paketi (.app) dizinine daha yakından bakalım (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
):
<application-name>.app
klasörünün içinde <application-name>
adında bir ikili dosya bulacaksınız. Bu, çalıştırılacak dosyadır. İkili dosyanın temel bir incelemesini otool
aracıyla gerçekleştirebilirsiniz:
Uygulamanın şifrelenip şifrelenmediğini kontrol et
Aşağıdaki için herhangi bir çıktı olup olmadığını kontrol edin:
İkiliyi Ayrıştırma
Metin bölümünü ayrıştırın:
Örnek uygulamanın Objective-C segmentini yazdırmak için şunları kullanabilirsiniz:
Daha kompakt bir Objective-C kodu elde etmek için class-dump kullanabilirsiniz:
Ancak, ikili dosyayı parçalamak için en iyi seçenekler: Hopper ve IDA.
Trickest kullanarak dünyanın en gelişmiş topluluk araçlarıyla desteklenen iş akışlarını kolayca oluşturun ve otomatikleştirin. Bugün Erişim Alın:
iOS'un cihazda verileri nasıl depoladığını öğrenmek için bu sayfayı okuyun:
iOS BasicsBilgileri depolamak için aşağıdaki yerler uygulama yüklendikten hemen sonra, uygulamanın tüm işlevleri kontrol edildikten sonra ve hatta bir kullanıcıdan çıkış yapıldıktan ve farklı bir kullanıcıya giriş yapıldıktan sonra kontrol edilmelidir. Amaç, uygulamanın (şifreler, token'lar) mevcut kullanıcısının ve daha önce giriş yapmış kullanıcıların korumasız hassas bilgilerini bulmaktır.
plist dosyaları, anahtar-değer çiftlerini içeren yapılandırılmış XML dosyalarıdır. Kalıcı verileri depolamanın bir yoludur, bu nedenle bazen bu dosyalarda hassas bilgiler bulabilirsiniz. Uygulamayı yükledikten sonra ve yoğun bir şekilde kullandıktan sonra bu dosyaları kontrol etmeniz önerilir.
plist dosyalarında verileri kalıcı hale getirmenin en yaygın yolu NSUserDefaults kullanmaktır. Bu plist dosyası, uygulama kumandasının içinde Library/Preferences/<appBundleID>.plist
konumunda kaydedilir.
NSUserDefaults
sınıfı, varsayılan sistemle etkileşim kurmak için programatik bir arayüz sağlar. Varsayılan sistem, bir uygulamanın kullanıcı tercihleri doğrultusunda davranışını özelleştirmesine olanak tanır. NSUserDefaults
ile kaydedilen veriler uygulama paketinde görüntülenebilir. Bu sınıf, plist dosyasında veri depolar, ancak küçük miktarda veri ile kullanılmak üzere tasarlanmıştır.
Bu verilere artık güvenilir bir bilgisayar aracılığıyla doğrudan erişilemez, ancak bir yedekleme yaparak erişilebilir.
NSUserDefaults
kullanarak kaydedilen bilgileri dump edebilirsiniz; objection'ın ios nsuserdefaults get
komutunu kullanarak.
Uygulama tarafından kullanılan tüm plist dosyalarını bulmak için /private/var/mobile/Containers/Data/Application/{APPID}
konumuna erişebilir ve şunu çalıştırabilirsiniz:
XML veya ikili (bplist) formatındaki dosyaları XML'e dönüştürmek için, işletim sisteminize bağlı olarak çeşitli yöntemler mevcuttur:
macOS Kullanıcıları için: plutil
komutunu kullanın. Bu, macOS'ta (10.2+) bu amaç için tasarlanmış yerleşik bir araçtır:
Linux Kullanıcıları için: Öncelikle libplist-utils
'ı kurun, ardından dosyanızı dönüştürmek için plistutil
kullanın:
Objection Oturumu İçinde: Mobil uygulamaları analiz etmek için, plist dosyalarını doğrudan dönüştürmenizi sağlayan özel bir komut vardır:
Core Data
uygulamanızdaki nesnelerin model katmanını yönetmek için bir çerçevedir. Core Data, kalıcı depolama olarak SQLite kullanabilir, ancak çerçeve kendisi bir veritabanı değildir.
CoreData varsayılan olarak verilerini şifrelemez. Ancak, CoreData'ya ek bir şifreleme katmanı eklenebilir. Daha fazla ayrıntı için GitHub Repo sayfasına bakın.
Bir uygulamanın SQLite Core Data bilgilerini /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support
yolunda bulabilirsiniz.
Eğer SQLite'ı açabiliyor ve hassas bilgilere erişebiliyorsanız, o zaman bir yanlış yapılandırma buldunuz.
YapDatabase SQLite üzerine inşa edilmiş bir anahtar/değer deposudur. Yap veritabanları sqlite veritabanları olduğundan, önceki bölümde önerilen komutu kullanarak bunları bulabilirsiniz.
Uygulamaların kendi sqlite veritabanlarını oluşturması yaygındır. Bu veritabanlarında duyarlı veri saklıyor olabilirler ve bunu şifrelemeden bırakabilirler. Bu nedenle, uygulama dizinindeki her veritabanını kontrol etmek her zaman ilginçtir. Bu nedenle, verilerin kaydedildiği uygulama dizinine gidin (/private/var/mobile/Containers/Data/Application/{APPID}
)
Geliştiriciler, Firebase Gerçek Zamanlı Veritabanları aracılığıyla veri depolayıp senkronize etme yeteneğine sahiptir. JSON formatında depolanan veriler, gerçek zamanlı olarak tüm bağlı istemcilere senkronize edilir.
Yanlış yapılandırılmış Firebase veritabanlarını nasıl kontrol edeceğinizi burada bulabilirsiniz:
Firebase DatabaseRealm Objective-C ve Realm Swift Apple tarafından sağlanmayan güçlü bir veri depolama alternatifi sunar. Varsayılan olarak, verileri şifrelenmemiş olarak depolar, belirli bir yapılandırma ile şifreleme mevcuttur.
Veritabanları şu konumda bulunmaktadır: /private/var/mobile/Containers/Data/Application/{APPID}
. Bu dosyaları keşfetmek için şu gibi komutlar kullanılabilir:
Bu veritabanı dosyalarını görüntülemek için Realm Studio aracının kullanılması önerilir.
Bir Realm veritabanında şifreleme uygulamak için aşağıdaki kod parçası kullanılabilir:
Couchbase Lite, hafif ve gömülü bir veritabanı motoru olarak tanımlanır ve belge odaklı (NoSQL) yaklaşımı takip eder. iOS ve macOS için yerel olacak şekilde tasarlanmıştır ve verileri sorunsuz bir şekilde senkronize etme yeteneği sunar.
Bir cihazda potansiyel Couchbase veritabanlarını belirlemek için aşağıdaki dizin incelenmelidir:
iOS, uygulamaların çerezlerini her uygulama klasöründeki Library/Cookies/cookies.binarycookies
içinde saklar. Ancak, geliştiriciler bazen bunları anahtar zincirinde saklamayı tercih ederler çünkü belirtilen çerez dosyası yedeklerde erişilebilir.
Çerez dosyasını incelemek için bu python betiğini kullanabilir veya objection'ın ios cookies get
komutunu kullanabilirsiniz.
Bu dosyaları JSON formatına dönüştürmek ve verileri incelemek için objection'ı da kullanabilirsiniz.
Varsayılan olarak NSURLSession, HTTP istekleri ve yanıtları Cache.db veritabanında depolar. Bu veritabanı, eğer tokenlar, kullanıcı adları veya başka herhangi bir hassas bilgi önbelleğe alınmışsa hassas veriler içerebilir. Önbelleğe alınmış bilgileri bulmak için uygulamanın veri dizinini açın (/var/mobile/Containers/Data/Application/<UUID>
) ve /Library/Caches/<Bundle Identifier>
dizinine gidin. WebKit önbelleği de Cache.db dosyasında saklanmaktadır. Objection, sqlite connect Cache.db
komutuyla veritabanını açabilir ve etkileşimde bulunabilir, çünkü bu normal bir SQLite veritabanıdır.
Bu verilerin önbelleğe alınmasını devre dışı bırakmanız önerilir, çünkü istek veya yanıtta hassas bilgiler içerebilir. Aşağıdaki liste, bunu başarmanın farklı yollarını göstermektedir:
Çıkış yaptıktan sonra Önbelleğe alınmış yanıtların kaldırılması önerilir. Bu, Apple tarafından sağlanan removeAllCachedResponses
yöntemi ile yapılabilir. Bu yöntemi aşağıdaki gibi çağırabilirsiniz:
URLCache.shared.removeAllCachedResponses()
Bu yöntem, Cache.db dosyasından tüm önbelleğe alınmış istekleri ve yanıtları kaldıracaktır. 2. Çerezlerin avantajını kullanmanıza gerek yoksa, URLSession'ın .ephemeral yapılandırma özelliğini kullanmanız önerilir; bu, çerezlerin ve önbelleklerin kaydedilmesini devre dışı bırakır.
Geçici bir oturum yapılandırma nesnesi, varsayılan bir oturum yapılandırmasına (bkz. varsayılan) benzer, ancak ilgili oturum nesnesi önbellekleri, kimlik bilgisi depolarını veya herhangi bir oturumla ilgili veriyi diske kaydetmez. Bunun yerine, oturumla ilgili veriler RAM'de saklanır. Geçici bir oturumun diske veri yazdığı tek zaman, bir URL'nin içeriğini bir dosyaya yazmasını söylediğiniz zamandır.
3. Önbellek, Önbellek Politikasını .notAllowed olarak ayarlayarak da devre dışı bırakılabilir. Bu, önbelleği herhangi bir şekilde, ister bellek ister disk üzerinde saklamayı devre dışı bırakır.
Ana düğmeye her bastığınızda, iOS mevcut ekranın bir anlık görüntüsünü alır böylece uygulamaya geçiş çok daha akıcı bir şekilde yapılabilir. Ancak, eğer mevcut ekranda hassas veri varsa, bu görüntüde kaydedilecektir (bu yeniden başlatmalarda sürekli olarak kalır). Bunlar, uygulamalar arasında geçiş yapmak için ana ekranı çift tıklayarak erişebileceğiniz anlık görüntülerdir.
iPhone jailbreak edilmedikçe, saldırganın bu ekran görüntülerini görebilmesi için cihaza erişimi açık olması gerekir. Varsayılan olarak, son anlık görüntü uygulamanın sandbox'ında Library/Caches/Snapshots/
veya Library/SplashBoard/Snapshots
klasöründe saklanır (güvenilir bilgisayarlar iOS 7.0'dan itibaren dosya sistemine erişemez).
Bu kötü davranışı önlemenin bir yolu, ApplicationDidEnterBackground()
fonksiyonunu kullanarak anlık görüntü almadan önce boş bir ekran koymak veya hassas verileri kaldırmaktır.
Aşağıda, varsayılan bir ekran görüntüsü ayarlayacak örnek bir düzeltme yöntemi bulunmaktadır.
Swift:
Objective-C:
Bu, uygulama arka plana alındığında arka plan resmini overlayImage.png
olarak ayarlar. overlayImage.png
mevcut görünümü her zaman geçersiz kılacağı için hassas veri sızıntılarını önler.
iOS anahtar zincirine erişim ve yönetim için, jailbreak yapılmış cihazlar için uygun olan Keychain-Dumper gibi araçlar mevcuttur. Ayrıca, benzer amaçlar için Objection ios keychain dump
komutunu sağlar.
NSURLCredential sınıfı, NSUserDefaults veya diğer sarmalayıcıları atlayarak hassas bilgileri doğrudan anahtar zincirinde saklamak için idealdir. Giriş yaptıktan sonra kimlik bilgilerini saklamak için aşağıdaki Swift kodu kullanılır:
Bu saklanan kimlik bilgilerini çıkarmak için, Objection'ın ios nsurlcredentialstorage dump
komutu kullanılır.
iOS 8.0 ve sonrasında, kullanıcılar Ayarlar > Genel > Klavye > Klavyeler altında yönetilebilen özel klavye uzantıları yükleyebilir. Bu klavyeler genişletilmiş işlevsellik sunarken, tuş vuruşlarını kaydetme ve verileri harici sunuculara iletme riski taşır; ancak kullanıcılar, ağ erişimi gerektiren klavyeler hakkında bilgilendirilir. Uygulamalar, hassas bilgi girişi için özel klavyelerin kullanımını kısıtlayabilir ve kısıtlamalıdır.
Güvenlik Önerileri:
Gelişmiş güvenlik için üçüncü taraf klavyelerin devre dışı bırakılması önerilir.
Varsayılan iOS klavyesinin otomatik düzeltme ve otomatik öneri özelliklerinin, Library/Keyboard/{locale}-dynamic-text.dat
veya /private/var/mobile/Library/Keyboard/dynamic-text.dat
konumundaki önbellek dosyalarında hassas bilgileri saklayabileceğini unutmayın. Bu önbellek dosyaları, hassas veriler için düzenli olarak kontrol edilmelidir. Önbelleğe alınmış verileri temizlemek için Ayarlar > Genel > Sıfırla > Klavye Sözlüğünü Sıfırla yoluyla klavye sözlüğünün sıfırlanması önerilir.
Ağ trafiğini yakalamak, özel bir klavyenin tuş vuruşlarını uzaktan iletip iletmediğini ortaya çıkarabilir.
UITextInputTraits protokolü, hassas bilgi önbelleklemesini önlemek için otomatik düzeltme ve güvenli metin girişi yönetimi için gerekli özellikler sunar. Örneğin, otomatik düzeltmeyi devre dışı bırakmak ve güvenli metin girişini etkinleştirmek şu şekilde gerçekleştirilebilir:
Ayrıca, geliştiricilerin metin alanlarının, özellikle şifreler ve PIN'ler gibi hassas bilgilerin girilmesi için olanların, autocorrectionType
'ı UITextAutocorrectionTypeNo
ve secureTextEntry
'yi YES
olarak ayarlayarak önbelleği devre dışı bıraktıklarından emin olmaları gerekir.
Hata ayıklama kodu genellikle logging kullanımını içerir. Logların hassas bilgileri içerebileceği bir risk vardır. Daha önce, iOS 6 ve önceki sürümlerde, loglar tüm uygulamalar tarafından erişilebilir durumdaydı ve bu da hassas veri sızıntısı riski oluşturuyordu. Artık, uygulamalar yalnızca kendi loglarına erişimle sınırlıdır.
Bu kısıtlamalara rağmen, açık bir cihaza fiziksel erişimi olan bir saldırgan, cihazı bir bilgisayara bağlayarak ve logları okuyarak bunu istismar edebilir. Logların, uygulamanın kaldırılmasından sonra bile diskte kalmaya devam ettiğini belirtmek önemlidir.
Riskleri azaltmak için, uygulama ile kapsamlı bir şekilde etkileşimde bulunulması ve hassas bilgilerin yanlışlıkla kaydedilmediğinden emin olmak için tüm işlevselliklerin ve girdilerin keşfedilmesi önerilir.
Uygulamanın kaynak kodunu potansiyel sızıntılar için incelerken, NSLog
, NSAssert
, NSCAssert
, fprintf
gibi anahtar kelimeleri kullanarak hem önceden tanımlı hem de özel logging ifadeleri arayın ve özel uygulamalar için Logging
veya Logfile
ifadelerine dikkat edin.
Uygulamalar, hassas olabilecek çeşitli bilgileri kaydeder. Bu logları izlemek için, şu araçlar ve komutlar gibi:
yararlıdır. Ayrıca, Xcode konsol günlüklerini toplamak için bir yol sağlar:
Xcode'u açın.
iOS cihazını bağlayın.
Window -> Devices and Simulators'a gidin.
Cihazınızı seçin.
İncelemek istediğiniz sorunu tetikleyin.
Günlükleri yeni bir pencerede görüntülemek için Open Console butonunu kullanın.
Daha gelişmiş günlükleme için, cihaz kabuğuna bağlanmak ve socat kullanmak gerçek zamanlı günlük izleme sağlayabilir:
Log aktivitelerini gözlemlemek için komutlar, sorunları teşhis etmek veya loglarda potansiyel veri sızıntılarını tanımlamak için çok değerli olabilir.
Dünyanın en gelişmiş topluluk araçlarıyla desteklenen iş akışlarını kolayca oluşturmak ve otomatikleştirmek için Trickest kullanın. Bugün Erişim Alın:
Otomatik yedekleme özellikleri, iOS'a entegre edilmiştir ve iTunes (macOS Catalina'ya kadar), Finder (macOS Catalina'dan itibaren) veya iCloud aracılığıyla cihaz veri kopyalarının oluşturulmasını kolaylaştırır. Bu yedeklemeler, Apple Pay detayları ve Touch ID yapılandırmaları gibi son derece hassas unsurlar hariç, neredeyse tüm cihaz verilerini kapsar.
Yedeklemelerdeki kurulu uygulamalar ve verileri dahil edilmesi, potansiyel veri sızıntısı ve yedekleme değişikliklerinin uygulama işlevselliğini değiştirme riski sorununu gündeme getirir. Bu riskleri azaltmak için, herhangi bir uygulamanın dizininde veya alt dizinlerinde hassas bilgilerin düz metin olarak saklanmaması önerilir.
Documents/
ve Library/Application Support/
içindeki dosyalar varsayılan olarak yedeklenir. Geliştiriciler, NSURL setResourceValue:forKey:error:
ile NSURLIsExcludedFromBackupKey
kullanarak belirli dosyaları veya dizinleri yedeklemelerden hariç tutabilir. Bu uygulama, hassas verilerin yedeklemelere dahil edilmesini korumak için kritik öneme sahiptir.
Bir uygulamanın yedekleme güvenliğini değerlendirmek için, önce Finder kullanarak bir yedekleme oluşturun, ardından Apple'ın resmi belgeleri rehberliğinde yedeği bulun. Uygulama davranışını etkileyebilecek hassas veriler veya yapılandırmalar için yedeği analiz edin.
Hassas bilgiler, komut satırı araçları veya iMazing gibi uygulamalar kullanılarak aranabilir. Şifreli yedeklemeler için, şifrelemenin varlığı, yedeklemenin kökündeki "Manifest.plist" dosyasındaki "IsEncrypted" anahtarı kontrol edilerek doğrulanabilir.
Şifreli yedeklerle başa çıkmak için, DinoSec'in GitHub deposunda bulunan Python betikleri, backup_tool.py ve backup_passwd.py gibi, faydalı olabilir, ancak en son iTunes/Finder sürümleriyle uyumlu hale getirmek için ayarlamalar gerektirebilir. iOSbackup aracı ise şifre korumalı yedekler içindeki dosyalara erişim için başka bir seçenektir.
Yedekleme değişiklikleri yoluyla uygulama davranışını değiştirme örneği, Bither bitcoin cüzdan uygulamasında gösterilmektedir; burada UI kilit PIN'i pin_code anahtarı altında net.bither.plist
içinde saklanmaktadır. Bu anahtarı plist'ten kaldırmak ve yedeği geri yüklemek, PIN gereksinimini ortadan kaldırarak sınırsız erişim sağlar.
Bir uygulamanın belleğinde saklanan hassas bilgilerle ilgilenirken, bu verilerin maruz kalma süresini sınırlamak çok önemlidir. Bellek içeriğini araştırmak için iki ana yaklaşım vardır: bir bellek dökümü oluşturmak ve belleği gerçek zamanlı olarak analiz etmek. Her iki yöntemin de, döküm süreci veya analiz sırasında kritik verileri kaçırma potansiyeli gibi zorlukları vardır.
Hem jailbreak yapılmış hem de yapılmamış cihazlar için, objection ve Fridump gibi araçlar, bir uygulamanın işlem belleğini dökme imkanı sunar. Döküm alındıktan sonra, bu verileri analiz etmek, aradığınız bilginin doğasına bağlı olarak çeşitli araçlar gerektirir.
Bir bellek dökümünden dizeleri çıkarmak için strings
veya rabin2 -zz
gibi komutlar kullanılabilir:
Daha ayrıntılı analiz için, belirli veri türlerini veya desenlerini arama dahil, radare2 geniş arama yetenekleri sunar:
r2frida, bir uygulamanın belleğini gerçek zamanlı olarak incelemek için güçlü bir alternatif sunar, bellek dökümüne ihtiyaç duymadan. Bu araç, çalışan uygulamanın belleğinde doğrudan arama komutlarının yürütülmesini sağlar:
Bazı geliştiriciler hassas verileri yerel depolamada saklar ve bunu kodda hardcoded/tahmin edilebilir bir anahtar ile şifreler. Bu yapılmamalıdır çünkü bazı tersine mühendislik işlemleri, saldırganların gizli bilgileri çıkarmasına olanak tanıyabilir.
Geliştiriciler, yetkilendirme kontrolleri yapmak, veri saklamak veya göndermek için kullanımdan kaldırılmış algoritmalar kullanmamalıdır. Bu algoritmalardan bazıları: RC4, MD4, MD5, SHA1... Örneğin, şifreleri saklamak için hash kullanılıyorsa, tuz ile birlikte brute-force dayanıklı hash'ler kullanılmalıdır.
Kodda hardcoded şifreler/gizli bilgiler bulup bulamayacağınızı, bunların tahmin edilebilir olup olmadığını ve kodun bazı tür zayıf kriptografi algoritmaları kullanıp kullanmadığını kontrol etmek için ana kontrolleri gerçekleştirin.
Bazı kriptografi kütüphanelerini otomatik olarak objection ile izleyebileceğinizi bilmek ilginçtir:
For daha fazla bilgi için iOS kriptografik API'leri ve kütüphaneleri hakkında https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography adresini ziyaret edin.
Yerel kimlik doğrulama, özellikle uzaktan bir uç noktada kriptografik yöntemlerle erişimi korumak söz konusu olduğunda kritik bir rol oynar. Buradaki öz, uygun bir uygulama olmadan yerel kimlik doğrulama mekanizmalarının aşılabileceğidir.
Apple'ın Yerel Kimlik Doğrulama çerçevesi ve anahtar zinciri, geliştiricilerin kullanıcı kimlik doğrulama diyaloglarını kolaylaştırmaları ve gizli verileri güvenli bir şekilde yönetmeleri için sağlam API'ler sunar. Secure Enclave, Touch ID için parmak izi kimliğini güvence altına alırken, Face ID biyometrik verileri tehlikeye atmadan yüz tanımaya dayanır.
Touch ID/Face ID'yi entegre etmek için geliştiricilerin iki API seçeneği vardır:
LocalAuthentication.framework
biyometrik verilere erişim olmadan yüksek seviyeli kullanıcı kimlik doğrulaması için.
Security.framework
biyometrik kimlik doğrulaması ile gizli verileri güvence altına alarak daha düşük seviyeli anahtar zinciri hizmetlerine erişim için. Çeşitli açık kaynaklı sarmalayıcılar anahtar zinciri erişimini daha basit hale getirir.
Ancak, hem LocalAuthentication.framework
hem de Security.framework
zafiyetler sunar, çünkü esasen kimlik doğrulama süreçleri için veri iletmeden boolean değerleri döndürürler, bu da onları aşılabilir hale getirir (bkz. Bana öyle dokunma, David Lindner ve diğerleri).
Kullanıcılardan kimlik doğrulama istemek için geliştiricilerin LAContext
sınıfındaki evaluatePolicy
yöntemini kullanmaları gerekir ve şu seçeneklerden birini seçmelidirler:
deviceOwnerAuthentication
: Touch ID veya cihaz şifresi için istemde bulunur, ikisi de etkin değilse başarısız olur.
deviceOwnerAuthenticationWithBiometrics
: Sadece Touch ID için istemde bulunur.
Başarılı bir kimlik doğrulama, evaluatePolicy
yönteminden dönen boolean bir değerle gösterilir ve bu potansiyel bir güvenlik açığını vurgular.
iOS uygulamalarında yerel kimlik doğrulama uygulamak, kimlik doğrulama token'ları gibi gizli verileri güvenli bir şekilde depolamak için anahtar zinciri API'lerini kullanmayı içerir. Bu süreç, verilerin yalnızca kullanıcının cihaz şifresi veya Touch ID gibi biyometrik kimlik doğrulama ile erişilebileceğini garanti eder.
Anahtar zinciri, SecAccessControl
niteliği ile öğeleri ayarlama yeteneği sunar; bu, kullanıcı Touch ID veya cihaz şifresi ile başarılı bir şekilde kimlik doğrulama yapana kadar öğeye erişimi kısıtlar. Bu özellik, güvenliği artırmak için kritik öneme sahiptir.
Aşağıda, bu güvenlik özelliklerini kullanarak anahtar zincirine bir dize kaydetme ve alma yöntemlerini gösteren Swift ve Objective-C'de kod örnekleri bulunmaktadır. Örnekler, Touch ID kimlik doğrulamasını gerektirecek şekilde erişim kontrolünü nasıl ayarlayacağınızı ve verilerin yalnızca ayarlandığı cihazda erişilebilir olmasını sağlamak için bir cihaz şifresinin yapılandırılması koşulunu göstermektedir.
Artık anahtarlıkta kaydedilen öğeyi talep edebiliriz. Anahtarlık hizmetleri, kullanıcıya kimlik doğrulama penceresini gösterecek ve uygun bir parmak izi sağlanıp sağlanmadığına bağlı olarak veriyi veya nil'i döndürecektir.
Bir uygulamadaki frameworklerin kullanımı, uygulama ikilisinin paylaşılan dinamik kütüphaneler listesinin analiz edilmesiyle de tespit edilebilir. Bu, otool
kullanılarak yapılabilir:
Eğer bir uygulamada LocalAuthentication.framework
kullanılıyorsa, çıktı aşağıdaki iki satırı da içerecektir (unutmayın ki LocalAuthentication.framework
arka planda Security.framework
kullanır):
Eğer Security.framework
kullanılıyorsa, yalnızca ikincisi gösterilecektir.
Objection Biometrics Bypass aracılığıyla, bu GitHub sayfasında bulunan bir teknik, LocalAuthentication mekanizmasını aşmak için mevcuttur. Bu yaklaşımın temeli, evaluatePolicy
fonksiyonunu manipüle etmek için Frida kullanmaktır; bu sayede, gerçek kimlik doğrulama başarısından bağımsız olarak sürekli olarak True
sonucu elde edilir. Bu, hatalı biyometrik kimlik doğrulama süreçlerini aşmak için özellikle faydalıdır.
Bu atlatmayı etkinleştirmek için aşağıdaki komut kullanılır:
Bu komut, Objection'ın evaluatePolicy
kontrolünün sonucunu True
olarak etkili bir şekilde değiştiren bir görevi kaydettiği bir dizi başlatır.
evaluatePolicy
kullanımına bir örnek DVIA-v2 uygulamasından:
Yerel Kimlik Doğrulama'nın bypass edilmesi için bir Frida scripti yazılmıştır. Bu script, evaluatePolicy kontrolünü hedef alır ve geri çağrısını keserek success=1 döndürmesini sağlar. Geri çağrının davranışını değiştirerek, kimlik doğrulama kontrolü etkili bir şekilde bypass edilir.
Aşağıdaki script, evaluatePolicy yönteminin sonucunu değiştirmek için enjekte edilir. Geri çağrının sonucunu her zaman başarıyı gösterecek şekilde değiştirir.
Frida betiğini enjekte etmek ve biyometrik kimlik doğrulamayı atlatmak için aşağıdaki komut kullanılır:
Şifreleme olmadan iletişim gerçekleşmediğinden emin olmak ve ayrıca uygulamanın sunucunun TLS sertifikasını doğru bir şekilde doğruladığından emin olmak önemlidir. Bu tür sorunları kontrol etmek için Burp gibi bir proxy kullanabilirsiniz:
iOS Burp Suite ConfigurationTLS sertifikasını doğrularken yaygın bir sorun, sertifikanın güvenilir bir CA tarafından imzalandığını kontrol etmektir, ancak sertifikanın hostname'inin erişilen hostname olup olmadığını kontrol etmemektir. Bu sorunu Burp kullanarak kontrol etmek için, iPhone'da Burp CA'ya güven verdikten sonra, farklı bir hostname için Burp ile yeni bir sertifika oluşturabilir ve bunu kullanabilirsiniz. Uygulama hala çalışıyorsa, o zaman bir şey savunmasızdır.
Bir uygulama SSL Pinleme kullanıyorsa, uygulama yalnızca beklenen sertifika ile çalışır. Bir uygulamayı test ederken bu, Burp kendi sertifikasını sunacağı için bir sorun olabilir. Jailbroken bir cihazda bu korumayı aşmak için SSL Kill Switch uygulamasını yükleyebilir veya Burp Mobile Assistant yükleyebilirsiniz.
Ayrıca objection'ın ios sslpinning disable
komutunu da kullanabilirsiniz.
/System/Library
içinde sistem uygulamaları tarafından kullanılan telefonun kurulu framework'lerini bulabilirsiniz.
Kullanıcı tarafından App Store'dan kurulan uygulamalar /User/Applications
içinde yer alır.
/User/Library
ise kullanıcı seviyesindeki uygulamalar tarafından kaydedilen verileri içerir.
Uygulama içinde kaydedilen notları okumak için /User/Library/Notes/notes.sqlite
dosyasına erişebilirsiniz.
Kurulu bir uygulamanın klasörü içinde (/User/Applications/<APP ID>/
) bazı ilginç dosyalar bulabilirsiniz:
iTunesArtwork
: Uygulama tarafından kullanılan simge
iTunesMetadata.plist
: App Store'da kullanılan uygulama bilgileri
/Library/*
: Tercihleri ve önbelleği içerir. /Library/Cache/Snapshots/*
içinde uygulamaya arka planda gönderilmeden önce yapılan anlık görüntüyü bulabilirsiniz.
Geliştiriciler, uygulamalarının tüm kurulumlarını anında yamanlayabilir ve uygulamayı App Store'a yeniden göndermeye gerek kalmadan onay bekleyebilirler. Bu amaçla genellikle JSPatch** kullanılır.** Ancak Siren ve react-native-appstore-version-checker gibi diğer seçenekler de vardır. Bu, kötü niyetli üçüncü taraf SDK'lar tarafından kötüye kullanılabilecek tehlikeli bir mekanizmadır, bu nedenle otomatik güncelleme için hangi yöntemin kullanıldığını kontrol etmek (varsa) ve test etmek önerilir. Bu amaçla uygulamanın önceki bir sürümünü indirmeyi deneyebilirsiniz.
3. taraf SDK'lar ile ilgili önemli bir zorluk, işlevleri üzerinde ayrıntılı kontrol eksikliğidir. Geliştiriciler, SDK'yı entegre etme ve potansiyel güvenlik açıkları ve gizlilik endişeleri dahil olmak üzere tüm özelliklerini kabul etme veya tamamen faydalarından vazgeçme seçeneği ile karşı karşıyadır. Genellikle, geliştiriciler bu SDK'lar içindeki güvenlik açıklarını kendileri yamalayamazlar. Ayrıca, SDK'lar topluluk içinde güven kazandıkça, bazıları kötü amaçlı yazılım içermeye başlayabilir.
Üçüncü taraf SDK'lar tarafından sağlanan hizmetler, kullanıcı davranışını izleme, reklam gösterimleri veya kullanıcı deneyimi iyileştirmeleri içerebilir. Ancak, bu, geliştiricilerin bu kütüphaneler tarafından yürütülen kodu tam olarak bilmemesi nedeniyle potansiyel gizlilik ve güvenlik riskleri oluşturur. Üçüncü taraf hizmetlerle paylaşılan bilgilerin yalnızca gerekli olanlarla sınırlı olması ve hassas verilerin açığa çıkmadığından emin olunması önemlidir.
Üçüncü taraf hizmetlerin uygulanması genellikle iki biçimde gelir: bağımsız bir kütüphane veya tam bir SDK. Kullanıcı gizliliğini korumak için, bu hizmetlerle paylaşılan verilerin anonimleştirilmesi gerekmektedir, böylece Kişisel Tanımlanabilir Bilgilerin (PII) ifşası önlenir.
Bir uygulamanın kullandığı kütüphaneleri belirlemek için otool
komutu kullanılabilir. Bu araç, uygulama ve kullandığı her paylaşılan kütüphane üzerinde çalıştırılmalıdır.
OWASP iGoat https://github.com/OWASP/igoat <<< Objective-C versiyonu https://github.com/OWASP/iGoat-Swift <<< Swift versiyonu
Dünyanın en gelişmiş topluluk araçlarıyla desteklenen iş akışlarını kolayca oluşturmak ve otomatikleştirmek için Trickest kullanın. Bugün Erişim Alın:
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)