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

Spread the love

ВНИМАНИЕ!!!! АВТОР ДАННОЙ СТАТЬИ НЕ НЕСЕТ ОТВЕТСТВЕННОСТИ ЗА ЛЮБЫЕ ДЕЙСТВИЯ ОТ ЕЕ ПРОЧТЕНИЯ. ВСЕ МАТЕРИАЛЫ ПРЕДОСТАВЛЕНЫ В ИСКЛЮЧИТЕЛЬНО ОБРАЗОВАТЕЛЬНЫХ ЦЕЛЯХ!

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

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

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

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

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

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

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

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

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

Для выполнения атаки человек-посередине будем использовать bettercap.

Запускаем 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 аутентификация, переданная строка — это имя пользователя и пароль от прокси сервера, закодированные в 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 аутентификацию

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

При Digest аутентификации пароль никогда не передаётся в виде простого текста. Но при этом нужно помнить, что в Digest аутентификации в виде простого текста передаются хеши и другие данные, перехватив которые можно запустить брут-форс пароля. Поэтому пароль должен быть достаточно сложным.

2. Вместо прокси-сервера используйте VPN

Как вы могли увидеть на скриншотах выше, узлы, через которые проходит ваш трафик (например, ваш Интернет-провайдер) могут видеть достаточно много из отправляемых вами запросов. Данная проблема решается только полным шифрованием трафика, которое может обеспечить VPN. При использовании VPN, наблюдатель может видеть только поток зашифрованных, абсолютно нечитаемых данных между вашим компьютером и VPN сервером.

Для аутентификации VPN сервера используют ключи и механизм, препятствующий перехвату учётных данных пользователей.

Добавить комментарий

WP2Social Auto Publish Powered By : XYZScripts.com