Пользователь
0,0
рейтинг
9 апреля 2014 в 06:18

Разработка → Справочник по уязвимости OpenSSL Heartbleed

Что может узнать атакующий


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

Уязвимость двусторонняя: если уязвимый клиент подключается к серверу злоумышленника, то злоумышленник может читать память процесса клиента. Пример уязвимых клиентов: MariaDB, wget, curl, git, nginx (в режиме прокси).

Как протестировать уязвимость


Веб-сервисы:
filippo.io/Heartbleed,
www.ssllabs.com/ssltest,
rehmann.co/projects/heartbeat,
possible.lv/tools/hb.
Тест для клиента: reverseheartbleed.com
Скрипт на Python: gist.github.com/sh1n0b1/10100394, gist.github.com/mitsuhiko/10130454
Скрипт на Go: github.com/titanous/heartbleeder
Статистика по сайтам: gist.github.com/dberkholz/10169691

Какие системы подвержены уязвимости


— Уязвимы OpenSSL 1.0.1 — 1.0.1f, 1.0.2-beta1, уязвимость исправлена в OpenSSL 1.0.1g и 1.0.2-beta2 (secadv).
— OpenVPN, в том числе и под Windows — исправлено в версии I004 (загрузка)
— Любые программы, статически слинкованные с уязвимой версией OpenSSL.
— Tor (блог).

— Debian Wheezy (stable) — исправлено в OpenSSL 1.0.1e-2+deb7u5 и 1.0.1e-2+deb7u6 (security)
— Ubuntu 12.04.4 LTS — исправлено в OpenSSL 1.0.1-4ubuntu5.12 (USN)
— CentOS 6.5 — исправлено в openssl-1.0.1e-16.el6_5.7 (centos-announce)
— Redhat 6.5 — исправлено в openssl-1.0.1e-16.el6_5.7 (solutions, errata, bugzilla)
— Fedora 19 и 20 — исправлено в openssl-1.0.1e-37 (announce)
— Gentoo — исправлено в openssl-1.0.1g (GLSA)
— Slackware 14.0 и 14.1 — исправлено в openssl-1.0.1g (slackware-security)
— OpenSUSE 12.3 и 13.1 — исправлено в openssl-1.0.1e (opensuse-security-announce)
— FreeBSD 10.0 — исправлено в 10.0-RELEASE-p1 (advisories)
— OpenBSD 5.3 и 5.4 (patch)
— NetBSD 5.0.2
— Amazon — исправлено в OpenSSL 1.0.1e-37.66 (security-bulletins)
— Android 4.1.1 — остальные версии без уязвимости.

Обычно зависят от уязвимой библиотеки и требуют перезапуска:
— Веб-серверы: Nginx, Apache, почтовые серверы: Postfix, Dovecot, Jabber и прочие IM: ejabberd,
— MySQL, если используется TLS для авторизации и он зависит от OpenSSL: в CentOS, RedHat (включая Remi), Percona Server (blog).

Что не подвержено уязвимости


— Windows (нет OpenSSL), MacOS (старая версия OpenSSL), Firefox, Thunderbird (по умолчанию использует NSS), Chrome/Chromium (по умолчанию использует NSS), Android (отключен heartbeat).
— Корневые и промежуточные сертификаты, которыми подписаны ключи TLS сервера (приватные ключи от них отсутствуют на сервере)
— OpenSSH (использует OpenSSL только для генерации ключей)
— OpenVPN, если использует статические ключи (не x509) или если использует в конфиге ключ вида «tls-auth ta.key 1»
— Метод распространения обновлений Unix-like ОС (чаще всего используется GnuPG для подписи).

Как обновить систему


Debian, Ubuntu

# aptitude update
# aptitude -VR full-upgrade

После этого полностью перезапустить сервисы, которые используют TLS. Установщик обновления предложит перезапустить автоматически, или можно вручную:
# service nginx restart
# service apache2 restart

Полный список сервисов, которые нуждаются в перезапуске и могут быть уязвимы:
# lsof -n | grep -iE 'del.*(libssl\.so|libcrypto\.so)'
или
# checkrestart

Если не уверены, лучше полностью перезагрузить сервер.
Проверка версии:
# dpkg -l | grep -i openssl
# aptitude changelog openssl


CentOS, RedHat, Fedora


# yum update

После этого полностью перезапустить сервисы, которые используют TLS, например:
# service nginx restart
# service httpd restart

Полный список сервисов, которые нуждаются в перезапуске и могут быть уязвимы:
# lsof -n | grep -iE 'del.*(libssl\.so|libcrypto\.so)'
или
# needs-restarting

Если не уверены, лучше полностью перезагрузить сервер.
Проверка версии:
# yum list openssl
# rpm -q --changelog openssl


FreeBSD


# freebsd-update fetch
# freebsd-update install

После этого полностью перезапустить сервисы, которые используют TLS, например:
# service nginx restart
# service apache22 restart

Если не уверены, лучше полностью перезагрузить сервер.
Проверка версии:
# freebsd-version


Отзыв TLS ключей и смена паролей


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

— Если браузер клиентов передавал пароли на сайт без hash+salt, а в чистом виде, то эти пароли также могут быть скомпрометированы.

На будущее


— Нужно убедиться, что браузер проверяет, не отозван ли сертификат сайта, который он посещает.
Firefox по умолчанию проверяет OSCP, а последние версии также поддерживают OCSP Stapling; Safari проверяет по умолчанию с версии Mac OS X 10.7 (Lion); Chrome не проверяет по умолчанию (в настройках раздел HTTPS/SSL), OCSP Stapling не поддерживается; Internet Explorer по умолчанию проверяет OSCP, но не поддерживает OCSP Stapling; Opera проверяет OSCP по умолчанию; Safari не проверяет OSCP по умолчанию. Настройки разных браузеров.

— На сервере желательно включить Perfect forward secrecy (PFS). При этом даже при компрометации приватного ключа злоумышленник не сможет расшифровать прошлый или будущий подслушанный трафик. Для этого нужно включить Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) или Diffie-Hellman Ephemeral (DHE). Настройка сервера, тестирование.
Иван Ванюшкин @Vanav
карма
62,4
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (46)

  • 0
    Странно http://filippo.io/Heartbleed/ говорит что все гуд, а http://rehmann.co/projects/heartbeat/ сообщает печальные новости
    • +1
      А что говорит www.ssllabs.com/ssltest/?
      • +1
        «Invalid domain name» — видимо не умеет работать с ip
    • +1
      Это нормально: первый сервис проверяет конкретно наличие уязвимости в реализации heartbeat, а второй — лишь поддержку heartbeat в целом.
  • 0
    Как страшно жить. И вроде в паблике сплоит, который всего лишь сливает 16кб памяти процесса, но даже в этом небольшом кусочке дампа попадается более, чем чувствительная информация. Какие есть способы дополнительной защиты от подобных ситуаций?
    • +4
      16кб памяти ЗА РАЗ.
      • 0
        Так все 64 же.
        • +2
          Где можно посмотреть, как затребовать упаковку пакета? Или так — какие именно версии отдают больше 16к?
  • –11
    Opera (по крайней мере старых версий, по 12 включительно) проверяет статус сертификата по умолчанию. Она вообще всегда была самой параноидальной в этом плане.
  • 0
    1.0.1e-2+deb7u4 — нет, в 1.0.1e-2+deb7u5
    • 0
      Спасибо, исправил.
  • –8
    Может проще было просто эту ссылку оставить? heartbleed.com
  • 0
    Что-то у меня на домашнем сервере с Proxmox не хочет обновляться. Aptitude пишет, что версия последняя — 1.0.1e.
  • +7
    Не забывайте, что в некоторых системах (например, Ubuntu и Debian) пакет openssl на самом деле разбит на два: openssl + libssl*, и в openssl на самом деле лежат только утилиты. Так что, если вы опасаетесь сразу накатывать все апдейты через full-upgrade, обновлять обязательно надо оба пакета, openssl и libssl1.0.0.
  • +1
    На сервере желательно включить Perfect forward secrecy (PFC). При этом даже при компрометации приватного ключа злоумышленник не сможет расшифровать прошлый или будущий подслушанный трафик. Для этого нужно включить Elliptic curve Diffie–Hellman (ECDH). Протестировать можно здесь: www.ssllabs.com/ssltest/
    1. PFS, а не PFC;
    2. не «прошлый и будущий», а только прошлый, и то, есть нюансы; будущий расшифровывается при mitm;
    3. не любая ECDH подходит, а только ephemeral ECDH, в шифрсьютах их называют ECDHe;
    4. подходит, не только ECDH, а и ephemeral DH, в шифрсьютах он называется EDH.
    • +1
      1. Спасибо, исправил.
      2. В этом контексте нет MITM, а есть утечка приватного ключа. Используя только приватный ключ нельзя расшифровать пакеты при PFS.
      3. Верно, исправил.
      4. Вообще, да, но ECDHE считается более производительным, чем DHE.
  • +2
    Про FreeBSD написано что уязвимы версия FreeBSD 10 и head (то есть разрабатываемая версия FreeBSD 11), а во FreeBSD 8/9 ведь старый openssl 0.9.8 (можно посмотреть командой openssl version)

    Или все-таки 8я и 9я FreeBSD уязвимы?

    www.freebsd.org/security/advisories/FreeBSD-SA-14:06.openssl.asc
    The code used to handle the Heartbeat Extension does not do sufficient boundary checks on record length, which allows reading beyond the actual payload. [CVE-2014-0160]. Affects FreeBSD 10.0 only.

    lists.freebsd.org/pipermail/freebsd-announce/2014-April/001541.html
    FreeBSD base system have been patched on 2014-04-08 18:27:32 UTC (head, r264265), 2014-04-08 18:27:39 UTC (stable/10, r264266), 2014-04-08 18:27:46 UTC (releng/10.0, r264267). The update is available with freebsd-update. All other supported FreeBSD branches are not affected by this issue.
    • 0
      Просто по какой-то причине многие админы столкнулись с тем, что сайт filippo.io выдает информацию о том, что их веб-сервера на FreeBSD 8 уязвимы
    • +1
      FreeBSD 8 и 9 не подвержены уязвимости, если, конечно, не устанавливался OpenSSL из портов или пакетов. По первой ссылке указаны и старые версии, поскольку этот advisory про две уязвимости в OpenSSL. На heartbleed.com были ошибочно указаны и версии 8 и 9, потом исправили.
  • +1
    Жалко нет сервиса для тестирования уязвимостей в клиентах, а не в серверах.
  • +8
    Just for fan I'll put it here :)

    image
    • +18
      Для вентилятора?
      • +3
        О нет, у меня так давно не было веселья, что даже допустил опечатку!)
      • +1
        Можно и так сказать :-)
  • 0
    OpenWrt Backfire 10.03 и старше не содержит уязвимую версию.

    OpenWrt Attitude Adjustment 12.09 уязвим, чиним устанавливая обновленный пакет из snapshot/trunk

    добавить в начало /etc/opkg.conf (подставьте свою архитектуру вместо ar71xx)
    src/gz trunk http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages

    выполнить
    opkg update
    opkg upgrade libopenssl openssl-util

    reboot
  • 0
    Вопрос: имеется сервер на котором бегает ubuntu 13.04, на сайте вендора говорят что эта версия не подвержена уязвимости, однако все детекторы (онлайн и скрипты) говорят что сервер уязвим. сделал апдейт/полный апгрейд, не помогло… мне надо начинать паниковать?
    • +1
      Да, можете начинать паниковать. Если не хотите апгрейдиться до 13.10, то переберите пакет, который у вас установлен (скорее всего это 1.0.1с), с флагом -DOPENSSL_NO_HEARBEATS.

      Примерно вот так.

      sudo apt-get install build-essential fakeroot dpkg-dev devscripts
      apt-get source openssl
      sudo apt-get build-dep openssl
      cd openssl-1.0.1c
      dch -i
      


      Измените в верхней строке UNRELEASED на raring-security (можете для пафоса и urgency=low на urgency=critical). После * в третьей строке можете написать что душа пожелает.

        * SECURITY UPDATE: memory disclosure in TLS heartbeat extension
          - CVE-2014-0160
      

      … будет прекрасным вариантом :)

      Потом добавьте флаг для компиляции, например:

      vim debian/rules
      


      Найдите CONFARGS и добавьте туда -DOPENSSL_NO_HEARTBEATS, примерно так.

      --- openssl-1.0.1c/debian/rules.orig	2014-04-10 14:54:42.010985253 +0400
      +++ openssl-1.0.1c/debian/rules	2014-04-10 14:55:10.710985431 +0400
      @@ -35,7 +35,7 @@
        ARCH_CONFARGS := enable-ec_nistp_64_gcc_128
       endif
       
      -CONFARGS  = --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) no-idea no-mdc2 no-rc5 zlib  enable-tlsext no-ssl2 $(ARCH_CONFARGS)
      +CONFARGS  = --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) no-idea no-mdc2 no-rc5 zlib  enable-tlsext no-ssl2 -DOPENSSL_NO_HEARTBEATS $(ARCH_CONFARGS)
       OPT_alpha = ev4 ev5
       ARCHOPTS  = OPT_$(DEB_HOST_ARCH)
       OPTS      = $($(ARCHOPTS))
      


      И собирайте-устанавливайте пакет.

      dpkg-buildpackage -rfakeroot -uc -b
      cd ..
      sudo dpkg -i libssl1.0.0_1.0.1c-4ubuntu8.3_amd64.deb  libssl-dev_1.0.1c-4ubuntu8.3_amd64.deb  libssl-doc_1.0.1c-4ubuntu8.3_all.deb  openssl_1.0.1c-4ubuntu8.3_amd64.deb
      # или
      sudo dpkg -i *.deb
      


      Можно было бы выложить для вас готовые собранные пакеты, но ведь это неправильный путь, устанавливать что попало, взятое у незнакомого чувака на Хабре :)
      • 0
        Да, устанавливать собраный пакет я бы не решился, спасибо большое за развернутый ответ, как собрать разберусь.
        С меня плюс, как только выберусь из кармадыры)
  • 0
    А Приватбанк все еще уязвим -_-
  • 0
    Если браузер клиентов передавал пароли на сайт без hash+salt, а в чистом виде, то эти пароли также могут быть скомпрометированы.

    Скажите пожалуйста, где можно почитать про такой способ аутентификации? Не очень понимаю механизм.
    • 0
      Можете пояснить, что именно не ясно?
      POST запрос, например, из формы.
      Или же Basic access authentication — там пароль тоже в открытом виде. en.wikipedia.org/wiki/Basic_access_authentication
      • 0
        Мне непонятно, что делать на сервере с хэшем пароля. Как его валидировать.
        • 0
          Например, вот так: ru.wikipedia.org/wiki/CHAP
          • 0
            Сервер, которому доступен пароль пользователя...

            Я думаю, что довольно опасно хранить на сервере пароль пользователя. Могут украсть.
    • 0
      Для аутентификации теоретически не нужно передавать пароль, достаточно дать знать, что и сервер и клиент знают один и тот же пароль, канал передачи данных не получает никакой информации о пароле. Для этого существуют протоколы Zero-knowledge password proof: Secure Remote Password protocol (внизу практические реализации) и Encrypted key exchange.

      Если таких строгих требований — не выдать ни бита информации — нет, то можно придумать что-то проще: сервер генерирует случайное число и передаёт в браузер, браузер рассчитывает HMAC от пароля (ключ k) и полученного числа (сообщение m), сервер рассчитывает то же самое от известного пароля и сверяет с полученным от браузера.

      По сети ходит только хеш, каждый раз новый, и два раза один и тот же хеш не подходит (защита от replay attack), активный атакующий также не сможет собрать достаточно информации, поскольку, зная много пар (m, t), невозможно вычислить ключ k, удовлетворяющий условию HMAC(k, m) = t.
      • 0
        сервер рассчитывает то же самое от известного пароля

        Я думаю, что довольно опасно хранить на сервере пароль пользователя. Могут украсть.
        • 0
          Можно хранить хеш на сервере, и его же рассчитывать на клиенте — этот хеш будет ключом.
          • 0
            Прости, потерял мысль. На сервере хранится хэш от пароля, сервер генерирует случайное число и передаёт в браузер, дальше что происходит?
            • 0
              Попробуем собрать полную схему из криптографических примитивов.

              Существует стандартная схема PBKDF2, которой на вход передаётся пароль, соль и число итераций, на выходе получаем хеш много раз от пароля с солью. Используем DK = PBKDF2(HMAC−SHA512, passphrase, salt, 1000 /* число итераций */, 512 /* длина результата */), при регистрации пользователя в БД сохраняем строку PBKDF2-HMAC-SHA512:1000:salt:DK.

              При логине клиенту передаём строку из БД, кроме самого хеша: PBKDF2-HMAC-SHA512:1000:salt. Клиент рассчитывает DK, зная алгоритм, число итераций, соль, и пароль, введённый пользователем. Полученное значение уже можно передавать на сервер и сравнивать с БД, но тогда любой, кто сможет один раз подслушать канал связи, сможет авторизоваться любое число раз.

              Поэтому пусть сервер сначала придумает случайный session_id, запомнит его и передаст клиенту: session_id и PBKDF2-HMAC-SHA512:1000:salt. Клиент не будет передавать DK, а рассчитает HMAC-SHA512(DK, session_id) и передаст результат. Сервер рассчитает ту же самую функцию и сравнит с данными, полученными от клиента.
              • 0
                Правильно я понимаю, что, украв базу DK с сервера, я смогу представляться пользователем?
                • 0
                  Да, это минус этого алгоритма.

                  Улучшим. DK рассчитывается как и ранее, но в БД сохраняем хеш от него: на сервере храним "PBKDF2-HMAC-SHA512":"1000":salt:H(DK).
                  1) Клиент передаёт на сервер: логин.
                  2) Сервер передаёт клиенту: случайный session_id, salt, 1000 — из БД.
                  3) Клиент рассчитывает DK и HMAC и передаёт серверу XOR этих двух значений: response = HMAC(H(DK), session-id) XOR DK.
                  4) Сервер также рассчитывает HMAC и делает XOR с ответом клиента, чтобы восстановить DK': DK' = HMAC(H(DK), session-id) XOR response, при этом H(DK) сервер берёт из БД. Дальше сервер рассчитывает H(DK') и сравнивает со значением в БД.

                  Так мы получим нужные нам свойства: компрометация БД не позволит залогиниться на сайте или узнать пароль, пароль не передаётся по сети, один и тот же ответ клиента нельзя использовать дважды для логина.

                  Также в этот алгоритм можно добавить не только авторизацию клиента, но и авторизацию сервера: клиент убеждается, что сервер знает какой-то секрет, хранимый в БД. Подробнее такая реализация описана в RFC 5802: SCRAM.

                  Слабое место алгоритма: если скомпрометирована БД, и при этом подслушан трафик настоящего клиента, то можно восстановить DK, а значит и авторизоваться как этот клиент. Но это будет работать только для этого конкретного сайта. Ещё одна угроза: если злоумышленник подслушает трафик, он может начать offline brute force атаку с целью поиска пароля, но от этого защищают только упоминавшиеся ранее алгоритмы SRP или EKE.
                  • 0
                    зачем выдумывать, если есть SRP-6?
                    • 0
                      Я уже упоминал SRP. SCRAM — это более простой и наглядный алгоритм, который может защитить процесс авторизации от прослушивания канала. Если есть ещё алгоритмы с такими же свойствами, которые ещё не упоминались, то напишите.
  • 0
    Synology уже пофиксили.

    Version: 5.0-4458 Update 2

    (2014/04/10)
    Change Log

    Fixed a critical security issue of OpenSSL (heartbleed) to prevent secret keys from being compromised. (CVE-2014-0160)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.