mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-22 04:33:28 +00:00
Translated ['macos-hardening/macos-security-and-privilege-escalation/mac
This commit is contained in:
Translator
parent
736f238176
commit
c4ba241f0e
3 changed files with 255 additions and 65 deletions
|
|
@ -159,7 +159,7 @@
|
|||
* [macOS Universal binaries & Mach-O Format](macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md)
|
||||
* [macOS Objective-C](macos-hardening/macos-security-and-privilege-escalation/macos-basic-objective-c.md)
|
||||
* [macOS Privilege Escalation](macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md)
|
||||
* [macOS Proces Abuse](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/README.md)
|
||||
* [macOS Process Abuse](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/README.md)
|
||||
* [macOS Dirty NIB](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md)
|
||||
* [macOS Chromium Injection](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-chromium-injection.md)
|
||||
* [macOS Electron Applications Injection](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-electron-applications-injection.md)
|
||||
|
|
|
|||
|
|
@ -2,37 +2,102 @@
|
|||
|
||||
<details>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
||||
Altri modi per supportare HackTricks:
|
||||
|
||||
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PACCHETTI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* 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 [**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.
|
||||
* 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.
|
||||
|
||||
</details>
|
||||
|
||||
## Informazioni di base
|
||||
|
||||
**Grand Central Dispatch (GCD)**, noto anche come **libdispatch**, è disponibile sia su macOS che su iOS. È una tecnologia sviluppata da Apple per ottimizzare il supporto delle applicazioni per l'esecuzione concorrente (multithreaded) su hardware multicore.
|
||||
**Grand Central Dispatch (GCD),** noto anche come **libdispatch** (`libdispatch.dyld`), è disponibile sia su macOS che su iOS. È una tecnologia sviluppata da Apple per ottimizzare il supporto dell'applicazione per l'esecuzione concorrente (multithread) sull'hardware multicore.
|
||||
|
||||
**GCD** fornisce e gestisce **code FIFO** a cui la tua applicazione può **inviare attività** sotto forma di **oggetti block**. I blocchi inviati alle code di invio vengono **eseguiti su un pool di thread** completamente gestito dal sistema. GCD crea automaticamente thread per eseguire le attività nelle code di invio e pianifica l'esecuzione di tali attività sui core disponibili.
|
||||
|
||||
{% hint style="success" %}
|
||||
In sintesi, per eseguire codice in **parallelo**, i processi possono inviare **blocchi di codice a GCD**, che si occuperà della loro esecuzione. Pertanto, i processi non creano nuovi thread; **GCD esegue il codice fornito con il proprio pool di thread**.
|
||||
In sintesi, per eseguire codice in **parallelo**, i processi possono inviare **blocchi di codice a GCD**, che si occuperà della loro esecuzione. Pertanto, i processi non creano nuovi thread; **GCD esegue il codice fornito con il proprio pool di thread** (che potrebbe aumentare o diminuire secondo necessità).
|
||||
{% endhint %}
|
||||
|
||||
Ciò è molto utile per gestire con successo l'esecuzione parallela, riducendo notevolmente il numero di thread creati dai processi e ottimizzando l'esecuzione parallela. Questo è ideale per attività che richiedono **un grande parallelismo** (brute-forcing?) o per attività che non dovrebbero bloccare il thread principale: ad esempio, il thread principale su iOS gestisce le interazioni dell'interfaccia utente, quindi qualsiasi altra funzionalità che potrebbe far bloccare l'applicazione (ricerca, accesso a un sito web, lettura di un file...) viene gestita in questo modo.
|
||||
Questo è molto utile per gestire con successo l'esecuzione parallela, riducendo notevolmente il numero di thread creati dai processi e ottimizzando l'esecuzione parallela. Questo è ideale per attività che richiedono **grande parallelismo** (forza bruta?) o per attività che non dovrebbero bloccare il thread principale: ad esempio, il thread principale su iOS gestisce le interazioni dell'interfaccia utente, quindi qualsiasi altra funzionalità che potrebbe far bloccare l'applicazione (ricerca, accesso a un sito web, lettura di un file...) è gestita in questo modo.
|
||||
|
||||
### Blocchi
|
||||
|
||||
Un blocco è una **sezione di codice autocontenuta** (come una funzione con argomenti che restituisce un valore) e può anche specificare variabili vincolate.\
|
||||
Tuttavia, a livello di compilatore i blocchi non esistono, sono `os_object`. Ciascuno di questi oggetti è formato da due strutture:
|
||||
|
||||
* **letterale del blocco**: 
|
||||
* Inizia con il campo **`isa`**, che punta alla classe del blocco:
|
||||
* `NSConcreteGlobalBlock` (blocchi da `__DATA.__const`)
|
||||
* `NSConcreteMallocBlock` (blocchi nello heap)
|
||||
* `NSConcreateStackBlock` (blocchi nello stack)
|
||||
* Ha **`flags`** (che indicano i campi presenti nel descrittore del blocco) e alcuni byte riservati
|
||||
* Il puntatore alla funzione da chiamare
|
||||
* Un puntatore al descrittore del blocco
|
||||
* Variabili importate dal blocco (se presenti)
|
||||
* **descrittore del blocco**: La sua dimensione dipende dai dati presenti (come indicato nei flag precedenti)
|
||||
* Ha alcuni byte riservati
|
||||
* La sua dimensione
|
||||
* Di solito avrà un puntatore a una firma in stile Objective-C per sapere di quanto spazio è necessario per i parametri (flag `BLOCK_HAS_SIGNATURE`)
|
||||
* Se le variabili sono referenziate, questo blocco avrà anche puntatori a un aiutante di copia (che copia il valore all'inizio) e a un aiutante di smaltimento (liberandolo).
|
||||
|
||||
### Code di invio
|
||||
|
||||
Una coda di invio è un oggetto nominato che fornisce l'ordinamento FIFO dei blocchi per le esecuzioni.
|
||||
|
||||
I blocchi sono impostati nelle code da eseguire e queste supportano 2 modalità: `DISPATCH_QUEUE_SERIAL` e `DISPATCH_QUEUE_CONCURRENT`. Naturalmente il **seriale** non avrà problemi di condizione di gara poiché un blocco non verrà eseguito fino a quando il precedente non sarà terminato. Ma **l'altro tipo di coda potrebbe averlo**.
|
||||
|
||||
Code predefinite:
|
||||
|
||||
* `.main-thread`: Da `dispatch_get_main_queue()`
|
||||
* `.libdispatch-manager`: Gestore delle code di GCD
|
||||
* `.root.libdispatch-manager`: Gestore delle code di GCD
|
||||
* `.root.maintenance-qos`: Compiti a priorità più bassa
|
||||
* `.root.maintenance-qos.overcommit`
|
||||
* `.root.background-qos`: Disponibile come `DISPATCH_QUEUE_PRIORITY_BACKGROUND`
|
||||
* `.root.background-qos.overcommit`
|
||||
* `.root.utility-qos`: Disponibile come `DISPATCH_QUEUE_PRIORITY_NON_INTERACTIVE`
|
||||
* `.root.utility-qos.overcommit`
|
||||
* `.root.default-qos`: Disponibile come `DISPATCH_QUEUE_PRIORITY_DEFAULT`
|
||||
* `.root.background-qos.overcommit`
|
||||
* `.root.user-initiated-qos`: Disponibile come `DISPATCH_QUEUE_PRIORITY_HIGH`
|
||||
* `.root.background-qos.overcommit`
|
||||
* `.root.user-interactive-qos`: Priorità più alta
|
||||
* `.root.background-qos.overcommit`
|
||||
|
||||
Nota che sarà il sistema a decidere **quali thread gestiscono quali code in ogni momento** (più thread potrebbero lavorare nella stessa coda o lo stesso thread potrebbe lavorare in code diverse in un certo momento)
|
||||
|
||||
#### Attributi
|
||||
|
||||
Quando si crea una coda con **`dispatch_queue_create`** il terzo argomento è un `dispatch_queue_attr_t`, che di solito è o `DISPATCH_QUEUE_SERIAL` (che in realtà è NULL) o `DISPATCH_QUEUE_CONCURRENT` che è un puntatore a una struttura `dispatch_queue_attr_t` che consente di controllare alcuni parametri della coda.
|
||||
|
||||
### Oggetti di invio
|
||||
|
||||
Ci sono diversi oggetti che libdispatch utilizza e code e blocchi sono solo 2 di essi. È possibile creare questi oggetti con `dispatch_object_create`:
|
||||
|
||||
* `blocco`
|
||||
* `dati`: Blocchi di dati
|
||||
* `gruppo`: Gruppo di blocchi
|
||||
* `io`: Richieste di I/O asincrone
|
||||
* `mach`: Porte Mach
|
||||
* `mach_msg`: Messaggi Mach
|
||||
* `pthread_root_queue`: Una coda con un pool di thread pthread e senza code di lavoro
|
||||
* `coda`
|
||||
* `semaforo`
|
||||
* `sorgente`: Sorgente di eventi
|
||||
|
||||
## Objective-C
|
||||
|
||||
In Objective-C ci sono diverse funzioni per inviare un blocco da eseguire in parallelo:
|
||||
|
||||
* [**dispatch\_async**](https://developer.apple.com/documentation/dispatch/1453057-dispatch\_async): Invia un blocco per l'esecuzione asincrona su una coda di invio e restituisce immediatamente.
|
||||
* [**dispatch\_sync**](https://developer.apple.com/documentation/dispatch/1452870-dispatch\_sync): Invia un oggetto blocco per l'esecuzione e restituisce dopo che il blocco ha finito di eseguire.
|
||||
* [**dispatch\_once**](https://developer.apple.com/documentation/dispatch/1447169-dispatch\_once): Esegue un oggetto blocco solo una volta per tutta la durata di un'applicazione.
|
||||
* [**dispatch\_sync**](https://developer.apple.com/documentation/dispatch/1452870-dispatch\_sync): Invia un oggetto blocco per l'esecuzione e restituisce dopo che quel blocco ha finito di eseguire.
|
||||
* [**dispatch\_once**](https://developer.apple.com/documentation/dispatch/1447169-dispatch\_once): Esegue un blocco solo una volta per tutta la durata di un'applicazione.
|
||||
* [**dispatch\_async\_and\_wait**](https://developer.apple.com/documentation/dispatch/3191901-dispatch\_async\_and\_wait): Invia un elemento di lavoro per l'esecuzione e restituisce solo dopo che ha finito di eseguire. A differenza di [**`dispatch_sync`**](https://developer.apple.com/documentation/dispatch/1452870-dispatch\_sync), questa funzione rispetta tutti gli attributi della coda quando esegue il blocco.
|
||||
|
||||
Queste funzioni si aspettano questi parametri: [**`dispatch_queue_t`**](https://developer.apple.com/documentation/dispatch/dispatch\_queue\_t) **`queue,`** [**`dispatch_block_t`**](https://developer.apple.com/documentation/dispatch/dispatch\_block\_t) **`block`**
|
||||
|
|
@ -48,7 +113,7 @@ struct BlockDescriptor *descriptor;
|
|||
// captured variables go here
|
||||
};
|
||||
```
|
||||
E questo è un esempio di utilizzo del **parallelismo** con **`dispatch_async`**:
|
||||
E questo è un esempio per utilizzare **il parallelismo** con **`dispatch_async`**:
|
||||
```objectivec
|
||||
#import <Foundation/Foundation.h>
|
||||
|
||||
|
|
@ -80,8 +145,8 @@ return 0;
|
|||
```
|
||||
## Swift
|
||||
|
||||
**`libswiftDispatch`** è una libreria che fornisce **binding Swift** al framework Grand Central Dispatch (GCD) che è originariamente scritto in C.\
|
||||
La libreria **`libswiftDispatch`** incapsula le API C GCD in un'interfaccia più amichevole per Swift, rendendo più facile e intuitivo per gli sviluppatori Swift lavorare con GCD.
|
||||
**`libswiftDispatch`** è una libreria che fornisce **binding Swift** al framework Grand Central Dispatch (GCD) originariamente scritto in C.\
|
||||
La libreria **`libswiftDispatch`** incapsula le API C GCD in un'interfaccia più amichevole per Swift, rendendo più semplice e intuitivo per gli sviluppatori Swift lavorare con GCD.
|
||||
|
||||
* **`DispatchQueue.global().sync{ ... }`**
|
||||
* **`DispatchQueue.global().async{ ... }`**
|
||||
|
|
@ -118,7 +183,7 @@ sleep(1) // Simulate a long-running task
|
|||
```
|
||||
## Frida
|
||||
|
||||
Il seguente script di Frida può essere utilizzato per **intercettare diverse funzioni `dispatch`** ed estrarre il nome della coda, la traccia di esecuzione e il blocco: [**https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js**](https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js)
|
||||
Il seguente script Frida può essere utilizzato per **agganciarsi a diverse funzioni `dispatch`** ed estrarre il nome della coda, la traccia dello stack e il blocco: [**https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js**](https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js)
|
||||
```bash
|
||||
frida -U <prog_name> -l libdispatch.js
|
||||
|
||||
|
|
@ -135,40 +200,30 @@ Backtrace:
|
|||
|
||||
Attualmente Ghidra non comprende né la struttura **`dispatch_block_t`** di ObjectiveC, né quella di **`swift_dispatch_block`**.
|
||||
|
||||
Quindi, se vuoi farlo capire, puoi semplicemente **dichiararle**:
|
||||
Quindi, se vuoi che le comprenda, puoi semplicemente **dichiararle**:
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (688).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
<figure><img src="../../.gitbook/assets/image (1157).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (690).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
<figure><img src="../../.gitbook/assets/image (1159).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (691).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
<figure><img src="../../.gitbook/assets/image (1160).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
Successivamente, trova un punto nel codice in cui vengono **utilizzate**:
|
||||
|
||||
{% hint style="success" %}
|
||||
Nota tutti i riferimenti al "block" per capire come puoi individuare l'utilizzo della struttura.
|
||||
Nota tutti i riferimenti al "block" per capire come potresti individuare che la struttura viene utilizzata.
|
||||
{% endhint %}
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (692).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
<figure><img src="../../.gitbook/assets/image (1161).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
Fai clic con il pulsante destro del mouse sulla variabile -> Retype Variable e seleziona in questo caso **`swift_dispatch_block`**:
|
||||
Fai clic destro sulla variabile -> Ridichiara la variabile e seleziona in questo caso **`swift_dispatch_block`**:
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (693).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
<figure><img src="../../.gitbook/assets/image (1162).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
Ghidra riscriverà automaticamente tutto:
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (694).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
<figure><img src="../../.gitbook/assets/image (1163).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
<details>
|
||||
## References
|
||||
|
||||
<summary><strong>Impara l'hacking di AWS da zero a esperto 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**, consulta i [**PACCHETTI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
||||
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](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 ai repository GitHub di** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
* [**\*OS Internals, Volume I: User Mode. Di Jonathan Levin**](https://www.amazon.com/MacOS-iOS-Internals-User-Mode/dp/099105556X)
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# macOS Proces Abuse
|
||||
# Abuso dei Processi su macOS
|
||||
|
||||
<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 su 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>
|
||||
|
||||
Altri modi per supportare HackTricks:
|
||||
|
||||
|
|
@ -14,13 +14,151 @@ Altri modi per supportare HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
## Abuso dei processi su macOS
|
||||
## Informazioni di Base sui Processi
|
||||
|
||||
macOS, come qualsiasi altro sistema operativo, fornisce una varietà di metodi e meccanismi per **processi per interagire, comunicare e condividere dati**. Sebbene queste tecniche siano essenziali per il corretto funzionamento del sistema, possono anche essere abusate da attori minacciosi per **eseguire attività dannose**.
|
||||
Un processo è un'istanza di un eseguibile in esecuzione, tuttavia i processi non eseguono codice, questi sono thread. Quindi **i processi sono solo contenitori per l'esecuzione dei thread** fornendo la memoria, i descrittori, le porte, le autorizzazioni...
|
||||
|
||||
Tradizionalmente, i processi venivano avviati all'interno di altri processi (tranne il PID 1) chiamando **`fork`** che avrebbe creato una copia esatta del processo corrente e poi il **processo figlio** avrebbe generalmente chiamato **`execve`** per caricare il nuovo eseguibile ed eseguirlo. Successivamente è stato introdotto **`vfork`** per rendere questo processo più veloce senza alcuna copia di memoria.\
|
||||
Successivamente è stata introdotta **`posix_spawn`** che combina **`vfork`** e **`execve`** in una chiamata e accetta flag:
|
||||
|
||||
* `POSIX_SPAWN_RESETIDS`: Reimposta gli id effettivi agli id reali
|
||||
* `POSIX_SPAWN_SETPGROUP`: Imposta l'affiliazione al gruppo di processo
|
||||
* `POSUX_SPAWN_SETSIGDEF`: Imposta il comportamento predefinito del segnale
|
||||
* `POSIX_SPAWN_SETSIGMASK`: Imposta la maschera del segnale
|
||||
* `POSIX_SPAWN_SETEXEC`: Esegui nello stesso processo (come `execve` con più opzioni)
|
||||
* `POSIX_SPAWN_START_SUSPENDED`: Avvia sospeso
|
||||
* `_POSIX_SPAWN_DISABLE_ASLR`: Avvia senza ASLR
|
||||
* `_POSIX_SPAWN_NANO_ALLOCATOR:` Usa l'allocatore Nano di libmalloc
|
||||
* `_POSIX_SPAWN_ALLOW_DATA_EXEC:` Consenti `rwx` sui segmenti di dati
|
||||
* `POSIX_SPAWN_CLOEXEC_DEFAULT`: Chiudi tutte le descrizioni dei file su exec(2) per impostazione predefinita
|
||||
* `_POSIX_SPAWN_HIGH_BITS_ASLR:` Randomizza i bit alti dello slide ASLR
|
||||
|
||||
Inoltre, `posix_spawn` consente di specificare un array di **`posix_spawnattr`** che controlla alcuni aspetti del processo generato e **`posix_spawn_file_actions`** per modificare lo stato dei descrittori.
|
||||
|
||||
Quando un processo muore invia il **codice di ritorno al processo genitore** (se il genitore è morto, il nuovo genitore è il PID 1) con il segnale `SIGCHLD`. Il genitore deve ottenere questo valore chiamando `wait4()` o `waitid()` e finché ciò non accade il figlio rimane in uno stato zombie in cui è ancora elencato ma non consuma risorse.
|
||||
|
||||
### PID
|
||||
|
||||
I PID, identificatori di processo, identificano un processo univoco. In XNU i **PID** sono di **64 bit** che aumentano in modo monotonico e **non si avvolgono mai** (per evitare abusi).
|
||||
|
||||
### Gruppi di Processi, Sessioni e Coalizioni
|
||||
|
||||
**I processi** possono essere inseriti in **gruppi** per renderne più facile la gestione. Ad esempio, i comandi in uno script della shell saranno nello stesso gruppo di processi in modo da poterli **segnalare insieme** utilizzando ad esempio kill.\
|
||||
È anche possibile **raggruppare i processi in sessioni**. Quando un processo avvia una sessione (`setsid(2)`), i processi figli vengono inseriti nella sessione, a meno che non avviino la propria sessione.
|
||||
|
||||
La coalizione è un altro modo per raggruppare i processi in Darwin. Un processo che si unisce a una coalizione gli consente di accedere alle risorse del pool, condividere un registro o affrontare Jetsam. Le coalizioni hanno ruoli diversi: Leader, servizio XPC, Estensione.
|
||||
|
||||
### Credenziali e Personaggi
|
||||
|
||||
Ogni processo detiene **credenziali** che **identificano i suoi privilegi** nel sistema. Ogni processo avrà un `uid` primario e un `gid` primario (anche se potrebbe appartenere a diversi gruppi).\
|
||||
È anche possibile cambiare l'ID utente e di gruppo se l'eseguibile ha il bit `setuid/setgid`.\
|
||||
Ci sono diverse funzioni per **impostare nuovi uid/gid**.
|
||||
|
||||
La syscall **`persona`** fornisce un **insieme alternativo** di **credenziali**. L'adozione di una persona assume il suo uid, gid e l'appartenenza ai gruppi **in una volta sola**. Nel [**codice sorgente**](https://github.com/apple/darwin-xnu/blob/main/bsd/sys/persona.h) è possibile trovare la struttura:
|
||||
```c
|
||||
struct kpersona_info { uint32_t persona_info_version;
|
||||
uid_t persona_id; /* overlaps with UID */
|
||||
int persona_type;
|
||||
gid_t persona_gid;
|
||||
uint32_t persona_ngroups;
|
||||
gid_t persona_groups[NGROUPS];
|
||||
uid_t persona_gmuid;
|
||||
char persona_name[MAXLOGNAME + 1];
|
||||
|
||||
/* TODO: MAC policies?! */
|
||||
}
|
||||
```
|
||||
## Informazioni di base sui Thread
|
||||
|
||||
1. **Thread POSIX (pthreads):** macOS supporta i thread POSIX (`pthreads`), che fanno parte di un'API standard per il threading in C/C++. L'implementazione di pthreads in macOS si trova in `/usr/lib/system/libsystem_pthread.dylib`, che proviene dal progetto `libpthread` disponibile pubblicamente. Questa libreria fornisce le funzioni necessarie per creare e gestire i thread.
|
||||
2. **Creazione dei Thread:** La funzione `pthread_create()` viene utilizzata per creare nuovi thread. Internamente, questa funzione chiama `bsdthread_create()`, che è una chiamata di sistema di livello inferiore specifica al kernel XNU (il kernel su cui si basa macOS). Questa chiamata di sistema prende vari flag derivati da `pthread_attr` (attributi) che specificano il comportamento del thread, inclusi le politiche di scheduling e la dimensione dello stack.
|
||||
* **Dimensione predefinita dello Stack:** La dimensione predefinita dello stack per i nuovi thread è di 512 KB, che è sufficiente per le operazioni tipiche ma può essere regolata tramite attributi del thread se è necessario più o meno spazio.
|
||||
3. **Inizializzazione del Thread:** La funzione `__pthread_init()` è cruciale durante la configurazione del thread, utilizzando l'argomento `env[]` per analizzare le variabili d'ambiente che possono includere dettagli sulla posizione e dimensione dello stack.
|
||||
|
||||
#### Terminazione del Thread in macOS
|
||||
|
||||
1. **Uscita dei Thread:** I thread vengono tipicamente terminati chiamando `pthread_exit()`. Questa funzione consente a un thread di uscire pulitamente, eseguendo la pulizia necessaria e consentendo al thread di inviare un valore di ritorno a eventuali joiner.
|
||||
2. **Pulizia del Thread:** Al chiamare `pthread_exit()`, viene invocata la funzione `pthread_terminate()`, che gestisce la rimozione di tutte le strutture del thread associate. Dealloca le porte del thread Mach (Mach è il sottosistema di comunicazione nel kernel XNU) e chiama `bsdthread_terminate`, una syscall che rimuove le strutture a livello kernel associate al thread.
|
||||
|
||||
#### Meccanismi di Sincronizzazione
|
||||
|
||||
Per gestire l'accesso alle risorse condivise ed evitare le race condition, macOS fornisce diversi primitivi di sincronizzazione. Questi sono fondamentali negli ambienti multithreading per garantire l'integrità dei dati e la stabilità del sistema:
|
||||
|
||||
1. **Mutex:**
|
||||
* **Mutex Standard (Firma: 0x4D555458):** Mutex standard con una dimensione di memoria di 60 byte (56 byte per il mutex e 4 byte per la firma).
|
||||
* **Mutex Veloce (Firma: 0x4d55545A):** Simile a un mutex standard ma ottimizzato per operazioni più veloci, anch'esso di 60 byte.
|
||||
2. **Variabili di Condizione:**
|
||||
* Utilizzate per attendere che si verifichino determinate condizioni, con una dimensione di 44 byte (40 byte più una firma di 4 byte).
|
||||
* **Attributi delle Variabili di Condizione (Firma: 0x434e4441):** Attributi di configurazione per le variabili di condizione, di dimensione 12 byte.
|
||||
3. **Variabile Once (Firma: 0x4f4e4345):**
|
||||
* Garantisce che un pezzo di codice di inizializzazione venga eseguito solo una volta. La sua dimensione è di 12 byte.
|
||||
4. **Lock di Lettura-Scrittura:**
|
||||
* Consente a più lettori o a un solo scrittore alla volta, facilitando l'accesso efficiente ai dati condivisi.
|
||||
* **Lock di Lettura-Scrittura (Firma: 0x52574c4b):** Di dimensione 196 byte.
|
||||
* **Attributi del Lock di Lettura-Scrittura (Firma: 0x52574c41):** Attributi per i lock di lettura-scrittura, di dimensione 20 byte.
|
||||
|
||||
{% hint style="success" %}
|
||||
Gli ultimi 4 byte di questi oggetti vengono utilizzati per rilevare gli overflow.
|
||||
{% endhint %}
|
||||
|
||||
### Variabili Locali del Thread (TLV)
|
||||
|
||||
Le **Variabili Locali del Thread (TLV)** nel contesto dei file Mach-O (il formato per gli eseguibili in macOS) vengono utilizzate per dichiarare variabili specifiche per **ogni thread** in un'applicazione multithread. Ciò garantisce che ogni thread abbia la propria istanza separata di una variabile, fornendo un modo per evitare conflitti e mantenere l'integrità dei dati senza necessità di meccanismi di sincronizzazione espliciti come i mutex.
|
||||
|
||||
In C e nei linguaggi correlati, è possibile dichiarare una variabile locale del thread utilizzando la parola chiave **`__thread`**. Ecco come funziona nell'esempio:
|
||||
```c
|
||||
cCopy code__thread int tlv_var;
|
||||
|
||||
void main (int argc, char **argv){
|
||||
tlv_var = 10;
|
||||
}
|
||||
```
|
||||
Questo frammento definisce `tlv_var` come una variabile locale al thread. Ogni thread che esegue questo codice avrà la propria `tlv_var`, e le modifiche che un thread apporta a `tlv_var` non influenzeranno `tlv_var` in un altro thread.
|
||||
|
||||
Nel binario Mach-O, i dati relativi alle variabili locali al thread sono organizzati in sezioni specifiche:
|
||||
|
||||
- **`__DATA.__thread_vars`**: Questa sezione contiene i metadati sulle variabili locali al thread, come i loro tipi e lo stato di inizializzazione.
|
||||
- **`__DATA.__thread_bss`**: Questa sezione è utilizzata per le variabili locali al thread che non sono esplicitamente inizializzate. Fa parte della memoria riservata per i dati inizializzati a zero.
|
||||
|
||||
Mach-O fornisce anche una specifica API chiamata **`tlv_atexit`** per gestire le variabili locali al thread quando un thread termina. Questa API consente di **registrare distruttori** - funzioni speciali che puliscono i dati locali al thread quando un thread termina.
|
||||
|
||||
### Priorità dei Thread
|
||||
|
||||
Comprendere le priorità dei thread implica guardare a come il sistema operativo decide quali thread eseguire e quando. Questa decisione è influenzata dal livello di priorità assegnato a ciascun thread. In macOS e nei sistemi simili a Unix, ciò è gestito utilizzando concetti come `nice`, `renice` e classi di Quality of Service (QoS).
|
||||
|
||||
#### Nice e Renice
|
||||
|
||||
1. **Nice:**
|
||||
- Il valore `nice` di un processo è un numero che influenza la sua priorità. Ogni processo ha un valore `nice` che va da -20 (la priorità più alta) a 19 (la priorità più bassa). Il valore `nice` predefinito quando un processo viene creato è tipicamente 0.
|
||||
- Un valore `nice` più basso (più vicino a -20) rende un processo più "egoista", dandogli più tempo CPU rispetto ad altri processi con valori `nice` più alti.
|
||||
2. **Renice:**
|
||||
- `renice` è un comando utilizzato per cambiare il valore `nice` di un processo già in esecuzione. Questo può essere utilizzato per regolare dinamicamente la priorità dei processi, aumentando o diminuendo la loro allocazione di tempo CPU in base ai nuovi valori `nice`.
|
||||
- Ad esempio, se un processo ha bisogno temporaneamente di più risorse CPU, potresti abbassare il suo valore `nice` usando `renice`.
|
||||
|
||||
#### Classi di Quality of Service (QoS)
|
||||
|
||||
Le classi di QoS sono un approccio più moderno per gestire le priorità dei thread, in particolare nei sistemi come macOS che supportano **Grand Central Dispatch (GCD)**. Le classi di QoS consentono agli sviluppatori di **categorizzare** il lavoro in diversi livelli in base all'importanza o all'urgenza. macOS gestisce automaticamente la prioritizzazione dei thread in base a queste classi di QoS:
|
||||
|
||||
1. **Interattivo con l'utente:**
|
||||
- Questa classe è per attività che interagiscono attualmente con l'utente o richiedono risultati immediati per fornire un'esperienza utente ottimale. Queste attività hanno la priorità più alta per mantenere l'interfaccia reattiva (ad esempio, animazioni o gestione eventi).
|
||||
2. **Inizializzato dall'utente:**
|
||||
- Attività che l'utente avvia e si aspetta risultati immediati, come aprire un documento o fare clic su un pulsante che richiede calcoli. Queste attività hanno una priorità elevata ma inferiore a quella interattiva con l'utente.
|
||||
3. **Utility:**
|
||||
- Queste attività sono a lungo termine e mostrano tipicamente un indicatore di avanzamento (ad esempio, scaricare file, importare dati). Sono di priorità inferiore rispetto alle attività inizializzate dall'utente e non è necessario che finiscano immediatamente.
|
||||
4. **Background:**
|
||||
- Questa classe è per attività che operano in background e non sono visibili all'utente. Possono essere attività come indicizzazione, sincronizzazione o backup. Hanno la priorità più bassa e un impatto minimo sulle prestazioni del sistema.
|
||||
|
||||
Utilizzando le classi di QoS, gli sviluppatori non devono gestire i numeri di priorità esatti, ma piuttosto concentrarsi sulla natura del compito e il sistema ottimizza di conseguenza le risorse CPU.
|
||||
|
||||
Inoltre, ci sono diverse **politiche di pianificazione dei thread** che consentono di specificare un insieme di parametri di pianificazione che lo scheduler terrà in considerazione. Questo può essere fatto utilizzando `thread_policy_[set/get]`. Questo potrebbe essere utile negli attacchi di condizione di gara.
|
||||
|
||||
## Abuso dei Processi su MacOS
|
||||
|
||||
MacOS, come qualsiasi altro sistema operativo, fornisce una varietà di metodi e meccanismi per **processi per interagire, comunicare e condividere dati**. Sebbene queste tecniche siano essenziali per il corretto funzionamento del sistema, possono anche essere abusate da attori minacciosi per **eseguire attività dannose**.
|
||||
|
||||
### Iniezione di Libreria
|
||||
|
||||
L'iniezione di libreria è una tecnica in cui un attaccante **costringe un processo a caricare una libreria dannosa**. Una volta iniettata, la libreria viene eseguita nel contesto del processo target, fornendo all'attaccante gli stessi permessi e accesso del processo.
|
||||
L'Iniezione di Libreria è una tecnica in cui un attaccante **costringe un processo a caricare una libreria dannosa**. Una volta iniettata, la libreria viene eseguita nel contesto del processo target, fornendo all'attaccante gli stessi permessi e accesso del processo.
|
||||
|
||||
{% content-ref url="macos-library-injection/" %}
|
||||
[macos-library-injection](macos-library-injection/)
|
||||
|
|
@ -28,7 +166,7 @@ L'iniezione di libreria è una tecnica in cui un attaccante **costringe un proce
|
|||
|
||||
### Hooking di Funzioni
|
||||
|
||||
Il Hooking di Funzioni coinvolge l'**intercettazione delle chiamate alle funzioni** o dei messaggi all'interno di un codice software. Mediante il hooking delle funzioni, un attaccante può **modificare il comportamento** di un processo, osservare dati sensibili o addirittura ottenere il controllo sul flusso di esecuzione.
|
||||
Il Hooking di Funzioni coinvolge **intercettare chiamate di funzioni** o messaggi all'interno di un codice software. Mediante l'hooking delle funzioni, un attaccante può **modificare il comportamento** di un processo, osservare dati sensibili o persino ottenere il controllo sul flusso di esecuzione.
|
||||
|
||||
{% content-ref url="macos-function-hooking.md" %}
|
||||
[macos-function-hooking.md](macos-function-hooking.md)
|
||||
|
|
@ -36,13 +174,13 @@ Il Hooking di Funzioni coinvolge l'**intercettazione delle chiamate alle funzion
|
|||
|
||||
### Comunicazione tra Processi
|
||||
|
||||
La Comunicazione tra Processi (IPC) si riferisce a diversi metodi con cui processi separati **condividono e scambiano dati**. Sebbene l'IPC sia fondamentale per molte applicazioni legittime, può anche essere abusato per eludere l'isolamento dei processi, rivelare informazioni sensibili o eseguire azioni non autorizzate.
|
||||
La Comunicazione tra Processi (IPC) si riferisce a diversi metodi con cui processi separati **condividono e scambiano dati**. Sebbene l'IPC sia fondamentale per molte applicazioni legittime, può anche essere abusato per eludere l'isolamento dei processi, divulgare informazioni sensibili o eseguire azioni non autorizzate.
|
||||
|
||||
{% content-ref url="macos-ipc-inter-process-communication/" %}
|
||||
[macos-ipc-inter-process-communication](macos-ipc-inter-process-communication/)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Iniezione nelle Applicazioni Electron
|
||||
### Iniezione di Applicazioni Electron
|
||||
|
||||
Le applicazioni Electron eseguite con specifiche variabili d'ambiente potrebbero essere vulnerabili all'iniezione di processi:
|
||||
|
||||
|
|
@ -50,7 +188,7 @@ Le applicazioni Electron eseguite con specifiche variabili d'ambiente potrebbero
|
|||
[macos-electron-applications-injection.md](macos-electron-applications-injection.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Iniezione in Chromium
|
||||
### Iniezione di Chromium
|
||||
|
||||
È possibile utilizzare i flag `--load-extension` e `--use-fake-ui-for-media-stream` per eseguire un **attacco man in the browser** che consente di rubare tasti premuti, traffico, cookie, iniettare script nelle pagine...:
|
||||
|
||||
|
|
@ -60,21 +198,21 @@ Le applicazioni Electron eseguite con specifiche variabili d'ambiente potrebbero
|
|||
|
||||
### NIB Sporco
|
||||
|
||||
I file NIB **definiscono gli elementi dell'interfaccia utente (UI)** e le loro interazioni all'interno di un'applicazione. Tuttavia, possono **eseguire comandi arbitrari** e **Gatekeeper non impedisce** l'esecuzione di un'applicazione già eseguita se un **file NIB viene modificato**. Pertanto, potrebbero essere utilizzati per far eseguire programmi arbitrari comandi arbitrari:
|
||||
I file NIB **definiscono gli elementi dell'interfaccia utente (UI)** e le loro interazioni all'interno di un'applicazione. Tuttavia, possono **eseguire comandi arbitrari** e **Gatekeeper non impedisce** l'esecuzione di un'applicazione già eseguita se un **file NIB è modificato**. Pertanto, potrebbero essere utilizzati per far eseguire programmi arbitrari comandi arbitrari:
|
||||
|
||||
{% content-ref url="macos-dirty-nib.md" %}
|
||||
[macos-dirty-nib.md](macos-dirty-nib.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Iniezione nelle Applicazioni Java
|
||||
### Iniezione di Applicazioni Java
|
||||
|
||||
È possibile abusare di determinate capacità di Java (come la variabile d'ambiente **`_JAVA_OPTS`**) per far eseguire a un'applicazione Java **codice/comandi arbitrari**.
|
||||
È possibile abusare di determinate capacità di Java (come la variabile d'ambiente **`_JAVA_OPTS`**) per fare in modo che un'applicazione Java esegua **codice/comandi arbitrari**.
|
||||
|
||||
{% content-ref url="macos-java-apps-injection.md" %}
|
||||
[macos-java-apps-injection.md](macos-java-apps-injection.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Iniezione nelle Applicazioni .Net
|
||||
### Iniezione di Applicazioni .Net
|
||||
|
||||
È possibile iniettare codice nelle applicazioni .Net **abusando della funzionalità di debug di .Net** (non protetta dalle protezioni macOS come il rafforzamento in fase di esecuzione).
|
||||
|
||||
|
|
@ -84,7 +222,7 @@ I file NIB **definiscono gli elementi dell'interfaccia utente (UI)** e le loro i
|
|||
|
||||
### Iniezione di Perl
|
||||
|
||||
Controlla le diverse opzioni per far eseguire a uno script Perl codice arbitrario in:
|
||||
Controlla diverse opzioni per fare in modo che uno script Perl esegua codice arbitrario in:
|
||||
|
||||
{% content-ref url="macos-perl-applications-injection.md" %}
|
||||
[macos-perl-applications-injection.md](macos-perl-applications-injection.md)
|
||||
|
|
@ -92,25 +230,23 @@ Controlla le diverse opzioni per far eseguire a uno script Perl codice arbitrari
|
|||
|
||||
### Iniezione di Ruby
|
||||
|
||||
È anche possibile abusare delle variabili d'ambiente di Ruby per far eseguire script arbitrari codice arbitrario:
|
||||
È anche possibile abusare delle variabili d'ambiente di Ruby per fare in modo che script arbitrari eseguano codice arbitrario:
|
||||
|
||||
{% content-ref url="macos-ruby-applications-injection.md" %}
|
||||
[macos-ruby-applications-injection.md](macos-ruby-applications-injection.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Iniezione di Python
|
||||
|
||||
Se la variabile d'ambiente **`PYTHONINSPECT`** è impostata, il processo Python si avvierà in una CLI Python una volta terminato. È anche possibile utilizzare **`PYTHONSTARTUP`** per indicare uno script Python da eseguire all'inizio di una sessione interattiva.\
|
||||
Se la variabile di ambiente **`PYTHONINSPECT`** è impostata, il processo python passerà a una CLI python una volta terminato. È anche possibile utilizzare **`PYTHONSTARTUP`** per indicare uno script python da eseguire all'inizio di una sessione interattiva.\
|
||||
Tuttavia, nota che lo script **`PYTHONSTARTUP`** non verrà eseguito quando **`PYTHONINSPECT`** crea la sessione interattiva.
|
||||
|
||||
Altre variabili d'ambiente come **`PYTHONPATH`** e **`PYTHONHOME`** potrebbero essere utili per far eseguire a un comando Python codice arbitrario.
|
||||
Altre variabili di ambiente come **`PYTHONPATH`** e **`PYTHONHOME`** potrebbero essere utili per eseguire codice arbitrario con un comando python.
|
||||
|
||||
Nota che gli eseguibili compilati con **`pyinstaller`** non utilizzeranno queste variabili ambientali anche se vengono eseguiti utilizzando un Python integrato.
|
||||
Nota che gli eseguibili compilati con **`pyinstaller`** non utilizzeranno queste variabili di ambiente anche se vengono eseguiti utilizzando un python integrato.
|
||||
|
||||
{% hint style="danger" %}
|
||||
In generale, non ho trovato un modo per far eseguire a Python codice arbitrario abusando delle variabili d'ambiente.\
|
||||
Tuttavia, la maggior parte delle persone installa Python usando **Hombrew**, che installerà Python in una **posizione scrivibile** per l'utente amministratore predefinito. Puoi dirottarlo con qualcosa del genere:
|
||||
|
||||
Nel complesso non sono riuscito a trovare un modo per far eseguire a python codice arbitrario abusando delle variabili di ambiente.\
|
||||
Tuttavia, la maggior parte delle persone installa python utilizzando **Hombrew**, che installerà python in una **posizione scrivibile** per l'utente amministratore predefinito. Puoi dirottarlo con qualcosa del genere:
|
||||
```bash
|
||||
mv /opt/homebrew/bin/python3 /opt/homebrew/bin/python3.old
|
||||
cat > /opt/homebrew/bin/python3 <<EOF
|
||||
|
|
@ -120,7 +256,6 @@ cat > /opt/homebrew/bin/python3 <<EOF
|
|||
EOF
|
||||
chmod +x /opt/homebrew/bin/python3
|
||||
```
|
||||
|
||||
Anche **root** eseguirà questo codice quando si esegue python.
|
||||
{% endhint %}
|
||||
|
||||
|
|
@ -128,18 +263,18 @@ Anche **root** eseguirà questo codice quando si esegue python.
|
|||
|
||||
### Shield
|
||||
|
||||
[**Shield**](https://theevilbit.github.io/shield/) ([**Github**](https://github.com/theevilbit/Shield)) è un'applicazione open source che può **rilevare e bloccare azioni di iniezione di processi**:
|
||||
[**Shield**](https://theevilbit.github.io/shield/) ([**Github**](https://github.com/theevilbit/Shield)) è un'applicazione open source che può **rilevare e bloccare azioni di injection di processi**:
|
||||
|
||||
* Utilizzando le **Variabili Ambientali**: Monitorerà la presenza di una qualsiasi delle seguenti variabili ambientali: **`DYLD_INSERT_LIBRARIES`**, **`CFNETWORK_LIBRARY_PATH`**, **`RAWCAMERA_BUNDLE_PATH`** e **`ELECTRON_RUN_AS_NODE`**
|
||||
* Utilizzando chiamate a **`task_for_pid`**: Per individuare quando un processo vuole ottenere la **porta del task di un altro** che consente di iniettare codice nel processo.
|
||||
* **Parametri delle app Electron**: Qualcuno può utilizzare gli argomenti della riga di comando **`--inspect`**, **`--inspect-brk`** e **`--remote-debugging-port`** per avviare un'app Electron in modalità di debug e quindi iniettare codice in essa.
|
||||
* Utilizzando **symlink** o **hardlink**: Tipicamente l'abuso più comune è **collocare un link con i privilegi dell'utente**, e **farlo puntare a una posizione con privilegi superiori**. Il rilevamento è molto semplice sia per i hardlink che per i symlink. Se il processo che crea il link ha un **livello di privilegio diverso** rispetto al file di destinazione, creiamo un **avviso**. Purtroppo nel caso dei symlink, il blocco non è possibile, poiché non abbiamo informazioni sulla destinazione del link prima della creazione. Questa è una limitazione del framework EndpointSecuriy di Apple.
|
||||
* Utilizzando chiamate a **`task_for_pid`**: Per individuare quando un processo desidera ottenere la **porta del task di un altro** che consente di iniettare codice nel processo.
|
||||
* **Parametri delle app Electron**: Qualcuno può utilizzare gli argomenti della riga di comando **`--inspect`**, **`--inspect-brk`** e **`--remote-debugging-port`** per avviare un'app Electron in modalità di debug e quindi iniettarvi del codice.
|
||||
* Utilizzando **symlink** o **hardlink**: Tipicamente l'abuso più comune è **collocare un link con i privilegi del nostro utente** e **farlo puntare a una posizione con privilegi superiori**. Il rilevamento è molto semplice sia per i symlink che per gli hardlink. Se il processo che crea il link ha un **livello di privilegio diverso** rispetto al file di destinazione, creiamo un **avviso**. Purtroppo nel caso dei symlink, il blocco non è possibile, poiché non abbiamo informazioni sulla destinazione del link prima della creazione. Questa è una limitazione del framework EndpointSecuriy di Apple.
|
||||
|
||||
### Chiamate effettuate da altri processi
|
||||
|
||||
In [**questo post sul blog**](https://knight.sc/reverse%20engineering/2019/04/15/detecting-task-modifications.html) puoi trovare come è possibile utilizzare la funzione **`task_name_for_pid`** per ottenere informazioni su altri **processi che iniettano codice in un processo** e quindi ottenere informazioni su quel altro processo.
|
||||
|
||||
Nota che per chiamare quella funzione devi essere **lo stesso uid** di quello che esegue il processo o **root** (e restituisce informazioni sul processo, non un modo per iniettare codice).
|
||||
Nota che per chiamare quella funzione devi essere **lo stesso uid** di chi esegue il processo o **root** (e restituisce informazioni sul processo, non un modo per iniettare codice).
|
||||
|
||||
## Riferimenti
|
||||
|
||||
|
|
@ -148,7 +283,7 @@ Nota che per chiamare quella funzione devi essere **lo stesso uid** di quello ch
|
|||
|
||||
<details>
|
||||
|
||||
<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>
|
||||
<summary><strong>Impara l'hacking su 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:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue