Sicherheitsaudit einer Banking-App: Fallstudie OWASP & MobSF

Die meisten Agenturen verkaufen Sicherheit als schmückendes Beiwort. Diese Fallstudie ist eine lückenlose Dokumentation: eine echte Retail-Bank, ein echter Scanner-Score, 48 bewertete Lücken, 124 Aufgaben und eine ehrliche Liste dessen, was noch offen ist.

Die Android-App der Bank basiert auf einem White-Label-Banking-SDK. Als der eigene Scan der Bank einen MobSF Security Score von 48 von 100 ergab, ging es nicht nur darum, wie sich die Zahl erhöhen lässt. Es ging darum, was die Zahl tatsächlich bedeutete, welche Lücken echt waren und wie sie sich so beheben ließen, dass das Sicherheitsteam der Bank es überprüfen konnte.

In diesem Artikel zeigen wir, wie das Audit ablief, was die Behebung umfasste, wie die Fixes verifiziert wurden und was noch offen ist.

Der Ausgangspunkt

Ein Score von 48/100 klingt alarmierend, doch ein reiner Score sagt für sich genommen wenig aus. Vor jedem Fix mussten wir drei Fragen beantworten:

Können wir den Score reproduzieren? Wenn wir nicht dasselbe Ergebnis erzielen, können wir später keine Verbesserung nachweisen.
Welche Befunde sind echt? Scanner vermischen echte Schwachstellen mit Rauschen aus der Build-Konfiguration und False Positives.
Was übersieht der Scanner? Automatisierte Tools sehen die Binärdatei, nicht die Logik. Authentifizierungsabläufe, Schlüsselverwaltung und Datenspeicherung erfordern eine Prüfung durch einen Menschen.

📌 Kernaussage:

Ein Scanner-Score ist der Anfang eines Audits, nicht sein Ende. Das nützliche Ergebnis ist eine Liste echter, bewerteter Lücken, für die jemand verantwortlich ist.

Wie das Audit ablief

Phase 1: Den Scanner-Score reproduzieren

Wir haben den Scan nachgebaut und das Ergebnis der Bank reproduziert. Dann haben wir jeden Punkt, den die App verloren hatte, in Kategorien eingeteilt. Der Befund, der die Bank am meisten überraschte: 6–7 der 52 fehlenden Punkte gingen allein auf den Build-Typ zurück – der Scan war mit einem Debug-Build statt mit dem Release-Build durchgeführt worden, den die Nutzer tatsächlich installieren. Und zwei Prüfungen, die der Scanner als sicher markiert hatte, erwiesen sich als False Positives.

Phase 2: Manuelles Audit nach OWASP Mobile Top 10 (2024)

Wir haben die App Kategorie für Kategorie anhand der OWASP Mobile Top 10 (2024) geprüft, von unsachgemäßer Verwendung von Zugangsdaten (M1) und Sicherheit der Lieferkette (M2) bis zu unsicherer Datenspeicherung (M9) und unzureichender Kryptografie (M10). Jede Lücke erhielt einen CVSS-Score, damit die Bank nach Schweregrad priorisieren konnte statt danach, wie alarmierend ein Befund klang.

Ergebnis: 48 nach CVSS bewertete Lücken.

Phase 3: Ein Maßnahmenplan mit Kostenschätzung

Die 48 Lücken wurden in 124 nachverfolgte Aufgaben aufgeteilt. Jede Änderung wurde von einem kurzen schriftlichen Bedrohungs- und Entscheidungsmemo begleitet: worin das Risiko besteht, welche Option wir gewählt haben, was wir verworfen haben und warum. Wo die Bank beschloss, ein Risiko zu akzeptieren, statt es zu beheben, wurde auch diese Entscheidung festgehalten.

Phase 4: Behebung und Härtung

Neben der Behebung der Befunde haben wir eine Reihe von Laufzeit- und Anti-Missbrauchs-Schutzmaßnahmen entwickelt und getestet, darunter:

Overlay-Schutz in drei Ebenen sowie ein Klassifikator für den Missbrauch von Bedienungshilfen (Accessibility Services).
An ein CryptoObject gebundener biometrischer Login, sodass ein gehookter Callback keinen erfolgreichen Login vortäuschen kann.
Root-, Frida- und Emulator-Erkennung, mit 35 Tests für die Emulator-Erkennung anhand exakter Werte und ohne False Positives auf Chromebooks.
Anti-Repackaging durch eine Prüfung des Signaturzertifikats und eine Prüfung der Installationsquelle.
Leeren der Zwischenablage nach 60 Sekunden für kopierte sensible Werte.
Ausschließlich TLS 1.3 für den Netzwerkverkehr.
Envelope Encryption für lokale Daten statt SQLCipher – das spart 6,5 MB nativen Code bei Kosten von etwa 1 ms pro Bildschirm.

Wie die Fixes verifiziert wurden

Fixes, die nur der Entwickler getestet hat, sind Behauptungen, keine Nachweise. Die Verifizierung lief auf zwei Ebenen.

Unabhängiges QA-Security-Paket

Das QA-Team erstellte ein Paket zur Sicherheitsverifizierung mit 79 skriptgesteuerten Prüfungen für 45 Sicherheitstickets. Jede Prüfung bestätigt, dass eine bestimmte Schutzmaßnahme auf einem echten Build funktioniert.

Die Tests testen

Anschließend haben wir das QA-Paket selbst mit Mutationstests geprüft: Wir setzten Schutzmaßnahmen in Test-Builds absichtlich außer Kraft und bestätigten, dass die Prüfungen jeden Defekt erkennen. Der Runner erkannte alle Mutanten. Ebenso wichtig: 13 dieser Mutanten hatten die eigenen Tests der Entwickler überlebt – genau die Lücken, die eine unabhängige Prüfung finden soll.

Nachweise zur Lieferkette in der CI

Jedes Release wird nun mit einer CycloneDX-SBOM ausgeliefert, und die Abhängigkeiten werden mit OWASP Dependency-Check gescannt. Der erste Scan ergab 1.388 rohe CVE-Treffer. Jeder wurde gesichtet und mit einer datierten, schriftlichen Begründung unterdrückt; keiner erwies sich als echte Schwachstelle in der Release-APK.

Ergebnisse auf einen Blick

Punkt	Ergebnis
MobSF-Score zu Beginn	48/100, reproduziert
Allein durch den Build-Typ erklärte Punkte	6–7 von 52
Fälschliche „sicher“-Haken des Scanners	2
Nach CVSS bewertete Lücken	48
Nachverfolgte Behebungsaufgaben	124
QA-Sicherheitsprüfungen	79 Prüfungen für 45 Tickets
Gesichtete rohe CVE-Treffer	1.388 → 0 echte
Dauer	Etwa neun Wochen

Was noch offen ist

Wir veröffentlichen die Lücken zusammen mit den Ergebnissen, denn genau das macht den Rest glaubwürdig:

Noch keine abschließende Neubewertung und kein externer Pentest. Wir behaupten weder eine endgültige MobSF-Note noch einen bestandenen Penetrationstest oder die vollständige Konformität mit OWASP MASVS.
Certificate Pinning ist vorbereitet und wartet auf die Richtlinie der Bank zur Schlüsselrotation, bevor es aktiviert wird.
Der Abhängigkeits-Scan meldet, blockiert aber noch keine Releases bei Befunden mit hohem Schweregrad.

Mobians Mobile Security Teardown

Dieses Projekt wurde zur Vorlage für unseren Mobile Security Teardown: zwei Wochen, Festpreis. Wir reproduzieren Ihren Scanner-Score, führen ein manuelles Audit nach OWASP Mobile Top 10 (2024) durch, bewerten jede Lücke nach CVSS und übergeben einen Maßnahmenplan mit Kostenschätzung, den Ihr Team – oder unseres – umsetzen kann.

Bei Mobian sind wir kein Compliance-Dienstleister, und wir werden Ihnen nicht erzählen, dass ein Audit Sie konform macht. Was wir liefern, sind Nachweise, die Ihr Auditor nachvollziehen kann – bis auf Datei- und Zeilenebene.

Fazit

Ein MobSF-Score von 48/100 sagte der Bank, dass etwas nicht stimmte, aber nicht, was. Den Score zu reproduzieren, manuell nach OWASP zu auditieren, jede Lücke zu bewerten und jeden Fix zu verifizieren, machte aus einer alarmierenden Zahl 124 zugeordnete, nachvollziehbare Aufgaben. Wenn jemand – eine Partnerbank, ein Auditor, eine Aufsichtsbehörde – bereits ein Problem in Ihrer mobilen App gefunden hat, ist das der richtige Ausgangspunkt.

Häufige Fragen

Was umfasste das Sicherheitsaudit?

Vier Dinge: eine Reproduktion des MobSF-Scans der Bank, ein manuelles Audit der Android-App anhand aller zehn Kategorien der OWASP Mobile Top 10 (2024), einen CVSS-Score für jede gefundene Lücke und einen Maßnahmenplan mit Kostenschätzung. Behebung und unabhängige QA-Verifizierung folgten im selben Projekt.

Hat die App nach den Fixes einen Penetrationstest bestanden?

Das behaupten wir nicht. Bisher wurden weder ein externer Penetrationstest noch eine abschließende MobSF-Neubewertung durchgeführt. Was wir vorweisen können, ist eine datierte, nummerierte Spur: 48 bewertete Lücken, 124 nachverfolgte Aufgaben und ein QA-Paket, das die Fixes verifiziert und selbst gegen absichtlich defekte Builds getestet wurde.

Reicht ein MobSF-Score aus, um die Sicherheit einer App zu beurteilen?

Nein. In diesem Projekt gingen 6–7 der 52 fehlenden Punkte allein darauf zurück, dass ein Debug-Build statt eines Release-Builds gescannt wurde, und zwei Prüfungen, die der Scanner als sicher markiert hatte, waren False Positives. Ein Score ist der Ausgangspunkt für ein manuelles Audit, kein Urteil.

Macht diese Arbeit eine App konform mit DORA oder anderen Vorschriften?

Mobian ist kein Compliance-Dienstleister, und ein Audit allein macht eine App nicht konform. Was es liefert, sind Nachweise, die ein Auditor nachvollziehen kann: bewertete Befunde, eine schriftliche Entscheidung zu jeder Änderung, eine Behebung auf Dateiebene und unabhängige QA-Ergebnisse. Was diese Nachweise abdecken, entscheiden Ihre Compliance- und Rechtsabteilungen.

Können dieselben Schutzmaßnahmen auch Krypto- oder Gaming-Apps schützen?

Viele davon, ja. Overlay-Schutz, Erkennung von Bedienungshilfen-Missbrauch, Hooking- und Emulator-Erkennung sowie Anti-Repackaging-Prüfungen zielen auf Missbrauchsmuster ab, die bei allen Apps rund ums Geld gleich aussehen. Nischenspezifische Funktionen wie Key Custody oder zertifizierte Geolokalisierung haben wir nicht entwickelt, und das sagen wir von vornherein.

Fallstudie: Von MobSF 48/100 zu 124 nachverfolgten Security-Fixes in neun Wochen