Vertrauen Sie auf mobile SDKs

Die jüngste Backdoor-Geschichte in der beliebtesten NPM-Bibliothek hat viele dazu veranlasst, darüber nachzudenken, wie sehr wir Code von Drittanbietern vertrauen und wie mutig wir ihn in unseren Projekten verwenden (wodurch möglicherweise Benutzer unserer Produkte ersetzt werden).

Aber noch Monate vor dem „Donnerschlag“ sprach Felix Kraus (den mobilen Entwicklern als Schöpfer von Fastlane bekannt) auf unserer Mobius 2018 Piter-Konferenz über das Gleiche: Vertrauen von mobilen Entwicklern in SDKs von Drittanbietern. Wenn wir das beliebte SDK von einem bekannten Unternehmen herunterladen, ist dort alles in Ordnung oder kann auch etwas schief gehen? Wo ist der Angriffsvektor und woran sollten wir diesbezüglich denken?

Und jetzt haben wir seinen Bericht transkribiert und übersetzt - so können Sie unter dem Schnitt zumindest das Originalvideo ansehen, zumindest die russischsprachige Textversion lesen. Da Kraus sich mit der iOS-Entwicklung beschäftigt, stammen alle Beispiele auch von iOS, aber Android-Entwickler können bestimmte Beispiele ignorieren und auch darüber nachdenken.

SDK-Sicherheit

Nachdem ich herausgefunden hatte, welche SDKs heute in der iOS-Entwicklung am beliebtesten sind, habe ich mich entschlossen zu untersuchen, wie anfällig sie für die häufigsten Netzwerkangriffe sind. 31% von ihnen erwiesen sich als potenzielle Opfer einfacher Man-in-the-Middle-Angriffe, was bedeutet, dass der Hacker seinen bösartigen Code in das SDK einfügt.

Aber lohnt es sich im Allgemeinen, Angst zu haben? Was kann er mit Ihrem SDK am schlechtesten machen? Ist das alles so ernst? Sie müssen verstehen, dass das im Bundle Ihrer Anwendung enthaltene SDK in seinem Umfang ausgeführt wird. Das heißt, das SDK erhält Zugriff auf alles, mit dem Ihre Anwendung arbeitet. Wenn der Benutzer der Anwendung Zugriff auf Geolokalisierungsdaten oder beispielsweise Fotos gewährt, werden diese Daten auch für das SDK verfügbar (es sind keine zusätzlichen Berechtigungen erforderlich). Andere Daten, auf die über das SDK zugegriffen werden kann: iCloud-verschlüsselte Daten, API-Token und außerdem alle UIKit-Ansichten, die viele verschiedene Informationen enthalten. Wenn ein Hacker ein SDK abfängt, das Zugriff auf diese Art von Daten hat, können die Folgen, wie Sie wissen, sehr schwerwiegend sein. Gleichzeitig sind alle Benutzer der Anwendung gleichzeitig betroffen.

Wie genau kann das passieren? Lassen Sie uns einen Schritt zurücktreten und über grundlegende Netzwerk-Dinge und deren Missbrauch sprechen.

Netzwerk

Ich warne Sie, dass meine Erklärungen nicht 100% genau und detailliert sein werden. Mein Ziel ist es, die Essenz zu vermitteln, also werde ich alles in einer etwas vereinfachten Form präsentieren. Wenn Sie an den Details interessiert sind, empfehle ich Ihnen, sich meinen Blog anzusehen oder das Thema selbst zu erkunden.

Wie Sie sich erinnern, besteht der Hauptunterschied zwischen dem HTTPS-Protokoll und dem HTTP-Protokoll in der Datenverschlüsselung während der Übertragung. Das Fehlen einer Verschlüsselung in HTTP bedeutet im Großen und Ganzen, dass jeder Host im Netzwerk, falls gewünscht, alle über das Netzwerk übertragenen Pakete frei abhören und ändern kann. Gleichzeitig kann nicht überprüft werden, ob die Integrität des Pakets verletzt wurde. All dies gilt für öffentliche Wi-Fi-Netzwerke sowie passwortgeschützte und lokale Ethernet-Netzwerke.

Bei Verwendung von HTTPS können Netzwerkhosts auch übertragene Pakete abhören, können diese jedoch nicht öffnen. Es sind nur Paketmetadaten sichtbar, insbesondere die Adressen der sendenden und empfangenden Hosts. Darüber hinaus bietet HTTPS eine Überprüfung: Nach Erhalt des Pakets können Sie überprüfen, ob es während der Reise Änderungen erfahren hat.

Bisher funktionierte alles wie folgt. Wenn Sie in der Adressleiste "google.com" eingegeben haben, ohne ein Protokoll anzugeben, hat der Browser Ihre Anfrage standardmäßig über HTTP gesendet. Da der Google-Server jedoch lieber über HTTPS kommuniziert, haben Sie als Antwort darauf einen neuen Link (Weiterleitung) mit dem Präfix "https: //" erhalten. Hier ist ein Bildschirm von Charles Proxy (ein HTTP / HTTPS-Verkehrsüberwachungstool), der dies demonstriert:



Der neue Link selbst wurde jedoch über das HTTP-Protokoll gesendet. Es ist leicht zu verstehen, was hier schief gehen kann: Sowohl die Anfrage als auch die Antwort werden über HTTP übertragen. Dies bedeutet, dass Sie beispielsweise das Antwortpaket abfangen und die darin enthaltene Standort-URL durch "http: //" ersetzen können. Diese einfache Art von Angriff wird als SSL-Strip bezeichnet. Bisher haben Browser bereits gelernt, etwas anders zu arbeiten. Aber zu verstehen, was ein SSL-Strip ist, ist für uns weiter nützlich.

Manchmal können Sie sich an das OSI-Netzwerkmodell erinnern. Ich empfand sie als etwas unerträglich Langweiliges. Später entdeckte er jedoch, dass das OSI-Modell seltsamerweise nicht einfach so existiert und sogar nützlich sein kann.

Wir werden es nicht im Detail betrachten. Das Wichtigste zu verstehen: Alles besteht aus mehreren Schichten, die für verschiedene Dinge verantwortlich sind und gleichzeitig in ständiger Interaktion miteinander stehen.

Eine der Schichten versucht festzustellen, welche MAC-Adresse einer bestimmten IP-Adresse entspricht. Dazu wird eine spezielle Broadcast-Anfrage gestellt, das erste beantwortete Gerät aufgezeichnet und anschließend Pakete an dieses gesendet.



Das Problem ist, dass der Hacker schneller auf die Anfrage antworten kann: "Ja, senden Sie mir alle Pakete." Dies wird als ARP-Spoofing oder ARP-Cache-Vergiftung bezeichnet. In diesem Fall sieht das Schema Ihrer Interaktion mit dem Internet folgendermaßen aus:



Alle Pakete werden jetzt über das Gerät des Hackers übertragen. Wenn der Datenverkehr nicht verschlüsselt ist, kann er lesen und schreiben. Im Fall von HTTPS gibt es weniger Möglichkeiten, aber Sie können nachverfolgen, auf welche Hosts Sie zugreifen.

Interessanterweise haben Internet- und VPN-Anbieter dieselben Befugnisse. Sie sind Vermittler bei Ihrer Interaktion mit dem Internet und stellen in gleicher Weise eine potenzielle Bedrohung für ARP-Spoofing dar.

Der Man-in-the-Middle-Ansatz selbst ist nichts Neues. Aber wie genau trifft dies auf mobile SDKs zu?

Mobile Besonderheiten

CocoaPods ist ein Standardwerkzeug für das Abhängigkeitsmanagement, das in der iOS-Entwicklung verwendet wird. Die Verwendung von CocoaPods für Open Source-Code gilt als praktisch sicher - er wird normalerweise auf GitHub gehostet und normalerweise über HTTPS oder SSH abgerufen. Es gelang mir jedoch, eine Sicherheitslücke zu finden, die auf der Verwendung von HTTP-Links basiert.

Tatsache ist, dass CocoaPods es ermöglicht, das SDK mit geschlossenem Quellcode zu installieren, und Sie müssen nur die URL angeben. Es gibt keine Überprüfung, ob der Datenverkehr verschlüsselt wird, und viele SDKs bieten eine HTTP-Adresse.

In diesem Zusammenhang habe ich mehrere Pull-Anfragen an CocoaPods-Entwickler gesendet, und bald haben sie die Fertigstellung abgeschlossen. Jetzt überprüfen neue Versionen von CocoaPods den benutzerdefinierten Link. Wenn er unverschlüsselt ist, wird eine Warnung angezeigt. Mein Rat ist also: Aktualisieren Sie immer die CocoaPods-Versionen und ignorieren Sie keine Warnungen.

Noch interessanter ist es zu überlegen, wie die Installation von nicht sensorischen SDKs, die nicht von CocoaPods stammen, abläuft. Nehmen Sie zum Beispiel die Localytics-Plattform.



Die Seite docs.localytics.com ist nicht verschlüsselt. Es scheint, dass dies in diesem Fall vernachlässigt werden kann, da dies nur eine Dokumentation ist. Beachten Sie jedoch, dass die Seite unter anderem einen Link zum Herunterladen der Binärdateien enthält. Der Link kann verschlüsselt werden, dies garantiert jedoch keine Sicherheit: Da die Seite selbst über HTTP übertragen wird, kann sie abgefangen und der Link durch einen unverschlüsselten ersetzt werden. Die Entwickler von Localytics wurden über diese Sicherheitsanfälligkeit informiert und sie wurde bereits behoben.

Sie können auch anders vorgehen: Ändern Sie nicht den Link zu HTTP, sondern verlassen Sie HTTPS, sondern ersetzen Sie die Adresse selbst. Dies zu entdecken wird sehr schwierig sein. Schauen Sie sich diese beiden Links an:



Einer von ihnen gehört mir. Welches ist von echten Entwicklern und welches nicht? Versuche zu verstehen.

Übungscheck

Dann beschloss ich, meine Annahmen zu testen, indem ich in der Realität versuchte, den Inhalt des SDK durch einen MITM-Angriff zu ersetzen. Es stellte sich heraus, dass dies nicht so schwierig ist. Für den Aufbau und Betrieb meiner Schaltung habe ich nur wenige Stunden gebraucht, um die einfachsten öffentlichen Tools einzurichten.



Ich vertraute den üblichen Raspberry Pi an, um abzufangen. Im lokalen Netzwerk enthalten, konnte er den Verkehr darin abhören. In den abgefangenen Paketen musste er zuerst alle HTTPS-Links durch HTTP-Links ersetzen und dann alle Localytics iOS-ZIP-Dateien durch die hack.zip-Datei ersetzen. All dies erwies sich als einfach und arbeitete mit einem Knall.



Die Datei trollface.jpg wurde im resultierenden Archiv angezeigt, und die Zeile "Modified by KrauseFx" wurde in der Datei Info.plist angezeigt. Wie viel war für einen solchen Angriff erforderlich? Nur zwei Bedingungen:

1. Sie haben es geschafft, Zugang zu Ihrem Netzwerk zu erhalten (denken Sie daran, dass dies für Internet- und VPN-Anbieter überhaupt keine Frage ist). Mit wie vielen Kaffee- und Hotelketten verbinden wir uns?
2. Der initiierte Download ist unverschlüsselt.

Sie sagen: "Aber ich schaue nur auf das sichere Symbol im Browser, was bedeutet, dass ich in Ordnung bin." Und wenn Sie bei Amazon sind, sollte alles in Ordnung sein, oder?

Ich schlage vor, die Amazon-Site in Betracht zu ziehen. Das AWS Mobile SDK ist das persönliche SDK, mit dem Entwickler Entwickler mit dem Service interagieren können.



Das "sichere" Symbol, eine bekannte Site, scheint nichts zu bedeuten. Aber leider - nur auf den ersten Blick. Der Link zum Herunterladen des SDK wird ohne Präfix angezeigt (weder https: // noch http: //). Gleichzeitig sollte der Benutzer zu einem anderen Host weitergeleitet werden. Daher wechselt der Browser von HTTPS zu HTTP. Wie Sie sehen können, ist der SDK-Download hier unverschlüsselt! Im Moment wurde die Sicherheitslücke bereits von Amazon-Entwicklern behoben, aber es gab wirklich einen Ort, an dem man sein konnte.

Ich muss sagen, dass die Entwicklung moderner Browser auch nicht ohne Berücksichtigung von Sicherheitsproblemen durchgeführt wird. Wenn Sie beispielsweise eine Seite mit HTTPS laden und ein Bild über einen HTTP-Link angezeigt wird, benachrichtigt Sie Google Chrome über den sogenannten „gemischten Inhalt“. Eine solche Sicherheitsmaßnahme ist für Downloads jedoch nicht vorgesehen: Browser verfolgen nicht, welches Protokoll für den auf der Seite angegebenen Download-Link ausgelöst wird. Daher schrieb ich im Rahmen dieses Projekts an Browserentwickler mit der Bitte, gemischte Inhalte zu verfolgen und Benutzer darüber zu informieren.

Apple ID Datendiebstahl

Schauen wir uns nun ein anderes Problem an. IPhone-Benutzer sollten mit diesem regelmäßigen Popup-Fenster vertraut sein:



Links sehen Sie die Originalversion von iOS, rechts meine Kopie. Wie einfach es ist, ein ähnliches Fenster zu simulieren, habe ich vor einigen Monaten in meinem Blog geschrieben. Es dauerte 20 Minuten, um die Ansicht wiederherzustellen.

Das iPhone fordert häufig iCloud-Authentifizierungsdaten an, und für den Benutzer bleibt der Grund für die Anforderung normalerweise unklar. Benutzer sind so daran gewöhnt, dass sie das Passwort automatisch eingeben. Die Frage, wer nach dem Passwort fragt - das Betriebssystem oder die Anwendung - fällt mir einfach nicht ein.

Wenn Sie der Meinung sind, dass es schwierig ist, die E-Mail-Adresse zu ermitteln, an die die Apple ID angehängt ist, übertreiben Sie: Dies kann sowohl über das Kontaktbuch als auch über iCloud-Container erfolgen (wenn Sie Zugriff auf die iCloud-Anwendung haben, über die Sie Informationen erhalten von UserDefaults dieser Anwendung). Und die einfachste Möglichkeit besteht darin, den Benutzer zu bitten, seine E-Mail-Adresse persönlich einzugeben. Theoretisch sollte dies ihn nicht einmal überraschen, da in iOS tatsächlich eine Art Fenster angezeigt wird, in dem nicht nur nach einem Kennwort, sondern auch nach einer E-Mail-Adresse gefragt wird.

Ich dachte: „Was ist, wenn ich diesen Code aus dem Anforderungsformular nehme und mit Hilfe des SDK-Spoofings viele verschiedene Anwendungen durchdringe, um alle iCloud-Passwörter mit ihnen zu stehlen? Wie schwierig ist diese Aufgabe?



Angenommen, wir haben einen vollständig sauberen Mac, auf dem kein VPN oder Proxy installiert ist, aber im selben Netzwerk haben wir unseren Raspberry Pi. Auf dem Mac in Xcode haben wir ein offenes iOS-Projektprojekt, das ein absolutes Minimum an Code enthält - eine einfache Kartenanzeige des Gebiets und nichts weiter.

Öffnen Sie nun den Browser und gehen Sie zu Amazon Web Services. Suchen Sie die AWS Mobile SDK-Seite und folgen Sie dem Download-Link. Entpacken Sie die heruntergeladene Binärdatei und ziehen Sie alle Frameworks in Xcode in unser Projekt. Dann importieren wir die Bibliotheken. Wir müssen nicht einmal Code aufrufen - es reicht aus, dass er heruntergeladen wird. Ich stelle fest, dass Xcode während des gesamten Prozesses keine Warnungen ausgegeben hat.

Was passiert beim Neukompilieren der Anwendung? Die gleiche Kopie des Fensters wird auf dem Bildschirm angezeigt und fordert mich auf, mich beim iTunes Store anzumelden. Ich gebe das Passwort ein, das Fenster verschwindet. Während ich das Anwendungsprotokoll beobachte, sehe ich, wie das von mir eingegebene Kennwort sofort darin angezeigt wird - das Abfangen der Apple ID-Daten ist abgeschlossen. Es wäre einfach, diese Daten irgendwo an den Server zu senden.

Hier können Sie sagen: "Nun, während der Entwicklung würde ich dieses Eingabeformular sofort bemerken und verstehen, dass etwas nicht stimmt." Wenn Sie jedoch ein Publikum von Millionen von Benutzern haben, können Sie es nur einmal pro Tausend herauskriechen lassen und beim Testen unbemerkt bleiben.

Und wieder, wie viel haben wir gebraucht, um den Angriff auszuführen? Es war notwendig, dass unser Computer im Netzwerk war (und der Raspberry Pi war genug). HTTP oder HTTPs - in diesem Fall spielte es keine Rolle, die Verschlüsselung würde die Situation nicht retten. Alle von mir verwendeten Softwaretools - die einfachsten - wurden von mir aus dem öffentlichen Zugriff übernommen. Gleichzeitig bin ich ein gewöhnlicher Entwickler ohne viel Wissen und Erfahrung mit Hacks.

Übernahme durch das Management

Im vorherigen Beispiel wurde bösartiger Code in die iOS-Anwendung eingeführt. Aber was wäre, wenn wir die Kontrolle über den Computer des Entwicklers im Allgemeinen bekommen könnten? Wie Sie wissen, bietet die Möglichkeit, Code auf Ihrem Gerät auszuführen, dem Hacker eine enorme Leistung. Er kann den Fernzugriff über SSH aktivieren, einen Keylogger installieren usw. Er kann Sie jederzeit beobachten, Ihre Aktionen aufzeichnen und das Dateisystem verwenden. Er kann auch neue SSL-Zertifikate installieren und damit alle Anforderungen abfangen, die Sie an das Netzwerk richten. Mit einem Wort, jemand hat die Möglichkeit, Code auf Ihrem Computer auszuführen - und Sie sind völlig gefährdet.

Ich dachte: "Welches iOS SDK kann ich dafür verwenden?" Es gibt einen Dienst, der dem SDK den Befehl curl und eine HTTP-Verbindung mit umgeleiteter Ausgabe zum Befehl sh bereitstellt. Das heißt, Ihr Terminal lädt das Shell-Skript herunter und führt es aus.



Diese Installationsmethode gefährdet Sie bereits. Tun Sie dies nicht. In diesem Fall wurde aber auch das HTTP-Protokoll verwendet. Was ist dann möglich?



Angenommen, Sie sind ein Benutzer. Sie gehen zur offiziellen Dokumentationsseite. Achten Sie darauf, dass die Seite mit dem HTTPS-Protokoll verschlüsselt ist - großartig! Sie kopieren den Befehl und führen ihn zu Hause aus. Der Befehl wird innerhalb weniger Sekunden ausgeführt. Was ist in dieser Zeit passiert?

In dieser Zeit funktionierte ein einfacher Angriffsmechanismus mit meinem Raspberry Pi. Das vom Benutzer geladene Shell-Skript updateSDK enthielt einen kleinen Spritzer meines eigenen Codes. Und jetzt darf ich über SSH remote auf Ihren Computer zugreifen, und Sie haben auch einen Keylogger installiert.



Links sehen Sie „Ihr“ Terminal und rechts meinen Raspberry Pi, der in Echtzeit bereits alles anzeigt, was Sie über die Tastatur eingeben. Nachdem ich mit Raspberry Pi SSH begonnen habe, logge ich mich mit dem Login und dem Passwort ein, die gerade mit dem Keylogger registriert wurden. Auf diese Weise erhalte ich vollen Zugriff auf die Steuerung Ihres Mac und seines Dateisystems. Und wahrscheinlich hat auch Ihr Arbeitgeberunternehmen Zugang zu vielem.

Abschließend

Wie wahrscheinlich ist es, dass Ihnen das passiert? Immerhin versuchen Entwickler immer noch, sicheres WLAN zu nutzen und ein VPN zu kaufen.

Persönlich dachte ich auch, dass ich vorsichtig war, bis ich eines Tages die Einstellungen meines Mac öffnete und in der Geschichte von mehr als 200 Verbindungen zu unsicheren Wi-Fi-Netzwerken entdeckte. Jede solche Verbindung ist eine potenzielle Bedrohung. Und selbst wenn Sie ein vertrauenswürdiges Netzwerk verwenden, können Sie sich Ihrer Sicherheit nicht hundertprozentig sicher sein, da Sie nicht wissen können, ob eines der Geräte in diesem Netzwerk kompromittiert wurde (wie wir gerade gesehen haben).

Angriffe über unsichere Wi-Fi-Netzwerke sind sehr häufig. Sie sind an öffentlichen Orten wie Hotels, Cafés, Flughäfen und übrigens auf Konferenzen leicht zu halten :) Stellen Sie sich einen Redner vor, der über eine Art SDK spricht, und wie üblich versucht ein Teil des Publikums, es parallel zu installieren, indem er eine Verbindung zum hier bereitgestellten WLAN herstellt . Und wie gesagt, es ist sehr einfach, Ihre Rechte an einem Netzwerkanbieter zu missbrauchen.
Genauso wie bei einem VPN übergeben Sie sich einfach dem Anbieter. Und wem kann man besser vertrauen - dem VPN-Anbieter oder Ihrem lokalen Netzwerk und seinen Benutzern? Nicht klar.

Im November 2017 führte ich meine Recherchen durch und analysierte das Vorhandensein der aufgeführten Sicherheitslücken in den 41 beliebtesten SDKs für iOS (ohne die SDKs von Google und Facebook sind sie alle geschützt).



Wie Sie sehen, haben 31,7% des SDK die Tests nicht bestanden. Es gelang mir, über fast alle Lieferanten über die bestehenden Probleme zu informieren. Von einer Antwort, die ich buchstäblich sofort erhielt, war das Problem innerhalb von drei Tagen behoben. Fünf Teams reagierten ebenfalls, verbrachten jedoch etwas mehr Zeit mit der Überarbeitung - etwa einen Monat. Seven hat sich überhaupt nicht die Mühe gemacht, meinen Bericht zu beantworten, und bis heute nichts korrigiert. Ich möchte Sie daran erinnern, dass es sich nicht um einige wenig bekannte Projekte handelt. Alle gehören zu den bekanntesten SDKs und haben Zehntausende von Benutzern, die iOS-Anwendungen mit diesen SDKs entwickeln, die wiederum von Millionen von iPhone-Benutzern verwendet werden.

Es ist wichtig zu verstehen, dass Benutzer geschlossener Anwendungen immer größeren Risiken ausgesetzt sind, während Benutzer von Open Source-Anwendungen weniger verwenden. Sie können nicht überprüfen, wie eine geschlossene Anwendung funktioniert. Es ist äußerst schwierig zu beurteilen, ob es sichere Lösungen gibt. Sie können Hashes und Hash-Summen vergleichen, aber auf diese Weise können Sie den Erfolg des Downloads überprüfen. Im Gegenteil, Sie können Open Source-Produkte gründlich untersuchen, was bedeutet, dass Sie sich selbst mehr Schutz bieten können.

Neben Man-in-the-Middle-Angriffen gibt es noch andere. Ein Hacker kann den Server angreifen, von dem das SDK heruntergeladen wird. Es kommt auch vor, dass das Unternehmen, das das SDK bereitstellt, absichtlich sogenannte Backdoors in den Code einbezieht, über die es anschließend unbefugten Zugriff auf Benutzergeräte erhalten kann (möglicherweise verlangt die lokale Regierung die Installation von Backdoors, und dies ist möglicherweise die Initiative des Unternehmens selbst).

Und wir sind verantwortlich für das Produkt, das wir liefern. Wir müssen sicher sein, dass wir den Benutzer nicht im Stich lassen und die DSGVO einhalten. Angriffe über das SDK sind in erster Linie deshalb schwerwiegend, weil sie massiv sind - sie richten sich nicht an einen Entwickler, sondern an jeweils eine Million Benutzergeräte. Diese Angriffe können von Ihnen fast unbemerkt bleiben. Open Source Code hilft Ihnen, sich davor zu schützen. Mit Closed Source ist alles viel komplizierter - verwenden Sie es nur, wenn Sie ihm sicher vertrauen können. Vielen Dank für Ihre Aufmerksamkeit.

Wenn Ihnen dieser Bericht gefallen hat, achten Sie darauf: Der nächste St. Petersburg Mobius findet vom 22. bis 23. Mai statt, Tickets sind bereits im Verkauf und werden nach und nach teurer.