Wstęp

Od czasu pierwszej wersji systemu iOS na oryginalnym iPhonie Apple nałożył restrykcyjne ograniczenia na oprogramowanie, które może działać na ich urządzeniach mobilnych. Tylko aplikacje, które zostały kryptograficznie podpisane certyfikatem programisty zaufanym przez Apple, mogły być uruchamiane, a języki skryptowe, takie jak AppleScript, nie zostały znalezione w iOS. Możliwość dynamicznego wykonywania kodu została prawie całkowicie usunięta, tworząc potężną barierę dla exploitów, które musiałyby znaleźć sposób na obejście tych zabezpieczeń, aby uruchomić szkodliwy program. Ponieważ system macOS stale adaptuje więcej funkcji systemu iOS, zaczął również ściślej egzekwować podpisywanie kodu. Zespół ds. luk w zabezpieczeniach Trellix Advanced Research Center odkrył dużą nową klasę błędów, które umożliwiają ominięcie podpisywania kodu w celu wykonania dowolnego kodu w kontekście kilku aplikacji platformy, co prowadzi do eskalacji uprawnień i wyjścia z piaskownicy zarówno w systemie macOS, jak i iOS. Luki w zabezpieczeniach wahają się od średniej do wysokiej z wynikami CVSS między 5,1 a 7,1. Problemy te mogą być wykorzystywane przez złośliwe aplikacje i exploity w celu uzyskania dostępu do poufnych informacji, takich jak wiadomości użytkownika, historia połączeń i zdjęcia.

Znalezienie nowej klasy błędu

We wrześniu 2021 r. firma Citizen Lab ujawniła FORCEDENTRY, exploit umożliwiający zdalne wykonanie kodu na iOS za pomocą 0 kliknięć, którego celem był saudyjski aktywista w celu zainfekowania jego iPhone’a złośliwym oprogramowaniem Pegasus. Następnie współpracowali z Google Project Zero w celu przeanalizowania exploitów, co doprowadziło do powstania dwóch postów szczegółowo opisujących metody użyte w ataku. W części 1 opisano wstępne wykorzystanie kodu parsującego PDF, a w części 2 przedstawiono wyjście z piaskownicy. Podczas gdy wiele uwagi poświęcono pierwszemu exploitowi, byliśmy znacznie bardziej zainteresowani drugim, ponieważ opisywał sposób dynamicznego wykonywania dowolnego kodu w innym procesie, który całkowicie omijał podpisywanie kodu. Obejmował on NPredicate, niewinnie wyglądającą klasę, która pozwala programistom filtrować listy dowolnych obiektów. W rzeczywistości składnia NSPredicate jest pełnym językiem skryptowym. Możliwość dynamicznego generowania i uruchamiania kodu na iOS była przez cały czas oficjalną funkcją. To był jednak dopiero początek, ponieważ ta funkcja ujawniła zupełnie nową klasę błędów, która całkowicie łamie zabezpieczenia międzyprocesowe w systemach macOS i iOS.

Ucieczka z piaskownicy FORCEDENTRY nie była pierwszą eksploracją tego zachowania. CodeColorist, płodny badacz bezpieczeństwa przestrzeni użytkownika iOS, zaprojektował wyzwanie dla Real World CTF 2019, które obejmowało wykorzystanie mechaniki NSPredicate. Następnie wygłosił przemówienie i opublikował post na blogu See No Eval w styczniu 2021 r., w którym szczegółowo opisano, jak używać ich do uruchamiania dowolnego kodu. Istotą tych badań było to, że obiekty NSExpression, bloki konstrukcyjne NSPredicate, mogą być używane do wywoływania dowolnych metod na dowolnych klasach i obiektach. Korzystając z istniejących klas w prywatnych frameworkach Apple, można było ominąć uwierzytelnianie wskaźnika (PAC) i wszelkie inne ograniczenia w celu wywołania dowolnej funkcji. Jednak post opisuje również sposoby, w jakie Apple złagodziło niebezpieczeństwo tych obiektów, a mianowicie poprzez protokół o nazwie NPredicateVisitor. Klasy, które implementują ten protokół, mogą być używane do sprawdzania każdego wyrażenia, aby upewnić się, że można je bezpiecznie ocenić. CodeColorist zauważa na końcu swojego postu, że „bez odpowiedniej walidacji może to być powierzchnia ataku między procesami w celu ominięcia TCC”.

Wydaje się, że post See No Eval był główną ideą ucieczki z piaskownicy w FORCEDENTRY. Od tego czasu Apple usunął funkcje używane w tym exploicie i poście na blogu CodeColorist oraz dodał nowe środki zaradcze, aby spróbować ograniczyć to, co można zrobić za pomocą NSPredicate. Te środki zaradcze były duże

listy odmów, aby uniemożliwić korzystanie z niektórych klas i metod, które mogłyby wyraźnie zagrozić bezpieczeństwu. Odkryliśmy jednak, że te nowe ograniczenia można ominąć. Używając metod, które nie zostały ograniczone, możliwe było opróżnienie tych list, umożliwiając wszystkie te same metody, które były dostępne wcześniej. To obejście zostało przypisane przez Apple do CVE-2023-23530. Co ważniejsze, odkryliśmy, że można ominąć prawie każdą implementację NSPredicateVisitor. Istnieje wiele procesów z usługami XPC (podstawowa metoda komunikacji międzyprocesowej wysokiego poziomu w systemach macOS i iOS), które akceptują argumenty NSPredicate i używają NSPredicateVisitor, aby upewnić się, że podane wyrażenie jest bezpieczne do oceny. Chociaż nie ma jednej implementacji, ponieważ prawie każdy proces ma swoją własną wersję, większość używa właściwości „expressionType” do odfiltrowywania wyrażeń funkcyjnych. Problem polega na tym, że ta właściwość może być ustawiona w procesie wysyłania i odbiorca ufa, że ​​jest dokładna, przez co kontrole są bezużyteczne. Temu obejściu przypisano CVE-2023-23531. Te dwie techniki otworzyły ogromny zakres potencjalnych luk, które wciąż badamy.

Luki w zabezpieczeniach

Pierwszą luką, którą znaleźliśmy w tej nowej klasie błędów, jest coreduetd, proces zbierający dane o zachowaniu na urządzeniu. Atakujący, który wykona kod w procesie z odpowiednimi uprawnieniami, takim jak Messages czy Safari, może wysłać złośliwy NSPredicate i wykonać kod z uprawnieniami tego procesu. Ten proces działa jako root w systemie macOS i daje atakującemu dostęp do kalendarza, książki adresowej i zdjęć użytkownika. Inny problem o podobnym wpływie dotyczy również kontekstu, procesu związanego z CoreDuet. Wynik ten jest podobny do wyniku FORCEDENTRY, w którym osoba atakująca może wykorzystać podatną na ataki usługę XPC do wykonania kodu z procesu z większym dostępem do urządzenia.

Demony appstored (i appstoreagent w systemie macOS) posiadają również podatne na ataki usługi XPC. Osoba atakująca mająca kontrolę nad procesem, który może komunikować się z tymi demonami, może wykorzystać te luki w celu uzyskania możliwości instalowania dowolnych podpisanych aplikacji, potencjalnie nawet aplikacji systemowych.

Wystąpiły również luki tej klasy w usługach, do których dostęp miała dowolna aplikacja, bez konieczności posiadania uprawnień. Pierwszym z nich, który znaleźliśmy, był OSLogService, usługa XPC, której można użyć do odczytania potencjalnie wrażliwych informacji z dziennika systemowego. Co ważniejsze, osoba atakująca może wykorzystać lukę NPredicate w UIKitCore na iPadzie. Ustawiając reguły aktywacji złośliwych scen, aplikacja może wykonać kod w SpringBoard, wysoce uprzywilejowanej aplikacji, która może uzyskiwać dostęp do danych lokalizacji, kamery i mikrofonu, historii połączeń, zdjęć i innych poufnych danych, a także czyścić urządzenie.

Wniosek

Powyższe luki stanowią poważne naruszenie modelu bezpieczeństwa macOS i iOS, który polega na tym, że poszczególne aplikacje mają precyzyjny dostęp do podzbioru potrzebnych im zasobów i wysyłają zapytania do usług o wyższych uprawnieniach, aby uzyskać cokolwiek innego. Usługi, które akceptują argumenty NSPredicate i sprawdzają je przy niewystarczającej liczbie NSPredicateVisitor, pozwalają złośliwym aplikacjom i kodowi wykorzystującemu luki w obejściu izolacji procesów i bezpośredniemu dostępowi do znacznie większej liczby zasobów, niż powinno to być dozwolone. Te problemy zostały rozwiązane w systemach macOS 13.2 i iOS 16.3. Chcielibyśmy podziękować firmie Apple za szybką współpracę z firmą Trellix w celu rozwiązania tych problemów.

Ten dokument i zawarte w nim informacje opisują badania bezpieczeństwa komputerowego wyłącznie w celach edukacyjnych i dla wygody klientów Trellix. Trellix prowadzi badania zgodnie z Polityką rozsądnego ujawniania luk w zabezpieczeniach.

(Autorem jest pan Austin Emmitt, a poglądy wyrażone w tym artykule są jego własnymi)