Атаки на прокси-сервер
Прокси довольно популярны среди пользователей, особенно среди желающих скрыть свой реальный IP адрес или обойти блокировки доступа к веб-ресурсу (со стороны владельца или со стороны государственной цензуры).
При этом бездумное использование прокси может привести к неожиданному для вас результату.
Забегаю вперёд скажу — с передаваемым паролем всё очень плохо, он передаётся практически в виде простого текста. Поможет ли использование HTTPS прокси-сервера в проблеме защиты пароля? Какие ещё атаки возможны в отношении прокси сервера? Забегая вперёд скажу — всё плохо. Поэтому если вы настраиваете свои прокси-серверы, то вам стоит прочитать эту заметку и принять меры.
Если совсем коротко, то все проблемы с безопасностью прокси-серверов восходят к Basic и Digest аутентификации, которая обычно на них и применяется; и HTTPS прокси в этом плане ничуть не безопаснее.
Атака человек-посередине против прокси
Задача: проверить, насколько прокси-сервер подвержен перехвату пароля, а также проверить, насколько HTTPS прокси безопаснее. Проверить возможность понижение подключения через прокси-сервер с HTTPS до HTTP.
Для этого выполним атаку человек-посередине в отношении тестового компьютера, на котором пользователь использует веб-браузер выполняющий подключения через прокси-сервер. Аналогичные риски, возникающие при атаке человек-посередине, могут быть при использовании публичных Точек Доступа; Точек Доступа без паролей; на выходных нодах сети Tor, записывающих трафик; при прохождении трафика через любые сетевые узлы, ищущие незашифрованные данные, в том числе через узлы Интернет-провадеров.
Итак, чтобы увидеть разницу, на тестовой машине веб-браузер настроен использовать только HTTP прокси (а HTTPS запросы уходят напрямую и нас не интересуют).
sudo bettercap
Смотрим имеющиеся устройства в локальной сети и запускаем их автоматическое обнаружение:
net.show net.probe on net.show
Тестовый компьютер имеет IP адрес 192.168.1.34, запускаем в отношении него атаку ARP-спуфинг, благодаря которой компьютер-жертва будет считать, что теперь шлюзом (роутером) является машина атакующего и обмен трафика теперь будет происходить для компьютера жертвы через компьютер атакующего:
set arp.spoof.targets 192.168.1.34 arp.spoof on
Настроем сохранение трафика в файл http-proxy.pcap (для последующего анализа) и запустим снифинг:
set net.sniff.output /home/mial/http-proxy.pcap net.sniff on
Дождёмся, когда на тестовом компьютере будет открыт любой сайт через прокси сервер.
Откроем файл http-proxy.pcap в Wireshark и воспользуемся следующим фильтром:
http.proxy_authorization
Можно увидеть строку, переданную как простой текст:
Proxy-Authorization: Basic cHJveHlfdXNlcjpMa2RmTGw1a2o3TGVn\r\n
Для декодирования используем следующую команду:
echo cHJveHlfdXNlcjpMa2RmTGw1a2o3TGVn | base64 -d
proxy_user:LkdfLl5kj7Leg
В этой строке proxy_user — это имя пользователя, а LkdfLl5kj7Leg — это пароль от прокси-сервера. То есть не смотря на сложность пароля, его очень легко перехватить и расшифровать.
Теперь на тестовом компьютере в веб-браузере мы удаляем настройки HTTP прокси и включаем HTTPS прокси. Идея в том, что HTTPS подразумевает зашифрованные соединения и, возможно, пароль не будет передаваться в открытом виде.
Настраиваем сохранять захваченный трафик в файл https-proxy.pcap, для этого перезапускаем сниффинг:
net.sniff off set net.sniff.output /home/mial/https-proxy.pcap net.sniff on
Откроем файл https-proxy.pcap в Wireshark и вновь воспользуемся фильтром:
http.proxy_authorization
Как видно по сркиншоту, HTTPS прокси также передаёт пароль в виде простого текста.
Разница между HTTP и HTTPS прокси есть, но только не в процессе аутентификации — в любом случае пароль передаётся в виде простого текста.
Чтобы наглядно увидеть разницу между HTTP и HTTPS прокси, воспользуемся фильтрами bettercap. В Wireshark вы можете увидеть строку:
Transmission Control Protocol, Src Port: 54882, Dst Port: 18008, Seq: 1060, Ack: 13141, Len: 414
То есть порт прокси-сервера 18008. На скриншотах выше вы можете увидеть и IP адрес прокси-сервера.
Чтобы отфильтровать только запросы через прокси сервер, установим соответствующий фильтр (для того, чтобы настройка вступила в силу, необходимо перезапустить снифинг):
net.sniff off set net.sniff.filter "host 157.245.118.66 and port 18008" net.sniff on
Это запрос через HTTP прокси-сервер:
То есть атакующему видно всё — какие данные передаются и какие получаются, кукиз, логины и пароли — абсолютно всё.
А это запрос через HTTPS прокси-сервер:
То есть атакующему из передаваемых данных видны только название удалённого хоста и User-Agent пользователя, остальные данные передаются зашифрованными.
Но в любом случае, в каждом запросе передаётся строка, содержащая логин и пароль от прокси, которые может перехватить атакующий:
Proxy-Authorization: Basic cHJveHlfdXNlcjpMa2RmTGw1a2o3TGVn
То есть в понижении подключения через прокси-сервер с HTTPS до HTTP для перехвата пароля от прокси нет никакой необходимости.
Для правильной остановки атаки выполните команды:
net.sniff off arp.spoof off exit
Как защититься от перехвата логина и пароля прокси-сервера
1. Никогда не используйте Basic аутентификацию
При Digest аутентификации пароль никогда не передаётся в виде простого текста. Но при этом нужно помнить, что в Digest аутентификации в виде простого текста передаются хеши и другие данные, перехватив которые можно запустить брут-форс пароля. Поэтому пароль должен быть достаточно сложным.
2. Вместо прокси-сервера используйте VPN
Как вы могли увидеть на скриншотах выше, узлы, через которые проходит ваш трафик (например, ваш Интернет-провайдер) могут видеть достаточно много из отправляемых вами запросов. Данная проблема решается только полным шифрованием трафика, которое может обеспечить VPN. При использовании VPN, наблюдатель может видеть только поток зашифрованных, абсолютно нечитаемых данных между вашим компьютером и VPN сервером.
Для аутентификации VPN сервера используют ключи и механизм, препятствующий перехвату учётных данных пользователей.
Фильтры Wireshark для анализа трафика через веб прокси-сервер
Поскольку «прокси» это обобщённое название множества технологий и ПО, то не все фильтры Wireshark в названии которых присутствует слово «proxy» применимы для веб-прокси.
К примеру, страница с фильтрами для протокола PROXY https://www.wireshark.org/docs/dfref/p/proxy.html содержит фильтры, ни один из которых не применим к веб-прокси.
Страница https://www.wireshark.org/docs/dfref/s/socks.html содержит фильтры для SOCKS-прокси, также не применимые для веб-прокси.
Эти два фильтра, хотя и должны (судя по названию) иметь отношение к HTTP прокси, но в моих тестах ничего не находили:
http.proxy_connect_host http.proxy_connect_port
Рассмотрим фильтры Wireshark для анализа трафика через веб прокси-сервер (HTTP и HTTPS прокси).
Этот фильтр покажет запросы от прокси на HTTP Digest аутентификацию:
http.proxy_authenticate
Этот фильтр покажет учётные данные, отправляемые клиентом на прокси-сервер для авторизации:
http.proxy_authorization
Показ запросов, сделанных через прокси-сервер (HTTP метод CONNECT):
http.request.method == "CONNECT"
Поскольку для аутентификации пользователей веб-прокси используют HTTP Basic и Digest аутентификации, то можно использовать соответствующие фильтры Wireshark. Все сессии аутентификации (BASIC/DIGEST/NTLM):
http.authorization
Только HTTP Basic аутентификация:
http.authbasic
Только HTTP Basic аутентификация с определёнными учётными данными:
http.authbasic == "ЛОГИН:ПАРОЛЬ"
Запрос Digest аутентификации от прокси-сервера:
http.proxy_authenticate contains "Digest"
Ответ пользователя передаваемый на прокси-сервер с информацией для Digest авторизации:
http.proxy_authorization contains "Digest"
Опасно ли пользоваться чужими прокси?
Если вы используетесь прокси-серверами от «добрых людей», чьи IP и номер порта просто нашли в Интернете, то вам нужно совершенно точно понимать риски этого.
Во-первых, все передаваемые в открытом виде данные видны владельцу прокси. Именно таким нехитрым способом были собраны многие базы паролей от социальных сетей. Сейчас, когда многие сайты перешли на HTTPS, злоумышленникам из передаваемых данных видны только: 1) имя хоста, на который делается запрос; 2) IP адрес пользователя, сделавшего запрос. И опять же, данные передаваемые в виде простого текста, видны полностью.
Во-вторых, незашифрованный трафик, передаваемый через чужой прокси, может быть модифицирован любым образом: вставка рекламы, выполнение атак и прочее.
Кстати, всё сказанное в этом разделе относится и к платным прокси-серверам (если вы заплатили кому-то за прокси, то это не означает, что он не может фильтровать пароли из вашего трафика или просто интересоваться, чем вы занимаетесь).
И к публичным (да и платным тоже) VPN серверам это также относится в полной мере. В комментариях к одной из статей меня пытались убедить, что «VPN трафик зашифрован». Да, он зашифрован, ровно до того момента, когда идёт к VPN серверу, а на VPN сервере он расшифровывается. И всё, что передаётся в виде простого текста, доступно VPN серверу для анализа и извлечения паролей и других данных.
Пользуясь чужими прокси и VPN нужно понимать, что их главными «поставщиками» являются хакеры, фильтрующие интересные данные из вашего трафика, и специалисты по информационной безопасности, изучающие методы атаки хакеров и их цели.
Если вы платите за прокси или VPN, это не означает, что всё выше сказанное не может происходить и на них, что бы там ни было написано в пользовательском соглашении.