Vanav 9 апр 2014 в 02:18

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

4 мин

60K

Информационная безопасность * Криптография *

+59

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

nightw0rk 9 апр 2014 в 03:36

Странно http://filippo.io/Heartbleed/ говорит что все гуд, а http://rehmann.co/projects/heartbeat/ сообщает печальные новости

DarkByte 9 апр 2014 в 03:37

А что говорит www.ssllabs.com/ssltest/?

nightw0rk 9 апр 2014 в 03:40

«Invalid domain name» — видимо не умеет работать с ip

ximaera 9 апр 2014 в 16:15

Это нормально: первый сервис проверяет конкретно наличие уязвимости в реализации heartbeat, а второй — лишь поддержку heartbeat в целом.

DarkByte 9 апр 2014 в 03:37

Как страшно жить. И вроде в паблике сплоит, который всего лишь сливает 16кб памяти процесса, но даже в этом небольшом кусочке дампа попадается более, чем чувствительная информация. Какие есть способы дополнительной защиты от подобных ситуаций?

cjmaxik 9 апр 2014 в 04:22

16кб памяти ЗА РАЗ.

Triang3l 9 апр 2014 в 09:13

Так все 64 же.

dei 9 апр 2014 в 10:17

Где можно посмотреть, как затребовать упаковку пакета? Или так — какие именно версии отдают больше 16к?

institor 9 апр 2014 в 04:43

Opera (по крайней мере старых версий, по 12 включительно) проверяет статус сертификата по умолчанию. Она вообще всегда была самой параноидальной в этом плане.

datacompboy 9 апр 2014 в 04:45

1.0.1e-2+deb7u4 — нет, в 1.0.1e-2+deb7u5

Vanav 9 апр 2014 в 05:51

Спасибо, исправил.

IamKarlson 9 апр 2014 в 05:23

Может проще было просто эту ссылку оставить? heartbleed.com

TheSteelRat 9 апр 2014 в 05:43

Что-то у меня на домашнем сервере с Proxmox не хочет обновляться. Aptitude пишет, что версия последняя — 1.0.1e.

ToSHiC 9 апр 2014 в 05:48

Не забывайте, что в некоторых системах (например, Ubuntu и Debian) пакет openssl на самом деле разбит на два: openssl + libssl*, и в openssl на самом деле лежат только утилиты. Так что, если вы опасаетесь сразу накатывать все апдейты через full-upgrade, обновлять обязательно надо оба пакета, openssl и libssl1.0.0.

НЛО прилетело и опубликовало эту надпись здесь

Vanav 9 апр 2014 в 07:01

1. Спасибо, исправил.
2. В этом контексте нет MITM, а есть утечка приватного ключа. Используя только приватный ключ нельзя расшифровать пакеты при PFS.
3. Верно, исправил.
4. Вообще, да, но ECDHE считается более производительным, чем DHE.

litos 9 апр 2014 в 07:10

Про 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.

litos 9 апр 2014 в 07:15

Просто по какой-то причине многие админы столкнулись с тем, что сайт filippo.io выдает информацию о том, что их веб-сервера на FreeBSD 8 уязвимы

Vanav 9 апр 2014 в 07:18

Возможно, проблема самого сервиса: filippo.io/Heartbleed/faq.html

Vanav 9 апр 2014 в 07:16

FreeBSD 8 и 9 не подвержены уязвимости, если, конечно, не устанавливался OpenSSL из портов или пакетов. По первой ссылке указаны и старые версии, поскольку этот advisory про две уязвимости в OpenSSL. На heartbleed.com были ошибочно указаны и версии 8 и 9, потом исправили.

vsespb 9 апр 2014 в 07:22

Жалко нет сервиса для тестирования уязвимостей в клиентах, а не в серверах.

Vanav 10 апр 2014 в 14:36

Есть: reverseheartbleed.com

luckyredhot 9 апр 2014 в 08:56

Just for fan I'll put it here :)

Daemon_Hell 9 апр 2014 в 10:29

Для вентилятора?

luckyredhot 9 апр 2014 в 11:33

О нет, у меня так давно не было веселья, что даже допустил опечатку!)

ximaera 9 апр 2014 в 16:17

Можно и так сказать :-)

Vayun 9 апр 2014 в 09:35

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

НЛО прилетело и опубликовало эту надпись здесь

cadmi 10 апр 2014 в 11:02

Да, можете начинать паниковать. Если не хотите апгрейдиться до 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

Можно было бы выложить для вас готовые собранные пакеты, но ведь это неправильный путь, устанавливать что попало, взятое у незнакомого чувака на Хабре :)

НЛО прилетело и опубликовало эту надпись здесь

sockeye 9 апр 2014 в 20:59

А Приватбанк все еще уязвим -_-

glader 10 апр 2014 в 03:57

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

Скажите пожалуйста, где можно почитать про такой способ аутентификации? Не очень понимаю механизм.

dei 10 апр 2014 в 07:13

Можете пояснить, что именно не ясно?
POST запрос, например, из формы.
Или же Basic access authentication — там пароль тоже в открытом виде. en.wikipedia.org/wiki/Basic_access_authentication

glader 10 апр 2014 в 07:19

Мне непонятно, что делать на сервере с хэшем пароля. Как его валидировать.

ToSHiC 10 апр 2014 в 09:06

Например, вот так: ru.wikipedia.org/wiki/CHAP

glader 10 апр 2014 в 09:09

Сервер, которому доступен пароль пользователя...

Я думаю, что довольно опасно хранить на сервере пароль пользователя. Могут украсть.

Vanav 10 апр 2014 в 13:58

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

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

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

glader 10 апр 2014 в 14:33

сервер рассчитывает то же самое от известного пароля

Я думаю, что довольно опасно хранить на сервере пароль пользователя. Могут украсть.

Vanav 10 апр 2014 в 14:37

Можно хранить хеш на сервере, и его же рассчитывать на клиенте — этот хеш будет ключом.

glader 10 апр 2014 в 14:42

Прости, потерял мысль. На сервере хранится хэш от пароля, сервер генерирует случайное число и передаёт в браузер, дальше что происходит?

Vanav 10 апр 2014 в 17:37

Попробуем собрать полную схему из криптографических примитивов.

Существует стандартная схема 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) и передаст результат. Сервер рассчитает ту же самую функцию и сравнит с данными, полученными от клиента.

glader 10 апр 2014 в 17:57

Правильно я понимаю, что, украв базу DK с сервера, я смогу представляться пользователем?

Vanav 11 апр 2014 в 01:26

Да, это минус этого алгоритма.

Улучшим. 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.

datacompboy 11 апр 2014 в 05:47

зачем выдумывать, если есть SRP-6?

Vanav 11 апр 2014 в 14:14

Я уже упоминал SRP. SCRAM — это более простой и наглядный алгоритм, который может защитить процесс авторизации от прослушивания канала. Если есть ещё алгоритмы с такими же свойствами, которые ещё не упоминались, то напишите.

Soulveig 11 апр 2014 в 06:22

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)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий