Angriff ShellShock, einfach

Kürzlich wurde eine Reihe von Sicherheitslücken im Zusammenhang mit einem BUG of Bash gemeldet, dem häufigsten Interpreter unter GNU / Linux, MAC OS und einigen Unix-Betriebssystemen. Der Name lautet S hellShock oder Bashdoor (CVE-2014-6271) . Das wichtigste und alarmierendste Problem in dieser Hinsicht hat mit der Tatsache zu tun, dass besagter BUG in den letzten 20 Jahren in Bash vorhanden war, so dass geschätzt wird, dass der Ernst der Angelegenheit noch größer ist als Heartbleed.

Der Bash BUG oder ShellShock ist an sich kein bösartiger Code (als ob es sich um Computerviren, Spyware, Malware usw. handelt), sodass er nicht von Antiviren- oder ähnlichen Systemen erkannt und blockiert werden kann, sondern in korrigiert werden muss die eigentliche Implementierung der Software, die “leidet”.

Es wird empfohlen, dieses Lernprogramm in kontrollierten Umgebungen anzuwenden, die sich auf die Erforschung und das Studium der Informatik beziehen, wie es hier dargestellt wird.

Was ist der Bash BUG ShellShock?

Grundsätzlich liegt das Problem in der Möglichkeit, dass Bash in Umgebungsvariablen die Definition von Skriptfunktionen speichern muss, genauer gesagt, wie diese Funktionen von Bash geladen werden.

Der BUG tritt auf, wenn eine Umgebungsvariable nach der Funktionsdefinition zusätzlichen Code hinzufügt, den Bash nach dem Laden der Funktion weiter analysiert und ausführt.

Mit dem folgenden Befehl wurde eine leere Funktionsdefinition, ein beliebiger Code und dann Bash in die Variable “x” geladen.

Was passiert ist, dass vor dem Aufruf von Bash die Umgebungsvariable geladen und der injizierte Code ausgeführt wurde, der einfach die Zeichenfolge “vulnerable” in der Konsole anzeigt (es hätte schlimmer sein können, klar!). Dann wurde Bash ausgeführt und als Beispiel der Echo-Befehl aufgerufen. Eine einfachere Variante des Befehls zum Ausführen des Tests:

 $ env x = '() {:;}; echo verwundbare 'Bash 

Dieser letzte Befehl zeigt auf dem Bildschirm die Zeichenfolge “vulnerable” an, wenn die Bash-Version den BUG aufweist, oder es wird nichts angezeigt, wenn es sich um eine gepatchte Version handelt.

Wie in der Einführung angegeben, stellt dieser BUG eine Reihe von Sicherheitsanfälligkeiten fest, die von einem Angreifer zur Remotesteuerung von Computern verwendet werden können. Innerhalb dieser Varianten gibt es einige etwas komplexere, andere sehr einfache und einige mehr oder weniger komplexe. Es gibt Varianten, die mit Apache und den CGI-Modulen zusammenhängen, andere für den DHCP-Client und einige etwas ausgefeilter als andere.

In diesem Handbuch verwenden wir einen der einfachsten Fälle, den ShellShock-Angriff auf den DHCP-Client von GNU / Linux .

Für den Proof-of-Concept nehmen wir ein LAN an, in dem sowohl das Opfer als auch der Angreifer verbunden sind.
Da die DHCP-Client-Software mit Administratorrechten ausgeführt wird, versucht der Angreifer, in die dem Opfer zugewiesene DHCP-Konfiguration böswilligen Code in einen DHCP-Optionsparameter aufzunehmen.

Vorgehensweise

1) Der Angreifer führt die DHCP-Dienstsoftware aus. {Für dieses Handbuch haben wir (ftp32 “von Ph. Jounin) verwendet.}

1.1) Wählen Sie die zu verwendende Netzwerkschnittstelle aus und klicken Sie auf die Schaltfläche “Einstellungen”

1.2) Konfigurieren Sie die Optionen so, dass nur der DHCP-Dienst ausgeführt wird.

1.3 Gehen Sie zur Registerkarte “DHCP” und konfigurieren Sie wie folgt:

1.4) Beachten Sie, dass im Feld “Addiotional Option” die Option 114 angegeben wurde (wird in VOIP verwendet) und im Optionsdetailfeld die Definition der Bash-Funktion und der Schadcode hinzugefügt wurden:

 () {ignoriert;}; Echo 'CODE INJECTED'; / bin / cat / etc / passwd 

1.5) Drücken Sie “OK”, der DHCP-Dienst ist bereit.

2) Führen Sie im Terminal des Systems des Opfers den folgenden Befehl aus, um “das System-Syslog” in der Ansicht zu belassen, wenn wir die DHCP-Anforderung ausführen:

 # tail -f / var / log / syslog & 

3) Unter der Annahme, dass eth1 die Netzwerkschnittstelle des Opfers ist, führen Sie den DHCP-Client aus:

 # dhclient eth1 

4) Der Befehl nimmt der DHCP-Anfrage und dem Angreifer die entsprechende Zuweisung vor:

5) Im Terminal des Opfers wird dank des Befehls tail, der im Hintergrund das Syslog des Systems anzeigt, die Ausführung des eingespeisten Codes visualisiert. In diesem Fall wird die Kette “INJECTED CODE” verschoben und anschließend der Inhalt des Systems aufgelistet. Datei / etc / passwd des Opfers (hätte viel schlimmer sein können …):

Dieser letzte Teil ist dem Befehl ” / bin / cat / etc / passwd ” zu verdanken, der Teil der als Option 114 angegebenen Zeichenfolge ist.

Der Angreifer hätte andere Befehle ausführen und jede Aktion ausführen können, vorausgesetzt er verfügt über “root” -Berechtigungen, da der DHCP-Client des Opfers mit solchen Berechtigungen ausgeführt wird.