Замена ключей

В рекомендации по безопасности Debian 1571, команда безопасности Debian обнаружила уязвимость в генераторе случайных чисел, используемом OpenSSL в Debian и производных от него дистрибутивах. В результате этой уязвимости некоторые ключи шифрования являются намного более простыми, чем они должны быть, так что атакующий может отгадать ключ с помощью атаки перебором, имея минимальные знания о системе. Это, в частности, касается использования ключей шифрования в OpenSSH, OpenVPN и сертификатах SSL.

Эта страница содержит информацию о том, как выполнить процедуру замены ключей для пакетов, чьи ключи подвержены уязвимости OpenSSL.

Другое ПО тоже использует криптографические ключи, но оно не подвержено этой уязвимости, поскольку OpenSSL не используется в нём для создания или обмена ключами.

Инструкции по замене ключей для остального ПО см. в информации, предоставленной пользователями, на странице https://wiki.debian.org/SSLkeys

OpenSSH

Для облегчения преобразования ключей были выпущены обновление пакетов, перечисленных в DSA-1576.

1. Установите обновления безопасности из DSA-1576

После того, как вы примените обновление, нестойкие пользовательские ключи будут автоматически отвергнуты там, где это возможно (хотя иногда определить все такие ключи нельзя). Если вы используете такие ключи для авторизации пользователей, они тут же перестанут работать и должны быть заменены (см. шаг 3).

OpenSSH-ключи узла могут быть автоматически созданы заново при применении обновления безопасности OpenSSH. Обновление запросит у вас подтверждение этого шага.

2. Обновите файлы known_hosts

Создание новых ключей узла приведёт к тому, что при подключении к этому узлу с системы, использующей SSH, будет отображаться предупреждение до тех пор, пока ключ узла не будет обновлён в файле known_hosts на стороне клиента. Предупреждение будет выглядеть приблизительно так:

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

В этом случае просто был изменён ключ узла, а вам следует обновить соответствующий файл known_hosts, как это обозначено в сообщении. Рекомендуется использовать доверенный канал для получения ключа сервера. Ключ находится в файле /etc/ssh/ssh_host_rsa_key.pub на сервере; его отпечаток может быть распечатан с помощью команды:

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

Помимо пользовательских файлов known_hosts, может существовать системный файл /etc/ssh/ssh_known_hosts. Этот файл используется и клиентом ssh, и sshd для предоставления функциональности hosts.equiv. Этот файл так же следует обновить.

3. Проверьте все пользовательские ключи OpenSSH

Наиболее безопасным способом является создание всех пользовательских ключей заново за исключением тех случаев, когда с достаточной определённостью может быть установлено, что данный ключ был создан на системе, не подверженной уязвимости.

Проверьте, уязвим ли ваш ключ, используя инструмент ssh-vulnkey, включённый в обновление безопасности. По умолчанию ssh-vulnkey проверит стандартный каталог на наличие пользовательских ключей (~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity), ваш файл authorized_keys (~/.ssh/authorized_keys и ~/.ssh/authorized_keys2) и системные ключи узла (/etc/ssh/ssh_host_dsa_key и /etc/ssh/ssh_host_rsa_key).

Чтобы проверить все ваши ключи, если они находятся в стандартном каталоге (~/.ssh/id_rsa, ~/.ssh/id_dsa, or ~/.ssh/identity) выполните следующую команду:

ssh-vulnkey

Чтобы проверить все ключи в вашей системе, используйте следующую команду:

sudo ssh-vulnkey -a

Чтобы проверить ключ в нестандартном каталоге, используйте следующую команду:

ssh-vulnkey /путь/к/ключу

Если ssh-vulnkey выводит Unknown (no blacklist information), то у него нет информации о том, уязвим этот ключ или нет. Если у вас имеются сомнения, удалите этот ключ и создайте новый.

4. Создайте заново уязвимые пользовательские ключи

Ключи OpenSSH, используемые для авторизации пользователей, следует создать заново вручную, включая те ключи, которые были перенесены с другой системы.

Новые ключи могут быть созданы, используя ssh-keygen, напр.:

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

5. Обновите файлы authorized_keys (если это необходимо)

После того, как пользовательские ключи заново созданы, соответствующие публичные ключи следует добавить во все файлы authorized_keys (и файлы authorized_keys2, если таковые имеются) на удалённых системах. Убедитесь в том, что уязвимые ключи удалены.

OpenSSL: общие инструкции по созданию PEM-ключа

Это просто напоминание тем, кто создаёт (может быть заново) сертификаты в формате PEM. Ваш сайт, вероятно, имеет другие правила управления ключами, которым вам нужно следовать. Кроме того, вам, скорее всего, может потребоваться получение подписи третьей стороны (центра сертификации) для ваших сертификатов, а не использование сертификатов, которые подписаны вами самими, как это показано ниже: 

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

bincimap

Пакет bincimap автоматически создаёт сертификат с собственной подписью через программу openssl для сервиса bincimap-ssl и помещает его в /etc/ssl/certs/imapd.pem. Чтобы создать его заново, выполните следующее: 

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

boxbackup

Boxbackup отсутствует в стабильном выпуске Debian, он есть только в тестируемом выпуске/Lenny.

В основной ветке разработки опубликован анализ ключей, созданных на системах с недостаточно случайным PRNG. Вы можете ознакомиться с подробностями здесь.

Если PRNG в вашем OpenSSL недостаточно случаен, вам следует выполнить следующее:

cryptsetup

Cryptsetup сам по себе не использует для шифрования openssl (эти применимо и к устройствам LUKS, и к устройствам dm-crypt).

Если cryptsetup был настроен на использование файлов с ключами, зашифрованными с помощью SSL (настройка не по умолчанию, которая должна быть явным образом изменена пользователем), и для создания файла ключей была использована сломанная версия openssl, шифрование файла ключей может быть менее стойко, чем это ожидалось (поскольку криптографическая соль не является по-настоящему случайными данными).

В качестве решения можно либо заново зашифровать файл ключей (если вы достаточно уверены, что зашифрованный файл не был раскрыт каким-либо третьим лицом), либо очистить и переустановить уязвимый раздел (-ы), используя новый ключ.

Инструкции о том, как заново зашифровать файл ключей:

Выполните следующие действия для каждого файла ключей, зашифрованного SSL, заменив <путь_к_зашифрованному_ssl_ключу> путём к фактическому файлу ключей: 

tmpkey=$(tempfile)
openssl enc -aes-256-cbc -d -salt -in <путь_к_зашифрованному_ssl_ключу> -out "$tmpkey"
shred -uz <путь_к_зашифрованному_ssl_ключу>
openssl enc -aes-256-cbc -e -salt -in "$tmpkey" -out <путь_к_зашифрованному_ssl_ключу>
shred -uz "$tmpkey"

dropbear

Если у вас имеются ключи /etc/ssh/*host*, то либо удалите их, либо до обновления ключей dropbear выполните инструкции для openssh.

Сценарии, выполняющиеся после установки dropbear, преобразуют существующие ключи openssh в формат dropbear, если они не могут найти ключи узла dropbear. 

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

Заметьте, что ключи, созданные самим dropbear, не подвержены уязвимости (он использует libtomcrypt, а не OpenSSL).

ekg

Пользователи программ ekg или ekg2 (последняя имеется только в экспериментальном выпуске), использующие функциональность шифрования SIM и создавшие пару ключей, используя команду /key [-g|--generate] (которая использует для этого libssl), должны заново создать эти ключи после обновления libssl и перезапустить программу.

Разработчики основной ветки разместили на своём веб-сайте заметку: http://ekg.chmurka.net/index.php

Если вам требуется дальнейшая помощь, задайте вопрос в ekg-users@lists.ziew.org или ekg2-users@lists.ziew.org (оба списка и на английском, и на польском языках).

ftpd-ssl

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

Это подходит для настройки по умолчанию. Если администратор до этого дополнительно настроил инфраструктуру SSL, эти ключи также следует создать заново.

gforge

Пакет gforge-web-apache2 в sid и lenny настраивает веб-сайт с временным сертификатом в том случае, если не были найдены существующие сертификаты. Позже пользователям следует заменить его действительным сертификатом. Этот временный сертификат выпущен для Snake Oil, поэтому он уже известен как нестойкий сертификат (даже без этой ошибки SSL), но некоторые пользователи могут принять его без задней мысли.

MIT Kerberos (krb5)

Ни одна часть MIT Kerberos в Debian 4.0 (Etch) не использует OpenSSL, и поэтому Kerberos в Debian 4.0 вообще не подвержен этой уязвимости.

В Lenny отдельный двоичный пакет krb5-pkinit использует OpenSSL. MIT Kerberos сам по себе не создаёт долговременных пар ключей, даже когда используется расширение PKINIT, поэтому любые уязвимые долговременные пары ключей должны были быть созданы не с помощью ПО MIT Kerberos. Расширение PKINIT лишь указывает существующие пары ключей и не ответственно за управление ключами.

Долговременные пары ключей, используемые с PKINIT, могут быть уязвимы в том случае, если они были созданы на уязвимой системе Debian, но это создание ключей является внешним по отношению к MIT Kerberos.

Тем не менее, функции случайных чисел OpenSSL используются для DH-обмена, когда используется авторизация PKINIT, что означает, что атакующий может использовать атаку перебором для получения доступа к ответу KDC на авторизацию PKINIT и в последствии может получить доступ к любой сессии, созданной с использованием сервисных билетов этой авторизации.

Любые KDC, использующие расширение PKINIT из Lenny должны немедленно обновить пакеты libssl0.9.8 и перезапустить Kerberos KDC с помощью следующей команды: 

/etc/init.d/krb5-kdc restart

Всякие билеты Kerberos, дающие билеты (TGT), или зашифрованные сессии, получающиеся при авторизации PKINIT с использованием Kerberos KDC с уязвимым пакетом libssl, следует рассматривать как подозрительные; возможно, что перехватившие пакеты атакующие смогут скомпрометировать эти ключи и сеансы.

Nessus

Сценарий серверного пакета Nessus (nessusd) после установки создаёт некоторые ключи SSL для безопасного взаимодействия между сервером Nessus и клиентом. Этот канал взаимодействия должен рассматриваться как скомпрометированный, поскольку злоумышленник мог перехватить информацию, которой обмениваются друг с другом сервер и клиент (эта информация включает информацию об уязвимостях удалённых узлов), и потенциально отправить команды на сервер от лица авторизованного пользователя.

Кроме того, если администратор создал либо ключ Nessus CA, либо пользовательский сертификат (с помощью nessus-mkcert-client) для удалённой авторизации на сервере, на котором установлена уязвимая версия OpenSSL, эти ключи следует считать скомпрометированными. Заметьте, что удалённые пользователи с доступом к серверу Nessus могут запускать атаки на серверы, которые им разрешено атаковать, и, если это включено в локальной конфигурации (в Debian этот параметр по умолчанию имеет значение no), загружать расширения, которые могут быть выполнены на сервере Nessus с правами суперпользователя.

Сценарии с настройками сопровождающего создадут заново сертификаты OpenSSL при настройке пакетов, если они не найдут эти сертификаты. Вам нужно удалить сертификаты и создать новые, используя следующие команды:

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

Когда это будет сделано, вам нужно будет удалить старые пользовательские ключи в /var/lib/nessus/users/USERNAME/auth и создать их заново с помощью nessus-mkcert-client. После удаления ключа CA старые ключи будут считаться неправильными.

После того, как будет заново создан ключ CA, вам будет нужно передать вашим пользователям новый сертификат CA, а ваши пользователи должны будут принять новый сертификат сервера Nessus, когда они снова к нему подключатся. Настройки сертификата для старого сервера должны быть автоматически удалены, но вы также можете удалить их вручную, редактируя .nessusrc.cert (если вы используете клиент Nessus) или .openvasrc.cert (если вы используете клиент OpenVAS).

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

Внимание: перезапуск служб ipsec приведёт к закрытию всех открытых в данный момент соединений IPSec, которые, возможно, надо будет перезапустить с другой стороны.

OpenVPN

Сделайте резервную копию ваших файлов секретных ключей. Хотя имена ключей являются случайными, они могут быть обнаружены с помощью команды 

grep secret /etc/openvpn/*.conf

Создайте их заново с использованием 

openvpn --genkey --secret SECRET_FILENAME

Затем скопируйте общие секретные ключи на удалённые узлы и перезапустите VPN на каждом из узлов с помощью команды 

/etc/init.d/openvpn force-reload

Proftpd

Пакет Debian не имеет возможностей создания ключей, поэтому следующие шаги будут необходимы только в том случае, если ключи SSL были созданы внешней программой.

В грядущей загрузке proftpd в нестабильный выпуск будет добавлен шаблон tls.conf с приведённым ниже комментарием.

Заметьте, что создание подписанного самостоятельно сертификата отличается от того, что предлагается в общем разделе об openssl, для того, чтобы избежать использование явного пароля при запуске службы.

Вы можете создать заново подписанный самостоятельно сертификат, используя следующую команду: 

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

Оба файла должны быть доступны для чтения только суперпользователю. Пути файлов можно проверить/настроить через следующие директивы настройки: 

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

puppet

Имеется два способа работы с сертификатами puppet, первый — через capistrano, второй — вручную.

Создание заново сертификатов SSL для Puppet, используя capistrano, подробно описано здесь: http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL

Для создания сертификатов заново вручную, выполните следующие шаги:

  1. Вам нужно удалить и создать заново вашу информацию CA: 
    /etc/init.d/puppetmaster stop
rm -rf $vardir/ssl/*
/etc/init.d/puppetmaster start

    Тем не менее, если у вас запущен mongrel, вместо того, чтобы запускать puppetmaster с помощью сценария инициализации, вам нужно будет сначала остановить интерфейс веб-сервера (apache, nginx и т.д.), а затем выполнить следующую команду: 

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

    Приведённая выше команда необходима потому, что если запущен mongrel, puppetmaster не будет создавать CA.

  2. Очистите клиентские сертификаты 
    /etc/init.d/puppet stop
rm $vardir/ssl/*
  3. Каждый клиент должен запросить новый сертификат: 
    puppetd --onetime --debug --ignorecache --no-daemonize
  4. Когда все запросы получены, вы можете одновременно подписать их: 
    puppetca --sign --all
  5. Запустите ваши puppet-клиенты: 
    /etc/init.d/puppet start

Также вам следует временно включить autosign, если вам это подходит.

sendmail

Sendmail (и в Etch, и в Lenny) во время установки может создавать сертификаты OpenSSL по умолчанию.

Замена ключа тривиальна: 

/usr/share/sendmail/update_tls new

Если у вас имеются настроенные шаблоны в /etc/mail/tls, их значения будут использованы для создания новых сертификатов.

ssl-cert

Сертификат /etc/ssl/certs/ssl-cert-snakeoil.pem может быть создан заново с помощью следующей команды: 

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

Это подходит для настройки по умолчанию. Если локальный администратор дополнительно настроил инфраструктуру SSL, эти ключи также следует создать заново.

tinc

Удалите все подозрительные публичные и частные файлы ключей:

  1. Удалите rsa_key.priv.
  2. Отредактируйте все файлы в каталоге hosts/ и удалите блоки публичных ключей.

Создайте новую пару ключей (публичный/частный): 

tincd -n <netname> -K

Обменяйтесь файлом настройки вашего узла, содержащим новый публичный ключ, с другими членами вашей VPN. Не забудьте перезапустить ваши службы tinc.

tor

Tor отсутствует в стабильном выпуске, но версия из Lenny уязвима.

Клиенты с запущенной версией 0.1.2.x не подвержены уязвимости. Узлы Tor или скрытые поставщики сервиса с любой запущенной версией, а также любой с версией 0.2.0.x подвержены уязвимости.

См. сообщение об уязвимости в списке рассылки объявлений Tor.

Рекомендуется обновиться до версии 0.1.2.19-3 (доступна в тестируемом выпуске, нестабильном выпуске, backports.org и в обычном репозитории noreply.org) или 0.2.0.26-rc-1 (доступна в экспериментальном выпуске и обычном репозитории noreply.org). Если у вас запущен транслятор, установка этих версий приведёт к созданию новых серверных ключей (/var/lib/tor/keys/secret_*).

Если вам нужно запускать узел Tor без использования инфраструктуры пакета (пользователь debian-tor, /var/lib/tor как DataDirectory и т.д.), вам нужно будет вручную удалить плохие ключи. См. ссылку на рекомендацию, приведённую выше.

Если вы являетесь скрытым поставщиком сервиса и создали свой собственный ключ с помощью уязвимой libssl, то удалите частный ключ вашего скрытого сервиса. Это изменит имя узла вашего скрытого сервиса и может потребовать перенастройки ваших серверов.

Если у вас запущена версия 0.2.0.x, настоятельно рекомендуем обновиться — 3 из 6 v3 серверов авторизации имеют скомпрометированные ключи. Старые версии 0.2.0.x перестанут работать в течении недели или двух.

xrdp

xrdp использует созданные ключи. Большинство клиентов по умолчанию не проверяет эти ключи, следовательно их изменение безболезненно. Вам лишь нужно выполнить следующие команды: 

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

xrdp отсутствует в стабильном выпуске.