Массивная. Огромный. Катастрофические. Все эти заголовки, которые я видел сегодня, в основном говорят о том, что мы теперь хорошо и по-настоящему облажались, когда речь заходит о безопасности в Интернете. В частности, это так :
Ошибка Heartbleed позволяет любому пользователю Интернета читать память систем, защищенных уязвимыми версиями программного обеспечения OpenSSL.
Время от времени в мире безопасности происходит что-то довольно серьезное и широкомасштабное, и мы все бегаем, как безголовый цыпленок, гадая, что это означает на земле. В конце концов, АНБ «поймало нас»? SSL мертв? Небо падает? Ну, это плохо , но не для всех и, возможно, не так плохо, как говорят многие. Большая часть ранних новостей пришла через heartbleed.com (сайт, созданный Codenomicon ), который, если можно так выразиться, проделал отличную работу, подняв очень симпатичный маленький веб-сайт и запечатлеть ошибку:
Но на самом деле все гораздо сложнее, чем предполагает блестящий логотип. Это не помогает , что это не простая концепция , чтобы понять и что только соединения путаница и спекуляции о том , что ошибка на самом деле, то, что ошибка не и , возможно , самое главное, что вам нужно сделать. Я попытаюсь разделить эту проблему на ряд общих вопросов, которые задают люди, — если хотите, в двух словах.
Что такое OpenSSL и на какие версии это влияет?
Давайте начнем здесь: ошибка Heartbleed присутствует только в реализации OpenSSL SSL и TLS (обратите внимание, что, хотя не всегда одно и то же, эти аббревиатуры, как правило, используются взаимозаменяемо и обычно ссылаются на их реализацию через HTTP или, другими словами, HTTPS ). Как следует из названия, это программный продукт с открытым исходным кодом, который облегчает связь по протоколу SSL, и это очень распространено. На момент раскрытия информации около 17% «безопасных» веб-сайтов в мире были признаны уязвимыми для этой ошибки .
Как правило, реализации OpenSSL присутствуют на серверах под управлением Apache и nginx. К сожалению, сегодня Apache остается доминирующим веб-сервером, на котором работает более половины активных сайтов в Интернете, а nginx — около 14%:
Сама ошибка Heartbleed была введена в декабре 2011 года, на самом деле она, по-видимому, была совершена примерно за час до канун Нового года (прочитайте, что хотите). Ошибка затрагивает версию 1.0.1 OpenSSL, которая была выпущена в марте 2012 года, до версии 1.0.1f, которая появилась 6 января этого года. К сожалению, в этом времени вы уязвимы, только если делаете «правильные вещи» и постоянно обновляете свои версии! Опять же, для тех, кто считает, что вам нужно немного подождать новых выпусков, чтобы исправить ошибки перед их принятием, действительно ли они ожидали, что это займет более двух лет? Возможно нет.
Это касается только сайтов на Apache и nginx?
Не все веб-серверы зависят от OpenSSL. IIS, например, использует реализацию Microsoft SChannel, которая не подвержена риску этой ошибки. Означает ли это, что сайты в IIS не уязвимы для Heartbleed? По большей части, да, но не слишком дерзкий, потому что OpenSSL все еще может присутствовать в ферме серверов. Пример: Тим Пост из Stack Overflow написал сегодня об этом в Твиттере:
Но разве они не используют все ASP.NET MVC на IIS? Да, они уверены, что это очень ясно показано в отличном посте Ника Крейвера в прошлом году о переходе на SSL , на самом деле вы можете видеть веб-серверы (IIS), расположенные справа на этом изображении:
Подожди — это там тоже nginx ??? Ага, про это
Трафик HTTPS поступает в nginx на машинах балансировки нагрузки и там заканчивается.
Вы видите проблему? Да, они могут использовать IIS, но нет, это не значит, что OpenSSL не присутствует в их архитектуре фермы серверов, и на самом деле он стоит перед всем остальным, заканчивая SSL. Та же проблема существует, если машина, действующая в качестве обратного прокси-сервера, находится перед IIS и работает под управлением Apache или nginx.
Редактировать: Ник и Бен из Переполнения стека пояснили , что теперь они используют HAProxy для завершения SSL, которое использует … OpenSSL.
Вот еще один, на самом деле я получил это вчера вечером от AppHarbor относительно хостинга ASP.NET, который у меня был с ними:
Дело в том, что часто серверная инфраструктура — это гораздо больше, чем просто веб-сервер, и она не работает сознательно на Apache или nginx, но это не значит, что она не работает в вашей среде.
Кто нашел это и зачем обнародовать?
Первое общедоступное свидетельство ошибки появилось в виде рекомендаций OpenSSL 7 апреля и предупреждает о «проверке пропущенных границ при обработке расширения пульса TLS». Нил Мехта (Neel Mehta) из Google Security обнаружил и сообщил об ошибке и просто указал затронутые версии и рекомендует обновить OpenSSL или, если это невозможно, перекомпилировать его и отключить тактовые импульсы.
Что касается того, почему это было обнародовано, это давние дебаты о том, ускоряет ли публичное раскрытие информацию исправление или открывает уязвимые системы для атаки. Вероятно, и то и другое, проблема с таким риском, а не с единственной дискретной уязвимостью на веб-сайте, состоит в том, что для ее исправления необходимо массовое внедрение пересмотренной версии, и до тех пор, пока риск не станет социализированным, этого не произойдет. , Затем возникает проблема, когда требуется только одна сторона со злонамеренным намерением начать разгул сайтов, которые совершенно не знают о риске, и у вас действительно серьезная проблема.
Независимо от этого, вы не можете спорить с тем, как он сейчас фокусируется, или со скоростью, с которой многие сейчас исправляют уязвимые сайты. Конечно, будут другие, которые отстают, и они будут подвергаться серьезному риску, давайте посмотрим, что это может для них значить.
Что такое сердцебиение SSL?
Давайте сначала разберемся с особенностью, в которую попала эта ошибка. Ошибка, о которой мы здесь говорим, существует в реализации OpenSSL расширения heartbeat, функция, описанная IETF следующим образом :
Расширение Heartbeat обеспечивает новый протокол для TLS / DTLS, позволяющий использовать функциональные возможности поддержания активности без выполнения повторного согласования, и основу для обнаружения MTU пути (PMTU) для DTLS.
Другими словами, это сердцебиение в том же духе, которое мы обычно знаем в других аспектах компьютерных систем, а именно проверка того, присутствует ли другая сторона или нет. Когда они все еще там, сердцебиение поддерживает контекст между сверстниками, и, следовательно, номенклатуру «поддерживать жизнь». В контексте SSL первоначальное согласование между клиентом и сервером связано с накладными расходами на связь, которые помогают избежать повторения импульса, устанавливая, если узел все еще «жив». Без сердцебиения единственным способом сделать это является пересмотр, который в относительном выражении является дорогостоящим.
Как используется риск? И как это было исправлено?
Уже есть множество доказательств концептуального кода, мне особенно нравится пример Рахула Саси в его POC и Mass Scanner для Heartbleed Attack, поскольку он четко объясняет уязвимый код, исправление и то, что он написал для проверки ошибки. Короче говоря, исходный риск в OpenSSL сводится к следующей строке кода:
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
Как объясняет Рахул:
В приведенном выше коде память выделяется из полезной нагрузки + заполнение с помощью управляемого пользователем значения. Для этого конкретного распределения не было никакой проверки длины, и злоумышленник мог заставить сервер Openssl прочитать произвольные области памяти.
Другими словами, злоумышленник может контролировать размер пульса и структурировать его так, чтобы он был больше ожидаемого, запустить его на целевом сервере с помощью TCP через порт 443 и получить ответ, содержащий до 64 КБ данных в распределении памяти за пределами какое сердцебиение должно быть в состоянии получить доступ. Сделайте это снова с другим размером сердцебиения, получите ответ 64 КБ из другого пространства памяти. Вспенить, промыть, повторить. Очень просто.
Вы можете пойти и проверить код и последующее исправление в этом коммите на GitHub, если вы хотите погрузиться в мелочь, но вкратце, полезная нагрузка теперь «привязана проверена» (она не может превышать 16 байт) и весь Теперь сердцебиение проверяется, чтобы убедиться, что оно не превышает максимально допустимую длину. В конечном итоге это сводилось к очень простой ошибке в очень маленьком фрагменте кода, который требовал очень маленького исправления. Теперь его просто нужно установить на полмиллиона уязвимых веб-сайтов.
Каковы риски? Что пойдет не так, если его использовать?
Давайте с техническим описанием любезно предоставлены Википедией :
Проверка пропущенных границ при обработке расширения пульса TLS может использоваться для обнаружения до 64 КБ памяти подключенному клиенту или серверу.
Хорошо, но что это на самом деле означает? Это означает, что злоумышленник может сделать что-то вроде этого:
В случае, если серьезность этого не ясна, здесь утверждается, что Марк мог считывать учетные данные другого пользователя непосредственно из памяти в службе Yahoo, и он делал все это удаленно, просто выдавая пульс SSL. Вау.
Более конкретно, мы смотрим на то, что было зашифрованным HTTPS-запросом к веб-сайту Yahoo (неизбежно POST-запросом к странице входа в систему), и мы видим компонент этого запроса, который все еще находился в памяти, когда Марк использовал эксплойт и вытащил данные. Так что еще может получить доступ злоумышленник через эту ошибку? Учетные данные — это одно, но, конечно, это просто потому, что они занимают пространство памяти, которое неизбежно является лишь одним фрагментом данных. Другим является идентификатор сеанса или токен аутентификации; даже если вы не можете получить учетные данные пользователя с помощью ошибки (она все еще должна быть в памяти в то время), вы все равно можете получить идентификатор, который сохраняет свой сеанс в запросах и, следовательно, позволяет злоумышленнику перехватить этот сеанс и выдавать себя за пользователя.
Другой действительно серьезный фрагмент данных, который можно извлечь, — это закрытый ключ сертификата. Я собираюсь повторить в точности то, что heartbleed.com резюмирует относительно утечек первичного ключевого материала, потому что они резюмируют это так красноречиво:
Это драгоценности короны, сами ключи шифрования. Утечка секретных ключей позволяет злоумышленнику дешифровать любой прошлый и будущий трафик к защищенным службам и выдавать себя за службу по желанию. Любая защита, предоставляемая шифрованием и подписями в сертификатах X.509, может быть обойдена. Восстановление после этой утечки требует исправления уязвимости, отзыва скомпрометированных ключей, а также переиздания и распространения новых ключей. Даже выполнение всего этого по-прежнему оставляет любой трафик, перехваченный злоумышленником в прошлом, все еще уязвимым для расшифровки. Все это должны сделать владельцы сервисов.
Не пропустите серьезность этой части вокруг прошлого перехвата; раскрытие секретного ключа дает возможность расшифровать, какие данные были ранее отправлены по сети, еще до того, как эта уязвимость стала известна. Если кто-то должен был хранить эти pcaps (* кашель * АНБ * кашель *), а затем он смог вытащить ключи, воспользовавшись этой ошибкой, все ваши предыдущие данные принадлежат им.
Это может быть так плохо. В теории — но тогда есть это:
Помнишь Нила? Да, он парень, который нашел ошибку для начала. Он прав, а все остальные не правы? Может быть. Может быть нет:
А как насчет Коденомикон — помните их тоже? Это парни, которые создали сайт heartbleed.com, на который я продолжаю ссылаться, который стал таким каноническим указанием на ошибку.
Независимо от того, являются ли ключи доступными для удаленного доступа или нет, есть еще вся эта адресуемая память, которая ведет к незащищенным учетным данным и идентификаторам сеансов. Кроме того, в HTTPS-связи есть все остальные данные, которые вам действительно не нужны для удаленного и анонимного доступа, вопрос лишь в том, скомпилирует ли ошибка и сами сертификаты, и достаточно ли шепот людей, которые смогли это сделать, чтобы планировать худшее и надеяться на лучшее.
Как определить, уязвим ли сайт?
Самый простой способ проверить это удаленно — перейти на тестовую страницу Heartbleed, созданную Филиппо Валсорда . Уязвимый сайт выглядит так:
Хорошо, так на что мы смотрим? Филиппо любезно открыл код на GitHub, чтобы мы могли заглянуть внутрь. Короче говоря, он просто вводит строку «ЖЕЛТАЯ ПОДВОДНАЯ ЛИНИЯ» в дополнение к сердцебиению (вернитесь к предыдущему фрагменту Рахула Саси для контекста), отправляя сердцебиение, а затем наблюдая, появляется ли оно в ответе. Это немного больше, чем это, но вы поняли идею.
Почему на то, чтобы найти риск, потребовалось 2 года — не безопасен ли открытый исходный код ?!
Теория выглядит следующим образом: «Программное обеспечение с открытым исходным кодом является более безопасным, потому что сообщество может проверить его и выявить ошибки намного раньше». Ключевое слово в этом утверждении, конечно, может , а не будет .
Проект OpenSSL на GitHub содержит более 10 000 коммитов, охватывающих 21 участника и 25 веток в 57 МБ исходного кода. Он не очень большой, но там достаточно, и оглядка назад достаточно неясна, чтобы оставаться незамеченной до сих пор. Мы думаем — возможно, другие заметили ранее и использовали его. Говоря о которых…
Присутствует ли в нем АНБ / ГКК / Русская мафия?
Да. Следующий вопрос?
Если серьезно, то теперь мы получили представление о том, на что пойдут правительства для того, чтобы перехватывать и дешифровать частные сообщения в массовом порядке и без нацеливания (и на мгновение не думаем, что это делают только США — мы забыли? Китай и другие уже ?!), можете ли вы представить, насколько это привлекательно для организаций, которые проводят массовые захваты пакетов? Если действительно возможно получить удаленные ключи удаленно с серверов, это будет абсолютной золотой жилой, и это чертовски просто, чем некоторые из вещей, которые, как мы теперь знаем, были предприняты правительствами.
Правительства — это одно, а карьерные преступники? Одна из тревожных вещей об этом риске — это простота его автоматизации. Мы уже видим, как это происходит как для хорошего (массовое тестирование веб-ресурсов организации), так и для плохого (массовое тестирование веб-ресурсов другой организации). То, что это можно сделать удаленно, оперативно и путем перечисления через несколько хостов, делает его еще более привлекательным, и я буду очень удивлен, если преступники еще не превратили это в инструмент массовой фильтрации данных.
Решат ли проблему перевыпуск сертификатов?
Да и нет. Во-первых, делать это можно только после исправления OpenSSL, иначе вы просто рискуете новым сертификатом.
Двигаясь дальше, если вы работаете с предположением, что закрытые ключи на уязвимых сайтах были скомпрометированы (и это самое безопасное предположение, если вы будете осторожны), тогда да, сертификаты должны быть переизданы, а старые отозваны . Но вот проблема с отзывом — проверьте настройки Chrome по умолчанию:
Да, нет проверки по умолчанию для аннулированных сертификатов в Chrome. Как насчет Internet Explorer:
Да, это настройка по умолчанию, и это было начиная с IE 7. Но, конечно, Chrome теперь имеет львиную долю аудитории просмотра, поэтому, хотя переиздание сертификата и отзыв старого, это хороший шаг, где присутствуют уязвимые версии OpenSSL, это не обязательно помешает клиентам доверять отозванным сертификатам. Насти.
Но помимо технической логистики того, как отозванные сертификаты проверяются (или нет), есть также влияние на стоимость. Обычно сертификаты стоят денег. Иногда отзыв сертификата стоит денег. Как сказал сегодня утром друг и умный охранник Кейси Эллис , сейчас целая куча продавцов сертификатов делают это:
Там редко серьезный инцидент безопасности без больших возможностей, представляемых игрокам в индустрии безопасности.
Как вы скажете, если вы уже были скомпрометированы?
Да, насчет этого — вы не можете просто вернуться через обычные логи, чтобы найти следы компромисса. Снова из heartbleed.com :
Эксплуатация этой ошибки не оставляет следов чего-либо ненормального, происходящего с журналами.
Проблема в том, что эта ошибка не используется через каналы, которые обычно регистрируются. Вы страдаете от уязвимости SQL-инъекций, и журналы вашего веб-сервера полны хитрых HTTP-запросов. Конечно, тогда возникает очень неудобный вопрос: если ваш сайт был уязвим, вы работаете в предположении, что вы были скомпрометированы?
Существует целый ряд вещей, которые должны стать на место, чтобы атака была успешной (см. Последний раздел этого блога), но, тем не менее, многие компании окажутся в очень сложном положении, когда они узнают, что оба Потенциал для использования и знание того, как сделать это, были оба там. Взять, к примеру, Yahoo — что они должны делать в свете документированного примера Марка? Заставить всех сбросить свои пароли? Скажите клиентам, что их данные могут быть скомпрометированы? Это очень рискованная ситуация для них.
Можно ли идентифицировать атаки с помощью систем обнаружения / защиты от вторжений?
Возможно, и я видел доказательства того, что это может уже происходить, плюс различные провайдеры IDS начинают рекламировать возможность блокировки. Например, монитор сетевой безопасности Bro утверждает, что :
Братан может обнаружить эту атаку несколькими способами . В простейшем воплощении, которое мы пока видели в дикой природе, сообщение сердцебиения отправляется очень рано, до того, как включится шифрование TLS.
В этих случаях Bro просто сравнивает полезную нагрузку и размеры сообщений. Если есть несоответствие, мы знаем, что эксплойт был опробован. Если сервер отвечает на сообщение, он, вероятно, был уязвим для атаки.
Конечно, существует также риск того, что чрезмерно усердная IPS может полностью блокировать запросы на сердцебиение ( относится к риску heartbleed.com ), но, честно говоря, если сайт действительно уязвим к риску, то это не плохая позиция, и это то же самое. конечный результат — перекомпиляция OpenSSL с отключенными пульсами. Да, это может сделать неприятные вещи немного, но возможная альтернатива намного, намного хуже.
Если вы используете IPS и не смогли исправить основной риск, то стоит немного взглянуть на то, могут ли быть доступны сигнатуры, чтобы смягчить проблему в промежуточный период.
Что влияет только на HTTPS?
Все, что имеет зависимость от OpenSSL, которое может включать реализации VPN, клиенты для обмена мгновенными сообщениями, электронную почту и кучу других вещей, о которых я почти наверняка не думал. Тот факт, что вы не видите HTTPS в адресной строке, не означает, что у вас нет риска.
Устраняет ли все это совершенная прямая секретность?
Да, но не ретроспективно, а только потенциальный риск открытых ключей, а не сценарий, в котором раскрывается содержимое памяти. Идея идеальной секретности форварда заключается в том, что использование одного ключа не должно привести к краху всего карточного дома:
Системы с открытым ключом, которые генерируют случайные открытые ключи за сеанс для согласования ключей, которые не основаны на каком-либо детерминированном алгоритме, демонстрируют свойство, называемое совершенной прямой секретностью . Это означает, что компрометация одного сообщения не может привести к компрометации других, а также что нет единого секретного значения, которое может привести к компрометации нескольких сообщений.
В контексте Heartbleed, если закрытый ключ может быть извлечен из памяти, это не приведет к компрометации каждого отдельного сообщения, так как они будут уникальным ключом. Но опять же, это то, что вы создали сейчас на будущее, это не решение Heartbleed, для этого уже слишком поздно.
Я администратор системы — что мне делать?
Если вы несете ответственность за поддержание инфраструктуры и веб-сервера, на котором работают сайты, есть один четкий немедленный шаг: обновите ваш OpenSSL до версии 1.0.1g в приоритетном порядке. Если это невозможно, вы можете перекомпилировать OpenSSL и отключить биение с помощью этого переключателя:
-DOPENSSL_NO_HEARTBEATS
Однако, как я объяснил ранее, сердцебиение служит определенной цели, и его отключение может оказать перфектное воздействие, поэтому относитесь к нему только как к пробелу.
Следующие шаги зависят от вашего неприятия риска или уровня паранойи в зависимости от того, как вы на это смотрите. Это и ценность информации, которую вы защищаете. Эти шаги также могут быть доменом разработчика и могут включать:
- Переоформление любых затронутых сертификатов
- Отзыв любых затронутых сертификатов
- Рассматривая возможность блокировки вредоносных запросов сердцебиения на уровне IPS
- Срок действия любых активных пользовательских сессий
- Принудительный сброс пароля на любых учетных записях пользователей
Это совет, который я получил от AppHarbor в отношении моих веб-сайтов, размещенных на них (хотя я добавил пункт о IPS), и хотя вы можете утверждать, что это ошибочно, вы также можете утверждать, что это точно что мы должны делать только сейчас.
Я разработчик — что мне делать?
Прежде всего, убедитесь, что вы прочитали предыдущий раздел для системных администраторов, потому что вы можете быть похожим на меня и обнаруживать, что делаете все виды вещей, которые теоретически являются областью людей, которые пачкаются руками на серверах.
Мне, как человеку, который очень старается преодолеть разрыв между дисциплинами разработки и безопасности, расстраивает то, что эта ошибка означает, что я больше не могу просто говорить «Разработчики, сосредоточиться на внедрении SSL в ваших веб-приложениях и не беспокоиться о протокол». Конечно, вы все равно хотите убедиться, что SSL настроен соответствующим образом для начала ( попробуйте пройти тест Qualsys SSL Labs для бесплатной проверки), но это больше не просто вопрос получения правильных результатов с самого начала, а затем переход к фокусированию. исключительно для того, чтобы пометить куки как безопасные и не загружать страницы входа по HTTP и т. д. и т. д.
Один чрезвычайно прагматичный совет, который я могу дать, заключается в следующем: не собирайте и не храните то, что вам не нужно. Недавно мне пришлось столкнуться с инцидентом, связанным со сбором религии владельцев регистрации, частью очень конфиденциальных данных для многих людей, и это было в чужой стране, которая не всегда особенно терпима, если ваше мировоззрение не совпадает с их мировоззрением. Зачем им это было нужно? Они этого не сделали, просто «тогда это казалось хорошей идеей». Вы не можете потерять то, чего у вас нет, и этот подход защитит данные не только от воздействия через Heartbleed, но и от атак с использованием SQL-инъекций, небезопасных прямых ссылок на объекты и перехвата сеансов, а также от множества других неприятностей, которые потенциально могут быть использованы. данные клиентов.
Я запускаю онлайн-сервис — что мне делать?
Теперь необходимо рассмотреть, какой ущерб может нанести злоумышленник, если он сможет получить учетные данные пользователя, конфиденциальные данные или сеансы перехвата. Что может получить доступ злоумышленник, если он вошел в систему как пользователь? Что они могли разрешить? Что они могли тогда сделать с этой информацией?
Одна из самых больших проблем здесь заключается в том, что вы почти наверняка не сможете определить, скомпрометированы ли вы. Вы можете сказать, подвергались ли вы риску и знаете ли вы, что вы остались уязвимыми, но вы можете только догадываться об окне уязвимости. Вы не знаете, когда злоумышленник впервые осознал этот риск — он был социализирован только в последние пару дней, но был введен более двух лет назад. Даже если вам потребовались часы, чтобы исправить, было ли достаточно времени для эксплуатации?
The most cautious approach in the security sense is to force password resets and explain to customers that there may have been “an incident”. That’s not a pleasant experience for you nor for your customers and there’s a trade-off to be considered between what makes sense security wise and what the impact on trust and the general user experience might be. It’ll be a case-by-case decision and it won’t be easy.
What do I tell my non-technical friends to do?
Break out the tinfoil hits? Turn off all their things? Take a break on a desert island until things calm down? This is one of those things where consumers won’t be the ones that need to take direction action in relation to the bug, at least not in the same way as, say, the goto bug in iOS recently which resulted in an update to the OS. They’re not the ones patching bad OpenSSL on web servers (although we’re yet to see if this risk may impact clients with OpenSSL dependencies).
On the other hand, they may need to take action if the bug has resulted in the exposure of their credentials or other personal data. Ideally this will be advice given to them by websites that have reason to believe there may have been a compromise, that is if they’re proactive enough to identify the risk and (arguably) responsible enough to advise their customers to take preventative action. It’s also an activity that should only be performed after a vulnerable site is patched and a new certificate installed – it’s no good going and putting a shiny new password into a site that may still expose it to an attacker.
Of course it also serves as another valuable reminder to consumers – The only secure password is the one you can’t remember. This is an oldie but a goodie and the premise remains the same; we must always make the assumption that passwords will eventually be compromised and that they must be both strong and unique which means that committing them to memory – human memory – is out. Two factor is another biggie and you want to make sure this is turned on at every possible location (Dropbox, GitHub, Evernote, Microsoft Live ID, etc). This won’t all solve the problems of Heartbleed, but it’s about the extent to which consumers can influence it.
But is it really that bad? And what happens next?
Multiple things have to line up in order for this bug to lead to successful exploitation:
- The site has to implement SSL in the first place – no SSL means no OpenSSL means no Heartbleed bug.
- The site has to be running OpenSSL. That rules out a significant chunk of the internet, including most IIS websites.
- The OpenSSL version has to be somewhere between 1.0.1 and 1.0.1f; anything older or newer and the bug isn’t present.
- An attacker needs to have had access to an at-risk environment somewhere between learning of the bug and it being patched by the provider.
- If all these things line up, there must have been something useful and retrievable from memory at the time of the attack. That’s highly likely in all but the most dormant sites.
- But regardless of current site activity, if the attacker had previous pcaps of traffic (hello again, NSA!) and could then pull the private key from the site, that’s a serious problem.
The problem, of course, is that whilst points 1 through 3 are clearly definable, in most cases we’ll have no idea of whether points 4 and on actually happened. How long did an attacker know about the risk before it was patched? Were they then able to gain access to the server? Was there anything useful in memory at the time? Or could they use exfiltrated keys against prior data captures?
It’s very early days right now and a number of different things could happen next. One likelihood is that we’ll see impacted sites requesting password resets; Mark showed how Yahoo is vulnerable, surely they can’t not now ask people to reset their passwords? I don’t mean to call out Mark specifically either, a quick trawl through pastebin shows extensive public documentation of vulnerable sites. Or how about all those on the list of the Alexa Top 10,000 that have all been tested and many shown to be vulnerable? That’s a very big list and in fact the password resets are already happening, I received this one today from AppHarbor:
Of course the other risk is that we’ll see exploitation of credentials that have been pulled from vulnerable sites. This could take on many forms; we’ve seen Acai Berry spam on Twitter after the Gawker breach and many significantly more serious events as a result of stolen credentials. The problem now is that every time an account is compromised by stolen credentials the question is going to be asked: “Where these popped from a vulnerable site via Heartbleed”? This bug could have a very, very long tail.