SSH Security Notification Tool

Wir sind Wissenschaftlerinnen der Forschungsgruppe Security, Usability, Society (SECUSO) des Karlsruher Institut für Technologie und des Fachgebiets Security in Telecommunications (SecT) der Technischen Universität Berlin. Beide Gruppen forschen im Bereich IT-Sicherheit und kooperieren im Rahmen dieser Studie zum Thema Schwachstellen-Benachrichtigung.

Bei weiteren Fragen oder Beschwerden können Sie sich gern an uns wenden. Unsere Kontaktdaten finden Sie weiter unten in der FAQ-Frage "Weitere Fragen?".

Wir haben im Impressum Ihrer Website nach einem technischen Kontakt gesucht oder Sie angeschrieben, weil Sie im Impressum als Inhaltlich Verantwortliche*r genannt werden. Gerne können Sie unsere Nachricht aber an die Person weiterleiten, die sich um Ihre IT-Infrastruktur kümmert.

Die Forschungsgruppe SECUSO forscht zum Faktor Mensch in der IT-Sicherheit und hier unter anderem auch zum Thema Schwachstellen-Benachrichtigungen. Die SecT Gruppe forscht im Bereich der Erkennung von Schwachstellen im Web-, Netzwerk- und Softwarebereich.

Gemeinsam wollen wir herausfinden, wie wir Betroffene effektiv über Schwachstellen informieren können.

Nein. Unser Prüf-Tool soll Ihnen helfen, die Fehlkonfigurationen selbst zu erkennen und zu beheben. Falls Sie dazu noch Fragen haben können Sie sich gerne an uns wenden. Unsere Kontaktdaten finden Sie weiter unten in der FAQ-Frage "Weitere Fragen?". Wir können Ihnen allerdings keinen IT-Support anbieten.

Unser Ziel ist es, herauszufinden, wie wir Betroffene am besten über Schwachstellen informieren können.

Je nachdem, in welche Szenarien Ihre Domain fällt, können Sie folgende Maßnahmen vornehmen:

1) Die SSHFP-Einträge aktualisieren, sodass diese mit den HostKey-Fingerprints der Server übereinstimmen. Generieren Sie mittels "ssh-keyscan -D <hostname>" neue SSHFP-Einträge und setzen Sie diese bei Ihrem DNS-Provider.

2) Falls kein DNSSEC für Ihre Domain aktiv ist, so können Sie es bei Ihrem DNS-Provider aktivieren. Manche DNS Provider haben dazu Informationen auf ihren Websites bereitgestellt (z.B. INWX, Namecheap, United Domains, oder Strato).

Die alten DNS Einträgen können im DNS-System für bis zu 24 Stunden zwischengespeichert sein, sodass das Selbsttest-Tool diese Änderung nicht sofort prüfen kann. Die Dauer hängt u.a. von der konfigurierten TTL (time-to-live) der DNS-Einträge ab.

In einem solchen Fall müssen Sie warten, bis die neuen Einträge durch das DNS-System propagiert sind (im Regelfall 1 Stunde). Danach können Sie mit dem Selbsttest-Tool erneut Ihre Domain prüfen.

Für diese Studie lag der Fokus auf der Benachrichtigung von deutschsprachigen Websites.

Dafür wurden zunächst aus verschiedenen, öffentlichen Quellen Domains mit deutscher Top-Level-Domain (".de") gesammelt. Insgesamt konnten wir 8.3 M aktiv genutzte deutsche Domains ermitteln. Inklusive der zugehörigen Subdomains, ergab sich ein Datensatz aus über 27.5 M Domains.

Jede Domain wurde anschließend auf das Vorhandensein und die korrekte Konfiguration von SSHFP gemäß der Methodik von Neef et. al. untersucht.

Falls Sie von uns benachrichtigt wurden, befand sich Ihre Domain in einem der Ausgangsdatensätzen und wurde durch die Analyse als nicht korrekt konfiguriert eingestuft.

Wie in der Veröffentlichung von Neef et. al. beschrieben, wurden die Domains auf die Existenz und korrekte Konfiguration von SSHFP sowie die Nutzung von DNSSEC geprüft.

Zunächst wurde geprüft, ob SSHFP-Einträge im DNS für eine Domain existieren. Anschließend wurden diese Einträge auf die syntaktische Korrektheit geprüft. Im nächsten Schritt wurden die IPv4-Adressen für die Domain ermittelt und diese Server auf einen offenen Port 22 (SSH) geprüft. Für alle SSH-Server wurden die HostKey-Fingerprints ermittelt. Nun konnte geprüft werden, ob die serverseitigen HostKey-Fingerprints mit den Fingerprints aus den SSHFP-Einträgen übereinstimmten.

Zuletzt wurde für jede Domain, für die dieser Vergleich durchgeführt wurde, erneut eine SSHFP DNS-Abfrage mit aktiver DNSSEC-Validierung durchgeführt, um zu ermitteln, ob DNSSEC genutzt wird.

Wir haben Sie benachrichtigt, weil Ihre Domain in diese Szenarien fällt:

1) Die SSHFP-Einträge stimmen nicht mit den serverseitigen HostKey-Fingerprints überein.

2) Die SSHFP-Einträge werden ungesichert ohne DNSSEC-Schutz übertragen.

SSH steht für "Secure Shell" und ist ein populäres Protokoll, um sichere Verbindungen zur Administration eines entfernten Computersystems aufzubauen. Bspw. sind der OpenSSH-Server und OpenSSH-Client eine sehr bekannte Implementierung des Protokolls.

Um sicherzustellen, dass ein Nutzer sich zum richtigen System verbindet, werden die Fingerprints der HostKeys bei jedem Verbindungsaufbau abgeglichen. Bei dem ersten Verbindungsaufbau zu einem neuen System, muss der Nutzer in einem Dialog bestätigen, ob der HostKey vom Server korrekt ist.

Mit SSHFP DNS-Einträgen kann dieser Bestätigungsprozess vereinfacht werden, indem der OpenSSH-Client die Korrektheit der Fingerabdrücke voll automatisch überprüft. Dies setzt allerdings voraus, dass die SSHFP-Einträge im DNS vor Manipulation geschützt übertragen werden, bspw. per DNSSEC.

DNS (Domain Name System) ist ursprünglich als Klartextprotokoll ohne Sicherheitsgarantien entworfen worden. Mit DNSSEC wurde eine Erweiterung für den DNS-Standard geschaffen. Mit Hilfe von Kryptografie (PKI, Signaturen) soll dadurch die Authentizität von DNS-Einträgen garantiert werden.

Sicherheitsbezogene DNS-Eintragstypen, zu denen auch SSHFP gehört, setzen eine fälschungsfreie Übertragung voraus. Werden die Einträge ohne DNSSEC-Schutz übertragen, so könnten Angreifer die im Klartext übertragenen SSHFP-Einträge manipulieren.

Stimmen die HostKey-Fingerprints aus den SSHFP DNS-Einträgen nicht mit den tatsächlichen Fingerabdrücken des Systems überein, so kann keine automatisierte Validierung durch das SSH-Programm vorgenommen werden bzw. scheitert diese automatisierte Validierung. Im Fall von OpenSSH, wird der Nutzer zur manuellen Verifizierung des HostKey-Fingerabdruckes aufgefordert. Um diese Verifizierung durchzuführen muss der Nutzer zunächst vom Administrator die gültigen serverseitigen HostKey-Fingerabdrücke erhalten. Darauffhin muss der Nutzer fehlerfrei die Übereinstimmung der zwei zufällig wirkenden Zeichenketten sicherstellen. Hierbei können menschliche Fehler auftreten, sodass ein potentiell manipulierter HostKey-Fingerprint akzeptiert werden könnte.

Bei der Schwachstelle handelt es sich primär um eine Fehlkonfiguration. Diese hat keinen sofortigen und direkten Einfluss auf die Sicherheit Ihrer Infrastruktur. Allerdings begünstigt diese Fehlkonfiguration Angriffe gegen die Personen, welche sich per SSH auf Ihre Systeme einloggen. Im schlimmsten Fall kann dies dazu führen, dass ein Angreifer an die SSH-Zugangsdaten gelangt.

Werden HostKey-Fingerabdrücke nicht automatisiert und fehlerhaft durch den Nutzer verifiziert, könnte ein netzwerkbasierter Angreifer den Nutzer durch eine manipulierte Verbindung und einen manipulierten HostKey-Fingerabdruck dazu bringen, sich zu einem Angreifer-kontrollierten System zu verbinden. Hierbei könnte, je nach Authentifizierungsmethode, die SSH-Zugangsdaten an den Angreifer gelangen.

In dem Fall, dass die SSHFP-Einträge übereinstimmen, aber nicht per DNSSEC-gesichert übertragen werden, kann ein netzwerk-basierter Angreifer die SSHFP-Einträge sowie die übertragene IP-Adresse des Servers auf DNS-Ebene manipulieren.

Unseres Verständnisses nach (d.h. ohne rechtliche Prüfung oder Beratung), muss nicht mit rechtlichen Konsequenzen gerechnet werden. Bei der beschriebenen Schwachstelle handelt es sich um eine Fehlkonfiguration in Ihrer Infrastruktur, die einen Angriff durch einen Angreifer begünstigen kann. D.h. ohne einen gezielten Angriff gegen Personen, die per SSH den Server administrieren, können keine Daten abfließen, die bspw. eine Meldung an die Datenschutzbehörden erfordern würde. Ohne rechtliche Prüfung können wir aber keine rechtlich bindenden Aussagen treffen. Kontaktieren Sie im Zweifel Ihre Rechtsabteilung oder andere entsprechende Entitäten.

Zum Schutz der eigenen und fremder Systeme sind in dem Selbsttest-Tool einige Beschränkungen umgesetzt worden. Bspw. dürfen Sie nur die Domains prüfen, welche wir angeschrieben haben. Zudem sind zum Schutz fremder Systeme gewisse IP-Bereiche hinterlegt, die nicht überprüft werden können und wir haben ein Limit an Testungen pro Stunde eingerichtet, welches Sie nicht überschreiten können (360 Testungen / Stunde). Bei einer normalen Nutzung des Selbsttest-Tools sollten diese Einschränkungen Ihnen nicht auffallen. Falls Sie dennoch ein fehlerhaftes Verhalten feststellen oder das Tool nicht so nutzen können, wie beschrieben, kontaktieren Sie uns bitte.

Falls Sie noch weitere Fragen haben, stehen wir Ihnen gern zur Verfügung. Am besten erreichen Sie uns per Email an:

- für technische Fragen: neef@sect.tu-berlin.de oder +493031477151
- für methodische Fragen: anne.hennig@kit.edu oder +49 721 608-46038