OpenSSL — рыцарь Кровоточащее Сердце

There is no knowledge that is not power

Ну-с, страсти вроде бы наконец поутихли, так что можно немножко покопаться во всей этой истории. Для начала, конечно, вкратце напомним, что же случилось. Есть такие замечательные протоколы SSL/TLS, которые позволяют надёжно зашифровать данные, передаваемые по Сети. В одном из открытых пакетов для работы с этими протоколами, причём очень популярном, — в том самом OpenSSL, в марте 2014 года внезапно (!) была найдена критическая уязвимость в реализации функции Heartbeat («сердцебиение»), от названия которой, собственно говоря, и было образовано имя Heartbleed («кровоточащее сердце»).

Функция эта нужна для периодической проверки того, что соединение не разорвано, то есть клиент и сервер постоянно «перестукиваются», отправляя друг другу коротенькие сообщения. По-хорошему, эти запросы и ответы должны быть одинаковой длины — всего с два десятка байт, однако из-за ошибки в этой функции один из участников общения мог отправить маленький пакетик, но запросить от второго участника ответ размером до 64 Кбайт, который попросту брался из памяти. В этом кусочке памяти мог быть и мусор, а могли оказаться и очень чувствительные данные вроде логинов-паролей других пользователей или даже криптоключа (сертификата) второй стороны. Отдельный вопрос в том, как автоматизировать процесс извлечения действительно важных данных из множества таких вот утянутых кусочков памяти. Технические подробности самой ошибки можно узнать из этой статьи или её перевода.

Сама эта ошибка просуществовала около двух лет, пока её не обнаружили специалисты из финской компании Codenomicon и сотрудник Google Neel Mehta. (И вот с этого момента мы имеем полное право погрузиться в пучину Теорий Заговора и прислушаться к хтоническому рыку Большого Брата.) Самое интересное то, что ошибка была найдена специалистами вышеназванных компаний независимо и практически одновременно. Хорошо, если это просто случайное совпадение. Однако не исключён и второй вариант — в Сети появилось что-то, что привлекло внимание обеих компаний. Причём это что-то должно было иметь некоторые заметные и совсем не единичные последствия своей работы. Давайте аккуратно предположим, что это была некая разновидность вредоносного ПО. Это всего лишь теория, так как никаких официальных заявлений на этот счёт не было. Вообще говоря, самое неприятное свойство Heartbleed — это жутко раздражающее состояние неопределённости. Действительно, довольно непросто понять, воспользовался ли кто-то на твоём сервисе этой уязвимостью и каков масштаб потерь, если они всё-таки были. Что делать, если у сервиса десятки миллионов пользователей и уязвимая версия OpenSSL проработала не один месяц? После починки всех деавторизовать и заставить поменять пароли? Дороговато выйдет. Впрочем, многие пользователи и сами кинулись массово менять пароли, что попутно привело к резкому скачку популярности менеджеров паролей.

А если посмотреть на всё это со стороны пользователя? В этом случае дела обстоят не лучше. Хороший пример — история с якобы утянутыми у ВТБ24+РЖД данными банковских карт покупателей. Банк отрицает возможность такой утечки. Тем временем некоторые покупатели рапортуют, что на специальном сайте, где выложены «украденные» реквизиты, действительно есть полная информация об их картах. (На всякий случай напомним читателям, что вводить данные своей карточки куда попало не следует.) И что в таком случае делать обычному пользователю? В панике заняться перевыпуском карты, если его банк уже не сделал этого, или поверить официальным заявлениям? Тут ведь ещё хитрость в том, что любые данные, полученные в результате любой уязвимости, совершенно необязательно тут же будут использованы в неблаговидных деяниях. Те же реквизиты банковских карт вполне могут «отлеживаться» месяц-другой или дольше, а Heartbleed, как известно, существует около двух лет. Одни специалисты считают, что использование Heartbleed не оставляет никаких следов. Другие утверждают, что косвенные улики таки можно найти, и одна из них, датированная ноябрём 2013 года, осталась от атаки с машин, которые являются — сюрприз-сюрприз! — частью крупного ботнета. Ещё хуже то, что некоторые вполне законные программы, похоже, могут оставлять аналогичные «улики».

Вообще, конечно, забавно было наблюдать, как некоторые компании стремительно скатились в своих официальных ответах от стадии «Да что вы, у нас такого не может быть!» к стадии «Ну-у-у, чисто теоретически атака возможна, но на практике она вряд ли реализуема», а затем и к признанию: «Да, были проблемы, но вы не беспокойтесь, мы уже всё починили!» Ярким примером стал сервис CloudFare. В первой заметке представитель компании подробно рассказал об уязвимости и предположил, что на практике украсть самое ценное, то есть приватный ключ сервера, нельзя. Однако для проверки этой теории всё-таки была создана тестовая площадка с «дырявой» версией OpenSSL, а всем желающим было предложено попытаться украсть с неё приватный SSL-ключ. Победителю понадобилось около трёх часов и 2,5 млн запросов, чтобы утащить ключ. Обладателю второго места повезло чуть больше — для «кражи» ему потребовалось только 100 тысяч запросов к конкурсному серверу. В общем, всё довольно печально, так как обладатель приватного ключа, к примеру, может организовать атаку типа MITM. Через день после публикации информации о Heartbleed компания Netcrafrt сообщила, что не менее полумиллиона сайтов были подвержены этой уязвимости, а спустя неделю только 80 тысяч сайтов отозвали и перевыпустили свои SSL-сертификаты.

Остальные в лучшем случае их перевыпустили, но не отозвали старые сертификаты, что тоже небезопасно. Столь массовые операции с большим числом SSL-сертификатов обходятся довольно дорого — как в плане финансов, так и с технической точки зрения. Заметьте, что мы сейчас говорим в первую очередь про популярные веб-серверы. OpenSSL же используется не только для реализации HTTPS, но и во множестве других программных продуктов. А что делать с различными встраиваемыми и прочими системами, для которых обновления прошивки могут быть вообще не выпущены? Взять те же роутеры и другое сетевое оборудование или смартфоны на базе Android 4.1.1. Обратите внимание, что инициировать работу уязвимой функции heartbeat может как клиент, так и сервер, а работает она в обоих случаях одинаково. Таким образом можно получить важные данные из памяти клиента. Например, достаточно отправить пользователю ссылку на специально подготовленный удалённый ресурс, который будет потихоньку утягивать из памяти его устройства те самые кусочки по 64 Кбайт. Согласитесь, не очень приятно. А уж тем более неприятно тем ресурсам, которые для повышения защиты внедрили SSL, а в результате оказались в худшем положении, чем те, кто решил не спешить с внедрением шифрования трафика. Да и нынешняя мода включать SSL даже там, где это совершенно не нужно, ни к чему хорошему не привела.

Итог по технической части примерно таков. Баг просуществовал около двух лет, он позволяет незаметно воровать критически важные данные, нет никакой абсолютно достоверной информации о его неблагонамеренном использовании в течение этого срока, нет точных данных о числе подверженных данной уязвимости пакетов ПО и оборудования, но после публичного оглашения информации об ошибке её неоднократно использовали. Кто виноват? О, это-то как раз хорошо известно — ошибка была в коде, который предоставил Robin Seggelman, занимающийся информационной безопасностью. И это, судя по отзывам его коллег, действительно непредумышленная ошибка. По нему, конечно, как следует проехались — мол, при работе с памятью как-то поаккуратнее надо быть. Второй извечный вопрос, «Что делать?», похоже, останется без ответа. Ну то есть сейчас выпустят патчи, обновят программы, перепишут свои реализации SSL/TLS и что-нибудь да посоветуют пользователям, но это всё последствия механического воздействия термически обработанного самца семейства фазановых на мягкое место. А дальше что? Опасные ошибки от этого в мгновенье ока не пропадут.

Неслучайно ведь во многих критичных системах до сих пор используется морально устаревший с точки зрения обычного пользователя софт. Его банально проверяют на надёжность, поэтому не стоит удивляться, когда в качестве базовой ОС, например, у военных всплывает какой-нибудь старенький дистрибутив GNU/Linux. Зачастую дешевле и быстрее взять для своих нужд открытое ПО, предварительно проверив его, чем с нуля писать свои компоненты. Правда, второй этап обычно игнорируют. Ну а случай с OpenSSL — это блеск и нищета opensource во всей красе. Блеск — потому что это действительно сложный и важный, но в то же время бесплатный и открытый проект, поддерживаемый энтузиастами, не все из которых профессионалы. При этом не надо думать, что открытость исходного кода действительно позволяет ему быть всегда корректнее и безопаснее закрытого ПО, хотя польза от неё всё равно есть — ошибки можно самостоятельно поправить и быстро выкатить новую версию софта. Открытость кода повышает шанс обнаружения проблем, но не гарантирует этого. В OpenSSL проверками занимался только один человек.

Нищета же тут не только в переносном — порой не хватает человеческих ресурсов для написания и проверки кода (многие проекты из-за этого просто умирают), но и в прямом смысле этого слова. Один из основателей OpenSSL Software Foundation сообщил, что ежегодно они получают около $2 000 за счёт пожертвований, что, конечно же, очень мало, если учесть важность проекта. При этом удивительны высказывания некоторых пользователей: «Они допустили такую серьёзную ошибку, да ещё и денег просят!» Это примерно то же самое, что и обвинения в адрес руководителей каких-нибудь благотворительных фондов, которые «имеют наглость» не отдавать всю свою зарплату до последней копейки в пользу страждущих.

Одним из положительных результатов истории с Heartbleed стало создание Core Infrastructure Initiative — проекта Linux Foundation по поддержке и финансированию критически важных технологий с открытым исходным кодом. К нему присоединились многие известные IT-корпорации, а первым претендентом на оказание помощи станет, конечно же, OpenSSL. Самое же удивительное, что вся эта инициатива родилась во многом благодаря грамотному освещению проблемы, что для opensource-продуктов не такое уж частое явление. В последнее время любят упоминать «информационные войны». (По идее, любая борьба в итоге сводится к информационной борьбе в психологическом и технологическом аспектах.) В случае Heartbleed борьба за внимание СМИ, компаний и пользователей прошла более чем успешно. Отличное запоминающееся имя для бага, официальный логотип, собственный веб-сайт с простым и понятным объяснением проблемы + определённая раскрутка в Сети. Всё как у больших! Да, вот только бум интереса к уязвимости закончился через пару недель. Но и такого отклика редко достигают другие, не менее серьёзные проблемы в IT, которые слабо освещаются и обсуждаются только в узких кругах профессионалов.

Забавно, что даже АНБ, которое обвинили в умышленном сокрытии информации о Heartbleed и использовании её для слежки, сподобилось опубликовать официальный ответ, воспринятый многими как фраза из анекдота: «Во-первых, не брала, а во-вторых, уже положила на место!» Знают ли спецслужбы о подобных ошибках? Вполне возможно. Используют ли? Наверняка. Внедряют их сами в opensource-проекты? Вряд ли, ведь шанс попасться на «закладке» несравнимо выше, чем в проприетарном ПО, которого и так везде хватает. Это не означает, что таких попыток — возможно, даже успешных — не было. Впрочем, есть смутные подозрения, что Heartbleed напомнит о себе ещё не раз и не два. Возможно, к моменту публикации этого материала всплывёт что-нибудь любопытное.

Что делать пользователю после всех этих страшилок? Во-первых, не переживать лишний раз — ошибки в ПО были, есть и будут. Во-вторых, проверить любимые сайты с поддержкой HTTPS на наличие Heartbleed какой-нибудь онлайн-утилитой вроде этой. Для Android есть утилитка, которая проверит не только ОС, но и установленные приложения. Если сайт и ПО не прошли проверку, то лучше отказаться от их использования. Однако если даже уязвимость не найдена, то лучше дождаться официального уведомления об этом либо, если не терпится, поменять пароли. Тут всё как обычно — пароль должен быть сложным и не использоваться на нескольких ресурсах одновременно. Если одни и те же логин с паролем использовались в нескольких местах, то их тоже будет нелишним сменить на новые. Для безопасного хранения паролей можно воспользоваться специальным софтом. Ещё одним полезным действием будет включение двухфакторной аутентификации там, где это возможно. Во всех остальных случаях придётся ждать обновления ПО.