Install Burp Certificate
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Su una Macchina Virtuale
Prima di tutto devi scaricare il certificato Der da Burp. Puoi farlo in Proxy --> Options --> Importa / Esporta certificato CA
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F197708944-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FE5VfhVAq0qYsgU9deMR8%252Fuploads%252Fgit-blob-ad88950d72ba52916d305d8bb5c938dd1f4cba70%252Fimage%2520%28367%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=6ca97e40&sv=1)
Esporta il certificato in formato Der e trasformalo in una forma che Android sarà in grado di comprendere. Nota che per configurare il certificato burp sulla macchina Android in AVD devi eseguire questa macchina con l'opzione -writable-system
.
Ad esempio, puoi eseguirlo così:
Quindi, per configurare il certificato di burp fare:
Una volta che la macchina ha terminato il riavvio, il certificato burp sarà in uso!
Utilizzando Magisc
Se hai rootato il tuo dispositivo con Magisc (forse un emulatore), e non puoi seguire i passaggi precedenti per installare il certificato Burp perché il filesystem è in sola lettura e non puoi rimontarlo in scrittura, c'è un altro modo.
Spiegato in questo video devi:
Installare un certificato CA: Basta trascinare e rilasciare il certificato Burp DER cambiando l'estensione in
.crt
nel mobile in modo che sia memorizzato nella cartella Download e andare suInstalla un certificato
->Certificato CA
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F197708944-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FE5VfhVAq0qYsgU9deMR8%252Fuploads%252Fgit-blob-a8cfa5b773303edb184e1e0eac4f0ba47f67677c%252Fimage%2520%2853%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=ce547a75&sv=1)
Controlla che il certificato sia stato memorizzato correttamente andando su
Credenziali attendibili
->UTENTE
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F197708944-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FE5VfhVAq0qYsgU9deMR8%252Fuploads%252Fgit-blob-0e554c193b3a470f5b1da38e3106da1e6d3ba244%252Fimage%2520%2854%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=6b7d40f9&sv=1)
Rendere fidato di sistema: Scarica il modulo Magisc MagiskTrustUserCerts (un file .zip), trascinalo e rilascialo nel telefono, vai all'app Magics nel telefono nella sezione
Moduli
, clicca suInstalla da memoria
, seleziona il modulo.zip
e una volta installato riavvia il telefono:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F197708944-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FE5VfhVAq0qYsgU9deMR8%252Fuploads%252Fgit-blob-8190e06a75ffa491e447ad9278cb40312d5e82b5%252Fimage%2520%2855%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=2dd8005e&sv=1)
Dopo il riavvio, vai su
Credenziali attendibili
->SISTEMA
e controlla che il certificato Postswigger sia presente
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F197708944-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FE5VfhVAq0qYsgU9deMR8%252Fuploads%252Fgit-blob-b98c9fbbc98929f4f21cab6c8d6d02d3844d23bd%252Fimage%2520%2856%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=6ee34da2&sv=1)
Post Android 14
Nell'ultima versione di Android 14, è stato osservato un cambiamento significativo nella gestione dei certificati dell'Autorità di Certificazione (CA) fidati di sistema. In precedenza, questi certificati erano ospitati in /system/etc/security/cacerts/
, accessibili e modificabili dagli utenti con privilegi di root, il che consentiva un'applicazione immediata in tutto il 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.
I tentativi di rimontare il percorso APEX cacerts come scrivibile incontrano un fallimento, poiché il sistema non consente tali operazioni. Anche i tentativi di smontare o sovrapporre la directory con un file system temporaneo (tmpfs) non eludono l'immutabilità; le applicazioni continuano ad accedere ai dati del certificato originale indipendentemente dalle modifiche a livello di file system. Questa resilienza è dovuta al fatto che il mount /apex
è configurato con propagazione PRIVATA, 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 dell'avvio dei processi delle applicazioni con un nuovo namespace di mount che include un mount /apex
privato, isolando così le modifiche a questa directory da altri processi.
Tuttavia, esiste una soluzione per coloro che necessitano di modificare i certificati CA fidati di sistema all'interno della directory /apex
. Questo comporta il rimontaggio manuale di /apex
per rimuovere la propagazione PRIVATA, rendendolo quindi scrivibile. Il processo include la copia dei contenuti 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 un'azione rapida per evitare crash di sistema. Per garantire l'applicazione di queste modifiche a livello di sistema, si consiglia di riavviare il system_server
, che riavvia effettivamente tutte le applicazioni e riporta il sistema a uno stato coerente.
Bind-mounting through NSEnter
Impostare una Directory Scrivibile: Inizialmente, viene stabilita una directory scrivibile montando un
tmpfs
sulla directory dei certificati di sistema non-APEX esistente. Questo viene realizzato con il seguente comando:
Preparazione dei certificati CA: Dopo aver impostato la directory scrivibile, i certificati CA che si intendono utilizzare devono essere copiati in questa directory. Questo potrebbe comportare la copia dei certificati predefiniti da
/apex/com.android.conscrypt/cacerts/
. È essenziale regolare le autorizzazioni e le etichette SELinux di questi certificati di conseguenza.Montaggio Bind per Zygote: Utilizzando
nsenter
, si entra nello spazio dei nomi di montaggio 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 è:
Questo garantisce che ogni nuova app avviata aderisca alla configurazione aggiornata dei certificati CA.
Applicare le modifiche alle app in esecuzione: Per applicare le modifiche alle applicazioni già in esecuzione,
nsenter
viene nuovamente utilizzato per entrare nel namespace di ciascuna app individualmente e eseguire un montaggio bind simile. Il comando necessario è:
Approccio Alternativo - Riavvio Morbido: Un metodo alternativo prevede di eseguire il bind mount sul processo
init
(PID 1) seguito da un riavvio morbido del sistema operativo con i comandistop && start
. Questo approccio propagherebbe le modifiche attraverso tutti i namespace, evitando la necessità di affrontare individualmente ciascuna app in esecuzione. Tuttavia, questo metodo è generalmente meno preferito a causa dell'inconveniente del riavvio.
Riferimenti
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated