Q
RC OD
E über eine mobile Anwendung zum Scannen der Ausweise von Ausstellern von Informationssicherheitsprojekten.
Letztes Jahr haben wir eine große Ausstellung von Informationssicherheitsprojekten in London besucht. Zur Vorbereitung erhielten wir unsere Ausweise in Form von PDFs zum Ausdrucken.
Wir haben sofort zwei Arten von Barcodes bemerkt. Interessanterweise sah der QR-Code zu dicht aus, da es ausreicht, nur die Teilnehmer-ID darin zu speichern. Da wir von Natur aus neugierig sind, haben wir einen QR-Scanner gestartet und den Inhalt des Codes erhalten:
{"CJe";"BHEEZST","DO";"Cvmmfuqsppg","G";"upn","KU";"Qfofusbujpo uftufs","T";"xzbuu"}
Es stellte sich heraus, dass es fast, aber nicht ganz JSON war. Einer der Vorteile eines so kurzen Namens wie meines ist, dass er in solchen Situationen auffällt. Daher bemerkte ich sofort, dass mein Name in ROT-25 verschlüsselt war (aus „tom“ wurde „upn“). Es ist auch als Caesar-Chiffre bekannt, bei der jeder Buchstabe durch einen anderen mit festem Versatz ersetzt wird (in diesem Fall wurde der Buchstabe im Alphabet anstelle jedes Buchstabens verwendet). Nachdem wir die Leitung durch den Decoder geführt haben (unter Berücksichtigung des JSON-Markups), haben wir:
{"BId";"AGDDYRS","CN";"Bulletproof","F";"tom","JT";"Penetration tester","S";"wyatt"}
Dies ist besser lesbar.
Brechen Sie es?
Seltsamerweise speichert der QR-Code Informationen, die mit dem BId-Feld in der Datenbank in Zusammenhang zu stehen scheinen. Warum? Das ist ziemlich einfach. Die Organisatoren haben eine mobile Anwendung für Anbieter erstellt, mit deren Hilfe sie die Kontakte der Teilnehmer während der Ausstellung sammeln können. Wir haben angenommen, dass die Daten in einem QR-Code verschlüsselt sind, falls das WLAN oder das Mobilfunksignal instabil ist.
Bisher können wir mit diesen Informationen nur wenig anfangen, außer unsere Daten zu ändern, um Spam von Anbietern von der Veranstaltung zu vermeiden. Es wäre lustig, aber kaum eine E-Mail an den Systementwickler wert. Also gingen wir zum Play Market und installierten die entsprechende Anwendung, um zu sehen, was sie tut.
Und hier sind wir auf ein Problem gestoßen: Wir hatten nicht die notwendigen Daten von den Organisatoren der Veranstaltung. Wir dachten, wir könnten die Serverantwort mit dem MiTM-Proxy fälschen, und die Anwendung wird uns gehen lassen. Wir haben Burpsuite eingerichtet und einige erfolglose Anmeldeversuche aufgezeichnet, in der Hoffnung, den Datenverkehr abzufangen und damit zu spielen.
Leider haben wir es nicht geschafft. Die Anwendung leitete alle Anfragen mithilfe von SOAP, und die Antworten waren nicht offensichtlich. Der Server veröffentlicht jedoch WSDL-Dokumente für die Anwendung.
Dies ist nicht das Ende
Warum nicht einen gefälschten Webdienst schreiben, damit Sie nicht mehr auf den realen Anwendungsserver zugreifen können? Ein paar Stunden später hatten wir einen solchen Service und der gesamte Verkehr wurde darauf geschaltet. Es funktioniert! Die Anwendung hat sich mit allen Daten authentifiziert und mit einem gefälschten Ereignis verbunden.
Wir haben ein paar Abzeichen gescannt und alles schien richtig zu funktionieren. Fortschritt! Nachdem ich einige Zeit in der Anwendung herumgewandert war, stellte sich heraus, dass sie eine Art WebView-basiertes Framework verwendete. Beim Stöbern in der APK fanden wir eine Reihe von Erwähnungen von Sencha und Ext.js, die unsere Annahme bestätigten.
Und jetzt - das interessanteste. Wenn eine Anwendung aus einer regulären Mischung aus HTML und JavaScript besteht, kann sie dann für Standard-Webangriffe anfällig sein? Wir haben ein paar XSS in den "nicht ganz JSON" eingewickelt, den die Anwendung erwartet, sie gescannt und ...
Wir haben es kaputt gemacht
Großartig! Die HTML-Injection im Feld "JT" zeigte das Bild. Wir können diesem Tag das Attribut "onerror" hinzufügen, um die Ausführung des Skripts zu erreichen. Wir sind jedoch durch die Beschränkung der maximalen Länge des QR-Codes begrenzt. Als Ergebnis haben wir eine Nutzlast erstellt, die die JS-Datei vom Server heruntergeladen und auf dem Gerät ausgeführt hat. Hier ist zum Beispiel der Standard-alert () -Test:
Das Scannen eines Barcodes löst XSS aus und führt den Code aus:
Wir haben es so gestochen, dass es genau in die maximale Größe eines lesbaren QR-Codes passt, nicht zu dicht zum Drucken auf einem Durchgang. Nachdem wir die Dokumentation für die Ext.js-API gelesen und mit dem dekompilierten APK-Code verglichen hatten, konnten wir einen Barcode erstellen, der:
- Laden Sie eine JS-Datei von einem Remote-Server herunter
- Liest Sitzungsschlüssel von einem Smartphone und sendet sie an unseren Server
- Liest den Inhalt der zwischengespeicherten Kontaktdatenbank aus der Anwendung, einschließlich der Namen und E-Mail-Adressen aller, deren Ausweise von diesem Gerät gescannt wurden
- Löscht Ihre Aufnahme von einem Smartphone
Dann läuft der Angriff auf Folgendes hinaus: Der Anbieter scannt meinen QR-Code im Austausch gegen einen kostenlosen Stift, und ich erhalte eine vollständige Liste aller von diesem Gerät gescannten Kontakte.
Nutzlast:
Anfragen an den Webserver:
Alles ist gut, das endet gut
Wir haben die Anbieter auf der Messe auf sich aufmerksam gemacht, und nach einigen Diskussionen haben sie beschlossen, die Anwendung dieses Jahr nicht zu verwenden. Nur wenige Teilnehmer der Veranstaltung nutzten die Anwendung, während einfache kleine Barcode-Scanner die Anwendung bevorzugten. Die Anwendung vom Markt wurde nur etwa 500 Mal heruntergeladen. Dies ist jedoch ein interessanter Vektor für XSS, der zeigt, dass Sie die Daten vor der Verwendung wirklich filtern müssen, unabhängig von ihrer Quelle.
Obwohl diese spezielle Anwendung nicht weit verbreitet ist, stellen Sie sich vor, ob die Sicherheitsanfälligkeit in einer Anwendung liegt, die von Tausenden verwendet oder von Millionen heruntergeladen wird. Alle diese Daten sind für Angreifer bestimmt, die sie nach eigenem Ermessen entsorgt hätten: von Phishing-Kampagnen bis hin zu Brute-Force-Angriffen.