How Nice!

Als er meer dan 1 apparaat bestaat met dezelfde private key, is de vraag niet of kwaadwillenden die gedeelde private key in handen kunnen krijgen, maar wanneer.

Dit is vergelijkbaar met een shared password dat je middels obfuscation geheim denkt te kunnen houden. Design error dus.

Zie ook https://secure.security.nl/artikel/42224/1/Fortinet_SSL_DPI_ook_lek_%28net_als_Cyberoam%29%3F.html.

Mensen snappen de principes niet achter public/private key versleuteling.

Epic fail

@Bitwiper:

Het is waar dat in de Fortinet Firewalls allemaal dezelfde STANDAARD certificaten zitten. Echter zoals het woord standaard al zegt dienen deze uiteraard vervangen te worden door een certificaat dat ondertekend is door een door jou eigen vertrouwde CA.

Het is vaak makkelijker om een product de schuld te geven als je niet weet hoe het in te stellen, dan om je erin te verdiepen.

Voorbeeld:
Als ik mijn Firewall op Pass All zet, wiens schuld is het dan dat het mij niet beveiligd. Dat van het product? Of is hij gewoon verkeerd geconfigureerd?

Ook zit er een optie in de Fortinet Firewall "Allow invalid SSL certificates" deze staat, zoals het hoort, standaard uit. Met deze optie kun je kiezen of je wilt dat de firewall de verbinding naar een website met een ongeldig certificaat of al meteen afkapt of doorlaat.

Dus het is geen design fout door Fortinet. Als er misbruik gemaakt wordt van deze functionaliteit betekent het dat je hem verkeerd hebt ingesteld. En je niet hebt gehouden aan de White Papers en Guides die beschikbaar gemaakt zijn.

Docs: http://docs.fortinet.com/fgt.html
White Papers: http://www.fortinet.com/resource_center/whitepapers.html

Ik zie dat er weer gelinkt word naar de "design error" van Fortinet.

Je vergeet dat de DPI in die apparaten niet lek is.
Als je een Fortinet Firewall in gebruik neemt, neem ik al aan dat je verstand van zaken hebt.

De Fortigate gaat als proxy dienen en ontsleutelt het verkeer zodat hij het kan inspecteren. Als je dit insteld met het standaard certtificaat dat in de Firewall ingebakken zit, zul je een certificaat melding krijgen (not trusted).

Dit betekent dus dat als je DPI wilt inzetten je een certificaat laat generen bij een vertrouwde CA.
DPI bij Fortinet is dus niet lek, je moet de tijd nemen om dit goed te configureren.

Ah, kenneklijk heb ik op de tenen van een wederverkoper van deze junk getrapt of zo. Okay, ik laat me trollen.

In zo'n Fortinet zit standaard een besturingssysteem, een CPU en er wordt een standaard netsnoer bijgeleverd. Moet ik die soms ook allemaal vervangen omdat ze "standaard" zijn?

De praktijk is dat mensen (en zeker admins) geen manuals lezen. Waarom werk je ze tegen als leverancier? Gebruikers mogen bij een security device verwachten dat "standaard" betekent dat zaken DICHT staan totdat zij ze zelf open zetten!

Of heeft die Fortinet crap toevallig ook by default ook een account "root" met password "root" toegankelijk vanaf de WAN poort? En "is dat logisch" omdat ergens op Internet, als je goed zoekt, en WEET dat je moet zoeken, een WhitePaper of FAQ te vinden is met een aanwijzing dat je dat natuurlijk meteen moet wijzigen?

Los daarvan is het wel degelijk een design error, want andere UTM fabrikanten genereren gewoon, zoals het hoort, een uniek keypair en maken daarmee een uniek certificaat; er is namelijk geen enkele reden (bekalve laksheid van de programmeurs) om dat NIET te doen - en, zoals duidelijk moge zijn, is er een heel goede reden om dit WEL te doen.

En kennelijk heb jij je er zelf niet in verdiept, want je kunt het voor SSL/TLS DPI benodigde certificaat helemaal niet bij een "door jou eigen vertrouwde CA" kopen (dat doen ze niet want dan verkopen ze daarna niks meer, en als ze dat zouden doen kan de publieke PKI meteen de prullenbak in). Zo'n self signed CA certificaat (of dochtercertificaat met een self signed root) zul je toch echt zelf moeten genereren en in de betreffende webbrowsers van je clients stoppen om certificate errors te voorkomen.

Tenzij je van alle kopers van zo'n UTM verwacht dat ze een eigen CA opzetten of met (voor de meesten mensen) onnavolgbare openssl commandline instructies aan de gang gaan (wat onveilig is want mensen snappen niet wat een private key is en hoe je daarmee om moet gaan), hoort die spulleboel gewoon aan boord van die Fortinet gegenereerd te worden! En als die dat kan, waarom zou Fortinet daar dan mee mee wachten todat de beheerder op een knop drukt i.p.v. dat dit bij de eerste keer booten automatisch gebeurt?!

Om bovenstaande redenen is het een BLUNDER als een UTM fabrikant een standaard CA cert + private key in al z'n appliances levert.

En dit is nog stommer dan KPN die in elke door haar geleverde Experiabox (van een bepaalde serie) een te raden Wifi wachtwoord genereert. Daar heb je A) nog een app voor nodig en B) die zul je per modem moeten draaien en C) we hebben het hier over een thuisdingetje en niet over een UTM die wordt aangeprezen als een beveiligingsdevice voor professionele organisaties.

In het artikel staat dat het om een "onveranderlijke RSA privésleutel in de firmware" gaat. Als ik dat letterlijk neem, is dit dus een heel ander geval dan bij Fortinet.
En als hij echt "onveranderlijk" is, en ook nog hetzelfde in alle installaties van de software, dan is het wel een probleem van de leverancier, vind ik.
Ten eerste wil je een sleutel (en daarmee het certificaat) kunnen wijzigen, om de zoveel jaar, of in ieder geval als je vermoedt dat de sleutel gecompromitteerd is. Maar ten tweede moet de sleutel natuurlijk anders zijn bij elke instantie van de software.

Ik ben het sowieso eens met het feit dat admins geen manuals lezen. Dit snap ik aangezien die uiteraard gewoon een miljoen en 1 dingen te doen hebben. Daarom zouden admins zich ook niet teveel zorgen moeten maken over de security aan zich en is het beter om hier specialisten voor te hebben. Op deze manier kan de admin zich beter bezig houden met de functionaliteit van het netwerk.

Bij een fortinet staat op de wan kant alles standaard dicht, je kunt ze alleen pingen en daar houd het op. Hij is standaard ook alleen van de interne kant te benaderen.

In de praktijk is het vaak beter als specialisten apparaten zoals die van Fortinet instellen, dan kunnen deze apparaten namelijk op de juiste manier geconfigureerd worden en dan zijn ze wel veilig. Dit is een betere oplossing dan gewoon een self-signed certificate te genereren.

Ik kwam misschien wel wat fel over in mijn reactie, het was niet de bedoeling om dit over te laten komen als een persoonlijke aanval. Het gaat mij erom dat je ten alle tijden je eigen CA dient te gebruiken omdat je dan zelf de controle hebt over welke certificaten geldig zijn en welke revoked zijn.

Het probleem is dat alles wat je aanlevert in principe compromised kan en zeker zal raken. Echter wordt dit certificaat niet gebruikt voor access naar je netwerk en standaard ook niet vanaf. Het is een feature die je aan moet zetten. Dus standaard zou deze hoe dan ook geen gevaar opleveren.

Desondanks dit alles zie ik wel het punt wat je probeert te maken. En snap ik je zorgen.

Ik hoop dat we het er in ieder geval over eens zijn dat mits alles goed geconfigureerd wordt door specialisten het allemaal een stuk beter zou zijn, ongeacht de fabrikant.

Ik ben het met je eens dat dit soort apparaten het beste door specialisten kunnen worden geconfigureerd.

Maar die zijn zelden in dienst bij een organisatie die zo'n UTM inzet. Inhuur (voor elke wijziging!) is duur. De praktijk is dat iemand dit "erbij" gaat doen. En zo heel vaak zit je ook niet aan een productie device te tweaken, waardoor de kennis snel weer verdampt (en/of op vakantie gaat). En je zal zien dat er dan een baas is, of een hands-off security officer, die vindt dat net op dat moment SSL/TLS DPI aangezet moet worden.

Als ik in http://kb.fortinet.com/kb/viewContent.do?externalId=FD32404 kijk, dan zie ik nergens staan dat je het meegeleverde certificaat nooit voor productiedoeleinden moet inzetten. Er wordt niet op de risico's van het importeren van root certificaten in webbrowsers gewezen (d.w.z. transport van self-signed certs moet veilig gebeuren, niet via http vanaf een webserver kunnen downloaden; zo'n self-signed cert is eenvoudig te spoofen).

In het tweede plaatje staat:Er staat geen waarschuwing bij dat dit certificaat als gecompromitteerd moet worden beschouwd. Net zoals bij Cyberoam zal Fortinet wel in de veronderstelling zijn dat de private key (in de firmware) zodanig obfuscated is dat niemand deze kan achterhalen. Een kansloze aanname.

In de laatste handleiding, "FortiOS Handbook, FortiOS 4.0 MR3" (online onder http://docs.fortinet.com/fos40hlp/43/wwhelp/wwhimpl/js/html/wwhelp.htm), zie ik ook nergens een waarschuwing dat je het meegeleverde certificaat niet moet gebruiken voor productie. In tegenstelling tot de kleine lettertjes in eerdergenoemd plaatje, zie ik hier nergens een waarschuwing dat dit certificaat en private key in alle units hetzelfde zijn.

In die online manual, in "Chapter 6 UTM Guide" -> "Other UTM considerations" -> "SSL content scanning and inspection" zie ik o.a.: M.a.w. de auteur zegt dat gebruikers certificaatfoutmeldingen gerust kunnen negeren. Dat biedt geen vertrouwen in de rest van de tekst.

Verderop volgt:Er staat niet you must; m.a.w. het is vrijblijvend.

Hoewel er in het tweede plaatje in http://kb.fortinet.com/kb/viewContent.do?externalId=FD32404 een "Generate" knop zichtbaar is, stelt http://kb.fortinet.com/kb/viewContent.do?externalId=FD30586 dat de Fortigate zelf geen (self-signed) CA-cert kan genereren. Hoe dat moet legt Fortinet niet zelf uit, daarvoor verwijzen ze je naar third party sites!?

Als Fortigate UTM's niet in staat zijn om hun eigen CA cert te genereren (terwijl het voor SSL/TLS inspectie noodzakelijk is om on-the-fly gespoofde server certficaten te genereren, en de bulk van de technologie dus aan boord moet zijn), dan is dit product incompleet. Het verwijzen naar third party sites voor howto's bevestigt dit beeld. Amateuristisch, niet doordacht en niet af. Risico voor de klant, succes ermee.

Onzin. Het probleem is dat elke Fortinet met hetzelfde SSL/TLS DPI certificaat en private key de deur uitgaat. Terwijl elke unit (volgens het 2e plaatje in http://kb.fortinet.com/kb/viewContent.do?externalId=FD32404) wel met twee unieke server certificaten de deur uit kan gaan.
ALS je het aanzet met het meegeleverde CA certificaat, zullen gebruikers dat ASAP in hun browser willen laden om de getoonde foutmeldingen te stoppen. Als je SSL/TLS DPI daarna weer uitzet, hebben die gebruikers nog steeds een (vermoedelijk) gecompromitteerd root certificaat in hun webbrowser.

Zo te zien (ook uit je vorige reactie, melding over STANDAARD) zijn we het erover eens dat het meegeleverde certificaat + private key ongeschikt is voor productiedoeleinden, en het certificaat nooit in webbrowsers van gebruikers gekopieerd mag worden (immers het moet als gecompromitteerd worden beschouwd).

Daarom vind ik dat Fortinet helemaal geen niet-uniek certificaat en private key had mogen voor-installeren. Het is zinloos en risicovol. Op het moment dat de beheerder de SSL/TPS DPI wil inzetten, kan de Fortinet melden dat er nog geen root certificaat plus private key aanwezig zijn, en aangeven dat deze ofwel geüpload, ofwel (door een druk op een knop) gegenereerd kunnen worden.

Ik ben het met je eens dat de aanpak anders voor het aanleveren van de certificaten anders had gekund. Het voordeel is wel dat hij ondersteuning heeft voor SCEP voor certificaten en dit werkt dus ook samen met een Microsoft Enterprise CA server, zonder SCEP kun je ook met MS CA server werken alleen kost het renewen van je Certificaat dan gewoon meer werk. En aangezien veel bedrijven een Active Directory hebben kan dit het beheer vergemakkelijken.

Het klopt dat per change een bedrijf inhuren duur is. Wij zelf worden ingehuurd door bedrijven om de firewall te managen en hebben verscheidenen apparaten onder ons beheer. Waaronder zo'n 200 Fortinet Fortigates, deze varieren van de kleine modellen tot en met de Enterprise modellen. En juist omdat changes normaal duur zijn, betalen ze bij ons niet per change, maar gewoon een vast bedrag per maand. Onafhankelijk van de hoeveelheid changes.

Wij bieden dit altijd aan bij elke firewall die via ons verkocht wordt juist omdat de systeembeheerders wel wat anders te doen hebben. Indien ze het toch zelf willen doen bieden wij ze een training aan zodat ze er minder tijd aan kwijt zijn om hem te managen en weten waar alles zit.

Wat betreft het certificaat was de beste methode die ze hadden kunnen doen gewoon een Key laten genereren en op basis van die nieuwe key een CSR genereren. En dan aan de admin de keuze aanbieden wil je hem Self-Signed of wil je de CSR naar een CA opsturen om te signen (denk aan GeoTrust, VeriSign, etc).

Ik ga hier bij de eerst volgende keer bij Fortinet over informeren waarom dit zo is, en of dit anders kan.

Je begrijpt SSL/TLS DPI niet.
We hebben het hier over een "legitieme" Man-In-The-Middle attack. Als een gebruiker https://mijn.ing.nl/ opent
zal de Fortigate een gespoofed certificaat van mijn.ing.nl genereren en dat naar de webbrowser sturen. Om dat te kunnen doen heeft de Fortigate een CA-certificaat nodig.

Die kun je echter niet zomaar kopen. Als GeoTrust, Verisign etc. een door jou ingediende CSR voor een CA-certificaat zouden accepteren, snijden ze zichzelf driedubbel in de vingers: 1) jij kunt zelf CA gaan spelen (dat kost hen inkomsten), 2) als zij dit soorts certs zouden uitgeven wordt het complete publieke PKI model ondermijnd en 3) als Microsoft, Mozilla, Opera etc. (en gebruikers!) hier achter komen, zal het gebruikte root certificaat van de CSP (GeoTrust, Verisign etc.) uit webbrowsers worden verwijderd (of dat dan echt zou gebeuren weet ik niet, maar volgens de richtlijnen van webbrowser fabrikanten zou dat wel moeten). GeoTrust en Verisign zouden net zo goed de Comodo/Diginotar hacker een RDP accountje kunnen geven...

Kortom, om SSL/TLS DPI te kunnen doen heb je een CA-certificaat nodig, en, omdat je er MITM (spoofing) aanvallen mee gaat uitvoeren, zal dit certificaat by default (en terecht) niet door webbrowsers worden vertrouwd.

Fortigate
In de FortiGate zit zo'n self-signed CA certificaat. Zelf zien? Open http://www.fortigate.com/login, name: demo, password: fortigate, klik links op Certificates en dan op Local Certificates, dan staat ie bovenaan. Zet er een vinkje voor en download deze op je bureaublad. Open het bestand door dubbel-klikken en constateer dat het een, niet vertrouwd, CA certificaat is en dat deze geen revocation URL's bevat (geen CRL en OCSP servers). Logisch, want het enige van waarde in dit certificaat is de public key, een kwaadwillende kan deze probleemloos in een eigen self-signed certificaat opnemen zonder revocation URL's (het is een fundamental PKI flaw dat certificaten i.p.v. public keys worden gerevoked).

De "enige" fout die Fortinet hier maakt is dat ze elke Fortigate unit met hetzelfde certificaat (en bijbehorende public key uitleveren). Ik vermoed dat beide (cert + private key), net als bij RuggedCom, in de firmware zitten. Nb. dat vermoeden is de reden dat ik de vergelijking maak (mocht iemand dit nog niet snappen).

Voor wie het maar horen wil: het is FUNDAMENTEEL FOUT om private keys in firmware te stoppen, DON'T EVEN THINK ABOUT IT! Ook obfuscation helpt je niet; zodra de software de onversleutelde private key nodig heeft, zal deze (al is het maar héél even) in het geheugen te vinden en dus te extracten zijn. Een private key in firmware verstoppen is bijna hetzelfde als deze meteen op internet publiceren, zeker als firmware updates bij een (onder-) leverancier te downloaden zijn, of als een beheerder deze voor het gemak op z'n eigen website gezet heeft.

Zodra de private key op straat ligt (als dat al niet zo is) zijn alle Fortinet klanten pnwed! En dan bedoel ik vooral eindgebruikers (denk ook aan zakelijke laptops en BYOD), met name als zij door aanvallers, die weten dat hun bedrijf, organisatie of universiteit van een Fortigate met SSL/TLS DPI gebruik maakt, "te vinden" zijn.

Elke SSL/TLS sessie (o.a. voor internetbankieren) kan dan gespoofed zijn zonder dat de gebruikers het merken, en schijnbaar door bijv. Microsoft gesigneerde software (updates!) kan malware zijn etc. Om een voorbeeld te geven: dit betekent dat bijv. een student, die de private key te pakken heeft gekregen, eenvoudig https sessies van zijn huisgenotes kan afluisteren als zo'n huisgenote ooit Fortinet_CA_SSLProxy.cer in haar browser heeft geladen. Ook kan hij dan ongemerkt malware planten op haar PC.

Oplossing
De oplossing is simpel; Fortinet moet voor elke Fortigate unit die ze verschepen een uniek keypair plus een self signed CA certificaat genereren. Dan kan de klant (die niet zelf een CA wil opzetten en onderhouden) er meteen veilig mee aan de slag!

Wordt de Fortigate van die betreffende klant gecompromitteerd (en de private key gekopieerd door de aanvaller), dan is dat heel vervelend voor die klant maar geen enkel probleem voor alle andere Fortinet klanten.

Actie van Fortinet is dus noodzakelijk!
Als je een "ingang" hebt bij Fortigate, stel ik het, namens alle Fortigate gebruikers zeer op prijs als je ze ASAP informeert...

@KorhalDragonir: de unencrypted private key behorend bij Fortinet_CA_SSLProxy.cer staat op Internet!

==> Elke PC met het Fortinet_CA_SSLProxy.cer certificaat in de webbrowser is kwetsbaar!

Feitelijk is de bedoelde private key al een tijdje op internet te vinden. Ik dacht dat deze versleuteld was, maar zie zojuist dat dit niet zo is; mijn excuses voor het feit dat ik dit gemist heb.

Ik kan checken of deze private key daadwerkelijk bij de public key in het certificaat hoort, maar in elk geval de (shared) modulus en publieke exponent komen overeen met die in het certificaat. Daarnaast bevat de gepubliceerde Fortigate private key hetzelfde aantal componenten en groote als de private key van Cyberoam die in https://blog.torproject.org/blog/security-vulnerability-found-cyberoam-dpi-devices-cve-2012-3372 gepubliceerd is, zoek in die pagina naar July 10th, 2012.

Echter bij voorkeur checken Fortinet engineers of het daadwerkelijk om de bedoelde private key gaat; ik stel voor dat je contact met me opneemt. Bitwiper ontvangt iemeel bij xs4all. Ik wil ook best zelf contact met Fortinet opnemen, maar kan op hun website -helaas- nergens een "report vulnerability contact" vinden. Dus als je wilt dat ik dat doe laat die contactgegevens dan hieronder achter of stuur me een meel.

Aanvulling 20120825 20:23 - edits om aan te geven dat het zeker is (en niet vermoedelijk) dat de bij het Fortinet_CA_SSLProxy.cer certifitcaat horende private key unencrypted op internet staat. Zie mijn volgende bijdrage.

Om aan te tonen dat ik over de private key kan beschikken heb ik een fake server certificaat van support.fortinet.com gegenereerd:
Als je Windows kladblok opent, bovenstaande tekst daarin kopieert, en dit opslaat op je bureaublad als support.fortinet.com.fake.cer, en daar vervolgens op dubbelklikt, zal Windows je de inhoud van dit certificaat laten zien. Zichtbaar is dan o.a. dat ik de geldigheidsperiode op 7 dagen heb gezet en in het certificaat het Netscape Comment "Fake cert created by Bitwiper" heb opgenomen.

Echter, in mijn (Engelstalige) Windows staat: "Windows does not have enough information to verify this certificate" en in het Certification Path tabblad staat: "The issuer of this certificate could not be found". Met andere woorden, Windows vertrouwt dit certificaat niet. De reden daarvoor is dat ik Fortinet_CA_SSLProxy.cer niet heb geïnstalleerd.

Voor elke gebruiker die wel Fortinet_CA_SSLProxy.cer in z'n webbrowser (en/of Windows) heeft geïnstalleerd, iets dat noodzakelijk is als die persoon wel eens achter een Fortigate met SSL inspection zit, zal Windows geen foutmelding geven: het certificaat is dan gewoon geldig!

Als je wilt kun je dat zelf verifiëren aan de hand van Fortinet_CA_SSLProxy.cer: Open kladblok, kopieer bovenstaande tekst en sla op als Fortinet_CA_SSLProxy.cer. Dubbel-klik op het bestand. Klik op de knop "Install certificate...", click Next, laat de automatische keuze geselecteerd staan, klik Finish en bevestig de import van het Fortigate CA root certificaat.

Als je nu support.fortinet.com.fake.cer nogmaals opent (dubbelklikken), zul je zien dat deze nu wel vertrouwd wordt door Windows! Nb. ik had net zo goed een certificaat voor https://mijn.ing.nl/ kunnen maken of er binaries mee kunnen ondertekenen.

Opmerkingen:
- Aan mijn fake support.fortinet.com certificaat heb je niks zonder private key. Ik heb die private key natuurlijk wel in mijn bezit maar ga daar geen misbruik van maken. Een kwaadwillende kan echter net zo makkelijk als ik nepcertificaten maken (of gesigneerde malware) en die inzetten bij personen waarvan zeker is of vermoed wordt dat ze ooit Fortinet_CA_SSLProxy.cer in hun webbrowser hebben geïmporteerd.

- Iedereen achter een Fortigate die verbinding maakt met https://support.fortigate.com/ ontvangt een vergelijbaar gespoofed certificaat. Echter die zijn geen 7 dagen geldig en de tekst "Fake cert created by Bitwiper" komt daar natuurlijk niet in voor. Het feit dat ik zo'n certificaat heb kunnen maken, ondertekend met de private key behorend bij het Fortigate CA root certificaat, toont aan dat ik die private key in mijn bezit moet hebben en ik geen verhaaltjes uit mijn duim zuig.

- Vergeet niet Fortinet_CA_SSLProxy.cer weer te verwijderen als je deze hebt geïnstalleerd! Dat kan o.a. door in MSIE Internet Options te openen, dan het tabblad Content (Inhoud), de knop Certificates in te drukken en het tabblad "Trusted Root Certification Authorities" te openen. Scroll naar "Fortigate CA" en klik op Remove en bevestig de 2 waarschuwingen.

Ik vind het nog steeds onbegrijpelijk dat Fortigate niet even bij zichzelf in de keuken gekeken heeft toen hun conculega Cyberoam exact hetzelfde overkwam.

Aanvulling: bovenstaande BASE64 code van "Fortinet_CA_SSLProxy.cer" ingevoerd in https://factorable.net/keycheck.html leidt tot de volgende output:Overigens is het opmerkelijk dat de onderzoekers dit certificaat "zien", want het zou nooit als servercertificaat beschikbaar moeten zijn.

http://www.kb.cert.org/vuls/id/111708