Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo budować i **automatyzować przepływy pracy** z wykorzystaniem najbardziej zaawansowanych narzędzi społecznościowych na świecie.\
<summary><strong>Zacznij od zera i zostań ekspertem od hakowania AWS z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) na GitHubie.
Podczas testowania **zostaną zaproponowane kilka operacji** (połączenie z urządzeniem, odczyt/zapis/przesyłanie/pobieranie plików, korzystanie z niektórych narzędzi...). Dlatego jeśli nie wiesz, jak wykonać którekolwiek z tych działań, **zacznij od przeczytania strony**:
***PIE (Position Independent Executable)**: Gdy jest włączony, aplikacja ładuje się pod losowy adres pamięci za każdym razem, gdy jest uruchamiana, co utrudnia przewidywanie jej początkowego adresu pamięci.
***Canaries stosu**: Do sprawdzenia integralności stosu, wartość „canary” jest umieszczana na stosie przed wywołaniem funkcji i ponownie sprawdzana po zakończeniu funkcji.
Sprawdź analizę dynamiczną, którą wykonuje [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF). Będziesz musiał poruszać się po różnych widokach i wchodzić w interakcje z nimi, ale narzędzie to będzie podłączać się do kilku klas, wykonywać inne czynności i przygotuje raport po zakończeniu.
Struktura pliku **IPA** jest w zasadzie strukturą **spakowanego pakietu**. Zmieniając jego rozszerzenie na `.zip`, można go **rozpakować**, aby ujawnić jego zawartość. W tej strukturze **Bundle** reprezentuje w pełni spakowaną aplikację gotową do instalacji. Wewnątrz znajdziesz katalog o nazwie `<NAME>.app`, który zawiera zasoby aplikacji.
* [**`Core Data`**](https://developer.apple.com/documentation/coredata): Służy do zapisywania trwałych danych aplikacji do użytku offline, do buforowania danych tymczasowych i dodawania funkcji cofania w aplikacji na jednym urządzeniu. Aby zsynchronizować dane między wieloma urządzeniami w jednym koncie iCloud, Core Data automatycznie odbija schemat w kontenerze CloudKit.
* [**`PkgInfo`**](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html): Plik `PkgInfo` to alternatywny sposób określenia kodów typu i twórcy twojej aplikacji lub pakietu.
* **en.lproj, fr.proj, Base.lproj**: Są to pakiety językowe zawierające zasoby dla tych konkretnych języków oraz domyślny zasób w przypadku braku obsługi danego języka.
* **Bezpieczeństwo**: Katalog `_CodeSignature/` odgrywa kluczową rolę w bezpieczeństwie aplikacji, weryfikując integralność wszystkich spakowanych plików za pomocą podpisów cyfrowych.
* **Zarządzanie zasobami**: Plik `Assets.car` wykorzystuje kompresję do efektywnego zarządzania zasobami graficznymi, co jest kluczowe dla optymalizacji wydajności aplikacji i zmniejszenia jej całkowitego rozmiaru.
* **Frameworks i PlugIns**: Te katalogi podkreślają modularność aplikacji iOS, pozwalając programistom na dołączanie bibliotek kodu do ponownego użycia (`Frameworks/`) i rozszerzanie funkcjonalności aplikacji (`PlugIns/`).
* **Lokalizacja**: Struktura wspiera wiele języków, ułatwiając globalne dotarcie aplikacji poprzez dołączenie zasobów dla konkretnych pakietów językowych.
**Info.plist** pełni rolę kamienia węgielnego dla aplikacji iOS, zawierając kluczowe dane konfiguracyjne w postaci par **klucz-wartość**. Ten plik jest niezbędny nie tylko dla aplikacji, ale także dla rozszerzeń aplikacji i frameworków dołączonych w pakiecie. Jest on strukturalnie zapisany w formacie XML lub binarnym i zawiera istotne informacje od uprawnień aplikacji po konfiguracje zabezpieczeń. Aby uzyskać szczegółowe informacje na temat dostępnych kluczy, można odnieść się do [**Dokumentacji deweloperskiej Apple**](https://developer.apple.com/documentation/bundleresources/information\_property\_list?language=objc).
Dla osób chcących pracować z tym plikiem w bardziej dostępnym formacie, konwersję XML można łatwo osiągnąć za pomocą `plutil` na macOS (dostępny domyślnie w wersjach 10.2 i nowszych) lub `plistutil` na Linuxie. Polecenia konwersji wyglądają następująco:
Wśród licznych informacji, które plik **Info.plist** może ujawnić, godne uwagi wpisy obejmują ciągi uprawnień aplikacji (`UsageDescription`), niestandardowe schematy URL (`CFBundleURLTypes`) oraz konfiguracje dotyczące bezpieczeństwa transportu aplikacji (`NSAppTransportSecurity`). Te wpisy, wraz z innymi, takimi jak eksportowane/importowane niestandardowe typy dokumentów (`UTExportedTypeDeclarations` / `UTImportedTypeDeclarations`), można łatwo zlokalizować, sprawdzając plik lub korzystając z prostego polecenia `grep`:
W środowisku iOS katalogi są przeznaczone specjalnie dla **aplikacji systemowych** i **aplikacji zainstalowanych przez użytkownika**. Aplikacje systemowe znajdują się w katalogu `/Applications`, podczas gdy aplikacje zainstalowane przez użytkownika są umieszczone w `/private/var/containers/`. Te aplikacje są przypisane unikalny identyfikator znany jako **128-bitowy UUID**, co sprawia, że ręczne zlokalizowanie folderu aplikacji jest trudne ze względu na losowość nazw katalogów.
Aby ułatwić odkrywanie katalogu instalacyjnego aplikacji zainstalowanej przez użytkownika, narzędzie **objection** udostępnia przydatne polecenie `env`. To polecenie ujawnia szczegółowe informacje o katalogu dla danej aplikacji. Poniżej znajduje się przykład użycia tego polecenia:
Polecenia takie jak `ps` i `lsof` mogą również być wykorzystane do zidentyfikowania procesu aplikacji i wylistowania otwartych plików, odpowiednio, dostarczając wglądu w ścieżki aktywnego katalogu aplikacji:
* To jest Pakiet Aplikacji, jak widziano wcześniej w IPA, zawiera podstawowe dane aplikacji, treści statyczne oraz skompilowany plik binarny aplikacji.
* Ten katalog jest widoczny dla użytkowników, ale **użytkownicy nie mogą w nim pisać**.
* Zawiera wszystkie **pliki, które nie są specyficzne dla użytkownika**, takie jak **pamięć podręczna**, **preferencje**, **ciasteczka** oraz pliki konfiguracyjne listy właściwości (plist).
Przyjrzyjmy się bliżej katalogowi Pakietu Aplikacji (.app) iGoat-Swift znajdującemu się w katalogu Bundle (`/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app`):
Wewnątrz folderu `<application-name>.app` znajdziesz plik binarny o nazwie `<application-name>`. To jest plik, który zostanie **wykonany**. Możesz przeprowadzić podstawową inspekcję binarną za pomocą narzędzia **`otool`**:
Jednak najlepsze opcje do rozkładania binarnego to: [**Hopper**](https://www.hopperapp.com/download.html?) i [**IDA**](https://www.hex-rays.com/products/ida/support/download_freeware/).
Użyj [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) do łatwego tworzenia i **automatyzowania prac** z wykorzystaniem najbardziej zaawansowanych narzędzi społecznościowych na świecie.\
Następujące miejsca przechowywania informacji powinny być sprawdzone **zaraz po zainstalowaniu aplikacji**, **po sprawdzeniu wszystkich funkcji** aplikacji, a nawet po **wylogowaniu się z jednego użytkownika i zalogowaniu się na innego**.\
Celem jest znalezienie **niezabezpieczonych wrażliwych informacji** aplikacji (hasła, tokeny), bieżącego użytkownika oraz wcześniej zalogowanych użytkowników.
Pliki **plist** to strukturalne pliki XML zawierające pary klucz-wartość. Jest to sposób przechowywania danych trwałych, dlatego czasami można w nich znaleźć **wrażliwe informacje**. Zaleca się sprawdzenie tych plików po zainstalowaniu aplikacji i po intensywnym jej używaniu, aby zobaczyć, czy zapisano nowe dane.
Najczęstszym sposobem przechowywania danych w plikach plist jest korzystanie z **NSUserDefaults**. Ten plik plist jest zapisywany wewnątrz piaskownicy aplikacji w **`Library/Preferences/<appBundleID>.plist`**
Klasa [`NSUserDefaults`](https://developer.apple.com/documentation/foundation/nsuserdefaults) zapewnia interfejs programistyczny do interakcji z systemem domyślnym. System domyślny pozwala aplikacji dostosować swoje zachowanie zgodnie z **preferencjami użytkownika**. Dane zapisane przez `NSUserDefaults` można zobaczyć w pakiecie aplikacji. Ta klasa przechowuje **dane** w pliku **plist**, ale jest przeznaczona do użytku z małymi ilościami danych.
Aby znaleźć wszystkie pliki plist używane przez aplikację, możesz uzyskać dostęp do `/private/var/mobile/Containers/Data/Application/{APPID}` i uruchomić:
[`Core Data`](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/nsfetchedresultscontroller.html#//apple\_ref/doc/uid/TP40001075-CH8-SW1) to framework do zarządzania warstwą modelu obiektów w Twojej aplikacji. [Core Data może używać SQLite jako swojego trwałego magazynu](https://cocoacasts.com/what-is-the-difference-between-core-data-and-sqlite/), ale sam framework nie jest bazą danych.\
CoreData nie szyfruje swoich danych domyślnie. Jednak dodatkowa warstwa szyfrowania może zostać dodana do CoreData. Zobacz [Repozytorium na GitHubie](https://github.com/project-imas/encrypted-core-data) po więcej szczegółów.
Informacje o bazie danych SQLite Core Data aplikacji znajdziesz w ścieżce `/private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support`
Jest powszechne, że aplikacje tworzą swoje własne bazy danych sqlite. Mogą one **przechowywać****wrażliwe****dane** i pozostawiać je niezaszyfrowane. Dlatego zawsze warto sprawdzić każdą bazę danych w katalogu aplikacji. Przejdź do katalogu aplikacji, gdzie dane są zapisywane (`/private/var/mobile/Containers/Data/Application/{APPID}`).
Deweloperzy mają możliwość **przechowywania i synchronizacji danych** w **bazie danych hostowanej w chmurze NoSQL** za pośrednictwem Firebase Real-Time Databases. Dane przechowywane są w formacie JSON, a dane są synchronizowane z wszystkimi podłączonymi klientami w czasie rzeczywistym.
[Realm Objective-C](https://realm.io/docs/objc/latest/) i [Realm Swift](https://realm.io/docs/swift/latest/) oferują potężną alternatywę dla przechowywania danych, niedostępną w ofercie Apple. Domyślnie **przechowują dane w formie niezaszyfrowanej**, z możliwością szyfrowania poprzez określoną konfigurację.
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios) jest opisany jako **lekki** i **wbudowany** silnik baz danych, który stosuje podejście **zorientowane na dokumenty** (NoSQL). Zaprojektowany tak, aby był natywny dla systemów **iOS** i **macOS**, oferuje możliwość synchronizacji danych w sposób bezproblemowy.
iOS przechowuje ciasteczka aplikacji w **`Library/Cookies/cookies.binarycookies`** wewnątrz folderu każdej aplikacji. Jednak deweloperzy czasami decydują się je zapisać w **keychainie**, ponieważ wspomniany **plik cookie może być dostępny w kopii zapasowej**.
Aby przejrzeć plik ciasteczek, można skorzystać z [**tego skryptu w języku Python**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) lub użyć polecenia **`ios cookies get`** z narzędzia objection.\
**Można również użyć narzędzia objection do** konwersji tych plików na format JSON i przejrzenia danych.
Domyślnie NSURLSession przechowuje dane, takie jak **żądania i odpowiedzi HTTP w bazie danych Cache.db**. Ta baza danych może zawierać **dane wrażliwe**, jeśli tokeny, nazwy użytkowników lub jakiekolwiek inne informacje wrażliwe zostały zapisane w pamięci podręcznej. Aby znaleźć zapisane informacje, otwórz katalog danych aplikacji (`/var/mobile/Containers/Data/Application/<UUID>`) i przejdź do `/Library/Caches/<Bundle Identifier>`. **Pamięć podręczna WebKit jest również przechowywana w pliku Cache.db**. **Objection** może otworzyć i interakcjonować z bazą danych za pomocą polecenia `sqlite connect Cache.db`, ponieważ jest to **zwykła baza danych SQLite**.
**Zaleca się wyłączenie przechowywania tych danych w pamięci podręcznej**, ponieważ może zawierać informacje wrażliwe w żądaniu lub odpowiedzi. Poniżej przedstawiono różne sposoby osiągnięcia tego:
1. Zaleca się usunięcie zapisanych odpowiedzi po wylogowaniu. Można to zrobić za pomocą udostępnionej metody Apple o nazwie [`removeAllCachedResponses`](https://developer.apple.com/documentation/foundation/urlcache/1417802-removeallcachedresponses). Można wywołać tę metodę w następujący sposób:
2. Jeśli nie potrzebujesz korzystać z plików cookie, zaleca się po prostu użycie właściwości konfiguracji [.ephemeral](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral) URLSession, która wyłączy zapisywanie plików cookie i pamięci podręcznej.
`Obiekt konfiguracji sesji efemerycznej jest podobny do domyślnej konfiguracji sesji (patrz domyślna), z tym wyjątkiem, że odpowiadający obiekt sesji nie przechowuje pamięci podręcznej, magazynów poświadczeń ani żadnych danych związanych z sesją na dysku. Zamiast tego dane związane z sesją są przechowywane w pamięci RAM. Jedynym momentem, kiedy sesja efemeryczna zapisuje dane na dysku, jest wtedy, gdy mówisz jej, aby zapisała zawartość adresu URL do pliku.`
3. Pamięć podręczna może być również wyłączona poprzez ustawienie polityki pamięci podręcznej na [.notAllowed](https://developer.apple.com/documentation/foundation/urlcache/storagepolicy/notallowed). Wyłączy to przechowywanie pamięci podręcznej w dowolny sposób, zarówno w pamięci, jak i na dysku.
Za każdym razem, gdy naciśniesz przycisk domowy, iOS **robi zrzut ekranu** bieżącego ekranu, aby umożliwić płynne przejście do aplikacji. Jednakże, jeśli **dane wrażliwe** znajdują się na bieżącym ekranie, zostaną **zapisane** w **obrazie** (który **utrzymuje się****po****ponownym****uruchomieniu**). Są to zrzuty ekranu, do których można również uzyskać dostęp, podwójnie klikając ekran główny, aby przełączać się między aplikacjami.
Chyba że iPhone jest złamany, **atakujący** musi mieć **dostęp** do **odblokowanego****urządzenia**, aby zobaczyć te zrzuty ekranu. Domyślnie ostatni zrzut ekranu jest przechowywany w piaskownicy aplikacji w folderze `Library/Caches/Snapshots/` lub `Library/SplashBoard/Snapshots` (zaufane komputery nie mogą uzyskać dostępu do systemu plików od wersji iOS 7.0).
Jednym ze sposobów zapobieżenia temu złemu zachowaniu jest umieszczenie pustego ekranu lub usunięcie danych wrażliwych przed zrobieniem zrzutu ekranu za pomocą funkcji `ApplicationDidEnterBackground()`.
To ustawia obraz tła na `overlayImage.png` za każdym razem, gdy aplikacja jest w tle. Zapobiega to wyciekom wrażliwych danych, ponieważ `overlayImage.png` zawsze będzie nadpisywać bieżący widok.
Do dostępu i zarządzania keychainem iOS dostępne są narzędzia takie jak [**Keychain-Dumper**](https://github.com/ptoomey3/Keychain-Dumper), odpowiednie dla urządzeń z jailbreakiem. Dodatkowo [**Objection**](https://github.com/sensepost/objection) udostępnia polecenie `ios keychain dump` do podobnych celów.
Klasa **NSURLCredential** jest idealna do przechowywania wrażliwych informacji bezpośrednio w keychainie, omijając konieczność korzystania z NSUserDefaults lub innych opakowań. Aby przechowywać poświadczenia po zalogowaniu, używany jest następujący kod w języku Swift:
Od wersji iOS 8.0 użytkownicy mogą instalować rozszerzenia niestandardowych klawiatur, które są zarządzane w **Ustawienia > Ogólne > Klawiatura > Klawiatury**. Chociaż te klawiatury oferują rozszerzoną funkcjonalność, stanowią ryzyko rejestrowania naciśnięć klawiszy i przesyłania danych do zewnętrznych serwerów, chociaż użytkownicy są informowani o klawiaturach wymagających dostępu do sieci. Aplikacje mogą i powinny ograniczać korzystanie z niestandardowych klawiatur do wprowadzania informacji poufnych.
* Zaleca się wyłączenie klawiatur stron trzecich dla zwiększonego bezpieczeństwa.
* Należy uważać na funkcje autokorekty i automatycznych sugestii domyślnej klawiatury iOS, które mogą przechowywać poufne informacje w plikach pamięci podręcznej znajdujących się w `Library/Keyboard/{locale}-dynamic-text.dat` lub `/private/var/mobile/Library/Keyboard/dynamic-text.dat`. Te pliki pamięci podręcznej powinny być regularnie sprawdzane pod kątem poufnych danych. Zaleca się resetowanie słownika klawiatury za pomocą **Ustawienia > Ogólne > Resetuj > Resetuj słownik klawiatury** w celu wyczyszczenia danych pamięci podręcznej.
Protokół [UITextInputTraits](https://developer.apple.com/reference/uikit/uitextinputtraits) oferuje właściwości do zarządzania autokorektą i wprowadzaniem tekstu zabezpieczonego, co jest istotne dla zapobiegania buforowaniu poufnych informacji. Na przykład wyłączenie autokorekty i włączenie wprowadzania tekstu zabezpieczonego można osiągnąć za pomocą:
Dodatkowo, programiści powinni upewnić się, że pola tekstowe, zwłaszcza te służące do wprowadzania wrażliwych informacji, takich jak hasła i PIN-y, wyłączają buforowanie, ustawiając `autocorrectionType` na `UITextAutocorrectionTypeNo` oraz `secureTextEntry` na `YES`.
Debugowanie kodu często wymaga użycia **logowania**. Istnieje ryzyko, ponieważ **dzienniki mogą zawierać informacje poufne**. Wcześniej, w iOS 6 i wcześniejszych wersjach, dzienniki były dostępne dla wszystkich aplikacji, co stanowiło ryzyko wycieku poufnych danych. **Obecnie aplikacje mają ograniczony dostęp tylko do swoich dzienników**.
Mimo tych ograniczeń, **atakujący mający fizyczny dostęp** do odblokowanego urządzenia nadal może to wykorzystać, podłączając urządzenie do komputera i **czytając dzienniki**. Warto zauważyć, że dzienniki pozostają na dysku nawet po odinstalowaniu aplikacji.
Aby zmniejszyć ryzyko, zaleca się **dokładne interakcje z aplikacją**, eksplorując wszystkie jej funkcjonalności i dane wejściowe, aby upewnić się, że nie są niechcący rejestrowane żadne poufne informacje.
Podczas przeglądania kodu źródłowego aplikacji w poszukiwaniu potencjalnych wycieków, szukaj zarówno **predefiniowanych** jak i **niestandardowych instrukcji logowania** za pomocą słów kluczowych takich jak `NSLog`, `NSAssert`, `NSCAssert`, `fprintf` dla wbudowanych funkcji oraz wszelkich wzmianek o `Logging` lub `Logfile` dla niestandardowych implementacji.
Następnie wykonaj polecenia, aby obserwować aktywności dziennika, które mogą być nieocenione przy diagnozowaniu problemów lub identyfikowaniu potencjalnych wycieków danych w dziennikach.
Korzystaj z [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) do łatwego tworzenia i **automatyzacji prac** z wykorzystaniem najbardziej zaawansowanych narzędzi społecznościowych na świecie.\
Funkcje **automatycznych kopii zapasowych** są zintegrowane w system iOS, ułatwiając tworzenie kopii danych urządzenia za pomocą iTunes (do macOS Catalina), Finder (od macOS Catalina) lub iCloud. Te kopie zapasowe obejmują prawie wszystkie dane urządzenia, z wyjątkiem bardzo wrażliwych elementów, takich jak szczegóły Apple Pay i konfiguracje Touch ID.
Włączenie **zainstalowanych aplikacji i ich danych** do kopii zapasowych stwarza ryzyko potencjalnego **wycieku danych** i ryzyko, że **modyfikacje kopii zapasowych mogą zmienić funkcjonalność aplikacji**. Zaleca się **nie przechowywać wrażliwych informacji w postaci tekstowej** w katalogu żadnej aplikacji ani jej podkatalogach, aby zminimalizować te ryzyka.
Pliki w `Documents/` i `Library/Application Support/` są domyślnie kopiowane. Programiści mogą wykluczyć określone pliki lub katalogi z kopii zapasowych, używając `NSURL setResourceValue:forKey:error:` z `NSURLIsExcludedFromBackupKey`. Ta praktyka jest kluczowa dla ochrony wrażliwych danych przed uwzględnieniem ich w kopii zapasowej.
Aby ocenić bezpieczeństwo kopii zapasowej aplikacji, zacznij od **utworzenia kopii zapasowej** za pomocą Finder, a następnie zlokalizuj ją, korzystając z instrukcji z [oficjalnej dokumentacji Apple'a](https://support.apple.com/en-us/HT204215). Analizuj kopię zapasową pod kątem wrażliwych danych lub konfiguracji, które mogą zostać zmienione, aby wpłynąć na zachowanie aplikacji.
Informacje wrażliwe można wyszukać za pomocą narzędzi wiersza poleceń lub aplikacji takich jak [iMazing](https://imazing.com). Dla zaszyfrowanych kopii zapasowych obecność szyfrowania można potwierdzić, sprawdzając klucz "IsEncrypted" w pliku "Manifest.plist" w głównym katalogu kopii zapasowej.
Do radzenia sobie z zaszyfrowanymi kopiami zapasowymi, skrypty Python dostępne w [repozytorium GitHub DinoSec](https://github.com/dinosec/iphone-dataprotection/tree/master/python\_scripts), takie jak **backup\_tool.py** i **backup\_passwd.py**, mogą być przydatne, chociaż mogą wymagać dostosowania do najnowszych wersji iTunes/Finder. Narzędzie [**iOSbackup**](https://pypi.org/project/iOSbackup/) to kolejna opcja pozwalająca uzyskać dostęp do plików w zabezpieczonych hasłem kopii zapasowych.
Przykład zmiany zachowania aplikacji poprzez modyfikacje kopii zapasowej jest pokazany w aplikacji portfela bitcoin [Bither](https://github.com/bither/bither-ios), gdzie PIN blokady interfejsu użytkownika jest przechowywany w `net.bither.plist` pod kluczem **pin\_code**. Usunięcie tego klucza z pliku plist i przywrócenie kopii zapasowej usuwa wymaganie PIN, zapewniając niograniczony dostęp.
Podczas pracy z wrażliwymi informacjami przechowywanymi w pamięci aplikacji, istotne jest ograniczenie czasu ekspozycji tych danych. Istnieją dwie podstawowe metody badania zawartości pamięci: **tworzenie zrzutu pamięci** i **analiza pamięci w czasie rzeczywistym**. Obie metody mają swoje wyzwania, w tym potencjalne pominięcie istotnych danych podczas procesu zrzutu lub analizy.
Zarówno dla urządzeń z jailbreakiem, jak i bez jailbreaka, narzędzia takie jak [objection](https://github.com/sensepost/objection) i [Fridump](https://github.com/Nightbringer21/fridump) pozwalają na zrzucanie pamięci procesu aplikacji. Po zrzuceniu, analiza tych danych wymaga różnych narzędzi, w zależności od charakteru poszukiwanych informacji.
**r2frida** zapewnia potężną alternatywę do inspekcji pamięci aplikacji w czasie rzeczywistym, bez konieczności tworzenia zrzutu pamięci. Narzędzie to umożliwia wykonywanie poleceń wyszukiwania bezpośrednio w pamięci działającej aplikacji:
Niektórzy programiści zapisują wrażliwe dane w lokalnym magazynie i szyfrują je kluczem zapisanym/wykonalnym w kodzie. Nie powinno się tego robić, ponieważ odwrócenie procesu może umożliwić atakującym wydobycie poufnych informacji.
Programiści nie powinni używać **przestarzałych algorytmów** do przeprowadzania **sprawdzeń** autoryzacji, **przechowywania** lub **wysyłania** danych. Niektóre z tych algorytmów to: RC4, MD4, MD5, SHA1... Jeśli **hashe** są używane do przechowywania haseł na przykład, należy używać hashy odporne na ataki brutalnej siły wraz z solą.
Główne sprawdzenia do przeprowadzenia to znalezienie **hardcoded** haseł/tajemnic w kodzie, lub czy są one **przewidywalne**, oraz czy kod używa jakiegoś rodzaju **słabych** algorytmów **kryptograficznych**.
Dla **więcej informacji** na temat interfejsów API i bibliotek kryptograficznych iOS odwiedź [https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography](https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography)
**Lokalna autoryzacja** odgrywa kluczową rolę, zwłaszcza jeśli chodzi o zabezpieczenie dostępu do zdalnego punktu końcowego za pomocą metod kryptograficznych. Istotą tutaj jest to, że bez właściwej implementacji mechanizmy lokalnej autoryzacji mogą zostać obejścia.
[**Framework Lokalnej Autoryzacji Apple**](https://developer.apple.com/documentation/localauthentication) oraz [**keychain**](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html) dostarczają deweloperom solidne interfejsy API do ułatwienia dialogów autoryzacyjnych użytkownika i bezpiecznego zarządzania tajnymi danymi. Enklawa bezpieczeństwa zabezpiecza identyfikator odcisku palca dla Touch ID, podczas gdy Face ID opiera się na rozpoznawaniu twarzy bez naruszania danych biometrycznych.
* **`Security.framework`** dla dostępu do usług schowka na niższym poziomie, zabezpieczając tajne dane za pomocą autoryzacji biometrycznej. Różne [opakowania open-source](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id) ułatwiają dostęp do schowka.
Jednak zarówno `LocalAuthentication.framework`, jak i `Security.framework` posiadają podatności, ponieważ głównie zwracają wartości logiczne bez przesyłania danych do procesów autoryzacyjnych, co czyni je podatnymi na obejście (patrz [Don't touch me that way, autorstwa Davida Lindnera i in.](https://www.youtube.com/watch?v=XhXIHVGCFFM)).
Implementacja **lokalnej autoryzacji** w aplikacjach iOS polega na wykorzystaniu **API schowka** do bezpiecznego przechowywania tajnych danych, takich jak tokeny autoryzacyjne. Ten proces zapewnia, że dane mogą być dostępne tylko przez użytkownika, korzystając z kodu dostępu do urządzenia lub autoryzacji biometrycznej, takiej jak Touch ID.
Schowek oferuje możliwość ustawienia elementów z atrybutem `SecAccessControl`, który ogranicza dostęp do elementu do momentu pomyślnej autoryzacji użytkownika za pomocą Touch ID lub kodu dostępu do urządzenia. Ta funkcja jest kluczowa dla zwiększenia bezpieczeństwa.
Poniżej znajdują się przykłady kodu w języku Swift i Objective-C, demonstrujące jak zapisać i odzyskać ciąg znaków do/z schowka, wykorzystując te funkcje zabezpieczeń. Przykłady pokazują specyficznie, jak skonfigurować kontrolę dostępu, aby wymagała autoryzacji Touch ID i zapewnić, że dane są dostępne tylko na urządzeniu, na którym zostały skonfigurowane, pod warunkiem, że kod dostępu do urządzenia jest skonfigurowany.
Aby rozpocząć testowanie penetracyjne aplikacji iOS, potrzebujesz skonfigurować środowisko, które umożliwi Ci analizę aplikacji pod kątem luk w zabezpieczeniach. Możesz skorzystać z narzędzi takich jak **Xcode** do analizy kodu aplikacji oraz **Cycript** do dynamicznej analizy działania aplikacji w czasie rzeczywistym.
Przeprowadzając testy penetracyjne aplikacji iOS, warto przeanalizować kod aplikacji w poszukiwaniu potencjalnych luk w zabezpieczeniach. Możesz skorzystać z narzędzi do dekompilacji kodu, takich jak **Hopper** lub **IDA Pro**, aby zrozumieć, jak działa aplikacja i gdzie mogą występować potencjalne zagrożenia.
Podczas testów penetracyjnych aplikacji iOS, nie zapomnij o testowaniu bezpieczeństwa sieciowego. Możesz użyć narzędzi do przechwytywania ruchu sieciowego, takich jak **Burp Suite** lub **Charles Proxy**, aby monitorować i analizować komunikację między aplikacją a serwerem.
#### Testowanie Bezpieczeństwa Danych
Kolejnym istotnym aspektem testów penetracyjnych aplikacji iOS jest testowanie bezpieczeństwa danych przechowywanych przez aplikację. Możesz skorzystać z narzędzi do analizy plików aplikacji, takich jak **iExplorer** lub **iFunBox**, aby zidentyfikować potencjalne wycieki danych lub słabe zabezpieczenia.
#### Podsumowanie
Pentestowanie aplikacji iOS wymaga zrozumienia zarówno technicznych aspektów testowania penetracyjnego, jak i specyficznych mechanizmów zabezpieczeń stosowanych w systemie iOS. Korzystając z odpowiednich narzędzi i metodologii, możesz skutecznie zidentyfikować i zabezpieczyć aplikacje przed potencjalnymi atakami.
Teraz możemy poprosić o zapisany element z Keychain. Usługi Keychain wyświetlą okno dialogowe uwierzytelniania użytkownika i zwrócą dane lub nil, w zależności od tego, czy został podany odpowiedni odcisk palca czy nie.
```swift
// 1. define query
var query = [String: Any]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecReturnData as String] = kCFBooleanTrue
query[kSecAttrAccount as String] = "My Name" as CFString
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecUseOperationPrompt as String] = "Please, pass authorisation to enter this area" as CFString
Testowanie penetracyjne aplikacji iOS polega na identyfikowaniu i wykorzystywaniu luk w zabezpieczeniach aplikacji iOS w celu zwiększenia bezpieczeństwa.
Metodologia testowania penetracyjnego iOS obejmuje analizę statyczną i dynamiczną aplikacji, testowanie bezpieczeństwa sieciowego, testowanie bezpieczeństwa danych, testowanie bezpieczeństwa sesji, itp.
Wykorzystanie frameworków w aplikacji można również wykryć, analizując listę współdzielonych bibliotek dynamicznych aplikacji. Można to zrobić, korzystając z `otool`:
Jeśli w aplikacji jest używany `LocalAuthentication.framework`, wynik będzie zawierał obie z poniższych linii (pamiętaj, że `LocalAuthentication.framework` korzysta z `Security.framework` pod spodem):
Poprzez **Ominięcie Biometryczne Objection**, dostępne na [tej stronie GitHub](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass), dostępna jest technika ominięcia mechanizmu **LocalAuthentication**. Istotą tego podejścia jest wykorzystanie **Frida** do manipulowania funkcją `evaluatePolicy`, zapewniając, że zawsze zwraca ona wynik `True`, niezależnie od faktycznego sukcesu uwierzytelnienia. Jest to szczególnie przydatne do obejścia wadliwych procesów uwierzytelniania biometrycznego.
[TouchIDAuthentication showAlert:@"Your device doesn't support Touch ID or you haven't configured Touch ID authentication on your device" withTitle:@"Error"];
Aby osiągnąć **ominięcie** Lokalnej Autentykacji, napisany jest skrypt Fridy. Skrypt ten jest skierowany na sprawdzenie **evaluatePolicy**, przechwytując jego wywołanie zwrotne, aby upewnić się, że zwraca **success=1**. Poprzez zmianę zachowania wywołania zwrotnego, sprawdzenie autentykacji jest efektywnie omijane.
Poniższy skrypt jest wstrzykiwany w celu zmodyfikowania wyniku metody **evaluatePolicy**. Zmienia on wynik wywołania zwrotnego tak, aby zawsze wskazywał sukces.
Jednym z powszechnych problemów związanych z weryfikacją certyfikatu TLS jest sprawdzenie, czy certyfikat został podpisany przez **zaufaną instytucję certyfikującą**, ale **nie sprawdzenie**, czy **nazwa hosta** certyfikatu jest taka sama jak nazwa hosta, do której się odwołujemy.\
Aby sprawdzić ten problem za pomocą Burp, po zaufaniu certyfikatowi Burp w iPhone'ie, można **utworzyć nowy certyfikat z Burp dla innej nazwy hosta** i go użyć. Jeśli aplikacja nadal działa, oznacza to, że istnieje podatność.
Jeśli aplikacja poprawnie korzysta z Pinowania SSL, to aplikacja będzie działać tylko wtedy, gdy certyfikat będzie oczekiwanym certyfikatem. Podczas testowania aplikacji **może to być problemem, ponieważ Burp będzie serwował swój własny certyfikat.**\
Aby ominąć tę ochronę w urządzeniu z jailbreakiem, można zainstalować aplikację [**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2) lub zainstalować [**Burp Mobile Assistant**](https://portswigger.net/burp/documentation/desktop/mobile/config-ios-device)
* Można uzyskać dostęp do **`/User/Library/Notes/notes.sqlite`** w celu odczytania zapisanych notatek w aplikacji.
* Wewnątrz folderu z zainstalowaną aplikacją (**`/User/Applications/<IDAPLIKACJI>/`**) można znaleźć kilka interesujących plików:
* **`iTunesArtwork`**: Ikona używana przez aplikację
* **`iTunesMetadata.plist`**: Informacje o aplikacji używane w Sklepie App Store
* **`/Library/*`**: Zawiera preferencje i pamięć podręczną. W **`/Library/Cache/Snapshots/*`** można znaleźć zrzut wykonany z aplikacji przed wysłaniem jej do tła.
Deweloperzy mogą zdalnie **załatać wszystkie instalacje swojej aplikacji natychmiast**, bez konieczności ponownego przesłania aplikacji do Sklepu App Store i oczekiwania na zatwierdzenie.\
W tym celu zazwyczaj używa się [**JSPatch**](https://github.com/bang590/JSPatch)**.** Istnieją również inne opcje, takie jak [Siren](https://github.com/ArtSabintsev/Siren) i [react-native-appstore-version-checker](https://www.npmjs.com/package/react-native-appstore-version-checker).\
**To mechanizm, który może być nadużyty przez złośliwe oprogramowanie innych firm, dlatego zaleca się sprawdzenie, jakie metody są używane do automatycznej aktualizacji (jeśli takie istnieją) i ich przetestowanie.** Można spróbować pobrać poprzednią wersję aplikacji w tym celu.
Znaczącym wyzwaniem związanym z **SDK firm zewnętrznych** jest **brak precyzyjnej kontroli** nad ich funkcjonalnościami. Deweloperzy stoją przed wyborem: zintegrować SDK i zaakceptować wszystkie jego funkcje, w tym potencjalne podatności bezpieczeństwa i obawy o prywatność, lub całkowicie zrezygnować z jego korzyści. Często deweloperzy nie są w stanie załatać podatności w tych SDK samodzielnie. Ponadto, gdy SDK zyskują zaufanie w społeczności, niektóre z nich mogą zaczynać zawierać złośliwe oprogramowanie.
Usługi świadczone przez SDK firm zewnętrznych mogą obejmować śledzenie zachowań użytkowników, wyświetlanie reklam lub ulepszenia w doświadczeniu użytkownika. Jednakże wiąże się to z ryzykiem, ponieważ deweloperzy mogą nie być w pełni świadomi kodu wykonywanego przez te biblioteki, co prowadzi do potencjalnych zagrożeń dla prywatności i bezpieczeństwa. Istotne jest ograniczenie udostępnianych firmom zewnętrznym informacji do niezbędnego minimum oraz zapewnienie, że żadne wrażliwe dane nie są ujawniane.
Implementacja usług firm zewnętrznych zazwyczaj przyjmuje dwie formy: samodzielna biblioteka lub pełne SDK. Aby chronić prywatność użytkownika, wszelkie dane udostępniane tym usługom powinny być **anonimizowane**, aby zapobiec ujawnieniu danych osobowych (PII).
Aby zidentyfikować biblioteki używane przez aplikację, można skorzystać z polecenia **`otool`**. Narzędzie to powinno być uruchomione przeciwko aplikacji i każdej używanej bibliotece, aby odkryć dodatkowe biblioteki.
Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować zadania** przy użyciu najbardziej zaawansowanych narzędzi społeczności.\
<summary><strong>Dowiedz się, jak hakować AWS od zera do bohatera z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegram**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) na GitHubie.