Derfor ble sikkerhetshullet et stort problem

[Nilsen]

Nettet vil aldri bli 100 prosent sikkert.

Derfor ble sikkerhetshullet et stort problem

[efikkan]

snip

Nok en tulleartikkel om dette tema. Dette er forkastelig dårlig journalistikk!

 

Kode kan være 100% sikker, men det er ikke vanlig. Argumentet om at all kode inneholder feil er ugyldig. Denne buggen er forårsaket av elendig kode.

 

For at noen skal utnytte heartbleed-buggen må mot alle odds klare å få privatnøkkelen i de 64kB de dumper ut som de ikke har kontroll over, og det er omtrent som å vinne i lotto. Deretter trenger de fysisk tilgang til nettet som forbinder trafikken mellom en klient og en server, og kan da se trafikken som går til serveren, men ikke den andre veien. Dette gir ikke tilgang til server eller databaser av passord eller sensitiv informasjon. Det er altså kun nettleverandører, transittselskaper og eventuelle myndigheter som kan utnytte det i praksis, og vi har ingen beviser på at det har skjedd hittil.

 

Vi har derimot så utrolig mange reelle sikkerhetstrusler å ta hånd om:

* Svært mange nettjenere er ikke oppdatert og lette bytter.

* Svært mange bruker utdatert nettleser eller JRE.

* Svært mange har routere med kjente sårbarheter.

 

Heartbleed må selvsagt fikses, men utgjør ikke en enorm sikkerhetstrussel.

Endret 10. april 2014 av efikkan

[EnvyAndroid]

 

snip

Nok en tulleartikkel om dette tema. Dette er forkastelig dårlig journalistikk!

 

Kode kan være 100% sikker, men det er ikke vanlig. Argumentet om at all kode inneholder feil er ugyldig. Denne buggen er forårsaket av elendig kode.

 

For at noen skal utnytte heartbleed-buggen må mot alle odds klare å få privatnøkkelen i de 64kB de dumper ut som de ikke har kontroll over, og det er omtrent som å vinne i lotto. Deretter trenger de fysisk tilgang til nettet som forbinder trafikken mellom en klient og en server, og kan da se trafikken som går til serveren, men ikke den andre veien. Dette gir ikke tilgang til server eller databaser av passord eller sensitiv informasjon. Det er altså kun nettleverandører, transittselskaper og eventuelle myndigheter som kan utnytte det i praksis, og vi har ingen beviser på at det har skjedd hittil.

 

Vi har derimot så utrolig mange reelle sikkerhetstrusler å ta hånd om:

* Svært mange nettjenere er ikke oppdatert og lette bytter.

* Svært mange bruker utdatert nettleser eller JRE.

* Svært mange har routere med kjente sårbarheter.

 

Heartbleed må selvsagt fikses, men utgjør ikke en enorm sikkerhetstrussel.

Etter hva jeg har skjønt, kan man dumpe ut 64 KB hver gang.

Altså kan man få ut mer.

[efikkan]

Etter hva jeg har skjønt, kan man dumpe ut 64 KB hver gang.

Altså kan man få ut mer.

Ja det er avhengig av hva som befinner seg i minnet som ligger etter der payloaden din havner. Du har ikke kontroll over hvor innenfor programmets virtuelle adresseområde dette er, og det blir et lotteri hva slags informasjon du får ut. At du treffer på privatnøkkelen skal noe til, spesielt siden den befinner seg i et område som er rimelig konstant under kjøring. Dataen som dumpes ut er naturligvis begrenset til hva som befinner seg i OpenSSL-prosessens minne til enhver tid. Sensitiv informasjon er bare innom der øyeblikksvis. Husk at sannsynligheten for at du finner deler av en sensitiv pakke er veldig lav på en normal nettjeneste. Passord sendes normalt én gang ved innlogging, og deretter sender gjerne tusenvis av pakker gjennom en økt.

 

Endret 10. april 2014 av efikkan

[ShadowMaster]

 

Etter hva jeg har skjønt, kan man dumpe ut 64 KB hver gang.

Altså kan man få ut mer.

 

 

Helt korrekt.

Men efikkan har også i minst en annen tråd demonstrert at han ikke har satt seg inn i hva heartbleed er.

 

Her er et eksempel på hva man kan få ut, uten å gjøre annet enn å sende en forespørsel til en tjeneste som benytter usikret openssl:

https://twitter.com/markloman/status/453502888447586304

 

Bruce Schneier som er ganske oppegående på datasikkerhet har uttalt følgende:

 

Basically, an attacker can grab 64K of memory from a server. The attack leaves no trace, and can be done multiple times to grab a different random 64K of memory. This means that anything in memory -- SSL private keys, user keys, anything -- is vulnerable. And you have to assume that it is all compromised. All of it.

"Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.

 

Man kan velge å stole på de som oppdaget feilen og de fremste sikkerhetsfolkene i verden om at dette er meget alvorlig og det er trivielt å hente ut sensitiv data, eller man kan stole på en tilfeldig forumbruker. Opp til hver enkelt.

Endret 10. april 2014 av ShadowMaster

[efikkan]

 

Etter hva jeg har skjønt, kan man dumpe ut 64 KB hver gang.

Altså kan man få ut mer.

Helt korrekt.

Men efikkan har også i minst en annen tråd demonstrert at han ikke har satt seg inn i hva heartbleed er.

 

For å ta et sitat du skrev tidligere i dag:

Poenget med heartbleed feilen er at den gir mulighet til å hente ut vilkårlig 64k fra minnet til prosessen som bruker OpenSSL

De som vet hva en kernel i et operativsystem gjør, vet at én prosess ikke kan aksessere minneområdet til en annen prosess. Minneområdet er oppdelt i pages som er hele blokker med minne reservert for én prosess. Mappingen av slike blokker er gjort internt i CPUen, så det har ingenting med programvarebugs.

 

Hva OpenSSL er i stand til å lekke ut er begrenset til minnet som er paget til prosessen. Det er harde fakta. Heartbleed kan altså lekke ut det som tilfeldigvis befinner seg "rett bak" payloaden, og dette kan f.eks. være rester av andre pakker eller privatnøkkelen. Men sannsynligheten for at du treffer på noe sensitiv data er ekstremt lav, spesielt siden passordet utgjør mindre enn 0.001% av trafikken på en typisk tjeneste.

[ShadowMaster]

 

Poenget med heartbleed feilen er at den gir mulighet til å hente ut vilkårlig 64k fra minnet til prosessen som bruker OpenSSL

De som vet hva en kernel i et operativsystem gjør, vet at én prosess ikke kan aksessere minneområdet til en annen prosess. Minneområdet er oppdelt i pages som er hele blokker med minne reservert for én prosess. Mappingen av slike blokker er gjort internt i CPUen, så det har ingenting med programvarebugs.

 

Hva OpenSSL er i stand til å lekke ut er begrenset til minnet som er paget til prosessen. Det er harde fakta. Heartbleed kan altså lekke ut det som tilfeldigvis befinner seg "rett bak" payloaden, og dette kan f.eks. være rester av andre pakker eller privatnøkkelen. Men sannsynligheten for at du treffer på noe sensitiv data er ekstremt lav, spesielt siden passordet utgjør mindre enn 0.001% av trafikken på en typisk tjeneste.

 

 

Jeg vet nøyaktig hva en kjerne, eller kernel er og gjør. Jeg har aldri påstått at man kan hente minne utenfor prosessen som er aktuell, men det trenger man da heller ikke da minnet TIL prosessen inneholder den sensitive informasjonen. Minnet er allokert prosessen av CPU, ja, men det hindrer på ingen måte prosessen selv i å aksessere minnet den har blitt tildelt. Og prosesser holder gjerne på minnet en god stund og det blir ikke nødvendigvis flushet med en gang. Apache prosessene på en av våre servere sitter akkurat nå med 700M med minne som er delt mellom alle prosessene, som alle har tilgang på dette delte minnet.

Det virker nesten som om du blander inn minnebufferne til transportlaget som er veldig kortlivede, men som er ganske urelevant for hva som ligger i minnet til prosessen forøvrig.

 

Det virker som om du baserer deg på at en angriper kan hente ut kun 64k av minnet totalt eller at ting ikke blir liggende i minnet i nevneverdig tid, når faktum er at dette kan hentes ut gang på gang på gang i relativt stor hastighet, og da sitter du plutselig på veldig mye av minnet til prosessen. Sannsynligheten er derfor IKKE lav, noe som har blitt demonstrert gang på gang de siste dagene. Det faktum at jeg selv etter 5 minutter satt med brukernavn og passord på flere brukere etter å ha sjekket kun en av våre webservere gjør at jeg ikke klarer å ta din påstand om at dette ikke på noen måte er alvorlig. At du tydeligvis avfeier alt eksperter på området sier om sårbarheten sier vel sitt.

 

Det som plager meg er at du driver med misvisende informasjon og får folk til å tro at dette ikke er alvorlig, at det er vanskelig å hente ut informasjon, når alvorligheten til hullet er nettopp at det er lett å hente ut slik informasjon.

[Gjest bruker-293283]

 

snip

Nok en tulleartikkel om dette tema. Dette er forkastelig dårlig journalistikk!

 

Kode kan være 100% sikker, men det er ikke vanlig. Argumentet om at all kode inneholder feil er ugyldig. Denne buggen er forårsaket av elendig kode.

 

For at noen skal utnytte heartbleed-buggen må mot alle odds klare å få privatnøkkelen i de 64kB de dumper ut som de ikke har kontroll over, og det er omtrent som å vinne i lotto. Deretter trenger de fysisk tilgang til nettet som forbinder trafikken mellom en klient og en server, og kan da se trafikken som går til serveren, men ikke den andre veien. Dette gir ikke tilgang til server eller databaser av passord eller sensitiv informasjon. Det er altså kun nettleverandører, transittselskaper og eventuelle myndigheter som kan utnytte det i praksis, og vi har ingen beviser på at det har skjedd hittil.

 

Vi har derimot så utrolig mange reelle sikkerhetstrusler å ta hånd om:

* Svært mange nettjenere er ikke oppdatert og lette bytter.

* Svært mange bruker utdatert nettleser eller JRE.

* Svært mange har routere med kjente sårbarheter.

 

Heartbleed må selvsagt fikses, men utgjør ikke en enorm sikkerhetstrussel.

 

Her er litt lesestoff til deg på sengen efikkan.

[endrebjo]

Hva er årsaken til at akkurat OpenSSL er så utbredt og ikke f.eks OSS-alternativet NSS? Etter hva jeg kan lese rundt om kring virker NSS som en solid løsning med mange store aktører i ryggen, mens OpenSSL fremstår mer som en liten og sammensveiset gruppe mennesker uten skikkelig struktur.

[ShadowMaster]

Kjenner ikke så godt til detaljene rundt det, men vil anta at det har sammenheng med at de i lengre tid hadde lisens(er) som ikke var kompatible med GPL som er veldig utbredt i open source verden.

[efikkan]

Her er litt lesestoff til deg på sengen efikkan.

Jeg reagerer på medienes(inkl. HW) misledende fremstilling av problemet som fremstiller dette som en lekkasje av sensitiv informasjon, når det tvert imot er snakk om en alvorlig sårbarhet som teoretisk kan gi begrenset lekkasje med mindre noen har fysisk tilgang på trafikken. Dette er selvsagt et alvorlig problem som skal adresseres umiddelbart av alle systemadministratorer, men det er ingen grunn til at mediene skal oppfordre alle til å bytte passord som følge av dette. Minst 99.999% av passordene har ikke vært kompromittert, så det er bare tullete å skape massehysteri når vi har langt større sikkerhetstrusler i dag. Som sagt, Heartbleed skal løses av administratorer, og brukere skal kun gjøre noe om de får beskjed fra tjenestetilbydere.

[ShadowMaster]

Mediene, unisont, sammen med sikkerhetsforskerne, og alle andre sikkerhetsrelaterte kilder, unisont, påpeker at lekkasje av sensitiv informasjon er problemet. Det er lekkasje av sensitiv informasjon som _er_ exploiten, mens du later til å tro at bivirkningen av exploiten, altså muligheten for å gjennomføre et MITM angrep med gyldige SSL sertifikat er sikkerhetshullet.

 

Som tsken2k sier så anbefaler jeg at du faktisk leser det som står på http://heartbleed.com/ som er hovedkilden til _gyldig_ informasjon, hvor det også bekreftes at de var i stand til, utenifra nettverket, uten å bruke MITM angrep, uten fysisk tilgang osv, hente ut sensitiv informasjon i form av brukernavn, passord, dokumenter, epost, im osv osv. Jeg, i likhet med veldig mange andre har bekreftet at dette er tilfellet ved å selv hente ut tilsvarende informasjon fra egne tjenere.

 

Med mindre du kan komme med noen kilder som motsier de som rapporterte heartbleed, de som har bekreftet at heartbleed virker, nasjonale sikkerhetsinstanser rundt om kring i verden osv, så foreslår jeg du slutter å spre disinformasjon.

 

Her har du forøvrig ytterligere kilder som bekrefter hva den offisielle kunngjøringssiden sier, som du mener ikke er mulig:

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

http://www.ubuntu.com/usn/usn-2165-1/

https://www.nsm.stat.no/Arbeidsomrader/Internettsikkerhet-NorCERT/Forsideartikler-NorCERT/Alvorlig-sarbarhet-i-SSL/

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

https://www.cert.se/2014/04/ny-sarbarhet-i-openssl-1-0-1

 

Samtlige av disse kildene sier klart og tydelig det motsatte av det du påstår.

 

Om du framdeles ønsker å fortsette ditt ensomme korstog mot verifiserte fakta så er man vel ned på et nivå hvor man bare troller.

[endrebjo]

Kjenner ikke så godt til detaljene rundt det, men vil anta at det har sammenheng med at de i lengre tid hadde lisens(er) som ikke var kompatible med GPL som er veldig utbredt i open source verden.

OpenSSL er heller ikke kompatibel med GPL. For meg ser det faktisk ut til at NSS-lisensen(e) er mer kompatible med GPL enn det OpenSSL-lisensen er.

[efikkan]

ShadowMasgter, det er på tide at du forstår at det er svært små mengder med informasjon som hentes ut på denne måten, og du vet om du tenker deg om at tjenester med stor trafikk som f.eks. facebook vil ha enormt mye data i minnet som ikke er passord. Matematikken blir da at angriperen må sende ikke bare tusenvis, men titusenvis eller mer pakker i gjennomsnitt per passord, som betyr en enorm trafikk mot serveren. Store tjenester som dette skal kjøre ratelimiting på slik trafikk som gjør det svært tidkrevente å få tak i mye informasjon. Så derfor er det urimelig å tro at millioner av passord kan ha kommet på avveie fra viktige tjenester som følge av dette. Med mindre du klarer å bevise at noen har utnyttet dette i månedsvis eller mer så blir det riktig å konkludere med at store datamengder ikke har kommet på avveie. (selvsagt er det alvorlig om tjenester ikke oppgraderer og lar sårbarheten være for fremtiden)

 

For å sette ting i perspektiv vil jeg minne f.eks. om Apples storlekkasje og en liten oversikt her over historiske lekkasjer det siste tiåret. Dette er lekkasjer som faktisk skal ha skjedd, mens heartbleed blir en sikkerhetsrisiko som kan inntreffe. Du må forstå forskjellen på potensiell risiko og faktiske hendelser. For forbrukere er det ingen tvil om at slike hendelser har hatt mye større innvirkning enn det heartbleed har så langt.

[ShadowMaster]

Burde kanskje påpekt at NSS spesifikt har endret/lagt til en lisens spesifikt for å være kompatibel med GPL

 

Når det gjelder OpenSSL så er denne interessant https://www.openssl.org/support/faq.html#LEGAL2

Så meningene er litt delt på den biten, men det virker som om det er hardcore opensource folka som mener det ikke er lov, mens det i de fleste tilfeller blir brukt.

[efikkan]

Burde kanskje påpekt at NSS spesifikt har endret/lagt til en lisens spesifikt for å være kompatibel med GPL

 

Når det gjelder OpenSSL så er denne interessant https://www.openssl.org/support/faq.html#LEGAL2

Så meningene er litt delt på den biten, men det virker som om det er hardcore opensource folka som mener det ikke er lov, mens det i de fleste tilfeller blir brukt.

Det er mye hardnakkede open source-folk hevder som ikke er jus, og det er slik forvirring som gjør at mange dessverre får fordommer mot fri og åpen kode. Noen ting er i gråsoner, men det vanlig sikre som mange gjør er å lage en generalisert wrapper rundt biblioteket, og da vil de være på trygg juridisk grunn. Selv om GPL er laget med gode intensjoner så får det altså uheldige konsekvenser med konflikter med andre frie lisenser.

[ShadowMaster]

ShadowMasgter, det er på tide at du forstår at det er svært små mengder med informasjon som hentes ut på denne måten, og du vet om du tenker deg om at tjenester med stor trafikk som f.eks. facebook vil ha enormt mye data i minnet som ikke er passord. Matematikken blir da at angriperen må sende ikke bare tusenvis, men titusenvis eller mer pakker i gjennomsnitt per passord, som betyr en enorm trafikk mot serveren. Store tjenester som dette skal kjøre ratelimiting på slik trafikk som gjør det svært tidkrevente å få tak i mye informasjon. Så derfor er det urimelig å tro at millioner av passord kan ha kommet på avveie fra viktige tjenester som følge av dette. Med mindre du klarer å bevise at noen har utnyttet dette i månedsvis eller mer så blir det riktig å konkludere med at store datamengder ikke har kommet på avveie. (selvsagt er det alvorlig om tjenester ikke oppgraderer og lar sårbarheten være for fremtiden)

 

Dette blir mitt siste innlegg på denne saken, men merker meg nok en gang at du ikke kan henvise til en eneste kilde som støtter ditt syn på saken.

 

Du fortsetter å hevde at det er små menger med informasjon, men påstår samtidig at det vil gå enorme mengder trafikk mot serveren, og at ratelimiting skal kunne stoppe dette (som ingen visste om, og dermed ikke hadde noen form for regler mot). Noe skurrer i den påstanden.

 

Jeg hater denne typen argumentasjon, spesielt siden ingen side kan bevises per dags dato, men kan du bevise at det ikke har forekommet datalekkasjer? Ikke? Nettopp. Derfor jobber man ut i fra at det har skjedd og tar fornuftige steg for å sikre tjenestene sine, samt å sikre brukerne sine. Spesielt når man _VET_ at det store flertall av brukere benytter dårlige passord og gjerne bruker samme passord overalt. Det er i dette tilfellet bedre å overreagere enn å ikke reagere før det er for sent. Det vi derimot _VET_ med sikkerhet, og som jeg kan bevise siden jeg selv har gjennomført angrepet mot våre egne systemer, er at fra det øyeblikket sikkerhetshullet ble kjent, så har det blitt utnyttet.

 

Det er verdt å merke seg at man kun trenger å sende en forespørsel på 16kilobyte for å få tilbake 64kilobyte med minne. Om man har 20 klienter som står og går så gir dette 1,25 Megabyte med minneinnhold per sekund. På en travel tjener vil dette være en dråpe i havet blandt all annen data som sendes ut. Å laste ned hovedsiden på vg.no vil selv med adblock sende ut 2.3 Megabyte med trafikk. Om man holder på med dette over litt tid, og man antar at brukere logger inn inntil flere ganger per dag, så har man ganske stor sannsynlighet til å få ut data uten at det merkes.

 

Sannsynligheten for at dette har skjedd de siste to årene er små, men ikke umulig.

 

Det større problemet er at i dagene etter at dette ble kjent så har dette blitt utnyttet i det vide og det brede. Kun de aller største på nettet ble advart på forhånd. Debian brukte 3 1/2 time på å få sin sikkerhetsadvarsel ut til vår innboks. Det tok ytterligere tid før vi fikk stengt hullet. På denne tiden har vi fått verifisert at folk hadde brukt sikkerhetshullet til å hente ut brukernavn og passord for våre brukere takket være whitehats. Derfor kan vi si med veldig stor sikkerhet si at vi ble kompromittert i løpet av timene fra det ble kjent til vi i det hele tatt hadde mulighet til å lukke hullet.

 

Hva får deg til å tro at innen minutter fra dette ble kjent at sikkerhetshullet ikke ble tatt i bruk av folk med ondsinnede hensikter mot attraktive mål? Et angrep som ikke kunne detekteres, og framdeles kun kan detekteres via honeypots eller IDS/IPS ved å sammenligne innkommende og utgående pakkestørrelser. Hvor mange timer var tek nettverket og diskusjon sårbart og sannsynligvis under angrep før de fikk lukket hullet? Ett av norges mest attraktive mål på grunn av brukermasse, som også beleilig nok har byttet til epost som brukernavn som gjør lekkasjer enda mer alvorlig.

 

Vi lever i et fritt land, og man har lov til å mene og tro det man vil, men jeg vil framdeles anbefale folk til å stole på eksperter innen området i forhold til alvorligheten, framfor hva jeg eller andre forumbrukere måtte mene og tro.

Jeg synes personlig det er feil å angripe media for å spre misvisende informasjon, nå informasjonen som kommer fram (dog, i enkelte tilfeller litt misforstått eller forvridd) er basert på informasjon fra eksperter.

 

Holder verden på å falle i grus? Nei. Står internett i brann? Neppe. Men dette er langt mer alvorlig og latterlig simpelt å misbruke enn det du prøver å framstille det som.

[efikkan]

Du fortsetter å hevde at det er små menger med informasjon, men påstår samtidig at det vil gå enorme mengder trafikk mot serveren, og at ratelimiting skal kunne stoppe dette (som ingen visste om, og dermed ikke hadde noen form for regler mot). Noe skurrer i den påstanden.

 

Jeg hater denne typen argumentasjon, spesielt siden ingen side kan bevises per dags dato, men kan du bevise at det ikke har forekommet datalekkasjer? Ikke? Nettopp. Derfor jobber man ut i fra at det har skjedd og tar fornuftige steg for å sikre tjenestene sine, samt å sikre brukerne sine. Spesielt når man _VET_ at det store flertall av brukere benytter dårlige passord og gjerne bruker samme passord overalt. Det er i dette tilfellet bedre å overreagere enn å ikke reagere før det er for sent. Det vi derimot _VET_ med sikkerhet, og som jeg kan bevise siden jeg selv har gjennomført angrepet mot våre egne systemer, er at fra det øyeblikket sikkerhetshullet ble kjent, så har det blitt utnyttet.

Du har ennå ikke klart å forstå poenget. Selv om vi antar at folk har prøvd å utnytte dette denne uken siden det ble kjent så er det begrenset med informasjon som kan hentes ut fra store tjenester som facebook og google på et så kort tidsrom(altså til de ble patchet). Hvis du må ha titusener av pakker per vellykkede passord så blir dette en soldi andel trafikk på kort tid, for du vil trenge millioner for å få ut store mengder data. Tjenester som Google og Facebook som har gode rutiner merker seg dersom det kommer unormalt med pakker fra noen få klienter, selv om de ikke vet hva de leter etter. Derfor vil slike ting som dette dukke opp som advarsler eller hopp i grafer. Det er fullt mulig å analysere trafikkmønster og oppdage slike avvik raskt. For å unngå oppdagelser må enten trafikken fordeles over lange tidsrom eller over et stort antall klienter som et botnett.

 

Selv om Google ikke har overvåket innholdet i slike pakker så registrerer de alltid hvor folk logger seg inn fra. Dette overvåker de nøye, og hadde merket ekstremt raskt dersom plutselig et stort antall kontoer ble innlogget fra andre steder. Siden dette ikke har hendt så er det rimelig å konkludere med at det ikke har vært en stor lekkasje der så langt. Selvsagt er én konto på avveie uakseptabelt, men du må sammenligne dette med store lekkasjer som stadig skjer og da blir heartbleed ingen katastrofe så langt. Sannsynligheten for at folk utnytter alle de andre lekkasjene er mye større, derfor har heartbleed fått ufortjent mye oppmerksomhet.

 

Merk at jeg er enig i at heartbleed er alvorlig og har potensiale (enten over tid eller ved fysisk kontakt), men at vi har større problemer.

[Sokkalf™]

Glem nå Google og Facebook, deres trafikkmønster er ikke akkurat normen. Finnes hundretusenvis av andre servere, som tar imot både kredittkortnumre og brukernavn og passord. Der jeg jobber har vi en tjeneste som kun håndterer brukertilganger og kredittkortbetalinger. Sannsynligheten for at man kunne finne "snacks" i minnet er var potensielt ganske høy, for å si det slik.

 

Finnes masse andre tjenester som har hovedvekt av "innloggingstrafikk", ta f.eks Difis "IDporten".

 

Dette var rett og slett krise.

[ShadowMaster]

Ikke uventet har NSA visst om og benyttet denne svakheten i minst to år.

http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html

 

Skal overraske meg stort at ikke en eneste blackhat blant alle som følger med på comitts til software som OpenSSL ikke har snappet opp dette på samme måte og brukt det.

 

Derimot er det ting som tyder på at det er ekstremt vanskelig å få tak i den private nøkkelen til tjenester siden det er noe av det aller første som blir lastet inn og måten minne blir håndtert på, noe som gjør bieffekten av sikkerhetshullet mye mindre sannsynlig, altså MITM angrep med gyldig SSL nøkkel.

Endret 11. april 2014 av ShadowMaster