Создание фальшивых SSL сертификатов или новогодний подарок для фишеров. Easy Hack: Хакерские секреты простых вещей Компании, выпускающие уязвимые сертификаты

Чтобы убедиться в отсутствии перешифровки https-трафика антивирусными программами или proxy, воспользуйтесь одним из способов ниже:

1. Зайдите на портал диагностики, в раздел « Проверка связи» (https://help.kontur.ru/check). Если в одной из строчек не стоит галочка, а значение в столбике « Сертификат» подсвечено красным, то происходит подмена сертификата. Название программы, подменяющей сертификат, указано в графе «Издатель».

2. Зайдите на сайт https://auth.kontur.ru , нажмите левой кнопкой мыши по значку «замкА» (возле адресной строки) либо правой кнопкой мыши на странице > Свойства > Сертификаты и проверьте, какой сертификат сервера предлагается. Сертификат должен быть таким:

• Кому выдан: *.kontur.ru
• Кем выдан: RapidSSL SHA256 CA
• Серийный номер: 48 61 59 21 53 c2 cf cd e2 0c f8 ec 70 a1 9d 67

или таким:

• Кому выдан: *.kontur.ru
• Кем выдан: GlobalSign Domain Validation CA — SHA256 — G2
• Серийный номер: 13 0b ab d5 ec ff a6 f0 71 ae 5a 36

Если сертификат другой, значит происходит перешифровка https-трафика. Название программы, подменяющей сертификат, указано в строке «Кем выдан».

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

Антивирус Avast

Отключите активную защиту для https-сайтов. Для этого кликните правой кнопкой мыши по значку Avast, который находится в области уведомлений, и выберите пункт «Открыть интерфейс пользователя Avast».

Перейдите в Меню > Настройки.

Выберите раздел Защита > Основные компоненты защиты > Веб-защита.

Снимите галочки со следующих пунктов:

• Включить сканирование HTTPS;
• Включить сканирование скриптов.

Антивирус ESET Internet Security

Отключите фильтрацию https-протоколов в ESET Internet Security . Для этого откройте ESET > Настройка > Расширенные параметры.

Перейдите в раздел Интернет и электронная почта > Защита доступа в интернет > Веб-протоколы > Настройка модуля > снимите галочку с пункта «Включить проверку протокола HTTPS».

Антивирус Kaspersky Internet Security

В зависимости от версии Касперского некоторые элементы интерфейса могут отличаться.

1. Отключите надстройки Kaspersky Internet Security. Для этого в Internet Explorer выберите вкладку Сервис > Настроить надстройки.

В разделе «Отображать» выберите пункт «Все надстройки». Найдите в списке надстройки Kaspersky Protection и Kaspersky Protection Toolbar, щелкните по строке правой кнопкой мыши и выберите пункт «Отключить».

2. Отключите внедрение скриптов Касперского и проверку защищенных соединений. Для этого откройте Kaspersky Internet Security > Настройки > Дополнительно > Сеть > Внедрять в трафик скрипт для взаимодействия с веб-страницами.

3. Откройте Kaspersky Internet Security > Настройки > Защита > Веб-Антивирус (или Веб-Защита).

Откройте Расширенные настройки и отключите «Автоматически активировать расширение Kaspersky Protection в браузерах».

4. Отключите проверку HTTPS-соединений. Для этого Откройте Kaspersky Internet Security > Настройки > Дополнительные параметры> Сеть. В блоке « Проверка защищенных соединений» отключите опцию « Проверять защищенные соединения» .

Антивирус Dr.Web

Отключите проверку HTTPS-соединений. Для этого откройте Dr.Web > Настройка > Основные > Сеть > Безопасные соединения. Установите переключатель « Проверять зашифрованный трафик» в положение « Откл.» .

Программа AdGuard

Отключите проверку HTTPS-соединений. Если в вашем браузере установлено дополнение AdGuard, для него ничего отключать не нужно. Если оно не установлено, то откройте программу «AdGuard » > Настройки > Общие настройки > уберите галочку с пункта «Фильтровать HTTPS протокол ».

AVG Antivirus

Отключите проверку HTTPS-соединений. ​Для этого откройте AVG Antivirus > Настройки > Компоненты > Веб-защита или Online Shield > Настройки > уберите галочку с пункта « Включить сканирование HTTPS».

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

Сегодня я столкнулся с довольно интересным способом «ограждения пользователей от нежелательной информации», а именно - подменой 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 сайтов и описание:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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