Wireshark Netzwerkverkehr

Wie kann man ein Portal überwachen?

[vgwort line=“24″ server=“vg05″ openid=“3535f72334224f089deecc74630bec9c“]

Ansicht der RedTube Seite mit aktiven NoScript Plugin
Ansicht der RedTube Seite mit aktiven NoScript Plugin

Im Falle der jetzigen Abmahnwelle und der angekündigten weiteren Abmahnungen stellt sich die Frage, wie kann der Abmahnende im Falle des Download oder Streaming eines Videos von einem Web-Server an die IP-Adressen der Nutzer, die sich die Videos ansehen, gelangen, wenn der Betreiber des Portals diese nicht bereitstellt. (Dazu, dass es keinen grundsätzlichen Unterschied zwischen Streaming und Download gibt, komme ich später.)

Gegenüber RA Christian Solmecke deutete RA Thomas Urmann an, dass Redtube nicht die einzige Plattform ist, die überwacht werden kann.[ref] Quelle: wbs-law.de[/ref]

Die Formulierung, dass die Portale „überwacht“ werden können, finde ich sehr interessant. Dies würde bedeuten, dass jemand alle oder zumindest sehr viele Zugriffe (zum Beispiel alle Zugriffe aus Deutschland) auf das Portal beobachtet und prüft.

An einem Video-Download oder -Streaming von einem Web-Server zu einem Web-Client sind nur diese beiden und die Router oder Proxy-Server auf dem Weg zwischen den beiden Rechnern beteiligt. Für eine Überwachung müsste sich der Überwacher, als Dritter im Bunde, in diese Verbindung einhängen. Dies geht nur an wenigen Stellen.

Eine derartige Überwachung könnte an folgenden Orten stattfinden:

  1. Auf den Servern von RedTube
  2. Auf einem Router zwischen Nutzer und den RedTube Servern
  3. Auf einem Proxy-Server zwischen Nutzer und den RedTube Servern
  4. Auf dem Rechner des Nutzers
  5. Im Video durch eingebetteten Code
  6. In der RedTube Seite durch eingebettete Objekte (Werbung)
  7. Durch umgeleitete Zugriffe / Routen

Jede dieser Möglichkeiten wollen wir nun untersuchen.

Kurzer Vorgriff

Betroffene berichten, dass sie von einer Seite namens trafficholder.com – einem Klick-Händler überwiegend für Adult Content (Porno) – über die Seiten movfile.net und retdube.net (einer Tippfehler-Domain) nach redtube.com[ref]Es ist möglich, dass die Weiterleitung bereits bei retdube.net endete. Siehe Kommentare.[/ref] umgeleitet wurden. Folgende Einträge fanden Betroffene in ihrer Chronik [ref]Siehe Kommentar bei Golem.de: Wie kommen die an die Daten …[/ref] bevor sie zur Seite mit dem Video „Amanda’s Secrets“ gelenkt wurden.[ref]Auf RedTube ist das Video mit Watch Kendra’s stepdad takes care of her überschrieben. Wie stellt ein Abgemahnter bei der Überschrift des Videos eine Verbindung zu „Amanda’s Secrects“ her und erkennt die Illegalität des Download? Da dürfe so mancher mit gutem Gewissen versichern, dass er dieses Video nie gesehen hat.[/ref]:

http://hit.trafficholder.com/transfer.php?http://49655.movfile.net
http://49655.movfile.net/
http://49655.retdube.net/

Dabei ist 49655 die ID (Nummer) des abgemahnten Videos auf RedTube. Die Umleitungen sind (leider) nicht mehr aktiv. Zeitgleich mit dem Beginn der Überwachung erhöhten sich die täglichen Zugriffe auf die überwachten Videos.

Frage: Wer hat genau in diesem Moment Interesse daran, die Zugriffe auf die Videos zu erhöhen? Sollte diese Umleitung von den Überwachern über bei TrafficHolder gekaufte Zugriffe (Kosten ca. 3€ pro 1.000) generiert worden sein, hätten sie die Urheberrechtsverstöße erst möglich gemacht und aktiv unterstützt / ausgelöst. Ohne die Umleitung hätte es den Verstoß[ref]Wenn es überhaupt ein Verstoß gegen die Rechte von The Archive AG war. Diese Frage spielt hier jedoch ein untergeordnete Rolle.[/ref] nicht gegeben. Doch dazu später mehr. Betrachten wir zuerst die möglichen Orte der Überwachung.

Auf den Servern von RedTube

Nun die beste und genaueste Methode wäre, die Server selbst zu überwachen. Die Web-Seiten des Portals RedTube (www.redtube.com) liegen nicht nur auf einem Server; außerdem liegen die Videos auf anderen Servern als die Web-Seiten von www.redtube.com.[ref]Bei der Zahl der Zugriffe wird RedTube nicht nur ein oder zwei Rechner betreiben, sondern ein Load-Balancing über viele Server betreiben.[/ref] Diese kann mit legalen Mittel nur der Besitzer überwachen, es sei denn er macht seine Log-Files versehentlich öffentlich.

Gegen diese These spricht, dass RedTube versichert, keine IP-Adressen oder sonstige Daten an The-Archive AG oder itGuards Inc. geliefert zu haben. itGuards müsste darüber hinaus mit weiteren – angeblich überwachten – Plattformen zusammenarbeiten.

Es ist sehr unwahrscheinlich, dass die Adult Content Provider ihre Kunden durch eine Abmahnwelle vergraulen werden. TrafficJunky, TrafficHolder, AddThis und Co. dürften zu ihrem Leidwesen in den letzten Tagen in manche Blacklist eingetragen worden sein. [ref]Natürlich mahnen die Studios zu Recht File-Sharing über Torrents ab. Aber hier geht es um ein Seite, auf der die Studios Trailer und längere Szenen als Appetithappen einstellen.[/ref]

Das zufällige Nutzer von TrafficHolder auf die Videos gelenkt werden, erhöht die Ausbeute, wirkt sich aber auf die Überwachung technisch nicht aus.

Auf einem Router zwischen Nutzer und den RedTube Server

Das Überwachen könnte auf einem Router stattfinden. In diesem Fall müssten alle IP-Pakete ausgewertet werden, die den Router passieren. Dieses Szenario ist wenig wahrscheinlich, da es die Zusammenarbeit von itGuards mit den Rechenzentrumsbetreibern oder einem Carrier bedeuten würde. Damit nicht der gesamte Datenstrom ausgeleitet werden muss, müsste der Router die Pakete filtern und zum Überwacher ausleiten.

Um dies zu prüfen, habe ich den Netzwerkverkehr während des Abspielens eines Videos mitgeschnitten (siehe Bild 2). Wichtig sind dafür die Pakete, die an den Server mit dem Video gehen und die einen HTTP Request mit „GET /_videos_…flv?hash=…=&start=0 HTTP/1.1\r\n“ enthalten. Da angeblich auch andere Portale überwacht werden können, müsste es mehrere Router oder einen sehr zentralen Router geben.

Network Protocol with wiresharkonitoring WirShark RedTube
Bild 2: Mit WireShark aufgezeichneter Start eines Video-Streaming.

Nach dem obligatorischen TCP 3-way-hand-shake wurde der Server mit dem HTTP GET-Befehl nach dem Video gefragt. Ob und wie weit der Server das Video ausgeliefert hat, zeigen erst die weiteren TCP Pakete. Starten und Stoppen des Video kann nicht beobachtet werden, da darüber keine Information an den Server gesendet wird. Nach der Abfrage sendet der Server den Film von Anfang bis Ende zum Client. Aufgrund des TCP-Protokoll gibt es auch keine Lücken. Bei einer langsamen Verbindung ruckelt das Video. Bei einer schnellen Verbindung füllt sich der Puffer schneller als das Video abgespielt werden kann. Nur wenn der Nutzer über den schon geladenen Teil hinaus vorspult, schickt der Client ein Folgepaket an den Server mit der Bitte, Teile des Videos zu überspringen. Solange die Seite im Browser geöffnet bleibt, wird – vorausgesetzt der Speicher reicht – der gesamte Film heruntergeladen. Einige Nutzer scheinen hier HTTP-Streaming[ref]Siehe WikiPedia: HTTP-Streaming[/ref] mit einen Video-Broadcast zu verwechseln. Dies findet bei RedTube nicht statt.

Ohne die Einwilligung / Mitwirkung der Besitzer wäre ein legaler Zugriff nicht möglich. In diesem Fall hätten die Zugriffe durch Verwerfen der IP-Pakete unterbunden und der Lizenzverstoß verhindert werden können. Auch hier hätte der Überwacher den Verstoß geduldet und durch Weiterleiten des Verkehrs unterstützt / erst möglich gemacht.

Auch hier spielen die erhöhten Abrufe der Videos für die Überwachung technisch keine Rolle; sie erhöhen aber die Zahl der angeblichen Gucker.

Auf einem Proxy-Server zwischen Nutzer und den RedTube Servern

Schaltet man einen Proxy-Server (z.B. squid) dazwischen oder vor die Server von RedTube, gilt im Grund das gleiche wie für einen Router. Allerdings lässt sich das Log-File des Proxy leichter auszuwerten, als die IP-Pakete eines Routers. Wiederum hätte der Überwacher den Verstoß geduldet und durch das Umsetzen des Verkehrs unterstützt.

Ein solcher Proxy-Server müsste extrem leistungsfähig sein, um den gesamten Traffic zu den RedTube Servern zu bewältigen. Selbst wenn nur ein Teil der Server überwacht wird, traue ich die Finanzierung und Platzierung der notwendigen Infrastruktur der Firma The Archive AG oder itGuards nicht zu. Das Kapital von The Archive AG beträgt nur 100.000 CHF und ein Teil dürfte für den Rechteerwerb verwendet worden sein. (Wer gegen The Archive AG klagen will, muss damit rechnen, dass die Firma in Konkurs geht und er höchstens die Auswerterechte an ein paar wertlosen Pornos bekommt.)

Im Proxy sollte sich z.B. ein ähnlicher Eintrag wie der Folgende finden:

9999999999.99 5888 192.168.2.186 TCP_MISS/200 823802 GET http://vid.lsw.redtubefiles.com/_videos_t4 … / … /_h264flv/ … .flv? – DIRECT/185.28.68.5 video/x-flv

Auch hier spielen die erhöhten Abrufe der Videos über die Umleitung technisch keine Rolle; sie erhöhen aber die Zahl der Abmahnbaren.

Auf dem Rechner des Nutzers

Dazu hätte eine Monitoring Software auf sehr vielen Rechner installiert werden müssen. Quasi ein „Bundestrojaner“ für itGuards. Der Code könnte natürlich auch in einem beliebten und weit verbreiteten Browser-Plugin versteckt sein, das bei Laden eines überwachten Videos nach Hause telefoniert und die IP-Adresse meldet. Dazu müsste die Firma itGuards entsprechende Beziehungen zu den Programmieren haben. Es ist nicht 100% auszuschließen, dass sich ein Programmierer damit ein Zubrot verdient. Wie beweiskräftig ein solcher Ansatz wäre, müssen andere beurteilen. Legal wäre dieses Vorgehen sicher nicht. Die Beweisbarkeit des Downloads wäre aber nicht gegeben. Der Trojaner könnte alles mögliche melden oder selbst angestoßen haben. Die ordnungsgemäße Installation und Prüfung der Funktion wäre schwierig. Dieses Verhalten wäre leicht zu entdecken und müsste noch heute beobachtbar sein.

Dass eine Sicherheitslücke im FlashPlayer ausgenutzt wurde, ist eher unwahrscheinlich. Die Rechner müssten sich irgendwie beim Überwacher melden, dazu müsste sich der Überwacher aber erst beim Client melden und einen Trojaner installieren. Bei mehreren Zehntausend Betroffenen ist dieses Szenario sehr unwahrscheinlich, da sich eine größere Zahl Abgemahnter melden müsste, die entsprechende Auffälligkeiten auf ihrem Rechner beobachtet haben.

Wozu der Aufwand mit dem gekauften Traffic? Über den Trojaner könnte ich den Nutzer ohne sein Zutun auf die Seiten lenken.

Im Video durch eingebetteten Code

Wenn das Video-Format die Einbindung von Makros erlaubt, könnte es nach Hause telefonieren und berichten wo es abgespielt wird.

Dagegen spricht, dass die Videos zum Teil zwei Jahre vorher auf RedTube geladen wurden. Der Vorbesitzer der Videos müsste den Code eingebaut haben, bevor jemand sie illegal auf RedTube hoch geladen hat. Nur: Warum hat er diese Fähigkeit nicht selbst für Abmahnungen genutzt? Die Videodatei müsste nicht aus dem Download-Portal von RedTube stammen. Diesen Code könnte man über einen Netzwerkmonitor nachweisen, denn die RedTube Videos müssten noch heute dieses Verhalten an den Tag legen. Ich habe nichts dergleichen beobachtet.

In der RedTube Seite durch eingebettete Objekte (Werbung)

Dazu müsste itGuards gezielt Werbung auf den Seiten geschaltet haben, die als Objekt (Bild, JavaScript, CSS …) in die Seite eingebunden wurde. Dazu müsste itGuards Zugriff auf Statistiken oder Log-Files mit IP-Adressen des Anbieters haben. Oder die Objekte über einen eigenen Server bereitstellen.

Soweit die Werbung nicht durch Werbe-Blocker gefiltert wird, käme itGuards an die IP-Adressen derjenigen, die eine HTML-Seite aufgerufen haben. Diese Abrufe würden aber maximal beweisen, dass die Seite und die eingebetteten Objekte (außer das Video) geladen wurden. Nicht bewiesen ist damit, dass das Video heruntergeladen wurde. Dieses Video könnte durch einen FlashBlocker unterdrückt worden sein. Wenn ein Werbebild geladen wird, muss nicht auch das Video angesehen werden und umgekehrt. Siehe NoScript.

Um zu klären, wie ein Portal / ein Video auf dem Portal auf diese Weise überwacht werden kann, schauen wir uns zuerst den Quelltext einer RedTube Seite mit einem Video an.

Exkurs: Wie ist eine RedTube Seite aufgebaut?

Jedes RedTube Video hat eine ID, eine Nummer von 1 bis unendlich. Um ein Video anzuschauen, muss man nur die Seite http://www.redtube.com/<Nummer> aufrufen. In der Regel startet das Video automatisch. Es sei denn, im Browser ist das automatische Starten des Videos durch einen Parameter, das NoScript-Plugin oder einen Flash-Blocker verhindert.

Wichtigsten eingebettetes Objekt ist das Video selbst. Schauen wir uns den für die Darstellung des Videos wesentlichen Teil einer HTML-Seite bei RedTube an. Die Videos werden z.B. über ein video-Tag und ein source-Tag in die Seite eingebunden. Dieser Teil wird durch ein Script an verschiedene Situationen / Browser angepasst und kann variieren.

<video x-webkit-airplay=“allow“ id=’html5_video‘ width=“610″ height=“447.33333333333″ style=“margin-top:21.333333333333px;“ autobuffer controls onerror=“cantPlayVideo()“ preload=“auto“>
<source src=“http://videos.mp4.redtubefiles.com/_videos_…“ type=“video/mp4″>

Wie man sieht ist das Video (URL src= gekürzt) nicht in der Seite enthalten. Das Video ist eine eigenständige Datei im mp4-Format, die auf einem einfachen File-Server liegt. Sie lässt sich mit wget – wie jede andere Datei – herunterladen, auf der Festplatte speichern und anschließend mit einem Player anschauen. Beispiel:

wget -O video.pmp4 http://videos.mp4.redtubefiles.com/_videos_…

Um das Video im Browser anzuzeigen, muss der Browser sich an den Server videos.mp4.redtubefiles.com wenden. Nur wer eine Anfrage an und die Antworten von diesem Server abfangen oder auswerten kann, kann zweifelsfrei beweisen, dass das Video teilweise oder vollständig heruntergeladen wurde. Ein Zugriff auf http://www.redtube.com/<Nummer> beweist nichts. Dort liegt kein Video. Dies ist nur die Datei, die das Video im Browser darstellbar macht und für den Rahmen sorgt.

Die Abgemahnten müssen das Video also nicht gesehen haben. Sie könnten es mit wget oder einem Download-Tool auch vollständig herunterladen. itGuards behauptet, dass es das Streaming eines Videos im Player überwachen kann.

Eine weitere interessante Zeile ist die folgende:

<script type=“text/javascript“ src=“http://s7.addthis.com/js/250/addthis_widget.js?pub=rtvideo“>

Dies ist ein Link, der nicht auf einen RedTube Server verweist. AddThis fügt der Seite ein JavaScript hinzu, das ein Overlay mit Social-Media Buttons und ähnlichem über die Seite legt. Über dieses Overlay könnte man die Mausbewegung abfangen und das Stoppen und Starten des Videos überwachen. Wenn der Browser den JavaScript-Code von AddThis lädt, dann verfügt auch AddThis über die IP-Adresse des Clients. Wer über entsprechende Reports von AddThis verfügt, kann über den Referrer im Seitenabruf feststellen, welche RedTube Seite angerufen wurde. Dies beweist allerdings nur, dass Script abgerufen wurde.[ref]Zum Beispiel habe ich die RedTube Seite und das JavaScript mit wget auf der Kommandozeile (Textmodus) abgerufen. Alle anderen Objekte wurden nicht mit abgerufen.[/ref]

Außer auf RedTube Server gibt es noch Verweise auf folgende Domains:

  • trafficjunky.net
  • feedburner.com
  • brazzersmobile.com
  • google-analytics.com

Wenn von diesen Server Dateien geladen werden, dann landet natürlich die IP-Adresse des Clients dort. In dessen Log-File müssten sich in etwa folgende Einträge finden:

192.168.0.1 – – [19/Dec/2013:21:20:03 +0100] „GET /… HTTP/1.1“ 200 99999 „http://redtube.com/123456“ „Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0“

Hier findet sich der Hinweis auf das betrachtete Video in dem fett markierten Hinweis auf den Referrer.

Ich habe das AddThis Script nicht näher untersucht, da es obfuskiert ist. Es könnte – wie andere Scripte auch – noch weitere externe Links und Quellen nachladen. Da es von AddThis speziell für RedTube erzeugt wird, bezweifle ich, dass itGuards dieses Script so verändern kann, dass es die Zugriffe auf Videos melden kann.

Interessant ist auch der Link auf TrafficJunky. Dies ist wie TrafficHolder ein Klick-Händler. Der Link befindet sich in folgendem iframe-Tag

<iframe
id=“zone_11781_site_16_41018600″
name=“zone_11781_site_16_41018600″
src=“http://ads.trafficjunky.net/ads?zone_id=11781&site_id=16__
&c=Couple%2B…
&cache=….“
width=“610″ height=“60″
scrolling=“no“ frameborder=“0″
allowtransparency=“true“
marginwidth=“0″
marginheight=“0″>
</iframe>

Über diesen iframe erhält TrafficJunky bestimmte Informationen (z.B. die Stichworte mit &anp;c= zum Video). Die ID des Videos scheint jedoch nicht in dem Aufruf kodiert zu sein, könnte sich aber aus dem Referrer ergeben.

Aber …

… wer darüber den Abruf der Videos beweisen will, muss dazu auf die Log-Files der Server zugreifen oder die Scripte so manipulieren, dass sie die Aktionen im Browser abfangen und zusätzlich „nach Hause“ zum Server des Überwachers telefonieren. Dies ist sehr kompliziert und ohne die Mitwirkung der Besitzer der Server oder Provider der Dienste kaum umsetzbar. Legal sicher nicht.

In diesen Log-Files der Server steht nur der Eintrag für den Download des JavaScript-Code. Ein eigener AddThis Account reicht für den Zugriff auf irgendwelche Statistiken nicht, weil der Code mit pub=rtvideo an RedTube gebunden ist.

Wer zu einem bestimmten Video bestimmte externe Inhalte generieren will, muss sich mit AddThis, TrafficJunky etc und / oder RedTube in Verbindung setzen. Eine in der Eidesstattlichen Versicherung behauptete Protokollierungsgenauigkeit im Nanosekundenbereich ist über diese Log-Files nicht zu erreichen. Eine Genauigkeit im Sekundenbereich wäre schon gut.

Fazit:

Durch das Einbetten von weit gestreuten Objekten ist es schon beachtlich, wo sich überall Spuren des Nutzers finden, wenn er eine Seite von RedTube öffnet.

Selbst wenn es möglich wäre, über diese Werbeeinblendungen die IP-Adressen zu sammeln, die die Video-Seite http://redtube.com/49655 geöffnet haben, dann wäre nicht bewiesen, dass auch das Video gesehen oder nur geladen wurde. Nicht ohne Grund verwenden Leute NoScript oder einen anderen FlashBlocker. Sie wollen keine Videos; nicht nur keine Pornos.

Durch umgeleitete Zugriffe

Man könnte Zugriffe von anderen, eigenen Seiten auf die RedTube Seiten um- oder weiterleiten. TrafficHolder vermittelt Zugriffe zwischen Verkäufern und Käufern. Dazu werden Klicks von Seiten der Verkäufer über die Server von TrafficHolder auf beliebige Web-Seiten der Käufer umgeleitet. Beispiel? Auf dieser Seite blende ich einen interessanten Link ein. Sie klicken drauf und landen auf RedTube. Für diesen Klick zahlt jemand 0,003 € an TrafficHolder und TrafficHolder zahlt mir etwa 0,001€. 1.000 Zugriffe Adult-Traffic kosten nur etwa 3€. D.h um sich 100.000 Abmahnopfer zu besorgen, muss ein Überwacher mit krimineller Energie im optimalen Fall nur 300€ zahlen. Manche werden zwei oder dreimal auf die Videos gelenkt worden sei. Da kann man sich überlegen, ob man nicht gleich mehrfach abmahnt.

Wie es aussieht hat jemand die Domains retdube.net (IP 192.31.186.27) und movfile.net (IP 192.31.186.117) kurz am 21. und 22. Juli 2013 in Panama über die WHOISGUARD Inc registriert. Die Server, auf die die DNS Einträge im Moment zeigen, stehen bei Black Lotus Communications. Auf diesen Server sind sehr viele Domains zu Hause. Ob die beiden fraglichen Domains während der Umleitung auf diese Server zeigten, kann ich nicht sagen. Aber diese Server sind auf Umleitungen spezialisiert.

Eigentlich würde ein Server und eine Weiterleitung reichen, aber vielleicht sollte TrafficHolder nicht mit der Nase darauf gestoßen werden, dass das eigentliche Ziel RedTube war. Es kann nicht schaden, die Spuren etwas zu verwischen. Die Einrichtung der Umleitung ist ein Kinderspiel. Wenn man nun Zugriff auf die Log-Files der Server hat, kann man die Weiterleitung der Klicks auf die Seiten bei RedTube mitschneiden. Mehr aber auch nicht. Möglicherweise schickt einer der Server eine Meldung (mir fällt da spontan syslog ein, MySQL oder einfach HTTP) an einen Überwachungsserver mit der sagenhaften GLADII 1.1.3. Software. Oder die Log-Files werden per FTP bereitgestellt. Die Software lässt sich mit einem guten Entwicklertool leicht zusammen bauen.

Für einen Test muss das Netz so konfiguriert werden, dass der Prüfer nicht merkt, dass nicht auf redtube.com zugegriffen wird, sondern auf movfile.net oder retdube.net. Ich kann natürlich auch einen transparenten Proxy dazwischen schalten und für den Test zusätzlich auf diesen statt auf retdube.net zugreifen. Wenn die Quelle des IP-Adressen nicht benannt wird, dann gibt es genügend Stellen für eine Manipulation.

Eine Firma Itguards Inc. wurde am 21.3.2013 im US Bundesstaat Delaware registriert. Einen Tag später wurde gemäß einer Eidesstattlichen Versicherung die Funktionsfähigkeit und Richtigkeit der Erfassung durch die Software GLADII 1.1.3 von der Kanzlei Diehl & Partner bestätigt. Saubere Leistung. Gerade gegründet und schon innerhalb von weniger als 48 Stunden eine Software entwickelt, internationale Geschäftsbeziehungen aufgebaut und die Software testen lassen. Da war aber jemand von der ganz schnellen Truppe.

Dies wäre die einfachste Überwachungsmethode. Juristen, denen nur die Oberfläche gezeigt wird, bestätigen nur die Funktionalität. Video heruntergeladen, Eintrag korrekt. Wurde geprüft, was angezeigt wird, wenn der FlashPlayer durch einen Blocker blockiert wurde? Vielleicht diente retdube.net gezielt dem Test. Was die Software anzeigt, wenn ein Video nicht heruntergeladen worden ist, wird nicht geprüft – neben vielen anderen Zugriffen. Es gibt ausreichend Manipulationsmöglichkeiten im Router, die dem Prüfer verborgen bleiben.

Fazit:

Außer dieser letzten Möglichkeit fallen alle anderen Möglichkeiten an die IP-Adressen zu kommen aus. Die verbleibende, plausible Erklärung für die Herkunft der IP-Adressen sind derzeit gekaufte Zugriffe, die über Server im Zugriff von itGuards und ihrer Software GLADII 1.1.3 geleitet wurden.

Da die Überwachungen teilweise schon Monate zurück liegen, und nur wenige die Historie des Browsers verstehen und lesen können oder einen eigenen Zwangsproxy betreiben und noch Logs aus der Zeit der Überwachung haben, ist es glücklich zu nennen, dass jemand die Weiterleitungen entdeckt hat. Hätte man sich mit deutlich weniger Opfer zufrieden gegeben, wäre vielleicht nichts aufgefallen.

Ein abschließendes Wort zur Eidesstattlichen Versicherung

Es ist gut möglich, dass die Eidesstattliche Versicherung (EV) richtig ist. Sicher die Genauigkeit im Bereich Nanosekunden ist unsinnig. Vielleicht ist der arme Kerl nur ein für ein paar Euro angeheuerter Bediener, dem die Funktionsweise der Software nicht klar ist. Er hat nur beschrieben, was ihm die Entwickler und das Gutachten sagen. Abgesehen davon, dass das Vorgehen dürftig und nicht nachvollziehbar beschrieben ist, sowie ohne eine Angabe der Funktionsweise und Quelle der IP-Adressen von Dritten nicht prüfbar ist, ist in der EV nichts wahrheitswidrig. Insofern gleicht er einem Polizeibeamten bei der Radarkontrolle.

Das Problem ist, dass das Gericht sich mit diesem Quatsch zufrieden gegeben hat.

Update 17.01.2014: Korrektur von Schreibfehlern.

33 Kommentare

  1. Sollte ein Filmaufruf auf retdube.net beim Flashplayer des Users die Funtion „peer assisted networking“ (P2P-Upload) angefragt haben, so müssten die Abmahnopfer in einem Popup-Fenster des Flashplayers eigentlich auf „Aktivieren“ geklickt haben, damit ihre Filmschnipsel samt IP-Adressen auf einem PC eintreffen, auf dem ein paar Sekunden später dasselbe Video aufgerufen wird.

    Quellen:

    http://www.wbs-law.de/abmahnung-filesharing/abmahnkanzleien/abmahnung-u-c-rechtsanwaelte/thomas-urmann-diese-abmahnwelle-war-erst-der-anfang-49126/#comment-124077

    http://m.heise.de/newsticker/foren/S-Wofuer-die-Buchstabendreher-Domain-wirklich-da-war/forum-271818/msg-24544228/read/

    „Und auch für den plötzlichen Anstieg der Zugriffzahlen auf die ansonsten kaum abgerufenen Redtube-Porons hat Hausner eine krude Erklärung parat: „Wegen dem Einsatz einer Monitoring-Software zur Feststellung der Verfügbarkeit von den Medien-Dateien kann es zu einem Anstieg der Views auf den Portalseiten kommen.““
    Quelle:
    http://www.heise.de/newsticker/meldung/Abmahnungen-wegen-Porno-Streaming-Rechteinhaber-aeussert-sich-zur-IP-Adress-Ermittlung-2071762.html?wt_mc=rss.ho.beitrag.atom

    http://www.golem.de/1006/75716-2.html

    http://www.macromedia.com/support/documentation/de/flashplayer/help/settings_manager09.html

  2. Eventuell gibt es doch eine Möglichkeit anhand von Werbung das Stoppen, Starten und Beenden eines Streams auszuwerten: Im von LG Köln veröffentlichten Teil des Gutachtens bzgl Gladii werden als Beispiele für überwachte Videoportale drei Portale genannt, die Exoclick als Werbeanbieter nutzen (xhamster, drtuber und tnaflix).

    Exoclick bietet laut Homepage die Einblendung von Werbung in Flash-Playern an, die angezeigt wird a) bevor der Film abgespielt wird, b) nachdem der Film abgespielt wird oder c) während der Film pausiert wird. Auf den genannten Seiten sind die Möglichkeiten b) und c) gebucht.

    Wie das technisch funktioniert (API des Player-Anbieters oder überlagertes AddThis scrip) müsste man sich mal ansehen.

    redtube nutzt allerdings den Werbeanbieter exoclick (derzeit?) nicht.

    Trotzdem finde ich das Puzzelstück „Alle Beispiel-Portale aus dem Gutachten nutzen ein Werbenetzwerk mit einem solchen Angebot“ interessant.

  3. Hallo Thomas,
    Du verwendest auffällig oft das Wörtchen Refferer … was aber sicherlich Referrer heißen sollte. Oder?
    🙂
    Stephan

    1. Hallo Markus, laut similarweb leitet retdube.net nach redtube.com weiter. Dein vermutetes Vorgehen wäre sehr viel komplizierter. Da sich die Views der Seiten htttp://redtube.com/49655 etc signifikant erhöht haben, ist davon auszugehen, das der Traffic bis zu diesen Seiten weitergeleitet wurde. Der Film erhöht nicht den View Counter. Der wird direkt von dem serverseitigem Script erhöht, in dem dasVideo eingebettet ist.

  4. Du hast das Rätsel fast gelöst, aber nur fast. Beachte die Sequenz

    http://hit.trafficholder.com/transfer.php?http://49655.movfile.net
    http://49655.movfile.net/
    http://49655.retdube.net/

    redtube.com kommt darin nicht vor. Folglich scheidet die Möglichkeit „Durch umgeleitete Zugriffe“ aus.

    Geschehen ist hingegen aller Wahrscheinlichkeit nach folgendes: Auf http://49655.retdube.net/ wurde das Video eingebettet, genauso wie auf der originalen Seite zu dem Video auf redtube.com. Dabei besteht natürlich volle Kontrolle darüber, welche Skripte geladen werden, und über Javascript kann dann das Abspielen des Streams zurückgemeldet werden (was übrigens bei redtube ohne Zutun des Besuchers geschieht).

    Da Betroffene übereinstimmend berichten, dass sie redtube nicht kennen, teils zum fraglichen Zeitpunkt auch gar nicht zuhause waren, kann man die Vorgehensweise folgendermaßen zusammenfassen:

    1. Über bei trafficholder gebuchten Skimmed Traffic, der wohl automatisch über zyklisch ausgetauschte Werbung aktiviert wurde, fand eine Weiterleitung nach retdube.net über movfile.net statt. Dabei wird aber noch nicht die IP gespeichert, weil es nicht beweist, dass auch ein Video abgespielt wurde

    2. Auf retdube.net wurde das Video eingebettet und ein javascript geladen

    3. Das Javascript überwacht den Start des Streams (der ohne noscript automatisch erfolgt) und meldet das zurück an GLADII bei den Ermittlern (z.B. mittels AJAX).

    1. Hallo Gast,

      ich bin nicht betroffen, sonst könnte ich mit Hinweisen aus meinem Proxy Server dienen. Mir war bei der Quelle nicht klar, ob der Aufruf von redtube.com nur weggelassen wurde. Es stand dort etwas von vorherige Aufrufe. Leider hat wohl keiner mehr die Original Antworten der Umleitungen. Die würden einiges klären.

      Zu Deinem Punkt 2. Wenn es so wäre, dann hätte sich der View Counter bei RedTube nicht erhöht. Es ist daher davon auszugehen, dass nicht der Film alleine in eine Retdube.net Seite eingebunden wurde, sondern die Seiten http://redtube.com/49655 etc eingebunden wurden oder auf diese weitergeleitet wurde.

      Frohe Weihnachten

      1. „Wenn es so wäre, dann hätte sich der View Counter bei RedTube nicht erhöht“ Ist das wirklich so? Hast Du das ausprobiert?

        1. Ja, ich habe es ausprobiert. Leider haeb ich den Source-Code der RedTube Seite nicht. In diesem Fall könnte ich es auch anhand des Codes belegen. So muss ich mich leider auf probieren beschränken. Wenn ich mit wget auchschließlich die Seite und nicht die eingebetteten Seiten abrufe, dann erhöhen sich bereits die Views.

      2. Nachtrag: „Mir war bei der Quelle nicht klar, ob der Aufruf von redtube.com nur weggelassen wurde“ Wurde nicht weggelassen, war nicht vorhanden. Bin selbst auch nicht betroffen, aber es gibt in Blog-Kommentaren explizite Aussagen von Betroffenen, wonach redtube selbst in ihrer Browser-History nicht auftaucht.

      3. Nachtrag 2: Beachte: Bei redtube selbst gibt es unter jedem Video einen Button „Embed Video“. Wenn man den anklickt kriegt man den nötigen Code in einer Box angezeigt. Es wäre doch verwunderlich, wenn die Nutzung einer von redtube selbst bereitgestellten Methode, sich das Video anzuschauen, nicht auch den View-Zähler erhöhen würde.

  5. Hausner: „Wegen dem Einsatz einer Monitoring-Software zur Feststellung der Verfügbarkeit von den Medien-Dateien kann es zu einem Anstieg der Views auf den Portalseiten kommen.“…

    Drei Möglichkeiten:
    1. Die Videos wurden vom retdube/movfile-Proxy aus dem Cache zu den Abgemahnten gestreamt. Gleichzeitig hat man das entspr. Video selbst bei Redtube aufgerufen. Diese „Feststellung der Verfügbarkeit“ (Hausner) hat den Redtube-Zähler jedes Mal um 1 erhöht.

    2. Die Videos wurden bei retdube/movfile im eigenen Player embedded. Beim (manuellen oder automatischen) Start des Players wurde der Redtube-Zähler um 1 erhöht.

    3. Die Redtube-Seiten mit den Videos wurden komplett bei retdube/movfile embedded. Jeder Start des Videos oder Aufruf der Seite hat den Zähler um 1 erhöht.

    GladII: Funktioniert, das Gutachten stimmt auch, aber das Entscheidende wurde nicht untersucht bzw. nicht veröffentlicht – auf welchem Rechner die Software sich befindet (hier der retdube/movfile-Proxyserver). Um dies zu verschweigen hat D.S. im Antrag an das Gericht einen „URL-Hash-Wert“ aufgeführt.

    Fundstück: Ein User namens Urmel schrieb sich am 23.12. bei T.Stadler in Rage, dabei ließ er das hier raus: „Hier war es besser, man kauft einen stinknormalen Proxy und setzt ihn ein(…)“. Im gleichen Thread jemand anderes: „(…)Der Zwischenproxy ist ein juristisch anerkanntes und probates Mittel zur Sicherung der Beweislage.“
    http://www.internet-law.de/2013/12/ist-die-streaming-abmahnwelle-schon-wieder-zu-ende.html

    Mein Fazit: Offenbar wurden die Leute nicht nur über trafficholder angelockt – man hat auch bei der Auslieferung der Videos aktiv mitgewirkt. Die Unterlassungserklärung müsste The Archive erstmal selbst unterschreiben.

    1. Hallo,

      Zu 1. Dies würde die Views bei RedTube mit den Views auf dem retdube Proxy synchroniseren. Könnte also gewesen sein.

      Zu 2. Verstehe ich nicht ganz. Die Seite http://redtube.com/{nummer} müsste auch die diesem Fall aufgerufen werden.

      Zu 3. Dies würde ein erheblichen Aufwand an Cross Site Scripting erfordern.

      Es gibt auch Teile der Videos z.B. „Sexual Rehab – Abbie Cat“, ID 266375, die nicht abgemahnt wurden.

      1. inzwischen hat redtube einen neuen embed button bei den Filmen. Folgender code wird zum einbetten zur Verfügung gestellt (id durch xxxx, redtube in URLs durch redtxxx ersetzt):

        damit ist klar, das der komplette player eingebettet wird und damit natürlich auch der counter incrementiert wird.

        1. Da muss ich Dir widersprechen. Ich habe ein selten gesehenes Video in eine eigene Seite eingebettet, die Seite mehrfach aufgerufen und den Film gestartet und gestoppt. Der View Counter wird dabei nicht erhöht. Er erhöhte sich (erst) um 1, wenn ich die Seite direkt bei RedTube neu geladen habe.

          Ein Einbetten des Videos als Objekt in einer Seite auf retdube.net hätte den View Counter nicht geändert.

      2. ich vermute retdupe hat die seiten selbst „als proxy server“ ausgeliefert. dazu schickt retdupe einen http request mit entsprechenden headern wie sie normal proxy server verwenden (zB X-FORWARDED-FOR) an redtube und bekommt den antwort html-code zurueck geschickt. bei redtube erhoeht sich dadurch der view count.

        retdupe hat nun die moeglichkeit, den http-code beliebig zu veraendern, bevor dieser an den tatsaechlichen user ausgeliefert wird. unter anderem, kann dadurch der auf redtube verwendete flash player ausgetauscht werden und somit selbst getrackt werden, wer was wann angeschaut hat.

        das verfahren waere nix neues.. selbst das beruehmte „squid“ projekt hat module zum herausfiltern von werbung.. es waere ein leichtes, ein entsprechendes modul zu basteln, dass eben bestimmte html-codes mit anderen html-codes ersetzt (siehe http://www.squid-cache.org/Misc/redirectors.html )

  6. Ist Streaming nun erlaubt? Ist es verboten?

    Sollte es zu einem Prozess kommen und Streaming verboten sein, muss man dan befürchten, dass rückwirkend Internetverhalten abgestraft wird? Fällt das Streamen von Original US TV Sendungen (auf der Webseite des Senders) mittels IP- Maskierung auch unter Strafe? Ein Online TV Recorder, der Sendungen als Stream anbietet … ist das dann auch verboten????
    Wie sieht es aus mit einer Webseite, die TV Sendungen sammelt und als Stream anbietet??? Und was ist mit Youtube und hochgeladenen Sendungen dort?

    Bislang dachte ich ansehen ist nicht strafbar herunterladen schon… UND NUN?

    1. Streaming ist erlaubt. File-Sharing ist erlaubt. In Ihrem eigenen Netz, zu Hause, dürfen Sie alles streamen oder sharen, was Sie lustig sind. Vorausgesetzt legal erworben. Eigenes Material dürfen sie weltweit streamen (vorausgesetzt: nicht illegal; z.B. KiPo, dann werden Sie aber kein Problem mit dem Urheberrecht bekommen.).

      Ansehen ist nicht strafbar. Im Internet ist Ansehen nur immer auch mit Kopieren, herunterladen verbunden. Hier gibt einen kleinen Unterschied zum alten, analoge Fernseher. Beim analogen Fernseher wird der Kathodenstrahl der Braunschen Röhre quasi direkt vom Sender gesteuert, mit dem Aufleuchten des Lichtpunktes auf dem Fernseher ist es schon vorbei. Dies hat man bisher nicht als Kopieren angesehen. Hier war es auch keine Frage, dass man Sendungen aufzeichnen durfte. Ausnahme: Piratensender, denn die hatten oft keine Lizenz zum Senden.

      In der digitalen Welt – als DVB, egal ob Satellit, Kabel oder Terrestrisch, ist es aber nicht mehr so einfach.

      Im Internet wird es noch schwieriger, denn dort wird je nach Protokoll noch mehr gepuffert.

  7. Ich möchte noch Details zu der Variante „Im Video durch eingebetteten Code“ ergänzen:
    Es gibt eine einfache Lösung, wie man an die IP-Adresse des Client-Rechners kommen kann: Ein Flash-Video kann Daten von anderen Servern nachladen, während es gestreamt wird.
    Diese Mechanismus ist von Adobe dacht, um Daten erst zum Zeitpunkt des Abspielens eines Videos integrieren zu können. Der Server, auf dem die nachzuladenden Daten liegen, muss nicht der Server sein, auf dem das Video liegt. Somit kann auch ein anderer Server die IP-Adresse des Client-Rechners ermitteln und in eine Log-Datei schreiben, die dann beispielsweise über die GLADII-Software bereitgestellt werden könnte.
    „The server can be in any location available to the Flash movie and does not have to be in the same domain.“ (siehe Adobe-Dokumentation „Cross-domain policy for Flash movies“, http://kb2.adobe.com/cps/142/tn_14213.html)
    Weil es sich dabei um ein offensichtliches Sicherheitsrisiko handelt, muss auf dem Server des Medien-Hosters das Nachladen von Daten erlaubt werden. Dazu dient eine spezielle Datei (Policy File) crossdomain.xml:
    „A policy file is a simple XML file that gives the Flash Player permission to access data from a given domain without displaying a security dialog. When placed on a server, it tells the Flash Player to allow direct access to data on that server, without prompting the user grant access.” (siehe Adobe-Dokumentation „Cross-domain policy for Flash movies“, http://kb2.adobe.com/cps/142/tn_14213.html)
    Die Datei crossdomain.xml muss im Wurzelverzeichnis des Webservers abgelegt sein. Mit dem Tag erlaubt sie beispielweise das Nachladen von Daten beliebiger Server, ohne dass der Benutzer dies bemerken könnte. Der * ist deshalb keine sinnvolle Einstellung. Richtig ist die Begrenzung auf die Domain des Medien-Hosters oder eine seiner Sub-Domains.
    Man kann die Datei crossdomain.xml bei den unter Punkt 5.2 genannten Medien-Hostestern direkt aufrufen. Aktuell (27.01.2014) zeigen Sie folgende Einstellungen:
    Die Datei http://drtuber.com/crossdomain.xml :

    Die Datei http://www.tnaflix.com/crossdomain.xml :

    Die Datei http://www.xvideos.com/crossdomain.xml :

    Man sieht, dass die im Falle von XVideos und TnaFlix die Einstellung so gewählt ist, dass Flash-Videos von beliebigen Servern im Internet Daten nachladen können. Der Zugriff auf die nachzuladenden Server kann protokolliert werden, so dass die IP-Adresse des Client-Rechners, der das gestreamte Video empfängt festgestellt werden kann. Lediglich bei DrTuber ist zum aktuellen Zeitpunkt das Nachladen von Daten auf *.drtuber.com begrenzt. Nutzt man den Service unter http://web.archive.org, so sieht man dass die Konfiguration zuletzt am 30.06.2013 geändert wurde. Vor dem 30.06.2013 sah sie so aus:
    Version der Datei vor dem 30.06.2013 http://web.archive.org/web/20110814163750/http://drtuber.com/crossdomain.xml :

    Auffällig ist, dass RedTube nicht im Gutachten, Abschnitt 5.2 aufgeführt ist, aber von den Abmahnungen betroffen ist. Aktuell sieht die Datei http://www.redtube.com/crossdomain.xml so aus:

    Diese Form hat die Datei (entsprechend der Abgaben von web.archive.org) auch schon seit August 2011, siehe: http://web.archive.org/web/*/http://www.redtube.com/crossdomain.xml .
    Wie kann bei RedTube das Nachladen von Daten dennoch möglich gewesen sein?
    Im Adobe Help Resource Center kann man unter im Abschnitt Learning ActionScript 2.0 in Adobe Flash / Understanding Security / About domains, cross-domain security, and SWF files (http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000466.html) nachlesen, dass der aktuelle Sicherheitsmechanismus (Cross-domain policy) erst mit Version 7 des Flash Players eingeführt wurde. Für Flash Player 5 gibt es dienen Sicherheitsmechanismus nicht:
    „In files published for Flash Player 5 or earlier, there were no restrictions on cross-domain or subdomain access.”
    Für Flash Player 6 basiert der Sicherheitsmechanismus meinem Verständnis nach auf einer Client-Einstellung, die so gut versteckt ist, dass sie vom Endbenutzer kaum hätte sinnvoll genutzt werden können (siehe unten).
    Im Fall von RedTube könnte beispielsweise die Sicherheitslücke einer älteren Flash Player-Version ausgenutzt worden sein.
    Diese Beobachtungen werfen mehrere Fragen auf. Zunächst die Wichtigste: Wie kann man seinen Client dagegen schützen, dass fehlerhafte Server-Einstellungen die eigene Sicherheit gefährden? Antwort: Ich weiß es nicht genau, aber nach „ADOBE® FLASH® PLAYERAdministration Guide for Microsoft® Windows® 8“, S. 10-11 von scheint mir folgende Lösung möglich:
    1. Öffnen Sie auf Ihrem Rechner die Konfigurationsdatei C:\Windows\SysWOW64\Macromed\Flash\mms.cfg mit einem Texteditor.
    2. Fügen Sie in dieser Datei die folgenden Zeilen ein:
    FileDownloadDisable = 1
    FileUploadDisable = 1
    Lesen Sie bitte selbst die unter: https://wwwimages2.adobe.com/content/dam/Adobe/en/devnet/flashplayer/pdfs/flash_player_windows8_admin_guide.pdf . Weitere Empfehlungen zu sicheren Konfigurationseinstellungen in dieser Datei finden Sie hier: https://anonymous-proxy-servers.net/en/help/flash-applets.html , wobei einige Einstellungen zugunsten erhöhter Sicherheit den Komfort der Mediennutzung beeinflussen können.
    Die zweite Frage ist, warum sollten die im Gutachten, Abschnitt 5.2 aufgelisteten drei Videos überhaupt versucht haben, Daten von anderen Server nachzuladen? Man kann natürlich nicht beweisen, dass diese drei Videos Daten von anderen Servern nachladen, weil sie nicht mehr zur Analyse verfügbar sind. Nehmen wir aber im Folgenden einmal an, dass die Videos tatsächlich Daten von einem Server nachgeladen haben. In diesem Fall muss das Video bewusst in einer besonderen Form bereitgestellt worden sein. Es muss nämlich die Daten nicht nur von irgendeinem Server nachgeladen haben, sondern dieser Server muss seine Daten zusätzlich an die GLADII-Software geliefert haben.
    Welcher Raubkopierer kennt den GLADII-Server? Wie könnte ein Raubkopierer, das von ihm im Rahmen seiner Urheberrechtsverletzung bereitgestellte Video zum Nachladen von Daten dieses Servers zu veranlassen? Warum sollte er das überhaupt tun? Ich denke, dass niemand diese Fragen beantworten kann. Sie führen aber zu folgendem Gedanken: Wenn die angeblich aufgrund einer Urheberrechtsverletzung bereitgestellten Videos Daten nachladen, dann wurden sie nicht von einem unwissenden Raubkopierer, sondern einer anderen Person bereitgestellt, die sich der Auswirkungen bewusst war. Hier liegt der Schluss nahe, dass es sich gar nicht um eine Urheberrechtsverletzung handelt. Denn diese Person muss mit der GLADII-Überwachung und den Sicherheitslücken der Serverkonfiguration in allen technischen Details vertraut gewesen sein.

  8. Echt gut gemacht der Artikel! Sehr vorbildlich recherchiert und mit einer produktiven Diskussion honoriert…! So wünscht man sich das. Was allerdings weniger wünschenswert ist, ist das es wirklich möglich ist ganze Portale von Anwälten überwachen zu lassen…..dann gibts es ja bald garkeine Portale mehr!

Kommentare sind geschlossen.