Теория.
Эту часть всем осведомленным можно пропустить.
Как всегда, сначала надо оговорить, что под роутерами будут подразумеваться в большинстве своем SOHO роутеры, которые стоят в общественных местах, домах и тд. А также под "вскрытием" понимается открытие доступа к роутеру из глобальной сети и получение данных для этого доступа (об этом подробнее потом).
Итак, почти всегда (и по дефолту) роутеры закрыты для доступа из вне и как-то с ними взаимодействовать (кроме переправки сетевых пакетов) можно только из локальной (часто беспроводной) сети, то есть попасть в настройки можно толкьо подключившись к нему через Ethernet кабель или по WiFi, если есть такая функция. Всем, кто настраивал или пробовал залезть в настройки известно, что роутеры исопльзуют пул частных IP-адресов и назначают эти адреса всем подключившемся к ним машинам, создавая локальную сеть между этими устрйоствами (включая их самих), и через частный IP роутера (может быть разный, но на практике вариантов совсем мало) можно зайти в его админсткую панель через веб-интерфейс и настроить там, все что он предложит. То есть у него там запущен какой-то веб-сервер, который и предлагает это сделать, можно сказать это сайт в этой локальной сети, через который можно провести настройку. Только эти настройки ограничиваются логином и паролем для защиты. Но в почти всегда обычным юзерам не хочется лезть в настройки (или не приходится), и настраивающие роутеры люди тоже не меняют пароли от настроек и они остаются дефолтными.
Задумка.
По моим наблюдениям (в моих случаях всегда, но возможно это не так) в большинстве роутеров в HTTP-заголовках ответов не было заголовка X-Frame-Options (хотя это не помеха, как выяснилось позже), то есть весь веб-интерфейс можно слегкостью подгрузить во фрейме. Но рулить содержимым <iframe> через JS мы не сможем, так как Cross Origin Policy браузеров не позволит, более того, мы даже не сможем увидеть, какой реальный адрес подгрузился во фрейме (если там был редирект) и тем более HTML-код в нем.
Несмотря на эти ограничения пользу из ситуации все же можно вынести: можно на основе шаблонов пробовать угадать марку и модель роутера, затем через дофолтные логин/пароль для этой модели залогиниться и отправлять все HTTP-запросы в тот <iframe>, тем самым как-никак, но мы получается будем управлять роутером.
Но управлять таким образом очень сложно, неудобно и довольно велика вероятность, что кое-что кое-где может пойти не так вся цепочка действий прервется или ключевые действия не будут выполнены, поэтому идея заключается в том, что мы:
Но для эффективности я еще сделал так, что после первой попытки авторизации скрипт еще раз посылает все логины и пароли из его словаря (при нужной установке переменных в скрипте). Это работает, так как нам достаточно один раз угадать логин и пароль, далее при успешной попытке они сохраняются в cookies или в сессиях на самом роутере (опять же, так может быть не у всех, но в моем случае было всегда), и мы можем еще перепробовать пару ложных паролей (cookie не удаляться при этом) и потом уже отправлять HTTP-запросы для открытия порта.
Теперь стоит упомянуть, когда это не сработает:
Реализация.
Определение марки и модели роутера. Сначала долго думал, каким способом можно это сделать, учитывая, что из доступных средств у нас толко JS (можно конечно сюда и флеш с джавой приспособить, но хром сейчас, напрмер, по умолчанию флеш на паузу ставит, да и не установлен может он быть + это нам мало что даст, по сравнению с JS'ом). Потом придумал (и выяснил, что до меня это уже кто-то догадался), что каждый роутер при подгрузке веб-интерфейса используют каие-то картинки, css-файлы, js-файлы, которые мы в принципе без каких-либо ограничений можем заправшивать у веб-сервера роутера с нашего подгуржаемого сайта. Тем самым, определив наличие/отсутствие каких-то файлов можно с относительно точной вероятностью сказать, что у юзера используется такой-то роутер и что там скорее всего стоят такие-то логин и пароль, и нам надо отправить такой-то HTTP-запрос, чтобы залогиниться и поставить настройку открытия внешнего администрирования.
Это подводит еще к моменту, что придется сосатвлять базу "отпечатков" конфигураций файлов js/css/картинок для каждой интересующий нас модели и так же в эту базу добавлять данные, как с этой моделью работать и какие там используются пароль и логин.
Забегаю чуть вперед, можно увидеть проблему в отправке POST зарпосов в <iframe>, но благо браузеры позволяет нашим формам (<form>) через атрибут target указать, куда будем сабмититься, то есть можно указать имя нашего фрейма и все POST запросы будут отсылаться в него.
Получившийся JS код прикреплю к теме и не буду вдаваться в его подробности, лишь опишу кратко алгоритм работы:
Параметры скрипта.
Тут их всего 2, которые можно поставить через переменные в начале. Первый - это число роутеров, которые будут выбираться из кандидатов (по умолчанию будет выбираться наиболее вероятная тройка). Второй параметр ставит режим брута, то есть на этапе логина по дефолтным данным будет проведен небольшой брут по топовым дефолтным парам логин-пароль для роутеров.
Для статистики - у меня при установках на 1 роутер и без брута уходило около 3-4 секунд в целом, а при установках также на 1 роутер и с брутом - около 20 секунд.
Составление базы данных.
Тут может быть несколько моментов (сложностей). Первое - это всякие токены и прочая муть, которая по сути является лишней информацией (если вообще не мешает провернуть дело), так например у меня при отправлении POST запроса на выставление "в мир" 8080 порта отправилась хренова туча инфы (другие настройки, которые должны были измениться), я конечно часть полей ненужных мне настроек удалил (и проверил работоспособность), но делать так с каждым роутером при составлении базы очень муторно, поэтому сначала, наверное, придется отправлять не удалять лишние поля, а отсылать их данные вместе с нужными. А выдергивание этих полей из HTTP-запросов (при их сниффинге каким-нибудь прокси) можно будет поручить потом какому-нибудь скрипту.
Также пока не проверил, насколько точную инфу по роутерам (их файлам, данным, которые надо отправлять в запросах) можно получить от онлайн-симуляторов прошивок. Возможно, что там они немного отличаются и придется каждую прошивку качать и запускать в эмуляторе отдельно - это второй момент.
Третий заключается в том, что у одной и той же модели (одной и той же марки) в разных версиях прошивок могут быть разные конфиги файлов и данных для запросов. Это я пока не проверил, нахожусь в процессе.
Есть еще одна особенность, что у некоторых роутеров перед передачей данных они сначала обрабатываются (передаются их хеши чаще всего), для этого в структуре объявлена переменная, которая для каждой модели будет обозначать имя функции (которую надо брать из у моделей), вызывающуюся перед отправкой данных. Функция обработки данных авторизации, как правило, вызываются через аттрибут onsubmin формы отправки данных.
Под конец.
Это пока можно сказать прототип, так как почти нет оптимизации работы скрипта (разве что изначально алгоритм подбирался таким образом, чтобы комп у юзера не зарычал от нагрузки и при этом была работа в несколько потоков), поэтому потом можно будет провести небольшой рефакторинг с целью оптимизации скорости (если база будет очень большая и ее обработка будет занимать относительно много времени) и база сейчас почти пустая, потом ее надо будет тоже наполнить хотя бы самыми популярными моделями.
Для себя планирую написать вспомогательный скрипт для составления БД, чтобы туда можно было послать дамп HTTP-запроса к роутеру при логине (скопировав его через какой-нибудь прокси вроде Burp Suite), и чтобы скрипт сам выцепливал почти все нужные ему данные. Ну а наполнив базу до относительно приличного объема, можно будет попробовать и уже боевые испытания провести.
И мне бы очень помогло, если бы кто-то посмотрел у себя дома у веб-интерфейса роутера файлы и сравнил бы их с файлами на онлайн симуляторах прошивок (а еще лучшим и аргументы при POST-запросах посмотреть).
Эту часть всем осведомленным можно пропустить.
Как всегда, сначала надо оговорить, что под роутерами будут подразумеваться в большинстве своем SOHO роутеры, которые стоят в общественных местах, домах и тд. А также под "вскрытием" понимается открытие доступа к роутеру из глобальной сети и получение данных для этого доступа (об этом подробнее потом).
Итак, почти всегда (и по дефолту) роутеры закрыты для доступа из вне и как-то с ними взаимодействовать (кроме переправки сетевых пакетов) можно только из локальной (часто беспроводной) сети, то есть попасть в настройки можно толкьо подключившись к нему через Ethernet кабель или по WiFi, если есть такая функция. Всем, кто настраивал или пробовал залезть в настройки известно, что роутеры исопльзуют пул частных IP-адресов и назначают эти адреса всем подключившемся к ним машинам, создавая локальную сеть между этими устрйоствами (включая их самих), и через частный IP роутера (может быть разный, но на практике вариантов совсем мало) можно зайти в его админсткую панель через веб-интерфейс и настроить там, все что он предложит. То есть у него там запущен какой-то веб-сервер, который и предлагает это сделать, можно сказать это сайт в этой локальной сети, через который можно провести настройку. Только эти настройки ограничиваются логином и паролем для защиты. Но в почти всегда обычным юзерам не хочется лезть в настройки (или не приходится), и настраивающие роутеры люди тоже не меняют пароли от настроек и они остаются дефолтными.
Задумка.
По моим наблюдениям (в моих случаях всегда, но возможно это не так) в большинстве роутеров в HTTP-заголовках ответов не было заголовка X-Frame-Options (хотя это не помеха, как выяснилось позже), то есть весь веб-интерфейс можно слегкостью подгрузить во фрейме. Но рулить содержимым <iframe> через JS мы не сможем, так как Cross Origin Policy браузеров не позволит, более того, мы даже не сможем увидеть, какой реальный адрес подгрузился во фрейме (если там был редирект) и тем более HTML-код в нем.
Несмотря на эти ограничения пользу из ситуации все же можно вынести: можно на основе шаблонов пробовать угадать марку и модель роутера, затем через дофолтные логин/пароль для этой модели залогиниться и отправлять все HTTP-запросы в тот <iframe>, тем самым как-никак, но мы получается будем управлять роутером.
Но управлять таким образом очень сложно, неудобно и довольно велика вероятность, что кое-что кое-где может пойти не так вся цепочка действий прервется или ключевые действия не будут выполнены, поэтому идея заключается в том, что мы:
- определяем марку и модель роутера;
- подбираем для модели дефолтные логин/пароль;
- после авторизации открываем порт для внешнего доступа к роутеру;
Но для эффективности я еще сделал так, что после первой попытки авторизации скрипт еще раз посылает все логины и пароли из его словаря (при нужной установке переменных в скрипте). Это работает, так как нам достаточно один раз угадать логин и пароль, далее при успешной попытке они сохраняются в cookies или в сессиях на самом роутере (опять же, так может быть не у всех, но в моем случае было всегда), и мы можем еще перепробовать пару ложных паролей (cookie не удаляться при этом) и потом уже отправлять HTTP-запросы для открытия порта.
Теперь стоит упомянуть, когда это не сработает:
- если юзер сменил дефолтные логин и пароль (и сменил не на другие дефолтные);
- если авторизация осуществляется с капчей или какими-нибудь токенами (такое пару раз видел, но редко);
Реализация.
Определение марки и модели роутера. Сначала долго думал, каким способом можно это сделать, учитывая, что из доступных средств у нас толко JS (можно конечно сюда и флеш с джавой приспособить, но хром сейчас, напрмер, по умолчанию флеш на паузу ставит, да и не установлен может он быть + это нам мало что даст, по сравнению с JS'ом). Потом придумал (и выяснил, что до меня это уже кто-то догадался), что каждый роутер при подгрузке веб-интерфейса используют каие-то картинки, css-файлы, js-файлы, которые мы в принципе без каких-либо ограничений можем заправшивать у веб-сервера роутера с нашего подгуржаемого сайта. Тем самым, определив наличие/отсутствие каких-то файлов можно с относительно точной вероятностью сказать, что у юзера используется такой-то роутер и что там скорее всего стоят такие-то логин и пароль, и нам надо отправить такой-то HTTP-запрос, чтобы залогиниться и поставить настройку открытия внешнего администрирования.
Это подводит еще к моменту, что придется сосатвлять базу "отпечатков" конфигураций файлов js/css/картинок для каждой интересующий нас модели и так же в эту базу добавлять данные, как с этой моделью работать и какие там используются пароль и логин.
Забегаю чуть вперед, можно увидеть проблему в отправке POST зарпосов в <iframe>, но благо браузеры позволяет нашим формам (<form>) через атрибут target указать, куда будем сабмититься, то есть можно указать имя нашего фрейма и все POST запросы будут отсылаться в него.
Получившийся JS код прикреплю к теме и не буду вдаваться в его подробности, лишь опишу кратко алгоритм работы:
- из базы берется элемент данных;
- проверяется его файлы один за другим;
- если файла нет на сервере, то записывается количество совпадений остальных файлов элемента данных;
- если совпали все файлы (или количество совпадений наибольшее), то берется из элемента данных инструкция и выполняется;
- если в результате перебора базы точных совпадений небыло, то выбираются "победители", с ниабольшим числом совпадений (их может быть несколько);
- если совпадений нет, то все заканчивается;
- далее просто для каждого "победителя" выполняются заложенные в базу команды;
- после окончания работы (если были совпадения) на сервер отправляется уведомление;
Параметры скрипта.
Тут их всего 2, которые можно поставить через переменные в начале. Первый - это число роутеров, которые будут выбираться из кандидатов (по умолчанию будет выбираться наиболее вероятная тройка). Второй параметр ставит режим брута, то есть на этапе логина по дефолтным данным будет проведен небольшой брут по топовым дефолтным парам логин-пароль для роутеров.
Для статистики - у меня при установках на 1 роутер и без брута уходило около 3-4 секунд в целом, а при установках также на 1 роутер и с брутом - около 20 секунд.
Составление базы данных.
Тут может быть несколько моментов (сложностей). Первое - это всякие токены и прочая муть, которая по сути является лишней информацией (если вообще не мешает провернуть дело), так например у меня при отправлении POST запроса на выставление "в мир" 8080 порта отправилась хренова туча инфы (другие настройки, которые должны были измениться), я конечно часть полей ненужных мне настроек удалил (и проверил работоспособность), но делать так с каждым роутером при составлении базы очень муторно, поэтому сначала, наверное, придется отправлять не удалять лишние поля, а отсылать их данные вместе с нужными. А выдергивание этих полей из HTTP-запросов (при их сниффинге каким-нибудь прокси) можно будет поручить потом какому-нибудь скрипту.
Также пока не проверил, насколько точную инфу по роутерам (их файлам, данным, которые надо отправлять в запросах) можно получить от онлайн-симуляторов прошивок. Возможно, что там они немного отличаются и придется каждую прошивку качать и запускать в эмуляторе отдельно - это второй момент.
Третий заключается в том, что у одной и той же модели (одной и той же марки) в разных версиях прошивок могут быть разные конфиги файлов и данных для запросов. Это я пока не проверил, нахожусь в процессе.
Есть еще одна особенность, что у некоторых роутеров перед передачей данных они сначала обрабатываются (передаются их хеши чаще всего), для этого в структуре объявлена переменная, которая для каждой модели будет обозначать имя функции (которую надо брать из у моделей), вызывающуюся перед отправкой данных. Функция обработки данных авторизации, как правило, вызываются через аттрибут onsubmin формы отправки данных.
Под конец.
Это пока можно сказать прототип, так как почти нет оптимизации работы скрипта (разве что изначально алгоритм подбирался таким образом, чтобы комп у юзера не зарычал от нагрузки и при этом была работа в несколько потоков), поэтому потом можно будет провести небольшой рефакторинг с целью оптимизации скорости (если база будет очень большая и ее обработка будет занимать относительно много времени) и база сейчас почти пустая, потом ее надо будет тоже наполнить хотя бы самыми популярными моделями.
Для себя планирую написать вспомогательный скрипт для составления БД, чтобы туда можно было послать дамп HTTP-запроса к роутеру при логине (скопировав его через какой-нибудь прокси вроде Burp Suite), и чтобы скрипт сам выцепливал почти все нужные ему данные. Ну а наполнив базу до относительно приличного объема, можно будет попробовать и уже боевые испытания провести.
И мне бы очень помогло, если бы кто-то посмотрел у себя дома у веб-интерфейса роутера файлы и сравнил бы их с файлами на онлайн симуляторах прошивок (а еще лучшим и аргументы при POST-запросах посмотреть).
Код:
https://mega.nz/#!Ix9zgJAR!ejVyDX0sFfQNRPfb58A9VQpoiHay1UjQDWy4skl1Sq4
