Эх, жизнь — хоть за хуй
-
Автор темы
- #1
Прокси довольно популярны среди пользователей, особенно среди желающих скрыть свой реальный IP адрес или обойти блокировки доступа к веб-ресурсу (со стороны владельца или со стороны государственной цензуры).
При этом бездумное использование прокси может привести к неожиданному для вас результату. Вы должны были узнать, что имеются прокси, которые по определению не являются анонимными — они отправляют IP адрес пользователя в HTTP заголовках.
Забегаю вперёд скажу — с передаваемым паролем всё очень плохо, он передаётся практически в виде простого текста. Поможет ли использование HTTPS прокси-сервера в проблеме защиты пароля? Какие ещё атаки возможны в отношении прокси сервера? Забегая вперёд скажу — всё плохо. Поэтому если вы настраиваете свои прокси-серверы, то вам стоит прочитать эту заметку и принять меры.
Если совсем коротко, то все проблемы с безопасностью прокси-серверов восходят к Basic и Digest аутентификации, которая обычно на них и применяется; и HTTPS прокси в этом плане ничуть не безопаснее.
Задача: проверить, насколько прокси-сервер подвержен перехвату пароля, а также проверить, насколько HTTPS прокси безопаснее. Проверить возможность понижение подключения через прокси-сервер с HTTPS до HTTP.
Для этого выполним атаку человек-посередине в отношении тестового компьютера, на котором пользователь использует веб-браузер выполняющий подключения через прокси-сервер. Аналогичные риски, возникающие при атаке человек-посередине, могут быть при использовании публичных Точек Доступа; Точек Доступа без паролей; на выходных нодах сети Tor, записывающих трафик; при прохождении трафика через любые сетевые узлы, ищущие незашифрованные данные, в том числе через узлы Интернет-провадеров.
Итак, чтобы увидеть разницу, на тестовой машине веб-браузер настроен использовать только HTTP прокси (а HTTPS запросы уходят напрямую и нас не интересуют).
Для выполнения атаки человек-посередине будем использовать bettercap.
Запускаем bettercap:
Смотрим имеющиеся устройства в локальной сети и запускаем их автоматическое обнаружение:
Тестовый компьютер имеет IP адрес 192.168.1.34, запускаем в отношении него атаку ARP-спуфинг, благодаря которой компьютер-жертва будет считать, что теперь шлюзом (роутером) является машина атакующего и обмен трафика теперь будет происходить для компьютера жертвы через компьютер атакующего:
Настроем сохранение трафика в файл http-proxy.pcap (для последующего анализа) и запустим снифинг:
Дождёмся, когда на тестовом компьютере будет открыт любой сайт через прокси сервер.
Откроем файл http-proxy.pcap в
Можно увидеть строку, переданную как простой текст:
На веб-сервере используется Basic аутентификация, что переданная строка — это имя пользователя и пароль от прокси сервера, закодированные в Base64.
Для декодирования используем следующую команду:
Вывод:
В этой строке proxy_user — это имя пользователя, а LkdfLl5kj7Leg — это пароль от прокси-сервера. То есть не смотря на сложность пароля, его очень легко перехватить и расшифровать.
Теперь на тестовом компьютере в веб-браузере мы удаляем настройки HTTP прокси и включаем HTTPS прокси. Идея в том, что HTTPS подразумевает зашифрованные соединения и, возможно, пароль не будет передаваться в открытом виде.
Настраиваем сохранять захваченный трафик в файл https-proxy.pcap, для этого перезапускаем сниффинг:
Откроем файл https-proxy.pcap в Wireshark и вновь воспользуемся фильтром:
Как видно по сркиншоту, HTTPS прокси также передаёт пароль в виде простого текста.
Разница между HTTP и HTTPS прокси есть, но только не в процессе аутентификации — в любом случае пароль передаётся в виде простого текста.
Чтобы наглядно увидеть разницу между HTTP и HTTPS прокси, воспользуемся фильтрами bettercap. В Wireshark вы можете увидеть строку:
То есть порт прокси-сервера 18008. На скриншотах выше вы можете увидеть и IP адрес прокси-сервера.
Чтобы отфильтровать только запросы через прокси сервер, установим соответствующий фильтр (для того, чтобы настройка вступила в силу, необходимо перезапустить снифинг):
Это запрос через HTTP прокси-сервер:
То есть атакующему видно всё — какие данные передаются и какие получаются, кукиз, логины и пароли — абсолютно всё.
А это запрос через HTTPS прокси-сервер:
То есть атакующему из передаваемых данных видны только название удалённого хоста и User-Agent пользователя, остальные данные передаются зашифрованными.
Но в любом случае, в каждом запросе передаётся строка, содержащая логин и пароль от прокси, которые может перехватить атакующий:
То есть в понижении подключения через прокси-сервер с HTTPS до HTTP для перехвата пароля от прокси нет никакой необходимости.
Для правильной остановки атаки выполните команды:
1. Никогда не используйте Basic аутентификацию
Если вы самостоятельно настраиваете прокси-сервер , то не используйте HTTP Basic аутентификацию, вместо неё используйте HTTP Digest аутентификацию.
При Digest аутентификации пароль никогда не передаётся в виде простого текста. Но при этом нужно помнить, что в Digest аутентификации в виде простого текста передаются хеши и другие данные, перехватив которые можно запустить брут-форс пароля. Поэтому пароль должен быть достаточно сложным.
2. Вместо прокси-сервера используйте VPN
Как вы могли увидеть на скриншотах выше, узлы, через которые проходит ваш трафик (например, ваш Интернет-провайдер) могут видеть достаточно много из отправляемых вами запросов. Данная проблема решается только полным шифрованием трафика, которое может обеспечить VPN. При использовании VPN, наблюдатель может видеть только поток зашифрованных, абсолютно нечитаемых данных между вашим компьютером и VPN сервером.
Для аутентификации VPN сервера используют ключи и механизм, препятствующий перехвату учётных данных пользователей.
При этом бездумное использование прокси может привести к неожиданному для вас результату. Вы должны были узнать, что имеются прокси, которые по определению не являются анонимными — они отправляют IP адрес пользователя в HTTP заголовках.
Забегаю вперёд скажу — с передаваемым паролем всё очень плохо, он передаётся практически в виде простого текста. Поможет ли использование HTTPS прокси-сервера в проблеме защиты пароля? Какие ещё атаки возможны в отношении прокси сервера? Забегая вперёд скажу — всё плохо. Поэтому если вы настраиваете свои прокси-серверы, то вам стоит прочитать эту заметку и принять меры.
Если совсем коротко, то все проблемы с безопасностью прокси-серверов восходят к Basic и Digest аутентификации, которая обычно на них и применяется; и HTTPS прокси в этом плане ничуть не безопаснее.
Атака человек-посередине против прокси
Задача: проверить, насколько прокси-сервер подвержен перехвату пароля, а также проверить, насколько HTTPS прокси безопаснее. Проверить возможность понижение подключения через прокси-сервер с HTTPS до HTTP.
Для этого выполним атаку человек-посередине в отношении тестового компьютера, на котором пользователь использует веб-браузер выполняющий подключения через прокси-сервер. Аналогичные риски, возникающие при атаке человек-посередине, могут быть при использовании публичных Точек Доступа; Точек Доступа без паролей; на выходных нодах сети Tor, записывающих трафик; при прохождении трафика через любые сетевые узлы, ищущие незашифрованные данные, в том числе через узлы Интернет-провадеров.
Итак, чтобы увидеть разницу, на тестовой машине веб-браузер настроен использовать только HTTP прокси (а HTTPS запросы уходят напрямую и нас не интересуют).
Запускаем bettercap:
Код:
sudo bettercap
Код:
net.show
net.probe on
net.show
Код:
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 в
Пожалуйста, авторизуйтесь для просмотра ссылки.
и воспользуемся следующим фильтром:http.proxy_authorization
Proxy-Authorization: Basic cHJveHlfdXNlcjpMa2RmTGw1a2o3TGVn\r\n На веб-сервере используется Basic аутентификация, что переданная строка — это имя пользователя и пароль от прокси сервера, закодированные в Base64.
Для декодирования используем следующую команду:
echo cHJveHlfdXNlcjpMa2RmTGw1a2o3TGVn | base64 -d Вывод:
proxy_user:LkdfLl5kj7Leg
В этой строке proxy_user — это имя пользователя, а LkdfLl5kj7Leg — это пароль от прокси-сервера. То есть не смотря на сложность пароля, его очень легко перехватить и расшифровать.
Теперь на тестовом компьютере в веб-браузере мы удаляем настройки HTTP прокси и включаем HTTPS прокси. Идея в том, что HTTPS подразумевает зашифрованные соединения и, возможно, пароль не будет передаваться в открытом виде.
Код:
net.sniff off
set net.sniff.output /home/mial/https-proxy.pcap
net.sniff on 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То есть атакующему видно всё — какие данные передаются и какие получаются, кукиз, логины и пароли — абсолютно всё.
А это запрос через 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 сервера используют ключи и механизм, препятствующий перехвату учётных данных пользователей.
