FortiSIEM bevat kritieke kwetsbaarheid die actief misbruikt wordt

Fortinet waarschuwt gebruikers voor een Kritiek beveiligingslek in de FortiSIEM-software. Het gaat om een OS-commandinjectionkwetsbaarheid, waardoor gebruikers ongewenste commando's op het besturingssysteem kunnen uitvoeren.

De kwetsbaarheid is geregistreerd onder CVE-2025-25256 en heeft een CVSS-score van 9,8. Het lek treft meerdere versies van de software: 7.3.0-7.3.1, 7.2.0-7.2.5, 7.1.0-7.1.7, 7.0.0-7.0.3 en alle versies vóór 6.7.9. Fortinet raadt gebruikers aan te upgraden naar een release waarin het probleem opgelost is. Als tijdelijke oplossing stelt de leverancier voor om de toegang tot de phMonitor-poort (7900) te beperken.

De kwetsbaarheid wordt veroorzaakt doordat FortiSIEM commandlineinterfaceverzoeken niet goed verwerkt. Daardoor kunnen hackers ongeautoriseerde code of opdrachten uitvoeren via gemanipuleerde cli-verzoeken en uiteindelijk het volledige systeem overnemen. Fortinet waarschuwt dat er een werkende exploitcode voor de kwetsbaarheid in omloop is.

Securitybedrijf GreyNoise waarschuwde op 3 augustus al dat het een 'aanzienlijke piek' zag in bruteforceaanvallen op Fortinet SSL-vpn's. Het bedrijf nam aanvallen van 780 unieke IP-adressen op één dag waar. In de afgelopen 24 uur registreerde GreyNoise aanvallen van 53 unieke IP's.

Met FortiSIEM kunnen beheerders beveiligingsgegevens uit verschillende bronnen in het netwerk verzamelen en analyseren. De software kan dreigingen en afwijkingen detecteren. Daarop kan FortiSIEM beheerders waarschuwen of zelf actie ondernemen om incidenten te mitigeren.

Reacties (37)

[JJ Le Funk]

FortiSIEM monitort op beveiligingslekken maar als het zelf lek is detecteert het niets. Daar krijg je als beheerder toch jeuk van.

[Blokker_1999]

Een SIEM doet zelf geen detecties, het is een verzamelaar van logs en events die je kan gebruiken voor analyse en daarop gaan detecteren, maar de informatie zelf wordt aangeleverd door externe tools.

[JJ Le Funk]

waarom leest het niet z'n eigen log files in voor analyse als het daar zo goed in is? of denk ik te simpel.

[Mellow Jack]

Als het vreemd gedrag is zal hij het vast detecteren. Nu is het vanuit het OS bijv een commando wat systeem info uitleest terwijl hij stiekem code mee stuurt wat iets compleet anders doet. In de log ga je dat niet zo snel terug vinden

[kodak]

Een systeem waar je kostbare gegevens over mogelijk misbruik en criminele activiteiten op worden bijgehouden hoor je om te beginnen goed te beschermen. Ik ben het met je eens dat als onbevoegden daar toch bij kunnen, en dan zelfs commando's kunnen proberen te geven, dat op zijn minst geregistreerd hoort te worden.

De verwachting dat de slager het eigen vlees gaat keuren is vooral handig als die slager betrouwbaar is. Van een systeem wat onder controle van een crimineel is kun je dat hoe dan ook niet meer verwachten. Die crimineel zal zichzelf namelijk proberen te verbergen. Het is dus ook belangrijk om dit soort systemen via andere systemen te monitoren. Bijvoorbeeld door niet maar één SIEM te hebben.

Maar nmm nog belangrijker: zorg dat je als bedrijf niet zomaar in de mooie woorden en beloften van de verkopers en ontwikkelaars trapt. Laat ze aantonen dat ze behoorlijke controles op hun code en implementaties uitvoeren door bijvoorbeeld onafhankelijk onderzoek te eisen. Dit soort systemen worden gebruikt om aan wettelijke eisen te voldoen, zoals borgen van behoorlijke verwerking van persoonlijke gegevens. Nog afgezien dat jeer als bedrijf meestal zo veel geld aan kwijt bent dat kopers wel extra eisen kunnen sturen aan dit soort software of systemen.

[Blokker_1999]

Dat is inderdaad te simpel. Aanzie een SIEM als een geavanceerde versie van de eventviewer in je Windows. Het is, heel simplistisch, puur een logaggregator. Wat je daarna met die data doet, moet je zelf weten en daar de nodige processen en automatisatie rondom ontwikkelen.

[GeroldM]

Wazuh als alternatief?

Is vervelend om op te zetten op een (virtuele) server, maar is open source en is zeer configureerbaar in de manieren waarop het aan jou kan rapporteren. Software zelf draait op Linux, maar heeft een agent voor Windows en andere besturingssystemen.

Nadat het eenmaal is opgezet, zijn de standaard inbegrepen rapportages en controle-mogelijkheden al behoorlijk prettig om mee te werken.

[Riesch]

Als tijdelijke oplossing stelt de leverancier voor om de toegang tot de phMonitor-poort (7900) te beperken.

Het was even zoeken wat er nou over die poort heen gaat. Maar via via kom ik uit op:
"The vulnerability is classified as an OS Command Injection (CWE-78) with a critical CVSS score of 9.8. It specifically affects the phMonitor service running on TCP port 7900, which is used by internal FortiSIEM components for discovery and synchronization tasks"


Ja dat wil je dus sowieso niet publiekelijk toegankelijk hebben.

[SVMartin]

En je hoopt ook dat een beheerder die wel toegang heeft van zijn werkplek, niet reeds geïnfecteerd is met malware. Natuurlijk heb je daar ook maatregelen voor genomen, maar dan nog steeds moet je snel deze forti patch uitrollen.

[D_Jeff]

Fortisiem is een product dat in 2018 is aangekocht door Fortinet en tot op de dag van vandaag ben ik niet overtuigd dat het iets toevoegd voor Fortinet. Het heeft ook een overlap met EMS, Fortianalyzer (FAZ) en FortiManager.

Reden 2: Geen volledige integratie & commitment: Het product heeft een nieuw jasje gehad, maar de kernelcode is nog steeds hetzelfde. Een volledige herschreving zie ik niet gebeuren, maar deze CVE kan daar wel aan bijdragen. Dit product kan binnen 1 kwartaal losgemaakt en verkocht worden

[aikebah]

offtopic:
commandlineinterfaceverzoeken.... past dat nog op een scrabblebord??

[Luchtbakker]

Hier ga je echt een flinke brug te ver. Want wil je hiermee zeggen dat bedrijven als Microsoft, Apple, maar ook ontwikkelaars van Linux een stel amateurs zijn omdat ze er maandelijks enkele tientallen patchen?

Iets met hoge bomen vangen veel wind. En fortigate wordt overal gebruikt, van kleinschalige tot enterprise omgevingen. En dat is niet voor niets.

Het feit dat het om poort 7900 gaat wat eigenlijk al niet van buitenaf beschikbaar zou moeten zijn, zegt al iets over jou als bedrijf als je dit wel publiekelijk open hebt staan, en echt NIETS over fortigate. En al was het wel een publieke poort, elk product blijft onderhevig aan tienduizenden hackers die maar wat graag een lek vinden om deze te misbruiken, ongeacht wat je product of dienst is.

[bzzzt]

Er is natuurlijk een groot verschil tussen de 'attack surface' van een volledig OS versus een enkele service die dan ook nog eens onderdeel is van een op beveiliging gericht stuk software. Je zou toch denken dat in het 'you had one job' geval de focus wel ligt op security.
Ik vind het daarom helemaal niet raar om juist van bouwers van beveiligingssoftware een hogere standaard te verwachten. Probleem is dat die software zelden wordt aangeschaft om daadwerkelijk veiliger bezig te zijn, maar meer om op papier compliant te zijn ('siem afgevinkt'). Dat het in de praktijk niks toevoegt of zelfs contraproductief werkt wordt helemaal niet relevant gevonden.

[Blokker_1999]

Is er een groot verschil? In Windows zijn deze maand 2 kwetsbaarheden opgelost in de GDI bibliotheek waarbij 1 van de 2 een CVSS score van 9.8 krijgt en de andere op 7.8 zit. Dat zijn geen lage scores voor wat in essentie een eenvoudige, oude bibliotheek is.

Het maakt niet uit of het hier om een service op een appliance gaat of een bibliotheek in het OS. Het onderdeel waar de kwetsbaarheid in zit is op zich niet zo groot.

En ik snap niet dat mensen blijven denken dat bugvrije code schrijven gewoon iets is dat moet kunnen, dat je er maar wat meer aandacht aan moet besteden. Maar we schrijven al zoveel testen en we vangen al zoveel af dat de bugs die vandaag overblijven in producctie vaak echt niet eenvoudig te detecteren zijn.

Ik vind het daarnaast ook spijtig dat jij er maar vanuit gaat dat bedrijven een SIEM nemen om maar een vinkje te zetten. En ja, die zijn er zeker en vast. Maar de meeste gaan er echt wel gebruik van maken. Soms onvoldoende, maar het gebruik is er wel.

[wooha]

En ik snap niet dat mensen blijven denken dat bugvrije code schrijven gewoon iets is dat moet kunnen, dat je er maar wat meer aandacht aan moet besteden. Maar we schrijven al zoveel testen en we vangen al zoveel af dat de bugs die vandaag overblijven in producctie vaak echt niet eenvoudig te detecteren zijn.

Command injection is toch wel één van de bekendste en oudste kwetsbaarheden waar een ontwikkelaar rekening mee moet houden. Waar FortiSIEM ook eerder vatbaar voor is gebleken.

Hier een proof of concept van een ander geval in FortiSIEM uit 2023 die er op duidt dat ze indertijd gewoon een string aan elkaar sleutelden en het resultaat uit lieten voeren door een shell.

https://github.com/horizon3ai/CVE-2023-34992/blob/main/CVE-2023-34992.py

Ze hadden toen ook één van de aanbevolen alternatieven kunnen gebruiken, zoals het commando rechtstreeks aanroepen via exec() met parameters. Uiteraard ook na het valideren van de parameters zelf, zoals in het genoemde geval of het wel een IP adres is. Maar zelfs zonder (effectieve) validatie is de impact dan minder en afhankelijk van kwetsbaarheden of functionaliteit in het aangeroepen commando. (Waaronder parameters die beginnen met een - en daarmee als optie/switch worden herkend door het commando. Ik heb bijvoorbeeld eens ergens -wooha als username gebruikt omdat wooha al in gebruik was. Dat vond hun mailer niet leuk)

https://cwe.mitre.org/data/definitions/77.html

https://cwe.mitre.org/data/definitions/78.html

Het is van belang wat ze in 2023 hebben gedaan naar aanleiding van die CVE. Hebben ze alleen die CVE opgelost of hebben ze uitgezocht of dit op meer plekken speelde? Van dezelfde programmeur? Van andere subprojecten?

Hechten ze belang aan defense in depth of vinden ze het niet hun probleem als een organisatie een poort open laat staan die niet bedoeld is voor publieke toegang?

Het ziet er niet positief uit gezien de onderstaande lijst CVE's in versie 7.0.0 waarin nog een aantal OS Command Injections voorkomen.

https://www.cvedetails.com/vulnerability-list/vendor_id-3080/product_id-53372/version_id-1680511/Fortinet-Fortisiem-7.0.0.html

[bzzzt]

Is er een groot verschil? In Windows zijn deze maand 2 kwetsbaarheden opgelost in de GDI bibliotheek waarbij 1 van de 2 een CVSS score van 9.8 krijgt en de andere op 7.8 zit. Dat zijn geen lage scores voor wat in essentie een eenvoudige, oude bibliotheek is.

Ok, maar de ene keer is het GDI, dan weer een netwerk driver, dan weer een HTTP library. Vergeleken met een service die letterlijk 1 type bericht moet kunnen aannemen is dat een enorm breed oppervlak.
Of probeer je te stellen dat een Siem tool zo complex is als een heel OS?

En ik snap niet dat mensen blijven denken dat bugvrije code schrijven gewoon iets is dat moet kunnen, dat je er maar wat meer aandacht aan moet besteden. Maar we schrijven al zoveel testen en we vangen al zoveel af dat de bugs die vandaag overblijven in producctie vaak echt niet eenvoudig te detecteren zijn.

Wat mij vaak opvalt aan issues in security producten is vaak de knulligheid van de bugs. Heb vaker gezien dat libraries niet geupdate worden en daardoor CVEs ontstaan, maar zelfs voorbeelden van AV tools die bijvoorbeeld bescherming van het OS uitschakelen en je daardoor meer gevoelig maken voor virussen.
Er zijn vast positieve uitschieters maar die zijn voor een buitenstaander heel lastig te onderscheiden van de rotte appels.

Ik vind het daarnaast ook spijtig dat jij er maar vanuit gaat dat bedrijven een SIEM nemen om maar een vinkje te zetten. En ja, die zijn er zeker en vast. Maar de meeste gaan er echt wel gebruik van maken. Soms onvoldoende, maar het gebruik is er wel.

Ik denk dat het verschilt per sector, het is ook niet altijd mogelijk of nuttig om conclusies te trekken op basis van bepaalde activiteit.

[aikebah]

CVEs ontstaan niet door libraries niet te updaten (al kan een niet-geupdate library wel de rootcause achter de CVE zijn, ). Als een ongepatchte library de root-cause achter de CVE is dan was de CVE dus al aanwezig voordat de library update überhaupt bestond, dus de CVE zou dan sowieso in het produkt zitten. Het enige effect van niet-updaten is dat de vulnerability er 'langer dan nodig' in heeft gezeten.

[d3burt]

Bugvrije code schrijven is bijna onmogelijk. Maar er zijn klassen van bugs die niet recht te praten zijn. Command insertion betekent dat er ergens data die van het netwerk komt aan een shell gegeven wordt. Dat had bij een code review naar boven moeten komen.

Dit soort bugs verwacht je in een TP-Link product, niet in een product van Fortinet.

De Engelse NCSC heeft hier een aardig artikel over: A method to assess 'forgivable' vs 'unforgivable' vulnerabilities.

[droba]

Hallo Luchtbakker.


Helaas heeft roel wel een beetje gelijk.

Ik snap je punt dat hoge bomen veel wind vangen, en dat netwerk/edge/security producten een extra doelwit zijn.

Maar het aantal CVE's 9 en hoger op foritnet producten is wel erg hoog. Let wel security producten die vaak hun reputatie te danken hebben aan betrouwbaarheid en veiligheid.

Een bug of een CVE kan natuurlijk gebeuren in een software product, maar als het aantal afzet tegen andere Vendoren Sophos/Palo/Checkpoint dan scoort Fortinet extreem hoog.

ongeacht of je TCP_7900 of bijvoorbeeld MGMT aan het internet hangt, dat zie ik eerder als configuratie fouten. Ben je met deze CVE's van binnenuit nog steeds extreem kwetsbaar.

Ik zou als ik Foritnet in ons portfolio zou hebben, niet blij zijn. Want dat kost me veel overuren om deze allemaal te moeten patchen.

Hierbij een lijst van alle CVE's >9 CVSS3.1

CVE-2025-25256CVE-2025-32756CVE-2025-25257CVE-2025-22252CVE-2024-21762CVE-2024-23113CVE-2024-47575CVE-2024-55591CVE-2024-48887CVE-2024-23108CVE-2024-23109

Gr Robert

[SunnieNL]

Met alleen kijken hoeveel CVE's er zijn, maak je de verkeerde vergelijking. Daarmee stel je dat een product zonder CVE veiliger zou zijn dan een product met CVE's.

Ik ken een aantal security vendoren die helemaal geen CVE's rapporteren in hun producten en die echt niet minder veilig zijn te noemen. Daarnaast zijn er vendoren die wel security updates uitbrengen zonder dat ze CVE's hebben. Je hebt vendoren die geen CVE's hebben en ook geen regelmatige security updates. En er zijn vendoren die CVE's naar buiten brengen van hun eigen oplossingen nav interne testen. En als laatste moet je ook kijken naar het aantal producten van een vendor. Een vendor met 1 product en 20 CVE's zou ik lager scoren dan een vendor met 30 produdcten en 20 CVE's.

Om even bij je lijstje met vendoren te blijven die je noemt... Checkpoint: hardcoded credentials in SFTP binnen hun applicaties die ze nog geen CVE nummer hebben gegeven (nog niet eens pending)... oeps... Dan bv. Netskope, die een vulnerability 16 (!) maanden open laat staan terwijl ze het publiek aangeven als exploitable. https://gbhackers.com/mul...-hit-zero-trust-products/

Palo Alto heeft in Juni een zelfde soort CLI injection als CVE geplaatst alleen met lagere CVSS score. Nou zegt de CVSS score ook niet direct iets over hoe makkelijk de exploit is en wordt die vaak niet meer aangepast als er wel een exploit voor is. Vorig jaar had Palo Alto ook 4 high critical CVE waarvan een met 9.9 en een met 10.

[Reactie gewijzigd door SunnieNL op 14 augustus 2025 14:31]

[droba]

Hallo Sunnie,


Ik kijk ook zeker niet alleen naar CVE's. En of porducten zonder CVE's of met veel public CVE's veiliger zijn. Dat weten we simpelweg niet.


Ik snap dat elke Vender links en rechts CVE's Bug hebben ect dat op zich zie ik ook niet als een zwakte ofzo.

Simpel feit is wel dat Fortinet erg vaak aan de beurt is en dat dat zeker iets doet met het vertrouwen in dat product.

[BSimpson]

Kijk voor de grap eens wie de kwetsbaarheden vind


Fortinet vind 80-90% van alle kwetsbaarheden zelf. Ze hebben intern een team die continue actief op zoek is naar exploits. En als ze die vinden, rapporteren ze dat ook.


Doe mij maar 10 van dat soort bedrijven die zelf actief op zoek gaan. Als je niet zoekt, ga je ze niet vinden...

[droba]

Daarmee zeg je dat andere Netwerk Security vendoren dit niet doet?

Palo heeft een eigen UNIT8200 afdeling Sophos heeft X-Ops, Checkpoint heeft hun Researchteam


Ik werk dagelijks met verschillende vendoren en ik moet eerlijk zeggen dat ik het minst durf te leunen op de Fortinet.

Hun interface, mogelijkheden, beheer is gewoon top, prijs (belangrijk) is gunstig. Dus begrijp me niet verkeerd product is verder prima.

Maaaaaaar het aantal "publieke" CVE's tast de betrouwbaarheid aan over tijd.

[SunnieNL]

Maar dat wilt niet zeggen dat de interne teams ook vulnerabilities aan publieke CVE's koppelen. Dat is wat we zeggen.

Palo Alto doet dat waarschijnlijk wel als ik uitga van hun informatie, CheckPoint kun je je afvragen met een hardcode credentials die al even open staan zonder CVE nummer. Ivanti en Ciso melden ook intern gevonden security problemen met een CVE. Netskope alleen als het de client betreft, maar niet als het hun SaaS dienst betreft.

Dus het simpele feit dat Forti Net veel CVE's publiceerd zegt totaal helemaal niets.
Zoals ik al zei, Palo Alto had er 5 hoger dan 9.5 vorig jaar, toch vind je die op de een of andere manier beter dan Forti Gate die er maar 4 heeft dit jaar. Daarnaast had Palo Alto alleen in Juni al meer dan 4 CVE's https://www.criticalpaths...ates-across-product-line/ Dus gebaseerd op aantal publieke CVE's doet Palo Alto het ook niet al te best.

[Reactie gewijzigd door SunnieNL op 14 augustus 2025 17:05]

[-Colossalman-]

Je moet natuurlijk ook kijken of een exploit vanaf internet uit te buiten is. Je management interface aan internet hangen is natuurlijk vragen om problemen. Zolang jij netjes bepaalde dingen afschermt is de kâns op inbraak ook lager. Netscalers bijvoorbeeld hebben wij best veel werk van(ook weer de afgelopen tijd). Fortinet stopt ook niet voor niks met sslvpn. Het kost ze te veel reputatie schade en het blijft maar dweilen met de kraan open.

[droba]

Hallo Yordi,


Beetje jammer deze reactie.

Denk dat de mensen hier prima weten hoe een CVE werkt.


Deze reactie zegt nog meer over de staat van ICT in Nederland

[ultimate-tester]

Ik ben het gedeeltelijk met je eerste alinea eens, maar niet helemaal met het verhaal over de poort. Natuurlijk moet die niet richting het WWW open staan, maar ook de gebruikers binnen het netwerk mogen geen exploits kunnen uitvoeren en zelfs de netwerkbeheerder mag dat niet. Het kan nu dus wel, en dat is slechte zaak.

En dan weer even terug naar de eerste alinea: Microsoft, Apple, etc. claimen niet dat ze "Global Leader of Cybersecurity" zijn.

[kabelmannetje]

maar ook ontwikkelaars van Linux een stel amateurs zijn omdat ze er maandelijks enkele tientallen patchen?

Kan je bewijs geven van deze stelling? Ben wel benieuwd waar je vandaan haalt er "tientallen ernstige security issues in Linux per maand zijn, die misbruikt worden" .

[Reactie gewijzigd door kabelmannetje op 14 augustus 2025 13:35]

[pascallj]

https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/Linux-Linux-Kernel.html?page=1&year=2025&month=7&order=1

Alleen in de maand juli, al meer dan 400 CVE's voor de Linux kernel. Dat wil niet zeggen dat ze allemaal even ernstig zijn en misbruikt worden, maar geeft wel aan dat ook daar continu gepatcht wordt.

[kabelmannetje]

Dus, wat geclaimd werd, klopt niet. Er zijn exact 0 remote vulnerable van enige vergelijkbare orde.

[Reactie gewijzigd door kabelmannetje op 14 augustus 2025 17:19]

[pascallj]

Ik claim helemaal niets. Ik geef alleen maar aan dat er ook in de Linux kernel veel CVE's zijn omdat je dat zelf blijkbaar niet wilt opzoeken.

[kabelmannetje]

Dus, claimen dat security issues van dat product ook maar enigszins vergelijkbaar met de Linux kernel zijn, is onjuist.

[pascallj]

Ik ben niet degene die dat claimde.

[kabelmannetje]

Dan moet je niet met 400 CVEs aankomen in de Linux kernel als het om herhaaldelijk serieuze remote security holes gaat in ander product.

[koelpasta]

Want wil je hiermee zeggen dat bedrijven als Microsoft, Apple, maar ook ontwikkelaars van Linux een stel amateurs zijn omdat ze er maandelijks enkele tientallen patchen?

Eeh, ja...

Iets met hoge bomen vangen veel wind.

Uhu,. En als die bedrijven (met name microsoft) hun hogebomen-winst zouden gebruiken om betere quality control te handhaven zou dat een stuk minder zijn. Maar het tegenovergestelde gebeurt en dat is dat ze de gebruikers tot testers maken. Dat betekent dat er meer kwetsbaarheden pas aan het licht komen als ze al actief worden misbruikt. Maar goed, dan hadden ze niet de rijkste techbedrijven op aarde geworden...