iOS Pentesting
Last updated
Last updated
Użyj Trickest, aby łatwo budować i automatyzować przepływy pracy zasilane przez najbardziej zaawansowane narzędzia społecznościowe na świecie. Uzyskaj dostęp już dziś:
Na tej stronie znajdziesz informacje o symulatorze iOS, emulatorach i jailbreaku:
iOS Testing EnvironmentPodczas testowania zostanie zasugerowanych kilka operacji (połączenie z urządzeniem, odczyt/zapis/przesyłanie/pobieranie plików, użycie niektórych narzędzi...). Dlatego, jeśli nie wiesz, jak wykonać którąkolwiek z tych czynności, proszę, zacznij czytać stronę:
iOS Basic Testing OperationsDla kolejnych kroków aplikacja powinna być zainstalowana na urządzeniu i powinna już uzyskać plik IPA aplikacji. Przeczytaj stronę Podstawowe operacje testowania iOS, aby dowiedzieć się, jak to zrobić.
Zaleca się użycie narzędzia MobSF do przeprowadzenia automatycznej analizy statycznej pliku IPA.
Identyfikacja ochron obecnych w binarnym:
PIE (Position Independent Executable): Gdy jest włączone, aplikacja ładowana jest do losowego adresu pamięci za każdym razem, gdy jest uruchamiana, co utrudnia przewidywanie jej początkowego adresu pamięci.
Stack Canaries: Aby zweryfikować integralność stosu, wartość „canary” jest umieszczana na stosie przed wywołaniem funkcji i jest weryfikowana ponownie po zakończeniu funkcji.
ARC (Automatic Reference Counting): Aby zapobiec powszechnym błędom uszkodzenia pamięci
Zaszyfrowany plik binarny: Plik binarny powinien być zaszyfrowany
Identyfikacja wrażliwych/niebezpiecznych funkcji
Słabe algorytmy haszujące
Niebezpieczne funkcje losowe
Niebezpieczna funkcja ‘Malloc’
Niebezpieczne i podatne funkcje
Sprawdź analizę dynamiczną, którą przeprowadza MobSF. Będziesz musiał nawigować przez różne widoki i wchodzić z nimi w interakcje, ale będzie to podłączać kilka klas podczas wykonywania innych czynności i przygotuje raport, gdy skończysz.
Użyj polecenia frida-ps -Uai
, aby określić identyfikator pakietu zainstalowanych aplikacji:
Dowiedz się, jak enumerować komponenty aplikacji i jak łatwo hookować metody i klasy za pomocą objection:
iOS Hooking With ObjectionStruktura pliku IPA jest zasadniczo taka sama jak spakowany pakiet. Zmieniając jego rozszerzenie na .zip
, można go rozpakować, aby ujawnić jego zawartość. W tej strukturze, Bundle reprezentuje w pełni zapakowaną aplikację gotową do instalacji. Wewnątrz znajdziesz katalog o nazwie <NAME>.app
, który zawiera zasoby aplikacji.
Info.plist
: Ten plik zawiera szczegółowe informacje konfiguracyjne aplikacji.
_CodeSignature/
: Ten katalog zawiera plik plist, który zawiera podpis, zapewniając integralność wszystkich plików w pakiecie.
Assets.car
: Skompresowany archiwum, które przechowuje pliki zasobów, takie jak ikony.
Frameworks/
: Ten folder zawiera natywne biblioteki aplikacji, które mogą być w formie plików .dylib
lub .framework
.
PlugIns/
: Może zawierać rozszerzenia do aplikacji, znane jako pliki .appex
, chociaż nie zawsze są obecne. * Core Data
: Jest używane do zapisywania trwałych danych aplikacji do użytku offline, do buforowania danych tymczasowych oraz do dodawania funkcji cofania do aplikacji na jednym urządzeniu. Aby synchronizować dane między wieloma urządzeniami w jednym koncie iCloud, Core Data automatycznie odzwierciedla schemat do kontenera CloudKit.
PkgInfo
: Plik PkgInfo
to alternatywny sposób określenia typu i kodów twórcy aplikacji lub pakietu.
en.lproj, fr.proj, Base.lproj: To pakiety językowe, które zawierają zasoby dla tych konkretnych języków oraz domyślny zasób na wypadek, gdy dany język nie jest obsługiwany.
Bezpieczeństwo: Katalog _CodeSignature/
odgrywa kluczową rolę w bezpieczeństwie aplikacji, weryfikując integralność wszystkich plików w pakiecie 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 ogólnego rozmiaru.
Frameworki i PlugIns: Te katalogi podkreślają modularność aplikacji iOS, umożliwiając programistom dołączanie wielokrotnego użytku bibliotek kodu (Frameworks/
) i rozszerzanie funkcjonalności aplikacji (PlugIns/
).
Lokalizacja: Struktura wspiera wiele języków, ułatwiając globalny zasięg aplikacji poprzez dołączanie zasobów dla konkretnych pakietów językowych.
Info.plist
Info.plist jest fundamentem aplikacji iOS, zawierającym kluczowe dane konfiguracyjne w formie par klucz-wartość. Ten plik jest wymagany nie tylko dla aplikacji, ale także dla rozszerzeń aplikacji i frameworków zapakowanych w środku. Jest zbudowany w formacie XML lub binarnym i zawiera krytyczne informacje, od uprawnień aplikacji po konfiguracje bezpieczeństwa. Aby szczegółowo zbadać dostępne klucze, można odwołać się do Dokumentacji Dewelopera Apple.
Dla tych, którzy chcą pracować z tym plikiem w bardziej dostępnym formacie, konwersja XML może być osiągnięta bez wysiłku za pomocą plutil
na macOS (dostępne natywnie w wersjach 10.2 i nowszych) lub plistutil
na Linuxie. Komendy do konwersji są następujące:
Dla macOS:
Dla Linuksa:
Wśród niezliczonych informacji, które plik Info.plist może ujawnić, szczególnie istotne wpisy to ciągi uprawnień aplikacji (UsageDescription
), niestandardowe schematy URL (CFBundleURLTypes
) oraz konfiguracje dla App Transport Security (NSAppTransportSecurity
). Wpisy te, wraz z innymi, takimi jak eksportowane/importowane niestandardowe typy dokumentów (UTExportedTypeDeclarations
/ UTImportedTypeDeclarations
), można łatwo zlokalizować, przeglądając plik lub używając prostego polecenia grep
:
Ścieżki danych
W środowisku iOS, katalogi są wyznaczone 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ą umieszczane w /var/mobile/containers/Data/Application/
. Te aplikacje mają przypisany unikalny identyfikator znany jako 128-bitowy UUID, co utrudnia ręczne zlokalizowanie folderu aplikacji z powodu losowości nazw katalogów.
Ponieważ aplikacje w iOS muszą być izolowane, każda aplikacja będzie miała również folder wewnątrz $HOME/Library/Containers
z CFBundleIdentifier
aplikacji jako nazwą folderu.
Jednak oba foldery (foldery danych i kontenerów) mają plik .com.apple.mobile_container_manager.metadata.plist
, który łączy oba pliki w kluczu MCMetadataIdentifier
).
Aby ułatwić odkrycie katalogu instalacyjnego aplikacji zainstalowanej przez użytkownika, narzędzie objection oferuje przydatne polecenie, env
. To polecenie ujawnia szczegółowe informacje o katalogu dla danej aplikacji. Poniżej znajduje się przykład użycia tego polecenia:
Alternatywnie, nazwa aplikacji może być wyszukiwana w /private/var/containers
za pomocą polecenia find
:
Polecenia takie jak ps
i lsof
mogą być również wykorzystane do zidentyfikowania procesu aplikacji i wylistowania otwartych plików, odpowiednio, dostarczając informacji na temat aktywnych ścieżek katalogów aplikacji:
Bundle directory:
AppName.app
To jest pakiet aplikacji, jak wcześniej widziano w IPA, zawiera niezbędne dane aplikacji, statyczne treści oraz skompilowany plik binarny aplikacji.
Ten katalog jest widoczny dla użytkowników, ale użytkownicy nie mogą do niego pisać.
Zawartość tego katalogu nie jest kopiowana.
Zawartość tego folderu jest używana do walidacji podpisu kodu.
Data directory:
Documents/
Zawiera wszystkie dane generowane przez użytkownika. Użytkownik końcowy aplikacji inicjuje tworzenie tych danych.
Widoczny dla użytkowników i użytkownicy mogą do niego pisać.
Zawartość tego katalogu jest kopiowana.
Aplikacja może wyłączyć ścieżki, ustawiając NSURLIsExcludedFromBackupKey
.
Library/
Zawiera wszystkie pliki, które nie są specyficzne dla użytkownika, takie jak cache, preferencje, ciasteczka i pliki konfiguracyjne listy właściwości (plist).
Aplikacje iOS zazwyczaj używają podkatalogów Application Support
i Caches
, ale aplikacja może tworzyć własne podkatalogi.
Library/Caches/
Zawiera półtrwałe pliki cache.
Niewidoczny dla użytkowników i użytkownicy nie mogą do niego pisać.
Zawartość tego katalogu nie jest kopiowana.
System operacyjny może automatycznie usunąć pliki z tego katalogu, gdy aplikacja nie jest uruchomiona, a miejsce na dysku jest ograniczone.
Library/Application Support/
Zawiera trwałe pliki niezbędne do działania aplikacji.
Niewidoczny dla użytkowników i użytkownicy nie mogą do niego pisać.
Zawartość tego katalogu jest kopiowana.
Aplikacja może wyłączyć ścieżki, ustawiając NSURLIsExcludedFromBackupKey
.
Library/Preferences/
Używany do przechowywania właściwości, które mogą utrzymywać się nawet po ponownym uruchomieniu aplikacji.
Informacje są zapisywane, niezaszyfrowane, wewnątrz piaskownicy aplikacji w pliku plist o nazwie [BUNDLE_ID].plist.
Wszystkie pary klucz/wartość przechowywane za pomocą NSUserDefaults
można znaleźć w tym pliku.
tmp/
Użyj tego katalogu do zapisywania plików tymczasowych, które nie muszą się utrzymywać między uruchomieniami aplikacji.
Zawiera nietrwałe pliki cache.
Niewidoczny dla użytkowników.
Zawartość tego katalogu nie jest kopiowana.
System operacyjny może automatycznie usunąć pliki z tego katalogu, gdy aplikacja nie jest uruchomiona, a miejsce na dysku jest ograniczone.
Przyjrzyjmy się bliżej katalogowi pakietu aplikacji iGoat-Swift (.app) wewnątrz katalogu Bundle (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
):
W folderze <application-name>.app
znajdziesz plik binarny o nazwie <application-name>
. To jest plik, który będzie wykonywany. Możesz przeprowadzić podstawową inspekcję pliku binarnego za pomocą narzędzia otool
:
Sprawdź, czy aplikacja jest zaszyfrowana
Zobacz, czy jest jakiekolwiek wyjście dla:
Rozkładanie binarnego
Rozłóż sekcję tekstową:
Aby wydrukować segment Objective-C przykładowej aplikacji, można użyć:
Aby uzyskać bardziej zwarty kod Objective-C, możesz użyć class-dump:
Jednak najlepsze opcje do deasemblacji binarnego to: Hopper i IDA.
Użyj Trickest, aby łatwo budować i automatyzować przepływy pracy zasilane przez najbardziej zaawansowane narzędzia społecznościowe na świecie. Uzyskaj dostęp już dziś:
Aby dowiedzieć się, jak iOS przechowuje dane na urządzeniu, przeczytaj tę stronę:
iOS BasicsNastępujące miejsca do przechowywania informacji powinny być sprawdzone zaraz po zainstalowaniu aplikacji, po sprawdzeniu wszystkich funkcjonalności aplikacji, a nawet po wylogowaniu się z jednego użytkownika i zalogowaniu się na innego. Celem jest znalezienie niechronionych wrażliwych informacji aplikacji (hasła, tokeny), bieżącego użytkownika oraz wcześniej zalogowanych użytkowników.
Pliki plist to strukturalne pliki XML, które zawierają pary klucz-wartość. To sposób na przechowywanie danych trwałych, więc czasami możesz znaleźć wrażliwe informacje w tych plikach. Zaleca się sprawdzenie tych plików po zainstalowaniu aplikacji i po intensywnym korzystaniu z niej, aby zobaczyć, czy zapisano nowe dane.
Najczęstszym sposobem na trwałe przechowywanie danych w plikach plist jest użycie NSUserDefaults. Ten plik plist jest zapisywany wewnątrz piaskownicy aplikacji w Library/Preferences/<appBundleID>.plist
Klasa NSUserDefaults
zapewnia programowy interfejs do interakcji z domyślnym systemem. Domyślny system pozwala aplikacji dostosować swoje zachowanie zgodnie z preferencjami użytkownika. Dane zapisane przez NSUserDefaults
można przeglądać w pakiecie aplikacji. Ta klasa przechowuje dane w pliku plist, ale jest przeznaczona do użycia z małymi ilościami danych.
Dane te nie mogą być dłużej bezpośrednio dostępne za pomocą zaufanego komputera, ale można uzyskać do nich dostęp, wykonując kopię zapasową.
Możesz zrzucić informacje zapisane za pomocą NSUserDefaults
używając ios nsuserdefaults get
z objection.
Aby znaleźć wszystkie pliki plist używane przez aplikację, możesz uzyskać dostęp do /private/var/mobile/Containers/Data/Application/{APPID}
i uruchomić:
Aby przekonwertować pliki z formatu XML lub binarnego (bplist) na XML, dostępne są różne metody w zależności od systemu operacyjnego:
Dla użytkowników macOS: Wykorzystaj polecenie plutil
. To wbudowane narzędzie w macOS (10.2+), zaprojektowane do tego celu:
Dla użytkowników Linuksa: Najpierw zainstaluj libplist-utils
, a następnie użyj plistutil
, aby przekonwertować swój plik:
W sesji Objection: Do analizy aplikacji mobilnych, konkretne polecenie pozwala na bezpośrednie konwertowanie plików plist:
Core Data
to framework do zarządzania warstwą modelu obiektów w Twojej aplikacji. Core Data może używać SQLite jako swojego trwałego magazynu, ale sam framework nie jest bazą danych.
CoreData nie szyfruje swoich danych domyślnie. Jednak dodatkowa warstwa szyfrowania może być dodana do CoreData. Zobacz GitHub Repo po więcej szczegółów.
Możesz znaleźć informacje o SQLite Core Data aplikacji w ścieżce /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support
Jeśli możesz otworzyć SQLite i uzyskać dostęp do wrażliwych informacji, to znalazłeś błędną konfigurację.
YapDatabase to magazyn klucz/wartość zbudowany na bazie SQLite. Ponieważ bazy danych Yap są bazami danych sqlite, możesz je znaleźć, używając zaproponowanej komendy w poprzedniej sekcji.
Powszechną praktyką jest, że aplikacje tworzą 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ź więc do katalogu aplikacji, w którym zapisane są dane (/private/var/mobile/Containers/Data/Application/{APPID}
)
Programiści mogą przechowywać i synchronizować dane w bazie danych NoSQL hostowanej w chmurze za pomocą Firebase Real-Time Databases. Przechowywane w formacie JSON, dane są synchronizowane do wszystkich podłączonych klientów w czasie rzeczywistym.
Możesz znaleźć, jak sprawdzić źle skonfigurowane bazy danych Firebase tutaj:
Firebase DatabaseRealm Objective-C i Realm Swift oferują potężną alternatywę dla przechowywania danych, której nie zapewnia Apple. Domyślnie przechowują dane w postaci niezaszyfrowanej, z możliwością szyfrowania dostępną poprzez odpowiednią konfigurację.
Bazy danych znajdują się w: /private/var/mobile/Containers/Data/Application/{APPID}
. Aby zbadać te pliki, można wykorzystać polecenia takie jak:
Aby wyświetlić te pliki bazy danych, zaleca się użycie narzędzia Realm Studio.
Aby wdrożyć szyfrowanie w bazie danych Realm, można użyć następującego fragmentu kodu:
Couchbase Lite jest opisywany jako lekki i wbudowany silnik bazy danych, który stosuje podejście zorientowane na dokumenty (NoSQL). Zaprojektowany z myślą o iOS i macOS, oferuje możliwość bezproblemowej synchronizacji danych.
Aby zidentyfikować potencjalne bazy danych Couchbase na urządzeniu, należy sprawdzić następujący katalog:
iOS przechowuje ciasteczka aplikacji w Library/Cookies/cookies.binarycookies
wewnątrz folderu każdej aplikacji. Jednak deweloperzy czasami decydują się zapisać je w keychain, ponieważ wspomniany plik cookie może być dostępny w kopiach zapasowych.
Aby sprawdzić plik ciasteczek, możesz użyć tego skryptu python lub użyć ios cookies get
z objection.
Możesz także użyć objection, aby przekonwertować te pliki na format JSON i sprawdzić dane.
Domyślnie NSURLSession przechowuje dane, takie jak żądania i odpowiedzi HTTP w bazie danych Cache.db. Ta baza danych może zawierać wrażliwe dane, jeśli tokeny, nazwy użytkowników lub jakiekolwiek inne wrażliwe informacje zostały zbuforowane. Aby znaleźć zbuforowane informacje, otwórz katalog danych aplikacji (/var/mobile/Containers/Data/Application/<UUID>
) i przejdź do /Library/Caches/<Bundle Identifier>
. Cache WebKit jest również przechowywany w pliku Cache.db. Objection może otworzyć i interagować z bazą danych za pomocą polecenia sqlite connect Cache.db
, ponieważ jest to normalna baza danych SQLite.
Zaleca się wyłączenie buforowania tych danych, ponieważ mogą one zawierać wrażliwe informacje w żądaniu lub odpowiedzi. Poniższa lista pokazuje różne sposoby osiągnięcia tego:
Zaleca się usunięcie zbuforowanych odpowiedzi po wylogowaniu. Można to zrobić za pomocą metody dostarczonej przez Apple o nazwie removeAllCachedResponses
. Możesz wywołać tę metodę w następujący sposób:
URLCache.shared.removeAllCachedResponses()
Ta metoda usunie wszystkie zbuforowane żądania i odpowiedzi z pliku Cache.db. 2. Jeśli nie potrzebujesz korzystać z zalet ciasteczek, zaleca się po prostu użycie właściwości konfiguracyjnej .ephemeral URLSession, która wyłączy zapisywanie ciasteczek i buforów.
Obiekt konfiguracyjny sesji efemerycznej jest podobny do domyślnej konfiguracji sesji (patrz domyślna), z tą różnicą, że odpowiadający obiekt sesji nie przechowuje buforów, magazynów poświadczeń ani żadnych danych związanych z sesją na dysku. Zamiast tego dane związane z sesją są przechowywane w RAM. Jedynym razem, gdy sesja efemeryczna zapisuje dane na dysku, jest wtedy, gdy powiesz jej, aby zapisała zawartość URL do pliku.
3. Bufor można również wyłączyć, ustawiając politykę buforowania na .notAllowed. Wyłączy to przechowywanie bufora w jakiejkolwiek formie, zarówno w pamięci, jak i na dysku.
Kiedy naciśniesz przycisk home, iOS robi zrzut ekranu bieżącego ekranu, aby móc przejść do aplikacji w znacznie płynniejszy sposób. Jednak jeśli na bieżącym ekranie znajdują się wrażliwe dane, zostaną one zapisane w obrazie (który utrzymuje się po ponownym uruchomieniu). To są zrzuty ekranu, do których możesz również uzyskać dostęp, podwójnie stukając w ekran główny, aby przełączać się między aplikacjami.
O ile iPhone nie jest zrootowany, atakujący musi mieć dostęp do urządzenia odblokowanego, 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 iOX 7.0).
Jednym ze sposobów zapobiegania temu złemu zachowaniu jest umieszczenie pustego ekranu lub usunięcie wrażliwych danych przed zrobieniem zrzutu ekranu za pomocą funkcji ApplicationDidEnterBackground()
.
Poniżej znajduje się przykładowa metoda naprawcza, która ustawi domyślny zrzut ekranu.
Swift:
Objective-C:
To ustawia tło na overlayImage.png
za każdym razem, gdy aplikacja jest w tle. Zapobiega to wyciekom wrażliwych danych, ponieważ overlayImage.png
zawsze zastępuje bieżący widok.
Aby uzyskać dostęp i zarządzać iOS keychain, dostępne są narzędzia takie jak Keychain-Dumper, odpowiednie dla urządzeń z jailbreakiem. Dodatkowo, Objection oferuje polecenie ios keychain dump
do podobnych celów.
Klasa NSURLCredential jest idealna do zapisywania wrażliwych informacji bezpośrednio w keychain, omijając potrzebę używania NSUserDefaults lub innych opakowań. Aby przechować poświadczenia po zalogowaniu, używany jest następujący kod Swift:
Aby wyodrębnić te zapisane dane uwierzytelniające, używana jest komenda Objection ios nsurlcredentialstorage dump
.
Od iOS 8.0 użytkownicy mogą instalować niestandardowe rozszerzenia klawiatur, które są zarządzane w Ustawienia > Ogólne > Klawiatura > Klawiatury. Chociaż te klawiatury oferują rozszerzoną funkcjonalność, niosą 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ć użycie niestandardowych klawiatur do wprowadzania wrażliwych informacji.
Zalecenia dotyczące bezpieczeństwa:
Zaleca się wyłączenie klawiatur firm trzecich w celu zwiększenia bezpieczeństwa.
Należy być świadomym funkcji automatycznej korekty i podpowiedzi domyślnej klawiatury iOS, które mogą przechowywać wrażliwe 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 wrażliwych danych. Zaleca się zresetowanie słownika klawiatury za pomocą Ustawienia > Ogólne > Resetuj > Zresetuj słownik klawiatury w celu usunięcia danych z pamięci podręcznej.
Przechwytywanie ruchu sieciowego może ujawnić, czy niestandardowa klawiatura przesyła naciśnięcia klawiszy zdalnie.
Protokół UITextInputTraits oferuje właściwości do zarządzania automatyczną korektą i bezpiecznym wprowadzaniem tekstu, co jest niezbędne do zapobiegania pamięci podręcznej wrażliwych informacji. Na przykład, wyłączenie automatycznej korekty i włączenie bezpiecznego wprowadzania tekstu można osiągnąć za pomocą:
Dodatkowo, deweloperzy powinni upewnić się, że pola tekstowe, szczególnie te do wprowadzania wrażliwych informacji, takich jak hasła i PIN-y, wyłączają pamięć podręczną, ustawiając autocorrectionType
na UITextAutocorrectionTypeNo
i secureTextEntry
na YES
.
Debugowanie kodu często wiąże się z użyciem logowania. Istnieje ryzyko, że logi mogą zawierać wrażliwe informacje. Wcześniej, w iOS 6 i wcześniejszych wersjach, logi były dostępne dla wszystkich aplikacji, co stwarzało ryzyko wycieku wrażliwych danych. Teraz aplikacje mają ograniczony dostęp tylko do swoich logów.
Pomimo tych ograniczeń, atakujący z fizycznym dostępem do odblokowanego urządzenia może nadal to wykorzystać, podłączając urządzenie do komputera i czytając logi. Ważne jest, aby zauważyć, że logi pozostają na dysku nawet po odinstalowaniu aplikacji.
Aby zminimalizować ryzyko, zaleca się dokładne interakcje z aplikacją, eksplorując wszystkie jej funkcjonalności i dane wejściowe, aby upewnić się, że żadne wrażliwe informacje nie są rejestrowane przypadkowo.
Przy przeglądaniu kodu źródłowego aplikacji w poszukiwaniu potencjalnych wycieków, należy szukać zarówno zdefiniowanych, jak i niestandardowych instrukcji logowania przy użyciu słów kluczowych takich jak NSLog
, NSAssert
, NSCAssert
, fprintf
dla funkcji wbudowanych oraz wszelkich wzmiankach o Logging
lub Logfile
dla niestandardowych implementacji.
Aplikacje rejestrują różne informacje, które mogą być wrażliwe. Aby monitorować te logi, użyj narzędzi i poleceń takich jak:
są przydatne. Dodatkowo, Xcode oferuje sposób na zbieranie logów konsoli:
Otwórz Xcode.
Podłącz urządzenie iOS.
Przejdź do Window -> Devices and Simulators.
Wybierz swoje urządzenie.
Wywołaj problem, który badałeś.
Użyj przycisku Open Console, aby wyświetlić logi w nowym oknie.
Dla bardziej zaawansowanego logowania, połączenie z powłoką urządzenia i użycie socat może zapewnić monitorowanie logów w czasie rzeczywistym:
Followed by commands to observe log activities, which can be invaluable for diagnosing issues or identifying potential data leakage in logs.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Funkcje automatycznego tworzenia kopii zapasowych są zintegrowane z iOS, co ułatwia tworzenie kopii danych urządzenia za pomocą iTunes (do macOS Catalina), Findera (od macOS Catalina wzwyż) lub iCloud. Te kopie zapasowe obejmują prawie wszystkie dane urządzenia, z wyjątkiem wysoce wrażliwych elementów, takich jak szczegóły Apple Pay i konfiguracje Touch ID.
Włączenie zainstalowanych aplikacji i ich danych do kopii zapasowych podnosi kwestię potencjalnego wycieku danych oraz ryzyko, że zmiany w kopiach zapasowych mogą wpłynąć na funkcjonalność aplikacji. Zaleca się, aby nie przechowywać wrażliwych informacji w postaci tekstu jawnego w katalogu aplikacji ani jej podkatalogach, aby zminimalizować te ryzyka.
Pliki w Documents/
i Library/Application Support/
są domyślnie kopiowane. Programiści mogą wykluczyć konkretne pliki lub katalogi z kopii zapasowych, używając NSURL setResourceValue:forKey:error:
z kluczem NSURLIsExcludedFromBackupKey
. Ta praktyka jest kluczowa dla ochrony wrażliwych danych przed uwzględnieniem w kopiach zapasowych.
Aby ocenić bezpieczeństwo kopii zapasowej aplikacji, zacznij od utworzenia kopii zapasowej za pomocą Findera, a następnie zlokalizuj ją, korzystając z wskazówek zawartych w oficjalnej dokumentacji Apple. Analizuj kopię zapasową pod kątem wrażliwych danych lub konfiguracji, które mogą być zmieniane, aby wpłynąć na zachowanie aplikacji.
Wrażliwe informacje można wyszukiwać za pomocą narzędzi wiersza poleceń lub aplikacji takich jak iMazing. W przypadku zaszyfrowanych kopii zapasowych obecność szyfrowania można potwierdzić, sprawdzając klucz "IsEncrypted" w pliku "Manifest.plist" w katalogu głównym kopii zapasowej.
Aby poradzić sobie z zaszyfrowanymi kopiami zapasowymi, przydatne mogą być skrypty Pythona dostępne w repozytorium GitHub DinoSec, takie jak backup_tool.py i backup_passwd.py, chociaż mogą wymagać dostosowań w celu zapewnienia zgodności z najnowszymi wersjami iTunes/Finder. Narzędzie iOSbackup to kolejna opcja uzyskania dostępu do plików w zabezpieczonych hasłem kopiach zapasowych.
Przykład zmiany zachowania aplikacji poprzez modyfikacje kopii zapasowej można zobaczyć w aplikacji portfela bitcoin Bither, gdzie PIN blokady UI jest przechowywany w net.bither.plist
pod kluczem pin_code. Usunięcie tego klucza z plist i przywrócenie kopii zapasowej usuwa wymóg podawania PIN-u, zapewniając nieograniczony dostęp.
Podczas pracy z wrażliwymi informacjami przechowywanymi w pamięci aplikacji, kluczowe jest ograniczenie czasu ekspozycji tych danych. Istnieją dwa główne podejścia do badania zawartości pamięci: tworzenie zrzutu pamięci i analiza pamięci w czasie rzeczywistym. Obie metody mają swoje wyzwania, w tym możliwość pominięcia krytycznych danych podczas procesu zrzutu lub analizy.
Dla urządzeń z jailbreakiem i bez jailbreaka, narzędzia takie jak objection i Fridump umożliwiają zrzut pamięci procesu aplikacji. Po zrzuceniu, analiza tych danych wymaga różnych narzędzi, w zależności od charakteru informacji, których szukasz.
Aby wyodrębnić ciągi z zrzutu pamięci, można użyć poleceń takich jak strings
lub rabin2 -zz
:
Aby uzyskać bardziej szczegółową analizę, w tym wyszukiwanie konkretnych typów danych lub wzorców, radare2 oferuje rozbudowane możliwości wyszukiwania:
r2frida oferuje potężną alternatywę do inspekcji pamięci aplikacji w czasie rzeczywistym, bez potrzeby zrzutu pamięci. To narzędzie umożliwia wykonywanie poleceń wyszukiwania bezpośrednio w pamięci działającej aplikacji:
Niektórzy deweloperzy zapisują wrażliwe dane w lokalnej pamięci i szyfrują je kluczem zakodowanym/predykcyjnym w kodzie. Nie powinno się tego robić, ponieważ pewne techniki odwracania mogą pozwolić atakującym na wydobycie poufnych informacji.
Deweloperzy nie powinni używać deprecated algorithms do przeprowadzania checks autoryzacji, store lub send danych. Niektóre z tych algorytmów to: RC4, MD4, MD5, SHA1... Jeśli hashes są używane do przechowywania haseł, powinny być używane hashe odporne na brute-force z solą.
Główne kontrole, które należy przeprowadzić, to sprawdzenie, czy można znaleźć hardcoded hasła/tajemnice w kodzie, czy są one predictable, oraz czy kod używa jakiegoś rodzaju weak cryptography algorithms.
Ciekawe jest to, że można monitor niektóre crypto libraries automatycznie za pomocą objection z:
For więcej informacji na temat iOS cryptographic APIs i bibliotek, odwiedź https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography
Lokalna autoryzacja odgrywa kluczową rolę, szczególnie w kontekście zabezpieczania dostępu do zdalnego punktu końcowego za pomocą metod kryptograficznych. Istotą jest to, że bez odpowiedniej implementacji mechanizmy lokalnej autoryzacji mogą być obejście.
Apple's Local Authentication framework oraz keychain oferują solidne API dla deweloperów, aby ułatwić dialogi autoryzacji użytkownika i bezpiecznie obsługiwać dane poufne. Secure Enclave zabezpiecza identyfikację odcisku palca dla Touch ID, podczas gdy Face ID opiera się na rozpoznawaniu twarzy bez kompromitowania danych biometrycznych.
Aby zintegrować Touch ID/Face ID, deweloperzy mają dwa wybory API:
LocalAuthentication.framework
dla autoryzacji użytkownika na wysokim poziomie bez dostępu do danych biometrycznych.
Security.framework
dla dostępu do usług keychain na niższym poziomie, zabezpieczając dane poufne za pomocą autoryzacji biometrycznej. Różne open-source wrappers ułatwiają dostęp do keychain.
Jednak zarówno LocalAuthentication.framework
, jak i Security.framework
mają luki, ponieważ głównie zwracają wartości boolean bez przesyłania danych do procesów autoryzacji, co czyni je podatnymi na obejście (zobacz Don't touch me that way, by David Lindner et al).
Aby poprosić użytkowników o autoryzację, deweloperzy powinni wykorzystać metodę evaluatePolicy
w klasie LAContext
, wybierając pomiędzy:
deviceOwnerAuthentication
: Prosi o Touch ID lub kod dostępu do urządzenia, niepowodzenie, jeśli żadne z nich nie jest włączone.
deviceOwnerAuthenticationWithBiometrics
: Wyłącznie prosi o Touch ID.
Sukces autoryzacji wskazuje wartość boolean zwrócona przez evaluatePolicy
, co podkreśla potencjalną lukę w zabezpieczeniach.
Implementacja lokalnej autoryzacji w aplikacjach iOS polega na użyciu keychain APIs do bezpiecznego przechowywania danych poufnych, takich jak tokeny autoryzacyjne. Proces ten zapewnia, że dane mogą być dostępne tylko dla użytkownika, korzystającego z kodu dostępu do urządzenia lub autoryzacji biometrycznej, takiej jak Touch ID.
Keychain oferuje możliwość ustawienia elementów z atrybutem SecAccessControl
, który ogranicza dostęp do elementu, dopóki użytkownik nie uwierzytelni się pomyślnie 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 Swift i Objective-C demonstrujące, jak zapisać i odzyskać ciąg z keychain, wykorzystując te funkcje zabezpieczeń. Przykłady pokazują, jak skonfigurować kontrolę dostępu, aby wymagać 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.
Teraz możemy zażądać zapisanej pozycji z keychain. Usługi keychain wyświetlą użytkownikowi okno dialogowe uwierzytelniania i zwrócą dane lub nil w zależności od tego, czy podano odpowiedni odcisk palca, czy nie.
Użycie frameworków w aplikacji można również wykryć, analizując listę współdzielonych bibliotek dynamicznych w binarnej wersji aplikacji. Można to zrobić za pomocą otool
:
Jeśli LocalAuthentication.framework
jest używany w aplikacji, wynik będzie zawierał obie poniższe linie (pamiętaj, że LocalAuthentication.framework
używa Security.framework
w tle):
Jeśli używany jest Security.framework
, tylko drugi zostanie wyświetlony.
Dzięki Objection Biometrics Bypass, znajdującemu się na tej stronie GitHub, dostępna jest technika umożliwiająca pokonanie mechanizmu LocalAuthentication. Istotą tego podejścia jest wykorzystanie Frida do manipulacji funkcją evaluatePolicy
, zapewniając, że zawsze zwraca wynik True
, niezależnie od rzeczywistego sukcesu autoryzacji. Jest to szczególnie przydatne do omijania wadliwych procesów autoryzacji biometrycznej.
Aby aktywować to ominięcie, używa się następującego polecenia:
To polecenie uruchamia sekwencję, w której Objection rejestruje zadanie, które skutecznie zmienia wynik sprawdzenia evaluatePolicy
na True
.
Przykład użycia evaluatePolicy
z aplikacji DVIA-v2:
Aby osiągnąć bypass lokalnej autoryzacji, napisano skrypt Frida. Skrypt ten celuje w kontrolę evaluatePolicy, przechwytując jej callback, aby upewnić się, że zwraca success=1. Poprzez zmianę zachowania callbacka, kontrola autoryzacji jest skutecznie omijana.
Poniższy skrypt jest wstrzykiwany, aby zmodyfikować wynik metody evaluatePolicy. Zmienia wynik callbacka, aby zawsze wskazywał na sukces.
Aby wstrzyknąć skrypt Frida i obejść uwierzytelnianie biometryczne, używa się następującego polecenia:
Ważne jest, aby sprawdzić, czy nie zachodzi żadna komunikacja bez szyfrowania oraz czy aplikacja poprawnie waliduje certyfikat TLS serwera. Aby sprawdzić te problemy, możesz użyć proxy, takiego jak Burp:
iOS Burp Suite ConfigurationJednym z powszechnych problemów przy walidacji certyfikatu TLS jest sprawdzenie, czy certyfikat został podpisany przez zaufane CA, ale nie sprawdzenie, czy nazwa hosta certyfikatu jest nazwą hosta, do której się uzyskuje dostęp. Aby sprawdzić ten problem za pomocą Burp, po zaufaniu Burp CA na iPhonie, możesz utworzyć nowy certyfikat z Burp dla innej nazwy hosta i go użyć. Jeśli aplikacja nadal działa, to coś jest podatne.
Jeśli aplikacja poprawnie używa SSL Pinning, to aplikacja będzie działać tylko wtedy, gdy certyfikat jest tym, którego się oczekuje. Podczas testowania aplikacji może to być problem, ponieważ Burp będzie serwować swój własny certyfikat. Aby obejść tę ochronę na urządzeniu z jailbreakiem, możesz zainstalować aplikację SSL Kill Switch lub zainstalować Burp Mobile Assistant
Możesz również użyć objection's ios sslpinning disable
W /System/Library
możesz znaleźć frameworki zainstalowane w telefonie używane przez aplikacje systemowe
Aplikacje zainstalowane przez użytkownika z App Store znajdują się w /User/Applications
A /User/Library
zawiera dane zapisane przez aplikacje na poziomie użytkownika
Możesz uzyskać dostęp do /User/Library/Notes/notes.sqlite
, aby przeczytać notatki zapisane w aplikacji.
W folderze zainstalowanej aplikacji (/User/Applications/<APP ID>/
) możesz znaleźć kilka interesujących plików:
iTunesArtwork
: Ikona używana przez aplikację
iTunesMetadata.plist
: Informacje o aplikacji używane w App Store
/Library/*
: Zawiera preferencje i pamięć podręczną. W /Library/Cache/Snapshots/*
możesz znaleźć zrzut wykonany dla aplikacji przed wysłaniem jej w tle.
Deweloperzy mogą zdalnie natychmiast załatać wszystkie instalacje swojej aplikacji bez konieczności ponownego przesyłania aplikacji do App Store i czekania na jej zatwierdzenie. W tym celu zazwyczaj używa się JSPatch. Istnieją jednak również inne opcje, takie jak Siren i react-native-appstore-version-checker. To niebezpieczny mechanizm, który może być nadużywany przez złośliwe SDK stron trzecich, dlatego zaleca się sprawdzenie, która metoda jest używana do automatycznych aktualizacji (jeśli w ogóle) i przetestowanie jej. Możesz spróbować pobrać wcześniejszą wersję aplikacji w tym celu.
Znaczącym wyzwaniem związanym z SDK stron trzecich jest brak szczegółowej kontroli nad ich funkcjonalnościami. Deweloperzy stają przed wyborem: albo zintegrować SDK i zaakceptować wszystkie jego funkcje, w tym potencjalne luki w zabezpieczeniach i obawy dotyczące prywatności, albo całkowicie zrezygnować z jego korzyści. Często deweloperzy nie są w stanie sami załatać luk w tych SDK. Ponadto, gdy SDK zyskują zaufanie w społeczności, niektóre mogą zacząć zawierać złośliwe oprogramowanie.
Usługi świadczone przez SDK stron trzecich mogą obejmować śledzenie zachowań użytkowników, wyświetlanie reklam lub ulepszanie doświadczeń użytkowników. Jednak wprowadza to ryzyko, 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. Ważne jest, aby ograniczyć informacje udostępniane usługom stron trzecich do tego, co jest konieczne, i upewnić się, że żadne wrażliwe dane nie są ujawniane.
Implementacja usług stron trzecich zazwyczaj występuje w dwóch formach: jako samodzielna biblioteka lub pełne SDK. Aby chronić prywatność użytkowników, wszelkie dane udostępniane tym usługom powinny być anonimizowane, aby zapobiec ujawnieniu Osobowych Danych Identyfikowalnych (PII).
Aby zidentyfikować biblioteki używane przez aplikację, można użyć polecenia otool
. To narzędzie powinno być uruchamiane w odniesieniu do aplikacji i każdej używanej przez nią biblioteki współdzielonej, aby odkryć dodatkowe biblioteki.
OWASP iGoat https://github.com/OWASP/igoat <<< Wersja Objective-C https://github.com/OWASP/iGoat-Swift <<< Wersja Swift
Użyj Trickest, aby łatwo budować i automatyzować przepływy pracy zasilane przez najbardziej zaawansowane narzędzia społecznościowe na świecie. Uzyskaj dostęp już dziś:
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)