Comments 46
Странно http://filippo.io/Heartbleed/ говорит что все гуд, а http://rehmann.co/projects/heartbeat/ сообщает печальные новости
0
А что говорит www.ssllabs.com/ssltest/?
+1
Это нормально: первый сервис проверяет конкретно наличие уязвимости в реализации heartbeat, а второй — лишь поддержку heartbeat в целом.
+1
Как страшно жить. И вроде в паблике сплоит, который всего лишь сливает 16кб памяти процесса, но даже в этом небольшом кусочке дампа попадается более, чем чувствительная информация. Какие есть способы дополнительной защиты от подобных ситуаций?
0
Opera (по крайней мере старых версий, по 12 включительно) проверяет статус сертификата по умолчанию. Она вообще всегда была самой параноидальной в этом плане.
-11
1.0.1e-2+deb7u4 — нет, в 1.0.1e-2+deb7u5
0
Может проще было просто эту ссылку оставить? heartbleed.com
-8
Что-то у меня на домашнем сервере с Proxmox не хочет обновляться. Aptitude пишет, что версия последняя — 1.0.1e.
0
Не забывайте, что в некоторых системах (например, Ubuntu и Debian) пакет openssl на самом деле разбит на два: openssl + libssl*, и в openssl на самом деле лежат только утилиты. Так что, если вы опасаетесь сразу накатывать все апдейты через full-upgrade, обновлять обязательно надо оба пакета, openssl и libssl1.0.0.
+7
UFO just landed and posted this here
Про 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.
Или все-таки 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.
+2
Просто по какой-то причине многие админы столкнулись с тем, что сайт filippo.io выдает информацию о том, что их веб-сервера на FreeBSD 8 уязвимы
0
Возможно, проблема самого сервиса: filippo.io/Heartbleed/faq.html
0
FreeBSD 8 и 9 не подвержены уязвимости, если, конечно, не устанавливался OpenSSL из портов или пакетов. По первой ссылке указаны и старые версии, поскольку этот advisory про две уязвимости в OpenSSL. На heartbleed.com были ошибочно указаны и версии 8 и 9, потом исправили.
+1
Жалко нет сервиса для тестирования уязвимостей в клиентах, а не в серверах.
+1
Есть: reverseheartbleed.com
0
Just for fan I'll put it here :)
+8
OpenWrt Backfire 10.03 и старше не содержит уязвимую версию.
OpenWrt Attitude Adjustment 12.09 уязвим, чиним устанавливая обновленный пакет из snapshot/trunk
добавить в начало /etc/opkg.conf (подставьте свою архитектуру вместо ar71xx)
выполнить
reboot
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
UFO just landed and posted this here
Да, можете начинать паниковать. Если не хотите апгрейдиться до 13.10, то переберите пакет, который у вас установлен (скорее всего это 1.0.1с), с флагом -DOPENSSL_NO_HEARBEATS.
Примерно вот так.
Измените в верхней строке UNRELEASED на raring-security (можете для пафоса и urgency=low на urgency=critical). После * в третьей строке можете написать что душа пожелает.
… будет прекрасным вариантом :)
Потом добавьте флаг для компиляции, например:
Найдите CONFARGS и добавьте туда -DOPENSSL_NO_HEARTBEATS, примерно так.
И собирайте-устанавливайте пакет.
Можно было бы выложить для вас готовые собранные пакеты, но ведь это неправильный путь, устанавливать что попало, взятое у незнакомого чувака на Хабре :)
Примерно вот так.
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
Можно было бы выложить для вас готовые собранные пакеты, но ведь это неправильный путь, устанавливать что попало, взятое у незнакомого чувака на Хабре :)
+1
А Приватбанк все еще уязвим -_-
0
Если браузер клиентов передавал пароли на сайт без hash+salt, а в чистом виде, то эти пароли также могут быть скомпрометированы.
Скажите пожалуйста, где можно почитать про такой способ аутентификации? Не очень понимаю механизм.
0
Можете пояснить, что именно не ясно?
POST запрос, например, из формы.
Или же Basic access authentication — там пароль тоже в открытом виде. en.wikipedia.org/wiki/Basic_access_authentication
POST запрос, например, из формы.
Или же Basic access authentication — там пароль тоже в открытом виде. en.wikipedia.org/wiki/Basic_access_authentication
0
Мне непонятно, что делать на сервере с хэшем пароля. Как его валидировать.
0
Например, вот так: ru.wikipedia.org/wiki/CHAP
0
Для аутентификации теоретически не нужно передавать пароль, достаточно дать знать, что и сервер и клиент знают один и тот же пароль, канал передачи данных не получает никакой информации о пароле. Для этого существуют протоколы Zero-knowledge password proof: Secure Remote Password protocol (внизу практические реализации) и Encrypted key exchange.
Если таких строгих требований — не выдать ни бита информации — нет, то можно придумать что-то проще: сервер генерирует случайное число и передаёт в браузер, браузер рассчитывает
По сети ходит только хеш, каждый раз новый, и два раза один и тот же хеш не подходит (защита от replay attack), активный атакующий также не сможет собрать достаточно информации, поскольку, зная много пар
Если таких строгих требований — не выдать ни бита информации — нет, то можно придумать что-то проще: сервер генерирует случайное число и передаёт в браузер, браузер рассчитывает
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
Да, это минус этого алгоритма.
Улучшим.
1) Клиент передаёт на сервер: логин.
2) Сервер передаёт клиенту: случайный
3) Клиент рассчитывает
4) Сервер также рассчитывает
Так мы получим нужные нам свойства: компрометация БД не позволит залогиниться на сайте или узнать пароль, пароль не передаётся по сети, один и тот же ответ клиента нельзя использовать дважды для логина.
Также в этот алгоритм можно добавить не только авторизацию клиента, но и авторизацию сервера: клиент убеждается, что сервер знает какой-то секрет, хранимый в БД. Подробнее такая реализация описана в RFC 5802: SCRAM.
Слабое место алгоритма: если скомпрометирована БД, и при этом подслушан трафик настоящего клиента, то можно восстановить DK, а значит и авторизоваться как этот клиент. Но это будет работать только для этого конкретного сайта. Ещё одна угроза: если злоумышленник подслушает трафик, он может начать offline brute force атаку с целью поиска пароля, но от этого защищают только упоминавшиеся ранее алгоритмы SRP или EKE.
Улучшим.
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
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)
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)
0
Sign up to leave a comment.
Справочник по уязвимости OpenSSL Heartbleed