Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Serverzugriff unsicher: Forscher entdecken SSH-Sicherheitslücke

Die Secure Shell (SSH) ist eine der wichtigsten Technologien zur Kommunikation zwischen Servern. Sie soll sicherstellen, dass niemand den Datenaustausch mitlesen oder verändern kann. Eine Veröffentlichung stellt jetzt das Kernversprechen des SSH-Protokolls in Frage. Die Wissenschaftler konnten bei den am weitesten verbreiteten Verschlüsselungsmethoden den Datenverkehr kompromittieren.


Für ihre "Terrapin" getaufte Methode brauchten die Forscher keinen Zugriff auf einen der beiden Server am Ende der Verbindung. Ihr Angriff funktioniert bereits, wenn der Datenverkehr über ihren Rechner läuft. SSH soll vor solchen Mittelsmann-Angriffen eigentlich schützen. Um sich in die Serverkommunikation einzuklinken, nutzten die Entwickler eine Lücke bei der Etablierung der SSH-Verbindung. Diese Handshake genannte Prozedur besteht aus mehreren aufeinanderfolgenden Nachrichten, bei der die beiden Server abklären, wer sie sind und wie die Verschlüsselung ablaufen soll.

Die Forscher wählten die Sumpfschildkröte (Terrapin) als Namensspender für ihre Sicherheitslücke.

Meistverbreitete Verschlüsselungen betroffen
SSH ist kein monolithischer Block, sondern ein Protokoll, in dem unterschiedliche Verschlüsselungsverfahren zum Einsatz kommen. "ChaCha20-Poly1305" und "CBC with Encrypt-then-MAC" sind für den Angriff anfällig. Sie waren bei ihren Untersuchungen im Oktober auf drei Viertel aller untersuchten öffentlich überprüfbaren SSH-Server im Netz aktiv, bei 57 Prozent sogar die bevorzugte Verschlüsselungsform.

Wohl kein Grund zur Panik
Die umfangreichen Erläuterungen der Sicherheitslücke haben die Wissenschaftler in einer Vorabveröffentlichung ins Netz gestellt. Sie werten ihren Ansatz als die erste bisher veröffentliche Sicherheitslücke im SSH-Protokoll. Im Fazit geben sie mehrere Empfehlungen: Kurzfristig können Serveradministratoren die beiden betroffenen Verschlüsselungsalgorithmen deaktivieren. Langfristig sollte die zugrunde liegende SSH-Spezifikation in zwei Punkten verändert werden, um diese Lücke zu schließen. Auf ihrer Website zur Veröffentlichung glätten sie auch die möglicherweise entstehenden Wogen der Aufregung: Damit die beschriebene Methode zum Erfolg führt, muss tatsächlich der gesamte Datentransfer durchgängig über den präparierten Mittelsmann-Server laufen. In den Weiten des Internets, bei dem sich Datenpakete stets den schnellsten Weg suchen, ist ein Mitlauschen nicht möglich.

Kommentare

Jethro100022.12.23 12:45
Jeder verantwortungsvolle Admin kennt das Tool ssh-audit und prüft seine Server regelmäßig mit diesem Tool. In den Standard Einstellungen sind bei fast allen Distros zu viele alte und angreifbare Algorithmen aktiviert. Die Distro Anbieter legen meiner Meinung viel Wert auf Abwärtskompatibilität als sich um Sicherheit zu kümmern.
Die oben genanten Cypher sind mindestens schon ein Jahr in ssh-audit auf der Redlist.
+8
Nebula
Nebula22.12.23 19:29
Wie steht’s um macOS? Da ist die SSH-Freigabe ja nur ein Schalter und zumindest in der GUI nicht weiter konfigurierbar.
»Wir werden alle sterben« – Albert Einstein
+3
Jethro100027.12.23 11:38
Nebula
Wie steht’s um macOS? Da ist die SSH-Freigabe ja nur ein Schalter und zumindest in der GUI nicht weiter konfigurierbar.

Das ist relativ einfach. Da macOS viele Teile aus BSD nutzt helfen da die Anleitungen. Aber um es abzukürzen, habe ich die wichtigen Schritte hier aufgelistet. Bitte die Schritte einem nach dem anderen durchführen, da Du Prompts bekommst in dem Du ein Overwrite bestätigen musst. Ferner wird die originale Config nicht geändert, da diese bei einem Update überschrieben werden könnte.

Wie es mit älteren Versionen aussieht weiß ich nicht, da ich diese Änderungen in macOS Ventura vorgenommen habe

sudo -i 

ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.safe

mv /etc/ssh/moduli.safe /etc/ssh/moduli

printf "\n# Restrict key exchange, cipher, and MAC algorithms, as per sshaudit.com\n# hardening guide.\nKexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256\nCiphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr\nMACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com\nHostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com\n" >> /etc/ssh/sshd_config.d/200-secure.conf

exit

Danach musst Du den SSH Daemon nicht neu starten, da er Änderungen automatisch erkennt
+1

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.