I dagarna har det kommit fram att den mycket vanliga krypteringspaketet OpenSSL sedan 2011 har haft en katastrofal säkerhetslucka, som gjort att en angripare kan läsa information i en servers minne. Luckan kallas heartbleed. Enkelt uttryckt så bör man byta lösenord och krypteringscertifikat på alla tjänster som använt OpenSSL de senaste åren, efter att respektive tjänst uppgraderas till en buggfriare version.
Det finns naturligtvis inga belägg för i vilken omfattning säkerhetsluckan missbrukats, men bland annat kan i teorin signalspaningsorganisationer som NSA eller FRA hämtat ut servercertifikat från drabbade tjänster och utfört man-in-the-middle-attacker, där man alltså helt och fullt kan omdirigera trafik via en egen server och avlyssna all trafik. Man kan också hämtat ut användares lösenord.
Även Tor-projektet verkar ha drabbats, vilket gör att t ex NSA eller FRA (eller någon svart hatt-hackare) kunnat sätta upp en Tor-nod och avlyssna all trafik som passerar genom noden, inte bara exittrafik. Och Tor-användare brukar anse sig ha något att dölja. Faktum är att det Tor måste varit mycket enkelt att avlyssna via heartbleed.
Den skada som eventuellt skett har redan inträffat. Vad man kan och bör göra är att byta alla sina lösenord, och om man driver en server, även byta ut alla servercertifikat, när buggen har fixats på berörda servrar. Dina lösenord kan vara på drift, eller i FRA:s, GCHQ:s eller NSA:s ägo, så myndigheterna när helst de har lust kan logga in t ex på din mail…
OpenSSL används för övrigt inte bara för webtrafik, utan kan också användas för krypterad överföring av mail (ej att blanda ihop med krypterade mail).
Den renommerade kryptoexperten Bruce Schneier kallar buggen för “en elva på en tiogradig skala” och svenska säkerhetsexperter jag kommunicerat med håller med. Schneier spekulerar i huruvida heartbleed lagts in i koden för OpenSSL avsiktligt.
“At this point, the probability is close to one that every target has had its private keys extracted by multiple intelligence agencies. The real question is whether or not someone deliberately inserted this bug into OpenSSL, and has had two years of unfettered access to everything.”
Över en halv miljon servrar är drabbade och har under två år alltså kunnat ge full tillgång åt de som nyttjat buggen.
Bland drabbade webplatser hittar man t ex Yahoo, Flicker, Imgur, Slate och diverse datingsajter mfl. Jag har inte hittat någon lista på svenska sajter än, och i takt med att de uppgraderas är en sådan lista svår att skapa, så omfattningen av tidigare drabbade sajter är okänd. En sajt som uppgraderat eller bytt ut OpenSSL mot någon annan lösning, men har kvar sina servercertifikat är fortfarande sårbar.
37 kommentarer
Man måste också dra tillbaka tidigare utställda certifikat (crl revoke) annars kan nedladdade cert användas av tredje part för att köra lite man-in-the-middle
Tydligen klarade sig OpenSSH eftersom den inte använder de heartbeats som var utsatta.
Hur är det med google och facebook? Någon som vet?
Openssl används inte till lösenord, utan till att kryptera trafik.
Lösenord är oftast hashade och påverkas därför inte av detta
Du blandar ihop äpplen och bananer. Heartbleed gör att en angripare kan läsa ditt lösenord när det skickas till servern eller ligger i serverns minne för behandling.
Det minne som går att läsa ut torde begränsas av serverprocessens allokerade minne. Således borde det bara vara om man just connectat som man finns där. Efter att serverprocessen forkat återanvänds väl minnet (kanske till slut) och då skrivs det förhoppningsvis över. Å andra sidan är t.ex. sshd väldigt liten så minnet man råkar få tag i är troligtvis väldigt relevant, om man lyckas avkoda det.
Den här kommentaren har tagits bort av skribenten.
ivl du har fel. Det som syns är HTTP förförfågan vilket inner håller vid inloggning lösenord och användarnamn. Vid en redan inloggad användare ser man denna persons kakor och kan helt enkelt koperia alla kakor (som innhåller session-id) och vipps är man inne. Det spelar ingen roll om du jobbar med detta om du har fel i det du säger.
Människa: Man skickar inte lösenord i klartext i HTTP förfrågan, man skickar en hash på sitt lösenord+salt. Det spelar ingen roll om du kan se vad som skickas, såvida du inte samlat in ett par terrabyte med data (från en användare) så kommer du inte att kunna knäcka det.
DÄREMOT, så medger jag att jag har fel. För det visade sig att "heartbleed" är en buffer overflow exploit vilket gör att man kommer åt datat på servern, och då är man ganska rökt. (Obs, lösenorden sparas fortfarande dock inte i klartext, om man inte använder en tjänst som är skriven av inkompetenta idioter)
ivl, när du loggar in på en hemsida skickas lösenorden i klartext till servern. Det spelar ingen roll om de skickas över en krypterad anslutning då man genom Hearbleed får tillgång till den avkrypterade httpförfråningen. Lösenordet hashas och saltas på serversidan och jämförs med det i databasen. Det spelar ingen roll och du hashar innan du skickar, då en illvillig hackare kan skicka samma hash till servern också.
Människa: Jag är ledsen, men du vet verkligen inte vad du pratar om. Vad skulle vitsen vara med att skicka lösenordet i klartext för att sedan hasha och salta det? Man hashar och saltar lösenord just för att man inte ska kunna avlyssna dom eller kopiera en förfrågan och skicka om den.
Kan ge ditt ett kort exempel så kanske du förstår
1. Du har ett lösenord: "mittlösenord".
2. Du börjar logga in på en sida.
3. Klienten (din dator) hashar "mittlösenord" med en random salt "HmNhMHmjkfak", alltså, du hashar "mittlösenordHmNhMHmjkfak" = "e19668ad6e6fc8665c97c550fa13238e"
4. Hashen du skickar = e19668ad6e6fc8665c97c550fa13238e, du skickar den tillsammans med "HmNhMHmjkfak"
5. Servern tar emot datat. Servern har ditt lösenord i databasen "mittlösenord", och den hashar det tillsammans med "HmNhMHmjkfak" och jämför resultatet mot hashen du skickade. Om resultatet stämmer överens = du är inloggad.
(Exemplet är förenklat med klartextlösenord)
Om du nu avlyssnar denna trafik så kommer du att få 2 st data
hashen "e19668ad6e6fc8665c97c550fa13238e" och salten: "HmNhMHmjkfak".
Salten går inte att återanvända igen = du kan inte bara kopiera datat och skicka det igen.
= du kan inte göra ett skit.
Ivl: alla som någonsin byggt en webbtjänst vet att du har fel. Man kan såklart hasha på klientsidan med tex JavaScript i browser om man vill det. Det är dock inte praxis. Lösenord skickas i klartext. De lagras i databasen hastade just för att man aldrig vill spara lösenord i klartext. Sajter som lagrar lösenord i klartext är dumma i huvudet, milt sagt. Det är mycket enkelt att testa också. Logga in på tex Facebook utan https och kolla paketen med wireshark.
Det man är rädd för med klartextlösenord är ju som bekant sql-injektioner som genom åren läckt många lösenord, dock oftast hastade sådana. Dessa måste sedan bruteforceas för att få fram lösenordet i klartext, vilket i praktiken inte går om man har ett bra lösenord.
Hashade ska det ju stå, inte hastade.
Du bör nog läsa på innan du jobbar vidare, tex någon trevlig tråd på stackoverflow. http://stackoverflow.com/questions/146146/is-my-form-password-being-passed-in-clear-text
Otto:
Jag jobbar med att programmera nätverksinfrastruktur, dvs routrar och andra typer av burkar. Vi har rätt hög krav på säkerhet och jobbar mycket med just autentisering.
Jag körde lite firebug mot google/facebook och Du och "människa" har helt rätt. Det visar sig att webb autentisering är helt åt helvete, jag trodde att OAuth och liknande teknologier löst detta för länge sedan, men har tydligen helt fel.
Från mitt perspektiv är detta verkligen ett skämt, framförallt att inte ens google eller facebook gör detta ordentligt.
Hur skulle det göras bättre menar du? Oavsett om du hashar på klienten vet ju jag exakt hur hashingsalgoritmen ser ut genom att jag får samma HTML och javascript som alla andra. Så jag kan få orginal hashen, och knäcka den så, eller kan jag bara skicka den hashen jag fick gneom att sniffa och återanvända denna.
Det är ju detta OpenSSL är till för. Kryptera anslutningen så är detta inget problem.
Människa, kolla på mitt exempel ovan, det är så alla lite "bättre" autentiserings-algoritmer fungerar.
Det gör inget att algoritmen är känd, fördelen med hashar är att de är envägs. Kryptering å andra sidan är ju 2 väg, eftersom det är gjort för att kunna avkrypteras, vilket också är varför man inte ska använda kryptering till autentisering.
Du kan även söka på "HMAC" vilket är det som jag beskrivit (förenklat)
Men hashen är ju samma. Det är ju bara att generera en egen salt enligt ditt exempel och logga in. Dessutom lagrar ditt exempel lösenordet i klartext.
Och algoritmen för att generera salt ligger i javascript = öppet för alla.
Man kan sammanfatta med: oavsett vad du skickar för att logga in så går det att kopiera och göra om. Annars skulle inte den rättmätige individen kunna göra om det. Ren logik. Om in det görs krypterat, tex med SSL där nycklarna är okända för man-in-The-middle.
Nån typ av challenge-response protokoll vid inloggning skulle väl mitigera sådan kopiering avsevärt? Challengen är väl bara giltig en gång och under en väldigt begränsad tid rimligen?
Otto, du har inte förstått exemplet.
Ja,man genererar en egen salt vilket är meningen. Men lösenordet har bara du och servern. Därför kan ingen utomstående generera samma hash.
Jag skrev att exemplet var förenklat, jag valde att inte göra det för komplicerat för att ni skulle förstå.
Det jag har läst är att man lyckats få ut användaruppgifter från servrar också. Det innebär i praktiken att man får ut passwordfilen vilket inte är så lyckat för de som sitter med lösenord som "Hello123" och liknande (användarnamnet finns i klartext så det är bara att leta upp vem som har det lösenordet).
Det finns med andra ord ett och annat sätt som en angripare kan komma åt mer från användarna…
Ja, man kan ju skippa lösenorden och ta sessions-cookie:n direkt. Så slipper man lösenord och hashar etc och är inne på 2 minuter
Ja, men alla vet väl att idag kör man med penna och papper och kurirer. Inget bolag, ingen nation bör använda datorer. OK, Nisses städs bokföring funkar väl. Men annars, no data plese! Alla bör omedelbart få skyddad identitet, IT bolagen som messat up bör konkas och allt tas ifrån de som är ansvariga, här kör vi fascism, ty det är , ja, fundera ut det du, förräderi av ngn form iaf. Pengarna tillbaka, annars fängesle tills de är tillbaka. Nej, jag trivs inte som icke-kriminell på ngt sätt här, och med kriminella räknar jag de flesta, de gör inte det som ålags dem, med heder och så, så slutar man, man slutar köra datasystem, man gör det rätyta, oavsett kostanden!
Den här kommentaren har tagits bort av skribenten.
Det här kvalar väl in som Svart Svan?
Det lustiga tycks vara att de som haft äldre versioner av OpenSSL inte drabbats(?).
Så mycket för tjatet om att det är säkrast att uppgradera…
Mina servrar har inte påverkats över huvud taget eftersom jag körde äldre versioner. Praktiskt.
@viktualiebroder
Då betyder det ju att säkerhetshålet introducerats och inte bara varit där från början. Skulle vara intressant att se när det introducerades och framförallt vem som gjorde ändringen.
Var det inte relativt nyligen någon annan säkerhetsbrist uppmärksammades (i apples? kod) som berodde på att någon "slarvat" i samband med mergning?
En dator som är kopplad mot internet är aldrig 100% säker!
Även om man har världens bästa säkerhetslösning och långa lösenord kan det finnas säkerhål som i fallet med OpenSSL/Hearbleed.
Viktig info som inte får hamna i fel händer bör man alltså spara på en dator som alltid lever offline.
@Alex The Great
Och en dator som inte är kopplad mot internet är heller aldrig 100% säker. Det finns alltid andra sätt än via internet för att angripa ett system eller komma åt känslig information.
Det verkar finnas mkt kunskap här… Hur påverkas en "vanlig" människa? Vad kan/bör jag göra?
Byt dina lösenord, och bra lösenord med mer än 8 tecken, stora små bokstäver och siffror. Detta bör upprepas regelbundet med eller utan nyheter om säkerhetsluckor.
Det har varit allmänt känt i nästan 10 år att NSA och deras kompisar har kunnat avlyssna SSL-kommunikation som baseras på "allmänt betrodda" CA-certifikat (certificate authority). Bl.a. Slashdot rapporterade då om ett amerikanskt företag som till statliga myndigheter sålda lådor specialiserade på detta, även om företaget efter att själva ha publicerat informationen efteråt försökte mörka det.
Hur? Hota, muta eller rekrytera från insidan så någon allmänt betrodd CA kan utfärda falska certifikat för kända siter. Sedan är det bara att någonstans längs kablarna (eller om man förfalskar DNS-svar) läsa eller manipulera kommunikationen, kryptera om den och sända vidare kommunikationen till den site som användaren (trygg med att se krypteringsikonen) från första början trodde att de hade en ostörd kommunikation med.
Så tillvida tillför Heartbleed alltså begränsat med ny förmåga till stora amerikanska myndigheter, vad gäller icke riktad övervakning.