New bit Ковель 1

Злом роутера TP-LINK

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

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

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

Ми спробували самі скомпілювати netcat під MIPS, але задати опцію дефолтного порту так і не змогли. Далі ми використовували дизассемблер, але так само безуспішно. І тут я вирішив відкрити цей бінарник звичайним Notepad ++, і, на свій подив знайшов там заповітні 2222. Це число можна було без проблем міняти на будь-яке інше, головне - щоб кількість символів в файлі не змінилося. Порт дійсно змінювався, все було протестовано на QEMU, тільки от змусити його заробити на роутері нам так і не вдалося.

Здавалося, що це глухий кут, довгий час у мене не було жодної зачіпки, але щось підказувало мені, що уразливості все ж є. І тут я з'ясував, що роутер не фільтрує GET запити. Тобто за замовчуванням при невірно введеному паролі відкривається сторінка / help, але якщо ми, наприклад, зробимо такий запит:
GET IP: port / help /../../
То ми потрапимо в корінь файлової системи роутера. Таким чином ми можемо завантажити практично будь-який файл з ФС роутера навіть не знаючи пароля. Це виявилася перша успішно працює вразливість з усіх знайдених мною. Але що вона нам дає, якщо ми можемо тільки завантажувати файли і при цьому не знаємо, де зберігається пароль?

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

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

Так само я дізнався, що логіном від VPN підключення для доступу в інтернет є ініціали та прізвище юзверя або її частина, а пароль все той же. Я став думати, як же мені знайти потрібного мені користувача? Може я все-таки помилився в той раз з визначенням IP, і він вже встиг помінятися, поки я спробував Законекть до вебморде? Перше, що спало на думку - це простий перебір всіх роутерів. Але кількість абонентів у провайдера досить велика. Просканувавши весь діапазон, я виявив близько 3000 роутерів з віддаленим доступом до web-інтерфейсу. І потрібно було якось знайти серед них потрібний, якщо він взагалі там є.

Спочатку я намагався написати скрипт, який би за допомогою знайденої уразливості дізнавався пароль, а далі скачував б сторінку настройки мережі та зберігав її. Але в цьому я слабий, і, відкинувши через деякий час цю ідею, я вирішив використовувати звичайний клікер. З горем навпіл я (вірніше клікер) обробив весь діапазон. Далі я зробив пошук по файлах з настройками (сподіваючись знайти жертву на прізвище в логіні від vpn-з'єднання), але нічого потрібного мені я так і не знайшов.

Я став копати далі і виявив, що будь-яким зламаним роутером можна через web-інтерфейс просканувати навколишні його точки доступу. Таким чином, у мене з'явилася божевільна ідея: зламати сусіда жертви цієї вразливістю, щоб потім його роутером спробувати зламати пароль від Wi-Fi жертви і зайти в web-інтерфейс вже через LAN, т. К. Проробляти шлях в 1600км без впевненості в успіху було нерозумним, та й просто можливості не було. Але і здійснити задумане на той момент здавалося немислимим. Як відшукати сусіда?

Відмінно! Роутер знайшли, як і сусідів, витративши, правда, на це дуже багато часу. Що ж далі? Потрібно якось отримати пароль від бездротової мережі, але для цього нам потрібно або перехопити 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

Насамперед я спробував зрозуміти, яким саме чином сервер визначає, що вхід виробляється з нового пристрою. Все виявилося досить просто: в браузер додається новий Cookie (якщо мені не зраджує пам'ять, то називається remixttpid), який передається тільки через шифрування з'єднання. І по ньому вже сервер визначає браузер, з якого дозволено вхід. Якщо не помиляюся, User-Agent теж повинен збігатися. Таким чином, нам досить перехопити цей cookie, щоб успішно залогінитися з відомим паролем, але це зробити досить складно: потрібно пропускати трафік користувача через mitmproxy, та так, щоб він ще й залогінився в цей момент. До того ж користувач помітить попередження браузера про розбіжності сертифіката. Навіщо так перекручуватися, подумав я, якщо можна просто перехопити вже існуючу сесію? Адже перевірка браузера проводиться тільки в момент логіна, але не проводиться при будь-яких запитах з уже існуючою сесії! Отже, нам всього лише потрібно перехопити remixsid. який, до того ж, передається через незахищене з'єднання, т. к. юзверя не використовує https.

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

У зв'язку з переведенням всіх користувачів на IPoE в недавні часи і відмовою від VPN, всі вони виявилися за NAT'ом, включаючи роутери, на яких мною було піднято VPN для доступу до внутрішньої мережі провайдера. Крім тих, хто подключід собі послугу «Статична IP», зрозуміло. Але і тут проблема: ті, хто хоче реальний IP, повинні все ще використовувати VPN для доступу в інтернет. Довелося мені помучитися і зібрати OpenWRT з вшитим і налаштованим PPTP-клієнтом (а працює він чомусь дійсно криво), а так само вшитим і налаштованим OpenVPN сервером. Чимало роутерів загинуло в ході експериментів, але результат в підсумку було досягнуто. Залив на кілька роутерів (з небагатьох, що залишилися з real IP) таку прошивку, я маю стабільний доступ у внутрішню мережу за допомогою OpenVPN.

Проблема з підключенням PPTP VPN полягала в тому, що сервера провайдера не підтримують шифрування. Це вдалося пофиксить додаванням рядка в /ppp/options.pptp.
nomppe
В іншому процес налаштування PPTP VPN клієнта і OpenVPN сервера нічим не відрізнявся від мінлива по OpenWRT.