4chan und der Hack, der keiner war: Eine selbstverschuldete PHP-Katastrophe

Soyjak.party, 4chans liebster Hasskonkurrent (entstanden aus den Trümmern des gebannten /qa/-Boards), hat zugeschlagen. Unter der Führung eines besonders redseligen „Chud“ führte die Gruppe ihren Hacker-Streich durch – ein Jahr lang unbemerkte Zugriffe, ein Revival des toten /qa/-Boards und geleakte Daten inklusive 4chan's PHP Source-Code.

Sicherheitslücke und Angriffsweg

Der Hack nutzte eine dreifach veraltete Sicherheitsarchitektur: 4chan erlaubte zwar PDF-Uploads auf Boards wie /pol/ oder /gdl/, verzichtete aber auf eine echtedateitypenprüfung. Dadurch konnten Angreifer PostScript-Dateien mit Schadcode einschleusen, die das System blind an Ghostscript zur Thumbnail-Erzeugung übergab – in einer Version von 2012, die längst als anfällig bekannt war. Über gezielte PostScript-Befehle gelang nicht nur Codeausführung, sondern durch eine fehlerhafte Binärdatei sogar die Eskalation zu Administratorrechten. Eine Kettenreaktion, die nur möglich war, weil 4chan gleich an mehreren Stellen IT-Archäologie betrieb: unsichere Dateiverarbeitung, ungepatchte Software und fehlende Privilegientrennung.

4chan und der Hack, der keiner war

Seit Christopher „moot“ Poole die Plattform 2003 ins Leben rief, steht 4chan wie ein monolithisches Relikt der frühen Internetkultur da – sperrig, ungezähmt und gerade deshalb unersetzlich. Während andere Plattformen modischen UX-Trends hinterherhechelten, bewahrte sich /b/ seine anarchische Rohheit: zerbröselndes PHP-Relikt und ein Design, als wäre es mit Telnet und Trotz gebaut. Dieser Hack legt die Schattenseiten dieser Sturheit offen – doch eben jene Unnachgiebigkeit macht 4chan zum lebendigen Archiv des digitalen Untergrunds. Möge es weiter gedeihen – nicht trotz, sondern wegen seiner Dysfunktionalität.