Атаки на прокси-сервер
Внимание: бездумное использование прокси может привести к неожиданному для вас результату.
Всем салют, дорогие друзья!
Прокси популярны не только в теневой сфере, но и среди обычных пользователей, желающих скрыть свой реальный 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
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 подразумевает зашифрованные соединения и, возможно, пароль не будет передаваться в открытом виде.
net.sniff off set net.sniff.output /home/имя_пользователя/https-proxy.pcap net.sniff on
http.proxy_authorization
Разница между 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
То есть атакующему видно всё — какие данные передаются и какие получаются, кукиз, логины и пароли — абсолютно всё.
Атакующему из передаваемых данных видны только название удалённого хоста и User-Agent пользователя, остальные данные передаются зашифрованными.
- Но в любом случае, в каждом запросе передаётся строка, содержащая логин и пароль от прокси, которые может перехватить атакующий:
Proxy-Authorization: Basic cHJveHlfdXNlcjpMa2RmTGw1a2o3TGVn
То есть в понижении подключения через прокси-сервер с HTTPS до HTTP для перехвата пароля от прокси нет никакой необходимости.
Как защититься от перехвата логина и пароля прокси-сервера
1. Никогда не используйте Basic аутентификацию
При Digest аутентификации пароль никогда не передаётся в виде простого текста. Но при этом нужно помнить, что в Digest аутентификации в виде простого текста передаются хеши и другие данные, перехватив которые можно запустить брут-форс пароля. Поэтому пароль должен быть достаточно сложным.
2. Вместо прокси-сервера используйте VPN
Как вы могли увидеть на скриншотах выше, узлы, через которые проходит ваш трафик (например, ваш Интернет-провайдер) могут видеть достаточно много из отправляемых вами запросов. Данная проблема решается только полным шифрованием трафика, которое может обеспечить VPN. При использовании VPN, наблюдатель может видеть только поток зашифрованных, абсолютно нечитаемых данных между вашим компьютером и VPN сервером.
Для аутентификации VPN сервера используют ключи и механизм, препятствующий перехвату учётных данных пользователей.
Напомню, что если вы решили использовать VPN в своей цепочки анонимности, то лучшим решением будет поднять свой. В первом пункте этой статьи я пошагово описал, как это сделать:
Опасно ли пользоваться чужими прокси?
Если вы используетесь прокси-серверами от «добрых людей», чьи IP и номер порта просто нашли в Интернете, то вам нужно совершенно точно понимать риски этого.
Во-первых, все передаваемые в открытом виде данные видны владельцу прокси. Именно таким нехитрым способом были собраны многие базы паролей от социальных сетей. Сейчас, когда многие сайты перешли на HTTPS, хакерам из передаваемых данных видны только: 1) имя хоста, на который делается запрос; 2) IP адрес пользователя, сделавшего запрос. И опять же, данные передаваемые в виде простого текста, видны полностью.
Во-вторых, незашифрованный трафик, передаваемый через чужой прокси, может быть модифицирован любым образом: вставка рекламы, выполнение атак и прочее.
Кстати, всё сказанное в этом разделе относится и к платным прокси-серверам (если вы заплатили кому-то за прокси, то это не означает, что он не может фильтровать пароли из вашего трафика или просто интересоваться, чем вы занимаетесь).
И к публичным (да и платным тоже) VPN серверам это также относится в полной мере. В комментариях к одной из статей меня пытались убедить, что «VPN трафик зашифрован». Да, он зашифрован, ровно до того момента, когда идёт к VPN серверу, а на VPN сервере он расшифровывается. И всё, что передаётся в виде простого текста, доступно VPN серверу для анализа и извлечения паролей и других данных.
Если вы платите за прокси или VPN, это не означает, что всё выше сказанное не может происходить и на них, что бы там ни было написано в пользовательском соглашении.
На сегодня это все. Берегите себя!
