Dette indlæg er alene udtryk for skribentens egen holdning.
Blogindlæg

Opdater OpenSSL - og dit OS nu

8. april 2014 kl. 10:3026
person
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.
person

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

Artiklen fortsætter efter annoncen

> 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.

Artiklen fortsætter efter annoncen

Jobs

Dine job
Vis alle

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!

  • https://github.com/FiloSottile/Heartbleed tool i Go og site http://filippo.io/Heartbleed/
  • https://github.com/titanous/heartbleeder tool i Go
  • http://s3.jspenguin.org/ssltest.py PoC
  • https://gist.github.com/takeshixx/10107280 test tool med STARTTLS support
  • http://possible.lv/tools/hb/ test site
  • https://twitter.com/richinseattle/status/453717235379355649 Practical Heartbleed attack against session keys links til, https://www.mattslifebytes.com/?p=533 og "Fully automated here " https://www.michael-p-davis.com/using-heartbleed-for-hijacking-user-sessions/
  • Metasploit er også opdateret på master repo https://twitter.com/firefart/status/453758091658792960 https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb

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

  • http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html? analyse af problemet i koden
  • http://blog.inliniac.net/2014/04/08/detecting-openssl-heartbleed-with-suricata/ IDS regler Detecting OpenSSL Heartbleed with Suricata
  • http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/ blog om emnet
  • https://www.getpantheon.com/heartbleed-fix god beskrivelse af hvordan man kan fixe hurtigere hvis man har automatiseret infrastruktur
  • "#nse script ssl-heartbleed.nse committed to #nmap as rev 32798. " du burde kunne finde Nmap og scanne, har ikke selv prøvet den endnu
  • You can now use Masscan to scan the whole internet for the Hearbleed vulnerability in under 6 minutes https://twitter.com/jedisct1/status/453679529710460928 og https://github.com/robertdavidgraham/masscan/commit/23497c448b0a1c7058e8443e5202e7bffcab4795

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

Emner
26 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Køb abonnementFå prøveabonnement

Fortsæt din læsning

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
20
Lasse Hillerøe Petersen
9. april 2014 kl. 11:44

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...

  • more_vert
    • insert_linkKopier link
19
Jørgen Ramskov
9. april 2014 kl. 10:04

Hej Henrik.

Som en ikke specielt sikkerhedskyndig person er dette umiddelbart bekymrende at læse citater som "I have come to the conclusion that OpenSSL is equivalent to monkeys throwing feces at the wall" om OpenSSL:https://www.peereboom.us/assl/assl/html/openssl.html

Har han ret?

  • more_vert
    • insert_linkKopier link
21
Henrik Kramselund
9. april 2014 kl. 14:32

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.

  • more_vert
    • insert_linkKopier link
23
Jørgen Ramskov
9. april 2014 kl. 15:28

Mange tak for svar!

  • more_vert
    • insert_linkKopier link
18
Kristian Larsen
9. april 2014 kl. 09:20

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.

  • more_vert
    • insert_linkKopier link
17
Carsten Olsen
9. april 2014 kl. 08:29

Min Chromebook beta-kanal køre Chrome/34.0.1847.118 openssl 1.0.1f

  • more_vert
    • insert_linkKopier link
13
Lars Sommer
8. april 2014 kl. 13:26

Mange tak for linket til POC også.. Har sat et script til at høste data fra en intern egen server, der ikke er patched endnu. Skal lige se hvor meget eller hvor nemt man får noget relevant ud.

  • more_vert
    • insert_linkKopier link
12
Lars Sommer
8. april 2014 kl. 13:18

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?

  • more_vert
    • insert_linkKopier link
11
Lars Sommer
8. april 2014 kl. 13:18

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?

  • more_vert
    • insert_linkKopier link
14
Henrik Kramselund
8. april 2014 kl. 13:36

Alle råber at vi skal opgradere OpenSSL nu, men hvor meget mere skal vi efterse?</p>
<p>Sårbarheden har tilladt angribere at læse hukommelsen af hvor meget? Den service der har kørt med OpenSSL? Altså webserveren, mailserveren mm.?</p>
<p>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.?</p>
<p>Og så en generel bevidsthed om, at al data, der har været transmitteret via SSL-linjen, kan være opsnappet.</p>
<p>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/

  • more_vert
    • insert_linkKopier link
16
Henrik Kramselund
8. april 2014 kl. 15:45

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?</p>
<p>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)."

  • more_vert
    • insert_linkKopier link
9
Kenneth Østrup
8. april 2014 kl. 12:46

Når man opdaterer openssl / libssl så husk også at genstarte services som benytter dette library. F.eks. Apache.

  • more_vert
    • insert_linkKopier link
8
Mike Mikjær
8. april 2014 kl. 12:45

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 :)

  • more_vert
    • insert_linkKopier link
10
Mike Mikjær
8. april 2014 kl. 13:07

Jeg får samme mærkelige opførsel på en Debian 7 ... men når jeg så patcher hullet på Debian 7 skifter den over til at sige "All good" hver gang ... men jeg skal tilsyneladende teste en 2-3 gange for at være sikker.

  • more_vert
    • insert_linkKopier link
6
Jacob Rasmussen
8. april 2014 kl. 11:29

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?

  • more_vert
    • insert_linkKopier link
4
Jacob Nordfalk
8. april 2014 kl. 11:18

$ 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 ?

  • more_vert
    • insert_linkKopier link
24
Jimmy Christiansen
9. april 2014 kl. 18:00

$ sudo apt-get update; sudo apt-get upgrade</p>
<p>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
...</p>
<p>Så min desktop-Ubuntu <strong>(sat til ugentlige opdateringer)</strong> var vist sårbar (?).</p>
<p>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</p>
<ul><li>SECURITY UPDATE: side-channel attack on Montgomery ladder implementation
<ul><li>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.</li>
<li>CVE-2014-0076</li>
</ul></li>
<li>SECURITY UPDATE: memory disclosure in TLS <strong>heartbeat</strong> extension
<ul><li>debian/patches/CVE-2014-0160.patch: use correct lengths in
ssl/d1_both.c, ssl/t1_lib.c.</li>
<li>CVE-2014-0160</li>
</ul></li>
</ul><p>-- Marc Deslauriers <a href="mailto:marc.deslauriers@ubuntu.com">marc.deslauriers@ubuntu.com</a&gt; <strong>Mon, 07 Apr 2014 15:43:47 -0400</strong>

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.

  • more_vert
    • insert_linkKopier link
1
Slettet bruger
8. april 2014 kl. 10:52

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)?

  • more_vert
    • insert_linkKopier link
2
Henrik Kramselund
8. april 2014 kl. 11:03

Du har helt ret, det er som om folk ikke tager det alvorligt. Jeg tror dog det vil virke bedre hvis journalisterne fra Version2.dk giver dem spørgsmålet - så det vil jeg lige prikke til dem.

  • more_vert
    • insert_linkKopier link