Kritieke kwetsbaarheid FortiSwitch maakte veranderen adminwachtwoorden mogelijk

Fortinet brengt een oplossing uit voor een kritieke kwetsbaarheid in de grafische interface van FortiSwitch. Aanvallers konden dankzij de kwetsbaarheid adminwachtwoorden op afstand veranderen. Het is niet duidelijk of de kwetsbaarheid actief misbruikt is.

Het beveiligingsbedrijf waarschuwt gebruikers van Fortinet-netwerkswitches dat een kwetsbaarheid in de interface van het FortiSwitch-besturingssysteem het mogelijk maakte voor aanvallers om op afstand adminwachtwoorden te veranderen. Dit was mogelijk door middel van een 'speciaal daarvoor ontwikkeld request'. De kwetsbaarheid CVE-2024-48887 heeft een risicoscore van 9,3 op een schaal van 10 en is daarmee kritiek.

Door middel van een update naar de nieuwste versie van FortiSwitch kan de kwetsbaarheid verholpen worden. Ook kunnen admins als workaround HTTP- en Https-toegang vanaf admininterfaces uitschakelen of het systeem zo configureren dat alleen vertrouwde hosts toegang kunnen krijgen.

Versie	Getroffen	Upgraden naar versie
FortiSwitch 7.6	7.6.0	7.6.1 of nieuwer
FortiSwitch 7.4	7.4.0 t/m 7.4.4	7.4.5 of nieuwer
FortiSwitch 7.2	7.2.0 t/m 7.2.8	7.2.9 of nieuwer
FortiSwitch 7.0	7.0.0 t/m 7.0.10	7.0.11 of nieuwer
FortiSwitch 6.4	6.4.0 t/m 6.4.14	6.4.15 of nieuwer

Reacties (49)

[Alcmaria]

Kunnen ze bij FortiNet dan niet even zelf al die FortiSwitch software installaties updaten, ze kunnen toch al bij de Admin GUI.

[-Elmer-]

Nou zo extreem is de kwetsbaarheid nu ook weer niet. Doorgaans zit er nog een router en firewall tussen het internet en de switch. En alhoewel echt niet alle IT'ers even capabel zijn, kom ik het echt maar zelden tegen dat de management interface van een switch vanaf het internet benaderbaar is. De management interface is niet altijd goed afgeschermd en in een apart management VLAN geplaatst maar public facing, nee zelden.

[Reactie gewijzigd door -Elmer- op 8 april 2025 22:35]

[Erikkamm]

Het is altijd af te raden om een admin interface via het internet beschikbaar te maken. Zelfs met mfa moet je dit vermijden. En bovendien, zou je dat ook in het interne netwerk moeten bespreken tot stepstone servers van waaruit het beheer mag worden uitgevoerd.

[willieverhoef]

Maar je hoeft toch ook niet te verwachten dat de leverancier zijn software zo maakt dat iedereen erbij kan?. Soms vraag ik me wel af hoe het kan dat Fortinet hier iedere keer lachend onderuit komt.

[thetakman]

Fortinet komt vaak in het nieuws met kwetsbaarheden of exploits dat klopt.
Maar tegelijkertijd, Fortinet is er over het algemeen heel erg open over.

Dit kan je alleen maar als positief zien, ze stoppen zover we weten niks in de doofpot. Dus of Fortinet is inderdaad erg lek vergeleken met de concurrentie (lijkt me héél erg sterk) Of bedrijven als Huawei en Sophos en andere communiceren een heel stuk minder open over hun beveiligingsincidenten.

[willieverhoef]

Tja, ook daar , zijn oude rapporten al of niet gekleurd over
https://loopback1.net/202...palo-alto-and-checkpoint/

[thetakman]

Artikel zegt zelf:

Fortinet geeft aantallen voor hoeveel devices ze in omloop hebben.
Palo Alto en andere vendors houden dit geheim.

En vervolgens eindigt het artikel met:

This is just pondering without hard facts and it’s difficult to know what happens behind vendor’s curtains. You can read certain messages from public discussions about vendors, their products, and practices. In the end, you can’t count on that too much

Oftewel kan niet echt zeggen dat dit een goede bron is om te zeggen dat ze minder of meer veiliger zijn omdat ze er open over zijn.

Zelfs in het artikel komt het ter spraken dat Fortinet er inderdaad heel open en bloot over is precies wat ik zeg.

[kodak]

Maar je kan wel verwachten dat onbevoegden op apparaten proberen in te loggen. En dan is het dus verstandig om dat zo veel mogelijk te voorkomen, zeker direct vanaf het internet.

[willieverhoef]

Zeker, maar dat is één deel van de beveiliging. Anders hoeft er ook geen wachtwoord op de admin pagina te zitten als je op één ding vertrouwd. Maar een "speciaal" request inbouwen ruikt toch een beetje naar een achterdeurtje.

[kodak]

Speciaal request gaat om hoe de exploit werkt. Zo werken wel meer exploits via webservices. Het is speciaal omdat het gewoonlijk niet geaccepteerd hoort te worden. Het wil niet zeggen dat het accepteren dus maar een bedoelde functionaliteit is die geheim moest blijven.

[Hatseflats]

Ik denk dat jij er een beter inzicht in hebt dan die kodak knakker. Ik zou ook niet meer op hem reageren. Da's een gevalletje DKE. Heb ik ook al gehad met verscheidene alhier.

Ik denk nl. zelf ook zoals jij, zeker aangezien het een bedrijf is uit een bepaald land.

[Kabouterplop01]

Bent u dan regelmatig het internet aan het afstruinen om zulke kwetsbaarheden te zoeken?
Overigens gaat het er niet om of jij vindt dat die kwetsbaarheid kritiek is of niet. Het gaat er om dat het zeer eenvoudig is om het uit te buiten.

[Reactie gewijzigd door Kabouterplop01 op 9 april 2025 07:40]

[-Elmer-]

Het gaat er om dat het zeer eenvoudig is om het uit te buiten.

En dát is nu juist mijn punt. Het is doorgaans niet zeer eenvoudig uit te buiten want management interfaces van switches zijn zelden benaderbaar via internet. Je zult eerst toegang moeten krijgen tot het interne netwerk alvorens deze kwetsbaarheid uit te kunnen buiten en in veel gevallen ook tot het management VLAN.

En wat betreft het afstruinen van internet naar kwetsbaarheden. Dat gebeurt de hele dag door en volledig automatisch, zowel door personen en organisaties met minder nobele doelen als door organisaties met goede bedoelingen (bedrijven waarschuwen dat ze kwetsbaar zijn).

[Reactie gewijzigd door -Elmer- op 9 april 2025 08:03]

[Tozz]

Gaat ook niet uitsluitend om Internet toegang. Switches publiek op Internet benaderbaar zal inderdaad niet zo vaak voorkomen. Maar in bedrijfsnetwerken is het al een stuk gangbaarder dat netwerkapparatuur 'gewoon' in het reguliere LAN hangt. Of dat 't wel een eigen VLAN heeft, maar verkeer van het LAN naar het switch management VLAN open gezet is voor beheersdoeleinden.

En dan is het weer een ingang voor bijvoorbeeld malware of een hacker.

Grote hacks zijn nooit 1 schakeltje. Het is een hele keten aan kleine kwetsbaarheden.

[DigitalExorcist]

En het hoeft niet eens malware of een hacker te zijn. Het kan ook een ontevreden, zojuist ontslagen medewerker van je bedrijf zijn die toevallig ook iets van PC's en netwerken afweet om de boel te verzieken.

(Random voorbeeld maar bijv. dat DOGE gedoe in Amerika waar tienduizenden mensen even per tekstberichtje ontslagen worden zou zoiets wel kunnen triggeren...)

[kodak]

Alleen maakt dat wel een verschil als het gaat om een securitybug kritiek noemen.

[Tozz]

De CVE score houdt geen rekening mee met specifieke design keuzes van de gebruikers/beheerders. De CVE score is een indicatie van de ernst van het specifieke lek, los van allerlei randvoorwaarden die verschillen per implementatie.

En dan is 'unauthenticated users can change the admin password' wel zo ongeveer het ergste dat je kan overkomen.

[-Elmer-]

Dat is niet helemaal waar. Iets preciezer:
- CVE is een nummer en beschrijving van een kwetsbaarheid maar heeft geen 'score'.
- Aan een specifieke CVE wordt vaak een CVSS score gekoppeld. Daar zijn in de loop der tijd de nodige ontwikkelingen in geweest (als in: wat bepaalt de score). Inmiddels zijn we aanbeland bij CVSS 4.0 en is er zoiets als een base score, een temporal en een environment score die tezamen de ernst bepalen van een kwetsbaarheid.

[kodak]

De cvss score gaat wel degelijk om de omstandigheden zoals design keuzes, bedoelingen hoe het apparaat wel en niet toe te passen en toe te passen security best practices zoals de fabrikant die omschrijft. En die omschrijvingen zijn in dit geval het niet gebruiken van deze interface voor het internet en intern een dedicated beheernetwerk gebruiken. En dan is deze security bug zeker niet het ergste wat je kan overkomen. Het is vooral erg als de eigenaren zo eigenwijs zijn de impementatiebedoelingen te negeren en de interface wel bereikbaar voor onbevoegden te maken. Die omstandigheden veroorzaken dat het kritiek is. Pas de bedoelde manieren toe en het is niet meer kritiek. Al is het dan waarschijnlijk nog steeds onacceptabel dit niet te verhelpen.

[nullbyte]

VLAN's, 802.1q is een tag in het ethernet frame. VLAN's zijn bedoeld als beperking van het broadcast domein. Al helpt het wel bij beveiliging door segmentatie, het is geen beveiligingsmaatregel. Net zo min als dat natten dat is.

[Reactie gewijzigd door nullbyte op 9 april 2025 20:30]

[Tozz]

Haha. Segmentatie helpt wel degelijk voor beveiliging. Het is zo ongeveer netwerk security maatregel 1.

Het is letterlijk het isoleren van Infrastructuur

[Reactie gewijzigd door Tozz op 11 april 2025 07:47]

[kodak]

Overigens gaat het er niet om of jij vindt dat die kwetsbaarheid kritiek is of niet

Het gaat er om dat een securitybug kritiek noemen niet zomaar redelijk is. Daarom horen bij het invullen van de gegevens voor een cvss score ook niet zomaar de meest ernstige omstandigheden gebruikt te worden. Dat gaat alleen op als de gebruikers zo onverstandig zijn om niet de gebruikelijke en geadviseerde installatie toe te passen, die bij deze switches al lange tijd is om juist het beheer streng te scheiden van het internet en zelfs gewone lokale netwerk. Deze securitybug is niet kritiek als klanten het behoorlijk installeren. Met als resultaat dat vooral klanten die beveiliging niet zo serieus nemen het probleem kritiek maken, niet de securitybug zelf.

[Luchtbakker]

De impact is natuurlijk in een goed beveiligde omgeving niet zo groot. Want je bent wel heel erg dom als je web interfaces van bijvoorbeeld een firewall als deze publiekelijk toegankelijk maakt.

Als je dan al bij de web interface komt, ben je eigenlijk al te ver en heb je een hele andere uitdaging.

[kodak]

Fortinet verwijst in documentatie voor installatie zelfs vaak naar security best practices, waarin ook staat dat je beter een apart administrator netwerk kan gebruiken en zeker niet beheer direct via de wan interface te doen.

De vraag is dus waarom ze kennelijk tegen hun eigen best practice in ervan uit gaan dat de interface beschikbaar is.

Het kan bijvoorbeeld zijn dat het genoemde request te makkelijk via een admin netwerk gedaan kan worden, zoals in een administrator netwerk waarin de beheerders ook mogen browsen op het internet of mails ontvangen waarin automatische requests worden gedaan.

[nullbyte]

Geen enkele poort anders dan die van een VPN zou aan het internet blootgesteld moeten worden en dan zeker geen well known poort gebruiken voor deze VPN. Poortje 22 is de meest gescande poort op het internet. Best practice is een VPN. Iets dat de xz liblzma vulnerability van verleden jaar april keihard heeft duidelijkgemaakt.

[Reactie gewijzigd door nullbyte op 9 april 2025 20:50]

[willtc]

Is al bekend of dit alleen van toepassing is op standalone FortiSwitches en/of ook op de FortiSwitches die aan een FortiGate zijn gekoppeld?

[Drardollan]

Een FortiSwitch die beheerd wordt door een gate heeft geen admin GUI aan staan (twijfel of dat zelfs kan, nooit geprobeerd).

[Tozz]

Dat hebben ze wel. Https access staat standaard aan. Ook als ze via fortigate beheerd worden

[Soldaatje]

Update 6.4.15 is al van 30 oktober 2024, is al een tijdje beschikbaar.

[Houtenklaas]

Ik hoop van harte dat iedereen de workarounds by default gebruikt cq ervoor zorgt dat de administratieve interface met "zero trust" 100% dichtstaat met een opening vanuit een trusted VLAN met voldoende drempels daarvoor. Ik snap dat het natuurlijk niet OK is, maar als je je management interface goed hebt ingericht is er weinig aan de hand lijkt mij.

• Disable HTTP/HTTPS Access from administrative interfaces
• Configure trusted hosts to limit the hosts that can connect to the system:

[Drardollan]

Als je als beheerder een standalone FortiSwitch met zijn GUI aan het internet hebt hangen dan moet je echt heel snel een ander vak gaan uitvoeren.

Niet zo heel spannend dit dus, intern zullen de meeste FortiSwitches beheerd worden door een gate en dus geen eigen GUI open hebben staan. Er is weinig reden om een FortiSwitch te kopen als je dit niet doet, dan zijn er goedkopere alternatieven die veel makkelijker verkrijgbaar zijn en beter geprijsd zijn.

[Anoniem: 334725]

Nou nou zo veel mensen die claimen dat je je management interface op een VLAN moet zetten.

Een VLAN is niet meer dan een nummertje op je pakketjes, het heeft niks te maken met veiligheid. Het is een logische scheiding.

[Houtenklaas]

Jouw managed switch zorgt er anders netjes voor dat het verkeer ook fysiek gescheiden wordt. Dat het op je trunk door elkaar loopt klopt ja, maar als het netjes geconfigureerd is, is het verkeer ook daar logisch van elkaar gescheiden. Heeft wel degelijk te maken met veiligheid.

[Bor]

Hoe zorgt de switch ervoor dat het verkeer fysiek wordt gescheiden? Dat doet VLAN tagging in ieder geval niet.

[themadone]

Laten we er even vanuit gaan dat je 2 vlans hebt, 1 voor al je management interfaces en 1 waar je clients zitten.

Wat je dan kan doen, mits je switches dit kunnen, is een ACL inrichten die toegang tot je management vlan alleen toestaat vanaf 1 cliënt/hop off server.

Dan kan je vanaf een random cliënt niet bij die interface komen. Als je beheer bak dan ook nog even knap dicht timmert met 2fa kun je zeggen dat je je best hebt gedaan om de management interface van je switch veilig te houden.

Dat er afhankelijk van de gebruikte hardware en config misschien mogelijkheden zijn om vlan te hoppen etc laat ik hier even buiten beschouwing. Het is niet heel realistisch om te denken dat je management helemaal kan scheiden op basic switches. Er zijn wel switches die echt een dedicated poort hebben voor management, Cisco heeft dit op sommige modellen, als je die hebt zou je echt helemaal fysiek kunnen scheiden, maar komt het alsnog samen op een gateway/firewall.

[Houtenklaas]

Jij snapt best wat ik bedoel. Mijn VLAN15 zit bij mij op fysieke poorten 1-5. Vlan 69 op fysieke poorten 6-9. En dat verkeer is daar volstrekt gescheiden van elkaar. Dat doet VLAN tagging wel degelijk, samen met de configuratie van je switch. Daarom had ik het ook over een "managed" switch ...

[Junketsu]

Alsnog gaat het door hetzelfde logische circuit heen. Dus niks fysieke scheiding.

Als er een bug in de managed switch, dan kan je in een ander vlan terechtgekomen.

Fysiek betekent dat het daadwerkelijk andere apparatuur en kabels zijn die worden gebruikt. Dus gescheiden netwerken.

[Houtenklaas]

Daar kunnen we verrassend kort over zijn. Als verkeer op poort 1 uitkomt en niet op poort 2, dan is dat fysiek gescheiden omdat je dat logisch zo hebt ingesteld. Op de trunk is het logisch gescheiden. Dat is natuurlijk kipsimpel met wireshark aan te tonen.

[nullbyte]

VLAN 802.1q is een tag in het ethernet frame, het is bedoeld voor scheiden/verkleinen van het broadcast domein. Ja, het is best practice om dit in te stellen op een loopback adres van een switch of router. Het is echter geen veiligheidsmaatregel.

VLAN-specifieke aanvals technieken volgens https://attack.mitre.org/
T1599 – Network Boundary Bridging

🔗 https://attack.mitre.org/techniques/T1599/
Uitleg:
Deze techniek beschrijft hoe aanvallers netwerkgrenzen proberen te overschrijden, bijvoorbeeld tussen gescheiden VLAN's. Dit kan via misconfiguraties of kwetsbaarheden in switches of routers, waardoor een aanvaller verkeer tussen VLAN's kan injecteren of onderscheppen.

T1599.001 – VLAN Hopping
🔗 https://attack.mitre.org/techniques/T1599/001/
Uitleg:
Specifieke subtechniek van Network Boundary Bridging. Hierbij probeert een aanvaller verkeer naar een ander VLAN te sturen (bijvoorbeeld via double-tagging of switch spoofing) om toegang te krijgen tot andere netwerksegmenten die normaal geïsoleerd zijn.

[Houtenklaas]

Wat zeg je nu precies ... Dat kwetsbaarheden in routers er mogelijk voor kunnen zorgen dat VLAN informatie naar andere segmenten lekt? Waar dient een VLAN ook weer voor? (hier gevonden). En dan blijf ik graag weg van "mogelijke" kwetsbaarheden in switches, daar kan je alles wel mee doodredeneren. Het ging er om dat je met VLAN's netwerken kunt segmenteren en een fysieke scheiding in netwerkpoorten kunt bewerkstelligen. En die blijft uiteraard staan als een huis.

Wat is een VLAN?

Een VLAN is een virtueel LAN waarmee u uw netwerk kunt segmenteren zonder de noodzaak van fysieke segmentatie. VLAN's zijn zeer flexibel en kunnen worden gebruikt om veiligheid, flexibiliteit en prestatievoordelen te bieden. VLAN's werken door Ethernet-frames in te kapselen met een VLAN-header die de VLAN-ID bevat. Deze ID wordt gebruikt om te identificeren welke apparaten zich op welk VLAN bevinden.

VLAN's worden gemaakt door switchpoorten toe te voegen aan een bepaald VLAN. Apparaten op hetzelfde VLAN kunnen met elkaar communiceren zonder dat er een router nodig is. Dit maakt VLAN's zeer efficiënt en eenvoudig te beheren. U kunt een VLAN zien als een virtuele switch die zorgt voor isolatie tussen apparaten.

[Die_ene_gast]

Als jouw vLAN afgeschermd is en alleen benaderbaar is door een stepping stone die je met bijvoorbeeld DUO mfa, dan zit je al heel goed hoor.
Of anders leg jij mij even uit hoe dat beter moet?

[Pinkys Brain]

Dan zet je de admin interface toch op een vlan ... oh wacht, nevermind.

Eigenlijk zou je gewoon niks met een http admin interface moeten gebruiken, het is gegarandeerd zo lek als een mandje ... en met een switch heb je weinig opties om de interface af te schermen.

[ZeromaNoiS]

Je zet uiteraard je admin interface in een high secure management VLAN, dus waarom nevermind?

[Pinkys Brain]

De manier om je VLANs in te stellen op een VLAN zetten is riskant (niet de enigste, wel de makkelijkste voor troubleshooting).

[Reactie gewijzigd door Pinkys Brain op 8 april 2025 22:27]

[Johan9711]

Hoezo? Je wilt toch juist dat het beheer van je gesegmenteerde netwerk maar in een specifiek segment uit te voeren is? Anders heb je juist met deze kwetsbaarheid een groot probleem, want dan is in feite heel je segmentatie weg.
Wanneer je beheerinterface en SSH netjes alleen vanaf je management VLAN bereikbaar zijn, heeft deze kwetsbaarheid vermoedelijk een stuk minder impact.

[CH4OS]

Als je dan toch beheer vanuit iets specifieks doet, beheer je waarschijnlijk meerdere switches. Dan ga je ook niet elke switch met de hand langs om instellingen aan te passen. Gelukkig kennen de switches dan ook een api en kun je het dus scripten. Heb je de webinterface niet eens nodig en spaar je dus lokaal een klein beetje resources en is de omgeving een stuk veiliger.

[Cyberpuppy]

In het geval je deze kwetsbaarheid kunt uitbuiten heb je hoe dan ook een enorm probleem. Het vereist namelijk dat je al van binnenuit het netwerk kunt benaderen. Dan helpt deze kwetsbaarheid niet, maar je netwerk is al gecompromitteerd.

[Pinkys Brain]

Ik had niet door dat ze ook nog SSH hadden, ik dacht dat HTTP de enigste manier was (plus VLAN trunking).

[Cyberpuppy]

Hoezo. Als je een beetje zakelijke switch koopt dan kun je prima HTTP en HTTPS uitzetten. Alternatief kun je ook nog ACLs zo instellen dat de interface er wel is, maar effectief niet benaderbaar is.