Laat ik je een verhaal vertellen Er is een nette, bijna academische versie van hoe softwarebeveiliging moet werken. Het verschijnt in conferenties, compliance-documenten en in de vrolijke diagrammen die op marketingslides te zien zijn. Een onderzoeker vindt een bug, rustig (en professioneel) rapporteert het upstream, upstream patches het, een CVE wordt toegewezen, downstream onderhouders trekken de fix, scanners waarschuwen, verdedigers patch, en de wereld blijft meestal ok. Als dat echt zo werkte, zou ik hier niet over alleen downstream-fixes, stille patches of beveiligingsproblemen schrijven die op één plek bestaan en op een andere verdwijnen. En iedereen moet het weten. verstoord Wat je in dit artikel leert 
 
 
 
 
 
 De beveiliging Timeline Inversion: Hoe CVE openbaarmaking is niet de echte start van de beveiliging timeline. Beveiligingsresultaten: Waarom routinematige onderhoudsbeslissingen, niet reactiesnelheid of gereedschappen, bepalend zijn voor beveiligingsresultaten. Defecte indicatoren: waarom CVE-scores, scanners en nalevingsdatums niet effectief zijn voor vroegtijdige waarschuwingssystemen. Vulnerabiliteitsverstoring: Hoe ingebouwde, vervalste en eind-of-life componenten de zichtbaarheid verduisteren in kwetsbaarheden en verantwoordingsplicht. De veranderingen in governance en levenscyclus zijn noodzakelijk om te voorkomen dat we structureel te laat zijn voor 'stille' kwetsbaarheden. In februari 2025 heeft Apache Tomcat een reeks Ze kwamen zonder urgentie, zonder commentaar en zonder het soort lawaai dat belangrijke veiligheidsincidenten kan vergezellen. Routine Voor de meeste teams was er geen directe reden om deze releases anders te behandelen dan andere onderhoudsupdates. Niets leek gebroken te zijn. Niets leek gecompromitteerd te zijn. Er was geen kwetsbaarheidsidentificator om te reageren. Een paar weken later werden diezelfde releases het middelpunt van een veiligheidssituatie. Tegen de tijd dat CVE-2025-24813 in maart openbaar werd gemaakt, was het kwetsbare codepad al geïdentificeerd, gecorrigeerd en verzonden via ondersteunde Tomcat-afdelingen.De oplossing bestond voordat het probleem een naam had. Voor iedereen kwam het als een onaangename verrassing: een CVSS-score van 9,8 is een geweldige manier om je dag te beginnen. Voel je vrij om de details van de CVE hier te bekijken We zullen de inhoud later bekijken, omdat wat er wordt opgenomen en wie het opneemt deel uitmaakt van dit verhaal.De slechte technische details van de CVE zijn meestal irrelevant. mode; het moet mogelijk worden gemaakt. https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Default https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Deze volgorde van gebeurtenissen zal ons helpen begrijpen hoe CVE's kunnen evolueren en hoe dat de consumenten kan beïnvloeden. De omkering van de beveiligingstijdlijn Deze omkering is gemakkelijk te missen als je alleen naar de openbaarmakingstermijnen kijkt. beveiligingstijdlijnen worden meestal verteld alsof ze beginnen wanneer een CVE wordt gepubliceerd. Wanneer een raket op het lanceerpad begint te tellen, zien we de motoren beginnen voordat de raket de grond verlaat. Dat is het soort patroon dat we zien met CVEs. In dit geval volgde het Tomcat-beveiligingsteam een patroon dat volledig normaal is voor langdurige open source-infrastructuur. Een privérapport arriveerde. Het probleem werd onderzocht. Een oplossing werd ontwikkeld en verzonden. Stilte, en alles voordat de 'raket' de pad verliet. De bedoeling was niet geheimhouding, maar beperking: het doel is om het venster te verminderen waarin de verdedigers geen levensvatbare reactie hebben. Gewoonte vs. hype Deze aanpak werkt goed voor organisaties die punt release behandelen als iets om toe te passen van routinematig. Die teams upgraden zonder te weten waarom, en op het moment dat de kwetsbaarheid publiekelijk werd besproken, waren ze al beschermd. Voor organisaties die vertrouwen op openbaarmaking als trigger voor actie, voelde maart zich als een nul-dag.De kwetsbaarheid leek volledig gevormd, compleet met ernstpunten, exploit claims, etc. Vanuit de buitenkant leek het alsof iedereen tegelijkertijd hetzelfde risico ondervond. Twee teams konden in januari identieke versies van Tomcat hebben uitgevoerd en eindigden halverwege maart in zeer verschillende posities. de ene was geïsoleerd, de andere blootgesteld. Het was De gewoonte. De onjuiste veronderstelling van luide waarschuwingen Er is een aanhoudende veronderstelling in veel engineering organisaties dat ernstige beveiligingsproblemen zichzelf hard genoeg zullen aankondigen om aandacht te eisen. Die veronderstelling is steeds onbetrouwbaarder. In dit geval was de meest cruciale indicator niet te onderscheiden van routinematig onderhoud. Een changelog-ingang. Een versie bump. Een release die zich niet dringend voelde omdat niets nog iemand had verteld dat het moest. Zodra de CVE werd gepubliceerd, nam het gebruikelijke verhaal over. De kwetsbaarheid kreeg een naam, een score en een doelgroep. Discussies over ernst, exploitabiliteit en configuratie begonnen onmiddellijk. Prioriteit geven aan veranderingen boven verhalen Het is verleidelijk om die februari-releases te beschouwen als een gelukkige timing. ze waren niet. ze waren gewoon het resultaat van een proces dat prioriteit geeft aan het fixeren van code boven het beheren van perceptie. gestructureerd om te reageren op verhalen in plaats van veranderingen, op verklaringen in plaats van diffuses. onbewust Tegen de tijd dat het bredere ecosysteem begon te debatteren over de implicaties van CVE-2025-24813, was het technische resultaat al vastgesteld.Sommige systemen waren veilig, andere niet, en het onderscheid had niets te maken met hoe snel iemand reageerde in maart. Hoe deze CVE (en om eerlijk te zijn, de overgrote meerderheid van alle CVEs) over de hele wereld verscheen, was een botsing van interpretaties, beoordelingen en verplichtingen Dat is waar deze case study interessant wordt en zo'n geweldige steekproef maakt. Hier is de belangrijkste timeline De kritieke elementen draaien allemaal rond de CVE- en CPE-informatie van de NVD. . https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 
 
 Ik moet benadrukken dat dit niet bedoeld is om te suggereren dat er iets ongunstigs is gebeurd. Ik moet benadrukken dat dit niet bedoeld is om te suggereren dat er iets ongunstigs is gebeurd. . Hoe de dingen zijn 13 januari 2025. kwetsbaarheid Privé gemeld Het Apache Tomcat-beveiligingsteam ontvangt een privérapport van een kwetsbaarheid waarbij gedeeltelijke HTTP PUT-verzoeken en de standaardbestandsservlet betrokken zijn. 24 januari 2025: Fix Committed. De Commit De bijbehorende pull request heet “Enhance lifecycle of temporary files used by partial PUT”. https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c 10 februari 2025: Fix is stil vrijgegeven. Apache vrijgegeven Tomcat 9.0.99, 10.1.35, en 11.0.3 met de correctie inbegrepen. dat is een maand voor de openbare bekendmaking. 10 maart 2025: CVE-2025-24813 openbaar gemaakt Apache onthult publiekelijk de kwetsbaarheid via de OSS-beveiligingsmailinglijst, gerangschikt als "belangrijk" met potentieel voor RCE- en informatieverstrekking. Discovery is gecrediteerd aan COSCO Shipping Lines DIC en onderzoeker "sw0rd1ight". citeren https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 “Dit probleem heeft invloed op Apache Tomcat: van 11.0.0-M1 tot 11.0.2, van 10.1.0-M1 tot 10.1.34, van 9.0.0.M1 tot 9.0.98.” 13-14 maart 2025: PoC exploits en actieve aanvallen beginnen Binnen 30 uur na de openbaarmaking worden proof-of-concept exploits publiekelijk vrijgegeven. massascan en exploitpogingen beginnen onmiddellijk. Aanvalsmethode: upload JSP webshell via gedeeltelijke PUT, trigger via gecreëerde JSESSIONID-verzoek. Sources: Sonatype Blog | CyRisk Analysis 17 maart 2025: Een POC-exploit wordt toegevoegd aan het NVD CVE-record https://github.com/absholi7ly/POC-CVE-2025-24813/blob/main/README.md 18 maart 2025: de eerste CPE-informatie wordt toegevoegd aan de CVE De CPE Het is de magische informatie die de CVE in principe machine-leesbaar maakt. Het stelt geautomatiseerde consumenten van de CVE in staat om te ‘weten’ welke versies van het product kwetsbaar zijn. https://nvd.nist.gov/products/cpe https://nvd.nist.gov/products/cpe Op dit punt komt de CPE gewoon overeen met de oorspronkelijke versiebereikverklaring die u eerder zag. 19-26 maart 2025: Analyse van beveiligingsleveranciers gepubliceerd Rapid7, Akamai, Wiz en Sonatype publiceren gedetailleerde analyses. Rapid7 merkt op dat "geen behoefte om in paniek te raken" omdat wijdverspreide exploitatie niet werd bevestigd en sommige van de aangegeven voorwaarden van Apache werden overschat. Sources: Rapid7 Blog | Akamai Blog | Wiz Analysis 1 april 2025 :CISA voegt toe aan KEV-catalogus De CVE registreert dat CISA CVE-2025-24813 toevoegt aan zijn catalogus van bekende uitgebuite kwetsbaarheden, met vermelding van bewijs van actieve exploitatie. Sources: Keysight Analysis | Amazon Linux Advisories Begin april 2025: Enterprise Vendor Patches vrijgegeven Red Hat, Amazon, SUSE, Atlassian en andere enterprise-leveranciers geven patches vrij. De meeste benadrukken dat standaardconfiguraties niet kwetsbaar zijn omdat de standaard servlet alleen leesbaar is. Sources: Red Hat CVE | Amazon CVE 3 juli 2025: Unit 42 rapporteert 125K+ aanvalspogingen Palo Alto's Unit 42 rapporteert 125.856 exploit pogingen geblokkeerd in maart 2025 alleen. De meeste exploitatie verkeer lijkt "opportunistisch" met behulp van publieke PoCs door low-sophistication actoren. Source: Unit 42 Report Zijn we klaar? Nou, voor een aantal Tomcat-gebruikers, die op versies 9, 10 of 11, is alles goed. ze hebben een fix, en zolang ze upgraden, dan zijn ze veilig. 7 augustus 2025 - CVE bijgewerkt "Ouder, EOL versies kunnen ook worden beïnvloed." Dit is belangrijk.Dit gebeurt zeer zelden, maar er waren ingenieurs in de mix bij Apache en elders die dachten dat de waarschuwing nodig was.De CPE werd bijgewerkt, maar het kreeg geen informatie over de EOL-versies, omdat er niets specifieks was om op te nemen. 8 augustus 2025 - CVE bijgewerkt met meer informatie over EOL-versies De CVE stelt nu: “De volgende versies waren EOL op het moment dat de CVE werd gemaakt, maar zijn bekend te worden beïnvloed: 8.5.0 tot 8.5.100.” Nu de CVE is officieel van toepassing op een andere versie stream van Tomcat. Helaas, de CPE werd niet bijgewerkt. Vandaag Zelfs vandaag is deze CVE niet bijgewerkt om de CPE-informatie op te nemen die een scanner kan helpen een probleem te detecteren in versie 8.5. Dat is niet bijzonder ongewoon. Een deel hiervan kan worden toegeschreven aan de aard van de CVE. Omdat de kwetsbaarheid alleen mogelijk is als een standaardconfiguratie wordt gewijzigd. Wijzigen naar Reactie = waarheid Reactie = vals Dat wil zeggen, in theorie hangt exploitabiliteit af van de mogelijkheid van de Tomcat-gebruiker om deze wijziging te maken. Als Tomcat is ingebed op een manier die voorkomt dat deze configuratie wordt gewijzigd, dan kan het ‘embedding’-product terecht beweren dat ze niet kwetsbaar zijn. Er zijn ook veel forken en commerciële varianten van Apache Tomcat. Bijvoorbeeld het is een onderdeel van Spring Boot, en Broadcom Tanzu integreert het ook. Hoe de boodschap wordt verdund De vaak bittere waarheid is dat CVE-rapportage en het verkrijgen van adequaat bewustzijn aan de juiste mensen falen.In feite, hoe populairder een component is om te forken of in te voegen, hoe moeilijker het kan zijn om degenen te bereiken die erover moeten weten.Vaak bereiken downstream-leveranciers in de hitte van het moment het oorspronkelijke CVE-rapport, maar komen niet terug voor updates. De Tanzu correct stelt dat de CVE van toepassing is op Tanzu en toewijst het zijn eigen identifier, TNZ-2025-014. Ze waarschuwen hun gebruikers dat de CVE van toepassing is op versies 9,10 en 11, maar dan, zoals altijd, wordt het rommelig. De Tanzu suite is geavanceerd en complex. Plots, de CVE, in plaats van een eenvoudige ' Ik weet niet of Tanzu versies heeft met Tomcat 8 of eerder - ik veronderstel dat ze dat doen. Aangezien hun advies is gedateerd 2025-03-25, lang voordat de CVE had de extra EOL versie info toegevoegd, men kan sympathiseren met deze fout, zelfs als het een grote blootstelling voor oudere Tanzu producten zou kunnen zijn. Ondersteuning pagina Are-you-exposed of niet Een gemeenschappelijk scenario Tegen de tijd dat CVE-2025-24813 een naam, een score en een mediacyclus kreeg, had het resultaat al afgeweken. De oplossing bestond vóór de CVE. Sommige systemen werden beschermd voordat iemand wist waarom. Die divergentie kwam niet van bewustzijn, tooling of enige bedreigingsintelligentie. Het kwam van timing. Meer precies, van een veronderstelling dat beveiliging begint wanneer een kwetsbaarheid wordt verklaard, in plaats van wanneer de code rustig verandert. Wat volgde was geen enkele gebeurtenis, maar een langdurige cascade. De CVE-tekst evolueerde. CPE-gegevens kwamen te laat en onvolledig aan. Leveranciersadvies herziende de reikwijdte. nalevingstermijnen verhardden gedeeltelijke waarheden in het beleid. updates over EOL-blootstelling verschenen maanden later, nadat veel downstream-beslissingen al waren genomen. Geen van deze was kwaadaardig. geen van deze was ongebruikelijk. Het moderne ecosysteem van kwetsbaarheid gedraagt zich als het openbaarmaking behandelt als een moment in plaats van een proces. Hoe Het gebeurde in januari, februari, maart, augustus en daarbuiten, afhankelijk van waar je zit en op welke signalen je vertrouwt. CVE-2025-24813 Hoe moet je reageren? Wat betekent dit voor u en wat u vervolgens moet doen Hoewel ik de term "ongemakkelijke waarheid" niet leuk vind, is het de term die in deze omstandigheden het meest wordt gebruikt. de situatie is alles wat we nodig hebben om het op te lossen. dus de "ongemakkelijke conclusie" van deze case study is niet dat ongebruikelijk gevaarlijk was.Het is dat niets over hoe het werd gerapporteerd en beheerd aanvaarden CVE-2025-24813 Ongebruikelijk helemaal De kwetsbaarheid kwam niet met een fanfare. Het kondigde zichzelf niet aan als dringend. Het werd opgelost voordat het werd genoemd. De systemen die overleefden deden dat niet omdat ze sneller reageerden, maar omdat ze al lang geleden hadden besloten hoe ze verandering zouden behandelen. Als uw veiligheidspositie afhankelijk is van Waarom een update belangrijk is voordat u het toepast, dan werkt u al te laat. Weten In moderne ecosystemen volgt verklaring actie, niet andersom. Wat dit in de praktijk betekent , openbaarmaking is niet langer het begin van de veiligheid timeline. Op het moment dat een CVE een naam, een score en uiteindelijk een nalevingsdatum krijgt, is het beslissende technische werk vaak al elders gebeurd. First Scanners geven je geen vooruitzichten; ze vertellen je gewoon dat je te laat bent. Second CVE databases, CPEs en KEV catalogi zijn coördinatietools. ze helpen grote ecosystemen samen te bewegen zodra een verhaal stabiliseert. Het behandelen ervan als vroegtijdige waarschuwingssystemen creëert blinde vlekken. Eigenlijk , “default safe” is geen strategie. Third Veel teams troosten zich in het idee dat deze kwetsbaarheid een niet-standaardconfiguratie vereiste. dat onderscheid instortte op het moment dat ingebedde distributies, forken en vet-JAR-implementaties het beeld binnenkwamen. Als u niet kunt bewijzen hoe een onderdeel is geconfigureerd in de productie, kunt u niet vertrouwen op upstream veiligheidsveronderstellingen. De gewoonte verslaat de helden. Het verschil tussen de beschermde en de blootgestelde systemen in dit verhaal was niet de tooling, bedreigingsintelligentie of reactiesnelheid. Finally Wat je volgende moet doen Wacht niet tot de volgende CVE deze veronderstellingen test. Door de bronnen van uw upgrade-beslissingen te identificeren. Start Als updates pas prioriteit krijgen nadat een kwetsbaarheid is genoemd, geteld of gemandateerd, is dit een beheers- en controleprobleem, niet een technisch probleem. Beslissingen worden genomen, niet welke instrumenten worden geraadpleegd. Wanneer Hoe behandel je ‘rustige’ vrijlatingen. Examine Vraag welke punt release in uw omgeving automatisch zou worden toegepast, en welke zou worden uitgesteld tot het gerechtvaardigd is. verantwoordelijkheid voor eind-of-life componenten expliciet. Map Als een afhankelijkheid niet langer door de opwaartse stroom wordt ondersteund, is het risico niet langer abstract of toekomstgetrouw. beveiligingsverantwoordelijkheid is al verplaatst. Ik moet expliciet over mijn eigen positie hier. ik werk voor een bedrijf Dat is een manier, soms zeer praktisch, om de controle te herwinnen wanneer kwetsbaarheden in oudere software verschijnen. (Voor de helden) Maar het is niet de enige optie, noch een vervanging voor het begrijpen hoe je hier bent gekomen. Uitgebreide ondersteuning is een beveiligingsnet, geen strategie. Zo zijn versnelde upgrades, compenserende controles, isolatie of architecturale veranderingen. Al deze zijn geldige antwoorden in verschillende contexten. De echte mislukkingsmodus is niet het kiezen van een reactie. Drifting naar een staat waar niemand duidelijk verantwoordelijk is en geen reactie daadwerkelijk eigendom is, is de verkeerde keuze. Het betekent dat de bewijslast is verplaatst. Iemand moet nu actief de beveiligingsverantwoordelijkheid dragen. Als u niet kunt wijzen op wie dat is of uitleggen hoe die verantwoordelijkheid wordt vervuld, dan is het risico al aanwezig, of een CVE uw aandacht heeft of niet. Behandel beveiliging als een levenscyclus, geen gebeurtenis. Zo doen de meeste echte kwetsbaarheden.Als uw processen alleen betrokken zijn op het moment van openbaarmaking, optimaliseren u voor verhalen, voor verhalen, in plaats van resultaten. Finally CVE-2025-24813 Veiligheid begint niet bij liftoff De enige vraag is of je het hebt opgemerkt, en of je je systemen hebt gebouwd om te bewegen voordat iemand je vertelde waarom.

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

Deze audio wordt geproduceerd in de originele taal van het verhaal!

Beveiliging begint niet met CVE Disclosure

About Author

OPMERKINGEN

LABELS

DIT ARTIKEL WERD GEPRESENTEERD IN

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps