EngageSDK Android-Sicherheitslücke gefährdete Wallets

Einleitung

Microsoft hat ein schwerwiegendes Android-Sicherheitsproblem in einer weit verbreiteten Drittanbieter-Bibliothek, EngageSDK, offengelegt. Zwar wurde keine Ausnutzung in freier Wildbahn festgestellt, doch betraf die Schwachstelle Apps in großem Maßstab und erinnert daran, dass SDKs von Drittanbietern unbemerkt erhebliche Supply-Chain-Risiken in ansonsten vertrauenswürdige Mobile-Apps einbringen können.

Was passiert ist

Die Sicherheitslücke ist eine Intent-Redirection-Schwachstelle in EngageSDK, einer Bibliothek für Messaging und Push-Benachrichtigungen in Android-Apps.

Wichtige Details sind:

• Das Problem ermöglichte es einer bösartigen App auf demselben Gerät, den vertrauenswürdigen Kontext der anfälligen App zu missbrauchen.
• Dies konnte potenziell zu unbefugtem Zugriff auf geschützte Komponenten, zur Offenlegung sensibler Daten und zu einer Privilegienausweitung führen.
• Microsoft erklärte, dass allein mehr als 30 Millionen Installationen von Crypto-Wallet-Apps von Drittanbietern potenziell gefährdet waren.
• Die Schwachstelle wurde auf eine exportierte Android-Aktivität, MTCommonActivity, zurückgeführt, die während des Build-Prozesses durch das SDK hinzugefügt wurde.
• Da sie erst nach dem Build im zusammengeführten Manifest erscheint, können Entwickler sie bei einer normalen Überprüfung leicht übersehen.

Microsoft koordinierte die Offenlegung mit EngageLab und dem Android Security Team. Das Problem wurde am 3. November 2025 in EngageSDK Version 5.2.1 behoben.

Warum das für Sicherheitsteams wichtig ist

Diese Offenlegung ist auch über Android-Wallets hinaus relevant. Sie zeigt, wie:

• SDKs von Drittanbietern die Angriffsfläche ohne klare Transparenz erweitern können
• exportierte Komponenten unbeabsichtigte Vertrauensgrenzen zwischen Apps schaffen können
• Schwächen in der Mobile-App-Supply-Chain Millionen von Nutzern gleichzeitig betreffen können

Android hat außerdem Plattform-Mitigationsmaßnahmen für dieses spezifische EngageSDK-Risiko hinzugefügt, und als anfällig erkannte Apps wurden aus Google Play entfernt. Microsoft merkte an, dass Nutzer, die anfällige Apps bereits heruntergeladen hatten, nun zusätzlichen Schutz erhalten.

Auswirkungen auf Administratoren und Entwickler

Für Sicherheitsadministratoren ist dies ein starkes Beispiel dafür, warum Mobile-Application-Governance auch die Überprüfung von Abhängigkeiten umfassen muss und nicht nur den Ruf der App oder die Freigabe im Store.

Für Entwickler- und DevSecOps-Teams sind die wichtigsten Lehren:

• Zusammengeführte Android-Manifeste prüfen, nicht nur Quell-Manifeste
• Exportierte Aktivitäten und andere exponierte Komponenten auditieren
• Intent-Handling und appübergreifende Vertrauensannahmen validieren
• Versionen von Drittanbieter-SDKs als Teil des Software-Supply-Chain-Managements nachverfolgen

Empfohlene nächste Schritte

• EngageSDK sofort aktualisieren auf Version 5.2.1 oder höher, wenn es in Android-Apps vorhanden ist.
• Mobile-Apps auf von Abhängigkeiten hinzugefügte exportierte Komponenten überprüfen.
• Analyse von Abhängigkeiten und Manifesten in CI/CD-Sicherheitsprüfungen integrieren.
• Die Detection-Hinweise und Indikatoren aus der ursprünglichen Empfehlung von Microsoft verwenden, um die eigene Exponierung zu bewerten.

Dieser Vorfall unterstreicht einen allgemeineren Punkt: Mobile Security wird zunehmend von den Bibliotheken geprägt, von denen Apps abhängen, und nicht nur von dem Code, den Entwickler direkt schreiben.