 |
|
Potentsiaalne HTTPS turvaauk -- ID kaardid sahtlisse?
postitas mauri e-kaardimajake-väriseb osak. 13:53 6. november, 2009
Olavi kirjutab: "Tundub, et https autentimises on avastatud gigantne man-in-the-middle turvaauk, mis avaldub eriti hästi ID kaardi puhul. Patchi ja workaroundi minu arusaamisel ei eksisteeri. Viited: Another Protocol Bites The Dust Renegotiating TLS MITM attack on delayed TLS-client auth through renegotiation Nonii kus mu pin-kalkulaator oligi?"
Minuti lühikokkuvõte oleks siis selline: On avastatud väga oluline turvaauk, mis eksisteerib SSL ja TLS protokollides. Üks oluline kõrgema taseme protokoll, mis sellest ohtu sattub on HTTPS, mida kasutavad kõik ennast turvalisena reklaamivad veebisaidid. Sealhulgas netipangad, e-hääletus, i-valimised, kõik ID kaardi rakendused ja mis iganes veel.
< USA-s elab 36 miljonit inimest toidutalongide peal
| "Seagripp" levib, raha tuleb >
| |
| | |
|
Potentsiaalne HTTPS turvaauk -- ID kaardid sahtlisse?
|
Logi sisse/tee kasutajakonto
| Top
| 25 kommentaari
| otsi arutelust
|
|
|
|
peenes kirjas:
Järgmised kommentaarid kuuluvad nende autoritele.
Meie ei vastuta nende eest kuidagi.
|
|
Ilmselt asi lihtsalt töötab "as designed". Lihtsalt keegi panin tähele.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Kogu see läänemaailm on üks jew-in-the-middle perseauk.
|
|
|
[ vasta sellele | artikkel
]
|
|
Mitte ainult ei solgi see ära kõigi muude brauserite võimalusi ID-kaardiga sisse logida kui kaart on korra unustatud lugejasse pista
vaid nagu nüüd välja tuleb on massive turvaauk kah.
Ning seda kõike ainult selle pärast, et saaks näidata ühte haledat veateadet: "oi, ai idikakaarti nihhuiaa"
Vaata ka https://id.eesti.ee/idtrac/wiki/VeebisAutentimineAnttix
|
|
|
[ vasta sellele | artikkel
]
|
|
Kas selle 1. punkti - et peab olema eraldi IP-aadress, pole mitte SNI (Server Name Identification) ebavajalikuks muutnud?
http://en.wikipedia.org/wiki/Server_Name_Indicatio n
--
plaes
|
|
|
[ vasta sellele | artikkel
]
|
|
Kahjuks veel mitte. Vaata hoolega sealtsamast lehelt toetatud brauserite nimekirja:
Internet Explorer 7 (Vista, not XP) or later.
Ehk siis XP-ga ei tööta. Miks see probleem on võid ehk ise arvata ;)Anttix
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Kuulge taadid - nii palju kui mina aru saan siis on asi täpselt ristivastupidine - ehk siis IDkaart on ainuke mis peab ja kõik digipassid ja m-id'id paneks põlema!
|
|
|
[ vasta sellele | artikkel
]
|
|
Niipalju kui minu pisike aju nüüd seda situatsiooni võtab peale kolmeminutilist tutvumist, on jah asi selles, et - piltikult öeldes - kuigi kirju on teoreetiliselt võimalik läbi vaadata ja allkirja näha (nõuab füüsilist ligipääsu võrgule kusagil sinu ja näiteks panga vahel), ei saa keegi kuidagi seda allkirja nüüd selle pärast järgi teha. Mis sel asjal siis idkaardiga pistmist on? Just sellist, mida pin-kalkulaatoriga ei ole?
Ma loodan, et loo autor täpsustab veidi oma seisukohta. Vastasel korral soovitan edaspidi piirduda üksnes uudise enda edastamisega ja jätta kommenteerimine inimeste hooleks, kes midagi asjast jagada võiksid.
|
|
|
[ vasta sellele | artikkel
]
|
|
No kui just soovitakse täpsustust.
Pahalase võimalik rünnika stsenaarium , on iseenesest HTTPS puhul selline:
0. Pahalane istutab ennast ohvri ja serveri vahele ja ootab kuni ohver üritab serveriga ühendust alustada kuid võtab selle ühenduse ise vastu.
1. Pahalane alustab ise SSL ühendust serveriga.
2. Pahalane saadab serverisse oma suvalisi https requeste, mida ta soovib teha ohvri identiteedi alt kuid jätab lõpu tegematta e. HTTPS server veel ei asu neid requeste töötlema.
3. TLS tasandil saadetakse renegotiation request, ja edaspidi viiakse pahalase ja ohvri toru( punkt 0) ning pahalase ja serveri vaheline toru(punkt 1) omavahel kokku.
4. Server ja Ohver (pahalase vahendusel) saavad sõpradeks ja server assotsieerib https sessiooni ohvri ID-kaardi sertifikaadiga.
5. Ohver lõpetab https requesti.
6. Serveris läheb ohvri serdiga assotsieerituna töötlusele läheb aga pahalase request+ohvri request. Kui pahalase request on sobivalt konstrueeritud, siis tegelikult vaid pahalase request (ohvri request maskitakse).
Sisuliselt assotsieeritakse pahalase request ohvri id-kaardiga tehes renegotiation. Kas sellest piisab ükskõik mille tegemiseks - ei oska öelda, ilmselt sõltub kuidas rünnatavas serveris on turva lahendatud ja kuivõrd fantaasiarikas on pahalane.
Paar sõna SSLVerifyClientis või ütleme laiemalt kliendiserdi nõudmisest serveri poolt ühenduse loomiseks. Jah see võiks kindlasti sees olla (vähemalt praegu ta kõikidel finantsteenusepakkujatel sees ei ole). Kuid see ei ole minu hinnangul hõbekuul, kuna sisuliselt teeb ta vaid pahalase elu natuke raskemaks / jälitatavamaks. Nimelt peab pahalane punktis 1 toodud ühenduse loomisel omama ka mingi tankisti sertifikaati (id-kaarti). Kuna see sert renegotiation käigus vahetatakse ikkagi ohvri serdi vastu, siis ülejäänud peaks samaks jääma. Parandage kui eksin loogikas.
See, miks hetkel pin-kalkulaator. No lihtsalt sellepärast:
1. PIN-kalkulaatori puhul ei ole olemas ohvri sertifikaati, millega pahalase requeste assotsieerides saab serveri ära petta. Ehk server poolt vaadatuna tuleb lihtsalt pahalase request + ohvri (maskitud) request, kuid need requestid ei ole seotud ohvri identiteediga.
2. Niikaua kui ei ole ümber disainitud TLS protokolli on võimalik kliendi serti mittenõudval serveril (pin-kalkulaatori) renegotiation ära keelata nagu on kirjeldatud esimeses postituses toodud linkides ka soovitatud. See sõltub muidugi serveri omanikust, kas ta seda viitsib teha ja kas üldse on lihtsalt teostatav (ei ole avatud lähtekoodil baseeruv server/seade). ID-kaardi puhul selline mahakeeramine komplitseeritud, kuna seal on sertifikaatide ringiswitchimine tihti osa protsessist.
ID-kaart on väga tore asi, lihsalt hetkel olen mina ettevaatlik kuni TLS protokoll korda disainitakse + implementeeritakse. Hästi turvatud server on nagu sibul - seal on kindlasti mitu turvakihti. Üks pealmine kiht on praegu irvakil ja kõik sõltub sellest kas sibul on altpoolt mäda või ei.
Olavi.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Kahjuks on alates punktist 2 täisti vale rada. See haavatavus EI tööta nii. Ja kogu edasise arutelu võib vastavalt > dev/null.
|
|
|
[ vasta sellele | artikkel
]
|
|
Noh ega need ikka luulud ei ole, mida ülal kirjeldasin. Sama probleemi, mida kirjeldasin SSLVerifyOptional on nüüdseks ka IETF mail-listis arutatud ja algse vea avastanud March Ray kinnitab seda:
>
> Had anyone considered the scenario when the server requires client
> certificate from the beginning, but MITM possesses some other
> credentials that will be good for authentication (but can be of no use
> for authorization)? In this case MITM can use this certificate to start
> the splitting request, then initiate renegotiation and proxy client's
> request through the established channel.
Yes. I regret that we didn't get a chance to update the paper before
making it generally available, so it is a bit understated:
"Other techniques allow the attacker to forward or re-purpose client
certificate authentication credentials."
Veelgi hullem, tundub browseri käitumist ja infovahetust pakette on jõutud järeldusele, et on võimalikud ka sellised MITM rünnakud, kus kasutaja poolt www.mingipank.ee-le külastuse üritusega MITM ründe käigus tehakse hoopis www.mingiteenus.ee alt paar kiiret serdiga "turvatud" requesti. Ehk pangakülastus katse muutubki pizzatellimuseks vms.
Soovijatel tutvuda:
http://www.ietf.org/mail-archive/web/tls/current/m sg04039.html
|
|
|
[ vasta sellele | artikkel
]
|
|
Oot-oot. Palun seleta nüüd mulle, kuidas sinu arvates käib id-kaardiga pangatehingu tegemine täpselt. Ja mis on seal vahet pin-kalkulaatoriga pangatehinguga. Mida tähendab id-kaardi sertifikaat ning kuidas see on seotud SSL-sertifikaatidega.
Kui mingi tarkvara leiab, et kuna sessiooni jooksul id-kaardiga digiallkiri antud, siis järelikult kehtib see kõikide järgmiste tehingute juures samamoodi, siis on see tarkvara loll, mitte id-kaart. Sama kehtiks pin-kalkulaatoriga. Digiallkirja andmine ei ole mitte krdi kuidagi moodi seotud httpsiga ega sellega, kui turvaline see on. Ma võin digiallkirja anda üle absoluutselt turvamata võrgu ja see oleks täpselt sama turvaline.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
|
Tasub tähele panna, et see viga OpenSSL versioonis 0.9.8 g puudub, Täpsemalt saab infot näiteks siit [securityfocus.com]
|
|
|
[ vasta sellele | artikkel
]
|
|
Hmm 0.9.8g on täitsa listitud vigasena. Ainuke, mis "ei ole" vigane on eilse sisse checkatud versioon. Täpsemal viimane koodi uurimisel on siiski tehtud häkk millega lihtsalt renegotiation kinni keeratud.
+ Changes between 0.9.8k and 0.9.8l [5 Nov 2009]
+
+ *) Disable renegotiation completely - this fixes a severe security
+ problem at the cost of breaking all renegotiation. Renegotiation
+ can be re-enabled by setting
+ OPENSSL_ENABLE_UNSAFE_LEGACY_SESSION_RENEGOTATION at
+ compile-time. This is really not recommended.
+ [Ben Laurie]
+
|
|
|
[ vasta sellele | artikkel
]
|
|
|
See sissetsekatud versioon keelab renegotiationi ära. Mis on eriline idiootsus ID kaardi lahenduse korral. Palun saage enne aru mis auk see on ja kuidas töötab - st enne kui kommenteerima, veel enam midagi pätsima asute.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
|
Olen ka ise teadlikult paanikaosakonna propagandat teinud seoses e-valimiste ja väidetavate bugidega (Debiani OpenSSL...). Kuid mäletamist mööda oli kõik e-valimise ja valimisrakenduse vaheline suhtlus selline, et ilma kliendisertifikaadita ligi ei lastud (ehk siis vastupidiselt selles ründes kirjeldatav algatuseks anonüümse sessiooniga ühendumine, millele hiljem renegotiation tehakse). Seega valimised jäävad vist mängust välja, erinevalt pankadest ja muust säärasest "pudipadist". --
pisi - muidumees & maailmaparandaja
|
|
|
[ vasta sellele | artikkel
]
|
|
|
et mis neil pankadel siis sinu arust viga on kui me räägime IDkaardi autentimisest?
|
|
|
[ vasta sellele | artikkel
]
|
|
Põmst võib pahalane teha ühenduse mingi aktsepteeritava kliendiserdiga ja siis 'poole' http päringu peal saata ClientHello, algatades renegotiationi ning siis lihtsalt vahenda edasist liiklust kliendi ja serveri vahel.
Poindiks on see, et paha tegu peab saama selle ühe päringuga tehtud, edasist liiklust pahalane ei näe.
A muidu vahet pole, id-kaart või mitte, VerifyClient optional või required...
|
|
|
[ vasta sellele | artikkel
]
|
|
|
No kuulge, vahemeherünnak on ju põhimõtteliselt rakendatav ABSOLUUTSELT IGA asümmeetrilise krüptograafilise algoritmi vastu, sõltumata šifrist.
Tõestus: osapool A(lice) soovib ühendust võtta osapoolega B(ob), kasutades mingit võtmevahetusprotokolli.
Vahemees E(ve, dgar) teeb A ees näo, et ta on B ing B ees näo, et ta on A. Kui A ja B ei ole varem üksteist näinud ja üksteisele turvaliselt võtmeid andnud, ei saa A aru, et ta räägib B asemel E-ga ja B ei saa aru, et ta räägib A asemel E-ga. E dekrüpteerib kõik A-lt saadu ja krüpteerib selle B-le edasisaatmiseks B-ga ühenduse pidamise võtme abil. Sama lugu B-lt A-le info saatmisega: E dekrüpteerib B-lt saadu ja krüpteeriub uuesti A-le edasisaatmiseks.
Seega, HTTPs protokoll ei oma siin loos mingit tähtsust. Vaid 2 tingimust on olulised: et ID-kaardi avalik võti jõuaks muutmata kujul sertifitseerimiskeskusse ja et sertifitseerimiskeskuse võti jõuaks muutmata kujul sertifitseerimiskeskuselt infot küsivasse arvutisse. Loomulikult on siin mõlemal juhtumil võimalik vahemeherünnak, aga palju neid vahemehi siis on?
Teine asi on, et tegelikult on ju Windows'i masin ise üks kahtlane värk. Kui pidevalt on vaja igasugu viirusetõrjet, millega hakkama ei saada, siis pole ju garantiid, et mõni nendest viirustest digiallkirja andmise korral ID-kaarti hoopis mingi viiruse pootl valitud dokumendi räsi ei lase.
Kolmas asi on ka see, et ID-kaardi SHA-1 räsialgoritm hakkab "moraalselt vananema", pööratavaks muutuma, nii nagu kunagi sai MD5.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Tundub tõesti nii: http://www.imperialviolet.org/2009/11/05/tls-reneg .html
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Mind täiesti teemaväliselt huvitab, et mis olendid need küll on, kes igale poole oma postituste lõppu "päikest" topivad? Esiotsa mõtlesin, et see on üksainus omastarust nunnu vanamutt, aga viimasel ajal tundub see mingi moeröögatus teatud ringkondades olema. "Teatud ringkondade" all mõtlen ikka pooletoobiseid, mitte päikesekummardajaid. Ka tundub see päikesemöla nagu mingi vabandus olevat. Umbes nagu: "Sõiman-sõiman, aga tegelikult olen hea".
|
|
|
[ vasta sellele | artikkel
]
|
| | | 1 vastus allpool su määratud taset. |
|
|
|
