Einführung

Die schnelle Entwicklung und breite Anwendung mobiler Anwendungen haben SDKs von Drittanbietern zu einem wichtigen Bestandteil der mobilen Entwicklung gemacht. Mit ihren umfangreichen Funktionen und ihrer bequemen Integration bieten SDKs von Drittanbietern den Entwicklern eine Möglichkeit, die Funktionalität ihrer Anwendungen schnell zu entwickeln und zu verbessern. Aufgrund des Blackbox-Charakters und des weit verbreiteten Einsatzes von SDKs von Drittanbietern hat ihre Sicherheit jedoch viel Aufmerksamkeit auf sich gezogen. In diesem Beitrag konzentrieren wir uns auf die Sicherheit von SDKs von Drittanbietern in mobilen Anwendungen und demonstrieren potenzielle Sicherheitsrisiken und Angriffsmethoden anhand von realen Fällen, in denen Schwachstellen gefunden werden.

Der Stand der Sicherheit von SDKs von Drittanbietern:

Es gibt einige Sicherheitsrisiken im Zusammenhang mit SDKs von Drittanbietern, die häufig in mobilen Anwendungen verwendet werden. Erstens werden SDKs von Drittanbietern in Form von Jar-Paketen oder Bibliotheken in Anwendungen integriert, die als Blackboxen existieren und deren Sicherheit Entwickler nicht überprüfen können. Zweitens hat eine Sicherheitslücke in einem SDK aufgrund der weit verbreiteten Verwendung Auswirkungen auf viele Anwendungen. Darüber hinaus kann die Integration von SDKs zu einer Vergrößerung der Angriffsfläche der Anwendung führen, wodurch sich das Sicherheitsrisiko der Anwendung erhöht.

AUO SDK Überschreibungsschwachstelle:

AUO SDK-Überschreitungsschwachstelle im September 2017 entdeckt Die Schwachstelle besteht im Message-Push-SDK von AUO, die von einem Angreifer ausgenutzt werden kann, um die Berechtigung zum Aufruf nicht exportierter Komponenten zu überschreiten und so Angriffe wie den böswilligen Aufruf einer beliebigen Komponente der betroffenen APP, die Zustellung beliebiger falscher Nachrichten, die Ausführung von Remote-Code usw. zu realisieren. Etwa 30.000+ APPs sind von dieser Schwachstelle betroffen, etwa 7.000+ APP-Produkte, die mehrere Arten von Anwendungen umfassen.

 

Baidu SDK durch Hintertür offengelegt

Baidu Moplus SDK Backdoor-Schwachstelle, die im November 2015 von Trend Micro entdeckt wurde. Die Schwachstelle besteht im Baidu Moplus SDK und kann von einem Angreifer ausgenutzt werden, um unbemerkt Apps auf einem gerooteten Android-Gerät zu installieren, um sensible Benutzerdaten zu stehlen oder die Kontrolle über das Gerät zu übernehmen. Die Sicherheitslücke betrifft etwa 100 Millionen Android-Geräte und Tausende von Android-Apps.

Schwerwiegende Risiken in der Lieferkette im Zusammenhang mit Finanzprodukten

Unter anderem sind die Sicherheitsrisiken von SDKs von Drittanbietern in der Lieferkette von Android-Anwendungen ein besonders ernstes Risiko für Finanzanwendungen.

Schwachstellenermittlung und -analyse

Grundkonzept

 Anwendungs-Sandbox

Linux-basierter Berechtigungskontrollmechanismus: UID und GID werden nach der Installation der Anwendung zugewiesen, UID wird verwendet, um den Zugriff auf Dateien einzuschränken, theoretisch kann die Anwendung nicht auf die privaten Dateien anderer Anwendungen zugreifen, GID wird verwendet, um den Zugriff auf Ressourcen einzuschränken, nachdem die Anwendung Berechtigungen beantragt hat, wird ihre UID der Benutzergruppe hinzugefügt, die den Berechtigungen entspricht, die Berechtigungen werden auf die GID abgebildet:/data/etc/platform.xml, die erforderlichen Berechtigungen werden während der Installation/Laufzeit angewendet und vom System/Benutzer kontrolliert, usw. platform.xml, Anwendung der erforderlichen Berechtigungen während der Installation/Ausführungszeit, kontrolliert durch das System/den Benutzer, usw.

 INTENT

Gemeinsame IPC-Formen in Android: gehören zu einer Art IPC-Nachrichtenobjekt, das für die Kommunikation zwischen APP-Komponenten, demselben Prozess/prozessübergreifend verwendet wird

Nachfolgend einige Beispiele für die Verwendung dieser Funktion: startActivity()/startService()/bindService()/sendBroadcast(), Angabe der Zielkomponente mit Action oder ComponentName usw., und kann zusätzliche Daten (Extras) enthalten.

Komponente Sicherheit

Android APP grundlegende Komponenten: Aktivität, Broadcast-Empfänger, Content Provider, Service vier Komponenten. Wie: xml-Datei zu deklarieren: Komponenten können als externe Export / Anwendung von privaten erklärt werden, können Berechtigungen auf seinen Schutz verwenden

Sicherheit bei der Ausfuhr von Komponenten

Exportierte Komponenten: Auf exportierte Komponenten kann von jeder Anwendung zugegriffen werden, android:exported=true, registerReceiver(), Komponenten mit Tags werden standardmäßig exportiert, wenn android:export=false nicht gesetzt ist. Beispiel:

<Empfänger android:name= "com.xxx.android.pushservice.PushServiceReceiver" android:process=":xxservice_v1″ >

<intent-filter>

<action android:name=”android.intent.action.BOOT_COMPLETED” />

<action android:name=”android.net.conn.CONNECTIVITY_CHANGE” />

<!– … –>

</intent-filter>

</receiver>

Private Komponenten: Private Komponenten enthalten meist anwendungssensible Funktionen und weisen eine geringere Überprüfung der Eingabedaten, einen unbefugten Zugriff auf andere private Anwendungskomponenten (Ausbruch aus der Sandbox der Anwendung) und ernsthafte Sicherheitsrisiken auf.

Methoden zur Ausnutzung von Schwachstellen

Durch Ausnutzung der Schwachstellen im SDK können böswillige Anwendungen sogar auf private Anwendungskomponenten zugreifen, böswillige Benachrichtigungen versenden, Besuche auf Phishing-Websites veranlassen, SMS-Verifizierungscodes erhalten, auf die privaten Daten der Benutzer zugreifen und beliebigen Code ohne jegliche Berechtigung und unter Umgehung der Sandbox-Beschränkungen ausführen.

Dieser Artikel enthält mehrere Beispiele aus der Praxis, die die möglichen Sicherheitsrisiken und Angriffe auf SDKs von Drittanbietern aufzeigen.

drücken.SDK Vulnerability Mining

Push-SDK ist eine der häufigsten Funktionen in mobilen Anwendungen, aber es gibt einige Sicherheitsschwachstellen darin. Durch Ausnutzung der Schwachstellen im Push-SDK können Angreifer die Sandbox-Beschränkungen der Anwendung umgehen, auf die privaten Komponenten der Anwendung zugreifen, bösartige Benachrichtigungen versenden und Benutzer zum Besuch von Phishing-Websites verleiten. Zu den konkreten Fällen gehört die Schwachstelle im Push-SDK-A, das in die offizielle App einer städtischen U-Bahn integriert ist. Hier gelang es dem Angreifer, eine Phishing-Benachrichtigung einzuschleusen, indem er eine bösartige Push-Nachricht und einen exportierten Empfänger erstellte.

PUSH SDK

Push SDK - A

• Die offizielle Dokumentation weist Entwickler an, einen exportierten Receiver hinzuzufügen
• Die spezifische Funktionalität des exportierten Empfängers wird vom Entwickler implementiert
• "Anweisung" an Entwickler, einen Einstiegspunkt für Angriffe zu hinterlassen

<receiver android:name=”您自己定义的Receiver” android:enabled=”true”>

<intent-filter>

<action android:name=”cn.xxxxx.android.intent.REGISTRATION” />

<action android:name=”cn.xxxxx.android.intent.MESSAGE_RECEIVED” />

<action android:name=”cn.xxxxx.android.intent.NOTIFICATION_RECEIVED” />

<action android:name=”cn.xxxxx.android.intent.NOTIFICATION_OPENED” />

<action android:name=”cn.xxxxx.android.intent.CONNECTION” />

<category android:name=”您应用的包名” />

</intent-filter>

</receiver>

In diesem Fall handelt es sich um das offizielle App-Integrations-Push-SDK für eine städtische U-Bahn.

• Export-Empfänger xxxxxCustomerReceiver
• Parsen von Intent-Eingangsdaten in xxxxxCustomerReceiver, Öffnen der angegebenen URL innerhalb der App
• POC

Die offizielle Metro-App der Stadt ruft eine bösartige Phishing-Seite auf

Push SDK - B

• Den Benutzer anweisen, den exportierten Empfänger hinzuzufügen
• Der exportierte Receiver erbt von com.xxx.android.xxxxxx.xxxBaseReceiver

<receiver android:name="com.xxxx.xxdemo.receiver.MessageReceiver"

android:exported="wahr” >

<intent-filter>

<action android:name=”com.xxxxx.android.xxxxx.action.PUSH_MESSAGE” />

<action android:name=”com.xxxxx.android.xxxxx.action.FEEDBACK” />

</intent-filter>

</receiver>

Push SDK - B

xxxxx.android.xxxxx. Push-Nachrichten werden in xxxxx.android.xxxxx. xxxBaseReceiver verarbeitet, die nach unten gesendeten Nachrichten werden mit RSA verschlüsselt, lokal von der App entschlüsselt und dem Benutzer nach erfolgreicher Entschlüsselung angezeigt, jedoch .... Es gibt jedoch eine Verschlüsselungsmethode im SDK, die von einem Angreifer aufgerufen werden kann, um die gefälschte Nachricht zu verschlüsseln.

XX Credit Card Manager integriert Push SDK - B, fügt exportierten Receiver hinzu, Angreifer konstruiert bösartige Push-Nachricht durch Aufruf einer verschlüsselten Methode im SDK und öffnet Phishing-Benachrichtigung mit exportiertem Receiver.POC.

Umfang der Auswirkungen

Sharing-KlasseSDK-SchwachstelleExhumierung

Sharing-SDKs werden häufig verwendet, um Social-Sharing-Funktionen in mobilen Anwendungen zu implementieren, jedoch weisen bestimmte Sharing-SDKs Sicherheitsschwachstellen auf. So gibt es beispielsweise eine exportierte Aktivität in einem Sharing-SDK-A, die es einem Angreifer ermöglicht, die Sandbox-Beschränkungen der Anwendung zu umgehen und auf alle privaten Aktivitäten zuzugreifen. Durch die Konstruktion eines bösartigen Eingabe-Strings kann ein Angreifer eine allgemeine Denial-of-Service-Schwachstelle auslösen, die zu einem Absturz der Anwendung führt. Darüber hinaus können bestimmte Sharing-SDKs auch dazu führen, dass die Kennwortsperre der Anwendung umgangen wird, was wiederum den Zugriff auf die privaten Daten der Benutzer ermöglicht.

SDK teilen - A

Es gibt eine exportierte Aktivität, XxShareXxXxxxxActivity, im SDK, die den Eingabestring als Komponentennamen annimmt und die angegebene Komponente direkt startet, ohne sie zu überprüfen. Bösartige Anwendungen können die Anwendungs-Sandbox-Einschränkungen umgehen und auf jede private Aktivität zugreifen.

XxShareXxXxxxxActivity empfängt die eingehende Zeichenkette Intent, speichert die eingehende Zeichenkette als ActivityName, ohne sie zu überprüfen, und ruft startActivity im aktuellen Anwendungskontext auf, um die mit ActivityName angegebene Activity zu starten usw.

Exploit - Generischer Denial of Service: Übergabe von Parametern/Initialisierung beim Start einer Activity/.... Ausnutzung einer SDK-Schwachstelle, um den Aufruf einer nicht exportierten Activity zu erzwingen, unsachgemäße Ausnahmebehandlung, die zum Absturz der Anwendung führt.

Schreiben Sie Test-Tools, Batch-Tests von einer großen Anzahl von Anwendungen, integrierte die SDK-Anwendung, 90% + die Existenz des Problems, nach der Statistik integrierte die SDK-Anwendung, 90% + die Existenz des Problems, eine große Anzahl von bekannten inländischen Herstellern Anwendungen, sind von dieser Schwachstelle betroffen.

Ausnutzung der Schwachstelle - Umgehung der Kennwortsperre der Anwendung: Die Anwendung speichert die privaten Daten des Benutzers, Sie müssen das richtige Kennwort eingeben, wenn Sie in die Anwendung eintreten, häufig in Finanz- und IM-Anwendungen gefunden, mit dieser SDK-Schwachstelle, die Überschreitung des Rechts auf die sensiblen funktionalen Komponenten mit Kennwort zurücksetzen, Kennwort festlegen und so weiter, die Anwendung von High-Privilege-Komponenten Authentifizierung ist nicht streng, was in der Kennwortsperre umgangen / zurückgesetzt, usw., fand der Test, dass Das Problem besteht bei Anwendungen vieler bekannter Hersteller, wie z.B....

Vulnerability Exploitation - unangemessen offen Debugging-Modus: Um Online-Positionierung Bugs zu erleichtern, viele Anwendungen Release-Version des Debugging-Code in der Anwendung Log-Switch, benutzerdefinierte Online-Server-Adresse, Export von Benutzerdaten und anderen sensiblen Funktionen ..., Debugging-Funktion ist in der Regel keine intuitive Eintrag in der UI, kann der normale Benutzer nicht leicht zugänglich, wie Debugging-Modul beinhaltet sensible Operationen, die Debugging-Modul. Im Wesentlichen als Hintertür, mit dem SDK-Schwachstelle, durchquert die Anwendung aller nicht exportierten Komponenten, festgestellt, dass die versteckten Debugging-Funktionen, wie ein Enterprise-Level-IM-Anwendung, festgestellt, dass es eine Reihe von nicht exportierten Komponenten mit Debugging-Funktionen, Reverse-Analyse, um festzustellen, dass es einen versteckten Eintrag in die UI Debugging, sondern durch die UI zu starten Debugging-Komponenten, müssen Sie ein Passwort eingeben:, die Authentifizierung ist nicht streng, die Verwendung des SDK-Schlupfloch, unter Umgehung der Passwort-Schutz, über das Recht, das Debugging zu öffnen Diese SDK-Schwachstelle wird ausgenutzt, um den Passwortschutz zu umgehen und unbefugten Zugriff auf die Debugging-Funktionalität zu erhalten.

Gewöhnliche Benutzer-Identität Login: mit SDK Schwachstellen zu öffnen, die Administrator-Privileg-Funktion, die Server-Seite der Benutzer-Identitätsprüfung ist nicht streng, ein Teil der Administrator-Funktion kann überschritten werden Aufruf und so weiter.

Umfang der Auswirkungen

Zusammenfassen und reflektieren:

Die Sicherheit von SDKs von Drittanbietern in mobilen Anwendungen muss ernst genommen und angegangen werden. Entwickler sollten die integrierten SDKs von Drittanbietern überprüfen, um deren Sicherheit und Zuverlässigkeit zu gewährleisten. Gleichzeitig wird Entwicklern empfohlen, die folgenden Maßnahmen zu ergreifen, um die Sicherheit von Drittanbieter-SDKs in mobilen APPs zu verbessern:

1. einen vertrauenswürdigen SDK-Anbieter wählen: Bevor ein SDK eines Drittanbieters ausgewählt und integriert wird, sollten die Entwickler die Anbieter umfassend prüfen und bewerten und sich für solche mit gutem Ruf und Sicherheitsbilanz entscheiden.

2. regelmäßige Aktualisierung und Upgrade der SDK-Versionen: SDK-Drittanbieter veröffentlichen häufig Updates und Korrekturen, um bekannte Sicherheitslücken zu schließen. Die Entwickler sollten das integrierte SDK rechtzeitig aktualisieren und aktualisieren, um die Sicherheit der Anwendung zu gewährleisten.

3) Durchführung von Sicherheitsaudits und Schwachstellenanalyse: Entwickler können potenzielle Sicherheitsschwachstellen in SDKs von Drittanbietern durch Sicherheitsaudits und Schwachstellenanalyse erkennen. Dies ermöglicht eine frühzeitige Erkennung und Behebung dieser Schwachstellen, um die Sicherheit der Anwendung zu verbessern.

4 Begrenzung der SDK-Berechtigungen und des Zugriffs: Bei der Integration von SDKs von Drittanbietern sollten die Entwickler deren Berechtigungen überprüfen und nur die notwendigen gewähren. Beschränken Sie außerdem den Zugriff des SDKs auf private Komponenten der Anwendung, um potenzielle Sicherheitsrisiken zu verringern.

5. den Schutz sensibler Nutzerdaten verstärken: Bei der Verwendung von SDKs von Drittanbietern sollten Entwickler auf den Schutz sensibler Nutzerdaten achten. Durch Maßnahmen wie Verschlüsselung und Authentifizierung kann die Sicherheit der Nutzerdaten gewährleistet werden.

Schließlich ist auch die Sicherheit von SDKs von Drittanbietern in mobilen Anwendungen ein wichtiges Thema. Entwickler und Sicherheitsforscher sollten der Sicherheitsprüfung und der Schwachstellenanalyse von SDKs von Drittanbietern große Aufmerksamkeit schenken und diese verstärken. Nur durch gemeinsame Anstrengungen können wir die allgemeine Sicherheit mobiler APPs verbessern und die Privatsphäre der Nutzer schützen.Datensicherheit.