kramselund jereminsen

Opdater OpenSSL - og dit OS nu

Af 26

Så kom der endnu en SSL fejl, denne gang i OpenSSL. Se straks http://heartbleed.com/ og specielt

What versions of the OpenSSL are affected?
Status of different versions:
OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable
Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

Har du en af de sårbare versioner, så gå igang med at opdatere nu - stop med at læse, smut!

Det er en alvorlig sårbarhed som gør at man kan læse hukommelsen, og derved bliver mange andre ting i hukommelsen potentielt opsnappet. Det betyder at du udover at opdatere skal skifte nøgler og det bliver en ordentligt omgang!

Fakta og tips

SSH er ikke sårbar, iflg. Theo de Raadt, se https://twitter.com/openbsdjournal/status/453425522425733120 "Noting also that OpenSSH is not affected"

Der er også binære patches til OpenBSD, hvis man bruger det https://twitter.com/mtierltd/status/453437410035388416

Dit favoritoperativsystem bør have opdateringer, ellers er de ved at blive kompileret.

Pas på under opgradering

Jakob Schlyter som er specialist på blandt andet DNSSEC og DANE gør opmærksom på at man lige skal passe på:
"Don't forget to update your TLSA records (at wait for TTL to expire) before you rekey #heartbleed"
https://twitter.com/jschlyter/status/453438431184834560

Så vær opmærksom og skift nøgler kontrolleret, noter gerne at du skal implementere mere automatik til næste gang.

Kom ind i kampen!

Hvornår har du sidst efterset dine SSL indstillinger?

Det er en udmærket årsag til lige at se på dine indstillinger for SSL/TLS. Du BØR idag i 2014 bruge PFS Perfect Forward Secrecy - det betyder blandt andet at hvis folk HAR fået fat på dine private nøgler er tidligere kommunikation stadig sikker. Jeg anbefaler at du tester dine web servere jævnligt med https://www.ssllabs.com/ssltest/

Jeg vil måske opdatere lidt i løbet af dagen, men har også selv en udfordring med at lokalisere sårbare maskiner og gå det hele efter :-( Hvis du er utålmodig så søg på Twitter eller se hvad jeg har retweetet hidtil.

Proof of Concept

Der er allerede flere testsider og værktøjer ude til at teste for dette - udover at du kan logge ind på serveren og checke OpenSSL versionen.

NB: check selv hvad du stoler på! Jeg har ikke prøvet dem allesammen, ej heller læst dem nøje!

Gætter på at sites som https://www.ssllabs.com/ssltest/ også hurtigt får inkluderet en test af det - de tilføjede igår aftes.

Analyser og andet

Konklusionen på igår er, så vidt jeg kan se:

  • 100.000vis af servere er sårbare overfor dette, se blandt andet listerne på https://github.com/musalbas/heartbleed-masstest
  • Store sites som Yahoo.com, Flickr, FBI osv. er ramt
  • Har du haft en server som var sårbar bør du skifte private key på SSL og få et nyt certifikat, Jeg køber gerne hos Larsen Data fordi de har konkurrencedygtige priser https://www.digitaltcertifikat.dk/ potentielt sparer du 10.000vis af kroner! NB: med DANE implementeret ville det kun koste dine egne ressourcer at skifte certs!
  • I Norge er der aktiv scanning igang og både HTTPS sites og mail servere har været ramt, dagens stat siger (tweet ca kl 8) "I've now completed checking STARTTLS mail servers: 11% still vulnerable." https://twitter.com/einaros/status/453773598172663808 . Jeg er ikke bekendt med danskere der pt. scanner, men hvis nogen har lyst, så kontakt mig off-list.

Good stuff

  • Jeg havde et par servere som ikke havde nyeste OpenSSL - en del ældre men stadig supporterede distributioner
  • OpenSSH er ikke ramt - men hvad hvis den var? Læs gerne Theos email https://www.mail-archive.com/tech@openbsd.org/msg17412.html# og støt Open Source med penge, penge som kan bruges til at betale audit. Jeg donerer til OpenBSD, OpenSSH og har tidligere opsporet software som Sudo og betalt til dem.

Donate FFS!

Det er helt tydeligt at Open Software ikke på magisk vis er sikkert, og det er ikke alle der har evnerne til at finde softwarefejl. Hvis du ligesom mig bruger kritiske værktøjer som OpenSSL, OpenSSH, OpenBSD, Linux mv. så synes jeg du skal finde lidt mønter og smide efter projekterne.

  • http://www.sudo.ws/sudo/sudo.html der er en donate knap. Jeg bruger sudo på hveranden kommando jeg udfører i vores produktion, så visse dage er det vel flere 100 gange jeg bruger sudo - på en dag
  • OpenSSH/OpenBSD - uanset om du synes Theo er en drama queen så er det fakta at OpenBSD projektet er ophav til mange af sikkerhedsteknologier som vi bruger idag.

Linux folk, kom gerne med PaX og andre teknologier og links som I synes er relevante her.

På Twitter siges det at heartbleed har resulteret i $15k donation til @freedomofpress, wauw!

This is amazing, @neelmehta, the Google engineer who discovered #heartbleed gave his $15k bounty to @FreedomOfPress. Hats off.

https://twitter.com/fredericjacobs/status/453676701973630976

Opdateret: 9. april 08:34

Kommentarer (26)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Deleted User

Hvornår har du sidst efterset dine SSL indstillinger?

Kære Henrik - kan du ikke lokkes til at stille dette spørgsmål til folkene bag borger.dk (foretrækker RC4-"kryptering", understøtter usikker genforhandling, understøtter ikke forward secrecy, understøtter kun TLS 1.0), Danske Bank (foretrækker RC4-"kryptering", understøtter kun TLS 1.0, understøtter ikke forward secrecy) og e-boks (foretrækker RC4-"kryptering", understøtter ikke forward secrecy)?

  • 10
  • 0
#4 Jacob Nordfalk

$ sudo apt-get update; sudo apt-get upgrade

Læser tilstandsoplysninger... Færdig Følgende pakker vil blive opgraderet: file gir1.2-gudev-1.0 icedtea-6-jre-cacao icedtea-6-jre-jamvm libgudev-1.0-0 libmagic1 libpam-systemd libssl1.0.0 libssl1.0.0:i386 libsystemd-daemon0 libsystemd-journal0 libsystemd-login0 libudev1 libudev1:i386 libvirt0 ...

Så min desktop-Ubuntu (sat til ugentlige opdateringer) var vist sårbar (?).

Hvad er - konkret - risikoen for en desktop-Ubuntu-PC ?

  • 1
  • 0
#6 Jacob Rasmussen

Så vidt jeg kan se, bruger hverken version2.dk eller ing.dk SSL på deres forum login.

Jeg bruger Facebook connect metoden til at logge ind begge steder. Hvor godt er jeg så beskyttet? Det værste der kan ske, er vel et session hi-jack, hvor andre kan skrive som 'mig' her i kommentarfeltet.

Hvordan logger bloggerne ind? Er HLK og PHK's passwords ude og svømme i cyberspace?

  • 1
  • 0
#8 Mike Mikjær Blogger

jvfr. http://www.debian.org/security/2014/dsa-2896

"The oldstable distribution (squeeze) is not affected by this vulnerability."

Alligevel fik jeg at vise fra filippo.io at en af mine Debian Squeeze kasser (fuldt opdateret iht. apt) var sårbar ... 10 minutter efter (uden at have ændret noget) får jeg at vide at samme maskine IKKE er sårbar, jeg tror måske ikke Filippo.io er den mest troværdige test-metrics at bruge :)

  • 0
  • 0
#11 Lars Sommer

Tak Henrik! Alle råber at vi skal opgradere OpenSSL nu, men hvor meget mere skal vi efterse?

Sårbarheden har tilladt angribere at læse hukommelsen af hvor meget? Den service der har kørt med OpenSSL? Altså webserveren, mailserveren mm.?

Så de SSL-specifikke ting som certifikater bør fornyes, ikke? Autentifikationsoplysninger der har strømmet gennem SSL-linjen, som web logins, mail credentials og lign.?

Og så en generel bevidsthed om, at al data, der har været transmitteret via SSL-linjen, kan være opsnappet.

Men ikke mere end det? - Ikke SSH-nøgler, root-passwords osv. vel?

  • 0
  • 0
#12 Lars Sommer

Tak Henrik! Alle råber at vi skal opgradere OpenSSL nu, men hvor meget mere skal vi efterse?

Sårbarheden har tilladt angribere at læse hukommelsen af hvor meget? Den service der har kørt med OpenSSL? Altså webserveren, mailserveren mm.?

Så de SSL-specifikke ting som certifikater bør fornyes, ikke? Autentifikationsoplysninger der har strømmet gennem SSL-linjen, som web logins, mail credentials og lign.?

Og så en generel bevidsthed om, at al data, der har været transmitteret via SSL-linjen, kan være opsnappet.

Men ikke mere end det? - Ikke SSH-nøgler, root-passwords osv. vel?

  • 0
  • 0
#14 Henrik Kramselund Jereminsen Blogger

Alle råber at vi skal opgradere OpenSSL nu, men hvor meget mere skal vi efterse?

Sårbarheden har tilladt angribere at læse hukommelsen af hvor meget? Den service der har kørt med OpenSSL? Altså webserveren, mailserveren mm.?

Så de SSL-specifikke ting som certifikater bør fornyes, ikke? Autentifikationsoplysninger der har strømmet gennem SSL-linjen, som web logins, mail credentials og lign.?

Og så en generel bevidsthed om, at al data, der har været transmitteret via SSL-linjen, kan være opsnappet.

Men ikke mere end det? - Ikke SSH-nøgler, root-passwords osv. vel?

Alt for mange spørgsmål på en gang, men du skal være passende paranoid.

Er det let, så gør det - nye keys+cert til dine services er nemme at lave, men kan koste lidt. Samme med SSH host keys, slet og lav nye. osv.

Mht. data sendt via SSL, hvis du bruger Perfect Forward Secrecy http://en.wikipedia.org/wiki/Perfect_forward_secrecy så er tidligere sessioner stadig sikre - derfor det STRAKS anbefales at slå det til. Det er også noget man bør slå til på IPsec VPN og andre VPNS, hvis de understøtter.

Så hvis du har en formodning om at din SSL trafik (uden PFS) er opsnappet og afkodet, så vil dine logins også kræve reset.

Din private SSH nøgle bør være sikker, hvis den er på en enhed som ikke kører eksempelvis en web server - den bør ligge på din laptop uden ekstra services/med en god firewall. Håber det gav lidt input.

NB: der er ikke så mange der snakker om hvor og hvordan man laver gode nøgler. Jeg vil anbefale OpenBSD som operativsystem og man kunne sagtens dedikere en ældre laptop til at være DER man laver keys, og så evt. bruge HSM http://en.wikipedia.org/wiki/Hardware_security_module - de findes i forskellige udgaver og vil gøre det svært at opsnappe nøgler på samme måde.

og et link jeg burde have sat ind er også https://bettercrypto.org/

  • 2
  • 0
#16 Henrik Kramselund Jereminsen Blogger

Er det rigtigt forstået at SSHv2 automatisk bruger PFS?

Tak for det spørgsmål, det måtte straks undersøges.

Jeg fandt et mere eller mindre tilfældigt link, http://utcc.utoronto.ca/~cks/space/blog/tech/SshForwardSecrecy

In version 1 of the SSH protocol, PFS is achieved by using the second, ephemeral set of host keys.

men F det, for vi bruger ikke SSHv1 mere - VEL!

So how does SSH v2 achieve (perfect) forward security?

It turns out that the answer is in RFC 4251's section 9.3.7: SSH v2 normally uses Diffie-Hellman key exchange to set up the session keys, which inherently provides perfect forward security without needing a second set of host keys or anything like that.

Jeg kiggede lidt i RFC'en - http://www.ietf.org/rfc/rfc4251.txt - og der står lidt mere, men også brugen af ordet "may" deri gør mig lidt usikker, jeg tror dog vi er på sikker grund. Linket fra Theo de Raadt ovenfor i indlægget peger også i den retning.

"It should be noted that the Diffie-Hellman key exchanges may provide perfect forward secrecy (PFS)."

  • 3
  • 0
#18 Kristian Larsen

Bare for god ordens skyld: jeg plejer at bestille SSL certs (og domæner) via GratisDNS siden - det er stadig Larsen data, men er min måde at støtte GratisDNS på og vise at det giver mening at fastholde servicen.

  • 0
  • 0
#20 Lasse Hillerøe Petersen

Jeg vil ikke prale af at besidde de store krypto-kundskaber, så tilgiv mig hvis svaret burde være indlysende.

Men givet at masser af browsere vist bruger OpenSSL på diverse platforme, kunne jeg forestille mig at en HTTPS-webserver indrettet på (u)passende vis, kunne anvendes til at hive private data ud af klienter (browsere). Det forudsætter dog, at det er begge sider af en SSL-forbindelse, der kan sende heartbeat requests. Jeg har kigget på RFC 6520, og kan ikke umiddelbart se at dette ikke skulle være muligt, selv om det nok er en mere hypotetisk angrebsvinkel...

  • 1
  • 0
#21 Henrik Kramselund Jereminsen Blogger

Kvaliteten har været diskuteret vidt og bredt.

Jeg tror et basalt problem er at OpenSSL skal understøtte ALLES behov for ALTING. Det betyder mange kodelinier, gamle algoritmer der burde være fjernet, kompleksitet for at imødegå alle trusler osv.

Det betyder at man starter med simple kodestumper, som så skal væves sammen til et tæppe der kan bruges på stranden og i Tibet! Så ja, OpenSSL er formentlig ikke smukt eller nemt at forstå. Til gengæld, vil du stole på et mindre brugt cryptobibliotek udviklet af nogle andre (amatører), som ikke bruges til så mange produkter?

Det kunne være dejligt hvis OpenSSL fik en "updated paranoia core" version, med KUN stærke algoritmer, minimal kode, få muligheder og færre options. ahf gav mig forøvrigt link til noget smukt, som jeg bliver nødt til at dele: http://golang.org/src/pkg/crypto/subtle/constant_time.go

altså funktioner som altid kører i konstant tid, og dermed ikke lækker nøgler/bits fra nøgler. Det er bare een af måderne cryptokode kan angribes på, som kræver omhyggelig programmering.

  • 3
  • 0
#22 Lars Kr. Lundin

$ sudo apt-get update; sudo apt-get upgrade

Apropos web-sikkerhed så vil jeg lige påpege at det er farligt bare at copy-paste html (når man ikke stoler på forfatteren) direkte ind på kommandolinjen:

http://thejh.net/misc/website-terminal-copy-paste

Istedet kopierer jeg først teksten ind i en editor, og når jeg så kan se at den er uskadelig, så kopierer jeg den ind på kommandolinjen.

  • 1
  • 0
#24 Jimmy Christiansen

$ sudo apt-get update; sudo apt-get upgrade

Læser tilstandsoplysninger... Færdig Følgende pakker vil blive opgraderet: file gir1.2-gudev-1.0 icedtea-6-jre-cacao icedtea-6-jre-jamvm libgudev-1.0-0 libmagic1 libpam-systemd libssl1.0.0 libssl1.0.0:i386 libsystemd-daemon0 libsystemd-journal0 libsystemd-login0 libudev1 libudev1:i386 libvirt0 ...

Så min desktop-Ubuntu (sat til ugentlige opdateringer) var vist sårbar (?).

Hvad er - konkret - risikoen for en desktop-Ubuntu-PC ?

Der er jo så en fejl i din opsætning, den bør være sat til daglige opdateringer.

Jeg tog selv lige et tjek i changeloggen for openssl via synaptic, det fremgår:

openssl (1.0.1e-3ubuntu1.2) saucy-security; urgency=medium

  • SECURITY UPDATE: side-channel attack on Montgomery ladder implementation
    • debian/patches/CVE-2014-0076.patch: add and use constant time swap in crypto/bn/bn.h, crypto/bn/bn_lib.c, crypto/ec/ec2_mult.c, util/libeay.num.
    • CVE-2014-0076

  • SECURITY UPDATE: memory disclosure in TLS heartbeat extension

    • debian/patches/CVE-2014-0160.patch: use correct lengths in ssl/d1_both.c, ssl/t1_lib.c.
    • CVE-2014-0160

    -- Marc Deslauriers marc.deslauriers@ubuntu.com Mon, 07 Apr 2014 15:43:47 -0400

Så en linux maskine ( i dette tilfælde en *buntu ) der er sat op med daglige opdateringer vil som jeg læser det være beskyttet på nuværende tidspunkt.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen