>
Сентябрь 2017
Пн Вт Ср Чт Пт Сб Вс
« Авг    
 123
45678910
11121314151617
18192021222324
252627282930  

Практика по взлому домашних роутеров.

Как всегда, сначала надо оговорить, что под роутерами будут подразумеваться в большинстве своем 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 и данные для подключения и все это сохраняться.

Параметры скрипта.

Тут их всего 2, которые можно поставить через переменные в начале. Первый – это число роутеров, которые будут выбираться из кандидатов (по умолчанию будет выбираться наиболее вероятная тройка). Второй параметр ставит режим брута, то есть на этапе логина по дефолтным данным будет проведен небольшой брут по топовым дефолтным парам логин-пароль для роутеров.
Для статистики – у меня при установках на 1 роутер и без брута уходило около 3-4 секунд в целом, а при установках также на 1 роутер и с брутом – около 20 секунд.

Составление базы данных.

Тут может быть несколько моментов (сложностей). Первое – это всякие токены и прочая муть, которая по сути является лишней информацией (если вообще не мешает провернуть дело), так например у меня при отправлении POST запроса на выставление “в мир” 8080 порта отправилась  туча инфы (другие настройки, которые должны были измениться), я конечно часть полей ненужных мне настроек удалил (и проверил работоспособность), но делать так с каждым роутером при составлении базы очень муторно, поэтому сначала, наверное, придется отправлять не удалять лишние поля, а отсылать их данные вместе с нужными. А выдергивание этих полей из HTTP-запросов (при их сниффинге каким-нибудь прокси) можно будет поручить потом какому-нибудь скрипту.

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

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

Есть еще одна особенность, что у некоторых роутеров перед передачей данных они сначала обрабатываются (передаются их хеши чаще всего), для этого в структуре объявлена переменная, которая для каждой модели будет обозначать имя функции (которую надо брать из у моделей), вызывающуюся перед отправкой данных. Функция обработки данных авторизации, как правило, вызываются через атрибут onsubmin формы отправки данных.

Под конец.

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

Для себя планирую написать вспомогательный скрипт для составления БД, чтобы туда можно было послать дамп HTTP-запроса к роутеру при логине (скопировав его через какой-нибудь прокси вроде Burp Suite), и чтобы скрипт сам выцепливал почти все нужные ему данные. Ну а наполнив базу до относительно приличного объема, можно будет попробовать и уже боевые испытания провести.
И мне бы очень помогло, если бы кто-то посмотрел у себя дома у веб-интерфейса роутера файлы и сравнил бы их с файлами на онлайн симуляторах прошивок (а еще лучшим и аргументы при POST-запросах посмотреть).

Share Button
[Всего голосов: 9    Средний: 2.8/5]

Вам может быть интересно также:

Last updated by at .

Leave a Reply

You can use these HTML tags

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">