Auspacken der Android-Sicherheit: Teil 1 – Unsachgemäße Nutzung der Plattform Lähde: Ed George | Februar 2022
👋 Hallo und willkommen zu der neuen Reihe von Blogbeiträgen, in denen wir tief in die Android-Sicherheit eintauchen werden. Diese Serie konzentriert sich hauptsächlich auf Top 10 mobil Sicherheitsbedrohungen zu Open Web Application Security Project Foundation (OWASP).die führende Community für Anwendungssicherheit in unserem Bereich.
Während sich diese Posts auf die Android-Plattform konzentrieren, sind viele der Ideen und Gefühle dahinter völlig agnostisch für die Plattform, ebenso wie die OWASP-Top-10-Liste selbst.
Diese Beiträge sind auch eine Ergänzung zu meiner Rede vom Januar 2022 „Don’t Be Stunned by OWASP – An Introduction to Writing Code for Greater Android Security“, in der ich die 5 größten Probleme ausführlicher bespreche. Bitte überprüfen Sie meine Diskussionsseite für weitere Details und relevante Links. EIN begleitender Antrag die die in der Rede vorgestellten Probleme demonstriert, steht ebenfalls zum kostenlosen Download zur Verfügung.
Bitte beachten Sie, dass diese Serie zu Bildungszwecken dient nur. Denken Sie daran, nur Anwendungen zu testen, für die Sie die Erlaubnis dazu haben, und vor allem, sei nicht gemein.
Wenn Ihnen diese Serie gefällt oder Sie Feedback haben, Bitte sende mir eine Nachricht. Danke!
In diesem ersten Teil meiner Serie über Android-Sicherheit werden wir uns mit der Bedrohung Nummer 1 für die Sicherheit mobiler Apps befassen, die von OWASP als unsachgemäße Nutzung der Plattform bezeichnet wird.
Auf den ersten Blick scheint die missbräuchliche Nutzung der Plattform eine etwas vage Aussage über etwas zu sein, das sein sollte das brennendes Problem in der Sicherheit mobiler Anwendungen. Was dieser Titel jedoch subtil auszudrücken versucht, ist, dass die Hauptbedrohung für die Sicherheit unserer mobilen Anwendungen tatsächlich darin besteht uns. Geradeheraus, Wir sind das Problem! ¹
Was meine ich mit dieser hyperbolischen Aussage? Nun, normalerweise führt unbeabsichtigter Missbrauch von Entwicklern, Fahrlässigkeit oder einfach Unverständnis für die Android-Plattform zu unseren schwerwiegendsten Sicherheitsproblemen.
Niemand kann erwarten, dass er die gesamte Plattform von innen kennt, und Entwickler sind auch nicht unfehlbar. Fehler passieren unvermeidlich, aber ich hoffe, dass Sie durch die Einführung einiger der häufigsten Sicherheitsprobleme, die wir versehentlich in unseren Code schreiben, es sich zweimal überlegen, bevor Sie selbst denselben Fehler machen, und sich vor einer potenziellen Sicherheitskatastrophe bewahren.
Entschuldigung für das schreckliche Wortspiel, das erste häufige Beispiel für den Missbrauch der Android-Plattform fällt in die Definition Intent. Für diejenigen, die neu bei Android sind, profitiert die Plattform Intent Klasse als eine Möglichkeit, eine Art von Aktion zu initiieren. Dies kann in Form des Navigierens auf einem neuen Bildschirm in Ihrer App, des Startens eines Hintergrund-/Vordergrund-Dienstes oder der Registrierung eines Rundfunkempfängers erfolgen, um regelmäßige Updates von einer Quelle zu erhalten. Der Intent -Klasse bietet eine einfache Möglichkeit, Daten zu parsen und an separate Anwendungskomponenten zu übergeben, und ist die häufigste Methode, dies mithilfe eines Frameworks zu erreichen.
Allerdings ist das Android-Framework Auch ermöglicht anderen Anwendungen das Senden und Empfangen Intent Instanzen zwischen ihnen, um die „Kommunikation“ zwischen Anwendungen zu erleichtern. Hierin liegt die erste gemeinsame Falle.
Um die Kommunikation zwischen Anwendungen zu ermöglichen, die Komponente der Anwendung, die wir erhalten möchten Intent muss als gekennzeichnet sein android:exported=true Innerhalb AndroidManifest.xml Datei. Wenn Sie eine Komponente mit diesem Flag markieren, können Sie eine „ausdrückliche Absicht“ an eine andere Anwendung (oder ein anderes System) senden, um die angegebene Aktion auszuführen, die die empfangende Komponente verwalten kann.
Darüber hinaus können auch Komponenten definiert werden <intent-filter> Blöcke innerhalb des Manifests, um die Arten von Absichten anzugeben, auf die die Aktivität, der Dienst oder der Broadcast-Empfänger reagieren kann. Durch diese Definition kann eine andere Anwendung „implizite Absicht“ verwenden, um das System aufzufordern, Ihre Anwendung als kompatibel anzuzeigen, wenn sie eine bestimmte Absicht anbietet. Beispielsweise die Weiterleitung an ein implizites Intent-System, um Anwendungen anzuzeigen, die URLs verarbeiten können https://spght.dev kann eine Liste der installierten Webbrowser anbieten. Was jedoch für Anfänger vielleicht nicht offensichtlich ist, ist, dass durch die Angabe des Intent-Filters die Komponente im System als Export gekennzeichnet wird obwohl android:exported=true es ist im Manifest nicht explizit definiert.
Meiner Erfahrung nach ist es nicht ungewöhnlich, dass App-Komponenten versehentlich als „Exportieren“ gekennzeichnet werden, obwohl dies eigentlich nicht der Fall sein sollte. Diese falsch definierten Anwendungskomponenten stellen ein großes Sicherheitsrisiko dar, da sie direkt verfügbar sind und daher potenziell ausgenutzt werden können.
Der Hauptgrund, warum schlecht verwaltete Exporte so gefährlich sind, liegt darin, dass es trivial ist, diese Schwachstellen in der Anwendung zu finden und darauf abzuzielen.
Böswillige Akteure können manuell nach Reverse-Engineering-Anwendungen suchen oder Befehlszeilentools wie z drozer oder Cutter um gefährdete exportierte Komponenten zu scannen. Einmal gesammelt, kann es verwendet werden adb entweder um eine Komponente auszuführen oder um eine Absicht zu erstellen, die die gewünschte Aktion des Hackers ausführt.
Ein bemerkenswertes Beispiel dafür aus der realen Welt wurde vom Käferjäger Mehtab Zafar (mzfr) in seinem November 2020 entdeckt. Blogeintrag die detailliert beschreibt, wie die falsch konfigurierte „Deep-Link-Aktivität“ die Ausnutzung von Multi-Site-Scripting (XSS) auf der offiziellen mobilen GitHub-App ermöglichte. Huch.
U begleitender Antrag für meine Rede geschrieben wurde, wurde dies durch Fehlkonfigurationen von Aktivitäten demonstriert MainActivity dass es gemeldet werden kann, obwohl normalerweise eine “Authentifizierung” für den Zugriff von der Anwendung erforderlich ist.
Wie MainActivity exportiert wird, ist es möglich, einfach anzurufen adb dass das System die Aktivität öffnet und somit die Notwendigkeit einer Authentifizierung umgeht.
All dies mag ein wenig entmutigend klingen, aber zum Glück ist es so einfach, diesen Angriffsvektor zu stoppen, wie die relevanten Komponenten in Ihrem zu sichern AndroidManifest.xml die Datei(en) korrekt mit gekennzeichnet sind android:exported.
Tatsächlich ist es ab Android 12 (API 31) nun eine Anfrage zu setzen android:exported Eigentum an allen Ihren Activity, Serviceich BroadcastReceiver Definitionen in Ihrer Anwendung AndroidManifest.xml Datei(en), wenn Sie auf dieses SDK abzielen.
Als zusätzlichen Schutz ermöglicht die Android-Plattform der App auch, eine „benutzerdefinierte Lizenz“ zu definieren Elemente der Genehmigung im Manifest für Wechselwirkungen einschränken mit seinen exponierten Komponenten.
Beispielsweise kann eine Anwendung eine “Signatur”-Berechtigung definieren, die es ihr erlaubt, nur mit anderen Anwendungen zu interagieren, die dieselbe Berechtigung teilen. ich werden mit demselben Signaturzertifikat erstellt:
Um das Schicksal von GitHub zu vermeiden, ist es außerdem eine bewährte Methode, Inhalte zu überprüfen und zu validieren Intent die Sie erhalten, wenn Sie mit Daten umgehen von a <intent-filter>. Tu es Nein blind glauben, dass das, was Sie bekommen, das sein wird, was Sie erwarten!
In zukünftigen Beiträgen dieser Serie werden wir weitere Fälle von „Plattformmissbrauch“ und mehr als die OWASP Top 10 für mobile Geräte untersuchen.
Danke wie immer fürs Lesen! Ich hoffe, Sie fanden diesen Beitrag interessant, zögern Sie nicht, mich mit Feedback zu twittern @Sp4ghettiCode und vergessen Sie nicht zu klatschen, zu liken, zu twittern, zu teilen, zu markieren usw.
