Was gibt es Neues zur Sicherheit von Microsoft Azure?

Azures Sicherheit - ein Update

Azures Sicherheit - ein Update

Was gibt es Neues zur Sicherheit von Microsoft Azure?

Azures Sicherheit - ein Update


Im Windows Developer 2.2014 ist ein Artikel über die Sicherheit von Windows Azure erschienen [1]. Das ist noch kein ganzes Jahr her, aber in dieser Zeit hat sich einiges getan. Aus Windows Azure wird Microsoft Azure, und sonst ändert sich nichts? Von wegen!

Zum einen hat Microsoft bei der Sicherheit von Azure kräftig nachgelegt, zum anderen gibt es neue Angriffe, sowohl auf Azure selbst als auch allgemeiner Art, die Azure allerdings auch betreffen. Und mit einem dieser allgemeinen Angriffe fange ich an.

Vorsicht, bissiger Poodle in der Mitte!

Poodle ist kein neues Maskottchen von Microsoft, sondern ein neuer Angriff auf SSL- und TLS-Verschlüsselungen. Vereinfacht geht es dabei darum, dass ein Man-in-the-Middle (MitM) erst dafür sorgt, dass bei der Aushandlung der Verschlüsselung das Protokoll SSL 3.0 verwendet wird, um danach dessen schwache Verschlüsselung zumindest teilweise zu brechen. Die Details hierzu finden Sie im Kasten „Der Poodle-Angriff auf SSL/TLS“. Vor allem ist es wichtig, SSL 3.0 auszuschalten, denn das Protokoll ist mit seinen achtzehn Jahren stark veraltet und wird daher nur noch als Fallback-Lösung für Systeme benötigt, die kein aktuelleres Protokoll wie TLS 1.0ff unterstützen.

Der Poodle-Angriff auf SSL/TLS

Der Poodle-Angriff wurde von Bodo Möller, Thai Duong und Krzysz­tof Kotowicz von Google entdeckt [2], [3]. Die dabei ausgenutzte Schwachstelle befindet sich im Protokoll selbst und betrifft dadurch alle SSL-nutzenden Implementierungen. Falls Sie die Schwachstelle im offiziellen Standarddokument von SSL 3.0 nachprüfen möchten, treffen Sie auf folgende Problematik: SSL 3.0 wurde nie offiziell als Standard veröffentlicht. Daher wurde es im August 2011 als „historical record“ in RFC 6101 dokumentiert [4].

Poodle ist die Abkürzung von „Padding Oracle On Downgraded Legacy Encryption“ und nutzt wie der 2011 vorgestellte BEAST-Angriff [5] das nicht ausreichend gesicherte Padding des CBC-Modus.

Ein Poodle-Angriff besteht aus zwei Schritten: Zuerst erzwingt der Angreifer durch die Manipulation des Verbindungsaufbaus den Rückfall auf die Verwendung von SSLv3. Danach kann er die Schwachstellen darin ausnutzen, um Teile der verschlüsselt ausgetauschten Daten zu entschlüsseln.

Der Angriff ist nur möglich, wenn sich der Angreifer als MitM in der Verbindung zwischen Client und Server befindet. Inzwischen ist davon auszugehen, dass sich in jede Verbindung ins Ausland mindestens ein Geheimdienst eingeschaltet hat. Diesem hilft die Schwachstelle aber nur begrenzt, da darüber nicht die gesamte Kommunikation entschlüsselt, sondern nur Teile des Klartexts ermittelt werden können. Kritischer dürfte die Situation in einem offenen WLAN oder bei einem Angriff über einen Rogue Access Point [6] sein, da Cyberkriminelle sich darüber zum Beispiel gezielt den Session-Cookie eines Social Networks oder Onlineshops beschaffen und auf diesen dann im Namen des Opfers zugreifen können.

Client

Man-in-the-Middle

Server

Request „Nehmen wir TLS 1.2?“

---->

Löscht Request

Da keine Antwort kam, der nächste Versuch: Request: „Nehmen wir TLS 1.1?“

---->

Löscht Request

Da keine Antwort kam, der nächste Versuch: Request: „Nehmen wir TLS 1.0?“

---->

Löscht Request

Da keine Antwort kam, der nächste Versuch: Request: „Nehmen wir SSL 3.0?“

---->

Lässt den Request durch

---->

Der Client möchte SSL 3.0 verwenden? Na, wenn es denn sein muss ...

Na endlich – dann also los

<----

Lässt die Aushandlung der SSL-3.0-Verschlüsselung zu und kann diese später angreifen

<----

SSL 3.0 ist OK, fangen wir mit dem Schlüsselaustausch an ...

Tabelle 1: Downgrade des Protokolls auf SSL 3.0 durch den MitM

Schritt 1: Fallback auf SSLv3 provozieren

Um auch mit veralteten Servern kommunizieren zu können, ist in den meisten TLS-Clients ein „Downgrade Dance“ implementiert: Im ersten Handshakeversuch wird die höchste vom Client unterstützte Protokollversion vorgeschlagen. Schlägt der Handshake fehl, wird die nächstniedrige unterstützte Protokollversion vorgeschlagen, und das so lange, bis der Server zustimmt (oder der Client keinen Vorschlag mehr zu machen hat und keine verschlüsselte Verbindung zustande kommt).

Anders als bei einer korrekten Aushandlung der Protokollversion, bei der zum Beispiel der Client TLS 1.2 vorschlägt und der Server mit TLS 1.0 antwortet, kann der Downgrade auch durch Netzwerkfehler ausgelöst werden. Oder durch einen Angreifer, der die Vorschläge des Servers unterdrückt, bis der Client freiwillig SSLv3 vorschlägt. Lässt der Angreifer diesen Vorschlag zu, wird die Verbindung mit SSLv3 aufgebaut. Wie das in etwa aussieht, zeigt Tabelle 1.

Schritt 2: Angriff auf die Verschlüsselung

Die Verschlüsselung in SSL 3.0 erfolgt entweder mit der Stream-Cipher RC4, die einige bekannte Schwachstellen enthält, oder einer Block-Cipher im CBC-Mode (Cipher Block Chaining). Der neu entwickelte Angriff richtet sich gegen diese „Blockchiffre mit Blockverkettung“ und setzt ebenso Schritt 1 voraus, dass der Angreifer die Netzwerkverbindung manipulieren kann.

Bei einer Blockverschlüsselung werden die Daten immer in Blöcken fester Länge verschlüsselt, daher müssen Daten, die kürzer als die verarbeitete Blocklänge sind, auf die nötige Länge aufgefüllt werden („Padding“). Das Problem der CBC-Verschlüsselung in SSL 3.0 besteht darin, dass dieses Padding nicht deterministisch ist und nicht vom MAC (Message Authentication Code) abgedeckt wird, mit dem ansonsten eine Manipulation der Daten erkannt wird. Dies führt dazu, dass die Integrität des Paddings bei der Entschlüsselung nicht geprüft werden kann.

Der Empfänger ignoriert das Padding, denn lediglich das letzte Byte muss die korrekte Länge des Paddings enthalten, da darüber die Position des MAC bestimmt wird. Stimmt diese Längenangabe nicht, wird der MAC von der falschen Stelle gelesen, also ein falscher Wert als MAC verwendet, und dessen Überprüfung schlägt folglich fehl.

Für den Angriff muss der Angreifer JavaScript-Code in den Browser des Opfers einschleusen, was ihm als MitM ja problemlos möglich ist. Dieser Code sendet dann präparierte HTTPS-Requests an die Website, deren Session-Cookie ...