James Steidl - Fotolia

Wie kritisch ist die OpenSSH-Schwachstelle CVE-2016-0777 wirklich?

Eine Schwachstelle in der nicht vollständig implementierten Roaming-Funktion von OpenSSH kompromittiert die privaten Schlüssel der Serverbenutzer.

Das Security Advisor Team des Sicherheitsanbieters Qualys hat eine Schwachstelle in OpenSSH entdeckt, durch die Angreifer das SSH-Protokoll kompromittieren können. Die Schwachstelle trägt die offizielle Bezeichnung CVE-2016-0777 und wird deshalb im Web auch Tripple Seven genannt. Betroffen ist OpenSSH-Client-Code in den Versionen 5.4 bis 7.1, der eine experimentelle Roaming-Funktion enthält.

Wolfgang Kandek, CTO bei Qualys, äußert sich gegenüber SearchSecurity.de zu CVE-2016-0777:

Zur Risikostufe der Schwachstelle: Es ist eine Schwachstelle, die das Auslesen von Informationen ermöglicht und daher gemäß CVSS-Skala (Common Vulnerability Scoring System) wohl nicht als kritisch gilt. Bei den offengelegten Informationen handelt es sich jedoch um SSH-Schlüssel und diese werden weithin zur Automatisierung von Systemverwaltungsaufgaben und für interaktive Logins verwendet. Wenn ein Angreifer Zugriff auf diese Schlüssel bekommt, könnte er sich als deren Eigentümer ausgeben, was dann oft mit Administrator-Rechten auf dem System verbunden ist. System-Administratoren können auf dem Zielsystem in der Regel installieren, was immer sie wollen, einschließlich Hintertüren und Malware.

Mit dem formal eher geringen Risikograd verhält es sich ähnlich wie bei der Sicherheitslücke Heartbleed. Diese hat ebenfalls einen niedrigen CVSS-Score, ist aber trotzdem eine sehr gravierende Schwachstelle aufgrund der Informationen, die offengelegt werden können.

Zur Roaming-Funktion: Das ist eine experimentelle Funktion in OpenSSH, die derzeit aber nur von den Clients unterstützt wird. Vollständig implementiert würde sie die Stabilität von SSH-Sitzungen erhöhen und eine Wiederaufnahme von Verbindungen ermöglichen. Da sie jedoch nicht vollständig implementiert ist, sollte sie sich in der OpenSSH-Konfigurationsdatei transparent abschalten lassen. Dies ist auch die empfohlene Abhilfemaßnahme für Benutzer, die nicht sofort einen Patch aufspielen können.

Zu den Angriffsmöglichkeiten: Um den Angriff durchführen zu können, muss der Angreifer den SSH-Server kapern. Das bedeutet, dass er bereits System-Administrator-Rechte auf dem Server hat, auf dem sich die Benutzer anmelden – allein das wäre dann schon ein gravierendes Sicherheitsereignis und dürfte entsprechend relativ selten vorkommen. Wenn es einem Angreifer allerdings tatsächlich gelungen ist, den SSH-Server zu kapern, kann er diesen Exploit implementieren und die privaten Schlüssel der Benutzer auslesen. Mit einem solchen privaten Schlüssel kann er sich dann als der betreffende Benutzer ausgeben und sich auf anderen Systemen anmelden. Da SSH vielfach zur Automatisierung von Prozessen der System-Administration verwendet wird, würde ein solcher privater Schlüssel dem Angreifer sehr umfangreichen Zugriff auf eine Infrastruktur ermöglichen.

Eine bloße MITM-Position genügt zur Durchführung dieses Angriffs nicht. Es reicht also nicht, wenn ein Angreifer nur im Netzwerk lauschen kann, sondern er muss tatsächlich Kontrolle über den Server haben, mit dem sich die Benutzer verbinden.

„Mit dem formal eher geringen Risikograd verhält es sich ähnlich wie bei der Sicherheitslücke Heartbleed.“

Wolfgang Kandek, CTO, Qualys

xxx

Meine Empfehlung: Spielen Sie verfügbare Patches so schnell wie möglich ein. Wenn Sie nicht sofort patchen können, schalten Sie Use Roaming ab. Bei persönlichen Systemen dürfte das einfach sein, doch in automatisierten Szenarien werden Sie vermutlich Tests durchführen müssen, um sicherzugehen, dass keine unerwünschten Nebeneffekte auftreten. Solche sind zwar eher nicht zu erwarten, aber trotzdem ist es sinnvoll zu überprüfen, ob alles noch wie gewohnt läuft. Wenn Sie Ihre SSH-Schlüssel neu generieren können, untersuchen Sie, ob jemand die Sicherheitslücke bereits ausgenutzt hat und Ihre Schlüssel preisgegeben wurden.

Auf openssh.com steht mit OpenSSH 7.1p2 eine Version bereit, in der das Problem beseitigt ist.

Über den Autor:
Wolfgang Kandek ist CTO bei Qualys. Der Sicherheitsanbieter stellt On-Demand-Lösungen für IT-Sicherheits- und Compliance-Management als Service bereit. Der Service QualysGuard wird derzeit von mehr als 5.000 Unternehmen in 85 Ländern genutzt, darunter 47 der Fortune Global 100, und führt pro Jahr über 500 Millionen IP-Audits durch. Qualys unterhält strategische Vereinbarungen mit führenden Managed Service Providern und Consulting-Firmen und gehört zu den Gründungsmitgliedern der Cloud Security Alliance (CSA).

Folgen Sie SearchSecurity.de auch auf Twitter, Google+ und Facebook!
 

Artikel wurde zuletzt im Januar 2016 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Enterprise-Vulnerability-Management

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close