macOS xpc_connection_get_audit_token Attack
Last updated
Last updated
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)
Aby uzyskać więcej informacji, sprawdź oryginalny post: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. To jest podsumowanie:
Jeśli nie wiesz, czym są wiadomości Mach, zacznij od sprawdzenia tej strony:
macOS IPC - Inter Process CommunicationNa razie pamiętaj, że (definicja stąd): Wiadomości Mach są wysyłane przez port mach, który jest kanałem komunikacyjnym z jednym odbiorcą i wieloma nadawcami wbudowanym w jądro mach. Wiele procesów może wysyłać wiadomości do portu mach, ale w danym momencie tylko jeden proces może z niego odczytać. Podobnie jak deskryptory plików i gniazda, porty mach są przydzielane i zarządzane przez jądro, a procesy widzą tylko liczbę całkowitą, którą mogą użyć, aby wskazać jądru, który z ich portów mach chcą użyć.
Jeśli nie wiesz, jak nawiązywane jest połączenie XPC, sprawdź:
macOS XPCCo jest interesujące do wiedzenia, to że abstrakcja XPC to połączenie jeden do jednego, ale opiera się na technologii, która może mieć wielu nadawców, więc:
Porty mach są jednym odbiorcą, wieloma nadawcami.
Token audytu połączenia XPC to token audytu skopiowany z najnowszej odebranej wiadomości.
Uzyskanie tokenu audytu połączenia XPC jest kluczowe dla wielu sprawdzania bezpieczeństwa.
Chociaż poprzednia sytuacja brzmi obiecująco, istnieją pewne scenariusze, w których nie spowoduje to problemów (stąd):
Tokeny audytu są często używane do sprawdzenia autoryzacji, aby zdecydować, czy zaakceptować połączenie. Ponieważ dzieje się to za pomocą wiadomości do portu usługi, połączenie jeszcze nie zostało nawiązane. Więcej wiadomości na tym porcie będzie traktowane jako dodatkowe żądania połączenia. Tak więc wszelkie sprawdzenia przed zaakceptowaniem połączenia nie są podatne (to również oznacza, że w -listener:shouldAcceptNewConnection: token audytu jest bezpieczny). Dlatego szukamy połączeń XPC, które weryfikują konkretne działania.
Obsługa zdarzeń XPC jest realizowana synchronicznie. Oznacza to, że obsługa zdarzenia dla jednej wiadomości musi być zakończona przed wywołaniem jej dla następnej, nawet na współbieżnych kolejkach dyspozytorskich. Tak więc wewnątrz obsługi zdarzeń XPC token audytu nie może być nadpisany przez inne normalne (nieodpowiadające!) wiadomości.
Dwie różne metody, które mogą być wykorzystywane:
Wariant 1:
Eksploit łączy się z usługą A i usługą B
Usługa B może wywołać uprzywilejowaną funkcjonalność w usłudze A, której użytkownik nie może
Usługa A wywołuje xpc_connection_get_audit_token podczas nie będąc w obsłudze zdarzeń dla połączenia w dispatch_async.
Tak więc inna wiadomość mogłaby nadpisać token audytu, ponieważ jest wysyłana asynchronicznie poza obsługą zdarzeń.
Eksploit przekazuje usłudze B prawo SEND do usługi A.
Tak więc svc B będzie faktycznie wysyłać wiadomości do usługi A.
Eksploit próbuje wywołać uprzywilejowane działanie. W RC svc A sprawdza autoryzację tego działania, podczas gdy svc B nadpisał token audytu (dając exploitowi dostęp do wywołania uprzywilejowanego działania).
Wariant 2:
Usługa B może wywołać uprzywilejowaną funkcjonalność w usłudze A, której użytkownik nie może
Eksploit łączy się z usługą A, która wysyła exploitowi wiadomość oczekującą na odpowiedź w określonym porcie odpowiedzi.
Eksploit wysyła usłudze B wiadomość przekazując ten port odpowiedzi.
Gdy usługa B odpowiada, wysyła wiadomość do usługi A, podczas gdy eksploit wysyła inną wiadomość do usługi A, próbując osiągnąć uprzywilejowaną funkcjonalność i oczekując, że odpowiedź od usługi B nadpisze token audytu w idealnym momencie (Race Condition).
Scenariusz:
Dwie usługi mach A i B, z którymi możemy się połączyć (na podstawie profilu sandbox i sprawdzeń autoryzacji przed zaakceptowaniem połączenia).
A musi mieć sprawdzenie autoryzacji dla konkretnego działania, które B może przekazać (ale nasza aplikacja nie może).
Na przykład, jeśli B ma jakieś uprawnienia lub działa jako root, może to pozwolić mu poprosić A o wykonanie uprzywilejowanego działania.
Dla tego sprawdzenia autoryzacji A uzyskuje token audytu asynchronicznie, na przykład wywołując xpc_connection_get_audit_token z dispatch_async.
W tym przypadku atakujący mógłby wywołać Race Condition, tworząc eksploit, który prosi A o wykonanie działania wielokrotnie, podczas gdy B wysyła wiadomości do A. Gdy RC jest udany, token audytu B zostanie skopiowany w pamięci podczas gdy żądanie naszego eksploit jest obsługiwane przez A, dając mu dostęp do uprzywilejowanego działania, które tylko B mógłby zażądać.
To zdarzyło się z A jako smd i B jako diagnosticd. Funkcja SMJobBless z smb może być używana do instalacji nowego uprzywilejowanego narzędzia pomocniczego (jako root). Jeśli proces działający jako root skontaktuje się z smd, żadne inne kontrole nie będą przeprowadzane.
Dlatego usługa B to diagnosticd, ponieważ działa jako root i może być używana do monitorowania procesu, więc gdy monitorowanie się rozpocznie, będzie wysyłać wiele wiadomości na sekundę.
Aby przeprowadzić atak:
Nawiąż połączenie z usługą o nazwie smd, używając standardowego protokołu XPC.
Utwórz drugie połączenie z diagnosticd. W przeciwieństwie do normalnej procedury, zamiast tworzyć i wysyłać dwa nowe porty mach, prawo wysyłania portu klienta jest zastępowane duplikatem prawa wysyłania związanego z połączeniem smd.
W rezultacie wiadomości XPC mogą być wysyłane do diagnosticd, ale odpowiedzi z diagnosticd są przekierowywane do smd. Dla smd wydaje się, że wiadomości zarówno od użytkownika, jak i diagnosticd pochodzą z tego samego połączenia.
Następny krok polega na poleceniu diagnosticd, aby rozpoczął monitorowanie wybranego procesu (potencjalnie własnego użytkownika). Równocześnie wysyłany jest potok rutynowych wiadomości 1004 do smd. Celem jest zainstalowanie narzędzia z podwyższonymi uprawnieniami.
Działanie to wywołuje warunek wyścigu w funkcji handle_bless. Czas jest kluczowy: wywołanie funkcji xpc_connection_get_pid musi zwrócić PID procesu użytkownika (ponieważ uprzywilejowane narzędzie znajduje się w pakiecie aplikacji użytkownika). Jednak funkcja xpc_connection_get_audit_token, szczególnie w podprogramie connection_is_authorized, musi odnosić się do tokenu audytu należącego do diagnosticd.
W środowisku XPC (Cross-Process Communication), chociaż obsługi zdarzeń nie wykonują się współbieżnie, obsługa wiadomości odpowiedzi ma unikalne zachowanie. Konkretnie, istnieją dwa różne sposoby wysyłania wiadomości, które oczekują odpowiedzi:
xpc_connection_send_message_with_reply: Tutaj wiadomość XPC jest odbierana i przetwarzana w wyznaczonej kolejce.
xpc_connection_send_message_with_reply_sync: Przeciwnie, w tej metodzie wiadomość XPC jest odbierana i przetwarzana w bieżącej kolejce dyspozytorskiej.
To rozróżnienie jest kluczowe, ponieważ pozwala na możliwość parsing pakietów odpowiedzi współbieżnie z wykonaniem obsługi zdarzeń XPC. Należy zauważyć, że podczas gdy _xpc_connection_set_creds implementuje blokady, aby chronić przed częściowym nadpisaniem tokenu audytu, nie rozszerza tej ochrony na cały obiekt połączenia. W rezultacie tworzy to podatność, w której token audytu może być zastąpiony w czasie między analizą pakietu a wykonaniem jego obsługi zdarzeń.
Aby wykorzystać tę podatność, wymagane jest następujące ustawienie:
Dwie usługi mach, określane jako A i B, które mogą nawiązać połączenie.
Usługa A powinna zawierać sprawdzenie autoryzacji dla konkretnego działania, które tylko B może wykonać (aplikacja użytkownika nie może).
Usługa A powinna wysłać wiadomość, która oczekuje odpowiedzi.
Użytkownik może wysłać wiadomość do B, na którą odpowie.
Proces eksploatacji obejmuje następujące kroki:
Czekaj na wysłanie wiadomości przez usługę A, która oczekuje odpowiedzi.
Zamiast odpowiadać bezpośrednio na A, port odpowiedzi jest przejmowany i używany do wysłania wiadomości do usługi B.
Następnie wysyłana jest wiadomość dotycząca zabronionego działania, z oczekiwaniem, że zostanie przetworzona współbieżnie z odpowiedzią od B.
Poniżej znajduje się wizualna reprezentacja opisanego scenariusza ataku:
 (1) (1) (1) (1) (1) (1).png)
Trudności w lokalizowaniu instancji: Wyszukiwanie instancji użycia xpc_connection_get_audit_token było trudne, zarówno statycznie, jak i dynamicznie.
Metodologia: Frida została użyta do podłączenia funkcji xpc_connection_get_audit_token, filtrując wywołania, które nie pochodziły z obsługi zdarzeń. Jednak ta metoda była ograniczona do podłączonego procesu i wymagała aktywnego użycia.
Narzędzia analityczne: Narzędzia takie jak IDA/Ghidra były używane do badania dostępnych usług mach, ale proces był czasochłonny, skomplikowany przez wywołania związane z pamięcią podręczną dyld.
Ograniczenia skryptowe: Próby skryptowania analizy wywołań do xpc_connection_get_audit_token z bloków dispatch_async były utrudnione przez złożoności w analizie bloków i interakcjach z pamięcią podręczną dyld.
Zgłoszone problemy: Zgłoszenie zostało przesłane do Apple, szczegółowo opisujące ogólne i specyficzne problemy znalezione w smd.
Odpowiedź Apple: Apple rozwiązało problem w smd, zastępując xpc_connection_get_audit_token funkcją xpc_dictionary_get_audit_token.
Charakter naprawy: Funkcja xpc_dictionary_get_audit_token jest uważana za bezpieczną, ponieważ pobiera token audytu bezpośrednio z wiadomości mach związanej z odebraną wiadomością XPC. Jednak nie jest częścią publicznego API, podobnie jak xpc_connection_get_audit_token.
Brak szerszej naprawy: Nie jest jasne, dlaczego Apple nie wdrożyło bardziej kompleksowej naprawy, takiej jak odrzucenie wiadomości, które nie są zgodne z zapisanym tokenem audytu połączenia. Możliwość legalnych zmian tokenu audytu w niektórych scenariuszach (np. użycie setuid) może być czynnikiem.
Aktualny status: Problem nadal występuje w iOS 17 i macOS 14, stanowiąc wyzwanie dla tych, którzy starają się go zidentyfikować i zrozumieć.
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)
