MIT-Kurs "Computer Systems Security". Vorlesung 20: Mobiltelefonsicherheit, Teil 3

Massachusetts Institute of Technology. Vorlesung # 6.858. "Sicherheit von Computersystemen." Nikolai Zeldovich, James Mickens. 2014 Jahr

Computer Systems Security ist ein Kurs zur Entwicklung und Implementierung sicherer Computersysteme. Die Vorträge behandeln Bedrohungsmodelle, Angriffe, die die Sicherheit gefährden, und Sicherheitstechniken, die auf jüngsten wissenschaftlichen Arbeiten basieren. Zu den Themen gehören Betriebssystemsicherheit, Funktionen, Informationsflussmanagement, Sprachsicherheit, Netzwerkprotokolle, Hardwaresicherheit und Sicherheit von Webanwendungen.

Vorlesung 1: „Einführung: Bedrohungsmodelle“ Teil 1 / Teil 2 / Teil 3
Vorlesung 2: „Kontrolle von Hackerangriffen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 3: „Pufferüberläufe: Exploits und Schutz“ Teil 1 / Teil 2 / Teil 3
Vorlesung 4: „Trennung von Privilegien“ Teil 1 / Teil 2 / Teil 3
Vorlesung 5: „Woher kommen Sicherheitssysteme?“ Teil 1 / Teil 2
Vorlesung 6: „Chancen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 7: „Native Client Sandbox“ Teil 1 / Teil 2 / Teil 3
Vorlesung 8: „Netzwerksicherheitsmodell“ Teil 1 / Teil 2 / Teil 3
Vorlesung 9: „Sicherheit von Webanwendungen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 10: „Symbolische Ausführung“ Teil 1 / Teil 2 / Teil 3
Vorlesung 11: „Ur / Web-Programmiersprache“ Teil 1 / Teil 2 / Teil 3
Vorlesung 12: Netzwerksicherheit Teil 1 / Teil 2 / Teil 3
Vorlesung 13: „Netzwerkprotokolle“ Teil 1 / Teil 2 / Teil 3
Vorlesung 14: „SSL und HTTPS“ Teil 1 / Teil 2 / Teil 3
Vorlesung 15: „Medizinische Software“ Teil 1 / Teil 2 / Teil 3
Vorlesung 16: „Seitenkanalangriffe“ Teil 1 / Teil 2 / Teil 3
Vorlesung 17: „Benutzerauthentifizierung“ Teil 1 / Teil 2 / Teil 3
Vorlesung 18: „Privates Surfen im Internet“ Teil 1 / Teil 2 / Teil 3
Vorlesung 19: „Anonyme Netzwerke“ Teil 1 / Teil 2 / Teil 3
Vorlesung 20: „Sicherheit von Mobiltelefonen“ Teil 1 / Teil 2 / Teil 3

Student: In vielen Anwendungen gibt es keine Möglichkeit, Berechtigungen zu entfernen.

Professor: Ja, in der neuen Version von Android ist dies nicht der Fall, es gibt lediglich Berechtigungsbeschreibungen. Sie können jedoch den Android-Berechtigungsmanager oder den Android-Berechtigungsmanager verwenden, mit dem Sie eine Liste aller Berechtigungen für jede Anwendung anzeigen und speziell diejenigen löschen können, die Sie für unnötig halten. Aber ich weiß nicht, wie beliebt dieses Ding bei Benutzern ist.

Schüler: Wenn die Beschriftungen nicht mit den für die Anwendung erforderlichen Berechtigungen übereinstimmen, führt dies zu einem schwerwiegenden Fehler oder funktioniert weiterhin alles einwandfrei?

Professor: Ich denke, es hängt davon ab, was die Anwendung versucht und was das Etikett zulässt. Wenn eine Anwendung beispielsweise eine Absicht senden soll und für das Senden dieser Absicht eine bestimmte Bezeichnung vom Typ DIALPERM erforderlich ist, wird zunächst der Verbindungsmonitor aufgerufen, auf dem steht: "Leider verfügt das System nicht über eine Anwendung, die zum Empfang Ihrer Nachricht bereit ist." Als Reaktion auf diese Anwendung werden einige vernünftige Schritte unternommen.



Ansonsten zum Beispiel beim Zugriff auf das Netzwerk. Wenn Sie keinen Zugriff auf das Netzwerk haben und den Socket öffnen oder den Befehl zum Herstellen einer Verbindung mit der IP-Adresse erteilen möchten, antwortet Ihnen der Kernel mit der Meldung EPERM "Operation nicht zulässig", dh Sie können dies nicht tun. Und wer weiß, was die Anwendung in diesem Fall tun wird? Es ist möglich, dass es irgendwie eine Nullzeigerausnahme auslöst oder so etwas tut.

Ein Argument dagegen ist, dass Android-Anwendungen zumindest anfangs nicht damit gerechnet haben, dass einige ihrer Aufrufe fehlschlagen, da ihnen mitgeteilt wurde, dass das Manifest alles oder nichts ist, dh entweder vom Benutzer genehmigt Installation der Anwendung oder nicht. Daher haben die Anwendungsentwickler den Code korrekt geschrieben, was abstürzt oder etwas Unerwartetes bewirkt, wenn ihm der Zugriff verweigert wird. Wenn Sie der Anwendung die erforderlichen Zugriffsberechtigungen entziehen, provozieren Sie möglicherweise einen Ausfall des Betriebs.

Angenommen, Sie haben eine Anwendung, die Zugriff auf die Kamera benötigt. Und wenn Sie ihm das Zugriffsrecht entziehen, wird die Bildvorlage einfach auf dem Smartphone-Bildschirm angezeigt, oder die Anwendung stürzt ab. Das ist nicht sehr gut. Wahrscheinlich wäre es möglich, ein komplexeres System zu schaffen, das im Falle eines Zugriffs auf die Kamera einfach immer einen schwarzen Bildschirm anzeigt. Android tut dies nicht, aber Sie können sich alternative Situationen vorstellen, in denen dies passieren könnte.

Daher haben wir untersucht, woher diese Zeilen in den Android-Anwendungsbezeichnungen stammen. Aber wer definiert diese Zeilen, woher beziehen sie die Bedeutung? Sie können alle Arten von Zeilen in der Manifestdatei auflisten. Wie entscheiden Sie jedoch, welche Zeilen wichtig sind und woher die Zeilen INTERNET oder FRIENDVIEW stammen? Wer gibt ihnen Bedeutung im System?



Ich sehe, du hast keine Ideen. Ich denke, dass keine dieser Zeilen etwas Magisches oder Vorbestimmtes sein sollte. Bei fast allen diesen Zeilen handelt es sich im Wesentlichen um Vereinbarungen zwischen zwei Anwendungen, wenn eine der Anwendungen bereit ist, etwas unter dem Schutz einer Label-Zeile bereitzustellen, und die andere Anwendung die Erlaubnis anfordern möchte, mit der von dieser Komponente bereitgestellten Anwendung zu sprechen.

Daher werden diese Bezeichnungen normalerweise von einer Anwendung definiert, die einige Dienste bereitstellt. Wenn Sie über die DIALPERM-Berechtigung verfügen, muss diese in der Anwendung definiert werden. Diese definiert, was das Wählen einer Telefonnummer bedeutet. Anscheinend definiert die Anwendung zum Tätigen von Anrufen auf Ihrem Telefon diese Leitung und sagt, dass diese DIALPERM-Sache existiert und meine Komponenten dadurch geschützt werden. Andere Anwendungen, die mit der aufrufenden Anwendung interagieren möchten, können diese DIALPERM-Berechtigung für sich selbst anfordern.

Natürlich gibt es einige eingebaute Dinge, wie die Erlaubnis zur Nutzung des Internets, eine Kamera und so weiter. Sie können sie jedoch als Quellanwendungen der Android-Laufzeit wahrnehmen, die für den Zugriff auf diese Ressource verantwortlich ist und die Zeile definiert, die diese Ressource schützt.

Was bedeutet das? Was ist mit dem Label in Android noch verbunden, außer der Tatsache, dass es von der Anwendung verwendet wird, wenn sie eine Erlaubnis anfordern muss? Es stellt sich heraus, dass mit dem Etikett mehrere Dinge verbunden sind. Neben der Zeichenfolge weist das Etikett mehrere interessante Eigenschaften auf. Insbesondere in Android gibt es 3 Arten von Tags. Das erste sind reguläre Berechtigungen, das zweite sind unsichere Berechtigungen und das dritte sind signierte Berechtigungen.



Die Anwendung, die diese Berechtigung zuerst bestimmt, erhält die Möglichkeit, den Typ und alle anderen Felder für das Etikett auszuwählen, über die wir in einer Sekunde sprechen werden. Was sind diese Tag-Typen? Warum brauchen Android-Labels Typen?

Student: Dienen sie dem Benutzer als Warnung?

Professor: genau. Warum dann nicht alle Tags eines unsicheren Typs erstellen? Was ist die Semantik dieser Typen? Einfach ausgedrückt, wird ein „gefährliches“ Etikett verwendet, um eine Anwendung zu ermöglichen, die etwas ruinieren könnte. Es warnt Benutzer bei der Installation der Anwendung, wenn die Anwendung Zugriff auf eine unsichere Berechtigung anfordert. Gleichzeitig sollte der Benutzer diese Nachricht lesen und sagen: "Ja, ich bin bereit, dieser neuen Anwendung eine unsichere Berechtigung zu erteilen." Wenn Anwendungen eine Beschriftung des üblichen Typs anfordern, erhält der Benutzer keine Nachricht über die Notwendigkeit, die Berechtigung für diese Aktion zu erteilen. Was bedeuten normale Berechtigungen, wenn alle Anwendungen sie erhalten? Gibt es einen Grund, warum wir normale Typetiketten verwenden sollten?

Ein Beispiel für eine typische Auflösung in Android ist das Festlegen von Hintergrundbildern auf dem Bildschirm. Wenn Sie eine Anwendung haben, die das Hintergrundbild installieren soll, kann ich als Anwendungsentwickler in meinem Manifest angeben, dass ich das Hintergrundbild nur für Sie installieren möchte. Und wenn Sie auf Installieren klicken, passiert nichts Interessantes, da Sie dieser Anwendung keine Berechtigungen erteilen müssen.

Student: Aber diese Berechtigungen erfordern normalerweise eine Bestätigung von Ihnen, oder? Wenn die Anwendung das Desktop-Hintergrundbild ändern möchte, werden Sie vom System gefragt, ob Sie das Hintergrundbild ändern möchten.

Professor: nein.

Student: nein?

Professor: Nein, es ändert nur das Hintergrundbild, weil es nur Zugriff auf den API-Aufruf ist. Wenn ich diese Berechtigung habe, mache ich einfach einen API-Aufruf.

Student: Vielleicht möchte der Anwendungsentwickler sicherstellen, dass Benutzer dies nicht versehentlich tun?

Professor: Ja, ich denke, dass dies einer der Gründe ist, warum Sie diese Berechtigungen benötigen, ist der Wunsch, dem Entwickler zu helfen, Fehler zu vermeiden. Wenn Sie befürchten, dass Ihre Anwendung versehentlich etwas falsch macht oder Fehler darin enthalten sind, die verwendet werden können, verringert das Vorhandensein einer Reihe von Berechtigungen, die Sie möglicherweise erhalten oder nicht, die Wahrscheinlichkeit eines Missbrauchs Ihrer Anwendung. Wenn Sie also eine harmlose Anwendung haben, für die kein Hintergrundbild installiert werden muss, müssen Sie keine Erlaubnis anfordern, da dies für den Benutzer besser ist, auf dessen Telefon sie installiert ist. Bis zu einem gewissen Grad ist dies eine Art Privileg.

Eine andere Sache ist, dass das Vorhandensein von Labels des üblichen Typs es Ihnen ermöglicht, eine Art Audit sowohl von der Entwicklerseite als auch von der Benutzerseite durchzuführen. Wenn Ihr Telefon das Hintergrundbild auf dem Bildschirm jede Sekunde ändert, können Sie nachsehen, welche Anwendung die Berechtigung dafür hat. Auch wenn Sie der Erteilung einer solchen Genehmigung nicht zugestimmt haben, können Sie dennoch überprüfen, welche Anwendung derzeit das Hintergrundbild ändert.

Daher scheinen diese allgemeinen Berechtigungen eine gute Sicherheitsmaßnahme oder in größerem Umfang eine gute Gelegenheit zu sein, die Anwendungsaktivität zu prüfen. Normalerweise wird diese Art von Etikett nicht für wirklich wichtige Dinge verwendet, z. B. für die Arbeit mit Daten oder den Zugriff auf Dienste, die Geld kosten.

Der dritte Etikettentyp ist die Signaturberechtigung. Eine interessante Eigenschaft von Android ist die Möglichkeit, nur auf Anwendungen zuzugreifen, die mit derselben digitalen Signatur signiert sind wie die Anwendung, in der das Zugriffsrecht deklariert ist. Der Vorlesungsartikel beschreibt ein Beispiel mit FRIENDVIEW. Wenn das Anzeigen von Freunden eine Berechtigung für diesen Tag-Typ definiert hat, können Anwendungen, die mit demselben Entwicklerschlüssel signiert sind, dieselbe Berechtigung erhalten. Was ist der Sinn dieser Sache? Warum sie nicht einfach als unsicher markieren? Warum brauchen wir eine dritte Art von Etiketten?

Student: Erleichtert es einem Entwickler die Verwaltung seiner Anwendungen?

Professor: Ja. Es kann sein, dass dieser Entwickler über interne APIs verfügt, die er von den Auswirkungen von Programmen von Drittanbietern isolieren möchte, gleichzeitig aber seine eigenen Anwendungen für eine produktive Interaktion bündeln möchte. Hypothetisch könnten die Macher von Facebook mehrere Anwendungen schreiben. Sie könnten eine Anwendung haben, die Inhalte von Facebook-Servern vorlädt, eine andere Anwendung mischt diese Inhalte, eine dritte verfolgt Ihren Standort und alle diese Komponenten interagieren miteinander. Für einen solchen Fall könnten sie eine unterschriebene Genehmigung verwenden.

Einer der Gründe, warum Sie diese Anwendung nicht als unsicher kennzeichnen möchten, ist der folgende. Wenn Sie wirklich wissen, wer diese Berechtigung erhalten kann, möchten Sie nicht, dass der Benutzer eingreift. Da der Benutzer immer getäuscht werden kann, indem er die Erlaubnis erzwingt, eine bösartige Anwendung zu erteilen, ist es besser, dass er die Bereitstellung interner Berechtigungen für einige Anwendungen überhaupt nicht beeinträchtigt. In diesem Sinne ist es besser, signierte Berechtigungen zu verwenden.

Beschriftungen enthalten auch eine Beschreibung der Benutzerberechtigungen. Dies ist eine Beschreibung dessen, was diese Erlaubnis beinhaltet. Diese Beschreibung wird angezeigt, wenn Sie aufgefordert werden, eine neue Anwendung zu installieren.



Daher überprüft die Android-Laufzeit alle Beschriftungszeilen im Manifest der Anwendung, die Sie installieren möchten, und zeigt dem Benutzer Beschreibungen aller dieser markierten Zeilen an, z. B.: "Sie geben dieser Anwendung das Privileg, zu wählen oder das Senden von SMS in Ihrem Namen zuzulassen" und usw.

Eine interessante Frage: Was passiert, wenn eine böswillige Anwendung die Bezeichnung für eine andere Anwendung ändert? Immerhin sind diese Marken nur Freiformzeichenfolgen. Was passiert also, wenn Sie eine bösartige Anwendung sind, die sagt: „Oh, ich habe diese neue, große Lösung! Es heißt DIALPERM. " Es hat kein unsicheres Etikett und seine Beschreibung gibt nichts. Das ist gefährlich?

Student: Die Struktur des Domainnamens der Anwendung wird wahrscheinlich nicht beeinflusst.

Professor: Ja, das kann man sich erhoffen, aber leider ist dies nicht zwingend erforderlich. Normalerweise sollten alle Berechtigungszeichenfolgen Domänennamen im Java-Stil haben, es besteht jedoch keine strikte Beziehung zwischen den von der Anwendung definierten Bezeichnungen und dem eigenen Namen der Anwendung im Java-Stil. Es gibt nichts, was den Java-ähnlichen Anwendungsnamen dazu zwingt, an etwas gebunden zu sein. Daher haben wir nicht die Möglichkeit herauszufinden, ob der öffentliche Entwicklerschlüssel, der die bestimmte Anwendung signiert, mit etwas auf com.google.something oder edu übereinstimmt. mit etwas.

Es gibt einen Nachteil in Android oder gab es zumindest, als ich mich kürzlich mit dieser Frage befasste. Bei der Definition der Labels wird also das Prinzip „Wer zuerst kam, wird bedient“ bedient. Das heißt, wenn Sie die Anwendung installieren, definiert sie ein bestimmtes Etikett, und Sie können entscheiden, um welchen Etikettentyp es sich handelt und wie seine Beschreibung lautet. Für Systemberechtigungen ist dies wahrscheinlich kein großes Problem, da Systemberechtigungen oder eingebettete Anwendungen, wie z. B. ein Dialer, ganz am Anfang definiert werden. Anwendungen, die später installiert werden, können Berechtigungen jedoch nicht überschreiben, da dies auf das Framework zurückzuführen ist.

Das Problem ist, dass, wenn Sie zuerst eine schädliche Anwendung und dann eine wichtige Anwendung installieren, die schädliche Anwendung möglicherweise die später von der gut gemeinten Anwendung verwendeten Bezeichnungen verzerren kann. Der Vorlesungsartikel beschreibt einen Fall, in dem ein Angreifer einen Benutzer zwingt, eine schädliche Anwendung zu installieren, die den Etikettentyp für die FRIENDVIEW-Anwendung in einen normalen Typ mit einer Beschreibungszeile wie "Es gibt überhaupt nichts Interessantes" ändert. Wenn Sie später das FRIENDVIEW-Applet installieren, kann es diese Bezeichnung nicht mehr überschreiben, da sie bereits definiert ist. Jetzt kann der Benutzer nicht mehr verhindern, dass andere Anwendungen die Berechtigung zum Anzeigen von Freunden verwenden.

Student: Vielleicht könnte das System vor Versuchen warnen, die Auflösung zu ändern?

Professor: Im Prinzip ist das Framework dazu in der Lage, aber als ich dies versuchte, wurden keine Nachrichten ausgegeben. Wenn Sie eine Anwendung installieren, die eine bereits definierte Bezeichnung definiert, tut das System nichts, ignoriert einfach die neue Etikettendefinition und verwendet die alte. Vielleicht ist dies das Problem, aufgrund dessen alles schief gehen kann. Zumindest müsste das System sagen: "Ich lehne die Installation dieser Anwendung ab, da bereits eine Etikettendefinition vorhanden ist."

Student: ... und gehört zu einer anderen Anwendung.

Professor: Ja, und kann sogar zu einem anderen Schlüssel gehören. Dann besteht zumindest möglicherweise die Möglichkeit, alles zu reparieren. Ich habe dieses Problem nicht verfolgt, vielleicht wurde es bereits behoben. In jedem Fall ist dies ein interessantes Problem, wenn Sie diese Namen wirklich im Auge behalten und herausfinden müssen, wem dieser Name gehört, und das Recht erhalten, solche Aktionen durchzuführen, ist wirklich sehr wichtig.

Ein weiteres interessantes Android-Problem betrifft den Broadcast-Empfänger oder den Empfänger von Broadcast-Nachrichten. Es bietet die Möglichkeit, Nachrichten von anderen Anwendungen zu empfangen und darauf zu antworten, und implementiert beispielsweise das Senden von Nachrichten zwischen Anwendungen. Zuerst muss ich beschreiben, wie diese Nachrichten mit dem Empfänger interagieren. Broadcast-Empfänger werden für eine Anwendung verwendet, die einige Ereignisse für jede andere Anwendung im System ankündigen kann.



Wie wir wissen, richten sich Absichten normalerweise an eine bestimmte Komponente, beispielsweise einen JPEG-Bildbetrachter. Über Ereignisse wie das Laden des Systems oder "Meine Freunde in der Nähe" können Sie jedoch jede Anwendung informieren, die dies betrifft. Dafür ist der Rundfunkempfänger da.

Es gibt zwei Dinge, die Sie betreffen. Zunächst die Authentifizierung der Quelle der Nachricht, dh Sie möchten wissen, wer diese Nachricht gesendet hat und ob Sie ihr vertrauen können. Zweitens möchten Sie steuern, an wen diese Nachricht gerichtet ist und wer sie empfangen kann.

Es scheint mir, dass die Android-Entwickler diese Dinge nicht richtig implementiert haben. In der ersten Version von Android unterstützen diese Anwendungen diese Nachricht möglicherweise, wenn Sie eine Broadcast-Nachricht an alle anderen Komponenten des Systems senden. Wenn Sie über die Friends Viewer-Anwendung verfügen, werden diese Nachrichten daher mithilfe der entsprechenden Komponenten wie Aktion oder Datum / MIME in ihrem Intent Intent-Filter unterstützt. Die meisten Anwendungen können jedoch immer alle Broadcast-Ereignisse im System unterstützen, und Sie können alles sehen, was auf dem Telefon passiert, oder alles, was gesendet wird.

Daher hat das Android-Framework ein zusätzliches Argument für Anwendungen hinzugefügt, um anzugeben, wer die Broadcast-Nachricht sehen kann.



, , – , , . , , , , .

, , , , , , . Android, , , , .

, ? , « » , . , ? ?

: ? ?

: , . App 1 RM, , , App 2, , . , App 1 , ? Android ?

, . , , . , . ? , « »?

: , , ?
: . , — . , , « ».



Broadcast receiver, , , . , , , Label.

. Android , . « », . , . , , , .

RPC , RPC-, , . , .

: ?

: , , .

: , …

: , . – . . : « ».

: ?

: .

: , ?

: , , . . , , , . , — . , : « , », , , Dangerous Description.



, : „ , ». , , , , . , Android , .

, , Android. , , . , «», « ». , , .



, , . , , , , , . , Java. , , , , .

Android . - , , , , . «» , RPC . , .

, , . , Android , 5 6 . , , , - «». , , .

, Android , , Apple . , Apple iPhone , .

«», «», , , , , , , . , . , , Android, . , - .

, Android .


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?