Wir schaffen es derzeit natürlich schon lange nicht mehr jede Vulnerability zu beschreiben, allerdings versuchen wir zumindest von Zeit zu Zeit auf besonders schwerwiegende Schwachstellen hinzuweisen.
CVE-2018-10933 – Authentication bypass in server code
Unter CVE-2018-10933 wurde am 16.10.2018 eine Schwachstelle in libssh 0.6 aufwärts markiert. Ein Fix wurde bereits mit libssh 0.8.4 und libssh 0.7.6 präsentiert. Dagegen vermutlich unbetroffen scheint libssh2.
Das libssh-Projekt teilt wie erwartet Code zwischen ihren Client- und Serverimplementierungen. Es gibt verschiedene Callbacks, um Pakettypen zu behandeln, wenn eine neue Verbindung den Handshake-Prozess abschließt. Das SSH-Protokoll definiert mehrere Antworten, die gesendet werden sollen, wenn eine Authentifizierungsanforderung bearbeitet wird. Eine dieser Nachrichten ist USERAUTH_SUCCESS, die der Server sendet, um dem Client mitzuteilen, dass die Authentifizierung erfolgreich war und der angeforderte Dienst bereit ist.
Nun kann man die Sicherheitslücke bereits erraten. Libssh hatte keinen Mechanismus um festzustellen, ob ein eingehendes Paket für den aktuellen Zustand der Verbindung erlaubt war. Ein Angreifer könnte eine Verbindung herstellen, der Server würde die Authentifizierungsanfrage senden und der Angreifer könnte mit der USERAUTH_SUCCESS-Antwort antworten. Das Problem besteht darin, dass diese Antwort nur vom Server, nicht vom Client und erst nach Abschluss der Authentifizierung gesendet werden soll.
/** * @internal * * @brief Handles a SSH_USERAUTH_SUCCESS packet. * * It is also used to communicate the new to the upper levels. */SSH_PACKET_CALLBACK(ssh_packet_userauth_success) { (void)packet; (void)type; (void)user; SSH_LOG(SSH_LOG_DEBUG, "Authentication successful"); SSH_LOG(SSH_LOG_TRACE, "Received SSH_USERAUTH_SUCCESS"); session->auth.state = SSH_AUTH_STATE_SUCCESS;Aufgrund des freigegebenen Codes springt der Server fälschlicherweise zum Handler für diesen Nachrichtentyp und markiert die abgeschlossene Authentifizierungsphase. An diesem Punkt richtet der Deamon die SSH-Verbindung so ein, als ob der Client sich authentifiziert hätte und rollt den roten Teppich für den Angreifer aus.
„libssh versions 0.6 and above have an authentication bypass vulnerability in the server code. By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication, the attacker could successfully authentciate without any credentials.“
Was tun?
Wir raten dringendst dazu vorhandene libssh Installationen zu prüfen und wenn nötig schnellst möglichst auf die oben beschriebenen Versionen anzuheben. Es gibt außerhalb dieser Versionen keinen Workaround. Ein großes Risiko besteht insbesondere darin, dass die libssh Libary oftmals embedded verwendet wird. Dies kann insbesondere ein großes Problem bei beispielweise IoT Devices darstellen, da es hier oftmals schwierig wird die Version der das Dasein von libssh zu prüfen. Bei Fragen könnt Ihr euch natürlich jederzeit an uns wenden!
Robert Wortmann
Robert ist seit 2014 bei der Proact Deutschland beschäftigt, wo er sich zunächst als Senior Consultant um Kundenlösungen im Bereich Security und Virtualisierung gekümmert hat. Seit 2016 ist er hauptverantwortlich für den Bereich Security zuständig.
