Обнаруженная брешь позволяет раскрывать 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 помогает обойти и блокировку ресурсов, введённую провайдерами по требованию властей.
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 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
            Если у меня VPN сервер свой, то мне это не грозит? Ведь только я к нему подключаюсь.
            • НЛО прилетело и опубликовало эту надпись здесь
            • +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
                    Некоторые сервисы позволяют пробрасывать порты.

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