Android-Anwendungssicherheit. Vortrag in Yandex

    Der Entwickler Dmitry Lukyanenko, dessen Vortrag wir heute veröffentlichen, ist nicht nur ein Yandex-Spezialist, sondern weiß auch, wie man die Stärke von Lösungen von Entwicklern anderer Unternehmen testet. Auf diese Weise können Sie aus den Fehlern anderer lernen - manchmal natürlich nicht ohne Ihre eigenen. In dem Bericht wird Dmitry Beispiele für Android-Sicherheitslücken nennen, einschließlich solcher, die er persönlich gefunden hat. Jedes Beispiel wird von Empfehlungen begleitet - wie man Anwendungen für Android schreibt und wie nicht.



    Mein Name ist Dmitry, ich arbeite für Yandex im Minsker Büro und entwickle einen Account Manager. Dies ist die Bibliothek, die für die Autorisierung von Benutzern verantwortlich ist. Daher werden wir über die Sicherheit von Android-Anwendungen sprechen.

    Ich würde die folgenden Problemquellen herausgreifen. Die ersten sind Netzwerke, die sich auf die Kommunikation mit dem Server beziehen. In diesem Fall werden Ihre Daten auf nicht sehr sichere Weise übertragen. Die zweite hängt mit dem Problem der Datenspeicherung zusammen: Dies ist der Fall, wenn Ihre Daten irgendwo im Klartext gespeichert sind, sie können sogar irgendwo auf der SD-Karte gespeichert werden oder sie werden im Allgemeinen nicht verschlüsselt, wenn von außen auf sie zugegriffen wird.

    Die dritte Art von Problem ist die Auswirkung von Anwendungen von Drittanbietern auf Ihre. In diesem Fall kann eine Drittanbieteranwendung unbefugten Zugriff auf Ihre Anwendungen erhalten, im Namen des Benutzers Aktionen ausführen oder sogar etwas stehlen usw.

    In diesem Bericht konzentrieren wir uns auf die dritte Art von Problemen, die mit den Auswirkungen von Drittanbieteranwendungen verbunden sind. Wir betrachten nicht nur die Theorie, sondern auch konkrete Beispiele aus der Praxis. Darüber hinaus sind einige dieser Beispiele immer noch relevant, anscheinend wurden sie nur bewertet, aber für mich scheinen sie ziemlich interessant zu sein.

    Dieser Bericht wird für diejenigen nützlich sein, die an der Android-Entwicklung beteiligt sind. Ich würde jedem empfehlen, der Anträge stellt, auf diese Aspekte zu achten. Zum Beispiel Tester. Tester, es scheint mir, wenn man sich diese Nuancen ansieht, können sie einige Boni ausknocken, sie werden anfangen, tiefer in die Entwicklung einzutauchen, auch wenn man das Programmieren nicht wirklich lernen kann. Die Manifest-Datei kann einfach potenziell gefährliche Orte analysieren und identifizieren. Und allen anderen, die sich für solche Sicherheitsfragen interessieren.

    Bevor wir beginnen, sollten Sie Software erwähnen, die sich als nützlich erweisen kann. Zunächst einmal können Sie mit BytecodeViewer, einem sehr nützlichen Programm, alle Quellen, alle Ressourcen, einschließlich der Manifest-Datei, mit einem Klick aus der APK-Datei abrufen.

    Es ist erwähnenswert, ein praktisches Dienstprogramm für Android - ManifestViewer. Sie können damit sehr schnell die Manifestdateien aller installierten Anwendungen anzeigen. Ich benutze es zum Beispiel bei der Arbeit, wenn Leute zu mir kommen und sagen: Der Account Manager arbeitet nicht, was ist das? Zunächst schaue ich mir immer die Manifest-Datei an, um sicherzustellen, dass der Account Manager korrekt integriert wurde, dh, alle seine Komponenten werden so deklariert, wie sie sollten.
    Dieses Programm ist nützlich, damit Sie schnell die Einstiegspunkte, den Vektor der Angriffe aus der Manifest-Datei, öffnen und betrachten können.

    Wenn Sie alles von der Konsole aus erledigen möchten, haben Sie hier alle diese Programme separat. Mit apktool können Sie alle Ressourcen und die Manifest-Datei abrufen. Mit Dex2jar und Enjarify können Sie apk-Dateien in jar konvertieren. Dex2jar kann möglicherweise keine apk konvertieren, mit einigen Ausnahmen. Verzweifeln Sie nicht: Oft genjarifizieren Sie diese Dateien und Sie erhalten ein Glas. Dies sind zwei gute Dienstprogramme.

    Sobald Sie die JAR-Dateien haben, können Sie den Java Decompiler nehmen und sie in eine bequemere Ansicht konvertieren - in die Klassenansicht. Es ist klar, dass sie nicht gestartet werden können, aber es ist viel einfacher, sie zu analysieren als den dort erhaltenen Code usw.

    Schauen wir uns die grundlegendsten Probleme an. Zuerst müssen wir die Manifest-Datei analysieren, da sie unbedingt alle Komponenten der Android-Anwendung beschreiben muss. Dies sind Aktivität, Service, Broadcast Receiver, ContentProvider. Alle mit Ausnahme des Rundfunkempfängers müssen da sein.

    Wenn wir also nach Problemen suchen, schauen wir uns diese Komponenten an. Hier ist ein konkretes Beispiel. Dies ist ein Dienst, der in der Manifestdatei einer Anwendung deklariert wurde und explizit exportiert wird. Es wird sogar ausdrücklich angegeben, dass es exportiert wird. Dies bedeutet, dass es für alle anderen Anwendungen von Drittanbietern verfügbar ist. Jede andere Anwendung kann wiederum Absichten an diesen Dienst senden, und der Dienst kann einige Aktionen ausführen, sofern diese dort bereitgestellt werden.

    In diesem Fall sehen wir einen potenziellen Angriffsvektor. Wenn wir uns näher mit der Quelle befassen, wird ihnen klar, dass dieser Dienst es beispielsweise ermöglicht, einen autorisierten Benutzer in diesem Programm zu entfernen. Ich bezweifle, dass die Entwickler eine solche Funktion für einige Anwendungen von Drittanbietern bereitgestellt haben. Dies ist ein konkretes Beispiel, das angesprochen werden sollte.

    Ein weiterer Punkt: Wenn eine Komponente Absichtsfilter verwendet, wird sie standardmäßig auch exportiert. Hier können möglicherweise Anfängerentwickler stolpern. Wenn es einen Absichtsfilter gibt, ist diese Komponente bereits öffentlich. Es sollte vorsichtig sein.

    Ich bin auf solche Probleme gestoßen, als eine Reihe von Aktionen für die Benachrichtigung ausgeführt werden konnten, die im entsprechenden Bereich angezeigt wird. Dies geschah beispielsweise in Yandex.Mail und anderen Anwendungen.

    Was hat diese Veranstaltung gemacht? Es wurde mit dem öffentlichen BroadcastReciever verarbeitet. Das heißt, der Angreifer könnte auch jede Sendung senden - die ID des Briefes abholen und ihn beispielsweise löschen. Und es ist nicht notwendig, dass dies eine Meldung im Panel ist.

    Es war einmal in Yandex.Mail eine solche Sicherheitslücke. Alles wurde bereits repariert, so dass Sie es verwenden können, alles ist in Ordnung. Dank Ildar machen sie das alles schnell.

    Wie wurde das entschieden? Die Komponente wurde einfach von außen unzugänglich gemacht und zusätzlich die Berechtigung gesetzt. Es konnte nicht installiert werden. Hauptsache, wenn es nicht exportiert wird, kann niemand eine Verbindung herstellen und etwas unternehmen.

    Die nächste Art von Problem ist die Verwendung impliziter Absichten, wenn eine Absicht keinen bestimmten Ort angibt, an dem sie auftreten soll. Dies bedeutet, dass Sie keine Garantie dafür haben, dass diese Absicht dahin geht, wo Sie wollen. Er könnte woanders hinkommen. Deshalb muss man hier vorsichtig sein.

    Eine andere Nuance, die ich impliziten Absichten zuschreiben würde, ist Browsable Activity, wenn wir die Aktivität einer Drittanbieteranwendung über unseren Browser öffnen können. Dies geschieht, wenn eine Art Schema angegeben wird, der Host darauf klickt und Ihr Fenster öffnet. Es ist gut, wenn das Fenster gerade geöffnet wurde und beispielsweise die Position auf der Karte übertragen wurde. Das ist nicht schrecklich. Und beängstigend - das Folgende. Nehmen wir an, einige Leute schlagen vor, Slack in einem Unternehmen einzusetzen. Slack hat eine sehr interessante Berechtigung. Wenn Sie sich bei Ihrem Android-Browser angemeldet haben, können Sie sich bei der installierten Slack-Anwendung anmelden. Dies funktioniert nach diesem Schema, wenn der Browser eine URL hat, klicken Sie darauf und die Slack-Anwendung fängt sie ab.

    Es gibt jedoch keine Garantie dafür, dass die URL nicht von einer anderen Person abgefangen wird und ein Token durch diese Person übertragen wird. Das Schema ist ganz einfach: Wenn Sie im Browser klicken, werden Sie sofort in der Slack-Anwendung autorisiert. Diese URL reicht also für die Autorisierung aus.

    Hier sind die Schaltflächen markiert, die im Browser angeklickt werden können und die das Öffnen auslösen. Dies ist nicht nur "Open Slack", sondern auch ein Logo - es ist immer oben auf jedem Bildschirm.

    Sehen wir uns ein Video an, in dem die Verwendung dieses Problems veranschaulicht wird. Wir haben uns angemeldet, sind in unser Verzeichnis gegangen und haben auf das Slack-Logo geklickt. Wir haben jedoch keine Slack-Anwendung. Unser Angreifer hat einen Absichtsfilter eingerichtet. Sie kehrten zurück, klickten ... Sie können Phishing durchführen - genau so wie Slack. Schreiben Sie, dass die Autorisierung nicht funktioniert hat und das alles. Der Benutzer wird nichts verstehen, und Sie werden das Token haben. Wenn Sie Slack verwenden, sollten Sie daher mit dieser Browser-Berechtigung vorsichtig sein.

    Die Lösung ist sehr einfach. Wie mein Kollege sagte, können Sie explizite Absichten verwenden, die über den Browser geöffnet werden. Aber als ich mich bei Slack anmeldete und mein Ticket die Nummer 80.000 mit etwas bekam, sagten sie, dass es ein Duplikat war und dass es bereits ein 50.000 Ticket gab. Wenn Sie schätzen, stellt sich heraus, dass sie vor mehr als sechs Monaten informiert wurden. Es scheint ganz einfach korrigiert, aber nicht behoben zu werden. Dies bedeutet, dass dies kein kritisches Problem ist, und dann können wir darüber sprechen.

    Hier gibt es eine Empfehlung, dass es am besten ist, immer explizite Absichten zu verwenden. Wenn Sie tiefer lesen und vertiefen, werden Sie feststellen, dass Android einen coolen Tippfehler hatte. Sie verwendeten implizite ausstehende Absichten an einer Stelle. Aus diesem Grund war es möglich, auf einen Benutzer mit Systemrechten zuzugreifen. Sie haben diese Fehler in Android 5 behoben. Jeder hat solche Fehler, sogar Google.

    Es ist immer besser, explizite Absichten zu verwenden oder, falls dies nicht möglich ist, immer eine Art von Berechtigung festzulegen. Hiermit können Sie den Zugriff einschränken.

    Betrachten Sie eine andere Art von Sicherheitsanfälligkeit - basierend auf Benutzerdaten.



    Wir haben Anwendungen, die Daten von Benutzern empfangen können, z. B. Dateien senden, öffnen und anzeigen. Dies geschieht normalerweise mit Absichten wie Anzeigen und Senden.

    Diese böswillige Anwendung kann Ihnen Folgendes mitteilen: Senden Sie mir eine Datei, die sich in Ihrem privaten Verzeichnis in Ihrer eigenen Sandbox befindet. Angenommen, diese Datei kann Ihre Datenbank sein, die die gesamte Korrespondenz enthält, oder Einstellungen, wenn einige Token gespeichert sind. Einige Anwendungen führen möglicherweise einige Aktionen mit diesen Dateien aus. Sie können beispielsweise die Datei auf der SD-Karte zwischenspeichern oder an einen anderen Ort senden. Einschließlich können Sie eine solche Aktion ausführen, dass diese Datei für den Angreifer verfügbar wird, obwohl er anfangs davon ausgegangen hat, dass es sich um seine interne Datei handelt.

    Sie können getAbsolutePath () nehmen und prüfen, ob das Verzeichnis mit Ihrem privaten Verzeichnis übereinstimmt. Das ist aber falsch.

    Ein Angreifer sendet Ihnen möglicherweise nicht die Datei selbst, sondern einen Link dazu.

    Wie kann dieser Link erstellt werden? Ein Angreifer erstellt readme.txt - er hat einen Link zu der privaten Datei Ihrer Anwendung erstellt. Dann hat er Ihnen diesen Link hinzugefügt, und wenn Sie getAbsolutePath () verwenden, wird der Linkpfad an Sie zurückgegeben - der Pfad zur Datei readme.txt. Und du denkst, dass alles in Ordnung ist.

    Um dies zu beheben, ist es besser, die Methode getCanonicalPath () zu verwenden. Er gibt den vollen Weg zurück, den wirklichen. In diesem Fall gibt das System nicht readme.txt, sondern eine Art Postfach zurück. Betrachten Sie diese Fragen.

    Ich bin auf eine Situation gestoßen, in der eine Anwendung mit mehr als 50 Millionen Benutzern ein ähnliches Problem hatte. Sie sagen: Zeigen Sie mir diese Datei. Sie speichern es auf einer SD-Karte und versuchen es dann zu öffnen. So war es möglich, alle Token zu stehlen. Sie haben bereits alles repariert, aber gebeten, es noch nicht offenzulegen. Dies tritt jedoch auf.

    Der nächste interessante Punkt: Sie können Ihnen einen Link zum Inhaltsanbieter senden, und es kann auch übertragen werden. Selbst wenn es durch Erlaubnis geschützt ist, wird die Abfragemethode, die sich im Inhaltsanbieter befindet, ausgeführt, wenn Ihre Anwendung versucht, es zu öffnen.

    Hier muss man vorsichtig sein. Hier ist ein weiteres reales Beispiel aus einer anderen Anwendung. Sie haben ein Backup der Datenbank mit der Abfragemethode erstellt. Dort konnte eine Aktion wie Backup übertragen werden und das Programm duplizierte sofort die gesamte Datenbank auf der SD-Karte. Es stellt sich heraus, dass der Provider geschützt ist, aber Sie können ihn so verschieben, dass die gesamte Datenbank abgerufen wird.


    Ich habe noch nie jemanden getroffen, der in der Abfragemethode schreibt, aber es ist immer besser, dort etwas zum Lesen zu öffnen. Und auch - bedenken Sie, dass es SQL-Injection geben kann. Nun gibt es eine Reihe von Anwendungen, in denen ich die Möglichkeit der SQL-Injection entdeckt habe. Sie haben jedoch nur Lesezugriff, und ich habe noch nicht herausgefunden, ob es möglich ist, dort etwas weiter zu tun. Aber was ist, wenn in der SQLite-Datenbank selbst eine Sicherheitslücke vorliegt, mit der Sie eine nicht ganz so harmlose Injektion durchführen können? Es ist jedoch besser, sie nicht zuzulassen, selbst wenn Sie beim Öffnen schreibgeschützt sind.



    Betrachten wir nun ein Problem mit WebView, das in allen Android-Versionen bis zur Version 5.0 funktioniert und die Umgehung von SOP ermöglicht. Daraus schließen wir, dass es in WebView besser ist, niemanden seine Dateien öffnen zu lassen.

    Betrachten Sie diese Art von Angriff. Eine böswillige Anwendung kann Ihre Anwendung fragen, ob sie Zugriff auf WebView hat: Zeigen Sie mir die Datei index.html. Angenommen, Ihre Anwendung hat index.html geöffnet. Der Inhalt der Datei ist sehr einfach - JavaScript, das nach 5 Sekunden die Datei selbst in einen Iframe lädt, lädt sozusagen neu.

    Während dieses Zeitraums löscht die böswillige Anwendung die angegebene Datei und ersetzt sie durch einen symbolischen Link zu der privaten Datei aus Ihrer Anwendung. 5 Sekunden vergehen, es wird neu gestartet, aber der Inhalt darin wird bereits zum Inhalt derselben privaten Datei. Unter Android vor 5.0 und sogar vor WebView wurde anscheinend nicht korrekt überprüft, ob es sich um einen symbolischen Link handelt. Auf diese Weise können Sie den Inhalt lesen. Es sieht so aus - die Dateinamen sind gleich, so dass die SOP nicht beschädigt wird, der Inhalt gesendet werden kann und das bedeutet, dass JavaScript den Inhalt nehmen und an den Server senden kann.

    Diese Art von Angriff ist nicht nur in WebView zu finden. Er arbeitet immer noch bei UCBrowser, das über 100 Millionen Installationen hat. Ich habe dies in einigen Versionen des Android-Browsers vor Android 5.0 gesehen. Wahrscheinlich basiert es auch auf WebView. Auf Samsung-Handys konnte ich dies beispielsweise nicht reproduzieren, aber auf meinem Handy funktioniert Acer.

    Schauen Sie sich ein kurzes Video an, wie dies in UCBrowser funktioniert. Dies ist eine kleine bösartige Anwendung, die jedoch möglicherweise funktioniert. Du bist ins Bett gegangen, Telefon auch, Aktivität beginnt plötzlich, Seite. Du schläfst und da fing es an - eine Art iFrame, Bestätigung, Alarm. Wenn eine Warnung den Inhalt liest, bedeutet dies, dass wir diesen Inhalt trotzdem überall hin senden können. Dies ist bookmark.db, Lesezeichen werden hier gespeichert. Ich denke, diejenigen, die interessiert sind, können nachforschen. Unter Umständen können dort weitere private Benutzerdaten gefunden werden. Sie können auch Cookies stehlen. Sie haben jedoch Cookies, die nach der Website benannt sind, sodass Sie sie sortieren müssen. Sie können VKontakte nehmen. Es gibt immer noch eine Sicherheitslücke, anscheinend sind sie noch nicht behoben und haben es nicht eilig, sie zu beheben.


    Fazit:Wenn Sie eine Webansicht haben, lassen Sie niemanden Ihre Links darin öffnen. Und wenn du noch gibst, dann verbiete zumindest das Öffnen von lokalen Dateien. In dieser Hinsicht ist die Qiwi-Firma sehr gute Kollegen, ich habe ihre Anwendung ausprobiert, ich war froh, dass ich die Datei jetzt öffnen würde - aber nein, sie haben das Öffnen lokaler Dateien verboten und nichts getan.

    Betrachten Sie die folgende Art von nicht trivialem Problem. Es basiert auf den Funktionen der Deserialisierung in Android. Vielleicht können die Entwickler von Java selbst hilfreich sein.

    Stellen Sie sich vor, wir haben eine Absicht, die einige Daten enthält, die an unsere Anwendung übertragen werden - sie nimmt ein Feld und liest es aus der Absicht. Wenn die Anwendung mindestens ein Feld liest, erfolgt eine automatische Deserialisierung aller Daten in der Absicht. Auch wenn sie nicht verwendet werden, werden sie immer noch deserialisiert. Jetzt werden Sie verstehen, was hier gefährlich ist.

    Es gibt einen solchen Bonus in Android bis 5.0: In einigen Versionen wird während der Deserialisierung nicht überprüft, ob die Klasse die Serialisierungsschnittstelle wirklich implementiert.

    Dies bedeutet, dass alle Klassen in Ihrer Anwendung möglicherweise anfällig sind. Ja, sie sind möglicherweise nicht serialisierbar, aber wenn sie den später beschriebenen Kriterien entsprechen ...

    Also, was ist so gefährlich? Wenn ein Objekt erstellt wurde, wird es eines Tages gelöscht. Normalerweise wird die Methode finalize aufgerufen, es gibt nichts Gefährliches, nichts ist implementiert. Bei nativer Entwicklung rufen sie jedoch normalerweise in der finalize-Methode den Destruktor aus dem nativen Bereich auf und übergeben dort einen Zeiger. Ich habe keine native Entwicklung gemacht, aber ich habe untersucht, wie Zeiger dort weitergegeben werden. Wenn dieser Zeiger serialisiert ist, kann der Angreifer seinen eigenen Zeiger ersetzen und entweder einen Fehler über die Speichergrenzen hinaus verursachen oder auf einen anderen Speicher verweisen, der dann Code aufnimmt und ausführt.

    Die Jungs von IBM haben das ausgenutzt. Sie analysierten die gesamte Liste der Klassen auf der Android-Plattform - überprüft mehr als tausend oder wie viele es gibt. Und sie fanden nur einen, der die Kriterien erfüllte: Es war serialisierbar und es serialisierte den nativen Zeiger. Sie nahmen diese Klasse, ersetzten ihren Zeiger, sie wurde serialisiert und deserialisiert. Er war nicht jedes Mal neu. Wir haben einen Proof of Concept gemacht, eine Demonstration, es gibt ein Video. Diese Sicherheitsanfälligkeit ermöglichte es ihnen, mithilfe dieser Klasse Absichten an die Systemanwendung zu senden. So konnten sie beispielsweise die ursprüngliche Facebook-Anwendung entfernen und durch eine gefälschte ersetzen. Das Video dauert ca. 7 Minuten und muss gedreht werden, bis das Finalisieren aufgerufen wird und der Speicher gelöscht wird. Die Schlussfolgerung ist jedoch, dass Sie niemals einen nativen Zeiger deserialisieren müssen.



    Um es zusammenzufassen. Es ist besser, die in Ihrer Anwendung enthaltenen Komponenten niemals zu exportieren. Oder - beschränken Sie den Zugriff mit Erlaubnis. Es ist immer besser, Absichten explizit zu verwenden oder Berechtigungen festzulegen. Vertrauen Sie niemals den Daten, die vom Benutzer kommen - es können Daten über alles, auch in Ihren privaten Bereichen, gespeichert werden. Sie können sie später beschädigen. Achten Sie auf ContentProvider, einschließlich SQL-Injection usw.

    So etwas wie WebView ist überhaupt nicht für Spielzeug geeignet. Wenn es sich in Ihrer Anwendung befindet, schließen Sie sie und lassen Sie niemanden damit spielen.

    Serialisierung, oder besser gesagt, native Entwicklung, ist auch wie ein Spiel, seien Sie vorsichtig damit. Vielen Dank für Ihre Aufmerksamkeit.

    Jetzt auch beliebt: