Benutzerdefinierte Berechtigungen

OWASP-Kategorie: MASVS-CODE: Codequalität

Übersicht

Die mit benutzerdefinierten Berechtigungen verbundenen Risiken entstehen, wenn die Definition der benutzerdefinierten Berechtigungen fehlt oder falsch geschrieben ist oder wenn das entsprechende android:protectionLevel-Attribut im Manifest missbraucht wird.

Diese Risiken können beispielsweise ausgenutzt werden, indem eine benutzerdefinierte Berechtigung mit demselben Namen erstellt wird, die jedoch von einer schädlichen App definiert und mit unterschiedlichen Schutzebenen angewendet wird.

Mit benutzerdefinierten Berechtigungen können Sie Ressourcen und Funktionen für andere Apps freigeben. Beispiele für eine rechtmäßige Verwendung benutzerdefinierter Berechtigungen:

  • Inter-Process-Kommunikation (IPC) zwischen zwei oder mehr Anwendungen steuern
  • Zugriff auf Dienste von Drittanbietern
  • Zugriff auf die freigegebenen Daten einer App einschränken

Positiv beeinflussen

Die Ausnutzung dieser Sicherheitslücke hat zur Folge, dass eine schädliche Anwendung Zugriff auf Ressourcen erlangen könnte, die ursprünglich geschützt werden sollten. Die Auswirkungen der Sicherheitslücke hängen von der geschützten Ressource und den zugehörigen Berechtigungen des ursprünglichen Anwendungsdienstes ab.

Risiko: Tippfehler bei benutzerdefinierten Berechtigungen

Im Manifest kann eine benutzerdefinierte Berechtigung deklariert werden, aber aufgrund eines Tippfehlers wird eine andere benutzerdefinierte Berechtigung zum Schutz der exportierten Android-Komponenten verwendet. Eine schädliche Anwendung kann Apps ausnutzen, bei denen eine Berechtigung falsch geschrieben wurde, indem sie

  • Diese Berechtigung zuerst registrieren
  • Rechtschreibung in nachfolgenden Anwendungen antizipieren

Dies kann einer Anwendung den unbefugten Zugriff auf Ressourcen oder die Kontrolle über die angegriffene Anwendung ermöglichen.

Beispiel: In einer angreifbaren App soll eine Komponente mithilfe der Berechtigung READ_CONTACTS geschützt werden, aber die Berechtigung wird versehentlich als READ_CONACTS geschrieben. Eine schädliche Anwendung kann READ_CONACTS beanspruchen, da sie keiner Anwendung (oder dem System) gehört und Zugriff auf die geschützte Komponente erhält. Eine weitere gängige Variante dieser Sicherheitslücke ist android:permission=True. Werte wie true und false sind unabhängig von der Groß- und Kleinschreibung ungültige Eingaben für die Berechtigungsdeklaration und werden wie Tippfehler in anderen benutzerdefinierten Berechtigungsdeklarationen behandelt. Um das Problem zu beheben, muss der Wert des Attributs android:permission in einen gültigen Berechtigungsstring geändert werden. Wenn die App beispielsweise auf die Kontakte des Nutzers zugreifen muss, sollte das Attribut android:permission den Wert android.permission.READ_CONTACTS haben.

Abhilfemaßnahmen

Android Lint-Prüfungen

Wenn Sie benutzerdefinierte Berechtigungen deklarieren, können Sie mit Android-Lint-Prüfungen Tippfehler und andere potenzielle Fehler in Ihrem Code finden.

Namenskonvention

Verwenden Sie eine einheitliche Namenskonvention, damit Tippfehler leichter zu erkennen sind. Prüfen Sie die Erklärungen zu benutzerdefinierten Berechtigungen im Manifest Ihrer App sorgfältig auf Tippfehler.

Risiko: Verwaiste Berechtigungen

Berechtigungen werden verwendet, um die Ressourcen von Apps zu schützen. Es gibt zwei verschiedene Standorte, an denen eine Anwendung die für den Zugriff auf Ressourcen erforderlichen Berechtigungen deklarieren kann:

Manchmal sind diese Berechtigungen jedoch nicht durch ein entsprechendes <permission>-Tag in einem Manifest eines APK auf dem Gerät definiert. In diesem Fall werden sie als verwaiste Berechtigungen bezeichnet. Das kann verschiedene Ursachen haben, z. B.:

  • Es kann zu einer Desynchronisierung zwischen den Aktualisierungen im Manifest und dem Code mit der Berechtigungsprüfung kommen.
  • Das APK mit den Berechtigungen ist möglicherweise nicht im Build enthalten oder es ist die falsche Version enthalten
  • Der Name der Berechtigung in der Prüfung oder im Manifest könnte falsch geschrieben sein.

Eine schädliche App könnte eine verwaiste Berechtigung definieren und erwerben. In diesem Fall können die privilegierten Anwendungen, die der verwaisten Berechtigung vertrauen, um eine Komponente zu schützen, manipuliert werden.

Wenn die App mit erhöhten Berechtigungen die Berechtigung verwendet, um eine Komponente zu schützen oder einzuschränken, kann dies der schädlichen App Zugriff auf diese Komponente gewähren. Beispiele hierfür sind das Starten von Aktivitäten, die durch eine Berechtigung geschützt sind, der Zugriff auf einen Inhaltsanbieter oder die Übertragung an einen Broadcastempfänger, der durch die verwaiste Berechtigung geschützt ist.

Es kann auch zu einer Situation kommen, in der die privilegierte Anwendung dazu verleitet wird, zu glauben, dass die schädliche App eine legitime App ist, und daher Dateien oder Inhalte lädt.

Abwehrmaßnahmen

Achten Sie darauf, dass alle benutzerdefinierten Berechtigungen, die Ihre App zum Schutz von Komponenten verwendet, auch in Ihrem Manifest definiert sind.

Die App verwendet die benutzerdefinierten Berechtigungen my.app.provider.READ und my.app.provider.WRITE, um den Zugriff auf einen Contentanbieter zu schützen:

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"/>

Die App definiert und verwendet auch diese benutzerdefinierten Berechtigungen, um zu verhindern, dass andere schädliche Apps dies tun:

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" />

Risiko: Missbrauch von android:protectionLevel

Dieses Attribut beschreibt das potenzielle Risikoniveau in der Berechtigung und gibt an, wie das System entscheiden soll, ob die Berechtigung gewährt wird oder nicht.

Abwehrmaßnahmen

Vermeiden Sie das Schutzniveau „Normal“ oder „Gefährlich“

Wenn Sie eine normale oder riskante protectionLevel für Ihre Berechtigungen verwenden, können die meisten Apps die Berechtigung anfordern und erhalten:

  • Bei „normal“ muss es nur deklariert werden.
  • „gefährlich“ wird von vielen Nutzern genehmigt

Daher bieten diese protectionLevels nur wenig Sicherheit.

Signaturberechtigungen verwenden (Android >= 10)

Verwenden Sie nach Möglichkeit Signaturschutzstufen. Dadurch können nur andere Anwendungen, die mit demselben Zertifikat wie die App, die die Berechtigung erstellt hat, auf diese geschützten Funktionen zugreifen können. Verwenden Sie ein dediziertes (nicht wiederverwendetes) Signaturzertifikat und speichern Sie es sicher in einem Schlüsselspeicher.

Definieren Sie eine benutzerdefinierte Berechtigung in Ihrem Manifest so:

XML

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

Beschränken Sie beispielsweise den Zugriff auf eine Aktivität auf die Apps, denen diese benutzerdefinierte Berechtigung gewährt wurde:

XML

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

Jede andere App, die mit demselben Zertifikat signiert ist wie die App, die diese benutzerdefinierte Berechtigung erklärt hat, erhält dann Zugriff auf die .MyActivity-Aktivität und muss sie in ihrem Manifest so deklarieren:

XML

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

Vorsicht bei benutzerdefinierten Berechtigungen für Signaturen (Android < 10)

Wenn Ihre App auf Android < 10 ausgerichtet ist, können bösartige Apps, die die benutzerdefinierten Berechtigungen Ihrer App aufgrund von Deinstallationen oder Updates nicht mehr verwenden können, diese Berechtigungen weiterhin verwenden und so Prüfungen umgehen. Dies liegt an einer Sicherheitslücke bei der Rechteausweitung (CVE-2019-2200), die in Android 10 behoben wurde.

Dies ist einer der Gründe (und das Risiko von Race-Bedingungen), warum Signaturprüfungen gegenüber benutzerdefinierten Berechtigungen empfohlen werden.

Risiko: Race-Bedingung

Wenn eine legitime App A eine benutzerdefinierte Signaturberechtigung definiert, die von anderen X-Apps verwendet wird, aber anschließend deinstalliert wird, kann eine schädliche App B dieselbe benutzerdefinierte Berechtigung mit einer anderen protectionLevel definieren, z.B. normal. Auf diese Weise erhält B Zugriff auf alle Komponenten, die in den X-Apps durch diese benutzerdefinierte Berechtigung geschützt sind, ohne dass sie mit demselben Zertifikat wie die App A signiert werden müssen.

Dasselbe passiert, wenn B vor dem A installiert wird.

Abwehrmaßnahmen

Wenn Sie eine Komponente nur für Anwendungen verfügbar machen möchten, die mit derselben Signatur wie die bereitstellende Anwendung signiert sind, müssen Sie möglicherweise keine benutzerdefinierten Berechtigungen festlegen, um den Zugriff auf diese Komponente zu beschränken. In diesem Fall können Sie Signaturprüfungen verwenden. Wenn eine Ihrer Apps eine Anfrage an eine andere Ihrer Apps sendet, kann die zweite App prüfen, ob beide Apps mit demselben Zertifikat signiert sind, bevor sie der Anfrage nachkommt.

Ressourcen