Wir sind uns nicht sicher, ob er kaputt ist.
Unsere Vierbeiner nutzen auch Videochat
Der heutige Eintrag wird vermutlich nur für einen kleinen Teil von euch (und Google) von Interesse sein. Aber Lysanda lag es am Herzen diese Informationen mal irgendwo verständlich festzuhalten, denn Facebook ist echt nicht zu gebrauchen in Sachen Transparenz (“Wie funktioniert das?”), Standards (“Wieso funktioniert das in der Smartphone-App aber nicht am Desktop?!”) und Beständigkeit (“Vorgestern funktionierte das noch so?!”). Speziell letzteres ist ein ständiger Nervfaktor. Jedes Tutorial, das man im Internet findet, ist im Prinzip schon am Tag der Veröffentlichung veraltet. Wir versuchen es heute trotzdem. Dementsprechend schon einmal der Disclaimer: Alles was hier steht ist Stand 8. November 2021.
Ich persönlich habe weiterhin keinen Facebook-Account auch, wenn Meta (was für ein bescheuerter Name) vermutlich trotzdem haufenweise Informationen über mich besitzt und auf irgendeinem Server lagert. Immer in der vagen Hoffnung, dass ich mich doch irgendwann mal anmelde. Aber, wenn man wie Lysanda Dienstleistungen online anbietet kommt man scheinbar nicht darum herum dort eine Präsenz zu haben und zu pflegen. Vom eigenen Profil über die Unternehmensseite bis hin zu spezialisierten Gruppen – der Aufwand ist enorm will man gesehen werden (und was verkaufen). Aber bei angeblich weltweit 2,91 Milliarden monatlich aktiven Nutzern (32 Millionen davon in Deutschland) ist natürlich auch das Potential entsprechend groß.
Facebook-Live-Events
Eine Sache, die der Facebook-Algorithmus zum Verfassungszeitpunkt besonders liebt sind Live-Events. Wie der Name schon sagt: Egal ob am Smartphone oder Rechner, man drückt auf den roten Knopf und schon strahlt man sein Wohnzimmer hinaus in die weite Welt. An dieser Stelle allerdings gleich ein wichtiger Hinweis: Für Facebook-Live-Events gelten die gleichen rechtlichen Bedingungen gemäß Medienstaatsvertrag (MStV) wie, wenn ihr auf YouTube oder Twitch live senden würdet. Und damit ist nicht zwingend nur die sogenannte Rundfunklizenz gemeint.
Die greift erst, wenn ihr innerhalb von sechs Monaten durchschnittlich mehr als 20.000 gleichzeitige Nutzer habt. Eine Marke, die wohl selbst die größten deutschen Streamer (noch) nicht erreichen. Es gibt da aber auch noch ein “oder” mit drin: “eine hohe Bedeutung für die individuelle und öffentliche Meinungsbildung”. In dem Fall braucht man selbst unter 20.000 Nutzern eine Rundfunklizenz. Aber selbst im zulassungsfreien Rundfunk gelten gewisse Regelungen u.a. in Bezug auf die Kennzeichnung/Länge von Werbung. Der entscheidende Faktor ob man als Rundfunk zählt ist vermutlich, ob das eigene Angebot “journalistisch-redaktionell” gestaltet ist. Das einzuschätzen finde ich etwas schwierig, da die Regelung aus meiner Sicht schwammig ist. Relativ eindeutig sind “Let’s Plays” (jemand spielt ein Spiel und kommentiert es live), die als Rundfunk zählen oder Katzen-Webcams, die wiederrum nicht als Rundfunk gelten. Ein guter Einstieg in das Thema ist diese Übersicht der Landesmedienanstalt NRW.
Solo-Streamen
Den Live-Button findet ihr im Grunde überall dort auf Facebook, wo ihr auch einen Beitrag erzeugen könnt. Alleine live zu gehen ist entsprechend einfach. Button gedrückt, festgelegt wo ihr live sein wollt (auf eurer Seite oder in irgendeiner Gruppe, in der ihr Mitglied seid) und schon kann es losgehen. Nachteil ist, dass ihr anders als beispielsweise bei einem spezialisierten Angebot wie Zoom so gut wie keine Einstellungsmöglichkeiten habt. Kamerawechsel z.B. sind während der Live-Übertragung nicht möglich. Und auch die Qualität des Streams lässt sich nur rudimentär regeln. Wenn ihr also etwas mehr Kontrolle wollt, kommt ihr um ein externes Programm wie OBS nicht herum. Da wir beispielsweise Logitech-Webcams nutzen, haben wir Logitech Capture installiert. Nimmt man das als Quelle in Facebook, kann man alles weitere (wie z.B. Kameraeinstellungen) im Programm regeln. Ihr könnt aber auch über Zoom in Facebook (oder YouTube) live gehen. Die Anleitung dazu findet ihr hier. Einzige Einschränkung: Das geht nur auf eurer Seite sowie in Gruppen, in denen ihr Administrator seid.
Der Vorteil “live” zu gehen ist, dass alle eure Freunde bzw. alle Mitglieder einer Gruppe direkt darüber informiert werden. Die Wahrscheinlichkeit, dass es jemand sieht, ist also höher als bei einem normalen Beitrag/einer Story. Außerdem habt ihr die Möglichkeit am Ende eine Aufzeichnung als Story oder Beitrag zu posten und so auch allen zugänglich zu machen, die nicht dabei sein konnten. Die Interaktion mit euren Zuschauern erfolgt in Form von Kommentaren unter dem Beitrag in dem das Live-Event angezeigt wird. Die Kommentare werden euch auch im “Live Producer” (so heißt das Ding auf Facebook) direkt dargestellt – was allerdings nicht immer zuverlässig funktioniert. Ein zweites Browser-Fenster oder ein Smartphone daneben können dabei Abhilfe schaffen. Die zeitliche Verzögerung bis die Inhalte eures Streams dem Zuschauer angezeigt werden ist irgendwo zwischen “fast zeitgleich” bis hin zu “Facebook hat heute einen schlechten Tag” und lässt sich meines Wissens nicht wirklich beeinflussen.
Gruppen-Events
Die Live Producer Ansicht mit den entscheidenden Feldern.
Wollt ihr in einer Gruppe arbeiten, bietet Facebook tatsächlich mehrere Möglichkeiten – je nachdem was ihr vorhabt. Wollt ihr beispielsweise einfach nur einen Videochat mit ein paar Leuten machen, dann stehen dafür die sogenannten “Messenger Rooms” zur Verfügung. Zu so einem Raum könnt ihr entweder eure Freunde einladen oder einen Link generieren. Jeder, der diesen Link hat kann dann reinkommen (je nach Einstellung mit oder ohne zusätzliche Genehmigung durch den Inhaber) – sogar, wenn er/sie kein Facebook nutzt. Mit einem “Messenger Room” kann man jedoch nicht auf einer Seite/in einer Gruppe öffentlich live gehen und es gibt keine Aufzeichnung. Ist also mehr was für den privaten Austausch/die geschlossene Gruppenarbeit.
Wollt ihr hingegen mit mehreren Personen live gehen, dann geht das wieder über den normalen “Live”-Button. Im Live Producer findet ihr dann die Auswahl “Personen einladen”. Drückt ihr auf die drauf, wird ein Messenger Room geöffnet. “Hä?” wird jetzt der ein oder andere verwundert fragen. “Ich dachte, man kann mit einem Raum nicht live gehen?”. Ja, da sind wir wieder bei dem Thema “Standards”… Facebook ist nicht sehr konsequent an vielen Stellen. Aber egal: Ihr landet also in einem Messenger Room und habt die bekannten Möglichkeiten sprich Personen direkt einzuladen oder einen Link zu verschicken.
Der Unterschied zwischen den beiden Räumen ist, dass ihr hier einen “Live gehen”-Button zur Verfügung habt und euch nun erstmal in einem Wartezimmer befindet. Dieses funktioniert ansonsten wie ein normaler Messenger Room. Ihr könnt also warten bis alle Personen da sind und dann gemeinsam in die Öffentlichkeit treten. Kommt jemand zu spät, ist das aber auch technisch kein Problem. Facebook lässt zu, dass nachträglich noch Leute mit in das Gruppen-Live hinzukommen (oder rausgehen). Abhängig von der Einstellung erst nach Bestätigung durch den Rauminhaber oder direkt. Eure Mitstreiter müssen übrigens nicht Mitglied in der Gruppe sein, in der ihr live gehen wollt. Es reicht, wenn der Rauminhaber die Erlaubnis hat dort etwas zu posten.
Zustimmung
“Bestätigung” ist ein gutes Stichwort: Bevor der “Live gehen”-Button aktiv wird, müssen erst alle Teilnehmer der Übertragung zustimmen. Das bedeutet aber nicht automatisch, dass damit auch die Zustimmung zu einer Aufzeichnung erteilt wurde. Um hier rechtlich sicher zu sein, solltet ihr das im Warteraum entsprechend absprechen und direkt nach dem Live gehen noch einmal deutlich sagen, dass alle der Aufzeichnung und Veröffentlichung an Ort X und Y zugestimmt haben bzw. die Gelegenheit geben diese Zustimmung durch Verlassen des Streams noch zurückzuziehen.
Facebook-Einwilligung
Wenn jemand später dazu kommt, dann müsst ihr das auch nochmal klar kommunizieren und ihm die Gelegenheit geben sofort wieder zu gehen. Aber Vorsicht: Die Person ist dann ggf. schon Teil der Aufzeichnung (z.B. weil ihr Video angeschaltet war). Lehnt sie also ab, dürft ihr die Aufzeichnung ohne vorheriges Rausschneiden des Abschnitts nicht veröffentlichen. Praktischerweise könnt ihr es direkt von Facebook herunterladen (die Qualität ist allerdings dürftig…). Da die Aufzeichnung aber automatisch veröffentlicht wird, könnt ihr den dazugehörigen Beitrag nur löschen (und verliert damit alle Kommentare) und dann das saubere Video neu posten. Stellt also am besten sicher, dass einfach alle rechtzeitig für euer Live da sind oder zumindest keiner nachkommt, der dann doch nicht mit Bild/Ton dabei sein möchte. Hier nochmal zum verdeutlichen:
- Die Teilnehmer über das Live-Event und die dazugehörige Aufzeichnung informieren
- Live erstellen
- Link teilen/Personen einladen (ggf. nochmal auf die Aufzeichnungseinwilligung hinweisen)
- Im Warteraum erneut das Thema Aufzeichnung ansprechen und die Zustimmung klären
- Live gehen
- Zu Beginn des Live-Events erwähnen, dass alle der Aufzeichnung zugestimmt haben
Beachtet außerdem: Die Einwilligungserklärung kann gemäß DSGVO jederzeit von jedem einzelnen zurückgezogen werden – mit der Konsequenz, dass ihr das Video löschen/den Teilnehmer anonymisieren müsst. Habt ihr allerdings einen Vertrag mit jemandem geschlossen und dort steht z.B., dass die Aufzeichnung drei Monate in der Gruppe zur Verfügung steht, dann kann er nicht innerhalb dieser drei Monate die Zustimmung zurückziehen – er hat den Vertrag ja unterschrieben und ihr benötigt seine Informationen (in dem Fall sein Part in der Aufzeichnung) zur Vertragserfüllung. Denkt aber daran, dass ihr nach den drei Monaten (= Erfüllung des Vertrages) verpflichtet seid die Aufzeichnung zu löschen. Es sei denn, es liegt von allen in der jeweiligen Aufzeichnung sicht- und hörbaren Teilnehmern eine Einwilligungserklärung vor, die über den Zeitraum hinaus geht. Die kann aber wieder jederzeit zurückgezogen werden – womit wir wieder am Anfang des Absatzes sind 
.
Epilog
Und damit ist erst einmal alles zum Thema “Facebook Live” gesagt, was Lysanda auf dem Herzen lag. Ich hoffe es hilft dem einen oder anderen weiter. Die Welt ist schon kompliziert genug, da muss sich nicht jeder alleine durchwuseln.
Im alten Ägypten währt ihr alle meine Sklaven gewesen!
Meine Schwachstelle, für alle Welt sichtbar!
Samstagmorgen hatte ich eine Mail im Postfach bei der ich zuerst dachte, dass es sich um Spam handelt. Sah ein wenig komisch aus und hatte auch noch einen für mich unbekannten Anhang. Sie stammte angeblich von Open Bug Bounty (eine mir bislang völlig unbekannte Seite) und wies mich darauf hin, dass für www.beimchristoph.de eine Sicherheitslücke gemeldet wurde. Zu allem Überfluss von jemandem, der sich “Cyber_India” nennt. Alles sehr verdächtig.
Nach etwas Recherche stellte sich diese Mail aber tatsächlich als legitim heraus. Die Seite ist echt, der Inhalt ebenfalls. Cyber_India hatte tatsächlich bei mir und >15.000 anderen deutschen Webseiten eine oder mehrere Sicherheitslücken gefunden. Vermutlich hat er irgendeinen Bot benutzt und auf Seiten mit WordPress losgelassen, um altbekannte und relativ einfach zu findende Lücken zu prüfen. Dieser Eindruck bestätigte sich, als ich ihn nach den Problemen bei Beim Christoph fragte. Gefunden hatte er drei Sachen:
Debug-Log
Wenn der Debug-Modus von WordPress angeschaltet ist, dann erzeugt dieser eine Log-Datei. Die hat einen vordefinierten Namen und einen allseits bekannten Ablageort. Sie enthält interne Informationen wie z.B. das Server-Verzeichnis, die ggf. jemand mit unlauteren Absichten missbrauchen könnte.
In meinem Fall hatte ich diesen Debug-Modus scheinbar am 29. November 2014 mal über die wp-config.php kurz aktiviert. Entsprechend lag eine (sehr kurze) Log-Datei im Verzeichnis wp-content rum. Die Lösung des Problems war also simpel: Datei gelöscht, Sicherheitslücke geschlossen.
REST-API
Hier muss der Code hin, um den Zugriff zu unterbinden.
Die REST-API ermöglicht die Kommunikation mit der von WordPress genutzten MySQL-Datenbank und ist grundsätzlich wohl wichtig für die Funktionen des Content Management Systems. Standardmäßig ist diese API nach außen für jeden offen (https://ihredomain.de/wp-json/), was scheinbar schon so einige Diskussionen im WordPress-Forum nach sich gezogen hat. Technisch gesehen ist es aber wohl keine Sicherheitslücke, weil alle Informationen, die man darüber abfragen kann auch ganz normal über die jeweilige Webseite zu finden sind.
Im konkreten Fall hat Cyber_India mich darauf hingewiesen, dass man sich über den Link “https://www.beimchristoph.de/wp-json/wp/v2/users” alle auf der Seite registrieren User anzeigen lassen kann, die schon einmal einen Beitrag veröffentlicht haben (inkl. ihrer ID und ihrem Icon). Sah ich grundsätzlich erstmal nicht als so kritisch an, da es eben alles nur Autoren sind und die Informationen entsprechend über die Einträge sowieso sichtbar sind. Aber im Sinne des Datenschutzes muss man es ja den Leuten nicht allzu einfach machen.
Am schnellsten ist das Problem durch die Installation eines der vielen Plugins zu lösen. Aber da ich schon mehr als genug Plugins auf der Seite nutze, habe ich stattdessen den Code angepasst – der hoffentlich nicht beim nächsten Core-Upgrade wieder ersetzt wird…
Die Anleitung dazu gibt es ganz offiziell hier. Den dort hinterlegten Code einfach in der Datei wp-includes/rest-api/class-wp-rest-server.php im Abschnitt “public function check_authentication()” einfügen. Das führt dazu, dass die API nur noch für angemeldete Nutzer zur Verfügung steht. Alle anderen bekommen einen 401 (=fehlende Autorisierung) ausgespuckt. “Sicherheitslücke” 2 geschlossen.
XML-RPC
Während die REST-API für interne WordPress-Prozesse gebraucht wird, ist die XML-RPC eine Schnittstelle nach außen. Sie erlaubt es Dritten mit einer WordPress-Seite zu interagieren z.B. einen Beitrag zu veröffentlichen oder Dateien hochzuladen. Das ist mitunter praktisch, wenn man beispielsweise seine Einträge wie ich nicht direkt auf der Seite schreibt, sondern eine andere Art von Editor nutzt. Dank der XML-RPC-Schnittstelle kann man dann direkt aus dem jeweiligen Programm heraus den Beitrag online bringen. Kein Copy & Paste notwendig. Microsoft Word hat diese Möglichkeit meines Wissens nicht andererseits will ich gar nicht wissen welcher HTML-Code entstehen würde, wenn ich Word direkt auf WordPress loslassen würde…
Nachteil dieser Schnittstelle ist allerdings, dass sie als Eingangstor für diverse Attacken dienen kann. Darunter klassische Denial-of-Service (DDoS)-Angriffe, um den Server in die Knie zu zwingen. Aber auch so Sachen wie Cloudflare Protection Bypass, die es ermöglichen eigentlich geschützte IP-Adressen zu finden oder Cross Site Port Angriffe (XSPA) mit denen man offene Ports entdeckt. Also tatsächlich nicht ganz ohne die Sache und leider ist in einer WordPress-Standard-Installation für jeden diese Schnittstelle offen zugänglich. Zwar nur im lesenden Modus aber eben exponiert und bereit von Anfragen überwältigt zu werden.
Wie bei der REST-API ist die Lösung schlicht und einfach das Ding zu deaktivieren, wenn man es tatsächlich nicht braucht. Das funktioniert über einen zusätzlichen Eintrag in der .htaccess:
# BEGIN protect xmlrpc.php
<files xmlrpc.php>
order allow,deny
deny from all
</files>
# END protect xmlrpc.php
Wenn jetzt jemand versucht die API anzusprechen wird er gnadenlos mit einem 403 (Verboten) abgespeist. Eine andere Variante wäre denjenigen, der die API anfragt, einfach auf die Webseite umzuleiten.
Die Interaktion
Cyber_India hat mich also auf meine Nachfrage über drei Probleme informiert (inkl. Lösungsvorschläge) und ich habe sie umgehend sowohl hier als auch bei Lysanda gefixt. Aber natürlich hat das Cyber_India nicht nur aus dem Guten seines Herzens gemacht. Kann ich nachvollziehen, schließlich müssen wir alle von etwas leben. Er behauptet ein Student zu sein, der zum Offensive Security Certified Professional (OSCP) werden möchte und dafür Geld sammelt. Das Zertifikat (PEN-200) ist wohl sehr hoch angesehen in der IT-Welt, weil es voll auf Praxis setzt und schlägt mit mindestens $999 zu Buche – je nachdem wie lange ihr Zugang zum Computerlabor benötigt, um die Aufgaben zu erledigen.
Zumindest ein paar grüne Häckchen!
Er bat mich also pro Report (zur Erinnerung: drei Stück) $50-$250 auf sein PayPal-Konto zu überweisen. Und machte auch gleich noch Werbung dafür ein vollständiges Vulnerability Assessement Penetration Testing (VAPT) für Beim Christoph durchzuführen – natürlich zum “besten” Preis (der ungenannt blieb). Wie ihr sicherlich schon vermutet: Ich habe ihm definitiv keine $150 und schon gar nicht $750 überwiesen und ein VAPT sehe ich für die Seite ebenfalls nicht als relevant an. Selbst, wenn ich hiermit Geld verdienen würde: Die Kritikalität der “Lücken” war äußerst überschaubar und sie sind bereits seit Jahren überall bekannt. Gleichzeitig hat er wie oben geschrieben innerhalb eines Tages tausende von Seiten vermutlich alle mit denselben Problemen gemeldet. Hätte ich freilich genauso gemacht. Masse machts und für den Roboter hat er garantiert nicht viel Aufwand gebraucht. Undankbar wollte ich also zwar nicht sein, aber belohnen wollte ich ihn dafür jetzt auch nicht unbedingt. Meine Lösung? Ich hab‘ ihm als Dank $10 (aktuell 9€) geschickt. Vermutlich immer noch zu viel aber man will ja nicht ganz unverschämt gegenüber einem sein, der potentiell die Möglichkeit hat schlimme Dinge mit der eigenen Webseite anzustellen 
.
Noch ein bisschen mehr Sicherheit
Da ich sowieso gerade im Code unterwegs war, habe ich mich auch mal wieder mit ein paar anderen Sicherheitsthemen beschäftigt. Ja, ich hatte damals für die DSGVO nicht alles gemacht, was theoretisch möglich und empfohlen ist. Schlicht und einfach, weil ich es nicht hinbekommen habe oder noch nicht wusste.
In letztere Kategorie fällt die sogenannte “Permissions Policy” (alt “Feature Policy”). Über diesen Header lässt sich regeln, welchen Seiten/Inhalten es erlaubt ist z.B. Zugriff auf eure Kamera oder eure Geolokation zu bekommen. Das macht Beim Christoph zwar sowieso nicht aber es von Haus zu unterbinden ist nie verkehrt. Dementsprechend habe ich meine .htaccess ergänzt:
Header always set Permissions-Policy: "geolocation=(), midi=(), camera=(), usb=(),
payment=(), vr=(), speaker=(), ambient-light-sensor=(), gyroscope=(), microphone=(), usb=(), interest-cohort=()"
“()” bedeutet: Nichts kann um Erlaubnis fragen und nichts kann sie bekommen. So soll das sein.
Das zweite Thema ist die sogenannte “Content Security Policy” (CSP). Hier geht es darum festzulegen welche Inhalte von wo welcher Quelle zulässig sind und welche nicht. Daran die möglichst restriktiv – also am besten ist ausschließlich www.beimchristoph.de eine zulässige Quelle – hinzubekommen bin ich in der Vergangenheit immer wieder gescheitert. Und auch dieses Mal war ich wieder nicht vollumfänglich erfolgreich aber immerhin zu 70% (7 von 10 Einschränkungen gesetzt) lt. webbkoll. Mehr Parameter und die Seite fing an in Teilen oder sogar überhaupt nicht mehr zu funktionieren. Also beispielsweise die WordPress-Editoren im Hintergrund, irgendwelche Plugins oder die eingebundenen YouTube-Videos. Ein paar Einschränkungen sind vermutlich schlicht nicht möglich (z.B. setzt WordPress so einige Berechtigungen voraus), bei anderen fehlt mir hingegen weiterhin das notwendige Wissen, um es richtig zu machen. Aber 70% ist schon mehr als die bislang 0% . Neu in der .htaccess ist entsprechend nun der folgende Satz:
Header set Content-Security-Policy: "frame-ancestors 'self'; base-uri 'self'; form-action 'self'; object-src 'none';"
Diese Policy führt im Prinzip dazu, dass ausschließlich Inhalte von meiner Seite geladen werden (“self”) dürfen oder im Falle der “object-src” sogar nicht einmal das, da ich weder Java noch Flash einsetze. Was jetzt noch fehlt sind “script-src”, “style-src” und “default-src”. Aber speziell letzteres macht in jeder Einstellung die Seite komplett unbrauchbar. Keine Ahnung wer da querschießt und dann keinen Zugriff mehr auf seine Dateien hat. Schließlich liegt ja alles auf meinem Server und es gibt soweit mir bekannt keinerlei Anfragen an Drittparteien solange man nicht auf ein YouTube-Video klickt. Aber irgendwann finde ich es bestimmt mal raus.
Epilog
Nun aber genug davon, wie ich meinen Samstag verbracht habe. War mal wieder was anders aber ab und zu mal im Code zu wühlen finde ich ja durchaus ganz nett. Da lernt man immer mal wieder was Neues oder bleibt zumindest frisch. Für euch gilt auf jeden Fall: Ihr könnt euch sicher sein, dass ihr hier Beim Christoph weiterhin sicher seid und ich ständig im Hintergrund daran arbeite, dass ihr auch sicher bleibt . Und nein, das war jetzt keine Aufforderung an alle mitlesenden Black Hats mir das Gegenteil zu beweisen *setzt den Bambi-Blick auf*.