TanStack & VIELE weitere Pakete betroffen - Deep Dive & Analyse
MMaximilian Schwarzmüller
Computing/SoftwareBusiness NewsInternet Technology
Transcript
00:00:00Wir haben einen weiteren großen, einen wirklich großen Supply-Chain-Angriff, der gerade stattfindet und noch andauert,
00:00:06und er hat sich von NPM auch auf das Python-Ökosystem ausgeweitet. Installieren Sie also vielleicht gerade keine
00:00:12NPM- oder Python-Pakete. Und stellen Sie sicher, dass Ihr System generell sicher eingerichtet ist. Ich habe dazu ein weiteres Video,
00:00:19ich werde unten einen Link teilen und auch hier in diesem Video darauf zurückkommen, aber zuerst möchte ich
00:00:23euch einige Details dazu geben, was betroffen ist, und wie ihr herausfindet, ob ihr betroffen seid. Es begann mit den
00:00:30TanStack-Paketen, TanStack Query, TanStack Router, TanStack Start und so weiter. Gestern, am 11. Mai,
00:00:36wurden in einem ziemlich kurzen Zeitraum ein paar bösartige Pakete oder eigentlich alle TanStack-Pakete
00:00:43mit bösartigen Versionen veröffentlicht, und es wurde innerhalb von 20 Minuten schnell eingedämmt. Am Ende
00:00:50wurde es schnell entdeckt und eingedämmt, aber all diese bösartigen Pakete wurden in diesem Zeitfenster
00:00:57oder in diesem kurzen Zeitraum hier veröffentlicht. Und dann breitete es sich weiter aus, und das tut es
00:01:03immer noch. Es breitete sich auf die Mistral-Pakete aus, die ha ha nur vier Nutzer haben, aber trotzdem war das
00:01:09betroffen, denn diese Malware agiert als Wurm und stiehlt Daten, stiehlt Anmeldedaten, potenziell auch
00:01:16eure, wenn sie auf eurem System installiert ist. Ich komme gleich darauf zurück, wie ihr herausfindet, ob ihr betroffen seid,
00:01:20aber sie verbreitete sich weiter auf mehr NPM-Pakete, da das die Idee dahinter ist, und
00:01:26dann sogar in das Python-Ökosystem, und das passiert gerade jetzt. Das ist erst ein paar Stunden alt
00:01:32hier, zwei Stunden zum Zeitpunkt, an dem ich das hier aufnehme. Nun, wie findet ihr heraus, ob ihr
00:01:39betroffen seid? Wenn ihr gestern Abend in meiner Zeitzone hier in Deutschland irgendein
00:01:45TanStack-Paket installiert habt, müsst ihr euch als betroffen betrachten. Wenn ihr es um diese Zeit herum installiert habt, denkt daran,
00:01:54dass das UTC ist, ihr müsst das also in eure Zeitzone umrechnen, in dieser Zeit müsst ihr euch
00:02:00als betroffen betrachten. Da es sich aber auf die Mistral-Pakete ausbreitet, auf viel mehr JavaScript-Pakete,
00:02:06als ich hier aufzählen könnte, müsst ihr euch oder eure Maschine ebenfalls als betroffen und kompromittiert betrachten.
00:02:13Ich werde Links zu diesen Posts unten teilen, damit ihr tiefer eintauchen und die vollständige Liste
00:02:18all dieser betroffenen Pakete sehen könnt, wie sie veröffentlicht wurden. Aber wie erwähnt, es läuft noch,
00:02:22also installiert vielleicht gerade nichts. Es gibt auch Anzeichen für eine Kompromittierung. Ihr solltet nach
00:02:31bestimmten Dateihashes suchen, SHA-Hashes, für den Router in einer JS-Datei. Ich werde diesen Post auch unten verlinken.
00:02:38Und wenn ihr eine Möglichkeit habt zu überwachen, welche Netzwerkanfragen auf eurem Rechner stattgefunden haben,
00:02:42solltet ihr nach ausgehendem Traffic zu dieser URL suchen, was ein weiteres klares Anzeichen dafür wäre,
00:02:48dass Daten von eurem System abgeflossen sind. Was bedeutet Kompromittierung im Detail? Es bedeutet, dass
00:02:55diese Malware vor allem zwei Dinge tut. Das erste wichtige Ding ist das Sammeln von Daten. Sie sucht nach
00:03:03NPM-Tokens, GitHub-Tokens, AWS-Zugangsdaten und anderen Geheimnissen. Sie scannt also euer System nach
00:03:12typischen Orten, an denen ihr Anmeldedaten und Geheimnisse speichert, sammelt sie und sendet sie an
00:03:18diese URL, die ich euch gezeigt habe. Sie stiehlt also diese Geheimnisse. Aber sie tut nicht nur das. Wie erwähnt,
00:03:26agiert sie als Wurm, sie nutzt also auch diese gestohlenen GitHub-Tokens. Zum Beispiel
00:03:33nutzt sie und die NPM-Token, um weitere kompromittierte Pakete zu veröffentlichen. Wenn Sie der Maintainer
00:03:40eines anderen Pakets seid oder wenn ihr vielleicht einen CI/CD-Workflow habt, der in diesem Zeitraum lief und der
00:03:46von TanStack-Paketen abhing, dann wurden in diesem CI/CD-Workflow die bösartigen, die kompromittierten
00:03:53TanStack-Pakete hineingezogen. Der bösartige Code wurde dort möglicherweise ausgeführt. Und dann könnten in diesem
00:04:00Workflow – also nicht auf eurem Rechner, sondern in diesem Workflow – ebenfalls bestimmte Anmeldedaten gestohlen werden,
00:04:06um eine bösartige Version, eine kompromittierte Version des Pakets zu veröffentlichen, das euer CI/CD-Workflow
00:04:14gerade bauen wollte. So verbreitet es sich also. Wie erwähnt, es agiert als Wurm. Es nutzt diese
00:04:20gestohlenen Zugangsdaten und Tokens, um mehr kompromittierte Pakete zu veröffentlichen. Und so verbreitet es sich
00:04:26auf Mistral und dann auch auf andere JavaScript-Pakete und dann sogar in das Python-Ökosystem. Und hier
00:04:32stehen wir gerade. Und es verbreitet sich nach allem, was ich weiß, immer noch. Wie kann man sich nun
00:04:39davor schützen? Ich habe dazu ein Video auf meinem anderen Kanal, AkataMind, erstellt. Ich werde es auch unten verlinken.
00:04:44Kurz gesagt: Ihr wollt sicherstellen, dass ihr euren Code ausführt oder eure Entwicklung macht,
00:04:51wenn möglich nicht direkt auf eurem Hauptrechner, sondern stattdessen in einer virtuellen Maschine, in einem Dev-Container,
00:04:57so etwas in der Art. Ihr wollt keine Geheimnisse im Klartext auf eurem Rechner speichern. Ich meine, für AWS,
00:05:03zum Beispiel, solltet ihr deren Single-Sign-On-Ansatz nutzen, anstatt IAM-Zugangsdaten auf
00:05:10eurem Rechner zu speichern, und ähnliche Techniken für andere Dienste verwenden, die ihr vielleicht nutzt. Zusätzlich
00:05:16solltet ihr in Betracht ziehen, Dienste wie Infisical oder Doppler zu nutzen, um eure Geheimnisse
00:05:25in der Cloud zu speichern und nicht auf eurer Festplatte, nicht in .env-Dateien. Das ist etwas, das ihr tun solltet.
00:05:30Und wie gesagt, über solche Sachen spreche ich in diesem Video. Und ihr solltet auch Paketmanager
00:05:38und Konfigurationen nutzen, die es erlauben, Dinge wie das Mindestalter eines Releases einzustellen, wie Bun es
00:05:44euch ermöglicht. In der bunfig.toml-Datei könnt ihr ein Mindestalter für Releases festlegen, was sicherstellt, dass ihr,
00:05:49selbst wenn ihr 'bun install' ausführt, nur Pakete installiert, die mindestens X Sekunden oder X Tage alt sind, in diesem
00:05:56Fall hier in diesem Beispiel. Nun, pnpm hat ein ähnliches Feature. Die neuesten Versionen von npm haben ein ähnliches
00:06:02Feature. Auch das habe ich in dem anderen Video behandelt. Und wenn ihr so etwas wie Bun nutzt oder wenn ihr
00:06:09die richtige Konfiguration für npm habt – Bun macht es beispielsweise standardmäßig – dann blockiert es auch die
00:06:15Ausführung von beispielsweise Post-Install-Skripten, also Lifecycle-Skripten der Pakete, die ihr gerade
00:06:21installiert. Das bietet euch einen weiteren Sicherheitsmechanismus, da diese Malware typischerweise darauf angewiesen ist,
00:06:28dass solche Skripte auf eurem System ausgeführt werden. Also: Die Nutzung eines sicheren Paketmanagers und/oder einer sicheren
00:06:36Konfiguration dafür, das Ausführen von Code in einer virtuellen Maschine oder einem Dev-Container
00:06:41und das Nicht-Speichern von Geheimnissen im Klartext. Das ist das, was man generell tun sollte, aber jetzt vielleicht
00:06:46noch mehr, da diese Angriffe, Angriffe wie diese hier, einfach ernster werden. Und wir werden uns ansehen,
00:06:52wie dieser Angriff funktioniert hat, denn das ist wirklich interessant. Aber natürlich werden wir noch mehr davon
00:06:58sehen. Ich erstelle mittlerweile fast jeden Monat ein solches Video, oder vielleicht sogar noch häufiger, denn erstens
00:07:04glaube ich, dass sie einfacher durchzuführen sind. Im Zeitalter der KI ist es einfacher, die Pakete oder
00:07:12Abhängigkeiten zu analysieren, die man befallen will, und deren Quellcode oder das CI/CD-Setup nach potenziellen
00:07:22Angriffsvektoren zu untersuchen. Das ist es, was hier bei TanStack passiert ist. Es war nicht so, dass der Rechner
00:07:28eines Maintainers befallen war, sondern stattdessen wurde der CI/CD-Workflow von TanStack angegriffen. Und darauf
00:07:34werde ich noch zurückkommen. Es ist also einfacher, mit KI nach Schwachstellen zu suchen. Es ist einfacher, Code zu schreiben,
00:07:40natürlich auch bösartigen Code. Und gleichzeitig haben wir diese Software-Explosion. Es wird mehr
00:07:45Software geschrieben als je zuvor. Es gibt also mehr Ziele da draußen, darunter viele Ziele,
00:07:51die sich vielleicht nicht allzu sehr um Sicherheit kümmern. Das macht solche Angriffe auch interessanter.
00:07:57Wie fing das alles an? Es ist wirklich interessant. Wie erwähnt, kein völlig neuer Ansatz,
00:08:03keiner, den wir noch nie gesehen hätten, aber dennoch recht ausgeklügelt. Das TanStack-Team hat ein
00:08:09Post-Mortem veröffentlicht, einen Artikel, in dem sie erklären, wie der Angriff ablief. Den werde ich auch unten verlinken.
00:08:15Aber natürlich gebe ich euch hier die Zusammenfassung, denn letztendlich beruhte dieser Angriff hier auf
00:08:22drei Hauptschritten, die ich im Detail erklären werde. Ein “Pull Request Target Pwn Request”-Muster. Ich werde
00:08:30erklären, was das ist. Dann GitHub Actions Cache-Poisoning über die Fork-basierte Vertrauensgrenze hinweg
00:08:38und Laufzeit-Memory-Extraktion eines OIDC-Tokens. Okay, was bedeutet das alles? Wie gesagt,
00:08:45ihr könnt den Artikel für alle Details lesen, aber lasst mich euch die Zusammenfassung geben. Fangen wir mit
00:08:50dem “Pull Request Pwn Request”-Muster an. Was ist das? Um das zu verstehen, müssen wir verstehen,
00:08:58dass GitHub Actions natürlich die CI/CD-Lösung ist, das CI/CD-Produkt von GitHub. Und ich
00:09:05habe übrigens auch einen Kurs zu GitHub Actions, falls ihr lernen wollt, wie man GitHub Actions einrichtet,
00:09:10wie man das Produkt für CI/CD-Aufgaben nutzt, wie man seine Pakete oder seine Website veröffentlicht und so weiter.
00:09:16Wie alle CI/CD-Workflow-Tools basiert GitHub Actions auf Ereignissen, die Workflows auslösen, denn
00:09:24natürlich geht es bei CI/CD darum, etwas automatisiert zu erledigen. Zum Beispiel eure Website freizugeben,
00:09:29zu veröffentlichen, eure Website automatisiert bereitzustellen, wenn ihr zum Beispiel in den Main-Branch pusht.
00:09:34Es gibt also verschiedene Ereignisse, die einen Workflow auslösen können, und ein Push ist zum Beispiel so ein Ereignis,
00:09:40sodass man sagen kann: Okay, wenn ich in den Main-Branch pushe – man kann nach
00:09:44verschiedenen Branches filtern – dann möchte ich bestimmte Aufgaben ausführen. Ich möchte meine Abhängigkeiten installieren. Ich möchte
00:09:49das Projekt bauen. Ich möchte es auf meinen Server hochladen. Das ist es, was man tun könnte. Ein weiterer Trigger
00:09:56ist 'pull_request_target'. Dieser Trigger wird aktiviert, wenn ein Pull Request für euer
00:10:05Repository geöffnet wurde. Und das bedeutet natürlich, dass jeder euer Repository forken kann, dort etwas macht, etwas
00:10:14in seinen Fork pusht und dann einen Pull Request bei eurem Repository eröffnet. Und das würde
00:10:19diesen Workflow auslösen. Klingt gefährlich? Nun, das ist es gewissermaßen auch. Und damit fing dieser Angriff an.
00:10:25Es gibt auch den 'pull_request'-Trigger. Ich habe vorhin über 'pull_request_target' gesprochen,
00:10:31aber wir haben auch 'pull_request', was genauso funktioniert, aber 'pull_request' führt den CI/CD-
00:10:38Workflow im Kontext des geforkten Repositories aus. Was auch immer dort an Bösartigem vor sich gehen mag,
00:10:45es passiert im geforkten Repository, nicht im Basis-Repository. Das ist also kein Problem.
00:10:52'pull_request_target' hingegen läuft im Kontext des Basis-Repositories. Und das ist natürlich
00:10:58potenziell gefährlich. Es ist potenziell gefährlich, weil jeder einen Pull Request öffnen kann. Und
00:11:04natürlich geschah in diesem Fall beim TanStack-Angriff Folgendes: In diesem Pull Request,” in diesem
00:11:10Fork, hat der Angreifer den bösartigen Code, den Wurm-Code, die Malware in das TanStack-Repository eingeschleust,
00:11:20also in den Fork davon. Dann hat der Angreifer den Pull Request geöffnet,
00:11:26und das führte dazu, dass 'pull_request_target' ausgeführt wurde. Und wie erwähnt, startet das dann einen GitHub
00:11:33Actions Runner, und dieser läuft dann im Kontext des Basis-Repositories. Was bedeutet das?
00:11:40Das bedeutet nicht, dass der Angreifer Zugriff auf den Basis-Code erhält oder den bösartigen Code
00:11:46in das Repository mergen kann, aber es bedeutet zum Beispiel, dass der Cache, der dort verwendet wird,
00:11:53mit nachfolgenden GitHub Actions-Ausführungen geteilt wird, die aus dem Basis-Repository stammen,
00:12:00potenziell von ganz anderen Hooks oder Event-Triggern wie dem Push-Trigger.
00:12:05Das Nächste, was passierte, war das Cache-Poisoning. Aber was bedeutet das? Nun,
00:12:11der Angreifer fügte Code zu seinem Fork hinzu, der sicherstellte, dass beim Ausführen der GitHub Action
00:12:17für den 'pull_request_target'-Trigger ein Befehl ausgeführt wurde, der 'hashfiles'-Befehl,
00:12:23der von GitHub Actions unterstützt wird, um etwas im GitHub Actions-Cache zu speichern. Nun,
00:12:28worum geht es bei diesem Cache? Die Idee hinter dem GitHub Actions-Cache ist schlicht, diese
00:12:33GitHub Actions-Workflows zu beschleunigen. Man kann zum Beispiel Abhängigkeiten hashen. Die Idee dabei ist:
00:12:39Wenn sich eine Abhängigkeit, von der euer Paket abhängt, nicht geändert hat, warum sollte man dann den gesamten
00:12:46Installationsprozess erneut durchlaufen? Das kostet einfach Zeit, und Zeit ist Geld, da euch die
00:12:52Laufzeit eures GitHub Actions-Workflows in Rechnung gestellt wird. Und natürlich wollt ihr keine Workflows,
00:12:56die ewig dauern. In den meisten Workflows, zum Beispiel beim Bauen der TanStack-Pakete,
00:13:00installiert ihr die Abhängigkeiten der TanStack-Pakete und macht dann den Build-Schritt und baut
00:13:06euer TanStack-Paket. Nochmals: Wenn sich diese Abhängigkeiten von TanStack nicht geändert haben,
00:13:12warum sie neu installieren? Das ist die Idee hinter dem Caching. Und das ergibt Sinn. Das Problem ist natürlich:
00:13:18Da diese 'pull_request_target'-GitHub-Actions-Ausführung und andere GitHub-Actions-Ausführungen,
00:13:24wie die für den Push-Trigger, denselben Kontext teilen, teilen sie sich auch denselben Cache. Und hier
00:13:31kommt das Cache-Poisoning ins Spiel, denn der Angreifer war in der Lage, eine bösartige Version zu cachen oder
00:13:39diesen bösartigen Code in eine Abhängigkeit von TanStack zu legen, sozusagen, und das zu cachen. Der Angreifer
00:13:46musste dann nur darauf warten, dass ein normaler GitHub Actions-Workflow für die TanStack-Pakete läuft.
00:13:53Also darauf, dass ein Maintainer Code pusht, und dann würde diese andere GitHub Actions-Ausführung
00:14:01denselben Cache wiederverwenden, der zuvor durch die bösartige Ausführung eingerichtet wurde, und würde nun den
00:14:08vorbereiteten, vergifteten Cache ziehen, der den bösartigen Code enthielt. So gelangte der bösartige Code
00:14:13vom Fork in die normale GitHub Actions-Ausführung bei einem normalen Push durch einen normalen Maintainer,
00:14:21der von keinerlei bösartigem Code betroffen war. So wurde der Cache als Transportmittel
00:14:28zwischen diesen beiden GitHub Actions-Ausführungen genutzt. Und in einem dritten Schritt, sobald der
00:14:35bösartige Code in eine reguläre Ausführung eines TanStack-CI/CD-Workflows gelangt war – aufgrund dieses Push-
00:14:44Ereignisses – stahl er einen kurzlebigen NPM-Token, letztlich einen OIDC-Token, um eine bösartige Version
00:14:54des TanStack-Pakets zu veröffentlichen. Worauf beziehe ich mich hier? NPM hat diese Funktion namens
00:15:00“Trusted Publishing”, die das Veröffentlichen von NPM-Paketen theoretisch sicherer macht, da
00:15:04es grob gesagt zwei Wege gibt, ein Paket auf NPM zu veröffentlichen. Einer besteht darin, einen
00:15:11Token mit eurem NPM-Konto zu erstellen und diesen zu nutzen, um neue Versionen eures Pakets zu veröffentlichen. Das Problem
00:15:19ist: Wenn dieser Token gestohlen wird, kann jeder eine neue Version dieses Pakets veröffentlichen. Um die
00:15:26Sicherheit zu erhöhen, gibt es diesen Trusted-Publishing-Prozess, bei dem NPM sagt: Nein, ihr könnt Pakete nicht von
00:15:33eurem Rechner aus veröffentlichen, ihr müsst über einen dieser vertrauenswürdigen Anbieter gehen, wobei GitHub Actions einer
00:15:37davon ist, und es gibt eine Trusted-Publishing-Integration für GitHub Actions, die man einrichten kann. Dann
00:15:44wird als Teil dieses Trusted-Publishing-Prozesses ein kurzlebiger Publishing-Token abgerufen
00:15:50oder angefordert. Und dieser kurzlebige Token wird dann zum Signieren dieser neuen Paketversion
00:15:57verwendet, die gerade veröffentlicht wird. Theoretisch ist die Idee, dass der Token schwer zu stehlen ist, weil
00:16:03er sich nicht auf dem Rechner eines Maintainers befindet. Zudem ist er kurzlebig. Selbst wenn er gestohlen würde,
00:16:08ist er nicht sehr lange aktiv. Das Problem ist natürlich nur: Wenn der Code, der im CI/CD-
00:16:15Workflow läuft und diesen vertrauenswürdigen Token anfordert, befallen ist, dann hat dieser bösartige
00:16:21Code Zugriff auf diesen brandneuen, kurzlebigen Trusted-Publishing-Token. Und genau das ist hier
00:16:27passiert. Dieser bösartige Code hat diesen Token missbraucht oder genutzt, um dann eine neue Version
00:16:36des TanStack-Pakets zu veröffentlichen. Interessanterweise ist dieser Angriff eigentlich ein wenig gescheitert, denn er hat
00:16:44diesen vertrauenswürdigen Token zwar erhalten und ihn genutzt, um die NPM-API zu erreichen und eine neue Version
00:16:52des TanStack-Pakets zu veröffentlichen, die diesen Wurm und den bösartigen Code enthielt. Aber er landete
00:16:58tatsächlich in einem GitHub Actions-Workflow, der nicht abgeschlossen werden konnte, weil etwas an
00:17:06dem Code falsch war, der zum CI/CD gepusht wurde. Wenn die Angreifer darauf geachtet hätten, ihren
00:17:12Angriff zu einem Zeitpunkt durchzuführen, an dem valider Code gepusht wird, dann wäre dieser Workflow natürlich
00:17:19abgeschlossen worden, und sie hätten sich nicht darauf verlassen müssen, ein bösartiges Paket manuell zu veröffentlichen, indem sie
00:17:26die NPM-API kontaktieren. Stattdessen hätten sie den bösartigen Code in diesen Workflow einschleusen können,
00:17:32wie sie es taten, diesen Workflow erfolgreich beenden lassen, und dann wäre eine kompromittierte Version von TanStack
00:17:38veröffentlicht worden, während sie sehr valide ausgesehen hätte, da es ein normaler Push eines Maintainers war und der Workflow
00:17:45erfolgreich endete. Die Art und Weise, wie dieser Angriff ablief – weil dieser Workflow eben nicht erfolgreich war –
00:17:51machte es am Ende für einen externen Mitwirkenden etwas einfacher zu bemerken, was da vor sich ging,
00:18:00da man sehen konnte, dass eine neue Version der TanStack-Pakete veröffentlicht wurde, obwohl der
00:18:05GitHub Actions-Workflow fehlgeschlagen war. Es hätte also gar keine neue Version veröffentlicht werden dürfen. Man konnte dort eine
00:18:12Diskrepanz sehen, was es etwas einfacher machte, diesen Angriff zu entdecken, was ein Punkt ist, an dem die
00:18:19TanStack-Maintainer und wir alle Glück hatten. Nichtsdestotrotz ein ziemlich ausgeklügelter Angriff, wie ihr
00:18:26wahrscheinlich merkt, der völlig ohne die Kompromittierung eines Rechners funktionierte. Und obwohl er schnell bemerkt
00:18:32wurde, hat er schweren Schaden angerichtet, da er sich, wie erwähnt, immer noch verbreitet. Und das war eine lange
00:18:41Episode über all das, ich weiß, aber ich möchte wirklich betonen: Ihr müsst daran arbeiten, euer System
00:18:49sicher zu machen. Wie ich bereits sagte und wie ich in diesem Video zeige, müsst ihr sicherstellen, dass ihr die
00:18:56Gefahr reduziert, betroffen zu sein. Dieser Angriff wurde zwar schnell entdeckt, und doch verbreitet er sich immer noch,
00:19:05es ist also noch nicht vorbei. Und es ist möglich, dass künftig nicht alle Angriffe so schnell entdeckt werden.
00:19:11Wie erwähnt, sie hatten hier ein wenig Glück; es hätte schwieriger sein können, diesen
00:19:18Angriff zu entdecken. Dann wäre der Schaden vielleicht noch größer gewesen. Aber er ist hier bereits ziemlich groß und
00:19:24es ist noch nicht vorbei. Wir werden sicher mehr solcher Angriffe sehen, da, wie gesagt, die Angriffsfläche
00:19:31größer und interessanter wird. Es schreiben mehr Leute Code, viele Leute,
00:19:36die nicht wissen, was sie tun, und KI hilft beim Ausführen solcher Angriffe. Also ja, das ist es, was gerade
00:19:42passiert. Wenn ihr nicht müsst, installiert vielleicht gerade nichts, prüft euer Setup doppelt, und ihr
00:19:48findet alle Links unten, falls ihr tiefer eintauchen wollt, die vollständige Liste der betroffenen
00:19:51Pakete sehen wollt und so weiter.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video