Ausnutzen von BASH mit dem ShellShock-Angriff

Von: Igor Jardim

O Neurose nutzt eine Schwachstelle in der Komponente aus BASH von Systemen UNIX, wodurch die Remote-Ausführung von Befehlen ermöglicht wird.

BASH ist ein Befehlsinterpreter in Unix-Umgebungen. Ein Befehl ist eine Aktion oder eine Reihe von Aktionen, die an einen Interpreter (Shell) gesendet werden. BASH (Bourne Again Shell), erstellt von SR Bourne, ist das am häufigsten verwendete dieser Programme, obwohl es auch andere wie csh, tesh und sh gibt. In Microsoft-Umgebungen ist cmd.exe der native Interpreter.

Ein weiterer wichtiger Punkt ist, dass die Shell auch ein Skriptinterpreter ist, der von Anwendungen auf Webservern wie Apache aufgerufen werden kann.

Der Angriff

BASH ermöglicht die Erstellung von Umgebungsvariablen, die bei Bedarf vom Benutzer aufgerufen werden. Es ist auch möglich, eine Umgebungsvariable automatisch mithilfe eines Skripts aufzurufen. Ein Beispiel wäre das Erstellen einer Variablen, die eine Zeichenfolge mit einem Namen empfängt:

Umgebungsname = Nicolas

echo „Willkommen $Name“

Shellshock (Sicherheitslücken CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187) ermöglicht, dass diese in der Umgebungsvariablen enthaltene Zeichenfolge Befehle enthält, die ausgeführt werden können, ohne dass die Variable überhaupt aufgerufen wird.

Die BASH-Versionen 1.14 (von 1994) bis 4.3 sind für diesen Fehler anfällig. Obwohl dieser Fehler sehr alt ist, wurde er erst vor Kurzem öffentlich entdeckt. Es gibt daher keine Garantie dafür, dass dieser Fehler nicht für Angriffe ausgenutzt wurde (oder weiterhin ausgenutzt wird).

Wie bei SQLInjection ermöglicht dieser Fehler einem Angreifer, den Interpreter mithilfe bestimmter Parameter zu umgehen, wodurch BASH beliebige Befehle ausführt, die von einem legitimen Benutzer nicht beabsichtigt sind. Im folgenden Beispiel sollte die einzige Ausgabe des Befehls „normale Skriptbefehle“ sein, aber in einer kompromittierten Bash wird die Variable ausgeführt, ohne dass sie in irgendeinem Teil des Skripts aufgerufen wird, und es wird Folgendes auf dem Bildschirm ausgegeben:

Wort „Warnung“.

# env NAME='() { :;}; echo Warnung‘ bash -c „normale Skriptbefehle echoen“

Warnung

normale Skriptbefehle

Die Variable NAME wurde nie aufgerufen, der darin enthaltene Echo-Befehl wurde jedoch trotzdem ausgeführt.

Dieser Fehler kann auf verschiedene Weise ausgenutzt werden. Die Variable kann einfach deklariert werden und jeder andere Befehl darin kann ausgeführt werden. In einem anderen Beispiel ist es möglich, einen bestimmten Port mit einem Tool zu öffnen, das häufig standardmäßig auf Systemen installiert ist und von Administratoren nicht entfernt wird: Netcat.

Im folgenden Beispiel öffnet das Skript bei der Ausführung Port 7654, wodurch der direkte Zugriff auf BASH auf dem kompromittierten Host ermöglicht wird. Dieser Angriff ermöglicht den Zugriff auf BASH automatisch und im Systemhintergrund, ohne dass der Benutzer davon Kenntnis hat.

# env NAME='() { :;}; nc -lp 7654 -e /bin/bash&' bash -c „echo Normal“

Normal

Die Ausführung der Funktion wird fortgesetzt und druckt am Ende das Wort „Normal“, ohne jedoch den Aufruf von Netcat zu erwähnen. Für einen normalen Benutzer, der nur die Befehlsausgabe überprüft, ist alles normal, aber wenn wir die offenen Ports des Systems mit netstat überprüfen, stellen wir fest, dass Port 7654 offen ist und auf Verbindungen wartet.

# netstat –tupan | grep 7654

tcp 0 0 0.0.0.0:7654 0.0.0.0:*

HÖREN 12846/nc

Dies macht Shellshock zu einem größeren Problem als Heartbleed, da letzteres zwar versteckte Daten auf dem Server liest, ersteres jedoch die vollständige Kontrolle über den anfälligen Host ermöglicht. Shellshock kann an zwei unterschiedlichen und weit verbreiteten Fronten auftreten, nämlich bei Webservern und eingebetteten Systemen (z. B. drahtlosen Routern).

Einige Unternehmen wie Yahoo! haben bestätigt, dass ihre Server durch die Schwachstelle beeinträchtigt wurden. Nach Angaben des Unternehmens selbst kam es jedoch zu keinerlei Beeinträchtigung der Benutzerdaten.

Lösung

Während dieser Fehler für normale Benutzer kein so bedrohliches Problem darstellt, kann er für Unternehmen äußerst kritisch werden. Die Geschäftsdienste liegen normalerweise in den Händen von Systemadministratoren, die für die Anwendung von Software-Patches und -Updates verantwortlich sind. Diese Fachleute haben nicht die Angewohnheit, ihre Server ständig zu aktualisieren, und bemerken den Hackerangriff erst lange nach dem Vorfall.

Für praktisch alle Linux-Distributionen ist bereits ein Fix für den Shellshock-Fehler verfügbar. Sie müssen lediglich das Standard-Repository aktualisieren und Bash aktualisieren.

Bei eingebetteten Geräten wie Routern, Druckern und VoIP-Telefonen ist das Problem etwas komplizierter. Das Aktualisieren (und Beheben von Fehlern) eingebetteter Geräte hängt von den vom Hersteller bereitgestellten Updates ab. Diese Updates sind nicht immer für alle Geräte verfügbar und ältere Modelle bleiben möglicherweise bis zum Ende ihrer Nutzungsdauer anfällig für derartige Angriffe.

Zusammenfassung

Um sich vor einem Shellshock zu schützen, sollten Sie die folgenden Maßnahmen ergreifen:

– Überprüfen Sie sofort mit den folgenden Befehlen, ob Ihre Bash anfällig ist:

# env shock='() { :;}; echo VULNERABLE‘ bash -c „echo Kryptus.com“

Wenn die Befehlsausgabe VULNERABLE ist, sollten Sie Ihr System aktualisieren.

# env shock='() { (kryptus.com)=>\' bash -c „Echo-Datum“; Katzenecho; rm ./echo

Wenn die Befehlsausgabe das aktuelle Datum ist, selbst wenn einige Fehler angezeigt werden, ist Ihr System anfällig.

– Aktualisieren Sie das System mit den je nach Distribution erforderlichen Befehlen:

Debian-basierte Systeme

# apt-get-Update; apt-get install –only-upgrade bash

RedHat-basierte Systeme

# yum update bash -y

Arch-basierte Systeme

#pacman -Syu

– Überprüfen Sie die Zugriffsprotokolle, um nach unerwarteten Zugriffen auf die Server zu suchen.

– Behalten Sie Sicherheitsfixes sowohl für Betriebssystemverteilungen als auch für eingebettete Geräte im Auge.

Referenzen
https://shellshocker.net/
http://www.businessweek.com/news/2014-10-06/yahoo-says-no-data-stolen-in-shellshock-hack
https://cve.mitre.org/
https://www.debian.org/security/2014/
http://www.ubuntu.com/usn/
http://lwn.net/Alerts/CentOS/
https://securityblog.redhat.com/