Lass mich dir eine Geschichte erzählen Es gibt eine ordentliche, fast akademische Version, wie Software-Sicherheit funktionieren soll. Es erscheint in Konferenzgesprächen, Compliance-Dokumenten und in den fröhlichen Diagrammen, die auf Marketing-Slides zu sehen sind. Ein Forscher findet einen Fehler, meldet ihn leise (und professionell) nach oben, patcht ihn nach oben, ein CVE wird zugewiesen, nach unten Wartungskräfte ziehen die Reparatur, Scanner benachrichtigen, Verteidiger patchen, und die Welt bleibt meist ok. Wenn das wirklich so wäre, wie die Dinge funktionierten, würde ich hier nicht über nachgelagerte Fixs, leise Patches oder Sicherheitsprobleme schreiben, die an einem Ort existieren und an einem anderen verschwinden. - und jeder muss es wissen. gestört Was Sie in diesem Artikel lernen werden 
 
 
 
 
 
 Die Sicherheitszeitlinie Inversion: Wie CVE Offenlegung ist nicht der wahre Anfang der Sicherheitszeitlinie. Sicherheitsergebnisse: Warum routinemäßige Wartungsentscheidungen, nicht Reaktionsgeschwindigkeit oder Werkzeuge, die Sicherheitsergebnisse bestimmen. Fehlende Indikatoren: Warum CVE-Score, Scanner und Compliance-Fristen keine wirksamen Frühwarnsysteme sind. Vulnerabilitätsverzerrung: Wie eingebettete, gefaltete und end-of-life-Komponenten die Sichtbarkeit in Schwachstellen und Rechenschaftspflicht verschleiern. Notwendige Änderungen: Die Governance- und Lebenszyklusänderungen sind notwendig, um zu vermeiden, strukturell zu spät zu "stille" Schwachstellen zu sein. Im Februar 2025 lieferte Apache Tomcat eine Reihe Sie kamen ohne Dringlichkeit, ohne Kommentare und ohne die Art von Lärm, der bedeutende Sicherheitsvorfälle begleiten kann. Routine Für die meisten Teams gab es keinen unmittelbaren Grund, diese Releases anders zu behandeln als andere Wartungsupdates. Nichts schien kaputt zu sein. Nichts schien gefährdet zu sein. Es gab keinen Schwachstelle-Identifikator, auf den man reagieren konnte. Einige Wochen später wurden diese gleichen Releases zum Mittelpunkt eines Sicherheitsnotfalls. Als CVE-2025-24813 im März veröffentlicht wurde, war der gefährdete Code-Pfad bereits identifiziert, korrigiert und über unterstützte Tomcat-Filialen versandt worden. Die Behebung bestand, bevor das Problem einen Namen hatte. Für alle anderen kam es als eine unangenehme Überraschung: Eine CVSS-Score von 9,8 ist eine großartige Möglichkeit, Ihren Tag zu beginnen. Fühlen Sie sich frei, die Details des CVE hier anzusehen Wir werden den Inhalt später betrachten, da das, was aufgezeichnet wird und wer es aufnimmt, Teil dieser Geschichte ist.Die schmutzigen technischen Details des CVE sind meist irrelevant. Modus; es muss ermöglicht werden. https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Defizit https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Diese Reihenfolge von Ereignissen wird uns helfen zu verstehen, wie CVEs sich entwickeln können und wie dies die Verbraucher beeinflussen kann. Die Umkehrung der Sicherheits-Timeline Diese Inversion ist leicht zu verpassen, wenn Sie sich nur die Offenlegungsdaten ansehen. Sicherheitszeitlinien werden in der Regel so erzählt, als würden sie beginnen, wenn ein CVE veröffentlicht wird. Wenn eine Rakete auf der Startplatte anfängt zu zählen, sehen wir, dass die Motoren starten, bevor die Rakete den Boden verlässt. Das ist das Muster, das wir mit CVEs sehen. In diesem Fall folgte das Tomcat-Sicherheitsteam einem Muster, das für eine langlebige Open-Source-Infrastruktur völlig normal ist. Ein privater Bericht kam. Das Problem wurde untersucht. Eine Lösung wurde entwickelt und versandt. Stille und alles, bevor die 'Rakete' den Pad verließ. Die Absicht war nicht Geheimhaltung, sondern Einschränkung: Das Ziel ist es, das Fenster zu reduzieren, in dem die Verteidiger keine tragfähige Reaktion haben. Gewohnheit vs. Hype Dieser Ansatz funktioniert gut für Organisationen, die Point Releases als etwas anwenden. Routine zu machen. Diese Teams upgraden, ohne zu wissen, warum, und zum Zeitpunkt, als die Schwachstelle öffentlich diskutiert wurde, waren sie bereits geschützt. Für Organisationen, die sich auf Offenlegung als Auslöser für das Handeln verlassen, fühlte sich der März wie ein Nulltag.Die Schwachstelle erschien vollständig gebildet, komplett mit Schwereinschätzungen, Ausbeutungsansprüchen usw. Von außen sah es so aus, als wären alle gleichzeitig dem gleichen Risiko ausgesetzt. Zwei Teams hätten im Januar identische Tomcat-Versionen laufen können und waren bis Mitte März in sehr unterschiedlichen Positionen.Eines war isoliert, das andere ausgesetzt. Es war Die Gewohnheit. Die fehlerhafte Annahme von lauten Warnungen Es gibt eine anhaltende Annahme in vielen Engineering-Organisationen, dass ernsthafte Sicherheitsprobleme sich laut genug anzeigen werden, um Aufmerksamkeit zu fordern. Diese Annahme ist zunehmend unzuverlässig. In diesem Fall war der entscheidende Indikator von der Routinewartung nicht zu unterscheiden. Ein ChangeLog-Eintrag. Eine Versionstörung. Eine Veröffentlichung, die sich nicht dringend fühlte, weil noch niemand etwas gesagt hatte, was es sollte. Sobald das CVE veröffentlicht wurde, übernahm die übliche Erzählung.Die Schwachstelle erwarb einen Namen, eine Punktzahl und ein Zielpublikum. Diskussionen über Schwere, Ausnutzbarkeit und Konfiguration begannen sofort. Veränderungen priorisieren über Geschichten Es ist verlockend, diese Februar-Releases als ein glückliches Timing zu betrachten. Sie waren es nicht. Sie waren einfach das Ergebnis eines Prozesses, der das Fixieren von Code vor der Verwaltung der Wahrnehmung priorisiert. strukturiert, um auf Geschichten statt auf Veränderungen, auf Erklärungen statt auf Differenzen zu reagieren. Unwissentlich Zu der Zeit, als das Ökosystem begann, die Auswirkungen von CVE-2025-24813 zu diskutieren, war das technische Ergebnis bereits festgelegt.Einige Systeme waren sicher, andere nicht, und die Unterscheidung hatte nichts mit der Schnelligkeit zu tun, wie jemand im März reagierte. Wie diese CVE (und um ehrlich zu sein, die überwiegende Mehrheit aller CVEs) auf der ganzen Welt erschien, war eine Kollision von Interpretationen, Bewertungen und Verpflichtungen Das ist, wo diese Fallstudie interessant wird und so eine große Probe macht. Hier die wichtigste Timeline Die kritischen Elemente kreisen alle um die CVE- und CPE-Informationen des NVD. . https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 
 
 Ich muss betonen, dass dies nicht dazu gedacht ist, zu vermuten, dass etwas Unwiderrufliches passiert ist. Ich muss betonen, dass dies nicht dazu gedacht ist, zu vermuten, dass etwas Unwiderrufliches passiert ist. 13. Januar 2025. Vulnerabilität Privat gemeldet Das Apache Tomcat-Sicherheitsteam erhält einen privaten Bericht über eine Schwachstelle, bei der teilweise HTTP-PUT-Anfragen und das Standard-Dateiservlet beteiligt sind. 24. Januar 2025: Fix verpflichtet. Das Komitee wurde aufgezeichnet, und wie üblich und erwartet gibt es keinen Hinweis darauf, dass es eine Sicherheitslücke behebt. Die damit verbundene Pull-Anfrage heißt "Enhance Lifecycle of temporary files used by partial PUT" https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c 10. Februar 2025: Fix wird schweigend veröffentlicht. Apache veröffentlicht ruhig Tomcat 9.0.99, 10.1.35, und 11.0.3 mit der Behebung enthalten. Das ist ein Monat vor der öffentlichen Offenlegung. 10. März 2025: CVE-2025-24813 öffentlich bekanntgegeben Apache veröffentlicht öffentlich die Schwachstelle über die OSS-Sicherheitsmailing-Liste, bewertet "Wichtig" mit dem Potenzial für RCE und Informationsveröffentlichung. c) Zitate https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Dieses Problem betrifft Apache Tomcat: von 11.0.0-M1 bis 11.0.2, von 10.1.0-M1 bis 10.1.34, von 9.0.0.M1 bis 9.0.98 13. bis 14. März 2025: PoC-Exploits und aktive Angriffe beginnen Innerhalb von 30 Stunden nach der Offenlegung werden Proof-of-Concept-Exploits öffentlich veröffentlicht. Massenscanning und Exploit-Versuche beginnen sofort. Angriffsmethode: Upload JSP Webshell über partielle PUT, Trigger über gestaltete JSESSIONID-Anfrage. Sources: Sonatype Blog | CyRisk Analysis 17. März 2025: Ein POC-Exploit wird dem NVD CVE-Eintrag hinzugefügt https://github.com/absholi7ly/POC-CVE-2025-24813/blob/main/README.md 18. März 2025: Die erste CPE-Information wird dem CVE hinzugefügt Die CPE Es ermöglicht automatisierten Verbrauchern der CVE, zu „wissen“, welche Versionen des Produkts anfällig sind. https://nvd.nist.gov/products/cpe https://nvd.nist.gov/products/cpe An diesem Punkt entspricht der CPE einfach der ursprünglichen Versionsbereichserklärung, die Sie zuvor gesehen haben. 19.–26. März 2025: Analyse der Sicherheitsanbieter veröffentlicht Rapid7, Akamai, Wiz und Sonatype veröffentlichen detaillierte Analysen. Rapid7 stellt fest, dass "keine Panik nötig ist", weil weit verbreitete Ausbeutung nicht bestätigt wurde und einige der angegebenen Voraussetzungen von Apache überbewertet wurden. Sources: Rapid7 Blog | Akamai Blog | Wiz Analysis 1. April 2025 :CISA fügt den KEV-Katalog hinzu Der CVE dokumentiert, dass CISA CVE-2025-24813 zu seinem Katalog bekannter ausgebeuteter Schwachstellen hinzufügt und Hinweise auf aktive Ausbeutung zitiert. US-Bundesbehörden wurde am 22. April 2025 eine Frist für das Patchen gegeben. Amazon AWS veröffentlicht auch ALAS-2025-2812 am selben Tag. Sources: Keysight Analysis | Amazon Linux Advisories Anfang April 2025: Enterprise Vendor Patches veröffentlicht Red Hat, Amazon, SUSE, Atlassian und andere Enterprise-Anbieter veröffentlichen Patches. Die meisten betonen, dass Standardkonfigurationen nicht anfällig sind, da das Standard-Servlet nur lesbar ist. Sources: Red Hat CVE | Amazon CVE 3. Juli 2025: Einheit 42 meldet 125K+ Angriffsversuche Die Einheit 42 von Palo Alto berichtet von 125.856 Ausbeutungsversuchen, die allein im März 2025 blockiert wurden. Der meisten Ausbeutungsverkehr scheint "opportunistisch" zu sein, indem öffentliche PoCs von Akteuren mit geringerer Komplexität verwendet werden. Source: Unit 42 Report Sind wir fertig? Nun, für einige Tomcat-Nutzer, die auf Versionen 9, 10 oder 11, ist alles in Ordnung. 7. August 2025 - CVE aktualisiert " Ältere, EOL-Versionen können ebenfalls betroffen sein." Wegen einiger Lobbyarbeit unter der Leitung von HeroDevs fügte das Apache-Team eine Warnung hinzu. Dies ist wichtig. Dies geschieht sehr selten, aber es gab Ingenieure in der Mischung bei Apache und anderswo, die das Gefühl hatten, dass die Warnung notwendig war. Die CPE wurde aktualisiert, aber sie erhielt keine Informationen über die EOL-Versionen, da es nichts Spezifisches zu enthalten gab. 8. August 2025 - CVE Aktualisiert mit weiteren Informationen über EOL-Versionen Der CVE stellt nun fest: „Die folgenden Versionen waren EOL zum Zeitpunkt der Erstellung des CVE, aber sind bekannt betroffen sein: 8.5.0 bis 8.5.100.“ Jetzt ist die CVE offiziell auf eine andere Version Stream von Tomcat anwendbar. Heute Selbst heute wurde dieses CVE nicht aktualisiert, um die CPE-Informationen aufzunehmen, die einem Scanner helfen könnten, ein Problem in der Version 8.5 zu erkennen. Ein Teil davon kann der Natur des CVE zugeschrieben werden.Da die Schwachstelle nur möglich ist, wenn eine Standardkonfiguration geändert wird. Veränderung zu Lektüre = wahr readonly = falsch Das heißt, theoretisch hängt die Ausbeutbarkeit davon ab, ob der Tomcat-Benutzer diese Änderung vornehmen kann. Wenn Tomcat auf eine Weise eingebettet ist, die verhindert, dass diese Konfiguration geändert wird, dann kann das "Eingebettete" Produkt zu Recht behaupten, dass sie nicht verletzlich sind. Es gibt auch viele Forks und kommerzielle Varianten von Apache Tomcat. Zum Beispiel ist es eine Komponente von Spring Boot, und Broadcom Tanzu integriert es auch. Wie viele Fettbehälter gibt es da draußen, wo die Komponenteninformationen verloren gegangen sind, oder das Projekt POM wurde seit dem Versand aktualisiert? Wie sich die Botschaft verdünnt Die oft bittere Wahrheit ist, dass CVE-Berichterstattung und das richtige Bewusstsein für die richtigen Personen fehlschlagen. In der Tat, je beliebter eine Komponente ist, um zu schleifen oder zu integrieren, desto schwieriger kann es sein, diejenigen zu erreichen, die darüber wissen müssen. Der Tanzu richtig erklärt, dass die CVE gilt für Tanzu und gibt ihm seine eigene Kennung, TNZ-2025-014. Sie warnen ihre Benutzer, dass die CVE für Versionen 9,10 und 11 gilt, aber dann, wie immer, wird es verwirrt. Die Tanzu-Suite ist anspruchsvoll und komplex. Ich weiß nicht, ob Tanzu Versionen mit Tomcat 8 oder früher hat - ich nehme an, dass sie es tun. Da ihr Rat datiert 2025-03-25, lange bevor die CVE die zusätzliche EOL-Version info hinzugefügt hatte, kann man mit diesem Fehler sympathisieren, auch wenn es eine große Exposition für ältere Tanzu-Produkte sein könnte. Support Seite Are-You-Exposed oder nicht Ein gemeinsames Szenario Als CVE-2025-24813 einen Namen, eine Punktzahl und einen Medienzyklus erwarb, war das Ergebnis bereits abweichend. Die Lösung bestand vor dem CVE. Einige Systeme wurden geschützt, bevor jemand wusste, warum. Andere würden unabhängig davon, wie schnell sie im März reagierten, ausgesetzt bleiben. Diese Divergenz kam nicht aus Bewusstsein, Tooling oder irgendeiner Art von Bedrohungsintelligenz. Es kam aus Timing.Genauer gesagt, aus der Annahme, dass Sicherheit beginnt, wenn eine Schwachstelle erklärt wird, und nicht, wenn sich der Code leise ändert. Was folgte, war kein einziges Ereignis, sondern eine längere Kaskade. Der CVE-Text entwickelte sich. CPE-Daten kamen spät und unvollständig an. Anbieterberatungen haben den Geltungsbereich neu definiert. Compliance-Fristen haben teilweise Wahrheiten in die Politik verschärft. Aktualisierungen über die Exposition gegenüber EOL erschienen Monate später, nachdem viele nachfolgende Entscheidungen bereits getroffen worden waren. Nichts davon war bösartig. Nichts war ungewöhnlich. Das moderne Ökosystem der Verletzlichkeit verhält sich, wenn es die Offenlegung als einen Moment und nicht als einen Prozess behandelt. wie Es geschah im Januar, Februar, März, August und darüber hinaus, je nachdem, wo Sie sitzen und auf welche Signale Sie sich verlassen. CVE-2025-24813 Wie sollten Sie reagieren? Was das für Sie bedeutet und was Sie als nächstes tun sollten So sehr ich den Begriff "unbequeme Wahrheit" nicht mag, ist er derjenige, der in diesen Umständen am häufigsten verwendet wird. Die Situation ist alles, was wir brauchen, um sie zu lösen, also ist die "unbequeme Schlussfolgerung" dieser Fallstudie nicht, dass war ungewöhnlich gefährlich. Es ist, dass nichts darüber, wie es gemeldet und verwaltet wurde, akzeptieren CVE-2025-24813 Ungewöhnlich überhaupt Die Schwachstelle kam mit keinem Fanfare. Es verkündete sich nicht als dringend. Es wurde gelöst, bevor es benannt wurde. Die Systeme, die überlebten, taten es nicht, weil sie schneller reagierten, sondern weil sie bereits vor langer Zeit entschieden hatten, wie sie Veränderungen behandeln würden. Wenn Ihre Sicherheitslage von Warum ein Update wichtig ist, bevor Sie es anwenden, dann arbeiten Sie bereits zu spät. Wissen In modernen Ökosystemen folgt Erklärung dem Handeln, nicht umgekehrt. Was das in der Praxis bedeutet , Offenlegung ist nicht mehr der Beginn der Sicherheitszeitlinie. Wenn ein CVE einen Namen, eine Punktzahl und schließlich eine Frist für die Einhaltung erwirbt, ist die entscheidende technische Arbeit oft schon anderswo stattgefunden. First Scanner geben Ihnen keine Vorhersage; Sie sagen Ihnen nur, dass Sie zu spät sind. Second CVE-Datenbanken, CPE und KEV-Kataloge sind Koordinationswerkzeuge. Sie helfen großen Ökosystemen, sich zusammenzubringen, sobald eine Erzählung stabilisiert ist. Sie haben Ihre Codebase nicht eingegeben, auch nicht, wenn sie ruhig weggelaufen ist. Eigentlich „Default safe“ ist keine Strategie. Third Viele Teams nahmen Trost in der Idee, dass diese Schwachstelle eine nicht-standardmäßige Konfiguration erforderte.Diese Unterscheidung kollabierte, als eingebettete Distributionen, Forks und Fat-JAR-Implementierungen in das Bild eintraten. Wenn Sie nicht nachweisen können, wie eine Komponente in der Produktion konfiguriert ist, können Sie sich nicht auf Sicherheitsannahmen verlassen. Gewohnheit schlägt Helden. Der Unterschied zwischen den geschützten und den exponierten Systemen in dieser Geschichte bestand nicht in Werkzeugen, Bedrohungsintelligenz oder Reaktionsgeschwindigkeit. Finally Was Sie als nächstes tun sollten Warten Sie nicht auf den nächsten CVE, um diese Annahmen zu testen. Identifizieren Sie die Quellen Ihrer Upgrade-Entscheidungen. Start Wenn Updates erst priorisiert werden, nachdem eine Sicherheitslücke benannt, bewertet oder beauftragt wurde, handelt es sich um ein Governance- und Control-Problem, nicht um ein technisches Problem. Entscheidungen werden getroffen, nicht welche Werkzeuge konsultiert werden. wenn Wie behandeln Sie „stille“ Freisetzungen. Examine Fragen Sie, welche Punktveröffentlichungen in Ihrer Umgebung automatisch angewendet würden und welche bis zur Begründung verschoben würden.Jede Verzögerung, die Sie machen, ist eine Wette, dass die Rechtfertigung vor dem Exploit ankommt. Verantwortung für End-of-Life-Komponenten explizit. Map Wenn eine Abhängigkeit von oben nicht mehr unterstützt wird, ist das Risiko nicht mehr abstrakt oder zukunftsgerichtet. Die Sicherheitsverantwortung ist bereits verschoben. Es sitzt jetzt entweder bei Ihnen, bei einem nachfolgenden Anbieter oder bei niemandem. Ich sollte meine eigene Position hier ausdrücklich machen.Ich arbeite für ein Unternehmen Das ist eine Möglichkeit, manchmal sehr praktisch, um die Kontrolle zurückzugewinnen, wenn Schwachstellen in älteren Software erscheinen. (von den Heldinnen) Aber es ist nicht die einzige Option, noch ein Ersatz für das Verständnis, wie Sie hierher gekommen sind. Erweiterter Support ist ein Sicherheitsnetz, keine Strategie. So sind beschleunigte Upgrades, kompensierende Kontrollen, Isolierung oder architektonische Änderungen. Alle von ihnen sind gültige Antworten in verschiedenen Kontexten. Der echte Ausfallmodus wählt keine Antwort. End-of-life bedeutet nicht „unsicher standardmäßig“. Es bedeutet, dass die Beweislast verschoben ist. Jemand muss jetzt aktiv Sicherheitsverantwortung tragen. Wenn Sie nicht darauf hinweisen können, wer das ist oder erklären, wie diese Verantwortung erfüllt wird, dann ist das Risiko bereits vorhanden, ob ein CVE Ihre Aufmerksamkeit hat oder nicht. Wir behandeln Sicherheit als Lebenszyklus, nicht als Ereignis. Wenn sich Ihre Prozesse nur im Moment der Offenlegung engagieren, optimieren Sie für Erzählungen, für Geschichten und nicht für Ergebnisse. Finally CVE-2025-24813 Sicherheit beginnt nicht beim Aufsteigen Die einzige Frage ist, ob Sie es bemerkt haben und ob Sie Ihre Systeme gebaut haben, um sich zu bewegen, bevor Ihnen jemand gesagt hat, warum.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

This story contains new, firsthand information uncovered by the writer.

Read My Stories

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Sicherheit beginnt nicht mit CVE Offenlegung

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Wir feiern unsere Remote-Work-Community!

HackerNoon Decoded 2024: Wir feiern unsere Gaming-Community!

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

HackerNoon Decoded 2024: Celebrating Our Writing Community!

HackerNoon Decoded 2024: Wir feiern unsere Remote-Work-Community!

HackerNoon Decoded 2024: Wir feiern unsere Gaming-Community!

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

HackerNoon Decoded 2024: Celebrating Our Writing Community!

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps