Autorizzazioni personalizzate

Categoria OWASP: MASVS-CODE: Code Quality

Panoramica

I rischi associati alle autorizzazioni personalizzate si presentano quando la definizione delle autorizzazioni personalizzate è mancante o errata o quando l'attributo android:protectionLevel corrispondente viene utilizzato in modo improprio nel 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.

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

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

Impatto

L'impatto dello sfruttamento di questa vulnerabilità è che un'app dannosa potrebbe ottenere l'accesso a risorse originariamente destinate a essere protette. Le implicazioni della vulnerabilità dipendono dalla risorsa protetta e dalle autorizzazioni associate del servizio applicazione originale.

Rischio: errori di battitura nelle autorizzazioni personalizzate

Nel manifest può essere dichiarata un'autorizzazione personalizzata, ma viene utilizzata un'autorizzazione personalizzata diversa per proteggere i componenti Android esportati a causa di un errore di battitura. Un'applicazione dannosa può sfruttare le applicazioni che hanno scritto in modo errato un'autorizzazione:

  • Registrando prima questa autorizzazione
  • Anticipare l'ortografia nelle applicazioni successive

Ciò può consentire a un'applicazione l'accesso non autorizzato alle risorse o il controllo dell'applicazione vittima.

Ad esempio, un'app vulnerabile vuole proteggere un componente utilizzando un'autorizzazione READ_CONTACTS, ma per errore la scrive in modo errato come 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 maiuscole, sono input non validi per la dichiarazione delle autorizzazioni e vengono trattati in modo simile ad altri errori di battitura nella 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 autorizzazioni personalizzate, utilizza i controlli lint di Android per trovare errori di battitura e altri potenziali errori nel codice.

Convenzione di denominazione

Utilizza una convenzione di denominazione coerente per rendere più evidenti gli errori di battitura. Controlla attentamente le dichiarazioni delle autorizzazioni personalizzate nel manifest della tua app per verificare che non ci siano errori di battitura.

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 richieste 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 verificarsi una mancata sincronizzazione tra gli aggiornamenti del manifest e il codice con il controllo delle autorizzazioni
  • L'APK con le autorizzazioni potrebbe non essere incluso nella build oppure potrebbe essere inclusa la versione sbagliata
  • Il nome dell'autorizzazione nel controllo o nel manifest potrebbe essere scritto in modo errato

Un'app dannosa potrebbe definire un'autorizzazione orfana e acquisirla. Se ciò accade, le applicazioni privilegiate che si affidano all'autorizzazione orfana per proteggere un componente potrebbero essere compromesse.

Nei casi in cui l'app con privilegi utilizza l'autorizzazione per proteggere o limitare qualsiasi componente, ciò potrebbe concedere all'app dannosa l'accesso a quel componente. Esempi includono l'avvio di attività protette da un'autorizzazione, l'accesso a un provider di contenuti o la trasmissione a un broadcast receiver protetto dall'autorizzazione orfana.

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

Mitigazioni

Assicurati che tutte le autorizzazioni personalizzate che la tua app utilizza per proteggere i componenti siano definite anche nel 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: android:protectionLevel utilizzato in modo improprio

Questo attributo descrive il potenziale livello di rischio nell'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

L'utilizzo di un'autorizzazione normale o pericolosa protectionLevel significa che la maggior parte delle app può richiedere e ottenere l'autorizzazione:

  • "normale" richiede solo la dichiarazione
  • "dangerous" will be approved by many users

Pertanto, questi protectionLevels offrono poca sicurezza.

Utilizzare le autorizzazioni di firma (Android >= 10)

Utilizza i livelli di protezione della firma ove possibile. 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 di archiviarlo in modo sicuro in un archivio chiavi.

Definisci un'autorizzazione personalizzata come segue nel manifest:

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 deve dichiararla nel file manifest come segue:

Xml

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

Attenzione alle autorizzazioni personalizzate della firma (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 utilizzare ancora queste autorizzazioni personalizzate e quindi aggirare i controlli. Ciò è dovuto a una vulnerabilità di escalation dei privilegi (CVE-2019-2200) che è stata corretta in Android 10.

Questo è uno dei motivi (insieme al rischio di race condition) per cui i controlli della firma sono consigliati rispetto alle autorizzazioni personalizzate.

Rischio: race condition

Se un'app legittima A definisce un'autorizzazione personalizzata con 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 questa autorizzazione personalizzata nelle app X senza bisogno di essere firmata con lo stesso certificato dell'app A.

Lo stesso accade se B viene installato prima di 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 questa situazione, puoi utilizzare i controlli della firma. 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