Deutsch | English
Dieser Blog enthält keine offiziellen Aussagen von CERT.at, sondern persönliche Meinungen einzelner Mitarbeiter.
Es steht KRACK auf dem Speiseplan!
16. Oktober 2017

Auch wenn die Arbeit für ein nationales CERT reichlich stressig ist, für den Konsum harter Drogen reicht die Verzweiflung dann doch noch nicht, auch wenn der Titel dieses Eintrages vielleicht anderes suggerieren mag. Nein, heute wurden Details zu den sogenannten "Key Reinstallation Attacks", kurz "KRACK", veröffentlicht (technisches Paper / Webseite).

Kurz zusammengefasst stellen diese Schwachstellen die ersten Angriffsmöglichkeiten gegen WPA2 auf Protokollebene dar, bisherige Angriffe gegen moderne Drahtlosnetzwerke richteten sich gegen veraltete Standards, wie WPA-TKIP, Technologien wie WPS, oder waren schlichtweg schnödes Bruteforce. Dementsprechend gross ist auch die Aufregung innerhalb der Community und der Medienwelt. Wie berechtigt ist diese allerdings tatsächlich?

Auf den ersten Blick wirkt die Situation relativ dramatisch, je nach konkreter Implementation des Standards ist es möglich, nahezu beliebig verschlüsselte Pakete zu entschlüsseln, zu manipulieren oder gar gänzlich zu fälschen. Das bedeutet dass Daten die nicht auf anderer Ebene verschlüsselt sind (z.B. via TLS), für einen Angreifer potentiell lesbar sind. Persönliche Daten, Kreditkartennummern, Benutzernamen und Passwörter - die Liste an gefährdeten Informationen ist lang.

In der Praxis, so schreiben die Autoren in dem oben verlinkten Paper selbst, gibt es Komplikationen, die die Ausnutzung der Schwachstellen, teils erheblich, erschweren. Zum einen halten sich nicht alle Hersteller bei der Implementierung an die vorgeschriebenen Standards, was einige Betriebssysteme für den potentiellen Angreifer 'unvorhersehbar', beziehungsweise deutlich schwerer angreifbar macht:

In practice, some complications arise when executing the attack. First, not all Wi-Fi clients properly implement the state machine. In particular, Windows and iOS do not accept retransmissions of message 3 (see Table 1 column 2). This violates the 802.11 standard. As a result, these implementations are not vulnerable to our key reinstallation attack against the 4-way handshake. Unfortunately, from a defenders perspective, both iOS and Windows are still vulnerable to our attack against the group key handshake (see Section 4). Additionally, because both OSes support 802.11r, it is still possible to indirectly attack them by performing a key reinstallation attack against the AP during an FT handshake (see Section 5).
Weiters muss der Angreifer es schaffen, sich in eine MitM-Position zu bringen:
A second minor obstacle is that we must obtain a MitM position between the client and AP. This is not possible by setting up a rouge AP with a different MAC address, and then forwarding packets between the real AP and client. Recall from Section 2.3 that the session key is based on the MAC addresses of the client and AP, meaning both would derive a different key, causing the handshake and attack to fail. Instead, we employ a channel-based MitM attack [70], where the AP is cloned on a different channel with the same MAC address as the targeted AP. This assures the client and AP derive the same session key.
Das ist technisch, wie in dem PoC-Video des Researchers gezeigt, zwar mit mittlerem Aufwand möglich, erfordert aber immer noch, dass sich ein Angreifer in der Nähe der potentiellen Ziele befindet, was die massenhafte Ausnutzung erheblich erschwert. Und zuletzt gibt es einige generelle Implementierungseigenheiten, die die Vorhersagbarkeit des Angriffes verringern:
The third obstacle is that certain implementations only accept frames protected using the data-confidentiality protocol once a PTK has been installed (see Table 1 column 3). This is problematic for our attack, because the authenticator will retransmit message 3 without encryption. This means the retransmitted message will be ignored by the supplicant. Although this would seem to foil our attack, we found a technique to bypass this problem (see Section 3.4).
 

Eine wirklich zuverlässige, gezielte Ausnutzung der Lücke ist also wesentlich schwerer, als es die Zusammenfassungen und Überschriften auf den ersten Blick vermuten lassen. Am schwersten betroffen sind bestimmte Versionen von Android (welche das tatsächlich sind, daran scheiden sich ein wenig die Geister - Paper, Webseite und Medienartikel haben allesamt unterschiedliche Angaben hierzu), die nicht einen alten Key wiederverwenden, sondern gar dazu gebracht werden können, einen 'leeren' Schlüssel zu verwenden.

Dennoch ist die eigentliche Gefahr hier nicht die besonders schwere 'Ausprägung' der Schwachstelle, sondern die generell eher problematische Situation rund um den Patchzyklus von Android. Manche Hersteller werden die Patches dafür wohl erst in einigen Monaten in ihre angepassten Versionen des Betriebssystems inkludieren, wenn überhaupt. Stichwort Patches: Die grossen Linuxdistributionen, und OpenBSD, haben bereits Patches zur Verfügung gestellt, selbiges gilt für einige - aber bei weitem noch nicht den Grossteil - der Hardwarehersteller.

Der grosse Vorteil ist, dass die Sicherheitsupdates 'abwärts'kompatibel sind, ein gepatchter Client kann mit einem ungepatchten AP kommunizieren, und vice-versa. Das ist vor allem für Unternehmen hilfreich, die eventuell nur eine von beiden Seiten patchen können. Die wesentlichen Punkte zusammengefasst sind also:

  • Die Schwachstellen lassen sich durch Sicherheitsupdates beheben, ohne dadurch Kompatibilitätsprobleme zu verursachen
  • Diese Updates gibt es bereits für die gängigsten Linuxdistributionen und einige Access Points, es ist damit zu rechnen, dass andere Projekte und Hersteller in Bälde gleichziehen
  • Es gibt noch keinen öffentlichen Exploit-Code, und einige Hindernisse - wie das Erfordernis der räumlichen Nähe - machen eine Ausnutzung der Schwachstellen erheblich schwerer
Keine Frage, das ist sehr wichtige Forschungsarbeit, die in einem lange vernachlässigten Bereich - Sicherheit drahtloser Netzwerke - ein grosser Schritt nach vorne ist, vor allem weil es andere Forscher vielleicht dazu ermutigt, die Implementationen ähnlicher Protokolle zu untersuchen, bei denen eine derartige Schwachstelle ebenfalls wahrscheinlich ist.

Dennoch, wie so oft ist das Fazit: Ja, wir werden alle sterben. Aber nicht an KRACK.

Autor: Alexander Riepl

Ein paar Thesen zu aktuellen Gesetzesentwürfen
31. Juli 2017

Das Thema "LE going dark in the age of encrytion" kocht mal wieder hoch, und noch schnell vor den Neuwahlen wurden entsprechende Gesetzesentwürfe eingebracht. Ich will hier aus technischer Sicht ein paar Argumente in die Diskussion einwerfen, beschränke mich hier aber rein auf den Aspekt Überwachung trotz Verschlüsselung. Die anderen Punkte (Registrierung und Zugriff auf Kameras, Zugriff auf Daten der ISPs, ...) sind zwar auch interessant, treffen aber nicht so sehr in das Kerngeschäft von CERTs, ich werde sie daher nicht mit dem CERT.at Hut kommentieren.

Links:

Wir leben in einer vernetzten Welt, ein lokaler Blickwinkel reicht nicht.

Echte End-to-End Verschlüsselungen in internetbasierten Kommunikationsplattformen (Messenger, VoIP, ...) verhindern, dass deren Betreiber Auskunft über Kommunikationsinhalte ihrer Nutzer geben können. Gut gemachte Verschlüsselung für Harddisks und Handys heißt das gleiche: der Hersteller kann die Devices seiner Kunden nicht einfach entsperren.

Natürlich wäre es für das FBI und andere Polizeibehörden im Westen sehr hilfreich, wenn dem nicht so wäre, und sie immer auf die Mithilfe von Apple, Microsoft, Google, Facebook & co bauen könnten, um an die Daten und die Kommunikation von Verdächtigen heranzukommen. Das hat nur zwei ernsthaft böse Konsequenzen:

  • Die gleichen Möglichkeiten gelten dann auch für die Polizei von fast allen Staaten dieser Welt. Man mag dem Rechtsschutz in Österreich noch vertrauen, aber es gibt genug Staaten (und weit weg von unserer Insel der Seligen müssen wir da gar nicht), in denen solche Werkzeuge in den Händen des Staates für Repression, Wirtschaftsspionage und Korruption verwendet werden.
  • Es ist für die betroffenen Anbieter ein massiver Imageschaden, wenn sie hier mitspielen. Das kann sich vielleicht gerade noch ein Monopolist erlauben, Firmen die im freien, global Markt operieren, können das nur ablehnen.

In anderen Worten: wir können nicht verhindern, dass das gleiche Werkzeug, mit dem eine österreichische Firma mit ihren Außenstellen und Mitarbeitern im Ausland geschützt kommunizierten kann, auch von einem Übeltäter bei uns benutzt wird, um der Strafverfolgung vermeintlich zu entkommen.

Das Rad der Zeit kann man nicht zurückdrehen

Das Internet basiert auf der Idee, dass das Transportnetz nichts von den Applikationen wissen muss, sondern sich rein auf den Datentransport beschränkten kann. Damit wurde eine Innovationskraft freigesetzt, die andere Ansätze (erinnert sich noch jemand an die ISDN Vision aus den 80ern?) komplett überrollt hat.

Ganz ähnliches ist bei PCs und Handys passiert: Erst mit der Möglichkeit, fast beliebige Programme auf diesen Computern laufen zu lassen, wurden sie erst wirklich interessant und so wurden sie zu Plattformen für vielfältigste Anwendungen und Nutzungen.

Wir leben in einer Welt, in der "breit verfügbare, generische Kommunikationsmittel" und "billige, mächtige, frei programmierbare Computer" eine Tatsache sind. Und auch wenn diese Idee im Zeitalter von App Stores (Apple, Windows 10 S), Staatlichen Firewalls (China) oder VPN-Verboten (aktuell Russland) etwas unter Druck kommt, glaube ich nicht, dass das Rad der Zeit hier komplett zurückgedreht werden kann.

Über das Internet kann man beliebige Kommunikation tunneln, das Netz selber kann hier nicht regulierend eingreifen. Und welche Programme auf unseren Endgeräten laufen, können wir in weitem Rahmen selbst bestimmen. Software zur Kommunikation von staatlicher Seite zu verbieten, hat sich in westlichen Demokratien bis jetzt als undurchsetzbar herausgestellt.

Auch das Wissen um Kryptografie (Verschlüsselung) ist inzwischen so breit gestreut und die Algorithmen sind überall über einfache APIs ansprechbar, dass auch die Verfügbarkeit von Kyptografie nicht mehr umkehrbar ist.

Kryptografie schwächen heißt Sicherheit schwächen

Bei der Einführung von Transportverschlüsselung (SSL/TLS) hat die US Regierung eine Zeit lange versucht, nur den Export von abgeschwächten Versionen zu erlauben. Das hat sich als Bumerang erwiesen, wie die Forscher schreiben, die die "DROWN" Lücke gefunden haben:

For the third time in a year, a major Internet security vulnerability has resulted from the way cryptography was weakened by U.S. government policies that restricted exporting strong cryptography until the late 1990s. Although these restrictions, evidently designed to make it easier for NSA to decrypt the communication of people abroad, were relaxed nearly 20 years ago, the weakened cryptography remains in the protocol specifications and continues to be supported by many servers today, adding complexity—and the potential for catastrophic failure—to some of the Internet’s most important security features.

The U.S. government deliberately weakened three kinds of cryptographic primitives: RSA encryption, Diffie-Hellman key exchange, and symmetric ciphers. FREAK exploited export-grade RSA, and Logjam exploited export-grade Diffie-Hellman. Now, DROWN exploits export-grade symmetric ciphers, demonstrating that all three kinds of deliberately weakened crypto have come to put the security of the Internet at risk decades later.

Today, some policy makers are calling for new restrictions on the design of cryptography in order to prevent law enforcement from “going dark.” While we believe that advocates of such backdoors are acting out of a good faith desire to protect their countries, history's technical lesson is clear: weakening cryptography carries enormous risk to all of our security.

Die Suche nach "NOBUS" (Nobody but us) Schwachstellen/Hintertüren in Verschlüsselungsverfahren hat sich in weitem Bereich als Suche nach dem heiligen Gral herausgestellt. Das klingt gut, mag auch eine Zeit funktionieren, aber dann explodiert das mit hohem Schaden. Ein plakatives Beispiel dafür sind die "TSA" Schlösser für Koffer, für die es bekannte Zweitschlüssel gibt. Es hat nicht lange gedauert, bis diese als 3D-Druckvorlagen im Netz auftauchten.

Daher: wenn man sichere Verschlüsselung haben will, auf die man sich verlassen können muss, dann kann man im Design der Software und der Algorithmen nicht schon absichtlich Hintertüren einbauen.

Kryptografie ist kein Safe

Manchmal wird die Verschlüsselung von Daten mit dem Versperren von Akten in Safes verglichen. Es gibt hier aber einen wichtigen Unterschied:

Für die Sicherheit von Safes wird bewertet, wie lange ein Angreifer unter gewissen Randbedingungen (Werkzeug, Lärmentwicklung, ...) braucht, um den Tresor aufzubrechen. Dass der Safe geknackt werden kann, steht außer Zweifel, es geht immer nur um "wie lange mit welchen Mitteln".

Bei Kryptografie ist es nur theoretisch gleich: mit genug Einsatz von roher Rechenleistung lassen sich die gängigen Verfahren knacken, nur ist bei aktuellen Algorithmen das "genug" schlicht außerhalb des derzeit technisch Machbaren. (OTPs und Quantencomputer lasse ich hier außen vor.)

In der klassische IT ist Security ist noch schwieriger zu erreichen als in der Kryptografie, aber auch ein gesperrtes iPhone lässt sich nicht einfach nur mit roher Gewalt öffnen.

Was heißt das für die Polizei und Gerichte?

Das Gewaltmonopol ist hier kein Joker, der immer sticht. Der Staat kann hier seinen Willen nicht immer hart durchsetzen. Ein österreichisches Bundesgesetz zieht gegen die Gesetze der Mathematik den Kürzeren.

Fähigkeiten von Malware / Kontrolle der Verwendung

Wenn wir vor Ort bei einer Vorfallsbehandlung helfen, kommt sehr oft die Frage, was denn die gefunden Schadsoftware alles hätte machen können. Mit viel Glück kann man manchmal beantworten, was gemacht wurde, aber die Frage der Möglichkeiten endet meistens mit "Sie konnte auch Programme nachladen und ausführen". Aus der Sicht des Angreifers ist das auch sehr verständlich: das hält den Code klein und den Handlungsspielraum groß. So können gezielt Werkzeuge und Funktionalitäten nachgeladen werden.

Aus rein technischer Sicht besteht kaum ein Unterschied zwischen dem Vorgehen einer Tätergruppe, die spionieren will und der Polizei, die mittels einer eingebrachten Software eine (vielleicht bald) legitimierte Kommunikationsüberwachung eines Verdächtigen durchführt.

Auch hier muss das Tool fast zwangsläufig generisch sein, es muss es dem Polizisten ermöglichen, auf den vorgefundenen Messenger zu reagieren und entsprechende Module nachzuladen. Ich halte daher Aussagen der Form "Die Software kann exakt nur das, was rechtlich erlaubt ist" für technisch nicht haltbar.

Damit haben wir aber ein Audit-Problem. Wie stellen wir sicher, dass das wirklich alles gesetzeskonform abläuft und nicht ein übermotivierter Beamte alle seine technischen Möglichkeiten im Sinne seines Ermittlungsauftrages ausreizt? Hier braucht es dann deutlich mehr als nur einen Juristen als Rechtsschutzbeauftragte, es braucht eine entsprechende Protokollierung und technisch geschulte Kontrolleure.

Das sehe ich im aktuellen Entwurf nicht.

Mobiltelefone sind wie Wohnungen

Mit gutem Grund legt der Gesetzgeber einen anderen Maßstab bei der Durchsuchung einer Wohnung im Vergleich zu der eines Autos an. Die Verletzung der Privatsphäre der eigenen vier Wände ist so signifikant, dass es eine wirklich starke Argumentation seitens des Staates geben muss, um das zu erlauben.

Es gibt global gesehen die ersten Richtersprüche die festhalten, dass die Daten, die heute in Smartphones gespeichert sind, so intimer Natur sein können (Kommunikationsarchiv, Bilder, Videos, Adressbücher, Terminkalender, Social Media, ...) dass für eine polizeiliche Durchsuchung die gleichen Maßstäbe anzulegen sind, wie für Wohnungen.

Der aktuelle Vorschlag nimmt das auf, indem er nur auf Kommunikationsüberwachung, nicht aber auf Durchsuchung abzielt. Ich halte das für in der Praxis nicht so schön trennbar, wie sich das die Juristen vorstellen.

Implantieren der Überwachungssoftware

Die Gretchenfrage ist aber, wie denn die Software der Überwacher auf den PC oder das Handy des zu Überwachenden kommt.

Das war früher mit Windows 95 & co noch relativ einfach: wenn man das Gerät in die Hand bekommt, kann man leicht Software installieren. Ein aktuelles Windows braucht hingegen eigentlich immer ein Passwort und ist darüber hinaus noch mit Secure Boot und BitLocker gegen Manipulationen geschützt. Bei Handys schaut es ähnlich aus, aktuelle Modelle lassen sich auch nicht so einfach mit nur einem USB-Kabel manipulieren. Dort kommt noch dazu, dass man schwerer unbeobachtet an das Gerät kommt.

Und das ist gut so. Der Schutz von sensiblen persönlichen oder Firmendaten, die auf mobilen Computern (Laptops, Smartphones, ...) gespeichert sind, ist bei jeder Risikobetrachtung (und sei es nach ISO 27k) ein wichtiges Thema. Ein verlorenes Handy oder ein gestohlener Laptop darf für Firmen nicht den Verlust der darauf gespeicherten Daten bedeuten. Diese Absicherung wird den Firmen vom Staat über mehrere Gesetze auch unter Androhung von Strafen vorgeschrieben, das reicht vom DSG bis hin zum kommenden NIS-Gesetz.

Ähnliches gilt auch für die Einbringung von Überwachungssoftware aus der Ferne. Das ist - aus rein technischer Sicht - einfach nur ein weiterer Advanced Persistent Threat (APT). Ob eine kriminelle Bande eine Bank infiltrieren will, um Geld zu bekommen, ob ein fremder Staat in Firmen eindringt um Wirtschaftsspionage durchzuführen, oder ob irgendein Geheimdienst die IT Systeme eines Ministeriums knacken will, um politische Spionage zu betreiben, alles das passiert mit genau denselben Methoden, die auch unsere Polizei anwenden müsste, um in System der vermuteten Kriminellen die Software für die Überwachung einzubringen.

Hier liegt die Krux der Sache: im Normalfall will der Staat, dass sich Bürger und Firmen erfolgreich gegen solche Angriffe absichern, aber wenn der Angriff von der Polizei kommt, soll er a) erlaubt sein und b) funktionieren. Ja, ersteres kann man mit einem Beschluss im Parlament durchsetzen, zweiteres nicht. Da sind wir wieder beim gleichen Thema wie oben bei der Kryptografie:

Sicherheitssysteme bewusst so zu schwächen, dass nur "die Guten" die Lücken nutzen können, funktioniert nicht.

Schizophrenie bezüglich Sicherheit vs. Überwachungsmöglichkeiten

Wir haben also sowohl bei der Kryptografie als auch bei der Sicherheit von IT Systemen zwei sich widersprechende Ziele:

  1. Die Systeme sollen so sicher sein, dass Bürger, Firmen und auch Behörden sicher Daten verarbeiten und vertraulich kommunizieren können. Dazu muss die Integrität der verwendeten Systeme nach bestem Stand der Technik geschützt werden und die verwendeten Algorithmen dürfen keine bekannten Schwächen aufweisen. Werden Schwachstellen gefunden, müssen diese sofort an den Hersteller gemeldet werden, damit sie behoben werden können.
  2. Der Staat will zur Verhinderung und zur Aufklärung von Verbrechen einen Einblick in die Kommunikation und die Daten von Verdächtigen bekommen können. In anderen Staaten kommt hier auch noch der Wunsch dazu, Schwachstellen für Geheimdienstaktivitäten und einen potentiellen "Cyberkrieg" zu horten.

Beide Ziele voll zu erfüllen geht schlicht nicht.

Jeder Staat muss für sich entscheiden, welches Ziel Priorität hat.

Davon unbenommen kann der Staat aber auch noch entscheiden, in welchem Rahmen die Polizei Fehler von Verdächtigen in deren Verwendung von IT Systemen (und deren Schwächen) ausnutzen darf.

Ob Österreich jetzt auch bei den üblichen Verdächtigen die Überwachungssoftware einkauft (dass diese im BM.I entwickelt wird, halte ich nicht für realistisch), wird den Markt von 0-days und diesen Lösungen nicht messbar beeinflussen. Wie seriös solche Firmen agieren, konnte man schön an dem HackingTeam Datenleak erkennen. Und natürlich wird auch hier den potentiellen Kunden manchmal mehr versprochen, als man halten kann.

Wenn aber die Grundsatzentscheidung zu den Prioritäten auf staatlicher Seite nicht klar getroffen wird, dann bringt man die Verwaltung und die Exekutive in eine Zwickmühle: sollen sie auf IT-Sicherheit oder auf Überwachungsmöglichkeiten hinarbeiten?

Die Hersteller scheinen ihre Wahl getroffen zu haben: für sie ist Überwachungssoftware Malware und wird bei Erkennung entfernt.

Autor: Otmar Lendl

In eigener Sache: CERT.at sucht Verstärkung
18. Juli 2017

Für unser "Daily Business" suchen wir derzeit 1 Berufsein- oder -umsteiger/in mit ausgeprägtem Interesse an IT-Security, welche/r uns bei den täglich anfallenden Standard-Aufgaben unterstützt.

Details finden sich hier.

Autor: Robert Waldner

Petya Updates #3 - Die Hoffnung auf einen Kill-Switch
27. Juni 2017

Petya lock screen Petya lock screen

Mittlerweile hauefen sich die Kommentare, dass Petya eventl. einen "Kill-Switch" eingebaut hat: Siehe auch https://twitter.com/0xAmit/status/879789734469488642.

Die naechsten Stunden werden sich zeigen, ob das stimmt und genuegend oft bestaetigt werden konnte. Mittlerweile gibt es auch gegenteilige Meinungen: https://twitter.com/hackerfantastic/ hat die Idee aufgegriffen und Einspruch erhoben. Es wird sich zeigen.

Selbst wenn es einen kill-switch gibt, dann klingt das zwar initial nach "Problem geloest, Welt gerettet, auf zu neuen Taten", aber....wer erzeugt nun diese kill-switch Datei auf jedem Windows Rechner weltweit? Ich fang schon mal mit meiner Familie an... 2 milliarden PCs spaeter sind wir dann fertig. Yeah, right.

Update 23:45: es war nur ein Teil-Sieg: https://twitter.com/hackerfantastic/status/879806667197644800 belegt, dass der Kill-Switch nur funktioniert, wenn die DLL "perfc.dll" hiess. Das ist nicht unbedingt der Fall. Schade.

Ich habe meine spaet Abends Pizza auf alle Faelle mal #Petya genannt. Ohne Mittagessen geht nichts mehr um 23:50.

Autor: L. Aaron Kaplan

Nächste >>
Email: reports@cert.at
Tel.: +43 1 5056416 78
mehr ...
Schwerwiegende Sicherheitsprobleme in Systemen mit aktuellen Intel-Prozessoren
21. November 2017 Beschreibung Wie ...
Kritische Sicherheitslücke in Adobe Flash Player - aktiv ausgenützt - Patches verfügbar
16. Oktober 2017 | Beschreibung Adobe ...
mehr ...
Es steht KRACK auf dem Speiseplan!
16. Oktober 2017 | Auch ...
Ein paar Thesen zu aktuellen Gesetzesentwürfen
31. Juli 2017 | Das Thema ...
mehr ...
Jahresbericht 2016
Ein Resumee zur digitalen Sicherheitslage in Österreich

(HTML, PDF).
Letzte Änderung: 2017/10/16 - 13:36:15
Haftungsausschluss