Nyckelbyte

I Debians säkerhetsbulletin 1571 avslöjade Debians säkerhetsgrupp en sårbarhet i slumptalsgeneratorn som användes av OpenSSL på Debian och dess avledda versioner. Som en följd av denna sårbarhet förekommer vissa kryptografiska nycklar mycket oftare än de skulle, så att en angripare kunde gissa nyckeln med ett ”brute force”-angrepp givet grundläggande kunskap om systemet. Detta påverkar speciellt användningen av krypteringsnycklar i OpenSSH, OpenVPN och SSL-certifikat.

Denna sida beskriver hur du utför en nyckelbytesprocess för paket vars nycklar påverkas av OpenSSL-sårbarheten.

Det finns ytterligare programvaror som använder kryptografiska nycklar men som inte påverkas eftersom OpenSSL inte använts för att generera eller kommunicera dess nycklar.

För instruktioner om hur du byter nycklar för annan programvara kan du se användarinsänd information på https://wiki.debian.org/SSLkeys.

OpenSSH

Ett uppdaterat paket har släppts genom DSA-1576, vilket förenklar uppdatering av nycklar.

1. Installera säkerhetsuppdateringarna i DSA-1576

Denna uppdatering innehåller ett beroende på openssl-uppdateringen och kommer automatiskt installera en rättad version av libssl0.9.8-paketet, samt det nya paketet openssh-blacklist.

När uppdateringen har installerats kommer svaga användarnycklar automatiskt att avvisas när så är möjligt (även om de inte alltid kan identifieras). Om du använder sådana nycklar för autentisering av användare kommer de omedelbart att sluta fungera och måste ersättas (se steg 3).

OpenSSH-värdnycklar kan omskapas automatiskt när OpenSSH-säkerhetsuppdateringen installeras. Uppdateringen kommer be dig om bekräftelse innan den gör det.

2. Uppdatera OpenSSH:s known_hosts-filer

När värdnyckeln omskapas kommer det att göra så att en varning visas när du ansluter till systemet med SSH fram till att värdnyckeln uppdaterats i filen known_hosts på klienten. Varningen ser ut som följer: 

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

I det här fallet har nyckeln helt enkelt ändrats, och du bör uppdatera motsvarande known_hosts-fil, enligt beskrivningen i varningsmeddelandet.

Vi rekommenderar att du använder en betrodd kanal för att hämta servernyckeln. Nyckeln finns i filen /etc/ssh/ssh_host_rsa_key.pub på severn; dess fingeravtryck kan skrivas ut med kommandot:

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

Förutom användarspecifika known_hosts-filer kan det finnas en systemglobal fil som heter /etc/ssh/ssh_known_hosts. Denna fil används både av ssh-klienten och av sshd för hosts.equiv-funktionalitet. Även denna fil behöver uppdateras.

3. Kontrollera samtliga OpenSSH-användarnycklar

Den mest säkra lösningen är att skapa alla OpenSSH-användarnycklar på nytt, förutom när det är möjligt att med tillräckligt hög sannolikhet avgöra att nyckeln har skapats på ett system som inte påverkats av problemet.

Se om din nyckel påverkas genom att köra verktyget ssh-vulnkey, vilket medföljer denna säkerhetsuppdatering. Som standard kommer ssh-vulnkey att se på standardplatsen för användarnycklar (~/.ssh/id_rsa, ~/.ssh/id_dsa och ~/.ssh/identity), din authorized_keys-fil (~/.ssh/authorized_keys och ~/.ssh/authorized_keys2), samt systemets värdnycklar (/etc/ssh/ssh_host_dsa_key och /etc/ssh/ssh_host_rsa_key).

För att kontrollera alla dina egna nycklar, förutsatt att de finns på standardplatser (~/.ssh/id_rsa, ~/.ssh/id_dsa, eller ~/.ssh/identity):

ssh-vulnkey

För att kontrollera alla nycklar på ditt system:

sudo ssh-vulnkey -a

För att kontrollera en nyckel på en icke-standardiserad plats:

ssh-vulnkey /sökväg/till/nyckel

Om ssh-vulnkey säger Unknown (no blacklist information) (okänd – svartlisteinformation saknas) så saknas information om huruvida nyckeln påverkas. Om du är osäker kan du ta bort nyckeln och skapa en ny.

4. Omskapa eventuella påverkade användarnycklar

OpenSSH-nycklar som används för användarautentisering måste skapas om manuellt, och det gäller även de som har överförts till ett annat system efter att de skapades.

Nya nycklar kan skapas med ssh-keygen, t.ex:

   $ ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/användare/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/användare/.ssh/id_rsa.
   Your public key has been saved in /home/användare/.ssh/id_rsa.pub.
   The key fingerprint is:
   00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 användare@värd

5. Uppdatera authorized_keys-filer (om nödvändigt)

När användarnycklarna har omskapats måste de relevanta öppna nycklarna kopieras till alla authorized_keys-filer (och authorized_keys2-filer, om de behövs) på fjärrsystem. Se till att ta bort de nycklar som påverkas från dessa filer.

OpenSSL: Allmänna instruktioner för att generera PEM-nycklar

Det här är bara en påminnelse till de som (om)skapar PEM-kodade certifikat. Din server har troligtvis en annan policy på plats för hur du hanterar nycklar som du bör följa. Dessutom kan du behöva få certifikaten signerade på nytt av ett tredjepartscertifieringsorgan, snarare än att använda ett självsignerat certifikat, vilket är vad som beskrivs här: 

cd /etc/ssl/private
openssl genrsa 1024 > minserver.pem
cd /etc/ssl/certs
openssl req -new -key ../private/minserver.pem -x509 -days 9999 -out minserver.pem

bincimap

Paketet bincimap skapar ett självsignerat certifikat för bincimap-ssl-tjänsten automatiskt, med hjälp av openssl-programmet, och lägger det i /etc/ssl/certs/imapd.pem. För att skapa ett nytt, kör: 

rm -f /etc/ssl/certs/imapd.pem
dpkg-reconfigure bincimap

boxbackup

Boxbackup finns inte i Debians stabila utgåva, bara i uttestningsutgåvan/Lenny.

Uppströmsförfattarna har publicerats en första konsekvensanalys för nyckelmaterial som skapats på system där slumptalsgeneratorn inte är tillräckligt slumpmässig. Se detaljerna här.

Om slumptalsgeneratorn för din OpenSSL inte var tillräckligt slumpmässig måste du:

cryptsetup

Cryptsetup använder i sig självt inte openssl för kryptering (gäller både LUKS- och dm-crypt-enheter).

Om cryptsetup har konfigurerats att använda SSL-krypterade nyckelfiler (en icke-standardinställning som måste konfigureras explicit av användaren), och nyckelfilen genererades av en trasig version av openssl, är krypteringen av nyckelfilen svagare än förväntad (eftersom saltet inte är verkligt slumpmässig).

Lösningen är antingen att kryptera nyckelfilen på nytt (om du är tillräckligt säker på att den krypterade nyckeln inte har tillhandahållits till några tredjeparter) eller att ta bort och ominstallera påverkade partitioner med en ny nyckel.

Instruktioner för att kryptera en nyckelfil på nytt:

Utför följande steg på varje SSL-krypterad nyckelfil, men ersätt <sökväg_till_sslkrypterad_nyckel> med den faktiska sökvägen till nyckelfilen: 

tmpkey=$(tempfile)
openssl enc -aes-256-cbc -d -salt -in <sökväg_till_sslkrypterad_nyckel> -out "$tmpkey"
shred -uz <sökväg_till_sslkrypterad_nyckel>
openssl enc -aes-256-cbc -e -salt -in "$tmpkey" -out <sökväg_till_sslkrypterad_nyckel>
shred -uz "$tmpkey"

dropbear

Om du har nycklar i /etc/ssh/*host* tar du antingen bort dem, eller följer instruktionerna för openssh först, innan du uppdaterar dropbears filer.

Dropbears postinst konverterar openssh-nycklar till dropbear-format om den inte hittar dropbear-värdnycklar. 

rm /etc/dropbear/*_host_key
dpkg-reconfigure dropbear

Observera att nycklar som har skapats av Dropbear självt inte är sårbara (det använder libtomcrypt istället för OpenSSL).

ekg

Användare av programmen ekg och ekg2 (det sistnämnda endast i den experimentella utgåvan), som använder SIM-krypteringsfunktionaliteten, och som har skapat ett nyckelpar med kommandot /key [-g|--generate] (som använder libssl för att göra sitt jobb) bör skapa nya nycklar efter att ha uppgraderat libssl och startat om programmet.

Uppströmsutvecklarna har publicerat information på sin webbplats: http://ekg.chmurka.net/index.php

Om du behöver ytterligare hjälp, fråga på ekg-users@lists.ziew.org eller ekg2-users@lists.ziew.org (både på engelska och polska).

ftpd-ssl

rm -f /etc/ftpd-ssl/ftpd.pem /etc/ssl/certs/ftpd.pem
dpkg-reconfigure ftpd-ssl

Detta täcker standardkonfigurationen. Om administratören lokalt har konfigurerat en SSL-infrastruktur utöver detta måste även dessa skapas på nytt.

gforge

Paketet gforge-web-apache2 package i Sid och Lenny ställer in webbplatsen med ett fuskcertifikat om det inte hittar ett riktigt certifikat. Användarna rekommenderas sedan att ersätta det med ett riktigt certifikat. Fuskcertifikatet i fråga är det från Snake Oil, så det bör redan vara känt som svagt (även utan SSL-felet), men en del användare kanske godtar det utan att tänka efter.

MIT Kerberos (krb5)

Inga delar av MIT Kerberos i Debian 4.0 (Etch) använder OpenSSL, och därför påverkas inte Kerberos i Debian 4.0 överhuvudtaget.

I Lenny använder det separata binärpaketet krb5-pkinit OpenSSL. MIT Kerberos självt genererar inte nyckelpar som skall användas över en längre tid, även om PKINIT-insticksprogrammet används, så eventuella nyckelpar tänkta att användas över längre tid har skapats utanför själva MIT Kerberos-programvaran. PKINIT-insticksprogrammet bara refererar till befintliga nyckelpar och ansvarar inte för nyckelhantering.

Nyckelpar som används med PKINIT över en längre tid kan vara påverkade om de skapats på ett påverkat Debiansystem, men alla sådana nycklar är utanför MIT Kerberos kontroll.

OpenSSL:s slumptalsfunktioner används dock för DH-utbyte när PKINIT-autentisering används, vilket betyder att angriparen kanske kan använda sig av en ”brute force”-teknik för att få tillgång till KDC-svaret till en PKINIT-autentisering, och därefter få tillgång till alla sessioner som använder tjänstebiljetter från denna autentisering.

Alla KDC:er som använder PKINIT-insticksprogrammet från Lenny bör uppdatera sitt libssl0.9.8-paket omedelbart och starta om Kerberos KDC med: 

/etc/init.d/krb5-kdc restart

Alla Kerberos biljetterbjudande biljetter (TGT, ticket-granting tickets) eller krypterade sessioner som kommer från en PKINIT-autentisering med en Kerberos-KDC med den påverkade libssl bör ses på som misstänkt; det är möjligt att angripare med paketfångare kan kompromettera de nycklarna och sessionerna.

Nessus

Nessus-serverpaketets (nessusd) skript som körs efter installationen skapar ett par SSL-nycklar för säker kommunikation mellan en Nessus-server och -klient. Denna kommunikationskanal är att anse som komprometterad eftersom en illasinnad användare skulle kunna fånga informationen som sänds mellan servern och klienten (vilket innehåller information om sårbarheter på andra värdar) och möjligen sända kommandon som den inloggade användaren.

Om administratören dessutom har skapat antingen en Nessus-CA-nyckel eller ett användarcertifikat (med nessus-mkcert-client) för fjärrautentisering på en server där en version av OpenSSL som påverkas av detta säkerhetsproblem är installerat bör dessa nycklar anses vara komprometterade. Observera att användare utifrån med tillgång till Nessus-servern kan starta angrepp mot servrar de har tillgång till att angripa, samt, om ativerat i den lokala konfigurationen (i Debian är standardvärdet nej) sända in insticksprogram som exekveras på Nessus-servern med rootbehörighet.

Paketskripten kommer att skapa nya OpenSSL-certifikat under konfigureringen om de inte hittar dem. Du måste ta bort de gamla certifikaten och skapa nya med: 

rm -f /var/lib/nessus/CA/cacert.pem
rm -f /var/lib/nessus/CA/servercert.pem
rm -f /var/lib/nessus/private/CA/cakey.pem
rm -f /var/lib/nessus/private/CA/serverkey.pem
dpkg-reconfigure nessusd

När detta är gjort måste du ta bort gamla användarnycklar i /var/lib/nessus/users/ANVÄNDARNAMN/auth och skapa dem på nytt med nessus-mkcert-client. Gamla nycklar kommer att vara ogiltiga så fort CA-nyckeln har tagits bort.

Efter att CA-nyckeln har skapats på nytt måste du även distribuera den nya CA_nyckeln till dina användare, och dina användare måste godta det nya certifikatet från Nessus-servern när de ansluter till den på nytt. Certifikatinställningar för den gamla servern bör tas bort automatiskt, men du kan även ta bort dem manuellt genom att redigera filen .nessusrc.cert (om du använder Nessus-klienten) eller .openvasrc.cert (om du använder OpenVAS-klienten).

OpenSWAN / StrongSWAN

rm /etc/ipsec.d/private/`hostname`Key.pem /etc/ipsec.d/certs/`hostname`Cert.pem
dpkg-reconfigure (open|strong)swan
/etc/init.d/ipsec restart

Varning: När du startar om ipsec-tjänsterna så avslutas alla öppna IPSec-anslutningar, vilka kanske behöver omstartas från andra sidan.

OpenVPN

Säkerhetskopiera dina hemliga nyckelfiler. Även om nyckelnamnen är godtyckliga kan de upptäckas genom att köra 

grep secret /etc/openvpn/*.conf

Skapa dem på nytt med 

openvpn --genkey --secret HEMLIG_FILNAMN

Kopiera därefter de delade hemliga nycklarna till fjärrvärdarna och starta om VPN:et på varje värd med 

/etc/init.d/openvpn force-reload

Proftpd

Debianpaketet innehåller inte skapande av nycklar, så stegen som följer bör endast vara nödvändiga om SSL-nycklar har skapats externt.

En kommande proftpd-insändning till den instabila utgåvan kommer innehålla en tls.conf-mall med kommentaren nedan.

Observera att en lite annan procedur används för att skapa självsignerade certifikat än vad som beskrivs i den allmänna openssl-sektionen, för att undvika att använda ett explicit lösenord när servern startar.

Du kan skapa (på nytt) ett självsignerat certifikat med kommandoraden: 

 openssl req -x509 -newkey rsa:1024 -keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt -nodes -days 365

De båda filerna måste vara läsbara endast av root. Filsökvägen kan kontrolleras/konfigureras genom följande konfigurationsdirektiv: 

TLSRSACertificateFile                   /etc/ssl/certs/proftpd.crt
TLSRSACertificateKeyFile                /etc/ssl/private/proftpd.key
TLSCACertificateFile                    /etc/ssl/certs/CA.pem
TLSOptions                              NoCertRequest

puppet

Det finns två sätt att hantera certifikat i puppet, ett är via capistrano, det andra är manuellt.

Information om hur du nygenererar Puppet SSL-certifikat med capistrano beskrivs på http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL

De manuella stegen är som följer:

  1. Du måste ta bort och skapa om din CA-information: 
    /etc/init.d/puppetmaster stop
rm -rf $vardir/ssl/*
/etc/init.d/puppetmaster start

    Om du använder mongrel måste du dock, istället för att starta puppetmaster från init-skriptet, först stoppa webblyssnarskalet (apache, nginx, osv.) och sedan göra följande: 

    puppetmasterd --daemonize ; sleep 30 ; pkill -f 'ruby /usr/sbin/puppetmasterd'

    Steget ovan behövs eftersom puppet som körs med mongrel av någon anledning inte komer att omgenerera sin CA.

  2. Ta bort alla klientcertifikat 
    /etc/init.d/puppet stop
rm $vardir/ssl/*
  3. Be varje klient hämta ett nytt certifikat: 
    puppetd --onetime --debug --ignorecache --no-daemonize
  4. När alla anrop har kommit in, kan du signera dem alla på en gång: 
    puppetca --sign --all
  5. Starta dina puppet-klienter: 
    /etc/init.d/puppet start

Du kan även tillfälligt slå på autosign, om du tycker att det är ok.

sendmail

Sendmail (i både Etch och Lenny) skapar standard-OpenSSL-certifikat om man väljer det under installationen.

Det är enkelt att skapa nya nycklar: 

/usr/share/sendmail/update_tls new

Om du har ändrat i mallarna i /etc/mail/tls kommer dessa värden att återanvändas för att skapa de nya certifikaten.

ssl-cert

Snakeoil-certifikatet /etc/ssl/certs/ssl-cert-snakeoil.pem kan skapas på nytt med: 

make-ssl-cert generate-default-snakeoil --force-overwrite

telnetd-ssl

rm -f /etc/telnetd-ssl/telnetd.pem /etc/ssl/certs/telnetd.pem
dpkg-reconfigure telnetd-ssl

Detta täcker standardkonfigurationen. Om administratören lokalt har konfigurerat en SSL-infrastruktur utöver detta måste även dessa skapas på nytt.

tinc

Ta bort alla misstänkta öppna och hemliga nyckelfiler:

  1. Ta bort rsa_key.priv.
  2. Redigera alla filer i hosts/-katalogen och ta bort blocken för öppen nyckel.

Skapa ett nytt öppen/hemlig-nyckelpar: 

tincd -n <netname> -K

Distribuera din värdkonfigurationsfil med din nya öppna nyckel till andra medlemmar på ditt VPN. Glöm inte att starta om dina tinc-servrar.

tor

Tor finns inte i den stabila utgåvan, men påverkas i Lenny.

Klienter som kör 0.1.2.x påverkas inte. Tor-noder eller dolda tjänsteleverantörer som kör alla versioner, samt alla på 0.2.0.x påverkas.

Se sårbarhetsbulletinen på Tors sändlista.

Vi rekommenderar att du uppgraderar till 0.1.2.19-3 (finns i uttestningsutgåvan, den instabila utgåvan, på backports.org och i det vanliga noreply.org-arkivet) eller 0.2.0.26-rc-1 (finns i den experimentella utgåvan och i det vanliga noreply.org-arkivet). Om du kör ett relä kommer dessa versioner tvinga fram att nya servernycklar (/var/lib/tor/keys/secret_*) skapas.

Om du kör en Tor-nod utan att använda paketets infrastruktur (debian-tor-användare, /var/lib/tor som DataDirectory osv.) måste du manuellt ta bort dåliga nycklar. Se bulletinlänken som finns ovan.

Om du är en dold tjänsteleverantör och har skapat din nyckel under den påverkade tidsramen med ett trasigt libssl-paket, bör du ta bort din dolda tjänsts hemliga nyckel. Detta kommer att ändra din dolda tjänsts värdnamn och kan kräva att dina servrar konfigureras om.

Om du kör 0.2.0.x rekommenderas en uppgradering å det bestämdaste – tre av de sex v3-auktoritetsservrarna har komprometterade nycklar. Gamla 0.2.0.x-versioner kommer sluta fungera om en eller ett par veckor.

xrdp

xrdp använder genererade nycklar. De flesta klienter kontrollerar inte dessa nycklar som standard, därför är det inga problem att byta dem. Allt du behöver göra är: 

rm /etc/xrdp/rsakeys.ini
/etc/init.d/xrdp restart

xrdp finns inte i den stabila utgåvan.