Обнаружена критическая уязвимость OpenSSL «Heartbleed»

Обнаружена уязвимость в популярном программном средстве шифрования OpenSSL, которое уже окрестили как Heartbleed (что в переводе звучит как «кровоточащее сердце» или «сердце кровью обливается»). Heartbleed-ошибка была введена в OpenSSL версии 1.0.1 в 2012 году и присутствует в следующих версиях OpenSSL: 1.0.1, 1.0.1a, 1.0.1b, 1.0.1c, 1.0.1d, 1.0.1e, 1.0.1f.

blog_heartbleedДанная уязвимость позволяет считывать содержимое памяти в системах, защищённых версией OpenSSL. По сути это означает, что все механизмы защиты соединений, полагающиеся на данную реализацию протоколов шифрования, попросту не работают. Речь идёт не о том, что шифрования никакого нет. Просто любой, кто знал об уязвимости (все уже догадались, кто уж точно мог знать об этом), присутствующей в OpenSSL, начиная с версии 1.0.1, выпущенной в 2012 году, мог всё это время прослушивать любые шифрованные соединения, эксплуатируя брешь (Большой брат наблюдает за тобой).

Заинтересованные стороны встретили новость с нарастающей паникой. На самом ли деле всё так плохо? Короткий ответ: да, потенциально.

Прежде всего, ситуация на самом деле скверная. Как написали многие мировые СМИ, например, BBC News, «Ошибка в программном обеспечении, которое используют миллионы веб-серверов, могла привести к тому, что все, кто посещал размещённые на этих серверах сайты, мог потенциально подвергаться прослушке».

Фактически, мы с вами наблюдаем, вероятно, одну из самых значительных брешей в защите информации за всю историю. И одну из самых «долгоиграющих». На данный момент никто не может сказать, насколько активно она эксплуатировалась, но очевидно, что дыра была открыта в течение двух лет: уязвимая OpenSSL 1.0.1 была выпущена в марте 2012 года.

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

Справка:

OpenSSL — это открытая реализация протоколов шифрования TSL (Transport Layer Security) и его предшественника SSL (Secure Socket Layer). Оба эти протокола используют сертификаты безопасности X.509 и, соответственно, ассиметричную криптографию, также известную под названием «криптография с открытым ключом». Такой алгоритм предполагает наличие двух раздельных ключей — фрагментов информации или параметров, которые определяют, какие функциональные результаты выдаёт криптографический алгоритм или шифр. Один из этих ключей является тайным, другой — публичным.

Ключ, используемый для шифрования сообщения, отличается от того, который используется для расшифровки. У каждого пользователя имеется своя пара криптографических ключей — публичный и секретный. Открытый (публичный) ключ можно распространять, в то время как закрытый знает только тот, кому он принадлежит. Ключи находятся в математической взаимосвязи, однако их параметры подобраны таким образом, чтобы вычислить открытый ключ по закрытому можно было без особых усилий, в то время как обратный процесс невозможен. То есть, как минимум, неоправданно сложен — требуются такие вычислительные мощности, что расшифровка теряет смысл.

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

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

Обычным решением этой проблемы является т.н. инфраструктура открытых ключей, в рамках которой доверенные организации — центры сертификации (Certificate Authority, CA) — удостоверяют принадлежность пар ключей их владельцам. Иными словами, центр сертификации берёт на себя ответственность говорить: «да, этот человек на самом деле является именно тем, кем он, по его словам, является, и мы это удостоверяем».

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

В условиях возможной эксплуатации уязвимости Heartbleed все эти предосторожности, увы, не имеют никакого смысла. Ошибка, приведшая к отсутствию необходимой проверки границ в одной из процедур расширения Heartbeat для протокола TLS/DTLS, позволяет в теории прочитать произвольные 64 КБ памяти компьютеров и серверов.

Таким образом, «Heartbleed» позволяет всем пользователям Сети прочитывать память систем, защищённых уязвимой версией OpenSSL. Это делает бесполезными секретные ключи, используемые для идентификации сервис-провайдеров и для шифрования трафика, а также позволяет получить доступ к именам и паролям пользователей и контенту, которым они обмениваются в данный момент. Злоумышленники могут прослушивать соединения и напрямую красть данные с сервисов и у пользователей, а также выдавать себя за кого-то другого.

Оценка угрозы

На момент раскрытия информации, 7 апреля 2014 года, около 17 % из 500 тыс. считавшихся безопасными веб-серверов, сертифицированных удостоверяющими центрами, были уязвимы к атаке «Heartbleed». В то же время веб-серверы под управлением Apache и nginx также гипотетически подвержены уязвимости, а их совокупная доля на рынке составляет порядка 66 %.

Что следует сделать бизнесу (и срочно!)

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

  1. Необходимо обновить OpenSSL до версии 1.0.1g (выпущена 07.04.2014) везде, где используется этот пакет — на серверах, в операционных системах. Затем сменить все пароли, особенно те, которые используются для доступа к важным данным.
  2. Если вы владелец веб-сервиса, который использует уязвимую версию OpenSSL, есть смысл отключиться от Сети. Именно это сделал, разработчик популярной игры Minecraft, компания Mojang. Для хостинга игры используются ресурсы Amazon, и Mojang отключил все свои сервисы пока хостер лечил свои системы от уязвимости. Такие поступки, столь крупных сервис-провайдеров не дают усомниться в серьёзности угроз и сводят на нет любые мысли о искусственном нагнетании обстановки. Естественно, это повлекло недовольство пользователей. Однако, в случае успешной атаки, ваше недовольство будет куда большим.
  3. К сожалению, компаниям, работающим с личными данными других людей, нужно сообщить своим клиентам о возможной утечке данных и необходимости срочно сменить пароли. Все крупные СМИ уже опубликовали информацию об этом баге, многие уже в курсе, но проблему требуется освещать как можно шире.

В свете вышесказанного, всем пользователям 2X ApplicationServer XG в кратчайшие сроки надлежит обновить версии всех компонентов, как серверной части, так и клиентской. Не допускать подключения пользователей с использованием уязвимых версий клиентов.

Безопасная версия OpenSSL 1.0.1g была оперативно внедрена в обновления всех компонентов 2X ApplicationServer XG 11 апреля 2014 года. Безопасными версиями компонентов являются:

  • 2X ApplicationServer XG 11.0.0 (1933) и выше
  • 2X ApplicationServer XG 10.6 (1558) (последняя в линейке продукта версии 10.6)
  • Windows Client 11.0 (1933) и выше
  • iOS Client 11.0 (1936) и выше
  • Android Client 11.0 (1937) и выше
  • Windows Phone Client 11.0 (1939) и выше
  • Linux Client 11.0 (1941) и выше
  • MacOS 11.0 (1897) и выше
Источники: