Autorizzazioni personalizzate

Categoria OWASP: MASVS-CODE: Qualità del codice

Panoramica

I rischi associati alle autorizzazioni personalizzate si verificano quando la definizione delle autorizzazioni personalizzate non è presente o è scritta in modo errato oppure quando l'attributo android:protectionLevel corrispondente viene utilizzato in modo improprio all'interno del file manifest.

Ad esempio, questi rischi possono essere sfruttati creando un'autorizzazione personalizzata con lo stesso nome, ma definita da un'app dannosa e con livelli di protezione diversi applicati.

Le autorizzazioni personalizzate sono progettate per consentire la condivisione di risorse e funzionalità con altre app. Ecco alcuni esempi di utilizzo legittimo delle autorizzazioni personalizzate:

  • Controllo della comunicazione tra i processi (IPC) tra due o più app
  • Accesso a servizi di terze parti
  • Limitare l'accesso ai dati condivisi di un'app

Impatto

Lo sfruttamento di questa vulnerabilità potrebbe consentire a un'app dannosa di accedere alle risorse originariamente destinate a essere protette. Le implicazioni della vulnerabilità dipendono dalla risorsa protetta e dalle autorizzazioni associate al servizio dell'applicazione originale.

Rischio: errori ortografici nelle autorizzazioni personalizzate

Nel file manifest potrebbe essere dichiarata un'autorizzazione personalizzata, ma per proteggere i componenti Android esportati viene utilizzata un'altra autorizzazione personalizzata a causa di un errore ortografico. Un'app danosa può trarre vantaggio dalle applicazioni che hanno scritto male un'autorizzazione in uno dei seguenti modi:

  • Devi prima registrare l'autorizzazione
  • Anticipare l'ortografia nelle applicazioni successive

In questo modo, un'applicazione può ottenere l'accesso non autorizzato alle risorse o il controllo sull'applicazione vittima.

Ad esempio, un'app vulnerabile vuole proteggere un componente utilizzando un'autorizzazione READ_CONTACTS, ma inserisce accidentalmente l'autorizzazione READ_CONACTS. Un'app dannosa può rivendicare READ_CONACTS poiché non è di proprietà di alcuna applicazione (o del sistema) e ottenere l'accesso al componente protetto. Un'altra variante comune di questa vulnerabilità è android:permission=True. Valori come true e false, indipendentemente dalle lettere maiuscole, sono input non validi per la dichiarazione delle autorizzazioni e vengono trattati in modo simile ad altri errori ortografici della dichiarazione delle autorizzazioni personalizzate. Per risolvere il problema, il valore dell'attributo android:permission deve essere modificato in una stringa di autorizzazione valida. Ad esempio, se l'app deve accedere ai contatti dell'utente, il valore dell'attributo android:permission deve essere android.permission.READ_CONTACTS.

Mitigazioni

Controlli Lint di Android

Quando dichiari le autorizzazioni personalizzate, utilizza i controlli di lint di Android per aiutarti a trovare errori ortografici e altri potenziali errori nel codice.

Convenzione di denominazione

Usa una convenzione di denominazione coerente per rendere più evidenti gli errori di battitura. Controlla attentamente la presenza di errori ortografici nelle dichiarazioni delle autorizzazioni personalizzate nel file manifest della tua app.

Rischio: autorizzazioni orfane

Le autorizzazioni vengono utilizzate per proteggere le risorse delle app. Esistono due diverse posizioni in cui un'app può dichiarare le autorizzazioni necessarie per accedere alle risorse:

Tuttavia, a volte queste autorizzazioni non sono definite da un tag <permission> corrispondente in un file manifest di un APK sul dispositivo. In questo caso, vengono chiamate autorizzazioni orfane. Questa situazione può verificarsi per diversi motivi, ad esempio:

  • Potrebbe esserci una mancata sincronizzazione tra gli aggiornamenti del file manifest e il codice con il controllo delle autorizzazioni
  • L'APK con le autorizzazioni potrebbe non essere incluso nella build o potrebbe essere inclusa la versione sbagliata
  • Il nome dell'autorizzazione nel controllo o nel file manifest potrebbe essere scritto in modo errato

Un'app dannosa potrebbe definire un'autorizzazione orfana e acquisirla. In questo caso, le applicazioni privilegiate che ritengono attendibile l'autorizzazione orfana per proteggere un componente potrebbero essere compromesse.

Se l'app con privilegi utilizza l'autorizzazione per proteggere o limitare un componente, l'app dannosa potrebbe ottenere l'accesso a quel componente. Alcuni esempi sono l'avvio di attività protette da un'autorizzazione, l'accesso a un fornitore di contenuti o la trasmissione a un ricevitore di trasmissione protetto dall'autorizzazione orfana.

Potrebbe anche creare una situazione in cui l'applicazione con privilegi viene indotti con l'inganno a ritenere che l'app dannosa sia un'app legittima e quindi a caricare file o contenuti.

Mitigazioni

Assicurati che tutte le autorizzazioni personalizzate utilizzate dalla tua app per proteggere i componenti siano anche definite nel file manifest.

L'app utilizza le autorizzazioni personalizzate my.app.provider.READ e my.app.provider.WRITE per proteggere l'accesso a un fornitore di contenuti:

XML

<provider android:name="my.app.database.CommonContentProvider" android:readPermission="my.app.provider.READ" android:writePermission="my.app.provider.WRITE" android:exported="true" android:process=":myappservice" android:authorities="my.app.database.contentprovider"/>

L'app definisce e utilizza anche queste autorizzazioni personalizzate, impedendo così ad altre app dannose di farlo:

Xml

<permission android:name="my.app.provider.READ"/>
<permission android:name="my.app.provider.WRITE"/>
<uses-permission android:name="my.app.provider.READ" />
<uses-permission android:name="my.app.provider.WRITE" />

Rischio: utilizzo improprio di android:protectionLevel

Questo attributo descrive il potenziale livello di rischio dell'autorizzazione e indica le procedure che il sistema deve seguire per decidere se concedere o meno l'autorizzazione.

Mitigazioni

Evitare il livello di protezione Normale o Pericoloso

Se utilizzi un protectionLevel normale o pericoloso per le tue autorizzazioni, significa che la maggior parte delle app può richiedere e ottenere l'autorizzazione:

  • "normale" richiede solo la dichiarazione
  • "pericoloso" verrà approvato da molti utenti

Pertanto, questi protectionLevels offrono poca sicurezza.

Utilizzare le autorizzazioni di firma (Android >= 10)

Se possibile, utilizza i livelli di protezione delle firme. L'utilizzo di questa funzionalità garantisce che solo altre app firmate con lo stesso certificato dell'app che ha creato l'autorizzazione possano accedere a queste funzionalità protette. Assicurati di utilizzare un certificato di firma dedicato (non riutilizzato) e archivialo in modo sicuro in un keystore.

Definisci un'autorizzazione personalizzata nel file manifest come segue:

Xml

<permission
    android:name="my.custom.permission.MY_PERMISSION"
    android:protectionLevel="signature"/>

Limita l'accesso, ad esempio a un'attività, solo alle app a cui è stata concessa questa autorizzazione personalizzata, come segue:

Xml

<activity android:name=".MyActivity" android:permission="my.custom.permission.MY_PERMISSION"/>

A qualsiasi altra app firmata con lo stesso certificato dell'app che ha dichiarato questa autorizzazione personalizzata verrà concesso l'accesso all'attività .MyActivity e dovrà dichiararla nel file manifest come segue:

Xml

<uses-permission android:name="my.custom.permission.MY_PERMISSION" />

Fai attenzione alle autorizzazioni personalizzate per le firme (Android < 10)

Se la tua app ha come target Android < 10, ogni volta che le autorizzazioni personalizzate dell'app vengono rimosse a causa di disinstallazioni o aggiornamenti, potrebbero esserci app dannose in grado di continuare a utilizzare queste autorizzazioni personalizzate e quindi bypassare i controlli. Il motivo è una vulnerabilità di escalation dei privilegi (CVE-2019-2200) che è stata corretta in Android 10.

Questo è uno dei motivi (oltre al rischio di condizioni di gara) per cui è consigliabile utilizzare i controlli delle firme anziché le autorizzazioni personalizzate.

Rischio: condizione di gara

Se un'app legittima A definisce un'autorizzazione personalizzata per la firma utilizzata da altre app X, ma viene successivamente disinstallata, un'app dannosa B può definire la stessa autorizzazione personalizzata con un protectionLevel diverso, ad esempio normale. In questo modo, B ottiene l'accesso a tutti i componenti protetti da quell'autorizzazione personalizzata nelle app X senza dover essere firmata con lo stesso certificato dell'app A.

Lo stesso accade se l'app B viene installata prima del giorno A.

Mitigazioni

Se vuoi rendere un componente disponibile solo per le app firmate con la stessa firma dell'app che lo fornisce, potresti evitare di definire autorizzazioni personalizzate per limitare l'accesso a quel componente. In questo caso, puoi utilizzare i controlli delle firme. Quando una delle tue app effettua una richiesta per un'altra delle tue app, la seconda app può verificare che entrambe le app siano firmate con lo stesso certificato prima di soddisfare la richiesta.

Risorse