26 ноября специалисты по безопасности VPN-провайдера Perfect Privacy обнаружили в VPN уязвимость, которая может привести к раскрытию ip-адресов пользователей. Атака работает за счёт перенаправления портов. По заявлениям специалистов, уязвимости подвержены все реализации VPN (протоколы IPSec, OpenVPN, PPTP, и другие), и не зависит от операционной системы.
Для успешного осуществления атаки атакующий должен завести аккаунт у того же VPN-провайдера, что и жертва. Затем необходимо узнать выходной ip-адрес жертвы. Часто у VPN-провайдеров используется небольшой пул выходных адресов – их можно перебирать, заманить жертву на специально созданный веб-сайт, что и выдаст её выходной ip-адрес, или брать адреса из торрентокачалки.
Затем атакующий активирует у себя перенаправление портов – при этом от жертвы не требуется никаких действий, и неважно, работает ли у неё такое перенаправление, или нет. И в заключение, жертве необходимо скормить любой ресурс, в url которого указан порт, на который идёт перенаправление.
Технические детали специалисты приводят следующие:
- У жертвы установлена связь с VPN-сервером 1.2.3.4
- Её таблица роутинга будет примерно такой: 0.0.0.0/0 -> 10.0.0.1 (адрес внутреннего шлюза VPN), 1.2.3.4/32 -> 192.168.0.1 (старый шлюз по-умолчанию)
- Атакующий соединяется с тем же сервером 1.2.3.4, уже зная выходной ip-адрес жертвы
- Он активирует перенаправление портов на сервере 1.2.3.4, например, на порт 12345
- Он заманивает жертву, чтобы та сделала запрос на 1.2.3.4:12345 (например, через включение в страницу кода <img src=http://1.2.3.4:12345/x.jpg>)
- Установленное соединение раскроет IP-адрес жертвы, из-за роутинга “1.2.3.4/32 -> 192.168.0.1”
Суть проблемы в том, что для обеспечения правильной работы VPN, в какой-то момент жертве приходится использовать свой реальный ip-адрес. В Perfect Privacy уже предложили свой вариант решения проблемы, который должны реализовать провайдеры – как на стороне сервера, так и в настройках клиента.
По словам специалистов, из девяти проверенных ими популярных VPN-провайдеров подобная уязвимость была найдена у пяти. Среди них оказались Private Internet Access (PIA), Ovpn.to и nVPN. В PIA уже оперативно исправили проблему, и даже наградили своего конкурента денежным призом в $5000 по программе Whitehat Alert Security Program.
VPN (Virtual Private Network), виртуальная частная сеть – набор технологий, позволяющих обеспечить одно или несколько сетевых соединений поверх другой сети. Уровень доверия к построенной логической сети не зависит от уровня доверия к базовым сетям благодаря использованию шифрования. Чаще всего VPN используют для доступа удалённо работающих сотрудников к корпоративной сети.
Также VPN очень популярен среди любителей скачивать фильмы, музыку и другие не совсем легальный контент из интернета, поскольку он помогает скрыть свой реальный ip-адрес, и шифрует трафик, что затрудняет прослушку канала. Часто у VPN-провайдеров есть несколько серверов в разных странах, благодаря чему VPN помогает обойти и блокировку ресурсов, введённую провайдерами по требованию властей.
Комментарии (19)
ValdikSS
28.11.2015 18:58+3Такая ерунда, а все с ней носятся. Это не уязвимость, тем более не уязвимость VPN. Так работает маршрутизация, только и всего. Я такое 3 года назад проделывал, да и похожая техника используется для DNS Rebinding Attack роутеров, которой тоже не один год.
ValdikSS
28.11.2015 19:04+1Вот, кстати, Android с его VPN API позволяет пускать через VPN в том числе и IP VPN-сервера, не вызывая закольцовывание маршрутизации. И Windows, в некоторых случаях, тоже может работать в таком режиме. На Linux такого поведения тоже можно добиться, используя policy routing.
qw1
28.11.2015 19:38+1Можно сказать, что и sql injection не уязвимость SQL-сервера, а проблема в приложении, которое не экранирует пользовательский ввод. Аналогично с VPN-сервисами — есть дырявые, хотя это не проблема протокола.
Но проблема не очевидна (её до сих пор массово не победили). Если о ней не трубить на каждом углу, N% сервисов так и останутся дырявыми. Как если не напоминать постоянно всем о stack overflow и sql injection, количество ошибок, приводящих к этим уязвимостям, будет сильно выше. Люди ленивы, аккуратно и правильно не будут делать без напоминания.ValdikSS
28.11.2015 20:15Частично согласен, частично нет. Это не проблема ни VPN-сервисов, ни VPN-серверов, ни протокола, это особенность работы сетевой маршрутизации. Ее нужно исправлять на клиенте, а не на сервере (хотя и на сервере ее исправить возможно).
Проблеме утечки DNS в Windows 8.1 и 10 как-то меньше внимания уделили, хотя ее заметно проще эксплуатировать массово.
Вот вам еще одна «уязвимость», которая не уязвимость, а особенность работы маршрутизации и сетевого стека, эксплуатирующая схожий принцип работы сети, описанный в статье, о которой, я надеюсь, знает каждый сетевой администратор, в том числе и администраторы VPN-сервисов, на примере BitTorrent-раздачи и слежения средствами правообладателей:
- У пользователя запущен BitTorrent-клиент, порт на маршрутизаторе открыт (статически или через UPnP, неважно)
- Правообладатели, которые следят за пирами на раздачах (в США и Германии это повсеместно) ловят связки IP: порт с торрент-трекеров и DHT
- Правообладатели массово отправляют UDP-пакеты торрент-клиентам на порты, которые поймали ранее, на все маршрутизируемые IPv4-адреса (это занимает считанные минуты, даже не десятки минут, для TCP через masscan на 10G канале, для UDP должно быть еще быстрее)
- Клиенты, будучи подключенными к VPN, получают пакет на реальный интерфейс, а ответ отправляют с VPN-адреса
- ???
- PROFIT!
Уязвимость ли это VPN? Определенно нет, это особенность маршрутизации. Можно ли ее исправить на стороне VPN-сервера? Нет, только на клиенте. Можно ли эксплуатировать массово? В какой-то степени, да, в отличие от описанного в статье способа, где нужно эксплуатировать конкретный VPN-сервер у конкретного VPN-сервиса.
Где мне забрать мои $5000?qw1
28.11.2015 20:26+1Это ошибка конфигурации. Можно ли назвать её уязвимостью? Спорный вопрос, но рассказывать о ней надо почаще, чтобы эти ошибки делали реже.
ComodoHacker
28.11.2015 20:29SLY_G, в каком именно «протоколе» уязвимость? VPN протоколов множество, как вы понимаете, и ни в одном из них уязвимости нет. Уязвимость в конфигурации VPN сервера. В оригинале нигде не говорится об «уязвимости в протоколе». Исправьте, пожалуйста. Нам тут желтизны и так хватает, не надо больше.
agranom555
28.11.2015 21:29Если у меня VPN сервер свой, то мне это не грозит? Ведь только я к нему подключаюсь.
Aclz
28.11.2015 23:01В этом случае (с учетом допущений, принятых в статье) ваш выходной IP и так однозначно отображается на вас и только на вас.
J_o_k_e_R
29.11.2015 00:54+2Всегда использовал только свой VPN сервис. Долго думал как может клиент VPN открыть порт на VPN сервере. Это ж ssh надо, к тому же с рут-доступом.
Я правильно понимаю, что VPN сервисы некоторые сами дают возможность через какой-то интерфейс открывать на сервере переадресацию портов на внтуренние адреса? Так это просто корявая конфигурация на стороне сервера всего лишь. Какая ж это уязвимость?qw1
29.11.2015 01:10VPN сервисы сами дают возможность через какой-то интерфейс открывать на сервере переадресацию портов?
Конечно, это очень полезная услуга. DHT в разных файлообменных программах требует какой-либо открытый порт. В принципе, если всё сделано правильно, то маппинг порта 30000 клиенту А, а порта 30001 клиенту B никакой угрозы безопасности не представляет.
stepik777
29.11.2015 11:01+3Вот, кстати, сервис, который определяет реальный ip из-за VPN: diafygi.github.io/webrtc-ips
Никаких уязвимостей, браузеры сами определяют и сообщают реальный ip. Работает, в случае если вы подключены к VPN непосредственно с компьютера, если через роутер, то браузер не сможет определить ваш реальный ip адрес.
vp7
30.11.2015 02:32+1Уточнение — работает только в случае, когда реальный IP адрес назначен на компьютере.
Если же компьютер выходит в интернет через роутер, при этом на компьютере поднят VPN туннель к VPN провайдеру, то ничего узнать не получится.
Специально ради этого подключился к VPN серверу, получил:
==
Your local IP addresses:
192.168.1.18
10.240.0.3
Your public IP addresses:
<публичный IP VPN сервера>
==
Valle
30.11.2015 05:38-1У меня прекрасно высвечивает мой реальный публичный IPv4 роутера через одного известного VPN провайдера. Спросил поддержку, за что я собственно деньги плачу :-)
phantasm1c
29.11.2015 12:50Я только одно понять не могу: как злоумышленник вызовет DNAT портов на самом VPN-сервере, не будучи его владельцем? А если он владелец этого сервера — он и так знает адреса своих пользователей.
qw1
Для исправления проблемы VPN-провайдеру нужно разнести адреса, чтобы пользователь подключался к vpn-серверу 1.2.3.4, а с vpn-сервера трафик выходил с адреса 1.2.3.5, этот адрес (1.2.3.5) и будет обслуживаться в заявках на перенаправление портов.
Другой способ защиты — на клиенте запретить любой трафик на адрес vpn-сервера 1.2.3.4, кроме трафика на порт, использующийся для создания туннеля.
Эта информация есть в оригинальной статье.