Что можно сказать про Heartbleed? Скорее всего, по прошествии времени, почти каждый слышал это название. Heartbleed — ошибка в криптографическом программном обеспечении OpenSSL, позволяющая несанкционированно читать память на сервере или на клиенте, в том числе для извлечения закрытого ключа сервера.
Эта уязвимость «взорвала» СМИ, вызвав настоящий шквал публикаций, которые рассказывали о последствиях и угрозах, связанных с ее применением. Между тем, обилие специальной терминологии значительно затрудняет осознание масштабов проблемы. Также многим до сих пор неясно, что нужно делать, чтобы обезопасить свои информационные ресурсы. Практически сразу появились скрипты и сервисы, которые позволяли проверить сервер на предмет того, подвержен он уязвимости или нет. Любой пользователь мог скачать небольшой скрипт, который позволял получать произвольные данные из памяти, используя уязвимость Heartbleed.
Попытаемся кратко обрисовать, в чем суть проблемы, связанной с эксплуатацией этой уязвимости. Итак, сервер не проверяет корректность некоторых запросов, поступающих от клиентов. Установив соединение, клиент периодически обращается к серверу с просьбой подтвердить, что соединение еще не разорвано. В ответ сервер должен вернуть некоторый небольшой объем данных, причем количество их определяет сам клиент. Так вот, если клиент запросит больше данных, чем отправил, его запрос все равно будет выполнен и сервер пришлет ему кусок из оперативной памяти. Размер ограничен 64 кб, но ведь можно послать много запросов. Тем самым, количество переходит в качество — посылая сотни, тысячи запросов можно читать большие блоки данных. Как видно — не нужно каких-то сложных методов, чтобы проэксплуатировать эту уязвимость.
Как работает понятно, но не особо ясно, как это можно было бы применить. Какие данные могут храниться в оперативной памяти? Там может располагаться конфиденциальная информация — приватные ключи, логины/пароли, данные для подключения к БД. Очень важные данные, завладев которыми, можно фактически завладеть любым бизнесом. При этом Heartbleed встречается почти везде! По информации, которую опубликовали netcaft, полмиллиона серверов используют уязвимую версию SSL. Это довольно много. А еще интересно, что при эксплуатации уязвимости злоумышленник не оставляет каких-либо видимых следов в системе. Компания Cloudflare организовывала конкурс, участники которого должны были получить доступ к серверу, используя только эту уязвимость. И им удалось это, причем в довольно короткие сроки. И вот тогда пришло осознание того, насколько критичные последствия может повлечь за собой простая бага. Из обычной уязвимости она превратилось в суперкритичную, с большим количеством применений.
Как уже было сказано, уязвимость существовала на огромном количестве серверов. Кого это могло затронуть? В первую очередь, медийных гигантов, крупные социальные сервисы (Facebook, Twitter, Google, Yahoo, Dropbox и т. д.), различные финансовые организации и многих других. Большие организации с огромной аудиторией, несомненно, озабочены обеспечением безопасности своих клиентов. Как только информация о проблеме просочилась, множество из них поспешили выпустить пресс-релизы о том, были они уязвимы или нет, и что надо сделать пользователям, чтобы себя обезопасить. Например, в Facebook заявили, что использовали на своих серверах модифицированную версию, и она не уязвима. В LinkedIn сказали, что они вообще не использовали версию, подверженную Heartbleed. Специалисты Google подчеркнули, что «пропатчили» все основные сервисы компании. В Dropbox также сообщили, что все патчи установлены, так что пользователи могут спокойно менять пароли, чтобы уже окончательно почувствовать себя в безопасности. А Microsoft заявила, что вообще не использовала OpenSSL. Однако, со столь масштабной проблемой не всем удалось справиться так быстро, как хотелось бы. В частности, проблемы возникли у Yahoo. До сих пор компания призывает пользователей соблюдать осторожность при работе со своими аккаунтами, так как еще не все серверы полностью обновились. Это, вероятно, связано с проблемами в организации инфраструктуры: иногда слишком много поддоменов и приложений затрудняют своевременное обновление.
А как дела обстояли с финансовыми организациями? В множестве банков применяются как OpenSSL, так и проприетарные решения для шифрования. И финансовым организациям потребовалось значительное время, чтобы заявить, что «все в порядке». Так, банки столкнулись с такой проблемой, как отсутствие связи с отделом, осуществляющим администрирование (почта не работала вовсе или письма приходили со значительным опозданием).
Сейчас, подводя итоги через некоторое время, можно сказать, что у многих не было ясности относительно масштабов бедствия. Поэтому некоторые организации слишком поспешили «успокоить» общественность, даже не разобравшись в сути проблемы. В момент пика панических настроений было важно успокоить тех взволнованных пользователей, которые, начитавшись новостей под заголовком типа «Heartbleed украдет ваши данные», кинулись проверять свои сервисы. И ясно, что такой ответ, как «мы проверяем» или «мы еще не знаем», никого не смог бы успокоить.
Если организация большая, то зачастую в критические моменты там происходит следующее: большинство сотрудников не знает точно, из чего состоит их ПО и где оно работает. И когда появляется какая-то критическая уязвимость, становится сложно все консолидировать и своевременно применить обновления. Ответственность ложится на администраторов системы, а у них и «своих проблем хватает». Это приводит к тому, что никто ни за что ответить не может, а проблема уже на пороге. Справедливости ради отметим, что большинство организаций, которые действительно обнаружили у себя наличие уязвимости, исправили ее максимально оперативно (и занялись перевыпуском сертификатов), внедрили какие-либо дополнительные меры защиты, дали пользователям рекомендации по защите.
В сети сразу появились специальные сервисы (и код на github), которые позволяли проверить тот или иной хост на наличие Heartbleed. Любой желающий мог взять и убедиться в том, присутствует ли проблема на том или ином сервере или нет. Несмотря на популярность OpenSSL, есть и другие реализации SSL/TLS. Кроме того, некоторые сайты используют более раннюю версию OpenSSL, в которой этот баг отсутствует. А некоторые не включали функцию Heartbeat, которая и служит источником уязвимости. Не стоит забывать о том, что помимо серверного ПО есть же еще и клиентский софт, ведь он может также быть уязвим! Речь идет, в частности, о традиционном софте баз данных, клиентов облачных сервисов, специальных программ-браузеров для развлекательных порталов, даже драйверов устройств. Как и в случае с серверными приложениями, уязвимость клиентов определяется версией OpenSSL. Некоторые приложения, такие, как Openssh, использовали OpenSSL только для генерации ключей, а потому не были подвержены проблеме. Также Heartbleed не обошла стороной и встраиваемые устройства, например, домашние роутеры. Некоторые крупные производители сетевого оборудования даже сообщали о том, что отдельные их продукты были уязвимы для Heartbleed.
А что можно сказать про ПО, которое должно обеспечивать шифрование и приватность передаваемых данных? Например, когда обнаруживались уязвимости в OpenVPN, разработчик реагировал очень оперативно, выпуская патчи для всех уязвимых версий. Другие же производители «защищенного» ПО, которые использовали в своих версиях OpenSSL (или выдавали ее за свою реализацию) и были сертифицированы, обещая полную неуязвимость, также представляли собой, по сути, решето из-за Heartbleed. Ясно, что их безопасность пользователей не сильно волновала.
Эта история показала, что даже незначительная ошибка в коде может поставить под удар большое разнообразие технических и программных средств, начиная от прикладных программ, заканчивая модемами, роутерами и т. п. Как только были выпущены рекомендации по безопасности и патчи, вполне естественно появились странные новые уязвимости, непосредственно связанные с обходом тех исправлений и ограничений, которые были внедрены. Они были основаны на том, что даже при правильной сборке OpenSSL без Heartbeat (одна из рекомендаций) можно было также получить данные из памяти. Интересно, что в данном случае никто не торопился делиться подробностями. Суть пресс-релиза, посвященного уязвимости, сводилась к следующему: «Мы много работали, нашли способ обойти ограничения. Хотите больше подробностей? Платите!» Выглядело это довольно непонятно, поскольку в том, на что ссылались создатели нового сплойта, не могло быть какой-либо проблемы. Ситуация вызвала неподдельный интерес. В итоге оказалось, что это активизировались обычные мошенники, которые решили по-быстрому заработать денег на обстановке. Идея была в том, что они предлагали возможность обойти патч, чтобы пользоваться уязвимостью. Те, кто пробовал получить от них какие-либо доказательства, получали поддельные данные. Мошенники пару раз «прокололись» даже на банальных вещах: путали адреса серверов, подставляли какие-то совсем нелепые данные.
Как уже было сказано, даже небольшая ошибка в программном коде может вести к очень серьезным последствиям. На этом примере хорошо видно, что чем сложнее софт, тем могут быть более «поверхностными» такого рода проблемы. В этом деле мелочей не бывает. Можно услышать, что эту уязвимость используют как предмет спора: мол «вот вы говорите: свободное ПО, коммьюнити, а сами такую „бомбу“ не обнаружили, поэтому все ваше свободное ПО не только не безопасное, а вообще насквозь плохо написано».
И вообще опровергает ли случившееся известное утверждение, что пользователи свободного программного обеспечения более защищены от ошибок, чем пользователи проприетарного софта, поскольку каждый желающий может проверить код на наличие уязвимостей? В маленьких проектах может быть да — скачал исходники и проверил. Но когда проект разрастается, такое сделать уже очень сложно, если вообще возможно. То есть когда размер исходников переваливает за десятки мегабайт и количество строк кода в проекте уже не сотни, а миллионы, тот факт, что их можно скачать и посмотреть, слабо влияет на защищенность. Более того, их открытость может создавать иллюзию безопасности. Когда проект разрастается, только анализ, т. е. привлечение профессионалов, которые будут заниматься проверкой кода на постоянной основе, является решающим фактором для обеспечения безопасности на каком-либо должном уровне.
Сложно сказать, общепринятая это норма или встречается только в отдельных проектах. Но это могло бы предотвратить появления таких уязвимостей, как Heartbleed. Подводя итог, можно сказать, что лучшая оценка для Heartbleed была дана Брюсом Шнайером: «По шкале угроз от 1 до 10 Heartbleed — это 11 баллов».
Автор статьи — исследователь ИБ Digital Security.