Обнаруженная брешь позволяет раскрывать ip-адреса клиентов VPN-провайдеров

[qw1]

Для исправления проблемы VPN-провайдеру нужно разнести адреса, чтобы пользователь подключался к vpn-серверу 1.2.3.4, а с vpn-сервера трафик выходил с адреса 1.2.3.5, этот адрес (1.2.3.5) и будет обслуживаться в заявках на перенаправление портов.

Другой способ защиты — на клиенте запретить любой трафик на адрес vpn-сервера 1.2.3.4, кроме трафика на порт, использующийся для создания туннеля.

Эта информация есть в оригинальной статье.

[ValdikSS]

Такая ерунда, а все с ней носятся. Это не уязвимость, тем более не уязвимость VPN. Так работает маршрутизация, только и всего. Я такое 3 года назад проделывал, да и похожая техника используется для DNS Rebinding Attack роутеров, которой тоже не один год.

[ValdikSS]

Вот, кстати, Android с его VPN API позволяет пускать через VPN в том числе и IP VPN-сервера, не вызывая закольцовывание маршрутизации. И Windows, в некоторых случаях, тоже может работать в таком режиме. На Linux такого поведения тоже можно добиться, используя policy routing.

[qw1]

Можно сказать, что и sql injection не уязвимость SQL-сервера, а проблема в приложении, которое не экранирует пользовательский ввод. Аналогично с VPN-сервисами — есть дырявые, хотя это не проблема протокола.

Но проблема не очевидна (её до сих пор массово не победили). Если о ней не трубить на каждом углу, N% сервисов так и останутся дырявыми. Как если не напоминать постоянно всем о stack overflow и sql injection, количество ошибок, приводящих к этим уязвимостям, будет сильно выше. Люди ленивы, аккуратно и правильно не будут делать без напоминания.

[ValdikSS]

Частично согласен, частично нет. Это не проблема ни VPN-сервисов, ни VPN-серверов, ни протокола, это особенность работы сетевой маршрутизации. Ее нужно исправлять на клиенте, а не на сервере (хотя и на сервере ее исправить возможно).
Проблеме утечки DNS в Windows 8.1 и 10 как-то меньше внимания уделили, хотя ее заметно проще эксплуатировать массово.

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

1. У пользователя запущен BitTorrent-клиент, порт на маршрутизаторе открыт (статически или через UPnP, неважно)
2. Правообладатели, которые следят за пирами на раздачах (в США и Германии это повсеместно) ловят связки IP: порт с торрент-трекеров и DHT
3. Правообладатели массово отправляют UDP-пакеты торрент-клиентам на порты, которые поймали ранее, на все маршрутизируемые IPv4-адреса (это занимает считанные минуты, даже не десятки минут, для TCP через masscan на 10G канале, для UDP должно быть еще быстрее)
4. Клиенты, будучи подключенными к VPN, получают пакет на реальный интерфейс, а ответ отправляют с VPN-адреса
5. ???
6. PROFIT!

Уязвимость ли это VPN? Определенно нет, это особенность маршрутизации. Можно ли ее исправить на стороне VPN-сервера? Нет, только на клиенте. Можно ли эксплуатировать массово? В какой-то степени, да, в отличие от описанного в статье способа, где нужно эксплуатировать конкретный VPN-сервер у конкретного VPN-сервиса.
Где мне забрать мои $5000?

[qw1]

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

[ComodoHacker]

SLY_G, в каком именно «протоколе» уязвимость? VPN протоколов множество, как вы понимаете, и ни в одном из них уязвимости нет. Уязвимость в конфигурации VPN сервера. В оригинале нигде не говорится об «уязвимости в протоколе». Исправьте, пожалуйста. Нам тут желтизны и так хватает, не надо больше.

[SLY_G]

Исправил.

[agranom555]

Если у меня VPN сервер свой, то мне это не грозит? Ведь только я к нему подключаюсь.

[J_o_k_e_R]

Всегда использовал только свой VPN сервис. Долго думал как может клиент VPN открыть порт на VPN сервере. Это ж ssh надо, к тому же с рут-доступом.

Я правильно понимаю, что VPN сервисы некоторые сами дают возможность через какой-то интерфейс открывать на сервере переадресацию портов на внтуренние адреса? Так это просто корявая конфигурация на стороне сервера всего лишь. Какая ж это уязвимость?

[qw1]

VPN сервисы сами дают возможность через какой-то интерфейс открывать на сервере переадресацию портов?

Конечно, это очень полезная услуга. DHT в разных файлообменных программах требует какой-либо открытый порт. В принципе, если всё сделано правильно, то маппинг порта 30000 клиенту А, а порта 30001 клиенту B никакой угрозы безопасности не представляет.

[Ryav]

Подробности?

[qw1]

Статья + исходники github.com/diafygi/webrtc-ips

[vp7]

Уточнение — работает только в случае, когда реальный IP адрес назначен на компьютере.
Если же компьютер выходит в интернет через роутер, при этом на компьютере поднят VPN туннель к VPN провайдеру, то ничего узнать не получится.

Специально ради этого подключился к VPN серверу, получил:
==
Your local IP addresses:
192.168.1.18
10.240.0.3
Your public IP addresses:
<публичный IP VPN сервера>
==

[Valle]

У меня прекрасно высвечивает мой реальный публичный IPv4 роутера через одного известного VPN провайдера. Спросил поддержку, за что я собственно деньги плачу :-)

[phantasm1c]

Я только одно понять не могу: как злоумышленник вызовет DNAT портов на самом VPN-сервере, не будучи его владельцем? А если он владелец этого сервера — он и так знает адреса своих пользователей.

[ValdikSS]

Некоторые сервисы позволяют пробрасывать порты.