Angriffsvektoren

Viele Dinge sind technisch möglich. Die meisten sind aber nicht immer sinnvoll. Dabei ist es angebracht, das eigene Tooling am eigenen Bedrohungsmodell auszurichten. Eine Erläuterung am Beispiel.

Ausgangssituation

SSH Multiplexing bietet das Potential, Authentifizierung und Verbindungsaufbau bei parallelen Sessions zum selben Ziel deutlich zu beschleunigen. In entsprechenden Situationen lassen sich so Zeit und Nerven sparen.

Haken daran: der Socket hält die Authentifizierungsdaten, Zugriff auf den Socket ermöglicht Zugriff auf das Zielsystem.

Alles im Kontext

Betrachtet man die Funktionalität “SSH Multiplexing” für sich alleinstehend, ist eine Bewertung ihrer Sicherheit schwierig. Wichtig ist daher immer der Blick auf die Umgebung, in der eine Lösung eingesetzt wird. Gleichzeitig müssen auch die eigenen Bedrohungsszenarien betrachtet werden.

Wenn beispielsweise ein Man-in-the-Middle-Angriff auf die SSH-Verbindung erwartet wird, dann ist die Sicherheit von SSH Multiplexing dadurch nicht beeinträchtigt. Es ist eine Authentifizierung am Zielsystem nötig, die Sessions sind verschlüsselt und solange angemessene Krypto-Standards verwendet werden, macht die auch so schnell niemand auf.

Vielleicht geht das eigene Bedrohungsszenario aber davon aus, dass der eigene Client bereits übernommen wurde. In diesem Fall wäre die Verwendung von SSH Multiplexing eine Sicherheitslücke. Die Angreifenden könnten über den Socket eigene Verbindungen zum Zielsystem aufbauen und für ihre Zwecke nutzen.

Konsequenzen

Wenn der eigene Client nun als kompromittiert gilt, hat das eine Reihe von Folgen. Es reicht beispielsweise nicht aus, Multiplexing aus der ~/.ssh/config zu entfernen. Denn nur, weil ich es nicht konfiguriert habe, heißt das noch lange nicht, dass die Angreifer*in das nicht konfiguriert und nutzt.

Grundsätzlich gilt in diesem Szenario als Basis für alle Absicherungsmaßnahmen:

Wenn der eigene Client als kompromittiert angesehen wird, kann die Absicherung nicht auf diesem Client stattfinden.

Um im konkreten Fall also die Ausnutzung von SSH Multiplexing durch einen Angriff zu vermeiden, muss das Feature auf dem Zielsystem abgeschaltet werden. Nur so kann sichergestellt werden, dass das nicht verwendet werden kann.

Die entsprechende Einstellung auf dem Zielsystem erfolgt in der /etc/ssh/sshd_config. Dort muss der Parameter MaxSessions auf den Wert 1 gesetzt werden¹.

MaxSessions 1

Der Wert 1 sorgt dafür, dass pro TCP-Verbindung nur noch eine SSH Session erlaubt ist. Dadurch wird die Nutzung von Multiplexing (mehrere Sessions pro TCP Verbindung) verhindert. Gleichzeitig bleibt es aber möglich, mehrere “reguläre” Verbindungen aufzubauen und so weiterhin parallele Sessions zum Ziel zu ermöglichen. Nur eben auf einem anderen technischen Weg.