Атаки на прокси-сервер

Можно ли взломать прокси?

Прокси довольно популярны среди пользователей, особенно среди желающих скрыть свой реальный IP адрес или обойти блокировки доступа к веб-ресурсу (со стороны владельца или со стороны государственной цензуры).

Связанная статья: Настройка программ и операционных систем для работы через прокси

При этом бездумное использование прокси может привести к неожиданному для вас результату. Например, из статьи «Всё о прокси: виды, как пользоваться, как проверить качество прокси» вы должны были узнать, что имеются прокси, которые по определению не являются анонимными — они отправляют IP адрес пользователя в HTTP заголовках.

В статье «Как создать и настроить прокси-сервер Squid» мы научились настраивать свои собственные прокси сервера, с контролем доступа по паролю и/или по IP адресу. Может возникнуть вопрос, насколько защищён передаваемый пароль прокси-сервера? Если пароль можно перехватить и/или расшифровать, то это может привести к тому, что вашим прокси-сервером будут пользоваться посторонние лица.

Забегаю вперёд скажу — с передаваемым паролем всё очень плохо, он передаётся практически в виде простого текста. Поможет ли использование HTTPS прокси-сервера в проблеме защиты пароля? Какие ещё атаки возможны в отношении прокси сервера? Забегая вперёд скажу — всё плохо. Поэтому если вы настраиваете свои прокси-серверы, то вам стоит прочитать эту заметку и принять меры.

Если совсем коротко, то все проблемы с безопасностью прокси-серверов восходят к Basic и Digest аутентификации, которая обычно на них и применяется; и HTTPS прокси в этом плане ничуть не безопаснее. Поэтому начать рекомендуется со статьи «Атаки на HTTP Basic и Digest аутентификацию».

Атака человек-посередине против прокси

Задача: проверить, насколько прокси-сервер подвержен перехвату пароля, а также проверить, насколько HTTPS прокси безопаснее. Проверить возможность понижение подключения через прокси-сервер с HTTPS до HTTP.

Для этого выполним атаку человек-посередине в отношении тестового компьютера, на котором пользователь использует веб-браузер выполняющий подключения через прокси-сервер. Аналогичные риски, возникающие при атаке человек-посередине, могут быть при использовании публичных Точек Доступа; Точек Доступа без паролей; на выходных нодах сети Tor, записывающих трафик; при прохождении трафика через любые сетевые узлы, ищущие незашифрованные данные, в том числе через узлы Интернет-провадеров.

Итак, чтобы увидеть разницу, на тестовой машине веб-браузер настроен использовать только HTTP прокси (а HTTPS запросы уходят напрямую и нас не интересуют).

Для выполнения атаки человек-посередине будем использовать bettercap. Смотрите также статью «Новая версия bettercap 2.x: как установить и использовать в Kali Linux».

Запускаем bettercap:

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

На веб-сервере используется Basic аутентификация, из статьи «Атаки на HTTP Basic и Digest аутентификацию» вы можете помнить, что переданная строка — это имя пользователя и пароль от прокси сервера, закодированные в Base64.

Для декодирования используем следующую команду:

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 аутентификацию

Если вы самостоятельно настраиваете прокси-сервер (смотрите статью «Как создать и настроить прокси-сервер Squid»), то не используйте HTTP Basic аутентификацию, вместо неё используйте HTTP Digest аутентификацию.

При 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"

Смотрите также: Фильтры Wireshark

Онлайн брут-форс учётных данных прокси-сервера

Для подбора логина и пароля применимы методы, описанные для Basic и Digest, поэтому подробности смотрите в разделе: Брут-форс HTTP Basic и Digest аутентификаций.

Взлом хеша пароля прокси-сервера

Методы взлома хешей прокси-сервера применяются такие же, как описаны для Basic и Digest:

Опасно ли пользоваться чужими прокси?

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

Во-первых, все передаваемые в открытом виде данные видны владельцу прокси. Именно таким нехитрым способом были собраны многие базы паролей от социальных сетей. Сейчас, когда многие сайты перешли на HTTPS, злоумышленникам из передаваемых данных видны только: 1) имя хоста, на который делается запрос; 2) IP адрес пользователя, сделавшего запрос. И опять же, данные передаваемые в виде простого текста, видны полностью.

Во-вторых, незашифрованный трафик, передаваемый через чужой прокси, может быть модифицирован любым образом: вставка рекламы, выполнение атак и прочее.

Кстати, всё сказанное в этом разделе относится и к платным прокси-серверам (если вы заплатили кому-то за прокси, то это не означает, что он не может фильтровать пароли из вашего трафика или просто интересоваться, чем вы занимаетесь).

И к публичным (да и платным тоже) VPN серверам это также относится в полной мере. В комментариях к одной из статей меня пытались убедить, что «VPN трафик зашифрован». Да, он зашифрован, ровно до того момента, когда идёт к VPN серверу, а на VPN сервере он расшифровывается. И всё, что передаётся в виде простого текста, доступно VPN серверу для анализа и извлечения паролей и других данных.

Пользуясь чужими прокси и VPN нужно понимать, что их главными «поставщиками» являются хакеры, фильтрующие интересные данные из вашего трафика, и специалисты по информационной безопасности, изучающие методы атаки хакеров и их цели.

Если вы платите за прокси или VPN, это не означает, что всё выше сказанное не может происходить и на них, что бы там ни было написано в пользовательском соглашении.

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность