Пользователь
46,8
рейтинг
8 апреля 2014 в 16:53

Разработка → Последствия OpenSSL HeartBleed

image

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

Что произошло?

1 января 2012 года, Robin Seggelmann отправил, а steve проверил commit, который добавлял HeartBeat в OpenSSL. Именно этот коммит и привнес уязвимость, которую назвали HeartBleed.

Насколько она опасна?
Эта уязвимость позволяет читать оперативую память кусками размером до 64КБ. Причем уязвимость двусторонняя, это значит, что не только вы можете читать данные с уязвимого сервера, но и сервер злоумышленника может получить часть вашей оперативной памяти, если вы используете уязвимую версию OpenSSL.

Злоумышленник может подключиться к, предположим, уязвимому интернет-банку, получить приватный SSL-ключ из оперативной памяти и выполнить MITM-атаку на вас, а ваш браузер будет вести себя так, будто бы ничего и не произошло, ведь сертификат-то верный. Или просто может получить ваш логин и пароль.

Каков масштаб трагедии?

По моим оценкам, примерно ⅔ вебсайтов используют OpenSSL для HTTPS-соединений, и примерно ⅓ из них были уязвимы до сегодняшнего дня.

Уязвимость была/есть, как минимум, у:
  • 10 банков
  • 2 платежных систем
  • 8 VPN-провайдеров
  • mail.yandex.ru
  • mail.yahoo.com


Используя уязвимость, с mail.yandex.ru можно было получить письма пользователей вместе с HTTP-заголовками (и, подставив cookie, зайти под этим пользователем), а, например, в АльфаБанке получать незашифрованные POST-данные с логином и паролем от Альфа-Клик (интернет-банкинг).

Что я предпринял?

Я не мог просто так сидеть и смотреть, как персональные данные пользователей утекают в руки злоумышленников.
Первым делом, я написал некоторым VPN-провайдерам, которые предоставляют доступ по протоколу OpenVPN, т.к. он мог быть уязвим. Затем, я начал искать уязвимости в системах, уязвимости в которых представляют наибольшую угрозу: банки, платежные системы, почтовые/jabber серверы. Я звонил и писал уязвимым сервисам. Как правило, до службы безопасности банков пробраться крайне сложно, и отвечают они только на почту.

Сервис Время отправки письма Время совершения звонка Время закрытия уязвимости Перевыпустили сертификат Утекшие данные
mail.yandex.ru 12:46, 13:27 (в bug bounty, чтобы быстрее ответили) 12:47 14:07 Нет Почта, cookie
Альфа-банк 12:51 12:59 14:00 Нет Логины и пароли пользователей, транзакции, личные данные пользователей, cookie. Отрицают уязвимость!!
Liqpay 13:15 - 15:15 Нет Нет (мусор, куски perl-скриптов)
Interkassa 13:15 13:20 18:28 Да Транзакции, cookie
Raiffeisen 13:35 13:30 ~19:00 Нет N/A
Банк «Открытие» 15:36 - ближе к вечеру Нет N/A
Банк Москвы - ~15:30 ~17:00, уязвим был только сайт - -
Yahoo.com - - 22:20 Да Логины и пароли пользователей, почта, cookie
АйМаниБанк - 14:31, 20:20 09.04 10:55 Да Логины и пароли пользователей, транзакции, cookie, личные данные пользователей
Русский стандарт 13:00 19:36, 09.04 10:38 09.04 13:00 Нет Транзакции, cookie, личные данные пользователей
ОТП Банк 09.04 14:20 09.04 14:19 09.04 15:03 Нет Транзакции, cookie, личные данные пользователей
Русславбанк ~16:00 - 09.04 ~12:00, уязвим был только сайт - -
Банк Зенит - 21:50, 09.04 11:15, 09.04 15:25 09.04 18:20 Нет Логины и пароли пользователей, cookie
Ак Барс Банк - - 11.04 15:30 Нет Логины и пароли пользователей, транзакции


Что мне делать, как пользователю?

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

Если вы используете Windows, то, скорее всего, у вас нет OpenSSL. Если вы устанавливали его вручную (например, через cygwin), то убедитесь, что ваша версия не содержит уязвимости.

После того, как вы обновите OpenSSL перезапустите все приложения, его использующие!

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

Что мне делать, как владельцу сайта/системному администратору?

Прежде всего, вы должны незамедлительно убедиться, уязвима ваша версия OpenSSL, или нет. Для HTTPS есть три сервиса: filippo.io/Heartbleed, possible.lv/tools/hb и www.ssllabs.com/ssltest. Обновите версию при необходимости. Убедитесь, что вы ставите версию с патчем, либо же 1.0.1.g.

Если у вас была уязвимая версия OpenSSL, вам следует отозвать старый SSL-сертификат — он, с большой вероятностью, скомпрометирован. Если у вас была уязвимость в сервисе — обязательно оповестите пользователей, чтобы они сменили пароли, и сбросьте сессии, если вы ими пользуетесь (PHPSESSID, JSESSID)

А я хочу подробности!

Вы можете почитать разбор уязвимости здесь, получить больше информации здесь и здесь.
629 сайтов из топ-10000 уязвимы.
Новость на cnet.com.
Статья на banki.ru

Бонус: разговор слепого с глухим, Михаил
@ValdikSS
карма
631,0
рейтинг 46,8
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • +5
    Уязвимость была, как минимум, у:
    Тот онлайн механизм проверки весь день сбоит, а сейчас пишет про то, что у них много false positive. Это тоже следует учитывать.
    • +3
      Да, есть такое. Есть еще один сервис: possible.lv/tools/hb/. Ну и можно использовать тот-скрипт-на-питоне.
  • +1
    Коллеги, а кто в курсе, что юзает для SSL Webmin? Насколько я понимаю, что-то перловое и своё?
    • +1
      Скорее всего на низком уровне используется тот же самый openssl, он же линкуется как динамическая библиотека ко всему подряд.
      • +1
        А вот нифига. Накатил патч на OpenSSL в своём wheezy — со стороны https, отдающегося через nginx, все в порядке, а вот со стороны webmin, который отдаёт юзеру страницу через свой перловый сервер, всё уже плохо. Пока потушил, сижу думаю, куда копать.
        • +6
          Точно всё перезапустили?
          • +9
            Да, милорд.
            • +7
              Нужно больше железа!
              • +9
                Постройте зиккурат.
                • +9
                  Алсо, разобрался — рестарта демонов не хватило. После ребута самого инстанса виртмашины всё заработало ок. Учитывайте это при апдейте, что ли.
                  • 0
                    На реальной машине то же — только рестарт помог! (OS: Ubuntu 12.04 LTS)
                    • +5
                      UPD: quick fix for ubuntu:
                      apt-get update && apt-get install openssl libssl1.0.0 -y
                      И перезапустите все необходимые сервисы.
                    • +1
                      Debian — та же хрень.
    • 0
      Вот тоже интересно что используют остальные 1/3 вебсайтов?
      • +1
        IIS + другие платформы или старые версии openssl без уязвимости.
        • +1
          Однако на stackoverflow оказались уязвимы балансировщики (HAProxy).
  • +26
    Настоящее веселье начнется если на секунду предположить, что в горячий патч встроен настоящий бэкдор.
    • +7
      Так опенсорс же. Я почти уверен, что ревью уже был.
      • +1
        Лично только перепроверять, а ещё лучше пересобирать из исходников, а то прилетит подставной пакет с уязвимого репозитория((
        Очень жёстко обрушена система «доверенных соединений» во всей сети.
        • +16
          Не говорите глупости. Все приличные репозитории (читай, dpkg/rpm-based) имеют криптографическую подпись с чексуммами, работающую через gpg, которая с libssl ни ногой ни душой. Потому линуксоиды так спокойно относятся к всяким «левым» миррорам. man in middle не может положить туда что-то, что будет принято локальной системой обновлений как доверенный пакет без доступа к приватному ключу gpg (о котором https-сервер в свою очередь ни сном ни духом). То же касается и репозиториев git, где коммиты подписываются (могут подписываться) криптографической подписью, делающей git пофигистичным к компрометации транспорта.
          • +3
            Да, ерунду в целом сморозил. Паранойя сегодня зашкаливает и мешает думать. Но каналов заражения репозитория, отметим, может быть много.
      • +5
        >>Так опенсорс же. Я почти уверен, что ревью уже был.

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

          Правильно. А закрытый не только не гарантирует безопасность, но даже проверить не позволяет.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Если закрыто, то уж точно пофиг, никто этот код не увидит, можно пихать туда любую хрень.

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

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

    Как они допускают в проекте единственный круг ревью кода?! Это в корне не подходящая методология проверки для критических проектов, есть же (уверен, но не проверял) куча стандартов по которым openssl сертифицируют и многие из них накладывают ограничения на процесс тестирования и проверки! Как?!
    • 0
      Спасибо за сообщение. В Debian Wheezy оперативно пришло обновление openssl, в процессе которого запустился конфигуратор с подробной информацией. Этот же конфигуратор позволяет перезагрузить демоны и советует вообще перезагрузить сервер, чтобы наверняка.
      • +1
        Тоже Debian Wheezy, openssl обновился молча (от apt-get, а не aptitude, если что). NGINX и OpenSSH так и оставались уязвимыми до ручного перезапуска.
        • 0
          Я делал apt-get update && apt-get upgrade, запустился конфигуратор.
          • 0
            Наверное, новый пакет положили или модификация от хостинга, утром с зеркал яндекса без конфигуратора было.
            • 0
              при установке нового libssl1.0.0, который как раз и был уязвим, запускается конфигуратор. Через депенденси он при apt-get install openssl не подтягивается.
          • 0
            Вчера в обновлении не было конфигуратора. Сегодня еще одно обновление и в нём уже есть.

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

        В обоих случаях — Debian Wheezy…
  • –2
    Спасибо, что сообщили. Проапгрейдил на серверной CentOS:
    Updated: openssl.x86_64 0:1.0.1e-16.el6_5.4
    • +3
      Хехе — а тестили тестилками потом? Все равно говорит, что уязвим сервер.
      • –2
        Да вот как раз тестю. И правда, говорит, что уязвим. Сейчас все апдейты прикладываю, и перегружу сервак.
        • +2
          Приложил все апдейты 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 обещает скоро положить пофиксиный пакет в официальные репы.
    • +2
      Мне кажется, или последняя сборка — это 1.0.1e-16.el6_5.7?
      • 0
        Обновил Ubuntu инстанс в амазоне — Openssl 1.0.1-4ubuntu5.12
        В CentOS обновилось до openssl-1.0.1e-16.el6_5.7.x86_64
        • 0
          Вот я сейчас тоже полностью обновил весь софт на 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

          Кто нибудь может мне объяснить, что это за версия?
          • 0
            Похоже что это порт обновленного 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"
            

          • –1
            Версия пакета какая?
            Вот тут говорят, что все ок.
            • 0
              Благодарю, да всё ок:

              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)


              Успокоили :)
          • 0
            Попробуйте выполнить команду
            aptitude show openssl
          • 0
            Вот тут подробнее про ubuntu:
            OpenSSL 1.0.1 14 Mar 2012
            built on: Mon Apr 7 20:31:55 UTC 2014
  • +10
    >Что произошло?
    >1 января 2012 года…

    Ох уж эти празники…
  • 0
    В 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
  • +35
    Хм, ок, вот мои 5 копеек
    — чтоб читать по 64к через UDP надо постараться и быть очень рядом в сети, реальные размеры пакетов 576, 1500 байт, много через такой свисток не выжмешь, а указывать смещения от куда читать данные возможности нет — соответсвенно, либо будешь читать из одного и того же места либо из случайных и склеить полученные данные весьма проблематично
    — выкачать секретные документы через такой свисток на практике близко к невозможному
    — инициализация либы происходит в порядке инициализации данных под ключи потом уже данных под соединения — соответсвенно данные что можно будет читать из хипа текущего процесса будут (вероятней всего) лежать уже после ключей и чтение будет происходить по совсем другим адресам.
    — чтение слепое, нет возможности двигать окно — соответсвенно все это на удачу, реальные ключи выглядят как мусор и склеить их из нескольких пакетов задача близкая к невозможному.
    — реальные сертификаты достаточно большие и не помещаются в обычные 1500 байтные пакеты, соответсвенно выкачать целиком сертификат…
    В общем есть баг, серьезный, но реальная его эксплуатация это 2 ведра удачи плюс ложка интеллекта.
    • +1
      Ведро, не ведро, но бывает в памяти хранятся имена пользователей и пароли, а это уже отличный улов (даже без паролей, уже неплохо), т.к. такие комбинации распарсиваются на раз и перебираются на этом же сервере на два.
      • +4
        Я с Вами согласен, теоритически это очень опасный баг. Хотя есть маленькое упраждение на воображение — вы аттакующий, и читаете куски данных с удаленной машины, как вы узнаете что вы считали пароль (UTF8, UTF-16/32, binary random), как узнать что пароль у вас на руках весь а не кусок, как получить другой кусок, как их склеить? очень много вопросов.
        • –2
          Я с вами согласен, это очень проблематично. Тут вступают в дело алгоритмы, подобные тем, как склеивают панорамы, или как тут на хабре был пост про конкурс склейки листа бумаги из шредера. Затем проводится анализ на символьные классы. По POSIX'у это [:graph:] или [\x21-\x7E], что значит «Печатные символы». Можно задать длину 20 символов максимально. Прогоняя через словарь можно узнать имена пользователей. Остальное пароли. Как-то так.
          • 0
            Если склеиваем большую строку (а память процесса можно так представить), проще взять алгоритмы из shotgun sequencing.
        • +9
          если в дампе (полученным через python-скрипт из прошлой темы) одного вебсайта одной не-российской компании, в где то 80% случаев в начале идет
          58axe0fxf7x3x1&username=kXnXuo%40gmail.com&passwd=xxaxxbcxx123&action=up…
          то думаю понять что тут — логин а что — пароль — достаточно просто.
          пусть даже в этом случаем максимум что это даст — возможность узнать что у вот этого пользователя есть такая то железка с таким то серийником. При этом тест на самих железках что они продают (и обычным пользователям), что-то очень похожие на куки доступа к веб-интерфейсу железки.

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

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

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

          • 0
            Я вам верю, в этом случае это критично, хотя у меня возникает масса вопросов по поводу того как именно хранятся эти данные в памяти, почему они лежат вот такой строкой, т.е. при доступе к ним их нужно парсить самому процессу… это не очень красиво :-)
        • 0
          Веселье начинается тогда, когда данные получаются в формализованном виде. Например, я тестировал тем самым питоновым скриптом сайт одного мессенджера, которым пользуюсь и на выходе получал JSON. Пусть и кусками, но в такой ситуации уже понять, что находится перед глазами очень просто. К счастью, паролей там не было, а были лишь списки пользователей групповых чатов. Хотя, может быть, вылезло бы что-то посерьезней, если бы я не переключился на устранение дыры на своём сервере.
    • +3
      Обычно шифрование траика нужно, чтобы спрятать критичные данные от админов устройств, через которые ваш трафик проходит.
      В данном случае, у них эти два ведра удачи уже есть. Осталась ложка и немного скуки, чтобы себя развлечь таким способом.
    • +3
      UDP? Какой UDP?
      Возможности указать адрес, похоже, действительно нет, но пакеты приходят без повреждений.

      Вы можете прямо сейчас читать чужую почту, используя скрипт на питоне и mail.yahoo.com в качестве параметра, например.
      • 0
        Возможно я не понял ваш вопрос, но 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
        • +2
          Ну HTTPS-то всегда через TCP работает.
          Мне вот только что часть ключа yahoo.com попалась.
    • +2
      Ну вот пример — погонял утилитку против одного из своих сайтов. В какой-то момент в начале длинной портянки нулей таки пролетел кусок HTTP запроса, включая куку типа sessid=NNNNNNNNNNNN. Зная формат, который мы «ловим» очень легко через этот маленький свисток, тыркать-тыркать, и регексами выцеплять то, что нам надо. А уж зная несколько байтов sessid — имеем полноценный доступ через удобный браузер, и уже выкачиваем терабайты секретов.

      P.S.
      UDP-то тут причем, оно все через TCP работает же.
      • +1
        Да, ошибся, оказывается сердцебиения используются не только для 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, но не зависит ли его правильная пересборка от оборудования?
        • 0
          Как UDPшный себя поведет — не знаю, но для TCP тут проблем никаких нет, у меня мой сервак мне отлично сливает дампы с индексами от 0000 до 3ff0 что гораааздо выше MTU. Может можно и .avi'шку одним запросом случайно так «скачать».
        • 0
          Не зависит. Дроблением на фрагменты и обратной сборкой занимается третий уровень — а там все уже давно стандартизовано.
    • 0
      выделение памяти не совсем рэндом все-таки, маркеры характерные выделить какие ни будь
    • +5
      Гонял тот-самый-скрипт-на-питоне. Экспериментировал на различных форумах с различными движками и на Steam (в Steam уже закрыли).

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

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

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

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

      Так что если словить в запросах вход пользователя или админа, и если нет ограничений на IP сессии и т.д., то задача выкачивания секретных документов может быть вполне решаемой.
      • –1
        А что за скрипт, можете подробней написать?
        • 0
          ssltest.py, его уже несколько раз в предыдущем (и вроде в этом) топиках выкладывали же
    • +12
      Ну вот пожалуйста, «реальная эксплуатация» не заставила себя долго ждать. Не знаю, может это Activision сами сделали, но скорее всего кто-то все же словил чьи-то куки.
      Changed name Call of Duty: Black Ops II › Valve please reset partner logins because heartbleed
      image
      steamcommunity.com/discussions/forum/12/558752450282315846/
      steamdb.info/app/202970/#section_history
  • +7
    Внимание, простое обновление системы не убирает уязвимость!

    На примере Debian, обновление openssl не вызвало перезапуска nginx (то же самое касалось бы почтовых серверов, XMPP, IRC, SSH и прочих SSL-серверов). Не забудьте перезапустить сервисы вручную!
    • 0
      Как я отписал выше: habrahabr.ru/post/218661/#comment_7477811, новая версия запускает конфигуратор, делающий перезапуск.
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Маленький fix: ssh — не использует SSL/TLS.

      А всякие slapd, nginx, apache, lighttpd, postfix/exim/sendmail перезапускать надо.
  • 0
    А мобильные системы подвержены? Android / iOS?
    • 0
      Пока не совсем понятно. По крайней мере, Android 4.1+ использует уязвимую версию OpenSSL, но в ней, вроде, Heartbeat отключен.
      • 0
        Busybox нас спасёт, все дела?
  • 0
    Похоже у QIwi все в порядке
  • +6
    Внезапно, драма. В убунте этому апдейту поставили 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
    
    • 0
      Видимо, они, не подумав, применили полиси от CVE-2014-0076. У того CVE и вправду urgency=medium, почитайте вот.
  • +3
    А что вообще дает это расширение? В Gentoo есть флаг tls-heartbeat, может его вырубить, пока дело не уляжется?
    • –2
      «Дело уляжется» как только вы обновите openssl и перезапустите зависимые сервисы. В чём смысл после этого отключать heartbeat? Или у вас есть инсайдерская инфа что следующий серьёзный баг тоже будет найден в коде heartbeat? :-)
      • +2
        По результатам чтения гентушной багзилы пришел к тому же выводу, что и victor1234. Там разработчики говорят, что типа «код новый, категорической пользы не несет, вполне можно отрубить». Я вот у себя на серверах помимо обновления openssl, поотрубал heartbeat вообще, полет нормальный вроде.

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

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

          Если у вас нет вечноживущих соединений, не передающих фактически трафик (что само по себе вредно и упрощает организацию DDoS-атак транспортного уровня) и нет DTLS/udp, то я не вижу, как вам может помочь TLS heartbeat.
  • +7
    Уже 8 вечера, а Raiffeisen всё тормозит. Facepalm (
    image
    • +7
      Да это ужас какой-то. Я им только что звонил, а отправил письмо 6 часов назад. Сначала меня быстро переадресовали хорошему технарю, который выслушал, запротоколировал и все понял, но советовал позвонить еще по одному телефону. Там ответила какая-то тетка, я ей говорю, что уже 6 часов прошло (непомерно много!), а она мне говорила таким тоном, будто я в очередь влажу. Бросил трубку.

      У них там трафик прямо от банк-клиента можно plaintext получать.
      • 0
        У Альфы слушать траф клиента не пробовал?
        Сам юзаю на постоянной основе, как-то ссыкотно — а линукс-машины под рукой нет, чтоб поснифать на проверку.
        • 0
          Да. Жуть. Plaintext логины и пароли для прямого доступа в банкинг. Но пофиксили после моего письма и звонка быстро.

          Я про эксплоит, если что.
          • 0
            Странно, клиент сегодня не обновлялся вовсе, кхм.
            Чо, логины даже засолены не были?
            • 0
              Ну, там же через веб-сайт вход, через HTTPS. Вот эксплоит и позволял посмотреть нешифрованные данные POST-запроса.
              • 0
                Позвольте уточнить, поскольку не совсем разобрался в природе уязвимости: вашего POST-запроса или случайного чужого?
                • +1
                  Случайного чужого.
          • 0
            Но пофиксили после моего письма и звонка быстро.

            … а сертификат от декабря 2012 оставили.
      • 0
        Интересно, многие пользуются стандартным ящиком security@domain.tld? Если писали на него, то не поделитесь статистикой?
    • 0
      И действительно открыто.
  • 0
    Кто-нибудь, кто на ты с этим коммитом, может пояснить в чем собственно проблема? Что-то я втыкаю в этот кусок кода и не вижу проблемы.
  • +2
    Знатный выдался Patch Tuesday!
  • 0
    Рядовому юзеру интернета что-то надо предпринять?
    • +2
      Надеяться, что данные не уплывут, как например на mail.yahoo.com уже целый день сливают…
    • +3
      Проверить есть ли уязвимость на сайте к которому вы собираетесь подключиться. Если есть, то лучше к нему не подключаться, пока они её не закроют, иначе рискуете быть взломанным, т.к. ваш логин и пароль может попасть в руки злоумышленников.
  • +4
    Автор, действительно, порекомендуйте простым пользователям не заходить пока на уязвимые сайты, чтобы их данные не оказались в оперативной памяти сервера и не могли быть оттуда прочитаны злоумышленником.
    • +2
      Готово
    • +2
      +сюда же — нужно обязательно сменить пароль после того, как сайты закроют у себя эту дырку, потому что потенциально он мог быть сосниффан.
      • +1
        Мне кажется, или лучше поменять пароль ещё и когда сайты поменяют сертификаты?
  • 0
    Мне вот интересно когда разродятся OpenVPN на апдейт для Windows.
    openvpn.net/index.php/open-source/downloads.html
    • 0
      Под Windows и OpenSSL ещё не собрали.
      • 0
        Вот это поворот…

        Благодарю за разъяснения.
      • +2
        Хотя стоп, уже собрали ведь:
        slproweb.com/products/Win32OpenSSL.html

        OpenSSL 1.0.1g

        … тьфу, это я слепой. OpenVPN тоже обновился уже, просто неочевидно по дате это
        • 0
          Прошу прощения, я забыл алфавит.
        • 0
          OpenVPN собрали под винду, а вот патченного исходника под никсы, и уж тем более, пакетов, я пока не вижу.
          Или я тоже слепой?
          • 0
            Хотя, вроде как отставить тревогу — слинковано, судя по всему, в Дебиане сразу напротив нужных либ:
            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 ночи, так что вроде как все в порядке (?). Кто-нибудь может у себя проверить?
  • +7
    Поистине эпическая уязвимость.
    Такой утечки персональных данных и паролей пользователей, какая я уверен произошла сегодня, мир ещё не видывал.
    Бьюсь об заклад ещё очень долго будут расхлёбываться последствия этого.
    • +27
      Самое страшное, что некоторым насрать. Yahoo.com насрать, банкам насрать, мелким сайтам насрать, неопытным сисадминам насрать, людям, которые считают, что уязвимость незначительная, насрать. Всем насрать, только нам не насрать.
      • 0
        ну так не их же пароли и деньги утекли, чего чесаться
      • 0
        Приятно удивила оперативная реакция Альфа-Банка, который не мог подписать свои java-аплеты в течении полугода.
        У остальных может не быть процедуры по экстренной установке патчей и в лучшем случае будут ждать окна обслуживания, а в худшем — сертификации всего комплекса ПО.
      • +3
        где-то на просторах интернета писали что у части реселлеров одного очень известного регистратора до сих пор ничего не пофикшено, двухфакторки нет и по словам поддержки и не планируется, тем временем в свободном доступе за час от них ушло около 300(!!!!!) сессий в куках. Далее пишут, что попробовали авторизоваться в парочку для проверки и на каждом из них по 5-10 доменов. Жаль, что я забыл где это читал или видел, поэтому не знаю где это найти и вряд ли узнаю если спросят, увы. Таким образом все сервисы делают хуже только клиентам, которых жалко только нам и которым неохота делать подлянки.
  • 0
    Информация для тех кто держит сервера на AWS.
    Последнии версии которые находятся в репозитории (openssl-1.0.1e-37.66.amzn1.x86_64 и openssl-1.0.1e-37.66.amzn1.i686) уже пропатчены от данной уязвимости.
  • 0
    Тем временем, yahoo.com запатчили.
  • 0
    Хрень какая-то. Два одинаковых сервера, Ubuntu 12.04, на обоих сделан апдейт, на обоих одинаковая версия OpenSSL (1.0.1-4ubuntu5.12) стоит, оба перезагрузил. В итоге: один уязвим, второй — нет. Чего делать — ХЗ. Сервисы перезапускал руками несколько раз.
    Все три сервиса проверки показывают одинаково.
  • +2
    Если вы на 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
    
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Банк «Русский Стандарт» до сих пор уязвим. Написал в поддержку.
    • 0
      И еще, как минимум, два. Я им звонил, им насрать.
      • 0
        Райф тоже до сих пор такой же?
        • 0
          Нет. А вот РС — да.
          • 0
            Они (райфы) сертификат обновили?
            • 0
              Nope.
              • 0
                Ну и смысл тогда? :-)

                Спасибо большое.
    • 0
      ОТП уязвим
    • +1
      Вроде РС исправили.
  • 0
    Тьфу черти полосатые, надо же такой чудненький код закомитить в такой продукт…
  • НЛО прилетело и опубликовало эту надпись здесь
  • +21
    АйМаниБанк запатчились.
    А еще меня забанили на 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
    >
    • +3
      Забейте на них, какие-то агрегаторы новостных подборок. Без громких и массовых эксплуатаций утечек новостей через СМИ не будет.
      В среднем по больонице получилось, что у мошенников было около 12 часов на сбор пользовательских данных и сомнительно, что сразу же найдут применение всему слитому, т.к. много мусора. Страшно будет, если получат доступ к внутренним ресурсам и назаливают шелов.

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

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

        Я с вами не согласен. Наоборот, мусора практически нет. Почти от всех банков мне прилетал либо логин/пароль, либо cookie (без ограничения по IP). А про почту и говорить не стоит.
    • –3
      Ну я думаю вы знали, на что шли. Глупо полагать, что все вас станут слушать.
    • 0
      Ак Барс Банк запатчился. Был уязвим около 87 часов.
  • +3
    Добавил информацию о перевыпуске сертификатов.
    • +3
      Добавил информацию о скомпрометированных данных.
      • 0
        Интеркасса прислала письмо, что необходимо сменить пароль. Молодцы!
        • +4
          Добавил бонусов ;)
          • +2
            «Не какого-то пользователя, а вашего пользователя»
            «Я говорю об уязвимости — ну так вам поступает SMS-уведомление!»
            Хоть «Михаил» оказался адекватным (а то можно было попасть и на кого-то вроде «ДА КАК ВЫ СМЕЕТЕ!!! Я ВЫЧИСЛЮ ВАС ПО АЙПИ»), хотя интересно было бы посмотреть его дальнейшую реакцию :)
          • +1
            Великолепно.
            – Я ничего не понимаю (у меня нет инструкций по вашим ключевым словам), но я вас никуда не переключу!
          • 0
            Шедеврально. Походу, девушка хотела поскорее закончить рабочий день и не заморачиваться поиском нужного специалиста.
          • +3
            Добавил ссылку на статью на banki.ru
            Альфа-Банк отрицает уязвимость. а banki.ru — ссыкуны
            • 0
              Альфа-Банк отрицает уязвимость.
              Так их банкинг («Альфа-клик») разве не на Яве, в которой собственная реализация?
              • 0
                Что вы имеете ввиду под «на Яве»? JAVA-апплетов никаких не запускается. Или вы, возможно, имеете ввиду, что он работает на каком-нибудь Tomcat? Уязвимость вполне могла быть в балансировщике между томкэтами, например.
                • 0
                  Ну, судя по адресу, на который перекидывает при заходе на Клик (https://click.alfabank.ru/adfform/auth.jspx), там именно сервлет-контейнер. Конкретно этот поддомен (click.alfabank.ru) проверялся на уязвимость?
                  • 0
                    Да, конкретно этот. По крайней мере, в Server написано BigIP, это, вероятно, балансер от F5 Networks, мог быть уязвим именно он.
                    • 0
                      Может, тогда до них самих не дошло, что у них балансер
                      • 0
                        Терминация SSL/TLS может быть не на балансировщике, а на балансируемых серверах. Дабы не распространять зону доверия на внешнюю контору.
                        • 0
                          Тогда бы уязвимости не было, Java же OpenSSL не использует.
                          Ну, а вообще на входе в Клик двухфакторная авторизация через СМС, сброс сессии при одновременном открытии более одной страницы, таймаут чуть ли не 2 минуты и прочая паранойя.
                          • 0
                            Вообще, я выдвинул неправдоподобный вариант, т. к., исходя из указанных выше заголовков, балансировка происходит на L7. В таком случае балансировщик обязательно обладает ключом и сертификатом. Терминация SSL/TLS на конечных серверах возможна, если балансировка тупая: virtual ip, например.
  • +6
    С таким качеством кода я не удивлен:
    if (1 + 2 + 16 > s->s3->rrec.length)
    • 0
      В комментариях к патчу на гитхабе уже есть замечания, что в будущем возможны проблемы.
  • +1
    Приватбанк отписался, что знает об уязвимости (но ничего не исправили).

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

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

    OTП Банк молчит.
    • 0
      У привата уязвим только сайт, а не интернет-банкинг.
      Русский стандарт реагировал около суток (см. таблицу)
      Зенит знает о проблеме, это единственный банк, который меня с сисадмином напрямую соединил. Но не запатчили еще почему-то, да.
      Про ОТП Банк не знал, сейчас им позвоню.
    • 0
      ОТП закрыл уязвимость.
    • +2
      Системный администратор Банка Зенит, кому я сообщал об уязвимости сегодня утром, видимо, узнал, что новый аниме сезон началася, пошел домой смотреть мультики и отключил телефон. По крайней мере, я недалеко от истины.
      • 0
        Администратор, видимо, посмотрел Soul Eater Not!, включил телефон и обновил openssl.
  • 0
    Сбербанк-онлайн я так понимаю пронесло (windows, не используют openssl)?
    • 0
      У них IIS.
  • 0
    Скажите, а где можно увидеть конкретный пример применения этой уязвимости на каком-либо сайте?
    • +1
      Вот например. А вообще в область в 64 КБ почти всегда (субъективно) попадают чьи-то заголовки, так что можно посмотреть пример самому.
      • 0
        Дело не в области, а в том, что контекст SSL, как правило, инициализируется прямо до чтения из сокета, и, собственно, ниже контекста лежат расшифрованные данные.
  • +12
    Написал скрипт, который дампил в файл в течении получаса вывод hb-test.py одного игрового сайта.
    Потом грепнул по паролям.
    В итоге 10 троек логин-пароль-почта вновь зарегистрованных, из которых несколько паролей подошли к почте и там были привязаны социальные сети.

    Страшная вещь если не фиксить, весь трафик сайта как на ладони.
    • 0
      можно посмотреть на скрипт?
      • 0
        Просто по циклу вызывал питоновый скрипт и перенаправлял вывод в файл при помощи >>.
  • 0
    Проверил lastpass.com, сейчас вроде всё ок: possible.lv/tools/hb/?domain=lastpass.com
    Но получается, что могли получить мою куку с которой обращается браузерный плагин к серверу и получить по ней все пароли?
    Представляю, сколько у меня уйдёт времени на то чтобы поменять все пароли…
    • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    А вот и удостоверяющие центры (представители GlobalSign) плюются хэдерами: prontossl.com, totallyssl.com
  • 0
    Многие западные сервисы (ifttt.com, appfog и др.) сделали рассылку с рекомендацией сменить пароль.
    Почему наши все молчат, в частности Яндекс?
    • 0
      Я не могу сказать про банки (т.к. они только своим клиентам могут делать рассылки), но Интеркасса прислала письмо, в котором говориться, что нужно-бы пароль сменить. Они вообще классные парни, мы с ними болтали по поводу уязвимости вчера.
  • 0
    А эта библиотека случайно не используется в прошивках роутеров на безу WRT или в серверных IPMI интерфейсах?
    • 0
      Обновили пакет судя по trac-у openwrt
      Надо так же собирать информацию по версиям и исправлениям… Используется, в частности при доступе к серверам авторизации (уточнять надо, пробежал по диагонали эту статью с хабра).
      • 0
        пакет-то обновили, но в прошивки он попадет только в след релизе, кому не охота ждать сюда habrahabr.ru/post/218713/#comment_7480227
  • +2
    Интересная получилась схема. Сначала новость «АНБ нас всех прослушивает, давайте переходить на HTTPS». Через несколько месяцев, когда все нужные данные слиты «Ой, оказывается в HTTPS есть дыра, через которую можно слить много ценной инфы».
    • 0
      … А дальше уже была шутка в предыдущем посте про то, что это обновление содержит новый эксплоит :)
  • 0
    Райффайзен написали новость о том, что необходимо сменить пароли: www.raiffeisen.ru/about/press/dist/index.php?id28=29220
    В Твиттере написал им, что ещё неплохо было бы перевыпустить сертификат: twitter.com/Raiffeisen_Ru/status/454147951208988672. Молчат.
    • +1
      это все хорошо, но до сих пор часть инет банков уязвима =(
      • 0
        Некоторые все еще уязвимы (11 число)
  • 0
    SSO в vCenter использует OpenSSL и некоторые другие java продукты. Так что для Windows это тоже проблема.
  • 0
    Написал в саппорт Судостроительного.

    Кстати, в чём реальный рсик для клиентов банков? Даже утекший пароль не большая проблема, если операции требуют подтверждения по SMS. Ну, максимум кто-то поулчит выписку по моему счёту — ничего страшного.
    • 0
      Симку перевыпустить — не самая большая проблема.
      На banki.ru полно отзывов об этом виде мошенничества, а ведь тут сразу видно и количество денег на счете, и фио, и номер телефона — задача сразу упрощается.
      • 0
        а если двухфакторная авторизация? сначала пароль, потом смска
    • 0
      Не похоже, чтобы они были уязвимы.
  • 0
    Всем, кто спрашивал меня про PVS-Studio: Скучная статья про проверку OpenSSL.
  • 0
    А OpenSSL HeartBleed только интернету страшен, всякие диалоговые сигнализации для автомобилей его не используют случайно?
    • 0
      Я более чем уверен, что не используют.
  • 0
    РЖД с пластиковыми картами попали под раздачу — sos-rzd.com/
    • 0
      Уже давно пост про этот сайт появился, опоздали вы с комментарием.

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