Die Shellshock-FAQ: Das müssen Sie wissen

Die Situation mit der Shellshock-Bug ist so flüssig und kompliziert, dass selbst Insider Schwierigkeiten haben, den Überblick zu behalten. Diese Fragen und Antworten können Ihnen helfen, den Fehler – eigentlich „Bugs“ – zu verstehen und zu verstehen, was Sie dagegen tun sollten.

Der Hauptautor dieser Fragen und Antworten ist Michael Lin, Sicherheitsforschungsingenieur bei FireEye, Inc. FireEye bietet Forschungs- und Sicherheitsprodukte zum Schutz von Unternehmens- und Regierungsnetzwerken vor Bedrohungen.

Was ist Shellshock?

Shellshock ist ein Spitzname für einen Fehler im Bash (Bourne Again Shell) Befehlszeileninterpreter, auch Shell genannt. Die Bash-Shell ist als Standard-Befehlszeileninterpreter auf vielen Betriebssystemen weit verbreitet einschließlich der meisten Linux-Varianten, vieler Unix-Varianten, einiger BSD-Varianten und Apples OSX (seitdem). 10.3).

Die Bash-Shell ist auch auf vielen anderen Systemen zu finden, von Windows bis Android. Allerdings ist es auf diesen Systemen nicht standardmäßig installiert und/oder verwendet.

Seit der Ankündigung des ersten Shellshock-Fehlers (CVE-2014-6271), verwandte Fehler in Bash wurden von verschiedenen Forschern gefunden. Die vollständige Liste (bisher) finden Sie unten. Der bedeutendste davon ist nach wie vor der Fehler CVE-2014-6271 und die Verweise auf Shellshock unten beziehen sich darauf, sofern nicht anders angegeben.

Wer ist gefährdet?

Theoretisch sind alle Benutzer von Bash angreifbar. Allerdings sind nur Benutzer von Bash, die mit dem Internet verbunden sind, einer Remote-Ausnutzung ausgesetzt. Darüber hinaus ist bestimmte Software erforderlich, um einen Weg bereitzustellen, über den ein Angreifer Bash erreichen kann.

Systeme, auf denen Internet-Server laufen, sind am anfälligsten und werden am wahrscheinlichsten angegriffen. Heimanwender, die Bash auf einem PC haben, können ebenfalls gefährdet sein, wenn sie nicht vertrauenswürdige Netzwerke (z. B. öffentliche WLAN-Zugangspunkte) nutzen.

Der durchschnittliche Internetnutzer mit Windows, Mac OS, iOS oder Android ist nicht anfällig, zumindest nicht standardmäßig. Die Kompromittierung von Internetservern, denen diese Benutzer vertrauen, könnte jedoch andere Angriffe des Servers auf Clients erleichtern und vertrauliche Benutzerdaten auf den Servern könnten Angreifern zugänglich gemacht werden.

Wo tritt der Fehler auf?

Der Fehler ist im Parsing-Code von Bash zu finden. Es liegt ein Fehler in der Art und Weise vor, wie Bash während der Initialisierungssequenz Umgebungsvariablen analysiert. Alles, was die Umgebungsvariablen manipulieren kann, kann potenziell ein Vektor für diese Schwachstelle sein.

Wie macht es dich verwundbar?

Der Bash-Bug ermöglicht es einem Angreifer, dieselben Befehle wie ein legitimer Benutzer auszuführen. Dies gibt einem erfolgreichen Angreifer die Möglichkeit, nahezu alles zu tun, was ein Benutzer tun kann. Ein Angreifer, der Zugriff auf einen Remote-Vektor hat, kann Bash-Befehle aus der Ferne ohne Authentifizierung in das System einschleusen.

Beachten Sie, dass der Angreifer (zumindest anfänglich) auf die Berechtigungsebene des Benutzers beschränkt ist, der die Bash-Instanz ausführt. Sobald ein Angreifer jedoch in Ihrem System Fuß gefasst hat, stehen ihm mehrere Möglichkeiten zur Ausweitung seiner Berechtigungen und möglicherweise zur Erlangung von Root-Zugriff zur Verfügung.

Wie nutzen die Leute es aus?

HTTP-Server
Die meisten Angriffe auf diese Schwachstelle zielen auf HTTP-Webserver ab. Server, auf denen das ausgeführt wird Common Gateway Interface (CGI) oder FastCGI haben die Möglichkeit, Bash einem HTTP-Anfragevektor auszusetzen. Eine in böser Absicht erstellte HTTP-Anfrage kann es einem Angreifer ermöglichen, beliebige Befehle auf dem Server einzuschleusen, und Bash führt diese aus, wenn sie aufgerufen werden.

Bash kann direkt vom CGI (d. h. einem Bash-Skript) oder über einen Unterprozess oder Systembefehl aufgerufen werden. Wenn Bash zu irgendeinem Zeitpunkt im Kontext dieser böswilligen CGI-Anfrage gestartet wird, wird die Sicherheitslücke ausgelöst.

CGI könnte beispielsweise ein PHP-Skript ausführen, das einen Systemaufruf enthält. Auf Systemen, auf denen Bash die Standard-Shell ist, führt dies dazu, dass Bash initialisiert wird, was die Sicherheitslücke auslöst.

Beachten Sie, dass PHP-, Perl- und Python-Skripte, die nicht über das CGI/FastCGI-System aufgerufen werden, wahrscheinlich nicht betroffen sind.

DHCP-Clients
DHCP-Clients basierend auf die Referenzimplementierung des Internet Systems Consortium (ISC) sind auch gefährdet. Dies gilt für die meisten Linux- und Unix-Systeme, OSX ist jedoch nicht betroffen. Dieser Vektor kann ausgenutzt werden, wenn das Opfer eine Verbindung zu einem böswilligen DHCP-Server herstellt. Der anfällige DHCP-Client verwendet vom DHCP-Server bereitgestellte Variablen und speichert sie als Umgebungsvariablen. Der DHCP-Client verwendet Bash, um die Netzwerkschnittstellen zu konfigurieren.

Dies kann passieren, wenn der Benutzer eine Verbindung zu einem öffentlichen WLAN-Zugangspunkt oder einem nicht autorisierten DHCP-Server herstellt.

Eine andere Möglichkeit besteht darin, dass ein Angreifer den CGI-Vektor für den Angriff nutzen könnte, um den DHCP-Dienst auf einem legitimen Server zu gefährden.

SSH
Viele SSH-Systeme sind so eingerichtet, dass sie die Befehle einschränken, auf die ein Benutzer zugreifen kann. Der Bash-Bug kann genutzt werden, um aus diesen Einschränkungen auszubrechen. Beachten Sie, dass hierfür eine Authentifizierung erforderlich ist. Daher stellt dieser Vektor eine Privilegieneskalation dar.

Viele Systeme nutzen SSH, wie zum Beispiel rsync, rlogin, git, subversion usw. Auch diese Systeme sind betroffen.

Common Unix Printing System (CUPS)
TASSEN ist ein Druckserver, der auf vielen Linux-, BSD- und Unix-Systemen zu finden ist. CUPS verwendet benutzergesteuerte Variablen, um Umgebungsvariablen bei der Verarbeitung von Filtern festzulegen. Dies kann möglicherweise ein Vektor für diese Sicherheitsanfälligkeit sein, wenn Bash während dieses Prozesses von CUPS initialisiert wird. Dieser Vektor ist derzeit theoretisch und wir haben ihn in freier Wildbahn noch nicht gesehen.

Browser-Plug-ins
Möglicherweise sind Plug-ins von Drittanbietern vorhanden, die Umgebungsvariablen mithilfe benutzergesteuerter Werte festlegen. Dadurch könnte ein lebensfähiger Vektor entstehen, obwohl dieser in freier Wildbahn noch nicht gesehen wurde.

Zusätzliche Vektoren
Angesichts der weit verbreiteten Verfügbarkeit von Bash ist es möglich, dass in den kommenden Wochen weitere Remote-Vektoren entdeckt werden.

Wie ernst ist es?

Als der Fehler erstmals öffentlich bekannt wurde, waren mindestens mehrere Hunderttausend mit dem Internet verbundene Server leicht anfällig für Ausnutzung. Dies ist eine konservative Schätzung. Es ist sehr wahrscheinlich, dass viele dieser Server inzwischen kompromittiert wurden.

Dieser Fehler lässt sich leicht ausnutzen. Spezialwerkzeuge und benutzerdefinierter Code sind nicht erforderlich. Auch konzeptionell ist es leicht zu verstehen. Proof-of-Concept-Skripte, Demos und Kits sind bereits weit verbreitet.

Die Folgen der Ausbeutung sind sehr schwerwiegend. Typischerweise ist die Befehlsinjektion aus der Ferne ohne Authentifizierung möglich. Sobald ein Vektor gefunden ist, ist die Ausführung willkürlichen Codes oft trivial möglich.

Dieser Fehler existiert seit über zwei Jahrzehnten im Bash-Code. Es ist möglich, dass mehrere Personen diesen Fehler selbst entdeckt und geheim gehalten haben. Es ist auch möglich, dass dieser Fehler vor seiner öffentlichen Entdeckung in freier Wildbahn für böswillige Zwecke ausgenutzt wurde. Es ist jedoch ebenso möglich, dass dieser Fehler vor seiner öffentlichen Entdeckung der Welt unbekannt war.

Die Kombination aus der großen Anzahl anfälliger Server, der Zugänglichkeit von Exploit-Tools und den schwerwiegenden Folgen eines erfolgreichen Exploits bedeutet, dass diese Schwachstelle äußerst schwerwiegend ist.

Was können Sicherheitsteams tun, um sich zu schützen?

Patchen Sie Ihre Systeme. Besorgen Sie sich die neuesten Patches von Ihrem Anbieter und patchen Sie Ihren Bash auf die neueste Version. Bedenken Sie, dass Patches vom Betreuer möglicherweise erneut veröffentlicht werden und neue Patches für Bash-Schwachstellen erwartet werden, die noch nicht behoben wurden.

Überprüfen Sie Ihre Belichtung. Red Hat hat ein ausgezeichneter Führer Erfahren Sie, wie Sie feststellen können, ob Ihr System ungepatcht und anfällig ist (Link).

Wenn Sie Bash nicht patchen können oder für Ihre Plattform kein Patch verfügbar ist, sollten Sie einen Wechsel zu einer anderen Shell in Betracht ziehen.

Aktualisieren Sie Ihre Netzwerk- und Serversicherheitsprodukte. Stellen Sie sicher, dass Ihre IPS-Systeme mit den richtigen Regelsätzen aktualisiert sind, um Ausnutzungsversuche zu erkennen und zu verhindern.

Seien Sie wachsam gegenüber unerwünschten Servern und Zugriffspunkten in Ihrem Netzwerk und an Ihrem Standort.

Wie effektiv kann IPS gegen diese Schwachstellen sein?

IPS und andere Arten der netzwerkbasierten Erkennung sind sehr effektiv zum Erkennen und Verhindern von Shellshock-Exploits. Die zum Auslösen der Sicherheitslücke erforderliche Zeichenfolgenfolge ist sehr charakteristisch und relativ einfach zu analysieren. Auch die Wahrscheinlichkeit falsch-positiver Ergebnisse ist relativ gering, da die schädlichen Daten an einer bestimmten Reihe von Stellen auftauchen und die Zeichenfolgensequenz selten an anderer Stelle verwendet wird.

Ich verwende Windows. Bin ich immun?

Im Allgemeinen ja. Derzeit gibt es keine Hinweise darauf, dass ein ausnutzbarer Windows-Vektor existiert, obwohl dies möglich ist.

Obwohl es möglich ist, Bash unter Windows zu installieren, wären dafür bestimmte Konfigurationseinstellungen und Anwendungen (normalerweise) erforderlich Cygwin oder WAMP), um eine Situation zu schaffen, die möglicherweise zu einem funktionierenden Vektor für diese Schwachstelle führt.

Ich verwende einen Mac. Bin ich verletzlich?

Streng genommen ja, und Apple hat ein Update veröffentlicht um die anfänglichen Schwachstellen zu beheben. In der Praxis benötigen Sie aktivierte Dienste, d. h. einen Webserver mit CGI, was der typische Mac-Benutzer nicht hat.

Ich habe den Patch angewendet. Geht es mir jetzt gut?

Nicht komplett. Für alle großen Linux-Distributionen sind jetzt Patches für CVE-2014-6271 und CVE-2014-7169, die beiden ursprünglichen Probleme, verfügbar. Mehrere andere damit zusammenhängende Schwachstellen in Bash bleiben ungepatcht. Es gibt noch keine öffentlichen Berichte über Angriffe, bei denen diese Schwachstellen ausgenutzt werden, noch gibt es bekannte Proof-of-Concept-Angriffe, und sie sind schwieriger auszunutzen.

Selbst die Patches für die beiden Hauptschwachstellen sind noch nicht stabil. Am Dienstag der Bash-Betreuer hat eine neue Version des Patches veröffentlicht. Diese Version ist strenger als der ursprüngliche Patch und wurde von Red Hat-Entwicklern geschrieben behauptete, der erste Patch sei unzureichend. Der strengere Patch birgt ein größeres, wenn auch immer noch geringes Risiko, dass bestehende Bash-Skripte nicht mehr funktionieren. Andere Anbieter, darunter FreeBSD, NetBSD und VMWare, sind sogar noch weiter gegangen und haben Patches herausgegeben, die die anfällige Funktionalität vollständig deaktivierten, wodurch Inkompatibilitäten wahrscheinlicher wurden.

Was sind die CVEs für Shellshock?

CVE-2014-6271: Dies ist der ursprüngliche „Shellshock“-Bash-Fehler. Wenn die meisten Leute vom Bash-Bug oder „Shellshock“ sprechen, meinen sie höchstwahrscheinlich dieses CVE.

CVE-2014-7169: Dies ist der CVE, der dem unvollständigen Patch für den ursprünglichen Fehler zugewiesen ist.

Kurz nachdem die Schwachstelle öffentlich bekannt wurde, stellte sich heraus, dass der ursprüngliche Patch unvollständig war. Eine Variation der ursprünglichen bösartigen Syntax kann es einem Angreifer ermöglichen, nicht autorisierte Aktionen durchzuführen, einschließlich des Schreibens in beliebige Dateien.

CVE-2014-7186 & CVE-2014-7187: Diese beiden CVEs beziehen sich auf Fehler, die im Zusammenhang mit dem ursprünglichen Bash-Fehler entdeckt wurden. Diese beiden Fehler werden durch eine Syntax ausgelöst, die dem ursprünglichen Bash-Fehler sehr ähnlich ist, aber anstelle einer Befehlsinjektion ermöglichen sie einen Speicherzugriff außerhalb der Grenzen. Derzeit gibt es keinen Beweis dafür, dass diese Käfer über entfernte Vektoren verfügen, und sie wurden auch nicht in freier Wildbahn gesehen.

CVE-2014-6277 & CVE-2014-6278: Sicherheitsforscher haben zwei weitere Fehler entdeckt. Diese beiden Fehler sollen das Potenzial für die Injektion willkürlicher Befehle haben, ähnlich wie der ursprüngliche Bash-Fehler. Details wurden jedoch noch nicht veröffentlicht, um entsprechende Patches erstellen zu können.

Verwandte Berichterstattung:

• Shellshock lässt Heartbleed unbedeutend erscheinen
• Apple veröffentlicht unvollständigen OS X-Patch für Shellshock
• Shellshock: Bessere „Bash“-Patches jetzt verfügbar
• Angreifer suchen nach Shellshock Bash-Zielen
• Hacker springen auf den Shellshock Bash-Zug auf
• Shellshock: So schützen Sie Ihre Unix-, Linux- und Mac-Server
• Zero Day Weekly: Bash-Bug Shellshock, jQuery, Amazons chaotischer EC2-Neustart