Обход HSTS с помощью sslstrip+ и dns2proxy

Я пытаюсь понять, как обойти защиту HSTS. Я читал об инструментах от LeonardoNve ( https://github.com/LeonardoNve/sslstrip2 и https://github.com/LeonardoNve/dns2proxy ). Но я совсем не понимаю.

  • Если клиент впервые запрашивает сервер, он будет работать в любое время, потому что sslstrip просто удалит поле заголовка Strict-Transport-Security:. Итак, мы вернулись к старому делу с оригинальным sslstrip.

  • Если не ... ? Что случается ? Клиент знает, что он должен взаимодействовать с сервером только по HTTPS, поэтому он автоматически попытается подключиться к серверу по HTTPS, нет? В таком случае MitM бесполезен... >‹

Глядя на код, я как бы понимаю, что sslstrip2 изменит доменное имя ресурсов, необходимых клиенту, поэтому клиенту не придется использовать HSTS, поскольку эти ресурсы не находятся в одном домене (это правда?). Клиент отправит DNS-запрос, который инструмент dns2proxy перехватит и отправит обратно IP-адрес для реального доменного имени. В конце клиент просто HTTP-запросит ресурсы, которые он должен был сделать по протоколу HTTPS.

Пример . Из ответа сервера клиент должен загрузить mail.google.com. Злоумышленник изменил его на gmail.google.com, так что это не тот же (дочерний) домен. Затем клиент запросит DNS для этого домена, dns2proxy ответит реальным IP-адресом mail.google.com. Затем клиент просто запросит этот ресурс через HTTP.

Чего я не понимаю, так это до этого ... Как злоумышленник может html-strip, в то время как соединение должно быть HTTPS от клиента к серверу ...?

Кусочка не хватает... :с

Спасибо


http ssl https man-in-the-middle hsts
person Nikkolasg    schedule 28.03.2015    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Хорошо, после просмотра видео я стал лучше понимать возможности инструмента dns2proxy. Из того, что я понял:

  • Большинство пользователей попадут на страницу HTTPS либо по ссылке, либо по перенаправлению. Если пользователь напрямую получает версию HTTPS, атака завершается неудачно, потому что мы не можем расшифровать трафик без сертификата сервера.
  • In the case of a redirection or link with sslstrip+ + dns2proxy enabled with us being in the middle of the connection .. mitm ! ==>
    • The user goes on google.com
    • злоумышленник перехватывает трафик с сервера на клиент и меняет ссылку для входа с "https://account.google.com" на "http://compte.google.com".
    • Браузер пользователя сделает DNS-запрос к «compte.google.com».
    • злоумышленник перехватывает запрос, делает настоящий DNS-запрос на настоящее имя «account.google.com» и отправляет обратно пользователю ответ «поддельное доменное имя + настоящий IP».
    • Когда браузер получит ответ DNS, он будет искать, должен ли этот домен быть доступен по HTTPS. Проверив предварительно загруженный список доменов HSTS или увидев уже посещенный домен, который находится в кеше или для сеанса, не знаю. Поскольку домен не является реальным, браузер просто установит HTTP-соединение с РЕАЛЬНЫМ адресом ip. ==> HTTP-трафик в конце ;)

Таким образом, реальные ограничения по-прежнему заключаются в том, что для этого необходимы непрямые HTTPS-ссылки. Иногда браузер напрямую «перепечатывает» URL-адрес, введенный в ссылку HTTPS.

Ваше здоровье !

person Nikkolasg    schedule 30.03.2015
comment
Еще одна серьезная проблема — кеширование 301 редиректа. Когда пользователь вводит target.com, браузер пытается запросить http://target.com, а затем в автономном режиме перенаправляется на https://www.target.com с помощью старого кэшированного перенаправления 301 (сохраненного при первом доступе), и этот кэш не имеет срока действия. Таким образом, единственным возможным решением будет ручная очистка кеша на компьютере жертвы. Проверьте мой обход HTTP-кэшированного HTTPS-перенаправления 301 на используйте SSLstrip вопрос. - person Bruno; 24.12.2015