Comments 19
Для исправления проблемы VPN-провайдеру нужно разнести адреса, чтобы пользователь подключался к vpn-серверу 1.2.3.4, а с vpn-сервера трафик выходил с адреса 1.2.3.5, этот адрес (1.2.3.5) и будет обслуживаться в заявках на перенаправление портов.
Другой способ защиты — на клиенте запретить любой трафик на адрес vpn-сервера 1.2.3.4, кроме трафика на порт, использующийся для создания туннеля.
Эта информация есть в оригинальной статье.
Другой способ защиты — на клиенте запретить любой трафик на адрес vpn-сервера 1.2.3.4, кроме трафика на порт, использующийся для создания туннеля.
Эта информация есть в оригинальной статье.
Такая ерунда, а все с ней носятся. Это не уязвимость, тем более не уязвимость VPN. Так работает маршрутизация, только и всего. Я такое 3 года назад проделывал, да и похожая техника используется для DNS Rebinding Attack роутеров, которой тоже не один год.
Вот, кстати, Android с его VPN API позволяет пускать через VPN в том числе и IP VPN-сервера, не вызывая закольцовывание маршрутизации. И Windows, в некоторых случаях, тоже может работать в таком режиме. На Linux такого поведения тоже можно добиться, используя policy routing.
Можно сказать, что и sql injection не уязвимость SQL-сервера, а проблема в приложении, которое не экранирует пользовательский ввод. Аналогично с VPN-сервисами — есть дырявые, хотя это не проблема протокола.
Но проблема не очевидна (её до сих пор массово не победили). Если о ней не трубить на каждом углу, N% сервисов так и останутся дырявыми. Как если не напоминать постоянно всем о stack overflow и sql injection, количество ошибок, приводящих к этим уязвимостям, будет сильно выше. Люди ленивы, аккуратно и правильно не будут делать без напоминания.
Но проблема не очевидна (её до сих пор массово не победили). Если о ней не трубить на каждом углу, N% сервисов так и останутся дырявыми. Как если не напоминать постоянно всем о stack overflow и sql injection, количество ошибок, приводящих к этим уязвимостям, будет сильно выше. Люди ленивы, аккуратно и правильно не будут делать без напоминания.
Частично согласен, частично нет. Это не проблема ни VPN-сервисов, ни VPN-серверов, ни протокола, это особенность работы сетевой маршрутизации. Ее нужно исправлять на клиенте, а не на сервере (хотя и на сервере ее исправить возможно).
Проблеме утечки DNS в Windows 8.1 и 10 как-то меньше внимания уделили, хотя ее заметно проще эксплуатировать массово.
Вот вам еще одна «уязвимость», которая не уязвимость, а особенность работы маршрутизации и сетевого стека, эксплуатирующая схожий принцип работы сети, описанный в статье, о которой, я надеюсь, знает каждый сетевой администратор, в том числе и администраторы VPN-сервисов, на примере BitTorrent-раздачи и слежения средствами правообладателей:
Уязвимость ли это VPN? Определенно нет, это особенность маршрутизации. Можно ли ее исправить на стороне VPN-сервера? Нет, только на клиенте. Можно ли эксплуатировать массово? В какой-то степени, да, в отличие от описанного в статье способа, где нужно эксплуатировать конкретный VPN-сервер у конкретного VPN-сервиса.
Где мне забрать мои $5000?
Проблеме утечки 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?
SLY_G, в каком именно «протоколе» уязвимость? VPN протоколов множество, как вы понимаете, и ни в одном из них уязвимости нет. Уязвимость в конфигурации VPN сервера. В оригинале нигде не говорится об «уязвимости в протоколе». Исправьте, пожалуйста. Нам тут желтизны и так хватает, не надо больше.
Если у меня VPN сервер свой, то мне это не грозит? Ведь только я к нему подключаюсь.
Всегда использовал только свой VPN сервис. Долго думал как может клиент VPN открыть порт на VPN сервере. Это ж ssh надо, к тому же с рут-доступом.
Я правильно понимаю, что VPN сервисы некоторые сами дают возможность через какой-то интерфейс открывать на сервере переадресацию портов на внтуренние адреса? Так это просто корявая конфигурация на стороне сервера всего лишь. Какая ж это уязвимость?
Я правильно понимаю, что VPN сервисы некоторые сами дают возможность через какой-то интерфейс открывать на сервере переадресацию портов на внтуренние адреса? Так это просто корявая конфигурация на стороне сервера всего лишь. Какая ж это уязвимость?
VPN сервисы сами дают возможность через какой-то интерфейс открывать на сервере переадресацию портов?Конечно, это очень полезная услуга. DHT в разных файлообменных программах требует какой-либо открытый порт. В принципе, если всё сделано правильно, то маппинг порта 30000 клиенту А, а порта 30001 клиенту B никакой угрозы безопасности не представляет.
UFO just landed and posted this here
Подробности?
Статья + исходники github.com/diafygi/webrtc-ips
Уточнение — работает только в случае, когда реальный IP адрес назначен на компьютере.
Если же компьютер выходит в интернет через роутер, при этом на компьютере поднят VPN туннель к VPN провайдеру, то ничего узнать не получится.
Специально ради этого подключился к VPN серверу, получил:
==
Your local IP addresses:
192.168.1.18
10.240.0.3
Your public IP addresses:
<публичный IP VPN сервера>
==
Если же компьютер выходит в интернет через роутер, при этом на компьютере поднят VPN туннель к VPN провайдеру, то ничего узнать не получится.
Специально ради этого подключился к VPN серверу, получил:
==
Your local IP addresses:
192.168.1.18
10.240.0.3
Your public IP addresses:
<публичный IP VPN сервера>
==
Я только одно понять не могу: как злоумышленник вызовет DNAT портов на самом VPN-сервере, не будучи его владельцем? А если он владелец этого сервера — он и так знает адреса своих пользователей.
Sign up to leave a comment.
Обнаруженная брешь позволяет раскрывать ip-адреса клиентов VPN-провайдеров