Proof-of-concept voor ernstige bug in Flowmon-netwerktool verschijnt online

Er is proof-of-conceptcode verschenen voor een exploit van een ernstige kwetsbaarheid in Progress Flowmon. Die tool, die netwerkprestaties in kaart kan brengen, bevat een grote bug waarmee het mogelijk is code te injecteren. Die kan nu makkelijk worden misbruikt.

De bug wordt getrackt als CVE-2024-2389. Het gaat om een bug in Flowmon-versies van vóór 11.1.14, en 12.3.5. De kwetsbaarheid maakt het mogelijk voor een ongeauthenticeerde gebruiker om toegang te krijgen tot een systeem door middel van de Flowmon-interface. Daarmee kan de gebruiker code uitvoeren op een systeem. Die bug krijgt een CVSS-score van 10 en wordt als Kritiek ingeschaald. Het gaat om een CWE-78-bug.

De kwetsbaarheid werd eerder deze week bevestigd door de maker van Flowmon, Progress Kemp Technologies. Het bedrijf bracht toen met 11.1.14 en 12.3.5 een patch uit en riep beheerders op die toe te passen.

Inmiddels is er een proof-of-concept verschenen van securitybedrijf Rhino Labs. Dat beschrijft in detail hoe het mogelijk is om de kwetsbaarheid in de praktijk uit te buiten. Flowmon is een tool die veel wordt gebruikt in grote bedrijven om netwerkstabiliteit in kaart te brengen en te optimaliseren. Het is niet bekend hoeveel Flowmon-instances via internet benaderbaar zijn.

Reacties (13)

[Master FX]

Gelukkig is er een patch, maar waarom wordt er dan alsnog tot in detail uit de doeken gedaan hoe de bug uit te buiten is? Dat zorgt dan toch alleen maar voor meer slachtoffers? Niet alle systemen zullen al gepatched zijn.

[wica]

Zonder een openbare PoC, zijn dit soort bugs geen HIGH/HIGH voor o.a. NCSC en denken veel CISO's onterecht, dat het geen probleem is.

/nuance toegevoegd
Veel bedrijven, denken onterecht, dat als er geen PoC is, dat ze ook laag risico lopen. Terwijl er ook niet openbare PoC's zijn.

Daarnaast is een PoC best wel leerzaam en kan wat vertellen over het product.

[Reactie gewijzigd door wica op 25 juli 2024 13:48]

[GertMenkel]

Bij veel kwetsbaarheden waar geen PoC voor beschikbaar is, zie je dat patchen langer duurt, omdat de noodzaak niet zo hoog is. De beschikbaarheid van een PoC weegt dan ook mee in de ingeschatte ernst van een lek in veel cybersecuritymanagementframeworks. Dit terwijl het triviaal kan zijn om de beveiligingsfouten uit een systeem te halen als je de voor en na versies van de software naast elkaar legt, met als gevolg dat men verrast wordt door exploits.

Ook laat de patch weinig aan de verbeelding over. Bijna iedereen die de patch kan downloaden, kan de exploit maken. Bij binaire bestanden, zoals bij Windows Update, gebeurt dit ook, maar dat is toch een stuk lastiger (al is het vinden van exploits voor 0day patches tegenwoordig bijna automatisch te doen). In dit geval is de broncode van de software goed leesbaar en kan iedereen met een klein beetje programmeerervaring zien wat er veranderd is.

Ook omdat het hier om nogal een amateuristisch lek gaat, snap ik wel dat men geneigd is hier extra aan te dringen. De escalatie die de foutieve sudo-configuratie toestaat had van mij wellicht niet gehoeven (of had als losse kwetsbaarheid gemeld mogen worden, met een los publicatietraject).

Onder de streep denk ik dat de publicatie hiervan vooral goed is, omdat het bedrijven en organisaties dwingt om daadwerkelijk patches te installeren. Publieke PoC of niet, de kans is groot dat ransomware groepen sinds de dag van de update hier al een eigen PoC voor hebben klaarliggen.

[Blokker_1999]

Om er van te leren. Waarom geheim houden? De bug wordt al actief misbruikt. De openbaring zorgt ervoor dat anderen kunnen leren van de fout, voorkomen dat deze ooit herhaald wordt, onderzoeken of er gelijkaardige fouten in dit of andere projecten zitten, nagaan hoe we exploits kunnen opsporen,... Zovele redenen waarom het vrijgeven net goed is.

[Kip]

Een snelle zoekactie op Shodan laat zien dat er ongeveer 45 instanties vanaf het internet bereikbaar zijn. Waarschijnlijk zijn er nog meer. Shodan kan niet alles vinden.

Dergelijke diensten moeten niet rechtstreeks vanaf het internet bereikbaar zijn.

De kwetsbaarheid kan worden misbruikt met een HTTP GET-verzoek. Dit betekent dat een aanvaller mogelijk een interne Flowmon-instantie kan compromitteren door een medewerker een URL te laten klikken, mits de Flowmon-webinterface door de medewerker direct intern benaderbaar is.
Een SSRF-kwetsbaarheid op een internet-facing dienst kan ook worden misbruikt om toegang te krijgen tot een interne diensten zoals Flowmon-interface.

Vaak lekken interne hostnamen/dns entries uit door het gebruik van publieke SSL certificaten. Door het gebruik van "Flowmon" in de certificaat, kan zo een interne Flowmon instantie worden gevonden.

[Mellow Jack]

Punt 1. Dit moet inderdaad niet aan het internet hangen
Punt 2. Een Web application firewall blokkeert dit soort GET request

[Kip]

Het omzeilen van een WAF is niet uitzonderlijk. Ik zou er niet blind op vertrouwen dat deze een aanval kan blokkeren.
Verder hebben de merendeel van organisaties geen WAF op hun interne management webinterfaces.

[Mellow Jack]

Precies vandaar mijn punt Heb deze net even getest en die word opgevangen door een standaard geconfigureerde WAF

[Kip]

Probeer nu de WAF te omzeilen. Door bijvoorbeeld URL encoding toe te passen op de query parameters of andere bash commando's toe te passen in de payload. De mogelijkheden zijn zeer divers met deze kwetsbaarheid.

[wesleey]

Met diezelfde WAF zal de applicatie waarschijnlijk sowieso niet werken. Voor dit soort tooling hoort geen WAF voor te staan. Het hoort simpelweg niet publiekelijk benaderbaar te zijn.

[BCC]

Nee, maar dat gebeurt ons allemaal wel eens

[Cergorach]

@TijsZonderH

Het gaat om een bug in Flowmon-versies 11.1.14, 12.3.5 en eerder.

Dit klopt niet (verkeerd vertaald) het gaat niet om 'en eerder', de correcte vertaling zou zijn:
"Het gaat om een bug in Flowmon-versies van voor 11.1.14, 12.3.5."

Het is immers ook tegenstrijdig met:

De kwetsbaarheid werd eerder deze week bevestigd door de maker van Flowmon, Progress Kemp Technologies. Het bedrijf bracht toen met 11.1.14 en 12.3.5 een patch uit en riep beheerders op die toe te passen.

[TijsZonderH]

Eens, ik pas aan, dank!