Атаки на Cisco cніффінг трафіку з роутера
Зміст статті
Сніфім трафік з роутера Cisco
Продовжимо тему, яка не влізла повністю до минулого випуску нашого хакбука :). Тоді ми обговорювали тему постексплуатації у разі захоплення контролю над Cisco роутером або свічем, а конкретніше можливість сніфа трафіку, що проходить через мережевий девайс. Адже у нас виходить реальний man-in-the-middle, оскільки трафік природно проходить через пристрій.
Тоді ми використовували фічу роутера Embedded Packet Capture, яка дозволяла нам зберігати пакети. Спосіб це дієвий і гнучкий (можна тонко налаштувати, що зняти), але має великий недолік для нас - обсяг пам'яті девайса. Наскільки мені набридло, це в середньому від 128 Мб до 2-4 Гб. Для цілей тестування при точному фільтрі цього може вистачити, але для «бойових умов» навряд чи. Для вирішення цієї проблеми ми можемо використовувати іншу фічу - дзеркаловання трафіку (port mirroring, port monitoring), коли весь трафік, що приходить на один мережевий інтерфейс обладнання, незмінно відправляється на інший порт.
Отже, як нам це реалізувати на практиці? Ця можливість в роутерах Cisco називається IP Traffic export і доступна з версії IOS 12.3(4)T. Для її реалізації нам потрібна така послідовність команд:
Входимо в конфігураційний режим:
Створюємо профіль з ім'ям TestFF для експорту трафіку:
Вказуємо, який трафік експортувати (весь - bidirectianal, вхідний, вихідний):
Далі - інтерфейс, куди експортуємо:
Виходимо з конфігурації профілю:
Задаємо, на яких інтерфейсах ми хочемо слухати трафік наступними двома командами.Спочатку вибираємо інтерфейс:
Призначаємо створений профіль:
Щоб зупинити сніф, необхідно повторити останні дві команди в режимі конфігурації, але вже з відключенням експорту (треба додати на початку):
Подивитися статистику з експорту можна командою
Крім того, цією ж можливістю, IP Traffic export можна експортувати трафік в NVRAM роутера, тобто аналогічно EPC.
І насамкінець хочу попередити, що з цим способом необхідно бути обережнішим, оскільки, по-перше, експорт витрачає деяку кількість ресурсів CPU у роутера, а по-друге, якщо ми експортуватимемо весь трафік з гігабітного інтерфейсу на 100-мегабітний, то може виникнути колапс:).
Хакер #196. Все про Docker
Сніфім трафік з Cisco-Свіча
Тепер трохи про свічі. Як було вже сказано, дзеркалювання трафіку — це можливість, властива саме свічам. Офіційна назва - SPAN (Switched Port Analyzer). Але тут, хоча суть та сама (трафік з одного інтерфейсу перекидається на інший), це реалізується інакше. Свіч не виробляє жодних замін значень заголовків ні канального, ні мережевого, ні інших рівнів у пакетах. Вони у незміненому вигляді копіюються на ще один мережний інтерфейс.
У SPAN є два основні терміни: source - інтерфейси, звідки копіюється трафік, та destination - куди копіюється трафік.
Реалізується це такою послідовністю:
Входимо в конфігураційний режим:
Вказуємо, який звідки трафік прослуховувати:
Вказуємо, куди його пересилати:
Тут також вказано номер сесії. Він використовується для угруповання source та destination, що дозволяє нам прослуховувати відразу кілька портів.
Цілкомпросто, погодься?
Але цей метод має кілька обмежень. По-перше, необхідно бути фізично підключеним до свічі, що не завжди можливо. По-друге, інтерфейс, зазначений як destination, перестає працювати як звичайний порт, тобто обробляти легітимний трафік, що входить/виходить від нас. І якщо ми захопили контроль над ним через SSH, наприклад, то включи ми дзеркалювання трафіку на інтерфейс — відразу втратимо контроль. Хоча слід зізнатися, що через відсутність гідного свіча перевірити другий пункт немає можливості.
У будь-якому випадку вирішенням обох проблем може бути технологія RSPAN (Remote SPAN) або ERSPAN (Encapsulated Remote SPAN). Перша з них дозволяє копіювати весь трафік у спеціальний VLAN (тобто ми вже можемо бути в одному мережевому сегменті, а не безпосередньо підключеними). Друга за рахунок інкапсуляції трафіку дозволяє передавати дані між мережами (L3). Ні з того, ні з іншого я справ не мав, тож якщо поламаєш якийсь свіч і вийде щось заюзати, то радий почути :).
До речі, останні кілька номерів ми обговорювали різні атаки на Cisco-девайси, тому якщо хочеш погратися/потестувати їх, то можна це зробити, навіть не володіючи реальним пристроєм. Все, що тобі знадобиться, - це тулза GNS3, що є емулятором для деяких версій роутерів цисочек, а також файрволів (ASA, PIX). Вона безкоштовна, тому потрібно лише знайти прошивок (у Гуглі).
Обходимо обмеження з IP Source Routing
Але про все по порядку. Є протокол IP, і спочатку в нього була додана ця можливість (Source Routing). Суть її полягає в тому, що хост-відправник пакету має можливість у заголовках IP-датаграми вказати, через які хопи (кінцеві хости, мережеве обладнання) цей пакет та відповідь нанього мають пройти. Так-так, ми можемо вказувати перелік пристроїв на шляху пакета, тобто ми як би «маршрутизуємо» його.
Причому розрізняються два види Source Routing: Strict та Loose. Перший — точна вказівка послідовності хостів (саме і лише через них має пройти пакет), другий — просто перелік хостів, через які пакет має пройти, тобто між цими хостами можуть бути якісь ще. Перший вид «спочатку» практично не використовувався, а другий досі номінально живий. Максимальна кількість хопів – дев'ять. Практично ця можливість була багато в чому задумана для тестування проблем в мережі, щоб ми зі свого хоста могли перевірити різні маршрути.
Окей, а тепер подивимося на прикладчику (взятому з www.enclaveforensics.com), як ми можемо це використовувати у своїх цілях (див. скріншот).
Отже, у нас є (спрощено): Alice та Bob, у яких «довірчі» стосунки. Наприклад, з IP Bob'а можна без аутентифікації підключатися Telnet'ом до Alice. Є Ivan — просто хост у мережі (принтер, мережний девайс), який має доступ до мережі Bob і Alice. Ми – Eddie та наш роутер – Lynksys (який насправді не дуже й потрібен). Завдання - підключитися до Alice від IP Bob'а, в обхід обмежень доступу з нашої мережі.
Як я думаю, ясно, по суті, ми можемо вказати IP Bob'a і відправити пакет Alice, але проблема в тому, що Telnet - це TCP, а значить, "триступеневий рукостискання", і означає, що Alice безпосередньо відповість Bob'у та підключення ми не отримаємо. А ось із використанням Loose Source Routing – зможемо. Для цього ми робимо таку послідовність:
Таким чином, Alice відповідає Bob'у, а так як пакет для цього має пройти через нас, то ми маємо можливість «привітатися через TCP-шному» та отримати такий для нас бажаний безаутентифікаційний доступ на Alice.
Якщо ж говорити про практичну сторону, спробувати ти можеш, використовуючи тулзу ncat (яка йде в комплекті з nmap). Тобі знадобиться параметр –g. Приклад дивись на картинці (необхідно насильно вказувати протокол IPv4, так що 4 теж параметри).
Як уже писалося, сучасні стаціонарні ОС та мережеве обладнання за промовчанням відкидають такі пакети. Але ніби старі цисочки, SOHO-роутери, embedded-девайси і всякі штуки типу мережевих принтерів все ще можуть підтримувати IP Source Routing.
Порівнюємо папки та файли в Meld
Давай вдамо, що це розділ X-Tools :).
Коли досліджуєш щось, то систематично виникають завдання або порівняти дві майже однакові директорії, або виявити різницю у кількох версіях файла. Дуже типовий приклад — порівняння вихідних джерел уразливої та пропатченої версії якогось ПЗ. Адже якщо дізнаємося, що було змінено, то зможемо створити експлойт.
Звичайно, є професійно ув'язнені тулзи для цих справ, та й у багатьох nix'ах спочатку є «вбудовані» можливості. Але мене нещодавно познайомили з чудовою тулзою, і я хотів би цим поділитися. Назва її - Meld.
До її переваг можна віднести крос-платформність (написана вона на Python і GTK) і з приємним простим інтерфейсом. Що треба для первинного поверхневого аналізу.
Атакуємо роутери через NAT-PMP
І ще одне завдання про мережі та мережеві атаки. Так Так! А то все Інтернет та Інтернет.
Відносно нещодавно з'явилася(Стандартом стала начебто в 2013 році) нова технологія - NAT PMP (NAT Port Mapping Protocol). Якщо загалом, вона використовується для автоматичного прокидання портів, переважно на SOHO-роутерах. Здавалося б, хто їй користуватиметься? Ан ні, просуває її компанія Apple, і це говорить нам про те, що підтримка буде тільки зростати. А тому вміння «ламати» такі девайси представляє пристойний інтерес, особливо тому, що вразливості, пов'язані з NAT-PMP, в основному конфігураційні (отже, навряд чи будуть «пропатчені»).
Але щось я розійшовся. Давай по порядку та з початку.
Отже, коли ти з ноута відправляєш запит на 8.8.8.8, роутер отримує Наш пакет (оскільки він стоїть шлюзом за замовчуванням у тебе на ноуті), бачить, що запит йде у зовнішню мережу, після чого починається процес NAT'а:
Таким чином, для твого ноуту ці перетворення залишаються непоміченими.
Залежно від порту, куди прийде пакет із відповіддю, він буде пересланий на той чи інший хост. До речі, саме тому такий вид NAT називається ще Port Address Translation. Все просто.
Але NAT вирішує одну проблему – підключення із сірого діапазону до білого. Зовні (з інтернету) практично немає можливості підключитись до якогось сервісу на твоєму ноутбуці. Розв'язання цього завдання - прокидання портів. Ми можемо вказати на роутері, що всі підключення, що надходять на 66.55.44.33 на порт 7777, повинні бути перекинуті на веб-сервер на ноуті 192.168.0.123:80. При цьому роутер виконує майже аналогічну операцію: підміняє в пакеті IP призначення зі свого зовнішнього на 192.168.0.123 і порт призначення з 7777 на 80. Пакети у відповідь від нашого веб-сервера піддаються зворотній зміні.
Окей. Перекидання портів - відмінне рішення. І я думаю, всі сучасні роутери дозволяютьналаштовувати його ручками через адмінку. Але вважаю, що середньостатистичний користувач навряд чи знає, що таке порт або де у роутера адмінка. З іншого боку, багато послуг, типу файлообміну або ігор, вимагають можливості зовнішніх підключень.
Рішенням буде автоматичне прокидання портів, коли програма на твоєму ноуті сама попросить роутер прокинути для нього такий порт і роутер виконає його бажання. Для цього можна використовувати протокол (точніше, набір протоколів) UPnP. Там є розширення Internet Gateway Device (IGD), яке створено спеціально для керування прокидом портів.
Не знаю, із чим точно були пов'язані потреби Apple у новому протоколі для заміни UPnP IGD. Можливо, справа в тому, що він був занадто універсальний, а тому дуже товстий (налаштування відбувається через три підключення до різних портів). До того ж у ньому було знайдено пучки вразливостей (переповняшки), що тут колись писалося. Але в будь-якому випадку Apple створила новий протокол і підтримує його у більшості своїх сучасних продуктів (наскільки мені відомо).
Зразковий, спрощений алгоритм такий:
Здавалося б, що тут такого може статися? Що тут взагалі ламати, якщо ти перебуваєш у зовнішній мережі (інтернеті) і хочеш атакувати користувачів, що перебувають за роутером?
Діти з Rapid7 провели цікаву роботу на цю тему і виявили низку проблем. Основна була пов'язана з некоректним настроюванням кінцевих девайсів (роутерів). За стандартом, запити NAT-PMP повинні оброблятися, коли вони приходять із внутрішнього діапазону, але на багатьох девайсах дозволена конфігурація і з WAN-інтерфейсу (тобто з Інтернету). Ця та деякі інші тонкощі дають можливість для атак. Причому тут важливо знати, що багато в чому це не проблеми кінцевихкористувачів, а некоректне налаштування з коробки, від вендорів роутерів. У результаті Rapid7 виявила в інтернеті близько мільйона вразливих пристроїв. Зауваж, це було сканування інтернету, а якщо згадати, що дуже багато користувачів знаходяться за NAT'ом від провайдерів, то число може зрости в рази (щоправда, для атаки на них необхідно бути підключеними до цього провайдера).
Найсмачніше тут — потенційні вектори атак через цю технологію, а вони тут, мабуть, виглядають вражаюче.
Перехоплення внутрішнього трафіку
Ми надсилаємо на зовнішній інтерфейс на NAT-PMP запит, щоб весь вхідний внутрішній трафік такий порт був «прокинутий» нам. Тобто ми можемо змусити роутер пересилати нам дані, що надходять на якийсь із внутрішніх портів його самого. А що це може бути? По-перше, адмінка: порти 23, 22, 80, 443. Піднімаємо у себе веб-сервер і знімаємо креди. Але ще цікавіше захоплення DNS-запитів. Адже роутери дуже часто використовуються як DNS-сервер, а тут ми взяли такі і вказали прокидання запитів собі. У результаті піднімаємо підроблений DNS-сервак і маємо чудову нагоду для різних MITM-атак.
Перехоплення зовнішнього трафіку
Майже аналогічна атака. Але тут ми змушуємо роутер перекидати всі підключення на зовнішній інтерфейс роутера на наш хост.
Цікавість цього варіанта сильно залежить від ситуації.
Доступ до внутрішніх хостів (за NAT'ом)
Що ще приємно, у Metasploit'і тепер є відповідні модулі для атак на сервіси NAT-PMP:
Дякуємо за увагу та успішних знань нового!