Rückblick: Angriffe auf Podlove

Martin · 0:07 Hallo zur 38. Ausgabe des Podlovers-Podcasts. Ich bin Martin und hier ist auch… Erik.

Eric · 0:16 Hallo.

Martin · 0:17 Hallo, Erik. Wir sind heute zu zweit. Die anderen beiden sind verhindert, aber wir wollten diese Folge nutzen. Wir haben gedacht, nach zwei Jahren kann man wieder mal eine Folge machen, weil es ist einiges passiert. Und das habt ihr bestimmt auch mitbekommen, wenn ihr Podlove nutzt oder den Podcast Medien wie zum Beispiel das Podjournal Verfolgt von Jörn Schaar. Es gab ein bisschen Aufregung um Podlove, es gab Exploits, es gab Patches, es gab neue Versionen und wir wollen das jetzt nochmal Revue passieren lassen und nochmal erklären, was eigentlich genau vorgefallen ist und was vor allem Erik gemacht hat, damit es hoffentlich nicht wieder passiert. Und genau, da würde ich sagen, steigen wir mal ein. Und genau, Erik wird jetzt gleich so ein bisschen eine kleine Chronologie berichten. Und wir steigen ein im September 2025. Vielleicht nochmal kurz da davor. Wir hatten ja das vom Prototype Fund geförderte Projekt, wo wir den Onboarding-Assistenten entwickelt haben. Das war 2024 und dann gab es so ein paar kleinere Releases. Und dann gab es, wie gesagt, den September 2025. Was ist da passiert, Erik?

Eric · 1:33 Ja, da hat mich ein CVE erreicht. Wofür steht das? Common Vulnerabilities and Exposures. Also CVE ist so ein System, um Exploits oder Sicherheitslücken in Software zu katalogisieren. Ja, der Begriff CVE wird noch ein paar Mal fallen.

Martin · 1:54 Den kann jeder melden und da gibt es so Plattformen, die die sammeln und öffentlich machen, wenn was gefunden wurde. Ist das so gängig oder ist das erstmal nur eine Beschreibung für eine Schwachstelle?

Eric · 2:07 Das ist ein System. Es gibt öffentliche Datenbanken, wo quasi jeder CVE hat eine ID, sodass jede Sicherheitslücke in der Software einzigartig auch referenziert werden kann. Das ist so ein Vorteil davon. Das ist immer CVE- und dann eine Nummer. Damit sind die eindeutig. Und wenn man über so eine Sicherheitslücke redet, dann kann man die eben eindeutig referenzieren. Und da ist so ein ganzes Ökosystem drumherum entstanden, vor allem um Open Source. Da gibt es eben Sicherheitsforscher, die aktiv auf Suche nach Sicherheitslücken gehen. Vor allem eben bei WordPress, weil es ein beliebtes Ziel ist. Es gibt eine Vorgehensweise, wie dann diese Sicherheitslücken gemeldet werden. Responsible Disclosure, also dass man eben nicht als Forscher sofort zu Social Media geht und sagt, hier guck mal, exploit und dann guckt, was passiert. Sondern die haben ja auch das, verfolgen ja eigentlich das Interesse, den, Nutzern Gutes zu tun, also möglichst eben diese schweren Sicherheitslücken zu finden, bevor es die, Bad Actors, also die bösen Menschen tun und entsprechend werden die Autoren, in dem Fall ich, privat informiert per E-Mail hier, wir haben was gefunden, behebt das doch mal bitte und dann gibt es eben so einen Prozess. Das war jetzt auch September 2025 nicht das erste Mal. Es gibt so ein Ranking-System, wie schwer die Sicherheitslücken sind. Die meisten sind eher trivial. In den meisten Fällen ist es irgendwas mit, hier ist irgendwie ein Inputfeld nicht validiert und wenn du schon Administrator bist und hier diese Schritte tust, dann kannst du irgendwie Unfug machen. Und die meisten sind eben mit, wenn du Administratorrecht hast und so weiter, und deswegen ein wenig relevant, wird natürlich trotzdem behoben.

Martin · 3:57 Okay. Also wie gesagt, die meisten Sachen sind Sachen, die man eigentlich nur machen kann, wenn einem die Website selber gehört, beziehungsweise man Zugriff zu dieser Website hat oder eingeloggt der User ist. Und genau, die werden dann behoben. Was war denn jetzt genau der Fall im September 2025? Also welchen, was wurde da entdeckt und ja, was war das?

Eric · 4:22 Ja, da wurde eine sogenannte RCE entdeckt, Remote Code Execution Lücke und das ist so, ja, das größte Tor, das man so aufmachen kann. Also genau gedacht, unauthenticated Remote Code, ich probiere es nochmal, unauthenticated Remote Code Execution. Unauthenticated hier das Wesentliche, nämlich eben, dass man ohne irgendeinen Account-Zugriff das Ganze ausführen kann und Code-Execution, also wirklich Code ausführen auf dem Server. Damit kann man mehr oder weniger den Server übernehmen, wenn der Angriff gelingt. Und das war hier der Fall.

Martin · 5:02 Und diese Lücke, die hat jemand gemeldet in diesem CVE-System, also sie hat irgendjemand gefunden und gemeldet?

Eric · 5:09 Genau, da gab es eben so einen Forscher, ich kenne mir bestimmt auch den Namen raussuchen, wenn ich es finde. Wir können ihn auch verlinken. Das kann man nachschlagen in diesen öffentlichen Verzeichnissen. Wenn die Person sich da im MCVE eingetragen hat. Genau, so eine Person, die es rausgefunden hat, die hier, ich weiß nicht, entweder aus Wordfans oder Patchstack, eben so ein Verzeichnis oder so ein System, wo das verwaltet wird und wo die Autron dann darüber informiert werden, hat das gemeldet. Und ich habe eine E-Mail bekommen, habe gesehen, okay, hier ist eine Sicherheitslücke, so funktioniert der Exploit, bitte fix das mal. Und ich muss dazu sagen, dass ich zu dem Zeitpunkt auch schon ziemlich CVE-müde war, weil eben ziemlich viel kommt. Was dazu führt, dass ich es beheben muss, weil ich es natürlich trotzdem auf jeden Fall innerhalb von 30 Tagen in der Regel veröffentlichen und ich muss natürlich beheben, bevor sie es veröffentlichen, weil sonst gibt es den Export öffentlich und das ist blöd für die Nutzer. Und mir war in dem Zeitpunkt nicht bewusst, was hier vormittig ist. Es stand natürlich drauf. Es hatte auch irgendwie eine Bewertung von 9, irgendwas. Aber wie gesagt, ich hatte irgendwie zu der Zeit auch wenig Zeit und ich habe es behoben, aber mir war nicht so richtig klar, was das für Auswirkungen haben wird.

Martin · 6:24 Weil die davor meistens so was waren wie, wenn du Administrator bist und eingeloggt bist, kannst du die Farbe des Players ändern. Gefühlt.

Eric · 6:31 In der Größenordnung.

Martin · 6:32 Ja, und dann wird man natürlich ein bisschen abgestumpft, wenn man dann laufend solche Nachrichten bekommt.

Eric · 6:38 Genau, und wie gesagt, ich habe das dann gelesen, Anfang September wahrscheinlich, da habe ich das auch lange vor mir hergeschoben, weil ich einfach überhaupt keine Zeit hatte zu dem Zeitpunkt. Irgendwann doch mal gefixt, dann irgendwann und still sogar veröffentlicht. Also ich habe den Fix released, ohne irgendjemandem Bescheid zu sagen. Also das ist wirklich nicht durchdacht, nicht geplant. Das Release war am 20. September, Version 4.2.7 und ich habe, weil ich mir auch nichts dabei gedacht habe, sofort auch, hier steht Wordfans war das, bescheid gesagt, hier, ich habe den Patches veröffentlicht, die Lücke ist geschlossen.

Martin · 7:18 Okay, also du hast es quasi repariert, hast ein Update veröffentlicht, die Version 4.2.7 vom Plugin und hast gleichzeitig mit dem Veröffentlichen oder kurz danach Wordfans Bescheid gesagt auf der Plattform, hey, jetzt ist es gefixt, alles super.

Eric · 7:35 Innerhalb von zwei Tagen haben die das dann veröffentlicht, weil gesagt, okay, alles abgeschlossen, wodurch quasi auch der Exploit öffentlich sichtbar, wurde, also in den Datenbanken.

Martin · 7:49 Bis dahin war nur für dich sichtbar oder für den, der das Plugin maintaint?

Eric · 7:54 Ja, theoretisch könnte ein Angreifer sehen, was der Exploit ist, sobald ich den Patch auf GitHub veröffentliche. Und das habe ich zu dem Zeitpunkt gemacht, als ich es im Publisher veröffentlicht habe. Aber da müsste schon jemand gezielt den Publisher im Visier haben. Die Angreifer haben aber sicherlich automatisierte Skripte, um eben diese CVE-Datenbanken zu überwachen und wenn dort solche schwerwiegenden CVEs veröffentlicht werden, dann sind die für die wirklich sofort sichtbar. Genau und am 22. September war es eben in den öffentlichen Datenbanken, CVE-Datenbanken sichtbar.

Martin · 8:34 Besonders hatten wir schon alle abgedatet.

Eric · 8:38 Ja, vielleicht kommen wir.

Martin · 8:40 Da kommen wir gleich dazu.

Eric · 8:41 Da kommen wir gleich dazu. Am 23. September, also drei Tage nachdem ich den Patch veröffentlicht habe, kam der erste Bericht im Sende-Gate, also unserem Forum, wo die ersten Leute sagten, es sieht so aus wie würdig, ich gehe hier gehackt, was ist denn hier los? Und dann kamen auch schnell andere, die meinten so, ja, ich auch und hier sind komische Dateien auf meinem System, was ist denn da los? Und dann da gingen dann bei mir erst so richtig die Alarmglöcken los also so richtig, auch drei Tage nach dem Release, ja, ich dachte eigentlich, ja Patch, alles klar, erledigt so wie die 10CV ist vorher, aber scheinbar war hier dann doch mehr dran, Ja, und bei dir auch, Martin, oder?

Martin · 9:27 Bei mir auch.

Eric · 9:27 Du hast dich dann auch bei mir gemeldet.

Martin · 9:29 Aber ich glaube nicht direkt im September. Ich habe dann auch nochmal geguckt, das war eher schon Richtung, es war schon vor Weihnachtszeit, wo es dann wirklich dramatisch bei mir war. Genau, kann ich nachher vielleicht noch ein bisschen was berichten. Aber wie gesagt, ich habe es nicht sofort bemerkt. Es war vielleicht ein bisschen, ich weiß nicht, ob es komisch war beim Einlocken, ob ich da noch irgendwas mache. Aber ich habe es, wie gesagt, nicht sofort in Verbindung gebracht.

Eric · 9:52 Okay. Ja, zu deinem Update-Thema. Also grundsätzlich, Patch veröffentlicht heißt ja nicht, dass alle Instanzen gefixt sind, sondern nur die, die den Patch auch installieren. Es gibt zwar so eine Auto-Update-Funktion von WordPress, aber die muss man aktivieren und die gibt es auch noch nicht so lange. Und ich glaube, zu dem Zeitpunkt hatte das kaum jemand aktiv für den Publisher. Ja, hätte in dem Fall geholfen, weil also die Auto-Update-Funktion innerhalb von 24 Stunden im Grunde hat man dann das Update. Ich glaube, die läuft nur ein- oder zweimal am Tag. Aber hier hätte es genug Vorlauf gegeben, als es ausgereicht hätte. Aber wie gesagt, viele hatten das gar nicht. Und das ist auch nicht die Schuld des Nutzers in dem Fall. Ich habe ein Rohr. Ich möchte nur darauf hinweisen, wenn es jetzt jemand noch hört, Auto-Update ist eine ganz gute Funktion für Plugins.

Martin · 10:48 Habe ich dann auch direkt angeschaltet später. Später, danach.

Eric · 10:53 Genau. Ja, das Drama ging dann noch weiter. Uberspace hat dann noch relativ Wellen geschlagen, weil, glaube ich, viele Publisher-Instanzen auf Uberspace gehostet sind. Und die haben dann richtig auch einen Incident-Report dazu gemacht. Die haben mich angeschrieben und mit mir so ein bisschen überlegt, Mich gefragt, was in der Angriff ist und wie sie sich schnell dagegen schützen können. Ich habe da mit denen zusammengearbeitet. Wie sie quasi ihre Instanzen auch ohne das Update sicher bekommen. Und sie haben ja auch dann quasi so zugeschickt, die Details, wie die Angreifer das ausnutzen, Ich als Autor sehe ja nicht, wie die Angriffe selbst ablaufen. Ich sehe nur die Berichte von Nutzern, die. Berichten, was passiert. Ich musste mich da auf die Berichte von Nutzern verlassen, um zu sehen, okay, hier werden richtig die kompletten WordPress-Instanzen, die Server aufgemacht, ja, Webshells abgelegt, also die kompletten Server übernommen, mehr oder weniger. Je nachdem auch, wie die einzelnen Server konfiguriert sind. Aber ja, da war dann zu dem Zeitpunkt klar, das war wirklich Worst-Case-Szenario für diejenigen, die betroffen sind. Da hilft nur Backup einspielen in der Regel. Also Server platt machen, Backup einspielen und hoffen, dass das letzte Backup nicht zu lang zurück lag.

Martin · 12:24 Genau, das war dann nämlich bei mir tatsächlich der Fall. Also das komische Verhalten, was ich dann bemerkt habe, war irgendwie Login-Schwierigkeiten oder Plugins. Plugins waren deaktiviert, glaube ich, auf einmal. Und dann haben wir ja irgendwie auch rausgefunden, dass eben dieser Angriff stattgefunden hat. Und dann ging es eben darum, wie kann man ein Backup einspielen und ich bin auch bei Überspace gehostet. Und dann weiß ich noch, dass du gesagt hast, es muss auf jeden Fall irgendwie Anfang, Mitte September sein, also bevor die Veröffentlichung gewesen ist. Weil bis dahin wurde das quasi nicht ausgenutzt. Da war es zwar existent, aber wurde nicht ausgenutzt. Und ja, da ging es erstmal darum, irgendwie ein Backup zu finden, dass das diese Daten wieder beinhaltet. Und seitdem ist ja auch bei vielen Webseiten, bei meiner auch, ja auch viel passiert. Also man hat irgendwie Sachen veröffentlicht. Dann gab es irgendwie Kommentare. Dann könnte man nochmal überlegen, ob das jetzt Teil des WordPress ist oder der Datenbank. Ich kann, glaube ich, gar nicht sagen, ob die Datenbank betroffen war. Ich glaube, so wie es aussieht, war die Datenbank nicht betroffen. Weiß nicht, ob du da Erfahrungsberichte bekommen hast. Also die SQL-Datenbank hätte man weiter benutzen können, aber ich möchte jetzt auch nicht die Hand für uns vorlegen, dass es dem so ist.

Eric · 13:33 Ja, möglich. Und das kann auch im Einzelfall anders sein. Aber vielleicht ist es ganz gut, mal kurz darauf einzugehen, wie diese Angriffe überhaupt ablaufen. Also das Angriffstor hier war, dass wirklich Angreifer eine Datei auf dem Server, eine beliebige Datei auf dem Server ablegen können. Also hier konkret im Builder-Cache-Verzeichnis. Und das ist meist eine relativ kleine Datei, die dann erstmal andere Dateien vom Bot-Netzwerk der Angreifer runterladen. Und das sind dann in der Regel Webshells, also wirklich im Prinzip ein Dateibrowser für den Server, die die Angreifer über, die einfach eine Webseite der Oberfläche benutzen können und da dann beliebig manuell Dateien hochladen, angucken, löschen, verändern können. Die Dateien breiten sich dann meist auch beliebig aus auf dem System, sodass man nicht sagen kann, okay, ich habe jetzt hier eine Datei gefunden, ich habe die gelöscht, dann ist alles wieder gut. Ja, die belegen dann meist auch Backups an, weit verzweigt, schwer zu identifizieren. Vor allem eben, war das so schon angedeutet vorhin, über das Erstellungsdatum. Also mir ist wirklich nicht bekannt, dass vor dem Zeitpunkt das ausgenutzt wurde. Das heißt, wenn man es irgendwie relativ konkret auf Mitte September eingrenzen konnte, dann war es relativ deutlich. Ja, und im Prinzip, wenn man so eine Datei auf seinem System gefunden hat, konnte ich nur sagen, ja, sorry, Backup einspielen, Server platt machen, andersrum, Server platt machen, Backup einspielen. Ansonsten kann man nicht sicher sein, dass nicht noch irgendwas irgendwo rumliegt. Und der Exploit, den gibt es grundsätzlich seit, keine Ahnung, zehn Jahren, müsste ich nachgucken, seit es das System gibt. Es wurde halt erst jetzt gemeldet. Vielleicht auch ein interessantes Detail. Ja, also die Lücken existieren so lange, bis es jemand meldet und es dann gefixt wird. Hier existiert es wirklich, seit es dieses Image-Cache-System gibt.

Martin · 15:41 Jetzt muss ich aber auch mal fragen, der jetzt nicht so tief drinsteckt, wie kriegt man denn jetzt diesen Code überhaupt auf die Seite, also gibt es jetzt keine Adresse, wo ich sage, hier, ich schicke den Code an diese Domain und dann liegt er da in dem Image Cache Ordner, wie kommt, der denn in diesen Ordner auf dem Server?

Eric · 16:01 Genau, dann lass uns doch jetzt mal über den den Exploit sprechen, weil das muss erklären, was die Lücke ist und das macht dann klar, wie die Datei dorthin kommt. Und zwar, also welches Modul ist betroffen? Der Bilder-Cache oder ja, das Bilderverwaltungssystem im Publisher. Wozu braucht der Publisher das? Ja, man hat ja so ein paar Bilddateien wie das Podcast Cover zum Beispiel oder auch Kontributorenbilder, die vermutlich irgendwo auf einem FTP rumliegen mit den Episodendateien, weil der Publisher so grundsätzlich so konzipiert ist. Also mittlerweile kann man es ja auch zu WordPress hochladen, aber original war es so gedacht, dass alle Dateien irgendwo auf einem FTP liegen. Der Publisher nur weiß, wo die Dateien liegen und die dann nur verlinkt oder damit arbeitet. Damit ich aber so Bilddateien zum Beispiel klein rechnen kann, weil die sind ja meist irgendwie 3000x3000 Pixel und ich möchte die nicht so groß in die Webseite einbinden, dann muss ich sie irgendwie klein rechnen. Damit das geht, brauche ich die Dateien auf dem Server. Das heißt, ich muss die Dateien auf den Server laden. Wichtig ist, die Datei liegt irgendwo anders und ich muss sie auf den Server laden. Wie macht der Bild-Cache das? Ich konstruiere so einen Link, wo die Bild-URL drinsteht. Also es ist enkodiert, aber es ist, kann man mal raussuchen, egal. Es steht so eine URL, wo irgendwie slash image und dann steht dann auch. Die Breite und Höhe, die man gerne haben möchte und eben enkodiert die URL der, Original-Bilddatei drin. Und darüber lädt der Publisher die Datei auf den Server und sobald sie dort liegt, gibt es auch eine quasi statische Bild-URL, aber das können wir ja für den Fall ignorieren, weil, ja, können wir ignorieren. Das Wesentliche ist ja diese dynamische URL, wo die Bild-URL mit drinsteht. Der Publisher macht natürlich so ein paar Prüfungen. Hey, ist diese URL, sieht die aus wie ein Bild? Ist das ein Bild? So ein paar Checks. Ich habe mich da aber auf quasi so PHP, es gibt PHP-Funktionen, die heißt isImage, also ist das ein Bild und mehr oder weniger habe ich mich darauf verlassen. Und die kann man aber relativ leicht austricksen. Also man kann als Angreifer, eine Datei und eine URL generieren, wo diese isImage-Funktion sagt, ja, ist ein Bild und dann wird das runtergeladen und dann ist das aber eine PHP-Datei, die eben in diesem Image-Cache-Verzeichnis liegt. Und weil das AdMitchCast-Verzeichnis öffentlich ist, kann der Angreifer einfach, sich berechnen, quasi wie diese URL heißt. Und kann die dann aufrufen und hat dann eine PHP-Datei auf deinen Server geladen und kennt auch die URL, um diese PHP-Datei aufrufen zu können. Und das ist schlecht. War das verständlich, so halbwegs?

Martin · 19:17 Ja, also, es ist trotzdem faszinierend, dass man das von außen steuern kann und dass der, weil ich, ich stelle mir das immer so vor, der Publisher, das Plugin ist halt irgendwie so self-contained innerhalb von WordPress und da kommt keiner ran. Das, was der da errechnet und erzeugt, das ist erstmal nicht angreifbar oder zugreifbar. Also man braucht dann wirklich Zugriff irgendeiner Form auf dieses Plugin, auf den Code.

Eric · 19:43 Ja, also ich meine grundsätzlich ist jeder Nutzer, jede Nutzereingabe ein potenzielles Einfallstor. Also von einem kleinen Inputfeld in einer Settings-Seite, wenn da nicht ausreichend Schutz drumrum ist, kann man damit Unfug machen, weil es zum Beispiel an eine Datenbank geht und wenn ich da nicht aufpasse, kann ich auf einmal SQL-Queries in die Datenbank schicken. Aber auch da natürlich, dazu bräuchte man erstmal Administrationszugriff, weil diese Settings-Seiten gibt es natürlich öffentlich nicht. Aber diese URL in dem Fall ist eben auch eine Nutzereingabe, die hier nicht zur Datenbank führt, aber eben aufs Dateisystem. Und grundsätzlich gilt natürlich, den Nutzer irgendwelche URLs eingeben zu lassen und die dann aufs Dateisystem zu laden, ist eine schlechte Idee. Und war mir vermutlich, ich weiß nicht, wann ich das geschrieben habe, 2014, 2016. Jugendlichen leicht. Ich war da noch in einer anderen Phase von zum einen Softwareentwicklungswissen, als auch, bei mir ging es ja erstmal darum, hier ein Produkt zu bauen, was irgendwie nützlich ist und hatte ja vielleicht nicht alle Eventualitäten im Kontext. Ich will das hier nicht entschuldigen. Ich sage nur, ja, ich habe da nichts gebaut. So ist es entstanden. Ich will da jetzt nur sachlich zurückgucken, mich nicht irgendwie verteidigen. Das ist halt so.

Martin · 21:12 Also wie es gesagt hat, ist es so, man konfrontiert den Server mit einer URL, die aussieht, als würde der Publisher hier ein Image-Cache anlegen. Dahinter steckt aber kein Bild, sondern ein Schadcode, der dann eben in diesem Verzeichnis abgelegt wird. Das ist so verkürzt korrekt.

Eric · 21:30 Ja also der normale weg ist eben ich sage hier ist cover punkt png, Und das legt das da mal ab und dann sagt der Angreifer aber, hey, nee, hier ist Cover.php und sieht aber aus wie ein Bild und legt das dann trotzdem ab.

Martin · 21:51 Okay ich habe gerade auch nochmal geguckt, also ich habe tatsächlich auch im September am 24.09.26.9 hatte ich schon das Problem und dann habe ich ein Backup zurückgespielt, und dann hat es mich aber im Dezember nochmal getroffen weil ich glaube das Zurückspielen des Backups, bei Überspace hat nicht, hat so ein Merch gemacht und nicht so ein clean, ich lösche erstmal alles und dann kopiere ich wieder an. Das haben wir zwei dann, glaube ich, noch rausgefunden. Und deswegen waren zwar die Dateien erstmal wieder korrekt, aber es waren einfach schon mehr Dateien nach wie vor drin, weil die infizierten Dateien weiterhin dort lagen. Und haben dann quasi über den Herbst weiter Quatsch gemacht und im Dezember war es dann so akut, dass ich dann radikal rangehen musste und quasi neuen Server aufsetzen musste und alles mit einem clean Backup zurückspielen musste. Ja, das war der Fall. Ich habe gesehen, hier 26.09. habe ich über Space geschrieben, 24.09. habe ich, glaube ich, mit dir auch Kontakt aufgenommen. Das war dann genau der Zeitraum. Und dann hat es mich am 18.12., also sechs Tage vor Weihnachten, habe ich dann Server neu aufgesetzt. Oder über die Feiertage.

Eric · 23:08 Vor nicht Weihnachten.

Martin · 23:09 Ja, das war ein schönes Fest, ja.

Eric · 23:14 Ja.

Martin · 23:14 Genau, vielleicht können wir noch mal kurz drüber sprechen. Wir haben ja dann auch, uns überlegt, was hätten wir denn anders machen können oder wie hätten wir anders kommunizieren können, sowohl öffentlich als auch Richtung von Wordfans der CVE-Verwaltungsseite. Und du meintest, oder man konnte es quasi auf den Nenner bringen, wir wollten zu schnell das Richtige machen und das hat dann quasi in die falsche Richtung geführt.

Eric · 23:45 Ja, verschiedene Aspekte. Also zum einen Kommunikation von mir aus war quasi ja nicht da. Also ich habe am, 27. September, gepostet in unserem Forum, wo ich das wirklich zusammengefasst habe und auch mit hier, das müsst ihr tun, das kann passieren. Also das Advisory nennt man das Security Advisory. Das, was ich eigentlich schon sofort hatte machen müssen. Und es war dieses Einzige. Und ich habe auch irgendwie auf Mastodon gepostet, aber auch viel zu spät. War einfach sehr unkoordiniert, weil mir, wie gesagt, zum Anfang die Tragweite gar nicht bewusst war. Und eben auch, was du angesprochen hast, mit MidBread-Fans vielleicht absprechen oder einfach nicht sofort Bescheid sagen, dass es behoben ist. Was ich gemerkt habe, das muss nicht unbedingt helfen. Ich habe mittlerweile auch schon ein paar kleinere zwischendurch gefixt und vergessen, ihnen Bescheid zu sagen. Und die haben trotzdem geschrieben, hey, wir haben gesehen, du hast gepatcht, alles klar.

Martin · 24:55 Weil unsere Idee dahinter war quasi, wir geben erstmal den Userinnen und Usern Zeit, dieses Update, zu installieren oder vielleicht auch Zeit zu lassen, dass die automatische 24 Stunden, ich installiere es automatisch, Funktion von WordPress greift, und nicht jeder sitzt ja dann gebannt vor seinem Rechner und verfolgt, was Podlove irgendwo veröffentlicht, sondern ist vielleicht auch mal im Urlaub, ist auf Reisen, macht vielleicht seinen Podcast auch nur einmal im Monat, loggt sich da ein, sieht, oh, hier ist ein Update, installiere ich mal. Und genau, viele sind halt irgendwie Hobbyprojekte oder semiprofessionelle Projekte, die jetzt auch nicht jemanden abgestellt haben, der da alle Plugins ständig im Blick behält. Und so kam es eben, dass es eben mehr als 24 Stunden waren, bis dann vielleicht Leute auch installiert haben.

Eric · 25:42 Ja, wir können ja mal prüfen, ob ich es besser gemacht habe.

Martin · 25:46 Genau, eine Sache zuvor noch Richtung Kommunikation. Ein Punkt, weswegen wir vielleicht auch gesagt haben, wir müssen gar nicht so viel erklären. Natürlich mehr erklären ist immer gut. Aber Überspace hat einen relativ guten Artikel geschrieben, relativ schnell am 26. September hat der Jonas geschrieben unter dem Titel, was wir gegen Potlove-Exploits tun. Also wir haben es in die Headlines vom Überspace-Blog geschafft. Und da hat er wirklich sehr detailliert beschrieben, wie dieser Angriff stattfindet, was sie getan haben, was man jetzt tun sollte. Und genau, das war, glaube ich, auch hilfreich, da so ein bisschen Ruhe reinzubringen und einen Verweis zu haben auf was hier. Guckt mal, lest euch das mal durch, weil das wirklich sehr gut geschrieben war aus Sicht von einem Serverbetreiber.

Eric · 26:34 Ja, auf jeden Fall, Überspace hat da richtig gut kommuniziert. Also deutlich besser als ich an der Stelle.

Martin · 26:43 Okay, jetzt… Auf jeden Fall Daumen hoch. Das war die Generalprobe sozusagen. Ja, beziehungsweise war schon die erste, war schon die U-Aufführung und dann gab es aber noch eine zweite Aufführung.

Eric · 26:55 Genau, zweite Aufführung begann im Juni 2026. Da ging es erneut los. Da habe ich eine Nachricht bekommen und ich dachte schon Déjà-vu. Ja, Exploit im Imagecache. War es jetzt wieder genau das gleiche? Habe ich vergessen den Bug zu fixen? Nee, das war, im Grunde schon. Also der Exploit ging wieder über genau diese gleiche Funktionalität mit der Image Cache URL, nur war es hier noch ein bisschen, ich sag mal pfiffiger und ein paar mehr Umwege, um quasi die bestehenden Prüfungen auszutricksen. Also hier wurde was ausgenutzt, dass ich, beim Ablegen der Datei und beim Validieren der Datei nicht exakt die gleichen, Verifikationen und Sanitation-Funktionen für den Pfad verwendet habe. Also ja, muss man jetzt vielleicht nicht in die Session-Datei gehen, ich will nur sagen, der Angriffsvektor war in etwa der gleiche, aber brauchte noch ein paar Ecken und Kanten, um das ausführen zu können, aber der Effekt war im Grunde der gleiche. Ich habe mir dann auch Zeit genommen, wirklich mal zu überlegen, in welcher Reihenfolge ich was kommuniziere. Den Fix hatte ich auch wieder relativ bald, aber nicht sofort veröffentlicht, sondern habe mir ein paar Tage genommen, um zum einen so ein paar auch Nachrichten schon vorzubereiten und ein bisschen recherchieren, wie man das eigentlich macht. Zum Beispiel irgendwie, ich hätte ja gedacht, irgendwie öffentlich zu schreiben, hier, an dem und dem Tag, haltet euch mal bereit. Auf den Update-Button zu drücken. Stellt sich raus, das sollte man eher nicht tun, weil natürlich auch Angreifer sofort vor diesem Tag werden könnten. Ja, genau. Habe ich da entsprechend nicht gemacht. Ich will nur sagen, ich habe mich informiert. Ich habe ein paar Überspace zum Beispiel privat informiert, also direkt angeschrieben, Hier ist was. So könnt ihr euch vorbereiten. Ah genau, das habe ich auch gemacht. Ich habe quasi ein Security-Guide veröffentlicht in der Dokumentation und auf Masso dann verkündet, wo man sich so ein bisschen über Web-Server, also Nginx oder Apache-Konfigurationen, das Cache-Verzeichnis absichern kann. Nicht gesagt, dass es vor einem Exploit schützt, aber wer auch immer das getan hat, hat sich quasi effektiv gegen diesen Exploit geschützt. Man kann zum Beispiel über Webserver sagen, hey, dieses Verzeichnis, da darf keine PHP-Datei ausgeführt werden, was dazu führt, dass der Angreifer zwar die PHP-Datei dort ablegen kann, aber nicht ausführen. Und an der Stelle endet dann der Angriff erfolglos. Genau das habe ich gemacht. Genau, und dann kam aber doch der Tag, wo ich es veröffentlicht habe, Release veröffentlicht, habe sofort das Ganze auf Mastodon gepostet, ich habe einen Blogpost dazu veröffentlicht, weiß nicht, ob es noch auf Sende geht, aber auf jeden Fall Blogpost sofort und Mastodon Post sofort. Ah ja, erschwerend kam hier noch hinzu, dass, ja, WordPress hat zwar ein Auto-Update, aber durch diese ganzen Supply-Chain-Attacks durch KI getrieben, also Angriffe auf alle möglichen größeren Paketsverzeichnisse und dazu gehört auch das WordPress-Plugin-Verzeichnis, hat WordPress das Auto-Update für die ersten 24 Stunden ausgesetzt, für alle Plugins. Das heißt, man sieht das Update erst nach 24 Stunden. Was es hier schwerer macht, weil ich möchte ja, dass die möglichst schnell aktualisieren. Und selbst wenn sie mein Mastodon-Announcement gesehen haben, sehen sie das Update im WordPress-Backend nicht. Das Einzige ist, also entweder manuell hochladen, also quasi zu WordPress gehen, das Plugin runterladen, das ZIP und dann auf der eigenen Webseite hochladen, oder über das Command-Line-Tool, also WP-Command-Line-Tool, aber es ist halt sehr nerdig. Und selbst das Hochladen ist ein Problem, weil häufig die WordPress-Instanzen gar nicht dazu konfiguriert sind, solche großen Dateien zu erlauben. Ja, das war doof an der Stelle. Hat das Ganze nochmal für die Nutzer um 24 Stunden quasi enger gemacht.

Martin · 31:45 Aber ist es dann so, dass nach 24 Stunden, wenn es dann sichtbar wird, dann wird das Auto-Update ausgeführt oder ist es dann immer noch so, dass dann je nach Installation, der sagt, in den nächsten 24 Stunden installiere ich es jetzt dann aber auch erst, also dass dann maximal 48 Stunden vergehen können oder ist dann nach diesen 24 Stunden, wissen dann alle Instanzen, die das angeschaltet haben, jetzt mache ich es dann auch?

Eric · 32:05 Ich vermute eher die 48-Stunden-Variante, weil dieses Auto-Update ist so ein Cron-Job, so ein WordPress-Cron.

Martin · 32:11 Und je nachdem, wie das Server kontrolliert ist, wann der aufgesetzt wurde, wann das Plugin installiert wurde, wann das angeschaltet wurde, dann greift quasi diese 24 Stunden, in denen es dann ausgeführt wird.

Eric · 32:19 Ja.

Martin · 32:21 Okay, also jetzt für den nächsten Angriff schon wieder gelandet, 48 Stunden warten, bevor irgendjemandem Bescheid sagt. Also beziehungsweise bevor man es öffentlich ... Ja.

Eric · 32:32 Ich weiß nicht, ob dieser Schutz jetzt auch noch da ist.

Martin · 32:35 Also das haben sie bloß gemacht in dem Zeitraum, wo es uns getroffen hat.

Eric · 32:41 Womöglich, ja. Also es ist grundsätzlich, vielleicht war es auch permanent, ich müsste es nachgucken, ich weiß nicht, ob es jetzt noch drin ist, aber grundsätzlich, auch wenn man als Entwickler mit solchen Verzeichnissen arbeitet, mittlerweile ist, man spricht ja von einer Cooldown-Period, also man, lädt nur Patches, die schon mindestens ein gewisses Alter erreicht haben, in der Regel sogar irgendwie eine Woche oder so. Weil man dann davon ausgeht, dass wenn da, also da geht es darum, dass Angreifer das Plugin oder das Paket übernehmen und in das Plugin selbst Schadcode einschleusen. Das soll damit hier verhindert werden. Und in der Regel wird sowas innerhalb von 24, 48 Stunden entdeckt und deswegen sagt man, okay, wir erlauben das herunterladen erst nach dieser Zeit. Also das ist schon okay, diesen Schutz, den WordPress da macht, macht es nur für solche dringenden Exploits schwieriger. Ich habe sogar WordPress, glaube ich, geschrieben, als ich das mitbekommen habe, dass es dieses Problem gibt. So mit, hey, hier könnt ihr mal eine Ausnahme machen. Und wir haben dann auch geschrieben, ja, wir haben jetzt diese Ausnahme für euch hinzugefügt, aber es hat nicht funktioniert. Also ich habe da nicht nochmal zurückgeschrieben. Aber ich habe es geprüft bei uns, Podlover, Specend. Da habe ich es tatsächlich unsicher gelassen, weil ich wollte das Verhalten sehen. und ich hatte quasi diesen. Nginx-Schutz drauf, also quasi, dass die Angreifer zwar die PHP-Datei ablegen können, wenn sie wollen, aber nicht ausführen können. Also es war nur so halb angreifbar. Und das war dann im Grunde auch so das Ausmaß des Angriffs. Also es kamen dann so ein paar Meldungen, weil auch mit diesem fix war es tatsächlich noch möglich, diese PHP-Dateien teilweise abzulegen. Der Angreifer konnte nur nichts damit machen. Auch natürlich schlecht, aber in dem Zustand habe ich den fix veröffentlicht. Dann kamen relativ schnell Hoster, die so automatische Virenscan- Erkennungsprogramme, haben, irgendwie eins und eins, wie heißen die? IONOS war dann großer, die dann quasi ihre Nutzer Bescheid gesagt haben, hey, hier liegt was rum, kümmere dich mal bitte. Sodass ich da auch noch ein Patch nachgeschoben habe. Hätte ich auch sofort machen müssen, ich weiß nicht. Ich hatte irgendwie zu dem Zeitpunkt keine bessere Idee. Die kam mir dann, als ich die Idee haben musste. Wie ich grundsätzlich dieses ganze Einfallstor ein bisschen zumachen kann. Weil auch dieser, da haben wir glaube ich noch gar nicht drüber gesprochen, also was war der zweite Fix hier? Ich habe hier auch wieder nur mehr Validierungen gemacht. Bessere Prüfungen der URL des Bills. Mehr Prüfungen in die Datei reingucken, mehr WordPress-Funktionen nutzen. Also wie auch, ich habe geguckt, was WordPress selbst für Prüffunktionen verwendet, wenn man da was hochlädt. Also über dieses WordPress-Media-Tex-Funktionen, die haben ja ihre eigenen Qualidierungen quasi auch, dass da kein Unfug hochgeladen wird, habe da sowas verwendet. Mime-Type-Checks, Dateiänderungen, solche Geschichten. Hat aber grundsätzlich das Tor noch offen gelassen, nur eben unattraktiv gemacht für Angreifer. Die Idee, die mir dann kam, als ich quasi die Leute gesagt habe, hey, die liegen immer noch PHP-Datei rum, ist es doof. Ich habe mir halt überlegt, wie kann ich es überhaupt, oder der hat mir die, Mechanik mal insgesamt angeguckt und hinterfragt. Das Problem ist, dass halt diese URLs überhaupt manipuliert werden können. Also der Publisher erzeugt halt diese Bilder, dynamischen Bilder-URLs und der Angreifer kann halt so eine nehmen und ein bisschen anpassen, sodass dann quasi er seine Angriffs-URL da reinpacken kann. Und der Fix, den ich mir ausgedacht habe, ist, die Datei, die URL zu signieren. Ja, also das ist ja der Fix gewesen. Hätte ich auch schon sofort machen können, ich hatte nur die Idee nicht. Signieren heißt was? Ich hänge quasi, mache die Datei, die URL ein bisschen länger, ist noch Slash und dann noch ein bisschen mehr Zeichen hintendran, was die Signatur ist. Das heißt, jeder, also der Publisher selbst erzeugt jetzt diese URLs, also die werden jetzt nicht mehr quasi dynamisch nur zusammengestückelt mit hier Bild hier, Breite hier Höhe, sondern der Publisher erzeugt die und signiert die eben mit diesem Teil hintendran. Dazu wird ein interner Schlüssel verwendet. Es gibt einfach von WordPress selbst ein paar Schlüssel, die stehen in der wp-config. Die sind für jede Instanz einzigartig. Und es sorgt eben dafür. Dass die Build-URL, wenn der Publisher versucht, die aufzulösen, Ich gucken kann, ob die Signatur noch stimmt. Das heißt, wenn jemand die URL nimmt, die Signierte, und da die URL ändert, dann sieht jetzt der Publisher, dass die Signatur nicht mehr stimmt und sagt, geh weg. Und das ist der eigentliche Fix hier an der Stelle, der die ganze Klasse von, Angriffen verhindert. Also ja, das hätte ich schon viel eher machen müssen.

Martin · 38:27 Aber hat man dann vielleicht auch nicht den Kopf in dem Moment, wo dann erstmal dieser Exploit gefixt werden muss und dann denkt man vielleicht auch erstmal, jetzt löse ich erstmal dieses Problem und hat gar nicht die Ruhe, überhaupt auf diese Idee zu kommen, könnte ich mir vorstellen.

Eric · 38:43 Ja, ich habe noch eine andere Idee, dass überhaupt gar keine URLs mehr, in den URLs drinstehen, also keine die Bilder-URLs, aber das würde deutlich mehr umschreiben von Code erfordern, wo ich einfach die Zeit nicht gehabt hätte. Könnte ich immer noch machen, aber ich glaube, jetzt ist es nicht mehr notwendig, wo diese Signaturgeschichte existiert. Ja, vielleicht, wenn jemand denkt, dass auch die Signatur umgehbar ist, kann er mir gerne schreiben, dann baue ich es nochmal richtig. Ich möchte es aber gerne umgehen, weil das wäre wirklich sehr viel Aufwand, die andere Idee, die ich da hatte. Ja, aber vielleicht ist das Thema ja doch jetzt damit abgeschlossen.

Martin · 39:27 Wie waren denn so Reaktionen, die jetzt leider auch dich erreicht haben? Ich habe festgestellt, es gab viel Verständnis und natürlich auch Ärger, dass vielleicht jetzt die eigene Website angegriffen wurde und man da jetzt entweder sehr viel Arbeit damit hat oder, im schlimmsten Fall dann Totalverlust der Website steht, wenn man kein Backup hat, aber ich habe aber auch viel Verständnis. Verständnis wahrgenommen für die Reaktion darauf und dass du dich vor allem dann gekümmert hast und bemüht hast, aber wie hast du es erlebt und hast du gedacht, jetzt am liebsten wir die alles hinschmeißen oder gab es diesen Moment?

Eric · 40:08 Ne, war vorwiegend positiv, also von meiner Seite. Also wirklich verständnisvoll. Es gab die ein oder andere holprige E-Mail, klar, wenn man aus dem Frust heraus, sich dann sagt, okay, jetzt schreibe ich doch mal dem Maintainer irgendwie um Hilfe und habe aber irgendwie schon da irgendwie zwei Stunden rumgefummelt und habe irgendwie Angst um meinen Podcast, dann ist man nicht in der besten Lage, eine nette E-Mail zu formulieren, das verstehe ich schon. Ja, nee, viel Verständnis, keine Ahnung, Morddrohung oder was man sonst so für, Quatsch hört von anderen Open-Source-Maintainern, ja, also gibt's alles.

Martin · 40:45 Wirklich, okay, schlimm.

Eric · 40:47 Ja, ja, also was Open-Source-Maintainer ist, aber hier die Community ist, war vorwiegend verständnisvoll und natürlich war Frust da, also gerade. Irgendwie Posts auf Mastodon, die jetzt nicht an mich direkt gerichtet waren, sondern nur so ins Nirvana waren schon viel Frust. Aber natürlich habe ich viel Frustverständnis, weil es schon scheiße ist. Kann man nicht anders sagen.

Martin · 41:17 Ich kann vielleicht nochmal kurz berichten aus Sicht von mir, einem Nutzer, der jetzt nicht Informatik studiert hat oder jahrelang programmiert hat, sondern sich das, was er halt gebraucht hat, um einen Podcast zu veröffentlichen, autodidaktisch beigebracht hat und dann, geguckt hat, ah, das muss ich hier auf der Kommandozeile machen, ah, so richte ich dann quasi bei Überspace den Server ein und das, so ein bisschen selber mir beigebracht habe. Und dann steht man natürlich schon erstmal da und denkt, oh Gott, was mache ich jetzt und ist jetzt alles weg und natürlich auch so Gedanken, schmeiße ich jetzt alles hin und sage, oh Gott, lass es, ich brauche das Ganze irgendwo anders neu auf, ich gehe zu irgendeinem Hoster, aber es war halt schon immer auch der Anspruch von mir und ich glaube, das ist auch von vielen, die Podlove nutzen, der Anspruch, dass man das eben selber unter Kontrolle hat und damit sowohl die Vorzüge, aber dann eben auch die Verantwortung hat, dass es läuft und was mir da immer Sicherheit gibt oder zumindest hilft, da wieder Sicherheit zu gewinnen ist. Auch erst mal zu überblicken oder auch in einer ruhigen Minute mal zu gucken, wo komme ich denn ran, wenn was passiert? Also wo liegen meine Backups? Wie funktioniert das? Wie kann ich ein Backup wieder herstellen? Vielleicht auch einfach mal auf dem FTP-Server gucken, ah, das ist der Ordner, wo die Sachen drin liegen. So komme ich da hin, so erkenne ich das. Sich einfach auch nochmal vertraut zu machen mit seiner Umgebung, soweit es geht. Entweder ob man jetzt bei Überspace direkt selber draufkommt oder bei einem, Anbieter wie Jonas oder im Hetzener All Inkel, dass man irgendwie guckt, wie sind da die Wege, wenn was wäre, wenn ich was machen müsste, was muss ich tun? Es war letztendlich dann auch eine Kombination, wie ich es dann über Weihnachten hinbekommen habe, aus... Dem Überspace Backup, ich habe dann mit Alex aus unserem Team auch nochmal konferiert, wir haben dann nochmal so, ich glaube Abtraft heißt das, auch so eine Backup-Lösung für WordPress, damit haben wir dann, die Datenbank gesichert und letztendlich haben wir dann entschieden, wir machen jetzt einen, educated guess, dass die Datenbank nicht kompromittiert ist und setzen einfach ein neues WordPress auf und spielen die Datenbank zurück und hoffen, dass dann alles okay ist. Das war in dem Fall auch so. Gleichzeitig kam von Überspace der Hinweis im Vorfeld, ja, der Server ist jetzt eigentlich durch. Mach doch mal einen neuen Server, wird mir dir sehr stark raten. Und dann habe ich quasi das alles nochmal durchgespielt. Also neuen Server aufsetzen, dann die Domain umleiten beim Registrat, das das dann wieder auf Staatsbürgerkunde zeigt in dem Fall und dann das Backup einspielen. Also das waren schon alles Schritte, die ich mal gemacht habe, aber die ich natürlich auch nicht jedes Jahr mache oder jeden Monat und da musste ich mich dann auch wieder rantasten, aber. Als es dann eh quasi zu spät war, hat man dann auch auf einmal wieder die Ruhe zu sagen, okay, jetzt geht es Schritt für Schritt durch und dann ist der Server jetzt eben mal fünf Tage nicht erreichbar und danach geht es aber wieder. Das hat mir dann wieder Ruhe gegeben. Und beim zweiten Angriff hattest du ja den Tipp, oder das hast du ja auch gerade erklärt, dass zwar Files abgelegt werden konnten, aber die nicht ausführbar waren. Das heißt, ich habe da auch wieder auf dem FTP-Server in diesem Cache-Ordner habe ich die komischen Files gesehen. Aber dein Hinweis war dann, lösch einfach diesen Ordner und dann sollte es eigentlich okay sein, wenn das Plugin upgedatet wurde. Und so war es dann auch. Genau. Also, ja, es war eine Kombination aus Dingen, die dann bei mir zum Erfolg geführt hat, aber genau, sich vertraut machen mit seiner eigenen Infrastruktur ist, glaube ich, immer erstmal ein guter Hinweis, auch in guten Zeiten.

Eric · 44:45 Ja, aber hat, wie du schon sagst, wie auch bei dir, bei vielen dazu geführt, dass sie mal hinterfragt haben, ob sie sich das noch zutrauen wollen mit der Infrastruktur.

Martin · 44:55 Ob es das wert ist.

Eric · 44:57 Einige sind, gut, ich habe ein paar Nerds gesehen, die sagen, okay, jetzt mache ich mir ein statisches Podcast-Hosting-System. Das ist natürlich die nerdige Antwort mit, ich mache es einfach selbst. Ein paar sind auch zu hostern gegangen auch nachvollziehbar, gerade wenn man irgendwie das nicht nur als Hobby betreibt oder je nachdem auch als Hobby aber insbesondere vielleicht wenn man das professionell betreibt und darauf angewiesen ist dass es einfach läuft, jetzt gehe ich doch zu einem Hoster und habe diese Sicherheitsthemen nicht, Ja, alles, natürlich volles Verständnis von meiner Seite. Es ist keinem übel zu sagen, dass sie keine Lust mehr haben auf Selbsthosting. Das ist einfach ein ganz normaler Prozess, muss jeder für sich selbst entscheiden. Klar, Selbsthosting ist viel mehr Aufwand, muss man wollen, muss man abwägen. Ja, ich hoffe, dass zumindest diese Lücke jetzt zu ist, aber ich arbeite weiter an Sicherheitsthemen.

Martin · 45:58 Genau, was ist denn deine Strategie jetzt für die Zukunft? Also du hast es schon mal am Anfang angeklungen, das habe ich auch so wahrgenommen. Durch die gebündelte Macht der KI wird jetzt auch sehr viel Software generell unter die Lupe genommen und ganz viele Exploits gefunden, die ein menschlicher Forscher, Forscherin vielleicht gar nie oder nur mit sehr viel Aufwand gefunden hätte. Aber durch dieses automatisierte Prüfen von Software, von Plugins, findet man jetzt einfach auch mehr. Das ist natürlich einerseits gut, aber andererseits setzt es natürlich auch die Entwickler sehr stark unter Druck, wenn dann immer automatisch gleich ein CVE erzeugt wird, der binnen 31 Tagen dann gefixt werden will, bevor er veröffentlicht wird.

Eric · 46:37 Ja, also meine Vermutung ist auch schon, dass der zweite CVE mit KI-Unterstützung gefunden wurde. Es ist nur eine Vermutung von mir, weiß ich natürlich nicht, aber einfach ein Beispiel des Textes, den ich da gesehen habe. Und der Forscher hat mir quasi ein Python-Skript zur Verfügung gestellt, um den Exploit zu reproduzieren und das sah mir KI-artig aus, aber das ist nur eine Vermutung. Im Laufe des zweiten CVEs oder zweiten Bugfixes hat mir auch ein Freund, ich sag mal nicht, wer weiß nicht, was er genannt werden will, quasi gesagt, hey, ich habe mal ChatGBT gefragt, um ein paar Exploits zu finden im Publisher. Hier ist eine Liste. Wo ich mir dazu dachte, okay.

Martin · 47:28 Die arbeite ich jetzt mal.

Eric · 47:31 Naja, also es war alles nichts Schlimmes. Aber wie gesagt, das sind so Dinge, wo ich wusste, das kann jeder beliebige Forscher machen auch und dann muss ich mich halt mit Zeitdruck drum kümmern. Also mache ich es mal lieber vorher. Und hab dann auch selbst noch ein bisschen selbst, gesucht er hat ja quasi ein prompt geschrieben und geschickt was was rauskam und ich habe dann versucht man auch selber noch ein bisschen trickreicher zu prompten irgendwie gezielter zu suchen und habe die liste dadurch auch noch ein bisschen länger bekommen, und also den den fix habe ich das nicht notiert welche version das war Ja, kürzlich gab es einen größeren Security-Patch. Das ist quasi das Ergebnis davon. Ja, ich habe das natürlich auch vor, jetzt weiterhin, es kommen ja irgendwie ständig neue Models raus, da auch immer mal wieder die KIs zu bemühen. Zumindest das, was oberflächlich schnell gefunden werden kann, dass ich da das selbst schneller entdecke, zumindest als die Forscher. Ja, versuche da ein bisschen proaktiver unterwegs zu sein und Dinge zu fixen, bevor sie gemeldet werden. Heißt natürlich nicht, dass ich alles finde, aber vielleicht bin ich ein paar Sachen schneller als Forscher und im schlimmsten Fall Angreifer, aber ich glaube, der Publisher hat eine zu kleine, Installationsdichte, als er es für Angreifer macht, wirklich gezielt danach zu suchen.

Martin · 48:55 Aber das heißt wenn die Community größer wird, wird es auch wieder gefährlicher das soll auch nicht die Botschaft sein also ihr könnt natürlich den Publisher gerne empfehlen weiterhin, weil ich glaube nach wie vor, dass das, ein Tool ist oder eine Möglichkeit ist, unabhängig von, großen Plattformen, die dann wieder ganz andere Probleme haben auf lange Sicht vielleicht, Podcasts zu veröffentlichen und das finde ich nach wie vor faszinierend und reizvoll, dass das eben alles in der eigenen Hand liegen kann, mit den Vor- und Nachteilen, die damit einherkommen, aber ich finde es nach wie vor einfach schön, dass es so ein Publikationsmedium ist, das man selber kontrollieren kann.

Eric · 49:40 Ja, auf jeden Fall. Also ich schmeiße das Handtuch ordentlich auf den Boden.

Martin · 49:44 Das freut mich persönlich auf jeden Fall.

Eric · 49:48 Also ich bleibe auf jeden Fall mindestens mit Maintenance dran. Also ich Ja, wenn was gemeldet wird, dann fixe ich das, so wie ich das auch in den letzten Jahren getan habe und versuche. Jetzt KI-getrieben. Also ich habe ja sonst keine Chance, irgendwie selbst mal nach Sicherheitslücken zu suchen. Keine Ahnung, mehr Codebase, ich wusste ja nicht, wo ich anfangen soll. Aber ja, das, was mir die Models irgendwie auswerten, das kann ich auf jeden Fall fixen. Ja, ich bleibe dran.

Martin · 50:18 Wollen wir noch einen kleinen Ausblick oder können wir einen kleinen Ausblick machen, was unabhängig von der Härtung des Systems inhaltlich passiert? Ich bin gerade aber auch nicht informiert, was wir eigentlich da besprochen haben. Gibt es irgendwas, was wir machen müssen? Also wir wollten ja auf jeden Fall irgendwie vielleicht alles so ein bisschen an diese Episodenseite anlehnen, das ist aber natürlich jetzt im Sinne dieser Sicherheitslücken ein bisschen zurückgetreten, dass wir da viele Sachen vereinheitlichen, aber ich glaube, es ist erstmal nichts groß inhaltlich jetzt geplant für dieses Jahr zumindest, ne?

Eric · 50:50 Nee, also ich bin jetzt vor allem noch an, also wo ich sowieso schon an so Wartungsthemen bin, also Security, so internes Aufräumen mache ich gerade noch so ein bisschen. Wir haben immer noch zwei JavaScript-Bundle-Systeme, das alte und das neue und ich ziehe so nach und nach so ein paar Systeme in das neue um, um es so zu vereinfachen und ja sowas. Ich habe irgendwie neulich Gravata, habe ich mal aktualisiert. Das ist so ein System, wo man Kontributoren Bilder hinterlegen kann über die URL, über die E-Mail. Genau. Wie ich drauf gekommen bin, ist, ich habe durch irgendeinen dieser Bilder fix, habe ich Gravata kaputt gemacht.

Martin · 51:32 Das habe ich gemerkt tatsächlich.

Eric · 51:35 Ah, okay. Ich weiß gar nicht mehr, was es genau war, aber es hat einfach die Gravata-URLs untauglich gemacht und habe das System zum einen auf die neue Gravata-API umgestellt. Die haben natürlich innerhalb von zehn Jahren mal ihre API geändert. Schön, dass sie die Legacy-API noch unterstützt haben. Aber ja, das ist jetzt die neue und auch die geht jetzt quasi komplett vorbei am Bildersystem, weil es einfach nicht notwendig, also wie gesagt, ich benutze das Bildersystem ja vor allem, um die Bilder zu, die Größe runterzurechnen und das kann Gravata selber. Also das mache ich jetzt quasi darüber. aber genau so Sachen. Einfach so Maintenance ein bisschen aufräumen. Ja, bei so einem Projekt, das weiß ich nicht, wie alt es ist, zwölf Jahre, da kann man auch mal ein bisschen durchfegen. Sowas mache ich.

Martin · 52:27 Ich glaube, Dirk, der heute nicht dabei ist, der bastelt ja auch noch am Subscribe-Button immer wieder mal ein bisschen rum, dass das passiert. Also es geht voran, es liegt nicht brav. Wir haben nicht aufgegeben nach den Angriffen, sondern genau, ihr könnt weiter mit Podlove podcasten. Und genau, dieses Jahr umso sicherer als zuvor. Kleines Snow Leopard Release quasi. Gut, dann sind wir, glaube ich, durch die Angriffswelle. Zumindest Stand heute, Aufnahmedatum 6. September. Fast ein Jahr nach dem Angriff. Genau, wir freuen uns.

Eric · 53:08 Wenn ihr … Jetzt müssen wir noch zusehen, wie wir die Episode veröffentlicht bekommen, weil das haben wir auch länger nicht gemacht. Und die Webseite ist seitdem umgezogen. Also du hast gerade das Aufnahmedatum genannt. Dann sehen wir, wenn wir es veröffentlicht bekommen.

Martin · 53:21 Hoffentlich noch im September. Das ist auf jeden Fall mein Ziel. Und genau, das könnt ihr noch mal zum Jahrestag mit einer Tasse Tee genüsslich darüber zuhören, was passiert ist. Genau, wir freuen uns auf jeden Fall über jeden, der Podlove benutzt, der uns kontaktiert, kommentiert, der vielleicht auch gute Ideen hat, was wir noch machen könnten, machen wollen. Also freuen uns immer sehr. Es scheint nach wie vor eine sehr schöne Community zu sein, die unsere und vor allem deine Software nutzt.

Eric · 53:52 Ja, macht immer noch Spaß, manchmal.

Martin · 53:57 Aber es liegt weniger an den Menschen, die es benutzen, als an den Menschen, die es kaputt machen wollen.

Eric · 54:01 Ja, das ist so das Drumherum.

Martin · 54:04 Gut, dann spiele ich nochmal unser schönes Jingle ein und dann verabschieden wir uns und grüßen an der Stelle Alex und Dirk und alle, die uns zuhören. Und bis bald, macht's gut.

Eric · 54:13 Ciao.