Определение локальных IP-адресов через WebRTC

    Через WebRTC можно получить список всех локальных (находящихся за NAT) интерфейсов в системе.

    Пример кода на JavaScript jsfiddle.net/GZurr

    Работает только в браузерах поддерживающих WebRTC, на текущий момент это Firefox и Chrome.

    Это можно использовать для получения более точного фингерпринта браузера или, например, разоблачения персонажей, сидящих за VPN, чтобы ВЫЧИСЛИТЬ ПО АЙПИ И НАБИТЬ Е**ЛЬНИК

    Для удобства использования я изготовил js-сниффер, который можно вставить на страницу и удобно просматривать результат его работы: zhovner.com/jsdetector

    Достаточно вставить на страницу код:

    <script src="//zhovner.com/jsdetector.js?name=test"></script>


    Где test нужно заменить на слово, по которому будет доступен результат работы сниффера: zhovner.com/jsdetector/test


    Из примечательного в скрипте — определение адресов пользовательского резовлера.

    Скрипт генерирует несколько рандомных поддоменов вида RANDOM.detect.zhovner.com и обращается к ним по HTTP.

    Зона *.detect.zhovner.com делегирована wildcard-ом на NS-сервер, которые логирует запросы резолверов, и при обращении к сайтам возвращает source адрес, с которого пришел резолвер.

    Нужно иметь в виду, что SSL сертификат валидный только для корневого домена, но не для *.detect.zhovner.com, поэтому при встраивании скрипта на https-сайты, будет показано предупреждение о контенте загружаемом не по HTTPS.

    UPD:

    Еще, оказывается, можно обнаружить соседние хосты в сети dl.dropboxusercontent.com/u/1878671/enumhosts.html
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 43
    • 0
      А что покажет скрипт, если нет NAT?
      • 0
        Ну что у вас показывает? Адреса локальных интерфейсов, не важно за натом они или нет.
        • +1
          Все, понял, смутило упоминание NAT в начале поста. Тогда это повод отключить webrtc.
          • +2
            Ну если нет НАТ, то и так виден ip при посещении сайта. Прелесть в том, что скрипт позволяет увидеть ВСЕ интерфейсы в системе. Так, например, если VPN поверх интернета, будет видно оба айпишника.
            • +1
              Видит лишь VPN IP и локальный IP. Но не домашний…
              • 0
                Так вы за роутером поди. Если бы напрямую к интернету подключались, то оно бы увидело ваш внешний IP.
      • –12
        Еще одно подтверждение того, что JS — зло
        • +10
          Ещё одно подтверждение, что у JS хейтеров проблемы с логическим мышлением.
          • 0
            Я не JS хейтер. Зря я так сформулировал. Имел ввиду: бездумное исполнение кода, загружаемого с какого-либо сервера. Пусть даже с ограничениями.
        • +8
          Воу-воу, вот это поворот!
          Реально палит IP при работе через VPN.
          • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              А вот еще, к примеру, айпишники с которых вы в скайп заходите:

              remote: 2.150.21.98 local: 10.102.236.5
              remote: 84.208.74.209 local: 10.0.0.203

              Виден один и тот же локальный 10.0.0.203. Довольно редкий.
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  А ту штуку со скайпом (ну, которая у тебя на домене со слабо связанным со скайпом названием висит) всё никак не прикроют, да?
              • +1
                А если у вас не было бы NAT (ну, предположим, 1 компьютер всего), то был бы виден ваш прямой IP.
            • +2
              ИМХО, в сочетании как раз с локальным NAT бесполезен — ну будет виден адрес вида 192.168.1.* и что?
              • 0
                Анонимность страдает, только если юзер сидит не за NAT, и при этом пользуется прокси-сервером или анонимайзером.
                • 0
                  Не только. Еще в случае, если есть уникальный локальный адрес, как например habrahabr.ru/post/215071/#comment_7386869 по которому можно трекать при смене внешних адресов.
                  • +1
                    А можно через webrtc определить ipv6-адреса локальных интерфейсов?
                    Например, мой случай: по ipv4 я за NAT-ом, но ipv6-адрес — публичный.
                • +2
                  Принцип работы до конца не понял, но впечаление производит!

                  Правда стоит заметить, что если сидишь за двойным NAT-ом (первый провайдерский, второй домашний), то определится IP последнего, который по сути — бесполезен.
                  • 0
                    Помню, раньше под IE использовался ActiveX, который отображал содержимое локальных дисков, чем то напомнило.
                    • +4
                      Хаха, умно!

                      Похоже я был прав, когда решил ходить в интернеты из под браузера, засунутого в виртуалку (виртуальная карта в режиме NAT), а VPN поднимать на хост-машине. Спасибо VMWare за наше счастливое детство.
                      • +8
                        Firefox -> about:config -> media.peerconnection.enabled = false
                        • –3
                          Ну вот посмотрел я, под виндой, показывает внешний IPшник виртуалки до которой браузер ходит надев носки(socks5), внутренние 192.168.x.x один выданный точкой доступа и парочка от VMWare, а резолверы вообще чудесные IPv6 и все такое. Как-то не помогает информация вычислить по IP и набить лицо.
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • +1
                              По моему скромному мнению, есть еще 1001 (неизвестная мне и многим другим) уловка, позволяющая «вытащить» через браузер инфу о разных «палевных» аспектах локального окружения.

                              Поэтому VMware, в качестве guestOS ставим Lubuntu, все любимые браузеры (а заодно TOR/TBB) ставим на guestOS'е, сетевую карту VMWare — в NAT-режим, VPN поднимаем на hostOS.

                              И ходим в эти ваши интернеты только из-под guestOS. Будет небольшой гемор с порт-форвардингом (решаемый), но в остальном все очень даже симпатично получается.
                              Даже если какая-то дрянь «прогрызет» различные защиты браузера, ей еще надо будет из-под VMWare выкарабкаться, а это уже не вполне заурядное (хотя и не невозможное) мероприятие.
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • 0
                                С каких пор через HTTP-прокси можно пустить DNS-резолвер?
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • +3
                                    Изначально. При использовании только HTTP-протокола прокси передаётся нужный домен в заголовке Host. При использовании HTTPS-прокси (через который по факту работает всё кроме обычного HTTP) домен передаётся при использовании CONNECT. То есть, если компьютер знает адрес HTTPS-прокси, то ему для общения с сетью не нужен доступ к DNS. nslookup работать не будет, но это не критично.
                                  • +3
                                    Ухты, можно и сеть посканировать dl.dropboxusercontent.com/u/1878671/enumhosts.html
                                    • +2
                                      Ладно про себя браузер все рассказывает, а вот про соседей — это уже точно за рамки выходит :(
                                    • 0
                                      а ещё автор забыл упомянуть что скрипт из его фиддла просто исходник страницы net.ipcalf.com/
                                      ссылка на неё там же в этом блоге
                                    • 0
                                      Про адреса резолверов на стороне клиента: мой локальный IP — 192.168.77.2
                                      1. на клиенте, с которого хожу:
                                      cat /etc/resolv.conf
                                      # Generated by NetworkManager
                                      domain i-hn.loc
                                      search i-hn.loc
                                      nameserver 192.168.77.1
                                      nameserver 2001:4860:4860::8888
                                      nameserver 2001:4860:4860::8844
                                      2. на маршрутизаторе:
                                      Яндекс.DNS, безопасный
                                      Плюс, вбиты для IPv6 only — гугловские IP-адреса серверов DNS, которые видны и в п.1.
                                      • 0
                                        zhovner.com/jsdetector/test — лихо все друг-друга на одной странице попалили ;)
                                        • 0
                                          Ага, немного напоминает злую шутку про «программу из одной строчки на Perl»
                                          • 0
                                            Вы не поняли, те кто перешел по ссылке туда не попадают. Там же виден реферер. Это только те, кто не сменив name=test вставили код себе на сайты.
                                            • 0
                                              Я таки уже понял :). Как раз этап «бездумно скопипастили» и объединяет ситуацию с той перловой историей.

                                              Кстати результаты довольно любопытные, имхо.

                                              • 0
                                                Судя по реферерам типа https://paypal.com, кто-то уже просто подкидывает фейковые данные.
                                                Кстати, неплохая идея — запатчить браузер, чтобы он для webrtc отдавал IP лондонского провайдера.
                                                Если придут, то к какому-нибудь ничего не подозревающему человеку.
                                        • 0
                                          тр768

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