Abo
  • Services:
Anzeige
Die Funktion zum Verschicken von Bildern und anderen Anhängen in iMessage ermöglicht einen Angriff mittels eines Kompressionsorakels.
Die Funktion zum Verschicken von Bildern und anderen Anhängen in iMessage ermöglicht einen Angriff mittels eines Kompressionsorakels. (Bild: Screenshot)

Apple: Lückenhafte iMessage-Verschlüsselung

Die Funktion zum Verschicken von Bildern und anderen Anhängen in iMessage ermöglicht einen Angriff mittels eines Kompressionsorakels.
Die Funktion zum Verschicken von Bildern und anderen Anhängen in iMessage ermöglicht einen Angriff mittels eines Kompressionsorakels. (Bild: Screenshot)

Kryptographen haben eine Sicherheitslücke bei der Verschlüsselung des iMessage-Protokolls entdeckt. In der Praxis dürfte diese nur sehr schwer ausnutzbar sein, doch sie zeigt, dass das dahinterstehende Protokoll äußerst fragwürdig ist.

Apples iMessage war eines der ersten weit verbreiteten Messaging-Systeme mit eingebauter Ende-zu-Ende-Verschlüsselung. Sicherheitsforscher der Johns-Hopkins-Universität haben sich das System genauer angesehen und dabei eine Sicherheitslücke entdeckt. Der vorgestellte Angriff baut darauf, dass Apple keinen authentifizierten Verschlüsselungsmodus benutzt und verwendet ein neuartiges Oracle-Verfahren, das den verwendeten Kompressionsalgorithmus ausnutzt. Die Lücke praktisch auszunutzen, dürfte nur für sehr mächtige Angreifer praktikabel sein. Es zeigt sich aber, dass Apple beim Design des Protokolls einige Fehler gemacht hat. Mit dem gestrigen iOS-Update wurde ein Workaround bereitgestellt, dieser behebt allerdings das zugrunde liegende Problem nicht.

Anzeige

Keine authentifizierte Verschlüsselung und kein Forward Secrecy

Entdeckt wurde der Angriff von Studenten des bekannten Kryptographen Matthew Green. In seinem Blog erläutert Green den Angriff, ein detailliertes Paper wurde ebenfalls veröffentlicht.

Das Verschlüsselungssystem von iMessage ist nicht öffentlich dokumentiert. Die Firma Quarkslab hatte jedoch 2013 das Protokoll mittels Reverse Engineering analysiert. iMessage verschlüsselt zunächst mittels RSA im OAEP-Modus einen symmetrischen Schlüssel, anschließend wird die eigentliche Nachricht mit diesem Schlüssel und dem AES-Verfahren im Counter-Modus verschlüsselt. Außerdem wird die verschlüsselte Nachricht mittels ECDSA signiert.

Zunächst einmal ist auffällig, dass dieses Verfahren keine Forward-Secrecy-Eigenschaft hat. Bei modernen Verschlüsselungsprotokollen gilt dies eigentlich heutzutage als selbstverständlich. Für den Angriff relevant ist jedoch etwas anderes: Der Counter-Mode ist kein authentifizierter Verschlüsselungsmodus. Nachrichten im Counter-Modus können durch einen Angreifer bitweise manipuliert werden, man spricht in der Kryptographie in solchen Fällen von "Malleability".

Verhindert werden soll die Manipulation von Nachrichten durch die Signatur. Doch genau das funktioniert nicht. Denn ein Angreifer kann schlicht eine bestehende Nachricht abfangen und mit einer eigenen gültigen Signatur eines anderen Accounts versehen.

Das allein ermöglicht noch keinen Angriff, damit könnte man lediglich eine Nachricht eines anderen erneut verschicken. Doch nun hat der Angreifer zumindest die Möglichkeit, dem Opfer eine Nachricht unterzujubeln, von der er zwar den Inhalt nicht kennt, die er aber gezielt manipulieren kann.

Orakel nutzt Gzip-Kompression aus

Um etwas über den Inhalt der Nachricht zu erfahren, kommt nun ein Orakel zum Einsatz. Die Nachrichten werden vor der Verschlüsselung mit dem Gzip-Verfahren komprimiert. Über das gezielte Einschleusen von Fehlern kann der Angreifer etwas über den Inhalt der Nachricht erfahren, allerdings muss er dafür wissen, ob eine manipulierte Nachricht vom Zielsystem erfolgreich dekomprimiert wurde. Ähnliche Orakel-Angriffe gab es in der Vergangenheit schon häufiger in anderen Zusammenhängen, allerdings ist es das erste Mal, dass hierfür eine Kompression ausgenutzt wird. Frühere Angriffe nutzten dafür etwa Padding-Mechanismen (Lucky Thirteen, Bleichenbacher-Angriffe) oder Zeichencodierungen.

Damit der Orakel-Angriff funktioniert, muss der Angreifer jedoch wissen, ob die Dekomprimierung auf dem Zielsystem fehlschlägt oder nicht. Bei normalen iMessage-Nachrichten ist das nicht der Fall, der Angreifer erhält keinerlei Rückmeldung. Doch wenn Bilder oder andere Anhänge über iMessage verschickt werden wird der Angriff möglich. In dem Fall wird ein verschlüsselter AES-Schlüssel als Nachricht zusammen mit einer URL verschickt, üblicherweise werden die eigentlichen Daten dann auf icloud.com abgelegt.

Da die Nachricht manipulierbar ist, kann ein Angreifer die URL des Anhangs durch eine eigene URL ersetzen. Damit erhält der Angreifer die Rückmeldung, die für den Orakel-Angriff nötig ist. Wird eine Nachricht erfolgreich dekomprimiert, ruft das Zielsystem die URL auf. Schlägt die Dekomprimierung fehl, erfolgt kein Zugriff auf die URL.

Der gesamte Angriff dauert in der vorgestellten Form etwa 70 Stunden und es müssen circa 250.000 Nachrichten an das Opfer geschickt werden. Matthew Green geht aber davon aus, dass sich dies weiter optimieren lässt.

Transportverschlüsselung und Key Pinning

Eine weitere Hürde dürfte den Angriff in der Praxis meistens verhindern: Die iMessage-Nachrichten sind nicht nur selbst verschlüsselt, für die Kommunikation zwischen den Apple-Servern und den Clients kommt zusätzlich eine Transportverschlüsselung zum Einsatz. Theoretisch wäre es denkbar, dass ein Angreifer sich durch die Kompromittierung einer Zertifizierungsstelle ein gültiges Zertifikat für die Apple-Server verschafft, doch unter iOS 9 wird auch das verhindert. Apps wie iMessage nutzen Key Pinning, um Verbindungen mit unberechtigt ausgestellten Zertifikaten zu verhindern.

Praktisch durchführbar ist der Angriff also bei modernen Systemen nur, wenn jemand direkt Zugriff auf Apples Server hat. Das dürfte in den wenigsten Fällen praktikabel sein. Doch genau das ist eigentlich das Versprechen einer Ende-zu-Ende-Verschlüsselung: Dass selbst der Betreiber eines Services nicht in der Lage ist, die Verschlüsselung anzugreifen.

Schlechtes Protokolldesign

Das iMessage-Protokoll wirkt aus kryptographischer Sicht alles andere als solide. In modernen Protokollen werden zur symmetrischen Verschlüsselung üblicherweise authentifizierte Verschlüsselungsmodi wie GCM oder Poly1305 eingesetzt. Diese sorgen dafür, dass eine Nachricht nicht nur verschlüsselt wird, sondern auch die Echtheit einer Nachricht durch den Schlüssel gewährleistet ist. Manipulationen der Nachricht sind damit nicht mehr möglich, da jede manipulierte Nachricht bereits bei der Entschlüsselung entdeckt und verworfen wird.

Apples Gegenmaßnahme wirkt aus dieser Sicht eher fragwürdig. Der Angriff wird künftig verhindert, indem iMessage den Teil der Nachricht, in dem sich der RSA-verschlüsselte AES-Key befindet, auf Doppelungen prüft. Wenn mehrere Nachrichten ankommen, die mit dem selben AES-Schlüssel verschlüsselt sind, werden diese verworfen. Dadurch wird der konkrete Angriff verhindert, das Protokolldesign wirkt aber weiterhin sehr fragil. Konstruktionsmängel wie die fehlende Forward-Secrecy-Eigenschaft bestehen natürlich auch weiterhin.

Matthew Green scheint ebenfalls nicht sehr glücklich mit dieser Lösung. Langfristig solle Apple iMessage am besten vergessen und stattdessen Signal mit dem Axolotl-Protokoll nutzen, meint Green.


eye home zur Startseite
matty3d 26. Mär 2016

Jobs war ja noch innovativ, aber seit der tot ist scheint Apple nur noch zu einer...

nakamura 23. Mär 2016

Facepalm.

JarJarThomas 22. Mär 2016

Weil es DAMALS nicht existierte

masel99 22. Mär 2016

Wenn man Zugriff auf die Apple-Server hat kann man noch ganz andere Dinge... Natürlich...

immatoll 22. Mär 2016

Der zweite Kommentar von jemanden der nur Überschriften lesen kann... Herrlich diese...



Anzeige

Stellenmarkt
  1. Blickle Räder+Rollen GmbH u. Co. KG, Rosenfeld
  2. init AG, Karlsruhe
  3. T-Systems on site services GmbH, Leinfelden-Echterdingen
  4. Intergraph PP&M Deutschland GmbH, Dortmund


Anzeige
Top-Angebote
  1. 199,00€
  2. 0,90€
  3. 3 Monate gratis testen, danach 70€ pro Jahr

Folgen Sie uns
       

Anzeige
Whitepaper
  1. Mehr dazu im aktuellen Whitepaper von Bitdefender
  2. Globale SAP-Anwendungsunterstützung durch Outsourcing
  3. Mehr dazu im aktuellen Whitepaper von IBM


  1. Spionage im Wahlkampf

    Russland soll hinter neuem Hack von US-Demokraten stecken

  2. Comodo

    Zertifikatsausstellung mit HTML-Injection ausgetrickst

  3. Autonomes Fahren

    Mercedes stoppt Werbespot wegen überzogener Versprechen

  4. Panne behoben

    Paypal-Lastschrifteinzug funktioniert wieder

  5. Ecix

    Australier übernehmen zweitgrößten deutschen Internetknoten

  6. Die Woche im Video

    Ab in den Urlaub!

  7. Ausfall

    Störung im Netz von Netcologne

  8. Cinema 3D

    Das MIT arbeitet an 3D-Kino ohne Brille

  9. AVM

    Hersteller für volle Routerfreiheit bei Glasfaser und Kabel

  10. Hearthstone

    Blizzard feiert eine Nacht in Karazhan



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Verbindungsturbo: Wie Googles Rack TCP deutlich schneller machen soll
Verbindungsturbo
Wie Googles Rack TCP deutlich schneller machen soll
  1. Black Hat 2016 Neuer Angriff schafft Zugriff auf Klartext-URLs trotz HTTPS
  2. Anniversary Update Wie Microsoft seinen Edge-Browser effizienter macht
  3. Patchday Microsoft behebt Sicherheitslücke aus Windows-95-Zeiten

Headlander im Kurztest: Galaktisches Abenteuer mit Köpfchen
Headlander im Kurztest
Galaktisches Abenteuer mit Köpfchen
  1. Hello Games No Man's Sky braucht kein Plus und keine Superformel
  2. Hello Games No Man's Sky droht Rechtsstreit um "Superformel"
  3. Necropolis im Kurztest Wo zum Teufel geht es weiter?

Elementary OS Loki im Test: Hübsch und einfach kann auch kompliziert sein
Elementary OS Loki im Test
Hübsch und einfach kann auch kompliziert sein
  1. Linux-Distribution Ubuntu diskutiert Ende der 32-Bit-Unterstützung
  2. Dells XPS 13 mit Ubuntu im Test Endlich ein Top-Notebook mit Linux!
  3. Aquaris M10 Ubuntu Edition im Test Ubuntu versaut noch jedes Tablet

  1. Re: Sind die Nutzer alle zu Blöd den "Downloads...

    KrasnodarLevita... | 02:29

  2. Re: Zu Teuer (wie immer)

    HagbardCeline | 01:48

  3. Re: Sind 31000 ¤ jetzt viel oder wenig?

    DonDöner | 01:35

  4. Re: Das beste an Win7 gibts nicht mehr in Win10

    slead | 01:22

  5. Re: Der einzige Grund für einen Telekom Vertrag

    quineloe | 01:13


  1. 14:22

  2. 13:36

  3. 13:24

  4. 13:13

  5. 12:38

  6. 09:01

  7. 18:21

  8. 18:05


  1. Themen
  2. A
  3. B
  4. C
  5. D
  6. E
  7. F
  8. G
  9. H
  10. I
  11. J
  12. K
  13. L
  14. M
  15. N
  16. O
  17. P
  18. Q
  19. R
  20. S
  21. T
  22. U
  23. V
  24. W
  25. X
  26. Y
  27. Z
  28. #
 
    •  / 
    Zum Artikel