Как мне восстановиться после ошибки Heartbleed в OpenSSL?

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

Я уязвим?

Глючная версия OpenSSL

Программное обеспечение с ошибками - библиотека OpenSSL 1.0.1 до 1.0.1f и OpenSSL 1.0.2 до бета1. Более старые версии (0.9.x, 1.0.0) и версии, в которых исправлена ошибка (1.0.1g и более поздние, 1.0.2 beta 2 и более поздние), не затрагиваются. Это ошибка реализации, а не недостаток протокола, поэтому затрагиваются только программы, использующие библиотеку OpenSSL.

Вы можете использовать инструмент командной строки openssl version -aдля отображения номера версии OpenSSL. Обратите внимание, что некоторые дистрибутивы переносят исправление ошибки на более ранние версии; если в журнале изменений вашего пакета упоминается исправление ошибки Heartbleed, это нормально, даже если вы видите версию, подобную 1.0.1f. Если openssl version -aупоминается дата сборки (а не дата в первой строке) 2014-04-07 около вечера UTC или позже, с вами все будет в порядке. Обратите внимание, что пакет OpenSSL может иметь 1.0.0свое имя, даже если версия 1.0.1 ( 1.0.0относится к двоичной совместимости).

Затронутые приложения

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

Вы можете проверить, какие программы связаны с библиотекой в вашей системе. В системах, использующих dpkg и apt (Debian, Ubuntu, Mint,…), следующая команда выводит список установленных пакетов, отличных от используемых библиотек libssl1.0.0(уязвимый пакет):

apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii  lib'

Если вы запускаете какое-либо серверное программное обеспечение, которое находится в этом списке, и прослушивает SSL-соединения, вы, вероятно, затронуты. Это касается веб-серверов, серверов электронной почты, серверов VPN и т. Д. Вы будете знать, что вы включили SSL, потому что вам нужно было сгенерировать сертификат, либо отправив запрос на подпись сертификата в центр сертификации, либо сделав собственную самозаверяющую подпись. сертификат. (Возможно, что некоторые процедуры установки сгенерировали самозаверяющий сертификат без вашего ведома, но обычно это делается только для внутренних серверов, а не для серверов, подключенных к Интернету.) Если вы запускали уязвимый сервер, подключенный к Интернету, считайте его скомпрометированным если в ваших логах нет связи с момента объявления 2014-04-07. (Это предполагает, что уязвимость не использовалась до ее объявления.) Если ваш сервер был открыт только для внутренних целей,

Клиентское программное обеспечение затрагивается, только если вы использовали его для подключения к вредоносному серверу. Поэтому, если вы подключились к провайдеру электронной почты с помощью IMAPS, вам не нужно беспокоиться (если только провайдер не подвергся нападению - но если это так, они должны сообщить вам), но если вы просматривали случайные веб-сайты с уязвимым браузером, вам может понадобиться беспокоиться. Пока что кажется, что уязвимость не эксплуатировалась до ее обнаружения, поэтому вам нужно беспокоиться, только если вы подключились к вредоносным серверам с 2014-04-08.

Следующие программы не затрагиваются, потому что они не используют OpenSSL для реализации SSL:

SSH (протокол не SSL)
Хром / Хром ( использует NSS )
Firefox (использует NSS) (по крайней мере, с Firefox 27 на Ubuntu 12.04, но не со всеми сборками?

Какое влияние?

Эта ошибка позволяет любому клиенту, который может подключиться к вашему SSL-серверу, одновременно получать с сервера около 64 КБ памяти. Клиент не должен проходить проверку подлинности. Повторяя атаку, клиент может сбрасывать различные части памяти при последовательных попытках. Это потенциально позволяет злоумышленнику извлечь любые данные, которые были в памяти серверного процесса, включая ключи, пароли, файлы cookie и т. Д.

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

Эта ошибка также позволяет любому серверу, к которому подключен ваш SSL-клиент, одновременно получать от клиента около 64 КБ памяти. Это беспокоит, если вы использовали уязвимый клиент для манипулирования конфиденциальными данными, а затем подключились к ненадежному серверу с тем же клиентом. Таким образом, сценарии атаки на этой стороне значительно менее вероятны, чем на стороне сервера.

Обратите внимание, что в типичных дистрибутивах нет влияния на безопасность при распространении пакетов, поскольку целостность пакетов зависит от сигнатур GPG, а не от транспорта SSL.

Как мне исправить уязвимость?

Восстановление открытых серверов

Переведите все затронутые серверы в автономный режим. Пока они работают, они потенциально могут передавать важные данные.
Обновите пакет библиотеки OpenSSL . Все дистрибутивы должны быть исправлены (либо с 1.0.1g, либо с патчем, который исправляет ошибку без изменения номера версии). Если вы скомпилировали из исходного кода, обновитесь до 1.0.1g или выше. Убедитесь, что все затронутые серверы перезапущены.
В Linux вы можете проверить, работают ли потенциально затронутые процессы сgrep 'libssl.*(deleted)' /proc/*/maps
Генерация новых ключей . Это необходимо, потому что ошибка могла позволить злоумышленнику получить старый закрытый ключ. Следуйте той же процедуре, которую вы использовали изначально.
- Если вы используете сертификаты, подписанные центром сертификации, отправьте новые открытые ключи в свой ЦС. Когда вы получите новый сертификат, установите его на своем сервере.
- Если вы используете самозаверяющие сертификаты, установите их на свой сервер.
- В любом случае, удалите старые ключи и сертификаты (но не удаляйте их, просто убедитесь, что они больше не используются).
Теперь, когда у вас есть новые бескомпромиссные ключи, вы можете снова подключить свой сервер .
Отмените старые сертификаты.
Оценка ущерба : любые данные, которые были в памяти процесса, обслуживающего SSL-соединения, потенциально могли быть утечки. Это может включать пароли пользователей и другие конфиденциальные данные. Вам необходимо оценить, какими могли быть эти данные.
- Если вы используете службу, которая разрешает аутентификацию по паролю, то пароли пользователей, которые подключились еще до того, как была объявлена уязвимость, должны считаться взломанными. Проверьте свои журналы и измените пароли любого затронутого пользователя.
- Также аннулируйте все сеансовые куки, поскольку они могут быть скомпрометированы.
- Сертификаты клиента не скомпрометированы.
- Любые данные, которые были обменены за некоторое время до появления уязвимости, могли остаться в памяти сервера и, следовательно, могли быть переданы злоумышленнику.
- Если кто-то записал старое SSL-соединение и получил ключи вашего сервера, теперь он может расшифровать свою расшифровку. (Если PFS не был обеспечен - если вы не знаете, это не так.)

Исправление в других случаях

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

С клиентами есть только редкие сценарии, где ошибка могла быть использована: эксплойт потребовал бы, чтобы вы использовали один и тот же клиентский процесс для

манипулировать конфиденциальными данными (например, паролями, клиентскими сертификатами и т. д.);
а затем, в том же процессе, подключается к вредоносному серверу по протоколу SSL.

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

Если вы сделали это в период между 2014-04-07 вечером по Гринвичу и обновлением библиотеки OpenSSL, сочтите все данные, которые были в памяти клиента, скомпрометированы.