Freitag, 22. Oktober 2010


Topthema

Donnerstag, 27. August 2009 | Topthema

About Security #219: Schwachstellen-Suche: Authentifizierung - Verschlüsselung

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/050850)

In About Security #218 wurden beschrieben, wie die bei der Authentifizierung übertragenen Daten ermittelt werden. Werden dabei keine Zugangsdaten als Klartext beobachtet, müssen alle kodierten Daten daraufhin untersucht werden, ob sie sich dekodieren oder entschlüsseln lassen und dabei die gesuchten Zugangsdaten preisgeben.

Werden die Daten über HTTPS übertragen, sind sie durch die dabei verwendeten kryptographische Verfahren während der Übertragung ausreichend geschützt, sie können lediglich durch einen sich in die Verbindung eingeschlichenen Man-in-the-Middle beobachtet werden. Manchmal wird aber, aus welchen Gründen auch immer, statt des standardisierten HTTPS eine eigene Schutzfunktion der Webanwendung verwendet - und die kann evtl. umgangen werden. Die folgenden Beschreibungen gelten nicht nur für die während der Authentifizierung übertragenen Daten, sondern sind allgemein anwendbar.

"Falsche Verschlüsselung"

Um Vertraulichkeit und Integrität von übertragenen Daten sicherzustellen, verwendet man verschiedene kryptographische Verfahren (siehe About Security #66 ff.). Obwohl es viele bewährte und nachweislich sichere Algorithmen samt passender Implementierungen gibt, werden immer wieder unsichere Verfahren eingesetzt. Dafür gibt es im Prinzip drei Möglichkeiten:

  • ungeschickte Eigenentwicklungen (die Entwicklung eines wirklich sicheren kryptographischen Verfahrens ist extrem aufwendig)
  • inzwischen gebrochene und dadurch unsichere Algorithmen
  • falsch konfigurierte bzw. eingesetzte aktuelle, eigentlich sichere Algorithmen

Während der ab About Security #144 beschriebenen Untersuchung der Webanwendung können an verschiedenen Stellen verschlüsselte Daten aufgetaucht sein, z.B. als "merkwürdiger" Wert eines GET- oder POST-Parameters oder als Datenstrom bei der Beobachtung einer unverschlüsselten HTTP-Verbindung. Alle nach zufälligen Zeichenketten aussehenden Daten können verschlüsselte Daten sein (sofern es nicht echte Zufallswerte, z.B. für Session-IDs oder Sicherheitstoken gegen CSRF-Angriffe sind). Zuerst muss dann untersucht werden, woher diese Daten stammen und wo sie ver- und entschlüsselt werden. Liefert der Server verschlüsselte Daten, müssen sie auf dem Client entschlüsselt werden, das geht z.B. durch JavaScript-Code oder ein Java-Applet. Überträgt der Client verschlüsselte Daten an den Server, müssen sie dementsprechend auf dem Client verschlüsselt worden sein. Wurden die entsprechenden Komponenten identifiziert, können sie genauer untersucht und evtl. verwendete unsichere Algorithmen entdeckt werden. Ist eine Analyse der Komponenten nicht möglich, müssen die verschlüsselten Daten untersucht werden.

Schwachstellen finden

Im folgenden wird davon ausgegangen, dass die zu verschlüsselnden Daten vom Benutzer und damit auch vom Tester bzw. Angreifer bestimmt werden können. Auf die Zugangsdaten trifft das immer zu, und auch in den meisten anderen Fällen können die Daten direkt oder indirekt bestimmt werden.

About Security: Die komplette Serie

Zuerst werden dann Texte mit unterschiedlicher Länge eingegeben und das Ergebnis untersucht. Als Testeingabe bietet sich ein Pangramm an, der Einfachheit halber wird im folgenden das englische 'The quick brown fox jumps over the lazy dog' verwendet. Man könnte auch ein deutsches Pangramm wie z.B. 'Falsches Üben von Xylophonmusik quält jeden größeren Zwerg' verwenden, muss dann aber damit rechnen, dass evtl. die Umlaute und das ß anders kodiert werden, als man es erwartet.

Ein praktisches Beispiel

Los geht es mit

'The quick brown fox',

aus dem die Verschlüsselungsfunktion

'VGhlIHF1aWNrIGJyb3duIGZveA=='

macht. Die zwei Gleichheitszeichen am Ende deuten auf eine Base64-Kodierung hin. Als nächstes wird ein weiteres Zeichen eingegeben:

'The quick brown fox '

wird zu

'VGhlIHF1aWNrIGJyb3duIGZveCA='

Das Verschlüsselungsergebnis ändert sich nur wenig, aber es ist nur noch ein Gleichheitszeichen vorhanden. Jetzt wird wieder ein Zeichen mehr eingegeben:

'The quick brown fox j'

liefert

'VGhlIHF1aWNrIGJyb3duIGZveCBq'

Da der Text nun ein Vielfaches von 3 Byte lang ist, muss er nicht aufgefüllt werden. Es gibt mehrere Hinweise darauf, das es sich um eine Base64-Kodierung handelt: Das Verschlüsselungsergebnis besteht nur aus Groß- und Kleinbuchstaben sowie Ziffern und hat kein, ein oder zwei Gleichheitszeichen am Ende. Ob der Text wirklich Base64-Kodiert ist, kann man prüfen, indem man den verschlüsselten Text mit Base64 dekodiert, z.B. mit einem Online-Decoder. Der macht aus

'VGhlIHF1aWNrIGJyb3duIGZveCBq'

dann

'The quick brown fox j',

die Eingabe wurde tatsächlich nicht verschlüsselt, sondern nur umkodiert.

Eigenentwicklungen

Ein weitere beliebte Verschlüsselung ist die Substitution. Dabei wird z.B. für jeden Buchstaben der jeweils nächste verwendet: Aus A wird B, aus B wird C, ..., aus Y wird Z und aus Z dann A. Wie man eine Substitution und ähnliche einfache Verfahren wie die Transposition oder die Polyalphabetische Substitution brechen kann, wurde bereits in About Security #66 ff beschrieben. Bei Angriffen auf die Authentifizierung stößt man meist auf das Problem, dass die Eingaben zu kurz sind, um genug Material für eine statistische Analyse zu liefern. Sofern möglich, kann man dann einfach mehrere Anmeldeversuche mit unterschiedlichen, passend gewählten Benutzernamen und Passwörtern durchführen, um genug Daten zu sammeln.

In der nächsten Folge wird der unsichere Einsatz eigentlich sicherer Krypto-Verfahren behandelt.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren