Vanav Apr 9 2014 at 06:18

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

4 min

60K

Information Security*Cryptography*

+60

Comments 46

nightw0rk Apr 9 2014 at 07:36

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

DarkByte Apr 9 2014 at 07:37

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

nightw0rk Apr 9 2014 at 07:40

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

ximaera Apr 9 2014 at 20:15

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

DarkByte Apr 9 2014 at 07:37

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

cjmaxik Apr 9 2014 at 08:22

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

Triang3l Apr 9 2014 at 13:13

Так все 64 же.

dei Apr 9 2014 at 14:17

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

institor Apr 9 2014 at 08:43

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

datacompboy Apr 9 2014 at 08:45

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

Vanav Apr 9 2014 at 09:51

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

IamKarlson Apr 9 2014 at 09:23

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

TheSteelRat Apr 9 2014 at 09:43

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

ToSHiC Apr 9 2014 at 09:48

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

UFO just landed and posted this here

Vanav Apr 9 2014 at 11:01

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

litos Apr 9 2014 at 11: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 Apr 9 2014 at 11:15

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

Vanav Apr 9 2014 at 11:18

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

Vanav Apr 9 2014 at 11:16

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

vsespb Apr 9 2014 at 11:22

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

Vanav Apr 10 2014 at 18:36

Есть: reverseheartbleed.com

luckyredhot Apr 9 2014 at 12:56

Just for fan I'll put it here :)

Daemon_Hell Apr 9 2014 at 14:29

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

luckyredhot Apr 9 2014 at 15:33

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

ximaera Apr 9 2014 at 20:17

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

Vayun Apr 9 2014 at 13: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

UFO just landed and posted this here

cadmi Apr 10 2014 at 15: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

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

UFO just landed and posted this here

sockeye Apr 10 2014 at 00:59

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

glader Apr 10 2014 at 07:57

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

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

dei Apr 10 2014 at 11:13

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

glader Apr 10 2014 at 11:19

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

ToSHiC Apr 10 2014 at 13:06

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

glader Apr 10 2014 at 13:09

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

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

Vanav Apr 10 2014 at 17: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 Apr 10 2014 at 18:33

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

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

Vanav Apr 10 2014 at 18:37

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

glader Apr 10 2014 at 18:42

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

Vanav Apr 10 2014 at 21: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 Apr 10 2014 at 21:57

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

Vanav Apr 11 2014 at 05: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 Apr 11 2014 at 09:47

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

Vanav Apr 11 2014 at 18:14

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

Soulveig Apr 11 2014 at 10: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)