From 05fe414d3e9b7610e3cbb4bfcad4ff5792867f22 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 26 Aug 2025 17:13:38 +0000 Subject: [PATCH] Translated ['src/macos-hardening/macos-security-and-privilege-escalation --- .../macos-proces-abuse/macos-dirty-nib.md | 156 +++++++++++++----- 1 file changed, 115 insertions(+), 41 deletions(-) diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md index d53339c07..1b2b7c0d0 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md @@ -2,72 +2,146 @@ {{#include ../../../banners/hacktricks-training.md}} -**Aby uzyskać więcej szczegółów na temat techniki, sprawdź oryginalny post z:** [**https://blog.xpnsec.com/dirtynib/**](https://blog.xpnsec.com/dirtynib/) oraz następujący post od [**https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/**](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/)**.** Oto podsumowanie: +Dirty NIB odnosi się do nadużywania plików Interface Builder (.xib/.nib) wewnątrz podpisanego bundle aplikacji macOS w celu wykonania logiki kontrolowanej przez atakującego w docelowym procesie, dziedzicząc w ten sposób jego entitlements i TCC permissions. Technika została pierwotnie opisana przez xpn (MDSec), a później uogólniona i znacznie rozszerzona przez Sector7, który także omówił mitygacje Apple w macOS 13 Ventura i macOS 14 Sonoma. Aby uzyskać tło i dogłębne analizy, zobacz referencje na końcu. -### Czym są pliki Nib +> TL;DR +> • Before macOS 13 Ventura: zastąpienie MainMenu.nib w bundle (lub innego nib ładowanego przy starcie) mogło niezawodnie umożliwić wstrzyknięcie do procesu i często eskalację uprawnień. +> • Since macOS 13 (Ventura) and improved in macOS 14 (Sonoma): first‑launch deep verification, bundle protection, Launch Constraints, and the new TCC “App Management” permission w dużej mierze uniemożliwiają modyfikacje nib po uruchomieniu przez niepowiązane aplikacje. Ataki mogą być nadal możliwe w niszowych przypadkach (np. narzędzia od tego samego dewelopera modyfikujące własne aplikacje, lub terminale, którym użytkownik nadał App Management/Full Disk Access). -Pliki Nib (skrót od NeXT Interface Builder), część ekosystemu deweloperskiego Apple, są przeznaczone do definiowania **elementów UI** i ich interakcji w aplikacjach. Zawierają zserializowane obiekty, takie jak okna i przyciski, i są ładowane w czasie wykonywania. Mimo ich ciągłego użycia, Apple obecnie promuje Storyboards dla bardziej kompleksowej wizualizacji przepływu UI. +## What are NIB/XIB files -Główny plik Nib jest odniesiony w wartości **`NSMainNibFile`** wewnątrz pliku `Info.plist` aplikacji i jest ładowany przez funkcję **`NSApplicationMain`** wykonywaną w funkcji `main` aplikacji. +Pliki Nib (skrót od NeXT Interface Builder) to zserializowane grafy obiektów UI używane przez aplikacje AppKit. Nowoczesne Xcode przechowuje edytowalne pliki XML .xib, które są kompilowane do .nib w czasie budowania. Typowa aplikacja ładuje główny interfejs za pomocą `NSApplicationMain()` która odczytuje klucz `NSMainNibFile` z Info.plist aplikacji i instancjuje graf obiektów w czasie wykonania. -### Proces wstrzykiwania Dirty Nib +Key points that enable the attack: +- NIB loading instancjuje dowolne klasy Objective‑C bez wymogu, aby implementowały NSSecureCoding (Apple’s nib loader falls back to `init`/`initWithFrame:` when `initWithCoder:` is not available). +- Cocoa Bindings mogą być nadużywane do wywoływania metod w trakcie instancjonowania nibów, w tym łańcuchowych wywołań, które nie wymagają interakcji użytkownika. -#### Tworzenie i konfigurowanie pliku NIB +## Dirty NIB injection process (attacker view) -1. **Wstępna konfiguracja**: -- Utwórz nowy plik NIB za pomocą XCode. -- Dodaj obiekt do interfejsu, ustawiając jego klasę na `NSAppleScript`. -- Skonfiguruj początkową właściwość `source` za pomocą Atrybutów Czasu Wykonania Zdefiniowanych przez Użytkownika. -2. **Gadżet do wykonywania kodu**: -- Konfiguracja umożliwia uruchamianie AppleScript na żądanie. -- Zintegruj przycisk, aby aktywować obiekt `Apple Script`, wywołując selektor `executeAndReturnError:`. -3. **Testowanie**: +The classic pre‑Ventura flow: +1) Create a malicious .xib +- Add an `NSAppleScript` object (or other “gadget” classes such as `NSTask`). +- Add an `NSTextField` whose title contains the payload (e.g., AppleScript or command arguments). +- Add one or more `NSMenuItem` objects wired via bindings to call methods on the target object. -- Prosty skrypt Apple do celów testowych: +2) Auto‑trigger without user clicks +- Użyj bindings, aby ustawić target/selector elementu menu, a następnie wywołaj prywatną metodę `_corePerformAction`, tak aby akcja uruchomiła się automatycznie podczas ładowania nib. Dzięki temu nie jest potrzebne kliknięcie użytkownika. -```bash +Minimalny przykład łańcucha auto‑wyzwalania wewnątrz .xib (skrócony dla przejrzystości): +```xml + + + + + + + + + + + + + + + + + + + + + + +``` +This achieves arbitrary AppleScript execution in the target process upon nib load. Advanced chains can: +- Instantiate arbitrary AppKit classes (e.g., `NSTask`) and call zero‑argument methods like `-launch`. +- Call arbitrary selectors with object arguments via the binding trick above. +- Load AppleScriptObjC.framework to bridge into Objective‑C and even call selected C APIs. +- On older systems that still include Python.framework, bridge into Python and then use `ctypes` to call arbitrary C functions (Sector7’s research). + +3) Zastąp nib aplikacji +- Skopiuj target.app do zapisywalnej lokalizacji, zastąp np. `Contents/Resources/MainMenu.nib` złośliwym nibem i uruchom target.app. Przed Venturą, po jednorazowej ocenie przez Gatekeeper, kolejne uruchomienia wykonywały tylko płytkie sprawdzenia podpisu, więc zasoby nie‑wykonywalne (jak .nib) nie były ponownie walidowane. + +Przykładowy AppleScript payload dla widocznego testu: +```applescript set theDialogText to "PWND" display dialog theDialogText ``` +## Nowoczesne zabezpieczenia macOS (Ventura/Monterey/Sonoma/Sequoia) -- Przetestuj, uruchamiając w debuggerze XCode i klikając przycisk. +Apple wprowadził kilka systemowych mechanizmów łagodzących, które radykalnie zmniejszają skuteczność Dirty NIB w nowoczesnym macOS: +- First‑launch deep verification and bundle protection (macOS 13 Ventura) +- Przy pierwszym uruchomieniu dowolnej aplikacji (poddanej kwarantannie lub nie) przeprowadzana jest głęboka weryfikacja podpisu obejmująca wszystkie zasoby bundle. Następnie bundle staje się chroniony: tylko aplikacje od tego samego dewelopera (lub wyraźnie dozwolone przez aplikację) mogą modyfikować jego zawartość. Inne aplikacje wymagają nowego uprawnienia TCC „App Management”, aby zapisywać w bundle innej aplikacji. +- Launch Constraints (macOS 13 Ventura) +- Aplikacje systemowe/dostarczane przez Apple nie mogą być kopiowane w inne miejsce i uruchamiane; to zabija podejście „copy to /tmp, patch, run” dla aplikacji OS. +- Usprawnienia w macOS 14 Sonoma +- Apple wzmocnił App Management i naprawił znane obejścia (np. CVE‑2023‑40450) zgłoszone przez Sector7. Python.framework został usunięty wcześniej (macOS 12.3), co przerwało niektóre łańcuchy eskalacji uprawnień. +- Gatekeeper/Quarantine changes +- Dla szerszej dyskusji o Gatekeeper, pochodzeniu (provenance) i zmianach w mechanizmach oceny (assessment), które wpłynęły na tę technikę, zobacz stronę wymienioną poniżej. -#### Celowanie w aplikację (przykład: Pages) +> Praktyczne implikacje +> • Na Ventura+ generalnie nie można modyfikować .nib aplikacji stron trzecich, chyba że Twój proces ma App Management lub jest podpisany tym samym Team ID co cel (np. narzędzia deweloperskie). +> • Przyznanie App Management lub Full Disk Access powłokom/terminalom skutecznie ponownie otwiera tę powierzchnię ataku dla wszystkiego, co może wykonywać kod w kontekście tego terminala. -1. **Przygotowanie**: -- Skopiuj docelową aplikację (np. Pages) do osobnego katalogu (np. `/tmp/`). -- Uruchom aplikację, aby obejść problemy z Gatekeeperem i zbuforować ją. -2. **Nadpisywanie pliku NIB**: -- Zastąp istniejący plik NIB (np. NIB panelu "O programie") stworzonym plikiem DirtyNIB. -3. **Wykonanie**: -- Wywołaj wykonanie, wchodząc w interakcję z aplikacją (np. wybierając element menu `O programie`). -#### Dowód koncepcji: Uzyskiwanie dostępu do danych użytkownika +### Radzenie sobie z Launch Constraints -- Zmodyfikuj AppleScript, aby uzyskać dostęp i wyodrębnić dane użytkownika, takie jak zdjęcia, bez zgody użytkownika. +Launch Constraints blokują uruchamianie wielu aplikacji Apple z lokalizacji innych niż domyślne począwszy od Ventury. Jeśli polegałeś na przed‑Ventura workflowach, takich jak kopiowanie aplikacji Apple do katalogu tymczasowego, modyfikowanie `MainMenu.nib` i uruchamianie jej, spodziewaj się, że na >= 13.0 to nie zadziała. -### Przykład kodu: Złośliwy plik .xib -- Uzyskaj dostęp i przeglądaj [**przykład złośliwego pliku .xib**](https://gist.github.com/xpn/16bfbe5a3f64fedfcc1822d0562636b4), który demonstruje wykonywanie dowolnego kodu. +## Enumeracja celów i nibów (przydatne do badań / systemów legacy) -### Inny przykład +- Zlokalizuj aplikacje, których UI jest oparty na nib: +```bash +find /Applications -maxdepth 2 -name Info.plist -exec sh -c \ +'for p; do if /usr/libexec/PlistBuddy -c "Print :NSMainNibFile" "$p" >/dev/null 2>&1; \ +then echo "[+] $(dirname "$p") uses NSMainNibFile=$( /usr/libexec/PlistBuddy -c "Print :NSMainNibFile" "$p" )"; fi; done' sh {} + +``` +- Znajdź potencjalne zasoby nib wewnątrz bundle: +```bash +find target.app -type f \( -name "*.nib" -o -name "*.xib" \) -print +``` +- Sprawdź dogłębnie code signatures (nie powiedzie się, jeśli manipulowałeś zasobami i nie podpisałeś ich ponownie): +```bash +codesign --verify --deep --strict --verbose=4 target.app +``` +> Uwaga: Na nowoczesnym macOS zostaniesz także zablokowany przez bundle protection/TCC przy próbie zapisu do bundle innej aplikacji bez odpowiedniej autoryzacji. -W poście [https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/) możesz znaleźć samouczek na temat tworzenia dirty nib. -### Rozwiązywanie ograniczeń uruchamiania +## Wykrywanie i wskazówki DFIR -- Ograniczenia uruchamiania utrudniają wykonywanie aplikacji z nieoczekiwanych lokalizacji (np. `/tmp`). -- Możliwe jest zidentyfikowanie aplikacji, które nie są chronione przez ograniczenia uruchamiania i celowanie w nie w celu wstrzykiwania plików NIB. +- Monitorowanie integralności plików w zasobach bundle +- Monitoruj zmiany mtime/ctime w `Contents/Resources/*.nib` oraz innych nie‑wykonywalnych zasobach zainstalowanych aplikacji. +- Zunifikowane logi i zachowanie procesów +- Monitoruj nieoczekiwane wykonanie AppleScript wewnątrz aplikacji GUI oraz procesy ładujące AppleScriptObjC lub Python.framework. Przykład: +```bash +log stream --info --predicate 'processImagePath CONTAINS[cd] ".app/Contents/MacOS/" AND (eventMessage CONTAINS[cd] "AppleScript" OR eventMessage CONTAINS[cd] "loadAppleScriptObjectiveCScripts")' +``` +- Oceny proaktywne +- Okresowo uruchamiaj `codesign --verify --deep` dla krytycznych aplikacji, aby upewnić się, że zasoby pozostają nienaruszone. +- Kontekst uprawnień +- Przeprowadź audyt, kto/co ma w TCC „App Management” lub Full Disk Access (szczególnie terminale i agenty zarządzające). Usunięcie tych uprawnień z ogólnego przeznaczenia shelli uniemożliwia trywialne ponowne włączenie manipulacji w stylu Dirty NIB. -### Dodatkowe zabezpieczenia macOS -Od macOS Sonoma wprowadzone zostały ograniczenia dotyczące modyfikacji wewnątrz pakietów aplikacji. Jednak wcześniejsze metody obejmowały: +## Hardening defensywny (developerzy i obrońcy) -1. Skopiowanie aplikacji do innej lokalizacji (np. `/tmp/`). -2. Zmiana nazw katalogów w pakiecie aplikacji, aby obejść początkowe zabezpieczenia. -3. Po uruchomieniu aplikacji w celu zarejestrowania się w Gatekeeperze, modyfikacja pakietu aplikacji (np. zastąpienie MainMenu.nib plikiem Dirty.nib). -4. Przywrócenie nazw katalogów i ponowne uruchomienie aplikacji w celu wykonania wstrzykniętego pliku NIB. +- Preferuj programowy interfejs użytkownika lub ogranicz to, co jest instancjonowane z nibów. Unikaj dołączania potężnych klas (np. `NSTask`) do grafów nib oraz unikaj wiązań, które pośrednio wywołują selektory na dowolnych obiektach. +- Przyjmij hardened runtime z Library Validation (już standard dla nowoczesnych aplikacji). Chociaż samo w sobie nie zatrzyma nib injection, blokuje łatwe ładowanie natywnego kodu i zmusza atakujących do payloadów opartych wyłącznie na skryptach. +- Nie żądaj ani nie polegaj na szerokich uprawnieniach App Management w narzędziach ogólnego przeznaczenia. Jeśli MDM wymaga App Management, odseparuj ten kontekst od shelli inicjowanych przez użytkownika. +- Regularnie weryfikuj integralność bundle aplikacji i spraw, by mechanizmy aktualizacji samonaprawiały zasoby bundle. -**Uwaga**: Ostatnie aktualizacje macOS złagodziły ten exploit, uniemożliwiając modyfikacje plików w pakietach aplikacji po buforowaniu przez Gatekeeper, co czyni exploit nieskutecznym. + +## Powiązana lektura w HackTricks + +Dowiedz się więcej o Gatekeeper, quarantine i zmianach provenance, które wpływają na tę technikę: + +{{#ref}} +../macos-security-protections/macos-gatekeeper.md +{{#endref}} + + +## Źródła + +- xpn – DirtyNIB (oryginalny opis z przykładem dla Pages): https://blog.xpnsec.com/dirtynib/ +- Sector7 – Bringing process injection into view(s): exploiting all macOS apps using nib files (April 5, 2024): https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/ {{#include ../../../banners/hacktricks-training.md}}