Содержание статьи
Снифим трафик с роутера Cisco
Продолжим тему, которая не влезла полностью в прошлый выпуск нашего хакбука :). Тогда мы обсуждали тему постэксплуатации в случае захвата контроля над Cisco роутером или свичем, а конкретнее — возможность снифа трафика, проходящего через сетевой девайс. Ведь у нас получается реальный man-in-the-middle, так как трафик естественным образом проходит через устройство.
В тот раз мы использовали фичу роутера Embedded Packet Capture, которая позволяла нам сохранять пакеты. Способ это действенный и гибкий (можно тонко настроить, что снифать), но имеет большой недостаток для нас — объем памяти девайса. Насколько мне нагуглилось, это в среднем от 128 Мб до 2–4 Гб. Для целей тестирования при точном фильтре этого может и хватить, но для «боевых условий» уже вряд ли. Для решения этой проблемы мы можем использовать другую фичу — зеркалирование трафика (port mirroring, port monitoring), когда весь трафик, приходящий на один сетевой интерфейс оборудования, в неизмененном виде отправляется на другой порт.
Изначально эта возможность идет от свичей (у которых портов обычно много), но это организовать можно и на роутере (даже если у него один физический порт), перекидывая трафик в какой-то VLAN например. При этом роутер оставляет данные IP-уровня и выше в неизменном виде, а вот данные канального уровня меняет, так как должен указать MAC-адрес устройства, которое уже будет «принимать» трафик.
Итак, как же нам это реализовать на практике? Возможность эта в роутерах Cisco называется IP Traffic export и доступна с версии IOS 12.3(4)T. Для ее реализации нам потребуется такая последовательность команд:
Входим в конфигурационный режим:
Conf termСоздаем профиль с именем TestFF для экспорта трафика:
ip traffic-export profile TestFF mode exportУказываем, какой трафик экспортировать (весь — bidirectianal, входящий, исходящий):
BidirectionalДалее — интерфейс, куда экспортируем:
interface fastEthernet 0/0И последнее, что нужно для профиля, — MAC-адрес устройства, куда отправлять трафик:
mac-address 5427.1E0C.45B1Выходим из конфигурации профиля:
ExitЗадаем, на каких интерфейсах мы хотим слушать трафик, следующими двумя командам. Сначала выбираем интерфейс:
interface fastEthernet 1/0Назначаем созданный профиль:
ip traffic-export apply TestFFВ примере мы весь трафик с интерфейса fastEthernet 1/0 перекидываем на fastEthernet 0/0. При этом наш хост, где мы уже фактически будем снифать трафик, может быть не напрямую подсоединен к fastEthernet 0/0, а через свичи, то есть главное — быть в одном сетевом сегменте. Достигается это за счет того, что роутер как раз подменяет канальный уровень, указывая в поле назначения наш MAC-адрес, который уже нормально обрабатывают промежуточные свичи. В качестве MAC-адреса отправителя роутер указывает свой (выходного интерфейса).
Чтобы остановить сниф, необходимо повторить последние две команды в режиме конфигурации, но уже с отключением экспорта (надо добавить no в начале):
interface fastEthernet 1/0
no ip traffic-export apply TestFFПосмотреть статистику по экспорту можно командой
show ip traffic-exportКроме того, этой же возможностью, IP Traffic export, можно экспортировать трафик в NVRAM роутера, то есть аналогично EPC.
И в конце хочу предупредить, что с этим способом необходимо быть осторожнее, так как, во-первых, экспорт затрачивает некоторое количество ресурсов CPU у роутера, а во-вторых, если мы будем экспортировать весь трафик с гигабитного интерфейса на 100-мегабитный, то может возникнуть коллапс :).
Снифим трафик с Cisco-свича
Теперь немножко о свичах. Как было уже сказано, зеркалирование трафика — это возможность, изначально свойственная именно свичам. Официальное название — SPAN (Switched Port Analyzer). Но здесь, хотя суть та же (трафик с одного интерфейса перекидывается на другой), реализуется это иначе. Свич не производит никаких подмен значений заголовков ни канального, ни сетевого, ни других уровней в пакетах. Они в неизмененном виде копируются на еще один сетевой интерфейс.
В SPAN есть два основных термина: source — интерфейсы, откуда копируется трафик, и destination — куда копируется трафик.
Реализуется это такой последовательностью:
Входим в конфигурационный режим:
Conf termУказываем, какой откуда трафик прослушивать:
monitor session 1 source interface fastethernet 0/1Указываем, куда его пересылать:
monitor session 1 destination interface fastethernet 0/0Здесь также указан номер сессии. Он используется для группировки source и destination, что позволяет нам прослушивать сразу несколько портов.
Вполне просто, согласись?
Но метод этот имеет несколько ограничений. Во-первых, необходимо быть физически подключенным к свичу, что не всегда возможно. Во-вторых, интерфейс, указанный как destination, перестает работать как обычный порт, то есть обрабатывать входящий / исходящий от нас легитимный трафик. И если мы захватили контроль над ним через SSH например, то включи мы зеркалирование трафика на интерфейс — сразу потеряем контроль. Хотя надо признаться, что из-за отсутствия достойного свича проверить второй пункт нет возможности.
В любом случае решением обеих проблем может быть технология RSPAN (Remote SPAN) или ERSPAN (Encapsulated Remote SPAN). Первая из них позволяет копировать весь трафик в специальный VLAN (то есть мы уже можем быть в одном сетевом сегменте, а не подключенными напрямую). Вторая за счет инкапсуляции трафика позволяет передавать данные и между сетями (L3). Ни с той, ни с другой я дел не имел, так что если поломаешь какой-то свич и получится что-то заюзать, то буду рад услышать :).
Кстати, последние несколько номеров мы обсуждали различные атаки на Cisco-девайсы, так что если хочешь поиграться/потестировать их, то можно это сделать, даже не обладая реальным устройством. Все, что тебе понадобится, — это тулза GNS3, представляющая собой эмулятор для некоторых версий роутеров цисочек, а также файрволов (ASA, PIX). Она бесплатная, так что нужно лишь найти прошивок (в Гугле).
Обходим ограничения с IP Source Routing
Существует достаточно интересная сетевая атака, которая позволяет нам обходить различные ограничения. Например, фильтрацию по IP-адресу для доступа к какому-то хосту. Основная ее фишка заключается в том, что она основана на «естественном поведении» хостов, которое вытекает из стандарта TCP/IP (RFC791). То есть это не проблема конкретной имплементации или проблема дизайна, а иное использование вполне безопасной с виду возможности — IP Source Routing. А мы такое ведь очень любим! К сожалению, скажу сразу, что атаку эту мало где можно сейчас применить, так как в большинстве ОС IP Source Routing отключено по умолчанию.
Но обо всем по порядку. Есть протокол IP, и изначально в него как раз была добавлена эта возможность (Source Routing). Суть ее заключается в том, что хост — отправитель пакета имеет возможность в заголовках IP-датаграммы указать, через какие хопы (конечные хосты, сетевое оборудование) этот пакет и ответ на него должны пройти. Да-да, мы можем указывать перечень устройств в пути пакета, то есть мы как бы «маршрутизируем» его.
Причем различаются два вида Source Routing: Strict и Loose. Первый — точное указание последовательности хостов (именно и только через них должен пройти пакет), второй — просто перечень хостов, через которые пакет должен пройти, то есть между этими хостами могут быть какие-то еще. Первый вид «изначально» практически не использовался, а вот второй до сих пор номинально жив. Максимальное количество хопов — девять. Практически эта возможность была задумана во многом для тестирования проблем в сети, чтобы мы со своего хоста могли проверить различные маршруты.
Окей, а теперь посмотрим на примерчике (взятом с www.enclaveforensics.com), как же мы можем это использовать в своих целях (см. скриншот).
Итак, у нас есть (упрощенно): Alice и Bob, у которых «доверительные» отношения. Например, c IP Bob’а можно без аутентификации подключаться по Telnet’у к Alice. Есть Ivan — просто хост в сети (принтер, сетевой девайс), у которого есть доступ в сеть Bob и Alice. Мы — Eddie и наш роутер — Lynksys (который на деле не очень и нужен). Задача — подключиться к Alice от IP Bob’а, в обход ограничений на доступ из нашей сети.
Как я думаю, ясно, по сути, мы можем указать IP Bob’a и отправить пакет Alice, но проблема в том, что Telnet — это TCP, а значит, «трехступенчатое рукопожатие», и значит, что Alice напрямую ответит Bob’у и подключения мы не получим. А вот с использованием Loose Source Routing — сможем. Для этого мы делаем такую последовательность:
- Отправляем пакет Alice с указанием в IP отправителя — Bob’а, а также IP-адреса Lynksys’а и Ivan’a в Source Routing.
- Пакет проходит через Lynsys, а потом через Ivan’a. При этом пакет обходит ограничения, которые наложены на нас
- Alice получает наш SYN-пакет, отвечает на него как для Bob’а, но так как у входящего пакета стоит Source Routing, то отвечает Bob’у с тем же списком. То есть пакет к Bob’у должен пройти опять через Ivan’а и наш LynkSys.
- И все бы дошло до Bob’а, да на нашем LynkSys’е мы пакет пересылаем на наш хост.
Таким образом, 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, в основном конфигурационные (а значит, вряд ли будут «пропатчены»).
Но что-то я разошелся. Давай по порядку и с начала.
Вот есть весь диапазон IPv4-адресов. Он меньше, чем общее количество всех сетевых устройств. Да даже если бы и выдать каждому по одному — это была бы неуправляемая каша. Поэтому достаточно давно выделили ряд диапазонов приватных/«серых» IP-адресов. Обычные же адреса называются публичными/«белыми».
Теперь представим себе, что ты сидишь дома с ноутом и смартфоном, у тебя есть Wi-Fi-роутер, все подключено к интернету. Представим, что у Wi-Fi-роутера есть «белый» IP (66.55.44.33), который ему назначил твой провайдер. Твой же ноут имеет IP-адрес из приватной сети, 192.168.0.123 например, а смартфон — 192.168.0.56. И ты хочешь подключиться к хосту 8.8.8.8 (белый IP). Но подключиться «напрямую» со своего серого IP не получится, 8.8.8.8 не сумеет отправить тебе ответ. Но ты же можешь отправить пакет через свой роутер (у него-то есть белый IP, и пакет вернется от 8.8.8.8 к нему). Но как же сделать, чтобы мы отправили пакет через роутер от IP роутера и при этом ответ бы пришел через роутер к нам? И здесь нам поможет NAT (Network Address Translation). Вообще, есть несколько видов NAT’а, но мы коснемся только конфигурации many-to-one (самой распространенной).
Итак, когда ты с ноута отправляешь запрос на 8.8.8.8, роутер получает Наш пакет (так как он стоит шлюзом по умолчанию у тебя на ноуте), видит, что запрос идет во внешнюю сеть, после через начинается процесс NAT’а:
- Роутер запоминает, с какого IP-адреса (192.168.0.123) и порта (1234) пришел запрос от тебя.
- Меняет в твоем пакете IP-адрес отправителя на свой публичный (66.55.44.33) и порт отправителя на свой незанятый внешний порт (5678).
- Запоминает это соотношение:
192.168.0.123:1234 = 66.55.44.33:5678 - Получив ответ от 8.8.8.8, роутер проверяет порт (5678), на который пришел запрос, и видит, что это соотношение сохранено у него.
- Роутер проводит обратное изменение: в IP-адрес назначения указывает 192.168.0.123, а в порт — 1234 и отправляет пакет на ноут.
Таким образом, для твоего ноута эти преобразования остаются незамеченными.
При этом твой смартфон также может ходить в интернет, и последовательность преобразований будет такой же. Разница лишь в том, что роутер выделит другой внешний порт для подключения со смартфона. То есть NAT-таблица будет выглядеть примерно так:
192.168.0.56:5555 = 66.55.44.33:5677
192.168.0.123:1234 = 66.55.44.33:5678В зависимости от порта, куда придет пакет с ответом, он будет переслан на тот или иной хост. Кстати, именно поэтому такой вид 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 создала новый протокол и поддерживает его в большинстве своих современных продуктов (насколько мне известно).
Главная его черта — простота. Используется UPD-порт 5351 для общения. Протокол бинарный. Никакой аутентификации не предусмотрено. И содержит, по сути, две команды (на деле чуть больше): пробрасывай данные с такого-то порта на такой-то хост и порт, скажи свой внешний IP-адрес.
Примерный, упрощенный алгоритм такой:
- Приложение ноута отправляет запрос на роутер «Пробрасывай TCP-порт 80 с внешнего интерфейса на 192.168.0.123 на 80».
- Если внешний порт 80 не занят, то роутер ответит, что данные будут пересылаться с 80-го порта на 192.168.0.123 на 80.
- Если внешний порт 80 занят, то роутер подставит какой-то свободный порт и ответит, что данные будут пересылаться с 4444-го порта на 192.168.0.123 на 80.
- Приложение с ноута запрашивает, какой внешний IP у роутера.
- Роутер отвечает со своим внешним IP-адресом 66.55.44.33.
- Приложение с ноута теперь знает, что коннекты на 66.55.44.33: 4444 будут приходить именно ему, и может «опубликовать» эти данные где-то в сети.
Казалось бы, что тут такого может случиться? Что тут вообще ломать, в особенности если ты находишься во внешней сети (интернете) и хочешь атаковать пользователей, находящихся за роутером?
Ребятки из Rapid7 провели интересную работу на эту тему и выявили ряд проблем. Основная была связана с некорректной настройкой конечных девайсов (роутеров). По стандарту, запросы NAT-PMP должны обрабатываться, когда они приходят с внутреннего диапазона, но на многих девайсах разрешена конфигурация и с WAN-интерфейса (то есть из сети Интернет). Данная и некоторые другие тонкости дают возможность для атак. Причем тут важно знать, что во многом это не проблемы конечных пользователей, а некорректная настройка из коробки, от вендоров роутеров. В итоге Rapid7 обнаружила в интернете порядка миллиона по-разному уязвимых устройств. Заметь, это было сканирование интернета, а если вспомнить, что очень многие пользователи находятся за NAT’ом от провайдеров, то число может возрасти в разы (правда, для атаки на них необходимо быть подключенными к данному провайдеру).
Самое же вкусное здесь — потенциальные векторы атак через эту технологию, а они тут, должен признаться, выглядят впечатляюще.
Перехват внутреннего трафика
Мы отправляем на внешний интерфейс на NAT-PMP запрос, чтобы весь входящий внутренний трафик такой-то порт был «проброшен» нам. То есть мы можем заставить роутер пересылать нам данные, приходящие на какой-то из внутренних портов его самого. А что это может быть? Во-первых, админка: порты 23, 22, 80, 443. Поднимаем у себя веб-сервер и снифаем креды. Но еще интересней захват DNS-запросов. Ведь роутеры очень часто используются как DNS-сервер, а тут мы такие взяли и указали проброс запросов себе. В итоге поднимаем поддельный DNS-сервак и имеем отличную возможность для различных MITM-атак.
Перехват внешнего трафика
Практически аналогичная атака. Но тут мы заставляем роутер перебрасывать все входящие подключения на внешний интерфейс роутера на наш хост.
Интересность данного варианта сильно зависит от ситуации.
Доступ к внутренний хостам (за NAT’ом)
Так как на самом деле в самом запросе к NAT-PMP мы не указываем IP-адрес, куда пересылать данные, а NAT-PMP берет эти данные из поля IP-адреса отправителя запроса, то мы можем за счет подмены адреса отправителя на внутренний адрес какого-то хоста за NAT’ом получать доступ к его сервисам. Например, мы из интернета можем послать NAT-PMP запрос от IP 192.168.0.123 на 445/TCP-порт на создание проброса и получить возможность сетевого доступа к 192.168.0.123 через SMB-протокол.
И последние три маленьких: возможность сканирования портов роутера без их сканирования (за счет различных ответов на закрытые/открытые порты), раскрытие внутреннего IP-адреса и DoS (за счет занятия всех портов). Мне кажется, что выглядит это впечатляюще. Но в реале подводных камней много.
Что еще приятно, в Metasploit’е теперь есть соответствующие модули для атак на сервисы NAT-PMP:
- NAT-PMP Port Mapper (auxiliary/admin/natpmp/natpmp_map) — для проброса портов;
- NAT-PMP External Port Scanner(auxiliary/scanner/natpmp/natpmp_portscan) — для сканирования портов;
- NAT-PMP External Address Scanner (auxiliary/gather/natpmp_external_address) — для получения IP-адреса роутера.
Спасибо за внимание и успешных познаний нового!
