Возможно ли сделать прозрачную MITM атаку (без промежуточного ip)?



@vebmaster

Здравствуйте.
Имеется 3 разных физических компьютера/сервера:
1) Компьютер и Браузер пользователя (ip адрес 1.1.1.1)
2) Веб-сервер (ip адрес 2.2.2.2)
3) компьютер MITM-атакующего (ip адрес 3.3.3.3), который находится между браузером и веб-сервером.

Стандартная MITM атака на HTTPS соединение подразумевает открытие сайта уже не с ip веб-сервера 2.2.2.2, а с ip атакующего 3.3.3.3. В результате чего в браузере отобразится сообщение, что корневой сертификат неизвестен.

Вопрос: возможна ли прозрачная MITM атака (например изменение содержимого страницы), как будто MITM-атакующего нету? Т.е. веб-браузер подключается как и положено к веб-серверу с ip адресом 2.2.2.2, но атакующий полностью пропускает трафик через себя.


Решения вопроса 2



@CityCat4 Куратор тега Информационная безопасность

Возможна 🙂

Вы описали сценарий работы корпоративного прокси с бампингом 🙂 Правда, для его работы нужно одно, но крайне существенное условие – на компьютере 1.1.1.1 в доверенных корневых сертификатах должен находиться сертификат/CA сертификата, который будет использоваться на 3.3.3.3

Иначе не получится нифига, потому что у Вас нету сессионного ключа, Вы не сможете “подделать” соединение между клиентом и Вами.

https как раз и придуман для того, чтобы отсеивать таких вот хитрожопых и требование по установке “госсертификатов” – оно вовсе недаром энфорсится – потому что без него никак.

Комментировать

Ответы на вопрос 2



@rPman

https как раз и создан как защита от подобных атак

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

Еще – атака через смену браузера на стороне клиента (всеми способами тебе ‘впаривается’ новый браузер, типа как это делает яндекс или как это уже сделал гугл со всем миром) тут уже порядок обработки и контроля шифрованного соединения на совести браузера (например можно логировать ключи шифрования каждой сессии, в этом случае логирование шифрованных дампов у провайдера плюс эти ключи позволят их как минимум расшифровывать, ну для подмены данных этот способ неудобен)



@gbg

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

Браузер клиента увидит или левый сертификат, или внезапный перепрыг с HTTPS на HTTP и начнет ругаться.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *