mirror of
https://github.com/carlospolop/hacktricks
synced 2025-02-16 14:08:26 +00:00
Translated ['macos-hardening/macos-security-and-privilege-escalation/mac
This commit is contained in:
Translator
parent
6f76a6ca7a
commit
d313286adc
1 changed files with 121 additions and 47 deletions
|
|
@ -2,13 +2,13 @@
|
|||
|
||||
<details>
|
||||
|
||||
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Altri modi per supportare HackTricks:
|
||||
|
||||
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](https://opensea.io/collection/the-peass-family)
|
||||
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
|
||||
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.
|
||||
|
||||
|
|
@ -16,9 +16,9 @@ Altri modi per supportare HackTricks:
|
|||
|
||||
## Messaggistica Mach tramite Porte
|
||||
|
||||
### Informazioni di Base
|
||||
### Informazioni di base
|
||||
|
||||
Mach utilizza **task** come **unità più piccola** per la condivisione di risorse, e ogni task può contenere **più thread**. Questi **task e thread sono mappati 1:1 ai processi e ai thread POSIX**.
|
||||
Mach utilizza **task** come **unità più piccola** per la condivisione di risorse, e ogni task può contenere **più thread**. Questi **task e thread sono mappati 1:1 su processi e thread POSIX**.
|
||||
|
||||
La comunicazione tra i task avviene tramite la Comunicazione tra Processi Mach (IPC), utilizzando canali di comunicazione unidirezionali. **I messaggi vengono trasferiti tra le porte**, che agiscono come una sorta di **code di messaggi** gestite dal kernel.
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ Un processo può anche inviare un nome di porta con alcuni diritti **a un task d
|
|||
|
||||
I diritti delle porte, che definiscono le operazioni che un task può eseguire, sono fondamentali per questa comunicazione. I possibili **diritti delle porte** sono ([definizioni da qui](https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html)):
|
||||
|
||||
* **Diritto di ricezione**, che consente di ricevere messaggi inviati alla porta. Le porte Mach sono code MPSC (multiple-producer, single-consumer), il che significa che può esserci solo **un diritto di ricezione per ogni porta** in tutto il sistema (a differenza delle pipe, dove più processi possono tutti detenere descrittori di file per l'estremità di lettura di una pipe).
|
||||
* **Diritto di ricezione**, che consente di ricevere messaggi inviati alla porta. Le porte Mach sono code MPSC (multiple-producer, single-consumer), il che significa che può esserci **solo un diritto di ricezione per ogni porta** in tutto il sistema (a differenza delle pipe, dove più processi possono tutti detenere descrittori di file per l'estremità di lettura di una pipe).
|
||||
* Un **task con il diritto di ricezione** può ricevere messaggi e **creare diritti di invio**, consentendogli di inviare messaggi. Originariamente solo il **proprio task ha il diritto di ricezione sulla sua porta**.
|
||||
* Se il proprietario del diritto di ricezione **muore** o lo termina, il **diritto di invio diventa inutile (nome morto).**
|
||||
* **Diritto di invio**, che consente di inviare messaggi alla porta.
|
||||
|
|
@ -55,19 +55,19 @@ Come già accennato, è possibile inviare diritti utilizzando messaggi Mach, tut
|
|||
|
||||
Per questo, è coinvolto il **bootstrap server** (**launchd** in mac), poiché **chiunque può ottenere un DIRITTO DI INVIO al bootstrap server**, è possibile chiedergli un diritto per inviare un messaggio a un altro processo:
|
||||
|
||||
1. Il Task **A** crea una **nuova porta**, ottenendo il **DIRITTO DI RICEZIONE** su di essa.
|
||||
2. Il Task **A**, essendo il detentore del DIRITTO DI RICEZIONE, **genera un DIRITTO DI INVIO per la porta**.
|
||||
3. Il Task **A** stabilisce una **connessione** con il **bootstrap server**, e **gli invia il DIRITTO DI INVIO** per la porta generato all'inizio.
|
||||
1. Il Task **A** crea una **nuova porta**, ottenendo il **diritto di ricezione** su di essa.
|
||||
2. Il Task **A**, essendo il detentore del diritto di ricezione, **genera un diritto di invio per la porta**.
|
||||
3. Il Task **A** stabilisce una **connessione** con il **bootstrap server**, e **invia il diritto di invio** per la porta generato all'inizio.
|
||||
* Ricorda che chiunque può ottenere un DIRITTO DI INVIO al bootstrap server.
|
||||
4. Il Task A invia un messaggio `bootstrap_register` al bootstrap server per **associare la porta data a un nome** come `com.apple.taska`
|
||||
5. Il Task **B** interagisce con il **bootstrap server** per eseguire una **ricerca bootstrap per il nome del servizio** (`bootstrap_lookup`). Quindi, affinché il bootstrap server possa rispondere, il task B invierà un **DIRITTO DI INVIO a una porta che ha creato precedentemente** all'interno del messaggio di ricerca. Se la ricerca ha successo, il **server duplica il DIRITTO DI INVIO** ricevuto dal Task A e **lo trasmette al Task B**.
|
||||
5. Il Task **B** interagisce con il **bootstrap server** per eseguire una **ricerca bootstrap per il nome del servizio** (`bootstrap_lookup`). Quindi, affinché il bootstrap server possa rispondere, il task B invierà un **DIRITTO DI INVIO a una porta precedentemente creata** all'interno del messaggio di ricerca. Se la ricerca ha successo, il **server duplica il DIRITTO DI INVIO** ricevuto dal Task A e lo **trasmette al Task B**.
|
||||
* Ricorda che chiunque può ottenere un DIRITTO DI INVIO al bootstrap server.
|
||||
6. Con questo DIRITTO DI INVIO, il **Task B** è in grado di **inviare** un **messaggio** **al Task A**.
|
||||
7. Per una comunicazione bidirezionale di solito il task **B** genera una nuova porta con un **DIRITTO DI RICEZIONE** e un **DIRITTO DI INVIO**, e dà il **DIRITTO DI INVIO al Task A** in modo che possa inviare messaggi a TASK B (comunicazione bidirezionale).
|
||||
7. Per una comunicazione bidirezionale di solito il task **B** genera una nuova porta con un **diritto di ricezione** e un **diritto di invio**, e dà il **diritto di invio al Task A** in modo che possa inviare messaggi a TASK B (comunicazione bidirezionale).
|
||||
|
||||
Il bootstrap server **non può autenticare** il nome del servizio reclamato da un task. Ciò significa che un **task** potrebbe potenzialmente **fingere di essere qualsiasi task di sistema**, come ad esempio **falsamente reclamare un nome di servizio di autorizzazione** e quindi approvare ogni richiesta.
|
||||
|
||||
Successivamente, Apple memorizza i **nomi dei servizi forniti dal sistema** in file di configurazione sicuri, situati in directory protette da SIP: `/System/Library/LaunchDaemons` e `/System/Library/LaunchAgents`. Accanto a ciascun nome di servizio, è anche memorizzato il **binario associato**. Il bootstrap server, creerà e manterrà un **DIRITTO DI RICEZIONE per ciascuno di questi nomi di servizio**.
|
||||
Successivamente, Apple memorizza i **nomi dei servizi forniti dal sistema** in file di configurazione sicuri, situati in directory protette da SIP: `/System/Library/LaunchDaemons` e `/System/Library/LaunchAgents`. Accanto a ciascun nome di servizio, è anche memorizzato il **binario associato**. Il bootstrap server, creerà e manterrà un **diritto di ricezione per ciascuno di questi nomi di servizio**.
|
||||
|
||||
Per questi servizi predefiniti, il **processo di ricerca differisce leggermente**. Quando viene cercato un nome di servizio, launchd avvia il servizio dinamicamente. Il nuovo flusso di lavoro è il seguente:
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ Per questi servizi predefiniti, il **processo di ricerca differisce leggermente*
|
|||
* **launchd** controlla se il task è in esecuzione e se non lo è, lo **avvia**.
|
||||
* Il Task **A** (il servizio) esegue un **check-in bootstrap** (`bootstrap_check_in()`). Qui, il **bootstrap** server crea un DIRITTO DI INVIO, lo mantiene e **trasferisce il DIRITTO DI RICEZIONE al Task A**.
|
||||
* launchd duplica il **DIRITTO DI INVIO e lo invia al Task B**.
|
||||
* Il Task **B** genera una nuova porta con un **DIRITTO DI RICEZIONE** e un **DIRITTO DI INVIO**, e dà il **DIRITTO DI INVIO al Task A** (il servizio) in modo che possa inviare messaggi a TASK B (comunicazione bidirezionale).
|
||||
* Il Task **B** genera una nuova porta con un **diritto di ricezione** e un **diritto di invio**, e dà il **diritto di invio al Task A** (il servizio) in modo che possa inviare messaggi a TASK B (comunicazione bidirezionale).
|
||||
|
||||
Tuttavia, questo processo si applica solo ai task di sistema predefiniti. I task non di sistema continuano a operare come descritto originariamente, il che potrebbe potenzialmente consentire l'usurpazione.
|
||||
|
||||
|
|
@ -101,8 +101,8 @@ I processi che possiedono un _**diritto di ricezione**_ possono ricevere messagg
|
|||
|
||||
Il campo iniziale **`msgh_bits`** è una mappa di bit:
|
||||
|
||||
- Il primo bit (più significativo) è utilizzato per indicare che un messaggio è complesso (più dettagli in seguito)
|
||||
- Il 3° e il 4° sono utilizzati dal kernel
|
||||
- Il primo bit (più significativo) viene utilizzato per indicare che un messaggio è complesso (più dettagli in seguito)
|
||||
- Il 3° e 4° bit sono utilizzati dal kernel
|
||||
- I **5 bit meno significativi del 2° byte** possono essere utilizzati per il **voucher**: un altro tipo di porta per inviare combinazioni chiave/valore.
|
||||
- I **5 bit meno significativi del 3° byte** possono essere utilizzati per la **porta locale**
|
||||
- I **5 bit meno significativi del 4° byte** possono essere utilizzati per la **porta remota**
|
||||
|
|
@ -120,12 +120,12 @@ I tipi che possono essere specificati nel voucher, nelle porte locali e remote s
|
|||
#define MACH_MSG_TYPE_DISPOSE_SEND 25 /* must hold send right(s) */
|
||||
#define MACH_MSG_TYPE_DISPOSE_SEND_ONCE 26 /* must hold sendonce right */
|
||||
```
|
||||
Per esempio, `MACH_MSG_TYPE_MAKE_SEND_ONCE` può essere utilizzato per **indicare** che un **diritto di invio una sola volta** deve essere derivato e trasferito per questa porta. È anche possibile specificare `MACH_PORT_NULL` per impedire al destinatario di poter rispondere.
|
||||
Per esempio, `MACH_MSG_TYPE_MAKE_SEND_ONCE` può essere utilizzato per **indicare** che un **diritto di invio una sola volta** dovrebbe essere derivato e trasferito per questa porta. Può anche essere specificato `MACH_PORT_NULL` per impedire al destinatario di poter rispondere.
|
||||
|
||||
Per ottenere una **comunicazione bidirezionale** semplice, un processo può specificare una **porta mach** nell'**intestazione del messaggio mach** chiamata _porta di risposta_ (**`msgh_local_port`**) dove il **ricevente** del messaggio può **inviare una risposta** a questo messaggio.
|
||||
Per ottenere una facile **comunicazione bidirezionale**, un processo può specificare una **porta mach** nell'**intestazione del messaggio mach** chiamata _porta di risposta_ (**`msgh_local_port`**) dove il **ricevente** del messaggio può **inviare una risposta** a questo messaggio.
|
||||
|
||||
{% hint style="success" %}
|
||||
Si noti che questo tipo di comunicazione bidirezionale è utilizzato nei messaggi XPC che si aspettano una risposta (`xpc_connection_send_message_with_reply` e `xpc_connection_send_message_with_reply_sync`). Ma **di solito vengono creati porti diversi** come spiegato in precedenza per creare la comunicazione bidirezionale.
|
||||
Nota che questo tipo di comunicazione bidirezionale è utilizzato nei messaggi XPC che si aspettano una risposta (`xpc_connection_send_message_with_reply` e `xpc_connection_send_message_with_reply_sync`). Ma **di solito vengono creati porti diversi** come spiegato in precedenza per creare la comunicazione bidirezionale.
|
||||
{% endhint %}
|
||||
|
||||
Gli altri campi dell'intestazione del messaggio sono:
|
||||
|
|
@ -133,10 +133,10 @@ Gli altri campi dell'intestazione del messaggio sono:
|
|||
- `msgh_size`: la dimensione dell'intero pacchetto.
|
||||
- `msgh_remote_port`: la porta su cui viene inviato questo messaggio.
|
||||
- `msgh_voucher_port`: [voucher mach](https://robert.sesek.com/2023/6/mach\_vouchers.html).
|
||||
- `msgh_id`: l'ID di questo messaggio, interpretato dal ricevente.
|
||||
- `msgh_id`: l'ID di questo messaggio, che viene interpretato dal ricevente.
|
||||
|
||||
{% hint style="danger" %}
|
||||
Si noti che i **messaggi mach vengono inviati su una `porta mach`**, che è un canale di comunicazione **singolo destinatario**, **multiplo mittente** integrato nel kernel mach. **Più processi** possono **inviare messaggi** a una porta mach, ma in qualsiasi momento solo **un singolo processo può leggere** da essa.
|
||||
Nota che **i messaggi mach vengono inviati su una `porta mach`**, che è un canale di comunicazione **singolo ricevente**, **multiplo mittente** integrato nel kernel mach. **Più processi** possono **inviare messaggi** a una porta mach, ma in qualsiasi momento solo **un singolo processo può leggere** da essa.
|
||||
{% endhint %}
|
||||
|
||||
I messaggi sono quindi formati dall'intestazione **`mach_msg_header_t`** seguita dal **corpo** e dal **trailer** (se presente) e possono concedere il permesso di rispondere ad esso. In questi casi, il kernel deve solo passare il messaggio da un task all'altro.
|
||||
|
|
@ -145,7 +145,7 @@ Un **trailer** è **un'informazione aggiunta al messaggio dal kernel** (non può
|
|||
|
||||
#### Messaggi Complessi
|
||||
|
||||
Tuttavia, ci sono altri messaggi più **complessi**, come quelli che passano diritti di porta aggiuntivi o condividono memoria, in cui il kernel deve anche inviare questi oggetti al destinatario. In questi casi, il bit più significativo dell'intestazione `msgh_bits` è impostato.
|
||||
Tuttavia, ci sono altri messaggi più **complessi**, come quelli che passano diritti di porta aggiuntivi o condividono memoria, dove il kernel deve anche inviare questi oggetti al destinatario. In questi casi il bit più significativo dell'intestazione `msgh_bits` è impostato.
|
||||
|
||||
I descrittori possibili da passare sono definiti in [**`mach/message.h`**](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html):
|
||||
```c
|
||||
|
|
@ -167,7 +167,7 @@ mach_msg_descriptor_type_t type : 8;
|
|||
In 32 bit, tutti i descrittori sono di 12B e il tipo di descrittore è nel 11°. In 64 bit, le dimensioni variano.
|
||||
|
||||
{% hint style="danger" %}
|
||||
Il kernel copierà i descrittori da un task all'altro ma prima **creerà una copia nella memoria del kernel**. Questa tecnica, nota come "Feng Shui", è stata abusata in diversi exploit per fare in modo che il **kernel copi i dati nella sua memoria** facendo sì che un processo invii descrittori a se stesso. Quindi il processo può ricevere i messaggi (il kernel li libererà).
|
||||
Il kernel copierà i descrittori da un task all'altro ma prima **creerà una copia nella memoria del kernel**. Questa tecnica, nota come "Feng Shui", è stata abusata in diversi exploit per fare in modo che il **kernel copi dati nella sua memoria** facendo sì che un processo invii descrittori a se stesso. Quindi il processo può ricevere i messaggi (il kernel li libererà).
|
||||
|
||||
È anche possibile **inviare diritti di porta a un processo vulnerabile**, e i diritti di porta appariranno semplicemente nel processo (anche se non li sta gestendo).
|
||||
{% endhint %}
|
||||
|
|
@ -177,7 +177,7 @@ Il kernel copierà i descrittori da un task all'altro ma prima **creerà una cop
|
|||
Nota che le porte sono associate allo spazio dei nomi del task, quindi per creare o cercare una porta, viene anche interrogato lo spazio dei nomi del task (più in `mach/mach_port.h`):
|
||||
|
||||
* **`mach_port_allocate` | `mach_port_construct`**: **Crea** una porta.
|
||||
* `mach_port_allocate` può anche creare un **insieme di porte**: diritto di ricezione su un gruppo di porte. Ogni volta che viene ricevuto un messaggio, viene indicata la porta da cui è stato inviato.
|
||||
* `mach_port_allocate` può anche creare un **insieme di porte**: diritto di ricezione su un gruppo di porte. Ogni volta che viene ricevuto un messaggio, viene indicata la porta da cui proviene.
|
||||
* `mach_port_allocate_name`: Cambia il nome della porta (di default un intero a 32 bit)
|
||||
* `mach_port_names`: Ottieni i nomi delle porte da un target
|
||||
* `mach_port_type`: Ottieni i diritti di un task su un nome
|
||||
|
|
@ -187,7 +187,7 @@ Nota che le porte sono associate allo spazio dei nomi del task, quindi per crear
|
|||
* `mach_port_...`
|
||||
* **`mach_msg`** | **`mach_msg_overwrite`**: Funzioni utilizzate per **inviare e ricevere messaggi mach**. La versione overwrite consente di specificare un buffer diverso per la ricezione del messaggio (l'altra versione lo riutilizzerà).
|
||||
|
||||
### Debug di mach\_msg
|
||||
### Debug mach\_msg
|
||||
|
||||
Poiché le funzioni **`mach_msg`** e **`mach_msg_overwrite`** sono quelle utilizzate per inviare e ricevere messaggi, impostare un breakpoint su di esse consentirebbe di ispezionare i messaggi inviati e ricevuti.
|
||||
|
||||
|
|
@ -284,9 +284,9 @@ name ipc-object rights flags boost reqs recv send sonce oref q
|
|||
+ send -------- --- 1 <- 0x00002603 (74295) passd
|
||||
[...]
|
||||
```
|
||||
Il **nome** è il nome predefinito assegnato alla porta (controlla come sta **aumentando** nei primi 3 byte). L'**`ipc-object`** è l'**identificatore** univoco **oscurato** della porta.\
|
||||
Il **nome** è il nome predefinito assegnato alla porta (controlla come sta **aumentando** nei primi 3 byte). L'**`ipc-object`** è l'**identificatore** univoco **offuscato** della porta.\
|
||||
Nota anche come le porte con solo il diritto di **`send`** stanno **identificando il proprietario** di essa (nome della porta + pid).\
|
||||
Nota anche l'uso di **`+`** per indicare **altri task connessi alla stessa porta**.
|
||||
Nota anche l'uso del **`+`** per indicare **altri task connessi alla stessa porta**.
|
||||
|
||||
È anche possibile utilizzare [**procesxp**](https://www.newosxbook.com/tools/procexp.html) per vedere anche i **nomi dei servizi registrati** (con SIP disabilitato a causa della necessità di `com.apple.system-task-port`):
|
||||
```
|
||||
|
|
@ -367,7 +367,16 @@ printf("Text: %s, number: %d\n", message.some_text, message.some_number);
|
|||
```
|
||||
{% endtab %}
|
||||
|
||||
{% tab title="sender.c" %}
|
||||
{% tab title="sender.c" %}Traduttore:
|
||||
|
||||
Inter Process Communication (IPC) è un meccanismo che consente a due processi di comunicare tra loro e scambiare dati. In macOS, IPC può essere utilizzato per scopi legittimi, ma può anche essere sfruttato da attaccanti per ottenere privilegi elevati o compromettere il sistema. Alcuni metodi comuni di IPC includono le code di messaggi, le code di notifica, le pipe e i socket.
|
||||
|
||||
Per proteggere un sistema macOS da abusi di processo tramite IPC, è importante implementare le seguenti misure di sicurezza:
|
||||
- Limitare i privilegi dei processi utilizzando le autorizzazioni corrette.
|
||||
- Validare e sanificare i dati scambiati tramite IPC per prevenire attacchi di tipo injection.
|
||||
- Monitorare e registrare le attività IPC sospette per individuare potenziali tentativi di compromissione del sistema.
|
||||
|
||||
Implementando queste pratiche di sicurezza, è possibile ridurre significativamente il rischio di abusi di processo tramite IPC su macOS.{% endtab %}
|
||||
```c
|
||||
// Code from https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html
|
||||
// gcc sender.c -o sender
|
||||
|
|
@ -422,26 +431,84 @@ printf("Sent a message\n");
|
|||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
### Porte privilegiate
|
||||
## Porte privilegiate
|
||||
|
||||
* **Porta host**: Se un processo ha il privilegio di **Invio** su questa porta può ottenere **informazioni** sul **sistema** (ad esempio `host_processor_info`).
|
||||
* **Porta host priv**: Un processo con il diritto di **Invio** su questa porta può eseguire **azioni privilegiate** come caricare un'estensione del kernel. Il **processo deve essere root** per ottenere questo permesso.
|
||||
* Inoltre, per chiamare l'API **`kext_request`** è necessario avere altri diritti **`com.apple.private.kext*`** che vengono concessi solo ai binari Apple.
|
||||
* **Porta nome attività**: Una versione non privilegiata della _porta attività_. Fa riferimento all'attività, ma non consente di controllarla. L'unica cosa che sembra essere disponibile tramite di essa è `task_info()`.
|
||||
* **Porta attività** (alias porta kernel)**:** Con il permesso di Invio su questa porta è possibile controllare l'attività (leggere/scrivere memoria, creare thread...).
|
||||
* Chiamare `mach_task_self()` per **ottenere il nome** di questa porta per l'attività chiamante. Questa porta viene ereditata solo attraverso **`exec()`**; una nuova attività creata con `fork()` ottiene una nuova porta attività (come caso speciale, un'attività ottiene anche una nuova porta attività dopo `exec()` in un binario suid). L'unico modo per generare un'attività e ottenere la sua porta è eseguire la ["danza dello scambio di porte"](https://robert.sesek.com/2014/1/changes\_to\_xnu\_mach\_ipc.html) durante un `fork()`.
|
||||
Ci sono alcune porte speciali che permettono di **eseguire determinate azioni sensibili o accedere a determinati dati sensibili** nel caso in cui un compito abbia i permessi **SEND** su di esse. Questo rende queste porte molto interessanti dal punto di vista degli attaccanti non solo per le capacità ma anche perché è possibile **condividere i permessi SEND tra i compiti**.
|
||||
|
||||
### Porte speciali dell'host
|
||||
|
||||
Queste porte sono rappresentate da un numero.
|
||||
|
||||
I diritti **SEND** possono essere ottenuti chiamando **`host_get_special_port`** e i diritti **RECEIVE** chiamando **`host_set_special_port`**. Tuttavia, entrambe le chiamate richiedono la porta **`host_priv`** a cui solo l'utente root può accedere. Inoltre, in passato l'utente root poteva chiamare **`host_set_special_port`** e dirottare arbitrariamente ciò che permetteva ad esempio di eludere le firme del codice dirottando `HOST_KEXTD_PORT` (SIP ora impedisce ciò).
|
||||
|
||||
Queste sono divise in 2 gruppi: I **primi 7 porte sono di proprietà del kernel** essendo il 1 `HOST_PORT`, il 2 `HOST_PRIV_PORT`, il 3 `HOST_IO_MASTER_PORT` e il 7 è `HOST_MAX_SPECIAL_KERNEL_PORT`.\
|
||||
Quelle che iniziano **dal** numero **8** sono **di proprietà dei daemon di sistema** e possono essere trovate dichiarate in [**`host_special_ports.h`**](https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/mach/host\_special\_ports.h.auto.html).
|
||||
|
||||
* **Porta host**: Se un processo ha il privilegio **SEND** su questa porta può ottenere **informazioni** sul **sistema** chiamando le sue routine come:
|
||||
* `host_processor_info`: Ottenere informazioni sul processore
|
||||
* `host_info`: Ottenere informazioni sull'host
|
||||
* `host_virtual_physical_table_info`: Tabella delle pagine virtuali/fisiche (richiede MACH\_VMDEBUG)
|
||||
* `host_statistics`: Ottenere statistiche sull'host
|
||||
* `mach_memory_info`: Ottenere la struttura della memoria del kernel
|
||||
* **Porta host Priv**: Un processo con il diritto **SEND** su questa porta può eseguire **azioni privilegiate** come mostrare i dati di avvio o provare a caricare un'estensione del kernel. Il **processo deve essere root** per ottenere questo permesso.
|
||||
* Inoltre, per chiamare l'API **`kext_request`** sono necessari altri entitlement **`com.apple.private.kext*`** che vengono dati solo ai binari Apple.
|
||||
* Altre routine che possono essere chiamate sono:
|
||||
* `host_get_boot_info`: Ottenere `machine_boot_info()`
|
||||
* `host_priv_statistics`: Ottenere statistiche privilegiate
|
||||
* `vm_allocate_cpm`: Allocare memoria fisica contigua
|
||||
* `host_processors`: Invio del diritto ai processori dell'host
|
||||
* `mach_vm_wire`: Rendere residente la memoria
|
||||
* Poiché **root** può accedere a questo permesso, potrebbe chiamare `host_set_[special/exception]_port[s]` per **dirottare le porte speciali o di eccezione dell'host**.
|
||||
|
||||
È possibile **vedere tutte le porte speciali dell'host** eseguendo:
|
||||
```bash
|
||||
procexp all ports | grep "HSP"
|
||||
```
|
||||
### Porte delle attività
|
||||
|
||||
Originariamente Mach non aveva "processi" ma aveva "task" che venivano considerati più come contenitori di thread. Quando Mach è stato unito a BSD **ogni task era correlato a un processo BSD**. Pertanto ogni processo BSD ha i dettagli necessari per essere un processo e ogni task Mach ha anche le sue operazioni interne (eccetto per il pid inesistente 0 che è il `kernel_task`).
|
||||
|
||||
Ci sono due funzioni molto interessanti correlate a questo:
|
||||
|
||||
* `task_for_pid(target_task_port, pid, &task_port_of_pid)`: Ottieni un diritto SEND per la porta del task del task correlato al pid specificato e assegnalo al `target_task_port` indicato (che di solito è il task chiamante che ha usato `mach_task_self()`, ma potrebbe essere una porta SEND su un task diverso).
|
||||
* `pid_for_task(task, &pid)`: Dato un diritto SEND a un task, trova a quale PID è correlato questo task.
|
||||
|
||||
Per eseguire azioni all'interno del task, il task aveva bisogno di un diritto `SEND` a se stesso chiamando `mach_task_self()` (che utilizza il `task_self_trap` (28)). Con questa autorizzazione un task può eseguire diverse azioni come:
|
||||
|
||||
* `task_threads`: Ottenere un diritto SEND su tutte le porte dei task dei thread del task
|
||||
* `task_info`: Ottenere informazioni su un task
|
||||
* `task_suspend/resume`: Sospendere o riprendere un task
|
||||
* `task_[get/set]_special_port`
|
||||
* `thread_create`: Creare un thread
|
||||
* `task_[get/set]_state`: Controllare lo stato del task
|
||||
* e altro può essere trovato in [**mach/task.h**](https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX11.3.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/mach/task.h)
|
||||
|
||||
{% hint style="danger" %}
|
||||
Nota che con un diritto SEND su una porta del task di un **task diverso**, è possibile eseguire tali azioni su un task diverso.
|
||||
{% endhint %}
|
||||
|
||||
Inoltre, la porta del task è anche la porta **`vm_map`** che consente di **leggere e manipolare la memoria** all'interno di un task con funzioni come `vm_read()` e `vm_write()`. Questo significa fondamentalmente che un task con diritti SEND sulla porta del task di un task diverso sarà in grado di **iniettare codice in quel task**.
|
||||
|
||||
Ricorda che poiché il **kernel è anche un task**, se qualcuno riesce a ottenere **permessi SEND** sul **`kernel_task`**, sarà in grado di far eseguire al kernel qualsiasi cosa (jailbreak).
|
||||
|
||||
* Chiama `mach_task_self()` per **ottenere il nome** di questa porta per il task chiamante. Questa porta viene ereditata solo attraverso **`exec()`**; un nuovo task creato con `fork()` ottiene una nuova porta del task (come caso speciale, un task ottiene anche una nuova porta del task dopo `exec()` in un binario suid). L'unico modo per generare un task e ottenere la sua porta è eseguire la ["port swap dance"](https://robert.sesek.com/2014/1/changes\_to\_xnu\_mach\_ipc.html) durante un `fork()`.
|
||||
* Queste sono le restrizioni per accedere alla porta (da `macos_task_policy` dal binario `AppleMobileFileIntegrity`):
|
||||
* Se l'app ha il diritto **`com.apple.security.get-task-allow`** i processi dello **stesso utente possono accedere alla porta attività** (comunemente aggiunto da Xcode per il debug). Il processo di **notarizzazione** non lo permetterà per i rilasci in produzione.
|
||||
* Le app con il diritto **`com.apple.system-task-ports`** possono ottenere la **porta attività per qualsiasi** processo, tranne il kernel. Nelle versioni precedenti era chiamato **`task_for_pid-allow`**. Questo è concesso solo alle applicazioni Apple.
|
||||
* **Root può accedere alle porte attività** delle applicazioni **non** compilati con un **ambiente di esecuzione protetto** (e non di Apple).
|
||||
* Se l'app ha il **permesso `com.apple.security.get-task-allow`** i processi dello **stesso utente possono accedere alla porta del task** (comunemente aggiunto da Xcode per il debug). Il processo di **notarizzazione** non lo permetterà per i rilasci in produzione.
|
||||
* Le app con il permesso **`com.apple.system-task-ports`** possono ottenere la **porta del task per qualsiasi** processo, tranne il kernel. Nelle versioni precedenti era chiamato **`task_for_pid-allow`**. Questo è concesso solo alle applicazioni Apple.
|
||||
* **Root può accedere alle porte dei task** delle applicazioni **non** compilati con un **ambiente di esecuzione protetto** (e non da Apple).
|
||||
|
||||
### Iniezione di shellcode nel thread tramite porta attività
|
||||
**La porta del nome del task:** Una versione non privilegiata della _porta del task_. Fa riferimento al task, ma non consente di controllarlo. L'unica cosa che sembra essere disponibile attraverso di essa è `task_info()`.
|
||||
|
||||
È possibile ottenere un shellcode da:
|
||||
### Iniezione di shellcode nel thread tramite la porta del task
|
||||
|
||||
Puoi ottenere un shellcode da:
|
||||
|
||||
{% content-ref url="../../macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md" %}
|
||||
[arm64-basic-assembly.md](../../macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="mysleep.m" %}
|
||||
```objectivec
|
||||
// clang -framework Foundation mysleep.m -o mysleep
|
||||
// codesign --entitlements entitlements.plist -s - mysleep
|
||||
|
|
@ -493,6 +560,9 @@ return 0;
|
|||
<summary>sc_injector.m</summary>
|
||||
```objectivec
|
||||
// gcc -framework Foundation -framework Appkit sc_injector.m -o sc_injector
|
||||
// Based on https://gist.github.com/knightsc/45edfc4903a9d2fa9f5905f60b02ce5a?permalink_comment_id=2981669
|
||||
// and on https://newosxbook.com/src.jl?tree=listings&file=inject.c
|
||||
|
||||
|
||||
#import <Foundation/Foundation.h>
|
||||
#import <AppKit/AppKit.h>
|
||||
|
|
@ -692,15 +762,19 @@ return 0;
|
|||
gcc -framework Foundation -framework Appkit sc_inject.m -o sc_inject
|
||||
./inject <pi or string>
|
||||
```
|
||||
{% hint style="success" %}
|
||||
Per far funzionare questo su iOS è necessario il permesso `dynamic-codesigning` per poter rendere eseguibile una memoria scrivibile.
|
||||
{% endhint %}
|
||||
|
||||
### Iniezione di Dylib nel thread tramite porta Task
|
||||
|
||||
In macOS i **thread** possono essere manipolati tramite **Mach** o utilizzando **l'API posix `pthread`**. Il thread generato nell'iniezione precedente è stato generato utilizzando l'API Mach, quindi **non è conforme a posix**.
|
||||
In macOS **i thread** possono essere manipolati tramite **Mach** o utilizzando **l'API posix `pthread`**. Il thread generato nell'iniezione precedente è stato generato utilizzando l'API Mach, quindi **non è conforme a posix**.
|
||||
|
||||
È stato possibile **iniettare un semplice shellcode** per eseguire un comando perché **non era necessario lavorare con API conformi a posix**, solo con Mach. **Iniezioni più complesse** avrebbero bisogno che il **thread** sia anche **conforme a posix**.
|
||||
È stato possibile **iniettare un semplice shellcode** per eseguire un comando perché **non era necessario lavorare con le API conformi a posix**, solo con Mach. **Iniezioni più complesse** avrebbero bisogno che il **thread** sia anche **conforme a posix**.
|
||||
|
||||
Pertanto, per **migliorare il thread**, dovrebbe chiamare **`pthread_create_from_mach_thread`** che creerà un pthread valido. Quindi, questo nuovo pthread potrebbe **chiamare dlopen** per **caricare una dylib** dal sistema, quindi anziché scrivere nuovo shellcode per eseguire azioni diverse, è possibile caricare librerie personalizzate.
|
||||
Pertanto, per **migliorare il thread** dovrebbe chiamare **`pthread_create_from_mach_thread`** che creerà un pthread valido. Quindi, questo nuovo pthread potrebbe **chiamare dlopen** per **caricare una dylib** dal sistema, quindi anziché scrivere nuovo shellcode per eseguire azioni diverse è possibile caricare librerie personalizzate.
|
||||
|
||||
Puoi trovare **esempi di dylibs** in (ad esempio quello che genera un log e poi puoi ascoltarlo):
|
||||
Puoi trovare **esempi di dylibs** in (ad esempio quella che genera un log e poi puoi ascoltarlo):
|
||||
|
||||
{% content-ref url="../macos-library-injection/macos-dyld-hijacking-and-dyld_insert_libraries.md" %}
|
||||
[macos-dyld-hijacking-and-dyld\_insert\_libraries.md](../macos-library-injection/macos-dyld-hijacking-and-dyld\_insert_libraries.md)
|
||||
|
|
@ -949,7 +1023,7 @@ kr = thread_create_running(remoteTask, ARM_THREAD_STATE64, // ARM_THREAD_STATE64
|
|||
(thread_state_t) &remoteThreadState64.ts_64, ARM_THREAD_STATE64_COUNT , &remoteThread );
|
||||
|
||||
if (kr != KERN_SUCCESS) {
|
||||
fprintf(stderr,"Impossibile creare un thread remoto: errore %s", mach_error_string (kr));
|
||||
fprintf(stderr,"Impossibile creare il thread remoto: errore %s", mach_error_string (kr));
|
||||
return (-3);
|
||||
}
|
||||
|
||||
|
|
@ -997,7 +1071,7 @@ In questa tecnica viene dirottato un thread del processo:
|
|||
|
||||
### Informazioni di base
|
||||
|
||||
XPC, acronimo di XNU (il kernel utilizzato da macOS) Inter-Process Communication, è un framework per la **comunicazione tra processi** su macOS e iOS. XPC fornisce un meccanismo per effettuare **chiamate di metodo sicure e asincrone tra processi diversi** sul sistema. Fa parte del paradigma di sicurezza di Apple, consentendo la **creazione di applicazioni con privilegi separati** in cui ogni **componente** viene eseguito con **solo i permessi necessari** per svolgere il proprio lavoro, limitando così i danni potenziali da un processo compromesso.
|
||||
XPC, che sta per XNU (il kernel utilizzato da macOS) Inter-Process Communication, è un framework per la **comunicazione tra processi** su macOS e iOS. XPC fornisce un meccanismo per effettuare **chiamate di metodo sicure e asincrone tra processi diversi** sul sistema. Fa parte del paradigma di sicurezza di Apple, consentendo la **creazione di applicazioni con privilegi separati** in cui ogni **componente** viene eseguito con **solo i permessi necessari** per svolgere il proprio lavoro, limitando così i danni potenziali da un processo compromesso.
|
||||
|
||||
Per ulteriori informazioni su come questa **comunicazione funziona** e su come **potrebbe essere vulnerabile**, controlla:
|
||||
|
||||
|
|
@ -1009,7 +1083,7 @@ Per ulteriori informazioni su come questa **comunicazione funziona** e su come *
|
|||
|
||||
MIG è stato creato per **semplificare il processo di creazione del codice Mach IPC**. Ciò è dovuto al fatto che gran parte del lavoro per programmare RPC coinvolge le stesse azioni (imballaggio degli argomenti, invio del messaggio, disimballaggio dei dati nel server...).
|
||||
|
||||
MIC genera **il codice necessario** affinché server e client possano comunicare con una definizione data (in IDL -Linguaggio di Definizione dell'Interfaccia-). Anche se il codice generato è brutto, uno sviluppatore dovrà solo importarlo e il suo codice sarà molto più semplice rispetto a prima.
|
||||
MIC genera **il codice necessario** per far comunicare server e client con una definizione data (in IDL -Linguaggio di Definizione dell'Interfaccia-). Anche se il codice generato è brutto, uno sviluppatore dovrà solo importarlo e il suo codice sarà molto più semplice rispetto a prima.
|
||||
|
||||
Per ulteriori informazioni, controlla:
|
||||
|
||||
|
|
@ -1028,13 +1102,13 @@ Per ulteriori informazioni, controlla:
|
|||
|
||||
<details>
|
||||
|
||||
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Impara l'hacking AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Altri modi per supportare HackTricks:
|
||||
|
||||
* Se desideri vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
|
||||
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
|
||||
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue