Pull to refresh

Comments 163

Обожаю красное на синем, так приятно читать.

Простите, но как заставить жертву использовать наш собственный DNS сервер?
Запрос от жертвы так или иначе приходит на DNS сервер, контролируемый владельцем сайта. Можно генерировать каждому пользователю отдельный поддомен домен, чтобы результаты DNS запроса не шарились для разных пользователей.
Это вам свой собственный DNS-сервер придётся реализовывать, потому что стандартный будет всегда отдавать «честную» информацию, не делая никаких подмен. А чтобы потом это всё запустить, нужен как минимум VPS, тут обычный хостинг не подойдёт.
[sarcasm]
Да уж… Вот это проблеееема… Стандартный хостинг не подойдёт. Можно спать спокойно.
[/sarcasm]
Даже на обычном хостинге, вовремя меняя A-записи вручную, можно так сделать.
А уж хелпер к PowerDNS написать не дольше, чем javascript для этой атаки.
Вручную — это руками в панели управления? Такое себе занятие. А автоматизировать этот процесс там, вроде бы, не дадут.

А уж хелпер к PowerDNS

А что это? Я говорил про обычный веб-хостинг с ISP Manager или похожей панелью управления.
Например, для ISP DNSmanager есть API.
bash скрипт в cron, который переписывает зону и обновляет честный KnotDNS, тоже сойдёт. Цены на подходящий хостинг начинаются, кажется, с 90 рублей в месяц.
bash скрипт в cron, который переписывает зону и обновляет честный KnotDNS

Это точно сработает на обычном хостинге?.. cron, который я знаю (как функция в панели), сделан для запуска php-скриптов (хотя может вы и правы, и bash-скрипты исполнять тоже можно, но мне почему-то кажется, что это будет запрещено политиками безопасности). Но даже в этом случае, нам нааверное нужно знать, какой именно DNS сервер использует хостер. Это можно как-то узнать без помощи техподдержки? Опять же, должно быть всё настроено так, чтобы файл конфигурации DNS сервера допускал модификацию пользователем, от которого запускается cron и bash интерпретатор (или чтобы DNS сервер допускал модификацию зон по команде, принятой от нашего скрипта — хотя раз он принимает такие запросы от ISP Manager, то чего бы не принять и от другого процесса, наверное). Тут надо уже у админов спрашивать, которые шарят в линуксе.
Очень непривычно, когда обычным хостингом называют shared. Самые дешёвые VPS уже не 100MHz с 16Мб памяти как 10 лет назад. VPS и есть обычный хостинг IMHO.

На shared, кажется, любой форум и любой WordPress научились cron симулировать, но если есть работающий в браузере скрипт, то проще XHR из браузера сделать.

К услугам нищебродов DynDNS, в котором можно явно указать IP, а также Яндекс.ПДД и т.п.
Так нам нужно менять отдаваемый IP по таймеру. DynDNS — это вроде немного не для этого сделано (для тех, у кого сервер на динамическом IP). Там надо API дёргать всякий раз, когда IP поменялся. То есть всё равно какой-то сервис писать придётся для такой атаки.

На shared, кажется, любой форум и любой WordPress научились cron симулировать

Вот это не понял. Каким образом?

Самые дешёвые VPS уже не 100MHz с 16Мб памяти как 10 лет назад. VPS и есть обычный хостинг IMHO.

Характеристики повыше, а цены всё так же кусаются. Тем более, хороший сервис у зарубежных провайдеров, а там цены в долларах или евро. Они и раньше-то были не особо низкими, а с тех пор ещё и курс скакнул. Обычный хостинг я могу найти за 80-100 рублей в месяц, если постараться, максимум за 120. VPS — от 380-400 сейчас (самый фиговый, отечественный). Нормальный — где-то 120-150 долларов в месяц, кажется. Но надо пересмотреть цены, давно не изучал рынок.
Если A запись можно поменять, то должно годиться. На что поменять, в API есть. В локалке Мегафона 10е DynDNS IP при этом работали, и 192м почему бы не работать тоже.

VPS — от 380-400 сейчас (самый фиговый, отечественный).


Самый-самый фиговый 90, а не так, чтобы очень фиговый 200-250 начинается. OpenVZ вполне доступные.

И для чего нормальные? Если жырную джаву гонять, ну да, джависты должны страдать. Платить и платить. С OpenVZ джаву попрут. Что трасирующая сборка мусора, что майнинг, одинаково расточительное использование вычислительных ресурсов. Софт, который тут уже успели насоветовать, этой проблеме не подвержен, ему роутеров хватает, не то, что современных хостингов.

У зарубежных хостингов именно самых дешёвых, кажется, нет, но те, которые у них самые дешёвые, временами предлагают сказочные характеристики. Есть один латвийский OpenVZ с 512Мб RAM (на OpenVZ нельзя ходить в своп), но 1Тб HDD. Есть германский за 7 евро в месяц с 6Гб RAM, 2 ядра, KVM, 500Гб HDD. Оверселлинг, да, но, кажется, всё работает вот уже который год. Со всеми скачками курса не знаю отечественного, чтоб мог так же, и чтоб как-то это всё же работало.

Вот это не понял. Каким образом?


Если сайт не оставляют надолго в покое посетители или хотя бы поисковики, то сделать блокировку через базу данных и выполнить код в примерно необходимое время возможно. Куча движков это умеет.
Не понял, зачем тут блокировка какая-то)
Вы говорите о довольно простом механизме — сохранять куда-нибудь время исполнения задачи и саму задачу, и запускать это всё по достижению заданного времени — но вместо крона сам PHP-скрипт инициируется посетителем сайта. Можно это в скрытом айфрейме сделать или через XHR, чтобы у юзера не «висела» основная страница. Да, это можно, но это не совсем «крон» :)

Тут вопрос в другом — если нам нужна системная команда, а не запуск ещё одного PHP-скрипта, то не все системные команды могут быть разрешены настройками безопасности (даже на уровне php.ini), если у нас не VPS.

И для чего нормальные? Если жырную джаву гонять, ну да, джависты должны страдать. Платить и платить. С OpenVZ джаву попрут. Что трасирующая сборка мусора, что майнинг, одинаково расточительное использование вычислительных ресурсов. Софт, который тут уже успели насоветовать, этой проблеме не подвержен, ему роутеров хватает, не то, что современных хостингов.

Проблема не только в джаве. Я вот, например, поднимал в своё время Icecast2 и PHP-FPM для своих нужд. И там автор книги по FreeBSD настаивал на мысли, что «правильнее компилять самому пакеты из исходников, убирая все лишние модули и подключая нужные, чем ставить готовый бинарник». А компиляция — процесс очень тяжёлый. И на медленном VPS он будет длиться часы, буквально.

Есть германский за 7 евро в месяц с 6Гб RAM, 2 ядра, KVM, 500Гб HDD

Очень щедрые характеристики за такую сумму)
Я когда последний раз искал VPS для какого-то проекта, это было весной 2015-ого, вроде. На эту компанию не натыкался. Вы её название не запомнили

UPD: сейчас бегло поискал в гугле. Одна из ссылок в первой двадцатке (европейский провайдер): www.vps.net/products/instant-servers

17$ в месяц. Такое себе… Причём ресурсы тоже не фонтан.
Блокировка чтоб race condition не было. Что-нибудь вроде «обновить timestamp и проверить, удалось ли это сделать». Какому потоку удалось, тот и делает регулярную задачу. Для того, чтобы по HTTP API дёргать DynDNS или Яндекс.ПДД, нужно только право на исходящий HTTP.

Про хостинги


Правда, вместо былого 500Гб за 7 евро теперь 300 за 4 или 700 за 8.

И отечественный OpenVZ минимально не с 250 начинается, а с 150.
Если жертва заходит на ваш домен, и он прописан в вашем собственном DNS то временем TTL управляете вы. Я встречал DNS-сервера, которые игнорируют время кэширования и кэшируют данные по каким то своим внутренним настройкам, но по моему опыту это скорее исключение.
Провайдерские DNS иногда так делали, что ожидаемо вызывает проблемы у некоторого меньшинства пользователей (например с DynDNS), поэтому такое должно встречаться нечасто.
Если на один и тот же ресурс зайти через день-два, когда кончится DNS провайдера, всё равно сработает. Вероятность чуть меньше, да.
В самом домене прописать NS-записи типа ns1.hacker.com, ns2.hacker.com и поднять там свой DNS сервер.
Вот ПО для автоматизированной атаки уязвимых реализаций UPnP на роутерах, которое использует DNS Rebinding: github.com/filetofirewall/fof
Накиньте ещё в список жертв уязвимости админку i2p, слушающую на localhost.

Полагаете, есть энтузиасты I2P, которые не ставят пароль на админку?

Вполне возможный сценарий.

Никто не ставит пароль на админку I2P. Никто *)

Теперь и я ставлю. Учитывая, что по некоторым причинам защита от ребиндинга у меня сознательно выключена.
UFO just landed and posted this here
Тогда уж все админки на localhost, например syncthing, можно файлы пользователя захватить.

Плюсом туда же локально развернутые базы данных, например тот же MySQL 3306, или часто встречал Firebird (типа sqlite) с тоже открыто слушающим портом и дефолтными логином пасс sysdba:masterkey.

Спасает ли от атаки на роутер использование нетипичных адресов для внутренней сети, типа 192.168.223.47?
В принципе да, но их можно перебрать, так что защита так себе, чуть больше времени нужно не более того. Плюс атака на локалхост в любом случае актуальна.
Ну, адреса типа 10.137.71.хх задолбаетесь искать. Главное, не палиться с X-FORWARDED-FOR…
Если IP машины 10.137.71.хx то скорее всего IP маршрутизатора 10.137.71.1.
Try failed, 35143 more addresses to check.

Можно же ещё делать трюк сл вставкой картинки img src ="http://10.137.71.2:80/image.jpeg", и если картинка загрузилась быстро, значит кто-то на том конце ответил "ошибка", или принудительно разорвал соединение. Если картинка грузилась долго, то скорее всего сработал timeout. Если мы целимся на конкретный сервис, то заранее можем узнать как он себя ведёт при таком запросе картинки.

Я про то, что количество /24 подсетей внутри 10.0.0.0/8 достаточно велико, и перебирать первый адрес не самая быстрая затея.
Кажется, можно ещё через a:visited css относительно быстро пропалить, куда в админку ходит админ. Хотя если он туда хоть иногда ходит, то, наверное, с паролем дело не заладится.

Это вроде бы не должно уже работать (иначе любая страничка может угадать все посещенные порносайты).
Rebinding здесь не поможет, потому что юзер не ходил на pew.hacker.com/admin.php, даже если оно сейчас резолвится в роутер.

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

И юзер ходит по IP, а через a:visited, поняв, на какой IP, можно его-то как раз сразу и забиндить.
Против зондирования WebRTC нет
Я так понимаю уязвимость не в подделке адреса через dns, а в локальных api не требующих аутентификации.
На самом деле, самая главная проблема в том, что кто-то решил, что 192.168.x.x — более «безопасно», чем интернет. Этот аргумент часто приводят в споре об ipv6, мол, «а как же NAT, за которым все защищены». Вся конструкция «локальных сегментов», которые вроде бы в интернете, но нет, полна дыр и неконсистентности.

(Вот атака на localhost — это да, это сурово — не верьте localhost, просто не верьте).

Оно действительно более безопасно — в том смысле, что защита в любом случае должна быть многослойной, и NAT честно добавляет ещё один слой, усложняющий доступ.


Боюсь, честный https плюс авторизация по случайным паролям для всех локальных сервисов/устройств — пока что фантастика, причём в стиле рассказа про хакера и столовую. Скорее всего в таком стиле это в принципе никогда не реализуют, слишком неудобно будет пользоваться, и такие "безопасные" устройства купят 2.5 параноика.

Предполагается, что в мире ipv6, не будет никакого «NAT»а и все будут голой задницей в интернет (как и сейчас, но сейчас есть иллюзия). Не хочешь голой задницей? Ставь файрвол.

А он вообще наступит, этот мир IPv6? В смысле, при нашей жизни? Потому что пока не начнут массово появляться IPv6-only сервисы, причём достаточно популярные и нужные обычным юзерам, текущее состояние (не)поддержки IPv6 может сохраняться неопределённо долгое время.

Цены на ipv4 на межпровайдерском рынке продолжают расти. Это как выгибание пластинки. До определённого предела прогресс минимальный, пока не происходят необратимые изменения (и все, кто не успел, торопятся догнать).

Сейчас вся индустрия проедает запасы ipv4. Они ещё есть, куда большие, чем ожидал RIPE NCC и IANA, но очевидно, что примерно 3 миллиарда адресов не достаточно для обслуживания 7.5 миллиардов человек (нам же не только и не столько человекам адреса надо выдавать, а железкам и серверам).

Если что, вот нерозданные адреса. Это не то, что нахомячили провайдеры, но всё равно тренд понятный:


Обратите внимание, даже непочатый в 14ом году AFRINIC уже похож на RIPE, а сам RIPE, хоть и самый экономный, но тоже сильно дальше 21ого не пытается. Если верить вот этим товарищам (https://ipv4marketgroup.com/broker-services/buy/), то цена колеблется от 26 до 17 баксов за IP (в зависимости от размера цены). И это довольно много (/24 — $6.5k, /16 — больше миллиона баксов).
В ЮВА уже наступил, судя по моему опыту. Цепляешься к публичному вай-фаю где-нибудь в тошниловке и тебе дают белый ipv6 и серый ipv4.
В Китае трафик в сетях IPv6 дешевле (или просто бесплатен), чем в IPv4. Университеты и студенты массово используют IPv6 only, чтобы платить меньше. Будущее наступило, просто еще не везде.

IPv6 only это как-то сильно жёстко, и за пределами ихнего файрвола не прокатит. Банальный пример: на habr.com нет AAAA записи. В мировом масштабе та же фигня: IPv6 нет у 70% из Alexa Top 1000, и у 80% из Alexa Top 1000000 сайтов.

Самая мякотка в том, что это не атака на нат. Это атака на проникновение внутрь периметра фаервола. NAT traversal идёт бонусом

Вообще, это интересно, да. Хороший файрвол должен просто запрещать ответы от DNS (на входе в сеть) с адресами из защищаемой сети (и тут уже не важно, белые они или серые), за вычетом SOA/NS'ов.

А такие вообще есть? iptables такого, вроде бы, не умеет. А то мы договоримся до волшебных файрволов, которых никто не видел, но которые "должны" блокировать 100% любых атак на защищаемую сеть.

ASA and FWSM обещают такое делать:

The Cisco ASA, PIX and FWSM Firewalls have several features that can be utilized to minimize attacks against the DNS protocol. The following subsections will provide an overview of these features and the capabilities they can provide.

DNS Guard
Beginning with software release 7.0(5) for Cisco ASA 5500 Series and Cisco PIX 500 Series, and software release 4.0 for the FWSM the DNS guard function can be controlled through thedns-guard global configuration or the dns-guard parameters submode command for policy-map type inspect dns. For Cisco ASA 5500 and Cisco PIX 500 Firewalls that are running releases prior to 7.0(5) and for the FWSM Firewall releases prior to 4.0, the DNS guard function is always enabled, and it cannot be configured through this command. The configuration of this feature, when configurable, will be detailed later in the feature configuration section.

Сам не щупал, не скажу.
Да, есть. dnsmasq по дефолту, кажется, так настроен. Но он точно это умеет. И во многих нестандартных прошивках стоит именно он.

И могу сразу предложить антидот. Во всяких TP-LINK есть волшебные адреса, которые типа заменяют IP. И у TP-LINK их домены прокисают, а они ещё новые покупают, надо список поддерживать постоянно, если прямо хочется заморочиться. Также за счёт всяких NetBIOS есть шанс отрезолвить dlink.workgroup, но это не точно.

Так вот, если вместо A 192.168.0.1 отдать CNAME, дальше оно отрезолвится на роутере «куда надо» в обход безопасного, стоящего после роутера DNS.
в каком месте dnsmasq — фаервол?
Сделать можно и в общем-то несложно: перенаправляем iptables ns-трафик на собственный сервер, на котором и разруливаем.

Собственный сервер и так анонсируется по DHCP, так что здесь роль файрвола не в защите от DNS rebinding, а в блокировании доступа к сторонним DNS в обход своего, в чём нет необходимости пока кто-то не попытается "выстелить себе в ногу" прописав себе ручками внешний DNS — но таких защищать обычно смысла нет, они с тем же успехом могут и VPN поднять наружу, и тогда такое перенаправление DNS-трафика в iptables уже не спасёт.

Такие вещи, по идее, давно известны, как и то, что к ресурсам внутри LAN следует относиться так же, как если бы они были выставлены голой ж. в интернет по белому IP. Хотя бы потому что атаки непосредственно на LAN тоже ивестны, или, например, может произойти заражение внутреннего хоста вирусом или же кто-то (в том числе несанкционированно) подключится к LAN. Если кто-то не запаролил роутер в надежде что на него никто изнутри не полезет, то он оптимист.
Много видов железа не умеет нормально паролиться. У меня есть NAS на unRaid. Запаролить интерфейс можно, но доступ к файлам остаётся. Если запаролить и доступ, то винда начинает время от времени спрашивать пароль снова. Через месяц это так задалбывает, что хоть всё выбрасывай. А ещё консоль отдельно закрывать нужно.
Отдельно упомяну 3D принтер на основе OctoPrint. При закрытии паролем он теряет самую удобную функцию — печать по сети прямо из слайсера.
Всякие вай-фай лампочки тоже мало заморачиваются безопасностью. Так что это не выход: LAN должен быть безопасным.
Помогает. До поры. Проблема в том, что если попытаться обратится к сетевому диску, когда NAS выключен или уснул или сеть упала, винда пишет «нет такого устройства» и сразу забывает пароль. После включения NAS нужно заново вбивать пароль.
Наверное, это можно вылечить настройками в реестре. Но до прочтения этой статьи мне и не нужно было ставить пароль. Я пробовал это сделать для защиты от малвари, но в итоге защитился иначе — теневой копией на самом NASе через btrfs snapshot. Так что вопрос с безопасностью LAN нужно решать сразу целиком, я не хочу разводить в своём хозяйстве бюрократию как на границе (с дырами как там же).

На самом деле самая главная проблема в том, что кто-то решил, что выполнять что-то на машине клиента — это достаточно безопасно, если это "что-то" немного в чем-то ограничить.

Либо с паролями по умолчанию, либо с межсессионными куками авторизации, либо тупом иот, где на авторизацию не хватило мозгов контроллера, либо просто с дырявыми прошивками.
И да, на 127.0.0.1 обычно куча всего висит без авторизации, но с ограничением по источнику.
Проверка заголовка Host устройством (и, между прочим, даже обычным сайтом) снимает кучу проблем, в том числе эту. Видел хорошие роутеры, которые отдают 302, чтоб по IP к ним заходили, а не как-то иначе.

Правильно ли я понял что CSP и CSRF защиты в веб-сервере устройства достаточно чтобы закрыть такого рода уязвимость?

CSP на дешманском домашнем маршрутизаторе? Да вы шутите.

Немалая часть дешманских домашних роутеров имеет существенно более дубовый, но очень эффективный механизм защиты: фильтрация ответов внешних dns, попадающие в rfc6890

Расскажите чайнику, а как это проверить? А то я тут вполне испугался. У меня в сети несколько IoT девайсов, не умеющих никакой авторизации.
nslookup privatenet.zolg.ru
nslookup localhost.zolg.ru

Цепочка из Cisco — AD — Zyxel пропустили "неправильный" ответ. Как же всё печально.

UFO just landed and posted this here
а что мешает заставлять пользователя делать запрос на адрес вроде 192.168.х.х. напрямую, без плясок с DNS

Запрос отправить можно. Как ответ прочесть без валидного CORS?
UFO just landed and posted this here
Браузер не позволяет отправлять запросы к внешним сайтам, если они не возвращают правильные заголовки CORS. Например, попробуйте опубликовать Ваш скрипт на jsbin.com или jsfiddle.net, и отправьте запросы к локальному серверу, и увидите, что такие запросы блокируются браузером. А если не блокируются, скорее всего Ваш локальный всегда возвращает заголовок Access-Control-Allow-Origin:*.
Не совсем так. Запрос уйдет и будет обработан на стороне веб сервера. Браузер заблокирует только чтение ответа, если в заголовках нет валидного CORS.
Думаю, Вы ошибаетесь. К слову, если бы это было так, то все бы использовали это для CSRF атак.
Используют)
Как браузер определит можно ли слать запрос без получения ответа от сервера?
С более сложными (если например надо менять content-type на application/json) — сначала отправляется «preflight request» методом OPTION для получения разрешения на отправку основной части запроса. Для обычных post/get такого не делается.
Ха! Спасибо за уточнение. Не знаю почему, но я подумал, что preflight запрос будет предупредить браузера о проблеме и не позволит отправить запрос :(
Зато сервер может не выполнить запрос в случае неправильного Referer. Правда, это нужно реализовывать на уровне бизнес-логики, да и смысла нет: Referer легко подделать.

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

Вот здесь https://developer.mozilla.org/en-US/docs/Web/HTTP/Cors можно почитать подробнее.
Если кратко, "простые" запросы выполняются сразу, просто к ним добавляет ся заголовок Origin, и проверяется, что сервер ответил корректным Access-Control-Allow-Origin

Итак, давайте резюмируем вышесказанное:
  • Пользователь посещает сайт, получая реальный IP-адрес и короткий TTL
  • Находясь на сайте, браузер делает обращения к тому же домену, где находится пользователь. Как только истекает время жизни кэша, браузер снова запрашивает IP домена.
  • Далее наш DNS-сервер выдает вместо настоящего адреса, IP-адрес внутреннего сервиса (в нашем случае – роутера)
  • После запрос идет по домену на роутер, а результат нам отправляет подгруженный заранее пользователем javascript.

Что-то я не совсем понимаю, как это работает, в частности четвёртый шаг. Как скрипт может отправить нам результат на pew.hacker.com, если тот уже указывает на IP-адрес роутера, полученный на третьем шаге? Разве запрос с отправкой результата не уйдёт опять на роутер? Или здесь схема сложнее и скрипт сначала сохраняет данные на клиенте, а через 59 секунд новый DNS-запрос снова возвращает IP-адрес злоумышленника и только потом скрипт отправляет ему собранную полезную нагрузку?

Мы можем отправить результат на другой домен

Эм, но разве браузер не заблокирует междоменный запрос? Суть ведь этих плясок именно в том, чтобы протокол, домен и порт не менялись. Да и в статье упирается, что запрос отправляется на тот же самый домен:


На следующем этапе сервер отвечает HTML-страницей с javascript кодом, обращающимся на наш же домен.
На другой поддомен того же домена не заблокирует.
почему тогда нельзя слать запросы со странички pew.hacker.com на что-нибудь вроде localhost.pew.hacker.com без всякого rebinding?

Отправлять данные мы можем (get-ом так точно, хотя в принципе можно и post-форму скрафтить в iframe-е), читать не можем только.

А почему именно в iframe-е, чтобы не видно было?
Чтобы всю страницу не обновлять, и оставить канал обмена данными (с тем же ребинднутым pew.hacker.com) на основной странице.
А, точно. Тупанул.

А я сейчас вот что подумал: если пользователь после ребинда нажмёт F5, то будет эпик-фейл, он увидит админку роутера (ну или того, куда его там ребинднули)? Ведь шансы на это ненулевые?
UFO just landed and posted this here
А вот интересно, есть какие-то базы, куда собирают жалобы на мошеннические сайты? Раньше вроде в IE была опция какая-то в контекстном меню, типа «отправить жалобу на сайт». А потом эти сайты могли бы в блэклисты браузеров попадать после модерации жалоб.
У старого IE и у HTML5 IFRAME есть какие-то флаги, чтоб он заткнулся и молчал в тряпочку, не мог ни window.top.location поменять, ни alert'ом бомбануть, ни пароль спросить.
Ну свой-то location он поменять сможет, отправив форму

Jsonp в помощь хакеру. Просто генерирует на странице


document.write('')


Дёшево, сердито, надежно

Эх как я люблю хабр с мобилы… и не поправить.


В общем генерируем тег script с src который является гет запросом. Можем даже получить ответ в виде исполняемого скрипта

Это контролирует сервер, может ли ему отправлять корс так что если сервак наш то проблем нет.

Скрипт запущен на домене pew.hacker.com. Он получает чувствительные данные, отправляя запрос на pew.hacker.com (IP которого теперь ведёт на локальную сеть), а результат сбора отправляет на report.hacker.com (IP которого ведёт на сервер злоумышленника). Запрос на report.hacker.com возможен, если report.hacker.com добавит в ответ заголовок access-control-allow-origin: *.

UFO just landed and posted this here

Как можно защититься от такой атаки?
Я вижу такой вариант:
Свой DNS сервер, который имеет белый список доменов, которые могут резолвится в IP из приватных диапазонов (192.168.0.0/16, 10.0.0.0/8 и т. д.). Остальные резолвы, приходящие из внешних источников он игнорит и не передаёт конечному устройству.

На маршрутизаторах с прошивкой OpenWRT по умолчанию фильтруются ответы для приватных диапазонов. Это штатная функциональность DNS и DHCP-сервера dnsmasq, параметр --stop-dns-rebind.
Недостаток в том, что некоторые провайдеры с локальной сетью отдают IP-адрес из внутренней сети на некоторые домены, и такие домены перестают открываться вовсе.
В прошивках Asus есть опция Enable dns rebind protection (или это Merlin добавил?). Правда, если ее включить, дофига сайтов перестаёт работать. Там их полный лог набивается.
Дофига сайтов отказываются работать, если не могут домогаться до LAN?
В родных не видел, а Merlin это таки форк, там много чего добавлено.
Очень плохо то, что если используется alias=11.22.33.44,192.168.10.10 (превращение внешнего айпишника во внутренний), то stop-dns-rebind стопает собственноручно подменённую запись.
Отвечу самому себе, вдруг у кого-то тоже будет подобная ситуация.
Опция rebind-domain-ok=/domain1/domain2/domain3/ позволяет разрешить некоторым доменам иметь локальные адреса. И хорошо еще то, что не надо указывать поддомены, они тоже будут работать.
Недостаток в том, что некоторые провайдеры с локальной сетью отдают IP-адрес из внутренней сети на некоторые домены, и такие домены перестают открываться вовсе.

У dnsmasq есть опция --rebind-domain-ok (--rebind-domain-ok=/домен1/домен2/домен3/), позволяющая явно указать домены, для которых защита от ребиндинга будет отключена.
UFO just landed and posted this here
Для этого на роутерах (не всех, конечно же) есть гостевые сети, с отдельным паролем, из которых не видно хосты, находящиеся в основной сети. Хотя, конечно, все еще видно сам роутер…
UFO just landed and posted this here
Но всё это бесполезно, если используются локальные прокси.

Чем они помешают? Я не очень понял проблему.
UFO just landed and posted this here
Если прокси на другом хосте, а ещё лучше — в другой подсети, то атака переносится на хост или подсеть прокси.
UFO just landed and posted this here
noscript вроде проверяет и блокирует локальный xss по айпи-адресам (локалхоста и локальных сеток), т.е. смотрит куда резолвится домен
хотя точно не помню уже, могу ошибаться в деталях
Ну если noscript (или соотв. настройкой браузера) пользоваться, то и вредоносный js может не сработать…
Если конечно моск включать и не вносить в доверенные/исключения что попало, даже если сильно хочется ;)
>>Ни для кого не секрет, что многие рядовые пользователи не меняют стандартные пароли от админ-панелей своих роутеров.
По моему это уже из области фантастики. Сейчас самый захудалый роутер, как только любой юзверь пытается «сам настроить» сходу через мастера настройки вопит «смени пароль». Или не?
Вы так говорите, как будто людей интересует какой-то пароль в момент, когда они пытаются настроить доступ в интернет, потому что срочно надо отправить презентацию / фотки / отчет. Ну или как будто возвращаются потом, чтобы сделать все как надо.
Что значит «срочно отправить»?.. Настройка роутера происходит буквально один раз в жизни (пока он не сломается). Обычно это целое событие, особенно для не-айтишника.
На некоторых моделях визард не даёт перейти к следующему шагу пока не сменишь пароль.

А я смотрю вы оптимист. Зайдите как нибудь на scanhub.shodan.io
Там не только роутеры в интернет торчат с admin:admin, но и айпи камеры, факсы, и прочая IoT херня от наших китайских колег.

Уметь то умеют, проблема в том что не сферический домашний пользователь о настройках и пароле к роутеру забудет через пару дней если не часов, сразу как только корректно настроит и не будет трогать месяцами. только пыль протирать.
И полностью согласен с комментарием popov654.

Дома зухель простенький 5 лет оттарабанил, как установил с дефолтными настройками так и работал.
Истинно говорю вам — пользуйтесь DNSCrypt и утилитой французского фотографа, на Go написанной, юзающей протокол сей.
И не сможет тогда ввести тестовый домен Стива Гибсона (а равно и прочие злохитренные волкИ) систему вашу компьютерную во искушение:
было:
image
стало:
image
Краткое описание, если интересна сия информация
;-)
UFO just landed and posted this here
Не интересовался как это работает в Windows, но он по моему всегда «не заслуживающий доверия».
Мне кажется, это как-то зависит от DNSSEC, но увы я с DNSSEC совсем незнаком.
Это плохой перевод сообщения о неавторитативном сервере (т.е. не том кто первично держит эту зону а например резолвере вашего провайдера)
Например, с 8.8.8.8 все ответы «не заслуживающие доверия». Дело в том, что это надмозговый перевод термина «non-authoritative», т.е. ответ пришел от сервера, который не отвечает непосредственно за домен. Поэтому эта фраза в современном вебе ничего не значит, а значит только её отсутствие, т.е. мы обратились напрямую на тот сервер, который отвечает за домен, и его ответ считается априори верным.
Ни для кого не секрет, что многие рядовые пользователи не меняют стандартные пароли от админ-панелей своих роутеров

Как бы нормальный роутер при настройке принудительно просит ввести вручную пароль. Так что такой номер не пройдёт в случае правильного девайса

Здесь проблема кроется во всё том же JSON-RPC, который мы рассмотрели чуть выше. В данном случае он позволяет изменять пользовательские настройки, например, изменять папку для загрузки файлов

То есть он сам себе сервер, висящий на localhost? Это же не WebControl для управления клиентом по сети через браузер, который обычно по умолчанию выключен. Зачем там вообще JSON-RPC?

С uTorrent сейчас попробовал — там во-первых порт у каждого свой, он генерируется при установке, а во-вторых мне возвращает текст «invalid request» вместо содержимого файла при указании адреса с моим портом…
На сегодня мне известен один ресолвер, способный защитить от атаки DNS rebinding — unbound.
Вакцина в конфиг:

private-address: "192.168.1.0/24" ### Block attack DNS rebinding
private-domain: "home.lo" ### Block attack DNS rebinding


Первая опция объявляет ресолверу наши приватные IP-адреса. (немаршрутизируемая сеть)
Вторая опция объявляет наш локальный домен, которому можно ресолвиться в адреса нашей локальной сети.
Обе опции можно дублировать, если ресолвером обслуживается несколько сетей. (ремарка, в мультидоменных сетях для недопущения пересечений используйте технологии VLAN 802.1Q)
Для любых не перечисленных в конфиге доменов ответы содержащие немаршрутизируемые адреса будут отброшены нашим ресолвером.

Важно! Для поддержания локального домена unbound не годится. Необходим любой авторитарный сервер. В качестве авторитарной пары к unbound рекомендую nsd.

P.S.: Для bind9 будет чуть сложнее. Постараюсь позже описать реализацию.
Важно! Для поддержания локального домена unbound не годится.

Вот здесь не понял. Что значит для поддержания? Поясните плиз. Вот у меня есть мой личный домен, в качестве DNS-хостинга я использую бесплатный ZoneEdit. IP там прописан мой собственный, домашний. Кстати, он ресолвится во внешний IP, так что тут вообще походу беспроблемный случай.

Я тогда вообще не понял, для каких кейсов ваша инструкция применима :)
Если использовать правильную терминологию, то unbound умеет быть только рекурсивным сервером, но не умеет быть ответственным (authoritative). В качестве authoritative авторы unbound предлагают использовать nsd.
В отличии от, например, bind'а который умеет и то и то (от чего случалась масса проблем при неправильной настройке)
Ничего сложного для bind9
deny-answer-addresses { 10.0.0.0/8; 127.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12; 192.168.0.0/16; } except-from { "example.com"; };

Ну здрасьте, единственный.
dnsmasq (трудящийся практически в каждом первом soho роутере) умеет это из коробки одним ключём запуска (и на совести авторов прошивки, включен ли этот ключ по умолчанию).
Да и практически на любом сервере, даже не имеющем такого синтетического сахара, это можно сделать настройками

А откуда логин/пароль роутера-то берется при такой атаке?

Ну то есть проблема в том, что люди сидят под дефолтными креденшиалсами, а не в чемто еще.

А зачем менять несферическому непродвинотому пользователю настройки на домашней коробке? Три или четыре провода воткнул кнопочку нажал оно само и заработало. Многие подключают себе инет включая коробку от оператора с предустановленным конфигом. Студентик пришел в сеть 220 воткнул штепсель и дальше побежал.

Понимаете, какие бы страшилки по безопасности не лились на головы рядового пользователя, в целом по больнице это ничего не изменит. Люди покупают коробку, для получения благ, и люди вообще не хотят разбираться в настройках дальше того момента, когда получат преемлимый на их взляд уровень блага.
А зачем менять несферическому непродвинотому пользователю настройки на домашней коробке?

Ну не надо менять, надо ставить рандомный пароль свой на каждом устройстве еще при производстве. Пароль писать на наклейке. У меня вот пароль вай-фая именно так предустановлен на роутере. Непонятно, почему нельзя то же самое делать просто с паролем доступа.


Я считаю, что вообще это надо регламентировать каким-то гостом. Устройства, на которых одинаковый пароль — просто не допускать к розничной торговле.


Вот чем бы заняться вместо запрета интернетов.

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

Не надо никакой базы с паролями. Рандомный пароль на устройство + наклейка на него, кроме как на наклейке пароля больше нигде нет.
Наличие некоего универсального "заводского пароля" при сбросе на "заводские настройки" тоже вполне можно оставить — с возможностью залогиниться и требованием выставить новый пароль. В этом случае если пользователь оставит старый — он уже сам себе злобный буратина.


В любом случае это уже детали, понятно при при гипотетическом принятии такого закона было бы какое-то обсуждение, анализ возможных проблем и т.д.

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

Дело как раз в законе, потому что без закона нафига кому-то париться?


От избежания дублей при работе псевдослучайного генератора случайных чисел

Будут дубли один на миллиард-другой, ну и что?


и при финальной сборки и тестирования решения перед отправкой

Можно тестировать до смены паролей.

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

Роутер — это частный случай. Ко многим ресурсам в локальной сети пароль вообще по-умолчанию не устанавливается. И на многих роутерах пароль остаётся по-умолчанию, либо «из стандартных» — именно из-за уверенности в безопасности локальной сети, «зачем усложнять».
У меня лет 8-10 назад был очень показательный случай: на мой домашний веб-сервер знакомые через дырявый скрипт залили веб-шелл. Далее прокинули порты, и с этого момента у атакующих был полный доступ к машине. А там ещё и RAdmin был поднят. Они прописали туда нового пользователя, сделали себе доступ… И очень хорошо в таких случаях, когда у атакующего хотя бы нет пароля от роутера. Хотя доступ к безпарольным файлопомойкам с возможностью там всё почистить у них так или иначе уже был…
Подбирается из дефолтовых (которые чаще всего никто при настройке не поменял)
О, так это ж ломануться можно на локальный вебинтерфейс торрентокачалки, поставить на скачивание и раздачу чего-нибудь редкого запрещенного.
Меня больше озаботил localhost:8384 (syncthing) — зашел в консоль, зацепил свою ноду и слил все что человек синхронизирует и налил ему всего что тебе хочется, причем на этой ноде можно настроить так что на ней и снести все пользовательские данные в треш можно (если при этом ни на одной ноде ignore_delete не стоит, то снос произойдет во всем кластере).

Буду себе настраивать DNS-over-HTTPS на домашенем роутере с OpenWRT… но пароли на консоль SyncThing уже поставил.
А как вам поможет DNS-over-HTTPS, в атаке нигде нет поддельных DNS серверов или модификации ответов, ответ, в неизменном виде, получен от «верного» DNS сервера. Тут требуется настроить фильтрацию ответов от внешних DNS-серверов, как было указано в некоторых ветках выше.
Совсем не понял с Cloud-ом — IP-шники вида 169.254.Х.Х вроде APIPA и никак не публичные?
192.168. — тоже не публичные — про то и статья.
proxy.pac, отбривающий домены, резолвящиеся в нехорошие IP, может быть, чуть поможет
Ещё можно через AdGuardHome, если он поднят на роутере.

Filters → Custom filtering rules:

|0.*
|127.*
|10.*
|192.168.*
|169.254.*
|192.0.2.*
|198.51.100.*
|203.0.113.*
Вы населению то поясните, что делать надо то
Извините за, возможно, нубские вопросы:
  1. В OpenWRT прошивках помимо опции rebind_protection есть опция rebind_localhost (allows upstream 127.0.0.0/8 responses, required for DNS based blacklist services). В частности, к таким сервисам относятся те, что содержат/проверяют ip'шники email спаммеров. Если ip спамерский, в ответе вы получите адрес из 127.0.0.0/8. Собственно поэтому эта опция может поломать работу с ними (если я все правильно понял). Верно ли, что если у меня не поднят собственный почтовый сервак, настроенный на работу с этими самыми DNSBL, то, по идее, ничего не сломается, и лучше эту опцию держать включенной?
  2. Допустим на компе настроена фильтрация ответов от DNS из локальный диапозонов 192.168.*, 10.*, 172.*, но я подключаюсь к wifi точке, на которой вот это вот ничего не настроено, или к точке, где все настроено, но есть «умник» в локалке с прописанным DNS сервером, например, 8.8.8.8 (что, по большому счету, одно и то же, ибо в обоих случаях локалка подвержена атаке, опять-таки, если я все правильно понял). Правильно ли, что мне побоку DNS rebinding, если:

  • у меня не поднято никаких сервисов, к которым можно обращаться по API или
  • подняты такие сервисы, но для их использования (API) необходимо сначала авторизоваться или
  • подняты такие сервисы, но все входящие соединения режутся фаерволом?

Sign up to leave a comment.