NetBIOS протокол подвержен spoofing'у

    Небольшое введение в работу NetBIOS протокола.

    Когда Windows пытается выполнить резолвинг сетевого имени, то сначала Windows обращается к DNS. Далее, если никто не вмешался в DHCP запрос и не подменил DNS сервер на свой, и если никто не произвел ARP spoofing атаку для перенаправления трафика, то запрос дойдет к указанному DNS. В свою очередь DNS предоставит необходимый IP адрес.

    Если запрос к DNS оказался не успешным (например, не доступен DNS сервер), то Windows попытается осуществить резолвинг сетевого имени с помощью NetBIOS протокола (NBNS). Именно NetBIOS резолвинг позволяет Вам выполнить ping SOMEPC (имя в сети), и если SOMEPC включен и находится в сети произойдет преобразование имени SOMEPC в IP адрес. Самое интересное, что все это сводится к широковещательному запросу — «Кому принадлежит SOMEPC?» и компьютер, который имеет имя SOMEPC ответит — «Эй, это же Я!».
    Но что мешает злоумышленнику выдать себя за SOMEPC (или любое другое имя)?



    NBTool


    Одна из утилит в пакете NBTool, называемая nbpoison, перехватывает широковещательные запросы NBNS (NetBIOS Name Query packet) в сети и отвечает на них адресам (NetBIOS Name Query Response packet), которые отправляли запрос, при этом подменяя IP адрес на свой. Кроме этого, если использовать ключ -c (флаг конфликта), то вновь загрузившийся хост получит сообщение, что имя, которое ему присвоено уже используется в сети.

    Т.е. сценарий будет выглядеть следующим образом:
    FREDSBOX: (только загрузился и регистрируется в сети) — «Эй, ребята, для Вашего внимания — мое имя в сети FREDSBOX»
    Атакующий: «Нет, уважаемый, Вы ошибаетесь — Я FREDSBOX».
    FREDSBOX: «Хорошо, извините.» (С этого момента FREDSBOX больше не отвечает на запросы, пришедшие на его имя)

    И так, например мы хотим отвечать на все широковещательные запросы NBNS в сегменте 172.21.49.0/24 своим адресом 172.21.49.129 и перенаправлять все запросы на свой компьютер. Для этого, запускаем nbpoison с параметрами:

    sudo ./nbpoison -s 172.21.49.129

    image

    На скриншоте мы можем увидеть, что при пинге несуществующего адреса NONAMESERVER1 происходит резолвинг данного имени и ответ на пинг (echo-reply) от адреса 172.21.49.129, т.е. тот, который мы указали в параметрах утилиты nbpoison. Еще один момент, на который стоит обратить внимание — это то, что запуск утилиты nbpoison необходимо выполнять от имени суперпользователя (root), т.к. утилита работает с привилегированным портом UDP 137.

    Теперь рассмотрим несколько типов атак на практике:

    Представим ситуацию когда корпоративный DNS сервер по какой-либо причине стал недоступным: например, uplink коммутатора, в который подключена ваша сеть физически (преднамеренно) выключен, либо произошел сбой в конфигурации маршрутизатора, фаервола, либо случился сбой на корпоративном DNS и вся ваша подсеть не может достучаться к DNS.
    Следовательно, как было сказано выше, Windows при не успешном резолвинге сетевого имени пытается осуществить резолвинг средствами NetBIOS (NetBIOS Name Service).



    И так, как вы можете увидеть, компьютер под управлением Linux был использован для подмены WEB страницы. Вместо данной страницы можно было отобразить фальшивую страницу какого-нибудь популярного почтового сервиса такого, как gmail либо какой-нибудь портал социальной сети. И все введенные пароли собирать и заносить в журнал.

    Следующий типа атаки, который мы рассмотрим, может быть использован для мониторинга WPAD запросов и сбора корпоративных конфиденциальных данных пользователей. Данный метод атаки может быть применим, когда в браузере стоит опция «Автоматически определять параметры proxy для данной сети». И Internet Explorer, и Mozilla Firefox поддерживают данную возможность для того, чтобы администратор сети мог автоматически сообщать настройки корпоративного proxy сервера. В данной ситуации, подменив NBNS запрос, мы можем указать жертве использовать наш WPAD скрипт, который будет перенаправлять запрос на ssltrip, настроенный на прослушивание порта 8080 и мы сможем увидеть много чего интересного.

    Похожие публикации

    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 9

      –3
      Вообще-то, в домене такие штуки работать не будут, потому что есть dns suffix. При доступе по простому имени, вместо NETBIOS запроса к NONAMESERVER будет DNS запрос к NONAMESERVER.domain.com. Собственно, даже мой провайде выдаёт dns suffix по DHCP. Ну и вообще в домене NetBIOS нет, а домашние пользователи по NetBIOS в интернет не ходят. Это раз.

      Статья об особенностях работы очень старого сетевого протокола, при проектировании которого не учитывалась безопасность несёт тайное послание Windows — дырявый, Linux — безопасный. Linux поддерживающий NetBIOS уязвим ничуть не меньше. Это два.
        +1
        Извините, но не смог уместить ответ в одном комментарии:
        Во первых, Вы недостаточно ознакомились с текстом, либо я недостаточно полно раскрыл данную тему.
        Данный метод атаки будет работать только, если жертва и атакующий находятся в ОДНОЙ ПОДСЕТИ и при условии того, что на в системе жертвы разрешен Netbios Over IP
        Во вторых, Вы не знакомы с тем, как и каким образом Windows осуществляет резолвинг.
        Сделал пример для Вас:

        В данном примере, я пытался сделать пинг хоста google1.com
        И, как Вы можете видеть:
        1)Попытка резолвинга с помощью DNS qeury
        2)Попытка завершилась неудачно
        3)3 широковещательных запроса NBNS, т.е. попытка разрешить имя с помощью протокола NetBios
          +1
          Две семёрки x64, дома и на работе. Рабочая в домен, уровень домена 2003, уровень леса 2003. Контроллёры 2008 R2, особых политик безопасности нет.

          Дома, несмотря на DNS суфикс действительно есть и NetBIOS запрос. Проверил вашим Wireshark. Забавная кстати программка, показала броадкасты провайдеровских цисок.

          На работе всё как я и говорил, после DNS никакого NetBIOS.
            0
            >Проверил вашим Wireshark. Забавная кстати программка, показала броадкасты >провайдеровских цисок.

            Уважаемый, adontz, wireshark — это лучший анализатор из когда-либо созданных на данное время. :)
              0
              Можно взглянуть на результат, полученный на рабочей машине? Желательно в виде pcap файла
          +2
          Вы путаете FQDN и Netbios name
            +3
            Последовательность разрешения имен такая:
            Кэш/hosts
            DNS — по FQDN
            NetBIOS Name Cache — по 16символьному имени NetBios
            WINS
            Broadcast
            lmhosts
              –1
              То, что Вы описали — не MITM. MITM подвержены любые протоколы, не использующие PKI (ожидаем статей «HTTP подвержен MITM», «FTP подвержен MITM», «DNS подвержен MITM», «SMTP подвержен MITM», «POP3 подвержен MITM», да чего уж там — «TCP/IP подвержен MITM»).

              Что же до описанной атаки — Вам совершенно верно указали на то, что в доманах атака не выполнима. Да и IPsec никто не отменял. Непонятно, почему Вы всего лишь вскользь упомянули ARP poisoning (в контектсе блокирования DNS) при том, что это гораздо более опасно, ибо ARP является stateless протоколом (то есть «отравить» кеш жертвы можно даже не дожидаясь APR-запроса), а следовательно можно устроить MITM на любой из вышеперечисленных (и не только) протоколов.
                0
                1)Вам совершенно верно указали на то, что в доманах атака не выполнима -> не правильно указали, смотрите ответ на его комментарий
                2)Вы всего лишь вскользь упомянули ARP poisoning — а целью и не было упомянуть все виды атак :)
                3)То, что Вы описали — не MITM -> Да, извините, это спуфинг.

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

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