© DrHitch/Shutterstock.com
Websecurity

2 Heartbleed, Shellshock, Poodle, BadUSB-Angriffe und Co.


Auch im zweiten Kapitel gehen wir der Frage „Is The Internet On Fire?“ [1] auf den Grund. Im ersten Kapitel konstatierten wir bereits, dass zwar nicht das ganze Internet in Flammen steht, es jedoch an etlichen Ecken und Enden kokelt. Ob dieser Umstand 2014 wirklich schlimmer war als in den Vorjahren, bezweifle ich. 2014 fielen die Schwachstellen und Angriffe nur mehr auf, da einige von ihnen werbewirksame Namen verpasst bekamen. Werfen wir mal einen Blick auf einige „Highlights“ des Jahres 2014. Los ging es mit dem am 7. April 2014 veröffentlichten Heartbleed-Bug in OpenSSL, der bereits im ersten Kapitel vorgestellt wurde [2]. Dieser erwies sich als längerfristiges Problem, etwa, weil die Installation der Patches nach kurzer Zeit stockte. Und er war noch gar nicht richtig verdaut, da kam schon der nächste Schock.

Shellshock – Immer mehr Schwachstellen in der GNU Bash

Die eigentliche Shellshock-Schwachstelle hat die CVE-ID CVE-2014-6271 [3] und wurde am 24. September 2014 veröffentlicht [4]. Die Bash kann nicht nur Shell-Variablen, sondern auch Shell-Funktionen über das Environment an (indirekte) Child-Prozesse exportieren. Aktuelle Versionen verwenden dazu eine Environment-Variable mit dem Funktionsnamen als Namen und der mit () { beginnenden Funktionsdefinition als Variablenwert. Die Schwachstelle besteht darin, dass die Bash die Auswertung nach der Funktionsdefinition nicht beendet, sondern darauf folgende Shell-Befehle parst und ausführt. Zum Beispiel führt das Setzen der Environment-Variable VAR=() { ignored; }; /bin/id dazu, dass beim Import des Environments in den Bash-Prozess /bin/id ausgeführt wird. Der Prozess befindet sich dabei zwar in einem undefinierten Zustand – zum Beispiel kann es sein, dass die PATH-Variable noch nicht gesetzt ist und die Shell unter Umständen nach der Ausführung von / bin/id abstürzt – der Schaden ist dann aber bereits eingetreten. Der ist zwar im Fall von /bin/id quasi nicht vorhanden, bei anderen Variablen wie zum Beispiel /bin/ rm -r / könnte es aber schon unschön werden – vom Öffnen einer Reverse-Shell oder der Installation einer Backdoor ganz zu schweigen.

Die weiteren Schwachstellen

Noch im Laufe des 24. Septembers wurde festgestellt, dass der Patch die Schwachstelle nicht vollständig behebt [5]. Die sich dadurch ergebende neue Schwachstelle erhielt die CVE-ID CVE-2014-7169 [6].

Am 25. September wurden zwei weitere Schwachstellen entdeckt [7]: eine Pufferüberlaufschwachstelle mit der CVE-ID CVE-2014-7186 [8] und ein Off-by-One-Fehler mit der CVE-ID CVE-2014-7187 [9]. Beide Schwachstellen haben mit der eigentlichen Shellshock-Schwachstelle nichts zu tun, erlauben aber unter Umständen das Ausführen eingeschleusten Codes über Eingaben, die eigentlich nicht zum Ausführen von Code führen würden.

Am 27. September wurden noch zwei weitere Schwachstellen bekannt [10]. CVE-2014-6277 [11] ist eine aus der Ferne ausnutzbare Parsing-Schwachstelle, bei der es zum Zugriff auf nicht initialisierten Speicher kommen kann. Die Schwachstelle hat ebenfalls nichts mit der ursprünglichen Shellshock-Schwachstelle zu tun, ermöglicht aber auch das Einschleusen von Code. Deutlich kritischer ist die Schwachstelle CVE-2014-6278 [12], denn sie ist äquivalent zur ursprünglichen Shellshock-Schwachstelle. Eine Folge verschachtelter $...-Statements innerhalb eines Redirects bringt den Parser aus dem Tritt, der daraufhin alles, was danach kommt, ausführt [13], [14]. Der Testcode für die Schwachstelle ist () { _; } >_[$($())] { echo hi mom; id; }' bash -c : und funktioniert mit Bash 4.2 und 4.3, nicht aber mit älteren Versionen. Ihr Entdecker Michal Zalewski schreibt zu dieser Schwachstelle: „The CVE-2014-6278 payload allows straightforward ‘put-your-commands-here’ remote code execution on systems that are protected only with the original patch ...“.

Am 27. September waren also zwei Schwachstellen bekannt, die Angriffe nach dem Muster [Auslöser] [Gewünschte Shell-Befehle] erlaubten. Leichter kann man es einem Angreifer kaum machen, und die Cyberkriminellen haben dieses unfreiwillige Angebot natürlich gerne genutzt.

Etliche Angriffsvektoren

Die große Gefahr der Shellshock-Schwachstelle besteht darin, dass eine Environment-Variable mit beliebigem Namen als „Träger“ einer bösartigen Funktionsdefinition mit angehängten Befehlen dienen kann. Als erster Hauptangriffsvektor wurden HTTP-Requests an CGI-Skripte identifiziert [15]. Ein HTTP-Request sieht typischerweise so aus:

GET /path?query-parameter-name=query-parameter-wert HTTP/1.1
Host: www.demo.example
Custom: custom-header-wert

Gemäß CGI-Spezifikation werden alle Teile der Anfrage in Environment-Variablen gespeichert. Im Fall des Apache httpd kann der „Magic String“ () { in den folgenden Feldern des Beispiels auftreten:

  • Host („www.demo.example“ als Environment-Variable REMOTE_HOST)
  • Headerwerte („custom-header-wert“, im Beispiel als HTTP_CUSTOM)
  • Serverprotokoll („HTTP/1.1“ als SERVER_PROTOCOL)

Beim Verarbeiten des CGI-Skripts durch die Bash wird das Environment ausgewertet. Dabei werden beim Parsen der Funktionsdefinitionen die angehängten Befehle ausgeführt. Das CGI-Skript muss also die betreffenden Environment-Variablen gar nicht verwenden; es reicht aus, dass sie beim Start des Skripts an die Bash übergeben werden.

Ziemlich schnell wurden weitere Angriffsvektoren entdeckt, die laufend mehr wurden. Einige Beispiele:

  • OpenSSH (über die AcceptEnv-Variablen, TERM oder SSH_ORIGINAL_COMMAND)
  • Apache-Server mit mod_cgi oder mod_cgid, die für die Bash geschriebene CGI-Skripte verwenden oder Subshells erzeugen. Subshells werden implizit von system/popen in C, os.system/os.popen in Python, system/exec in PHP (im CGI-Modus) und bei Verwendung einer Shell von open/system in Perl verwendet. Mit mod_php ausgeführte PHP-Skripte sind dagegen nicht betroffen
  • DHCP-Clients, die Shell-Skripte zur Konfiguration verwenden und dabei Parameter von einem möglicherweise bösartigen Server übernehmen
  • Die beiden Skripte /cgi-sys/entropysearch.cgi und /cgi-sys/FormMail-clone.cgi von CPanel
  • Auf Unix/Linux basierende NAS-Systeme, zum Beispiel von Synology und QNAP
  • Mailserver, zum Beispiel qmail, Exim, Postfix und Procmail
  • OpenVPN mit bestimmten Konfigurationen

Auf GitHub gibt es eine Sammlung mit Links zu Proof of Concepts für etliche Programme, Dienste etc. [16].

Aus Angriffsvektoren werden Angriffe – und zwar viele!

Angriffsvektoren sind die eine Sache, Angriffe darauf die andere. Nicht jeder Angriffsvektor wird genutzt, aber eine Schwachstelle, die das Ausführen von Code so einfach wie die Shellshock-Schwachstelle erlaubt, schreit ja geradezu danach, ausgenutzt zu werden. Diese Rufe wurden von den Cyberkriminellen natürlich erhört – und das sehr schnell und sehr oft [17]. Los ging es mit Angriffen auf Webserver. Einige Beispiele:

  • 24. September: Yinette (@yinettesys) veröffentlicht auf GitHub den ersten „in the wild“ beobachteten Angriff, bei dem eine Backdoor eingeschleust wird [18], [19], [20]. In den Kommentaren auf GitHub wurden daraufhin weitere Angriffe gemeldet.
  • 25. September: Michael Bulat hat auf GitHub Code für einen Angriff veröffentlicht, der ein Perl-Skript einschleust [21]. Dabei handelt es sich um eine bekannte Botnet-Backdoor namens Shellbot [22].
  • 25. September: Sucuri hat viele verschiedene Angriffe registriert, unter anderem Versuche zum Öffnen einer Shell und zum Einschleusen von Schadsoftware [23].
  • 26. September: Die Angriffe nehmen weiter zu. Das Botnet wopbot scannt das Internet nach angreifbaren Systemen, um sich dann über die Shellshock-Schwachstelle zu verbreiten [24]. Das Botnet wurde unter anderem für DDoS-Angriffe auf Akamai eingesetzt.
  • 26. September: In Brasilien haben es die Angreifer auf „official institutions“ abgesehen. Es wird aber kein Code eingeschleust; stattdessen sammeln die Angreifer nur Informationen über die Systeme [25], was aber vermutlich nur zur Vorbereitung weiterer Angriffe geschieht.
  • 27. September: Die Bandbreite der Angriffe nimmt weiter zu und umfasst jetzt [26]:
    • Klickbetrug: Über die Schwachstelle wird ein Aufruf an eine Webseite ausgelöst, die dort als Klick eines Benutzers gewertet wird.
    • Reverse-Shell: Es wird eine neue Bash-Shell gestartet und an ein Netzwerk-Socket gebunden, sodass der Angreifer von außen darauf zugreifen und den Rechner kontrollieren kann.
    • Kopieren von /etc/passwd: Über die Bash wird die Passwortdatei, die inzwischen zwar keine Passwörter, aber immerhin noch die Benutzernamen enthält, an den Angreifer geschickt.
    • E-Mail-basierte Tests: Es werden Befehle eingeschleust, die eine E-Mail an den Angreifer schicken, wenn der Angriff erfolgreich ist. Danach dürften dann weitere Angriffe auf die so als angreifbar erkannten Server erfolgen. Oder sie werden zum Spam-Versand missbraucht, denn statt der Befehle zum Mailen einer Rückmeldung an die Angreifer können diese auch zum Senden beliebiger E-Mails an beliebige Empfänger verwendet werden.
    • Einschleusen eines Perl-Skripts mit einer Reverse-Shell (genannt Bashattack), über die die Angreifer dann auf den Server zugreifen können.
    • Installation eines IRC-basierten DDoS-Clients, der auch als Backdoor funktioniert (genannt Tsunami/Kaiten).
    • Einschleusen eines PHP-Skripts, das UDP-Pakete an einen Server senden kann und daher wahrscheinlich für DoS-Angriffe mittels UDP-Flooding genutzt werden soll.
    • Installation von Perl.Shellbot, einem weiteren IRC-basierten DDoS-Client mit Backdoor-Funktionen. Dabei wird zuerst eine Reverse-Shell geöffnet und darüber dann Python-Code eingeschleust, der wiederum das Perl-Skript installiert – entweder wollte da jemand zeigen, wie viele Computersprachen er spricht oder der Angriff wurde aus verschiedenen Quellen zusammen gesetzt.
    • Installation einer weiteren Perl.Shellbot-Variante.
    • Installation einer Reverse-Shell als ELF-Executable.
  • 1. Oktober: Die ersten Angriffe auf aus dem Internet erreichbare NAS-Systeme von QNAP werden gemeldet [27]. Die Angreifer fügen einen eigenen SSH-Schlüssel zur authorized_keys-Datei hinzu und installieren ein ELF-Binary mit einer Backdoor.
  • 25. Oktober: Es wird vor Angriffen auf SMTP-Server gewarnt [28], [29]. Der Shellshock-Exploit wird über verschiedene E-Mail-Header eingeschleust und installiert einen IRC-Perlbot.

Danach war es dann einige Zeit relativ ruhig, bis am 14. Dezember der nächste Angriff gemeldet wurde: Ein Wurm ist auf der Suche nach angreifbaren QNAP-NAS und wurde auch schon fündig [30]. Nachdem das Gerät kompromittiert wurde, wird der bereits seit Anfang Oktober verfügbare Patch von QNAP [31] installiert. Danach macht sich der Wurm auf die Suche nach weiteren Opfern und wartet auf neue Befehle.

Der Shellshock war also bei Weitem noch nicht ausgestanden, da stand am 14. Oktober schon der nächste Angriff vor der Tür: Ein bissiger Poodle hat es auf HTTPS-Verbindungen abgesehen. Vieles dazu wurde bereits im ersten Kapitel geschildert. Im Dezember 2014 fand der Poodle jedoch neue Opfer, die in diesem Kapitel thematisiert werden.

Der Poodle beißt auch TLS-Implementierungen

Der Poodle-Angriff auf SSL/TLS best...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang