ValdikSS 8 апр 2014 в 16:53

Последствия OpenSSL HeartBleed

3 мин

157K

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

+187

194

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

kekekeks 8 апр 2014 в 16:57

Уязвимость была, как минимум, у:

Тот онлайн механизм проверки весь день сбоит, а сейчас пишет про то, что у них много false positive. Это тоже следует учитывать.

ValdikSS 8 апр 2014 в 16:58

Да, есть такое. Есть еще один сервис: possible.lv/tools/hb/. Ну и можно использовать тот-скрипт-на-питоне.

ksenobayt 8 апр 2014 в 17:16

Коллеги, а кто в курсе, что юзает для SSL Webmin? Насколько я понимаю, что-то перловое и своё?

divanikus 8 апр 2014 в 17:23

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

ksenobayt 8 апр 2014 в 17:26

А вот нифига. Накатил патч на OpenSSL в своём wheezy — со стороны https, отдающегося через nginx, все в порядке, а вот со стороны webmin, который отдаёт юзеру страницу через свой перловый сервер, всё уже плохо. Пока потушил, сижу думаю, куда копать.

amarao 8 апр 2014 в 17:57

Точно всё перезапустили?

ksenobayt 8 апр 2014 в 19:00

Да, милорд.

vvzvlad 8 апр 2014 в 20:05

Нужно больше железа!

ksenobayt 8 апр 2014 в 20:06

Постройте зиккурат.

ksenobayt 8 апр 2014 в 20:15

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

luckyredhot 8 апр 2014 в 23:05

На реальной машине то же — только рестарт помог! (OS: Ubuntu 12.04 LTS)

luckyredhot 9 апр 2014 в 01:43

UPD: quick fix for ubuntu:
apt-get update && apt-get install openssl libssl1.0.0 -y
И перезапустите все необходимые сервисы.

kurokikaze 9 апр 2014 в 10:43

Debian — та же хрень.

novoselov 8 апр 2014 в 17:56

Вот тоже интересно что используют остальные 1/3 вебсайтов?

dlancer 8 апр 2014 в 22:46

IIS + другие платформы или старые версии openssl без уязвимости.

navion 8 апр 2014 в 23:04

Однако на stackoverflow оказались уязвимы балансировщики (HAProxy).

cyberXndr 8 апр 2014 в 17:21

Настоящее веселье начнется если на секунду предположить, что в горячий патч встроен настоящий бэкдор.

+26

ksenobayt 8 апр 2014 в 17:22

Так опенсорс же. Я почти уверен, что ревью уже был.

sam002 8 апр 2014 в 17:27

Лично только перепроверять, а ещё лучше пересобирать из исходников, а то прилетит подставной пакет с уязвимого репозитория((
Очень жёстко обрушена система «доверенных соединений» во всей сети.

amarao 8 апр 2014 в 18:52

Не говорите глупости. Все приличные репозитории (читай, dpkg/rpm-based) имеют криптографическую подпись с чексуммами, работающую через gpg, которая с libssl ни ногой ни душой. Потому линуксоиды так спокойно относятся к всяким «левым» миррорам. man in middle не может положить туда что-то, что будет принято локальной системой обновлений как доверенный пакет без доступа к приватному ключу gpg (о котором https-сервер в свою очередь ни сном ни духом). То же касается и репозиториев git, где коммиты подписываются (могут подписываться) криптографической подписью, делающей git пофигистичным к компрометации транспорта.

+16

sam002 8 апр 2014 в 22:39

Да, ерунду в целом сморозил. Паранойя сегодня зашкаливает и мешает думать. Но каналов заражения репозитория, отметим, может быть много.

alexkbs 9 апр 2014 в 05:37

Вот вам коммит с исправлением, смотрите и изучайте:
github.com/openssl/openssl/commit/731f431497f463f3a2a97236fe0187b11c44aead

cyberXndr 8 апр 2014 в 17:32

>>Так опенсорс же. Я почти уверен, что ревью уже был.

А до момента обнаружения уязвимости ревью не было? Вся эта история еще раз показывает, что опенсорс не гарантирует безопасность, а лишь позволяет ее проверить.

ksenobayt 8 апр 2014 в 17:33

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

merlin-vrn 8 апр 2014 в 19:21

Вся эта история еще раз показывает, что опенсорс не гарантирует безопасность, а лишь позволяет ее проверить.

Правильно. А закрытый не только не гарантирует безопасность, но даже проверить не позволяет.

+41

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

merlin-vrn 11 апр 2014 в 12:20

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

Если открыто, может, увидят и засмеют, хотя мне похер.

Закрытый однозначно хуже супротив пофигиста.

sam002 8 апр 2014 в 17:24

Народ просто шокирован. Хорошо, что СМИ ещё не разобрались как это преподносить и что случилось…
Утром всех знакомых админов обзванивал, все быстро и чётко реагировали и вопросов лишних не задавали — сила комьюнити))

Как они допускают в проекте единственный круг ревью кода?! Это в корне не подходящая методология проверки для критических проектов, есть же (уверен, но не проверял) куча стандартов по которым openssl сертифицируют и многие из них накладывают ограничения на процесс тестирования и проверки! Как?!

+13

kyberorg 8 апр 2014 в 18:33

Спасибо за сообщение. В Debian Wheezy оперативно пришло обновление openssl, в процессе которого запустился конфигуратор с подробной информацией. Этот же конфигуратор позволяет перезагрузить демоны и советует вообще перезагрузить сервер, чтобы наверняка.

Lockal 8 апр 2014 в 18:52

Тоже Debian Wheezy, openssl обновился молча (от apt-get, а не aptitude, если что). NGINX и OpenSSH так и оставались уязвимыми до ручного перезапуска.

kyberorg 8 апр 2014 в 18:56

Я делал apt-get update && apt-get upgrade, запустился конфигуратор.

sam002 8 апр 2014 в 19:25

Наверное, новый пакет положили или модификация от хостинга, утром с зеркал яндекса без конфигуратора было.

nikolayvaganov 8 апр 2014 в 22:13

при установке нового libssl1.0.0, который как раз и был уязвим, запускается конфигуратор. Через депенденси он при apt-get install openssl не подтягивается.

alexkbs 9 апр 2014 в 05:38

Вчера в обновлении не было конфигуратора. Сегодня еще одно обновление и в нём уже есть.

Вообще они могли бы сами посмотреть что линкуется с OpenSSL и предложить перезапустить.

mayorovp 8 апр 2014 в 21:32

Админю два сервера. Первый обновился молча, второй предложил перезапустить демоны…

В обоих случаях — Debian Wheezy…

ZeroBit 8 апр 2014 в 17:25

Спасибо, что сообщили. Проапгрейдил на серверной CentOS:

Updated:
  openssl.x86_64 0:1.0.1e-16.el6_5.4

-2

Daimos 8 апр 2014 в 17:42

Хехе — а тестили тестилками потом? Все равно говорит, что уязвим сервер.

ZeroBit 8 апр 2014 в 17:45

Да вот как раз тестю. И правда, говорит, что уязвим. Сейчас все апдейты прикладываю, и перегружу сервак.

-2

ZeroBit 8 апр 2014 в 19:17

Приложил все апдейты ClearOS (сделан на основе CentoOS), рестартанул все демоны в зависимостях которого был OpenSSL. Нет, все таки тестилки показывают, что уязвимость есть. Подумал, что, т.к. ядро обновилось, хорошо бы перегрузить вес сервак. Так и сделал. Потом проверил, оказывается

# openssl version 
OpenSSL 1.0.1e-fips 11 Feb 2013

According to heartbleed.com:
Status of different versions:
OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable

Т.е. для CentOS openssl.x86_64 0:1.0.1e-16.el6_5.4 все еще уязвима. Служба поддержки ClearOS обещает скоро положить пофиксиный пакет в официальные репы.

d00kie 8 апр 2014 в 19:21

lists.centos.org/pipermail/centos-announce/2014-April/020248.html

openssl-1.0.1e-16.el6_5.4.0.1 НЕ уязвима.

lehha 8 апр 2014 в 17:44

Мне кажется, или последняя сборка — это 1.0.1e-16.el6_5.7?

Daimos 8 апр 2014 в 17:56

Обновил Ubuntu инстанс в амазоне — Openssl 1.0.1-4ubuntu5.12
В CentOS обновилось до openssl-1.0.1e-16.el6_5.7.x86_64

ElleSolomina 8 апр 2014 в 19:10

Вот я сейчас тоже полностью обновил весь софт на VPS под Ubuntu 12.04 LTS и перезагрузился, теперь
openssl version -a
показывает что то странное:
OpenSSL 1.0.1 14 Mar 2012
built on: Mon Apr 7 20:31:55 UTC 2014
platform: debian-i386
…
Кто нибудь может мне объяснить, что это за версия?

kyberorg 8 апр 2014 в 19:26

Похоже что это порт обновленного openssl для debian64.
А с годом вышел фейл.

У друга на сервере после обновления сегодня кажет такое:

$ openssl version -a
OpenSSL 1.0.1 14 Mar 2012
built on: Mon Apr  7 20:33:29 UTC 2014
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

isden 8 апр 2014 в 19:30

Версия пакета какая?
Вот тут говорят, что все ок.

-1

ElleSolomina 8 апр 2014 в 19:36

Благодарю, да всё ок:

apt-cache show openssl

Package: openssl
Priority: standard
Section: utils
Installed-Size: 898
Maintainer: Ubuntu Developers
Original-Maintainer: Debian OpenSSL Team
Architecture: i386
Version: 1.0.1-4ubuntu5.12
Depends: libc6 (>= 2.15), libssl1.0.0 (>= 1.0.1)
…

Успокоили :)

Daimos 8 апр 2014 в 20:19

Попробуйте выполнить команду
aptitude show openssl

Kwull 9 апр 2014 в 01:58

Вот тут подробнее про ubuntu:
OpenSSL 1.0.1 14 Mar 2012
built on: Mon Apr 7 20:31:55 UTC 2014

sluge 8 апр 2014 в 17:36

>Что произошло?
>1 января 2012 года…

Ох уж эти празники…

+10

ivan_kolmycheck 8 апр 2014 в 17:49

В ubuntu уже прикатили изменения:
> possible.lv/tools/hb/
> Actively checking if CVE-2014-0160 works: Your server appears to be patched against this bug.

Версия openssl: 1.0.1e-3ubuntu1.1

Lau 8 апр 2014 в 17:49

Хм, ок, вот мои 5 копеек
— чтоб читать по 64к через UDP надо постараться и быть очень рядом в сети, реальные размеры пакетов 576, 1500 байт, много через такой свисток не выжмешь, а указывать смещения от куда читать данные возможности нет — соответсвенно, либо будешь читать из одного и того же места либо из случайных и склеить полученные данные весьма проблематично
— выкачать секретные документы через такой свисток на практике близко к невозможному
— инициализация либы происходит в порядке инициализации данных под ключи потом уже данных под соединения — соответсвенно данные что можно будет читать из хипа текущего процесса будут (вероятней всего) лежать уже после ключей и чтение будет происходить по совсем другим адресам.
— чтение слепое, нет возможности двигать окно — соответсвенно все это на удачу, реальные ключи выглядят как мусор и склеить их из нескольких пакетов задача близкая к невозможному.
— реальные сертификаты достаточно большие и не помещаются в обычные 1500 байтные пакеты, соответсвенно выкачать целиком сертификат…
В общем есть баг, серьезный, но реальная его эксплуатация это 2 ведра удачи плюс ложка интеллекта.

+35

ZeroBit 8 апр 2014 в 17:54

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

Lau 8 апр 2014 в 17:57

Я с Вами согласен, теоритически это очень опасный баг. Хотя есть маленькое упраждение на воображение — вы аттакующий, и читаете куски данных с удаленной машины, как вы узнаете что вы считали пароль (UTF8, UTF-16/32, binary random), как узнать что пароль у вас на руках весь а не кусок, как получить другой кусок, как их склеить? очень много вопросов.

ZeroBit 8 апр 2014 в 18:03

Я с вами согласен, это очень проблематично. Тут вступают в дело алгоритмы, подобные тем, как склеивают панорамы, или как тут на хабре был пост про конкурс склейки листа бумаги из шредера. Затем проводится анализ на символьные классы. По POSIX'у это [:graph:] или [\x21-\x7E], что значит «Печатные символы». Можно задать длину 20 символов максимально. Прогоняя через словарь можно узнать имена пользователей. Остальное пароли. Как-то так.

-2

kurokikaze 8 апр 2014 в 18:26

Если склеиваем большую строку (а память процесса можно так представить), проще взять алгоритмы из shotgun sequencing.

vikarti 8 апр 2014 в 18:34

если в дампе (полученным через python-скрипт из прошлой темы) одного вебсайта одной не-российской компании, в где то 80% случаев в начале идет
58axe0fxf7x3x1&username=kXnXuo%40gmail.com&passwd=xxaxxbcxx123&action=up…
то думаю понять что тут — логин а что — пароль — достаточно просто.
пусть даже в этом случаем максимум что это даст — возможность узнать что у вот этого пользователя есть такая то железка с таким то серийником. При этом тест на самих железках что они продают (и обычным пользователям), что-то очень похожие на куки доступа к веб-интерфейсу железки.

у другой компании, которая просит с собой интегрировать Google Drive,Dropbox, Evernote,Box… тот же скрипт выдает нечто очень напоминающие токены доступа к этим самым сервисам. (да да не пользуйтесь облачными сервисами… но надо иногда)

это что — не критично? мне как бы сохранность моих данных — важна.

да, в обоих случаях письмо куда следует написано.

Lau 8 апр 2014 в 18:44

Я вам верю, в этом случае это критично, хотя у меня возникает масса вопросов по поводу того как именно хранятся эти данные в памяти, почему они лежат вот такой строкой, т.е. при доступе к ним их нужно парсить самому процессу… это не очень красиво :-)

skobkin 11 апр 2014 в 02:43

Веселье начинается тогда, когда данные получаются в формализованном виде. Например, я тестировал тем самым питоновым скриптом сайт одного мессенджера, которым пользуюсь и на выходе получал JSON. Пусть и кусками, но в такой ситуации уже понять, что находится перед глазами очень просто. К счастью, паролей там не было, а были лишь списки пользователей групповых чатов. Хотя, может быть, вылезло бы что-то посерьезней, если бы я не переключился на устранение дыры на своём сервере.

Smithson 8 апр 2014 в 18:10

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

ValdikSS 8 апр 2014 в 18:34

UDP? Какой UDP?
Возможности указать адрес, похоже, действительно нет, но пакеты приходят без повреждений.

Вы можете прямо сейчас читать чужую почту, используя скрипт на питоне и mail.yahoo.com в качестве параметра, например.

Lau 8 апр 2014 в 18:49

Возможно я не понял ваш вопрос, но DTLS = Datagram Transport Layer Security,
However, TLS must run over a reliable transport channel — typically TCP [TCP]. Therefore, it cannot be used to secure unreliable datagram traffic. An increasing number of application layer protocols have been designed that use UDP transport.
Из RFC tools.ietf.org/html/rfc6347

ValdikSS 8 апр 2014 в 19:16

Ну HTTPS-то всегда через TCP работает.
Мне вот только что часть ключа yahoo.com попалась.

xenon 8 апр 2014 в 19:22

Ну вот пример — погонял утилитку против одного из своих сайтов. В какой-то момент в начале длинной портянки нулей таки пролетел кусок HTTP запроса, включая куку типа sessid=NNNNNNNNNNNN. Зная формат, который мы «ловим» очень легко через этот маленький свисток, тыркать-тыркать, и регексами выцеплять то, что нам надо. А уж зная несколько байтов sessid — имеем полноценный доступ через удобный браузер, и уже выкачиваем терабайты секретов.

P.S.
UDP-то тут причем, оно все через TCP работает же.

Lau 8 апр 2014 в 19:39

Да, ошибся, оказывается сердцебиения используются не только для DTLS, но и для TLS так же…
This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.
The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS.
Вот интересно как поведет себя пакет если он не будет влазить в MTU — если не будет флага DF то пакет будет дробится на MTU, но не зависит ли его правильная пересборка от оборудования?

xenon 8 апр 2014 в 19:48

Как UDPшный себя поведет — не знаю, но для TCP тут проблем никаких нет, у меня мой сервак мне отлично сливает дампы с индексами от 0000 до 3ff0 что гораааздо выше MTU. Может можно и .avi'шку одним запросом случайно так «скачать».

mayorovp 8 апр 2014 в 21:41

Не зависит. Дроблением на фрагменты и обратной сборкой занимается третий уровень — а там все уже давно стандартизовано.

mrjj 8 апр 2014 в 19:22

выделение памяти не совсем рэндом все-таки, маркеры характерные выделить какие ни будь

KorDen32 8 апр 2014 в 23:22

Гонял тот-самый-скрипт-на-питоне. Экспериментировал на различных форумах с различными движками и на Steam (в Steam уже закрыли).

В 90% случаев в дампе был виден запрос пользователя и часть ответа сервера. В запросе соответственно было Cookies: со всеми вытекающими.

Словил так на одном форуме member_id=2, т.е. первый пользователь (1 обычно технический бот), головной админ. Подставил у себя в браузере — зашел под админом. Там еще password_hash был, т.е. можно по радужным таблицам подобрать пароль по идее (в админку полную же не зайти, там повтороно нужно авторизоваться каждый раз), т.к. вроде на том движке без соли хранится в куках…

В Steam у меня почти каждый запрос выдавал куку, хотя там вроде ограничение стоит на IP сессии (вроде сессия не возобновляется при заходе с другого региона (на базе GeoIP)). Хотя возможно плохо смотрел и что-то из кук пропустил при эксперименте.

Теоретически можно было поставить скажем каждые 5 секунд запрос и получить кучу кук, из которых часть бы была валидной — а в инвентарях пользователей много ценных внутриигровых предметов, которые можно обменять через сайт…

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

cigulev 10 апр 2014 в 00:58

А что за скрипт, можете подробней написать?

-1

KorDen32 10 апр 2014 в 11:30

ssltest.py, его уже несколько раз в предыдущем (и вроде в этом) топиках выкладывали же

KorDen32 9 апр 2014 в 11:40

Ну вот пожалуйста, «реальная эксплуатация» не заставила себя долго ждать. Не знаю, может это Activision сами сделали, но скорее всего кто-то все же словил чьи-то куки.
Changed name Call of Duty: Black Ops II › Valve please reset partner logins because heartbleed

steamcommunity.com/discussions/forum/12/558752450282315846/
steamdb.info/app/202970/#section_history

+12

Lockal 8 апр 2014 в 18:41

Внимание, простое обновление системы не убирает уязвимость!

На примере Debian, обновление openssl не вызвало перезапуска nginx (то же самое касалось бы почтовых серверов, XMPP, IRC, SSH и прочих SSL-серверов). Не забудьте перезапустить сервисы вручную!

kyberorg 8 апр 2014 в 19:29

Как я отписал выше: habrahabr.ru/post/218661/#comment_7477811, новая версия запускает конфигуратор, делающий перезапуск.

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

grossws 9 апр 2014 в 21:51

Маленький fix: ssh — не использует SSL/TLS.

А всякие slapd, nginx, apache, lighttpd, postfix/exim/sendmail перезапускать надо.

DimonCJ 8 апр 2014 в 18:51

А мобильные системы подвержены? Android / iOS?

ValdikSS 8 апр 2014 в 19:16

Пока не совсем понятно. По крайней мере, Android 4.1+ использует уязвимую версию OpenSSL, но в ней, вроде, Heartbeat отключен.

ksenobayt 8 апр 2014 в 23:13

Busybox нас спасёт, все дела?

NeoTheFox 8 апр 2014 в 18:54

Похоже у QIwi все в порядке

amarao 8 апр 2014 в 19:14

Внезапно, драма. В убунте этому апдейту поставили urgency=medium.

openssl (1.0.1-4ubuntu5.12) precise-security; urgency=medium

  * SECURITY UPDATE: side-channel attack on Montgomery ladder implementation
    - debian/patches/CVE-2014-0076.patch: add and use constant time swap in
      crypto/bn/bn.h, crypto/bn/bn_lib.c, crypto/ec/ec2_mult.c,
      util/libeay.num.
    - CVE-2014-0076
  * SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160

 -- Marc Deslauriers <marc.deslauriers@ubuntu.com>  Mon, 07 Apr 2014 15:45:14 -0400

ximaera 8 апр 2014 в 21:44

Видимо, они, не подумав, применили полиси от CVE-2014-0076. У того CVE и вправду urgency=medium, почитайте вот.

victor1234 8 апр 2014 в 19:46

А что вообще дает это расширение? В Gentoo есть флаг tls-heartbeat, может его вырубить, пока дело не уляжется?

powerman 8 апр 2014 в 23:43

«Дело уляжется» как только вы обновите openssl и перезапустите зависимые сервисы. В чём смысл после этого отключать heartbeat? Или у вас есть инсайдерская инфа что следующий серьёзный баг тоже будет найден в коде heartbeat? :-)

-2

J_o_k_e_R 9 апр 2014 в 01:14

По результатам чтения гентушной багзилы пришел к тому же выводу, что и victor1234. Там разработчики говорят, что типа «код новый, категорической пользы не несет, вполне можно отрубить». Я вот у себя на серверах помимо обновления openssl, поотрубал heartbeat вообще, полет нормальный вроде.

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

ximaera 9 апр 2014 в 03:31

В черновике IETF достаточно подробно описано.

Грубо говоря, heartbeat нужен для:
1) поддержания установленной TLS-сессии в активном состоянии;
2) проверки, жива ли сессия ещё (актуально только для DTLS over UDP);
3) для path MTU discovery (актуально только для DTLS over UDP, и я не уверен, что это реально используется).

Если у вас нет вечноживущих соединений, не передающих фактически трафик (что само по себе вредно и упрощает организацию DDoS-атак транспортного уровня) и нет DTLS/udp, то я не вижу, как вам может помочь TLS heartbeat.

invented 8 апр 2014 в 19:46

Уже 8 вечера, а Raiffeisen всё тормозит. Facepalm (

ValdikSS 8 апр 2014 в 20:06

Да это ужас какой-то. Я им только что звонил, а отправил письмо 6 часов назад. Сначала меня быстро переадресовали хорошему технарю, который выслушал, запротоколировал и все понял, но советовал позвонить еще по одному телефону. Там ответила какая-то тетка, я ей говорю, что уже 6 часов прошло (непомерно много!), а она мне говорила таким тоном, будто я в очередь влажу. Бросил трубку.

У них там трафик прямо от банк-клиента можно plaintext получать.

ksenobayt 8 апр 2014 в 20:11

У Альфы слушать траф клиента не пробовал?
Сам юзаю на постоянной основе, как-то ссыкотно — а линукс-машины под рукой нет, чтоб поснифать на проверку.

ValdikSS 8 апр 2014 в 20:12

Да. Жуть. Plaintext логины и пароли для прямого доступа в банкинг. Но пофиксили после моего письма и звонка быстро.

Я про эксплоит, если что.

ksenobayt 8 апр 2014 в 20:13

Странно, клиент сегодня не обновлялся вовсе, кхм.
Чо, логины даже засолены не были?

ValdikSS 8 апр 2014 в 20:15

Ну, там же через веб-сайт вход, через HTTPS. Вот эксплоит и позволял посмотреть нешифрованные данные POST-запроса.

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

ValdikSS 8 апр 2014 в 21:24

Случайного чужого.

jcmvbkbc 8 апр 2014 в 21:30

Но пофиксили после моего письма и звонка быстро.

… а сертификат от декабря 2012 оставили.

navion 8 апр 2014 в 23:59

Интересно, многие пользуются стандартным ящиком security@domain.tld? Если писали на него, то не поделитесь статистикой?

vvzvlad 8 апр 2014 в 20:07

И действительно открыто.

Angelore 8 апр 2014 в 20:12

Кто-нибудь, кто на ты с этим коммитом, может пояснить в чем собственно проблема? Что-то я втыкаю в этот кусок кода и не вижу проблемы.

Angelore 8 апр 2014 в 20:21

Вопрос снимается, нашел: github.com/openssl/openssl/commit/7e840163c06c7692b796a93e3fa85a93136adbb2

navion 8 апр 2014 в 20:48

Знатный выдался Patch Tuesday!

engine9 8 апр 2014 в 21:18

Рядовому юзеру интернета что-то надо предпринять?

lehha 8 апр 2014 в 21:27

Надеяться, что данные не уплывут, как например на mail.yahoo.com уже целый день сливают…

opencoder 8 апр 2014 в 21:28

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

encyclopedist 8 апр 2014 в 21:42

Автор, действительно, порекомендуйте простым пользователям не заходить пока на уязвимые сайты, чтобы их данные не оказались в оперативной памяти сервера и не могли быть оттуда прочитаны злоумышленником.

ValdikSS 8 апр 2014 в 21:59

Готово

opencoder 8 апр 2014 в 22:00

+сюда же — нужно обязательно сменить пароль после того, как сайты закроют у себя эту дырку, потому что потенциально он мог быть сосниффан.

timurrrr 9 апр 2014 в 00:40

Мне кажется, или лучше поменять пароль ещё и когда сайты поменяют сертификаты?

ElleSolomina 8 апр 2014 в 22:01

Мне вот интересно когда разродятся OpenVPN на апдейт для Windows.
openvpn.net/index.php/open-source/downloads.html

navion 8 апр 2014 в 22:13

Под Windows и OpenSSL ещё не собрали.

ElleSolomina 8 апр 2014 в 22:27

Вот это поворот…

Благодарю за разъяснения.

ElleSolomina 8 апр 2014 в 22:40

Хотя стоп, уже собрали ведь:
slproweb.com/products/Win32OpenSSL.html

OpenSSL 1.0.1g

… тьфу, это я слепой. OpenVPN тоже обновился уже, просто неочевидно по дате это

navion 8 апр 2014 в 22:51

Прошу прощения, я забыл алфавит.

ksenobayt 8 апр 2014 в 22:52

OpenVPN собрали под винду, а вот патченного исходника под никсы, и уж тем более, пакетов, я пока не вижу.
Или я тоже слепой?

ksenobayt 8 апр 2014 в 23:01

Хотя, вроде как отставить тревогу — слинковано, судя по всему, в Дебиане сразу напротив нужных либ:

root@maniac ~ # ldd /usr/sbin/openvpn
linux-gate.so.1 => (0xb77d9000)
libpkcs11-helper.so.1 => /usr/lib/i386-linux-gnu/libpkcs11-helper.so.1 ( 0xb7710000)
libssl.so.1.0.0 => /usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0 (0x b76b7000)
libcrypto.so.1.0.0 => /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0 .0 (0xb74f7000)
liblzo2.so.2 => /usr/lib/i386-linux-gnu/liblzo2.so.2 (0xb74d3000)
libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb74cf000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb736b000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb735 2000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb7338000)
/lib/ld-linux.so.2 (0xb77da000)

У libssl.so.1.0.0 и libcrypto.so.1.0.0 дата изменения 8-го апреля в 01-26 ночи, так что вроде как все в порядке (?). Кто-нибудь может у себя проверить?

opencoder 8 апр 2014 в 22:12

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

ValdikSS 8 апр 2014 в 22:18

Самое страшное, что некоторым насрать. Yahoo.com насрать, банкам насрать, мелким сайтам насрать, неопытным сисадминам насрать, людям, которые считают, что уязвимость незначительная, насрать. Всем насрать, только нам не насрать.

+27

merlin-vrn 8 апр 2014 в 22:26

ну так не их же пароли и деньги утекли, чего чесаться

navion 8 апр 2014 в 23:00

Приятно удивила оперативная реакция Альфа-Банка, который не мог подписать свои java-аплеты в течении полугода.
У остальных может не быть процедуры по экстренной установке патчей и в лучшем случае будут ждать окна обслуживания, а в худшем — сертификации всего комплекса ПО.

nikolayvaganov 8 апр 2014 в 23:04

где-то на просторах интернета писали что у части реселлеров одного очень известного регистратора до сих пор ничего не пофикшено, двухфакторки нет и по словам поддержки и не планируется, тем временем в свободном доступе за час от них ушло около 300(!!!!!) сессий в куках. Далее пишут, что попробовали авторизоваться в парочку для проверки и на каждом из них по 5-10 доменов. Жаль, что я забыл где это читал или видел, поэтому не знаю где это найти и вряд ли узнаю если спросят, увы. Таким образом все сервисы делают хуже только клиентам, которых жалко только нам и которым неохота делать подлянки.

chupakabra 8 апр 2014 в 22:35

Информация для тех кто держит сервера на AWS.
Последнии версии которые находятся в репозитории (openssl-1.0.1e-37.66.amzn1.x86_64 и openssl-1.0.1e-37.66.amzn1.i686) уже пропатчены от данной уязвимости.

ValdikSS 8 апр 2014 в 22:54

Тем временем, yahoo.com запатчили.

alexxxst 8 апр 2014 в 23:04

Хрень какая-то. Два одинаковых сервера, Ubuntu 12.04, на обоих сделан апдейт, на обоих одинаковая версия OpenSSL (1.0.1-4ubuntu5.12) стоит, оба перезагрузил. В итоге: один уязвим, второй — нет. Чего делать — ХЗ. Сервисы перезапускал руками несколько раз.
Все три сервиса проверки показывают одинаково.

alexxxst 8 апр 2014 в 23:52

В соседнем аналогичном топике нашлось решение.

monolithed 8 апр 2014 в 23:28

Если вы на OSX, вы, с большой верятностью, используете OpenSSL 0.9.8, которая не подвержена уязвимости, если вы не ставили версию новее вручную.

➜ openssl version
OpenSSL 1.0.1e 11 Feb 2013

➜ sudo port -v selfupdate
➜ sudo port install openssl

➜ openssl version
OpenSSL 1.0.1g 7 Apr 2014

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

DjPhoeniX 8 апр 2014 в 23:56

Банк «Русский Стандарт» до сих пор уязвим. Написал в поддержку.

ValdikSS 9 апр 2014 в 00:56

И еще, как минимум, два. Я им звонил, им насрать.

norritt 9 апр 2014 в 10:03

Райф тоже до сих пор такой же?

ValdikSS 9 апр 2014 в 10:04

Нет. А вот РС — да.

norritt 9 апр 2014 в 10:10

Они (райфы) сертификат обновили?

ValdikSS 9 апр 2014 в 10:11

Nope.

norritt 9 апр 2014 в 10:15

Ну и смысл тогда? :-)

Спасибо большое.

HighwayStar 9 апр 2014 в 10:29

ОТП уязвим

Pongo 9 апр 2014 в 13:45

Вроде РС исправили.

pokupo 9 апр 2014 в 06:08

Тьфу черти полосатые, надо же такой чудненький код закомитить в такой продукт…

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

ValdikSS 9 апр 2014 в 11:04

АйМаниБанк запатчились.
А еще меня забанили на banki.ru по причине «спам».

Скрытый текст

Мы не можем разместить такой контент на нашем портале.

С наилучшими пожеланиями,
Григорьева Юлия,
модератор направления интерактивных сервисов
информационного портала www.banki.ru

-----Original Message-----
From: ValdikSS [mailto:iam@valdikss.org.ru]
Sent: Wednesday, April 09, 2014 11:00 AM
To: moderator@banki.ru
Subject: Re: Бан ValdikSS

Вы это серьезно?
Это самая серьезная уязвимость за всю историю интернета. Мой долг сообщить о
ней пользователям. Вы не представляете, как просто можно получить логин и
пароль пользователя, читать чужие сообщения (вчера mail.yandex.ru был пол
дня уязвим) и смотреть транзакции в уязвимых банках.

Мне-то с этого никакой выгоды, даже наоборот, пожалуй.
Я совершенно уверен, что информация о 20-40% пользователей этих банков уже
утекла.

On 04/09/2014 10:55 AM, moderator@banki.ru wrote:
> Здравствуйте.
> Ваш комментарий на портале Банки.ру был весьма «назойлив» (в разных
> разделах) со ссылкой на стороной ресурс. И содержание поста весьма
> сомнительное. Такие комментарии на нашем портале являются спамом, за
> что вы и получили бессрочный бан.
> Ваш основной аккаунт в бессрочном бане, заход через «быструю
> регистрацию», является повторной регистрацией. Для связью с
> модераторами пишите по почту moderator@banki.ru.
>
> С наилучшими пожеланиями,
> Григорьева Юлия,
> модератор направления интерактивных сервисов информационного портала
> www.banki.ru
>
>
> -----Original Message-----
> From: noreply@banki.ru [mailto:noreply@banki.ru]
> Sent: Wednesday, April 09, 2014 10:46 AM
> To: Canqpup
> Subject: Банки.ру [Личное сообщение] Бан ValdikSS
>
>!!! Сообщение сгенерировано автоматически.
>!!! НЕ ИСПОЛЬЗУЙТЕ функцию «Ответить» (Reply) вашего почтового клиента.
>
> ЛИЧНОЕ СООБЩЕНИЕ (отправлено из форума Банки.ру)
> ===============================================================
> Тема: Бан ValdikSS
> Автор: iam@valdikss.org.ru | дата: 09.04.2014 10:46:25
> — >
> День добрый!
> Вы меня только что забанили за спам и удалили 3 темы и мои сообщения.
> Это, вообще-то, не спам. Это информация о реальной угрозе, которая
> позволяет получить персональные данные и логин/пароль пользователей
интернет-банкинга.
> Надеюсь на разбан.
>
> ================================================================
> Для ответа автору этого сообщения воспользуйтесь ссылкой:
> www.banki.ru/forum/index.php?PAGE_NAME=pm_read&FID=1&MID=103745
> 5&by=p
> ost_date&order=desc
>

+21

sam002 9 апр 2014 в 11:51

Забейте на них, какие-то агрегаторы новостных подборок. Без громких и массовых эксплуатаций утечек новостей через СМИ не будет.
В среднем по больонице получилось, что у мошенников было около 12 часов на сбор пользовательских данных и сомнительно, что сразу же найдут применение всему слитому, т.к. много мусора. Страшно будет, если получат доступ к внутренним ресурсам и назаливают шелов.

Я вот думаю, что делать с яндекс.ПДД — надо заставлять пользователей менять пароли на рандом уникальный, как это для всех провести — хз. Надо бы сессии сбросить и заставить менять со сравнением версий паролей…

PS: Прилетало обновление WP и плагинов-чекалок секюрности — как-то ребята не вовремя, кажется. Долго бродил по репозиториям и форумам — проверял оригинальность источников и решил отложить до завтра, а утром уже накатилось автоматически((

ValdikSS 9 апр 2014 в 12:09

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

Я с вами не согласен. Наоборот, мусора практически нет. Почти от всех банков мне прилетал либо логин/пароль, либо cookie (без ограничения по IP). А про почту и говорить не стоит.

Nordvind 9 апр 2014 в 12:30

Ну я думаю вы знали, на что шли. Глупо полагать, что все вас станут слушать.

-3

ValdikSS 11 апр 2014 в 16:21

Ак Барс Банк запатчился. Был уязвим около 87 часов.

ValdikSS 9 апр 2014 в 11:27

Добавил информацию о перевыпуске сертификатов.

ValdikSS 9 апр 2014 в 12:10

Добавил информацию о скомпрометированных данных.

ValdikSS 9 апр 2014 в 19:18

Интеркасса прислала письмо, что необходимо сменить пароль. Молодцы!

ValdikSS 10 апр 2014 в 10:24

Добавил бонусов ;)

KorDen32 10 апр 2014 в 11:40

«Не какого-то пользователя, а вашего пользователя»
«Я говорю об уязвимости — ну так вам поступает SMS-уведомление!»
Хоть «Михаил» оказался адекватным (а то можно было попасть и на кого-то вроде «ДА КАК ВЫ СМЕЕТЕ!!! Я ВЫЧИСЛЮ ВАС ~~ПО АЙПИ~~»), хотя интересно было бы посмотреть его дальнейшую реакцию :)

ArtRoman 11 апр 2014 в 02:39

Великолепно.
– Я ничего не понимаю (у меня нет инструкций по вашим ключевым словам), но я вас никуда не переключу!

skobkin 11 апр 2014 в 02:58

Шедеврально. Походу, девушка хотела поскорее закончить рабочий день и не заморачиваться поиском нужного специалиста.

ValdikSS 11 апр 2014 в 10:03

Добавил ссылку на статью на banki.ru
Альфа-Банк отрицает уязвимость. _{а banki.ru — ссыкуны}

Chamie 12 апр 2014 в 00:24

Альфа-Банк отрицает уязвимость.

Так их банкинг («Альфа-клик») разве не на Яве, в которой собственная реализация?

ValdikSS 12 апр 2014 в 00:28

Что вы имеете ввиду под «на Яве»? JAVA-апплетов никаких не запускается. Или вы, возможно, имеете ввиду, что он работает на каком-нибудь Tomcat? Уязвимость вполне могла быть в балансировщике между томкэтами, например.

Chamie 12 апр 2014 в 00:33

Ну, судя по адресу, на который перекидывает при заходе на Клик (https://click.alfabank.ru/adfform/auth.jspx), там именно сервлет-контейнер. Конкретно этот поддомен (click.alfabank.ru) проверялся на уязвимость?

ValdikSS 12 апр 2014 в 00:35

Да, конкретно этот. По крайней мере, в Server написано BigIP, это, вероятно, балансер от F5 Networks, мог быть уязвим именно он.

Chamie 12 апр 2014 в 00:37

Может, тогда до них самих не дошло, что у них балансер

grossws 12 апр 2014 в 01:31

Терминация SSL/TLS может быть не на балансировщике, а на балансируемых серверах. Дабы не распространять зону доверия на внешнюю контору.

Chamie 14 апр 2014 в 11:42

Тогда бы уязвимости не было, Java же OpenSSL не использует.
Ну, а вообще на входе в Клик двухфакторная авторизация через СМС, сброс сессии при одновременном открытии более одной страницы, таймаут чуть ли не 2 минуты и прочая паранойя.

grossws 14 апр 2014 в 13:01

Вообще, я выдвинул неправдоподобный вариант, т. к., исходя из указанных выше заголовков, балансировка происходит на L7. В таком случае балансировщик обязательно обладает ключом и сертификатом. Терминация SSL/TLS на конечных серверах возможна, если балансировка тупая: virtual ip, например.

Nordvind 9 апр 2014 в 11:29

С таким качеством кода я не удивлен:

if (1 + 2 + 16 > s->s3->rrec.length)

entze 9 апр 2014 в 13:05

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

Lockal 9 апр 2014 в 13:50

Приватбанк отписался, что знает об уязвимости (но ничего не исправили).

Русский Стандарт исправили меньше за час после сообщения (но знали и ранее).

Банк Зенит молчит.

OTП Банк молчит.

ValdikSS 9 апр 2014 в 14:16

У привата уязвим только сайт, а не интернет-банкинг.
Русский стандарт реагировал около суток (см. таблицу)
Зенит знает о проблеме, это единственный банк, который меня с сисадмином напрямую соединил. Но не запатчили еще почему-то, да.
Про ОТП Банк не знал, сейчас им позвоню.

ValdikSS 9 апр 2014 в 15:17

ОТП закрыл уязвимость.

ValdikSS 9 апр 2014 в 16:10

Системный администратор Банка Зенит, кому я сообщал об уязвимости сегодня утром, видимо, узнал, что новый аниме сезон началася, пошел домой смотреть мультики и отключил телефон. По крайней мере, я недалеко от истины.

ValdikSS 9 апр 2014 в 18:47

Администратор, видимо, посмотрел Soul Eater Not!, включил телефон и обновил openssl.

drdim 9 апр 2014 в 14:24

Сбербанк-онлайн я так понимаю пронесло (windows, не используют openssl)?

Lockal 9 апр 2014 в 15:08

У них IIS.

cigulev 9 апр 2014 в 14:56

Скажите, а где можно увидеть конкретный пример применения этой уязвимости на каком-либо сайте?

Lockal 9 апр 2014 в 15:05

Вот например. А вообще в область в 64 КБ почти всегда (субъективно) попадают чьи-то заголовки, так что можно посмотреть пример самому.

ValdikSS 9 апр 2014 в 15:29

Дело не в области, а в том, что контекст SSL, как правило, инициализируется прямо до чтения из сокета, и, собственно, ниже контекста лежат расшифрованные данные.

veam 9 апр 2014 в 15:44

Написал скрипт, который дампил в файл в течении получаса вывод hb-test.py одного игрового сайта.
Потом грепнул по паролям.
В итоге 10 троек логин-пароль-почта вновь зарегистрованных, из которых несколько паролей подошли к почте и там были привязаны социальные сети.

Страшная вещь если не фиксить, весь трафик сайта как на ладони.

+12

cigulev 10 апр 2014 в 00:51

можно посмотреть на скрипт?

veam 10 апр 2014 в 06:50

Просто по циклу вызывал питоновый скрипт и перенаправлял вывод в файл при помощи >>.

morozovsk 9 апр 2014 в 16:20

Проверил lastpass.com, сейчас вроде всё ок: possible.lv/tools/hb/?domain=lastpass.com
Но получается, что могли получить мою куку с которой обращается браузерный плагин к серверу и получить по ней все пароли?
Представляю, сколько у меня уйдёт времени на то чтобы поменять все пароли…

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

Lockal 9 апр 2014 в 18:28

А вот и удостоверяющие центры (представители GlobalSign) плюются хэдерами: prontossl.com, totallyssl.com

-1

Vnr 10 апр 2014 в 09:45

Многие западные сервисы (ifttt.com, appfog и др.) сделали рассылку с рекомендацией сменить пароль.
Почему наши все молчат, в частности Яндекс?

ValdikSS 10 апр 2014 в 10:05

Я не могу сказать про банки (т.к. они только своим клиентам могут делать рассылки), но Интеркасса прислала письмо, в котором говориться, что нужно-бы пароль сменить. Они вообще классные парни, мы с ними болтали по поводу уязвимости вчера.

tsifra 10 апр 2014 в 14:22

А эта библиотека случайно не используется в прошивках роутеров на безу WRT или в серверных IPMI интерфейсах?

sam002 10 апр 2014 в 14:32

Обновили пакет судя по trac-у openwrt
Надо так же собирать информацию по версиям и исправлениям… Используется, в частности при доступе к серверам авторизации (уточнять надо, пробежал по диагонали эту статью с хабра).

Vayun 10 апр 2014 в 16:08

пакет-то обновили, но в прошивки он попадет только в след релизе, кому не охота ждать сюда habrahabr.ru/post/218713/#comment_7480227

mOlind 10 апр 2014 в 14:46

Интересная получилась схема. Сначала новость «АНБ нас всех прослушивает, давайте переходить на HTTPS». Через несколько месяцев, когда все нужные данные слиты «Ой, оказывается в HTTPS есть дыра, через которую можно слить много ценной инфы».

KorDen32 10 апр 2014 в 14:49

… А дальше уже была шутка в предыдущем посте про то, что это обновление содержит новый эксплоит :)

pmurzakov 10 апр 2014 в 16:01

Райффайзен написали новость о том, что необходимо сменить пароли: www.raiffeisen.ru/about/press/dist/index.php?id28=29220
В Твиттере написал им, что ещё неплохо было бы перевыпустить сертификат: twitter.com/Raiffeisen_Ru/status/454147951208988672. Молчат.

nikolayvaganov 10 апр 2014 в 16:56

это все хорошо, но до сих пор часть инет банков уязвима =(

ValdikSS 11 апр 2014 в 10:04

Некоторые все еще уязвимы (11 число)

papersaltserver 10 апр 2014 в 18:39

SSO в vCenter использует OpenSSL и некоторые другие java продукты. Так что для Windows это тоже проблема.

EgorKotkin 10 апр 2014 в 19:18

Написал в саппорт Судостроительного.

Кстати, в чём реальный рсик для клиентов банков? Даже утекший пароль не большая проблема, если операции требуют подтверждения по SMS. Ну, максимум кто-то поулчит выписку по моему счёту — ничего страшного.

veam 10 апр 2014 в 21:06

Симку перевыпустить — не самая большая проблема.
На banki.ru полно отзывов об этом виде мошенничества, а ведь тут сразу видно и количество денег на счете, и фио, и номер телефона — задача сразу упрощается.