Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 194
Уязвимость была, как минимум, у:Тот онлайн механизм проверки весь день сбоит, а сейчас пишет про то, что у них много false positive. Это тоже следует учитывать.
Да, есть такое. Есть еще один сервис: possible.lv/tools/hb/. Ну и можно использовать тот-скрипт-на-питоне.
Коллеги, а кто в курсе, что юзает для SSL Webmin? Насколько я понимаю, что-то перловое и своё?
Скорее всего на низком уровне используется тот же самый openssl, он же линкуется как динамическая библиотека ко всему подряд.
А вот нифига. Накатил патч на OpenSSL в своём wheezy — со стороны https, отдающегося через nginx, все в порядке, а вот со стороны webmin, который отдаёт юзеру страницу через свой перловый сервер, всё уже плохо. Пока потушил, сижу думаю, куда копать.
Вот тоже интересно что используют остальные 1/3 вебсайтов?
Настоящее веселье начнется если на секунду предположить, что в горячий патч встроен настоящий бэкдор.
Так опенсорс же. Я почти уверен, что ревью уже был.
Лично только перепроверять, а ещё лучше пересобирать из исходников, а то прилетит подставной пакет с уязвимого репозитория((
Очень жёстко обрушена система «доверенных соединений» во всей сети.
Очень жёстко обрушена система «доверенных соединений» во всей сети.
Не говорите глупости. Все приличные репозитории (читай, dpkg/rpm-based) имеют криптографическую подпись с чексуммами, работающую через gpg, которая с libssl ни ногой ни душой. Потому линуксоиды так спокойно относятся к всяким «левым» миррорам. man in middle не может положить туда что-то, что будет принято локальной системой обновлений как доверенный пакет без доступа к приватному ключу gpg (о котором https-сервер в свою очередь ни сном ни духом). То же касается и репозиториев git, где коммиты подписываются (могут подписываться) криптографической подписью, делающей git пофигистичным к компрометации транспорта.
Да, ерунду в целом сморозил. Паранойя сегодня зашкаливает и мешает думать. Но каналов заражения репозитория, отметим, может быть много.
Вот вам коммит с исправлением, смотрите и изучайте:
github.com/openssl/openssl/commit/731f431497f463f3a2a97236fe0187b11c44aead
github.com/openssl/openssl/commit/731f431497f463f3a2a97236fe0187b11c44aead
>>Так опенсорс же. Я почти уверен, что ревью уже был.
А до момента обнаружения уязвимости ревью не было? Вся эта история еще раз показывает, что опенсорс не гарантирует безопасность, а лишь позволяет ее проверить.
А до момента обнаружения уязвимости ревью не было? Вся эта история еще раз показывает, что опенсорс не гарантирует безопасность, а лишь позволяет ее проверить.
Разве это не было очевидно изначально, про то, что это лишь возможность, и что если сильно надо удостовериться — копай?
По мне, лучше так, чем глухая проприетарщина. Могли бы и не знать.
По мне, лучше так, чем глухая проприетарщина. Могли бы и не знать.
Вся эта история еще раз показывает, что опенсорс не гарантирует безопасность, а лишь позволяет ее проверить.
Правильно. А закрытый не только не гарантирует безопасность, но даже проверить не позволяет.
Народ просто шокирован. Хорошо, что СМИ ещё не разобрались как это преподносить и что случилось…
Утром всех знакомых админов обзванивал, все быстро и чётко реагировали и вопросов лишних не задавали — сила комьюнити))
Как они допускают в проекте единственный круг ревью кода?! Это в корне не подходящая методология проверки для критических проектов, есть же (уверен, но не проверял) куча стандартов по которым openssl сертифицируют и многие из них накладывают ограничения на процесс тестирования и проверки! Как?!
Утром всех знакомых админов обзванивал, все быстро и чётко реагировали и вопросов лишних не задавали — сила комьюнити))
Как они допускают в проекте единственный круг ревью кода?! Это в корне не подходящая методология проверки для критических проектов, есть же (уверен, но не проверял) куча стандартов по которым openssl сертифицируют и многие из них накладывают ограничения на процесс тестирования и проверки! Как?!
Спасибо за сообщение. В Debian Wheezy оперативно пришло обновление openssl, в процессе которого запустился конфигуратор с подробной информацией. Этот же конфигуратор позволяет перезагрузить демоны и советует вообще перезагрузить сервер, чтобы наверняка.
Тоже Debian Wheezy, openssl обновился молча (от apt-get, а не aptitude, если что). NGINX и OpenSSH так и оставались уязвимыми до ручного перезапуска.
Я делал apt-get update && apt-get upgrade, запустился конфигуратор.
Админю два сервера. Первый обновился молча, второй предложил перезапустить демоны…
В обоих случаях — Debian Wheezy…
В обоих случаях — Debian Wheezy…
Спасибо, что сообщили. Проапгрейдил на серверной CentOS:
Updated:
openssl.x86_64 0:1.0.1e-16.el6_5.4 
Хехе — а тестили тестилками потом? Все равно говорит, что уязвим сервер.
Да вот как раз тестю. И правда, говорит, что уязвим. Сейчас все апдейты прикладываю, и перегружу сервак.
Приложил все апдейты ClearOS (сделан на основе CentoOS), рестартанул все демоны в зависимостях которого был OpenSSL. Нет, все таки тестилки показывают, что уязвимость есть. Подумал, что, т.к. ядро обновилось, хорошо бы перегрузить вес сервак. Так и сделал. Потом проверил, оказывается
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 обещает скоро положить пофиксиный пакет в официальные репы.
# 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 обещает скоро положить пофиксиный пакет в официальные репы.
lists.centos.org/pipermail/centos-announce/2014-April/020248.html
openssl-1.0.1e-16.el6_5.4.0.1 НЕ уязвима.
openssl-1.0.1e-16.el6_5.4.0.1 НЕ уязвима.
Мне кажется, или последняя сборка — это 1.0.1e-16.el6_5.7?
Обновил Ubuntu инстанс в амазоне — Openssl 1.0.1-4ubuntu5.12
В CentOS обновилось до openssl-1.0.1e-16.el6_5.7.x86_64
В CentOS обновилось до openssl-1.0.1e-16.el6_5.7.x86_64
Вот я сейчас тоже полностью обновил весь софт на 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
…
Кто нибудь может мне объяснить, что это за версия?
openssl version -a
показывает что то странное:
OpenSSL 1.0.1 14 Mar 2012
built on: Mon Apr 7 20:31:55 UTC 2014
platform: debian-i386
…
Кто нибудь может мне объяснить, что это за версия?
Похоже что это порт обновленного 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"
Версия пакета какая?
Вот тут говорят, что все ок.
Вот тут говорят, что все ок.
Попробуйте выполнить команду
aptitude show openssl
aptitude show openssl
>Что произошло?
>1 января 2012 года…
Ох уж эти празники…
>1 января 2012 года…
Ох уж эти празники…
В 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
> 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
Хм, ок, вот мои 5 копеек
— чтоб читать по 64к через UDP надо постараться и быть очень рядом в сети, реальные размеры пакетов 576, 1500 байт, много через такой свисток не выжмешь, а указывать смещения от куда читать данные возможности нет — соответсвенно, либо будешь читать из одного и того же места либо из случайных и склеить полученные данные весьма проблематично
— выкачать секретные документы через такой свисток на практике близко к невозможному
— инициализация либы происходит в порядке инициализации данных под ключи потом уже данных под соединения — соответсвенно данные что можно будет читать из хипа текущего процесса будут (вероятней всего) лежать уже после ключей и чтение будет происходить по совсем другим адресам.
— чтение слепое, нет возможности двигать окно — соответсвенно все это на удачу, реальные ключи выглядят как мусор и склеить их из нескольких пакетов задача близкая к невозможному.
— реальные сертификаты достаточно большие и не помещаются в обычные 1500 байтные пакеты, соответсвенно выкачать целиком сертификат…
В общем есть баг, серьезный, но реальная его эксплуатация это 2 ведра удачи плюс ложка интеллекта.
— чтоб читать по 64к через UDP надо постараться и быть очень рядом в сети, реальные размеры пакетов 576, 1500 байт, много через такой свисток не выжмешь, а указывать смещения от куда читать данные возможности нет — соответсвенно, либо будешь читать из одного и того же места либо из случайных и склеить полученные данные весьма проблематично
— выкачать секретные документы через такой свисток на практике близко к невозможному
— инициализация либы происходит в порядке инициализации данных под ключи потом уже данных под соединения — соответсвенно данные что можно будет читать из хипа текущего процесса будут (вероятней всего) лежать уже после ключей и чтение будет происходить по совсем другим адресам.
— чтение слепое, нет возможности двигать окно — соответсвенно все это на удачу, реальные ключи выглядят как мусор и склеить их из нескольких пакетов задача близкая к невозможному.
— реальные сертификаты достаточно большие и не помещаются в обычные 1500 байтные пакеты, соответсвенно выкачать целиком сертификат…
В общем есть баг, серьезный, но реальная его эксплуатация это 2 ведра удачи плюс ложка интеллекта.
Ведро, не ведро, но бывает в памяти хранятся имена пользователей и пароли, а это уже отличный улов (даже без паролей, уже неплохо), т.к. такие комбинации распарсиваются на раз и перебираются на этом же сервере на два.
Я с Вами согласен, теоритически это очень опасный баг. Хотя есть маленькое упраждение на воображение — вы аттакующий, и читаете куски данных с удаленной машины, как вы узнаете что вы считали пароль (UTF8, UTF-16/32, binary random), как узнать что пароль у вас на руках весь а не кусок, как получить другой кусок, как их склеить? очень много вопросов.
Я с вами согласен, это очень проблематично. Тут вступают в дело алгоритмы, подобные тем, как склеивают панорамы, или как тут на хабре был пост про конкурс склейки листа бумаги из шредера. Затем проводится анализ на символьные классы. По POSIX'у это [:graph:] или [\x21-\x7E], что значит «Печатные символы». Можно задать длину 20 символов максимально. Прогоняя через словарь можно узнать имена пользователей. Остальное пароли. Как-то так.
Если склеиваем большую строку (а память процесса можно так представить), проще взять алгоритмы из shotgun sequencing.
если в дампе (полученным через python-скрипт из прошлой темы) одного вебсайта одной не-российской компании, в где то 80% случаев в начале идет
58axe0fxf7x3x1&username=kXnXuo%40gmail.com&passwd=xxaxxbcxx123&action=up…
то думаю понять что тут — логин а что — пароль — достаточно просто.
пусть даже в этом случаем максимум что это даст — возможность узнать что у вот этого пользователя есть такая то железка с таким то серийником. При этом тест на самих железках что они продают (и обычным пользователям), что-то очень похожие на куки доступа к веб-интерфейсу железки.
у другой компании, которая просит с собой интегрировать Google Drive,Dropbox, Evernote,Box… тот же скрипт выдает нечто очень напоминающие токены доступа к этим самым сервисам. (да да не пользуйтесь облачными сервисами… но надо иногда)
это что — не критично? мне как бы сохранность моих данных — важна.
да, в обоих случаях письмо куда следует написано.
58axe0fxf7x3x1&username=kXnXuo%40gmail.com&passwd=xxaxxbcxx123&action=up…
то думаю понять что тут — логин а что — пароль — достаточно просто.
пусть даже в этом случаем максимум что это даст — возможность узнать что у вот этого пользователя есть такая то железка с таким то серийником. При этом тест на самих железках что они продают (и обычным пользователям), что-то очень похожие на куки доступа к веб-интерфейсу железки.
у другой компании, которая просит с собой интегрировать Google Drive,Dropbox, Evernote,Box… тот же скрипт выдает нечто очень напоминающие токены доступа к этим самым сервисам. (да да не пользуйтесь облачными сервисами… но надо иногда)
это что — не критично? мне как бы сохранность моих данных — важна.
да, в обоих случаях письмо куда следует написано.
Веселье начинается тогда, когда данные получаются в формализованном виде. Например, я тестировал тем самым питоновым скриптом сайт одного мессенджера, которым пользуюсь и на выходе получал JSON. Пусть и кусками, но в такой ситуации уже понять, что находится перед глазами очень просто. К счастью, паролей там не было, а были лишь списки пользователей групповых чатов. Хотя, может быть, вылезло бы что-то посерьезней, если бы я не переключился на устранение дыры на своём сервере.
Обычно шифрование траика нужно, чтобы спрятать критичные данные от админов устройств, через которые ваш трафик проходит.
В данном случае, у них эти два ведра удачи уже есть. Осталась ложка и немного скуки, чтобы себя развлечь таким способом.
В данном случае, у них эти два ведра удачи уже есть. Осталась ложка и немного скуки, чтобы себя развлечь таким способом.
UDP? Какой UDP?
Возможности указать адрес, похоже, действительно нет, но пакеты приходят без повреждений.
Вы можете прямо сейчас читать чужую почту, используя скрипт на питоне и mail.yahoo.com в качестве параметра, например.
Возможности указать адрес, похоже, действительно нет, но пакеты приходят без повреждений.
Вы можете прямо сейчас читать чужую почту, используя скрипт на питоне и mail.yahoo.com в качестве параметра, например.
Возможно я не понял ваш вопрос, но 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
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
Ну вот пример — погонял утилитку против одного из своих сайтов. В какой-то момент в начале длинной портянки нулей таки пролетел кусок HTTP запроса, включая куку типа sessid=NNNNNNNNNNNN. Зная формат, который мы «ловим» очень легко через этот маленький свисток, тыркать-тыркать, и регексами выцеплять то, что нам надо. А уж зная несколько байтов sessid — имеем полноценный доступ через удобный браузер, и уже выкачиваем терабайты секретов.
P.S.
UDP-то тут причем, оно все через TCP работает же.
P.S.
UDP-то тут причем, оно все через TCP работает же.
Да, ошибся, оказывается сердцебиения используются не только для 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, но не зависит ли его правильная пересборка от оборудования?
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, но не зависит ли его правильная пересборка от оборудования?
Как UDPшный себя поведет — не знаю, но для TCP тут проблем никаких нет, у меня мой сервак мне отлично сливает дампы с индексами от 0000 до 3ff0 что гораааздо выше MTU. Может можно и .avi'шку одним запросом случайно так «скачать».
Не зависит. Дроблением на фрагменты и обратной сборкой занимается третий уровень — а там все уже давно стандартизовано.
выделение памяти не совсем рэндом все-таки, маркеры характерные выделить какие ни будь
Гонял тот-самый-скрипт-на-питоне. Экспериментировал на различных форумах с различными движками и на Steam (в Steam уже закрыли).
В 90% случаев в дампе был виден запрос пользователя и часть ответа сервера. В запросе соответственно было Cookies: со всеми вытекающими.
Словил так на одном форуме member_id=2, т.е. первый пользователь (1 обычно технический бот), головной админ. Подставил у себя в браузере — зашел под админом. Там еще password_hash был, т.е. можно по радужным таблицам подобрать пароль по идее (в админку полную же не зайти, там повтороно нужно авторизоваться каждый раз), т.к. вроде на том движке без соли хранится в куках…
В Steam у меня почти каждый запрос выдавал куку, хотя там вроде ограничение стоит на IP сессии (вроде сессия не возобновляется при заходе с другого региона (на базе GeoIP)). Хотя возможно плохо смотрел и что-то из кук пропустил при эксперименте.
Теоретически можно было поставить скажем каждые 5 секунд запрос и получить кучу кук, из которых часть бы была валидной — а в инвентарях пользователей много ценных внутриигровых предметов, которые можно обменять через сайт…
Так что если словить в запросах вход пользователя или админа, и если нет ограничений на IP сессии и т.д., то задача выкачивания секретных документов может быть вполне решаемой.
В 90% случаев в дампе был виден запрос пользователя и часть ответа сервера. В запросе соответственно было Cookies: со всеми вытекающими.
Словил так на одном форуме member_id=2, т.е. первый пользователь (1 обычно технический бот), головной админ. Подставил у себя в браузере — зашел под админом. Там еще password_hash был, т.е. можно по радужным таблицам подобрать пароль по идее (в админку полную же не зайти, там повтороно нужно авторизоваться каждый раз), т.к. вроде на том движке без соли хранится в куках…
В Steam у меня почти каждый запрос выдавал куку, хотя там вроде ограничение стоит на IP сессии (вроде сессия не возобновляется при заходе с другого региона (на базе GeoIP)). Хотя возможно плохо смотрел и что-то из кук пропустил при эксперименте.
Теоретически можно было поставить скажем каждые 5 секунд запрос и получить кучу кук, из которых часть бы была валидной — а в инвентарях пользователей много ценных внутриигровых предметов, которые можно обменять через сайт…
Так что если словить в запросах вход пользователя или админа, и если нет ограничений на IP сессии и т.д., то задача выкачивания секретных документов может быть вполне решаемой.
Ну вот пожалуйста, «реальная эксплуатация» не заставила себя долго ждать. Не знаю, может это 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
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
Внимание, простое обновление системы не убирает уязвимость!
На примере Debian, обновление openssl не вызвало перезапуска nginx (то же самое касалось бы почтовых серверов, XMPP, IRC, SSH и прочих SSL-серверов). Не забудьте перезапустить сервисы вручную!
На примере Debian, обновление openssl не вызвало перезапуска nginx (то же самое касалось бы почтовых серверов, XMPP, IRC, SSH и прочих SSL-серверов). Не забудьте перезапустить сервисы вручную!
Как я отписал выше: habrahabr.ru/post/218661/#comment_7477811, новая версия запускает конфигуратор, делающий перезапуск.
Маленький fix: ssh — не использует SSL/TLS.
А всякие slapd, nginx, apache, lighttpd, postfix/exim/sendmail перезапускать надо.
А всякие slapd, nginx, apache, lighttpd, postfix/exim/sendmail перезапускать надо.
А мобильные системы подвержены? Android / iOS?
Похоже у QIwi все в порядке
Внезапно, драма. В убунте этому апдейту поставили 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
Видимо, они, не подумав, применили полиси от CVE-2014-0076. У того CVE и вправду urgency=medium, почитайте вот.
А что вообще дает это расширение? В Gentoo есть флаг tls-heartbeat, может его вырубить, пока дело не уляжется?
«Дело уляжется» как только вы обновите openssl и перезапустите зависимые сервисы. В чём смысл после этого отключать heartbeat? Или у вас есть инсайдерская инфа что следующий серьёзный баг тоже будет найден в коде heartbeat? :-)
По результатам чтения гентушной багзилы пришел к тому же выводу, что и victor1234. Там разработчики говорят, что типа «код новый, категорической пользы не несет, вполне можно отрубить». Я вот у себя на серверах помимо обновления openssl, поотрубал heartbeat вообще, полет нормальный вроде.
Кто бы еще поподробнее растолковал, что делает это расширение. Из описания я могу предположить, что на серверах среднего масштаба оно не особо нужно, только под высокую нагрузку. Поправьте меня кто-нибудь, если я не прав.
Кто бы еще поподробнее растолковал, что делает это расширение. Из описания я могу предположить, что на серверах среднего масштаба оно не особо нужно, только под высокую нагрузку. Поправьте меня кто-нибудь, если я не прав.
В черновике IETF достаточно подробно описано.
Грубо говоря, heartbeat нужен для:
1) поддержания установленной TLS-сессии в активном состоянии;
2) проверки, жива ли сессия ещё (актуально только для DTLS over UDP);
3) для path MTU discovery (актуально только для DTLS over UDP, и я не уверен, что это реально используется).
Если у вас нет вечноживущих соединений, не передающих фактически трафик (что само по себе вредно и упрощает организацию DDoS-атак транспортного уровня) и нет DTLS/udp, то я не вижу, как вам может помочь TLS heartbeat.
Грубо говоря, heartbeat нужен для:
1) поддержания установленной TLS-сессии в активном состоянии;
2) проверки, жива ли сессия ещё (актуально только для DTLS over UDP);
3) для path MTU discovery (актуально только для DTLS over UDP, и я не уверен, что это реально используется).
Если у вас нет вечноживущих соединений, не передающих фактически трафик (что само по себе вредно и упрощает организацию DDoS-атак транспортного уровня) и нет DTLS/udp, то я не вижу, как вам может помочь TLS heartbeat.
Уже 8 вечера, а Raiffeisen всё тормозит. Facepalm (
Да это ужас какой-то. Я им только что звонил, а отправил письмо 6 часов назад. Сначала меня быстро переадресовали хорошему технарю, который выслушал, запротоколировал и все понял, но советовал позвонить еще по одному телефону. Там ответила какая-то тетка, я ей говорю, что уже 6 часов прошло (непомерно много!), а она мне говорила таким тоном, будто я в очередь влажу. Бросил трубку.
У них там трафик прямо от банк-клиента можно plaintext получать.
У них там трафик прямо от банк-клиента можно plaintext получать.
У Альфы слушать траф клиента не пробовал?
Сам юзаю на постоянной основе, как-то ссыкотно — а линукс-машины под рукой нет, чтоб поснифать на проверку.
Сам юзаю на постоянной основе, как-то ссыкотно — а линукс-машины под рукой нет, чтоб поснифать на проверку.
Да. Жуть. Plaintext логины и пароли для прямого доступа в банкинг. Но пофиксили после моего письма и звонка быстро.
Я про эксплоит, если что.
Я про эксплоит, если что.
Интересно, многие пользуются стандартным ящиком security@domain.tld? Если писали на него, то не поделитесь статистикой?
И действительно открыто.
Кто-нибудь, кто на ты с этим коммитом, может пояснить в чем собственно проблема? Что-то я втыкаю в этот кусок кода и не вижу проблемы.
Вопрос снимается, нашел: github.com/openssl/openssl/commit/7e840163c06c7692b796a93e3fa85a93136adbb2
Знатный выдался Patch Tuesday!
Рядовому юзеру интернета что-то надо предпринять?
Надеяться, что данные не уплывут, как например на mail.yahoo.com уже целый день сливают…
Проверить есть ли уязвимость на сайте к которому вы собираетесь подключиться. Если есть, то лучше к нему не подключаться, пока они её не закроют, иначе рискуете быть взломанным, т.к. ваш логин и пароль может попасть в руки злоумышленников.
Автор, действительно, порекомендуйте простым пользователям не заходить пока на уязвимые сайты, чтобы их данные не оказались в оперативной памяти сервера и не могли быть оттуда прочитаны злоумышленником.
Мне вот интересно когда разродятся OpenVPN на апдейт для Windows.
openvpn.net/index.php/open-source/downloads.html
openvpn.net/index.php/open-source/downloads.html
Под Windows и OpenSSL ещё не собрали.
Вот это поворот…
Благодарю за разъяснения.
Благодарю за разъяснения.
Хотя стоп, уже собрали ведь:
slproweb.com/products/Win32OpenSSL.html
OpenSSL 1.0.1g
… тьфу, это я слепой. OpenVPN тоже обновился уже, просто неочевидно по дате это
slproweb.com/products/Win32OpenSSL.html
OpenSSL 1.0.1g
… тьфу, это я слепой. OpenVPN тоже обновился уже, просто неочевидно по дате это
Прошу прощения, я забыл алфавит.
OpenVPN собрали под винду, а вот патченного исходника под никсы, и уж тем более, пакетов, я пока не вижу.
Или я тоже слепой?
Или я тоже слепой?
Хотя, вроде как отставить тревогу — слинковано, судя по всему, в Дебиане сразу напротив нужных либ:
root@maniac ~ # ldd /usr/sbin/openvpnУ libssl.so.1.0.0 и libcrypto.so.1.0.0 дата изменения 8-го апреля в 01-26 ночи, так что вроде как все в порядке (?). Кто-нибудь может у себя проверить?
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)
Поистине эпическая уязвимость.
Такой утечки персональных данных и паролей пользователей, какая я уверен произошла сегодня, мир ещё не видывал.
Бьюсь об заклад ещё очень долго будут расхлёбываться последствия этого.
Такой утечки персональных данных и паролей пользователей, какая я уверен произошла сегодня, мир ещё не видывал.
Бьюсь об заклад ещё очень долго будут расхлёбываться последствия этого.
Самое страшное, что некоторым насрать. Yahoo.com насрать, банкам насрать, мелким сайтам насрать, неопытным сисадминам насрать, людям, которые считают, что уязвимость незначительная, насрать. Всем насрать, только нам не насрать.
ну так не их же пароли и деньги утекли, чего чесаться
Приятно удивила оперативная реакция Альфа-Банка, который не мог подписать свои java-аплеты в течении полугода.
У остальных может не быть процедуры по экстренной установке патчей и в лучшем случае будут ждать окна обслуживания, а в худшем — сертификации всего комплекса ПО.
У остальных может не быть процедуры по экстренной установке патчей и в лучшем случае будут ждать окна обслуживания, а в худшем — сертификации всего комплекса ПО.
где-то на просторах интернета писали что у части реселлеров одного очень известного регистратора до сих пор ничего не пофикшено, двухфакторки нет и по словам поддержки и не планируется, тем временем в свободном доступе за час от них ушло около 300(!!!!!) сессий в куках. Далее пишут, что попробовали авторизоваться в парочку для проверки и на каждом из них по 5-10 доменов. Жаль, что я забыл где это читал или видел, поэтому не знаю где это найти и вряд ли узнаю если спросят, увы. Таким образом все сервисы делают хуже только клиентам, которых жалко только нам и которым неохота делать подлянки.
Информация для тех кто держит сервера на AWS.
Последнии версии которые находятся в репозитории (openssl-1.0.1e-37.66.amzn1.x86_64 и openssl-1.0.1e-37.66.amzn1.i686) уже пропатчены от данной уязвимости.
Последнии версии которые находятся в репозитории (openssl-1.0.1e-37.66.amzn1.x86_64 и openssl-1.0.1e-37.66.amzn1.i686) уже пропатчены от данной уязвимости.
Тем временем, yahoo.com запатчили.
Хрень какая-то. Два одинаковых сервера, Ubuntu 12.04, на обоих сделан апдейт, на обоих одинаковая версия OpenSSL (1.0.1-4ubuntu5.12) стоит, оба перезагрузил. В итоге: один уязвим, второй — нет. Чего делать — ХЗ. Сервисы перезапускал руками несколько раз.
Все три сервиса проверки показывают одинаково.
Все три сервиса проверки показывают одинаково.
В соседнем аналогичном топике нашлось решение.
Если вы на 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
Банк «Русский Стандарт» до сих пор уязвим. Написал в поддержку.
Тьфу черти полосатые, надо же такой чудненький код закомитить в такой продукт…
АйМаниБанк запатчились.
А еще меня забанили на banki.ru по причине «спам».
А еще меня забанили на 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
>
Забейте на них, какие-то агрегаторы новостных подборок. Без громких и массовых эксплуатаций утечек новостей через СМИ не будет.
В среднем по больонице получилось, что у мошенников было около 12 часов на сбор пользовательских данных и сомнительно, что сразу же найдут применение всему слитому, т.к. много мусора. Страшно будет, если получат доступ к внутренним ресурсам и назаливают шелов.
Я вот думаю, что делать с яндекс.ПДД — надо заставлять пользователей менять пароли на рандом уникальный, как это для всех провести — хз. Надо бы сессии сбросить и заставить менять со сравнением версий паролей…
PS: Прилетало обновление WP и плагинов-чекалок секюрности — как-то ребята не вовремя, кажется. Долго бродил по репозиториям и форумам — проверял оригинальность источников и решил отложить до завтра, а утром уже накатилось автоматически((
В среднем по больонице получилось, что у мошенников было около 12 часов на сбор пользовательских данных и сомнительно, что сразу же найдут применение всему слитому, т.к. много мусора. Страшно будет, если получат доступ к внутренним ресурсам и назаливают шелов.
Я вот думаю, что делать с яндекс.ПДД — надо заставлять пользователей менять пароли на рандом уникальный, как это для всех провести — хз. Надо бы сессии сбросить и заставить менять со сравнением версий паролей…
PS: Прилетало обновление WP и плагинов-чекалок секюрности — как-то ребята не вовремя, кажется. Долго бродил по репозиториям и форумам — проверял оригинальность источников и решил отложить до завтра, а утром уже накатилось автоматически((
Ну я думаю вы знали, на что шли. Глупо полагать, что все вас станут слушать.
Ак Барс Банк запатчился. Был уязвим около 87 часов.
Добавил информацию о перевыпуске сертификатов.
Добавил информацию о скомпрометированных данных.
Интеркасса прислала письмо, что необходимо сменить пароль. Молодцы!
Добавил бонусов ;)
«Не какого-то пользователя, а вашего пользователя»
«Я говорю об уязвимости — ну так вам поступает SMS-уведомление!»
Хоть «Михаил» оказался адекватным (а то можно было попасть и на кого-то вроде «ДА КАК ВЫ СМЕЕТЕ!!! Я ВЫЧИСЛЮ ВАСПО АЙПИ»), хотя интересно было бы посмотреть его дальнейшую реакцию :)
«Я говорю об уязвимости — ну так вам поступает SMS-уведомление!»
Хоть «Михаил» оказался адекватным (а то можно было попасть и на кого-то вроде «ДА КАК ВЫ СМЕЕТЕ!!! Я ВЫЧИСЛЮ ВАС
Великолепно.
– Я ничего не понимаю (у меня нет инструкций по вашим ключевым словам), но я вас никуда не переключу!
– Я ничего не понимаю (у меня нет инструкций по вашим ключевым словам), но я вас никуда не переключу!
Шедеврально. Походу, девушка хотела поскорее закончить рабочий день и не заморачиваться поиском нужного специалиста.
Добавил ссылку на статью на banki.ru
Альфа-Банк отрицает уязвимость. а banki.ru — ссыкуны
Альфа-Банк отрицает уязвимость. а banki.ru — ссыкуны
Альфа-Банк отрицает уязвимость.Так их банкинг («Альфа-клик») разве не на Яве, в которой собственная реализация?
Что вы имеете ввиду под «на Яве»? JAVA-апплетов никаких не запускается. Или вы, возможно, имеете ввиду, что он работает на каком-нибудь Tomcat? Уязвимость вполне могла быть в балансировщике между томкэтами, например.
Ну, судя по адресу, на который перекидывает при заходе на Клик (https://click.alfabank.ru/adfform/auth.jspx), там именно сервлет-контейнер. Конкретно этот поддомен (click.alfabank.ru) проверялся на уязвимость?
Да, конкретно этот. По крайней мере, в Server написано BigIP, это, вероятно, балансер от F5 Networks, мог быть уязвим именно он.
Может, тогда до них самих не дошло, что у них балансер
Терминация SSL/TLS может быть не на балансировщике, а на балансируемых серверах. Дабы не распространять зону доверия на внешнюю контору.
С таким качеством кода я не удивлен:
if (1 + 2 + 16 > s->s3->rrec.length)
Приватбанк отписался, что знает об уязвимости (но ничего не исправили).
Русский Стандарт исправили меньше за час после сообщения (но знали и ранее).
Банк Зенит молчит.
OTП Банк молчит.
Русский Стандарт исправили меньше за час после сообщения (но знали и ранее).
Банк Зенит молчит.
OTП Банк молчит.
У привата уязвим только сайт, а не интернет-банкинг.
Русский стандарт реагировал около суток (см. таблицу)
Зенит знает о проблеме, это единственный банк, который меня с сисадмином напрямую соединил. Но не запатчили еще почему-то, да.
Про ОТП Банк не знал, сейчас им позвоню.
Русский стандарт реагировал около суток (см. таблицу)
Зенит знает о проблеме, это единственный банк, который меня с сисадмином напрямую соединил. Но не запатчили еще почему-то, да.
Про ОТП Банк не знал, сейчас им позвоню.
ОТП закрыл уязвимость.
Системный администратор Банка Зенит, кому я сообщал об уязвимости сегодня утром, видимо, узнал, что новый аниме сезон началася, пошел домой смотреть мультики и отключил телефон. По крайней мере, я недалеко от истины.
Сбербанк-онлайн я так понимаю пронесло (windows, не используют openssl)?
У них IIS.
Скажите, а где можно увидеть конкретный пример применения этой уязвимости на каком-либо сайте?
Вот например. А вообще в область в 64 КБ почти всегда (субъективно) попадают чьи-то заголовки, так что можно посмотреть пример самому.
Написал скрипт, который дампил в файл в течении получаса вывод hb-test.py одного игрового сайта.
Потом грепнул по паролям.
В итоге 10 троек логин-пароль-почта вновь зарегистрованных, из которых несколько паролей подошли к почте и там были привязаны социальные сети.
Страшная вещь если не фиксить, весь трафик сайта как на ладони.
Потом грепнул по паролям.
В итоге 10 троек логин-пароль-почта вновь зарегистрованных, из которых несколько паролей подошли к почте и там были привязаны социальные сети.
Страшная вещь если не фиксить, весь трафик сайта как на ладони.
Проверил lastpass.com, сейчас вроде всё ок: possible.lv/tools/hb/?domain=lastpass.com
Но получается, что могли получить мою куку с которой обращается браузерный плагин к серверу и получить по ней все пароли?
Представляю, сколько у меня уйдёт времени на то чтобы поменять все пароли…
Но получается, что могли получить мою куку с которой обращается браузерный плагин к серверу и получить по ней все пароли?
Представляю, сколько у меня уйдёт времени на то чтобы поменять все пароли…
А вот и удостоверяющие центры (представители GlobalSign) плюются хэдерами: prontossl.com, totallyssl.com
Многие западные сервисы (ifttt.com, appfog и др.) сделали рассылку с рекомендацией сменить пароль.
Почему наши все молчат, в частности Яндекс?
Почему наши все молчат, в частности Яндекс?
А эта библиотека случайно не используется в прошивках роутеров на безу WRT или в серверных IPMI интерфейсах?
Обновили пакет судя по trac-у openwrt
Надо так же собирать информацию по версиям и исправлениям… Используется, в частности при доступе к серверам авторизации (уточнять надо, пробежал по диагонали эту статью с хабра).
Надо так же собирать информацию по версиям и исправлениям… Используется, в частности при доступе к серверам авторизации (уточнять надо, пробежал по диагонали эту статью с хабра).
пакет-то обновили, но в прошивки он попадет только в след релизе, кому не охота ждать сюда habrahabr.ru/post/218713/#comment_7480227
Интересная получилась схема. Сначала новость «АНБ нас всех прослушивает, давайте переходить на HTTPS». Через несколько месяцев, когда все нужные данные слиты «Ой, оказывается в HTTPS есть дыра, через которую можно слить много ценной инфы».
Райффайзен написали новость о том, что необходимо сменить пароли: www.raiffeisen.ru/about/press/dist/index.php?id28=29220
В Твиттере написал им, что ещё неплохо было бы перевыпустить сертификат: twitter.com/Raiffeisen_Ru/status/454147951208988672. Молчат.
В Твиттере написал им, что ещё неплохо было бы перевыпустить сертификат: twitter.com/Raiffeisen_Ru/status/454147951208988672. Молчат.
SSO в vCenter использует OpenSSL и некоторые другие java продукты. Так что для Windows это тоже проблема.
Написал в саппорт Судостроительного.
Кстати, в чём реальный рсик для клиентов банков? Даже утекший пароль не большая проблема, если операции требуют подтверждения по SMS. Ну, максимум кто-то поулчит выписку по моему счёту — ничего страшного.
Кстати, в чём реальный рсик для клиентов банков? Даже утекший пароль не большая проблема, если операции требуют подтверждения по SMS. Ну, максимум кто-то поулчит выписку по моему счёту — ничего страшного.
Всем, кто спрашивал меня про PVS-Studio: Скучная статья про проверку OpenSSL.
А OpenSSL HeartBleed только интернету страшен, всякие диалоговые сигнализации для автомобилей его не используют случайно?
РЖД с пластиковыми картами попали под раздачу — sos-rzd.com/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Последствия OpenSSL HeartBleed