FortiBleed: wachtwoorden van 75.000 Fortinet-firewalls liggen op straat, roteer nu

Heb je in je netwerk een Fortinet FortiGate-firewall of een SSL VPN-gateway hangen, dan is dit het bericht waarop je deze week moet handelen. Onderzoekers brachten een dataset naar buiten met inlog- en VPN-gegevens van tienduizenden FortiGate-apparaten wereldwijd. De vondst kreeg de naam FortiBleed en raakt organisaties van het kleinste MKB tot grote multinationals. De kern is simpel: ga ervan uit dat de wachtwoorden van je firewall bekend zijn bij aanvallers, en roteer ze vandaag nog.

Wat is er precies gevonden

Beveiligingsonderzoeker Bob Diachenko stuitte op een blootgestelde server met de gegevens; het Israëlische dreigingsbedrijf Hudson Rock analyseerde de dataset en publiceerde de bevindingen, inclusief een gratis opzoektool waarmee je kunt checken of jouw domein erin staat. Onderzoeker Kevin Beaumont verifieerde dat de inloggegevens echt zijn. Het gaat volgens BleepingComputer om credentials van 73.932 unieke firewall-URL's, met gebruikersnamen, e-mailadressen en wachtwoorden in platte tekst. De getroffen apparaten staan verspreid over 21.632 domeinen in 194 landen. Dat is volgens de onderzoekers ongeveer de helft van alle aan het internet hangende Fortinet-firewalls, gemeten via Shodan.

De meeste van die apparaten staan nog gewoon online en draaien recente FortiOS-versies. Het is dus niet zo dat dit alleen verouderde, vergeten kastjes betreft. Onder de getroffen organisaties zaten volgens de berichtgeving namen als Foxconn, Samsung, Comcast, Siemens en FedEx, een teken dat de gevolgen niet stoppen bij kleine spelers.

Hoe de wachtwoorden gekraakt zijn

Dit is geen klassieke 'nieuwe kwetsbaarheid met een patch'. De gegevens lijken te zijn geoogst uit de configuratiebestanden van FortiGate-apparaten, waarna de opgeslagen wachtwoord-hashes zijn gekraakt. De zwakke plek zit in hoe die hashes historisch werden bewaard. Fortinet stapte over op het sterkere PBKDF2 in FortiOS 7.2.11, 7.4.8 en 7.6.1, maar bij een upgrade vanaf een oudere versie blijft het oude SHA-256-hash staan totdat de betreffende beheerder na de upgrade voor het eerst inlogt. Precies dat legacy-hash maakte massaal kraken haalbaar.

Fortinet zelf nuanceert de zaak. Tegenover The Register stelde het bedrijf dat de data een hergebruik is van eerdere incidenten en van bruteforce-pogingen, en niet samenhangt met een recent incident of advisory. Dat is een belangrijk onderscheid voor de schuldvraag, maar het verandert weinig aan je risico: als je beheerderswachtwoord in deze verzameling staat en je hebt het nooit geroteerd, dan is het bruikbaar voor wie binnen wil komen.

Wat dit voor jou betekent

Een firewall of VPN-gateway is de voordeur van je netwerk. Een geldig beheerders- of VPN-wachtwoord daarop is voor een aanvaller goud: het geeft toegang zonder dat er een exploit aan te pas komt, en zulke toegang wordt vaak doorverkocht aan groepen die ransomware uitrollen. Het feit dat de helft van de wereldwijde Fortinet-vloot in deze lijst opduikt, betekent dat de kans reëel is dat ook jouw apparaat of dat van een leverancier erin zit.

De stappen zijn nuchter en concreet:

• Roteer nu alle wachtwoorden van zowel de beheerdersinterface als de VPN-accounts op je FortiGate, te beginnen met apparaten die aan het internet hangen.
• Zet multifactor-authenticatie aan op alle beheer- en remote-toegang. Een gestolen wachtwoord alleen is dan niet langer genoeg.
• Scherm de beheerinterface af zodat die alleen vanaf vertrouwde interne netwerken bereikbaar is, niet vanaf het hele internet.
• Forceer het sterkere hash-formaat door elke beheerder na de upgrade opnieuw te laten inloggen, en zet waar mogelijk de optie aan die zwakkere versleuteling uit back-upbestanden weert.
• Controleer je logs op verdachte aanmeldingen vanaf onbekende locaties.

Dit incident past in een patroon dat ik de afgelopen weken vaker zag terugkomen: aanvallers richten zich op de gereedschappen en infrastructuur die je vertrouwt. Diezelfde dynamiek zat achter de vijftien valse JetBrains-plugins die AI-API-sleutels stalen van bijna 70.000 ontwikkelaars en achter de actief misbruikte Langflow-kwetsbaarheid die je direct moet patchen. De les is steeds dezelfde: wie zijn randapparatuur en zijn zelfgehoste diensten goed wil beschermen, hardent zijn infrastructuur van standaardinstellingen naar productie-veilig in plaats van te vertrouwen op de fabrieksconfiguratie.

De harde waarheid: of dit nu 'verse' diefstal is of hergebruikte data, doet er voor jouw verdediging niet toe. Een wachtwoord dat ooit lekte en nooit is veranderd, is vandaag nog steeds een sleutel die past. Behandel elk credential op je perimeter als mogelijk gecompromitteerd, en maak roteren plus MFA tot routine in plaats van een eenmalige brandblusactie.