Dat was ik :-)

Om te beginnen zitten er wat tegenstrijdigheden in het artikel van SecuringSam (https://securingsam.com/breaching-the-fort/), daarin staat:
In het plaatje onder "Fortigate Example Certificate" zijn verschillen te zien tussen de velden onder "Subject Name" en "Issuer Name" die erop zouden kunnen duiden dat het niet om een self-signed certificaat gaat. Als Fortinet zelf CA speelt en hun root-certificaat (of -certificaten) meegeeft met de VPN-client-software, zou er sprake kunnen zijn van een solide basis.

Echter:
Met "Server Name" wordt hier, neem ik aan, het serienummer bedoeld (waarvan je mag hopen dat het wereldwijd uniek is).

Interessant is dat in het plaatje onder "Fortinet’s vague warning" het volgende staat:
Het filmpje vind ik te vaag om eruit op te maken dat gebruikers daadwerkelijk een waarschuwing te zien krijgen bij een Fortinet certificaat (al dan niet self-signed). Ook weet ik niet of gebruikers (van de VPN-client), indien gebruik gemaakt wordt van een publiek uitgegeven certificaat (met CN = domeinnaam) te zien krijgen met welke domeinnaam er verbinding wordt gemaakt.

Denkbaar is wel dat de VPN-client-software de domainnaam in een publiek uitgegeven certificaat, zoals het hoort, vergelijkt met de domeinnaam waar verbinding mee wordt gemaakt (dit vereist dat in de VPN-client geen IP-adres maar een domeinnaam is geconfigureerd, zoals vpn.example.com). Echter volgens SecuringSam:
Als de VPN-client niet checkt of de domeinnaam in het publieke certificaat overeenkomt met de domainnaam waar de verbinding mee gemaakt is (en SecuringSam geen instelling over het hoofd heeft gezien), heeft het geen zin om het Fortinet certificaat door een publiek certificaat te vervangen.

Er is echter helemaal niks mis met een self-signed server-certificaat als je precies weet wie de legitieme clients zijn die deze server bezoeken. Gebruikelijk is om dan van certificate-pinning of public-key-pinning gebruik te maken (een lange levensduur van het certificaat is, bij certificate-pinning, dan wel zo handig). Dit onder de voorwaarde dat de client niet, als alternatief, ook elk willekeurig publiek certificaat accepteert.

Conclusie: ik zou eerst onderzoeken of de client zó geconfigureerd kan worden dat pinning wordt gebruikt en alternatieve publieke certificaten (en natuurlijk certificaten van andere FortiGates) worden geweigerd. Als dat niet volledig wordt ondersteund, zou ik een publiek certificaat installeren en verifiëren dat de client de verbinding weigert als de domeinnaam waarmee verbinding wordt gemaakt niet overeenkomt met de domeinnaam in het certificaat. Als ook dat fout gaat zou ik mijn geld terugvragen.

Om dat laatste te testen zou je (mits de VPN-client de hosts file raadpleegt) het volgende kunnen doen als vpn.example.com de correcte domeinnaam is en 10.1.2.3 het echte IP-adres is:
1) Configureer de VPN-client om verbinding te maken met flauwe.kul.example.com (i.p.v. vpn.example.com)
2) Neem op in hosts file: 10.1.2.3 flauwe.kul.example.com
Het opzetten van een VPN-verbinding zou dan een foutmelding moeten opleveren.

Hi Erik,

Even aan het testen geweest.

- Een "echt" betaald SSL cert op de Forti gezet.
- SSL VPN client test:
- Naar de juiste DNS naam: Kan verbinden, geen warnings.
- Naar het publieke IP adres: Kan verbinden, WEL een certificate warning.
- Hostfile ingesteld dat test.website.nl naar het public IP wijst: Kan verbinden, WEL een certificate warning.

Kortom: De client waarschuwt je alleen of een server name mismatch, maar weigert niets.
Maar goed, als ik als gebruiker naar een website ga met een malafide certificaat, krijg ik ook alleen een warning en wel een keuze om door te gaan.

Een waarschuwing is in elk geval iets (overigens kun je, als je met een browser recentelijk een https site met HSTS hebt bezocht en nu op die site een certificaatfoutmelding krijgt, niet doorgaan).

Punt van zorg (dat ik in mijn bijdrage hierboven wellicht onvoldoende duidelijk heb gemaakt) blijft dat een MitM, die de client een willekeurig Fortinet certificaat voorschotelt, wellicht niet door de client wordt geblokkeerd en de gebruiker zelfs geen waarschuwing te zien krijgt.

Kregen jouw gebruikers een waarschuwing te zien toen het default Fortinet certificaat werd gebruikt?

Zojuist even gekeken op een andere Forti.
Als ik verbind met de SSL VPN client naar deze Forti die het standaard cert heeft, dan krijg ik ook diezelfde warning.

Overigens is dat certificaat niet helemaal "self-signed", maar uitgegeven door "Support" CA van Fortinet zelf. Die dus niet trusted is.

De installatie van het certificaat heeft er dus alleen voor gezorgd dat de warning weg is, omdat alles klopt. De client "blokkeert" echter nooit iets lijkt het, ongeacht het gebruikte certificaat.

De SSL VPN client heeft zelfs een vinkje "Do not warn invalid server certificate", wat het dan helemaal gevaarlijk maakt.

Dank voor jouw antwoord! Bizar dat je certificaatwaarschuwingen kunt uitzetten. Dit bevestigt dat Fortinet het risico op MitM aanvallen volledig negeert.

Ik hoop dat het mogelijk is voor jou om op afstand eventueel gezette vinkjes weg te halen. Daarna zul je jouw gebruikers op het hart moeten drukken om voortaan certificaatwaarschuwingen niet te negeren, geen vinkje te zetten en dan onmiddelijk contact met jou op te nemen. De vraag is hoeveel gebruikers daar gevolg aan zullen geven - ook na een mailtje dat door jou verzonden lijkt waarin staat dat zij, t.g.v. een update of andere smoes, tijdelijk certificaatwaarschuwingen moeten negeren.

Fortinet heeft kennelijk nog niets geleerd van haar vele securityblunders. Mijn advies: verspil geen geld aan hun halfbakken meuk.

Het probleem huist hierin dat het Fortinet certificaat door iedere eigenaar van een Fortigate FW te verkrijgen en dus te extraheren is en zo op het internet terecht kan komen. Iedere #@cker kan deze dan gebruiken voor de MITMa.

De aanvaller zal linksom of rechtsom over een server moeten beschikken (vaak zal dit een gehackte server van een onwetende derde zijn). Dan is het in de meeste gevallen waarschijnlijk eenvoudiger om daar een Let's Encrypt certificaat voor aan te vragen dan op zoek te gaan naar zo'n Fortinet certificaat inclusief bijbehorende private key. Als het de aanvaller vervolgens lukt (bijv. via manipulatie van DNS-replies via een gehackte thuisrouter) om de VPN-client naar die gehackte server om te leiden, maakt het niet uit welk certificaat (Fortinet of uitgegeven door een trusted CA) daarop staat; in beide gevallen krijgt de gebruiker van de VPN-client een certificaatwaarschuwing.

Natuurlijk onder voorbehoud dat die gebruiker het vakje "zeur niet over certificaten" eerder niet heeft aangevinkt. Wat voor de hand ligt als die certificaatwaarschuwing elke keer verscheen bij het opzetten van de VPN-verbinding, nl. als de FortiGate van het default certificaat gebruikmaakte. Mocht dat vinkje niet zijn gezet, dan valt de certificaatwaarschuwing in die situatie waarschijnlijk ook niet op, want die was er altijd al.

Ik begrijp niet dat beheerders meer dan 200.000 FortiGates aan internet hangen en daarbij certificaatmeldingen van clients negeren. Maar nog minder snap ik waarom Fortinet hen daartoe de gelegenheid geeft en daarmee, plus zo'n vinkje, stimuleert dat beheerders en gebruikers certificaatwaarschuwingen in de wind slaan.

Hebben zelf voor alle Fortinet VPN users 2FA geactiveerd, toch weer een extra barrière om daadwerkelijk toegang te verkrijgen

Ik verwacht niet dat 2FA een extra barrière oplevert voor MitM-aanvallers. Als de gebruiker bijv. een code in een SMSje ontvangt (of een TOTP code bijv. uit Authy of dedicated Fortinet app afleest) en deze invoert in de GUI van de VPN-client, dan hoeft de MitM-aanvaller die code alleen maar door te sturen naar de echte FortiGate waarna die aanvaller via de daarna gerealiseerde VPN-verbinding zijn/haar gang kan gaan.

In theorie zou de FortiGate de MitM op dat moment kunnen detecteren, bijvoorbeeld als de VPN-client, i.p.v. gewoon de 2FA code, een HMAC (een soort hash) zou sturen met als inputs de public key van het ontvangen servercertificaat en (als secret) de 2FA code (als het servercertificaat van de MitM afkomt, zal daar een andere public key inzitten en zal dezelfde HMAC-berekening op de FortiGate een ander resultaat opleveren; ook kan de MitM op deze manier niet de echte 2FA code achterhalen en zich voordoen als client).

Dat scenario ligt echter niet voor de hand. Een MitM hoor je bij het opzetten van een geauthenticeerde en versleutelde verbinding te detecteren en niet pas op het moment dat een (optioneel te configureren) 2FA code wordt verzonden. 2FA codes zijn meestal bedoeld om zwakke gebruikerwachtwoorden minder erg te maken, niet om MitM aanvallen te voorkomen.

En als je gebruik maakt van een 2FA oplossing zoals van DUO, wordt de 2FA code via een geheel ander kanaal verzonden en heeft dus geen invloed op een MitM in verbinding 1 linksboven in https://duo.com/assets/img/documentation/fortinet/fortinet_network_diagram.png (dat netwerkdiagram is afkomstig uit https://duo.com/docs/fortinet).

Kortom, ik verwacht niet dat 2FA codes je beschermen tegen MitM aanvallen.