В данной статье рассматривается сетевая атака Man in the middle в общедоступных сетях Wi-Fi и её возможности. Описываются методы защиты и возможные способы их нейтрализации.
Ключевые слова: MiTM, man in the middle, Wi-Fi, HTTP, HTTPS, SLL, TLS, шифрование
В настоящее время сети Wi-Fi распространены везде. Будь это магазин, кафе, кинотеатр. Бесплатный интернет доступен всем и каждому. Это очень удобно, но есть один нюанс — безопасность передаваемых данных через данную сеть Wi-Fi. Например, зайдя в социальную сеть или в интернет-магазин через общественную сеть можно запросто «отдать» пароли и данные кредитной карты злоумышленнику.
Атака «человек посередине» или «Man in the middle» (MiTM) — вид криптографической атаки, где злоумышленник перехватывает и подменяет сообщения, которыми обмениваются пользователи сети. Данная атака полностью прозрачна для пользователей, то есть ни один из них догадывается о присутствии третьего пользователя между ними.
Суть данной атаки состоит в том, чтобы прослушать канал связи, а позже подменить необходимые данные при передаче другому пользователю, или вовсе извлечь из переданной информации фрагменты, которые будут полезны злоумышленнику.
Большая часть информации в интернете передаётся по протоколу HTTP. HTTP — протокол прикладного уровня передачи. Основой данного протокола является технология «клиент-сервер», то есть предполагается существование:
– потребителей (клиентов), которые инициируют соединение и посылают запрос;
– поставщиков (серверов), которые ожидают соединения для получения запроса и производят необходимые действия.
Ранее, когда вся информация передавалась по протоколу HTTP (до появления защищённого протокола HTTPS), атака MiTM была более распространена. Пакеты, передающиеся через протокол HTTP, не обрабатывались криптографическими методами. Таким образом, любой человек, «встав посередине», мог просмотреть весь трафик, который передавался между двумя пользователями.
Протокол HTTPS эту проблему частично решает. HTTPS — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в защищённом протоколе передаются поверх криптографических протоколов SSL или TLS. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443.
SSL — криптографический протокол, использующий асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации для целостности сообщений.
Таким образом, если злоумышленник попробует осуществить атаку MiTM, то получит зашифрованное сообщение. На первый взгляд это полностью решает проблему при передаче информации в общественных сетях Wi-Fi. Но с течением времени было придумано несколько способов обхода данной защиты.
Самым распространённым способом обойти защищённый протокол HTTPS — переадресация на HTTP. Как уже было сказано ранее, атака «человека посередине» позволяет подменить необходимые данные при передаче. Злоумышленник посылает команду переадресации на HTTP протокол (например, с https://moluch.ru на http://moluch.ru). С помощью данного метода вся информация передаётся открыто и снова доступна для чтения третьим лицам.
Существует два основных метода решения проблемы несанкционированной переадресации:
– принудительный разрыв HTTP сессий;
– принудительная переадресация с HTTP на HTTPS веб-сайтом.
В первом случае пользователь не сможет получить доступ к сайту, если он использует HTTP протокол при соединении. Данный способ действует в ущерб владельцу веб-сайта, так как человек, не знающий таких тонкостей, лучше откажется от услуг компании по причине недоступности сайта. Обычному пользователю не придёт в голову попробовать перейти на соседний протокол HTTPS.
Во втором случае происходит незаметная переадресация с помощью сайтового скрипта на протокол HTTPS без вмешательства пользователя. Данный способ является наиболее эффективным как для клиента, так и для владельца сайта. В данном случае, если производится атака MiTM, то сайт не даст перейти на протокол HTTP. А позже уже выступают в защиту SSL сертификаты.
При посещении веб-сайта через HTTPS протокол браузер проверяет наличие и подлинность SSL сертификата. Если все требования соблюдены, то разрешается вход на сайт. В обратном случае браузер выдаст сообщение, что сайт не является надёжным и SSL сертификат отсутствует, не является подлинным или даже просрочен.
Рис. 1. Случай, когда SSL сертификат отсутствует
Также существует проблема подмены сертификатов SSL руками злоумышленника. Для этого злоумышленнику необходимо получить SSL сертификат от одного из лицензиатов. Но и в этом случае злоумышленника ждёт неудача, так как лицензиаты дорожат своей репутацией и правом на выдачу сертификатов. В следствии чего при подозрительной активности сертификат блокируется.
Таким образом, атака «человек посередине» или «Man in the middle» возможна с достаточным результатом только в том случае, если используется HTTP протокол для передачи информации. В связи с массовым переходом на HTTPS протокол в настоящее время уже бывает сложно найти сайт, который бы не имел SSL сертификат и соединение с ним не было бы защищено. Сайты, где производятся различная авторизация через логин и пароль или электронные платежи, обязаны иметь SSL сертификат для защиты передаваемой информации. На сегодняшний день невозможно найти веб-сайт такого типа на HTTP протоколе.
В связи с этим данную атаку нельзя считать актуальной. Сидя в кафе или кинотеатре, шанс того, что можно будет перехватить данные, имеющие ценность для злоумышленника (например, логины и пароли), близится к нулю за счёт того, что сейчас уже многие социальные сети перешли на защищённое соединение. Значит ли это то, что обычный пользователь может не волноваться за передаваемые данные в общественной сети Wi-Fi? Возможно, но есть и другие видны атак, а фантазия злоумышленников безгранична. Никогда не стоит быть полностью уверенным в своей безопасности.
Литература:
1. ARP-Spoofing // Википедия — URL: https://ru.wikipedia.org/wiki/ARP-spoofing
2. Атака посредника // Википедия — URL: https://ru.wikipedia.org/wiki/Атака_посредника
3. SSL // Википедия — URL: https://ru.wikipedia.org/wiki/SSL
4. Принудительный разрыв HTTP сессий при MiTM // Википедия — URL: https://habrahabr.ru/post/151696/
