Klartextprotokolle: Was Angreifer sehen

HTTP überträgt alle Daten als unverschlüsselten ASCII-Text. Wenn Sie ein Anmeldeformular über HTTP absenden, sendet der Browser eine POST-Anfrage, die Ihren Benutzernamen und Ihr Passwort im Klartext enthält. Jede Person im selben Netzwerksegment oder jeder Router zwischen Ihnen und dem Server kann die vollständige Anfrage einschließlich Anmeldedaten, Sitzungscookies und aller sensiblen Formulardaten lesen.

Telnet war vor SSH das Standardprotokoll für den Fernzugriff auf Terminals. Jeder Tastendruck in einer Telnet-Sitzung wird als einzelnes unverschlüsseltes TCP-Paket an den Server übertragen. Ein Angreifer, der den Netzwerkverkehr mitschneidet, sieht nicht nur den Benutzernamen und das Passwort bei der Anmeldung, sondern auch jeden eingegebenen Befehl und jede angezeigte Ausgabe. Dadurch ist eine vollständige Sitzungsübernahme ohne kryptografische Schutzmechanismen möglich.

FTP authentifiziert sich mit einem USER-Befehl, gefolgt von einem PASS-Befehl. Beide werden als Klartext über TCP-Port 21 übertragen. Ein Mitschnitt einer FTP-Anmeldung zeigt die exakten Zugangsdaten. Selbst wenn der Dateiübertragungskanal mit FTPS verschlüsselt ist, wird das Passwort beim anfänglichen Authentifizierungsaustausch jedem Beobachter offengelegt. Veraltete FTP-Server sind in Unternehmensumgebungen häufig anzutreffen und stellen daher leicht auszunutzende Ziele zum Abgreifen von Zugangsdaten dar.

POP3 (Port 110) und IMAP (Port 143) übertragen ohne TLS E-Mail-Zugangsdaten und den vollständigen Nachrichteninhalt im Klartext. Wenn Sie Ihren E-Mail-Client in einem Café-WLAN öffnen, während der Mailserver unverschlüsselt konfiguriert ist, kann jedes von Ihnen heruntergeladene E-Mail von jedem anderen Gerät im Netzwerk gelesen werden. POP3S (Port 995) und IMAPS (Port 993) verwenden TLS bereits ab dem Verbindungsaufbau.

Datenbankserver wie MySQL (Port 3306) und PostgreSQL (Port 5432) unterstützen standardmäßig unverschlüsselte Verbindungen. Wenn Anwendungsserver ohne verpflichtendes SSL eine Verbindung zur Datenbank herstellen, übertragen sie Abfragen und deren Ergebnisse, einschließlich sensibler personenbezogener Daten, als Klartext über das Netzwerk. Interne Netzwerke werden häufig als vertrauenswürdig betrachtet. Angreifer, die jedoch irgendeinen Zugangspunkt erlangen, können sofort damit beginnen, den Datenbankverkehr mitzuschneiden.

LDAP (Lightweight Directory Access Protocol) über Port 389 überträgt Verzeichnisabfragen und Authentifizierungsdaten im Klartext. In Unternehmensumgebungen, die Active Directory zur Authentifizierung verwenden, können LDAP-Bind-Vorgänge Benutzernamen und Passwörter im internen Netzwerk offenlegen. LDAPS über Port 636 verwendet TLS, und STARTTLS über Port 389 kann die Verbindung nachträglich aufrüsten. Dies wird jedoch nicht immer erzwungen.

Redis lauscht standardmäßig über Port 6379 ohne Authentifizierung und ohne TLS. Eine ohne Passwort im Netzwerk erreichbare Redis-Instanz ermöglicht jedem Client, alle gespeicherten Schlüssel zu lesen, beliebige Befehle auszuführen und möglicherweise Konfigurationsdateien zu schreiben. Bis Redis 6.0 (2020) TLS-Unterstützung hinzufügte, war der gesamte Redis-Datenverkehr, einschließlich Cache-Daten und Sitzungstoken, bei der Übertragung vollständig offengelegt.

Memcached, eine weit verbreitete Caching-Schicht, verfügt über keinen integrierten Authentifizierungsmechanismus und überträgt alle Daten als unverschlüsselten ASCII-Text über TCP-Port 11211. Entwickler verlassen sich typischerweise auf Netzwerk-Firewalls, um den Zugriff einzuschränken. Fehlkonfigurierte, aus dem Internet erreichbare Memcached-Instanzen wurden jedoch für Amplification-DDoS-Angriffe und Datendiebstahl verwendet. Alle zwischengespeicherten Inhalte, einschließlich Sitzungsdaten und API-Antworten, sind für jeden sichtbar, der den Port erreichen kann.

Traditionelles Syslog verwendet UDP-Port 514 ohne Authentifizierung und ohne Verschlüsselung. Über das Netzwerk gesendete Systemprotokolle können von jedem in der Übertragungskette gelesen, verändert oder gefälscht werden. Ein Angreifer, der Syslog-Datenverkehr abfangen kann, kann Sicherheitsereignisse in Echtzeit lesen oder falsche Protokolleinträge einschleusen, um seine Spuren zu verwischen. RFC 5425 definiert Syslog über TLS, dennoch verwenden viele Systeme weiterhin das veraltete Klartextprotokoll.

Von einem einzigen Netzwerkstandort aus erhält ein Angreifer, der unverschlüsselten Protokollverkehr mitschneidet, einen umfassenden Einblick in die Umgebung. Er sieht Benutzernamen und Passwörter für mehrere Dienste, Sitzungstoken, die sich ohne das ursprüngliche Passwort wiederverwenden lassen, übertragene sensible Daten sowie die interne Architektur des Netzwerks. Diese Informationen können passiv und ohne Interaktion mit den Zielsystemen gesammelt werden.

Trotz jahrzehntelanger Kenntnis der Risiken von Klartext bestehen unverschlüsselte Protokolle fort. Gründe dafür sind veraltete Systeme, die nicht aktualisiert werden können, die Komplexität der Konfiguration in großen Umgebungen, Bedenken hinsichtlich der Leistung bei internen Verbindungen mit hohem Durchsatz sowie die Annahme, dass interne Netzwerke vertrauenswürdig sind. Netzwerksegmentierung und die Prinzipien einer Zero-Trust-Architektur stellen diese Annahme infrage, indem sie internen Datenverkehr genauso sorgfältig prüfen wie externen Datenverkehr.

Welche der folgenden Kombinationen aus Protokoll und Port überträgt Authentifizierungsdaten standardmäßig im Klartext?

HTTP, Telnet, FTP, POP3, IMAP, rohe Datenbankverbindungen, LDAP, Redis, Memcached und Syslog übertragen Daten standardmäßig ohne Verschlüsselung. Jeder Beobachter in der Übertragungskette kann Zugangsdaten, Sitzungstoken und sensible Daten lesen. Für all diese Protokolle gibt es TLS-gesicherte Varianten. Annahmen über das Vertrauen in interne Netzwerke sind gefährlich: Zero-Trust-Prinzipien behandeln jeden Datenverkehr als potenziell einsehbar.