7 апреля стало известно об уязвимости в OpenSSL, которую назвали Heartbleed (CVE-2014-0160). Проблема не в вашем коде и не в настройках сервера – баг сидит в самой библиотеке, на которой держится TLS у большей части интернета. Ошибка в расширении Heartbeat позволяет удалённо вычитывать до 64 КБ оперативной памяти сервера за один запрос. И так – сколько угодно раз, без следов в логах. В этой памяти может оказаться что угодно: приватные ключи сертификатов, пароли пользователей, сессионные токены, тела запросов.

Под удар попали версии OpenSSL 1.0.1–1.0.1f. Ветки 0.9.8 и 1.0.0 уязвимости не подвержены. Поскольку 1.0.1 вышла два года назад, заражена огромная доля Linux-серверов, балансировщиков, VPN-шлюзов и встроенных устройств. Для систем, обрабатывающих персональные данные или подключённых к государственным сервисам, это прямой инцидент безопасности, а не повод подождать.

Как проверить, что вы уязвимы

Сначала определите версию на каждом узле, который терминирует TLS:

openssl version -a

Если это 1.0.1–1.0.1f и библиотека собрана с поддержкой Heartbeat – узел под угрозой. Проверьте не только веб-серверы. Уязвимы почтовые серверы (SMTP/IMAP с STARTTLS), OpenVPN, базы данных с TLS, прокси и любые внутренние сервисы, которые вы считали закрытыми периметром. Внутренний сервис тоже доступен злоумышленнику, который уже получил доступ в сеть.

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

Порядок действий

  1. Обновите OpenSSL до 1.0.1g. Патч уже в репозиториях Debian, Ubuntu, RHEL и CentOS. Если обновиться сразу нельзя, пересоберите библиотеку с флагом -DOPENSSL_NO_HEARTBEATS.
  2. Перевыпустите все сертификаты. Исходите из того, что приватные ключи скомпрометированы. Сгенерируйте новые ключевые пары, получите новые сертификаты и отзовите старые. Перевыпуск без замены ключа смысла не имеет.
  3. Сбросьте секреты. Принудительно завершите пользовательские сессии, ротируйте пароли сервисных учёток, API-токены и ключи доступа, которые могли оказаться в памяти.
  4. Уведомите пользователей. Для систем с персональными данными попросите сменить пароли после того, как закрыли дыру, – раньше делать это бессмысленно.

Особое внимание – контурам, интегрированным с государственными сервисами. Если ваша система обменивается данными через защищённые каналы, проверьте всю цепочку шлюзов. Требования к транспортной безопасности мы уже разбирали в материале о подключении к СМЭВ, и Heartbleed бьёт ровно по этому уровню. То же касается систем юридически значимого ЭДО: если ключ электронной подписи или TLS-сертификата мог утечь, под вопросом доверие ко всему документообороту.

Урок про цепочку зависимостей

Heartbleed – напоминание о том, что вы наследуете уязвимости всех библиотек, которые тянете в продакшн. Это особенно остро для контейнеров и образов: один базовый слой с дырявой версией расходится по сотням сервисов. Мы писали об изоляции в заметке про libcontainer и Docker – изоляция помогает локализовать ущерб, но не отменяет необходимости вовремя пересобирать образы и инвентаризировать зависимости.

Если вы не уверены, что закрыли все узлы, то реагирование на подобные инциденты стоит вынести в постоянный аудит и сопровождение безопасности – от инвентаризации криптографии до регламентов ротации ключей.

Закрыть Heartbleed технически просто. Сложнее – гарантировать, что вы нашли все места, где живёт уязвимая библиотека. Начните инвентаризацию сегодня.