#56: PHP2Shell - Das ganze Internet in Aufruhr

00:00:04: Felix: Die ganze Internetwelt ist in Aufruhr. Die ganze Internetwelt? Nein. Eine kleine Agentur aus Dortmund bleibt entspannt. Und damit hallo und herzlich willkommen zu einer neuen Folge von unserem Webcafé. Ja, Kay wäre stolz auf mich, auf das Intro, denke ich. Kay, vielleicht hörst du es auch. Und der Aussage entnehmt ihr schon. Kay kann leider heute nicht dabei sein.

00:00:28: Felix: Das liegt daran, dass ich im Urlaub war und wir einfach keine Zeit hatten aufzunehmen. Und ich wollte aber schon gerne jetzt für Montag noch eine Folge machen. Und deswegen sitze ich hier gerade Samstag, 2 Uhr nachts ist es gerade exakt, und nehme euch eine Folge auf. Habe dafür auch, weil ich schon Zähne geputzt habe, hier nur ein Wasser als Getränk.

00:00:46: Felix: Also unspektakulär. Ich hoffe, die Folge wird dann entsprechend interessanter als das Getränk. Und ja, ich will euch eben Richtung PHP2Shell abholen. Das ist diese Sicherheitslücke, über die im Moment alle sprechen und die ja sogar durch die Populärmedien gegeistert ist, was mich doch dann sehr gewundert hat. Und weil das Thema natürlich eine gewisse Aktualität hat und vielleicht sogar der eine oder andere noch nicht PHP geupdatet hat, habe ich gedacht, das macht jetzt Sinn, das relativ schnell rauszufeuern und dass das jetzt am Montag dann auch direkt online geht.

00:01:20: Felix: Genau. Ja, was macht denn PHP2Shell jetzt besonders im Vergleich zu anderen Sicherheitslücken? Weil dass grundsätzlich mal Sicherheitslücken entstehen, ist ja jetzt nichts Besonderes. Also es werden ja tagtäglich Sicherheitslücken gefixt, jetzt nicht nur bei PHP. Und es gibt auch viele Sicherheitslücken, die dann einen höheren Schweregrad haben. Und das heißt trotzdem nicht, dass da jetzt alle plötzlich nervös werden, sondern dann spielt man ein Update ein und dann ist das auch gut.

00:01:45: Felix: Also erstmal haben wir es natürlich hier mit einer Sicherheitslücke zu tun. Die ist jetzt CVSS 9,2. Das ist dieses Scoring-System für Sicherheitslücken. Common Vulnerability Scoring System heißt glaube ich 9,2 auf einer Skala von 0 bis 10 also das scheppert schon, das ist schon ganz gut da werden ja so Fragen gestellt wie kann ich das über das Internet ausführen das macht so ein Ding natürlich gefährlicher, wie schwer ist der Angriff, brauche ich besondere Bedingungen wie viele Systeme sind betroffen und dann ist das so ein objektiver Score und wenn er hier bei 9,2 landet dann sind wir hier auf jeden Fall im kritischen Bereich und dann kann man sich das schon mal angucken was da los ist Ja, und ein großes Problem kommt natürlich daher, dass das hier wirklich ein Bug in PHP ist.

00:02:30: Felix: Das heißt, das ist jetzt nicht Laravel, das ist nicht WordPress, das ist nicht irgendwie, wenn jemand was nicht sauber gecodet hat, sondern die Anwendung kann total sauber gecodet sein und trotzdem ist man anfällig mit seinem Server für diese Schwachstellen. Ja und dann sind natürlich super viele PHP-Versionen betroffen, also alles von 5.4 aufwärts. 5.4 ist ja von 2012, das heißt alle Versionen, die so die letzten, ich sag mal 10, 15 Jahre rausgekommen sind, sind alle anfällig. und wenn wir uns Zugriff zu den Systemen verschafft haben, dann können wir eben Code ausführen, wirklich auf dem System.

00:03:11: Felix: Also das ist so ziemlich der Worst Case, den man eigentlich so haben kann bei einer Sicherheitslücke.

00:03:17: Felix: Bevor ich so ein bisschen darauf eingehe, wie wir mit der Sicherheitslücke umgegangen sind und vielleicht auch so ein bisschen eine Einschätzung, warum das jetzt so hochgekocht ist, wollte ich einmal darauf eingehen, wie die Sicherheitslücke überhaupt funktioniert und genau genommen haben wir es hier sogar mit zwei Sicherheitslücken zu tun. Die werden beide unter PHP2Shell zusammengefasst, einfach weil das die gleiche Fehlerklasse ist. Also es geht bei beiden um Speicherverwaltung.

00:03:42: Felix: Dann sind die gemeinsam veröffentlicht worden von Calif, Wiz und OpenAI, also war ja viel KI auch involviert. Und dann wurde das natürlich jetzt auch zusammen am 21. gepatcht, also mit diesem gemeinsamen Patch. Und das führt einfach dazu, dass man die alle jetzt letztlich unter PHP2Shell als Sicherheitslückenfamilie zusammenfasst.

00:04:02: Felix: Ja, grundsätzlich verarbeitet PHP ja HTTP-Anfragen und legt dabei dann auch Daten im Arbeitsspeicher, also im Memory ab. Und das funktioniert beispielsweise, wenn man ein Formular ausfüllt, aber hier in dem Fall funktioniert es eben auch mit allen Requests grundsätzlich. Das heißt, ich könnte jetzt einfach auch ein Post-Request an eine Hallo-Welt-Anwendung schicken, die jetzt nichts anderes macht als eine Ausgabe von einem String.

00:04:29: Felix: Das heißt, ich brauche kein Formular oder so. Ich kann aber auch das Ganze über einen Get-Parameter machen. Und es geht immer darum, dass ich den maximalen Speicher nutze und dann zu einem Abbruch des Programms komme. Ich versuche das technisch so ein bisschen runterzubrechen. Ich habe da sehr viel drüber gelesen, wie das funktioniert, weil es mich natürlich auch interessiert, welche Systeme sind angreifbar, in welchen Zuständen sind die Systeme angreifbar.

00:04:52: Felix: Und ich gebe euch einfach hier nur so einen kurzen Abriss. Also man kann sich vielleicht ein Szenario vorstellen. Ich habe einen Post-Request mit verschiedenen Parametern und die werden im Memory in so eine Hashtable geschrieben. Und könnt ihr euch vorstellen wie so ein Key-Value-Storage eigentlich. Und im PHP war es bisher so, dass ein Counter hochgezählt wurde für ein neues Attribut und danach wurde das Attribut dann tatsächlich auch geschrieben, also dieser Key-Value-Pair.

00:05:19: Felix: Wenn jetzt aber genau zwischen diesen beiden Ausführungen das System abbricht, weil ein Memory-Overflow da ist oder vielleicht aus anderen Gründen, Dann haben wir diesen Counter schon hochgezählt, der zeigt aber letztlich auf einen leeren Speicherbereich oder einen Speicherbereich, wo Sachen drinsteht, die wir jedenfalls so erstmal nicht erwartet haben.

00:05:34: Felix: Das können eben Angreifer ausnutzen, indem sie bestenfalls in diesen Speicherbereich Sachen platzieren, die dann für sie günstig sind. Ja genau genommen ist es kein Buffer-Overflow oder Memory-Overflow, sondern das Speicherlimit von PHP wird da absichtlich erreicht. Bei PHP kann man ja Memory-Limit einstellen. Ich sage mal sowas wie zum Beispiel 128 MB.

00:05:56: Felix: Und wenn das erreicht wird oder überschritten würde, dann gibt PHP eben einen Fehler aus und der wird dann hier absichtlich provoziert. Und dann sind das ja zwei Sicherheitslücken. Das eine ist eben dieser Zähler, der hochgezählt wird, was dann ein Problem ist. Und das andere ist so ein Use-after-free. Da geht es darum, dass eigentlich ein Verweis, also ein Pointer da bleibt, obwohl der Speicher eigentlich an der Stelle schon freigegeben ist.

00:06:20: Felix: Also relativ klassischer Fehler, den man so grundsätzlich auch erstmal schon öfter gehört hat. Ja, das ist jetzt kritisch, so wie viele andere Fehler auch. Aber warum wurde das jetzt in den Populärmedien so aufgenommen? Ich glaube, ein großer Baustein dabei war einerseits natürlich die Tragweite. Ja, da sind sicherlich so roundabout zwei Drittel des gesamten Internets betroffen. Also ich glaube ja, dass weit über die Hälfte der Internetseiten auf PHP-Basis laufen. Und es ist eben nicht abhängig von einem System, sondern es betrifft unglaublich viele Versionen, unglaublich viele Jahre.

00:06:57: Felix: Jahre und so eine weite Verbreitung von einer Sicherheitslücke, die macht es natürlich super attraktiv für Angreifer, genau darauf einen Exploit zu entwickeln, genau diese Sicherheitslücke anzugreifen, weil es sich eben lohnt, weil man sehr viele Targets hat, während andere Lücken dann in ganz speziellen Situationen nur greifen und da lohnt es sich dann nicht so richtig, dafür extra Aufwand aufzuwenden, es sei denn, das sind jetzt staatliche Akteure zum Beispiel, die dann ein spezielles Ziel haben, wo dann genau exakt dafür ein Exploit gebaut wird.

00:07:30: Felix: Aber grundsätzlich haben wir es ja ganz viel mit Angreifern zu tun, die einfach nur das Internet überfluten mit Anfragen, mit Abklopfen von Sicherheitslücken auf Webseiten. Und da, wo sie reinkommen, platzieren sie vielleicht Werbung auf einer Seite, installieren Bitcoin-Miner, versuchen Phishing irgendwie zu betreiben. Und das macht eben genau dann viel Spaß, wenn man besonders viele Ziele hat, die verwundbar sind. Und das ist hier natürlich definitiv der Fall.

00:07:58: Felix: Ja, und dann wurden Details zu dieser Sicherheitslücke öffentlich, bevor das gepatcht wurde. Normalerweise ist das so, dass da Sicherheitsforscher hingehen und die entdecken das dann. Oft sind das auch mehrere Forscher, die zusammenarbeiten und Firmen, die aus irgendwelchen Gründen an den Sicherheitslücken forschen. Und wenn die was finden, dann wird das eigentlich hinter verschlossenen Türen erstmal den Entwicklern von PHP dann zum Beispiel mitgeteilt.

00:08:24: Felix: Und die können dann Patch vorbereiten und in dem Moment, wo der Patch bereitsteht und ausgeliefert wurde, werden auch Details dann zu der Sicherheitslücke bekannt gegeben. Aber in dem Moment sind die wichtigsten Systeme schon gepatcht und die Angreifer können das eigentlich dann nicht mehr richtig ausnutzen. Genau, das geht hier übrigens auf einen Bug zurück, der schon 2014 gemeldet wurde, der damals aber nicht als kritisch eingestuft wurde und ein bisschen in anderer Form.

00:08:47: Felix: Und jetzt, also irgendwie mithilfe von AI wurde das herausgefunden, wurde da nochmal ein bisschen mehr draus gemacht, wurden da wirklich Exploits auch geschrieben, die funktionieren und ja, so ist da erstmal diese Brisanz überhaupt reingekommen. Genau, jedenfalls ist der Fix am 21. gekommen, der wurde auch vorverlegt, sollte eigentlich am 22. kommen.

00:09:04: Felix: Aber am 17. Oktober hat Amazon zumindest schon Bestrebungen registriert, dass dieser Fehler ausgenutzt wurde. Also massive Angriffe oder automatisierte Angriffe. Wir sind da schon gelaufen am 17. Ja, und das ist natürlich schwierig, weil da Angriffe liefen auf eine kritische Sicherheitslücke, wo noch kein Patch verfügbar war. Und allein das hat schon dazu geführt, dass viele Leute dann sehr nervös wurden.

00:09:28: Felix: Ja, wie sind wir jetzt mit der Sicherheitslücke umgegangen und wie haben wir reagiert, als wir davon gehört haben. Ich mache jetzt Softwareentwicklung seit 20 Jahren und die Erfahrung zeigt eigentlich, überstürzen ist selten eine gute Idee und normalerweise wird auch etwas kälter gegessen, als gekocht wird. Und jetzt war hier schon klar, das ist schon eine kritische Lücke, wo man sich drum kümmern muss, wo man auch dranbleiben muss.

00:09:54: Felix: Aber ich habe jetzt keinen Grund darin gesehen, jetzt wirklich groß Panik zu schieben oder da jetzt irgendwie nervös zu werden. Wir haben grundsätzlich eine relativ standardisierte Infrastruktur mit einer einheitlichen Hardware für die allermeisten unserer Kunden. Und das kam uns da sehr zugute, weil ja 16 Uhr dann am 21.10. der Patch rauskam für die Versionen ab 8.2.

00:10:16: Felix: Und das ist so bei uns das Gros der Kunden, läuft dann eben auch auf neueren PHP-Versionen, weil wir da sehr darauf achten. und ja, dann war es letztlich entweder mit einem Klick erledigt oder wir haben ja viele Webseiten auch auf Hetzner Managed Servern, wo Hetzner natürlich entsprechend die Patches eingespielt hat. Ich glaube 16.34 oder so hat Hetzner angefangen zu patchen und die waren halt super zackig und schnell drauf.

00:10:39: Felix: Und dadurch, dass wir dann beispielsweise jetzt viele Seiten bei Forge liegen haben mit Cloud-Servern von Hetzner, konnten wir letztlich mit einer Methode schon super viele Seiten absichern und waren sehr, sehr zeitig eigentlich dran, sobald die Images verfügbar waren. Das hat ja bei manchen Distributionen dann noch ein bisschen gedauert. Aber in dem Moment, wo da was verfügbar war, haben wir das eingespielt und da waren die Systeme auch sicher und dann lief das erst mal.

00:11:05: Felix: Jetzt hatten wir zwei, drei Systeme, wo wir ein bisschen länger mit rumgeeiert haben. Der Kay wird dann ein Lied von singen. Kay hätte ich dazu gerne noch gefragt, weil der einen Kunden hat, einen größeren Kunden von uns. Die haben einen eigenen IT-Dienstleister und da war es wohl nicht so einfach, einfach diesen Patch einzuspielen. Und die haben sich dann tatsächlich auch dafür entschieden, die Webseiten erstmal down zu nehmen.

00:11:25: Felix: Habe ich übrigens auch Webseiten gesehen, die einen Wartungsmodus angeschaltet haben. Das bringt gar nichts. Aber das ist eine andere Geschichte. Genau, also wir haben schon auch so ein paar Kunden gehabt, wo wir schon zugucken mussten, dass wir das Ganze gefixt kriegen und wollten das natürlich auch möglichst schnell machen. Obwohl, wir betreuen schon wichtige Systeme, würde ich sagen, und auch große Online-Shops.

00:11:44: Felix: Aber das sind alles keine Shops, die jetzt ein Angreifer zuerst angreifen würde. Also da gibt es immer noch andere Player, die da glaube ich größere Probleme kriegen. Und ich persönlich habe dann mich zum Beispiel um einen Plesk-Server gekümmert, wo man in Plesk halt die aktuellen PHP-Versionen reinziehen muss. Ja, dann kann man die flächendeckend eigentlich für alle Domains ausrollen, die da auf diesem Server liegen.

00:12:06: Felix: Letztlich eine Sache von einer Viertelstunde, wenn man das schon mal gemacht hat. Und das ging relativ easy. Kay hat da ein bisschen länger Spaß gehabt mit den Kunden. Aber ich glaube, nach zwei, drei Stunden war das Thema dann letztlich auch durch. Ja, und bei LinkedIn habe ich dann mich eigentlich tatsächlich das erste Mal schön amüsiert und habe mir angeguckt, wie andere Agenturen und Freelancer da schreiben, dass sie irgendwie schon Pizza bestellt haben.

00:12:29: Felix: Und mit der ganzen Nacht planen, bin ich mir nicht ganz sicher, was die da alle machen. Aber ich glaube, dass viele eben ein super elaboriertes Setup haben, komplizierte Serverlandschaften. Und das dann up-to-date und vielleicht auch sehr heterogen. Dann hat man hier vielleicht mal einen kleinen Root-Server stehen, hier hat man einen Cloud-Server und das alles dann irgendwie auf eine aktuelle Version zu bringen, ist dann vielleicht schon eine Herausforderung.

00:12:50: Felix: Da war ich ganz happy, wie wir aufgestellt sind. Das größte Problem hatte ich eigentlich mit einer Seite, die ich bisher noch nie gesehen habe. Da ist ein Kunde von uns auf uns zugekommen und hat gesagt, ja, ich habe hier noch so einen Online-Shop laufen, läuft seit Jahren, ist nie geupdatet worden und die Agentur, die den betreut hat, ja, ich weiß nicht, ob die nicht nicht auf Zack waren.

00:13:09: Felix: Jedenfalls haben die die tatsächlich darauf hingewiesen, dass sie es updaten sollten, konnten und wollten aber selbst dieses Update nicht machen. Ja und dann gab es natürlich auch keine Zugangsdaten. Dann durfte ich mich da wirklich erstmal durch, ja, zehn Leute durchtelefonieren, wer da noch irgendwelche Zugangsdaten hat.

00:13:25: Felix: Letztlich musste ich sie dann zurücksetzen und das über den Kunden spielen. Dann habe ich festgestellt, dass da eine PHP-Version lief, die relativ alt war. Das war glaube ich so eine 7.1, 7.2 und dafür gab es eben keine offiziellen Patches. Die offiziellen Patches gibt es nämlich erst ab Version 8.2. Und da gehen Gott sei Dank dann Leute hin und fixen das quasi freiwillig.

00:13:50: Felix: Also das ist so Open-Source-mäßig. Ist vor allem einer involviert, dessen Namen ich leider hier gerade nicht nennen kann. Habe aber so ein bisschen darüber gelesen. Und der geht dann wirklich hin und patcht das letztlich freiwillig. Gehört aber nicht zum PHP-Core-Team. Und dann kamen aber relativ schnell auch schon gepatchte 7er Versionen raus. und da konnte ich updaten, weil die Website dann mit 8.2 nicht mehr lief.

00:14:11: Felix: Das war so eine ältere Shopware-5-Variante. Und genau da habe ich sicherlich letztlich vier, fünf Stunden dran aufgewendet. Jetzt alles nicht nur am 21., sondern wir haben das dann in den 22. mit reingezogen, weil wir gesagt haben, dass die Seite jetzt nicht so kritisch ist, dass wir da jetzt innerhalb von Stunden ein Update unbedingt verfügbar haben müssen. Genau, das war eben eine Seite, die wir bisher nicht betreut haben. und da hatte ich das größte Thema mit.

00:14:37: Felix: Ab dem 21. kam dann die Meldung auch in den Populärmedien, also ich habe es zum Beispiel bei n-tv auch gelesen, dass diese PHP-Sicherheitslücke da rumgeistert hat und alle Web-Server angreifbar sind und ganz viele Webseiten auch schon down genommen werden und abgeschaltet werden. Und das ist natürlich auch unseren Kunden auch nicht vorbeigegangen und die haben dann so bestimmt ab 16, 17 Uhr angefangen anzurufen.

00:15:02: Felix: Ich konnte dann Gott sei Dank allen sagen, ja, ab 16.30 Uhr waren eure Seiten schon gefixt. Also ist eigentlich alles schon Schnee von gestern. Die waren auch alle ziemlich happy. Das war eigentlich cool. Für mich so ein bisschen eine besondere Situation, weil diese Updates ja für uns eigentlich im Hintergrund laufen. Also wir machen oft Updates für Systeme, sei das jetzt für WordPress, wo viel an Sicherheitslücken immer mal wieder publik wird für irgendwelche Plugins und so, wo man dann Updates einspielen muss.

00:15:28: Felix: Und mein Ziel ist eigentlich, dass die Kunden davon gar nichts mitkriegen. Und ich würde jetzt auch nicht eine Notice rausschreiben oder eine Rundmail schreiben, wir haben jetzt hier PHP2Shell gefixt. Für mich ist das nichts, was an den Kunden raus muss, sondern das ist was, was wir im Rahmen unserer Wartungsverträge einfach machen. und tatsächlich bei solchen kritischen Sicherheitslücken machen wir es auch, wenn die Kunden bei uns jetzt nicht einen expliziten Wartungsvertrag haben, aber wir haben natürlich einfach keinen Bock, dass unsere Server kompromittiert werden und dann gehen wir da schon hin und fixen das und da kriegt eigentlich auch keiner was von mit.

00:16:02: Felix: Aber dadurch, dass es jetzt in den großen Medien eben rumgegeistert ist, waren die Kunden natürlich auch sehr interessiert und haben nachgefragt und ja, ich war dann froh, dass ich die allermeisten dann eben sehr beruhigen konnte. Ich habe den Kunden im Wesentlichen davon abgeraten, Website noch abzuschalten, weil ich dann einfach die Kritikalität nicht so eingeschätzt habe, wie das vielleicht viele da draußen gesehen haben.

00:16:25: Felix: Und ich habe gedacht, wenn das jetzt einen Tag später kommt, also so schnell laufen die automatisierten Angriffe auch nicht. Und ich habe mir den Patch da angeguckt, beziehungsweise was man da machen muss. Also das war für mich schon sehr schwer zu verstehen und dafür einen Exploit wirklich zu schreiben, der dann für ein konkretes System, also für unsere Systeme auch funktioniert.

00:16:44: Felix: Also da rechne ich schon, also wenn jemand schnell ist damit, dass er da schon Tage für braucht, sowas zu machen. Klar, jetzt sind seit dem 17.10. Angriffe gelaufen. Ja, man kann sich das so vorstellen, wenn dann weltweit 10.000 Angriffe registriert werden und wenn man dagegen hält, wie viele Webseiten es so gibt, dann ist das doch eher verschwindend gering, was da so in den ersten Stunden und Tagen passiert.

00:17:03: Felix: Und die Leute, die wirklich ein Interesse daran haben, auch flächendeckend kleinere Seiten anzugreifen, die kommen normalerweise erst später auf den Plan. Dann, ja grundsätzlich ist es natürlich auch immer so ein Trade-off. Schalte ich einen Online-Shop zum Beispiel ab und generiere keine Einnahmen mehr oder ja, habe ich jetzt eine Sicherheitslücke, die potenziell mal angreifbar ist.

00:17:22: Felix: Im aktuellen Szenario gibt es ja noch keine echten Exploits da draußen in der freien Welt, wo wirklich ja Seiten auch erfolgreich angegriffen wurden, sondern es wird viel versucht, aber es ist letztlich noch nicht viel durchgekommen. und das ist ein Punkt, wo ich den Kunden zumindest mindestens mal, sagen wir mal, in den ersten 24 Stunden gesagt habe, einen Shop abzuschalten, ist im aktuellen Szenario nicht unbedingt notwendig.

00:17:47: Felix: Manche Kunden haben es erst trotzdem gewünscht, da haben wir das natürlich auch gerne gemacht und haben die Seiten dann aber nicht nur in Wartungsmodus gepackt, weil dann letztlich natürlich auch PHP läuft, sondern dann muss man wirklich hingehen und die ganze Seite abschalten, sodass PHP auch nicht mehr läuft und ausgeführt wird. Das ist dann mit ein bisschen mehr Aufwand verbunden und die Seite zeigt vor allem im Worst Case gar nichts mehr an.

00:18:08: Felix: Man kann natürlich auch eine statische HTML-Seite dann ausliefern. Aber genau, das kann schon der sinnvolle Weg sein, das Ding abzuschalten. Ich habe den meisten Leuten empfohlen, lasst die Seite weiterlaufen. Wir fixen das so schnell wie möglich und dann seid ihr auch safe.

00:18:22: Felix: Ja, viele Agenturen wollten natürlich so ein bisschen Kasse machen und haben die Leute tierisch nervös gemacht. Und ich habe dann auch von Kunden gehört, ja, da bieten wir jetzt welche an. Die wollen jetzt PHP auf 8.2 updaten. Aber das war schon zu einem Zeitpunkt, wo eigentlich schon die Fixes für auch ältere Versionen rausgekommen sind und wo dann klar war, die Seite ist eigentlich schon sicher, jetzt wollen sie das PHP-Update verkaufen, wo ich dann denke, boah, wenn man so eine Seite betreut und dann nach fünf Jahren mal draufkommt, ach hier gibt es übrigens auch ein PHP-Update, finde ich das ein bisschen spät.

00:18:53: Felix: Ich finde das schon erschreckend, wie viele Seiten da nicht richtig aktuell gehalten werden. Ich kann das natürlich auch verstehen, kümmert sich nicht jeder drum, hat vielleicht auch nicht jeder das Budget für.

00:19:01: Felix: Aber grundsätzlich finde ich, man kann schon darauf achten, dass eine PHP-Version vielleicht dann nicht unbedingt älter als zwei oder drei Jahre ist. Das ist so ungefähr der Support-Zeitraum, wo auch offizielle Patches rauskommen. Und dann ist man eigentlich auf der sicheren Seite. Und die PHP-Updates, die ich in letzter Zeit gemacht habe, also sei das jetzt von 8.0 auf 8.3, 8.5. Da kommen so wenig Änderungen dazu, dass normalerweise das auch locker durchläuft.

00:19:27: Felix: Ohne irgendwelche Fehler kann man einfach hochstellen, testet man einmal durch. Und wenn es dann einen Error gibt, den kriegt man meistens auch noch gerade gefixt. Also normalerweise ist das eine Sache von zwei Minuten, die PHP-Version eben aktuell zu halten.

00:19:39: Felix: Ja, was ist jetzt mein Fazit zu PHP2Shell? Das war jetzt so ein kleiner Schnelldurchlauf. Das ist definitiv kritisch. Das ist eine kritische Sicherheitslücke. und alle, die das hören und vielleicht von der Sicherheitslücke noch nichts gehört haben oder ihren Server noch nicht angepackt haben, tut es auf jeden Fall, weil das automatisierte Angriffe kommen, die über das ganze Internet laufen und jede Seite angreifen, die irgendwie dafür anfällig ist.

00:20:05: Felix: Das wird kommen, von daher updatet definitiv eure Systeme und vielleicht jetzt nach einer Woche, wo das Ding schon raus ist, ist vielleicht dann auch angesagt, das auch relativ schnell zu machen, weil das wird sicherlich nicht mehr so wahnsinnig lange auf sich warten lassen. Ja, dann solltet ihr natürlich, obwohl es auch Patches für ältere Versionen gibt, doch zugucken, dass ihr auf eine halbwegs aktuelle PHP-Version updatet.

00:20:28: Felix: Und eigentlich macht es auch keinen Sinn, jetzt zum Beispiel auf eine 8.2 zu gehen, die noch supported wird. Wenn 8.2 läuft, läuft auch 8.5 und dann updatet einfach direkt auf die aktuellste Version und guckt vielleicht in Zukunft, dass sie ja aktuell bleibt. Und grundsätzlich vielleicht nochmal zu solchen Themen, wenn solche Sachen hochkochen, bleibt erstmal ruhig und besonnen und guckt euch an, was ist das für eine Sicherheitslücke, betrifft das meine Systeme, wie kritisch ist das und jetzt in so einem Fall, wo es dann wirklich sehr kritisch ist, ist natürlich schon angesagt, dass man sich da noch zeitig darum kümmert, am besten direkt, aber man muss jetzt nicht irgendwie die Hände über den Kopf zusammenschlagen, alle Zelte einreißen und da Panik machen. Das ist sicherlich der falsche Weg, sondern Patch einspielen, Systeme prüfen, ob was passiert ist und dann funktioniert das.

00:21:16: Felix: Ja, ich hoffe, dass ihr so ein paar Einblicke bekommen habt, was bei uns in den letzten Tagen so los war. Und vielleicht war es auch so eine ganz spannende Reise durch Sicherheitslücken, IT-Security und was heute mit AI dann auch möglich ist. und was so für Bugs gefunden werden, die eigentlich seit 15 Jahren schon rumschlummern, schon ewig offen sind und jetzt gefunden werden.

00:21:38: Felix: Kann man eine eigene Folge zu machen, ob das jetzt positiv oder negativ ist. Ich glaube, grundsätzlich sind gefundene Sicherheitslücken dann auch immer gut, weil es natürlich schon Akteure geben kann, die von solchen Lücken auch Kenntnis haben, die das jetzt nicht unbedingt publik machen, die das aktiv ausnutzen. Und dann ist, glaube ich, jede gestopfte eine gute Sicherheitslücke.

00:21:58: Felix: Ein letzter Punkt habe ich noch und zwar sind wir gebeten worden, bei der Umfrage zu deutschsprachigen Tech-Podcasts mitzumachen und das machen wir natürlich für die Community auch total gerne. Das ist eine Umfrage, die ist vom Engineering Kiosk aufgesetzt worden. Das sind 37 Fragen. Könnt ihr euch einfach so durchklicken. Also kommt man wahrscheinlich in fünf Minuten durch.

00:22:20: Felix: Und das hilft uns und der gesamten Community so ein bisschen zu verstehen, was ihr gerne hört, wo ihr Podcasts gerne hin entwickeln wollt. Ja, und da wir natürlich zugesagt wollen, gerne teilnehmen. Die Links dazu findet ihr in den Shownotes. Ja, ich bedanke mich wie immer fürs Zuhören und wünsche euch eine gute Woche. Bis dahin. Nächstes Mal sehen wir uns dann und hören uns wieder mit Kay. Ciao, ciao.