Kritična ranljivost v OpenSSL bi lahko omogočala krajo strežniških zasebnih ključev

poweroff je 11. apr 2014 ob 22:47 izjavil:

Pričakovano.

Upam, da bodo šli sedaj OpenSSL spisat na novo.

Zakaj, saj ga lahko sam. Saj je open surs!

poweroff je 12. apr 2014 ob 00:01 izjavil:

BTW: Heartbleed ranljivost in varnost slovenske državne uprave.

Katera inštitucija je pristojna za nadzor tega? Vsak sam? Policija šele ko do zlorabe pride (če sploh vedo zanjo)? Pri komercialnih ponudniki se lahko odločim in ne uporabljal njihove storitve, državo pa je malo težje zamenjati...

Preveč predpostavk.

techfreak :) je 12. apr 2014 ob 06:35 izjavil:

Iz pravokator.si:

Digitalno potrdilo spletnega mesta je podpisano s strani overitelja SIGOV-CA, ki ga spletni brskalniki privzeto nimajo shranjenega v shrambi digitalnih potrdil. To je sicer problematično in DURS bi si verjetno lahko privoščil nekaj evrov visok letni strošek overjanja svojega digitalnega potrdila s strani enega izmed zaupanja vrednih overiteljev.

Na svetu je precej zaupanja vrednih overiteljev, vendar ne ves kdo vse ima dostopa do njihovih intermediate in root certifikatov.

Pri SIGOV-CA si lahko precej bolj preprican, da ima dostop do certifikata samo vzdrzevalec informacijskega sistema (npr. e-davki) ter overitelj (SIGEN-CA). Ce predpostavljamo da root certifikat dobis na varen nacin, se lahko pri uporabi vedno prepricas da stran uporablja certifikat izdan s strani SIGEN-CA.

Če SIGEN-CA podpiše svoj certifikat z strani overiteljev, ki so vključeni v browser bo še vedno samo on imel dostop do privatnega ključa. Torej ne, podpisovanje z strani overitelja ne predstavlja nobene dodatne nevarnosti, niti teoretično.

Nevarnost, da overitelj ponaredi certifikat je namreč prisotna že apriori samo z tem, da "kompromiziran" overitelj sploh obstaja v tvojem browserju zapisan kot root. In ja, ISPji lahko pridejo do certifikatov podpisanih z strani overiteljev z katerimi lahko ponaredijo prav vsako SSL sejo. To uporabljajo sicer kao samo za "QOS"... In če lahko en bogi ISP pride do takih ključev ste lahko sigurni da lahko čisto vsaka malo pomembnejša organizacija izvaja MITM napade na poljubno HTTPS sejo z izjemo takih sej, kjer ima tudi stranka svoj certifikat(ebančne storitve).

Malo me moti, da se okoli tega Heartbleed-a zganja predvsem paniko, zelo malo pa je zaslediti REALNE ocene nevarnosti, ki jo ta bug povzroča.
Kakor jaz zadevo razumem, so 'zadetki' bolj ko ne stvar naključja in mora napadalec imeti kar nekaj sreče, da 'izpraska' kakšen dejansko uporaben podatek iz delovnega pomnilnika računalnika - pa še potem ga mora znati pravilno interpretirati (prepoznati) in potem tudi tudi znati uporabiti.
Nisem še zasledil nobene analize, ki bi nazorno pokazala v kolikšnem času se v povprečju uspe 'napraskati' session cookie uporabnika, v koliko primerih je dejansko uspelo strežniku izvabiti certifikata, koliko uporabniških gesel se v eni uri da pridobiti v praksi,....

Hočem reči, da je velika razlika med teorijo in prakso. Kaj je v teoriji možno, smo že vse slišali - zanima me pa PRAKTIČNA, torej DEJANSKA grožnja, ki jo bug predstavlja, podkrepljena z konkretnimi številkami, ki so bile pridobljene s testiranji, da bi se dalo bolj realno oceniti, kako veliko grožnjo v praksi predstavlja. Ali lahko rečemo 'bodo že poštimali' - ali pa bi morali zaradi tega imeti nemiren spanec.

Torej, na hitro. Na temo HTTPS varnosti pripravljam en obsežnejši članek, o tem bom imel tudi predavanje ha HEK.si. Samo par glavnih poudarkov.

Problem zaupanja vrednih CA-jev je seveda zelo realen. Vendar je po mojem mnenju napaka SIGOV-CA pristopa v tem, da od uporabnikov pričakuje, da si bodo uvozili njihov CA certifikat v svoj certificate store.

Večina uporabnikov tega ne bo storila, zato se bodo navadili spregledati opozorila brskalnika da je certifikat neustrezno podpisan. Poleg tega obstajajo naprednejše tehnike vzpostavljanja zaupanja certifikatu, npr. certificate pinnig, TACK, SSL Observatory, itd. Vsega tega naša e-Uprava očitno ne pozna.

Kakšne so praktične posledice Heartbleed ranljivosti? Recimo kraja identitete oz. session hijacking je zelo preprosta reč. Če se ti to ne zdi problematično v praksi...

chironex10 je 12. apr 2014 ob 10:09 izjavil:

O groza, zdaj bo pa zagotovo kdo na site udrl... Aja ne, dekriptirat bo šel povezavo me browserjem in edavki, ker je pa tam notri toliko zanimivega, da zagotovo upraviči trud.

Hmm, iz tvojega odziva bi kdo še sklepal, da si eden izmed "strokovnjakov", ki so nastavljali HTTPS konfiguracijo omenjenih dveh strežnikov...

Naj samo omenim, da ko sem pred leti pisal novice o tem, da so razbili GSM šifrirni algoritem A5/1, je bilo tudi precej takih odzivov. Ko sva potem z Jakatom nekaj časa za tem to tudi praktično demonstrirala na slovenskih GSM omrežjih, je pa zavladala tišina.

techfreak :) je 12. apr 2014 ob 19:09 izjavil:

Tudi pri CloudFlare so mislili da v praksi ni tako nevarna zadeva, vendar so jim dokazali nasprotno: http://blog.cloudflare.com/answering-th...

Nekoliko so olajšali zadevo z reštartom serverja - vendar je strašljivo, če lahko (z nekaj sreče) že samo z 100.000 requesti izpraskaš zasebni ključ. Škoda, da niso challenge vsaj dva dneva pustili teči na ne-reštartanemu strežniku in šele potem izvedli reštart oz. olajšali zadevo.

Zanimivo bi bilo, če bi raziskovalci 'vzeli na piko' tri različne ranljive strežnike, routerje, switche,... in objavili statistiko, koliko katerih občutljivih podatkov so strežniku izvabili v določenem časovnem obdobju. Za zavedanje neke grožnje, je bistveno bolj učinkovito, če veš, da 'povprečen strežnik' v eni uri napadalcu izpljune xx uporabniških gesel, yy session cooki-jev,....

Najbolj zaskrbljujoče pri vsej zadevi je namreč dejstvo, da kljub vsemu viku in kriku okoli tega buga tudi po enem tednu najdeš admine, ki zanj še niso slišali.

Zelo zanimivo bi bilo videti statistične podatke, kako hitro bodo upravljalci strežnikov pokrpali svoje sisteme. Koliko % (in kateri?) slovenskih 'top 100' strežnikov bo še ranljivih po 14 dnevih, enemu mesecu, dveh, treh...

chironex10 je 12. apr 2014 ob 10:09 izjavil:

Hmm, iz tvojega odziva bi kdo še sklepal, da si eden izmed "strokovnjakov", ki so nastavljali HTTPS konfiguracijo omenjenih dveh strežnikov...

In sklepal bi narobe.

chironex10 je 12. apr 2014 ob 10:09 izjavil:

Naj samo omenim, da ko sem pred leti pisal novice o tem, da so razbili GSM šifrirni algoritem A5/1, je bilo tudi precej takih odzivov. Ko sva potem z Jakatom nekaj časa za tem to tudi praktično demonstrirala na slovenskih GSM omrežjih, je pa zavladala tišina.

Govoriš o dveh popolnoma različnih stvareh s popolnoma drugimi nivoji problematike. Za tisti članek kapo dol, tale zadnji, pa je na nivoju Lady. In tudi če se z njim usedeš na ramena velikana (A5/1) ne bo zato nič boljši. In tudi ad hominem zgoraj ti ni prav nič v čast. Včasih je pač bolje ne objaviti nič.

Me zanima kaj boš tu demonstriral, če boš demonstriral kako se vtakniti med edavke in uporabnika, brez, da bi bil zaposlen kot sistemec na vmesni poti, bo to demonstracija, ki bo daleč presegala vrednost "neverjetnih" ranljivosti v edavkih.

Invictus je 9. apr 2014 ob 09:49 izjavil:

WizmoTo je 8. apr 2014 ob 23:00 izjavil:

Kaj se je že zgodilo s tistim tipom, ki je neki slo. banki povedal, da je odkril luknjo ?

Samomor je naredil ...

Menda so bile okoliščine samomora precej čudne. Ampak, če so tako zaključili bo že držalo

Zanimivo da imam pri svojih domenah povsod A-, ceprav imam povsod privzete nastavitve.

Še dva z oceno F (pa ne samo zaradi nezaupanja SIGOV-CA).

evlozisce-test.sodisce.si (84.39.221.41)
evlozisce.sodisce.si (84.39.221.40)

Najslabša ocena, ki ni povezana z nezaupanjem v CA:

This server supports SSL 2, which is obsolete and insecure. Grade set to F.

Najboljše je obvestilo banke Sparkasse na omenjeno ranljivost:

Spoštovani,

v zadnjih dneh se je na spletu pojavila varnostna pomanjkljivost heartbeat, ki jo uporabljajo nekateri sistemi pri uporabi varnih spletnih storitev. Spletne storitve banke Sparkasse na to varnostno pomanjkljivost NISO ranljive. V banki Sparkasse redno posodabljamo celoten bančni sistem. Vsem uporabnikom priporočamo, da redno posodabljajo svojo programsko opremo in varnostne mehanizme. Več informacij omenjene varnostne ranljivosti lahko prebere na spletnih straneh SI-CERT. https://www.cert.si/si-cert-2014-03-ope...

Banka Sparkasse d.d
https://netstik.sparkasse.si/eb/obvesti...

Berejo ST.

http://www.openbsd.org/papers/bsdcan14-...

zanimivi slajdi, ce koga zanima realno stanje. vse OSS ni nujno najboljša stvar po narezanem kruhu.