Aus der Hölle der Internetprotokolle: Base64

Aus der Hölle der Internetprotokolle: Base64

Die Manipulation von Internetprotokollen öffnet kreativen Angreifern eine Spielwiese. Die resultierenden, oft versteckten Risiken sind für die IT-Sicherheitsforscher von genua besonders interessant: Denn ist die Gefahr entdeckt, kann eine wirksame Verteidigung aufgebaut werden. Dies erläutert der Autor am Beispiel der Base64-Kodierung.

Ein wiederkehrendes Problem bei Internetprotokollen ist die Notwendigkeit, binäre Daten als Text auszudrücken. Ein Anwendungsfall ist die Einbettung von binären Anhängen oder auch Umlauten in Mails, welche historisch bedingt eigentlich nur aus ASCII-Text bestehen. Andere Anwendungsfälle sind die Nutzung von Nicht-ASCII-Daten wie zum Beispiel von Passwörtern im Header von HTTP-Nachrichten (Web), die Einbettung von Bildern direkt in eine HTML-Seite über Data-URL oder die Einbettung binärer Inhalte in SOAP-Nachrichten.

Um eine solche Umwandlung von binär nach Text und zurück zu erreichen, wird in vielen Fällen auf die Base64-Kodierung zurückgegriffen. Die Grundidee hierbei ist, dass jeweils 3 Byte binär auf 4 ASCII-Zeichen abgebildet werden, genauer 3 x 8 Bit (binär) auf 4 x 6 Bit (ASCII). Um die 6 Bit auszudrücken, werden 64 Zeichen benötigt. Üblicherweise werden für die 64 Zeichen des Ausgabealphabets in dieser Reihenfolge alle Großbuchstaben (26), Kleinbuchstaben (26), Zahlen (10) sowie die Zeichen "+" und "/" verwendet. Verdeutlicht werden kann dies am Beispiel der Abbildung von dem binären String "\x2A\x7B\xF3" als Text "Knvz" mittels Base64:

Die ersten 6 Bit von \x2A sind 001010, also 10 im Dezimalsystem. Das Zeichen mit dem Index 10 im Ausgabealphabet ist "K" (der Index wird von 0 ausgehend gezählt). Für die nächsten 6 Bit werden die letzten beiden Bit von \x2A sowie die ersten 4 Bit von \x7B genutzt, also 100111 bzw. dezimal 39 welches dem Zeichen "n" des Ausgabealphabets entspricht usw. Ist die Länge der Eingabedaten nicht ein Vielfaches von 3, so wird in Anwendungen wie z. B. bei Mail die Ausgabe mit einem "=" so aufgefüllt, dass sie stets ein Vielfaches von 4 ergibt. So wird also aus "\x2A\x7B\xF3" ein "Knvz", aus "\x2A\x7B" hingegen ein "Kns=" und aus "\x2A" wird "Kg==".

In Mails wird Base64 zum Beispiel zur Kodierung binärer Attachments genutzt. Da Mails eine maximale Zeilenlänge bei der Übertragung haben, wird typischerweise nach 76 Zeichen ein Zeilenumbruch eingefügt. Als Beispiel nehmen wir das Gedicht "Ein männlicher Briefmark erlebte“ von Joachim Ringelnatz, welches in einer Zeit weit vor der Erfindung von E-Mail entstand. In eine Mail eingebettet sieht es so aus:


Aus den bisherigen Ausführungen kann man entnehmen, dass ein korrekt mit Base64 kodiertes Attachment folgende Eigenschaften aufweisen sollte:

  • Es werden nur die 26 Buchstaben (ohne Umlaute) in Groß- und Kleinschreibung, die 10 Zahlen sowie die Zeichen "+" und "/" benutzt. Zeilenumbrüche sind erlaubt.
  • Außerdem können am Ende der kodierten Daten ein oder zwei "=" stehen, aber wirklich nur am Ende.
  • Die Länger aller Zeichen (bis auf Zeilenumbrüche) macht zusammen eine Vielfaches von 4 aus.

Regelverstoß birgt Risiken

Ein Angreifer kann jedoch nicht gezwungen werden, sich an diese Regeln zu halten. Er könnte bewusst eine "kaputte" Kodierung generieren, zum Beispiel indem Zeichen benutzt werden, die nicht im Ausgabealphabet von Base64 stehen oder indem ein "=" an Stellen einfügt wird, wo es nicht sein darf. Wie eine derart fehlerhafte Kodierung dann interpretiert wird, ist abhängig von der jeweiligen Implementation im Mailprogramm des Endnutzers oder auch im Mailfilter der Firewall. Und wenn es hier Unterschiede in der Interpretation gibt, so kann ein Angreifer damit eventuell Malware von der Firewall unerkannt zum Endnutzer transportieren. Um solche Sicherheitsprobleme zu verhindern, haben wir die Problematik tiefer analysiert und bei der Firewall-Lösung genugate adressiert.

Ein "=" an der falschen Stelle

Ein Gleichheitszeichen wird bei Base64 ausschließlich genutzt, um am Ende der Daten aufzufüllen, wenn die Länge der Ausgabe nicht ein Vielfaches von 4 ist. Das heißt, das Zeichen darf nur am Ende stehen und daher wird das Auftreten dieses Zeichens vielfach als Ende der Daten gewertet. Das bedeutet, in der folgenden Mail hören Programme wie Outlook, KMail oder mutt mit dem Dekodieren nach dem ersten Gleichheitszeichen auf und ignorieren den Rest der Daten. Sie betrachten also nur "ZWlucyE=" und dekodieren den Inhalt entsprechend zu "eins!":

Content-type: text/plain
Content-Transfer-Encoding: base64

ZWlucyE=endlaSE=

Thunderbird hingegen betrachtet und dekodiert auch die Daten nach dem Gleichheitszeichen und bekommt somit "eins!zwei!". Der Webmailer Roundcube macht zwar auch irgendwie weiter, aber das Resultat ist nicht das erwartete. Wenn man hingegen nach dem fehlerhaften Gleichheitszeichen noch ein weiteres Zeichen einfügt (z. B. ein "X" wie im folgenden Beispiel) interpretiert Roundcube den Inhalt wie vom Angreifer gewünscht, das heißt aus "ZWlucyE=XendlaSE=" wird ebenfalls "eins!zwei!".

Aber das ist nur eine vereinfachte Beschreibung der Situation. Tatsächlich hängt das Verhalten der verschiedenen Mailprogramme auch noch von der genauen Position des fehlerhaften Gleichheitszeichens ab. Ist es am Ende der kodierten Sequenz von jeweils 4 ASCII-Zeichen, so wird es von vielen Implementationen als Ende der kodierten Daten betrachtet. Ist es an einer anderen Stelle, wird es von Roundcube einfach ignoriert. Thunderbird hingegen geht davon aus, dass die Eingabe korrekt ist und verarbeitet implizit das fehlerhafte Zeichen auf innovative Weise, die erst beim Studium des Quellcodes von Thunderbird offensichtlich wird.

Gutgläubige Endnutzerprogramme

Letztendlich gehen Endnutzerprogramme typischerweise davon aus, dass die Daten korrekt kodiert sind. Bei fehlerhaft kodierten Daten gibt es daher keine Meldungen an den Nutzer, sondern die Daten werden einfach irgendwie interpretiert, abhängig von der jeweiligen Implementierung. Und auch wenn dieses einfache Vorgehen für ein Endnutzerprogramm sinnvoll sein mag – in einem Analysesystem kann es fatale Auswirkungen haben. Denn Interpretationsunterschiede zwischen Analysesystem und Endnutzerprogramm können vom Angreifer gezielt ausgenutzt werden.

Um eine Umgehung der Analyse durch gezielt fehlerhafte Kodierungen zu umgehen, müssen daher derartige Probleme erkannt werden und entweder die Weiterleitung der ungültigen Daten zum Endkunden unterbunden oder alternativ sämtliche potenziell vom Endnutzerprogramm genutzten Varianten der Dekodierung der Daten untersucht werden.

Risiken werden noch zu oft übersehen

Aber wie schon bei der Untersuchung der Analysequalität von Firewalls für Webverkehr festgestellt wurde, ist das Bewusstsein für Umgehungen auf Protokollebene nicht wirklich ausgeprägt. Eine Analyse von einigen freien und kommerziellen Mailfiltern, Firewalls und IDS zeigt wie erwartet eine Analyse-Lücke: In vielen Systemen werden analog zu den meisten Mailprogrammen die Daten nur bis zum ersten Gleichheitszeichen dekodiert und der Rest einfach ignoriert. Und selbst wenn mit der Dekodierung nach dem Gleichheitszeichen weitergemacht wird, so implementiert doch keiner die spezielle Art der Dekodierung fehlerhafter Inhalte von Thunderbird.

Die Firewall genugate erkennt fehlerhafte Kodierung und vermeidet Angriffsrisiken

Kritisch ist dabei, dass in den meisten Fällen keine sinnvolle Fehlerbehandlung erfolgt, wie zum Beispiel das Blockieren einer Mail. Benutzt der Empfänger also beispielsweise den verbreiteten Mail-Client Thunderbird, so kann ein Angreifer Malware vom Sicherheitssystem unbemerkt erfolgreich an den Endnutzer zustellen.

Wie kann man sich schützen?

Die Sicherheitsforscher von genua haben die Risiken untersucht und das Problem zusammen mit der Produktentwicklung gelöst: Ist in der Firewall genugate die Analyse von Mailinhalten aktiviert, so werden Anhänge mit derart fehlerhafter Kodierung erkannt. Je nach Konfiguration des Systems wird die Mail blockiert oder der fehlerhafte Anhang entfernt – und so die Gefahr vermieden.

 

Bildquelle: ©  valerybrozhinsky - Fotolia.com


Lesen Sie auch

Diskutieren Sie mit

Sie können diesen Artikel sofort ohne Registrierung als Gast-User kommentieren.

Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.



Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.

Um für Sie unsere Webseite zu optimieren, verwenden wir Cookies.
Klicken Sie auf "Cookies zulassen", falls Sie der Nutzung von diesen Cookies zustimmen.
Weitere Informationen dazu finden Sie in unserer Datenschutzerklärung, in der Sie auch jederzeit Ihre Cookie-Einstellungen einsehen und anpassen können.
Datenschutz Cookies akzeptieren