(Voortzetting - samen met het bovenstaande kwalificeerde security.nl dit als spam - zucht)

Eigen onderzoek (met Google) lijkt dit te bevestigen. Zoeken naar "Fortinet_CA_SSLProxy.cer" leidt me naar verschillende sites met identieke root certs, die gebruikers in hun OS en/of webbrowser moeten importeren:

- https://sites.google.com/a/cakmail.org/student-laptop-program/security-certificate/Fortinet_CA_SSLProxy.cer (van de Christian Academy of Knoxville, geen idee waarom dit op een Google site staat)

- http://web.saihs.edu.tw/iec/download/Fortinet_CA_SSLProxy.cer (Songshan High School of Agriculture and Industry, Taipei, Taiwan)

- http://aau.in/sites/default/files/certificate.zip (Anand Agricultural University, Anand, India)

Zoeken naar de 1e regel van de .cer file: levert nog meer interessants op:
- http://users.telenet.be/kennes/FGT50B3G08638815_20091023%20laatst%20conf%20bouw.conf
- http://users.telenet.be/kennes/FGT50B3G08638815_20091020.conf

Hierin zie ik, naast het certificaat, ook (uit de 1e link, de 2e wijkt af maar bevat natuurlijk wel dezelfde private key): Vergelijkbare data is te vinden in bijv. http://www.credist.co.jp/sample/afa/Demo5.3/firewalls/afa-594/raw_files/gen-tulip.fortigate en http://netnotetw.blogspot.co.at/2010/09/exp80c6321990913conf.html (ongelofelijk dat admins dit soort info online posten).

Hoe lastig het is om hieruit de -unecrypted- private key te herleiden weet ik zo snel niet, maar met kennis van de Fortinet sources (die best wel eens op open source materiaal gebaseerd zouden kunnen zijn) en verschillende encrypted versies van dezelfde private key kunnen alleen maar "helpen" bij pogingen de private key te achterhalen. Voor een bezitter van een (tweedehands/gestolen) Fortinet UTM is het waarschijnlijk niet moeilijk om de private key te achterhalen, waarmee Fortinet net zo lek is als Cyberoam.

Nb. in het Fortinet root certificaat is geen CRL en/of OCSP URL opgenomen waardoor het niet kan worden gerevoked anders dan het te verwijderen of blacklisten.

Conclusie: Cyberoam en Fortinet lijken niet te beseffen hoe ze eindgebruikers in gevaar brengen. Dit zijn merken die nooit meer op mijn boodschappenlijstje zullen voorkomen...

Zoals steeds weer een uitstekende post Bitwiper! Maar kan je me eens verklaren hoe je precies bij die configuration files van telenet bent uitgekomen (via google gezocht op die "Fortinet_CA_SSLProxy.cer" ?). En betekent dit dat ik als telenet gebruiker nu ook gebruik maak van hun certificaat. Zoja, waar kan ik dit terugvinden en heeft dit specifieke gevolgen?
EN welke stappen zou ik kunnen nemen om dit wat meer dicht te spijkeren?

Alvast bedankt.

Om de SSL inspection te activeren gebruik je je eigen Root CA en nooit die dat factory default op de Fortigate staan. Mensen die dat wel doen zouden best eerst even de manual lezen.

De FG speelt als proxy en versleuteld het verkeer terug met de SSL van de eigen CA.

Indien de std. certificate gebruikt wordt krijgen alle clients een warning dat de CA niet vertrouwd is wanneer ze een https site bezoeken. Gebruikt de FG de CA van het bedrijf, is deze wel trusted maar dan nog kan het zijn dat bepaalde site problemen geven (banken), deze sites worden dan best niet via de SSLProx gedaan. (makkelijk te doen met de webfiltering module)

Nee,
Google naar: MIID1zCCAr+gAwIBAgIBADANBgkqhkiG9w0BAQUFADCBpTELMAkGA1UEBhMCVVMx

Dat is de 1e regel van het root certificate. Die Fortinet_CA_SSLProxy.cer bestaat uit de volgende leesbare tekst: Nb. als je alle bovenstaande tekst (in het grijze vlak, van "-----BEGIN" t/m "END CERTIFICATE-----" en de lege regel erachter) in kladblok kopieert en in bijv. op je Windows bureaublad opslaat als "Fortinet_CA_SSLProxy.cer" (let op dat de feitelijke bestandsextensie .cer wordt en niet .cer.txt) dan kun je er op dubbelklikken en zal er een dialoogbox verschijnen met (in mijn Engelstalige XP) de volgende informatie in het "General" tabblad: In de "Details" tab kun je alle gegevens van dit certificaat bekijken. Als je op de eerste knop klikt kom je (in XP) in de 1e dialoogbox van de Certificate Import Wizard (die zou ik niet doorlopen in dit geval...)

In theorie zou dit kunnen maar in dit geval is dat niet zo. Het gaat hier om een slordige admin van klein ICT bedrijfje met een (hoogstwaarschijnlijk privé) Telenet.be account. Ik heb dat bedrijfje en de het bedrijf met de Fortinet appliance ondertussen gewaarschuwd.

Iedereen die bovenstaand certificaat in één of meer van de certificate stores op zijn of haar PC heeft zou deze onmiddellijk moeten verwijderen - of een kopie ervan importeren in de "Untrusted Certificates" store.

Bij importeren moet je er wel om denken dat de meeste certificate stores uit een systeen een een "per gebruiker" deel bestaan, importeren in de "Untrusted Certificates" store moet je beslist in het systeemdeel doen.

Update 2012-07-12 18:32 - typo's gefixed en kleine aanvulling.
Update 2012-07-12 23:14 - http://users.telenet.be/kennes/ is niet meer toegankelijk. Dat lost het probleem van Fortinet natuurlijk niet op, want elke kwaadwillende of slordige admin, of "successvolle" aanvaller, kan Fortinet configuratiebestanden (eventueel onbedoeld) publiceren (of reeds uit bovenstaande "share" hebben gekopieerd).

De private key van Cyberoam is in comments onder https://blog.torproject.org/blog/security-vulnerability-found-cyberoam-dpi-devices-cve-2012-3372 gepubliceerd.

Dat je een ander certificaat zou moeten genereren en gebruiken spat er in elk geval niet vanaf in http://kb.fortinet.com/kb/viewContent.do?externalId=FD32404.

Het punt is dat mensen (vooral beheerders, die hebben minder tijd dan "normale" mensen ;) geen manuals lezen. Om ze te dwingen veilig van SSL DPI gebruik te maken zou zo'n device helemaal geen fixed (dwz non-random) assymetrisch sleutelpaar aan boord mogen hebben. En als het dan TOCH moet (om te testen bijv.), dan een certificaat dat verlopen is en ZEKER niet een die geldig is tot eind 2028 zonder te zijn voorzien van revocation mogelijkheden. Dit is echt prutswerk.

En nergens kom ik documenten tegen (maar misschien kijk ik eroverheen) die voorschrijven wat je (als beheerder) moet doen mocht zo'n UTM (Unified Threat Management) appliance gecompromitteerd raken. En dan heb ik het zowel over de situatie bij Cyberoam en Fortinet, als bij appliances met unieke root certs. Immers elk apparaat kan gecompromitteerd raken; vaak draaien er allerlei services op (waaronder virusscanners). Dit zijn uiterst complexe apparaten waarop vanalles mis kan gaan (zie bijv. http://www.net-security.org/secworld.php?id=10882, https://www.net-security.org/secworld.php?id=10884 en http://www.theregister.co.uk/2008/12/03/sonicwall_licensing_snafu/).

Hoe zorg je dat alle gebruikers met een gecompromitteerd root certificaat deze verwijderen of blokkeren? Is revocation mogelijk op de een of andere manier? Wat is een verstandige keuze voor een looptijd als je zelf zo'n root certificaat genereert? Krijgen gebruikers die een organisatie verlaten (BYOD!) het advies om zulke root certs te deïnstalleren? En doen ze dat dan ook?

PS niet dat ik al dit soort informatie paraat heb, ik schrijf dit van me af ook om voor mezelf op een rijtje te zetten welke vangnetten er in het geval van PKI securityproblemen zouden moeten bestaan. Tips (bijv. verwijzingen naar handige documenten) zijn welkom!

Anoniem @ 15:45 heeft de enige zinvolle post in dit topic.

Je gebruikt of geen SSL inspectie als je geen tijd hebt, of je gebruikt het wel en richt het goed in?
Ik zie het probleem niet..

Los daarvan zijn alle SSL connecties gevoelig voor MITM.
Dus snap de heisa niet zo..
Gevalletje klok klepel?

Hmm, interessante kwestie. Maar gaat dit niet alleen maar op op het moment dat de private key bekend is? In het geval van Fortinet is dit toch niet de case? Als het eenvoudig zou zijn om uit de public key de private key te halen zoals in de post van BitWiper om 00:20 gesteld word, dan hebben we volgens mij een probleem van een veel grotere orde.

De private key kan je met weinig moeite uit de virtual appliance versie van een fortigate halen.
Hier staat in de root van sda1 een file rootfs.gz met daarin de etc folder met de certs.

-rw-r--r-- 1 root root 3.4K May 11 21:20 ca_512.crt
-rw-r--r-- 1 root root 2.0K May 11 21:20 ca_512.key
-rwxr-xr-x 1 root root 1.4K May 11 21:20 cacert.pem
-rw-r--r-- 1 root root 1.4K May 11 21:20 ca.crt
-rw-r--r-- 1 root root 1.7K May 11 21:20 ca.key
drwxr-xr-x 6 root root 4.0K May 11 21:20 cert
-rw-r--r-- 1 root root 1.8K May 11 21:20 comodo_ca.crt
-rw-r--r-- 1 root root 1.9K May 11 21:20 comodo.crt
-rw-r--r-- 1 root root 1.7K May 11 21:20 comodo.key
drwxr-xr-x 2 root root 4.0K May 11 21:20 custom_menu
-rw-r--r-- 1 root root 405 May 11 21:20 fase.rules.conf
-rw-r--r-- 1 root root 51K May 11 21:20 fc_fasl.dat
-rwxr-xr-x 1 root root 91 May 11 21:20 fcni.dat
-rwxr-xr-x 1 root root 71 May 11 21:20 fdnservers.dat
-rw-r--r-- 1 root root 3.1K May 11 21:20 fgt_512.crt
-rw-r--r-- 1 root root 493 May 11 21:20 fgt_512.key
-rwxr-xr-x 1 root root 4.2K May 11 21:20 fgt.crt
-rwxr-xr-x 1 root root 1.7K May 11 21:20 fgt.key
-rwxr-xr-x 1 root root 451 May 11 21:20 fips.crt
drwxr-xr-x 2 root root 4.0K May 11 21:20 hasync.dhcpd
-rw-r--r-- 1 root root 767K May 11 21:20 idsav.rules
-rw-r--r-- 1 root root 1.1M May 11 21:20 ids.rules
-rw-r--r-- 1 root root 0 May 11 21:20 idsuser.rules
-rw-r--r-- 1 root root 159K May 11 21:20 ip_country_dict.gz
-rw-r--r-- 1 root root 566K May 11 21:20 manuf.map
-rw-r--r-- 1 root root 6.4K May 11 21:20 modem_list.conf
drwxr-xr-x 2 root root 4.0K May 11 21:20 pac
-rw-r--r-- 1 root root 137K May 11 21:20 pci.ids
-rw-r--r-- 1 root root 665 May 11 21:20 sample.pac
-rwxr-xr-x 1 root root 47 May 11 21:20 sci.dat
drwxr-xr-x 2 root root 4.0K May 11 21:20 ssh
-rw-r--r-- 1 root root 1.6K May 11 21:20 sslvpn-sw-list
-rw-r--r-- 1 root root 218K May 11 21:20 system.conf.def
-rw-r--r-- 1 root root 0 May 11 21:20 system.csum
-rw-r--r-- 1 root root 211K May 11 21:20 system-tp.conf.def
-rw-r--r-- 1 root root 217K May 11 21:20 system.vd.conf.def
-rwxr-xr-x 1 root root 15K May 11 21:20 termcap
-rw-r--r-- 1 root root 3 May 11 21:20 vdlicense-v30.dat
-rwxr-xr-x 1 root root 1.2M May 11 21:20 vir
-rw-r--r-- 1 root root 21K May 11 21:20 virexdb
-rw-r--r-- 1 root root 21K May 11 21:20 virext

Zie onderaan het bericht https://secure.security.nl/artikel/42224/1/Fortinet_SSL_DPI_ook_lek_%28net_als_Cyberoam%29%3F.html#comment-289518

bovenstaand certificaat inclusief private key:


ca.crt
-----BEGIN CERTIFICATE-----
MIID1zCCAr+gAwIBAgIBADANBgkqhkiG9w0BAQUFADCBpTELMAkGA1UEBhMCVVMx
EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTERMA8GA1UE
ChMIRm9ydGluZXQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEVMBMG
A1UEAxMMRm9ydGlHYXRlIENBMSMwIQYJKoZIhvcNAQkBFhRzdXBwb3J0QGZvcnRp
bmV0LmNvbTAeFw0wODEwMTgwMDQ2MzlaFw0yODEwMTMwMDQ2MzlaMIGlMQswCQYD
VQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2YWxl
MREwDwYDVQQKEwhGb3J0aW5ldDEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y
aXR5MRUwEwYDVQQDEwxGb3J0aUdhdGUgQ0ExIzAhBgkqhkiG9w0BCQEWFHN1cHBv
cnRAZm9ydGluZXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
tveDq5vViSsRgHROaylt0qMdteLi1D/L0AWct+j5Y+N+HskBqsK5eGHrgytW6Jr3
dtQ/53/usTI+8HHpPXj8gWune6ivjQcOAmGsB/gfwLPCa98+kLgo9wpu0NxLVbyU
i5F9OjFtMpEGsYlnu6jtrsIR8EonAnaUtYKCqPLNSVc/U97ZX9m7zyjLYEGENt2M
elnAeTDNy2VHdxvjCkHBZYuI8lygtQsFvAGdvHsoIGEKgnLHbycLCWUk1j9mTkYB
0QFKWdy45jsvrUEnaEuWBlIKNZEgy8uI1wW/Rtv1HHbofuWr/2gTIaggPjIWshak
sPA5wXth1N5pBMrPOxNoHwIDAQABoxAwDjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3
DQEBBQUAA4IBAQBrAfI+ULwg3M+k4s3FB6//6sPG5TcrvPdrQ8gArEeYJJCzHnVY
tknIPPx1K5V+QueAXRpLiuWphFP5w9OxWuDqHw8zwb24wJc7BD4CeFKUyYinbpDi
Yg035SKYl4TSGMOTiYRoTxqgkfzcmTFfpfD1pOJQ08Kh+1yle35WqG9Ab1jrO0Y/
vltGReZckwh9e95SPzNA43xGZPSIgxZ8007EUqYBekoSKGAQPqTalHBkzpB1Us3F
5yCZzxA4WYT9UGVwPhIVgMlZvm5NL29/5dFgts51U+P4OZ0Or+xQfWYIxTzCWtAC
1ikZ/6HeIvet27H4CPP1rolBTXw4z6olP32T
-----END CERTIFICATE-----

ca.key
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAtveDq5vViSsRgHROaylt0qMdteLi1D/L0AWct+j5Y+N+HskB
qsK5eGHrgytW6Jr3dtQ/53/usTI+8HHpPXj8gWune6ivjQcOAmGsB/gfwLPCa98+
kLgo9wpu0NxLVbyUi5F9OjFtMpEGsYlnu6jtrsIR8EonAnaUtYKCqPLNSVc/U97Z
X9m7zyjLYEGENt2MelnAeTDNy2VHdxvjCkHBZYuI8lygtQsFvAGdvHsoIGEKgnLH
bycLCWUk1j9mTkYB0QFKWdy45jsvrUEnaEuWBlIKNZEgy8uI1wW/Rtv1HHbofuWr
/2gTIaggPjIWshaksPA5wXth1N5pBMrPOxNoHwIDAQABAoIBAAqml+SaerC0cB1h
J9t3GuyDEEyxO3ENkai3Wusdxb651HKoUs+E7FUEpjgJgtKhirxBGMM6IEPyX9WR
W/l3HIPQJ3y8UhPMkFU1KFWCbR7DmBK9eR/liITw94hy+nOwOZlyS67ih6/E33Xg
QMicydE9fNvXBTRQgNGcGk0JbUfSkihXRin/v88NSHU7P1Q1ptuhkQVZ06EGpYuq
hbcvoBfj4hxPhK3C8kzOnVOF9T+6Gtq3TTOophSGrpXRAXbtqcmyE8B6Oe0EluaV
AMasT8BVG9LeEzEvZDROvHtnswNGzS8+UTZz3+pm71tucQQrjMhBgevoF2x3CXbJ
ANzlockCgYEA34UtOfcgfIPmhPKJQgqtp7YmFxn9Ad3rhHtAuHmQmWb2oJAaFOcI
WYVziveYmsoEKCCL8b6639oQ7RgHYz2Tjs/aIPGEtneG2PhSqBex2vMsgZv60f3P
+cccnGa48dnviswpQzP9f26TXXZnE4IRIxbZfZT0DyEcIKaVz+zX9i0CgYEA0Y3G
l5tTVHHnhFSkjz5wxzjMnSoiN4Em6uOxvN7YQkOzK+CBsPYYrbS3IblS9z9073rJ
YbylOWYrJJXIZmIEml7Ffv6XD0zIV0yXkv93aZFgtVwPW84lEd39WThMdGXnoO7T
uxQ3wT6IQx/7B06VLZnvZoWkJ8kiUAecsiSpcvsCgYB2SUoH1OoSOtMxJBDTLEd9
63z42L310PUkJP25IkwNglmd2uSSjzjx9xeQQTs3HxVYDvFAO4k1kXdHoWG3eQyv
lPuAV4+96D8qby9+2Rs8HVg+NsdjfYgkTOStOAdDpeuIbkaf09GhMGk4GsKtpjVf
dmYeeUc3AnSaKs45PMOE+QKBgAN/gF8rgpqYRCsbVpvliPBqbE/7UhLnHwUww9jJ
R4bjpmwHFWMk2IidyajQdSgXcRZGUHJHOeLZZ8L2lR/QZw9Eobta+J6Sw41hg+46
QX4LpTehz8fSix/fOslwfSY8RT+UfQhUcBHTv2aPdBtNHoRiW3K0rGbVnrMDTYRT
xFhdAoGBAN2esVoSUhIO66ls27ga5K/XzL3rjqn+UdoGkwSm0EGIJyDqrcskDhea
YGpaauL414mh0kCI5585SiypIZkh6a98EocAlSXURR0UB6RTbEQ0e0nvy6s2ogtq
URXsltKMIHdGwHkfS8ddN03fysbTR/bM/owgn7EfbX1nrxthYkZ+
-----END RSA PRIVATE KEY-----


openssl pkcs12 -export -in ca.crt -inkey ca.key -out ca.p12

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

Meer achtergrond in http://www.security.nl/artikel/42782/1/Sleutelblunder_in_systeem_kritieke_infrastructuur.html.