Редактор GeekTimes
1049,0
рейтинг
28 ноября 2015 в 17:59

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

image

26 ноября специалисты по безопасности VPN-провайдера Perfect Privacy обнаружили в VPN уязвимость, которая может привести к раскрытию ip-адресов пользователей. Атака работает за счёт перенаправления портов. По заявлениям специалистов, уязвимости подвержены все реализации VPN (протоколы IPSec, OpenVPN, PPTP, и другие), и не зависит от операционной системы.

Для успешного осуществления атаки атакующий должен завести аккаунт у того же VPN-провайдера, что и жертва. Затем необходимо узнать выходной ip-адрес жертвы. Часто у VPN-провайдеров используется небольшой пул выходных адресов – их можно перебирать, заманить жертву на специально созданный веб-сайт, что и выдаст её выходной ip-адрес, или брать адреса из торрентокачалки.

Затем атакующий активирует у себя перенаправление портов – при этом от жертвы не требуется никаких действий, и неважно, работает ли у неё такое перенаправление, или нет. И в заключение, жертве необходимо скормить любой ресурс, в url которого указан порт, на который идёт перенаправление.

Технические детали специалисты приводят следующие:

  1. У жертвы установлена связь с VPN-сервером 1.2.3.4
  2. Её таблица роутинга будет примерно такой: 0.0.0.0/0 -> 10.0.0.1 (адрес внутреннего шлюза VPN), 1.2.3.4/32 -> 192.168.0.1 (старый шлюз по-умолчанию)
  3. Атакующий соединяется с тем же сервером 1.2.3.4, уже зная выходной ip-адрес жертвы
  4. Он активирует перенаправление портов на сервере 1.2.3.4, например, на порт 12345
  5. Он заманивает жертву, чтобы та сделала запрос на 1.2.3.4:12345 (например, через включение в страницу кода <img src=http://1.2.3.4:12345/x.jpg>)
  6. Установленное соединение раскроет 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 помогает обойти и блокировку ресурсов, введённую провайдерами по требованию властей.
Вячеслав Голованов @SLY_G
карма
133,2
рейтинг 1049,0
Редактор GeekTimes
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (19)

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

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

    Эта информация есть в оригинальной статье.
  • +3
    Такая ерунда, а все с ней носятся. Это не уязвимость, тем более не уязвимость VPN. Так работает маршрутизация, только и всего. Я такое 3 года назад проделывал, да и похожая техника используется для DNS Rebinding Attack роутеров, которой тоже не один год.
    • +1
      Вот, кстати, Android с его VPN API позволяет пускать через VPN в том числе и IP VPN-сервера, не вызывая закольцовывание маршрутизации. И Windows, в некоторых случаях, тоже может работать в таком режиме. На Linux такого поведения тоже можно добиться, используя policy routing.
    • +1
      Можно сказать, что и sql injection не уязвимость SQL-сервера, а проблема в приложении, которое не экранирует пользовательский ввод. Аналогично с VPN-сервисами — есть дырявые, хотя это не проблема протокола.

      Но проблема не очевидна (её до сих пор массово не победили). Если о ней не трубить на каждом углу, N% сервисов так и останутся дырявыми. Как если не напоминать постоянно всем о stack overflow и sql injection, количество ошибок, приводящих к этим уязвимостям, будет сильно выше. Люди ленивы, аккуратно и правильно не будут делать без напоминания.
      • 0
        Частично согласен, частично нет. Это не проблема ни 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?
        • +1
          Это ошибка конфигурации. Можно ли назвать её уязвимостью? Спорный вопрос, но рассказывать о ней надо почаще, чтобы эти ошибки делали реже.
  • 0
    SLY_G, в каком именно «протоколе» уязвимость? VPN протоколов множество, как вы понимаете, и ни в одном из них уязвимости нет. Уязвимость в конфигурации VPN сервера. В оригинале нигде не говорится об «уязвимости в протоколе». Исправьте, пожалуйста. Нам тут желтизны и так хватает, не надо больше.
    • 0
      Исправил.
  • 0
    Если у меня VPN сервер свой, то мне это не грозит? Ведь только я к нему подключаюсь.
    • 0
      В этом случае (с учетом допущений, принятых в статье) ваш выходной IP и так однозначно отображается на вас и только на вас.
  • +2
    Всегда использовал только свой VPN сервис. Долго думал как может клиент VPN открыть порт на VPN сервере. Это ж ssh надо, к тому же с рут-доступом.

    Я правильно понимаю, что VPN сервисы некоторые сами дают возможность через какой-то интерфейс открывать на сервере переадресацию портов на внтуренние адреса? Так это просто корявая конфигурация на стороне сервера всего лишь. Какая ж это уязвимость?
    • 0
      VPN сервисы сами дают возможность через какой-то интерфейс открывать на сервере переадресацию портов?
      Конечно, это очень полезная услуга. DHT в разных файлообменных программах требует какой-либо открытый порт. В принципе, если всё сделано правильно, то маппинг порта 30000 клиенту А, а порта 30001 клиенту B никакой угрозы безопасности не представляет.
  • +3
    Вот, кстати, сервис, который определяет реальный ip из-за VPN: diafygi.github.io/webrtc-ips
    Никаких уязвимостей, браузеры сами определяют и сообщают реальный ip. Работает, в случае если вы подключены к VPN непосредственно с компьютера, если через роутер, то браузер не сможет определить ваш реальный ip адрес.
    • 0
      Подробности?
    • +1
      Уточнение — работает только в случае, когда реальный IP адрес назначен на компьютере.
      Если же компьютер выходит в интернет через роутер, при этом на компьютере поднят VPN туннель к VPN провайдеру, то ничего узнать не получится.

      Специально ради этого подключился к VPN серверу, получил:
      ==
      Your local IP addresses:
      192.168.1.18
      10.240.0.3
      Your public IP addresses:
      <публичный IP VPN сервера>
      ==
      • –1
        У меня прекрасно высвечивает мой реальный публичный IPv4 роутера через одного известного VPN провайдера. Спросил поддержку, за что я собственно деньги плачу :-)
  • 0
    Я только одно понять не могу: как злоумышленник вызовет DNAT портов на самом VPN-сервере, не будучи его владельцем? А если он владелец этого сервера — он и так знает адреса своих пользователей.
    • +1
      Некоторые сервисы позволяют пробрасывать порты.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.