Цифровой мир: дыры в роутерах.

[holydiver_777]

Какой-бы SOHO роутер не был крутой — он с "дырами". Какая бы крутая контора не производила SOHO роутеры — они все равно с дырами.

Сначала надо оговорить, что под роутерами будут подразумеваться в большинстве своем SOHO роутеры, которые стоят в общественных местах, домах и тд. А также под «вскрытием» понимается открытие доступа к роутеру из глобальной сети и получение данных для этого доступа (об этом подробнее потом).
Итак, почти всегда (и по дефолту) роутеры закрыты для доступа из вне и как-то с ними взаимодействовать (кроме переправки сетевых пакетов) можно только из локальной (часто беспроводной) сети, то есть попасть в настройки можно только подключившись к нему через Ethernet кабель или по WiFi, если есть такая функция.

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

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

Задумка.

По моим наблюдениям (в моих случаях всегда, но возможно это не так) в большинстве роутеров в HTTP-заголовках ответов не было заголовка X-Frame-Options (хотя это не помеха, как выяснилось позже), то есть весь веб-интерфейс можно с легкостью подгрузить во фрейме. Но рулить содержимым < iframe > через JS мы не сможем, так как Cross Origin Policy браузеров не позволит, более того, мы даже не сможем увидеть, какой реальный адрес подгрузился во фрейме (если там был редирект) и тем более HTML-код в нем.

Несмотря на эти ограничения, пользу из ситуации все же можно вынести: можно на основе шаблонов пробовать угадать марку и модель роутера, затем через дофолтные логин/пароль для этой модели залогиниться и отправлять все HTTP-запросы в тот < iframe >, тем самым как-никак, но мы получается будем управлять роутером.

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

• определяем марку и модель роутера;


• подбираем для модели дефолтные логин/пароль;


• после авторизации открываем порт для внешнего доступа к роутеру;

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

Но для эффективности я еще сделал так, что после первой попытки авторизации скрипт еще раз посылает все логины и пароли из его словаря (при нужной установке переменных в скрипте). Это работает, так как нам достаточно один раз угадать логин и пароль, далее при успешной попытке они сохраняются в cookies или в сессиях на самом роутере (опять же, так может быть не у всех, но в моем случае было всегда), и мы можем еще перепробовать пару ложных паролей (cookie не удаляться при этом) и потом уже отправлять HTTP-запросы для открытия порта.
Теперь стоит упомянуть, когда это не сработает:

• если юзер сменил дефолтные логин и пароль (и сменил не на другие дефолтные);


• если авторизация осуществляется с каптчей или какими-нибудь токенами (такое пару раз видел, но редко);

Еще сначала мне казалось, что если веб-сервер роутера будет отправлять X-Frame-Options со значениями SAMEORIGIN и тем более DENY, то наша затея тоже накрывается. Но затем я более детально вдумываясь пришел к выводу, что фрейм нам нужен только для того, чтобы при отправки POST или GET запросов у нас не происходила переадресация главной страницы.

А это значит, что нам не важно, какой будет ответ от веб-сервера, нам главное, доставить до него запрос через фрейм. А современные браузеры применяют политику Cross Origin Policy только при получении ответа от веб-сервера и уже на основе нужного заголовка решают, отдавать нам ответ во фрейм или зажать. Но в нашей ситуации достаточно только доставить запрос до веб-сервера, а к запросу эта политика не будет принята, так что в теории все должно быть нормально, что и было потом подтверждено опытным путем.

Реализация.

Определение марки и модели роутера.
Сначала долго думал, каким способом можно это сделать, учитывая, что из доступных средств у нас толко JS (можно конечно сюда и флеш с джавой приспособить, но хром сейчас, например, по умолчанию флеш на паузу ставит, да и не установлен может он быть + это нам мало что даст, по сравнению с JS’ом).

Потом придумал (и выяснил, что до меня это уже кто-то догадался), что каждый роутер при подгрузке веб-интерфейса используют каие-то картинки, css-файлы, js-файлы, которые мы в принципе без каких-либо ограничений можем запрашивать у веб-сервера роутера с нашего подгружаемого сайта. Тем самым, определив наличие/отсутствие каких-то файлов можно с относительно точной вероятностью сказать, что у юзера используется такой-то роутер и что там скорее всего стоят такие-то логин и пароль, и нам надо отправить такой-то HTTP-запрос, чтобы залогиниться и поставить настройку открытия внешнего администрирования.

Это подводит еще к моменту, что придется составлять базу «отпечатков» конфигураций файлов js/css/картинок для каждой интересующий нас модели и так же в эту базу добавлять данные, как с этой моделью работать и какие там используются пароль и логин.

Забегаю чуть вперед, можно увидеть проблему в отправке POST зарпосов в < iframe >, но благо браузеры позволяет нашим формам (< form >) через атрибут target указать, куда будем сабмититься, то есть можно указать имя нашего фрейма и все POST запросы будут отсылаться в него.
Получившийся JS код прикреплю к теме и не буду вдаваться в его подробности, лишь опишу кратко алгоритм работы:

• из базы берется элемент данных;


• проверяется его файлы один за другим;


• если файла нет на сервере, то записывается количество совпадений остальных файлов элемента данных;


• если совпали все файлы (или количество совпадений наибольшее), то берется из элемента данных инструкция и выполняется;


• если в результате перебора базы точных совпадений не было, то выбираются «победители», с наибольшим числом совпадений (их может быть несколько);


• если совпадений нет, то все заканчивается;


• далее просто для каждого «победителя» выполняются заложенные в базу команды;


• после окончания работы (если были совпадения) на сервер отправляется уведомление;

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

Несколько примеров:

• Взлом роутеров ASUS


• Взлом роутеров TP LINK


• Взлом роутеров Tendra и Medialink


• Взлом роутеров D-Link через backdoor


• Взлом роутеров Linksys E-серий


• Взлом роутеров со стандартными паролями


• Взлом флагманского роутера D-Link DIR-890L


• Взлом роутеров Zyxel

Некоторые роутеры настолько ущербны, что вас даже не спасет альтернативная прошивка вроде openwrt или dd-wrt. Дыры в прошивках производители устранять не торопятся.
Интересно почему? Не потому ли, что этим пользуются спецслужбы?
Сейчас очень много говорят о попытках взлома смартфонов, краже персональных данных и все такое. А то что целую домашнюю сеть взломать можно как нефиг делать и слить от туда все что угодно — про это как-то никто особо не говорит. А между тем, в большинстве случаев у людей дома компы вообще без паролей и единственная защита перед ним от внешних атак — это роутер-сито.

По материалам сайта cryptoworld.su