Ook lek in Fortigate-vpn maakt netwerken Nederlandse bedrijven kwetsbaar

Wederom is een lek in vpn-software naar buiten gekomen, waarbij Nederlandse bedrijven kwetsbaar zijn voor aanvallen van buitenaf. Er is een patch beschikbaar, maar net als bij het lek in Pulse Secure blijkt dat veel bedrijven die niet hebben geïnstalleerd.

Dat blijkt uit onderzoek van het radioprogramma Reporter Radio, dat zondagavond aandacht besteedt aan het lek. Volgens NOS gaat het om ongeveer 900 bedrijven en instellingen die gebruikmaken van de Fortigate-vpn en de patch niet hebben geïnstalleerd. Om welke bedrijven het precies gaat is overigens niet duidelijk, maar wel heeft het Nationaal Cyber Security Center in augustus al gewaarschuwd voor de kwetsbaarheid.

Specifiek gaat het om de kwetsbaarheden CVE-2018-13379, CVE-2018-13381 en CVE-2018-13384, die aanvallen beschrijven met kwaadaardige http-verzoeken en een buffer overflow via een ddos, waardoor een aanvaller ongeautoriseerde toegang tot het interne netwerk zou kunnen krijgen. Volgens het NCSC is er een exploit beschikbaar en is er een hoog risico op misbruik. Reporter Radio meent overigens dat er al misbruik van het lek wordt gemaakt. Welke bedrijven en instellingen in Nederland kwetsbaar zijn wil het radioprogramma niet bekendmaken, omdat er nog steeds risico's zijn vanwege de ongepatchte software.

Bedrijven zoals KLM en Shell bleken al kwetsbaar te zijn voor misbruik van hun vpn door ongepatchte software. Daarbij ging het om Pulse Secure. Bij dit lek gaan er geluiden dat Chinese staatshackers een exploit inzetten om toegang te krijgen tot de interne netwerken.

Reacties (83)

[D_Jeff]

Voor de FortiGate geld dat de CVE's gelden voor de Firmware (FortiOS) -- FortiClient lijkt niet getroffen te zijn.

Korte check voor wie veilig wil zijn:
Firmware version:
6.2: 6.2.2 en hoger
6.0: 6.0.6 en hoger
5.6: 5.6.8 en hoger
5.4: 5.4.13 en hoger

Voor wie nog op FortiOS 5.4 zit: Je zit in hetzelfde schip als Win 7 - De ondersteuning verloopt binnenkort en 5.4.13 of 5.4.14 kan best wel eens de laatste release zijn. Tijd om te upgraden naar 6.0 (5.6 heeft niet zoveel nut en 6.2 zit nog in de 'speeltuin van de Devvers' door het wijzigen van features of verwijderen ervan)

[bwiep]

Schaamtelozen paste van Fortinet website:

Affected Products

FortiOS 6.0 - 6.0.0 to 6.0.4
FortiOS 5.6 - 5.6.3 to 5.6.7
FortiOS 5.4 - 5.4.6 to 5.4.12
(other branches and versions than above are not impacted)
ONLY if the SSL VPN service (web-mode or tunnel-mode) is enabled.
Solutions

Upgrade to FortiOS 5.6.8 or above, 6.0.5 or above, 6.2.0 or above, or upcoming 5.4.13.

Maw jij hebt de laatste versies beschreven maar dat wil niet zeggen dat daf ze niet al eerder opgelost zijn. Bv 6.0.6. Is nog geen advised production firmware. Idem met 6.2.

[xSNAKEX]

Draai al tijden zonder problemen 6.0.6. op meerdere devices. Dit is nu bijna 2,5 maanden uit en kan je echt wel gerust gebruiken. 6.2 als geheel heeft best wel wat unieke features en ook deze kan al tijden zonder grote risico's gebruikt worden.

[dasiro]

op meerdere devices of in verschillende configuraties? De ene situatie is de andere niet en het kan goed zijn dat je de functionaliteit waar problemen mee kunnen zijn helemaal niet gebruikt, waardoor het lijkt dat "alles" stabiel is.

[xSNAKEX]

Beiden, mix van 30D, 60D, 100D, 30E, 50E, 60E en 80E's in verschillende configuraties met wisselende services in gebruik.
Uiteraard zal het niet zo zijn dat alles helemaal bug vrij is, maar een groot deel zal al bekend zijn en is gedocumenteerd en hoogste waarschijnlijk niet extreem breaking voor de functionaliteiten. Zie ook https://docs.fortinet.com...notes/933609/known-issues
Wat echter wel het geval is, is dat o.a. https://fortiguard.com/psirt/FG-IR-19-144 gefixed is.

In het verleden ben ik wel vaker discussies over de nieuwere FortiOS firmware tegen gekomen, waarbij mensen tot in lengte van dagen blijven beweren dat nieuwere (feature) firmware nog absoluut niet productie klaar is en zelfs mensen die om deze reden niet eens boven 5.2.x durfden te gaan.
Zelf heb ik deze ervaring helemaal niet.

Na release wacht ik een week of 2 a 3, waarna ik de firmware eerst thuis uitprobeer. Wanneer ik deze een paar weken getest heb begin ik hem ook stapsgewijs uit te rollen naar een paar andere devices. Na een maand gebruik rol ik het dan gefaseerd verder uit naar de andere devices. Dit maakt het nog steeds niet een 100% garantie dat alles overal goed zal werken natuurlijk, maar het is mijn inziens beter dan andere issues en vulnerabilities een langere tijd te laten bestaan.

Wat ik in het verleden wel ben tegen gekomen zijn vreemde onverklaarbare issues zoals packet loss, drops, SD WAN issues, etc. Verder onderzoek wees er dan meestal op dat waarschijnlijk niet het juiste upgrade patch was gevolgd bij het upgraden van de firmware. Na een factory reset, herinstallatie van dezelfde firmware en het opnieuw invoeren van de config (handmatig) waren de issues echter weg en werkte alles dan naar behoren.

Zelf heb ik het idee dat mensen die problemen ervaren met nieuwe firmware vooral van zo iets dergelijks last hebben. Dit ligt mijn inziens dan dus echter niet aan de firmware an sich, maar aan een foute/verkeerde/mislukte firmware upgrade.

[D_Jeff]

Als Certified Fortinet Professional kan ik je zeggen:
In sommige versies (6.0 / 6.2 release 'train') zijn de CVE's niet erg netjes opgelost (Haast op de Devvers om die versie live te krijgen)

Dat hebben ze in de latere versies wel netjes opgelost voor in ieder geval 6.0 -- Voor 6.2.0/6.2.1 was het wel "first time right" qua security, maar veroorzaakte het een memory heap leak*

* In deze memory heap leak sprak de kernel 2x zoveel geheugen aan voor 1 actie, maar werd na het afronden slechts de normale hoeveelheid geheugen vrijgegeven.
Het resultaat laat zich raden: Na een paar uren/dagen zat je FortiGate in Memory Conserve mode, waardoor je FortiGate bijna niets meer deed.

[bwiep]

Idd hier ook de certificeringen. Maar vooral problemen gehad met 6.2. Niet stabiel vastlopers tot zelf sd wan functionaliteit welke niet correct route veranderingen opvangt.

Waarom 6.0.6 nog niet advised is kan ik niet vertellen maar draai 6.0.5 zonder grote problemen maar met de wat bekende kleinere

[TommyboyNL]

Bij het upgraden van een cluster naar 6.0.6 kan je tegen een bug aanlopen waarbij je configuratie niet in sync komt, met als enige fix om het cluster op te breken en opnieuw aan te maken. Hier is gelukkig omheen te werken door uninterruptable upgrades uit te zetten alvorens te upgraden, en dit na de upgrade weer aan te zetten.

[m0nkm0nk]

Vervelende memory leak was dat inderdaad. Gelukkig wel verholpen in 6.2.1
Verder eingelijk geen problemen bij klanten met v 6.2.x.

[slelieveld]

Hi D_Jeff, waar vind je dat 6.2.2 al uit is?

[D_Jeff]

Is als Nightly al beschikbaar, stable release is eind volgende week verwacht (als die datum niet weer wijzigt)

[slelieveld]

Link?

[TommyboyNL]

Is er niet. Nightlies zijn vaak alleen via support te verkrijgen bij écht breaking issues die in de volgende release gefikst zouden moeten zijn. Ga er maar van uit dat als je een firmware niet zelf kan downloaden via support.fortinet.com of fndn.fortinet.net, je deze ook absoluut niet moet willen draaien.

[bvdli]

Het gaat om de SSL-VPN van Fortinet aan de "server kant", FortiClient is slechts de eindpoint of client die verbindt met een VPN service op een Fortigate.

[D_Jeff]

Dat klopt. Vergeet niet dat een VPN tunnel 2 punten nodig heeft om te kunnen werken:

FortiGate (Met de SSL-VPN server)
FortiClient (client eindpunt)

In het geval van Pulse waren zowel de client als de server het bokje.
Bij deze CVE's van Forti is alleen de "SSL-VPN server" getroffen. Echter verwacht ik wel dat de FortiClient ook bijgewerkt gaat worden "just in case"

[dasiro]

je kan ook sites met fortigates verbinden zonder dat je clients nodig hebt

[KrisBerd]

Kan je in één keer upgraden van 5.4 naar 6.0.6 of moet dat in een volgorde met tussen versies?

[D_Jeff]

Dat hangt van je 5.4 versie af.
Het kan wel, maar ik adviseer om eerst naar 5.6 te gaan en dan direct door naar 6.0.x

[blinchik]

Ga naar de support site, downloads (https://support.fortinet.com/Download/FirmwareImages.aspx) en daar kies je "upgrade path".

Als je dan je model invult, bron en doel firmware, dan zie je het exacte upgrade path dat je moet uitvoeren.

[deSenna24]

Niet alleen Fortigates hadden hier last van, elke vendor zit met het lek.

Enkele weken terug hebben wij bij bijna al onze klanten die een risico hadden een upgrade gedaan.

[bvdli]

De kwetsbaarheden zijn in Mei al opgelost door Fortinet.

Het gaat niet om VPN in het algemeen maar om de SSL-VPN implementatie. Specifiek de SSL-VPN service (web-mode or tunnel-mode) in de eerste bug, en SSL-VPN web portal service in de andere twee bugs.

Zie ook https://fortiguard.com/psirt/FG-IR-18-384, https://fortiguard.com/psirt/FG-IR-18-387 en https://fortiguard.com/psirt/FG-IR-19-002

[johnkeates]

Tsja, dat spul wordt onder contract neergezet en de contract managers aan de betalende kant kunnen weinig inschatten qua risico's en technische diepgang. Dan krijg je dit...

Is niet anders dan met Juniper, HP of Cisco spul om maar wat te noemen, gaat eigenlijk altijd stuk op kennis en management. In theorie 'koop je een oplossing', maar hoe turnkey en MSP een stuk technologie ook is, zonder kennis kom je eigenlijk altijd wel in de problemen. Als generieke manager of MBA koop je dat risico af (in theorie), maar problemen in de echte wereld bestrijd je niet met papieren tijgers.

In de praktijk moet je om dit soort zaken te bestrijden gewoon weten wat je doet en op z'n minst wat diepgang qua technische kennis hebben. Dat kan er bijv. toe leiden dat je je aanmeldt op een security-announce list naast dat je zelf aan monitoring doet en dit soort zaken (security patches) tijdig test en uitrolt.

Maar dat kost dan weer geld, en dan laten veel organisaties liever relatief simpele zaken (zoals een maanden oude vuln met beschikbare patch) links liggen in de hoop dat er niks gebeurt.

[likewise]

Als je je er echt in verdiept, kom je toch eerder op WireGuard uit?

[johnkeates]

Nee, maar wel bijv bij IKEv2 of OpenVPN waar gewoon goede toetsbare auditing voor bestaat zodat je het aan de lopende band in de gaten kan houden. Daarom is er bijv. ook OpenVPN-NL [https://openvpn.fox-it.com/].

WireGuard heeft wel potentie, en na de nodige audits krijgen we vast ook goede opties om over te stappen.

Het onderliggende probleem blijft dan echter nog steeds: als je als bedrijf niet weet waar je mee bezig bent en puur risico probeert af te kopen ben je nog steeds het haasje. Maakt qua implementatie niet uit...

[Reactie gewijzigd door johnkeates op 22 juli 2024 23:11]

[blinchik]

Fortinet is wel wat meer dan een gewone VPN en "risico afkopen".

Ze hebben enorm veel producten, maar in hun firewall reeks (waar ook de SSL vpn in zit), zit ook deep packet inspection, antivirus, DDOS protectie, IPS (intrusion protection, waarbij er 0 days exploits worden uitgefilterd), realtime lijksten van botnet's die je kan blokkeren, BGP beheren, ....

Lang geleden deed ik ook mijn firewalling op Linux, maar de flexibiliteit en kracht van de Fortigate producten overstijgt wel gewoon iptables en openvpn of wireguard. Goed, je kan ook snort beginnen inbouwen en pfsense gebruiken, en proberen gebruik te maken van publieke barracuda ip lijsten voor dns blocking etc ... maar bij Fortinet gaat het toch wel allemaal iets verder.

[johnkeates]

Dat zegt elke vendor, daar is Fortinet niet anders bij. Echt meespelen met de grote jongens is er ook niet bij, je kan ze moeilijk afzetten tegen een F5, PaloAlto, Juniper, Cisco enz. Aan het eind van de rit doen ze allemaal wel technisch hetzelfde en zal je nog steeds kennis nodig hebben om het te onderhouden. Doe je dat niet (bijv. door naar een MSP te gaan en dan te zeggen dat je monitoring en configuration management te duur vind en hopen dat het set & forget werkt), dan krijg je dit soort nieuws.

note: fortinet gebruikt zelf gewoon linux en standaard GNU software, ze hebben een custom traffic module en integratie toolkits met security feeds en WebUI enz, maar technisch zijn ze niet anders. zelf iets random in elkaar draaien voor een bedrijf zou ik niet aanraden, maar puur op een vendor leunen is net zo af te raden

[Reactie gewijzigd door johnkeates op 22 juli 2024 23:11]

[Keypunchie]

Jammer dat de ontwikkeling van Wireguard zo langzaam lijken te gaan. Volgens mij is het echt tijd voor zo’n veel simpelere manier van VPN beveiliging.

[markjanssen]

Het mag dat nog niet een 'stable' release hebben, of in de kernel ingebouwd zitten, het is zeker wel al klaar voor productie-gebruik. Ook de windows-client is ondertussen op een bruikbaar niveau.

Ik heb 't hier nu al een flinke tijd in productie draaien met vele tientallen hosts connected.

[Keypunchie]

Voor privé-gebruik durf ik het zonder meer aan. Maar voor productie-gebruik loop je in mijn sector al snel tegen certificering-issues aan. Soms zit beveiligingsbeleid je in de weg...

[mrdemc]

Is het gebruik van de OpenVPN-NL geen optie dan?

[WhatsappHack]

Nouja, in de weg, in de weg... Als het nog niet klaar is voor productie en/of nog niet voldoende getest, dan doet het beleid z’n werk in principe toch? Zeker als de ontwikkelaars zelf dat vinden.

[Anoniem: 310408]

Ik heb 't hier nu al een flinke tijd in productie draaien met vele tientallen hosts connected.

Je weet dat wireguard dat zelf afraad (they may contain security quirks)? Beveiligingssoftware in beta in productie inzetten zou beteken dat de manager daar zeer goede redenen voor moet hebben. Daarnaast krijg je geen enkele certificatie, verzekering etc.

[Alfa1970]

Och gebruik een van de vele andere (Open)SSL "VPN" oplossingen. Wireguard is niks unieks, de oplossing die omschreven staat bestaat al tientallen jaren er zijn letterlijk honderden implementaties van te vinden die in meer of mindere mate exact zo werken.

En veel simpeler dan met deze SSL gebaseerde oplossingen gaat het niet.
Het werkt okay, maar is als beveiliging technologie verder niet echt om over naar huis te schrijven.

[markjanssen]

Toch triest dat al die bedrijven hun patch-management niet op orde hebben. Daar is genoeg software voor beschikbaar om dat te monitoren, en diverse partijen bieden commerciele diensten aan om dit in goed beheer te houden.

[kodak]

Wat is niet op orde hebben als er geen standaard voor is? Wat is niet op orde hebben als er procedures gevolgd zouden worden om een patch met zo min mogelijk risico uit te rollen?

[Wim-Bart]

Als het beleid risicomijdend is, dan had de patch met een spoed change uitgerold moeten worden. Want hackers weten ook wel hoe laat het is. Niet bijgewerkt + bedrijfsnaam = paradijs!

[kodak]

Het niet patchen en criminelen die daardoor hun gang kunnen gaan bestaat al vele jaren. Waar zijn de voorbeelden dat het voor een bedrijf dan echt een probleem is? We kunnen het wel een probleem noemen, maar als het weinig gevolgen heeft, moeten we dan vreemd opkijken dat bedrijven er de tijd voor nemen?

[FreshMaker]

Het niet patchen en criminelen die daardoor hun gang kunnen gaan bestaat al vele jaren. Waar zijn de voorbeelden dat het voor een bedrijf dan echt een probleem is? We kunnen het wel een probleem noemen, maar als het weinig gevolgen heeft, moeten we dan vreemd opkijken dat bedrijven er de tijd voor nemen?

Je moet weten dat er een patch beschikbaar is.
Niet elke leverancier zet dat door naar zijn klanten ( want inkomsten om uurtjes te factureren )
Niet elke wijziging in je softwareomgeving kan zomaar gemaakt worden, risico dat je je bedrijf lam legt is aanwezig.
Noodzaak tegen gevaar afzetten, op welke schaal kan het kwaad als het niet vandaag maar morgen gebeurt.

Vanuit de burostoel is het makkelijk praten, als ik mijn DNSserver in de router aanpas, en dat gaat verkeerd, hebben er 20 apparaten last van
Doe ik dat in de routers op de werkvloer, praten we over 1500 medewerkers, 10K machines of meer, en misschien ook nog externe firma's.
Dat moet je plannen, testen, nog eens nalopen, iets grotere testgroep en dan implementeren ( daar kan zomaar 4 weken in zitten )

[johnkeates]

Zal wel een gevalletje 'kwartaalcijfers opleuken' zijn geweest. Bespaar je misschien 50k maar ben je wel het haasje zodra dit soort vulnerabilities naar buiten komen, en dat gebeurt gewoon altijd.

[SkiFan]

Ach onzin. Bedrijven hebben dit soort hardware altijd in een cluster hangen. Ik heb deze een paar maanden terug al remote in het weekend geïnstalleerd, en je downtime bedraagt echt niet meer dan enkele minuten.

Als je het een beetje slim aanpakt (en groot genoeg bent), heb je meerdere gateways hangen. Gewoon even DNS aanpassen en je kunt met 0 downtime de boel patchen.

[markjanssen]

Dat... en daarnaast kan je ook gewoon onderhouds-windows inplannen... bij voorkeur iedere maand of iedere 2 weken... Dan heb je geen excuus om niet na max 2-3 werken je patches geinstalleerd te hebben.
Als iets mission-critical is, dan moet 't ook gewoon redundant zijn, en moet er dus gewoon een instance in onderhoud kunnen zijn.

[SkiFan]

Vervelende bij Firewalls is dat de functionaliteit nogal uitgebreid is. Je merkt daarom niet altijd meteen of er toch niet kleine dingetjes zijn die ondanks het testen toch niet lopen.

[slelieveld]

En eventuele S2S VPNs? Die vang je niet af met DNS, dan moet je toch "echt" clusteren. Kleine extra stap in "makkelijk" patchen... afhankelijk van je cluster tech (vrrp, fgcp, etc.)

[SkiFan]

Daar heb je routing protocollen (bv RIP, OSPF) voor, zodat bij downtime je verkeer over een andere route gaat. Ook dat hoeft slechts enkele secondes tot max 30 secondes downtime op te leveren. Over je stelt je route vooraf al anders in.

[blinchik]

Vaak is het ook niet zo simpel. Je hebt misschien Fortinet ap's van klanten aan je toestel hangen (wij hebben bv. subbedrijven met hun eigen hardware) en die zijn niet meer compatibel met een nieuwere major firmware zoals 5.6.

Of je hebt dingen overgeerfd en hebt geen beschikking meer tot alle IPSEC passphrases, die je bij een migratie opnieuw moet invoeren (zie release notes fg upgrade), waarbij je nieuwe afspraken moet maken met andere IT-partners.

Daarbij ben ik (alhoewel ik zeer tevreden ben van Fortinet) toch wel vaak bij upgrades enkele rare dingen tegengekomen (thuis zit ik op bleeding edge 6.2 en daar heb ik al 4 issues gemeld, waarvan 1 echt critical wat tot downtime leidde). Dat wil je dus in het bedrijfsleven zeker niet.

Akkoord, alles moet gepatched worden, maar in een uitgebreide professionele context is het vaak niet zo maar even op de upgrade knop drukken.

[SCS2]

Voor mij als leek, tussen jullie ICT-ers:
Mijn VPN draait bij een VPN aanbieder.
Gaat het hierboven over VPN-software die een bedrijf koopt en op hun eigen servers installeert ?
Bijv. om hun mensen buiten het bedrijf toegang tot het interne netwerk te geven?

[mjansen2016]

In dit geval VPN software maar ook hardware appliances, voor externe toegang, maar ook om co-locaties hun infrastructuur aan elkaar te koppelen. In feite waar een VPN altijd voor bedoeld is geweest.

Dat het nou in de volksmond bedoeld is om "anoniem te internetten en films te downloaden" zorgt al voor verwarring genoeg bij de technisch minder onderlegden en je moet het nu de IT stagaires ook al uitleggen.

[OxWax]

https://www.fortinet.com/products/vpn.html#models-specs

[zjeeraar84]

Even voor de zekerheid: het restricten van SSLVPN voor specifieke IP-adressen is in dit geval voor de korte termijn genoeg? De vulnerability is dan alleen maar actief voor de gewhiteliste hosts? Kan iemand dit bevestigen?

[reconf]

Voor zover ik begrijp kan de kwetsbaarheid alleen misbruikt worden als de SSL VPN publiekelijk beschikbaar is gemaakt om bijvoorbeeld toegang tot het bedrijfsnetwerk vanuit huis mogelijk te maken voor clients (thuiswerken). Heb je de SSL VPN gerestrict met enkele trusted IP-adressen dan zit je safe.

[kr4t0s]

Palo Alto Networks VPN (Global Protect) was ook kwetsbaar 9.0.3 is met hotfix versies gefixt tot 9.0.3-h3 en vanaf 9.0.4 in reguliere versie. En alle andere software versies die in support zijn ook 8.x en 7.1.

[e.dewaal]

Grappig hè, dat de concurrent er mee in het nieuws komt en dat je over de Palo Alto niets hoort... (in mijn mening ook een betere managementinterface )

[Drardollan]

Dat is even schrikken, maar gelukkig zowel een veilige firmware als niet gebruikte SSL-VPN hier.

Wel bijzonder dat er ineens zoveel aan het licht komt, je mag toch verwachten dat bedrijven als Fortinet de security hoog in het vaandel hebben.

[Vedette.]

Specifiek gaat het om de kwetsbaarheden CVE-2018-13379, CVE-2018-13381 en CVE-2018-13384, die aanvallen beschrijven met kwaadaardige http-verzoeken en een buffer overflow via een ddos, waardoor een aanvaller ongeautoriseerde toegang tot het interne netwerk zou kunnen krijgen.

In deze zin gaat even een hoop mis:

• CVE-2018-13381 beschrijft een buffer overflow kwetsbaarheid, welke gebruikt kan worden om een Denial-of-Service (DoS) aanval uit te voeren. Het is dus DoS via een buffer overflow en niet andersom.
• Deze DoS aanval kan worden uitgevoerd vanaf een enkele machine. Het betreft dus geen Distributed Denial-of-Service (DDoS) aanval.
• Deze buffer overflow kan voor zover bekend enkel gebruikt worden voor een DoS aanval, en dus niet om ongeautoriseerde toegang tot het interne netwerk te krijgen. De twee andere CVE's zouden hier wel voor gebruikt kunnen worden.

[Aapmansz]

Dit is al een tijdje bekend en een aantal weken geleden ook al onder de aandacht gebracht door BNR:
https://www.bnr.nl/nieuws...ties-staat-wagenwijd-open

Hoorde het op de radio en ben actie gaan ondernemen richting de externe partij die onze firewalls beheerd.
En jawel, ook niet gepatched. Na patchen was er wel wat gedoe met toegang voor medewerkers, was redelijk snel opgelost.