Sleutels overzetten

In het beveiligingsadvies 1571 van Debian, heeft het veiligheidsteam van Debian een zwakte onthuld in de generator van willekeurige getallen die gebruikt wordt door OpenSSL op Debian en zijn derivaten. Als gevolg van deze zwakte komen bepaalde encryptiesleutels veel vaker voor dan het geval zou moeten zijn, zodat een aanvaller met minimale kennis van het systeem de sleutel kan raden via een aanval met brute kracht. Dit heeft vooral gevolgen voor het gebruik van encryptiesleutels in OpenSSH, OpenVPN en SSL-certificaten.

Op deze pagina wordt beschreven hoe u de procedures voor het overzetten van sleutels uitvoert voor pakketten waarvan de sleutels zijn aangetast door de OpenSSL-kwetsbaarheid.

Nog andere software maakt gebruik van cryptografische sleutels, maar is niet kwetsbaar omdat OpenSSL niet wordt gebruikt om sleutels te genereren of uit te wisselen.

Voor instructies voor het overzetten van sleutels voor andere software, wilt u misschien de door gebruikers ingediende informatie raadplegen op https://wiki.debian.org/SSLkeys

OpenSSH

Er is een bijgewerkt pakket uitgebracht via DSA-1576, dat sleutelomzetting vergemakkelijkt.

1. Installeer de beveiligingsupdates uit DSA-1576

Zodra de update is toegepast, worden zwakke gebruikerssleutels waar mogelijk automatisch geweigerd (hoewel ze niet in alle gevallen kunnen worden gedetecteerd). Als u dergelijke sleutels gebruikt voor gebruikersauthenticatie, werken ze onmiddellijk niet meer en moeten ze worden vervangen (zie stap 3).

OpenSSH-computersleutels kunnen automatisch worden geregenereerd wanneer de OpenSSH-beveiligingsupdate wordt toegepast. De update vraagt om bevestiging voordat deze stap wordt uitvoerd.

2. Werk de known_hosts-bestanden van OpenSSH bij

Het vernieuwen van computersleutels veroorzaakt een waarschuwing bij het verbinden met het systeem via SSH totdat de computersleutel is bijgewerkt in het bestand known_hosts op de client. De waarschuwing ziet er als volgt uit:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@  WAARSCHUWING: IDENTIFICATIE EXTERNE COMPUTER IS VERANDERD! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
HET IS MOGELIJK DAT IEMAND IETS SLECHTS DOET!
Iemand zou u op dit moment kunnen afluisteren (man-in-the-middle-aanval)!
Het is ook mogelijk dat de RSA-computersleutel zojuist is gewijzigd.

In dit geval is de computersleutel gewoon gewijzigd, en moet u het relevante bestand known_hosts bijwerken zoals aangegeven in het waarschuwingsbericht. Het wordt aanbevolen een betrouwbaar kanaal te gebruiken om de serversleutel uit te wisselen. Deze is te vinden in het bestand /etc/ssh/ssh_host_rsa_key.pub op de server; de vingerafdruk ervan kan worden afgedrukt met het commando:

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

Naast de gebruikersspecifieke known_hosts-bestanden kan er ook een systeembreed bestand /etc/ssh/ssh_known_hosts bestaan. Dit bestand wordt zowel door de ssh-client als door sshd gebruikt voor de functionaliteit hosts.equiv. Ook dit bestand moet worden bijgewerkt.

3. Controleer alle OpenSSH-gebruikerssleutels

De veiligste manier van handelen is om alle OpenSSH-gebruikerssleutels opnieuw te genereren, behalve wanneer met een voldoende hoge mate van zekerheid kan worden vastgesteld dat de sleutel werd gegenereerd op een niet-getroffen systeem.

Controleer of uw sleutel is aangetast door het hulpprogramma ssh-vulnkey uit te voeren, dat is opgenomen in de beveiligingsupdate. Standaard controleert ssh-vulnkey de standaardlocatie voor gebruikerssleutels (~/.ssh/id_rsa, ~/.ssh/id_dsa en ~/.ssh/identity), uw bestand authorized_keys (~/.ssh/authorized_keys en ~/.ssh/authorized_keys2), en de computersleutels van het systeem (/etc/ssh/ssh_host_dsa_key en /etc/ssh/ssh_host_rsa_key).

Om al uw eigen sleutels te controleren, ervan uitgaande dat ze zich op de standaardlocaties bevinden (~/.ssh/id_rsa, ~/.ssh/id_dsa of ~/.ssh/identity):

ssh-vulnkey

Om alle sleutels op uw systeem te controleren:

sudo ssh-vulnkey -a

Om een sleutel op een niet-standaard locatie te controleren:

ssh-vulnkey /path/to/key

Als ssh-vulnkey zegt Unknown (no blacklist information) (Onbekend - geen informatie wat de zwarte lijst betreft), dan heeft het geen informatie over of die sleutel is aangetast. Vernietig in geval van twijfel de sleutel en maak een nieuwe aan.

4. Maak alle getroffen gebruikerssleutels opnieuw aan

OpenSSH-sleutels die worden gebruikt voor gebruikersauthenticatie moeten handmatig opnieuw worden gegenereerd, inclusief sleutels die mogelijk naar een ander systeem zijn overgebracht nadat ze waren gegenereerd.

Nieuwe sleutels kunnen worden gegenereerd met ssh-keygen, bijv:

   $ ssh-keygen
   Generating public/private rsa key pair.
   (Genereren van publiek/privaat rsa sleutelpaar.)
   Enter file in which to save the key (/home/user/.ssh/id_rsa):
   (Voer het bestand in waarin de sleutel moet worden opgeslagen (/home/user/.ssh/id_rsa):)
   Enter passphrase (empty for no passphrase):
   (Voer wachtwoordzin in (leeg voor geen wachtwoordzin):)
   Enter same passphrase again:
   (Voer dezelfde wachtwoordzin opnieuw in:)
   Your identification has been saved in /home/user/.ssh/id_rsa.
   (Uw identificatie werd opgeslagen in /home/user/.ssh/id_rsa.)
   Your public key has been saved in /home/user/.ssh/id_rsa.pub.
   (Uw publieke sleutel is opgeslagen in /home/user/.ssh/id_rsa.pub.)
   The key fingerprint is:
   (De vingerafdruk van de sleutel is:)
   00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
   (00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 gebruiker@computer)
   

5. Werk de bestanden authorized_keys bij (indien nodig)

Zodra de gebruikerssleutels zijn geregenereerd, moeten de relevante publieke sleutels worden doorgegeven aan alle authorized_keys-bestanden (en authorized_keys2-bestanden, indien van toepassing) op externe systemen. Vergeet niet de aangetaste sleutel te verwijderen.

OpenSSL: algemene instructies voor het genereren van PEM-sleutels

Dit is slechts een herinnering voor degenen die PEM-gecodeerde certificaten (her)genereren. Uw site heeft waarschijnlijk andere beleidsregels over het beheer van sleutels die u moet volgen. Bovendien moet u de certificaten mogelijk opnieuw laten ondertekenen door een externe certificeringsinstantie in plaats van een door uzelf ondertekend certificaat te gebruiken, zoals hieronder weergegeven:

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

bincimap

Het bincimap-pakket maakt automatisch een zelfondertekend certificaat aan via het openssl-programma voor de bincimap-ssl-service en plaatst dit in /etc/ssl/certs/imapd.pem. Voer het volgende uit om te regenereren:

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

boxbackup

Boxbackup is niet aanwezig in Debian stable, alleen in testing/Lenny

De bovenstroomse ontwikkelaar heeft een eerste impactanalyse gepubliceerd van sleutelmateriaal dat gemaakt werd op systemen met onvoldoende willekeurige PRNG. U kunt de details lezen op deze plaats.

Als de PRNG in uw OpenSSL onvoldoende willekeurig was, moet u:

cryptsetup

Cryptsetup zelf gebruikt geen openssl voor encryptie (dit geldt zowel voor apparaten met LUKS als met dm-crypt).

Als cryptsetup is geconfigureerd om met SSL geëncrypteerde sleutelbestanden te gebruiken (een niet-standaard instelling die expliciet door de gebruiker moet worden geconfigureerd) en er een defecte versie van openssl is gebruikt om het sleutelbestand te genereren, kan de encryptie van het sleutelbestand zwakker zijn dan verwacht (aangezien de salt / het zout niet echt willekeurig is).

De oplossing is om het sleutelbestand opnieuw te encrypteren (als u er redelijk zeker van bent dat de geëncrypteerde sleutel niet aan derden is vrijgegeven) of om de getroffen partitie(s) te wissen en opnieuw te installeren met een nieuwe sleutel.

Instructies voor het opnieuw encrypteren van een sleutelbestand:

Doe het volgende voor elk met SSL geëncrypteerd sleutelbestand, en vervang <ssl_encrypted_key_path> door het pad naar het eigenlijke sleutelbestand:

tmpkey=$(tempfile)
openssl enc -aes-256-cbc -d -salt -in <ssl_encrypted_key_path> -out "$tmpkey"
shred -uz <ssl_encrypted_key_path>
openssl enc -aes-256-cbc -e -salt -in "$tmpkey" -out <ssl_encrypted_key_path>
shred -uz "$tmpkey"

dropbear

Als u sleutels heeft van het type /etc/ssh/*host*, verwijder deze dan, of volg eerst de instructies voor openssh voordat u de sleutels van dropbear bijwerkt.

Het script postinst van Dropbear converteert bestaande openssh-sleutels naar de door dropbear gebruikte indeling als het de computersleutels van dropbear niet kan vinden.

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

Merk op dat sleutels die zijn gegenereerd door Dropbear zelf niet kwetsbaar zijn (het gebruikt libtomcrypt in plaats van OpenSSL).

ekg

Gebruikers van programma's ekg en ekg2 (het laatste is alleen aanwezig in experimental) welke gebruik maken van de encryptiefunctionaliteit SIM, die een sleutelpaar hebben gegenereerd met behulp van het commando /key [-g|--generate] (dat libssl gebruikt om het werk te doen) zouden de sleutels opnieuw moeten genereren na het upgraden van libssl en het herstarten van het programma.

De bovenstroomse ontwikkelaars hebben een bericht op hun website geplaatst: http://ekg.chmurka.net/index.php

Als u meer hulp nodig heeft, vraag die dan op ekg-users@lists.ziew.org of ekg2-users@lists.ziew.org (zowel Engels als Pools).

ftpd-ssl

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

Dit geldt voor de standaardinstelling. Als de lokale beheerder verdere SSL-infrastructuur heeft opgezet, moeten deze sleutels ook opnieuw worden gegenereerd.

gforge

Het pakket gforge-web-apache2 in sid en lenny zet de website op met een dummycertificaat als er geen bestaand certificaat wordt gevonden. Gebruikers worden dan aangemoedigd om het te vervangen door een echt exemplaar. Het dummy-certificaat in kwestie is het Snake Oil-certificaat, dus het zou al bekend moeten staan als een zwak certificaat (zelfs zonder de SSL-bug), maar sommige gebruikers accepteren het misschien zonder erbij na te denken.

MIT Kerberos (krb5)

Geen enkel onderdeel van MIT Kerberos in Debian 4.0 (Etch) maakt gebruik van OpenSSL, en dus is Kerberos in Debian 4.0 helemaal niet aangetast.

In Lenny maakt het aparte binaire pakket krb5-pkinit gebruik van OpenSSL. MIT Kerberos zelf genereert geen sleutelparen, zelfs niet wanneer de plug-in PKINIT wordt gebruikt, dus eventuele kwetsbare sleutelparen voor de lange termijn zouden buiten de software van MIT Kerberos om zijn gegenereerd. De plug-in PKINIT verwijst alleen naar bestaande sleutelparen en is niet verantwoordelijk voor sleutelbeheer.

Sleutelparen voor de lange termijn die gebruikt worden met PKINIT kunnen aangetast zijn als ze werden aangemaakt op een aangetast Debian-systeem, maar een dergelijke aanmaak gebeurt buiten MIT Kerberos om.

De willekeurige sleutelfuncties van OpenSSL worden echter gebruikt voor de DH-uitwisseling wanneer PKINIT-authenticatie wordt gebruikt, wat betekent dat een aanvaller brute kracht kan gebruiken om toegang te krijgen tot het KDC-antwoord op een PKINIT-authenticatie en vervolgens toegang kan krijgen tot alle sessies die zijn aangemaakt met behulp van servicetickets van die authenticatie.

Alle KDC's die de plug-in PKINIT van Lenny gebruiken, moeten hun pakket libssl0.9.8 onmiddellijk laten upgraden en de Kerberos KDC herstarten met:

/etc/init.d/krb5-kdc restart

Alle Kerberos ticket-granting tickets (TGT's) of versleutelde sessies die het resultaat zijn van PKINIT-authenticatie met behulp van een Kerberos KDC met het aangetaste libssl moeten als verdacht worden behandeld; het is mogelijk dat aanvallers met pakketafvangeers deze sleutels en sessies kunnen compromitteren.

Nessus

Het post-installatiescript van het Nessus-serverpakket (nessusd) maakt enkele SSL-sleutels aan voor veilige communicatie tussen een Nessus-server en client. Dat communicatiekanaal moet als gecompromitteerd worden beschouwd, aangezien een malafide gebruiker in staat zou kunnen zijn om de informatie die wordt uitgewisseld tussen de server en de client (inclusief informatie over kwetsbaarheden op externe computers) te onderscheppen en mogelijk opdrachten naar de servers te sturen als de ingelogde gebruiker.

Bovendien, als de beheerder de Nessus CA-sleutel of een gebruikerscertificaat (met nessus-mkcert-client) heeft gemaakt voor externe authenticatie op een server waarop de OpenSSL-versie was geïnstalleerd waarop dit beveiligingsprobleem betrekking heeft, moeten die sleutels als gecompromitteerd worden beschouwd. Merk op dat externe gebruikers met toegang tot de Nessus-server aanvallen kunnen lanceren op de servers die ze mogen aanvallen en, indien ingeschakeld in de lokale configuratie (in Debian is dit standaard no), plug-ins kunnen uploaden die zouden worden uitgevoerd op de Nessus-server met systeembeheerdersrechten.

De configuratiescripts van de pakketbeheerder zullen de OpenSSL-certificaten opnieuw genereren wanneer dit geconfigureerd is wanneer deze niet kunnen worden gevonden. U moet de certificaten verwijderen en nieuwe laten genereren met:

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

Zodra dit gebeurd is moet u de oude gebruikerssleutels verwijderen in /var/lib/nessus/users/GEBRUIKERSNAAM/auth en ze opnieuw genereren met nessus-mkcert-client. Oude sleutels zijn ongeldig zodra de CA-sleutel is verwijderd.

Nadat de CA-sleutel opnieuw is gegenereerd, moet u ook het nieuwe CA-certificaat naar uw gebruikers verspreiden, en uw gebruikers moeten het nieuwe certificaat van de Nessus-server accepteren zodra ze opnieuw verbinding maken. Certificaatinstellingen voor de oude server zouden automatisch moeten worden verwijderd, maar u kunt ze ook handmatig verwijderen door .nessusrc.cert (bij gebruik van de Nessus-client) of .openvasrc.cert (bij gebruik van de OpenVAS-client) te bewerken..

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

Pas op: Het herstarten van de ipsec-diensten beëindigt alle momenteel openstaande IPSec-verbindingen, die mogelijk opnieuw gestart moeten worden vanaf de andere kant.

OpenVPN

Maak een back-up van uw geheime sleutelbestanden. Hoewel sleutelnamen willekeurig zijn, kunnen ze worden gedetecteerd door het uitvoeren van

grep secret /etc/openvpn/*.conf

Maak ze opnieuw aan met

openvpn --genkey --secret BESTANDSNAAM_GEHEIME_SLEUTELS

Kopieer vervolgens de gedeelde geheime sleutels naar de externe computers en herstart de VPN op elke computer met

/etc/init.d/openvpn force-reload

Proftpd

De verpakking van dit programma in Debian voorziet geen aanmaak van sleutels, dus de volgende stappen zijn alleen nodig als er extern SSL-sleutels zijn aangemaakt.

Een toekomsitge upload van proftpd naar unstable zal een tls.conf-sjabloon bevatten met onderstaande opmerking.

Merk op dat het genereren van een zelfondertekend certificaat een beetje afwijkt van wat in de algemene openssl sectie wordt voorgesteld, om het gebruik van een expliciet wachtwoord bij het opstarten van de achtergronddienst te vermijden.

U kunt een zelfondertekend certificaat (opnieuw) genereren met een commando als:

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

Beide bestanden mogen alleen door root gelezen kunnen worden. De bestandspaden kunnen worden gecontroleerd/geconfigureerd via de volgende configuratierichtlijnen:

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

puppet

Er zijn twee methoden om met puppet-certificaten om te gaan, de ene is via capistrano, de tweede is handmatig.

Het opnieuw genereren van Puppet SSL-Certificaten met behulp van capistrano wordt hier beschreven: http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL

De handmatige stappen zijn de volgende:

  1. U moet uw CA-info wissen en opnieuw genereren:
    /etc/init.d/puppetmaster stop
    rm -rf $vardir/ssl/*
    /etc/init.d/puppetmaster start
    

    Als u echter mongrel gebruikt, moet u in plaats van puppetmaster te starten vanuit het init-script, eerst het frontend programma dat op het web luistert (apache, nginx, enz.) stoppen en dan het volgende doen:

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

    Het bovenstaande is nodig omdat om de een of andere reden puppetmaster zijn CA niet regenereert wanneer het met mongrel werkt.

  2. Wis alle clientcertificaten
    /etc/init.d/puppet stop
    rm $vardir/ssl/*
    
  3. Laat elke client een nieuw certificaat aanvragen:
    puppetd --onetime --debug --ignorecache --no-daemonize
    
  4. Zodra alle aanvragen binnen zijn, kunt u ze allemaal tegelijk ondertekenen:
    puppetca --sign --all
    
  5. Start uw puppet-clients op:
    /etc/init.d/puppet start
    

U zou ook tijdelijk automatisch ondertekenen kunnen inschakelen, als u dat goed vindt.

sendmail

Sendmail (zowel in Etch als in Lenny) maakt facultatief standaard OpenSSL-certificaten aan bij de installatie.

De procedure voor het omzetten van de sleutels is triviaal:

/usr/share/sendmail/update_tls new

Als u de sjablonen in /etc/mail/tls hebt aangepast, zullen die waarden opnieuw worden gebruikt om de nieuwe certificaten te maken.

ssl-cert

Het snakeoil-certificaat /etc/ssl/certs/ssl-cert-snakeoil.pem kan opnieuw worden gemaakt met:

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

Dit geldt voor de standaardopstelling. Als de lokale beheerder verdere SSL-infrastructuur heeft opgezet, moeten deze sleutels ook opnieuw worden gegenereerd.

tinc

Verwijder alle verdachte bestanden met openbare en private sleutels:

  1. Verwijder rsa_key.priv.
  2. Bewerk alle bestanden in de map hosts/ en verwijder de blokken met openbare sleutels.

Genereer een nieuw publiek/privaat sleutelpaar:

tincd -n <netname> -K

Wissel het configuratiebestand op uw computer met de nieuwe publieke sleutel uit met andere leden van uw VPN. Vergeet niet uw tinc-achtergronddiensten te herstarten.

tor

Tor is niet in stable, maar aangetast in Lenny.

Clients die versie 0.1.2.x gebruiken, zijn niet aangetast. Elke versie van Tor-knooppunten of verborgen dienstverleners, alsook iedereen die versie 0.2.0.x gebruikt, is wel aangetast.

Raadpleeg de aankondiging van de kwetsbaarheid in de mailinglijst met Tor-aankondigingen.

Het wordt aanbevolen om op te waarderen naar versie 0.1.2.19-3 (beschikbaar in testing, unstable, backports.org en in de gebruikelijke noreply.org-pakketbron) of versie 0.2.0.26-rc-1 (beschikbaar in experimental en in de gebruikelijke noreply.org-pakketbron). Als u een relais bent, dwingen deze versies het genereren van nieuwe serversleutels (/var/lib/tor/keys/secret_*) af.

Als u een Tor-knooppunt bent zonder gebruik te maken van de infrastructuur van het pakket (gebruiker debian-tor, /var/lib/tor als DataDirectory, enz.), moet u handmatig slechte sleutels verwijderen. Zie de hierboven geplaatste link naar het advies.

Als u een verborgen dienstverlener bent, en uw sleutel in de betrokken periode hebt aangemaakt met een slechte libssl, verwijder dan alstublieft de privésleutel van uw verborgen dienst. Dit zal de computernaam van uw verborgen dienst veranderen en het kan nodig zijn uw servers opnieuw te configureren.

Indien u versie 0.2.0.x gebruikt, is een upgrade ten stelligste aanbevolen — 3 van de 6 v3 autoriteitsservers hebben gecompromitteerde sleutels. Oude 0.2.0.x-versies zullen over een tweetal weken stoppen met werken.

xrdp

xrdp gebruikt gegenereerde sleutels. De meeste clients controleren die sleutels niet standaard, daarom is het veranderen ervan pijnloos. U hoeft alleen maar het volgende te doen:

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

xrdp is niet in stable.