<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PACCHETTI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT**](https://opensea.io/collection/the-peass-family) esclusivi
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo Telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
È 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**:
Questo è lo strumento principale di cui hai bisogno per connetterti a un dispositivo Android (emulato o fisico).\
**ADB** consente di controllare i dispositivi tramite **USB** o **Rete** 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.
A volte è interessante **modificare il codice dell'applicazione** per accedere a **informazioni nascoste** (ad esempio password o flag ben oscurati). Quindi, potrebbe essere interessante decompilare l'apk, modificare il codice e ricompilarlo.\
[**In questo tutorial** puoi **imparare come decompilare un APK, modificare il codice Smali e ricompilare l'APK** con la nuova funzionalità](smali-changes.md). Questo potrebbe essere molto utile come **alternativa per diversi test durante l'analisi dinamica** che verranno presentati. Quindi, **tieni sempre presente questa possibilità**.
Semplicemente dando un'occhiata alle **stringhe** dell'APK puoi cercare **password**, **URL** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **chiavi api**, **crittografia**, **UUID Bluetooth**, **token** e qualsiasi altra cosa interessante... cerca anche backdoor di esecuzione del codice o backdoor di autenticazione (credenziali admin codificate nell'app).
Presta particolare attenzione agli **URL di Firebase** e verifica se sono configurati in modo errato. [Ulteriori informazioni su cosa è Firebase e come sfruttarlo qui.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
L'**esame dei file _Manifest.xml_ e _strings.xml_ di un'applicazione può rivelare potenziali vulnerabilità di sicurezza**. Questi file possono essere accessibili utilizzando decompiler o rinominando l'estensione del file APK in .zip e quindi decomprimendolo.
* **Applicazioni in modalità di debug**: Le applicazioni impostate come debuggable (`debuggable="true"`) nel file _Manifest.xml_ rappresentano un rischio in quanto consentono connessioni che possono portare a sfruttamenti. Per una comprensione più approfondita su come sfruttare le applicazioni in modalità di debug, consulta un tutorial su come trovare ed esplorare le applicazioni in modalità di debug su un dispositivo.
* **Impostazioni di backup**: L'attributo `android:allowBackup="false"` dovrebbe essere impostato esplicitamente per le applicazioni che gestiscono informazioni sensibili per impedire il backup non autorizzato dei dati tramite adb, soprattutto quando il debug USB è abilitato.
* **Sicurezza di rete**: Le configurazioni personalizzate di sicurezza di rete (`android:networkSecurityConfig="@xml/network_security_config"`) in _res/xml/_ possono specificare dettagli di sicurezza come pin dei certificati e impostazioni del traffico HTTP. Un esempio è consentire il traffico HTTP per domini specifici.
* **Attività e servizi esportati**: L'individuazione di attività e servizi esportati nel manifesto può evidenziare componenti che potrebbero essere utilizzati impropriamente. Un'analisi ulteriore durante il testing dinamico può rivelare come sfruttare questi componenti.
* **Provider di contenuti e FileProviders**: I provider di contenuti esposti potrebbero consentire l'accesso o la modifica non autorizzati dei dati. Anche la configurazione dei FileProviders dovrebbe essere attentamente esaminata.
* **Broadcast Receiver e URL Scheme**: Questi componenti potrebbero essere sfruttati per scopi malevoli, prestando particolare attenzione a come vengono gestiti gli URL Scheme per le vulnerabilità di input.
* **Versioni SDK**: Gli attributi `minSdkVersion`, `targetSDKVersion` e `maxSdkVersion` indicano le versioni di Android supportate, evidenziando l'importanza di non supportare versioni obsolete e vulnerabili di Android per motivi di sicurezza.
Dal file **strings.xml**, è possibile scoprire informazioni sensibili come chiavi API, schemi personalizzati e altre note degli sviluppatori, sottolineando la necessità di una revisione attenta di queste risorse.
**Tapjacking** è un attacco in cui un'applicazione **malintenzionata** viene avviata e si posiziona sopra un'applicazione vittima. Una volta che oscura visivamente l'app vittima, la sua interfaccia utente è progettata in modo tale da ingannare l'utente a interagire con essa, mentre passa l'interazione all'app vittima.\
In pratica, **acceca l'utente facendogli credere di eseguire azioni sull'app vittima**.
Un'**attività** con **`launchMode`** impostato su **`singleTask` senza alcun `taskAffinity`** definito è vulnerabile all'hijacking del task. Ciò significa che un'**applicazione** può essere installata e se viene avviata prima dell'applicazione reale può **dirottare il task dell'applicazione reale** (quindi l'utente interagirà con l'applicazione malevola pensando di utilizzare quella reale).
In Android, i file **archiviati** nell'**archiviazione 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 alle esigenze di sicurezza della maggior parte delle applicazioni. Tuttavia, gli sviluppatori talvolta 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 malevole.
- **Assicurarsi** che l'uso di `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` sia **scrupolosamente esaminato**. Queste modalità **possono potenzialmente esporre** i file a **accessi non intenzionali o non autorizzati**.
- **Verificare** le **autorizzazioni** impostate sui file creati dall'app. In particolare, **verificare** se alcuni file sono **impostati come leggibili o scrivibili a livello globale**. Ciò può rappresentare un rischio significativo per la sicurezza, in quanto consentirebbe a **qualsiasi applicazione** installata sul dispositivo, indipendentemente dalla sua origine o intento, di **leggere o modificare** questi file.
- I file su archiviazione esterna sono **leggibili e scrivibili globalmente**. Ciò significa che qualsiasi applicazione o utente può accedere a questi file.
- Effettuare sempre una **validazione dell'input** sui dati recuperati dall'archiviazione esterna. Questo è fondamentale perché i dati provengono da una fonte non attendibile.
- È fortemente sconsigliato archiviare eseguibili o file di classe su archiviazione esterna per il caricamento dinamico.
- Se la tua applicazione deve recuperare file eseguibili da archiviazione esterna, assicurati che questi file siano **firmati e verificati crittograficamente** prima di essere caricati dinamicamente. Questo passaggio è fondamentale per mantenere l'integrità della sicurezza della tua applicazione.
A partire da Android 4.4 (**API 17**), la scheda SD ha una struttura delle directory che **limita l'accesso di un'app alla directory specifica per quell'app**. Ciò impedisce alle applicazioni malevole di ottenere accesso in lettura o scrittura ai file di un'altra app.
* **Preferenze condivise**: Android consente a ogni applicazione di salvare facilmente file XML nel percorso `/data/data/<nomedelpackage>/shared_prefs/` e talvolta è possibile trovare informazioni sensibili in chiaro in quella cartella.
* **Database**: Android consente a ogni applicazione di salvare facilmente database SQLite nel percorso `/data/data/<nomedelpackage>/databases/` e talvolta è possibile trovare informazioni sensibili in chiaro in quella cartella.
Per qualche motivo, a volte gli sviluppatori accettano tutti i certificati anche se, ad esempio, il nome host non corrisponde con righe di codice come la seguente:
Un buon modo per testare ciò è cercare di catturare il traffico utilizzando un proxy come Burp senza autorizzare Burp CA all'interno del dispositivo. Inoltre, è possibile generare con Burp un certificato per un nome host diverso e utilizzarlo.
Alcuni sviluppatori salvano dati sensibili nella memoria locale e li crittografano con una chiave codificata/predicibile nel codice. Questo non dovrebbe essere fatto poiché un'operazione di reversing potrebbe consentire agli attaccanti di estrarre le informazioni confidenziali.
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 ad esempio vengono utilizzati hash per memorizzare le password, dovrebbero essere utilizzati hash resistenti all'attacco di forza bruta con salt.
* È consigliabile **oscurare l'APK** per rendere più difficile il lavoro di reverse engineering agli attaccanti.
* Se l'app è sensibile (come le app bancarie), dovrebbe effettuare i **propri controlli per verificare se il dispositivo mobile è rootato** e agire di conseguenza.
* Se l'app è sensibile (come le app bancarie), dovrebbe verificare se viene utilizzato un **emulatore**.
* Se l'app è sensibile (come le app bancarie), dovrebbe **verificare la propria integrità prima di eseguirsi** per verificare se è stata modificata.
* Utilizzare [**APKiD**](https://github.com/rednaga/APKiD) per verificare quale compilatore/packer/obfuscator è stato utilizzato per creare l'APK.
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 singolo file. Il blog parla della possibilità di creare un'app che decomprime questo tipo di app... e un modo più veloce che consiste nell'**eseguire l'applicazione e raccogliere i file decompressi dal filesystem**.
Lo strumento [**mariana-trench**](https://github.com/facebook/mariana-trench) è in grado di individuare **vulnerabilità** analizzando il **codice** dell'applicazione. Questo strumento contiene una serie di **fonti conosciute** (che indicano allo strumento i **luoghi** in cui l'**input** è **controllato dall'utente**), **sink** (che indicano allo strumento **luoghi pericolosi** in cui l'input utente malintenzionato potrebbe causare danni) e **regole**. Queste regole indicano la **combinazione** di **fonti-sink** che indica una vulnerabilità.
Un'applicazione potrebbe contenere segreti (API key, password, URL nascosti, sottodomini...) al suo interno che potresti essere in grado di scoprire. Puoi utilizzare uno strumento come [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks)
> Innanzitutto, è necessario un ambiente in cui è possibile installare l'applicazione e tutto l'ambiente (certificato Burp CA, Drozer e Frida principalmente). Pertanto, è estremamente consigliato un dispositivo rootato (emulato o meno).
Puoi creare un **account gratuito** su: [https://appetize.io/](https://appetize.io). Questa piattaforma ti consente di **caricare** ed **eseguire** APK, quindi è utile per vedere come si comporta un APK.
* [**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)**ultime versioni x86** **supportano le librerie ARM** senza la necessità di un lento emulatore ARM).
* [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Versione gratuita:** Personal Edition, è necessario creare un account. _Si consiglia di **scaricare** la versione **CON**__**VirtualBox** per evitare errori potenziali._)
* [**Nox**](https://es.bignox.com) (Gratuito, ma non supporta Frida o Drozer).
Quando si crea un nuovo emulatore su qualsiasi piattaforma, ricorda che più grande è lo schermo, più lento sarà l'emulatore. Quindi seleziona schermi piccoli se possibile.
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 diversa VM con gli strumenti).
> Una volta installata l'applicazione, la prima cosa da fare è provarla e indagare su cosa fa, come funziona e familiarizzare con essa.\
> Suggerisco di **effettuare questa analisi dinamica iniziale utilizzando l'analisi dinamica di MobSF + pidcat**, in modo da poter **imparare come funziona l'applicazione** mentre MobSF **acquisisce** molti **dati interessanti** che potrai rivedere in seguito.
Gli sviluppatori dovrebbero fare attenzione a esporre informazioni di **debugging** pubblicamente, poiché ciò può portare a falle di sicurezza con la divulgazione di dati sensibili. Gli strumenti [**pidcat**](https://github.com/JakeWharton/pidcat) e `adb logcat` sono consigliati per monitorare i log dell'applicazione al fine di identificare e proteggere informazioni sensibili. **Pidcat** è preferito per la sua facilità d'uso e leggibilità.
Nota che a partire da **versioni successive ad Android 4.0**, **le applicazioni possono accedere solo ai propri log**. Quindi le applicazioni non possono accedere ai log di altre app.\
In ogni caso, è comunque consigliabile **non registrare informazioni sensibili**.
Il framework basato sulla **clipboard** di Android consente la funzionalità di copia e incolla nelle app, ma rappresenta un rischio in quanto **altre applicazioni** possono **accedere** alla clipboard, potenzialmente esponendo dati sensibili. È fondamentale **disabilitare le funzioni di copia/incolla** per sezioni sensibili di un'applicazione, come i dettagli della carta di credito, per evitare fughe di dati.
Se un'applicazione **si blocca** e **salva i log**, questi log possono essere utili agli attaccanti, soprattutto quando l'applicazione non può essere decompilata. Per mitigare questo rischio, evitare di registrare i crash e, se i log devono essere trasmessi tramite la rete, assicurarsi che vengano inviati tramite un canale SSL per la sicurezza.
Le applicazioni spesso integrano servizi come Google Adsense, che possono involontariamente **divulgare dati sensibili** a causa di un'implementazione impropria da parte degli sviluppatori. Per identificare possibili fughe di dati, è consigliabile **intercettare il traffico dell'applicazione** e verificare se vengono inviate informazioni sensibili a servizi di terze parti.
La maggior parte delle applicazioni utilizzerà **database SQLite interni** per salvare le informazioni. Durante il pentest, **controlla** i **database** creati, i nomi delle **tabelle** e delle **colonne** e tutti i **dati** salvati, poiché potresti trovare **informazioni sensibili** (che costituirebbero una vulnerabilità).\
I database dovrebbero trovarsi in `/data/data/nome.pacchetto/databases` come `/data/data/com.mwr.example.sieve/databases`
Se il database sta salvando informazioni confidenziali ed è **crittografato** ma puoi **trovare** la **password** all'interno dell'applicazione, è comunque una **vulnerabilità**.
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 **tutto ciò 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 Provider**, come imparerai nelle sezioni seguenti.
Quando un'attività viene esportata, è possibile invocare la sua schermata da un'app esterna. Pertanto, se un'attività con **informazioni sensibili** è **esportata**, potresti **eludere** i meccanismi di **autenticazione** per accedervi.
**NOTA**: MobSF rileverà come dannoso l'uso di _**singleTask/singleInstance**_ come `android:launchMode` in un'attività, ma a causa di [questo](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750), apparentemente ciò è pericoloso solo nelle vecchie versioni (versioni API <21).
**Le attività possono anche restituire risultati**. Se riesci a trovare un'attività esportata e non protetta che chiama il metodo **`setResult`** e **restituisce informazioni sensibili**, si tratta di una divulgazione di informazioni sensibili.
Se il tapjacking non viene impedito, è possibile abusare dell'attività esportata per far sì che l'**utente esegua azioni impreviste**. Per ulteriori informazioni su [**cosa è il Tapjacking segui il link**](./#tapjacking).
[**Leggi questo se vuoi rinfrescare cosa è un Content Provider.**](android-applications-basics.md#content-provider)\
I content provider vengono utilizzati principalmente per **condividere dati**. Se un'app dispone di content provider disponibili, potresti essere in grado di **estrarre dati sensibili** da essi. È anche interessante testare possibili **iniezioni SQL** e **traversali di percorso** in quanto potrebbero essere vulnerabili.
Un servizio è fondamentalmente qualcosa che **può ricevere dati**, **elaborarli** e **restituire** (o meno) una risposta. Quindi, se un'applicazione esporta alcuni servizi, dovresti **controllare** il **codice** per capire cosa sta facendo e **testarlo****dinamicamente** per estrarre informazioni confidenziali, eludere le misure di autenticazione...\
[**Scopri come sfruttare i Servizi con Drozer.**](drozer-tutorial/#services)
Un ricevitore di trasmissione sarà in attesa di un tipo di messaggio. A seconda di come il ricevitore gestisce il messaggio, potrebbe essere vulnerabile.\
[**Scopri come sfruttare i Ricevitori di Trasmissione con Drozer.**](./#exploiting-broadcast-receivers)
Puoi cercare i deep link manualmente, utilizzando strumenti come MobSF o script come [questo](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py).\
Puoi **aprire** uno **schema** dichiarato utilizzando **adb** o un **browser**:
Ogni volta che trovi un deeplink, controlla che **non stia ricevendo dati sensibili (come password) tramite parametri URL**, perché qualsiasi altra applicazione potrebbe **fingere il deeplink e rubare quei dati!**
Devi controllare anche se un deeplink sta utilizzando un parametro all'interno del percorso dell'URL come: `https://api.example.com/v1/users/{username}`, in tal caso puoi forzare una traversa del percorso accedendo a qualcosa del genere: `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 un **Open Redirect** (se parte del percorso viene utilizzato come nome di dominio), **account takeover** (se puoi modificare i dettagli degli utenti senza token CSRF e l'endpoint vulnerabile utilizza il metodo corretto) e qualsiasi altra vulnerabilità. Maggiori [informazioni su questo qui](http://dphoeniixx.com/2020/12/13-2/).
- **I certificati non vengono sempre ispezionati correttamente** dalle applicazioni Android. È comune che queste applicazioni ignorino gli avvisi e accettino certificati autofirmati o, in alcuni casi, tornino a utilizzare connessioni HTTP.
- **Le negoziazioni durante la handshake SSL/TLS sono talvolta deboli**, utilizzando suite di cifratura non sicure. Questa vulnerabilità rende la connessione suscettibile ad attacchi di tipo man-in-the-middle (MITM), consentendo agli attaccanti di decifrare i dati.
- **La divulgazione di informazioni private** è un rischio quando le applicazioni si autenticano utilizzando canali sicuri ma poi comunicano su canali non sicuri per altre transazioni. Questo approccio non protegge i dati sensibili, come i cookie di sessione o i dettagli dell'utente, dall'intercettazione da parte di entità malevole.
Ci concentreremo sulla **verifica del certificato**. È necessario verificare l'integrità del certificato del server per migliorare la sicurezza. Questo è fondamentale perché le configurazioni TLS non sicure e la trasmissione di dati sensibili su canali non crittografati possono comportare rischi significativi. Per dettagliati passaggi sulla verifica dei certificati del server e sulla risoluzione delle vulnerabilità, **[questa risorsa](https://manifestsecurity.com/android-application-security-part-10/)** fornisce una guida completa.
SSL Pinning è una misura di sicurezza in cui l'applicazione verifica il certificato del server rispetto a una copia nota memorizzata all'interno dell'applicazione stessa. Questo metodo è essenziale per prevenire attacchi MITM. L'implementazione di SSL Pinning è fortemente consigliata per le applicazioni che gestiscono informazioni sensibili.
Per ispezionare il traffico HTTP, è necessario **installare il certificato dello strumento di proxy** (ad esempio, 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 che mirano a **API Level 24 e superiori** richiedono modifiche alla configurazione di sicurezza di rete per accettare il certificato CA del proxy. Questo passaggio è fondamentale per l'ispezione del traffico crittografato. Per istruzioni su come modificare la configurazione di sicurezza di rete, **[consulta questo tutorial](make-apk-accept-ca-certificate.md)**.
* Modificare automaticamente l'**apk** per **bypassare** SSL Pinning con [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Il vantaggio principale di questa opzione è che non sarà necessario ottenere i permessi di root per bypassare l'SSL Pinning, ma sarà necessario eliminare l'applicazione e reinstallarne una nuova, e ciò non funzionerà sempre.
* Puoi utilizzare **Frida** (discusso di seguito) per bypassare questa protezione. Qui trovi una guida su come utilizzare 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 l'SSL Pinning** utilizzando [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
* Puoi anche provare a **bypassare automaticamente l'SSL Pinning** utilizzando l'**analisi dinamica di MobSF** (spiegata di seguito)
* Se pensi ancora che ci sia del traffico che non stai catturando, puoi provare a **inoltrare il traffico a burp utilizzando 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)
È importante cercare anche vulnerabilità web comuni all'interno dell'applicazione. Le informazioni dettagliate sull'individuazione e sulla mitigazione di queste vulnerabilità esulano dallo scopo di questo riassunto, ma sono ampiamente trattate altrove.
[Frida](https://www.frida.re) è un toolkit di strumenti di strumentazione dinamica per sviluppatori, reverse engineer e ricercatori di sicurezza.\
**Puoi accedere all'applicazione in esecuzione e agganciare i metodi in tempo di esecuzione per cambiare il comportamento, cambiare i valori, estrarre valori, eseguire codice diverso...**\
Se vuoi fare pentesting delle applicazioni Android, devi sapere come usare Frida.
* Impara come usare Frida: [**Tutorial su Frida**](frida-tutorial/)
* Alcuni "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 Frida fantastici qui: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
In Android, il Keystore è il posto migliore per archiviare dati sensibili, tuttavia, con sufficienti privilegi, è ancora **possibile accedervi**. Poiché le applicazioni tendono a memorizzare qui **dati sensibili in chiaro**, i test di penetrazione dovrebbero verificarlo poiché un utente root o qualcuno con accesso fisico al dispositivo potrebbe essere in grado di rubare questi dati.
Per accedere ai dati all'interno del keystore, è possibile utilizzare questo script di Frida: [https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js](https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js)
Utilizzando lo script Frida seguente potrebbe essere possibile **bypassare l'autenticazione tramite impronte digitali** che le applicazioni Android potrebbero eseguire al fine di **proteggere determinate aree sensibili:**
Quando si mette un'applicazione in background, Android memorizza uno **snapshot dell'applicazione** in modo che quando viene ripristinata in primo piano, inizia a caricare l'immagine prima dell'app in modo che sembri che l'app sia stata caricata più velocemente.
Tuttavia, se questo snapshot contiene **informazioni sensibili**, qualcuno con accesso allo snapshot potrebbe **rubare tali informazioni** (nota che è necessario il root per accedervi).
Android fornisce un modo per **prevenire la cattura dello screenshot impostando il parametro FLAG\_SECURE**. Utilizzando questo flag, i contenuti della finestra vengono trattati come sicuri, impedendo che vengano visualizzati negli screenshot o su display non sicuri.
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)
Gli sviluppatori spesso creano componenti proxy come attività, servizi e ricevitori di trasmissione che gestiscono questi Intent e li passano a metodi come `startActivity(...)` o `sendBroadcast(...)`, il che può essere rischioso.
Il pericolo risiede nel permettere agli attaccanti di attivare componenti dell'app non esportati o accedere a provider di contenuti sensibili deviando questi Intent. Un esempio notevole è il componente `WebView` che converte gli URL in oggetti `Intent` tramite `Intent.parseUri(...)` e poi li esegue, potenzialmente portando a iniezioni di Intent dannose.
* **SQL Injection:** Quando si gestiscono query dinamiche o Content-Provider, assicurarsi di utilizzare query parametrizzate.
* **JavaScript Injection (XSS):** Verificare che il supporto JavaScript e dei plugin sia disabilitato per qualsiasi WebView (disabilitato per impostazione predefinita). [Maggiori informazioni qui](webview-attacks.md#javascript-enabled).
* **Local File Inclusion:** Le WebView dovrebbero avere l'accesso al file system disabilitato (abilitato per impostazione predefinita) - `(webview.getSettings().setAllowFileAccess(false);)`. [Maggiori informazioni qui](webview-attacks.md#javascript-enabled).
* **Cookie eterni**: In diversi casi, quando l'applicazione Android termina la sessione, il cookie non viene revocato o potrebbe persino essere salvato su disco.
* [**Secure Flag** nei cookie](../../pentesting-web/hacking-with-cookies/#cookies-flags)
**Valutazione delle vulnerabilità dell'applicazione** utilizzando un'interfaccia web-based piacevole. È anche possibile eseguire un'analisi dinamica (ma è necessario preparare l'ambiente).
Si noti che MobSF può analizzare le applicazioni **Android** (apk), **IOS** (ipa) e **Windows** (apx) (le applicazioni Windows devono essere analizzate da un MobSF installato in un host Windows).\
Inoltre, se crei un file **ZIP** con il codice sorgente di un'app **Android** o **IOS** (vai alla cartella principale dell'applicazione, seleziona tutto e crea un file ZIP), sarà in grado di analizzarlo anche.
MobSF consente anche di confrontare/analizzare le analisi e di integrare VirusTotal (è necessario impostare la chiave API in MobSF/settings.py e abilitarla: `VT_ENABLED = TRUE``VT_API_KEY = <La tua chiave API>``VT_UPLOAD = TRUE`). È anche possibile impostare `VT_UPLOAD` su `False`, quindi l'hash verrà caricato invece del file.
MobSF può essere molto utile anche per l'analisi dinamica su Android, ma in questo caso sarà necessario installare MobSF e genymotion nel tuo host (una VM o Docker non funzioneranno). Nota: è necessario **avviare prima una VM in genymotion** e **poi MobSF**.\
* Estrarre i dati dell'applicazione (URL, log, appunti, screenshot effettuati da te, screenshot effettuati da "Exported Activity Tester", email, database SQLite, file XML e altri file creati). Tutto ciò viene fatto automaticamente tranne gli screenshot, devi premere quando desideri uno screenshot o devi premere "Exported Activity Tester" per ottenere gli screenshot di tutte le attività esportate.
* Catturare il traffico HTTPS
* Utilizzare Frida per ottenere informazioni in tempo reale
A partire 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.
Per impostazione predefinita, utilizzerà anche alcuni script di Frida per aggirare il pinning SSL, la rilevazione del root e la rilevazione del debugger e per monitorare le API interessanti.\
MobSF può anche invocare attività esportate, acquisire screenshot di esse e salvarle per il report.
Per avviare il test dinamico, premi il pulsante verde: "Start Instrumentation". Premi "Frida Live Logs" per visualizzare i log generati dagli script di Frida e "Live API Monitor" per visualizzare tutte le invocazioni ai metodi hook, gli argomenti passati e i valori restituiti (questo apparirà dopo aver premuto "Start Instrumentation").\
MobSF consente anche di caricare i propri script di Frida (per inviare i risultati dei tuoi script di Frida a MobSF utilizza la funzione `send()`). Ha anche diversi script predefiniti che è possibile caricare (è possibile aggiungerne altri 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").
* Enumera le classi caricate: Stampa tutte le classi caricate
* Cattura stringhe: Stampa tutte le stringhe catturate durante l'utilizzo dell'applicazione (molto rumoroso)
* Cattura confronti di stringhe: Potrebbe essere molto utile. Mostra le 2 stringhe confrontate e se il risultato è stato True o False.
* Enumera i metodi di classe: Inserisci il nome della classe (come "java.io.File") e stamperà tutti i metodi della classe.
* Cerca modello di classe: Cerca classi per modello
* Traccia i metodi di classe: Traccia un'intera classe (vedi input e output di tutti i metodi della classe). Ricorda che per impostazione predefinita MobSF traccia diversi metodi interessanti delle API Android.
Una volta selezionato il modulo ausiliario che desideri utilizzare, è necessario premere "Start Intrumentation" e vedrai tutti gli output in "Frida Live Logs".
Mobsf ti offre anche una shell con alcuni comandi adb, comandi MobSF e comandi shell comuni nella parte inferiore della pagina di analisi dinamica. Alcuni comandi interessanti:
Quando viene catturato il traffico HTTP, è possibile visualizzare una vista poco attraente del traffico catturato nella sezione "**HTTP(S) Traffic**" in basso o una vista più piacevole nel pulsante verde "**Start HTTPTools**". Dalla seconda opzione, è possibile **inviare** le **richieste catturate** a **proxy** come Burp o Owasp ZAP.\
Per farlo, _accendere Burp -->__disattivare l'intercettazione --> in MobSB HTTPTools selezionare la richiesta_ --> premere "**Send to Fuzzer**" --> _selezionare l'indirizzo del proxy_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
Una volta completata l'analisi dinamica con MobSF, è possibile premere su "**Start Web API Fuzzer**" per **fuzzare le richieste HTTP** e cercare vulnerabilità.
Dopo aver eseguito un'analisi dinamica con MobSF, le impostazioni del proxy potrebbero essere configurate in modo errato e non sarà possibile correggerle dall'interfaccia grafica. È possibile correggere le impostazioni del proxy eseguendo:
Questo strumento è progettato per cercare diverse **vulnerabilità di sicurezza delle applicazioni Android**, sia nel **codice sorgente** che negli **APK confezionati**. Lo strumento è inoltre **in grado di creare un APK "Proof-of-Concept" deployable** e **comandi ADB**, per sfruttare alcune delle vulnerabilità trovate (attività esposte, intenti, tapjacking...). Come Drozer, non è necessario eseguire il root del dispositivo di test.
SUPER è un'applicazione da linea di comando che può essere utilizzata su Windows, MacOS X e Linux per analizzare i file _.apk_ alla ricerca di vulnerabilità. Lo fa decomprimendo gli APK e applicando una serie di regole per rilevare tali vulnerabilità.
StaCoAn è uno strumento **crossplatform** che aiuta sviluppatori, cacciatori di bug e hacker etici a eseguire l'analisi del codice statico sulle applicazioni mobili.
Il concetto è che trascini e rilasci il file dell'applicazione mobile (un file .apk o .ipa) sull'applicazione StaCoAn e genererà un rapporto visuale e portatile per te. Puoi personalizzare le impostazioni e le liste di parole per ottenere un'esperienza personalizzata.
AndroBugs Framework è un sistema di analisi delle vulnerabilità di Android che aiuta sviluppatori o hacker a individuare potenziali vulnerabilità di sicurezza nelle applicazioni Android.\
[Rilasci per Windows](https://github.com/AndroBugs/AndroBugs\_Framework/releases)
**Androwarn** è uno strumento il cui obiettivo principale è rilevare e avvertire l'utente riguardo potenziali comportamenti maligni sviluppati da un'applicazione Android.
La rilevazione viene effettuata tramite 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 "cattive" applicazioni come: esfiltrazione di identificatori telefonici, intercettazione di flussi audio/video, modifica dei dati PIM, esecuzione di codice arbitrario...
**MARA** è un **F**ramework di **R**everse engineering e **A**nalisi di **A**pplicazioni **M**obili. È uno strumento che riunisce strumenti comuni utilizzati per il reverse engineering e l'analisi di applicazioni mobili, al fine di testare le applicazioni mobili contro le minacce alla sicurezza mobile di OWASP. Il suo obiettivo è rendere questa attività più facile e amichevole per gli sviluppatori di applicazioni mobili e i professionisti della sicurezza.
* Analizzare i domini trovati utilizzando: [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) e [whatweb](https://github.com/urbanadventurer/WhatWeb)
* Deobfuscare l'APK tramite [apk-deguard.com](http://www.apk-deguard.com)
Da [Wikipedia](https://en.wikipedia.org/wiki/ProGuard\_\(software\)): **ProGuard** è uno strumento open source a riga di comando che riduce, ottimizza e obfusca il codice Java. È in grado di ottimizzare il bytecode e rilevare ed eliminare istruzioni inutilizzate. ProGuard è un software gratuito e viene distribuito con la licenza GNU General Public License, versione 2.
**DeGuard inverte il processo di obfuscazione eseguito dagli strumenti di obfuscazione di Android. Ciò consente numerose analisi di sicurezza, inclusa l'ispezione del codice e la previsione delle librerie.**
È un **deobfuscator generico per Android.** Simplify **esegue virtualmente un'app** per comprendere il suo comportamento e quindi **cerca di ottimizzare il codice** in modo che si comporti in modo identico ma sia più comprensibile per un essere umano. Ogni tipo di ottimizzazione è semplice e generico, quindi non importa quale tipo specifico di obfuscazione viene utilizzato.
APKiD fornisce informazioni su **come è stato creato un APK**. Identifica molti **compilatori**, **packer**, **obfuscatore** e altre cose strane. È [_PEiD_](https://www.aldeid.com/wiki/PEiD) per Android.
AndroL4b è una macchina virtuale di sicurezza Android basata su ubuntu-mate che include la raccolta degli ultimi framework, tutorial e laboratori di diversi esperti di sicurezza e ricercatori per il reverse engineering e l'analisi del malware.
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PACCHETTI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR ai repository github di** [**HackTricks**](https://github.com/carlospolop/hacktricks) **e** [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
