Мое сердце остановилось (13.05.2014)

Ставшая широко известной 8 апреля этого года уязвимость в OpenSSL (самая серьезная за последние несколько лет) получила название Heartbleed. Такого слова словари в отрыве от контекста не знают, но перевести это можно как “кровоточащее сердце”. Название очень удачное: оно отражает и весь драматизм проблемы, и то, что атака использует ошибки в реализации предложенного несколько лет назад расширения Heartbeat.

Что произошло с технической точки зрения? Постоянно открытые соединения удобнее и экономичнее по ресурсам, чем открываемые “по потребности”. Чтобы избежать накладных расходов, которые при постоянном открытии-закрытии соединения довольно велики, было предложено расширение протокола TLS под названием Heartbeat. Если клиент и сервер поддерживают это расширение, то, как бы проверяя пульс, клиент присылает данные и указывает их длину, а сервер должен послать их обратно. В спецификации этого расширения говорилось о том, что слишком длинные пакеты, пришедшие от клиента, надо игнорировать, но ничего не говорилось о необходимости сверки длины данных, идущих туда-обратно, с общей длиной пакета.

Как известно, труднее всего найти место, где что-то НЕ сделано — то, что сделано не так, обычно найти проще. В данном случае не делалась проверка, что запрошено столько байт, сколько передано. В результате приложение выделяло большой буфер, и туда копировались данные, пришедшие от клиента. Что было в буфере за пределами скопированных данных? А тут уже как повезет: это мог быть, к примеру, участок, взятый из памяти текущего приложения (а не заполненный нулями). Туда мог попасть и секретный ключ, если он был в памяти, и http-заголовки cookie, содержащие данные о клиентских сессиях, и, в конце концов, банальные пары логин-пароль. Поскольку обращаться за довольно большим (до 64 килобайт) куском памяти можно неоднократно, то у злоумышленников была возможность методично “просеивать” память до нахождения чего-нибудь по-настоящему интересного. Популярный комикс XKCD уже откликнулся объяснением “для чайников”, наглядным и довольно точным.

Какие данные на самом деле «утекают», зависит от версии операционной системы, программного обеспечения и, в конце концов, удачи. Например, известны случаи утечки cookies, с помощью которых отличаются друг от друга пользовательские сессии, и утечки «обычных» данных пользователей, вроде персональных или email-адреса. Другим исследователям, по их словам, удавалось получить секретные ключи серверов — то есть злоумышленники могут в такой ситуации подсунуть поддельные версии пострадавших сайтов. Правда, необходимое для получения ключа количество запросов измеряется уже миллионами, но для автоматических скриптов это немного. Вот тут можно найти подробное объяснение, в какой ситуации уязвимыми могут оказаться именно секретные ключи.

Один из самых неприятных моментов во вскрывшейся ситуации — то, что атаку очень тяжело обнаружить. Для этого требуется постоянно хранить значительное количество TLS-трафика, только тогда в нем можно искать характерные запросы, которые могут свидетельствовать об атаке (впрочем, могут и не свидетельствовать). По всем прочим параметрам эта уязвимость — рай для атакующего: она не оставляет следов от успешного получения данных. Из-за этого, кстати, трудно сказать, насколько долго Heartbleed использовалась до того, как аналитики из Google рассказали о ней OpenSSL Team.

Уязвимости оказались подвержены многие крупные сервисы - Yahoo Mail, Facebook, а также некоторые банки. По оценкам экспертов, так или иначе она присутствовала на двух третях сайтов, доступных по протоколу https. Вот тут можно посмотреть, с какой скоростью исправления вносятся в уязвимые системы.

Хорошей новостью в этой ситуации остается разве только то, что исправления примерно в половину уязвимых сайтов были внесены за неделю — разработчики операционных систем выпустили обновленную версию библиотеки OpenSSL. Правда, после применения обновлений надо было не забыть перезапустить все сервисы, использующие OpenSSL, иначе в памяти компьютера оставалась старая версия библиотеки, и сервис продолжал быть уязвимым.

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

Для идеальной ликвидации последствий на сервере (в случае, если уязвимость на нем была) нужно обновить OpenSSL, перезапустить все использующие его сервисы, после чего перегенерировать секретный ключ (а не перевыпускать, как многие делают, заявку на основании ключа, уже существующего), и переустановить ключ и сертификат. Обязательно нужно отозвать старый сертификат — иначе злоумышленники смогут по-прежнему убедительно изображать сайт жертвы. По сообщениям аналитического ресурса Netcraft, многие (хотя и не все)удостоверяющие центры в этой ситуации бесплатно отзывают и перевыпускают сертификаты. Ошибиться очень легко: тот же Netcraft сообщает, впрочем, что многие сайты сменили и отозвали сертификат, но не перегенерировали секретный ключ, а это практически бесполезно: проблема состоит именно в возможной утечке секретного ключа. В сети есть несколько исчерпывающих инструкций, вот одна из них.

После смены сертификата владельцу сайта нужно оповестить пользователей о том, что проблема устранена, и предложить поменять пароли. Сохраненные сессии на стороне сервера тоже лучше сбросить, эти данные могут быть скомпрометированы. Поменять пароли стоит всем пользователям. Конечно, на стороне обычных пользователей —закон больших чисел, а местами и принцип “неуловимого Джо”, но полагаться на них безоговорочно не стоит. И, конечно, менять пароли простым пользователям стоит только после того, как сервис устранит уязвимость. Двухфакторная авторизация (с подтверждением логина по телефону или контрольному вопросу) в сложившейся ситуации сильно уменьшает вероятность неавторизованных действий.

Но веб-сервисами дело не ограничивается. OpenSSL может оказаться без ведома пользователей в практически любом средстве защиты канала, и особенно неприятно, когда уязвимость вдруг оказывается в прошивке, скажем, роутера. BlackBerry уже признала наличие уязвимости в своей продукции (впрочем, это не относится к смартфонам), аналогично поступила компания Cisco, и исследования продукции еще не завершены — когда я заходил по этой ссылке, документ с описанием уязвимости и перечнем продукции обновился до версии 1.5. Аналогичные обновления уже выпустила компания Oracle, и вряд ли кто-нибудь сейчас составит исчерпывающий список пострадавших компаний, не говоря уже о продуктах.

Разумеется, тут же появились обсуждения того, как давно уязвимость известна криптографам из спецслужб. АНБ США, впрочем, уже открестилось от знания этой уязвимости. Зато есть информация о том, что следы использования Heartbleed относятся к ноябрю прошлого года. В частности, из данного сообщения можно сделать вывод, что Heartbleed использовалась операторами ботнетов.

Если же отвлечься непосредственно от уязвимости в OpenSSL и посмотреть на ее практическое применение (утекающие пользовательские пароли, cookies, идентифицирующие сессии и так далее), то станет ясно, что текущие механизмы обмена паролями и поддержания сессий по протоколу HTTP нуждаются в усовершенствовании, чтобы, например, пароль не ходил в незащищенном (точнее, зашифрованном средствами TLS) виде. Одно из таких предложений уже внесено в IETF “по горячим следам” известным специалистом по информационной безопасности Филипом Халлам-Бейкером, и возможно, будет встречено с пониманием. Но быстрого распространения даже полезных нововведений такого рода ждать не приходится. Если значительная часть браузеров обновляется автоматически, и новая функциональность в них появляется регулярно, то, например, многие распространенные дистрибутивы Linux при автоматическом обновлении лишь закрывают дыры в безопасности и обновляют информационные базы (например, сведения о переходе на летнее и зимнее время). Новая функциональность становится доступной в них только при выпуске нового релиза операционной системы. Желающих же собственноручно внедрять новую функциональность обычно немного.

Из широко распространенных библиотек с открытым кодом, реализующих протокол TLS, в этом году не случилось атак только на одну — NSS, используемую по умолчанию в браузерах Mozilla Firefox, Google Chrome и некоторых других. Но вряд ли она является исключением и настолько хорошо написана, что не содержит опасных уязвимостей.

Скорее всего, решение проблемы, оцененной Брюсом Шнайером в “11 баллов по 10-балльной шкале”, стоит искать в организационной плоскости. При исключительной важности OpenSSL для всего интернета и огромной ответственности, лежащей на немногочисленных участниках OpenSSL Team, финансирование по контрактам и от пожертвований составило в 2013 году меньше миллиона долларов. Уже появились призывы провести аудит кода OpenSSL на предмет уязвимостей, а собранные пожертвования превысили за несколько дней сборы прошлого года (впрочем, это все равно достаточно скромные суммы, тут речь идет о нескольких тысячах долларов). Кроме того, резко увеличилось количество сообщений о потенциально опасных местах в коде OpenSSL. Образован консорциум с участием Microsoft, Google и других крупных игроков индустрии, его задача – обеспечить финансирование критически важных проектов, чтобы их разработчики могли сосредоточиться на программировании, а не решать параллельно организационные задачи.

Еще одно направление, которое может оказаться успешным, а может остаться маргинальным – проект LibreSSL. Этот проект воплощает один из часто встречающихся в мире Open Source подходов: взять исходную базу кода и начать развивать его независимой командой. Разработчики начали с того, что выкинули из проекта функциональность, которую они считают устаревшей (SSL v2), редкой или маргинальной (Kerberos), поддержку аппаратных решений. К сожалению, по этой же категории у этой команды разработчиков проходит и поддержка алгоритмов российской криптографии ГОСТ.

Эксперты давно говорят о том, что программное обеспечение с открытым кодом, который может быть прочитан любым программистом, читается далеко не любым, а понимается еще меньшим количеством. Когда речь идет о мегабайтах исходного кода, реализующего практическую задачу, а не о нескольких страницах спецификации, поддержка такого ПО в идеальном качестве весьма затруднена. Автоматические же средства предупреждения о потенциальных проблемах несовершенны и способны ловить опечатки, но не существенные провалы в логике. И мысль о том, что самые стойкие с математической точки зрения алгоритмы не помогают в случае банальных ошибок в реализации, еще раз нашла свое подтверждение в истории с Heartbleed.


Автор:  Дмитрий Белявский (ТЦИ)

Возврат к списку