Pull to refresh

Comments 46

«Invalid domain name» — видимо не умеет работать с ip
Это нормально: первый сервис проверяет конкретно наличие уязвимости в реализации heartbeat, а второй — лишь поддержку heartbeat в целом.
Как страшно жить. И вроде в паблике сплоит, который всего лишь сливает 16кб памяти процесса, но даже в этом небольшом кусочке дампа попадается более, чем чувствительная информация. Какие есть способы дополнительной защиты от подобных ситуаций?
Где можно посмотреть, как затребовать упаковку пакета? Или так — какие именно версии отдают больше 16к?
Opera (по крайней мере старых версий, по 12 включительно) проверяет статус сертификата по умолчанию. Она вообще всегда была самой параноидальной в этом плане.
Спасибо, исправил.
Что-то у меня на домашнем сервере с Proxmox не хочет обновляться. Aptitude пишет, что версия последняя — 1.0.1e.
Не забывайте, что в некоторых системах (например, Ubuntu и Debian) пакет openssl на самом деле разбит на два: openssl + libssl*, и в openssl на самом деле лежат только утилиты. Так что, если вы опасаетесь сразу накатывать все апдейты через full-upgrade, обновлять обязательно надо оба пакета, openssl и libssl1.0.0.
UFO just landed and posted this here
1. Спасибо, исправил.
2. В этом контексте нет MITM, а есть утечка приватного ключа. Используя только приватный ключ нельзя расшифровать пакеты при PFS.
3. Верно, исправил.
4. Вообще, да, но ECDHE считается более производительным, чем DHE.
Про 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.
Просто по какой-то причине многие админы столкнулись с тем, что сайт filippo.io выдает информацию о том, что их веб-сервера на FreeBSD 8 уязвимы
FreeBSD 8 и 9 не подвержены уязвимости, если, конечно, не устанавливался OpenSSL из портов или пакетов. По первой ссылке указаны и старые версии, поскольку этот advisory про две уязвимости в OpenSSL. На heartbleed.com были ошибочно указаны и версии 8 и 9, потом исправили.
Жалко нет сервиса для тестирования уязвимостей в клиентах, а не в серверах.
О нет, у меня так давно не было веселья, что даже допустил опечатку!)
Можно и так сказать :-)
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
Да, можете начинать паниковать. Если не хотите апгрейдиться до 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
Если браузер клиентов передавал пароли на сайт без hash+salt, а в чистом виде, то эти пароли также могут быть скомпрометированы.

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

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

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

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

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

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

Улучшим. 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.
зачем выдумывать, если есть SRP-6?
Я уже упоминал SRP. SCRAM — это более простой и наглядный алгоритм, который может защитить процесс авторизации от прослушивания канала. Если есть ещё алгоритмы с такими же свойствами, которые ещё не упоминались, то напишите.
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)
Sign up to leave a comment.

Articles