Всем привет! Сегодня мы бы хотели рассказать об одной старой и почти всеми забытой атаке под названием DNS rebinding. Первые разговоры о ней начались еще в 2007 году, однако тогда эксперты из области практической информационной безопасности не уделяли ей должного внимания в связи с особенностями эксплуатации этой атаки, а также мало ощутимыми, как тогда казалось, последствиями. Сегодня мы попробуем убедить в обратном их и вас, в частности, продемонстрировав, что в современном мире эта атака обрела второе дыхание и более не кажется такой безобидной.
Что такое DNS rebinding?
Рассмотрим следующую схему:
У нас есть компьютер жертвы с IP 192.168.0.2 в локальной сети, а также в ней имеется роутер с IP-адресом 192.168.0.1. Цель злоумышленника, управляющего сервером с адресом 13.37.13.37 и доменным именем hacker.com (также, на ip-шнике крутится наш собственный DNS-сервер, содержащий информацию о домене), – получить доступ к роутеру в локальной сети.
Для эксплуатации техники DNS rebinding нам необходимо заманить жертву на наш вредоносный сайт. Предположим, что нам это удалось.
Давайте теперь подробно разберем, как работает атака.
В первую очередь, браузер обращается к DNS-серверам с запросом А-записи:
Цепочка DNS-серверов приводит к нашему серверу, который, в свою очередь, выдает стандартный ответ, содержащий истинный IP-адрес вредоносного сайта, а также указывает необходимый нам TTL, в данном случае 59.
Далее браузер делает стандартный HTTP-запрос на полученный IP.
На следующем этапе сервер отвечает HTML-страницей с javascript кодом, обращающимся на наш же домен.
Теперь, пока не истечет TTL и пользователь будет находится на сайте, будет выполняться полученный выше javascript. Как только TTL закончится, браузер снова сделает запрос A-записи.
В это время наш javascript продолжает выполняться, а управляемый нами DNS-сервер ответит A-записью с IP-адресом из локальной сети, куда злоумышленник хочет достучаться.
Так как домен, порт и протокол остаются неизменными, то SOP не нарушается, и в результате браузер обращается по домену pew.hacker.com, однако стучаться он уже будет на заветный и недосягаемый роутер.
Как результат, мы спокойно получаем ответ от роутера и перенаправляем его к себе, встроив соответствующий функционал в javascript код, подгруженный ранее.
Итак, давайте резюмируем вышесказанное:
- Пользователь посещает сайт, получая реальный IP-адрес и короткий TTL
- Находясь на сайте, браузер делает обращения к тому же домену, где находится пользователь. Как только истекает время жизни кэша, браузер снова запрашивает IP домена.
- Далее наш DNS-сервер выдает вместо настоящего адреса, IP-адрес внутреннего сервиса (в нашем случае – роутера)
- После запрос идет по домену на роутер, а результат нам отправляет подгруженный заранее пользователем javascript.
С этим разобрались! У многих может возникнуть резонный вопрос: "Ну и что?", ведь для эксплуатации нужно знать внутренние IP-адреса сервисов, удержать пользователя определенное время и т.д.
Да, однако, с приходом стримминговых сервисов, видео хостингов, старых добрых порносайтов и прочих платформ, где люди надолго зависают, у злоумышленника будет достаточно времени, чтобы провести атаку. Что касательно адресов, то они зачастую бывают стандартными или легко предугадываемыми.
Но это всё в теории, а что же на практике? Мы выбрали 4 наиболее актуальные сферы в 2019, где произошли инциденты, связанные с атакой DNS rebinding, это:
- IoT
- Crypto wallets
- Desktop applications
- Clouds
Давайте рассмотрим каждый топик по порядку и выясним, действительно ли всё так безобидно?
Iot
Google home
Google home – это умный помощник от компании Google. Этот девайс имеет (или имел в прошлом) API, не требующий какой-либо аутентификации для управления устройством. Он предоставляет ряд возможностей, таких как:
- Проигрывание контента
- Сканирование
- Перезагрузка
- Подключение к WI-FI сетям и т.д.
Примерный сценарий атаки: злоумышленник может деанонимизировать пользователя, получая координаты ближайших WI-FI точек. Очевидно, что тут никакой VPN не спасет.
Sonos WIFI speakers
Данные колонки от компании Sonos подымают в локальной сети UPnP веб-сервер, который дает доступ к ряду интересных страниц:
- 192.168.1.76:1400/support/review – выплевывает вывод некоторых UNIX-команд
- 192.168.1.76:1400/tools – позволяет запускать некоторые UNIX-команды
В данном случае злоумышленник имеет возможность исполнять команду traceroute для сканирования топологии внутренней сети.
Radio Thermostat CT50
Это один из наших самых любимых кейсов. Данная модель термостата также обладает API без какой-либо авторизации и позволяет изменять:
- Климат-режим
- Температуру
- Режим подсветки и прочие настройки
Как результат, злоумышленник может заставить свою жертву нехило попотеть, но если говорить серьезно, то подобная атака на термостат, например, медицинского учреждения может привести к довольно малоприятным последствиям.
Roku TV
У телевизоров от компании Roku всё тот же недуг – API без аутентификации.
API позволяет:
- Запускать различные приложения
- Проигрывать контент
- Совершать поисковые запросы по системе и т. д.
В данном случае максимум, что грозит пользователю, это утечка чувствительных данных, что тоже неприятно.
Любой WI-FI роутер
Этот IoT-девайс сегодня есть дома почти у каждого. Ни для кого не секрет, что многие рядовые пользователи не меняют стандартные пароли от админ-панелей своих роутеров. При помощи DNS rebinding нам ничего не мешает совершить попытку логина со стандартными учетными данными и получить доступ к админке. В случае, если локальный IP не удается подобрать, на помощь приходит WebRTC.
Итог по IoT
Выделим некоторые возможности, которые предоставляет DNS rebinding при работе с IoT:
- Возможность деанонимизировать пользователя
- Возможность сканировать локальную сеть
- Издеваться над пользователем
- Что угодно, в зависимости от функционала IoT-устройства
Crypto wallets
Geth
Теперь поговорим о криптокошельках. Первый кейс из рассмотренных – это клиент для ethereum-кошельков, под названием Geth. Здесь ящик пандоры кроется в работе JSON-RPC сервиса. Для начала давайте разберемся что это такое. JSON-RPC – это протокол удаленного вызова процедур в JSON формате. Выглядит это всё примерно так:
Большинство клиентов запускают этот сервис на localhost:8545, а он, в свою очередь, предоставляет набор интересных функций, таких как eth_sendTransaction и так далее.
Теперь пример, каким образом можно без ведома пользователя и с использованием атаки DNS rebinding получить его баланс и адрес кошелька:
EOSIO keosd wallet
Далее на очереди у нас клиент для EOSIO-кошельков. Сам keosd запускается на localhost:8900 и автоматически подписывает любые действия приложения на 15 минут после ввода авторизационных данных. Углубившись в API, можно опять обнаружить интересный функционал. Для наглядности, используя продемонстрированный ниже запрос, можно получить публичный ключ пользователя:
Итог по Crypto wallets:
- злоумышленник может красть деньги пользователя
- злоумышленник может изменять различные пользовательские настройки
- возможность деанонимизации пользователя
Desktop applications
Transmission client
Блок инцидентов, связанных с Desktop-приложениями, хочется начать с относительно нашумевшей уязвимости в торрент-клиенте Transmission.
Здесь проблема кроется во всё том же JSON-RPC, который мы рассмотрели чуть выше. В данном случае он позволяет изменять пользовательские настройки, например, изменять папку для загрузки файлов:
С одной стороны, вроде бы ничего серьезного, однако если указать вместо папки контролируемую злоумышленником smb share (в случае, если клиент использует Windows клиент), то можно перехватить хеш пользователя, который может быть использован в дальнейшем.
uTorrent web client
Этот товарищ имеет у себя в арсенале всё тот же JSON-RPC сервис, позволяющий изменять конфигурационные файлы пользователя, а также скачивать файлы.
В данном случае требуется аутентификация, однако учетные данные доступны из http://localhost:19575/users.conf. Как же можно это использовать?
Для начала делаем следующий запрос:
После получения токена меняем папку загрузки на папку, где располагаются программы, запускаемые при старте системы:
И, наконец, даем команду на скачивание необходимой полезной нагрузки:
В итоге, evil.exe будет запущен после следующей перезагрузки.
Minikube
Minikube – утилита командной строки для настройки и запуска однонодового кластера Kubernetes в виртуальной машине на локальном компьютере.
Он всегда висит на 192.168.99.100, а web-интерфейс доступен на 3000 порту. В итоге у злоумышленника есть возможность создать зловредный контейнер с общей папкой с основной системой.
Первый делом необходимо получить csrf токен.
Далее нужно создать контейнер, а для этого послать следующий запрос:
Давайте разберем, что он делает. В нем мы указываем, что при запуске контейнера нам нужно пробросить reverse-shell, а также примонтировать папку Users с основной системы:
Ruby on Rails
Для фреймворка Ruby on Rails существует гем, позволяющий выполнять Ruby-код прямо в браузере.
Давайте попробуем разобраться, что нам для этого понадобится?
Для начала нам нужно обратиться на несуществующую страницу:
Далее мы делаем попытку обращения к консоли через браузер:
Ну и, наконец, формируем запрос за запуск приложения калькулятор (в данном примере вектор для MAC OS X):
Blizzard Desktop application
Не только разработчики и обычные пользователи подвержены атаке типа DNS rebinding, но и геймеры тоже. Здесь мы опять же встречаемся с проблемой JSON-RPC сервиса, торчащим в данном случае на localhost на 1120 порту. Сервис дает возможность производить апдейты, изменять настройки и другие различные обслуживающие опции.
В данном случае поддерживается аутентификация, но пройти её, делая запросы от localhost, не составляет труда:
Как результат, можно добиться чего-то подобного:
Более подробно можно ознакомиться тут.
Итог по Desktop Application:
- злоумышленник может получить RCE на основной системе (также не забываем про VM Escape)
- злоумышленник может получить доступ к конфиденциальным данным и т.д.
Clouds
Ну, и напоследок, осталось самое интересное – облака. Суть в том, что облачные сервисы часто используются для размещения ПО, которое проводит аналитику приходящих на сайт пользователей. Например, переходя headless браузером по ссылке из заголовка Referer, чтобы скраулить ресурс, с которого клиент перешел на сайт. Этот вектор атаки так же можно использовать, ведь по сути headless браузер — это полноценный веб-браузер без графического интерфейса, но с поддержкой DOM, JS и всего остального.
Возвращаясь к нашим баранам, что мы можем сделать в данном случае? Ведь для атаки нам необходимо задержать пользователя (в данном случае бота) на странице. Что ж, для этого мы можем использовать на странице изображение, имеющее Content-Length на единицу больше, чем оно есть на самом деле. Как результат, бот будет думать, что картинка ещё не прогрузилась и задержится на нашей странице, а далее, мы применяем нашу стандартную технику DNS rebinding.
В итоге, так как запросы мы будем слать от доверенного лица, мы можем творить множество веселых вещей. Например:
- сканировать внутреннюю сеть
- авторизовываться во внутренних сервисах (теоретически)
- красть данные авторизации других сервисов и т.д.
Вернемся непосредственно к Amazon. AWS EC2 имеет такой функционал, как Instance Metadata Service. Она позволяет любой EC2 сущности использовать REST API, находящийся по адресу 169.254.169.254, раскрывающий информацию об инстансе.
Например, вот небольшой список подобных сервисов у различных облаков:
- AWS http://169.254.169.254/latest/user-data
- Google Cloud http://169.254.169.254/computeMetadata/v1/
- Digital Ocean http://169.254.169.254/metadata/v1.json
- OpenStack/RackSpace http://169.254.169.254/openstack
- Azure http://169.254.169.254/metadata/instance
- Oracle Cloud http://169.254.169.254/opc/v1/instance/
Теперь давайте рассмотрим кейс, в котором мы побалуемся с AWS.
Для начала пусть бот сделает запрос к API:
В ответе мы можем получить конфиденциальную информацию, например, креды в скрипте, который запускается при старте машины:
Далее мы можем вытащить имя ноды, с которой будем дальше работать:
Далее мы сделаем следующее обращение по уже известному имени и – бинго!
Мы получили различную информацию о пользователе, такую как AccessKeyId, SecretAccessKey, Token и т.д.
Получив эти данные, мы можем использовать их для авторизации через консольный клиент:
Общий итог:
Давайте выделим общие слабые точки, которые мы заметили при эксплуатации атаки типа DNS rebinding:
- API без аутентификации
- Локальные сервисы без аутентификации
- Игнорирование Host параметра к запросе
- Использование http вместо https
Таким образом, несмотря на различные доводы со стороны экспертов в области практической информационной безопасности, атака данного типа рождается заново в эпоху IoT, облачных сервисов, криптовалют и так далее, даже несмотря на необходимость задержки клиента на стороне злоумышленника, ведь в мире онлайн-кинотеатров, видеохостингов и прочих сервисов, предоставляющих контент пользователю, сделать это не составляет особого труда. Поэтому будьте бдительны при путешествии в онлайн-мире, при покупке очередного умного помощника, ну и при разработке, естественно.
Источники:
- https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325
- https://blog.hacker.af/how-your-ethereum-can-be-stolen-using-dns-rebinding
- https://medium.com/coinmonks/the-call-is-coming-from-inside-the-house-dns-rebinding-in-eosio-keosd-wallet-e11deae05974
- https://github.com/transmission/transmission/pull/468
- https://labs.mwrinfosecurity.com/advisories/minikube-rce/
- http://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/
- https://bugs.chromium.org/p/project-zero/issues/detail?id=1471&desc=3#maincol
- https://labs.mwrinfosecurity.com/blog/from-http-referer-to-aws-security-credentials/
Комментарии (149)
andreyons
13.02.2019 16:44+1Простите, но как заставить жертву использовать наш собственный DNS сервер?
Regis
13.02.2019 17:04+1Запрос от жертвы так или иначе приходит на DNS сервер, контролируемый владельцем сайта. Можно генерировать каждому пользователю отдельный поддомен домен, чтобы результаты DNS запроса не шарились для разных пользователей.
popov654
14.02.2019 04:47Это вам свой собственный DNS-сервер придётся реализовывать, потому что стандартный будет всегда отдавать «честную» информацию, не делая никаких подмен. А чтобы потом это всё запустить, нужен как минимум VPS, тут обычный хостинг не подойдёт.
trapwalker
14.02.2019 11:53+2[sarcasm]
Да уж… Вот это проблеееема… Стандартный хостинг не подойдёт. Можно спать спокойно.
[/sarcasm]
catharsis
14.02.2019 15:16Даже на обычном хостинге, вовремя меняя A-записи вручную, можно так сделать.
А уж хелпер к PowerDNS написать не дольше, чем javascript для этой атаки.popov654
15.02.2019 06:01Вручную — это руками в панели управления? Такое себе занятие. А автоматизировать этот процесс там, вроде бы, не дадут.
А уж хелпер к PowerDNS
А что это? Я говорил про обычный веб-хостинг с ISP Manager или похожей панелью управления.
OCTAGRAM
14.02.2019 18:27+1bash скрипт в cron, который переписывает зону и обновляет честный KnotDNS, тоже сойдёт. Цены на подходящий хостинг начинаются, кажется, с 90 рублей в месяц.
popov654
15.02.2019 06:05bash скрипт в cron, который переписывает зону и обновляет честный KnotDNS
Это точно сработает на обычном хостинге?.. cron, который я знаю (как функция в панели), сделан для запуска php-скриптов (хотя может вы и правы, и bash-скрипты исполнять тоже можно, но мне почему-то кажется, что это будет запрещено политиками безопасности). Но даже в этом случае, нам нааверное нужно знать, какой именно DNS сервер использует хостер. Это можно как-то узнать без помощи техподдержки? Опять же, должно быть всё настроено так, чтобы файл конфигурации DNS сервера допускал модификацию пользователем, от которого запускается cron и bash интерпретатор (или чтобы DNS сервер допускал модификацию зон по команде, принятой от нашего скрипта — хотя раз он принимает такие запросы от ISP Manager, то чего бы не принять и от другого процесса, наверное). Тут надо уже у админов спрашивать, которые шарят в линуксе.OCTAGRAM
15.02.2019 15:28Очень непривычно, когда обычным хостингом называют shared. Самые дешёвые VPS уже не 100MHz с 16Мб памяти как 10 лет назад. VPS и есть обычный хостинг IMHO.
На shared, кажется, любой форум и любой WordPress научились cron симулировать, но если есть работающий в браузере скрипт, то проще XHR из браузера сделать.
К услугам нищебродов DynDNS, в котором можно явно указать IP, а также Яндекс.ПДД и т.п.popov654
15.02.2019 20:41Так нам нужно менять отдаваемый IP по таймеру. DynDNS — это вроде немного не для этого сделано (для тех, у кого сервер на динамическом IP). Там надо API дёргать всякий раз, когда IP поменялся. То есть всё равно какой-то сервис писать придётся для такой атаки.
На shared, кажется, любой форум и любой WordPress научились cron симулировать
Вот это не понял. Каким образом?
Самые дешёвые VPS уже не 100MHz с 16Мб памяти как 10 лет назад. VPS и есть обычный хостинг IMHO.
Характеристики повыше, а цены всё так же кусаются. Тем более, хороший сервис у зарубежных провайдеров, а там цены в долларах или евро. Они и раньше-то были не особо низкими, а с тех пор ещё и курс скакнул. Обычный хостинг я могу найти за 80-100 рублей в месяц, если постараться, максимум за 120. VPS — от 380-400 сейчас (самый фиговый, отечественный). Нормальный — где-то 120-150 долларов в месяц, кажется. Но надо пересмотреть цены, давно не изучал рынок.OCTAGRAM
16.02.2019 03:11Если 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. Оверселлинг, да, но, кажется, всё работает вот уже который год. Со всеми скачками курса не знаю отечественного, чтоб мог так же, и чтоб как-то это всё же работало.
Вот это не понял. Каким образом?
Если сайт не оставляют надолго в покое посетители или хотя бы поисковики, то сделать блокировку через базу данных и выполнить код в примерно необходимое время возможно. Куча движков это умеет.popov654
16.02.2019 06:40Не понял, зачем тут блокировка какая-то)
Вы говорите о довольно простом механизме — сохранять куда-нибудь время исполнения задачи и саму задачу, и запускать это всё по достижению заданного времени — но вместо крона сам 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$ в месяц. Такое себе… Причём ресурсы тоже не фонтан.
unclejocker
13.02.2019 17:04+1Если жертва заходит на ваш домен, и он прописан в вашем собственном DNS то временем TTL управляете вы. Я встречал DNS-сервера, которые игнорируют время кэширования и кэшируют данные по каким то своим внутренним настройкам, но по моему опыту это скорее исключение.
catharsis
14.02.2019 15:10Провайдерские DNS иногда так делали, что ожидаемо вызывает проблемы у некоторого меньшинства пользователей (например с DynDNS), поэтому такое должно встречаться нечасто.
OCTAGRAM
14.02.2019 18:32Если на один и тот же ресурс зайти через день-два, когда кончится DNS провайдера, всё равно сработает. Вероятность чуть меньше, да.
vanxant
13.02.2019 18:23+1В самом домене прописать NS-записи типа ns1.hacker.com, ns2.hacker.com и поднять там свой DNS сервер.
ValdikSS
13.02.2019 17:01+2Вот ПО для автоматизированной атаки уязвимых реализаций UPnP на роутерах, которое использует DNS Rebinding: github.com/filetofirewall/fof
amarao
13.02.2019 17:30+1Накиньте ещё в список жертв уязвимости админку i2p, слушающую на localhost.
powerman
13.02.2019 18:18Полагаете, есть энтузиасты I2P, которые не ставят пароль на админку?
rogoz
13.02.2019 18:41+2Тогда уж все админки на localhost, например syncthing, можно файлы пользователя захватить.
qw1
13.02.2019 17:49Спасает ли от атаки на роутер использование нетипичных адресов для внутренней сети, типа 192.168.223.47?
nApoBo3
13.02.2019 17:58В принципе да, но их можно перебрать, так что защита так себе, чуть больше времени нужно не более того. Плюс атака на локалхост в любом случае актуальна.
vanxant
13.02.2019 18:16Ну, адреса типа 10.137.71.хх задолбаетесь искать. Главное, не палиться с X-FORWARDED-FOR…
w0den
13.02.2019 19:34+4Думаю, WebRTC может облегчить задачу злоумышленника. Например, так: output.jsbin.com/jipiyovizu
pae174
13.02.2019 19:50Если IP машины 10.137.71.хx то скорее всего IP маршрутизатора 10.137.71.1.
А IP машины за NAT на самом деле можно определить:
xakep.ru/2015/01/29/webrtc-leak
xakep.ru/2014/01/24/61942
chupasaurus
13.02.2019 22:53+1Если IP машины 10.137.71.хx то скорее всего IP маршрутизатора 10.137.71.1.
Try failed, 35143 more addresses to check.
TimsTims
14.02.2019 12:07Можно же ещё делать трюк сл вставкой картинки img src ="http://10.137.71.2:80/image.jpeg", и если картинка загрузилась быстро, значит кто-то на том конце ответил "ошибка", или принудительно разорвал соединение. Если картинка грузилась долго, то скорее всего сработал timeout. Если мы целимся на конкретный сервис, то заранее можем узнать как он себя ведёт при таком запросе картинки.
chupasaurus
14.02.2019 12:10Я про то, что количество /24 подсетей внутри 10.0.0.0/8 достаточно велико, и перебирать первый адрес не самая быстрая затея.
OCTAGRAM
14.02.2019 18:36Кажется, можно ещё через a:visited css относительно быстро пропалить, куда в админку ходит админ. Хотя если он туда хоть иногда ходит, то, наверное, с паролем дело не заладится.
catharsis
15.02.2019 13:21Это вроде бы не должно уже работать (иначе любая страничка может угадать все посещенные порносайты).
Rebinding здесь не поможет, потому что юзер не ходил на pew.hacker.com/admin.php, даже если оно сейчас резолвится в роутер.OCTAGRAM
15.02.2019 15:21Типа не должно, но тема-то всплывает, значит, с какими-то ухищрениями всё же работает. Кажется, последний раз, навешивая картинку и отслеживая, загрузилась ли она, можно было отследить.
И юзер ходит по IP, а через a:visited, поняв, на какой IP, можно его-то как раз сразу и забиндить.
nApoBo3
13.02.2019 17:54Я так понимаю уязвимость не в подделке адреса через dns, а в локальных api не требующих аутентификации.
amarao
13.02.2019 18:12+1На самом деле, самая главная проблема в том, что кто-то решил, что 192.168.x.x — более «безопасно», чем интернет. Этот аргумент часто приводят в споре об ipv6, мол, «а как же NAT, за которым все защищены». Вся конструкция «локальных сегментов», которые вроде бы в интернете, но нет, полна дыр и неконсистентности.
(Вот атака на localhost — это да, это сурово — не верьте localhost, просто не верьте).powerman
13.02.2019 18:24Оно действительно более безопасно — в том смысле, что защита в любом случае должна быть многослойной, и NAT честно добавляет ещё один слой, усложняющий доступ.
Боюсь, честный https плюс авторизация по случайным паролям для всех локальных сервисов/устройств — пока что фантастика, причём в стиле рассказа про хакера и столовую. Скорее всего в таком стиле это в принципе никогда не реализуют, слишком неудобно будет пользоваться, и такие "безопасные" устройства купят 2.5 параноика.
amarao
13.02.2019 18:35+1Предполагается, что в мире ipv6, не будет никакого «NAT»а и все будут голой задницей в интернет (как и сейчас, но сейчас есть иллюзия). Не хочешь голой задницей? Ставь файрвол.
powerman
13.02.2019 18:39А он вообще наступит, этот мир IPv6? В смысле, при нашей жизни? Потому что пока не начнут массово появляться IPv6-only сервисы, причём достаточно популярные и нужные обычным юзерам, текущее состояние (не)поддержки IPv6 может сохраняться неопределённо долгое время.
amarao
13.02.2019 18:54+3Цены на 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 — больше миллиона баксов).
vanxant
13.02.2019 20:38В ЮВА уже наступил, судя по моему опыту. Цепляешься к публичному вай-фаю где-нибудь в тошниловке и тебе дают белый ipv6 и серый ipv4.
philipto
15.02.2019 22:21+1В Китае трафик в сетях IPv6 дешевле (или просто бесплатен), чем в IPv4. Университеты и студенты массово используют IPv6 only, чтобы платить меньше. Будущее наступило, просто еще не везде.
powerman
15.02.2019 22:50IPv6 only это как-то сильно жёстко, и за пределами ихнего файрвола не прокатит. Банальный пример: на habr.com нет AAAA записи. В мировом масштабе та же фигня: IPv6 нет у 70% из Alexa Top 1000, и у 80% из Alexa Top 1000000 сайтов.
Zolg
13.02.2019 22:29+3Самая мякотка в том, что это не атака на нат. Это атака на проникновение внутрь периметра фаервола. NAT traversal идёт бонусом
amarao
14.02.2019 14:30Вообще, это интересно, да. Хороший файрвол должен просто запрещать ответы от DNS (на входе в сеть) с адресами из защищаемой сети (и тут уже не важно, белые они или серые), за вычетом SOA/NS'ов.
powerman
14.02.2019 18:07А такие вообще есть? iptables такого, вроде бы, не умеет. А то мы договоримся до волшебных файрволов, которых никто не видел, но которые "должны" блокировать 100% любых атак на защищаемую сеть.
amarao
14.02.2019 18:12ASA 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.
Сам не щупал, не скажу.
OCTAGRAM
14.02.2019 18:51Да, есть. dnsmasq по дефолту, кажется, так настроен. Но он точно это умеет. И во многих нестандартных прошивках стоит именно он.
И могу сразу предложить антидот. Во всяких TP-LINK есть волшебные адреса, которые типа заменяют IP. И у TP-LINK их домены прокисают, а они ещё новые покупают, надо список поддерживать постоянно, если прямо хочется заморочиться. Также за счёт всяких NetBIOS есть шанс отрезолвить dlink.workgroup, но это не точно.
Так вот, если вместо A 192.168.0.1 отдать CNAME, дальше оно отрезолвится на роутере «куда надо» в обход безопасного, стоящего после роутера DNS.
Zolg
14.02.2019 18:52Сделать можно и в общем-то несложно: перенаправляем iptables ns-трафик на собственный сервер, на котором и разруливаем.
powerman
14.02.2019 19:50Собственный сервер и так анонсируется по DHCP, так что здесь роль файрвола не в защите от DNS rebinding, а в блокировании доступа к сторонним DNS в обход своего, в чём нет необходимости пока кто-то не попытается "выстелить себе в ногу" прописав себе ручками внешний DNS — но таких защищать обычно смысла нет, они с тем же успехом могут и VPN поднять наружу, и тогда такое перенаправление DNS-трафика в iptables уже не спасёт.
genuimous
14.02.2019 12:58Такие вещи, по идее, давно известны, как и то, что к ресурсам внутри LAN следует относиться так же, как если бы они были выставлены голой ж. в интернет по белому IP. Хотя бы потому что атаки непосредственно на LAN тоже ивестны, или, например, может произойти заражение внутреннего хоста вирусом или же кто-то (в том числе несанкционированно) подключится к LAN. Если кто-то не запаролил роутер в надежде что на него никто изнутри не полезет, то он оптимист.
Kozel-007
14.02.2019 15:00Много видов железа не умеет нормально паролиться. У меня есть NAS на unRaid. Запаролить интерфейс можно, но доступ к файлам остаётся. Если запаролить и доступ, то винда начинает время от времени спрашивать пароль снова. Через месяц это так задалбывает, что хоть всё выбрасывай. А ещё консоль отдельно закрывать нужно.
Отдельно упомяну 3D принтер на основе OctoPrint. При закрытии паролем он теряет самую удобную функцию — печать по сети прямо из слайсера.
Всякие вай-фай лампочки тоже мало заморачиваются безопасностью. Так что это не выход: LAN должен быть безопасным.
Evengard
14.02.2019 15:06А Windows Credential Manager не помогает разве в такой ситуации, с доступом к NAS-у?
Kozel-007
14.02.2019 15:42Помогает. До поры. Проблема в том, что если попытаться обратится к сетевому диску, когда NAS выключен или уснул или сеть упала, винда пишет «нет такого устройства» и сразу забывает пароль. После включения NAS нужно заново вбивать пароль.
Наверное, это можно вылечить настройками в реестре. Но до прочтения этой статьи мне и не нужно было ставить пароль. Я пробовал это сделать для защиты от малвари, но в итоге защитился иначе — теневой копией на самом NASе через btrfs snapshot. Так что вопрос с безопасностью LAN нужно решать сразу целиком, я не хочу разводить в своём хозяйстве бюрократию как на границе (с дырами как там же).
Throwable
14.02.2019 14:29На самом деле самая главная проблема в том, что кто-то решил, что выполнять что-то на машине клиента — это достаточно безопасно, если это "что-то" немного в чем-то ограничить.
vanxant
13.02.2019 18:18Либо с паролями по умолчанию, либо с межсессионными куками авторизации, либо тупом иот, где на авторизацию не хватило мозгов контроллера, либо просто с дырявыми прошивками.
И да, на 127.0.0.1 обычно куча всего висит без авторизации, но с ограничением по источнику.
OCTAGRAM
14.02.2019 18:41Проверка заголовка Host устройством (и, между прочим, даже обычным сайтом) снимает кучу проблем, в том числе эту. Видел хорошие роутеры, которые отдают 302, чтоб по IP к ним заходили, а не как-то иначе.
kapuletti
13.02.2019 19:50+1Правильно ли я понял что CSP и CSRF защиты в веб-сервере устройства достаточно чтобы закрыть такого рода уязвимость?
vlreshet
13.02.2019 20:06+1Не очень понял следующего — а что мешает заставлять пользователя делать запрос на адрес вроде 192.168.х.х. напрямую, без плясок с DNS? Сейчас протестил на локальном домене — роутер вполне себе отвечает на ajax… Или суть в dns в скрытности? Так множество постоянных запросов (setInterval) тоже не сильно то скрытно
w0den
13.02.2019 20:24+3Браузер не позволяет отправлять запросы к внешним сайтам, если они не возвращают правильные заголовки CORS. Например, попробуйте опубликовать Ваш скрипт на jsbin.com или jsfiddle.net, и отправьте запросы к локальному серверу, и увидите, что такие запросы блокируются браузером. А если не блокируются, скорее всего Ваш локальный всегда возвращает заголовок
Access-Control-Allow-Origin:*.ganjar
13.02.2019 20:28+1Не совсем так. Запрос уйдет и будет обработан на стороне веб сервера. Браузер заблокирует только чтение ответа, если в заголовках нет валидного CORS.
w0den
13.02.2019 20:29+1Думаю, Вы ошибаетесь. К слову, если бы это было так, то все бы использовали это для CSRF атак.
ganjar
13.02.2019 20:37+1Используют)
Как браузер определит можно ли слать запрос без получения ответа от сервера?
С более сложными (если например надо менять content-type на application/json) — сначала отправляется «preflight request» методом OPTION для получения разрешения на отправку основной части запроса. Для обычных post/get такого не делается.w0den
13.02.2019 20:42Ха! Спасибо за уточнение. Не знаю почему, но я подумал, что preflight запрос будет предупредить браузера о проблеме и не позволит отправить запрос :(
popov654
14.02.2019 05:03Зато сервер может не выполнить запрос в случае неправильного Referer. Правда, это нужно реализовывать на уровне бизнес-логики, да и смысла нет: Referer легко подделать.
По-хорошему сервер не должен выполнять вообще никаких операций, если не передан валидный токен сессии. При первом запросе такого токена у нас, конечно же, нет (весь пример с роутером строится вокруг того, что пользователь мог установить слишком простой пароль).
ferosod
13.02.2019 20:42+1Вот здесь https://developer.mozilla.org/en-US/docs/Web/HTTP/Cors можно почитать подробнее.
Если кратко, "простые" запросы выполняются сразу, просто к ним добавляет ся заголовок Origin, и проверяется, что сервер ответил корректным Access-Control-Allow-Origin
Mingun
13.02.2019 20:15Итак, давайте резюмируем вышесказанное:
- Пользователь посещает сайт, получая реальный IP-адрес и короткий TTL
- Находясь на сайте, браузер делает обращения к тому же домену, где находится пользователь. Как только истекает время жизни кэша, браузер снова запрашивает IP домена.
- Далее наш DNS-сервер выдает вместо настоящего адреса, IP-адрес внутреннего сервиса (в нашем случае – роутера)
- После запрос идет по домену на роутер, а результат нам отправляет подгруженный заранее пользователем javascript.
Что-то я не совсем понимаю, как это работает, в частности четвёртый шаг. Как скрипт может отправить нам результат на
pew.hacker.com, если тот уже указывает на IP-адрес роутера, полученный на третьем шаге? Разве запрос с отправкой результата не уйдёт опять на роутер? Или здесь схема сложнее и скрипт сначала сохраняет данные на клиенте, а через 59 секунд новый DNS-запрос снова возвращает IP-адрес злоумышленника и только потом скрипт отправляет ему собранную полезную нагрузку?ganjar
13.02.2019 20:22+3Мы можем отправить результат на другой домен
Mingun
13.02.2019 20:29Эм, но разве браузер не заблокирует междоменный запрос? Суть ведь этих плясок именно в том, чтобы протокол, домен и порт не менялись. Да и в статье упирается, что запрос отправляется на тот же самый домен:
На следующем этапе сервер отвечает HTML-страницей с javascript кодом, обращающимся на наш же домен.
Evengard
14.02.2019 00:17+1Отправлять данные мы можем (get-ом так точно, хотя в принципе можно и post-форму скрафтить в iframe-е), читать не можем только.
popov654
14.02.2019 05:06А почему именно в iframe-е, чтобы не видно было?
Evengard
14.02.2019 14:00Чтобы всю страницу не обновлять, и оставить канал обмена данными (с тем же ребинднутым pew.hacker.com) на основной странице.
popov654
15.02.2019 06:15А, точно. Тупанул.
А я сейчас вот что подумал: если пользователь после ребинда нажмёт F5, то будет эпик-фейл, он увидит админку роутера (ну или того, куда его там ребинднули)? Ведь шансы на это ненулевые?vlreshet
15.02.2019 10:40Ну и пусть. Рядовой пользователь подумает что-то вроде «ой, глюк какой-то», и закроет сайт.
popov654
15.02.2019 10:59А вот интересно, есть какие-то базы, куда собирают жалобы на мошеннические сайты? Раньше вроде в IE была опция какая-то в контекстном меню, типа «отправить жалобу на сайт». А потом эти сайты могли бы в блэклисты браузеров попадать после модерации жалоб.
mclander
14.02.2019 01:46+1Jsonp в помощь хакеру. Просто генерирует на странице
document.write('')
Дёшево, сердито, надежно
mclander
14.02.2019 01:49+1Эх как я люблю хабр с мобилы… и не поправить.
В общем генерируем тег script с src который является гет запросом. Можем даже получить ответ в виде исполняемого скрипта
xPomaHx
14.02.2019 04:53+1Это контролирует сервер, может ли ему отправлять корс так что если сервак наш то проблем нет.
Finesse
14.02.2019 08:16Скрипт запущен на домене pew.hacker.com. Он получает чувствительные данные, отправляя запрос на pew.hacker.com (IP которого теперь ведёт на локальную сеть), а результат сбора отправляет на report.hacker.com (IP которого ведёт на сервер злоумышленника). Запрос на report.hacker.com возможен, если report.hacker.com добавит в ответ заголовок
access-control-allow-origin: *.
glowingsword
13.02.2019 20:31+1Про dnsrebinding знаю уже сравнительно давно. Но такой подробной статьи с конкретными примерами и широким охватом возможных целей атаки ранее не встречал. Спасибо за отличную статью!
ferosod
13.02.2019 20:31+1Как можно защититься от такой атаки?
Я вижу такой вариант:
Свой DNS сервер, который имеет белый список доменов, которые могут резолвится в IP из приватных диапазонов (192.168.0.0/16, 10.0.0.0/8 и т. д.). Остальные резолвы, приходящие из внешних источников он игнорит и не передаёт конечному устройству.ValdikSS
13.02.2019 21:05+1На маршрутизаторах с прошивкой OpenWRT по умолчанию фильтруются ответы для приватных диапазонов. Это штатная функциональность DNS и DHCP-сервера dnsmasq, параметр
--stop-dns-rebind.
Недостаток в том, что некоторые провайдеры с локальной сетью отдают IP-адрес из внутренней сети на некоторые домены, и такие домены перестают открываться вовсе.vagonovozhaty
13.02.2019 22:35В прошивках Asus есть опция Enable dns rebind protection (или это Merlin добавил?). Правда, если ее включить, дофига сайтов перестаёт работать. Там их полный лог набивается.
Revertis
14.02.2019 20:46Очень плохо то, что если используется alias=11.22.33.44,192.168.10.10 (превращение внешнего айпишника во внутренний), то stop-dns-rebind стопает собственноручно подменённую запись.
Revertis
14.02.2019 23:31Отвечу самому себе, вдруг у кого-то тоже будет подобная ситуация.
Опция rebind-domain-ok=/domain1/domain2/domain3/ позволяет разрешить некоторым доменам иметь локальные адреса. И хорошо еще то, что не надо указывать поддомены, они тоже будут работать.
vvadzim
13.02.2019 21:33+1А потом так дашь пароль от вайфай тёще, а ей племянник гугловский днс на планшете жёстко прописал.
Т.е. ещё и 53 порт закрывать нужно. Но скоро днс-овер-хттпс и вот опять.
И даже не вижу способа закрыть дыру в браузерах. Можно детектить изменение IP домена, пока тот загружен, и перегружать страницу, либо делать XHR недоверенным или ещё каким подобным образом. Но всё это бесполезно, если используются локальные прокси.ferosod
13.02.2019 22:29Для этого на роутерах (не всех, конечно же) есть гостевые сети, с отдельным паролем, из которых не видно хосты, находящиеся в основной сети. Хотя, конечно, все еще видно сам роутер…
vvadzim
13.02.2019 22:37И как прикажете тёще кондиционер настроить/фотками с планшета на смарт-тв порисоваться/распечатать что-нить пока зять-параноик на работе?
Кароче, паролить всё в локалке и на локалхосте. Эх.
popov654
14.02.2019 05:09Но всё это бесполезно, если используются локальные прокси.
Чем они помешают? Я не очень понял проблему.vvadzim
14.02.2019 09:15Я про закрывание дыры в браузерах. Если используется прокси, то доменные имена там и резолвятся, и браузер даже может быть не в курсе IP адресов.
qw1
14.02.2019 10:00Если прокси на другом хосте, а ещё лучше — в другой подсети, то атака переносится на хост или подсеть прокси.
vvadzim
14.02.2019 10:08Ну это да. Я про локальные и упомянул. Ну и про прокси я это к тому, что разработчики браузеров могут не захотеть решать проблему, если она в принципе решается только частично.
firk
13.02.2019 22:12noscript вроде проверяет и блокирует локальный xss по айпи-адресам (локалхоста и локальных сеток), т.е. смотрит куда резолвится домен
хотя точно не помню уже, могу ошибаться в деталяхplus79501445397
14.02.2019 07:28Ну если noscript (или соотв. настройкой браузера) пользоваться, то и вредоносный js может не сработать…
Если конечно моск включать и не вносить в доверенные/исключения что попало, даже если сильно хочется ;)
veselovi4
13.02.2019 23:03>>Ни для кого не секрет, что многие рядовые пользователи не меняют стандартные пароли от админ-панелей своих роутеров.
По моему это уже из области фантастики. Сейчас самый захудалый роутер, как только любой юзверь пытается «сам настроить» сходу через мастера настройки вопит «смени пароль». Или не?slonpts
14.02.2019 04:42+1Вы так говорите, как будто людей интересует какой-то пароль в момент, когда они пытаются настроить доступ в интернет, потому что срочно надо отправить презентацию / фотки / отчет. Ну или как будто возвращаются потом, чтобы сделать все как надо.
popov654
14.02.2019 05:10Что значит «срочно отправить»?.. Настройка роутера происходит буквально один раз в жизни (пока он не сломается). Обычно это целое событие, особенно для не-айтишника.
Daniyar94
14.02.2019 09:27А я смотрю вы оптимист. Зайдите как нибудь на scanhub.shodan.io
Там не только роутеры в интернет торчат с admin:admin, но и айпи камеры, факсы, и прочая IoT херня от наших китайских колег.
OnelaW
14.02.2019 14:08Уметь то умеют, проблема в том что не сферический домашний пользователь о настройках и пароле к роутеру забудет через пару дней если не часов, сразу как только корректно настроит и не будет трогать месяцами. только пыль протирать.
И полностью согласен с комментарием popov654.
Дома зухель простенький 5 лет оттарабанил, как установил с дефолтными настройками так и работал.
Alyoshka1976
13.02.2019 23:36Истинно говорю вам — пользуйтесь DNSCrypt и утилитой французского фотографа, на Go написанной, юзающей протокол сей.
И не сможет тогда ввести тестовый домен Стива Гибсона (а равно и прочие злохитренные волкИ) систему вашу компьютерную во искушение:
было:
стало:
Краткое описание, если интересна сия информация
;-)
popov654
14.02.2019 04:20Ни для кого не секрет, что многие рядовые пользователи не меняют стандартные пароли от админ-панелей своих роутеров
Как бы нормальный роутер при настройке принудительно просит ввести вручную пароль. Так что такой номер не пройдёт в случае правильного девайса
Здесь проблема кроется во всё том же JSON-RPC, который мы рассмотрели чуть выше. В данном случае он позволяет изменять пользовательские настройки, например, изменять папку для загрузки файлов
То есть он сам себе сервер, висящий на localhost? Это же не WebControl для управления клиентом по сети через браузер, который обычно по умолчанию выключен. Зачем там вообще JSON-RPC?
С uTorrent сейчас попробовал — там во-первых порт у каждого свой, он генерируется при установке, а во-вторых мне возвращает текст «invalid request» вместо содержимого файла при указании адреса с моим портом…
karavan_750
14.02.2019 05:21На сегодня мне известен один ресолвер, способный защитить от атаки 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 будет чуть сложнее. Постараюсь позже описать реализацию.popov654
14.02.2019 06:30Важно! Для поддержания локального домена unbound не годится.
Вот здесь не понял. Что значит для поддержания? Поясните плиз. Вот у меня есть мой личный домен, в качестве DNS-хостинга я использую бесплатный ZoneEdit. IP там прописан мой собственный, домашний. Кстати, он ресолвится во внешний IP, так что тут вообще походу беспроблемный случай.
Я тогда вообще не понял, для каких кейсов ваша инструкция применима :)Zolg
14.02.2019 12:31Если использовать правильную терминологию, то unbound умеет быть только рекурсивным сервером, но не умеет быть ответственным (authoritative). В качестве authoritative авторы unbound предлагают использовать nsd.
В отличии от, например, bind'а который умеет и то и то (от чего случалась масса проблем при неправильной настройке)
1x1
14.02.2019 11:58Ничего сложного для 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"; };
Zolg
14.02.2019 12:08Ну здрасьте, единственный.
dnsmasq (трудящийся практически в каждом первом soho роутере) умеет это из коробки одним ключём запуска (и на совести авторов прошивки, включен ли этот ключ по умолчанию).
Да и практически на любом сервере, даже не имеющем такого синтетического сахара, это можно сделать настройками
Druu
14.02.2019 08:28А откуда логин/пароль роутера-то берется при такой атаке?
Zolg
14.02.2019 12:18Например отсюда
http://www.routerpasswords.comDruu
14.02.2019 13:19Ну то есть проблема в том, что люди сидят под дефолтными креденшиалсами, а не в чемто еще.
OnelaW
14.02.2019 14:17А зачем менять несферическому непродвинотому пользователю настройки на домашней коробке? Три или четыре провода воткнул кнопочку нажал оно само и заработало. Многие подключают себе инет включая коробку от оператора с предустановленным конфигом. Студентик пришел в сеть 220 воткнул штепсель и дальше побежал.
Понимаете, какие бы страшилки по безопасности не лились на головы рядового пользователя, в целом по больнице это ничего не изменит. Люди покупают коробку, для получения благ, и люди вообще не хотят разбираться в настройках дальше того момента, когда получат преемлимый на их взляд уровень блага.Druu
14.02.2019 14:36А зачем менять несферическому непродвинотому пользователю настройки на домашней коробке?
Ну не надо менять, надо ставить рандомный пароль свой на каждом устройстве еще при производстве. Пароль писать на наклейке. У меня вот пароль вай-фая именно так предустановлен на роутере. Непонятно, почему нельзя то же самое делать просто с паролем доступа.
OnelaW
14.02.2019 14:42Технологически это возможно. Вопрос как будет организована защиты базы с паролями для устройств. Те же операторы из большой тройки предоставляют роутеры с предустановленными настройками включая пароли на вай-фай и к админке. Рандомные пароли или нет не знаю, как и не зная автоматизирован ли этот процесс или нет.
Druu
14.02.2019 14:46Вопрос как будет организована защиты базы с паролями
Не надо никакой базы с паролями. Рандомный пароль на устройство + наклейка на него, кроме как на наклейке пароля больше нигде нет.
Наличие некоего универсального "заводского пароля" при сбросе на "заводские настройки" тоже вполне можно оставить — с возможностью залогиниться и требованием выставить новый пароль. В этом случае если пользователь оставит старый — он уже сам себе злобный буратина.
В любом случае это уже детали, понятно при при гипотетическом принятии такого закона было бы какое-то обсуждение, анализ возможных проблем и т.д.
OnelaW
14.02.2019 15:00Дело не в законе. Технологически компании производящие роутеры могут наладить подобный технологический процесс. База паролей нужна в первую очередь для двух моментов. От избежания дублей при работе псевдослучайного генератора случайных чисел и при финальной сборки и тестирования решения перед отправкой.
Druu
14.02.2019 16:34Дело не в законе.
Дело как раз в законе, потому что без закона нафига кому-то париться?
От избежания дублей при работе псевдослучайного генератора случайных чисел
Будут дубли один на миллиард-другой, ну и что?
и при финальной сборки и тестирования решения перед отправкой
Можно тестировать до смены паролей.
Sly_tom_cat
14.02.2019 14:02Подбирается из дефолтовых (которые чаще всего никто при настройке не поменял)
trapwalker
14.02.2019 11:58О, так это ж ломануться можно на локальный вебинтерфейс торрентокачалки, поставить на скачивание и раздачу чего-нибудь редкого запрещенного.
Sly_tom_cat
14.02.2019 14:08Меня больше озаботил localhost:8384 (syncthing) — зашел в консоль, зацепил свою ноду и слил все что человек синхронизирует и налил ему всего что тебе хочется, причем на этой ноде можно настроить так что на ней и снести все пользовательские данные в треш можно (если при этом ни на одной ноде ignore_delete не стоит, то снос произойдет во всем кластере).
Буду себе настраивать DNS-over-HTTPS на домашенем роутере с OpenWRT… но пароли на консоль SyncThing уже поставил.
OCTAGRAM
14.02.2019 20:24proxy.pac, отбривающий домены, резолвящиеся в нехорошие IP, может быть, чуть поможет
BekoBou
Обожаю красное на синем, так приятно читать.