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 birkaç 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 metotları ve sınıfları kolayca hook'lamayı öğ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 bir şekilde paketlenmiş uygulamayı temsil eder. İçinde, uygulamanın kaynaklarını kapsayan <NAME>.app
adlı 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/
: Uygulamaya uzantılar 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ızda tek bir cihazda geri alma işlevselliği eklemek için kullanılır. Bir iCloud hesabındaki birden fazla cihaz arasında veri senkronizasyonu sağlamak 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 framework'ler 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 dosyayla daha erişilebilir bir formatta çalışmak isteyenler için, XML dönüşümü macOS'ta plutil
kullanılarak kolayca gerçekleştirilebilir (10.2 ve sonraki sürümlerde yerel olarak mevcuttur) veya Linux'ta plistutil
ile yapılabilir. Dönüşüm için komutlar şu şekildedir:
macOS için:
Linux için:
Info.plist dosyasının ortaya çıkarabileceğ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ı 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.
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, tokenlar), mevcut kullanıcı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 kullanımıdı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ına erişmek için /private/var/mobile/Containers/Data/Application/{APPID}
konumuna gidebilir 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
yükleyin, 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.
SQLite'yi açıp 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, her zaman uygulama dizinindeki her veritabanını kontrol etmek 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 veri depolama için güçlü bir alternatif 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 olarak tasarlanmış olup, 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ü içindeki Library/Cookies/cookies.binarycookies
dosyasında 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ı, tokenlar, kullanıcı adları veya başka herhangi bir hassas bilgi önbelleğe alındıysa 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 depolanmaktadı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 depolanı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 depolamayı 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 ve uygulamaya geçişi çok daha akıcı bir şekilde yapabilmek için. Ancak, eğer hassas veri mevcut ekranın içindeyse, bu görüntüde kaydedilir (bu yeniden başlatmalarda sürdürülü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 olmalıdır. Varsayılan olarak, son anlık görüntü uygulamanın sandbox'ında Library/Caches/Snapshots/
veya Library/SplashBoard/Snapshots
klasöründe depolanır (güvenilir bilgisayarlar iOX 7.0'dan itibaren dosya sistemine erişemez).
Bu kötü davranışı önlemenin bir yolu, anlık görüntü alınmadan önce boş bir ekran koymak veya hassas verileri kaldırmaktır; bunu ApplicationDidEnterBackground()
fonksiyonunu kullanarak yapabilirsiniz.
Aşağıda, varsayılan bir ekran görüntüsü ayarlayacak bir örnek 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ı, hassas bilgileri doğrudan anahtar zincirinde saklamak için idealdir ve NSUserDefaults veya diğer sarmalayıcıları atlamayı sağlar. 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. Önbellek verilerini 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 ö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 uygulamalara 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 tüm işlevselliklerin ve girdilerin keşfedilmesi önerilir, böylece hassas bilgilerin yanlışlıkla kaydedilmediğinden emin olunabilir.
Olası sızıntılar için uygulamanın kaynak kodunu incelerken, NSLog
, NSAssert
, NSCAssert
, fprintf
gibi anahtar kelimeleri kullanarak hem önceden tanımlı hem de özel logging ifadelerini arayın ve özel uygulamalar için Logging
veya Logfile
ifadelerine dikkat edin.
Uygulamalar çeşitli hassas olabilecek 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.
İncelemekte olduğunuz 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ı belirlemek 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 verilerinin kopyalarını oluşturmayı 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 yedek 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 bilgilere, komut satırı araçları veya iMazing gibi uygulamalar kullanarak ulaşılabilir. Şifreli yedeklemeler için, şifrelemenin varlığı, yedeğin 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 kilidi PIN'i net.bither.plist
içinde pin_code anahtarı altında 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 koruma 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 bö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, kullanıcı başarılı bir şekilde Touch ID veya cihaz şifresi ile kimlik doğrulaması yapana kadar öğeye erişimi kısıtlayan SecAccessControl
niteliği ile öğeleri ayarlama yeteneği sunar. Bu özellik, güvenliği artırmak için kritik öneme sahiptir.
Aşağıda, bu güvenlik özelliklerini kullanarak anahtar zincirine bir dizeyi nasıl kaydedip alacağınızı gösteren Swift ve Objective-C'de kod örnekleri bulunmaktadır. Örnekler, erişim kontrolünü ayarlamanın nasıl yapılacağını, Touch ID kimlik doğrulaması gerektirecek şekilde ve verilerin yalnızca ayarlandığı cihazda erişilebilir olmasını sağlamak için cihaz şifresinin yapılandırılması koşuluyla 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 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 Biyometrik Atlatma 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 atlatmak için özellikle yararlı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ğrulamasını 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 imzalanıp imzalanmadığını kontrol etmektir, ancak sertifikanın host adı ile erişilen host adının kontrol edilmemesidir. Bu sorunu Burp kullanarak kontrol etmek için, iPhone'da Burp CA'ya güven verdikten sonra, farklı bir host adı için Burp ile yeni bir sertifika oluşturabilir ve bunu kullanabilirsiniz. Uygulama hala çalışıyorsa, bir şeyin zayıf noktası vardı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. Jailbreak yapılmış 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 çerçevelerini bulabilirsiniz.
Kullanıcı tarafından App Store'dan kurulan uygulamalar /User/Applications
içinde yer alır.
/User/Library
kullanıcı düzeyindeki 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 plana 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 yönteminin (varsa) hangi yöntemle kullanıldığını kontrol etmek 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, fonksiyonları ü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 zayıf noktaları 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 kodun tam olarak farkında olmaması nedeniyle potansiyel gizlilik ve güvenlik riskleri oluşturur. Üçüncü taraf hizmetlerle paylaşılan bilgilerin, gerekli olanla 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, böylece ek kütüphaneler keşfedilebilir.
OWASP iGoat https://github.com/OWASP/igoat <<< Objective-C versiyonu https://github.com/OWASP/iGoat-Swift <<< Swift versiyonu
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:
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)