RCE-kwetsbaarheid maakt overnemen Apache Tomcat-servers mogelijk
Apache Tomcat-servers zijn kwetsbaar voor een nieuw ontdekte remote code execution (RCE)-kwetsbaarheid. Kwaadwillenden kunnen via een PUT API-verzoek de servers overnemen. Een exploit is al gepubliceerd op internet. Hiervoor waarschuwt Wallarm, dat zich richt op API-beveiliging. De kwetsbaarheid (CVE-2025-24813) is in twee stappen uit te buiten. Allereerst upload een kwaadwillende een malafide sessiebestand naar de server, met als payload een base64-encoded ysoserial gadget chain.
Dit verzoek schrijft het bestand weg naar de opslag voor sessiedata op de Tomcat-server. Stap twee bestaat uit het deserialiseren van het bestand door een GET-verzoek te versturen met de JSESSIONSID die naar de malafide sessie verwijst. De Tomcat-server haalt vervolgens het opgeslagen bestand op, deserialiseert dit en voert de embedded Java-code uit. Dit geeft de aanvaller toegang tot de server.
Wallarm stelt dat de aanval erg eenvoudig uitvoerbaar is. De enige vereiste is dat de Tomcat-server file-gebaseerde sessieopslag gebruikt, wat in veel implementatie het geval is. Ook weet de aanval de meeste traditionele securityfilters te omzeilen, waardoor de aanval moeilijk detecteerbaar is. Zo ziet het PUT-verzoek er normaal uit en bevat geen duidelijk kwaadaardige content, is de payload 64base-gecodeerd wat patroon-gebaseerde detectie bemoeilijkt en bestaat de aanval uit twee stappen waarbij het schadelijke deel van de aanval pas tijdens de deserialisatie wordt uitgevoerd.
Ik vraag me dus af of dit geen lekken zijn in ondoordacht opgezette webapplicaties die draaien op ondoordacht geconfigureerde servers. Is dit werkelijk een kwetsbaarheid in Tomcat of is dit een kwetsbaarheid die mogelijk is in op Tomcat gebaseerde applicaties?
Hoe krijg je het nog voor elkaar om hiervoor kwetsbaar te zijn?
Inmiddels weet ieder zelf-respecterende java ontwikkelaar wel dat je nooit onvertrouwde data moet deserialiseren!
En dit is breder te trekken, trouwens: valideer alle input, zelfs als het geen user input is! Zeker als je willekeurige data bestanden gaat inladen! Check of je data structuren zijn zoals je ze verwacht en geen extra data bevatten of juist elementen missen. Zijn alle numerieke waarden binnen de grenzen die je hebt gesteld? Hebben je strings een maximum of minimum lengte? Zijn floats of doubles geen NaN of (-)Infinity? Zijn arrays van de juiste grootte? Zijn linked lists toevallig oneindig doorlopend? Kom je binaire data tegen waar je base64 verwacht?
En we hebben dit soort fouten eerder gezien, trouwens.
Log4Shell was ook een deserialisatie exploit.
Ik denk dat de veiligheid van software omhoog zou gaan als libraries en functies indicatoren hebben van risico's.
Bijvoorbeeld, als een functie willekeurige code kan uitvoeren, dan zou dat in rode letters moeten staan.
Code dat nieuwe processen kan starten is ook een risico factor, evenals code dat risicovolle side-effects heeft.
For the vulnerability to be exploited, the following conditions must be true:
writes to the default servlet are enabled (disabled by default), sensitive file uploads are sub-directories of a target URL for public uploads, attackers know the names of the files, and those files are subject to partial PUT uploads (enabled by default). If an application uses file-based session persistence with default storage and includes exploitable libraries, remote code execution (RCE) is possible.
Zoals reageerder hierboven al opmerkt. Sensitive file uploads een sub-directory maken van de target URL is naïef en niet standaard. O.a. daardoor is de CVE severity moderate denk ik
hoe ga je dit product ooit echt betrouwbaar krijgen. Als beheerder is simpelweg onmogelijk om zo'n extreem omslachtig product echt met zekerheid volledig te overzien, laat staan de datastromen.
Maargoed, bij mij was toen een meer basale vraag: hoe ga je ooit continuiteit met dit product kunnen hebben.
Elke update ging gepaard met fatal errors. Waarbij wachten altijd de enige remedie was.
Dus positief bekeken; Tomcat is echt flink vooruit gegaan
(maar ik loop er liever voor weg, denk ik).
hoe ga je dit product ooit echt betrouwbaar krijgen. Als beheerder is simpelweg onmogelijk om zo'n extreem omslachtig product echt met zekerheid volledig te overzien, laat staan de datastromen.
Maargoed, bij mij was toen een meer basale vraag: hoe ga je ooit continuiteit met dit product kunnen hebben.
Elke update ging gepaard met fatal errors. Waarbij wachten altijd de enige remedie was.
Dus positief bekeken; Tomcat is echt flink vooruit gegaan
(maar ik loop er liever voor weg, denk ik).
Het is al voor je geconfigureerd. Zit in een redhat repo en updates zijn natuurlijk getest!. Onder windows moet je alles zelf doen.
Daar maak je dus een fout, default zijn ze op Windows en Linux beide hetzelfde geconfigureerd.
In dit geval is de default dat write uit staat en dus "veilig" is, zover dat kan met Tomcat.
Het is al voor je geconfigureerd. Zit in een redhat repo en updates zijn natuurlijk getest!. Onder windows moet je alles zelf doen.
Daar maak je dus een fout, default zijn ze op Windows en Linux beide hetzelfde geconfigureerd.
In dit geval is de default dat write uit staat en dus "veilig" is, zover dat kan met Tomcat.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Full Stack Developer
bij Certified Secure
Ben je toe aan een nieuwe nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
