Не беспокойтесь по поводу BREACH

Во время последней недели на конференции BlackHat общественности был представлен новый тип атаки, направленный на SSL-защищенный контент. Этот тип атаки был назван BREACH (англ. “брешь” прим. перев.), и вызвал целую волну обсуждений в различных сообществах. Технические блоги были забросаны ссылками на сайты со статьями о том, что нет никакой возможности это исправить, и как вы можете попытаться защититься от уязвимости. Многие уважаемые специалисты в ИБ писали об этом.

И я здесь, что бы сказать вам, не беспокойтесь об этом.

Дисклеймер

Данный пост и мое мнение основано на моем личном исследовании атаки, из данных доступных в открытых источниках. Если кто-то может доказать неправоту моих выводов, я буду очень рад изменить свою позицию и переписать этот пост.

С учетом вышесказанного, давайте продолжим.

Что такое BREACH

BREACH, по своей сути, это атака на защищенный HTTPS трафик, которая позволяет злоумышленнику извлечь часть защищенной информации. В основном она, использует детали HTTP сжатия для распознавания строки, если она уже присутствует на странице.

Это означает, что злоумышленник может совершать подбор, для поиска любого содержимого которое появляется на странице. Одна из самых больших проблем, как мне кажется, может быть, проблема с CSRF токенами. Где-нибудь на вашей странице у Вас может быть скрытый элемент формы, например:

	<input type="hidden" name="csrf" value="1sfgafu23r23p9oig" />

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

• угадать: 1sfa если общий размер содержимого: 950
• угадать: 1sfb если общий размер содержимого: 950
• угадать: 1sfc если общий размер содержимого: 950
• ...
• угадать: 1sfg если общий размер содержимого: 949

Реальная атака будет более сложной (и утонченной). Но это основная предпосылка. Это на самом деле очень похоже на атаку по времени (“Timing attack” прим. перев.).

Есть 3 обязательных условия, для успешного совершения атаки:

1. Использование HTTP сжатия (GZIP/DEFLATE)
2. Отражение пользовательских данных
3. Кража секрета

Отражение пользовательских данных (такие как URL аргумент) обозначает, что данные должны выводиться (примечание: где угодно) на странице предсказуемым образом (они могут быть замаскированы).

Так что да, это важно. Это массивная брешь. Это несет большую угрозу для персональных данных (представьте себе провайдера, у которого есть возможность проверить наличие определенных слов, в содержимом которое вы просматриваете). Это повлияет в будущем на проектирования систем. Но это не «Святой Грааль», каким делают его люди.

Давайте посмотрим почему:

Доступно только тело контента

Обратите внимание, что, так как атака использует детали сжатия HTTP (GZIP или DEFLATE), отправляемые на сервер заголовки отследить невозможно. Это означает, что если в теле ответа будут присутствовать куки(cookie), куки(cookies) (и любой другой заголовочный контент) будут защищены от этого типа атаки.

Обратите внимание. Если вы не включаете идентификатор сессии в тело ответа (что само по себе было бы небезопасно в любом случае), эта атака не может быть использована для атаки на сессию.

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

Cross-origin проблема

Так как вы не можете получить идентификатор сессии, лучшая применение атаки которое вы сможете реализовать это атака на браузер (“Browser-Based Attacks” прим. перев.) (например через встроенный IFRAME или нечто похожее). В этом случае, ваш код будет совершать большое количество запросов от IFRAME, и обрабатывать результат. Таким образом, вы могли бы извлечь CSRF токен из IFRAME без получения доступа к содержимому страницы!!!

Но подождите минутку. Браузер защищает нас от получения доступа к cross-origin данным. Таким образом, даже если злоумышленник смог добраться до вас через IFRAME, он не сможет увидеть размер ответа, что бы выполнить атаку в браузере…

Актуальная проблема

Есть один случай, когда атака действительно актуальна для получения доступа к базовой информации сессии. Если атакующий получит доступ для просмотра вашего трафика (например, через провайдера), и вы будете находиться на странице, которая будет выдавать запросы IFRAME, это позволит злоумышленнику получить CSRF токен. Далее злоумышленник может использовать расшифрованный токен для совершения POST запросов (через web-форму, или что-нибудь похожее) с действующим CSRF токеном. Которые могут быть интерпретированы удаленным сервером как корректные (поскольку он не сможет отличить из от настоящих запросов).

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

Но подождите минутку. Если вы следовали моим рекомендациям в прошлом о «Предотвращении CSRF атак», вы уже в безопасности от этого вектора атаки! Так как каждый CSRF токен это одноразовый номер (номер, использованный только один раз), он не используется более чем в одном запросе. Это означает, что злоумышленник не сможет этого сделать.

Таким образом, Вы уязвимы, если используете стандартные (статические) CSRF токены. Если вы используете случайный одноразовый токен, вы в безопасности.

Истинная проблема

Истинная проблема здесь в раскрытии информации. Если информация существует в виде текста на странице, злоумышленник может получить ее. Это серьезная проблема для кого-то вроде банковских сайтов, где ваш номер счета может быть показан в виде простого текста. Злоумышленник может использовать этот тип атаки для того что бы определить ваш номер счета. Что и является проблемой.

Но они не смогут использовать ее для того что бы отправить ложные запросы (так как они не могут скомпрометировать сессию). Так что это проблема (одна большая), но не все потеряно.

Практический результат

SSL традиционно оказывает три типа защиты:

1. Идентификация (Identity) – вы говорите кто вы и с кем вы разговариваете (используя сертификаты)
2. Конфиденциальность (Privacy) – никто не может видеть, что вы говорите
3. Проверка подлинности сообщения (Message Authentication) – сообщение, которое было отправлено, это сообщение которое было получено

Эта атака не эффективна для идентификации. Так же как и не эффективна для проверки подлинности сообщения (поскольку запрос все еще нуждается в обработке оригинального браузера). Вместо этого атака компрометирует только компонент конфиденциальности.

По сути, эта атака снижает HTTPS к шифрованию только заголовков. Большинство другого содержимого страницы подвержена своего рода прослушке (sniffing) (в зависимости от наличия XSS, например).

Теперь понимая, что шифрование заголовков по-прежнему значительно. Злоумышленник не может узнать, какой URL вы посетили (если они уже не определили его). Они не могут узнать какой хост (только IP адрес сервера). Они не могут получить ни один заголовок.
И так же они не могут получить ни одну куку (cookie).

Защита

Я говорил, не беспокойтесь об этом типе атак. Ну, я солгал. Есть несколько относительно простых мер предосторожностей, которые вы можете предпринять:

1. Используйте случайные одноразовые CSRF токены. Серьезно вы должны были делать это в любом случае.
2. Выключите сжатие для страниц содержащих конфиденциальную информацию (банковская информация, информация о состоянии здоровья и т.д.). Если вы все равно беспокоитесь по этому поводу, просто выключите его для всех страниц.
3. Случайное наполнение ответа. Следует отметить, что длина наполнения может значительно отличаться (это необходимо для случайной длины). Так вы можете добавить от 1 до 32 символов где угодно в контексте.

$randomData = mcrypt_create_iv(25, MCRYPT_DEV_URANDOM);
echo "<!--"
    . substr(
        base64_encode($randomData),
        0,
        ord($randomData[24]) % 32
    )
    . "-->";

Защитите сами себя

Все это будет работать, если у вас есть контроль над приложением (исход. код, управление сервером и т.д. прим. перев.). Но если у вас есть доступ только к вашему браузеру, вы можете защитить себя от атаки сами, просто используя расширение браузера: Change HTTP Request Header (Chrome).

В основном, я настраиваю автоматический профиль, который на всех сайтах изменяет заголовок в запроса Accept-Encoding на Accept-Encoding: identity, который отключает gzip и deflate для всех совместимых серверов. Это означает, что любой трафик должен будет быть в безопасности от подобного типа угроз…

Заключение

BREACH– это серьезная уязвимость. Но она не заслуживает того внимания которое ей уделяется в прессе или блогах.
Если вы, следуете лучшим практикам, злоумышленнику нужно выйти (существенно) за рамки данной уязвимости, что бы быть в состоянии произвести эту атаку. Злоумышленник должен найти брешь между вами и сервером. Если Вы используете открытый Wi-Fi, сделать это тривиально. В противном случае, эту задачу не так просто выполнить. Как только злоумышленнику удастся скомпрометировать линию связи, ему необходимо будет скомпрометировать URL. Мы знаем, с вредоносными программами, что это не трудно. Это не тривиально просто, но довольно близко к нему.

Как только злоумышленник получит URL, он должен будет найти на странице персональные данные. Сессии на основе секретов должны быть безопасными (если вы следуете лучшим практикам).

Да, это на самом деле проблема. Но не стоит делать поспешных решений. И так беспокоиться об этом. Позвольте мне прояснить одну вещь. XSS и SQLi (среди прочих) являются более практичными способами атаки на ваши сайты. Сфокусируйтесь на решении этих проблем. Хоть и нет однозначного решения для исправления BREACH, не беспокойтесь об этом…

Автор оригинала: Anthony Ferrara
Источник: http://blog.ircmaxell.com/2013/08/dont-worry-about-breach.html ^[1]

Автор: TODOOM

Источник ^[2]