Многие центры безопасности смыслом своей работы, а то и жизни делают борьбу с хакерами и атаками. Дело действительно важное и интеллектуально очень емкое. Исследуем данные Threat Intelligence, собираем атрибуцию на группировки и её TTP (tactics, techniques and procedures), разрабатываем отдельные сценарии и правила выявления инцидентов, внедряем мощные технологические решения. Это огромный и важный кусок работы любой команды по безопасности, а уж тем более любого зрелого SOC.



Но периодически все классические подходы к безопасности через мониторинг просто умножаются на ноль, когда в жизнь приходит большая и неприятная массовая атака. Та самая, о которой узнаёт даже ваша бабушка. Условно назовем такую атаку медиакиберпандемией, чтобы не путать с регулярными рассылками Cobalt или хитрыми инструментами Silence (для бывалых они уже стали чем-то вроде белого шума). Речь о Heartbleed, Shellshock, WannaСry, уязвимости в оборудовании Cisco и прочих. Что их отличает от прочих кибердиверсий? Как в этом случае стоит (или не стоит) вести себя SOC и просто ИБ-службе компании? Давайте разбираться под катом.

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3

Безопасность через неясность работает в некоторых редких ситуациях: например, указать нестандартный порт SSH для защиты от брута или закамуфлировать критически важный объект, как сова на фотографии (см. приёмы обфускации кода). Да, есть такие экзотические методы. Но обычно наилучшую защиту обеспечивает максимальная открытость кода.

Чем меньше секретов в коде программы — тем безопаснее.

Насколько справедливо это парадоксальное утверждение? Посмотрим на статистику.

Фонд электронных рубежей (EFF) подал иск против Агентства национальной безопасности США.

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

Вполне вероятно, что иск будет удовлетворён, поскольку в точности соответствует параграфу 552 Закона о свободе информации, в части «общественной важности» рассекречиваемой информации. В этом случае он станет первым шагом в подготовке процесса публичного обсуждения деятельности АНБ.

Агентство ранее уже косвенно дало понять, что при определённых условиях не разглашает информацию о 0day-уязвимостях, используя их для сбора разведданных в целях национальной безопасности.

На хабре уже появлялись статьи о незащищенных инстансах mongodb и непропатченных openssl с heartbleed.
Проект un1c0rn решил не мелочиться и сделать целый «поисковик уязвимостей», в статье на Motherboard.vice.com un1c0rn даже назвали «Google-ом для уязвимостей».



UPDATE 17.06.14 — un1c0rn стал платным! Теперь для доступа к результатым эксплойтов они просят перевести на их кошелек сумму не менее 0,01 BTC

Warning:
Only part of the leaked data is available.
Send your contribution to… (> 0.01 BTC) to unlock the full leak.

Пользователи Windows, я думаю, были несколько расстроены, что OpenSSL Heartbleed их практически не затронул. Теперь же и они могут повеселиться, ведь у них есть аналогичная уязвимость!

Вчера Microsoft опубликовала Security Bulletin MS14-066, в котором описывается критический баг в SChannel — реализации SSL/TLS от Microsoft, который позволяет злоумышленнику удаленно выполнять произвольный код. Обновления, закрывающую уязвимость, уже доступны через Windows Update.

Подвержены все версии Windows, начиная с 2003, в том числе и Windows RT. Это позволяет предположить, что уязвимость имеется не только на стороне сервера, но и на стороне клиента.

Один из топовых сайтов Alexa (центральный кружок), защищённый HTTPS, с поддоменами (серым) и зависимостями (белым), среди которых есть уязвимые (штриховая заливка)

В наше время значок защищённого соединения HTTPS стал стандартным и даже необходимым атрибутом любого серьёзного сайта. Если сертификат отсутствует, почти все последние браузеры показывают предупреждение, что соединение с сайтом «не защищено» и не рекомендуют передавать на него конфиденциальную информацию.

Но оказывается, что наличие «замочка» в адресной строке не всегда гарантирует защиту. Проверка 10 000 ведущих сайтов из рейтинга Alexa показала: многие из них подвержены критическим уязвимостям протоколов SSL/TLS, обычно через поддомены или зависимости. По словам авторов исследования, сложность современных веб-приложений многократно увеличивает поверхность атаки.

Половина сайтов использует HTTPS, и их число стабильно увеличивается. Протокол сокращает риск перехвата трафика, но не исключает попытки атак как таковые. О некоторых их них — POODLE, BEAST, DROWN и других — и способах защиты, мы расскажем в нашем материале.

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

Что произошло?

1 января 2012 года, Robin Seggelmann отправил, а steve проверил commit, который добавлял HeartBeat в OpenSSL. Именно этот коммит и привнес уязвимость, которую назвали HeartBleed.

Насколько она опасна?

Эта уязвимость позволяет читать оперативую память кусками размером до 64КБ. Причем уязвимость двусторонняя, это значит, что не только вы можете читать данные с уязвимого сервера, но и сервер злоумышленника может получить часть вашей оперативной памяти, если вы используете уязвимую версию OpenSSL.

Злоумышленник может подключиться к, предположим, уязвимому интернет-банку, получить приватный SSL-ключ из оперативной памяти и выполнить MITM-атаку на вас, а ваш браузер будет вести себя так, будто бы ничего и не произошло, ведь сертификат-то верный. Или просто может получить ваш логин и пароль.

Каков масштаб трагедии?

По моим оценкам, примерно ⅔ вебсайтов используют OpenSSL для HTTPS-соединений, и примерно ⅓ из них были уязвимы до сегодняшнего дня.

Уязвимость была/есть, как минимум, у:

• 10 банков
• 2 платежных систем
• 8 VPN-провайдеров
• mail.yandex.ru
• mail.yahoo.com

Используя уязвимость, с mail.yandex.ru можно было получить письма пользователей вместе с HTTP-заголовками (и, подставив cookie, зайти под этим пользователем), а, например, в АльфаБанке получать незашифрованные POST-данные с логином и паролем от Альфа-Клик (интернет-банкинг).

Когда я писал об ошибке в GnuTLS, я сказал, что это не последняя тяжелая ошибка в стеке TLS, которую мы увидим. Однако, я не ожидал, что всё будет так плачевно.

Ошибка в Heartbleed — это особенно неприятный баг. Она позволяет злоумышленнику читать до 64 Кб памяти, и исследователи в области безопасности говорят:

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

Что может узнать атакующий

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

Уязвимость двусторонняя: если уязвимый клиент подключается к серверу злоумышленника, то злоумышленник может читать память процесса клиента. Пример уязвимых клиентов: MariaDB, wget, curl, git, nginx (в режиме прокси).

О Heartbleed уязвимости, которая присутствует в компоненте «heartbeat» некоторых версий OpenSSL, написано уже достаточно подробно. Основная ее особенность заключается в том, что атакующий может прочитать определенный диапазон адресов памяти (длиной 64KB) в процессе на сервере, который использует эту библиотеку. Используя эту уязвимость злоумышленники путем отправки специальным образом сформированного запроса могут:

• Украсть пароли/логины от ваших сервисов.
• Получить доступ к конфиденциальным cookie.
• Украсть приватный SSL/TLS ключ сервера, с которым вы работаете по HTTPS (скомпрометировать HTTPS).
• Украсть любую секретную информацию, которую защищает HTTPS (прочитать письма, сообщения на сервере и т. д.).

Злоумышленники могут скомпрометировать HTTPS и позднее (через известную атаку типа MitM), имея у себя на руках закрытый SSL/TLS-ключ (представиться сервером).

Короткий ответ на вопрос, озвученный в заголовке: потому, что этого не требуется. Heartbleed, одна из самых критичных уязвимостей в истории OpenSSL, не ударила по нашим пользователям. Чуть более подробный ответ – под катом.

Пока индустрия, в целом, отходит от удара, нанесенного ей Heartbleed, отдельные компании выпустили свои пресс-релизы и комментарии, в которых разъясняют свою причастность к сабжу. Ниже дана справка по известным вендорам в кратком виде.

Сервис: Facebook
Затронут уязвимостью: неясно
Нужно сменить пароль?: Да. We added protections for Facebook’s implementation of OpenSSL before this issue was publicly disclosed. We haven’t detected any signs of suspicious account activity, but we encourage people to… set up a unique password.

Сервис: Tor
Затронут уязвимостью: косвенно, через другие серверы
Нужно сменить пароль?: зависит от целевого сервера. If you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle.
Детальнее см. https://blog.torproject.org/blog/openssl-bug-cve-2014-0160

Сервис: LinkedIn
Затронут уязвимостью: нет
Нужно сменить пароль?: нет. We didn't use the offending implementation of OpenSSL in www.linkedin.com or www.slideshare.net. As a result, HeartBleed does not present a risk to these web properties.

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

Вы, вероятно, догадываетесь, почему мы так делаем. CVE-2014-0160 — одна из самых серьезных уязвимостей, найденных за последние годы. Нельзя сказать, что она касается только отдельных сервисов и сайтов — уязвимость затронула практически весь интернет. OpenSSL — одна из самых распространённых криптобиблиотек. По разным оценкам, до двух третей всех HTTPS-соединений в интернете организуются с помощью этой библиотеки.

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

10 апреля 2014 года был представлен выпуск дистрибутива для создания межсетевых экранов и сетевых шлюзов pfSense 2.1.2. Дистрибутив основан на кодовой базе FreeBSD 8.3 с задействованием наработок проекта m0n0wall и активным использованием pf и ALTQ. Для загрузки доступно множество образов для архитектуры i386 и amd64, размером от 80 до 180 Мб, включая LiveCD и образы для заливки прямо на Compact Flash'ки разного размера (512, 1ГБ, 2ГБ, 4ГБ).

Агентству национальной безопасности было известно о уязвимости, которая недавно получила название Heartbleed, на протяжении двух последних лет. Также АНБ регулярно использовало эту уязвимость для получения доступа к желаемой информации. Об этом изданию Bloomberg стало известно от двух неназываемых людей.

Тем не менее, представители АНБ в ответ на публикацию этих данных заявили, что с багом CVE-2014-0160 эксперты агентства ознакомились лишь после массового распространения информации о нём в СМИ. Heartbleed — пожалуй, наиболее опасная уязвимость в истории Интернета, ей были затронуты основы безопасности приблизительно двух третей всех веб-сайтов.

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

11 апреля исследователи компании CloudFlare опубликовали в своём блоге статью «Answering the Critical Question: Can You Get Private SSL Keys Using Heartbleed?», в которой они задались вопросом, возможно ли извлечь приватные ключи, используя нашумевшую уязвимость Heartbleed. Попытка извлечь из оперативной памяти сервера приватный ключ не увенчалась успехом. В итоге исследователи пришли к выводу, что кража SSL-сертификатов с помощью Heartbleed маловероятна:

Мы считаем, что кража приватных ключей на большинстве серверов NGINX по крайней мере крайне затруднительна и, вероятно, невозможна. Мы уверены, что даже при использовании Apache, который, как мы считаем, может быть чуть более уязвимым, и который мы в CloudFlare не используем, вероятность раскрытия SSL-ключей с помощью уязвимости Heartbleed крайне мала. Это одна из немногих хороших новостей за эту неделю.

Несколько интернет-СМИ уже растиражировали это исследование (пример) и на его основе уверенно заявили, что кража приватных ключей с помощью Heartbleed невозможна. Как оказалось, исследователи CloudFlare были неправы.