Dipl.-Inform. Carsten Eilers

Das erste vorgestellte Beispiel für einen CSRF-Angriff war in mehr als einer Hinsicht ziemlich lahm: Weder ist das Ausloggen des Benutzers besonders gefährlich, noch der Angriff über einen vom Benutzer anzuklickenden Link besonders trickreich. Aber das war ja auch nur das erste Beispiel, wie so oft gilt "Schlimmer geht immer".

Nehmen wir mal an, in einem Forum kann ein neuer Benutzer angelegt werden, indem ein durch einen Cookie authentifizierter Administrator den URL

http://www.server.example/admin/adduser.php?name=[Der Name]&pass=[Das Passwort]

aufruft. Ein Angreifer kann dem Administrator nun ein Seite mit folgendem Tag darin unterschieben:

<img src="http://www.server.example/admin/adduser.php?name=boese&pass=boese">

Ruft der (eingeloggte) Administrator die Seite auf, passiert folgendes: Der Browser sendet einen GET-Request zum Laden des angegebenen Bilds - und auf dem Server wird der Befehl zum Anlegen des Benutzers ausgeführt. Den Cookie, mit dem der eingeloggte Administrator erkannt wird, hat der Browser gehorsam mitgeschickt.

Auch ein Angriff gegen ein Formular, das statt eines GET- einen POST-Request verwendet, ist möglich. Ein Formular für obiges Beispiel könnte so aussehen:

<form method="post" action="http://www.server.example/admin/adduser.php">
  Name:     <input name="benutzername"> <br>
  Passwort: <input name="passwort"> <br>
  <input type=submit value="Benutzer anlegen">
</form>

Die übertragenen Daten werden im Request verborgen und tauchen nicht im URL auf. Aber ein Angreifer kann dem Benutzer einfach eine Seite mit einem sich selbst absendenden Formular darin unterschieben:

<form name="CSRF" method="post" action="http://www.server.example/admin/adduser.php">
  <input type="hidden" name="benutzername" value="boese">
  <input type="hidden" name="passwort" value="boese">
</form>
<script>document.CSRF.submit()</script>

Ruft der (eingeloggte) Administrator die Seite auf, wird das Formular abgesendet, als hätte der Benutzer auf den (nicht vorhandenen) Submit-Button geklickt. Den Cookie zur Erkennung des Administrators sendet der Browser wieder automatisch mit.

Ein letztes Beispiel: Ein Benutzer sitzt hinter einer Firewall, deren webbasiertes Administrationstool durch eine HTTP-Basic-Authentication geschützt ist. Die Regeln der Firewall lassen sich durch folgenden GET-Request löschen:

http://192.168.1.1/admin/delrule?rule=[Nummer der Regel]

Wird statt einer Zahl ein * eingegeben, werden alle Regeln gelöscht. Dem angemeldeten Benutzer wird nun ein entsprechender Link untergeschoben, z.B. in einer Webseite mit folgendem Tag darin:

<script src="http://192.168.1.1/admin/delrule?rule=*">

Beim Laden der Seite versucht der Browser, das gewünschte Skript zu laden und sendet dabei den GET-Request zum Löschen aller Regeln an die Firewall. Den zugehörigen HTTP-Authentication-Header sendet der Browser automatisch mit. Danach kann der Angreifer, von der Firewall ungestört, das lokale Netz angreifen.

Statt der Firewall-Regeln könnte so auch z.B. die Verschlüsselung und Authentifizierung eines WLAN-Access-Points ausgeschaltet werden, wenn dessen Weboberfläche eine entsprechende Schwachstelle enthält. Das Bemerkenswerte daran: Der Angreifer kann Anwendungen angreifen, die hinter einer Firewall vor ihm verborgen sind. Nur das Opfer muss Zugriff auf die Anwendungen haben.

Und nun zum IoT...

Alle vorgestellten Beispiele waren allgemeine Beispiele für Webanwendungen. Aber sie zeigen, was mit CSRF möglich ist.

Sie müssen sich dabei immer nur vor Augen halten, dass diese Angriffe nur dann möglich (und nötig) sind, wenn die angegriffenen Funktionen nur von authentifizierten (und ggf. autorisierten) Benutzern genutzt werden können. Und es dem Angreifer dann (eine CSRF-Schwachstelle vorausgesetzt) erlauben, diese Funktionen in seinem Sinne zu missbrauchen.

Das ist schon übel, wenn z.B. "nur" ein normaler Benutzer in einem Forum oder Social Network durch einen CSRF-Angriff bösartige Kommentare in seinem Namen veröffentlicht. Und wird äußerst gefährlich, wenn einem Administrator dadurch die Kontrolle über seine Webanwendung entrissen wird.

Und nun betrachten wir mal die Weboberflächen der IoT-Geräte: Die können i.A. nur von angemeldeten Benutzern genutzt werden, und diese Benutzer sind i.A. die Administratoren der Geräte.

Die Weboberflächen geben den angemeldeten Benutzern i.A. die vollständige Kontrolle über das betreffende Gerät. Sie können es nach belieben Konfigurieren. Was ja i.A. auch durchaus so gewünscht ist. Nur: Gibt es in der Weboberfläche CSRF-Schwachstellen, können die betroffenen Funktionen auch über CSRF von einem Angreifer genutzt werden. Was i.A. ganz und gar nicht gewünscht wird.

Die Auswirkungen hängen dabei natürlich von der Art des Geräts und der von der CSRF-Schwachstelle betroffenen Funktion ab. Aber stellen Sie sich mal vor, ein Angreifer macht sich an Ihrer Heizungssteuerung zu schaffen. Oder Ihrer Beleuchtung. Oder Ihrem NAS mit all den darauf gespeicherten privaten Daten. Oder was auch immer. Das dürfte Ihnen in den allerwenigsten Fällen egal sein.

In der nächsten Folge werde ich beschreiben, wie die CSRF-Angriffe in den Browser des Benutzers eingeschleust werden können, und wie die Entwickler die Weboberflächen vor CSRF-Angriffen schützen können. Und was die Benutzer des IoT-Geräte tun können, um das Risiko eines Angriffs zu minimieren.

Ich wünsche Ihnen alles einen guten Rutsch ins Neues Jahr
und ein gesundes und erfolgreiches 2017!

Carsten Eilers