Cybercrime Curiosities Part 3: Das colors.js-Desaster

Hier liest du einen Artikel aus unserer Reihe Cybercrime Curiosities. Lust auf weitere obskure und schockierende Fälle von Cyberattacken? Dann schmöker doch mal rein: Der Fisch, der zu viel wusste, Cyberangriff legt Flughäfen lahm.

Protestware sorgt für Farbenchaos

Den Stein ins Rollen brachte ein unscheinbares Werkzeug namens colors.js. Das ist eine kleine Softwarebibliothek, die Programmierern hilft, Text in Konsole und im Terminal bunt und übersichtlich darzustellen. Fast jeder, der mit sogenannten Node.js-Anwendungen arbeitet, hatte das Paket im Einsatz – und das weltweit.

Doch urplötzlich, am 8. Januar 2022, war Schluss mit der Routine: Programme, die normalerweise nüchtern Zahlen oder Hinweise ausgaben, schienen wie im Farbrausch zu sein. Sie liefen endlos, statt wie gewohnt ihren Dienst zu tun. Was war der Grund für diese kollektive Fehlfunktion? Experten vermuteten einen Softwarefehler, einen Cyberangriff, vielleicht sogar einen bösartigen Hack.

Wie ein Entwickler das Ökosystem erschütterte

Was folgte, war Detektivarbeit quer durch die IT-Welt. Ein Hackerangriff schien zuerst am wahrscheinlichsten. Nach kurzer Zeit wurde jedoch ermittelt, dass der Maintainer – also der Hauptverantwortliche für das Paket – selbst hinter der Aktion steckte. Sein Name: Marak Squires.

Squires hatte nicht einfach einen Bug eingebaut. Er hatte absichtlich eine Endlos-Schleife in die Software gepackt, die für Chaos sorgte. Warum sabotiert jemand sein eigenes Programm? Die Antwort wirkt ernüchternd: Squires war frustriert darüber, dass große Konzerne seine kostenlose Arbeit nutzten, ohne sich an den Kosten oder der Pflege zu beteiligen oder ihm etwas zu spenden – also zog er die Reißleine. Ein Pfeil mitten in das Herz von Open Source.

Faker.js und der Protest gegen Großkonzerne

Das Farbspektakel war aber nur der Startschuss. Direkt danach zeigte Squires auch beim zweiten seiner populären Projekte klare Kante: faker.js. Dieses kleine Paket erzeugt automatisch Fantasiedaten – perfekt zum Testen von Software, ohne gleich echte Adressen und Namen zu benutzen.

Auch hier wurde kurzerhand die Schnittstelle sabotiert, sodass nichts mehr funktionierte wie gewohnt. Klar, der Protest richtete sich gegen Tech-Giganten und unzählige Firmen, die Open Source zu selbstverständlich einsetzten.

Kuriose Details: Endlosschleifen und die amerikanische Flagge

Die Software zauberte endlose, fast psychedelische Zeichenketten ins Terminal – und mittendrin die amerikanische Flagge oder kryptische Botschaften im sogenannten „Zalgo“-Stil. Wer auf GitHub nach Hilfe suchte, stieß auf philosophische Fragen und Anspielungen, etwa: „Was ist eigentlich aus Aaron Swartz geworden?“ (Eine Ikone des freien Internets.) Das World Wide Web lachte, staunte und ärgerte sich.

Was ist Protestware?

Was steckt eigentlich hinter Protestware? Anders als klassische Cyberangriffe wollen Entwickler mit Protestware nicht mutwillig Schaden anrichten oder sich bereichern. Sie nutzen ihr Wissen, um die Gemeinschaft auf Missstände aufmerksam zu machen.

Protestware im Open Source: Ursachen, Motive, Folgen

Oft geht es ums Geld, manchmal um Ethik, manchmal einfach um Gehör. Viele Open Source-Entwickler investieren unzählige Stunden, während große Unternehmen kostenlos von ihrer Arbeit profitieren. Das Ziel von Protestware ist, Aufmerksamkeit zu schaffen. Für Nutzer kann das zum Albtraum werden: Plötzlich laufen Programme nicht mehr, Fehler jagt Fehler, und die Ursache ist schwer zu finden.

Auch andere Fälle sorgten für Furore:

• node-ipc
  Der Maintainer sorgte 2022 für Schlagzeilen, indem er Code einschleuste, der gegen Computer mit russischer oder belarussischer Zeitzone protestierte – als Reaktion auf politische Entwicklungen. Ein konkretes Zeichen der politischen Haltung, mit unmittelbaren Auswirkungen auf die Nutzer.
• es5-ext
  Der Entwickler dieses weitverbreiteten Pakets baute eine Protestnachricht in den Code, die für „peace not war“ auf Computern ausließ, die auf russische Zeitzonen eingestellt waren. Zwar war die Aktion harmlos – sie machte aber klar, wie schnell ein Maintainer sein Projekt zum Sprachrohr machen kann.
• event-stream
  Hier war weniger Protest, sondern mehr politische Motivation im Spiel: Ein ehemaliger Mitentwickler mischte schädlichen Code für Krypto-Diebstahl in das Paket, um auf Missstände in der Open-Source-Sicherheitskette hinzuweisen – ein Fall, der zeigte, wie dünn die Linie zwischen Protest und gefährlicher Manipulation im Software-Ökosystem sein kann.

Die kuriosesten Reaktionen aus der Entwickler-Community

Das Netz ist ein bunter Ort – und die Farben-Attacke erzeugte eine der buntesten Debatten überhaupt. Einige Entwickler kommentierten lakonisch: „So hat mein Terminal noch nie geglänzt.“ Andere schimpften wie Rohrspatzen – und ließen ihrer Frustration über die Ausnahmesituation freien Lauf.

Von Ironie bis Empörung: Was die Community sagte

Die Community war zwischen Bewunderung für die kreative Rebellion und handfester Empörung hin und hergerissen. Slogans, Memes, hitzige Diskussionen auf Twitter und in Foren – jede Meinung war vertreten. Manche lobten Mut und Kreativität, andere warnten vor Kollateralschäden und der Gefahr, dass künftig Entwickler und Firmen durch solche Aktionen misstrauischer gegenüber Open Source werden könnten. Verwiesen wurde darauf, dass Programmierer von Open Source damit rechnen müssen, eben nicht mit Einnahmen durch diese Arbeit rechnen zu können.

Lehren aus dem Protestware-Vorfall

Nachdem der Skandal abebbte, begann die Szene zu diskutieren: Was lernen wir daraus? Dass Software keine Einbahnstraße ist? Dass Maintainer nicht beliebig belastet werden dürfen, ohne Unterstützung? Dass gute Kommunikation und Wertschätzung kein Luxus sind?

Supply Chain Risiken und Software-Maintenance

Gerade der Fall colors.js zeigt, wie verwundbar die sogenannte Software Supply Chain ist: Ein einzelnes Paket-Update reicht, um den Betrieb tausender Anwendungen zu crashen. Wer Software in Projekten nutzt, sollte nicht jedes Update blind einspielen und immer ein Auge auf die Herkunft und Pflege der Bausteine haben – und Maintainer öfter mal ein Dankeschön oder einen Sponsor-Coffee spendieren. Entwickler sollten bewusster mit Abhängigkeiten umgehen und offen für Dialog zu sein. Open Source lebt von Gemeinschaft.

Eine der wichtigsten Konsequenzen aus dem colors.js Vorfall für Unternehmen und Entwickler ist der Blick auf Alternativen zu colors.js nach dem Skandal. Viele wechselten zu Bibliotheken wie „chalk“ oder „kleur“, andere setzten auf eigene Lösungen oder Forks – alles mit dem Ziel, mehr Kontrolle und Cybersicherheit in der Software Supply Chain zu bekommen.

Der colors.js Protestware-Skandal als Weckruf

Am Ende bleibt die Geschichte ein denkwürdiges Beispiel für den Wandel im Umgang mit Open Source. Nicht immer ist alles „for free“ – manchmal kostet ein Farbtupfer eben doch mehr als ein Mausklick. Wer Software entwickelt oder nutzt, sollte nicht nur an die Technik denken, sondern auch an die Menschen dahinter. Denn manchmal steckt hinter einer bunten Fehlermeldung weit mehr als nur ein Bug.