Автор: dunkel
Для форума: xss.pro
Всем привет. Что происходит когда человек открывает сайт? Браузер должен отправить на ip сервера где хостится сайт (или на ip cdn типа cloudflare) GET запрос по протоколу http для получения запрашиваемой страницы сайта чтобы открыть ее в браузере. Где он узнает этот ip адрес?
1) Браузер сначала проверяет свой локальный кэш
2) Затем файл hosts (конфиг этого файла используется системным резолвером)
3) Если на устройстве ip нет или TimeToLive (ttl) истек, то делает запрос по DNS протоколу к "местному" DNS серверу (кто такой "местный" - расскажу позже).
4) Если в кэше dns сервера тоже нет актуального адреса (записи), dns сервер запрашивает его у других, вышестоящих dns серверов
Пример открытия xss.pro:
Устройство ищет по dhcp в локальной сети ближайший(местный) dns сервер(резолвер) и спрашивает запись A (ipv4) для xss.pro (лог из wireshark)
А затем когда получает ip из A записи посылает на него GET запрос с http заголовком Host: xss.pro
И в теле ответа получает код страницы которую надо отрендерить в браузере.
*По этому заголовку сервер или cdn определяет контент для какого сайта отдавать пользователю. Потому что на одном хостинге с одним ip может быть несколько сайтов. Если введете просто айпи сайта в адресную строку скорее всего ничего не получите. Можно таким образом хостить и отдавать жертвам несколько фишингов с одной нашей vps, в зависимости от заголовка
Архитектура dns за редким исключением остается неизменной с 1983 года. Каждый раз, когда человек хочет открыть сайт, браузер отправляет запрос с указанием домена на днс сервер, который в ответ отправляет необходимый айпи адрес. И запрос, и ответ на него передаются в открытом виде, без какого-либо шифрования. Это значит, что провайдер, админ сети или злоумышленники c mitm могут не только логгировать историю всех запрошенных сайтов, но и подменять ответы на эти запросы.
Что будет если жертва введет в браузер например binance.com или просто кликнет по любой ссылке на любу страницу на этом домене, и получит из локального кэша или в ответе dns вместо реального ip сайта - ip нашей подконтрольной vps? - жертва попадет на фишинг.
Фишинг кредов в wifi сети офиса компании частая точка входа в сеть корпу, есть апт кто таким образом добывает доступы
Фишинг через dns может быть точечным (направленным на одного/нескольких людей в локальной сети) или массовым фармингом траффика (через свой mitm узел/ iot ботнет/отравление кэша)
Вместе с кредами, 2fa и куки сессией так же сохраняйте в бд exit node айпи жертвы, чтобы подобрать прокси по подсети/городу для входа и не иметь проблем с фродом.
Теперь про сами dns атаки и их мое небольшое определение:
Подготовка фишинга:
Перед тем как спуфать/загрязнять dns надо подготовить фишинг.
После перехода жертвы на наш сервер у нас будет два варианта продолжения атаки:
1) Моментально редиректить жертву на наш визуально похожий домен, чтобы отдавать контент по https и иметь замочек ssl слева от url, так как мы легко получим ssl/tls сертификат на подконтрольный нам домен. Найти незанятую доменную зону для слова можно здесь https://lab.xpaw.me/alldomainsearch.html
Но не рекомендую использовать популярные трейдмарки слова вроде binance, так как браузеры могут быстро автоматически накинуть кт (Красная Табличка, deceptive site ahead) за фишинг. Лучше используйте похожие символы (например blnance), panycode + клоакинг чтобы боты не чекали контент
2) Отдавать фишинг прямо на оригинальном домене, но через http, без ssl замочка. Так как мы не можем получить приватный ключ от чужого ssl сертификата и оригинального домена для подписи своих запросов.
Но плюс этого метода в том что не нужен клоакинг, и ваш фишинг никогда не попадет под бан/красную табличку, потому что его будут видеть только виктим юзеры, а гугл боты никак не смогут на него попасть, потому что у них будет открываться оригинальный сайт.
Мне лично нравиться больше первый вариант, с редиректом, т.к юзер увидев страшную надпись "Не защищено" может что нибудь заподозрить
Для начала я подниму простенький ленд фишинг страницы входа xss.pro на Apache на левой vps. Просто скачаю страницу входа и добавлю надпись "фишинг" чтобы вы могли отличить, что сейчас мы на фишинге.
В реальных атаках лучше использовать реверс прокси, всякие фреймворки для фишинга например gophish, evilginx3 или очень качественный клон
Теперь подменим айпи сайта на всех этапах поиска его устройством (из начала статьи), будем двигаться в том же порядке, от локального кэша к dns запросам
1) Браузер сначала проверяет свой локальный кэш
Кэш браузера может отравиться после получения отравленного dns запроса и остаться таким до его следущего обновления из легитимного dns. Если IP адрес уже кэширован (то есть недавно использовался), браузер может сразу использовать его, чтобы ускорить загрузку страницы. Посмотреть какие ip закешированны для каждого домена в гугл хроме можно введя chrome://net-internals/#dns ,в firefox about:networking#dns
Кэш браузера (допустим Google Chrome в Windows) храниться в C:\Users\%юзер%\AppData\Local\Google\Chrome\User Data\Default\Cache в каком то бинарном формате. Изменить этот кеш можно в любом hex редакторе открыв самый тяжелый файл в этой директории и поискав через ctrl + f (для этого не нужны админ права в отличии от редактирования hosts)
Также ip сайта можно указывать в burp suite, это будет тоже самое что кэш браузера (хотя работает скорее как системный резолвер) и проще для наших тестов. Открываем настройки settings, пишем в поисковой строке dns и добавляем запись с доменом xss.pro и айпи нашей vps (185.104.248.247) на которой поднят фишинг
Отключаем "безопасный dns сервер" если включено в настройках браузера (иначе может не сработать)
Вводим в адресную строку xss.pro, и у нас на легитимном домене открывается фишинг который мы подняли на vps
Правда без ssl/tls замочка (слева от url будет палевная надпись "не защищено"). Поэтому лучше редиректить на наш домен, типа xss.ls или xxs.is
2) Файл hosts
Указывает на хосты (ip) для конкретных доменов в формате "ip host", являясь конфигом для системного резолвера. Для редактирования требует админ прав C:\Windows\System32\drivers\etc\hosts
Часто используется чтобы заблокировать домены телеметрии и проверки лицензий софта всякими установщиками кряков, указав 0.0.0.0 domain.com
Раньше часто модифицировался Adware для показа рекламы. Я его трогать не буду так как для его изменения нужен доступ к устройству, а это не относится к сетевым атакам с dns.
Тут кстати ситуация непонятная, потому что иногда некоторые браузеры работают по правилам hosts только при недоступности dns сервера. То есть
1)сначала проверяют кэш браузера
2) затем отправляют dns запрос
3)и если ответа от резолвера нет - только потом используют айпи из hosts.
3) Если на устройстве его нет или ttl истек, то делает запрос по DNS протоколу к ближайшему DNS серверу
Предположим жертва давно не заходила на сайт, и срок годности ее кэш записи истек. Тогда браузер/устройство посылает dns запрос на ближайший dns сервер чтобы узнать айпи домена xss.pro.
А ближайший это какой? По умолчанию, если вы не используете vpn, ближайшим обычно считается тот который автоматически высылает провайдер при настройке PPPoE соединения в роутере. Посмотреть их можно зайдя в админку роутера в настройки сети или pppoe (их два, часто один в локальной сети NAT, другой запасной). Роутер отдает эти dns сервера по DHCP всем устройствам или сам перенаправляет на них dns запросы работая как dns relay.
Еще dns можно вручную указать в настройках сети в винде, здесь кстати некоторые вредоносы изменяют их на свой, например в 2007 году группа "предприимчивых" кодеров из Эстонии написали троян dnschanger, который за несколько лет заразил 4 млн машин по всему миру. Троян изменял системные настройки днс, что приводило к появлению рекламы на веб страницах (просто реклама, даже не фишинг). Это принесло создателям $14 млн (по 4$ с машины) + тюремный срок. Причем по решению суда пришлось в течение 7 месяцев поддерживать временные dns сервера по тем адресам, где располагались сервера мошенников. Если бы они это не сделали, то пользователи зараженных устройств одномоментно лишились бы доступа в сеть.
Но по умолчанию в режиме "автоматически" винда получает dns от роутера
Изменение DNS в роутере:
Если у нас есть доступ к роутеру (например через IoT ботнет) мы можем изменить в нем dns по умолчанию на свои. Так делали роутерные ботнеты Ttint и GhostDNS
А на какой сервер нам менять? Давайте поднимем свой dns сервер на той же vps с помощью dnschef.
Открываем ssh с vps:
Если не указаны какие-либо параметры, DNSChef будет работать в режиме прокси. Это означает, что все запросы будут просто перенаправлены вышестоящему DNS серверу (по умолчанию 8.8.8.8) и ответы от него будут возвращены обратно запрашивающему хосту.
Перед перехватом я изменю конфиг Apache сервера чтобы он редиректил на тестовый фишинг домен (чтобы был замочек ssl). Добавляем в конфиг строку
Redirect / https://xssis.ddns.net
Запускаем dnschef указывая, что нужно возвращать 185.104.248.247 для A (ipv4) записи домена xss.pro и слушать внешний интерфейс.
python3 dnschef.py --fakeip 185.104.248.247 --fakedomains xss.pro --interface 185.104.248.247
Указываем айпи нашего dns сервера в настройках роутера как DNS1 (DNS2 можно оставить пустым)
И пробуем зайти на xss.pro с любого подключенного устройства. Среди запросов к другим доменам видим что запрос с xss.pro перехвачен и отправлен ответ с нашим айпи на котором же у нас веб сервер
А затем жертву редиректит на фишинг доменRedirect / https://xssis.ddns.net
Похожим образом (только взламывая не роутеры, а модемы) в Бразилии в 2011-2012 годах было взломано 4,5 млн DSL модемов. Для этого было достаточно разослать спам со ссылкой на вредоносную страницу, которая взламывала модем и прописывала новый адрес днс сервера. Причем в этот раз мошенники не стали мелочиться с рекламой. На своих подставных днс серверах они подменяли адреса для всех крупнейших банков Бразилии https://securelist.com/web-based-attack-targeting-home-routers-the-brazilian-way/66358/
MITM/Перехват DNS запросов (DNS hijacking):
Сам по себе протокол dns не имеет никакого шифрования, все DNS запросы и ответы передаются в открытом виде, что означает, что любые промежуточные узлы могут перехватывать и просматривать, какие домены юзер запрашивает, и модифицировать ответы.
Многие (даже известные) интернет провайдеры и правительственные организации тоже могут перехватывать днс запросы своих юзеров. Провайдеры делают это для сбора статистики и для показа пользователям рекламы(так щас делают только всякие нищие индуские и азиатские провайдеры). Например, если пользователь пытается зайти на несуществующий сайт, провайдер вместо сообщения об ошибке, может перенаправить его на свою веб-страницу с рекламой. Правительственные организации (в Китае например) могут использовать перехват днс запросов для цензуры и для "безопасного перенаправления" пользователей на "рекомендуемые" правительством домены или вебстраницы. Американский провайдер Earthlink в 2006 году стал перенаправлять пользователей и информацию об их запросах рекламному партнеру barefruit. Особенно плохо это выглядело в том случае, если пользователь запрашивал несуществующий домен известного сайта, например, webmale.google.com. Пользователь видел рекламу и контент, которые не имели ничего общего с google.com в адресной строке. Подобная практика явно нарушает стандарт rfc для dns ответов и делает пользователей уязвимыми даже для xss атак, которые работают на поддомене для домена.
В рф пример - провайдер (когда кончились деньги или "сайт заблокирован на территории по решению кого то там блаблабла бубубубу...) или даже роутер (когда нет WAN выхода в интернет, или родительский контроль, или когда вайфай где то в заведении и требуется ввести данные кастомера...) могут перехватить запросы к dns серверам. Мы хотим так же, только допустим редиректить на наш фишинг.
Против mitm перехвата dns запросов есть несколько защит:
- DNS over HTTPS (DoH, самый популярный, используется браузерами при dns запросах к серверам которые его поддерживают, например google 8.8.8.8 и cloudflare 1.1.1.1. Наше счастье что большинство местных dns от провайдера досихпор работают без doh (а то так сложнее будет следить будет за юзерами))
- DNS over TLS (DoT, юзают некоторые программы)
- DNSCrypt (редко встречается, знаю что использует Яндекс Браузер)
- Любой VPN тоннель.
DNS спуфинг через ARP спуфинг:
Если у нас нет доступа к настройкам dns в админке роутера, но мы находимся в одной локальной/wifi сети? В таком случаем мы можем выдать себя за маршрутизатор в сети, и проксировать/изменять dns запросы. Существует большое количество способов попасть в локальную сеть или взломать чужой wifi (например через routerscan, wifite, уязвимости конкретных моделей и прошивок, перехват и брут пароля из хендшейка).
Конкретно под спуфинг dns через arp существует несколько готовых инструментов, например https://github.com/0x0be/mitm написан на python. Она сразу и arp спуфает, и dns подменяет.
Устанавливаете утилиту, подключаетесь к wifi, запускаете, указываете интерфейс и айпи жертвы в сети.
Правда умолчанию все dns запросы жертвы будут редиректиться на твой локальный айпи, на котором у тебя должен быть веб сервер или реверс прокси. Но можно в коде легко подправить, чтобы спуфались только запросы для конкретного домена (содержали допустим строку xss.pro) и указывали на другой ip, не атакующего, а vps.
Перехват dns запросов через nat/vpn ноду:
А если у мы не рядом с wifi, но у нас есть удаленный доступ промежуточному к узлу (например к коммутатору через сетевой бекдор) в цепочке узлов (hop'ов) через которую жертва выходит в интернет? Или мы сами являемся узлом (например у нас свой "бесплатный впн сервис"). Тогда если траффик проходит через нас, мы можем запустить dns спуфинг, например через старенькую софтину ettercap
Или его современный и более функциональный аналог bettercap https://www.bettercap.org/ (написан на go)
Я буду использовать его. Поддерживает все типы сетей, все протоколы, куча модулей и аддонов на гитхабе, авто, фото, вело, мото, ебля гребля и охота.
Проект вроде якобы кроссплатформенный, но на линукс его гораздо легче установить, т.к на винде могут быть проблемы с зависимостями
Сначала устанавливаем go https://go.dev/doc/install
Затем
Пробуем запустить, и если все нормально установилось вы увидите консоль с программой. У bettercap есть веб интерфейс https://github.com/bettercap/ui ,но это для сойджаков.
Пишем help и нам выводит список запущенных модулей
По умолчанию сниффает траффик на eth0, мы можем установить свой интерфейс командой
У меня просто траффик с windows 10 виртуалки проксируется через виртуалку kali.
Перед запуском модуля dns.spoof нам нужно установить домен для которого будут перехватываться dns запросы из огромного потока траффика, допустим xss.pro
Пишем
Далее устанавливаем айпи который будет возвращаться для A записи этого домена (наша vps с фишингом)
Запускаем
Пробуем на виртуалке с виндой в браузере открыть сайт xss.pro
Видим в логах что dns запрос перехвачен и bettercap сам резолвит наш фейк айпи, откуда как мы помним нас редиректит на фишинг с ssl замочком https://xssis.ddns.net
Но mitm перехват не сработает, если жертва использует dns не от местного провайдера, а в браузере от гугла или cf, так как они поддерживают dns over https, и браузер использует doh при работе с ними, а снифферы просто не увидят dns траффик
Отравление кэша легитимного dns сервера
Это сложная атака, которая после удачного исполнения позволит массово получать качественный траффик на фишинг/дрейнер из целого региона провайдера и конвертировать его в $.
Во 2 части, to be continued...
Для форума: xss.pro
Всем привет. Что происходит когда человек открывает сайт? Браузер должен отправить на ip сервера где хостится сайт (или на ip cdn типа cloudflare) GET запрос по протоколу http для получения запрашиваемой страницы сайта чтобы открыть ее в браузере. Где он узнает этот ip адрес?
1) Браузер сначала проверяет свой локальный кэш
2) Затем файл hosts (конфиг этого файла используется системным резолвером)
3) Если на устройстве ip нет или TimeToLive (ttl) истек, то делает запрос по DNS протоколу к "местному" DNS серверу (кто такой "местный" - расскажу позже).
4) Если в кэше dns сервера тоже нет актуального адреса (записи), dns сервер запрашивает его у других, вышестоящих dns серверов
Пример открытия xss.pro:
Устройство ищет по dhcp в локальной сети ближайший(местный) dns сервер(резолвер) и спрашивает запись A (ipv4) для xss.pro (лог из wireshark)
А затем когда получает ip из A записи посылает на него GET запрос с http заголовком Host: xss.pro
И в теле ответа получает код страницы которую надо отрендерить в браузере.
*По этому заголовку сервер или cdn определяет контент для какого сайта отдавать пользователю. Потому что на одном хостинге с одним ip может быть несколько сайтов. Если введете просто айпи сайта в адресную строку скорее всего ничего не получите. Можно таким образом хостить и отдавать жертвам несколько фишингов с одной нашей vps, в зависимости от заголовка
Архитектура dns за редким исключением остается неизменной с 1983 года. Каждый раз, когда человек хочет открыть сайт, браузер отправляет запрос с указанием домена на днс сервер, который в ответ отправляет необходимый айпи адрес. И запрос, и ответ на него передаются в открытом виде, без какого-либо шифрования. Это значит, что провайдер, админ сети или злоумышленники c mitm могут не только логгировать историю всех запрошенных сайтов, но и подменять ответы на эти запросы.
Что будет если жертва введет в браузер например binance.com или просто кликнет по любой ссылке на любу страницу на этом домене, и получит из локального кэша или в ответе dns вместо реального ip сайта - ip нашей подконтрольной vps? - жертва попадет на фишинг.
Фишинг кредов в wifi сети офиса компании частая точка входа в сеть корпу, есть апт кто таким образом добывает доступы
Фишинг через dns может быть точечным (направленным на одного/нескольких людей в локальной сети) или массовым фармингом траффика (через свой mitm узел/ iot ботнет/отравление кэша)
Вместе с кредами, 2fa и куки сессией так же сохраняйте в бд exit node айпи жертвы, чтобы подобрать прокси по подсети/городу для входа и не иметь проблем с фродом.
Теперь про сами dns атаки и их мое небольшое определение:
- Изменение DNS - атака, при которой устройство жертвы делает dns запрос к подконтрольному серверу злоумышленника, который перенаправляет интернет трафик жертвы на вредоносный хост вместо легитимного.
- Mitm/спуфинг - когда хакер перехватывает и изменяет незашифрованные dns запросы/ответы.
- Отравление dns кэша (dns poisoning) - когда мы загрязняем кэш легитимного dns сервера поддельными днс записями для домена (вместо реального айпи сайта в записях - айпи нашего хоста на котором поднят/или который редиректит на наш фишинг). При отравлении dns можно указать максимальный ttl наших записей - 2147483647 секунд, это 68 лет. В итоге dns сервер после нашей атаки будет хранить наш фишинг пока админ сервера не почистит кэш, или сам сервер принудительно не перезапросит свежие записи
Подготовка фишинга:
Перед тем как спуфать/загрязнять dns надо подготовить фишинг.
После перехода жертвы на наш сервер у нас будет два варианта продолжения атаки:
1) Моментально редиректить жертву на наш визуально похожий домен, чтобы отдавать контент по https и иметь замочек ssl слева от url, так как мы легко получим ssl/tls сертификат на подконтрольный нам домен. Найти незанятую доменную зону для слова можно здесь https://lab.xpaw.me/alldomainsearch.html
Но не рекомендую использовать популярные трейдмарки слова вроде binance, так как браузеры могут быстро автоматически накинуть кт (Красная Табличка, deceptive site ahead) за фишинг. Лучше используйте похожие символы (например blnance), panycode + клоакинг чтобы боты не чекали контент
2) Отдавать фишинг прямо на оригинальном домене, но через http, без ssl замочка. Так как мы не можем получить приватный ключ от чужого ssl сертификата и оригинального домена для подписи своих запросов.
Но плюс этого метода в том что не нужен клоакинг, и ваш фишинг никогда не попадет под бан/красную табличку, потому что его будут видеть только виктим юзеры, а гугл боты никак не смогут на него попасть, потому что у них будет открываться оригинальный сайт.
Мне лично нравиться больше первый вариант, с редиректом, т.к юзер увидев страшную надпись "Не защищено" может что нибудь заподозрить
Для начала я подниму простенький ленд фишинг страницы входа xss.pro на Apache на левой vps. Просто скачаю страницу входа и добавлю надпись "фишинг" чтобы вы могли отличить, что сейчас мы на фишинге.
В реальных атаках лучше использовать реверс прокси, всякие фреймворки для фишинга например gophish, evilginx3 или очень качественный клон
Теперь подменим айпи сайта на всех этапах поиска его устройством (из начала статьи), будем двигаться в том же порядке, от локального кэша к dns запросам
1) Браузер сначала проверяет свой локальный кэш
Кэш браузера может отравиться после получения отравленного dns запроса и остаться таким до его следущего обновления из легитимного dns. Если IP адрес уже кэширован (то есть недавно использовался), браузер может сразу использовать его, чтобы ускорить загрузку страницы. Посмотреть какие ip закешированны для каждого домена в гугл хроме можно введя chrome://net-internals/#dns ,в firefox about:networking#dns
Кэш браузера (допустим Google Chrome в Windows) храниться в C:\Users\%юзер%\AppData\Local\Google\Chrome\User Data\Default\Cache в каком то бинарном формате. Изменить этот кеш можно в любом hex редакторе открыв самый тяжелый файл в этой директории и поискав через ctrl + f (для этого не нужны админ права в отличии от редактирования hosts)
Также ip сайта можно указывать в burp suite, это будет тоже самое что кэш браузера (хотя работает скорее как системный резолвер) и проще для наших тестов. Открываем настройки settings, пишем в поисковой строке dns и добавляем запись с доменом xss.pro и айпи нашей vps (185.104.248.247) на которой поднят фишинг
Отключаем "безопасный dns сервер" если включено в настройках браузера (иначе может не сработать)
Вводим в адресную строку xss.pro, и у нас на легитимном домене открывается фишинг который мы подняли на vps
Правда без ssl/tls замочка (слева от url будет палевная надпись "не защищено"). Поэтому лучше редиректить на наш домен, типа xss.ls или xxs.is
2) Файл hosts
Указывает на хосты (ip) для конкретных доменов в формате "ip host", являясь конфигом для системного резолвера. Для редактирования требует админ прав C:\Windows\System32\drivers\etc\hosts
Часто используется чтобы заблокировать домены телеметрии и проверки лицензий софта всякими установщиками кряков, указав 0.0.0.0 domain.com
Раньше часто модифицировался Adware для показа рекламы. Я его трогать не буду так как для его изменения нужен доступ к устройству, а это не относится к сетевым атакам с dns.
Тут кстати ситуация непонятная, потому что иногда некоторые браузеры работают по правилам hosts только при недоступности dns сервера. То есть
1)сначала проверяют кэш браузера
2) затем отправляют dns запрос
3)и если ответа от резолвера нет - только потом используют айпи из hosts.
3) Если на устройстве его нет или ttl истек, то делает запрос по DNS протоколу к ближайшему DNS серверу
Предположим жертва давно не заходила на сайт, и срок годности ее кэш записи истек. Тогда браузер/устройство посылает dns запрос на ближайший dns сервер чтобы узнать айпи домена xss.pro.
А ближайший это какой? По умолчанию, если вы не используете vpn, ближайшим обычно считается тот который автоматически высылает провайдер при настройке PPPoE соединения в роутере. Посмотреть их можно зайдя в админку роутера в настройки сети или pppoe (их два, часто один в локальной сети NAT, другой запасной). Роутер отдает эти dns сервера по DHCP всем устройствам или сам перенаправляет на них dns запросы работая как dns relay.
Еще dns можно вручную указать в настройках сети в винде, здесь кстати некоторые вредоносы изменяют их на свой, например в 2007 году группа "предприимчивых" кодеров из Эстонии написали троян dnschanger, который за несколько лет заразил 4 млн машин по всему миру. Троян изменял системные настройки днс, что приводило к появлению рекламы на веб страницах (просто реклама, даже не фишинг). Это принесло создателям $14 млн (по 4$ с машины) + тюремный срок. Причем по решению суда пришлось в течение 7 месяцев поддерживать временные dns сервера по тем адресам, где располагались сервера мошенников. Если бы они это не сделали, то пользователи зараженных устройств одномоментно лишились бы доступа в сеть.
Но по умолчанию в режиме "автоматически" винда получает dns от роутера
Изменение DNS в роутере:
Если у нас есть доступ к роутеру (например через IoT ботнет) мы можем изменить в нем dns по умолчанию на свои. Так делали роутерные ботнеты Ttint и GhostDNS
А на какой сервер нам менять? Давайте поднимем свой dns сервер на той же vps с помощью dnschef.
Открываем ssh с vps:
Bash:
sudo apt install python3-pip
sudo pip3 install dnschef
git clone https://github.com/iphelix/dnschef.git
cd dnschef
sudo python3 setup.py installПеред перехватом я изменю конфиг Apache сервера чтобы он редиректил на тестовый фишинг домен (чтобы был замочек ssl). Добавляем в конфиг строку
Redirect / https://xssis.ddns.net
Запускаем dnschef указывая, что нужно возвращать 185.104.248.247 для A (ipv4) записи домена xss.pro и слушать внешний интерфейс.
python3 dnschef.py --fakeip 185.104.248.247 --fakedomains xss.pro --interface 185.104.248.247
Указываем айпи нашего dns сервера в настройках роутера как DNS1 (DNS2 можно оставить пустым)
И пробуем зайти на xss.pro с любого подключенного устройства. Среди запросов к другим доменам видим что запрос с xss.pro перехвачен и отправлен ответ с нашим айпи на котором же у нас веб сервер
А затем жертву редиректит на фишинг доменRedirect / https://xssis.ddns.net
Похожим образом (только взламывая не роутеры, а модемы) в Бразилии в 2011-2012 годах было взломано 4,5 млн DSL модемов. Для этого было достаточно разослать спам со ссылкой на вредоносную страницу, которая взламывала модем и прописывала новый адрес днс сервера. Причем в этот раз мошенники не стали мелочиться с рекламой. На своих подставных днс серверах они подменяли адреса для всех крупнейших банков Бразилии https://securelist.com/web-based-attack-targeting-home-routers-the-brazilian-way/66358/
MITM/Перехват DNS запросов (DNS hijacking):
Сам по себе протокол dns не имеет никакого шифрования, все DNS запросы и ответы передаются в открытом виде, что означает, что любые промежуточные узлы могут перехватывать и просматривать, какие домены юзер запрашивает, и модифицировать ответы.
Многие (даже известные) интернет провайдеры и правительственные организации тоже могут перехватывать днс запросы своих юзеров. Провайдеры делают это для сбора статистики и для показа пользователям рекламы(так щас делают только всякие нищие индуские и азиатские провайдеры). Например, если пользователь пытается зайти на несуществующий сайт, провайдер вместо сообщения об ошибке, может перенаправить его на свою веб-страницу с рекламой. Правительственные организации (в Китае например) могут использовать перехват днс запросов для цензуры и для "безопасного перенаправления" пользователей на "рекомендуемые" правительством домены или вебстраницы. Американский провайдер Earthlink в 2006 году стал перенаправлять пользователей и информацию об их запросах рекламному партнеру barefruit. Особенно плохо это выглядело в том случае, если пользователь запрашивал несуществующий домен известного сайта, например, webmale.google.com. Пользователь видел рекламу и контент, которые не имели ничего общего с google.com в адресной строке. Подобная практика явно нарушает стандарт rfc для dns ответов и делает пользователей уязвимыми даже для xss атак, которые работают на поддомене для домена.
В рф пример - провайдер (когда кончились деньги или "сайт заблокирован на территории по решению кого то там блаблабла бубубубу...) или даже роутер (когда нет WAN выхода в интернет, или родительский контроль, или когда вайфай где то в заведении и требуется ввести данные кастомера...) могут перехватить запросы к dns серверам. Мы хотим так же, только допустим редиректить на наш фишинг.
Против mitm перехвата dns запросов есть несколько защит:
- DNS over HTTPS (DoH, самый популярный, используется браузерами при dns запросах к серверам которые его поддерживают, например google 8.8.8.8 и cloudflare 1.1.1.1. Наше счастье что большинство местных dns от провайдера досихпор работают без doh (а то так сложнее будет следить будет за юзерами))
- DNS over TLS (DoT, юзают некоторые программы)
- DNSCrypt (редко встречается, знаю что использует Яндекс Браузер)
- Любой VPN тоннель.
DNS спуфинг через ARP спуфинг:
Если у нас нет доступа к настройкам dns в админке роутера, но мы находимся в одной локальной/wifi сети? В таком случаем мы можем выдать себя за маршрутизатор в сети, и проксировать/изменять dns запросы. Существует большое количество способов попасть в локальную сеть или взломать чужой wifi (например через routerscan, wifite, уязвимости конкретных моделей и прошивок, перехват и брут пароля из хендшейка).
Конкретно под спуфинг dns через arp существует несколько готовых инструментов, например https://github.com/0x0be/mitm написан на python. Она сразу и arp спуфает, и dns подменяет.
Устанавливаете утилиту, подключаетесь к wifi, запускаете, указываете интерфейс и айпи жертвы в сети.
Правда умолчанию все dns запросы жертвы будут редиректиться на твой локальный айпи, на котором у тебя должен быть веб сервер или реверс прокси. Но можно в коде легко подправить, чтобы спуфались только запросы для конкретного домена (содержали допустим строку xss.pro) и указывали на другой ip, не атакующего, а vps.
Перехват dns запросов через nat/vpn ноду:
А если у мы не рядом с wifi, но у нас есть удаленный доступ промежуточному к узлу (например к коммутатору через сетевой бекдор) в цепочке узлов (hop'ов) через которую жертва выходит в интернет? Или мы сами являемся узлом (например у нас свой "бесплатный впн сервис"). Тогда если траффик проходит через нас, мы можем запустить dns спуфинг, например через старенькую софтину ettercap
Или его современный и более функциональный аналог bettercap https://www.bettercap.org/ (написан на go)
Я буду использовать его. Поддерживает все типы сетей, все протоколы, куча модулей и аддонов на гитхабе, авто, фото, вело, мото, ебля гребля и охота.
Проект вроде якобы кроссплатформенный, но на линукс его гораздо легче установить, т.к на винде могут быть проблемы с зависимостями
Сначала устанавливаем go https://go.dev/doc/install
Затем
go install github.com/bettercap/bettercap@latest Пробуем запустить, и если все нормально установилось вы увидите консоль с программой. У bettercap есть веб интерфейс https://github.com/bettercap/ui ,но это для сойджаков.
Пишем help и нам выводит список запущенных модулей
По умолчанию сниффает траффик на eth0, мы можем установить свой интерфейс командой
bettercap -I tun0 , это может быть любой прокси/vpn/узел в виде интерфейса с которого уходит/приходит траффик.У меня просто траффик с windows 10 виртуалки проксируется через виртуалку kali.
Перед запуском модуля dns.spoof нам нужно установить домен для которого будут перехватываться dns запросы из огромного потока траффика, допустим xss.pro
Пишем
set dns.spoof.domains xss.proДалее устанавливаем айпи который будет возвращаться для A записи этого домена (наша vps с фишингом)
set dns.spoof.address 185.104.248.247Запускаем
dns.spoof onПробуем на виртуалке с виндой в браузере открыть сайт xss.pro
Видим в логах что dns запрос перехвачен и bettercap сам резолвит наш фейк айпи, откуда как мы помним нас редиректит на фишинг с ssl замочком https://xssis.ddns.net
Но mitm перехват не сработает, если жертва использует dns не от местного провайдера, а в браузере от гугла или cf, так как они поддерживают dns over https, и браузер использует doh при работе с ними, а снифферы просто не увидят dns траффик
Отравление кэша легитимного dns сервера
Это сложная атака, которая после удачного исполнения позволит массово получать качественный траффик на фишинг/дрейнер из целого региона провайдера и конвертировать его в $.
Во 2 части, to be continued...
Вложения
Последнее редактирование модератором:
. Но можешь через sslstrip попробовать перевести коннект на http без ssl/tls
