mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-22 04:33:28 +00:00
Translated ['mobile-pentesting/android-app-pentesting/android-applicatio
This commit is contained in:
Translator
parent
26d0861513
commit
258a1371ff
1 changed files with 18 additions and 18 deletions
|
|
@ -33,15 +33,15 @@ Impara e pratica GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-s
|
|||
|
||||
### Sandboxing
|
||||
|
||||
Il **Sandbox delle Applicazioni Android** consente di eseguire **ogni applicazione** come un **processo separato sotto un ID utente separato**. Ogni processo ha la propria macchina virtuale, quindi il codice di un'app viene eseguito in isolamento rispetto ad altre app.\
|
||||
A partire da Android 5.0(L), **SELinux** è applicato. Fondamentalmente, SELinux nega tutte le interazioni tra processi e poi crea politiche per **consentire solo le interazioni previste tra di essi**.
|
||||
Il **Sandbox delle Applicazioni Android** consente di eseguire **ogni applicazione** come un **processo separato sotto un ID Utente separato**. Ogni processo ha la propria macchina virtuale, quindi il codice di un'app viene eseguito in isolamento rispetto ad altre app.\
|
||||
A partire da Android 5.0(L) **SELinux** è applicato. Fondamentalmente, SELinux nega tutte le interazioni tra processi e poi crea politiche per **consentire solo le interazioni previste tra di essi**.
|
||||
|
||||
### Permessi
|
||||
|
||||
Quando installi un'**app e chiede permessi**, l'app sta chiedendo i permessi configurati negli elementi **`uses-permission`** nel file **AndroidManifest.xml**. L'elemento **uses-permission** indica il nome del permesso richiesto all'interno dell'**attributo name**. Ha anche l'attributo **maxSdkVersion** che smette di chiedere permessi su versioni superiori a quella specificata.\
|
||||
Nota che le applicazioni android non devono chiedere tutti i permessi all'inizio, possono anche **chiedere permessi dinamicamente**, ma tutti i permessi devono essere **dichiarati** nel **manifest**.
|
||||
Nota che le applicazioni android non devono chiedere tutti i permessi all'inizio, possono anche **chiedere permessi dinamicamente** ma tutti i permessi devono essere **dichiarati** nel **manifest.**
|
||||
|
||||
Quando un'app espone funzionalità, può limitare **l'accesso solo alle app che hanno un permesso specificato**.\
|
||||
Quando un'app espone funzionalità, può limitare l'**accesso solo alle app che hanno un permesso specificato**.\
|
||||
Un elemento di permesso ha tre attributi:
|
||||
|
||||
* Il **nome** del permesso
|
||||
|
|
@ -49,8 +49,8 @@ Un elemento di permesso ha tre attributi:
|
|||
* Il **protection-level** che indica come vengono concessi i permessi. Ci sono quattro tipi:
|
||||
* **Normale**: Usato quando non ci sono **minacce note** all'app. L'utente **non è tenuto ad approvarlo**.
|
||||
* **Pericoloso**: Indica che il permesso concede all'applicazione richiedente un **accesso elevato**. **Gli utenti sono invitati ad approvarli**.
|
||||
* **Firma**: Solo le **app firmate dallo stesso certificato di quello** che esporta il componente possono ricevere il permesso. Questo è il tipo di protezione più forte.
|
||||
* **FirmaOSistema**: Solo le **app firmate dallo stesso certificato di quello** che esporta il componente o **app che girano con accesso a livello di sistema** possono ricevere permessi.
|
||||
* **Firma**: Solo le **app firmate dallo stesso certificato di quello** che esporta il componente possono ottenere il permesso. Questo è il tipo di protezione più forte.
|
||||
* **FirmaOSystem**: Solo le **app firmate dallo stesso certificato di quello** che esporta il componente o **app che girano con accesso a livello di sistema** possono ottenere permessi.
|
||||
|
||||
## Applicazioni Preinstallate
|
||||
|
||||
|
|
@ -65,7 +65,7 @@ Queste app si trovano generalmente nelle directory **`/system/app`** o **`/syste
|
|||
Per ottenere accesso root su un dispositivo android fisico, generalmente è necessario **sfruttare** 1 o 2 **vulnerabilità** che tendono a essere **specifiche** per il **dispositivo** e la **versione**.\
|
||||
Una volta che lo sfruttamento ha funzionato, di solito il binario Linux `su` viene copiato in una posizione specificata nella variabile PATH dell'utente come `/system/xbin`.
|
||||
|
||||
Una volta configurato il binario su, viene utilizzata un'altra app Android per interfacciarsi con il binario `su` e **elaborare le richieste di accesso root** come **Superuser** e **SuperSU** (disponibile nel Google Play store).
|
||||
Una volta configurato il binario su, un'altra app Android viene utilizzata per interfacciarsi con il binario `su` e **elaborare richieste di accesso root** come **Superuser** e **SuperSU** (disponibile nel Google Play store).
|
||||
|
||||
{% hint style="danger" %}
|
||||
Nota che il processo di rooting è molto pericoloso e può danneggiare gravemente il dispositivo.
|
||||
|
|
@ -109,7 +109,7 @@ Una volta che un dispositivo è rootato, qualsiasi app potrebbe richiedere acces
|
|||
|
||||
Nello sviluppo Android, **Java o Kotlin** viene utilizzato per creare app. Invece di utilizzare la JVM come nelle app desktop, Android compila questo codice in **bytecode Dalvik Executable (DEX)**. In passato, la macchina virtuale Dalvik gestiva questo bytecode, ma ora, l'Android Runtime (ART) prende il sopravvento nelle versioni più recenti di Android.
|
||||
|
||||
Per il reverse engineering, **Smali** diventa cruciale. È la versione leggibile dall'uomo del bytecode DEX, agendo come un linguaggio assembly traducendo il codice sorgente in istruzioni bytecode. Smali e baksmali si riferiscono agli strumenti di assemblaggio e disassemblaggio in questo contesto.
|
||||
Per il reverse engineering, **Smali** diventa cruciale. È la versione leggibile dall'uomo del bytecode DEX, che agisce come un linguaggio assembly traducendo il codice sorgente in istruzioni bytecode. Smali e baksmali si riferiscono agli strumenti di assemblaggio e disassemblaggio in questo contesto.
|
||||
|
||||
## Intents
|
||||
|
||||
|
|
@ -161,7 +161,7 @@ Un intent-filter deve corrispondere all'**azione**, ai **dati** e alla **categor
|
|||
|
||||
Il processo di "risoluzione dell'Intent" determina quale app dovrebbe ricevere ciascun messaggio. Questo processo considera l'**attributo di priorità**, che può essere impostato nella **dichiarazione dell'intent-filter**, e **quella con la priorità più alta sarà selezionata**. Questa priorità può essere impostata tra -1000 e 1000 e le applicazioni possono utilizzare il valore `SYSTEM_HIGH_PRIORITY`. Se si verifica un **conflitto**, appare una finestra "choser" in modo che **l'utente possa decidere**.
|
||||
|
||||
### Intents Espliciti
|
||||
### Explicit Intents
|
||||
|
||||
Un intent esplicito specifica il nome della classe che sta mirando:
|
||||
```java
|
||||
|
|
@ -181,7 +181,7 @@ Questi consentono ad altre applicazioni di **eseguire azioni per conto della tua
|
|||
|
||||
A differenza degli intent precedenti, che sono ricevuti solo da un'app, gli intent broadcast **possono essere ricevuti da più app**. Tuttavia, dalla versione API 14, è **possibile specificare l'app che dovrebbe ricevere** il messaggio utilizzando Intent.setPackage.
|
||||
|
||||
In alternativa, è anche possibile **specificare un permesso quando si invia il broadcast**. L'app ricevente dovrà avere quel permesso.
|
||||
In alternativa, è anche possibile **specificare un permesso quando si invia il broadcast**. L'app ricevente avrà bisogno di avere quel permesso.
|
||||
|
||||
Ci sono **due tipi** di Broadcast: **Normale** (asincrono) e **Ordinato** (sincrono). L'**ordine** si basa sulla **priorità configurata all'interno dell'elemento ricevente**. **Ogni app può elaborare, inoltrare o scartare il Broadcast.**
|
||||
|
||||
|
|
@ -190,15 +190,15 @@ Puoi anche utilizzare la funzione **`sendBroadcast`** dal **`LocalBroadCastManag
|
|||
|
||||
### Sticky Broadcasts
|
||||
|
||||
Questo tipo di Broadcasts **può essere accessibile a lungo dopo che sono stati inviati**.\
|
||||
Questo tipo di Broadcasts **può essere accessibile molto tempo dopo che sono stati inviati**.\
|
||||
Questi sono stati deprecati a livello API 21 ed è consigliato **non usarli**.\
|
||||
**Consentono a qualsiasi applicazione di intercettare i dati, ma anche di modificarli.**
|
||||
**Consentono a qualsiasi applicazione di sniffare i dati, ma anche di modificarli.**
|
||||
|
||||
Se trovi funzioni contenenti la parola "sticky" come **`sendStickyBroadcast`** o **`sendStickyBroadcastAsUser`**, **controlla l'impatto e cerca di rimuoverle**.
|
||||
|
||||
## Deep links / URL schemes
|
||||
|
||||
Nelle applicazioni Android, **deep links** vengono utilizzati per avviare un'azione (Intent) direttamente tramite un URL. Questo viene fatto dichiarando uno specifico **URL scheme** all'interno di un'attività. Quando un dispositivo Android cerca di **accedere a un URL con questo schema**, l'attività specificata all'interno dell'applicazione viene avviata.
|
||||
Nelle applicazioni Android, **deep links** vengono utilizzati per avviare un'azione (Intent) direttamente tramite un URL. Questo viene fatto dichiarando un **URL scheme** specifico all'interno di un'attività. Quando un dispositivo Android cerca di **accedere a un URL con questo schema**, l'attività specificata all'interno dell'applicazione viene avviata.
|
||||
|
||||
Lo schema deve essere dichiarato nel file **`AndroidManifest.xml`**:
|
||||
```xml
|
||||
|
|
@ -212,9 +212,9 @@ Lo schema deve essere dichiarato nel file **`AndroidManifest.xml`**:
|
|||
</intent-filter>
|
||||
[...]
|
||||
```
|
||||
Lo schema dell'esempio precedente è `exampleapp://` (nota anche il **`category BROWSABLE`**)
|
||||
Lo schema dell'esempio precedente è `examplescheme://` (nota anche il **`category BROWSABLE`**)
|
||||
|
||||
Quindi, nel campo dei dati, puoi specificare l'**host** e il **path**:
|
||||
Quindi, nel campo dati, puoi specificare l'**host** e il **path**:
|
||||
```xml
|
||||
<data android:scheme="examplescheme"
|
||||
android:host="example"
|
||||
|
|
@ -249,7 +249,7 @@ Questi includono: **Attività, Servizi, Ricevitori di Broadcast e Provider.**
|
|||
|
||||
Nelle app Android, le **attività** sono come schermi, mostrando diverse parti dell'interfaccia utente dell'app. Un'app può avere molte attività, ognuna delle quali presenta uno schermo unico all'utente.
|
||||
|
||||
L'**attività di lancio** è il principale gateway a un'app, avviata quando tocchi l'icona dell'app. È definita nel file manifest dell'app con intent specifici MAIN e LAUNCHER:
|
||||
L'**attività di lancio** è il principale gateway per un'app, avviata quando tocchi l'icona dell'app. È definita nel file manifest dell'app con intent specifici MAIN e LAUNCHER:
|
||||
```markup
|
||||
<activity android:name=".LauncherActivity">
|
||||
<intent-filter>
|
||||
|
|
@ -362,11 +362,11 @@ Per controllare l'accesso ai file:
|
|||
|
||||
### **Verifica dell'App per Maggiore Sicurezza**
|
||||
|
||||
- A partire da **Android 4.2**, una funzione chiamata **Verifica App** consente agli utenti di far controllare le app per la sicurezza prima dell'installazione. Questo **processo di verifica** può avvisare gli utenti contro app potenzialmente dannose, o addirittura prevenire l'installazione di app particolarmente dannose, migliorando la sicurezza dell'utente.
|
||||
- A partire da **Android 4.2**, una funzione chiamata **Verifica App** consente agli utenti di far controllare le app per la sicurezza prima dell'installazione. Questo **processo di verifica** può avvisare gli utenti contro app potenzialmente dannose, o addirittura prevenire l'installazione di quelle particolarmente dannose, migliorando la sicurezza dell'utente.
|
||||
|
||||
### **Gestione dei Dispositivi Mobili (MDM)**
|
||||
|
||||
- Le **soluzioni MDM** forniscono **supervisione e sicurezza** per i dispositivi mobili attraverso l'**API di Amministrazione Dispositivo**. Richiedono l'installazione di un'app Android per gestire e proteggere efficacemente i dispositivi mobili. Le funzioni chiave includono **imposizione di politiche di password**, **obbligo di crittografia dello storage**, e **permissibilità di cancellazione remota dei dati**, garantendo un controllo e una sicurezza completi sui dispositivi mobili.
|
||||
- Le **soluzioni MDM** forniscono **supervisione e sicurezza** per i dispositivi mobili attraverso l'**API di Amministrazione Dispositivi**. Richiedono l'installazione di un'app Android per gestire e proteggere efficacemente i dispositivi mobili. Le funzioni chiave includono **imposizione di politiche di password**, **obbligo di crittografia dello storage**, e **permettere la cancellazione remota dei dati**, garantendo un controllo e una sicurezza completi sui dispositivi mobili.
|
||||
```java
|
||||
// Example of enforcing a password policy with MDM
|
||||
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
|
||||
|
|
|
|||
Loading…
Reference in a new issue