а вот я не прочь себя в android программировании попробовать, посмотрим что да как. Как вариант из локальной базы на телефоне вида essid:bssidassword производить сравнение с доступными, либо добавлять местоположение точкам из локальной бд по доступным
Вопрос по router scan'у: можно ли как-то сделать, чтобы он автоматически проверял и писал в таблицу геопозицию всех найденный роутеров? А то приходится тыкать на каждый роутер и жать ctrl+l.
На счет свежести инфо не знаю, но вот чищю базу 3WiFi, натыкаюсь на такие строчки: Name: Micro DSL (96328A-1341N1 | A741-S406QTH-C02 R05.B2pD032c.d23e) BSSID: <!--[BCMBG-WLAN-0 Остальные поля определились нормально. Логи можно найти в RouterScanLog20150711.txt Так же криво парсятся данные: name: OpenWrt X-Wrt (name: OpenWrt, model: NTE-RG-1402G-W) (попадают теги в поля ESSID и Security) name: D-Link DSL-2640NRU name: D-Link DIR-300, hardware: B1, firmware: 2.04 name: Upvel UR-309BN Router Все есть в логе RouterScanLog20150711.txt
Вот еще отловил name: ZyNOS ADSL (<INPUT TYPE="BUTTON" NAME="Logout" VALUE="Logout" onClick="doLogout()" class="sbutton">) Водится в больших количествах здесь: 37.53.84.104 37.54.215.83 37.53.1.125 46.201.8.84 91.124.242.221 92.113.22.102 95.133.43.75 95.133.241.121 95.135.163.220 name: ZyNOS ADSL (<B>ADSL WiFi 802.11g Lite) Здесь: 178.36.94.20 178.36.128.48
name: D-Link DAP-1155, hardware: A1, firmware: ver1.00 LAN IP: 5.228.103.236</div> Замечены здесь (Москва, OnLime): 176.194.172.253 176.194.173.16 176.194.5.138 178.140.119.187 178.140.185.233 178.140.216.157 178.140.231.228 178.140.242.56 178.140.6.179
вот еще если можно это исправить 79.174.34.249 80 46 SQLite Done Seems to be ASUS RT-N12 192.168.1.1 255.255.255.0 79.174.48.253 8080 31 SQLite Done Seems to be ASUS RT-N66U 192.168.0.1 255.255.255.0 79.174.52.235 8080 32 SQLite Done Seems to be ASUS RT-N12 Rev.B1 192.168.0.1 255.255.255.0 217.117.252.254 8080 16 SQLite Done Seems to be ASUS RT-N12VP 192.168.0.1 255.255.255.0 134.0.111.198 80 32 SQLite Done RT-N11P 192.168.10.1 255.255.255.0 134.0.111.198 8080 78 SQLite Done RT-N11P 192.168.10.1 255.255.255.0 91.123.18.157 8080 47 SQLite Done Seems to be ASUS RT-N66U 50:46:5D:00:2C:48 VIRUS192.168.1.1 255.255.255.055.67900085449219 37.2760009765625 46.235.64.57 80 32 SQLite Done Seems to be ASUS RT-AC66U BC:EE:7B:7A:69:F0 Wi-Fi 2.4 192.168.1.1 255.255.255.0
А что с этими не так? По-моему здесь всё правильно. 1. У вас был включён модуль SQLite, поэтому в статусе результат выполнения последнего модуля (в новой версии, кстати, будет просто "Done"). 2. Роутеры просканировались, уязвимости позволили получить некоторые данные. 3. Пароли к админке не удалось подобрать/получить. 4. А когда доступа к админке нет, пишет Seems to be %Model%, впрочем может я это изменю к релизу.
Вопрос. Если изменили логин пароль на наностейшен м5, РоутерСкан до роутера пробьётся если на роутере дефолтный логин пароль? Подробнее. Провайдер поставляет интернет по оборудованию <Ubiquiti>. логин пароль ubnt:ubnt изменил, я сканю свой диапазон ip,выдаёт кучу наностейшенов всяких без доступа, а как до роутеров достучатся? Как узнать логин:пароль наностейшен.
Сегодня утром на гик-хабре прочитал захватывающую дух статью по нашей теме: http://geektimes.ru/post/253392/ И задумался... интересно, есть ли роутеры, которые Router Scan по каким-то причинам вывел из строя. И если да, то сколько их. Проект предполагает использование неразрушающих уязвимостей, эксплуатация которых не должна приводить к падениям, отказам в обслуживании, и прочим малоприятным последствиям. Сегодня же, во время тестового сканирования диапазонов МГТС, обнаружил, что многие роутеры ZTE F660 вместо веб-админки выдают 500 Internal Error, выводя неизвестную ошибку в одном из системных скриптов. В браузере это выглядит так: Решил попробовать зайти в telnet, и получилось - порт 23 был открыт, и пароль был одним из стандартных. Посмотрел структуру папок - в /home/httpd было пусто! Но этого не может быть, файловая система ведь только для чтения. Решил копнуть в сторону монтированных разделов, и наткнулся на такую вещь: Code: / # mount proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw) /dev/mtdblock2 on /tagparam type jffs2 (rw) tmpfs on /var type tmpfs (rw) /dev/mtdblock5 on /userconfig type jffs2 (rw) none on /proc/bus/usb type usbfs (rw) tmpfs on /home/httpd type tmpfs (rw) Последняя строчка указывает, что смонтирована временная ФС в памяти устройства по адресу /home/httpd. И тут мне пришло в голову, что один из эксплойтов Router Scan для ZTE использует телнет и монтирование временного хранилища для подгрузки скрипта test_gch.gch, получающего пароль администратора. Казалось бы, в коде данного эксплойта предусмотрено последующее размонтирование директории после получения пароля... но не всё так гладко. Router Scan имеет свойство зависать при одновременной обработке большого кол-ва устройств и иногда падать. А это означает, что эксплойт может остановиться на пол пути, не размонтировав директорию, таким образом вызвав отказ в обслуживании веб интерфейса. После я решил узнать, сколько таких сломанных админок насчитывается в мире... https://www.shodan.io/search?query=Mini+web+server+ZTE+corp+500+Error А их чуть более полкило! (Showing results 1 - 10 of 519) В общем, сей факт меня не радует, и я добавил в Router Scan код, позволяющий определить данную неисправность, и в автоматическом режиме (как всегда) исправить её через тот же telnet. Исправляется всё очень просто: 1. Получаем root шелл 2. umount /home/httpd 3. exit После чего функционал веб интерфейса приходит в норму. Конечно, данный недочёт не является критическим, поскольку он также исправляется обычной перезагрузкой, но всё же мало приятным. Исправляющая фича будет доступна в релизе.
Если точки настроены в режиме роутеров (т.е. включен NAT), то чтобы достучаться до оконечного оборудования, надо пробросить соответствующий порт на его внутренний ip. Если обе точки настроены в режиме роутера, то это надо проделать на обеих точках. Для сканрования следующего роутера во внутренней сети наностэйшна придется проделать все тоже самое. Короче это геморой еще тот! Другое дело, если наностэйшны работают в режиме моста, тогда нужно просто сканировать соответсвующий диапазо IP, на котором сидят абоны, а не наностэйшны, и будет все ок.
Хы, моя статейка binarymaster, может быть стоит добавить эту уязвимость в RouterScan? Это как минимум позволит узнать SSID и пароль от WiFi. Так же можно сделать так, чтобы RouterScan этот пароль попробовал и к web-интерфейсу, т. к. зачастую они совпадают, как мы видим.
