Heartbleed

Heartbleed — это критическая уязвимость в криптографической библиотеке OpenSSL, обнаруженная в апреле 2014 года. Она позволяла злоумышленнику, не оставляя следов, читать защищённую память сервера или клиента, получая доступ к секретным ключам шифрования, паролям, сессионным токенам и другим конфиденциальным данным. Уязвимость получила кодовое название Heartbleed (от англ. heart — «сердце» и bleed — «кровотечение») из-за своей природы: она эксплуатировала ошибку в реализации расширения TLS Heartbeat (RFC 6520), которое предназначено для поддержания соединения.

История и обнаружение

Уязвимость была внесена в код OpenSSL в декабре 2011 года (в версии 1.0.1) и оставалась незамеченной более двух лет. Она была независимо обнаружена и задокументирована двумя группами исследователей: сотрудниками финской компании Codenomicon (Някки Лахти, Матти Камюнен и др.) и инженером Google Security Нилом Мехта (Neel Mehta).

7 апреля 2014 года Codenomicon публично раскрыла информацию об уязвимости, одновременно выпустив исправленную версию OpenSSL 1.0.1g. В тот же день компания CloudFlare провела демонстрацию эксплуатации уязвимости на своём сайте, показав, как можно украсть закрытый ключ сервера. Новость мгновенно распространилась по всему миру, вызвав панику в интернет-сообществе, так как OpenSSL использовалась на подавляющем большинстве веб-серверов (около 66% по данным опросов того времени).

Технические детали

Принцип работы расширения Heartbeat

Протокол TLS (Transport Layer Security) использует расширение Heartbeat для поддержания активного соединения между клиентом и сервером. Оно работает следующим образом:

1. Запрос (HeartbeatRequest): Одна сторона (например, клиент) отправляет другой стороне (серверу) сообщение, содержащее произвольные данные (полезную нагрузку) и указание их длины.
2. Ответ (HeartbeatResponse): Получившая сторона должна вернуть ровно те же данные обратно, подтверждая, что соединение живо.

Ошибка в реализации

Уязвимость заключалась в том, что реализация Heartbeat в OpenSSL не проверяла, соответствует ли фактическая длина отправляемых данных заявленной в сообщении. Если злоумышленник отправлял запрос, где в поле длины указывал значение, большее, чем реальный размер данных, сервер, доверяя этому полю, копировал в ответный пакет не только полезную нагрузку, но и произвольный фрагмент из своей оперативной памяти, следующий за ней.

Схема эксплуатации

1. Злоумышленник формирует HeartbeatRequest, содержащий, например, 1 байт данных, но в поле длины указывает 65535 байт.
2. Сервер, следуя протоколу, выделяет буфер размером 65535 байт для ответа.
3. Сервер копирует в этот буфер 1 байт полезной нагрузки, а затем заполняет оставшиеся 65534 байта содержимым своей оперативной памяти, которая находилась рядом с этим 1 байтом.
4. Сервер отправляет этот 65535-байтовый пакет обратно злоумышленнику.
5. Злоумышленник получает фрагмент памяти сервера, который может содержать секретные ключи, пароли, содержимое запросов других пользователей и т.д.

Атака могла повторяться многократно, позволяя постепенно «вычитать» всю память процесса OpenSSL.

Что можно было украсть

• Закрытые ключи сервера (Private Keys): Самый опасный сценарий. Зная закрытый ключ, злоумышленник мог расшифровать любой ранее перехваченный трафик, а также выдавать себя за легитимный сервер.
• Пароли и учётные данные: Пользовательские логины и пароли, передаваемые в открытом виде (например, при аутентификации на форумах или в приложениях, не использующих дополнительные меры защиты).
• Сессионные токены (Session IDs, Cookies): Позволяли перехватить сессию пользователя и получить доступ к его аккаунту без ввода пароля.
• Содержимое запросов: Данные, которые другие пользователи отправляли на сервер в момент атаки (например, содержимое форм, личные сообщения).
• Конфиденциальная информация: Любые другие данные, временно хранящиеся в памяти процесса OpenSSL (номера кредитных карт, медицинские записи, внутренняя переписка).

Масштаб и последствия

Heartbleed стала одной из самых масштабных и резонансных уязвимостей в истории интернета.

Поражённые системы

Уязвимость затрагивала версии OpenSSL с 1.0.1 по 1.0.1f. Она была исправлена в версии 1.0.1g. По оценкам экспертов, на момент обнаружения уязвимости ей были подвержены около 500 000 веб-сайтов, включая крупнейшие интернет-сервисы:

• Социальные сети: Facebook (организация признана экстремистской и запрещена в РФ), Twitter, Instagram (организация признана экстремистской и запрещена в РФ), LinkedIn, Pinterest.
• Поисковые системы и почта: Yahoo!, Google (Gmail, YouTube), Microsoft (Outlook.com), Яндекс.
• Сервисы облачных вычислений: Amazon Web Services, Dropbox, CloudFlare (частично).
• Правительственные и финансовые сайты: Сайты многих государственных учреждений США, Великобритании, Канады и других стран, а также банковские порталы.
• Операционные системы: Уязвимости были подвержены дистрибутивы Linux (Debian, Ubuntu, Red Hat, CentOS), FreeBSD, а также некоторые версии OpenBSD.
• Сетевое оборудование: Маршрутизаторы, коммутаторы и VPN-устройства от Cisco, Juniper и других производителей, использующие OpenSSL.

Реакция сообщества

• Экстренное исправление: Разработчики OpenSSL в течение нескольких дней выпустили исправление. Ведущие интернет-компании (Google, Facebook (организация признана экстремистской и запрещена в РФ), Yahoo!) в течение нескольких часов или дней обновили свои серверы.
• Массовая смена паролей: Пользователям по всему миру настоятельно рекомендовали сменить пароли на всех сайтах, которые могли быть уязвимы. Многие крупные сервисы (например, Apple, Google) ввели принудительную смену паролей для своих пользователей.
• Отзыв и перевыпуск сертификатов: Компании, чьи закрытые ключи могли быть скомпрометированы, были вынуждены отзывать старые SSL/TLS-сертификаты и получать новые от центров сертификации.
• Создание Core Infrastructure Initiative: После Heartbleed была создана инициатива Core Infrastructure Initiative (CII) под эгидой Linux Foundation для финансирования и поддержки критически важных проектов с открытым исходным кодом, таких как OpenSSL.

Юридические и финансовые последствия

Уязвимость привела к нескольким судебным искам. Например, в Канаде был подан коллективный иск против компании Yahoo! за то, что она не смогла защитить данные пользователей. Финансовые потери от утечки данных, смены сертификатов и простоев были оценены в миллиарды долларов.

Критика и уроки

Heartbleed стала ярким примером проблем управления проектами с открытым исходным кодом.

• Недостаток финансирования: Проект OpenSSL на момент обнаружения уязвимости имел крайне ограниченное финансирование и, по сути, поддерживался горсткой добровольцев. Это привело к нехватке времени для аудита кода и тестирования.
• Сложность кода: Кодовая база OpenSSL была огромной, плохо документированной и содержала множество устаревших и неиспользуемых функций, что затрудняло поиск ошибок.
• Отсутствие автоматизированного тестирования: В проекте не было достаточного покрытия кода автоматическими тестами, которые могли бы выявить несоответствие между заявленной и фактической длиной данных.

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

Источники

• Codenomicon. «Heartbleed Bug». Официальный сайт уязвимости (heartbleed.com).
• OpenSSL Security Advisory [07 Apr 2014]. «TLS heartbeat read overrun (CVE-2014-0160)».
• Bruce Schneier. «Heartbleed». Блог Schneier on Security, 9 апреля 2014.
• Robert Graham. «How Heartbleed works». Блог Errata Security, 9 апреля 2014.
• CloudFlare. «The Heartbleed Bug and CloudFlare». Блог CloudFlare, 8 апреля 2014.
• Linux Foundation. «Core Infrastructure Initiative». Официальный сайт.