Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/mobile-pentesting/android-app-pentesting/android-applications-basics.md

30 KiB
Raw Blame History

Concetti di base delle applicazioni Android

Impara l'hacking di AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

Modello di sicurezza Android

Ci sono due livelli:

  • Il SO, che mantiene le applicazioni installate isolate l'una dall'altra.
  • L'applicazione stessa, che consente agli sviluppatori di esporre determinate funzionalità e configurare le capacità dell'applicazione.

Separazione UID

A ciascuna applicazione viene assegnato un ID utente specifico. Questo avviene durante l'installazione dell'app in modo che l'app possa interagire solo con i file di proprietà del suo ID utente o condivisi. Pertanto, solo l'app stessa, determinati componenti del SO e l'utente root possono accedere ai dati delle app.

Condivisione UID

Due applicazioni possono essere configurate per utilizzare lo stesso UID. Questo può essere utile per condividere informazioni, ma se una di esse viene compromessa, i dati di entrambe le applicazioni saranno compromessi. Per questo motivo questo comportamento è sconsigliato.
Per condividere lo stesso UID, le applicazioni devono definire lo stesso valore android:sharedUserId nei loro manifesti.

Isolamento

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 da altre app.
A partire da Android 5.0(L) SELinux è obbligatorio. Fondamentalmente, SELinux nega tutte le interazioni dei processi e quindi crea delle politiche per consentire solo le interazioni previste tra di loro.

Autorizzazioni

Quando si installa un'app e richiede autorizzazioni, l'app sta chiedendo le autorizzazioni configurate negli elementi uses-permission nel file AndroidManifest.xml. L'elemento uses-permission indica il nome dell'autorizzazione richiesta all'interno dell'attributo name. Ha anche l'attributo maxSdkVersion che smette di chiedere autorizzazioni su versioni superiori a quella specificata.
Nota che le applicazioni Android non devono chiedere tutte le autorizzazioni all'inizio, possono anche chiedere autorizzazioni dinamicamente ma tutte le autorizzazioni devono essere dichiarate nel manifest.

Quando un'app espone funzionalità può limitare l'accesso solo alle app che hanno una determinata autorizzazione.
Un elemento di autorizzazione ha tre attributi:

  • Il nome dell'autorizzazione
  • L'attributo permission-group, che consente di raggruppare autorizzazioni correlate.
  • Il livello di protezione che indica come vengono concesse le autorizzazioni. Ci sono quattro tipi:
  • Normale: Usato quando non ci sono minacce conosciute per l'app. All'utente non è richiesto di approvarla.
  • Pericoloso: Indica che l'autorizzazione concede all'applicazione richiedente un accesso elevato. Gli utenti sono invitati ad approvarle.
  • Firma: Solo app firmate dallo stesso certificato di quello che esporta il componente possono ottenere l'autorizzazione. Questo è il tipo di protezione più forte.
  • FirmaOSystema: Solo app firmate dallo stesso certificato di quello che esporta il componente o app in esecuzione con accesso a livello di sistema possono ottenere autorizzazioni

Applicazioni preinstallate

Queste app si trovano generalmente nelle directory /system/app o /system/priv-app e alcune di esse sono ottimizzate (potresti non trovare nemmeno il file classes.dex). Queste applicazioni meritano attenzione perché a volte funzionano con troppe autorizzazioni (come root).

  • Quelle fornite con il ROM AOSP (Android OpenSource Project)
  • Aggiunte dal produttore del dispositivo
  • Aggiunte dal provider del telefono cellulare (se acquistato da loro)

Rooting

Per ottenere l'accesso root a un dispositivo Android fisico è generalmente necessario sfruttare 1 o 2 vulnerabilità che solitamente sono specifiche per il dispositivo e la versione.
Una volta che l'exploit ha funzionato, di solito il binario Linux su viene copiato in una posizione specificata nella variabile di ambiente PATH dell'utente come /system/xbin.

Una volta configurato il binario su, un'altra app Android viene utilizzata per interfacciarsi con il binario su e elaborare le richieste di accesso root come Superuser e SuperSU (disponibili su Google Play Store).

{% hint style="danger" %} Nota che il processo di rooting è molto pericoloso e può danneggiare gravemente il dispositivo {% endhint %}

ROM

È possibile sostituire il sistema operativo installando un firmware personalizzato. Facendo ciò è possibile estendere l'utilità di un vecchio dispositivo, bypassare le restrizioni software o accedere al codice Android più recente.
OmniROM e LineageOS sono due dei firmware più popolari da utilizzare.

Nota che non è sempre necessario eseguire il root del dispositivo per installare un firmware personalizzato. Alcuni produttori consentono lo sblocco dei loro bootloader in modo ben documentato e sicuro.

Implicazioni

Una volta che un dispositivo è stato sradicato, qualsiasi app potrebbe richiedere l'accesso come root. Se un'applicazione dannosa lo ottiene, potrà accedere a quasi tutto e sarà in grado di danneggiare il telefono.

Fondamenti delle Applicazioni Android

  • Il formato delle applicazioni Android è chiamato formato file APK. È essenzialmente un file ZIP (rinominando l'estensione del file in .zip, è possibile estrarre e visualizzare i contenuti).
  • Contenuti APK (non esaustivi)
  • AndroidManifest.xml
  • resources.arsc/strings.xml
  • resources.arsc: contiene risorse precompilate, come XML binario.
  • res/xml/files_paths.xml
  • META-INF/
  • Qui si trova il Certificato!
  • classes.dex
  • Contiene bytecode Dalvik, che rappresenta il codice Java (o Kotlin) compilato che l'applicazione esegue per impostazione predefinita.
  • lib/
  • Contiene librerie native, suddivise per architettura CPU in sottodirectory.
  • armeabi: codice per processori basati su ARM
  • armeabi-v7a: codice per processori basati su ARMv7 e superiori
  • x86: codice per processori X86
  • mips: codice solo per processori MIPS
  • assets/
  • Conserva file vari necessari dall'app, potenzialmente inclusi ulteriori librerie native o file DEX, talvolta utilizzati dagli autori di malware per nascondere codice aggiuntivo.
  • res/
  • Contiene risorse che non sono compilate in resources.arsc

Dalvik & Smali

Nello sviluppo Android, Java o Kotlin vengono utilizzati per creare app. Invece di utilizzare la JVM come nelle app desktop, Android compila questo codice in Dalvik Executable (DEX) bytecode. In passato, la macchina virtuale Dalvik gestiva questo bytecode, ma ora, nelle versioni più recenti di Android, subentra l'Android Runtime (ART).

Per l'ingegneria inversa, Smali diventa cruciale. È la versione leggibile dall'uomo del bytecode DEX, agendo come linguaggio assembly traducendo il codice sorgente in istruzioni bytecode. Smali e baksmali si riferiscono agli strumenti di assemblaggio e disassemblaggio in questo contesto.

Intents

Gli Intents sono il principale mezzo attraverso il quale le app Android comunicano tra i loro componenti o con altre app. Questi oggetti messaggio possono anche trasportare dati tra app o componenti, simile a come vengono utilizzate le richieste GET/POST nelle comunicazioni HTTP.

Quindi un Intent è fondamentalmente un messaggio che viene passato tra i componenti. Gli Intents possono essere diretti a componenti o app specifici, o possono essere inviati senza un destinatario specifico.
Per semplificare, un Intent può essere utilizzato per:

  • Avviare un'Attività, aprendo tipicamente un'interfaccia utente per un'app
  • Come trasmissioni per informare il sistema e le app di cambiamenti
  • Avviare, fermare e comunicare con un servizio in background
  • Accedere ai dati tramite ContentProviders
  • Come richiami per gestire eventi

Se vulnerabili, gli Intents possono essere utilizzati per eseguire una varietà di attacchi.

Intent-Filter

Gli Intent Filters definiscono come un'attività, un servizio o un ricevitore di trasmissioni possono interagire con diversi tipi di Intents. Essenzialmente, descrivono le capacità di questi componenti, come le azioni che possono eseguire o i tipi di trasmissioni che possono elaborare. Il luogo principale per dichiarare questi filtri è all'interno del file AndroidManifest.xml, anche se per i ricevitori di trasmissioni, è anche un'opzione codificarli.

Gli Intent Filters sono composti da categorie, azioni e filtri dati, con la possibilità di includere metadati aggiuntivi. Questa configurazione consente ai componenti di gestire Intents specifici che corrispondono ai criteri dichiarati.

Un aspetto critico dei componenti Android (attività/servizi/provider di contenuti/ricevitori di trasmissioni) è la loro visibilità o stato pubblico. Un componente è considerato pubblico e può interagire con altre app se è esportato con un valore di true o se è dichiarato un Intent Filter per esso nel manifesto. Tuttavia, c'è un modo per gli sviluppatori di mantenere esplicitamente privati questi componenti, garantendo che non interagiscano con altre app involontariamente. Ciò viene realizzato impostando l'attributo esportato su false nelle loro definizioni di manifesto.

Inoltre, gli sviluppatori hanno l'opzione di proteggere ulteriormente l'accesso a questi componenti richiedendo specifici permessi. L'attributo permission può essere impostato per garantire che solo le app con il permesso designato possano accedere al componente, aggiungendo un ulteriore livello di sicurezza e controllo su chi può interagire con esso.

<activity android:name=".MyActivity" android:exported="false">
<!-- Intent filters go here -->
</activity>

Intenti Impliciti

Gli intenti vengono creati programmaticamente utilizzando un costruttore Intent:

Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));

L'Azione dell'intento precedentemente dichiarato è ACTION_SEND e l'Extra è un Uri mailto (l'Extra è l'informazione aggiuntiva che l'intento si aspetta).

Questo intento dovrebbe essere dichiarato all'interno del manifesto come nell'esempio seguente:

<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>

Un intent-filter deve corrispondere all'azione, ai dati e alla categoria per ricevere un messaggio.

Il processo di "risoluzione dell'intento" determina quale app dovrebbe ricevere ciascun messaggio. Questo processo considera l'attributo di priorità, che può essere impostato nella dichiarazione dell'intent-filter, e quello con la priorità più alta verrà selezionato. Questa priorità può essere impostata tra -1000 e 1000 e le applicazioni possono utilizzare il valore SYSTEM_HIGH_PRIORITY. Se sorge un conflitto, compare una finestra "chooser" in modo che l'utente possa decidere.

Intenti Espliciti

Un intento esplicito specifica il nome della classe a cui si sta puntando:

Intent downloadIntent = new (this, DownloadService.class):

In altre applicazioni per accedere all'intento precedentemente dichiarato è possibile utilizzare:

Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);

Intenti Pendenti

Questi permettono ad altre applicazioni di eseguire azioni per conto della tua applicazione, utilizzando l'identità e i permessi della tua app. Per costruire un Intent Pendente, è necessario specificare un intent e l'azione da eseguire. Se l'intent dichiarato non è Esplicito (non dichiara quale intent può chiamarlo), un'applicazione malevola potrebbe eseguire l'azione dichiarata per conto dell'applicazione vittima. Inoltre, se un'azione non è specificata, l'app malevola sarà in grado di fare qualsiasi azione per conto della vittima.

Intenti di Broadcast

A differenza degli intenti precedenti, che vengono ricevuti solo da un'app, gli intenti di broadcast possono essere ricevuti da più app. Tuttavia, a partire dalla versione API 14, è possibile specificare l'app che dovrebbe ricevere il messaggio utilizzando Intent.setPackage.

In alternativa è anche possibile specificare un permesso durante l'invio del broadcast. L'app ricevente dovrà avere quel permesso.

Ci sono due tipi di Broadcast: Normale (asincrono) e Ordinato (sincrono). L'ordine è basato sulla priorità configurata all'interno del ricevitore. Ogni app può elaborare, inoltrare o eliminare il Broadcast.

È possibile inviare un broadcast utilizzando la funzione sendBroadcast(intent, receiverPermission) dalla classe Context.
È anche possibile utilizzare la funzione sendBroadcast dal LocalBroadCastManager per garantire che il messaggio non esca mai dall'app. Utilizzando questo metodo, non sarà nemmeno necessario esportare un componente ricevitore.

Broadcast Sticky

Questo tipo di Broadcast può essere accessibile molto tempo dopo essere stato inviato.
Sono stati deprecati nel livello API 21 ed è consigliato non utilizzarli.
Permettono a qualsiasi applicazione di intercettare i dati, ma anche di modificarli.

Se trovi funzioni contenenti la parola "sticky" come sendStickyBroadcast o sendStickyBroadcastAsUser, verifica l'impatto e cerca di rimuoverle.

Deep links / Schema URL

Nelle applicazioni Android, i deep link vengono utilizzati per avviare un'azione (Intent) direttamente tramite un URL. Ciò viene fatto dichiarando uno specifico schema URL all'interno di un'attività. Quando un dispositivo Android cerca di accedere a un URL con questo schema, viene avviata l'attività specificata all'interno dell'applicazione.

Lo schema deve essere dichiarato nel file AndroidManifest.xml:

[...]
<activity android:name=".MyActivity">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="examplescheme" />
</intent-filter>
[...]

Lo schema dell'esempio precedente è exampleapp:// (nota anche la categoria BROWSABLE)

Quindi, nel campo dati, puoi specificare l'host e il percorso:

<data android:scheme="examplescheme"
android:host="example"
/>

Per accedervi da un web è possibile impostare un link come:

<a href="examplescheme://example/something">click here</a>
<a href="examplescheme://example/javascript://%250dalert(1)">click here</a>

Per trovare il codice che verrà eseguito nell'App, vai all'attività chiamata dal deeplink e cerca la funzione onNewIntent.

Scopri come chiamare deep link senza utilizzare pagine HTML.

AIDL - Linguaggio di Definizione delle Interfacce Android

Il Linguaggio di Definizione delle Interfacce Android (AIDL) è progettato per facilitare la comunicazione tra client e servizio nelle applicazioni Android attraverso la comunicazione tra processi (IPC). Poiché su Android non è consentito accedere direttamente alla memoria di un altro processo, AIDL semplifica il processo marshalling degli oggetti in un formato comprensibile dal sistema operativo, facilitando così la comunicazione tra processi diversi.

Concetti Chiave

  • Servizi Vincolati: Questi servizi utilizzano AIDL per IPC, consentendo ad attività o componenti di collegarsi a un servizio, fare richieste e ricevere risposte. Il metodo onBind nella classe del servizio è fondamentale per avviare l'interazione, rendendolo una zona vitale per la revisione della sicurezza alla ricerca di vulnerabilità.

  • Messaggero: Operando come un servizio vincolato, il Messaggero facilita l'IPC con un focus sul trattamento dei dati attraverso il metodo onBind. È essenziale ispezionare attentamente questo metodo per qualsiasi gestione non sicura dei dati o esecuzione di funzioni sensibili.

  • Binder: Anche se l'uso diretto della classe Binder è meno comune a causa dell'astrazione di AIDL, è utile comprendere che Binder agisce come un driver a livello di kernel facilitando il trasferimento di dati tra gli spazi di memoria di processi diversi. Per una maggiore comprensione, è disponibile una risorsa su https://www.youtube.com/watch?v=O-UHvFjxwZ8.

Componenti

Queste includono: Attività, Servizi, Ricevitori di Broadcast e Provider.

Attività di Avvio e altre attività

Nelle app Android, le attività sono come schermate che mostrano diverse parti dell'interfaccia utente dell'app. Un'app può avere molte attività, ognuna presentando uno schermo unico all'utente.

L'attività di avvio è il principale gateway per un'app, avviato quando si tocca l'icona dell'app. Viene definito nel file di manifesto dell'app con specifici intent MAIN e LAUNCHER:

<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

Non tutte le app hanno bisogno di un'attività di lancio, specialmente quelle senza un'interfaccia utente, come i servizi in background.

Le attività possono essere rese disponibili ad altre app o processi contrassegnandole come "esportate" nel manifesto. Questa impostazione consente ad altre app di avviare questa attività:

<service android:name=".ExampleExportedService" android:exported="true"/>

Tuttavia, accedere a un'attività da un'altra app non è sempre un rischio per la sicurezza. La preoccupazione sorge se i dati sensibili vengono condivisi impropriamente, il che potrebbe portare a fughe di informazioni.

Il ciclo di vita di un'attività inizia con il metodo onCreate, impostando l'interfaccia utente e preparando l'attività per l'interazione con l'utente.

Sottoclasse dell'Applicazione

Nello sviluppo di Android, un'app ha l'opzione di creare una sottoclasse della classe Application, anche se non è obbligatorio. Quando viene definita una tale sottoclasse, diventa la prima classe istanziata all'interno dell'app. Il metodo attachBaseContext, se implementato in questa sottoclasse, viene eseguito prima del metodo onCreate. Questa configurazione consente una inizializzazione anticipata prima che il resto dell'applicazione inizi.

public class MyApp extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// Initialization code here
}

@Override
public void onCreate() {
super.onCreate();
// More initialization code
}
}

Servizi

I Servizi sono operazioni in background capaci di eseguire compiti senza un'interfaccia utente. Questi compiti possono continuare ad essere eseguiti anche quando gli utenti passano a diverse applicazioni, rendendo i servizi cruciali per le operazioni a lungo termine.

I servizi sono versatili; possono essere avviati in vari modi, con gli Intent che rappresentano il metodo principale per avviarli come punto di ingresso dell'applicazione. Una volta che un servizio viene avviato utilizzando il metodo startService, il suo metodo onStart entra in azione e continua ad essere eseguito fino a quando non viene chiamato esplicitamente il metodo stopService. In alternativa, se il ruolo di un servizio dipende da una connessione client attiva, viene utilizzato il metodo bindService per collegare il client al servizio, attivando il metodo onBind per il passaggio dei dati.

Un'applicazione interessante dei servizi include la riproduzione di musica in background o il recupero di dati di rete senza ostacolare l'interazione dell'utente con un'app. Inoltre, i servizi possono essere resi accessibili ad altri processi sullo stesso dispositivo tramite esportazione. Questo non è il comportamento predefinito e richiede una configurazione esplicita nel file Android Manifest:

<service android:name=".ExampleExportedService" android:exported="true"/>

Ricevitori di trasmissione

I ricevitori di trasmissione fungono da ascoltatori in un sistema di messaggistica, consentendo a più applicazioni di rispondere agli stessi messaggi provenienti dal sistema. Un'app può registrare un ricevitore in due modi principali: tramite il Manifest dell'app o dinamicamente all'interno del codice dell'app tramite l'API registerReceiver. Nel Manifest, le trasmissioni vengono filtrate con le autorizzazioni, mentre i ricevitori registrati dinamicamente possono anche specificare autorizzazioni durante la registrazione.

I filtri di intenti sono cruciali in entrambi i metodi di registrazione, determinando quali trasmissioni attivano il ricevitore. Una volta inviata una trasmissione corrispondente, viene invocato il metodo onReceive del ricevitore, consentendo all'app di reagire di conseguenza, ad esempio regolando il comportamento in risposta a un avviso di batteria scarica.

Le trasmissioni possono essere asincrone, raggiungendo tutti i ricevitori senza un ordine specifico, o sincrone, dove i ricevitori ricevono la trasmissione in base alle priorità impostate. Tuttavia, è importante notare il potenziale rischio per la sicurezza, poiché qualsiasi app può dare priorità a se stessa per intercettare una trasmissione.

Per comprendere la funzionalità di un ricevitore, cercare il metodo onReceive all'interno della sua classe. Il codice di questo metodo può manipolare l'Intent ricevuto, evidenziando la necessità di convalida dei dati da parte dei ricevitori, specialmente nelle Trasmissioni Ordinate, che possono modificare o eliminare l'Intent.

Provider di contenuti

I Provider di contenuti sono essenziali per condividere dati strutturati tra le app, sottolineando l'importanza dell'implementazione delle autorizzazioni per garantire la sicurezza dei dati. Consentono alle app di accedere ai dati da varie fonti, inclusi database, filesystem o web. Autorizzazioni specifiche, come readPermission e writePermission, sono cruciali per controllare l'accesso. Inoltre, l'accesso temporaneo può essere concesso tramite le impostazioni grantUriPermission nel manifesto dell'app, sfruttando attributi come path, pathPrefix e pathPattern per un controllo dettagliato dell'accesso.

La convalida dell'input è fondamentale per prevenire vulnerabilità, come l'SQL injection. I Provider di contenuti supportano operazioni di base: insert(), update(), delete() e query(), facilitando la manipolazione e la condivisione dei dati tra le applicazioni.

FileProvider, un Provider di contenuti specializzato, si concentra sulla condivisione sicura dei file. Viene definito nel manifesto dell'app con attributi specifici per controllare l'accesso alle cartelle, indicati da android:exported e android:resource che puntano alle configurazioni delle cartelle. Si consiglia cautela nella condivisione delle directory per evitare di esporre involontariamente dati sensibili.

Esempio di dichiarazione nel manifesto per FileProvider:

<provider android:name="androidx.core.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
android:grantUriPermissions="true"
android:exported="false">
<meta-data android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/filepaths" />
</provider>

E un esempio di specifica delle cartelle condivise in filepaths.xml:

<paths>
<files-path path="images/" name="myimages" />
</paths>

Per ulteriori informazioni controlla:

WebViews

Le WebViews sono come mini browser web all'interno delle app Android, che recuperano contenuti sia dal web che da file locali. Affrontano rischi simili ai browser tradizionali, ma ci sono modi per ridurre questi rischi attraverso impostazioni specifiche.

Android offre due tipi principali di WebView:

  • WebViewClient è ottimo per l'HTML di base ma non supporta la funzione di avviso JavaScript, influenzando come gli attacchi XSS possono essere testati.
  • WebChromeClient si comporta più come l'esperienza completa del browser Chrome.

Un punto chiave è che i browser WebView non condividono i cookie con il browser principale del dispositivo.

Per il caricamento dei contenuti, sono disponibili metodi come loadUrl, loadData, e loadDataWithBaseURL. È cruciale assicurarsi che questi URL o file siano sicuri da utilizzare. Le impostazioni di sicurezza possono essere gestite tramite la classe WebSettings. Ad esempio, disabilitare JavaScript con setJavaScriptEnabled(false) può prevenire gli attacchi XSS.

Il "Bridge" JavaScript consente agli oggetti Java di interagire con JavaScript, richiedendo che i metodi siano contrassegnati con @JavascriptInterface per la sicurezza da Android 4.2 in poi.

Consentire l'accesso ai contenuti (setAllowContentAccess(true)) consente alle WebViews di raggiungere i Content Providers, il che potrebbe essere un rischio a meno che gli URL dei contenuti siano verificati come sicuri.

Per controllare l'accesso ai file:

  • Disabilitare l'accesso ai file (setAllowFileAccess(false)) limita l'accesso al filesystem, con eccezioni per determinati asset, garantendo che siano utilizzati solo per contenuti non sensibili.

Altri Componenti dell'App e Gestione dei Dispositivi Mobili

Firma Digitale delle Applicazioni

  • La firma digitale è un must per le app Android, garantendo che siano autenticamente autenticate prima dell'installazione. Questo processo utilizza un certificato per l'identificazione dell'app e deve essere verificato dal package manager del dispositivo all'installazione. Le app possono essere auto-firmate o certificate da una CA esterna, proteggendo dall'accesso non autorizzato e garantendo che l'app rimanga intatta durante la consegna al dispositivo.

Verifica dell'App per una Sicurezza Potenziata

  • A partire da Android 4.2, una funzionalità chiamata Verifica App consente agli utenti di controllare la sicurezza delle app prima dell'installazione. Questo processo di verifica può avvisare gli utenti contro app potenzialmente dannose, o addirittura impedire l'installazione di quelle particolarmente maliziose, potenziando la sicurezza dell'utente.

Gestione dei Dispositivi Mobili (MDM)

  • Le soluzioni MDM forniscono controllo e sicurezza per i dispositivi mobili attraverso Device Administration API. Necessitano dell'installazione di un'app Android per gestire e proteggere efficacemente i dispositivi mobili. Le funzioni chiave includono l'applicazione di politiche di password, l'obbligo di crittografia dello storage, e il consenso al wipe remoto dei dati, garantendo un controllo e una sicurezza completi sui dispositivi mobili.
// Example of enforcing a password policy with MDM
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminComponent = new ComponentName(context, AdminReceiver.class);

if (dpm.isAdminActive(adminComponent)) {
// Set minimum password length
dpm.setPasswordMinimumLength(adminComponent, 8);
}

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

Impara l'hacking AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks: