Das Problem mit SSH Agent-Forwarding

Am 12. April 2019 wurde die Website matrix.org gehackt. Anschließend wurden auf GitHub einige der Fehler veröffentlicht, die diesen Angriff ermöglicht haben, u.a. [SECURITY] SSH Agent Forwarding. Eine Zusammenfassung dieser Fehler findet sich in Repost of the security issues. Dabei war der initiale Fehler, dass den Entwicklern SSH-Forwarding erlaubt wurde.

Problem und Lösungen für SSH Agent-Forwarding

Selbst in den man pages von ssh_config wird gewarnt:

Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

Einfach ausgedrückt: Wenn der Jump Server kompromitiert ist und SSH Agent-Forwarding als Verbindung zu einem anderen Computer verwendet wird, kann auch der Zielhost angegriffen werden.

Statt SSH Agent-Forwarding sollte besser ProxyCommand oder ProxyJump (ab OpenSSH 7.3) verwendet werden, da dann die TCP-Verbindung über ssh an den Zielhost weitergeleitet wird und so eine Ende-zu-Ende-Verschlüsselung realisiert wird. Falls dann jemand auf dem Jump Host versucht, die Verbindung mit einem Man-in-the-Middle-Angriff zu unterbrechen, warnt ssh vor dieser Unterbrechung.

ProxyCommand kann z.B. folgendermaßen konfiguriert werden:

Host bastion
  HostName bastion.example.org

Host target
  HostName target.example.internal
  Port 2222
  ProxyCommand ssh -W %h:%p bastion

Die entsprechende Konfiguration mit ProxyJump kann z.B. so aussehen:

Host bastion
  HostName bastion.example.org

Host target
  HostName target.example.internal
  Port 2222
  ProxyJump bastion

Alternativ können beide Optionen selbstverständlich auch über die Befehlszeile angegeben werden:

ssh -o 'ProxyJump=bastion.example.org' target.example.internal -p 2222

Eskalation

Die Eskalation von Privilegien hätte vermieden werden können …

  • wenn die Entwickler nur den Zugriff bekommen hätten, der unbedingt benötigt wird und nicht root-Zugriff auf alle Server.
  • wnn nicht alle Server direkt über das Internet erreichbar gewesen wären.
  • wenn mit sshd_config nicht Schlüssel in authorized_keys2 hinzugefügt werden könnten.
  • wenn nicht vertrauliche Daten im Repository für die interne Kommunikation gespeichert worden wären.
  • wenn auf den Hosts nur die eigene Konfiguration gespeichert gewesen wäre.
  • wenn die Log-Dateien besser analysiert und Warnmeldungen bei ungewöhnlichem Verhalten geschickt worden wären.
  • wenn GPG-Schlüssel zum Signieren von Paketen nicht auf Production-Hosts hinterlegt gewesen wären.
  • wenn Zwei-Faktor-Authentifizierung (2FA) verwendet worden wäre, z.B. mit Yubikey.