Главная Интернет

Создание фальшивых SSL сертификатов или новогодний подарок для фишеров. Настроить Nmap для сложных условий

Решение: Нередко бывает нужно потребоваться перехватить данные. Например, для решения исследовательских задач или при проведении реальных атак. Причем наряду с возможностью посмотреть желательно еще иметь возможность и поменять что-то в потоке данных. И если с обычными протоколами по большей части все просто, то при оборачивании их в SSL (что случается в последнее время все чаще) мы получаем проблемку.

Warning!

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

Окей, если говорить об анализе трафика из браузера, то проблем не возникает. Любой перехватывающий прокси-сервер (а-ля Burp или ZAP) справится с этим на раз. А что делать, если «ломаемое» клиентское приложение не умеет использовать прокси? А что делать, если используется там какой-нибудь не HTTP-протокол? О решении второй проблемы мы поговорим в следующей задаче (разделены они были лишь для будущего удобного поиска), о первой же - читай ниже.

Хотелось бы отметить, что идейно «атака» на SSL будет одинакова для любой из тулз. Важно понимать, что никто не пытается расшифровать передаваемые данные, ведь главное - это обойти проверку правильности конечной точки подключения, которая происходит на первых этапах подключения, то есть заставить клиент думать, что наш сервис - это то место, куда он хотел подключиться. Подписи, сертификаты и все такое. Но не будем углубляться и перейдем к сути.

Есть клиентское приложение, работает по HTTPS, но юзать прокси не умеет. Мы можем использовать тот же Burp или любой другой прокси, который в состоянии работать в режиме transparent (invisible).

Немного поясню, в чем разница. Начнем с простого - с HTTP, а потом перейдем к HTTPS. Для обычного HTTP-трафика, когда используется прокси, ПО (а-ля браузер) посылает такой запрос:

GET http://any\_host.com/url?query=string HTTP/1.1 Host: any\_host.com

Когда прокси отсутствует, то браузер шлет

GET /url?query=string HTTP/1.1 Host: any\_host.com

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

Если же приложение не поддерживает работу с прокси, то у нас возникает две проблемы: как заставить его подключиться к нам и как наш прокси может понять, куда подключаться.

Для решения первой задачи нам пригодится любой метод, при котором трафик от приложения потечет через нас. Мы можем либо стать гейтвеем/шлюзом для подсети (ARP poisoning в помощь), либо стать сервером (запись в hosts, DNS spoofing и прочее), либо использовать что-то поизвращенней.

Вторая же задача решается тем, что прокси берет имя сервера, куда надо подключаться, но не из URL’а, а из заголовка Host в самом запросе. Вот такое поведение прокси и называется transparent (хотя имеются и другие значения). Ты, например, можешь ходить в инет на работе, не указав прокси, но фактически подключения твои будут все равно идти через корпоративный прокси, с теми же ограничениями на контактик, что и у проксированных юзеров.

Но это было про HTTP. А как же с HTTPS? Здесь все труднее.

В прошлом номере я описывал, как работает браузер через прокси, подключаясь к HTTPS-сайтам. Напомню, что браузер подключается к прокси методом CONNECT с указанием имени хоста, куда он хочет подключиться. Прокси же, в свою очередь, подключается по указанному имени хоста, а дальше просто редиректит трафик от браузера на сервер.

Если же приложение не поддерживает прокси, то как же transparent прокси узнает, куда ему подключать клиента? В описанных условиях - никак. Во всяком случае, в автоматическом режиме.

Но все-таки вариант есть, если добавить сюда еще одну технологию. Она называется Server Name Indication (SNI) и является одним из расширений SSL-протокола. Поддерживается еще далеко не всеми, но основные браузеры уже в лодке. Технология очень простая. Клиент указывает имя сервера, куда подключается в самом начале SSL handshak’а (то есть эта инфа не зашифрована).

Таким образом, у transparent-прокси опять-таки появляется возможность автоматически проксировать данные между клиентом и серверами на основе анализа SNI при подключениях.

Теперь общая ситуация примерно ясна. Перейдем к частностям. За основу возьмем Burp и его возможности, как типовой пример.

Если клиентское приложение не поддерживает прокси, то Burp, как ты уже понял, умеет работать в режиме invisible proxy. Включить его можно, воспроизведя следующую цепочку:

Proxy -> Options -> Proxy Listeners -> Выделение прокси -> Edit -> Request Handling -> Support Invisible Proxy.

Если клиент поддерживает SNI, то все хорошо: Burp может и к нужному хосту подключиться, и сгенерировать сертификат либо самоподписанный, либо подписанный Burp’овским CA. Но если это не так, то придется поработать руками.

Во-первых, на вкладке Request Handling мы должны указать адрес и порт, куда необходимо осуществлять подключение. Во-вторых, в Certificate указать имя сервера, для которого будет сгенерен сертификат. Самоподписанный создать совсем не получится.

Ясное дело, эти данные надо еще откуда-то получить. Тебе, скорее всего, потребуется посмотреть, к какому IP-адресу и порту подключается клиентское приложение, а далее подключиться к нему напрямую и из полученного SSL-сертификата взять имя для генерации своего.

Как видишь, все просто, но местами муторно. Но в итоге мы получаем чистый HTTP-трафик в Burp’е. За подробностями по этой возможности Burp’а обращайся сюда .

Перехватить не HTTP-трафик в SSL

Решение: Как ты, наверное, заметил, описанный выше транспарент-прокси для SSL-трафика, по сути, представляет собой простой порт-форвардинг. Получается такой редирект с подменой сертификата. И на самом деле, ведь в данном случае нет никакой особой привязки к протоколу, который находится внутри SSL. То есть предыдущая задача в какой-то мере подвид этой.

Наш же вопрос с прошлого топика - а что делать, если внутри SSL используется не HTTP-протокол? IMAPS, FTPS и почти любой другой аналогичный протокол с буковкой S на конце. В SSL запихивают все подряд. А ведь как сладко было бы обойти SSL и добраться до чистого трафика…

Ответ простой. В других случаях - не использовать Burp:), а использовать что-то другое. Есть много различных тулз, которые в этом помогут. Какие-то из них заточены под конкретный протокол, но есть и универсальные. С одним из универсалов я и хотел бы тебя сегодня познакомить - с SSLsplit .

Тулза эта прекрасна тем, что ее основная идея очень проста и понятна, но при этом имеется приличный объем специфичных настроек. Она представляет собой простой порт-форвардер («если трафик пришел на такой-то порт - пересылай все в такое-то место»), но имеет возможность для «работы» с SSL. Можно подсунуть реальный (краденый) сертификат, создать самоподписанный или подписанный своим CA. Также поддерживает автоматическую генерацию на основе SNI или редирект трафика на конечный IP-адрес (когда мы изображаем из себя гейтвей). Плюс она консольна, что позволяет легко автоматизировать типовые действия. Все это в целом делает ее куда более юзабельной для проведения атак (а не просто анализа протоколов приложений). Что делать дальше с трафиком - это уже зависит от твоих потребностей.

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

Sslsplit -k ca.key -c ca.crt -l connect.log -L /tmp ssl 0.0.0.0 993 www.example.org 993 tcp 0.0.0.0 143

Здесь -k и -c указывают путь до приватного ключа и сертификата нашего CA, которые можно сгенерить при необходимости, используя openssl. Остальные параметры:

-l - путь до файла, в котором будет вестись лог коннектов;
-L - путь до директории, в которой будут сохраняться логи всех подключений (в плейн-тексте);

Далее блок «ssl 0.0.0.0 993 www.example.org 993». Ssl указывает, что мы снифаем SSL и надо подменить сертификат. Далее интерфейс и порт, на котором SSLsplit будет прослушивать трафик. Последняя пара - имя домена и порт, куда SSLsplit должен подключиться.

Блок «tcp 0.0.0.0 143» почти аналогичен. Но здесь мы указываем, что ssl не используется (поэтому tcp), а также входной порт SSLsplit. Если SSLsplit «подключен», как гейт (шлюз), то можно не указывать конечную точку подключения, так как она будет взята из IP-заголовков.

Таким образом, мы имеем простую и универсальную тулзу. Описание ее использования с примерами можно почитать , а перечень всех возможностей (man).

Настроить Nmap для сложных условий

Решение: Nmap, несомненно, тулзенка из топ-десятки самых необходимых и заюзанных тулз - как для пентестов, так и для мониторинга системы, да и для других дел. С одной стороны, она проста, умна и быстра, за что ее все любят. С другой стороны, при работе с ней в нестандартных условиях возникают различного рода трудности, во многом связанные с тем, что не совсем понятно, как же она устроена внутри, ее алгоритмы.

А внутренности Nmap совсем не простые, даже если взять ее главный функционал - сканирование портов. Не вдаваясь в подробности, можно четко утверждать, что целью создателей Nmap было сделать сканер, который бы предельно точно находил открытые порты (то есть без false positive, false negative), мог бы работать в различных сетях (стабильных/нестабильных, быстрых и медленных), подстраиваться под меняющиеся характеристики сети (например, когда промежуточное сетевое оборудование перестало справляться с нагрузками). То есть поведение Nmap меняется динамически, под конкретную сеть, под конкретный хост.

С другой стороны, его нацеленность на точность часто очень негативно сказывается на производительности. Приведу типичный пример: сканирование хостов в интернете, часть из которых находится за файрволом. На SYN-запрос на закрытый порт файрвол не отвечает ничего, вместо RST. Казалось бы, в чем проблема? Как раз в умности Nmap. Так как причин проблемы он не знает (файрвол, лагучая сеть, ограничения конечного хоста), то он будет замедлять частоту отправки запросов на сервер (до одной секунды по умолчанию), увеличивать ожидание до ответа на отправленный запрос (до десяти секунд). И добавь сюда то, что Nmap перепроверяет порты по десять раз. Получается, чтобы просканировать все TCP-порты зафайрволенного хоста с одним открытым портом, счет переходит даже не на часы, а на дни. Но найти-то данный открытый порт необходимо.

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

Признаюсь, сам я не глубокий знаток алгоритмов Nmap (об этом ведь даже книги пишут:Nmap Reference Guide , Nmap Network Scanning), что необходимо для корректной настройки таймингов. С другой стороны, у нас тут Easy Hack, так что сконцентрируемся на основных параметрах и практических рекомендациях (которые в большинстве случаев отлично работают).

Итак, у Nmap есть ряд параметров, напрямую влияющих на производительность. Все приводить не буду, а лишь понравившиеся:).

Перед началом сделаю два замечания. Здесь, раньше и далее «по умолчанию» значит «для профиля Т3», который и на самом деле используется по умолчанию, когда не выбран какой-то другой профиль. А значение задается в секундах, но можно использовать и другие единицы времени, добавляя соответствующую букву. Например, 3000ms, 5h, 10s.

--initial-rtt-timeout , --max-rtt-timeout . RTT (Round Trip Time) - время от отправки пакета до получения на него ответа. Очень важный параметр, который постоянно подсчитывается Nmap’ом во время сканирования. И не зря, ведь по нему Nmap понимает «производительность» сети и конечного хоста. Фактически он напрямую влияет на то, как долго будет ждать Nmap между отправкой запроса и получением ответа.

И как ты понимаешь, если ответа мы не получаем, то это значительно влияет на RTT. Как следствие, Nmap, послав SYN-пакет в «черную дыру» файрвола, будет ждать в итоге max-rtt (даже в быстрой сети), перед тем как понять, что порт зафильтрован. По умолчанию initial - одна секунда, max - десять секунд.

Для выбора же корректных значений RTT запускаем Nmap с параметром -traceroute (команда ping тоже подойдет). По сути, нам надо получить время прохождения пакета до конечного хоста или хотя бы «близкого» к нему. Далее, рекомендуется для initial указать удвоенное полученное значение, а для max - учетверенное.

--max-retries - очень простой параметр - максимальное количество повторов. Хотя я уже и писал, что десять повторов может быть, но это только в случае, если Nmap ощущает «плохую» сеть. Обычно меньше. Так что если сеть хороша - можешь обрезать вполовину и даже больше.

--max-scan-delay - максимальное время ожидания между отсылкой пакетов. По умолчанию - секунда. Если сеть хороша и нагрузки не боится (то есть почти всегда), то спокойно можно уменьшать даже в пять раз.

--host-timeout . Последний параметр относится косвенно к настройке тайминга, но очень и очень полезен. Он позволяет установить значение, после которого хост «пропускается» в сканировании.

Представь, сканируем мы сеть класса С и сканирование идет скоренько. Но тут бац! Два-три хоста где-то в середине сильно зафильтрованы. Если не настроил все заранее (как указано выше), либо жди «до бесконечности», либо пересканируй все заново, но уже с настройками.

Так вот, если Nmap достигает host-timeout для конкретного хоста, то он останавливает сканирование и переходит к следующим хостам. Установив значение минут в двадцать-тридцать, можно уже не опасаться «зафайрволенных» хостов, по достижению лимитов они проскочат. А разобраться с ними можно будет уже позже, настроив сканирование вручную. И да, по умолчанию он бесконечен.

Конечно, есть еще другие параметры для настройки производительности Nmap’а, так что если эти тебе не помогли, то обратись сюда . Но главная мысль, скорее, такова: лучше потратить чуть больше времени на первичную настройку, чем потом ждать или пересканировать.

Установить любое приложение на Android

Решение: Недавно была задискложена отличнейшая логическая бага в Android. И мне кажется, это хороший, типичный представитель логических уязвимостей, а потому хотелось бы познакомить тебя с ней. Ведь такие баги - это просто кайф: и мозгом пошевелить надо, и найти можно там, где уже «каждый совал свою кавычку».

Итак, суть проблемы заключалась в том, что любое андроидовское приложение, обладающее определенными, не очень большими привилегиями, имело возможность установить ЛЮБОЕ другое приложение с маркета, с любыми привилегиями. То есть закачал себе человек игрульку, а та взяла и поставила еще софта на девайс и слила все деньги через какой-нить SMS-сервис. Здесь мы видим прямой профит для злых дядек, а потому ее автору гугл заплатила две тысячи долларов.

Давай же разберем багу. Я не буду вдаваться в технические глубины, а сконцентрируюсь на базовых вещах, чтобы те, кто незнаком с дройдами, тоже ощутил всю крутость. Ведь на самом деле она проста! Здесь все по принципу: по отдельности каждый из «фрагментов мозаики» защищен, а в целом - дыра.

Мозаика складывается из следующего:

В наше приложение мы можем добавить WebView, то есть браузер. При этом мы можем подпихнуть свой JavaScript на любую страницу.
Для установки приложения из маркета нам необходим лишь браузер. Например, ты можешь зайти на Google play и, если аутентифицирован, установить любое приложение на любой свой подцепленный девайс.
Обладая кое-какими правами (android.permission.USE_CREDENTIALS), приложение может запросить у Account Manager’а девайса токен на аутентификацию и автоматически залогиниться в WebView в твой акк.

Ощущаешь? Наше приложение может автоматически залогиниться в гугл и с помощью подконтрольного JS в WebView полностью эмулировать поведение пользователя! Всевозможные анти-CSRF-токены, запросы на согласие о высоких правах и прочее мы можем вынуть и «накликать».

Хотя фактически так же мы можем получить доступ и к другим сервисам гугла. Почту, например, почитать:).

Так как багу задисклозили, значит, ее и закрыли. По предположению автора, главным изменением стала отмена автоматического логина. Теперь выводится сообщение, правда ли мы хотим залогиниться, и без юзерского клика «ОК» никак не обойтись.

На этом все. За подробностями отправляю к , да и рекомендую запилить личный PoC.

В конце хотел бы лишь добавить про «глубину проникновения» гугла в нашу жизнь. Я не говорю о проблеме приватности. Аккаунт на гугле для очень многих людей главный, к которому привязано почти все. Причем это не просто набор критичных сервисов, а доступ к браузеру Chrome (а потом к ОС?), дройдо-девайсам (чему-то еще?). Мне кажется, что это в будущем значительно поменяет типовые подходы к безопасности. Например, трояны. Зачем «закапываться» вглубь систем, обходить разграничение прав ОС, подписи драйверов, когда можно спрятаться в JS-коде одного из компонентов браузера, ничего при этом не обходя и обладая контролем над главным «выходом»? Хотя понятно зачем:).

Или какую защиту для банк-клиентов может дать одноразовый код по SMS, если с затрояненного браузера на компе на все дройд-девайсы пользователя можно поставить троянчик, который будет читать SMS? Но это так - словоблудие:).

Спасибо за внимание и успешных познаний нового!

незнакомец 25 октября 2014 в 19:03

Подмена SSL сертификата провайдером

Информационная безопасность

Здравствуйте, пользователи Хабра!

Сегодня я столкнулся с довольно интересным способом «ограждения пользователей от нежелательной информации», а именно - подменой SSL сертификата.

Начну с того, что ко мне обратился мой хороший товарищ, играющий в интернет-покер. Его провайдер заблокировал один из суб-доменов покер-рума, отвечающий за ставки на спортивные события. Проверив у себя, с удивлением обнаружил, что у меня этот суб-домен открывается (начал уважать своего провайдера чуточку больше). Решил не оставаться в стороне от беды у хорошего человека.

На моем домашнем сервере поднят VPN PPTP сервер, которым я пользуюсь для доступа к общим ресурсам домашней сети, когда нахожусь на работе или где-то еще. Недолго раздумывая и взяв с товарища слово, что мой IP не будет им использоваться где-то еще, кроме этого покер-рума (кому охота потом сидеть за экстремизм или что-то еще противозаконное?) я создал для него отдельную учетную запись, выдал пароль, дал инструкции для подключения и со спокойной душой отправился по своим делам. Спустя 5 минут сообщение от товарища - «не помог этот ваш VPN».

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

Первым делом захотелось глянуть, что же за страницы получает мой товарищ при заходе на заблокированный сайт без VPN доступа. Тут начинается самое интересное, на мой взгляд:

При наличии подключения картинка не изменилась: сайт покер-рума отдавал сертификат провайдера моего товарища. Nslookup отдавал IP адрес заглушки. После прописывания VPN-сервера в качестве DNS-сервера в подключении ситуация изменилась - сертификат начал отдаваться правильно, но доступ все равно оставался закрыт.

Как вы могли заметить, https из строки адреса был убран специально - проверить, как блокируется сайт при использовании VPN.

Был сброшен кэш DNS Windows и по https ситуация улучшилась - сайт начал работать. Однако доступ без https по прежнему выдает заглушку. Скорее всего, проблема где-то на ПК товарища, но в этом я не уверен, в любом случае - ему было достаточно https и на данный момент его все устраивает.

Ну, а этичность в плане подмены сертификата - остается вопросом открытым который, скорее всего, провайдером будет проигнорирован.

Теги: ssl сертификаты, подмена ssl, блокировка сайтов, реестр запрещенных сайтов

Мы обнаружили уязвимость в Internet Public Key Infrastructure (PKI), используемой для выдачи цифровых сертификатов для Web сайтов. В качестве примера мы продемонстрировали часть атаки и успешно создали фальшивый CA сертификат, которому доверяют все современные браузеры. Сертификат позволяет нам выдать себя за любой сайт в интернете, использующий HTTPS, включая сайты банков и online магазинов.

Валерий Марчук
www.сайт

Вчера закончилась конференция 25C3 (25th Chaos Communication Congress) в Берлине. Одним из самых громких докладов на конференции стал доклад Александра Сотирова (Alexander Sotirov), Марка Стивенса (Marc Stevens) и Джекоба Аппельбаума (Jacob Appelbaum) – MD5 considered harmful today: Creating a rogue CA certificate. В этой статье я кратко опишу суть уязвимости и постараюсь ответить на возможные вопросы.

«Мы обнаружили уязвимость в Internet Public Key Infrastructure (PKI), используемой для выдачи цифровых сертификатов для Web сайтов. В качестве примера мы продемонстрировали часть атаки и успешно создали фальшивый CA сертификат, которому доверяют все современные браузеры. Сертификат позволяет нам выдать себя за любой сайт в интернете, использующий HTTPS, включая сайты банков и online магазинов».

Суть уязвимости

Многие центры сертификации до сих пор используют MD5 хеши для проверки подлинности сертификатов. С 2004 года достоверно известно, что MD5 хеши являются слабыми с криптографической точки зрения. Злоумышленник может создать фальшивый сертификат-посредник центра сертификации (CA), и с его помощью, подписать произвольное количество сертификатов, например, для Web серверов, которые будут считаться доверенными для коневых сертификатов – тех, которые находятся в «доверенном списке» в вашем браузере. Александру Сотирову, Марку Стивенсу и Джекобу Аппельбауму удалось создать фальшивый сертификат, выдающий себя за подлинный сертификат от RapidSSL. Для генерации фальшивого сертификата было сделано 4 покупки действительных сертификатов у RapidSSL, и использовался кластер из 200 станций Sony PlayStation 3 для коллизионной атаки. В основе атаки лежит метод обнаружения коллизий в MD5 хешах. В данный момент атака считается сложно реализуемой, но продемонстрированной на практике.
Исследователи собрали 30 000 сертификатов для Web серверов, 9 000 из которых были подписаны MD5, 97% сертификатов принадлежали RapidSSL.

Воздействие уязвимости

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

Уязвимые протоколы

Уязвимость распространяется на все протоколы, использующие SSL:

HTTPS
SSL VPN
S-MIME

SSH не уязвим к этой атаке.

Компании, выпускающие уязвимые сертификаты

RapidSSL
C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1
FreeSSL (бесплатные временные сертификаты, предлагаемые RapidSSL)
C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications
TC TrustCenter AG
C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 3 CA/[email protected]
RSA Data Security
C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Thawte
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/[email protected]
verisign.co.jp
O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign

Сценарий атаки

Атакующий запрашивает легитимный сертификат для Web сайта у коммерческого центра сертификации (CA), которому доверяют браузеры. Поскольку запрос является легитимным, CA подписывает сертификат и выдает его злоумышленнику. Для атаки используется CA, который использует алгоритм MD5 для генерации подписей для сертификатов. Второй сертификат - сертификат посредника центра сертификации, который можно использовать для выдачи сертификатов для других сайтов. Поскольку MD5 хеши обоих сертификатов – действительного и фальшивого – одинаковые, цифровая подпись, полученная от коммерческого CA, может быть просто скопирована в фальшивый CA сертификат, который будет оставаться действительным.

Ниже приведена схематическая диаграмма того, как должны работать сертификаты для Web сайтов и описание:

Центр сертификации выпускает свой корневой сертификат и передает его через производителей браузеров клиентам. Эти корневые сертификаты находятся в «доверенном списке» на системе пользователя. Это означает, что все сертификаты, выданные этим CA, по умолчанию будут доверенными для пользователя.
Компания, которая желает защитить пользователей своего сайта, приобретает сертификат для Web сайта в центре сертификации. Этот сертификат подписывается CA и гарантирует идентичность Web сайта для пользователя.
Когда пользователь желает посетить защищенный Web сайт, браузер запрашивает у Web сервера сертификат. Если подпись будет подтверждена сертификатом CA в списке доверенных сертификатов, сайт будет загружен в браузер и обмен данными между сайтом и браузером будет происходить с использованием шифрования.

Следующая диаграмма демонстрирует сценарий атаки с подменой существующего Web сайта.

Легитимный сертификат для Web сайта приобретается у коммерческого CA (голубой сертификат на диаграмме)
Создается фальшивый CA сертификат (черный на диаграмме). Он содержит туже подпись, что и сертификат, выданный для Web сайта, поэтому, браузер полагает, что этот сертификат был выдан действительным CA.
С помощью фальшивого CA, злоумышленник создает и подписывается новый сертификат для Web сайта (красный на диаграмме) с новым публичным ключом. Создается копия доверенного сайта, размещается на Web сервере с фальшивым сертификатом.

Когда пользователь посещает защищенный сайт, браузер осуществляет поиск Web сайта. Существуют различные способы, с помощью которых злоумышленник может перенаправить пользователя на специально сформированный Web сайт. Этот Web сайт предоставит пользователь фальшивый сертификат, совместно с фальшивым CA сертификатом. Подлинность фальшивого сертификата для Web сайта подтверждается фальшивым CA сертификатом, который, в свою очередь, будет подтвержден коневым CA сертификатом. Браузер согласится принять такой сертификат и пользователь ничего не заметит.

Векторы атаки

Злоумышленник может осуществить атаку типа «человек посредине» и перехватить трафик целевого пользователя. Возможные векторы атак:

Атака по локальной сети:

Небезопасные беспроводные сети
ARP спуфинг
Автоматическое обнаружение прокси серверов

Удаленная атака:

DNS спуфинг
Компрометация маршрутизатора

Насколько опасна эта уязвимость?

Существующая проблема позволяет создать идеальные фишинговые сайты с действительными SSL сертификатами. Злоумышленник сможет обмануть даже профессионала, выбрав правдоподобное имя для центра сертификации. Имея возможность произвести атаку «человек посередине», злоумышленник сможет, незаметно для пользователя, перенаправить трафик на специально сформированный сервер и получить доступ к потенциально важным данным. Владельцы сайтов, которые используют SSL сертификаты, никак не смогут защитить своих клиентов. Даже если сертификат для Web сайта подписан алгоритмом SHA1, злоумышленник все равно может использовать фальшивый MD5 сертификат.

Какие существуют средства защиты?

На самом деле пользователи не могут сделать многого. Проблема заключается не в браузерах и не в SSL – а в центрах сертификации.

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

Здравствуйте, пользователи Хабра!

Теги: ssl сертификаты, подмена ssl, блокировка сайтов, реестр запрещенных сайтов

Статьи по теме